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