[mkgmap-dev] [PATCH V2] boundary preparer with quadtree

Tue Feb 7 20:39:35 GMT 2012

Gerd,

I asked to keep the bnd file format before you decided to put quadtree 
info into the precompiled bounds. Now the situation has changed and I 
agree that it is better to change the format. Otherwise too many tricks 
must be used which make it much more complicated to understand what happens.

So feel free to change the format :-)
If possible please also think about Klaus wish to use one zip file 
instead of lots of single files. I know there is a problem that the ZIP 
file classes of Java are not thread safe. But for reading it should be 
possible to use a ThreadLocal ZIP file reader (just an idea....).

The old tools must not be kept but some changed or new tools that helps 
to get infos about the precompiled bounds should exist after the format 
change. Some ideas what might be of interest:
* Which boundaries are used at a given location?
* Listing of a boundary file
* Merging all areas of a given admin_level over all bnd files. I can 
send you a tool for the old bnd format which creates GPX files with the 
coverage of admin_levels. This was quite necessary to check which 
countries were broken.
* ...

WanMil

> Hi WanMil,
>
> my goal was to save the information in a way that filling the quadtree
> can be done with
> a minimum of complex operations like Area.subtract() or intersect().
> The BoundaryQuadTree.merge() information is stored in the
> mkgmap:intersects_with tag.
> Each boundary saved a treepath is trimmed to its place in the quadtree,
> level2 boundaries
> are probably only saved with their tags and the bounding box. I used
> this way to enable
> the locator to chose the right when used in LocationHook.
> One drawback of this method is that we have many small parts of
> boundaries, which is bad
> for tools like BoundaryLister or BoundaryFile2Gpx, but best for
> LocationHook.
> I am not sure if it is better to convert each of the tools to handle the
> quadtree format as well or
> to add an adaptor which tries to rebuild the original boundary list.
> I guess the adaptor is the better choice.
> The other drawback is that the bnd file contains a lot more redundant
> information. All tags of a level-8 boundary
> that overlaps multiple quadtree nodes are saved many times, maybe with
> different mkgmap:intersects_with tags,
> and for sure with different area info.
> If you don't mind creating a completely new bnd format, I would not save
> this redundant info, instead I would
> save the common tags once, and then all areas, and only the tags for
> ref-only boundaries.
>
> Ciao,
> Gerd
>
>
>
>
>  > Date: Mon, 6 Feb 2012 23:11:27 +0100
>  > From: wmgcnfg at web.de
>  > To: mkgmap-dev at lists.mkgmap.org.uk
>  > Subject: Re: [mkgmap-dev] [PATCH V2] boundary preparer with quadtree
>  >
>  > Hi Gerd,
>  >
>  > I need some time to look through your patch. But after a first short
>  > look through I wonder if you tried to handle the balancing act between
>  > keeping the old bnd format and saving your quadtree in an apropriate way.
>  >
>  > Using the boundary lister I think have seen that you save each boundary
>  > but no merged boundary? I see you are saving admin_level=2 and
>  > additionally admin_level=4 and admin_level=6 etc. I expected that one of
>  > your improvements is that you are doing the complete merge step during
>  > preparation so that you save one area (or boundary) with all infos of
>  > admin_level=2,4 and 6.
>  >
>  > Your new mkgmap:boundaryid format mixes multiple information in one tag.
>  > I think it is better to use the mkgmap:boundaryid for the id only and
>  > one or more additional tags for your quadtree information.
>  >
>  > That's just my first impression. I think your idea is exactly right to
>  > move the merge step to the preparer. I am not 100% sure if it is
>  > necessary to save the quadtree node infos. But I am sure you have
>  > compared the performance :-)
>  >
>  > WanMil
>  >
>  > > Hi,
>  > >
>  > > attached is the patch that works on linux systems, no functional
> change to
>  > > v1.
>  > >
>  > >
> http://gis.19327.n5.nabble.com/file/n5459686/boundary_prep_quadtree_v2.patch
>  > > boundary_prep_quadtree_v2.patch
>  > >
>  > > Gerd
>  > >
>  > > --
>  > > View this message in context:
> http://gis.19327.n5.nabble.com/PATCH-V2-boundary-preparer-with-quadtree-tp5459686p5459686.html
>  > > Sent from the Mkgmap Development mailing list archive at Nabble.com.
>  > > _______________________________________________
>  > > mkgmap-dev mailing list
>  > > mkgmap-dev at lists.mkgmap.org.uk
>  > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>  >
>  > _______________________________________________
>  > mkgmap-dev mailing list
>  > mkgmap-dev at lists.mkgmap.org.uk
>  > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev