No. An element can lie only in one admin_level with each number bound (one for admin_level=11,10,9,8,7,etc.). There can be only one bound tagged with postcode. If an admin_level is tagged with a postcode there must be no other bound at the same position tagged with postcode. That means it is sufficient to check for the admin_level. That's tricky but it works if the input data is correct. WanMil
WanMil,
the problem is this: We 1st process all boundaries with postcode-only tag. That's ok. We start processing boundaries that have an admin-level tag. The first boundary that has an admin-level tag but no postcode-tag switches the currLevel from postcode to something starting with mkgmap:admin-level, but we still may have other boundaries that have the postcode tag coming later. So, I think we must first process all boundaries that have a postcode tag.
Gerd
WanMil wrote
Hi Gerd,
I don't see a problem just right now.
The algorithm is as follows: 1. Load the precompiled bounds 2. Sort the bounds in the order 1. all bounds tagged with a postcode tag only 2. all bounds tagged with admin_level=11 3. all bounds tagged with admin_level=10 4. .. 5. all bounds tagged with admin_level=2 3. Go through the bounds and assign all tags and assign the referenced bounds tags also. 4. If an element is tagged with all remaining bounds tags it can be removed from the quadtree.
Now comes the tricky thing: If a boundary with admin_level=4 also has a postcode tag it is ensured that no element without postcode tag is removed from the quadtree. Why? I assume that there must not be two overlapping postcode areas. So tagging admin_level=10 with postcode 12345 and admin_level=9 with postcode 12345 too would be an OSM error. There should be only one postcode area defining the whole area. With this assumption there can be only one bounds tagged with postcode only or one bounds tagged with an admin_level and the postcode. Postcode only bounds are handled first so after that it is only possible that an element lies in an area tagged with admin_level and postcode. So it's sufficient to check that the admin_level is set before removing it from the quadtree.
WanMil
Hi WanMil,
I think the problem is that we sort the boundaries before analysing the lies_in tag. If we first fill the missing zip code tag (and maybe the admin_level tag as well) from the boundaries found in lies_in, we should not see the problem that elements are removed too early. I'm just trying that.
Ciao, Gerd
WanMil wrote
Hi,
WanMil wrote
that sounds strange. I think recreating the quadtree would only be benficial if recreating takes less time than removing elements. I wonder if that's the case?
I think the current quadtree implementation has one problem: As long as it still contains a few elements, a get(...) takes more or less the same time. I guess that's because it still calls a lot of intersect() calculations to return a result. I am still searching for an error which seems to slow down the program too much, but my patch does this: - It keeps the list elemList - If currLevel is changed, it checks if the previous level caused any changes to the elements in the quadTree. If not, the whole elemList is tested, all elements that are fully worked out are removed. If the remaining list is much smaller, the quadtree is replaced.
Sounds reasonable. There might be another solution within the quadtree: At the moments subtrees are not reduced. At an early stage of implementation I did have implemented this but it did not have an advantage. Now the quadtree uses other datastructures which might be easier to reduce. So a node which is not a leaf can be reduced after a successful remove operation if all childs are leafs and the sum of points in the leafs are lower than the maxsize. That should be not too complicted to implement and does not require any special handling in the LocationHook.
I will give it a try within the next days.
WanMil
Ciao, Gerd
-- View this message in context: http://gis.638310.n2.nabble.com/Bug-in-LocationHook-tp7157897p7161772.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- View this message in context: http://gis.638310.n2.nabble.com/Bug-in-LocationHook-tp7157897p7162654.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- View this message in context: http://gis.638310.n2.nabble.com/Bug-in-LocationHook-tp7157897p7164147.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev