Wrong path orders affect bicycle profile display in dependent renderers like Touring view

[michaelblyons]

Description

In vector maps with the style for Touring view, the footpaths disappear and reappear at different zooms. Edit: Only if the base profile is bicycle.

Steps to reproduce

• Edit: Use a bicycle profile.
• Make sure you're in vector maps.
• Set the style to Touring view.
• Find a location with footways.
• Zoom all the way in.
• Zoom out until the footway disappears.
• Zoom out one more time.
• Observe the footways reappear.

Actual result

There's a random zoom where footways are missing.

Expected result

Continuous visible footways. Pick zoom where you want to hide footways, but don't have a random missing section.

Your Environment (required)

OsmAnd Version:4.8.6

[mariush444]

Same with icons supermarket example 31.33120 37.34670 zoom 15 and 17 - icon is visibled but at zoom 16 icon is not shown

probably overlaping problem but I coudn't find object that makes this

[sonora]

I cannot actually reproduce this for now. Perhaps you are viewing a rather'busy' section of the map and encounter a detail cutoff present by default for perfomance reasons. Can you please activate the setting Configure map > Detail > More details to see if this fixes the behavior?

[michaelblyons]

"More details" fixes the problem. If there's no more to be done, feel free to close.

[sonora]

@xmd5a2 , @Chumva I wonder if there is a way to simply set the "More Details" flag's default to 'on', (at least) when the Touring view renderer is selected?

After all it is a high detail Map style anyway, and with more powerful devices these days having it default to 'off' may not be justified any more.

Please note that the Touring view renderer itself has only 1 dependency on the More Details flag anyway, but the underlying default.render has hundreds... That's why setting the flag to 'on' seems necessary, eliminating Touring view's direct dependency will not do the trick(?)

[mariush444]

but not everyone uses power devices

[sonora]

By my old testing, performance hit by using "More Details" in the Touring view renderer was ~20%. If that's not worth it for having the extra details, "More Details" should simply be turned off. My idea is simply to turn it on by default for Touring view users, because a typical reason for selecting it in the first is to receive high detail.

[sonora]

@xmd5a2 I initially thought this is a density issue, but it is not. It looks like a gap between Touring view and default.render. Possibly caused here? What's the point in suppressing zoom 14 here, can we eliminate this?

<apply_if baseAppMode="bicycle" moreDetailed="false">
    <apply_if minzoom="14" maxzoom="14" order="-1"/>
    <apply_if additional="bicycle=designated" minzoom="15" maxzoom="15" order="88"/>
</apply_if>

[sonora]

PS: A good way to reproduce, because it's long enough, seems https://www.openstreetmap.org/way/152135015, in bicycle profile and with "More Details" being off.

General finding: Panning around city areas in bicycle profile: There is a general failure to re-order some bicycle usable paths to the top, (in partilular e.g. highway=path with bicycle=designated, which in rendering_types.xml seem transformed to footways). Often they are hidden below e.g. unclassified or tertiary roads. Switching to the pedestrian profile has no such issue, there they become visible on top.

We need a general review of the <order> block in default.render in combination with minzooms (and keep in mind that the orders should also cater for dependent renderers, which may display some parhs at earlier minzooms already than default.render.

[michaelblyons]

Tangentially, I think you could hide footway=sidewalk at medium zooms for bicycle/touring. But I can move that to another issue if you prefer.

[sonora]

Separate issue, perhaps. Also there, Touring view carries no deviating provisioning for sidewalks, so also this is something which would need looking at in default render.

[sonora]

While I am still not sure why we need minzoom statements in the highway <order> section of default render, this small fix at least corrects the most blatant issues observed above.