Am 31.12.2011 15:04, schrieb Gerd Petermann:
Hi WanMil,
Date: Sat, 31 Dec 2011 14:55:08 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [PATCH v1] LocationHook speedup
Am 31.12.2011 14:51, schrieb Gerd Petermann:
Hello WanMil,
admin_level=7 just an example. admin_levels are used differently in countries and in regions etc.
I see "Verbandsgemeinde Waldmohr" http://www.openstreetmap.org/browse/relation/897709 which is the only boundary that has admin_level=7. The interesting thing is: the returned result-list for this boundary is always empty. So, maybe there is a cheaper way to detect this first or does it means that there is a bug in quadtree or the selection of the boundaries?
Sounds more like a bug! But it's also possible that the higher admin_levels (8,9,10,11) references all other admin_levels and therefore there all elements of Waldmohr have been removed before querying for it.
hmm, I think you missed the point that we start with lower admin_levels: // Reverse the sorting because we want to start with the lowest admin level Collections.reverse(boundaries);
No, I didn't. I should have better written admin_levels (11,10,9,8) but the meaning is the same. No, not really. We check 2,4,5,6 first.
That would be a bug. But I am very sure that the algorithm starts with admin_level 11. The BoundaryLevelCollator sorts the bounds with admin_level=2 first but then the bounds are reversed. Can you please check if I am wrong? That's important!
and I found Waldmohr because it prevented the elements from being
"fully
worked out".
Sounds reasonable. But then querying for Waldmohr should have returned some elements, shouldn't it? No, all elements are kept in the quadtree because they are not "fully worked out" until this admin_level=7 part is done, or to be more precise, until they are processed for admin_level=8 or higher, because for admin_level=7 nothing is changed in this special case.
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev