Making srtm.obf files

[Frederico]

Hello,

Some days ago a noted that there is no detailed map for Fernando de Noronha in OsmAnd+ (it belongs to Pernambuco in Brazil). I downloaded a small region aroud it from the OpenStreetMaps server (named it map.osm-2.xml), converted it to obf format with OsmAndMapCreator and renamed it (Map.obf). I saved it together with the other obf files in OsmAnd+ directory (Android) and that worked nice.

I tried then to make contour lines for Fernando de Noronha (the strm plugin works fine for other regions).

Using phyghtmap-1.80 I downloaded strm data for a region around Fernando de Noronha (fn2_lon-33.00_-32.33lat-3.90_-3.80_srtm3v3.0.osm) and again using OsmAndMapCreator converted it to obf format, renamed it (Map.srtm.obf). I saved it in the srtm subdirectory of Osmand, where other working strm.obf files are located, but I could no manage to see any contour lines for Fernando de Noronha.

To make some kind of testing, I used JOSM on a personal computer. Since it cannot handle obf files, I loaded simultaneously map.osm-2.xml and fn2_lon-33.00_-32.33lat-3.90_-3.80_srtm3v3.0.osm and saw both the map for Fernando de Noronha and the contour lines correctly.

Do you know how to make it work with OsmAnd+ (version 2.7.5) on Android (version 5.0.2)? Thanks a lot.

Frederico

[A Thompson]

I've successfully played with making contours as a vector layer in QGIS, saving as an ESRI shapefile with WGS84 coordinate reference system (CRS), converting that to .osm using JOSM with the opendata plugin, then converting to .obf using OsmAndMapCreator. It's crucial that the contours be tagged with key=contour, value=elevation for them to display as contours in OsmAnd - as long as they are, then the .obf can be named anything and just placed in OsmAnd's main directory. In my tool chain, I added the tag in QGIS, but you can do it in JOSM if you have enough memory to "select all" and add a new tag. I haven't looked at the files you posted - sorry if you've already got this covered.

[Frederico]

Thanks for the answer. I saw that in map.osm-2.xml (working file for a normal map) the delimiter ' is used:

  <way id='129217800' timestamp='2011-09-07T13:14:43Z' uid='71025' user='Bráulio Bezerra' version='1' changeset='9236849'>

    <nd ref='1426104597' />

    <nd ref='1426104602' />

    <nd ref='1426104600' />

    <nd ref='1426104595' />

    <nd ref='1426104597' />

    <tag k='building' v='yes' />

  </way>

instead of the delimiter " in fn2_lon-33.00_-32.33lat-3.90_-3.80_srtm3v3.0.osm. So I changed every occurrence of " to ' and converted the file (fn2_lon-33.00_-32.33lat-3.90_-3.80_srtm3v3.0.osm) for the contour lines again. Now a way for the contour lines looks like

<way id='10000002' version='1'><nd ref='10000472' />

<nd ref='10000473' />

<nd ref='10000474' />

<nd ref='10000475' />

<nd ref='10000472' />

<tag k='ele' v='0'/><tag k='contour' v='elevation'/><tag k='contour_ext' v='elevation_major' /></way>

There is a tag with key 'contour' and value 'elevation', defined with the same syntax as in map.osm-2.xml. But even so after conversion with OsmAndMapCreator I don't see any contour line.

It still remains the same if I add one more tag  <tag k="name" v="elevation goes here"/>, like in

<way id='10000002' version='1'><nd ref='10000472' />

<nd ref='10000473' />

<nd ref='10000474' />

<nd ref='10000475' />

<nd ref='10000472' />

<tag k='name' v='0' />

<tag k='ele' v='0'/><tag k='contour' v='elevation'/><tag k='contour_ext' v='elevation_major' /></way>

I read in a forum, that this last tag is necessary for the elevation (in the case above 0) to be showed too, instead of only the contour line without any specification.

I can't find any other information about making srtm files. Do you have more ideas or know where I can ask for it?

thanks in advance.

Frederico

[Poutnik]

It is a pity the contours are not part of the ( full ) OBF map,
similarly as they are part of MapsForge compatible maps.

Dne 07/10/2017 v 10:10 Frederico napsal(a):

> Thanks for the answer. I saw that in map.osm-2.xml (working file for a
> normal map) the delimiter ' is used:
>

> I read in a forum, that this last tag is necessary for the elevation
> (in the case above 0) to be showed too, instead of only the contour
> line without any specification.
>
> I can't find any other information about making srtm files. Do you
> have more ideas or know where I can ask for it?
> thanks in advance.
>
> Frederico

--
Poutnik ( The Wanderer )

My Brouter profiles
https://github.com/poutnikl/Brouter-profiles/wiki

[Poutnik]

OTOH, I admit the separate contour data download
has advantage in decreasing the data download traffic,
as contours rarely change.

Dne 07/10/2017 v 10:52 Poutnik napsal(a):

