Rendering problem while rotating the map (OSMScout2) about libosmscout HOT 10 CLOSED

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)!

from libosmscout.

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

from libosmscout.

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 :-)?

from libosmscout.

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)

from libosmscout.

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.

from libosmscout.

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) :-/

from libosmscout.

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.

from libosmscout.

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.

from libosmscout.

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?

from libosmscout.

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...

from libosmscout.