EN—Rendering
style begins with the definition of
the optional menus, for example:
<!-- add cricri remove markup -->
<renderingProperty attr="markup" name="hide markup" description="hide markup" type="boolean" possibleValues="" category="hide"/>
or "markup" must be called each time you want the following element(s) to be hidden
<!-- pedestrian markings -->
<switch markup="false" >
`<case minzoom="12" tag="network_iwn" value="" color="#ffddaa" shadowColor="#99ffddaa" strokeWidth="0.1:1" />
this "switch" will appear in the "hide" menu of the style options.
then the definition of
which can be reused at will to replace a value provided you put $ before_their_name,
for example the color of the paths
<renderingAttribute name="trackColor">
<case attrColorValue="#996600"/>
</renderingAttribute>
each time we want to use this variable (here an RGB hexadecimal color) we will put $trackcolor instead of #RGB
<!-- drivable -->
<switch>
<case additional="surface=pebblestone" />
<case additional="smoothness=very_bad" />
<case additional="tracktype=grade3" />
<apply minzoom="12" color_5="$trackColor" >
the interest being to only have to modify the variable so that it is updated in all the rest of the style.
it defines the content of the "Road type" block in the "Details" of the route calculation
WARNING it can crash iOS with attrStringValue different from those used by default (details to come after testing)
<case tag="highway" value="track" attrColorValue="$trackColor" attrStringValue="highway_class_track"/><!-- translated Track-->
<case tag="highway" value="path" attrColorValue="#ff0000" attrStringValue="highway_class_path"/><!-- translated path-->
<case tag="highway" value="pedestrian" attrColorValue="#ff0000" attrStringValue="highway_class_path"/>
<case tag="highway" value="footway" attrColorValue="#ff0000" attrStringValue="highway_class_path"/>
<case tag="highway" value="bridleway" attrColorValue="#ff0000" attrStringValue="highway_class_bridleway"/>
<case tag="highway" value="steps" attrColorValue="#ff0000" attrStringValue="highway_class_steps"/>
<case tag="highway" value="cycleway" attrColorValue="#ff0000" attrStringValue="highway_class_cycleway"/>
</renderingAttribute>
defines the content of the "Surface hardness" block in the "Details" of the route calculation
no limitations, you can arrange/name it however you want
<renderingAttribute name="routeInfo_tracktype"> <!-- surface hardness-->
<case tag="highway" value="service" attrColorValue="$trackColor" attrStringValue="driving"/>
<case additional="tracktype=grade1" attrColorValue="$trackColor" attrStringValue="driveable"/>
<case additional="tracktype=grade2" attrColorValue="$trackColor" attrStringValue="driveable"/>
<case additional="tracktype=grade3" attrColorValue="$trackColor" attrStringValue="coarse driveable"/>
<case additional="tracktype=grade4" attrColorValue="$trackColor_2" attrStringValue="driveable depending on weather"/>
<case additional="tracktype=grade5" attrColorValue="$trackColor_2" attrStringValue="bare ground"/>
<case tag="highway" value="track" attrColorValue="$trackColor_2" attrStringValue="unspecified path"/>
<case tag="highway" value="path" attrColorValue="#ff0000" attrStringValue="path"/>
<case tag="highway" value="footway" attrColorValue="#ff0000" attrStringValue="trail"/>
<case tag="highway" value="bridleway" attrColorValue="#ff0000" attrStringValue="jumper"/>
<case tag="highway" value="steps" attrColorValue="#ff0000" attrStringValue="stairway"/>
<case tag="highway" value="cycleway" attrColorValue="#ff0000" attrStringValue="cycleway"/>
items not in this paragraph will not be displayed (use wildcards or empty definitions ="")
the value ranges from 1 to 200, with 1 being the lowest in the stack when displaying (polygons first, lines second, then points)
if you don't see an element that you know exists in OpenStreetMap, first check if it is included by OsmAnd in the map by searching for it with its osm tag in this file
if you found it and you I don't see, check in this chapter "order" of your style if it is well treated somewhere...
you can "cheat" (for test for example) by adding before the end of the chapter this which will make appear any element
<case tag="" value=""/>
there are some subtleties like getting (or not) a point from a polygon
convert polygon to line (no fill)
here the polygons of the national parks without filling because already filled by the attribute "nature reserve" which allows transparency
their contour become "line" will be usable in the rendering and to recover the text to be displayed via the created point
<case tag="boundary" value="national_park" order="2" ignorePolygonArea="true"/>
<case tag="boundary" value="protected_area" order="1" ignorePolygonArea="true"/>
see my comments in the file for the "text on path"
everything related to the texts displayed in the style, regardless of the element
WARNING the order is reversed compared to the "order" paragraph, the smaller the number, the more the text has priority in the display
it can even, depending on the parameters, stay above the others and hide them
I haven't managed to really understand the impact of these parameters intersectionMargin intersectionSizeFactor intersectsWith
the textMinDistance allows you to manage the number of text of the same type displayed (along a river for example), the smaller it is (in pixels?) the more text there is displayed
this is where the icons are managed along the markups for example or the route refs
for example the icons of mountain bike routes
<!-- MTB icon -->
<switch lessDetailed="false" markup="false" minzoom="14" textOnPath="false" textSize="0" textOrder="169" >
<case tag="route_mtb" value="" nameTag="name"/>
<case tag="route_mtb" value="" />
<apply icon="osmc_blue_bicycle" textShield="osmc_blue_circle_bg">
<case maxzoom="14" intersectionMargin="60" textMinDistance="450"/>
<case minzoom="15" intersectionMargin="30" textMinDistance="300"/>
</apply>
<apply_if nightMode="true" icon="osmc_blue_bicycle" textShield="osmc_blue_circle_bg" textMinDistance="130"/>
</switch>
with settings that manage the amount of symbols displayed (textMinDistance and intersectionMargin which repels or suppresses other text nearby)
here 2 settings depending on the zoom for the amount of symbols displayed (these settings require a lot of testing on different device resolution to be satisfactory)
where each icon allows in the latest versions of OsmAnd to load the route (here MTB) as a track with the associated info
WARNING the order is reversed compared to the "order" paragraph, the smaller the number, the more the point (the icon) has priority in the display
iconVisibleSize doesn't seem to work
this is where you choose from the icons imposed by OsmAnd and available here
nothing special if you have managed your "order" well (polygon in line or point in the center of the polygon)
here the "water" surfaces
<!-- water -->
<switch color="#7ad1ed">
<switch>
<case minzoom="1" tag="natural" value="coastline"/>
<case minzoom="10" tag="natural" value="water"/>
<case minzoom="10" tag="landuse" value="tank"/>
<case minzoom="10" tag="landuse" value="salt_pond"/>
<case minzoom="12" tag="waterway" value="riverbank"/>
<case minzoom="14" tag="landuse" value="basin"/>
<apply color_2="#90c0ff" strokeWidth_2="1:1"/>
</switch>
"color" is the fill color
"color_2" is the color of the outline to which you must imperatively associate a "strokeWidth_2" to define its thickness
ATTENTION do not use "color_0" as fill (inherited from shader), the polygon will be invisible in OpenGL.
nothing special if you have managed your "order" well (polygon online)
each line can have in addition to the "color" attributes a "shadowColor" attribute which is the border (practical for routes but with certain defects, such as an order which does not follow that of the line)
each line can have several "color" attributes (color, color_0, color_1 etc) it is necessary each time to define its "strokeWidth" according to the same principle of numbering, which makes it possible to define a line several times, as for bridges by example where "color" is the color of the road and "color_1" the color of the road when it is a bridge.
the colors overlap each other according to their index (0 below 1 below 2 etc)
there are many limitations related to the rendering engine (openGL on iOS, java on Android)to the definition of peripherals and zoom levels, it is sometimes quite complex to obtain the desired rendering and you have to "cheat".