[PATCH v2] - round coordinates when zoomed out
v2 - also removes points with the same coordinates as the previous point. I know that this also gets done by the DP filter but it's very easy to do while rounding the coordinates and it does shrink the number of points to be processed by subsequent filters. This version of the patch should produce the same map as v1 of the patch. Unless anyone has any problems with this patch, I intend to commit it in a few days as I think the line gap-filling is worthwhile. ------- Having filled some gaps with that last little patch, I was wondering why I still had quite a few gaps when zoomed out. Obviously, the coords weren't being rounded to nearest given the zoom level. So, the attached patch does that rounding and, lo and behold, even more gaps have disappeared. Please give it a go, especially for maps that cross the equator/day line where the coords flip signs. Sure to be buggy but it's looking quite promising. BTW - this patch does not contain the last patch but they probably should be used together. Mark
Can't notice any difference to v1. BTW - Is it possible that there is a difference with the douglas peucker filter whether a road is routable or not? I think it is possible that non routable ways are smoothed heftier than routable ways. This has nothing to do with this patch though, but the difference only seems to become really visible on resolution <20 (maybe resolution 24 is filtered if not routable, but not filtered if routable. Then the more filtering is applied on each successive level, the bigger the difference). Also I noticed that cgpsmapper maps, seem to have much higher smoothing at lower resolutions compared to mkgmap (using 2.6). At resolution 24 and 22 it seem to be mostly identical though. Maybe we could also increase the douglas peucker severity on resolution <20 compared to right now. Even with very few lines mkgmap maps seem slow on GPS on resolution 16 or 18. Mark Burton wrote:
v2 - also removes points with the same coordinates as the previous point. I know that this also gets done by the DP filter but it's very easy to do while rounding the coordinates and it does shrink the number of points to be processed by subsequent filters. This version of the patch should produce the same map as v1 of the patch.
Unless anyone has any problems with this patch, I intend to commit it in a few days as I think the line gap-filling is worthwhile.
-------
Having filled some gaps with that last little patch, I was wondering why I still had quite a few gaps when zoomed out. Obviously, the coords weren't being rounded to nearest given the zoom level. So, the attached patch does that rounding and, lo and behold, even more gaps have disappeared.
Please give it a go, especially for maps that cross the equator/day line where the coords flip signs. Sure to be buggy but it's looking quite promising.
BTW - this patch does not contain the last patch but they probably should be used together.
Mark
------------------------------------------------------------------------
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Felix,
Can't notice any difference to v1.
OK - thanks.
BTW - Is it possible that there is a difference with the douglas peucker filter whether a road is routable or not?
Yes, looking at the code, it seems that it doesn't change points that are routing nodes so routable ways will be "less smooth" than non-routable ways.
I think it is possible that non routable ways are smoothed heftier than routable ways. This has nothing to do with this patch though, but the difference only seems to become really visible on resolution <20 (maybe resolution 24 is filtered if not routable, but not filtered if routable. Then the more filtering is applied on each successive level, the bigger the difference).
It think the DP filter does nothing at res 24 whether the way is routable or not.
Also I noticed that cgpsmapper maps, seem to have much higher smoothing at lower resolutions compared to mkgmap (using 2.6). At resolution 24 and 22 it seem to be mostly identical though. Maybe we could also increase the douglas peucker severity on resolution <20 compared to right now. Even with very few lines mkgmap maps seem slow on GPS on resolution 16 or 18.
That's worth experimenting with. Perhaps Johann can comment on this, he's the original author of the DP stuff. Cheers, Mark
Mark Burton wrote:
Hi Felix,
Can't notice any difference to v1.
OK - thanks.
BTW - Is it possible that there is a difference with the douglas peucker filter whether a road is routable or not?
Yes, looking at the code, it seems that it doesn't change points that are routing nodes so routable ways will be "less smooth" than non-routable ways.
yeah - the problem is not really one being smoother than the other, but the ways being different. So if I use the multiple_elements_patch only one "line" will be routable, whereas the copies are not routable. As I wan't to display the ways side-by-side the further one zooms out, the more the ways are apart from each other, or overlapping. At resolution 22 this effect is barely noticeable, on 20 it is okay, but on 18 it really gets distracting. Also roads running parallel to rivers often get inside the river because of this. For me in practice on bicycle/mtb/foot this does not matter much because I rarely use resolution 20 or lower, but I assume that for carrouting on a motorway it would be nicer to have all ways "smoothed" the same. Might be a bit difficult to change however I think, because this would need additional calculation time for non routable ways to know which nodes would be routing nodes in case a line is not routable.
I think it is possible that non routable ways are smoothed heftier than routable ways. This has nothing to do with this patch though, but the difference only seems to become really visible on resolution <20 (maybe resolution 24 is filtered if not routable, but not filtered if routable. Then the more filtering is applied on each successive level, the bigger the difference).
It think the DP filter does nothing at res 24 whether the way is routable or not.
Also I noticed that cgpsmapper maps, seem to have much higher smoothing at lower resolutions compared to mkgmap (using 2.6). At resolution 24 and 22 it seem to be mostly identical though. Maybe we could also increase the douglas peucker severity on resolution <20 compared to right now. Even with very few lines mkgmap maps seem slow on GPS on resolution 16 or 18.
That's worth experimenting with.
Perhaps Johann can comment on this, he's the original author of the DP stuff.
Cheers,
Mark _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Felix,
yeah - the problem is not really one being smoother than the other, but the ways being different. So if I use the multiple_elements_patch only one "line" will be routable, whereas the copies are not routable. As I wan't to display the ways side-by-side the further one zooms out, the more the ways are apart from each other, or overlapping. At resolution 22 this effect is barely noticeable, on 20 it is okay, but on 18 it really gets distracting. Also roads running parallel to rivers often get inside the river because of this. For me in practice on bicycle/mtb/foot this does not matter much because I rarely use resolution 20 or lower, but I assume that for carrouting on a motorway it would be nicer to have all ways "smoothed" the same. Might be a bit difficult to change however I think, because this would need additional calculation time for non routable ways to know which nodes would be routing nodes in case a line is not routable.
OK - I understand what you're saying. I have an easy solution for that in mind and will work up a patch to try out. Cheers, Mark
Hi, I'm the coder of the original dp code. Some comments to it:
BTW - Is it possible that there is a difference with the douglas peucker filter whether a road is routable or not?
Yes, looking at the code, it seems that it doesn't change points that are routing nodes so routable ways will be "less smooth" than non-routable ways.
This is true. The reason for it laid in some possible inaccuracies at nodes. Take for example a T-crossing. This means two lines.A straigth (long) one and one ending at the node. In my first attempt the DP algorithm handles all nodes indifferent. But this means, that the long line could be straighened out at this node, whereas the ending line will never move its end point. So the end node laid not on the line. This error could become visible at some resolutions. The only possibility to change this behaviour was to never move a node connecting lines. This would affect all routing lines.
I think it is possible that non routable ways are smoothed heftier than routable ways. This has nothing to do with this patch though, but the difference only seems to become really visible on resolution <20 (maybe resolution 24 is filtered if not routable, but not filtered if routable. Then the more filtering is applied on each successive level, the bigger the difference).
It think the DP filter does nothing at res 24 whether the way is routable or not.
Yes, as far as I can remember, there was some errors with the routing tables, if I enable it at res 24. Also all other filters was disabled at res 24. So I disabled it too.
Also I noticed that cgpsmapper maps, seem to have much higher smoothing at lower resolutions compared to mkgmap (using 2.6). At resolution 24 and 22 it seem to be mostly identical though. Maybe we could also increase the douglas peucker severity on resolution <20 compared to right now. Even with very few lines mkgmap maps seem slow on GPS on resolution 16 or 18.
That's worth experimenting with.
Perhaps Johann can comment on this, he's the original author of the DP stuff.
Yes, at resolution 16 most of the nodes should be allowed to be removable, as the connecting streets disappear at this level. But at the time of writing I had no reasonable idea of how to get this information inside the dp filter. Maybe in the meanwhile this information is available? Regards, Johann
Johann Gail wrote:
Hi,
I'm the coder of the original dp code. Some comments to it:
BTW - Is it possible that there is a difference with the douglas peucker filter whether a road is routable or not?
Yes, looking at the code, it seems that it doesn't change points that are routing nodes so routable ways will be "less smooth" than non-routable ways.
This is true. The reason for it laid in some possible inaccuracies at nodes. Take for example a T-crossing. This means two lines.A straigth (long) one and one ending at the node. In my first attempt the DP algorithm handles all nodes indifferent. But this means, that the long line could be straighened out at this node, whereas the ending line will never move its end point. So the end node laid not on the line. This error could become visible at some resolutions.
The only possibility to change this behaviour was to never move a node connecting lines. This would affect all routing lines.
I think it is possible that non routable ways are smoothed heftier than routable ways. This has nothing to do with this patch though, but the difference only seems to become really visible on resolution <20 (maybe resolution 24 is filtered if not routable, but not filtered if routable. Then the more filtering is applied on each successive level, the bigger the difference).
It think the DP filter does nothing at res 24 whether the way is routable or not.
Yes, as far as I can remember, there was some errors with the routing tables, if I enable it at res 24. Also all other filters was disabled at res 24. So I disabled it too.
Also I noticed that cgpsmapper maps, seem to have much higher smoothing at lower resolutions compared to mkgmap (using 2.6). At resolution 24 and 22 it seem to be mostly identical though. Maybe we could also increase the douglas peucker severity on resolution <20 compared to right now. Even with very few lines mkgmap maps seem slow on GPS on resolution 16 or 18.
That's worth experimenting with.
Perhaps Johann can comment on this, he's the original author of the DP stuff.
Yes, at resolution 16 most of the nodes should be allowed to be removable, as the connecting streets disappear at this level. But at the time of writing I had no reasonable idea of how to get this information inside the dp filter.
I don't think that this really matters. One will only use level 18 or 16 for orienation/map panning. Garmin City Navigator only goes down to 20, then it's already basemap - of course in Mapsource they have a nice filled overview map, which we are really missing. If we had a decent overview map, I would have 18 as last level, as on my GPS I never use level 17 or 16 cause it's too slow to be usable (even though it only has motorways and trunk roads, plus cities more than 1Mio inhabitants or Capitals.). Level 18 already could be much much more smoothed. Have a look at the MalsingFreeMaps - I think their low resolutions are really well done (smoothing as well as level of detail). (though level 22 and 20 is a bit too much information for my taste).
Maybe in the meanwhile this information is available?
Regards, Johann
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
I don't think that this really matters. One will only use level 18 or 16 for orienation/map panning. Garmin City Navigator only goes down to 20, then it's already basemap - of course in Mapsource they have a nice filled overview map, which we are really missing. If we had a decent overview map, I would have 18 as last level, as on my GPS I never use level 17 or 16 cause it's too slow to be usable (even though it only has motorways and trunk roads, plus cities more than 1Mio inhabitants or Capitals.). Level 18 already could be much much more smoothed.
This is one target I wanted to achieve with the dp filter. Smooth out the lines and therfore increase the drawing speed. For the dp filter to work usefull at low zoom levels it is neccessary to have long lines as inputs, i.e. motorways should be as one single line and not as hundreds of segemnts each only 1 km long. This should be achieved by the merge-lines patch. I have not watched, if the patch has made its way into the trunk. I will see after it. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
participants (3)
-
Felix Hartmann -
Johann Gail -
Mark Burton