[PATCH v1 + v1] fix overview bounding box rounding + splitter rounding

v1 + v1 - OK, here's the matched pair - patches for both the splitter and mkgmap. With these in place, the mapsource mouse works as expected across all tile boundaries right up to the outer boundaries. No weird overlap of tile and overview map. Spot on. Please could some others give this a test and confirm that the rounding is now correct. ----------------- Thinking some more about what I was seeing in mapsource when mousing around the Baltic map, I came to the conclusion that the edges of the overview map bounding boxes where in the wrong place so I took a look at mkgmap where it rounds those coords and came up with the attached fix. No great theory here, I just dicked around until it worked as I expected. For the Baltic map, the mouse now works right up to each boundary in both lat and lon directions whereas before it would only work right on one side of each boundary. Please try the patch, especially for maps that are W of Greenwich and S of the equator and see if the overview boxes are right. Cheers, Mark

On 25.01.2010 23:05, Mark Burton wrote:
v1 + v1 - OK, here's the matched pair - patches for both the splitter and mkgmap.
With these in place, the mapsource mouse works as expected across all tile boundaries right up to the outer boundaries. No weird overlap of tile and overview map. Spot on.
So we need the splitter even if the tile needs no splitting. Correct? Maybe my problems with the legend map relate to me not passing it trough the splitter. Will try out if it makes a difference.
Please could some others give this a test and confirm that the rounding is now correct.
-----------------
Thinking some more about what I was seeing in mapsource when mousing around the Baltic map, I came to the conclusion that the edges of the overview map bounding boxes where in the wrong place so I took a look at mkgmap where it rounds those coords and came up with the attached fix. No great theory here, I just dicked around until it worked as I expected.
For the Baltic map, the mouse now works right up to each boundary in both lat and lon directions whereas before it would only work right on one side of each boundary.
Please try the patch, especially for maps that are W of Greenwich and S of the equator and see if the overview boxes are right.
Cheers,
Mark
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Felix,
So we need the splitter even if the tile needs no splitting. Correct? Maybe my problems with the legend map relate to me not passing it trough the splitter. Will try out if it makes a difference.
A side effect of using the splitter is that it rounds the boundaries of the tiles. So if the boundaries of your map are already correctly rounded and the map otherwise doesn't need splitting, you don't have to split it. But yes, running a map through the splitter is an easy way of rounding the boundaries (assuming it's doing it right!) Mark

On 25.01.2010 23:20, Mark Burton wrote:
Felix,
So we need the splitter even if the tile needs no splitting. Correct? Maybe my problems with the legend map relate to me not passing it trough the splitter. Will try out if it makes a difference.
A side effect of using the splitter is that it rounds the boundaries of the tiles.
So if the boundaries of your map are already correctly rounded and the map otherwise doesn't need splitting, you don't have to split it.
But yes, running a map through the splitter is an easy way of rounding the boundaries (assuming it's doing it right!)
Mark
The fix to the splitter plus the patches DID it. However why is the map flooded if I don't put an natural=land all around it. I'm using "=polygons" Have you got any idea on this? I think if there is no sea polygon at all, the =polygons code should still create a natural=land on top of the blue background (I already noticed this, so bug is not new, but I assumed it to happen somehow due to the wrong overview map) - Should I open another thread for this?
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Felix,
The fix to the splitter plus the patches DID it. However why is the map flooded if I don't put an natural=land all around it. I'm using "=polygons" Have you got any idea on this?
I should think that your little natural=coastline poly on the RHS just below the middle is causing the problem because what you have there is an anti-island (sea surrounded by land) and I don't think the sea generation code knows about anti-islands.
I think if there is no sea polygon at all, the =polygons code should still create a natural=land on top of the blue background (I already noticed this, so bug is not new, but I assumed it to happen somehow due to the wrong overview map) - Should I open another thread for this?
Well, it does generate a land poly when there's no sea but your legend map has sea. I'll think about this and see if I can fix the problem. Mark

On 25.01.2010 23:38, Mark Burton wrote:
Felix,
The fix to the splitter plus the patches DID it. However why is the map flooded if I don't put an natural=land all around it. I'm using "=polygons" Have you got any idea on this?
I should think that your little natural=coastline poly on the RHS just below the middle is causing the problem because what you have there is an anti-island (sea surrounded by land) and I don't think the sea generation code knows about anti-islands.
No I put that natural=land to stop flooding. If it is removed everything gets flooded. Sorry should have noted this. There is one big big reason why I really don't want to drop --geneerate-sea=polygons (and also would like to have the option to create natural=land for all maps where I have to disable --generate-sea to avoid flooding), and that is that I need natural=land to change background color (so there is no nasty nasty yellow).
I think if there is no sea polygon at all, the =polygons code should still create a natural=land on top of the blue background (I already noticed this, so bug is not new, but I assumed it to happen somehow due to the wrong overview map) - Should I open another thread for this?
Well, it does generate a land poly when there's no sea but your legend map has sea.
It does, sadly.
I'll think about this and see if I can fix the problem.
No problem to make it complicated. But I don't understand why it is flooded 100% without natural=land polygon.
Mark _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (2)
-
Felix Hartmann
-
Mark Burton