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. -- You received this message because you are subscribed to the Google Groups "Osmand" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
