[mkgmap-dev] [Patch v5] LocationHook with new Quadtree

Thu Jan 19 21:32:53 GMT 2012

Hi WanMil,

OK, so I try to keep all available info available.
I thought about saving the original boundary information with an empty area section, 
and for the boundaries that were merged in quadtree add a tag similar to lies_in, e.g. 
intersects_with=2:r19884;4:r20039;6:r998818
Will try that tomorrow...

ciao,
Gerd

> Date: Thu, 19 Jan 2012 21:51:20 +0100
> From: wmgcnfg at web.de
> To: mkgmap-dev at lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] [Patch v5] LocationHook with new Quadtree
> 
> > Hi WanMil,
> >
> > I have coded a first version of the preparer with quadtree. It works so
> > far, the bnd files are not
> > much bigger and the format is still the old one (boundaryLister can read
> > them), the creation is a
> > little bit faster compared to trunk.
> 
> Great!
> 
> >
> > I think I understand now your question regarding the merging the tags.
> > In the trunk implementation we save all kinds of tags for the boundary,
> > although only a few are
> > needed by LocationHook. Now, when BoundaryQuadTree.Node.merge() has
> > executed, I have
> > some areas that are intersections of two or more boundaries. It is clear
> > that we have to save the
> > location relevant tags, but what about the other? Can we simply ignore
> > them? I guess no, because
> > we loose information like name:en, name:fr if they exist.
> 
> Yes, that's a problem. The name that is used for the boundaries is taken 
> from the name-tag-list option. I think this should not be dropped - 
> otherwise we loose the option to create a map with french or spanish 
> country and boundary names. But the tags used in the name-tag-list 
> option are not limited to "name:*" tags. So we cannot create a rule 
> which tags could be dropped during preparation.
> 
> It would be possible to create a dictionary with tag names at the 
> beginning of each bnd file. But I think it's better to implement the 
> whole functionality first with the current bnd file format. Once that is 
> done we might check if it improves the performance to optimize the bnd 
> format. But I doubt that it makes a big difference because most of the 
> bnd files are not very big. 99% of the bnd files of the world are 
> smaller than 1 MB.
> 
> WanMil
> 
> >
> > Any ideas?
> >
> > Ciao,
> > Gerd
> >
> >
> _______________________________________________
> 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/20120119/37eca4ce/attachment.html 