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

Thu Jan 19 21:36:13 GMT 2012

Hi Gerd,

in an abstract way that's also a dictionary. Like I wrote I would first 
continue to implement the functionality and improve it afterwards if 
required. Keep it simple :-)

WanMil

> 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
>
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev