[mkgmap-dev] [PATCH v1] LocationHook speedup

Mon Jan 2 20:27:36 GMT 2012

Gerd,

attached BoundaryLister is a useful util when working with bounds. It 
lists the tags of all bounds in the preprocessed bounds files. Just give 
the bounds dir as parameter and the BoundaryLister creates a bounds.txt 
file containing all the information.

WanMil

> 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
>
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: boundarylister_v1.patch
Type: text/x-patch
Size: 1101 bytes
Desc: not available
Url : http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20120102/00ab9221/attachment.bin 