logo separator

[mkgmap-dev] [PATCH v1] LocationHook speedup

From WanMil wmgcnfg at web.de on Mon Jan 2 19:40:32 GMT 2012

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




More information about the mkgmap-dev mailing list