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: [email protected] > To: [email protected] > 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 > > [email protected] > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > _______________________________________________ > mkgmap-dev mailing list > [email protected] > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list [email protected] http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
