Day: March 5, 2022

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

This will be a fairly long write-up, so depending on your interests, you can skip sections that aren’t useful to you.

First I will write about the OGF topo layer, and give a tour of its current status, with some discussion of how it works.

Then in subsequent sections I will try to discuss how to create or edit your own contributions to the OGF Topo layer.

Part I – Introducing The OGF Topo Layer

The term “topo” (short for topographic) refers to a style of map that shows the physical elevation of land, either through shading or drawing contour lines or both. There are many topo renders available for the OpenStreetMap platform. My own favorite for daily use is the Cycle Map layer on OSM – not for any specific reason except that it’s easy to get to – it’s included right there in the layer selector for the OSM site. The best known, however, and one of the oldest, is the separately built and maintained OpenTopoMap. The code for OpenTopoMap is freely available on github.

All the various implementations of topo style for OpenStreetMap rely on the easy availability of free data from the United States’ NASA. This agency did a planet-wide survey of the elevation of all the land in the world on an arc-second (approx. 30-meter) grid, using radar, and published that data, online, for anyone to use. This data is called “SRTM”. Developers implementing OpenStreetMap’s various topo layers are able to download and use this SRTM data to use as a raw source of the detailed topographic information needed to draw the map. So, in the case of OpenTopoMap, the SRTM data is loaded to the render machine, processed in various ways, and turned into the hillshading, contour lines, and map-elevation color shading that we all know and love.

For the real world, getting topo data is matter of launching a spacecraft or satellite with a little radar range-finder on it, and flying over the surface of the earth finding how high each part of the earth is relative to some baseline (i.e. mean high sea level). Easy! But OpenGeofiction is on a fictional planet. To repurprose Virginia Woolf’s famous line: There’s no there, there.

Instead we have to sit down and make up each square of elevation information – there’s got to be a 30-meter square grid for our entire imaginary planet, and we have to invent the elevation for each and every square! And just randomizing this isn’t going to work – real world topographic data betrays the evolved geophysical patterns of our planet, influenced by everything from plate tectonics to vulcanism to erosion to human landscaping. The data is going to have to either be “drawn” by creative human hands, or “drawn” by well-trained machine-learning AI’s. Both are possible in principle, but then we have the data problem.

The data problem is this: the NASA SRTM format was developed for storing real world data. But no one ever thought: we need a nice, user-friendly, SRTM file editor! Why? Because no one needs to edit real-world data. It came from a super-precise scientific gadget, who’s going to need to edit that? They could only mess it up.

So there simply does not exist any easy way to get the “imaginary” SRTM files that we need for our topo layer. Some geofiction genius is going to need to write a converter.

Luckily, OpenGeofiction has such a genius. The original creator of OpenGeofiction, Thilo, wrote a little program that turns a standard OSM XML format file (.osm) that has been filled with hand-drawn contour lines (tagged contour=elevation / ele=nnn) into a pseudo-SRTM format file (.hgt). Then we just need to install the standard OpenTopoMap software on our render server, copy the pseudo-SRTM files across, and voila, topo for OGF!

Still, we have a whole planet to cover. At this point in time (the time of writing this article, early 2022) the overall coverage for OGF’s topo layer is tiny, and of fairly low quality, on average, so far.

One of the main reasons I started my “OGF Mirror” project, last year, was because Thilo had decided he could no longer invest the time and energy required to support the topo layer for OpenGeofiction. I had a strong desire to see the topo layer continue to be supported and expand. Eventually that “OGF Mirror” became the migration project and I and user wangi and some other admin took over running OGF from Thilo, with his blessing. So it was my interest in topo that led to my taking on all this work for OGF, and therefore it remains of a focus of my efforts, moving forward.

Part II – The Current OGF Topo Zones

OpenGeofiction currently has 14 actively maintained topo zones. Here they are, in alphabetical order.

zone-alved

This zone has been created by mapper SwissCrusader. It’s a first draft, and clearly needs a lot of cleanup work, but it’s an excellent and ambitious start.

zone-gobras

This zone actually is two smaller areas that have been combined because of their close proximity. The older is the topo work for Khaiwoon, on the eastern tip of the Gobrassanya peninsula. The territory is one of the oldest on OGF. It was developed by user isleño with a lot of additional mapping by user histor. The contours were drawn as a collaboration between thilo and isleño. The other is the background topo for Gobras City, to the northwest. Gobras City is one of the most successful wholly public and collaborative projects on OGF, created by a very large number of different mappers over almost a decade, now. User Ūdilugbulgidħū volunteered to draw contours for the city, and in my opinion, they are quite excellent. Obviously, since the contours were drawn after much of the city, and since there is work in the city drawn without a strong awareness of the contours, there are areas where the human development (roads, etc) doesn’t really properly “match” the contours as drawn.

zone-gwynian

This zone is also actually two adjacent areas combined because of proximity. The older part, to the west, is my own work (user Luciano), drawn for my territory Ardisphere, in 2014-2016. I think it has well-done areas, but it’s quite noticeably incomplete, full of lacunae and missing expanses and weird glitches where the contour work is too sparse to properly cover the map. The newer part, currently in development by user Martinawa, is the largest single expanse of topo work on OGF, and still in early stages across most of the territory, but it’s got a lot of promise.

zone-hesperis

This is a quite small but complete set of contours for an island territory drawn by mapper Ūdilugbulgidħū.

