Hi, I am trying to find a better algo for the handling of short arcs. (Garmins routing algo refuses to route over short arcs) The typical case of a short arc is a crossing like here: http://www.openstreetmap.org/browse/node/1449682318 We don't lose much information if we merge the node with node 1303933872, so merging is a good idea here. On the other hand I stumbled across a few cases were I am not sure what to do. I many cases I'd prefer to move one of the two nodes so that the arc gets longer. See e.g. http://www.openstreetmap.org/browse/way/47138169 The first two points of the way build a short arc (2.8 m), while the next arc to point 267185122 is > 33m. The merging of these two nodes will produce a map which implies that you can turn right directly at the end of the bridge http://www.openstreetmap.org/browse/way/47138168 I think it would be better to move the node 627157116 a little bit closer to the next point 267185122. A similar case: The bridge at http://www.openstreetmap.org/browse/way/131860005 has a length of ~ 4.99 m. With the default value 5m, this is considered to be a short arc and short-arc-removal will remove the bridge by merging the two end points. On the other hand, a (service) road with just two points, one point connected to a road, the other not connected to a road should be removed if it is a short arc instead of eventually moving the point connected to the road (as this produces the zig zag lines as posted by popej (road.png): http://gis.19327.n5.nabble.com/Distorted-lines-tp5775761.html (this one is easy to detect and I can create a simple patch) I don't know yet how to implement all this, so I'd like to make sure that I am not investing much time into a wrong solution. Comments? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/special-cases-with-short-arcs-tp5778708.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi, I'm doing similar processing for cgpsmapper. My algorithm is following: First I try to remove very short lines. I don't remove lines which are a part of roundabout, restriction or road sign. I check ending nodes of short lines and don't remove lines if any node is external (on tile boundary). I merge nodes and move them to the middle of removed line. But if a node connects to multiple short lines, I leave it at original position (this is mostly to preserve integrity of network). Then I try to extend remaining short lines. I move both ending nodes unless one of them connects to multiple short lines. I'm working with floating points coordinates but I round coordinates to 24-bit equivalent to calculate length. I remove only the shortest lines, where difference between ending coordinates is no longer than 1-bit in 24-bit range. I simply hope there won't be problems like removing whole bridge. I don't know what is real Garmin condition for short line. Cgpsmapper uses distance 2.4m. I would rather expect that condition is based on 24-bit coordinate grid. Would be good to know precisely, when line is too short, this would minimize the number of changes. -- Best regards, Andrzej
Hi Andrzej, thanks for the hints. I just wonder if anybody ever tried to use a very simple trick: If I remember correctly, we calculate and write the arc length to the img file. What happens if we just make sure to write the minimum length (e.g. 3.5m), no matter how short the arc really is? Gerd popej wrote
Hi,
I'm doing similar processing for cgpsmapper. My algorithm is following:
First I try to remove very short lines. I don't remove lines which are a part of roundabout, restriction or road sign. I check ending nodes of short lines and don't remove lines if any node is external (on tile boundary).
I merge nodes and move them to the middle of removed line. But if a node connects to multiple short lines, I leave it at original position (this is mostly to preserve integrity of network).
Then I try to extend remaining short lines. I move both ending nodes unless one of them connects to multiple short lines.
I'm working with floating points coordinates but I round coordinates to 24-bit equivalent to calculate length. I remove only the shortest lines, where difference between ending coordinates is no longer than 1-bit in 24-bit range. I simply hope there won't be problems like removing whole bridge.
I don't know what is real Garmin condition for short line. Cgpsmapper uses distance 2.4m. I would rather expect that condition is based on 24-bit coordinate grid. Would be good to know precisely, when line is too short, this would minimize the number of changes.
-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/special-cases-with-short-arcs-tp5778708p57788... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Good idea! It is also possible that the --process-exits and --process-destination options might create several ways with short arcs. I should change it so that both options do not create ways shorter than the shortest allowed arc. WanMil
Hi Andrzej,
thanks for the hints. I just wonder if anybody ever tried to use a very simple trick: If I remember correctly, we calculate and write the arc length to the img file. What happens if we just make sure to write the minimum length (e.g. 3.5m), no matter how short the arc really is?
Gerd
popej wrote
Hi,
I'm doing similar processing for cgpsmapper. My algorithm is following:
First I try to remove very short lines. I don't remove lines which are a part of roundabout, restriction or road sign. I check ending nodes of short lines and don't remove lines if any node is external (on tile boundary).
I merge nodes and move them to the middle of removed line. But if a node connects to multiple short lines, I leave it at original position (this is mostly to preserve integrity of network).
Then I try to extend remaining short lines. I move both ending nodes unless one of them connects to multiple short lines.
I'm working with floating points coordinates but I round coordinates to 24-bit equivalent to calculate length. I remove only the shortest lines, where difference between ending coordinates is no longer than 1-bit in 24-bit range. I simply hope there won't be problems like removing whole bridge.
I don't know what is real Garmin condition for short line. Cgpsmapper uses distance 2.4m. I would rather expect that condition is based on 24-bit coordinate grid. Would be good to know precisely, when line is too short, this would minimize the number of changes.
-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/special-cases-with-short-arcs-tp5778708p57788... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi, GerdP wrote
I just wonder if anybody ever tried to use a very simple trick: If I remember correctly, we calculate and write the arc length to the img file. What happens if we just make sure to write the minimum length (e.g. 3.5m), no matter how short the arc really is?
I tried it, but without success. A routing error caused by a short arc doesn't disappear if I just manipulate the saved length in RouteArc.java. It seems that the saved value is used for something else. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/special-cases-with-short-arcs-tp5778708p57789... Sent from the Mkgmap Development mailing list archive at Nabble.com.
I still have the problem that short arcs look good on resolution 24 but not at res 22. Maybe you can keep an eye on this issue while redoing the short arc handling.
Hi, I think these problems are not related to short arcs. Please try smaller values for the reduce-* options. Gerd From: rheinskipper1000@gmx.de To: mkgmap-dev@lists.mkgmap.org.uk Date: Wed, 25 Sep 2013 09:46:44 +0200 Subject: Re: [mkgmap-dev] special cases with short arcs I still have the problem that short arcs look good on resolution 24 but not at res 22. Maybe you can keep an eye on this issue while redoing the short arc handling. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
The screenshots were done with: reduce-point-density=1 reduce-point-density-polygon=1 Von: mkgmap-dev-bounces@lists.mkgmap.org.uk [mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk] Im Auftrag von Gerd Petermann Gesendet: Mittwoch, 25. September 2013 09:51 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] special cases with short arcs Hi, I think these problems are not related to short arcs. Please try smaller values for the reduce-* options. Gerd From: rheinskipper1000@gmx.de To: mkgmap-dev@lists.mkgmap.org.uk Date: Wed, 25 Sep 2013 09:46:44 +0200 Subject: Re: [mkgmap-dev] special cases with short arcs I still have the problem that short arcs look good on resolution 24 but not at res 22. Maybe you can keep an eye on this issue while redoing the short arc handling. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi, okay, so what exactly would you like to see if you reduce the resolution? I am not sure about the absolute values, but I think res 22 uses something like a 10m grid. If you zoom such a picture to the same size it cannot show a circle as perfect as a grid with ~ 2.5m. Gerd From: rheinskipper1000@gmx.de To: mkgmap-dev@lists.mkgmap.org.uk Date: Wed, 25 Sep 2013 10:15:52 +0200 Subject: Re: [mkgmap-dev] special cases with short arcs The screenshots were done with: reduce-point-density=1reduce-point-density-polygon=1 Von: mkgmap-dev-bounces@lists.mkgmap.org.uk [mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk] Im Auftrag von Gerd Petermann Gesendet: Mittwoch, 25. September 2013 09:51 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] special cases with short arcs Hi, I think these problems are not related to short arcs. Please try smaller values for the reduce-* options. GerdFrom: rheinskipper1000@gmx.de To: mkgmap-dev@lists.mkgmap.org.uk Date: Wed, 25 Sep 2013 09:46:44 +0200 Subject: Re: [mkgmap-dev] special cases with short arcsI still have the problem that short arcs look good on resolution 24 but not at res 22. Maybe you can keep an eye on this issue while redoing the short arc handling. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
My intention is having a zoom level that shows buildings in good quality but without being jammed by POIs. So I try to render buildings earlier (e.g. res 22) than POIs (which I want to show up at max zoom only). Von: mkgmap-dev-bounces@lists.mkgmap.org.uk [mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk] Im Auftrag von Gerd Petermann Gesendet: Mittwoch, 25. September 2013 10:32 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] special cases with short arcs Hi, okay, so what exactly would you like to see if you reduce the resolution? I am not sure about the absolute values, but I think res 22 uses something like a 10m grid. If you zoom such a picture to the same size it cannot show a circle as perfect as a grid with ~ 2.5m. Gerd _____ From: <mailto:rheinskipper1000@gmx.de> rheinskipper1000@gmx.de To: <mailto:mkgmap-dev@lists.mkgmap.org.uk> mkgmap-dev@lists.mkgmap.org.uk Date: Wed, 25 Sep 2013 10:15:52 +0200 Subject: Re: [mkgmap-dev] special cases with short arcs The screenshots were done with: reduce-point-density=1 reduce-point-density-polygon=1 Von: mkgmap-dev-bounces@lists.mkgmap.org.uk [mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk] Im Auftrag von Gerd Petermann Gesendet: Mittwoch, 25. September 2013 09:51 An: <mailto:mkgmap-dev@lists.mkgmap.org.uk> mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] special cases with short arcs Hi, I think these problems are not related to short arcs. Please try smaller values for the reduce-* options. Gerd From: rheinskipper1000@gmx.de To: mkgmap-dev@lists.mkgmap.org.uk Date: Wed, 25 Sep 2013 09:46:44 +0200 Subject: Re: [mkgmap-dev] special cases with short arcs I still have the problem that short arcs look good on resolution 24 but not at res 22. Maybe you can keep an eye on this issue while redoing the short arc handling. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list <mailto:mkgmap-dev@lists.mkgmap.org.uk> mkgmap-dev@lists.mkgmap.org.uk <http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi, okay, I am not a style expert, but you may try to render buildings only at res 23. Gerd RheinSkipper wrote
My intention is having a zoom level that shows buildings in good quality but without being jammed by POIs.
So I try to render buildings earlier (e.g. res 22) than POIs (which I want to show up at max zoom only).
Von:
mkgmap-dev-bounces@.org
[mailto:
mkgmap-dev-bounces@.org
] Im Auftrag von Gerd Petermann Gesendet: Mittwoch, 25. September 2013 10:32 An:
mkgmap-dev@.org
Betreff: Re: [mkgmap-dev] special cases with short arcs
Hi,
okay, so what exactly would you like to see if you reduce the resolution? I am not sure about the absolute values, but I think res 22 uses something like a 10m grid. If you zoom such a picture to the same size it cannot show a circle as perfect as a grid with ~ 2.5m.
Gerd
_____
From: <mailto:
rheinskipper1000@
>
rheinskipper1000@
To: <mailto:
mkgmap-dev@.org
>
mkgmap-dev@.org
Date: Wed, 25 Sep 2013 10:15:52 +0200 Subject: Re: [mkgmap-dev] special cases with short arcs
The screenshots were done with:
reduce-point-density=1
reduce-point-density-polygon=1
Von:
mkgmap-dev-bounces@.org
[mailto:
mkgmap-dev-bounces@.org
] Im Auftrag von Gerd Petermann Gesendet: Mittwoch, 25. September 2013 09:51 An: <mailto:
mkgmap-dev@.org
>
mkgmap-dev@.org
Betreff: Re: [mkgmap-dev] special cases with short arcs
Hi,
I think these problems are not related to short arcs. Please try smaller values for the reduce-* options.
Gerd
From:
rheinskipper1000@
To:
mkgmap-dev@.org
Date: Wed, 25 Sep 2013 09:46:44 +0200 Subject: Re: [mkgmap-dev] special cases with short arcs
I still have the problem that short arcs look good on resolution 24 but not at res 22.
Maybe you can keep an eye on this issue while redoing the short arc handling.
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list <mailto:
mkgmap-dev@.org
>
mkgmap-dev@.org
<http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev>; http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/special-cases-with-short-arcs-tp5778708p57789... Sent from the Mkgmap Development mailing list archive at Nabble.com.
participants (5)
-
Andrzej Popowski -
Gerd Petermann -
GerdP
-
RheinSkipper -
WanMil