Include the following patches into trunk -- Patch4 - decrease douglas peucker error
This is the last patch for the series. I'm not really sure if it should be applied. I don't even find out where I got this patch from. I just assumed that someone thought about writing it, and hence it provides some benefit. I really don't know whether this patch improves or degrades the map. Actually mostly wondering on what it is worth:
Okay I found where I got this patch from. Probably not ready for trunk: http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg03653.html On 01.03.2011 20:45, Felix Hartmann wrote:
This is the last patch for the series. I'm not really sure if it should be applied. I don't even find out where I got this patch from. I just assumed that someone thought about writing it, and hence it provides some benefit.
I really don't know whether this patch improves or degrades the map. Actually mostly wondering on what it is worth:
Okay I've done some comparisons between the two approximations. For polygons the old version is much better because the patched version creates bad artifacts. For streets at resolution 23 (if used) to 21 I prefer it too. At resolution 20 I am indifferent and cannot really decide what is better. However from 19 to x the approach as given by the patch is far superior (drawing speed on GPS much higher, actually using the normal DP filter maps become more or less unusable for resolution 16,18 or 19 on etrex). Can someone see how this behaviour could be implemented for lines only from resolution 20 or 19 downwards, while keeping the current approach of the DP filter for the rest?
Okay I've done some comparisons between the two approximations.
For polygons the old version is much better because the patched version creates bad artifacts. For streets at resolution 23 (if used) to 21 I prefer it too. At resolution 20 I am indifferent and cannot really decide what is better. However from 19 to x the approach as given by the patch is far superior (drawing speed on GPS much higher, actually using the normal DP filter maps become more or less unusable for resolution 16,18 or 19 on etrex).
Can someone see how this behaviour could be implemented for lines only from resolution 20 or 19 downwards, while keeping the current approach of the DP filter for the rest?
Thanks for intensively testing my old patches and the propose for them being checked in. Glad to see them work fine and beeing useful. :-) I have looked at this patch again. I think your proposal of switching between them at a given resolution is a good one. This should preserve the accuracy at higher zooms and compress the data at lower zooms. Should be worth a try. I'm sorry, but at the moment I have no toolchain ready for compiling mkgmap and preparing patches. If I find the time, I will look into it the next days. Regards, Johann
On 02.03.2011 20:54, Johann Gail wrote:
Okay I've done some comparisons between the two approximations.
For polygons the old version is much better because the patched version creates bad artifacts. For streets at resolution 23 (if used) to 21 I prefer it too. At resolution 20 I am indifferent and cannot really decide what is better. However from 19 to x the approach as given by the patch is far superior (drawing speed on GPS much higher, actually using the normal DP filter maps become more or less unusable for resolution 16,18 or 19 on etrex).
Can someone see how this behaviour could be implemented for lines only from resolution 20 or 19 downwards, while keeping the current approach of the DP filter for the rest?
Thanks for intensively testing my old patches and the propose for them being checked in. Glad to see them work fine and beeing useful. :-)
I have looked at this patch again. I think your proposal of switching between them at a given resolution is a good one. This should preserve the accuracy at higher zooms and compress the data at lower zooms. Should be worth a try.
I'm sorry, but at the moment I have no toolchain ready for compiling mkgmap and preparing patches. If I find the time, I will look into it the next days.
Okay great. Hope it's not too difficult to change the behaviour to get the best of both. I think actually at resolution 20, the "straight" patched behaviour should already be used for all lines.
Regards, Johann
Okay I've done some comparisons between the two approximations.
For polygons the old version is much better because the patched version creates bad artifacts. For streets at resolution 23 (if used) to 21 I prefer it too. At resolution 20 I am indifferent and cannot really decide what is better. However from 19 to x the approach as given by the patch is far superior (drawing speed on GPS much higher, actually using the normal DP filter maps become more or less unusable for resolution 16,18 or 19 on etrex).
Can someone see how this behaviour could be implemented for lines only from resolution 20 or 19 downwards, while keeping the current approach of the DP filter for the rest?
Thanks for intensively testing my old patches and the propose for them being checked in. Glad to see them work fine and beeing useful. :-)
I have looked at this patch again. I think your proposal of switching between them at a given resolution is a good one. This should preserve the accuracy at higher zooms and compress the data at lower zooms. Should be worth a try.
I'm sorry, but at the moment I have no toolchain ready for compiling mkgmap and preparing patches. If I find the time, I will look into it the next days.
Okay great. Hope it's not too difficult to change the behaviour to get the best of both. I think actually at resolution 20, the "straight" patched behaviour should already be used for all lines. Here is a patch which enables the straightening only at resolution level 20 and below. This is for testing purposes only! :-) Before checking it in, it needs a option to set the resolution at which this behaviour changes. I expect, not all people at the list will find it their taste matched... ;-)
Regards, Johann
Am 03.03.2011 21:54, schrieb Johann Gail:
Okay I've done some comparisons between the two approximations.
For polygons the old version is much better because the patched version creates bad artifacts. For streets at resolution 23 (if used) to 21 I prefer it too. At resolution 20 I am indifferent and cannot really decide what is better. However from 19 to x the approach as given by the patch is far superior (drawing speed on GPS much higher, actually using the normal DP filter maps become more or less unusable for resolution 16,18 or 19 on etrex).
Can someone see how this behaviour could be implemented for lines only from resolution 20 or 19 downwards, while keeping the current approach of the DP filter for the rest?
Thanks for intensively testing my old patches and the propose for them being checked in. Glad to see them work fine and beeing useful. :-)
I have looked at this patch again. I think your proposal of switching between them at a given resolution is a good one. This should preserve the accuracy at higher zooms and compress the data at lower zooms. Should be worth a try.
I'm sorry, but at the moment I have no toolchain ready for compiling mkgmap and preparing patches. If I find the time, I will look into it the next days.
Okay great. Hope it's not too difficult to change the behaviour to get the best of both. I think actually at resolution 20, the "straight" patched behaviour should already be used for all lines. Here is a patch which enables the straightening only at resolution level 20 and below. This is for testing purposes only! :-) Before checking it in, it needs a option to set the resolution at which this behaviour changes. I expect, not all people at the list will find it their taste matched... ;-)
Regards, Johann To tired to remember attaching the patch....
For lines it works perfect. But somehow polygons really get munged and destructed (lots of straight line holes - that are fewer without this patch). Could you check what is going on for polygons? For polygons the old algo should be used, it looks like it would be even worse than the straight line algo has ever been before.
On 03.03.2011 22:37, Felix Hartmann wrote:
For lines it works perfect. But somehow polygons really get munged and destructed (lots of straight line holes - that are fewer without this patch).
Could you check what is going on for polygons? For polygons the old algo should be used, it looks like it would be even worse than the straight line algo has ever been before. Sorry, for my complaint. Polygons are nice up to level 21. But really bad from level 20 down. The new aggressive filter should only be for lines, not for polygons as it does not work well for them. As for lines it does work well though.
Am 03.03.2011 22:56, schrieb Felix Hartmann:
On 03.03.2011 22:37, Felix Hartmann wrote:
For lines it works perfect. But somehow polygons really get munged and destructed (lots of straight line holes - that are fewer without this patch).
Could you check what is going on for polygons? For polygons the old algo should be used, it looks like it would be even worse than the straight line algo has ever been before. Sorry, for my complaint. Polygons are nice up to level 21. But really bad from level 20 down. The new aggressive filter should only be for lines, not for polygons as it does not work well for them. As for lines it does work well though.
No idea, what goes wrong in your case. I didn't expect big differences for polygons at resolutions <=20. In my test cases there I can't see any difference. I have just tested. Polygons looks a bit ugly with or without the recent change. I know, that the dp filter is not really optimal for cleaning up polygons in general. Maybe needs an other approach... Johann
participants (2)
-
Felix Hartmann -
Johann Gail