Srtm2Osm tool uses Shuttle Radar Topography Mission (SRTM) digital elevation model (DEM) to generate elevation contours (isohypses) of a selected terrain. The tool writes contours as OSM ways into an OSM file. This then enables rendering of the terrain using Osmarender XSLT transformations or other OSM renderers.
NOTE: It is not intended to upload such contours into OSM database, but to improve OSM output. So do not try to upload the generated data to OSM server!
The tool was originally developed by Igor Brejc (User:Breki), but is no longer supported by him. The current version 1.16 is working and was built by Michael Bemmerl (User:Michi2). The tool is mainly build for running on Windows, but also works on Linux (see Running On Linux). For alternatives you may want to look at the Alternatives section.
A great example of using Srtm2Osm generated contours in slippy map is in the Freemap Slovakia.
- Windows: Microsoft .NET Framework 4.6.2 (available here)
- Linux: Mono 4.8
installed on your computer in order to run Srtm2Osm.
- Changed defaults for node & way IDs, because downstream software uses the old defaults for state handling.
- Downgrade the cell file size check, which will trigger a warning instead an error.
- Don't output fractional seconds in the resulting file. Another fix for downstream software...
- Add support for file:// scheme in source URLs.
- Display a warning when no contour lines were generated.
- Srtm2Osm requires at least .NET Framework 4.6.2
- The ArduPilot Firmware server is used as default SRTM source.
- Fixed "ERROR: 1 is not a supported code page." on Windows 10 systems when the input and system locale is different.
- The ArduPilot Terrain Generator server is used as default SRTM source.
- Support for encrypted HTTP communication with SRTM servers.
- Srtm2Osm requires at least .NET Framework 4.0 / Mono 4.8.
- New feature for splitting the bounding box into smaller ones for reduced memory footprint.
- Support for multiple bounding boxes: The -bound* options can be specified more than once.
- Catch more out-of-memory errors.
- Reduced memory footprint a bit.
- Merge support for large area mode.
- The first node / way IDs and the direction of counting can be specified with the -first*id / -incrementid options.
- Support for digital elevation models which are larger than 2 GiB (workaround for .NET restriction).
- added support for new slippymap URL syntax.
- added support for splitting isohypse ways after a certain amount of nodes.
- using 64 bit integers for element IDs.
- node / way element IDs start at 2^63-1 and are counted down: No need for updating the starting ID in future (like in version 1.8 ext).
- added console logging of download phase.
- output is now compatible to XML output of API 0.6.
- added "upload=false" attribute to "osm" tag.
- added support for slippymap URLs with bbox parameter.
- improved error handling on incomplete SRTM cell files.
- check if the download of a SRTM cell was complete.
- fixed exception on malformed URIs when using the -source option.
- improved error handling on network errors.
- fixed possible Exception on network errors.
- fixed missing "timestamp" XML attribute on exports which were made with the -large option.
- fixed missing "lon" / "lat" XML attribute when nodes were at 0° longitude or latitude.
- do not crash when no bounds were specified by the user.
Older entries are available in the release notes file.
Srtm2Osm works from a command line. Be aware of the fact that in case of typos, srtm2osm will just ignore your misspelled option instead of throwing an error. You specify one or more area(s) to cover and some additional options. You can specify the coverage area in three ways:
- By using -bounds1 option, you specify minimum and maximum latitude/longitude of the area, for example:
-bounds1 46.51 15.57 46.5385 15.6356
- By using -bounds2 option, you specify the latitude and longitude of the center of the area and the area size (in kilometers), example:
-bounds2 46.51 15.57 10
- By using -bounds3 option, you specify the slippymap URL of the area (the URL must be enclosed in quotes). The tool will take into account the zoom level in determining the area size. Example:
All options can be specified multiple times to download more than one area at the same time. Attention: All values are interpreted as decimal degrees. So 46.51 equals 46.51 degrees, not 46 degrees 51 minutes.
Covering Large Areas
If you want to cover a large area, use -large option, which turns on 'large area mode'. In this mode each contour is written to OSM file immediately upon discovery.
Be advised that a really large area causes problems: There is a .NET restriction which limits the maximum memory usage of the SRTM cache to 2 GiB. To workaround that, the filesystem is used as cache, when this limit is reached. That means a file bigger than 2 GiB will be created in your location for temporary files (and deleted afterwards). But even since SSD's are way slower than RAM, the process takes a whole lot more time, so be patient. The program will output a warning message when this happens. You should try to split the covered area in smaller chunks (see below). With this technique User:Michi2 was able to create a file of complete Japan, which had over 347 million nodes and 5.5 million ways, but also was nearly 73 GiB large.
Experiment when selecting the area size, first try with the small area (up to 50 km). If the area is large and hilly, the generated OSM file could become very big and basically useless for further processing by renderers. As an experiment, I ran the tool on the area which covered the whole of Sicily and it produced an OSM XML file with 450 MB in size.
Downloading SRTM Data
The tool does this automatically. It connects to the ArduPilot server and downloads the zipped tiles which it needs to process your request. It then unzips the files and stores them in a cache directory, so that it doesn't have to download the same tiles the next time it needs them. The first time you use the tool it will create an index file of all SRTM tiles present on the server. This is needed because the tiles on the server are organized into subfolders corresponding to continents and Srtm2Osm has no way of knowing which tile belongs to which continent.
You can also use a different download server by using the -source option. This option also supports file:// URLs if you happen to have a local mirror of the server.
Elevation In Feet
If you want to have contours generated in feet instead of meters, specify -feet option. You should also set an appropriate elevation step.
You can specify the step size (in meters or feet, depending on the usage of -feet option) between adjacent contour lines by using -step option.
Srtm2Osm stores elevation contours as OSM ways tagged with contour = elevation tag. Also, the ele tag contains the elevation of the contour (in elevation units). The nodes and ways have ID numbers starting from 9,223,372,036,854,775,797 and are decremented for each new element in order to avoid the conflict with the actual data from the OSM server.
If you don't like this high ID number, you can also set the starting ID with the -firstnodeid and -firstwayid options. If you want the IDs to increment, use the -incrementid option.
The amount of node references in a way is not restricted. If you prefer to limit this to a certain amount, use the -maxwaynodes option.
Categorizing Contours For Mkgmap
By using -cat option, the tool will set an additional contour_ext tag for all contours. The value of the tag will represent the category of the contour (either elevation_major, elevation_medium or elevation_minor). This is useful if you want to use contour data with the Mkgmap tool. Example:
-cat 400 100
will mark all elevations which are multiples of 400 as major, all other multiples of 100 as medium and all other as minor. The units of elevation are determined by the usage (or non-usage) of -feet option. You can also use the -cat option in combination with the -step option. Example:
-feet -step 150 -cat 1350 450
will produce contours in feet, with elevation step of 150 feet. Elevations of 1350, 2700 feet etc will be tagged as contour_ext = elevation_major. Elevations of 450, 900, 1800 feet etc will be tagged as contour_ext = elevation_medium. All other contours will be tagged as contour_ext = elevation_minor.
Note: the order might be the opposite of what you expect! - major before medium ---- [[User:Tms13]] 22:23, 17 January 2009 (UTC)
The article Topographic maps for garmin devices describes how to use srtm2osm to generate topographic maps for Garmin devices.
If you want to merge your existing OSM file that you have downloaded from the server using JOSM with the contour data, you can use -merge option to specify that file.
If you use the -large option, every XML element below the root element will be copied to the new file, regardless of the content. If you do not use this option, the merge file will be loaded and parsed into memory.
However, it is important that there are no duplicated ID's. If you have problems with that, use the -firstnodeid and -firstwayid option.
The -o option allows you to specify the output path:
-o <path>: specifies an output OSM file (default: 'srtm.osm')
If you want to process a really large area, you should try to split the bounds into smaller ones with the -splitbounds option. This reduces the memory footprint vastly and you have the chance to really get a large file of a large area. This option needs the width and height of the "working boundary" in decimal degrees:
-splitbounds 5 5
This example will split the given area into 5° wide and tall working boundaries.
With this technique it should theoretically be possible to process the whole world at once, though this has never been tried.
Rendering Using Maperitive
Maperitive includes rendering rules for elevation contours generated by Srtm2Osm. No additional rules are necessary.
Rendering Using Osmarender
The following rules can be used to render elevation contours using Osmarender (version 6):
<!-- elevation countours --> <rule e="way" k="contour" v="elevation"> <rule k="ele" v="100|200|300|400|500|600|700|800|900|1000|1100|1200|1300|1400|1500|1600|1700|1800|1900|2000|2100|2200|2300|2400|2500|2600|2700|2800|2900|3000|3100|3200|3300|3400|3500|3600|3700|3800|3900|4000|4100|4200|4300|4400|4500|4600|4700|4800|4900|5000"> <line style="stroke-width: 0.2px; stroke: #502D16;" fill="none"/> <text k="ele" startOffset='25%' dy="-1.5px" font-family='Verdana' font-size='3.5px' font-style='bold' fill='#502D16'/> <text k="ele" startOffset='75%' dy="-1.5px" font-family='Verdana' font-size='3.5px' font-style='bold' fill='#502D16'/> </rule> <else> <line style="stroke-width: 0.1px; stroke: #502D16;" fill="none"/> </else> </rule>
Notes On Rendering
- This rule will draw contours as polylines, with contours of 100's drawn thicker.
- The rule will also show elevation of those thicker lines.
- If you want this to apply to elevations higher than 5000 meters, you have to extend the selection list in the rule.
- I added this rule after "man-made areas" and before "Airfields and airports" since I think this is the most logical way to place contours on maps (the contours should be visible over land features, but not over roads, for example).
- I tried this on new (alpha) 0.5 rules, see examples
- I'm not an expert on Osmarender, so if anybody knows a better way to define render rules, please contribute :). Using SVG Bezier lines would make it look much nicer.
The tool is currently in beta mode. I tested it on certain areas and it worked OK. If you see any errors, please report them in the discussion page.
- Currently the tool only supports SRTM3 data.
Things Still To Do
- Automatic splitting of generated contours into several OSM files (as tiles). This would make working with the resulting OSM contours much easier. (You can use splitter for this, with the
- Support SRTM1 data
- Using smaller elevation steps to show relief in plains. This should be activated automatically for plains, based on some algorithm.
- Support for SRTM Water Body Dataset (SWBD)?
- Rendering through Osmarender using Bezier curves
- Support for CGIAR-CSI void-filled SRTM data
- Support boundary polygons instead of -bounds
- Support for the OSM 0.6 data format
- Integrating the features SRTM2OSMsegmenter offers
Support for the new permalink syntax on osm.org (e.g. https://www.openstreetmap.org/#map=18/49.95924/9.65667)
- Support for 1 arc second SRTM data
Running On Linux
Versions >= 1.13
Debian Buster / Bullseye / Bookworm
apt install libmono-system-web4.0-cil libmono-system-io-compression-filesystem4.0-cil
Afterwards you are able to run Srtm2Osm with this command:
Srtm2Osm needs at least Mono 4.8 to support the encryption protocol TLS 1.2 currently (11-2017) used by the SRTM server. Debian ships 4.6, so the Mono package in the Debian repo will not work. Luckily the Mono project itself hosts repositories with newer versions. Follow the install instructions to add the Mono repo, afterwards install the package libmono-system-web4.0-cil from the Mono repo:
apt-get install libmono-system-web4.0-cil=5*
This should install the Mono system due to the dependencies of this package. The =5* should ensure that the newer version 5.4 from the Mono repo is used. Otherwise use a tool like aptitude or use apt pinning to choose the right repository.
Versions < 1.13
I've had success running Srtm2Osm on Ubuntu Gutsy (7.10). I simply downloaded & extracted Srtm2Osm-126.96.36.199.zip, then made Srtm2Osm.exe executable. I have various mono libraries installed, and I suspect having these is what allows it to work. If you know more about getting this to run on Linux, please add it here. Avantman42
To run Srtm20sm on Debian GNU/Linux, apt-get install mono-runtime libmono-corlib2.0-cil libmono-system-runtime2.0-cil libmono-system2.0-cil, then run the program with "mono Srtm20sm.exe". --Bgm 02:37, 15 January 2008 (UTC)
- Also needed to install the packages mono-gmcs and libmono-i18n2.0-cil to fix a 'Cannot open assembly' and 'CodePage not supported' error in a Linux/Debian environment. --Lambertus 20:07, 12 March 2008 (UTC)
On Ubuntu Hardy Heron (8.10) srtm2osm worked after I had installed the two packages mentioned by Lambertus (and only those). --Winlemski 17:18, 12 October 2008 (UTC)
I confirm that it runs on Kubuntu 8.04 as well. Followed above instructions and installed all mentioned packages. --GoemonGPS 26 March 2009
Ubuntu 8.04, 9.10, Debian
aptitude install mono-runtime libmono-corlib2.0-cil libmono-system-runtime2.0-cil libmono-system2.0-cil mono-gmcs libmono-i18n2.0-cil
- Confirmed working on Debian Sid —Granjow 16:10, 15 December 2009 (UTC)
- Confirmed working on Ubuntu 9.10 —Yvecai 06 February 2010
Lenny 64bit, Debian
aptitude install mono-runtime libmono-corlib2.0-cil libmono-system-runtime2.0-cil libmono-system2.0-cil libmono-i18n2.0-cil
- Confirmed working Lenny 64bit (kernel 2.6.26-2-amd64) —DirkS 28 February 2010
# yum install mono-tools
And then you should be able to run srtm20sm as
# mono Srtm20sm.exe ...
# zypper install mono-core mono-web mono-winforms mono-data mono-data-sqlite
And then you able to run srtm20sm as
# mono Srtm20sm.exe ...
(Verified on openSUSE 11.4.)
- See Srtm2Osm Development for more.
Alternatives exist that do not require a .NET/Mono environment and may offer other advantages in some circumstances. None of these are a direct replacement for Srtm2Osm though:
- GroundTruth, gdal_contour, mkgmap, or GRASS GIS's r.in.srtm, r.contour, and v.out.gpsbabel modules.
- Phyghtmap using Python, http://katze.tfiu.de/projects/phyghtmap/
- Srtm2osm_perl using Perl/GNUplot
- BBBike.org extract service offers SRTM data in OSM, PDF, Garmin or Osmand format for an area of your choosing, 40m or 25m contours lines.