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

Fri Jan 13 17:11:29 GMT 2012

Hi WanMil,

 Date: Fri, 13 Jan 2012 17:03:58 +0100
> From: wmgcnfg at web.de
> To: mkgmap-dev at lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] [Patch v3] LocationHook with new Quadtree
> 
> 
> >
> >  >
> >  > Also note that admin_level=1 is not used in OSM. So you can remove that
> >  > either.
> > Ok, I did not know this. Anyway, admLevel-2 is a bit too confusing in my
> > eyes.
> 
> I wonder a bit: You try to remove as much as possible but leave the 
> admin_level=1 tag which is definetly never used? In the end the array 
> with tags must be well known at any place when mapping the original 
> admin_level/postcode to the tags in the array.
> 
> I think the array can be removed completely. It seems to confuse more 
> than it helps in the LocationHook. It is used in the BoundaryQuadTree 
> but it could be easily created just before calling the constructor.

I did not think too much about that. I just found the original HashSet too confusing.
The array was needed in an interims solution, and I used it also for printing debugging info.
The content of the array is no longer performance critical. 
I also thought about placing it only in the quadtree source, what do you think about that?

> 
> >
> > By the way: I thought very long about the idea of the HashTable mkgmapTags
> > in the trunk version. I guess it was used to allow easy removing of
> > selected admin_levels or postal_code from processing ?
> >
> 
> The original idea was that multiple tags might be used to map to the 
> mkgmap internal tags. So not only admin_level=2 could map to 
> mkgmap:admin_level2. But that was a nice idea which was never used. 
> Maybe postal code tagging will require such a n:1 mapping because that 
> tagging is not very consistent.

OK, that's understood. Maybe most of the code in LocationHook can 
be moved to BoundaryPreparer, but none of it is performance critical.

Ciao,
Gerd

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