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.

Thanks for the answer. I saw that in map.osm-2.xml (working file for a
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.

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

--
Poutnik ( The Wanderer )

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

[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!

<Loading Image...>

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.

[Frederico]

I think I got the point. The contour lines are plotted only when the tag
contour type is present. I just have to learn more about the render.xml
files.

Today I found a python script on their git repository to make contour
lines, but it cannot be correct, because they are not adding this new tag.
Maybe it is an old version. The following is only part of the script.

for way in ways:
nds=way.findall('nd')
newWay = etree.Element("way",id=str(wayid))
# create nodes in the output tree
for nd in nds:
ref=nd.get('ref')
try:
newNode = etree.Element("node",id=str(nodeid), lon=nodeList[ref].get('lon'),
\
lat=nodeList[ref].get('lat'))
except:
newNode = etree.Element("node",id=str(nodeid), lon="0",\
lat=nodeList[ref].get('lat')) # Srtm2Osm bug on lon="0"
newNd= etree.Element("nd",ref=str(nodeid))
nodeid+=1
outRoot.append(newNode)
newWay.append(newNd)
newTag= etree.Element("tag",k="contour", v="elevation")
newWay.append(newTag)
tags=way.findall('tag')
for tag in tags:
if tag.get('k')=='ele':
ele=tag.get('v')
#pdb.set_trace()
newTag= etree.Element("tag",k="ele", v=ele)
newWay.append(newTag)
#pdb.set_trace()
# Add a 'name' tag to render elevation on 100m lines
if int(ele) % 100 == 0:
newTag= etree.Element("tag",k="name", v=ele)
newWay.append(newTag)
outRoot.append(newWay)
wayid+=1

Now that the contour lines are there (with your tips) I realized that the
elevation information for routes calculated with OsmAnd are not present for
tracks in Fernando de Noronha. I am thinking that some tag is missing again
...