Usage of "additional" condition in rendering styles

[a***@tiscali.it]

I’m trying to change the *peak* icon for *natural=peak* to a cross when the
tag *summit:cross=yes* is used.



I’m editing the following section in *default.render.xml* for this.


<case minzoom="11" tag="natural" value="peak" iconOrder="65">
<case maxzoom="11" icon="natural_peak" shield="peakvolcano_shield"
iconVisibleSize="25" intersectionSizeFactor="2"/>
<case maxzoom="14" icon="natural_peak" shield="peakvolcano_shield"/>
<case minzoom="15" icon="natural_peak_big" shield="peakvolcano_big_shield"
/>
<apply_if nightMode="true" shield="">
<case minzoom="11" maxzoom="14" icon="natural_peak_night"/>
<case minzoom="15" icon="natural_peak_night_big"/>
</apply_if>
</case>


I cannot succeed to manage the "*additional"* attribute:


additional="summit:cross=yes”



For instance:


<case additional="summit:cross=yes" icon="
"/>


is never executed.



Also


<apply_if additional="summit:cross=yes" icon="
"/>


appears to be a condition which never occurs.



I’m testing the code with this feature:


https://www.openstreetmap.org/api/0.6/node/26864320

https://www.openstreetmap.org/node/26864320



I’d like to get some advise on the correct usage, thanks.

[A Thompson]

Please someone correct me, but from a naive experiment I just did I don't
think the summit:cross=yes tag in the .osm ends up being incorporated in
OsmAnd's .obf database.

I downloaded a tiny patch of .osm data around the peak in question,
generated the .obf using OsmAndMapCreator, then used the inspector.bat
script from OsmAndMapCreator with the -vmap -vmapobjects -osm flags to
report on the .obf contents.

where the .osm has:

<node id="26864320" lat="45.9565995" lon="10.0555039">
<tag k="alt_name" v="Pizzo della Presolana"/>
<tag k="ele" v="2521"/>
<tag k="name" v="Presolana Occidentale"/>
<tag k="natural" v="peak"/>
<tag k="summit:cross" v="yes"/>
</node>


inspector.bat gives from the .obf:

<node id = '9' version='1' lat='45.956604' lon='10.055494' >
<tag k='natural' v='peak' />
<tag k='ele_limit' v='3000' />
<tag k='ele' v='2521' />
<tag k='name' v='Presolana Occidentale' />
<tag k='original_id' v='26864320'/>
<tag k='osmand_id' v='3438632972'/>
</node>


I only found out how to use inspector.bat from this post
<https://groups.google.com/forum/#!topic/osmand/amP5cFzHUg8> and have
never used it before, so I'll stop now in case I'm doing more harm than
good! However, given the rather unregulated tagging in OSM I can see it
would be essential for OsmAnd to be selective to optimise the file size.

[a***@tiscali.it]

Post by A Thompson
Please someone correct me, but from a naive experiment I just did I don't
think the summit:cross=yes tag in the .osm ends up being incorporated in
OsmAnd's .obf database.
...

Thanks a lot for your swift reply, this does make sense!


I made some additional research meanwhile.


Vector maps (as the ones handled by Osmand) would need a database (with
spatial extension) to process queries and the OBF files adopted by Osmand
should just be a sort of sqlite3 structure storing all features. The tool
to import them from OSM is OsmAndMapCreator (or similar), basing on a file
named *rendering_types.xml*, as explained here
<http://osmand.net/help/docs/Custom_Rendering_How-To.htm> ("Add new
Features to the Map" paragraph).


Unfortunately the basic frontend Osmand feature that shows the properties
of a geographic feature misled me and I thought that the appropriate column
was already available. I did not consider to examine the DB itself.


Thanks also to notifying me the tools you mentioned.


At the end I might assume that, as *summit:cross* is not a column mentioned
in the default *rendering_types.xml* file, then it is missing in the DB.


This would mean that not only the *rendering_types.xml* file must be edited
and a new custom .obf database has to be generated, but also that no map
file downloaded from Osmand will be able to show the new feature until, I
guess, a merge update is performed here
<https://github.com/osmandapp/OsmAnd-resources/blob/master/obf_creation/rendering_types.xml> and
all hosted DB files are subsequently refreshed.


So I should no more rely on the downloaded maps to show the new feature (at
least until the new feature is also managed by the map generator hosted by
Osmand).