> It is a pity the contours are not part of the ( full ) OBF map,
> similarly as they are part of MapsForge compatible maps.
>

[A Thompson]

Hi Frederico,

I downloaded your files, and they all seemed fine in the same tools I used. So I put your Map.obf and Map.srtm.obf in my osmand 2.7.5 folder on Android  and they worked!

It turns out that both your contours, and the ones I made for fun (using UK LIDAR) don't display with the standard renderers ("Map Style"s) like "Osmand" and "Touring view (contrast and details)", but they do work with the "walking" renderer I posted:

https://groups.google.com/forum/#!topic/osmand/WyGJS0Dekrk

I have no idea why this is! My renderer loads "Touring View" then adds some extra options, including boosting the width of contour lines (as in the screenshot: that's x3). The code I wrote for contours was based on what I found in Touring View, but presumably I've somehow relaxed a requirement.

The walking renderer was a "labour of love", so feel free to ask anything about it! The extra menu options it adds only appear while it's selected, and if you delete the file then it's gone without a trace, so there's no harm in trying it.

Adrian

[Frederico]

Thank you a lot Adrian, with your walking.render.xml the contour lines are showing up for me too and I am already very happy with that. I will be looking at it in detail during the next week and let you know if I don't understand it.

[A Thompson]

I worked out what's going on. In recent versions of OsmAnd, the code for contours in "Touring View" is commented-out, so it falls back on the default renderer: "Osmand". This requires contours not only to have the contour=elevation tag, but also one of contourtype=10m, contourtype=20m, contourtype=50m, or contourtype=100m.

In JOSM, I added the contourtype=10m tag to all of your fn2_lon-33.00_-32.33lat-3.90_-3.80_srtm3v3.0.osm contours, converted to .obf, and they were visible with the OsmAnd and Touring view renderers (but so thin as to be barely visible on my devices). 

By the way, I noticed that the "LightRS" renderer (which doesn't fall back on the default for contours) does show our contours without the contourtype tag, but they are very hard to see.

I have no involvement with the OsmAnd developers, so I don't know the intentions behind the change to Touring View. I find the contours barely visible in any of the supplied renderers, hence their inclusion in walking.render.xml but we must be aware that it may break as OsmAnd develops.

More detail:

OsmAnd was at version 2.4.7 when I started playing with custom renderers, at which time Touring view contained the section:

<!-- countour lines -->

<group>

<filter contourLines="11" tag="contour" value="elevation" minzoom="11" color="$contourLineColor" strokeWidth="1"/>

<filter contourLines="12" tag="contour" value="elevation" minzoom="12" color="$contourLineColor" strokeWidth="1"/>

<filter contourLines="13" tag="contour" value="elevation" minzoom="13" color="$contourLineColor" strokeWidth="1"/>

<filter contourLines="14" tag="contour" value="elevation" minzoom="14" color="$contourLineColor" strokeWidth="1"/>

<filter contourLines="15" tag="contour" value="elevation" minzoom="15" color="$contourLineColor" strokeWidth="1"/>

<filter contourLines="16" tag="contour" value="elevation" minzoom="16" color="$contourLineColor" strokeWidth="1"/>

<groupFilter>

<filter additional="contourtype=10m" color="$contourLineColor" strokeWidth="1"/>

<filter additional="contourtype=20m" color="$contourLineColor" strokeWidth="1"/>

<filter additional="contourtype=50m" minzoom="16" color="$contourLineColor50m" strokeWidth="1.5"/>

<filter additional="contourtype=100m" color="$contourLineColor50m" strokeWidth="2"/>

</groupFilter>

</group>

In my first attempt at a custom renderer dependent on Touring View, I just copied this and doubled the strokeWidth. In walking.render.xml I restructured to find a neater solution for variable contour widths, but with the same effect.

In the current Google Play release (2.7.5) the code for contours has been commented out of Touring View, which is itself dependent on "default" which means it falls back to the "Osmand" renderer for contours. This has the code:

<switch tag="contour" value="elevation">

<case minzoom="11" contourLines="11"/>

<case minzoom="12" contourLines="12"/>

<case minzoom="13" contourLines="13"/>

<case minzoom="13" contourLines=""/>

<case minzoom="14" contourLines="14"/>

<case minzoom="15" contourLines="15"/>

<case minzoom="16" contourLines="16"/>

<apply>

<case minzoom="13" additional="contourtype=10m" color="$contourLineColor" strokeWidth="1"/>

<case additional="contourtype=20m" color="$contourLineColor" strokeWidth="1"/>

<case additional="contourtype=50m" minzoom="14" color="$contourLineColor50m" strokeWidth="1.3"/>

<case additional="contourtype=100m" color="$contourLineColor100m" strokeWidth="1.8"/>

</apply>

<apply_if minzoom="15" pathIcon="stroke_lightorange_left" pathIconStep="100"/>

</switch> 

which requires the contourtype=10,20,50,100m tag otherwise there's nothing to set the strokeWidth of contours.