Hi WanMil,
> Date: Sat, 31 Dec 2011 14:55:08 +0100 > From: wmgc...@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. > > > > > 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
