Date: Fri, 13 Jan 2012 17:03:58 +0100
> From: wmgcnfg@web.de
> To: mkgmap-dev@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