[mkgmap-dev] [PATCH v1] LocationHook speedup

Sat Dec 31 14:13:31 GMT 2011

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20111231/1e34641f/attachment.html 