[mkgmap-dev] [PATCH v1] LocationHook speedup
From Gerd Petermann gpetermann_muenchen at hotmail.com on Mon Jan 2 10:24:07 GMT 2012
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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20120102/06474f8e/attachment.html
- Previous message: [mkgmap-dev] [PATCH] LocationHook performance
- Next message: [mkgmap-dev] [PATCH v1] LocationHook speedup
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list