Mapsforge: large query zoom levels have polygon artifacts

[braandl]

When trying to render large Polygons from Mapsforge Mapsource, the Polygons and their outlines got destroyed, due to coordinates that break the linits of the shortBuffer.

Clipping these coordinates does improve rendering performance a little and prevents rendering artifacts on high zoomlevels (18+ for me).

[devemux86]

Can you share an area to test that behavior before and after?

[braandl]

Sorry, I was just preparing the Images for upload. Here they come:

[braandl]

Simply allow the MapFileTileSource to load up to Zoomlevel 20+ and then load some map.

[devemux86]

Coordinates (to avoid searching) ? 🙂

[braandl]

lat: 50.069218, lon: 8.719738

https://www.google.de/maps/place/50%C2%B004'09.2%22N+8%C2%B043'11.7%22E/@50.069207,8.7177343,17z/data=!3m1!4b1!4m14!1m7!3m6!1s0x47bd1ea31649d8eb:0x98bb77a2ca2fc8a5!2sA66!3b1!8m2!3d50.1313217!4d8.6615183!3m5!1s0x0:0x0!7e2!8m2!3d50.0692073!4d8.7199232

using the normal "hessen.map" from Mapsforge Download Server for example.

The only changes I did to the mapsforge sample is allowing Zoomlevels up to 21.

After applying my patch, the issue is gone.

[devemux86]

Thanks for the additional info, will review it.

BTW any tile clip buffer probably should be based on dpi, like in MapDatabase.

[braandl]

The issue with dpi based buffers is, that no dpi is known in gwt applications what can lead to render artifacts again.

[devemux86]

Library is platform agnostic, running on mobile and desktop, so should support all.

We use dpi scaling (e.g. CanvasAdapter.dpi / CanvasAdapter.DEFAULT_DPI) in many places like in rendering, themes, etc.
If a platform cannot calculate it, the default is 1.

[braandl]

I know. Still it results in bad render quality on some browser plattforms, but feel free to change it and change the buffer to some dpi dependent value.

[devemux86]

Still it results in bad render quality on browser plattforms.

Why? It's the ratio we use, not the actual dpi value.
Vector map libraries like Mapsforge or VTM on desktop can keep default scale ratio 1, unless have in mind 4K screens.

[braandl]

Exactly. It makes lines disappear and produces a lot of alias. But this is all totally off-topic.

[devemux86]

Cannot reproduce the case (even with tilt), what else is needed?

Used vtm-android-example and MapsforgeMapActivity with hessen.map and changed:

mMap.viewport().setMaxZoomLevel(22);
mMap.setMapPosition(new MapPosition(50.069218, 8.719738, 1 << 21));

[braandl]

Nothing else. The effect is the strongest when you have some large polygons with highlighted boundaries... My screenshot is from a clean pull of the master branch with no changes...

[devemux86]

Still we need a test case. Cannot see anything strange at those coordinates.

[braandl]

On the Samsung Galaxy S7 Edge it is really intense here:

https://www.google.de/maps/place/Mobilheime-Kahl+Dirk+Ritter/@50.0808835,9.0028989,17.42z/data=!4m5!3m4!1s0x47bd3ddf71125ecd:0xdb00313dc1f32675!8m2!3d50.081895!4d9.007894

[devemux86]

Very strange.. using the same map file and default theme, see nothing.

mMap.viewport().setMaxZoomLevel(30);
mMap.setMapPosition(new MapPosition(50.0808835, 9.0028989, 1 << 21));

Where is the image position, is it the above?
Can you post an exact setMapPosition where the issue should appear?
The issue should be reproducible on Android emulator to be able to test it.

[braandl]

Did you allow the Maploader to generate Tiles to that degree, too? Otherwise it will simply not render the tiles in that zoomlevel and the issue does not appear, as I wrote earlier. You can enable the debugoverdraw in "VectorTileRenderer" and all tiles should be rendered in green. The position does not matter to much, it happens everywhere on the map.

public MapFileTileSource() { this(0, 21); }

[devemux86]

No, of course not. Such information did not exist in issue description, so obviously hadn't all the required information for a proper testing. 🙁

BTW there is #231 about changing Mapsforge default settings, in most cases not needed since the tiles over zoom to max zoom of the map view and map files max base zoom is 14.

[braandl]

Simply allow the MapFileTileSource to load up to Zoomlevel 20+ and then load some map.

And it is a completly different issue

[devemux86]

A test code is a thousand words.

Now that the issue is more informative, can test what happens.

[devemux86]

Behavior seems Mapsforge specific, so if can handle it inside Mapsforge classes, to not break rest lib GL rendering.

The buildings could cause the issue (as seen in urban areas), since commenting them here in default.xml theme eliminates any artifacts.

In Mapsforge MapDatabase.processWays there is a check here to not use TileClipper for buildings, probably due to opensciencemap#124.

So pushed in issue_391 branch also an additional check for map file tile source max zoom that clips also the buildings and the render artifacts disappear.

Additional work can be done in MapDatabase.setTileClipping optimizing the tile clip buffer for map files.

[braandl]

That should also do it for the MapFileTileSource, but I am convinced that your assumption is wrong, and it does simply not effect other Tilesources because they do not deliver tiles on such a high zoom level, so the parent tiles are rendered.

[devemux86]

Each tile source has its own tile decoder and we can check each one when can be actually tested.
e.g. Mapzen doesn't seem having polygon issues, but has line artifacts even at zoom 16 (#288)

[devemux86]

Closing as handled inside Mapsforge classes.