logo separator

[mkgmap-dev] [PATCH v1] LocationHook speedup

From WanMil wmgcnfg at web.de on Mon Jan 2 19:59:52 GMT 2012

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




More information about the mkgmap-dev mailing list