Rendering problem while rotating the map (OSMScout2)

[liv-kuka]

While rotating the map in demo application OSMScout (Qt, qml), some objects in the map may disappear depending on angle. Below few screenshots for demonstration.

In this case, river and some buildings not rendered in some range of angles.

[Framstag]

See http://libosmscout.sourceforge.net/documentation/renderprocess/ especially the chapter regarding map characteristics.

In case of rotating the map you bounding box for the "to be loaded" data of course increases. Did you take this into account in your code?

If your tiles have the dimension a*a than your bounding box may increase up to sqrt(a^2+a^2)!

[Karry]

This problem is reproducible by OSMScout2. It don't use limits for loaded elements right? It should not happen...

[Framstag]

Right, as you can see in void DBThread::TriggerMapRendering() the bounding box for the data is equal the dimension of the requested map. To fix this currentWidth and currentHeight would have to be extended (IMHO in worst case to sqrt(2*max(currentWidth,currentheight)^2)). You can of course evaluate the concrete angle to make a better guess.

Anybody interested to write down the math and supply a tested patch :-)?

[Karry]

I don't think that lookup bounding box is problem. When you look to MapService::LookupTiles , for bounding box is called Projection::GetDimensions and it already takes angle into account.

Look to this debug outputs:

Draw: [50.08573 N 14.42506 E - 50.13754 N 14.49069 E] 16384x/14 480x800 94.11040 DPI
Paths: 7170/1271/1271/243 (pcs) 0.029/0.010/0.010 (sec)
Areas: 4977/774/1548 (pcs) 0.054/0.010/0.001 (sec)
Nodes: 304+0/304 (pcs) 0.003/0.000 (sec)
Labels: 23/5/28 (pcs) 0.020 (sec)

And with different angle:

Draw: [50.08623 N 14.41825 E - 50.13705 N 14.49749 E] 16384x/14 480x800 94.11040 DPI
Paths: 7170/1245/1245/237 (pcs) 0.027/0.007/0.009 (sec)
Areas: 4977/317/634 (pcs) 0.050/0.004/0.000 (sec)
Nodes: 304+0/304 (pcs) 0.003/0.000 (sec)
Labels: 21/6/27 (pcs) 0.019 (sec)

Loaded area count is equals (4977) but rendered count is half... (1548 / 634)

[Framstag]

In this case it would also be helpful to have a concrete (geofrabrik) import and the id of the object that is missing on rotation. In above case the id of the river.

It is possible that further bounding box specific code (clipping,...) in the renderer does not use the corrected or an unrotated bounding box. Having a reproducer I can see, where data is dropped.

[Framstag]

I still believe that there is a bug in libosmscout regarding this. Likely sound bounding box check or similar is not in line with the rotation. To check this, it would be still helpful to get a concrete example. Ideally reproducable with one of the DrawXXX example (though the do not allow angle input yet) :-/

[liv-kuka]

Sorry for my long absence.
I encountered this problem using OSMScout2 from this repository. Map data was downloaded from geofabrik.de, it's Warsaw region (you can get it here: Mazovian Voivodeship). Rotating the map - using shift + left/right arrow key.
The only thing i added to the source code of OSMScout - it's debug message with current angle.
OSMScout_rotating_trouble.zip

In the images above also Warsaw and the disappearing river - Vistula.

[Framstag]

It looks like the problem is the visibility of https://www.openstreetmap.org/way/4990573#map=15/52.2206/21.0708 (and other objects). Lets check this and take a look, what is happening in the MapPainter.

[Framstag]

I have taken a look at it yesterday, but it looks like in this case I'm just stupid and do not see the real problem. What I see is, that in case where the object is not rendered the IsAreaVisible() method in the MapPainter returns false for these objects. The reason is, that the transformed on screen coordinates of the bounding box of the object (pixel position) result in rectangle that seems to be not visible. Either there is a bug in the projection code (which I do not see and I'm rather sure is just not there) or the conceptional idea of calcuating the bounding box, calculating the resulting screen positions of the min and max coordinates (including in this case rotating) and afterwards checking of the new (unrotated) rectangle build from the pixel coordinates is partly visible is plain wrong.

Anybody who has some time to think this through?

[Karry]

Hi, Tim. I extracted one problematic area and create test for this issue:
https://github.com/karry-space-with-my-second-forks/libosmscout/commit/d5448faa90568e2e2fc2a47d462170dad1deeaf2

We can use it for simple debugging this issue... I will look at it later...