OpenGeofiction:Topo layer

What is a topo layer?

That's easy! 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.

How is a topo layer made?

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.

Does OpenGeofiction have a topo layer?

Yes it does! But it's not a simple thing to have or do.

Think about it: as explained above, 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 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.

Where can I see OGF's topo layer, right now?

For ease of administration and maintenance, the "active" areas of the topo layer for OpenGeofiction are divided into "zones." There are currently 10 active zones, which are as follows (in alphabetical order by their somewhat arbitrary names).

• zone-gobras
• zone-gwynian
• zone-hesperis
• zone-iscu (not currently loaded)
• zone-january
• zone-kofuku
• zone-kojo
• zone-makaska
• zone-roantra
• zone-ruanerara
• zone-tapira
• zone-tarrases
• zone-tekan (deleted territory)
• zone-udzdanarat (territory moved by admin, not currently re-loaded)

What are the technical specifications of the OGF topo layer?

The OGF topo layer is called ogf-topo in the code base. It is rendered on the current main render server, tiles04.rent-a-planet.com. This server is also aliased as tile.opengeofiction.net.

You can find the tiles at this path (e.g. for adding as a TMS image layer to JOSM or iD):

https://tile.opengeofiction.net/ogf-topo/{zoom}/{x}/{y}.png

Maximum zoom is the same as for OpenTopoMap: zoom=17

The topo render database receives incoming replication from the main apidb (opengeofiction.net) which currently "ticks" about every 10 minutes (not minutely, as in OSM). However, low zooms (less than 10) require special processing to a separate "lowzooms" database which is done much less frequently: currently, about every 2 weeks.

How can I add my own work to this above list of topo layers?

Contact Luciano via direct message in OGF, or send me an email (luciano🐌geofictician·com) or a ping in OGFC (OGF's discord server). We can discuss. First and foremost, do not upload contour lines or data to the OGF map directly! That's not how it works.

In the past, I've often said, "Send me a draft contour line file in in .osm format" (i.e. something drawn using JOSM, saved, and sent to me). But I'm going to change this workflow. I've received too many poorly done or frustratingly incomplete contour files, and so here's how I want to do this, moving forward.

First, we will discuss the area where you want to implement contours, and then I will send you one or more degree-square contour files as a sort of template, which you can then "fill in" with your contour lines. Then I can be sure to get the contour files in a format that is actually useful for Thilo's conversion program, and that is divided up into the degree-square format that I want to use to standardize this process.