LocationHook and tagging ways
Hi list, as discussed before, the current implementation of LocationHook produces somehow unpredictable results when it locates ways that cross boundaries. A correct solution would be to split the way, but according to WanMil this would be very slow. So, with bad luck, we may find a way with 100 points in a boundary that contains only one of them. While thinking about a test for my optimized version I wondered why we put all points of a way into the quadtree, and not only one (e.g. the 1st, the last, or the one in the middle). Using only one point makes the quadtree much smaller and faster, and the result is (almost) as correct as before. I see only one problem: If the way crosses boundaries, one of the boundaries may contain better information (more complete) than the other(s). If we chose the "wrong" point for searching, we may find only the incomplete information. Gerd -- View this message in context: http://gis.638310.n2.nabble.com/LocationHook-and-tagging-ways-tp7167931p7167... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi list,
as discussed before, the current implementation of LocationHook produces somehow unpredictable results when it locates ways that cross boundaries. A correct solution would be to split the way, but according to WanMil this would be very slow.
I think so. But of course it would be good to try that. Maybe it's also possible to differ between a quick mode (the one which is implemented) and an exact mode (splitting ways and shapes at the boundaries).
So, with bad luck, we may find a way with 100 points in a boundary that contains only one of them.
While thinking about a test for my optimized version I wondered why we put all points of a way into the quadtree, and not only one (e.g. the 1st, the last, or the one in the middle). Using only one point makes the quadtree much smaller and faster, and the result is (almost) as correct as before. I see only one problem: If the way crosses boundaries, one of the boundaries may contain better information (more complete) than the other(s). If we chose the "wrong" point for searching, we may find only the incomplete information.
That's the problem. In areas where boundaries are not 100% complete a lot of elements are not assigned. WanMil
Gerd
-- View this message in context: http://gis.638310.n2.nabble.com/LocationHook-and-tagging-ways-tp7167931p7167... 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
Hi WanMil,
Date: Tue, 10 Jan 2012 22:25:29 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] LocationHook and tagging ways
Hi list,
as discussed before, the current implementation of LocationHook produces somehow unpredictable results when it locates ways that cross boundaries. A correct solution would be to split the way, but according to WanMil this would be very slow.
I think so. But of course it would be good to try that. Maybe it's also possible to differ between a quick mode (the one which is implemented) and an exact mode (splitting ways and shapes at the boundaries).
I did not look at this until now, but I agree that it would result in higher quality. We already seem to have a class for that stuff, see AreaClipper which is used in StyledConverter, and LineClipper which is used in ElementSaver. Maybe we just have to move some method calls?
So, with bad luck, we may find a way with 100 points in a boundary that contains only one of them.
While thinking about a test for my optimized version I wondered why we put all points of a way into the quadtree, and not only one (e.g. the 1st, the last, or the one in the middle). Using only one point makes the quadtree much smaller and faster, and the result is (almost) as correct as before. I see only one problem: If the way crosses boundaries, one of the boundaries may contain better information (more complete) than the other(s). If we chose the "wrong" point for searching, we may find only the incomplete information.
That's the problem. In areas where boundaries are not 100% complete a lot of elements are not assigned.
Oh oh! I did not notice that until now. I thought it is a rare case that Node or Way is not found, because I only looked at the final result of LocationHook. I thought I can ignore the few cases where the first point of a way is not found. In fact, for some admin_levels we only have a few boundaries which do not nearly cover the whole bounding box, means, many ways are not found. This means my current implementation is much slower than expected :-(( and I definetly have to change it so that I have all boundary info in my quadtree before starting to seach. The good news is that I now have an idea how that could be done in the BoundaryPreparer. Ciao, Gerd
participants (3)
-
Gerd Petermann -
GerdP
-
WanMil