OpenGeofiction:Topo layer: Difference between revisions

From OpenGeofiction
Jump to navigation Jump to search
 
(9 intermediate revisions by the same user not shown)
Line 2: Line 2:
=What is a 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 [https://www.openstreetmap.org/#map=8/55.630/-132.393&layers=Y 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 [https://opentopomap.org/#map=8/55.630/-132.393 OpenTopoMap].
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 [https://www.openstreetmap.org/#map=8/55.630/-132.393&layers=Y 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 [https://opentopomap.org/#map=8/55.630/-132.393 OpenTopoMap]. The code for OpenTopoMap is freely available on [https://github.com/der-stefan/OpenTopoMap github].


=How is a topo layer made?=
=How is a topo layer made?=
Line 14: Line 14:
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.
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 princple, but then we have the data problem.
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.
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.
Line 20: Line 20:
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.
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 Stapf, 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!
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.
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.
Line 28: Line 28:
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).
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).


*[https://opengeofiction.net/#map=7/53.041/125.057&layers=V zone-alved]
*[https://opengeofiction.net/#map=8/19.777/87.954&layers=V zone-gobras]
*[https://opengeofiction.net/#map=8/19.777/87.954&layers=V zone-gobras]
*[https://opengeofiction.net/#map=7/-22.624/127.612&layers=V zone-gwynian]
*[https://opengeofiction.net/#map=7/-22.624/127.612&layers=V zone-gwynian]
*[https://opengeofiction.net/#map=10/51.4189/0.1092&layers=V zone-hesperis]
*[https://opengeofiction.net/#map=10/51.4189/0.1092&layers=V zone-hesperis]
*zone-iscu (not currently loaded)
*[https://opengeofiction.net/#map=11/2.0224/92.2343&layers=V zone-iscu]
*[https://opengeofiction.net/#map=9/32.3823/126.4828&layers=V zone-izaland]
*[https://opengeofiction.net/#map=9/-62.2922/108.5875&layers=V zone-january]
*[https://opengeofiction.net/#map=9/-62.2922/108.5875&layers=V zone-january]
*[https://opengeofiction.net/#map=10/-48.6846/72.0408&layers=V zone-kofuku]
*[https://opengeofiction.net/#map=10/-48.6846/72.0408&layers=V zone-kofuku]
Line 42: Line 44:
*zone-tekan (deleted territory)
*zone-tekan (deleted territory)
*zone-udzdanarat (territory moved by admin, not currently re-loaded)
*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):
<pre>
https://tile.opengeofiction.net/ogf-topo/{zoom}/{x}/{y}.png
</pre>
Maximum zoom is the same as for OpenTopoMap: zoom=17
It's "layer code letter" is "V" (this is a suffix to the URL, e.g. ''"...&layers=V"'').
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.
=The OGF topo layer isn't showing something I added/deleted correctly. Why?=
We have had problems since the migration to the new platform with occasions where the render data seems to get "out of sync" with the apidb (the map database, AKA rails port). This can result in the persistence of deleted objects in the render, or the failure of newly added object to appear in a timely fashion. We are aware of this problem, and even working to solve it, but currently it is an open, unsolved problem.


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


Contact [https://opengeofiction.net/user/Luciano Luciano] via direct message in OGF, or send me an email (luciano&#x1f40c;geofictician&#xB7;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.
Contact [https://opengeofiction.net/user/Luciano Luciano] via direct message in OGF, or send me an email (luciano&#x1f40c;geofictician&#xB7;net) 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.
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.
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.
=Is the raw OGF topo data accessible online?=
Yes, it is! There is a special server called ogfsrtm. This is where the raw "OSM contour" files reside, and where the pseudo-SRTM degree squares are stored. This server is currently ''separate'' from the main OpenGeofiction server ecosystem, and maintained solely by Luciano, not by the full OGF admin team. Because of this, it has no strong guarantee of consistency or reliability - it is a "work in progress" and probably not in its final "production" architecture yet.
The publicly-accessible data on the server is organized according into four folders:
* [https://ogfsrtm.rent-a-planet.com/osm-squares/ osm-squares] - these are the "source contour files" as drawn by individual mappers; there is one file per "degree square"
* [https://ogfsrtm.rent-a-planet.com/contours/ contours] - these are processed "contour data files" prepped for load to the ogfcontours database on the render server (not user-friendly)
* [https://ogfsrtm.rent-a-planet.com/tiff-files/ tiff-files] - these are processed giant image files; "hillshade" and "map-elevation color" files, for load to the data folder on the render server (not user-friendly)
* [https://ogfsrtm.rent-a-planet.com/hgt-files/ hgt-files] - these are the processed "pseudo-SRTM" files in NASA format (not user-friendly)
Only the first category (osm-squares) are in a somewhat user-friendly format - these are the files you should download if you want to see what a "contour file" looks like in the JOSM editor, and, if you are in charge of maintenance of a contour zone, these are the files you should edit, alter, add detail to, and send back to me for re-upload.
If, on the other hand, you're interested in building your own topo render for the OGF world, you can use the latter three categories to make your job much, much easier, using off-the-shelf software stacks built to consume NASA-style SRTM data.
The first and last of the above elements are further split up into subfolders based on the "zone" names. Let's repeat the list topo zones from above, now with much more detail.
*'''zone-alved''' (new load in progress)
** Original topo creator(s): {{OGF user|SwissCrusader}}
** Current territory owner(s): {{OGF user|SwissCrusader}}
** Contour source files: https://ogfsrtm.rent-a-planet.com/osm-squares/zone-alved
** pseudo-SRTM hgt files: https://ogfsrtm.rent-a-planet.com/hgt-files/zone-alved
*'''[https://opengeofiction.net/#map=8/19.777/87.954&layers=V zone-gobras]'''
** Original topo creator(s): {{OGF user|isleño}} and {{OGF user|thilo}} (Khaiwoon); {{OGF user|Ūdilugbulgidħū}} (Gobras City)
** Current territory owner(s): Archived (Khaiwoon); Collaborative (Gobrassanya)
** Contour source files: https://ogfsrtm.rent-a-planet.com/osm-squares/zone-gobras
** pseudo-SRTM hgt files: https://ogfsrtm.rent-a-planet.com/hgt-files/zone-gobras
*'''[https://opengeofiction.net/#map=7/-22.624/127.612&layers=V zone-gwynian]'''
** Original topo creator(s): {{OGF user|Luciano}} (Ardisphere); {{OGF user|Martinawa}} (Adaria)
** Current territory owner(s): {{OGF user|Luciano}} (Ardisphere); {{OGF user|Martinawa}} (Adaria)
** Contour source files: https://ogfsrtm.rent-a-planet.com/osm-squares/zone-gwynian
** pseudo-SRTM hgt files: https://ogfsrtm.rent-a-planet.com/hgt-files/zone-gwynian
*'''[https://opengeofiction.net/#map=10/51.4189/0.1092&layers=V zone-hesperis]'''
** Original topo creator(s): {{OGF user|Ūdilugbulgidħū}}
** Current territory owner(s): {{OGF user|Ūdilugbulgidħū}}
** Contour source files: https://ogfsrtm.rent-a-planet.com/osm-squares/zone-hesperis
** pseudo-SRTM hgt files: https://ogfsrtm.rent-a-planet.com/hgt-files/zone-hesperis
*'''zone-iscu''' (new load in progress)
** Original topo creator(s): {{OGF user|Lithium-Ion}}
** Current territory owner(s): {{OGF user|Lithium-Ion}}
** Contour source files: https://ogfsrtm.rent-a-planet.com/osm-squares/zone-iscu
** pseudo-SRTM hgt files: https://ogfsrtm.rent-a-planet.com/hgt-files/zone-iscu
*'''zone-izaland''' (new load in progress)
** Original topo creator(s): {{OGF user|Izaland Terramorphing Committee}}
** Current territory owner(s): {{OGF user|Izaland Terramorphing Committee}}
** Contour source files: https://ogfsrtm.rent-a-planet.com/osm-squares/zone-izaland
** pseudo-SRTM hgt files: https://ogfsrtm.rent-a-planet.com/hgt-files/zone-izaland
*'''[https://opengeofiction.net/#map=9/-62.2922/108.5875&layers=V zone-january]'''
** Original topo creator(s): {{OGF user|Luciano}}
** Current territory owner(s): {{OGF user|deltanz}}
** Contour source files: https://ogfsrtm.rent-a-planet.com/osm-squares/zone-january
** pseudo-SRTM hgt files: https://ogfsrtm.rent-a-planet.com/hgt-files/zone-january
*'''[https://opengeofiction.net/#map=10/-48.6846/72.0408&layers=V zone-kofuku]'''
** Original topo creator(s): {{OGF user|Huachachi}}
** Current territory owner(s): {{OGF user|Huachachi}}
** Contour source files: https://ogfsrtm.rent-a-planet.com/osm-squares/zone-kofuku
** pseudo-SRTM hgt files: https://ogfsrtm.rent-a-planet.com/hgt-files/zone-kofuku
*'''[https://opengeofiction.net/#map=11/34.8471/120.8513&layers=V zone-kojo]'''
** Original topo creator(s): {{OGF user|Luciano}} (Joenji Peninsula); {{OGF user|Leowezy}} (rest of Kojo)
** Current territory owner(s): {{OGF user|Leowezy}}
** Contour source files: https://ogfsrtm.rent-a-planet.com/osm-squares/zone-kojo
** pseudo-SRTM hgt files: https://ogfsrtm.rent-a-planet.com/hgt-files/zone-kojo
*'''[https://opengeofiction.net/#map=7/-43.874/146.629&layers=V zone-makaska]'''
** Original topo creator(s): {{OGF user|Luciano}}
** Current territory owner(s): {{OGF user|Luciano}}
** Contour source files: https://ogfsrtm.rent-a-planet.com/osm-squares/zone-makaska
** pseudo-SRTM hgt files: https://ogfsrtm.rent-a-planet.com/hgt-files/zone-makaska
*'''[https://opengeofiction.net/#map=7/45.398/27.955&layers=V zone-roantra]'''
** Original topo creator(s): {{OGF user|thilo}}
** Current territory owner(s): Archived
** Contour source files: https://ogfsrtm.rent-a-planet.com/osm-squares/zone-roantra
** pseudo-SRTM hgt files: https://ogfsrtm.rent-a-planet.com/hgt-files/zone-roantra
*'''[https://opengeofiction.net/#map=11/-33.0472/-136.4485&layers=V zone-ruanerara]'''
** Original topo creator(s): {{OGF user|Toadwart}}
** Current territory owner(s): {{OGF user|Toadwart}}
** Contour source files: https://ogfsrtm.rent-a-planet.com/osm-squares/zone-ruanerara
** pseudo-SRTM hgt files: https://ogfsrtm.rent-a-planet.com/hgt-files/zone-ruanerara
*'''[https://opengeofiction.net/#map=12/-8.8888/50.2183&layers=V zone-tapira]'''
** Original topo creator(s): {{OGF user|Ūdilugbulgidħū}}
** Current territory owner(s): Unowned ([https://opengeofiction.net/relation/30260 TA111b])
** Contour source files: https://ogfsrtm.rent-a-planet.com/osm-squares/zone-tapira
** pseudo-SRTM hgt files: https://ogfsrtm.rent-a-planet.com/hgt-files/zone-tapira
*'''[https://opengeofiction.net/#map=10/-58.3297/84.1615&layers=V zone-tarrases]'''
** Original topo creator(s): {{OGF user|Luciano}}
** Current territory owner(s): {{OGF user|Luciano}}
** Contour source files: https://ogfsrtm.rent-a-planet.com/osm-squares/zone-tarrases
** pseudo-SRTM hgt files: https://ogfsrtm.rent-a-planet.com/hgt-files/zone-tarrases
*'''zone-udzdanarat''' (territory moved by admin, not currently re-loaded)
** Original topo creator(s): {{OGF user|Ūdilugbulgidħū}}
** Current territory owner(s): {{OGF user|Ūdilugbulgidħū}}
** Contour source files: https://ogfsrtm.rent-a-planet.com/osm-squares/zone-udzdanarat
** pseudo-SRTM hgt files: https://ogfsrtm.rent-a-planet.com/hgt-files/zone-udzdanarat
[[Category: OGF technical documentation]]

Latest revision as of 19:42, 5 March 2022

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. The code for OpenTopoMap is freely available on github.

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

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

It's "layer code letter" is "V" (this is a suffix to the URL, e.g. "...&layers=V").

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.

The OGF topo layer isn't showing something I added/deleted correctly. Why?

We have had problems since the migration to the new platform with occasions where the render data seems to get "out of sync" with the apidb (the map database, AKA rails port). This can result in the persistence of deleted objects in the render, or the failure of newly added object to appear in a timely fashion. We are aware of this problem, and even working to solve it, but currently it is an open, unsolved problem.

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·net) 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.

Is the raw OGF topo data accessible online?

Yes, it is! There is a special server called ogfsrtm. This is where the raw "OSM contour" files reside, and where the pseudo-SRTM degree squares are stored. This server is currently separate from the main OpenGeofiction server ecosystem, and maintained solely by Luciano, not by the full OGF admin team. Because of this, it has no strong guarantee of consistency or reliability - it is a "work in progress" and probably not in its final "production" architecture yet.

The publicly-accessible data on the server is organized according into four folders:

  • osm-squares - these are the "source contour files" as drawn by individual mappers; there is one file per "degree square"
  • contours - these are processed "contour data files" prepped for load to the ogfcontours database on the render server (not user-friendly)
  • tiff-files - these are processed giant image files; "hillshade" and "map-elevation color" files, for load to the data folder on the render server (not user-friendly)
  • hgt-files - these are the processed "pseudo-SRTM" files in NASA format (not user-friendly)

Only the first category (osm-squares) are in a somewhat user-friendly format - these are the files you should download if you want to see what a "contour file" looks like in the JOSM editor, and, if you are in charge of maintenance of a contour zone, these are the files you should edit, alter, add detail to, and send back to me for re-upload.

If, on the other hand, you're interested in building your own topo render for the OGF world, you can use the latter three categories to make your job much, much easier, using off-the-shelf software stacks built to consume NASA-style SRTM data.

The first and last of the above elements are further split up into subfolders based on the "zone" names. Let's repeat the list topo zones from above, now with much more detail.

Retrieved from "https://wiki.opengeofiction.net/index.php?title=OpenGeofiction:Topo_layer&oldid=5574"