[mkgmap-dev] splitter: relations to be checked with keep-complete=true

Wed Dec 19 20:32:23 GMT 2012

I want to go a bit more into detail.

Splitter now puts the following things into a tile (Gerd, please correct 
me if I am wrong ;-):

1. All nodes that are within the tiles bounding box
2. All ways that intersect the bounding box including all nodes
    (no matter if they are within the bbox)
3. All relations that contain a node or a way that is in the tile.
   These relations need not be complete. Some nodes or ways can be
   missing if they do not match the first two rules. Subrelations
   are not handled.
   Special rule:
   Relations of the following type are always complete:
   multipolygon
   restriction
   through_route

In more simple words these rules put all data into the tile that lies 
directly in the tile or that might modify some data in the tile.

Obviously this will generate some questions.

- Why are subrelations not ignored?
Subrelations are not handled by mkgmap so they can be ignored.

- Shouldn't route relations be complete in the tile?
Route relations contain ways. It is possible with the relations style 
file to modify ways and nodes based on the relation tags. But this makes 
sense only with ways and nodes lying within or intersecting the tile 
bounding box.

- Shouldn't boundary relations like multipolygons be complete in the tile?
Yes, but...
Adding all related boundary data to a tile increases the tile size very 
much and makes sense only if the boundaries are used as polygons. At the 
moment we don't know anybody who uses boundaries as polygons but lots of 
users use them as lines to display the border names. All relevant data 
for this is available in the tile (some relations are missing with the 
current trunk version!).

- Why are the tiles sizes noticeably smaller compared to the trunk version?
The main reason is that the trunk version puts complete relations to the 
tile. If you have a motorway in the tile that is part of an e-road the 
trunk version adds the whole e-road to the tile although you need only 
the ways that intersect the bounding box.

So my conclusion is: The patch fixes a (small) bug in the trunk version 
(some missing boundary relations) and optimizes the tile size by putting 
only data into the tile that theoretically can be used by mkgmap.

If someone wants to test that more in detail I propose to run splitter 
with a small polygonfile, a small max-nodes number and xml output. Then 
you can open the tiles with JOSM and see if everything you would expect 
is contained in the tile.

WanMil

> Hi all,
>
> attached is version 4 of the patch, based on the problem-list branch.
> WanMil and I found out that it reduces the size of splitter output files
> (and run time) quite nice, but it also sometimes adds boundary relations
> that were not output with r263, which in
> turn changes the output of mkgmap a little bit.
> We are not sure if this is acceptable for all, so please try this.
>
> Gerd
>
>
>  > Date: Mon, 17 Dec 2012 06:41:40 -0800
>  > From: gpetermann_muenchen at hotmail.com
>  > To: mkgmap-dev at lists.mkgmap.org.uk
>  > Subject: Re: [mkgmap-dev] splitter: relations to be checked with
> keep-complete=true
>  >
>  > GerdP wrote
>  > > Attached is a patch for r263 that tries to implement WanMils
> proposals.
>  >
>  > Stupid error: the patch did not filter type=route relations because
> route is
>  > contained in through_route.
>  > Here is the corrected version.
>  > limit_relation_types_v2.patch
>  >
> <http://gis.19327.n5.nabble.com/file/n5740697/limit_relation_types_v2.patch>
>
>  >
>  > The amount of removed data is quite big, so it would be nice if that
> still
>  > is all that we need
>  > for mkgmap.
>  >
>  > Ciao,
>  > Gerd
>  >
>  >
>  >
>  > --
>  > View this message in context:
> http://gis.19327.n5.nabble.com/splitter-relations-to-be-checked-with-keep-complete-true-tp5740576p5740697.html
>  > Sent from the Mkgmap Development mailing list archive at Nabble.com.
>  > _______________________________________________
>  > mkgmap-dev mailing list
>  > mkgmap-dev at lists.mkgmap.org.uk
>  > http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>