Category: Geofiction

[This is a cross-post from my other blog.]

I have utterly neglected this blog [meaning that other blog].

I offer no excuses. Just didn’t cross my mind. I had other things going on. I have other blogs and other, non-geofictional projects that occupy me.

In fact, I have been quite busy with geofiction, too. Over the last 6 months since my last blog post here, I have been developing my “Ohunkagan 1880” snapshot, at OpenGeofiction. This is my city in my fictional state of Makaska, in the parallel-universe US called FSA. Here is a screenshot of the city, in its 1880 incarnation. I intend to then roll the historical window forward, mapping in changes and additions, over the coming decades, until it catches up to the present.

[Technical note: screenshot taken at this URL (for future screenshots to match).]

But I have also been working on my own, long-neglected map server. I have named my planet: Arhet.

It’s just a name. But one thing that always annoyed me about OGF was that the planet not only lacks a name, but there has always been strong community resistance to finding a consensus name for it. Someone is always bound to object to any proposal, and thus, “OGF world” remains unnamed. For my planet, I decided to just put a name on it from the start, so no one would end up grappling with the dilemma later.

Arhet is tentatively open to interested mappers. I’ve written up my current thinking on how this will work, here:

http://wiki.geofictician.net/wiki/index.php/Arhet

Music to make worlds by: The Youngsters, “Smile (Sasha Remix)”.

[This is a cross-post from my other blog.]

I finally got tired of dealing with Windows 10 drama, and decided to rebuild my preferred Ubuntu Linux desktop, as I’d been using in Korea before moving away last July.

I’ve made good progress on that, and have JOSM up and working again, and all that. But I became aware, as I was migrating my data and files, that I have a lot of files I would rather not lose, especially related to my geofiction. I need some systematic means of keeping stuff backed up.

I handled the issue of backup and redundancy for my creative writing years ago, when I started storing all my drafts and notes in google docs. It’s convenient, too, because I can get to my writing no matter where I am.

But I have no such system for all my .osm files for the geofiction. Especially important are the .osm files I use for drawing the topo layer, since those are never uploaded anywhere except temporarily at the time of an update.

I suppose I could just copy the files. But I decided I needed to store them in some kind of version-controlled space. About two years ago, I’d had them in a git repository but it was just copied out to an extra harddrive. I used git for some other stuff I used to do, so it wasn’t that hard to figure out.

I decided this time to try something different – I made a repository on github and decided to put my topo .osm files there. If I get in the habit of regularly updating the git repository, I’ll always have those topo files, no matter what happens to my computer or where I am. Further, if ever I go in the direction of wanting to collaborate on drawing topo files, this will make it really easy (assuming the other person is up to dealing with checking things out of a git repository). [UPDATE: this was a short-lived effort. Subsequently the files are just files, again, but they live on one of my HRATE servers]

If ever there will be a truly collaborative geofiction “planet” with a master topo layer, this might be a way to maintain that information, since practically speaking it can’t and shouldn’t be uploaded to the map server. Just an experiment, I guess, and meanwhile I’ll have a reliable backup of my work.

Music to map by: 선미, “가시나.“

[This is cross-posted from my other blog.]

This isn't exactly geofiction, but I was messing around with a new project on my server.

Way back in the day (I am somewhat old), I used to play MUDs (Multi-User Dungeons). These are text-based computer games of various kinds – no graphics at all. They're a kind interactive "choose your own adventure" text, you might say. But the game mechanics in them are the ancestors of modern MMORPGs such as World of Warcraft, and there are even conceptual connections to Grand Theft Auto or Minecraft.

MUDs are quite old – they existed on mainframes at businesses and universities before PCs were even a thing, starting in the 1960s. Because of my family's connection to the local university, I was a rare child of the 1970s who actually played computer games before PCs were invented! These were MUDs and other text-based games.

When I noticed I had my own server up and running, it occured to me that I could build a MUD. Possibly, it's not even that hard. Sure enough, there is open-source software that will run a MUD on a server for you.

I chose a package called CoffeeMud. I'm still messing with it. It's very unlikely I'll ever do anything with it. But I had this domain-name, "Hellbridge.com", lying around, so I thought, sure, make a MUD.

  _    _        _  _  _            _      _
| |  | |      | || || |          (_)    | |
| |__| |  ___ | || || |__   _ __  _   __| |  __ _   ___
|  __  | / _ \| || || '_ \ | '__|| | / _` | / _` | / _ \
| |  | ||  __/| || || |_) || |   | || (_| || (_| ||  __/
|_|  |_| \___||_||_||_.__/ |_|   |_| \__,_| \__, | \___|
__/ |
Hellbridge.com                   |___/
Powered by CoffeeMud v5.9

I originally acquired the "Hellbridge.com" domain for a quite different purpose: It was intended to be a "satire-website" for a place where I once worked, which had a name where "Hellbridge" was a similar sound but darker connotation. But looking at it now, I thought it would make a great name for a MUD. So there it is.

I liked the CoffeeMud package because the admin and config of the site is mostly done from within the game. That's cool. So I create an "Archon" character, who is like God. I walk around the MUD and type "Create chair" and a chair falls from the sky. Likewise with any other object, room, monster, or character class. That's fun.

The Archon character is created in the empty, default "Fresh Install" room, by reading a book that is placed there. I read the book and I became a God.

Nice book. Note the stats jump in the prompt.

<20Hp 100m 100mv> read book
The manual glows softly, enveloping you in its magical energy.
The book vanishes out of your hands.
<1403Hp 571m 595mv>

It's not live yet. It may never be. But meanwhile, I thought it was interesting to try it out.

It's a little bit like geofiction – you're creating an imaginary world, after all.

[daily log: walking, 7km]

[This is a cross-post from my other blog.]

And then, some weeks, I don’t get much done.

I started working on trying to customize my Rails Port (the main “copy” of the OpenStreetMap slippy map), and got very bogged down in the fact that the OpenStreetMap Rails Port is highly complex software written in a language and using an architecture unfamiliar to me: the infamous “Ruby on Rails.”

I dislike the way that the actual name “OpenStreetMap” is hard-coded throughout all the little modules. It seems like a poor application design practice, especially for an opensource project. One area where the name proliferates is in all the internationalization files. So I started wondering how hard it might be to get all these internationalization files to be more “generic.” The answer: pretty hard, at least for me.

I’ve wandered off down a digressive passage where I’m learning about software internationalization under the Ruby on Rails paradigm, but I’m undecided how I want to handle this. Do I want to try to solve it the “right way”? Or just kludge it (most likely by deleting all the internationalization files except perhaps English, Spanish, and Korean)?

Meanwhile I have also got pulled away by some non-computer, non-geofiction projects.

So… not much to report, this week – nothing mapped, nothing coded, nothing configured.

Music to map by: Sergei Rachmaninoff, “Piano Concerto No. 2.”

[The following is a direct cross-post from my other blog – just so you don’t think I’m doing nothing with my free time, these days.]
[Update 20180923: continues from here]

The objective

I started discussing the coastline shapefile problem in first post.

Early on, I found the tool called QGIS Browser and installed it on my desktop. I used this to examine the shapefiles I was creating.

The first step was to look at the “real Earth” OpenStreetMap-provided shapefiles I was trying to emulate – the two mentioned in my previous post:
/openstreetmap-carto/data/land-polygons-split-3857/land_polygons.shp
and
/openstreetmap-carto/data/simplified-land-polygons-complete-3857/simplified_land_polygons.shp

Here are screenshots of each one.

First, land_polygons.shp

And here is simplified_land_polygons.shp

The structure is pretty straightforward, but – how do I make these? Where do they come from? – aside from the non-useful explanation found most places, which is that “OpenStreetMap generates them from the data”.

The coastline problem

The way that the shapefiles are generated for OpenStreetMap are not well documented. But after looking around, I found a tool on github (a software code-sharing site) developed by one of the OpenStreetMap gods, Jochen Topf. It is called osmcoastline, which seemed to be the right way to proceed. I imagined (though I don’t actually know this) that this is what’s being used on the OpenStreetMap website to generate these shapefiles.

The first thing I had to do was get the osmcoastline tool working, which was not trivial, because apparently a lot of its components and prerequisites are not in their most up-to-date or compatible versions in the Ubuntu default repositories.

So for many of the most important parts, I needed to download each chunk of source code and compile them, one by one. Here is the detailed breakdown (in case someone is trying to find how to do this).

Installing osmcoastline

I followed the instructions on the github site (https://github.com/osmcode/osmcoastline), but had to compile my own version of things more than that site implied was necessary. Note that there are other prerequisites not listed below here, like git, which can be gotten via standard repositories, e.g. using apt-get on Ubuntu. What follows took about a day to figure out, with many false starts and incompatible installs, uninstalls, re-installs, as I figured out which things needed up-to-date versions and which could use the repository versions.

I have a directory called src on my user home directory on my server. So first I went there to do all this work.
cd ~/src

I added these utilities:
sudo apt-get install libboost-program-options-dev libboost-dev libprotobuf-dev protobuf-compiler libosmpbf-dev zlib1g-dev libexpat1-dev cmake libutfcpp-dev zlib1g-dev libgdal1-dev libgeos-dev sqlite3 pandoc

I got the most up-to-date version of libosmium (which did not require compile because it’s just a collections of headers):
git clone https://github.com/osmcode/libosmium.git

Then I had to install protozero (and the repository version seemed incompatible, so I had to go back, uninstall, and compile my own, like this):

Git the files…
git clone https://github.com/mapbox/protozero.git
Then compile it…
cd protozero
mkdir build
cd build
cmake ..
make
ctest
sudo make install

I had to do the same for the osmium toolset:

Git the files…
git clone https://github.com/osmcode/osmium-tool.git
Then compile it…
cd osmium-tool
mkdir build
cd build
cmake ..
make

That takes care of the prerequisites. Installing in the tool itself is the same process, though:

Git the files…
git clone https://github.com/osmcode/osmcoastline.git
Then compile it…
cd osmcoastline
mkdir build
cd build
cmake ..
make

I had to test the osmcoastline tool:
./runtest.sh

Using osmcoastline for OGF data

So now I had to try it out. Bear in mind that each command line below took several hours (even days!) of trial and error before I figured out what I was doing. So what you see looks simple, but it took me a long time to figure out. In each case, after making the shapefile, I would copy it over to my desktop and look at it, using the QGIS browser tool. This helped me get an in intuitive, visual feel of what it was I was creating, and helped me understand the processes better. I’ll put in screenshots of the resulting QGIS Browser shapefile preview.

To start out, I decided to use the OGF (OpenGeofiction) planet file. This was because the shapefiles were clearly being successfully generated on the site, but I didn’t have access to them – so it seemed the right level of challenge to try to replicate the process. It took me a few days to figure it out. Here’s what I found.

Just running the osmcoastline tool in what you might call “regular” mode (but with the right projection!) got me a set of files that looked right. Here’s the command line invocation I used:
YOUR-PATH/src/osmcoastline/build/src/osmcoastline --verbose --srs=3857 --overwrite --output-lines --output-polygons=both --output-rings --output-database "YOUR-PATH/data/ogf-coastlines-split.db" "YOUR-PATH/data/ogf-planet.osm.pbf"

Then you turn the mini self-contained database file into a shapefile set using a utility called ogr2ogr (I guess part of osmium?):
ogr2ogr -f "ESRI Shapefile" land_polygons.shp ogf-coastlines-split.db land_polygons

This gives a set of four files
land_polygons.dbf
land_polygons.prj
land_polygons.shp
land_polygons.shx

Here is a view of the .shp file in the QGIS Browser. Looks good.

I copied these files into the /openstreetmap-carto/data/land-polygons-split-3857/ directory, and I tried to run renderd. This alone doesn’t show the expected “ghost” of the OGF continenents, though. Clearly the simplified_land_polygons.shp are also needed.

So now I experimented, and finally got something “simplified” by running the following command line invocation (note setting of –max-points=0, which apparently prevents the fractal-like subdivision of complex shapes – technically this is not really “simplified” but the end result seemed to satisfy the osm-carto requirements):
YOUR-PATH/src/osmcoastline/build/src/osmcoastline --verbose --srs=3857 --overwrite --output-lines --output-rings --max-points=0 --output-database "YOUR-PATH/data/ogf-coastlines-unsplit.db" "YOUR-PATH/data/ogf-planet.osm.pbf"

Again, make the database file into shapefiles:
ogr2ogr -f "ESRI Shapefile" simplified_land_polygons.shp ogf-coastlines-unsplit.db land_polygons

This gives another set of four files
simplified_land_polygons.dbf
simplified_land_polygons.prj
simplified_land_polygons.shp
simplified_land_polygons.shx

And this .shp looks like this:

Now when I copied these files to the /openstreetmap-carto/data/simplified-land-polygons-complete-3857/ directory, and re-ran renderd, I got a successful ghosting of the continents in the render (no screenshot, sorry, I forgot to take one).

Using osmcoastline for my own data

Now I simply repeated the above, in every respect, but substituing my own rahet-planet.osm.pbf file for the ogf-planet.osm.pbf file above. I got the following shapefiles:

land_polygons.shp

simplified_land_polygons.shp

And these, copied to the appropriate osm-carto data directory locations, gives me the beautiful render you see now. [EDIT: Note that the view below of the Rahet planet is “live”, and therefore doesn’t match what shows in the screenshots above. I have moved in a different concept with my planet, and thus I have erased most of the continents and added different ones, and the planet is now called Arhet.]

I actually suspect this way that I did it is not the completely “right” way to do things. My main objective was to give the osm-carto shapefiles it would find satisfactory – it was not to try to reverse-engineer the actual OSM or OGF “coastline” processes.

There may be something kludgey about using the output of the second coastline run in the above two instances as the “simplified” shapefile, and this kludge might break if the Rahet or OGF planet coastlines were more complex, as they are for “Real Earth.” But I’ll save that problem for a future day.

A more immediate shapefile-based project would be to build north and south pole icecaps for Rahet, in parallel with the “Real Earth” Antarctic icesheets that I disabled for the current set-up. You can see where the icecaps belong – they are both sea-basins for the planet Rahet, but they are filled with glacial ice, cf. Antarctica’s probably below-sea-level central basin. And the planet Mahhal (my other planet) will require immense ice caps on both poles, down to about 45° latitude, since the planet is much colder than Earth or Rahet (tropical Mahhal has a climate similar to Alaska or Norway).

Happy mapping.

Music to map by: Café Tacuba, “El Borrego.”

At the risk of becoming boring, posting on the same essentially autobiographical topic for the third day in a row…

I continue to obsessively mess around with my computer, trying to figure out what happened to it. There is a component of my personality that is a compulsive tinkerer, and thus I somehow prefer to try to fix a clearly dying computer to buying a new one. I suppose partly I see it as an opportunity to "prove myself" and make sure I possess at least some of the skills necessary to be "self-sufficient" in the context of computers.

I made a very weird thing happen: when I gave my computer a complete "cold" shutdown (i.e. I removed the onboard battery, which forces the BIOS to reset), my USB bus returned to life! This seems quite weird and miraculous, but I can just barely grasp how this might work. If something happened that had caused my BIOS to break, which had in turn been the cause of the lost USB bus, by forcing the reset I recovered the original BIOS configuration.

Well, anyway, in theory this means my computer isn't actually broken, at the moment. But I have lost my trust in my computer – I'm working hard to make sure nothing would be lost if it should crash catastrophically. This is a useful exercise, which I don't resent.

I continue to tinker with Linux – it's interesting to me, at an almost obsessive level. I'm curious, now, to see if I can replicate ALL the functions I was performing on my home Windows machine – because my relationship with Windows was always a marriage not of love but of convenience. I had concluded 4 years ago that I could NOT replicate all those functions, but having solved the language issue yesterday, I feel optimistic that Ubuntu has progressed to the point where I maybe can do it.

There are some challenges:

• getting my massive music collection (18000 tracks? – I didn't even know!) to be accessible and playable – every time I try to configure one of ubuntu's music players and point it to my music collection, it crashes;
• configuring my  offline mapping tool (JOSM) that use for my geofiction hobby; this should be easy, since JOSM was originally written for Linux, but I'm running into problems;
• replicating my "sandbox" database (postgresql) and coding environment (perl / python) – because I have a mostly dormant hobby of trying to keep my programming skills functional, in case this "teach English in Korea" gig falls apart, or if that worst-case-scenario related to my mouth health situation eventuates, and I experience a major impairment or loss of my ability to talk.

[daily log: walking, 7km]