logo separator

[mkgmap-dev] splitter r232

From Henning Scholland osm at aighes.de on Fri Nov 16 09:11:23 GMT 2012

Am 16.11.2012 09:09, schrieb Gerd Petermann:
> Hi all,
>
> >
> > 11000004: 1800192,1406976 to 1968128,1681408
> >
> > In this tile (north-western Turkey) there are missing two ferry-routes
> > (Yalta-Istanbul and Sivastopol-Istanbul). As I opened the tile in josm,
> > I discovered also, that there are several objects in that tile, which
> > shouldn't be in it. Eg. boundary of USA, Russia
>
> reg. the ferry-routes:
> I can't say for sure, but I'd say these ferry lines really don't cross 
> the tile.
> I think it is a good idea to write the tile bordes in gpx format, this 
> will help
> to answer such questions.
An easy check is to display the map in MapSource and choose one tile, so 
this tile will be highlighted.
I created an osm-file with 11000004-boundary and the two ferry-routes. 
http://www.aighes.de/data/11000004.zip

With open-data-PlugIn you can also open kml-files to josm ;)

> reg. "objects that shouldn't be in it":
> I would accept Russia for now, but USA really sounds strange.
> I think the reason is the very simple that is used now:
> For a multipolygon (or boundary), splitter simply calculates the 
> bounding box
> of all ways. The result is a rectangle. Every tile that intersects 
> this rectangle contain the
> complete relation.
> The advantage of this method is that splitter doesn't have to 
> calculate the real MP (which
> invvolves many special cases like incomplete data, holes etc). I 
> wanted to leave this
> to mkgmap.
Ah..thats logical. Russia is crossing 180°/-180°
> For most boundaries, this simple alg. works quite well, because the 
> bbox of the boundary doesn't
> contain too much other stuff.
> The bbox for Russia is obviously very big and contains a large area 
> which doesn't belong
> to Russia. A real problem is USA (and probably other countries with 
> external territories:
> Because of Hawai and some other islands the bbox for USA covers almost 
> half of the planet.
> I hope I can find an alternative algorithm that is still simple and 
> fast, but doesn't
> make this error.
I think, this would be acceptable. Splitter would save data with 
overlap=0, so there shouldn't be a real problem, if these to boundaries 
were copied to a lot of tiles.

Henning
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20121116/0bab3578/attachment.html 


More information about the mkgmap-dev mailing list