1320 feet

I continue to be really busy with work, so I don’t have a lot of time for mapping or server stuff.

I have been progressing further on Makaska. The hydrology is pleasing, and contours feel like they’re falling into place and that it will be possible to actually finish them in a finite amount of time.

Another thing that needs working on to make a truly “US analogue” midwestern state such as Makaska, is that there need to be realistic county and township divisions. This means replicating the kinds of the errors and styles of 19th century “compass and chain” survey methods.

I am quite pleased with my results – not yet uploaded because I want to make sure the townships I’ve laid out are in sync with my ideas about where the rivers and county lines will go and I want everything to have a name, of course. Anyway, here is a screenshot in JOSM.

My title refers to the fact that the 19th century North American grid style was based on the mile, which is 5280 feet. A standard township was made up of 36 “sections”, 6 miles by 6 miles square. Each “section” was divided into quarters (160 acres, 2640 feet to a side) and those were further divided into “quarter quarters” (40 acres, 1320 feet to side). So in recreating the survey process for my fictional place, I “paced” my way across my entire state in 1320 foot lengths, imagining my surveyors stretching out their chain over and over. By doing it this way, I could introduce random “mistakes” that would render the result realistic, and I could account for the way the curvature of the earth forces periodic resets of the alignments of the north-south meridian lines.

So my grid contains these inconsistencies, and in a few places, I have deliberately failed to “walk” perfectly north/south/east/west, forcing a later realignment.

In the picture above, the little “tic marks” on the north-south “base meridian” are 1320 feet apart.

Music to map by: 블락비, “닐리리 맘보.”

Makaska

Work has been quite rough, lately. So I haven’t done much of anything geofictional.

However, isleño recently took AR120 “live” in OGF. AR120 is meant to be a kind of OGF version of the US. And I had long planned to make a state in this country. I gave up the vast majority of my territory in Mahhal (returning it to the unused country pool as AN160e) and exchanged it for a smallish “Great Lakes” state. This state will be Makaska.

Makaska is roughly modeled on Minnesota, and other upper midwest locations (Wisconsin, Michigan, Dakotas). It has a large, isthmic metropolis, called Ohunkagan – this is real-world Dakota language, which I studied once, long ago. Many of the place-names in Makaska will be from Dakota, including the actual state’s name.

I have actually done a lot of work on Makaska. But its shape was vague because I wasn’t sure which location I would get in OGF to implement it. So it was kind of schematic, with all these fragments of contour sections, hydrology, counties, etc.

Now I’ve begun the work of adapting these schemata to its actual location. I have more than 10 different JOSM layers, and I go back and forth, adjusting a river, rearranging some towns, etc. I used JOSM’s opendata plugin to upload about 300 placenames directly from a spreadsheet where I’d been working on them. So that’s a start.

Here’s a screenshot of the work-in-progress.

Music to map by: Niloo, “Ola Ola.”

A different sort of worldbuilding

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.

Music to MUD by: Maná, “En el muelle de San Blás.”

Mahhal Contours

I’ve been trying to organize my contour work for the new, smaller Mahhal. I’ve scaled the country back to a size where I think I can actually accomplish contours for the whole place in a finite amount of time, using my current methods. Mahhal is now just the northwesternmost 15% of the original archipelago. The remaining islands will eventually serve some other purpose, I suppose. Hopefully, it will be something very low density (Antarctic tundra and glaciers!).

Just like the Ardisphere, I felt the need to divide the contour work into manageable-sized “chunks”. Since the contour conversion program is based on a division of the planet into “degree squares” (which aren’t exactly square except at the equator, but anyway), I decided to do the same as I’d done in that country. However, because of the much higher latitude, and the fact that they’re all islands, I didn’t opt to try to subdivide each degree square into “bands.”

Currently I have four squares that are active. The 84°E Line splits Tárrases, so I have the two squares that straddle that island. And I have the two to the north, which are the northernmost reaches of the archipelago.

Below is a screenshot of the work, in JOSM. Each square is a different file (layer), so JOSM has four files open. Tárrases is complete, of course. The island directly west of the Duchy, Tteu (ዕሓ ጼዐ), is complete (though I might adjust some of it, later). Now the big island northeast, Kkogyra (ዕሓ ቆግራ) is complete too. That is where the capital and largest city of the Jessitim Kingdom, Piropeta, will be.

The matching view on the OGF standard map is here.

Music to map by: Rural Alberta Advantage, “On The Rocks.”

Not so geoficticiany, are we?

I have become rather obsessively immersed in a non-server-related, non-geofiction-related project. Such is my nature. I’m easily distracted by new projects.

As a result, though I still load these new geofictician sites and the OGF sites daily, and even comment occasionally or tweak something here and there, I haven’t really been doing much.

I’ll get back to this soon enough.

I did spend a few hours building Mahhalian contours, the other day, with a mind on fleshing out the new, leaner, smaller, faux Mahhal-for-OGF (because the “real” Mahhal will be a separate planet file on this here server thing, eventually).

Music to map by: 매드 클라운, “콩.”

Some weeks…

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.”

A more technical summary of how I built my tileserver – part 2

[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.]

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.”

Progress Made!

[Update 20180923: continued from here]

The OSM “Rails Port” is now running on my server, and I have successfully connected to the api via JOSM and rebuilt my test-version of my planet, Rahet.

It took me an entire week of googling and meditating before I solved the port problem. Ultimately, I was looking in the wrong place for clear documentation about it – I was hoping someone would write about it from the perspective of Rails, but finally I found the documentation that made it possible on the Passenger website, buried in an example. There’s a line that belongs in the apache config file, “PassengerRuby /usr/bin/ruby2.3” (or whatever version).

And that made all the difference.

Here’s the link: MAP.

So now you can look around. It’s just the “out-of-the-box” OpenStreetMap website (AKA Rails Port), with some minimal customization where I could find where to do it easily. I’ll continue working on that. I might actually disable the iD and Potlatch editing tools – I always use JOSM, and if it ever reaches a point where I’m allowing or inviting others to edit, I would make JOSM-use a prerequisite, I’m certain. JOSM, with its steep learning curve, seems like it would be a good way to “filter” people on the question of how serious they’re taking a project.

There are a number of features that don’t work. I would like to figure out a way to disable the user sign-up page. That’s a kind of vulnerability for the types of use I’m intending for this set-up. Meanwhile, I’ve disabled in a rather inelegant way by “breaking” the sign-up page (by changing its name inside the appropriate folder on the app/views/user path).

I’m happy.

I’ll write up how I figured out the coastline problem, tomorrow, and begin working on deciding what features to retain versus which to change in the Rails Port (i.e. think about customization).

[Update 20180923: continues here]

Music to map by: Run The Jewels, “Talk To Me.”

Not making progress

I wanted to post a part 2 for my last post, about how I got the tileserver working. I was going to talk about coastlines. In fact, my tileserver IS working, but it feels a bit useless without the other half: the so-called Rails Port.

So I have become obsessed with trying to get the Rails Port running. And I keep running into problems. The fundamental problem is that I have never used Ruby (and/or “Ruby on Rails”) before. I don’t really understand it. It’s not a development environment I have any comfort with at all. I don’t really even get the overall model.

I can get a local version of the generic “openstreetmap-website” code running on port 3000 on my desktop. And I can get a similar “development” version running on my server. But I don’t know all the places I need to edit to get the Rails Port to “look at” my tile server and not the default OSM tileservers. And I don’t know what other files I need to customize to control e.g. users, site security, name presentation, etc.

I think I’m going to have to take a timeout on trying to set this up, and spend some time learning how to deploy a much simpler Ruby app on my server.

One bit that seems like it should be utterly trivial is how to get the application to present on port 80 (standard webpage) instead of port 3000 (Ruby’s default development port, I guess). I have installed Passenger for Apache and that’s how I can present the application on port 3000, but I guess Rails doesn’t cohabit well with other applications on Apache – e.g. the wiki, this blog, etc. So somehow… it has to get “wrapped” or “proxied” but the details of how to configure this are beyond my expertise.

I’m frustrated, so I’m going to take a break from this server stuff.

Music to map by: 박경애 – 곡예사의 첫사랑

A more technical summary of how I built my tileserver – part 1

I thought I should put a discussion of how I did this, with much more detail, as I am sure there are other people out there in the world who might want to do something similar.

This is part 1. I’ll post part 2 later.

Background

I wanted to be able to serve Openstreetmap-style map tiles of my own fictional planet, in the same way that the site OpenGeofiction does, but using my own data set.

This process of building a tileserver is separate from the job of setting up an Openstreetmap-style apidb database to be able to edit the data set using tools such as iD, Potlatch, or JOSM. I’m still working on that.

Platform and Preliminaries

I deliberately set up my server on Ubuntu 16.04 (a flavor of Debian Linux) because I knew that OpenGeofiction runs in this environment. I’m not actually sure, but I assume Openstreetmap does too, though, given its scale, that may not be exactly the case, anymore – more likely it’s got a kind of customized, clustered Linux fork that has some genetic relationship to Ubuntu.

I thought it would therefore be easier to replicate the OpenGeofiction application stack.

Before starting this work, I had already installed MySQL and Apache and Mediawiki – except for Apache, however, these are not relevant to setting up a tileserver.

I had also already set up PostgreSQL (the preferred Openstreetmap database server), so the preliminary mentions of setting up this application were skipped.

Finally, using Apache’s sites-available config files and DNS, I had set up a subdomain on my server, tile.geofictician.net, to be the “outside address” for my tileserver. This will hopefully mean that if I ever decide to separate my tileserver from other things running on the same server, it will be somewhat easier to do.

S2OMBaTS with Deviations

Starting out, I mostly followed the steps and documentation at switch2osm.org’s detailed tutorial, here. Below, I refer to this page as S2OMBaTS (“switch2osm manually building a tile server”).

So I don’t see any need to repeat everything it says there. I just followed the steps given on that webpage exactly and religiously. What I’ll document are only the spots where I had to do something differently. These are my “deviations.”

  1. Where S2OMBaTS suggests creating a ‘renderaccount’ on the server to own all the tileserver-related directories and tools, I used my non-root regular username. I’m not sure this is good practice, and if I were setting something up as a “production” environment, I’d be more careful to segregate ownership of this collection of files, applications and services.
  2. There are some problems with authenticating a non-root user for PostgresSQL (‘root’ being the infamous ‘postgres’ superuser). I had to edit the /etc/postgresql/9.5/main/pg_hba.conf file so that the authentication method was “trust”[css]
    # Database administrative login by Unix domain socket
    local all postgres trust

    # TYPE DATABASE USER ADDRESS METHOD

    # “local” is for Unix domain socket connections only
    local all all trust
    [/css]

    I think this might be a bad solution from a security standpoint, but it’s the only one I could find that I understood and could get to work. PostgreSQL security is weird, to me. My DBA experience was entirely with SQLServer and Oracle, back in the day, and those databases’ security are integrated to OS security more tightly, I think. Similarly, MySQL seems to assume linkages between system users and database users, so security for the matched pairs of users are linked. But it seems like PostgreSQL doesn’t work that way.

  3. Where S2OMBaTS suggests using the URI=/hot/ in the /usr/local/etc/renderd.conf file (which seems intended to hijack other applications’ support for the already-existing “HOT” – Humanitarian Openstreetmap Team – layer). I used URI=/h/ instead, which was entirely arbitrary and I could just as easily have used something more meaningful, as at OpenGeofiction, with e.g. URI=/osmcarto/.
  4. To test my installation, of course, I had to load some test data. S2OMBaTS uses a geofabrik snapshot of Azerbaijan. I decided just for the sake of familiarity, to use a snapshot of South Korea. I had to spend quite a bit of time researching and tweaking the individual osm2pgsql options (parameters) to get it to run on my itty-bitty server, even for a fairly small dataset like South Korea’s OSM snapshot, so here’s the osm2pgsql invokation I used to load the data (YMMV).
    osm2pgsql --database gis --create --slim  --multi-geometry --keep-coastlines --hstore --verbose --tag-transform-script ~/src/openstreetmap-carto/openstreetmap-carto.lua --cache 2500 --cache-strategy optimized --number-processes 1 --style ~/src/openstreetmap-carto/openstreetmap-carto.style ~/data/south-korea-latest.osm.pbf
    

At this point, I reached the end of the S2OMBaTS tutorial.

Loading my own planet

I then had to customize things to load my own planet instead of a largely “naked earth” with South Korea well-mapped. The first step was easy enough. I just replaced the South Korea pbf extract with a pbf of my own planet, and re-ran the osm2pgsql step. I got the pbf extract of my planet by working with some kludges and with JOSM on my desktop machine. It was a “simplified” planet – just the continent outlines, a few cities, two countries with their admin_level=2 boundaries, and one tiny outlying island with lots of detail, which I borrowed from my city-state Tárrases at OpenGeofiction. It was composed as a kind of “test-planet” to keep things simple but hopefully test most of what I wanted to achieve in my tileserver.

Here’s the load script for that (essentially the same as used for South Korea, above).

osm2pgsql --database gis --create --slim  --multi-geometry --keep-coastlines --hstore --verbose --tag-transform-script ~/src/openstreetmap-carto/openstreetmap-carto.lua --cache 2500 --cache-strategy optimized --number-processes 1 --style ~/src/openstreetmap-carto/openstreetmap-carto.style ~/data/gf-planet.osm.pbf

The problem, of course, is that if you run the render at this point, you get all the features of the new planet, but the continent outlines and the land-water distinction is “inherited” from earth. That’s because the mapnik style being used is referencing the shapefiles produced by and downloaded from Openstreetmap. The creators of the Openstreetmap software, including the OSM carto style, didn’t take into account the possibility that someone would try to use their software to show a map of somewhere that wasn’t planet Earth, and consequently, these need for these shapefiles is “hardcoded.” So the “Earth” shapefiles have to be substituted by alternate shapefiles extracted from the alternate planet dataset.

Customizing Coastlines and Shapefile Hell

This was the hardest part for me. It took me more than a week to figure it all out. I’m not experienced with shapefiles, and don’t really understand them, and the process by which shapefiles get extracted from the OSM global dataset in a format that can be used by the openstreetmap-carto mapnik style is very poorly documented, online. So it was a lot of google-fu and experimentation, and downloading QGIS and teaching myself a bit about shapefiles, before I could get things working. It’s not clear to me that I really did it the right way. All I can say is that it seems to work.

The first steps I took were to try to simplify my task. I did this by chasing down the shapefile dependencies in the mapnik style sheet, and manually removing the ones that seemed less important. I did this mostly through trial and error.

The only file that needs to be edited to accomplish this simplification is the main mapnik xml file: <YOUR-PATH>/openstreetmap-carto/mapnik.xml. Bear in mind, though, that this file is the output of the carto engine (or whatever it’s called). By editing it, I have “broken” it – I won’t be able to upgrade my OSM carto style easily. But this is just a test run, right? I just wanted to get it to work.

So I edited the <YOUR-PATH>/openstreetmap-carto/mapnik.xml file and deleted some stuff. You have to be comfortable just going in and hacking around the giant xml file – just remember to only delete things at the same branch level of the tree structure so you don’t end up breaking the tree.

I removed the <Style></Style> sections that mentioned Antarctic icesheets – there were two. As things stand, my planet has no Antarctic icesheets, so why try to incorporate shapefiles supporting them?

Then, I eliminated the<Style></Style> section mentioning the <YOUR-PATH>/openstreetmap-carto/data/ne_110m_admin_0_boundary_lines_land directory, since these are land-boundaries for Earthly nations. I figured if I couldn’t see land-boundaries for my planet’s nations at low zooms, it would be no big deal. It’s not clear to me that this has been implemented on OpenGeofiction, either.

I also discovered that in fact, this file doesn’t even point to the <YOUR-PATH>/openstreetmap-carto/data/world_boundaries directory. So there was no need to worry about that one.

So that left me with two shapefiles I had to recreate for my own planet’s data:
<YOUR-PATH>/openstreetmap-carto/data/land-polygons-split-3857/land_polygons.shp and <YOUR-PATH>/openstreetmap-carto/data/simplified-land-polygons-complete-3857/simplified_land_polygons.shp.

Let’s just summarize by saying that this is what took so long. I had to figure out how to create shapefiles that the mapnik style would know what to do with, so that my continents would appear on the render. It took a lot of trial and error, but I’ll document what’s working for me, so far.

*** To be continued ***

[Update 20180923: Continues here]

Music to map by: Héctor Acosta, “Tu Veneno.”