Hi Gerd, that sounds strange. I think recreating the quadtree would only be benficial if recreating takes less time than removing elements. I wonder if that's the case? I am happy to see new and interesting ideas to improve mkgmap so I am curious for your patch :-) WanMil
Hi WanMil,
okay, I see. By the way: I gave up changing the BoundaryPreparer regarding those admin_level=7 special cases. I got lost in too many complex special cases. So I started again lookin at LocationHook, and I think I found a way to speedup the processing by re-creating the quadtree when the processing of a complete admin_level did not change any element. The new quadtree contains typically < 1000 elements then. I just have to clean the code...
Gerd
Date: Fri, 6 Jan 2012 19:45:58 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Bug in LocationHook?
Gerd,
it is intended. The tag names are used only to retrieve the name from the precompiled boundaries. Loading precompiled boundaries does not care about the getUsedTags() information so it is correct not to add them to this list.
WanMil
WanMil,
LocationHook checks these hard coded tag names: private static final String[] LEVEL2_NAMES = new String[]{"name","name:en","int_name"};
but it doesn't add them in getUsedTags() as long as the user doesn't set them in parameter name-tag-list.
Is this intended?
Ciao, Gerd
-- View this message in context: http://gis.638310.n2.nabble.com/Bug-in-LocationHook-tp7157897p7157897.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev