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

Mon Feb 6 23:23:03 GMT 2012

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20120207/2e3866ae/attachment.html 