zone-iscu

This zone includes several islands in a chain called Iscu, drawn by mapper Lithium-Ion. The contours are quite detailed and excellent.

zone-izaland

This zone includes a few of the southern islands of a the nation called Izaland, by the user Izaland Terramorphing Committee. I’m looking forward to seeing more of Izaland getting contours.

zone-january

I (user Luciano) drew these islands as part of a collaborative effort between myself and mapper deltanz. I later turned over the islands to deltanz. Personally I think they are my “most complete” set of contours among those I have done.

zone-kofuku

This is a new effort by mapper Huachachi. Kofuku is an immense territory and so far these are just a few islands off that country’s north coast. They are excellently done, and I’m looking forward to seeing more of Kofuku with contours.

zone-kojo

I (user Luciano) did a small spot of contours in collaboration with user Leowezy some years ago, in the southernmost spot of this zone, at the Joenji Peninsula. Leowezy has subsequently been gradually adding other areas of coverage for his territory, Kojo. Hopefully will come in the future.

zone-makaska

This zone actually overlaps not just the territory of Makaska, but also the one to the south, called Ooayatais. I (user Luciano) own both of these territories. The northern territory, Makaska, has a very complete set of contours and is work I’m quite proud of. The southern territory, Ooayatais is much lower quality and, for now, also quite incomplete. It’s my “current project” with contour mapping, however, and hopefully sometime later this year I’ll upload a major update.

zone-roantra

This is the oldest and, arguably, best of all the topo zones on OGF. User thilo, the original creator of OpenGeofiction, uploaded this topo zone when he first created the OGF server, for his territory Roantra. It is the archetype of OSM-style topo work.

zone-ruanerara

This is a small project done by user Toadwart for his outlying (overseas) territory of his country, KA076 (apparently this mapper recently decided to change the name of the country, and the new name hasn’t been decided on). Anyway, the contours are clearly still in development but I’m looking forward to seeing more progress.

zone-tapira

This zone, a small island, was created by mapper Ūdilugbulgidħū, but he subsequently gave up the territory. It’s someone’s chance to take on an already-existing topo project.

zone-tarrases

This is another of my own (user Luciano) territories. The Duchy of Tárrases is the one case where I quite successfully imposed a set of contours on an already-created map. I’m quite happy with the result. The surrounding islands used to be owned by me, too, but for now they are in a bit of limbo. For that reason I haven’t bothered to repair the mess of half-finished contours on those surrounding islands.

Part III – Create A New Topo Zone

There is quite a bit of work involved in creating a new topo zone for the ogf-topo rendering process. Multiple new working and data directories must be created, code must be added to xml layer specifications and data-processing scripts, and the proper raw contour templates need to be created and populated with initial draft contour data.

Therefore if you want to create a new topo zone for your OGF territory, you need to contact me and we can discuss, so I can get things set up and I can create the templates you’ll need to draw your contours (see next section). There is nothing wrong with diving in and drawing contours for yourself before contacting me, but bear in mind you’ll probably end up doing a lot of cutting and pasting and manipulation using the JOSM editor once I’ve created those templates for you, because I will no longer accept contour data drawn in files other than the pre-created templates.

If you’re trying to decide whether or not you want to create a topo zone, one good way to get a feel for what’s involved is to download one of the osm-squares from the server (see below) and just go ahead and open that up in JOSM and try to get a feel for how it works and what’s involved. Start with something small, complete and well-done, like the January Islands or Hesperis (see above).

Part IV – Edit or Improve An Existing Topo Zone

In the past, I’ve allowed users to simply submit new, hand-drawn “contour files” which I then clean up and process using the tools at hand. However, I have found that the first step – cleaning up the submitted files – can be quite tedious and time-consuming, and further, I often end up repeating work as newly submitted files have the same problems as previous iterations.

I would like to move toward a more reliable system of iterative improvement. To do this, if there is an already-existing topo zone and you want to add to it or improve it, you must download the existing osm-squares (contour files) from the ogfsrtm server, edit those, and send the edited copies of those files back to me. Do not try to bypass this process – I have special tags embedded in those contour files as found on the server, and I’ll know if you haven’t used those as a basis for your edits.

You can find downloadable individual squares for most topo zones at this location on the ogfsrtm server: https://ogfsrtm.rent-a-planet.com/osm-squares/

If a given square is missing from the server, contact me and I’ll create an initial template for that square and post it there, that you can then edit. Don’t try to create squares not found on the server.

Part V – An Alternative Pathway To Maintaining Your Own Topo Zone

If all this business of drawing vast numbers of contour lines in JOSM is not your style, there is, in fact, an alternative. You can directly submit NASA-SRTM format compliant .hgt files. This bypasses the whole contour conversion process, and would be quite a bit easier for me to do.

That said, so far, no one has done this successfully. There have been challenges to finding a program that produces .hgt files in the exact NASA-SRTM format expected by the OpenTopoMap rendering software. If, as a community, we find such a tool in the future, that may make a lot of what’s written above obsolete and we’ll have a better way to do things, moving forward.

Regardless, if you want to try doing it this way, you still need to contact me in advance, so I can set up the new zone on the render server – that aspect won’t change. Then you’d send me the pseudo-SRTM files (.hgt) so I can post them on the ogfsrtm server in the proper directory, since that’s where the render server expects to find them.