Hi WanMil, 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