[mkgmap-dev] [PATCH v1] LocationHook speedup

Mon Jan 2 20:02:31 GMT 2012

Hello WanMil,

okay, I see. This will allow complex calculations. I have to read again how you create that boundary files for europe...

Gerd

> Date: Mon, 2 Jan 2012 20:59:52 +0100
> From: wmgcnfg at web.de
> To: mkgmap-dev at lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] [PATCH v1] LocationHook speedup
> 
> Hi Gerd,
> 
> you have to do this step during the preprocessing. Time used in 
> preprocessing doesn't matter because that have to be performed once only 
> and most of the mkgmap users just download them and never have to run it 
> themselves.
> 
> All other aproaches won't work (I am quite sure ;-)
> 
> WanMil
> 
> > Hello WanMil,
> >
> > OK, I'll first try the effect by hard coding the wanted boundary list.
> > If I really see a big improvement, I know how much complexety the new
> > function can have. My first approach was to use subtract() for the Areas
> > that are in the level=7 boundary, but that it much too slow.
> >
> > Ciao,
> > Gerd
> >
> >
> >  > Date: Mon, 2 Jan 2012 20:40:32 +0100
> >  > From: wmgcnfg at web.de
> >  > To: mkgmap-dev at lists.mkgmap.org.uk
> >  > Subject: Re: [mkgmap-dev] [PATCH v1] LocationHook speedup
> >  >
> >  > Hi Gerd,
> >  >
> >  > good idea! I am not sure if this additional preprocessing information
> >  > has a great effect but it's worth trying that.
> >  >
> >  > Up to now we don't have such a function. The place for such a function
> >  > would be to extend the BoundaryPreparer.workoutBoundaryRelations method.
> >  >
> >  > WanMil
> >  >
> >  > > Hello WanMil,
> >  > >
> >  > > I think I understand now what is so special with these admin_level=7
> >  > > boundaries.
> >  > > They form a collection of admin_level=8 boundaries. So, after working
> >  > > through all admin_level=8 boundaries, the admin_level=7 is also done
> >  > > because the admin_level=8 boundaries have the lies_in tag for them, but
> >  > > LocationHook doesn't recognize that and continues to work through the
> >  > > admin_level=6 boundaries. For each of the level=6 boundaries we
> > retrieve
> >  > > a large number of elements from quadTree, and most of them are already
> >  > > fully worked out.
> >  > > So, if I got this right, we could save a lot of time if we can detect
> >  > > that admin_level=7 should not be added to remainingLevels which would
> >  > > reduce the size of the quadtree earlier.
> >  > > I think we would need a function that determines if a boundary x is
> >  > > completely overlaped by boundaries with a higher admin_level that have
> >  > > the lies_in for x.
> >  > >
> >  > > Does that make sense?
> >  > > Do we have such a function?
> >  > >
> >  > > Gerd
> >  > >
> >  > >
> >  > > > > > >
> >  > > > > > > 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.
> >  > >
> >  > >
> >  > >
> >  > > _______________________________________________
> >  > > 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
> 
> _______________________________________________
> 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/20120102/28783baf/attachment.html 