Rendering artifacts in navigation mode when perspective view is on.

[Endem10n]

After created route to some point, some objects rendered with artifacts, when perspective view setting is on.

Coordinates, where it can be reproduced: 54°24'50.0"N 18°36'12.6"E; 54°24'27.4"N 18°36'59.7"E.

Reproduced on Vivo Y11s with Android 11 and on iPhone SE with iOS 14.6

video from Android video from iOS

[vng]

Reproduced flickering here 49.4219568,8.6382218 on desktop, perspective:

[biodranik]

How to start a Nav mode on the desktop?

[vng]

• ALT + LMB to set your current position
• SHIFT + LMB to set end route point and build route
• Press blue arrow button (Follow route)

Emulate driving positions with ALT + LMB

[pastk]

Reproduced flickering here 49.4219568,8.6382218 on desktop, perspective:

Now OSM data has changed here, but it looks like it was landuse-allotments mapped on top of landuse-farmland - their area drules have the same priority and hence polygons sent to OGL had the same depth value. So the flickering is probably a result of "z-fighting".

Since #4581 it shouldn't happen in such cases as the depth value is derived from area's bbox sizes and here they're very different.

But now it could happen for cases when same bbox size features overlap each other, like here: https://www.openstreetmap.org/way/616385905 (a cemetery and a forest mapped on top of each other). As bbox sizes are the same then depth values are the same and hence "z-fighting" resulting in flickering: video

This is the hypothesis :) If its true then to prevent "z-fighting" we need to avoid identical depth values - we can try to add a priority-derived tiny value to bbox size value - so tiny as to not affect the size ordering, but big enough to make depth values different (i.e. distinguishable given a limited z-buffer precision).

[RicoElectrico]

This issue also happens for me in the latest beta: https://www.openstreetmap.org/#map=17/54.47004/18.52403

https://github.com/organicmaps/organicmaps/assets/1409116/8d1b9166-6a41-4bff-aa99-78f1dc9b837c

[pastk]

This issue also happens for me in the latest beta: https://www.openstreetmap.org/#map=17/54.47004/18.52403

Yeap there is a park mapped two times with almost same borders (bbox is likely the same), so this case fits into the hypothesis I described in the previous post.

https://www.openstreetmap.org/way/1195392633 https://www.openstreetmap.org/way/1194863848

[biodranik]

Is it an OSM data issue that should be fixed there?

[RicoElectrico]

@biodranik Yes, I fixed it yesterday. However I think it's best to handle errors gracefully. I know it's not that rare for mappers to come up with such constructs. For example when cemetery sectors did not have standardized tagging, people mapped landuse=cemetery+name=* inside landuse=cemetery. Likewise I would not be surprised if I see landuse=residential inside landuse=residential to signify housing estates named by the property developers (think "Foo City Waterfront", "Random Name Park"). @pastk maybe we can do something similar to openstreetmap-carto which sorts z-order by area?

[pastk]

@RicoElectrico we sort by area size already (bounding box though, not a true precise area), but in those cases bbox areas are of same size, hence the issue. A possible solution I described before will work for overlapping features of different types. For the same type (duplicate) features we might add a tiny random or featureId derived value. If you're curious or want help fix it, then the relevant code is in drape_frontend/stylist.cpp Aggregator::Init().

[RicoElectrico]

Oh, I see. This error indeed will be very rare as it not only requires geometry to cross, but also bboxes to equal. Here's an example PostGIS query: sselect a.osm_id, b.osm_id, a.landuse from planet_osm_polygon a join planet_osm_polygon b on a.landuse is not null and a.landuse=b.landuse and a.osm_id < b.osm_id and a.way ~= b.way and ST_Relate(a.way,b.way,'2********') limit 10; which returns such cases for landuse. I don't know why https://www.openstreetmap.org/way/243870368 and https://www.openstreetmap.org/relation/10755784 don't flicker, then? I do my calculations in EPSG:3857, maybe that's the issue.

[pastk]

I don't know why https://www.openstreetmap.org/way/243870368 and https://www.openstreetmap.org/relation/10755784 don't flicker, then?

Those ways are a little different (you've got to take a very close look), so their bbox sizes might be a little different too. I don't know how your query works, perhaps the query's and OM's precision of calculation is different. You might want to log the sizes in OM to confirm.

[pastk]

I don't know why https://www.openstreetmap.org/way/243870368 and https://www.openstreetmap.org/relation/10755784 don't flicker, then?

Those ways are a little different (you've got to take a very close look), so their bbox sizes might be a little different too. I don't know how your query works, perhaps the query's and OM's precision of calculation is different. You might want to log the sizes in OM to confirm.

[RicoElectrico]

I don't know how your query works

Let me explain :) ~= is an operator that, using an index, compares whether 2 geometries have an identical bbox ST_Relate() does a generic spatial relationship test, with 9 relationships that represent dimensionality of intersection of interior/boundary/exterior of input geometries. Here I'm testing whether interior of the intersection of two geometries has a dimension of 2 (that is, it's a polygon, too). So, in plain English, whether they "properly intersect", not just touch. Or contain each other.

[biodranik]

If it's OSM data issues, then IMO we should not waste time on them, but instead fix them in OSM, and let everyone know: see blinking? Fix it.

[0Karakurt0]

50°26′58.27″N, 30°30′09.3″E

Reproduced here

[fizwidget]

Reproduced here (in pedestrian navigation mode).

[pastk]

In this case it seems to be natural=wood vs leisure=park area fills that seemingly share same polygon borders.

[user334]

Should we report here all the places where this issue occurs? 🤔 Anyway, found it happening here: https://omaps.app/44Ietr4urv/Лес App version: 2024.07.08-2-Google-beta with the latest available maps. Video: https://github.com/user-attachments/assets/9948d4fc-ffb4-474b-99b7-9ba7550c2d75

[user334]

Reproduced here: https://omaps.app/w4I0DjqIhK/Uilenbos There is a military zone which is shown on maps via red stroked overlay. This exact overlay flickers there while navigating.

[dmitrygribenchuk]

Hello. Have the same since 2023.09.05-12-Google-beta

Coordinates: https://www.openstreetmap.org/#map=19/54.645681/25.282650

https://github.com/user-attachments/assets/a78db3f7-d735-4d34-a5f3-81efd62892a6

[Self-Perfection]

I get the same issue here https://www.openstreetmap.org/#map=19/48.865820/2.317627

This is how it looks like:

https://github.com/user-attachments/assets/462bde7a-9336-4ba4-937f-a0cc9e246f57

I suspect these two relations are in conflict:

• https://www.openstreetmap.org/relation/1060283/
• https://www.openstreetmap.org/relation/10142348

Does not look like incorrect mapping to me. But I am not quite proficient with relations.

version: 2024.11.12-7-FDroid app.organicmaps