[mkgmap-dev] [PATCH v1] LocationHook speedup

Sat Dec 31 14:16:49 GMT 2011

Puuuh, but it's also a pity because that would have been an easy 
improvement ;-)


> Hi WanMil,
>
> sorry, you are right. I must have looked at availableLevels instead of
> remainingLevels :-(
>
> ciao,
> Gerd
>
>  > Date: Sat, 31 Dec 2011 15:09:03 +0100
>  > From: wmgcnfg at web.de
>  > To: mkgmap-dev at lists.mkgmap.org.uk
>  > Subject: Re: [mkgmap-dev] [PATCH v1] LocationHook speedup
>  >
>  > Am 31.12.2011 15:04, schrieb Gerd Petermann:
>  > > Hi WanMil,
>  > >
>  > >
>  > > > Date: Sat, 31 Dec 2011 14:55:08 +0100
>  > > > From: wmgcnfg at web.de
>  > > > To: mkgmap-dev at 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 at lists.mkgmap.org.uk
>  > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>  >
>  > _______________________________________________
>  > mkgmap-dev mailing list
>  > mkgmap-dev at lists.mkgmap.org.uk
>  > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev