Suppressing dead-end-checks for parking entrance/exit
Hi, I would like to suppress warnings for oneways leading to or from underground parking when the entrance and exit are not connected by underground lines. One of these two parking sites is using a relation to group the entrance and exit together. 2013/02/26 10:33:43 WARNING (RouteNode): 63240005.osm.pbf: Oneway road (http://www.openstreetmap.org/browse/way/187642343) goes nowhere at http://www.openstreetmap.org/?mlat=60.86977&mlon=26.70146&zoom=17 2013/02/26 10:33:43 WARNING (RouteNode): 63240005.osm.pbf: Oneway road (http://www.openstreetmap.org/browse/way/135634060) comes from nowhere at http://www.openstreetmap.org/?mlat=60.86846&mlon=26.70092&zoom=17 2013/02/26 10:33:43 WARNING (RouteNode): 63240005.osm.pbf: Oneway road (http://www.openstreetmap.org/browse/way/207169562) goes nowhere at http://www.openstreetmap.org/?mlat=60.86960&mlon=26.70261&zoom=17 I tried adding fixme=continue in the points file: resources/styles/default/points Index: resources/styles/default/points =================================================================== --- resources/styles/default/points (revision 2498) +++ resources/styles/default/points (working copy) @@ -79,7 +79,10 @@ amenity=library [0x2c03 resolution 24] amenity=nightclub [0x2d02 resolution 24] amenity=nursing_home [0x2b04 resolution 24] -amenity=parking [0x2f0b resolution 24 default_name 'Parking'] +# Disable dead-end-checks for parking entrance/exit +entrance=* | amenity=parking_exit { add fixme=continue } +amenity=parking | amenity=parking_entrance | parking=* +{add fixme=continue} [0x2f0b resolution 24 default_name 'Parking'] amenity=pharmacy [0x2e05 resolution 24] amenity=place_of_worship [0x2c0b resolution 24] amenity=police [0x3001 resolution 24] It did not suppress the warnings, because the way parser would interpret the original tags for nodes, not processed ones. Any ideas how to resolve this? I do not feel like adding checks for the parking and entrance tags to the way parser. Best regards, Marko
Hi Marko, looking at the source in HighwayHooks.java I think the tag shoud be "fixme" or "FIXME", not "fixme=continue". Does that work? Ciao, Gerd
Date: Tue, 26 Feb 2013 11:17:23 +0200 From: marko.makela@iki.fi To: mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] Suppressing dead-end-checks for parking entrance/exit
Hi,
I would like to suppress warnings for oneways leading to or from underground parking when the entrance and exit are not connected by underground lines. One of these two parking sites is using a relation to group the entrance and exit together.
2013/02/26 10:33:43 WARNING (RouteNode): 63240005.osm.pbf: Oneway road (http://www.openstreetmap.org/browse/way/187642343) goes nowhere at http://www.openstreetmap.org/?mlat=60.86977&mlon=26.70146&zoom=17 2013/02/26 10:33:43 WARNING (RouteNode): 63240005.osm.pbf: Oneway road (http://www.openstreetmap.org/browse/way/135634060) comes from nowhere at http://www.openstreetmap.org/?mlat=60.86846&mlon=26.70092&zoom=17 2013/02/26 10:33:43 WARNING (RouteNode): 63240005.osm.pbf: Oneway road (http://www.openstreetmap.org/browse/way/207169562) goes nowhere at http://www.openstreetmap.org/?mlat=60.86960&mlon=26.70261&zoom=17
I tried adding fixme=continue in the points file:
resources/styles/default/points Index: resources/styles/default/points =================================================================== --- resources/styles/default/points (revision 2498) +++ resources/styles/default/points (working copy) @@ -79,7 +79,10 @@ amenity=library [0x2c03 resolution 24] amenity=nightclub [0x2d02 resolution 24] amenity=nursing_home [0x2b04 resolution 24] -amenity=parking [0x2f0b resolution 24 default_name 'Parking'] +# Disable dead-end-checks for parking entrance/exit +entrance=* | amenity=parking_exit { add fixme=continue } +amenity=parking | amenity=parking_entrance | parking=* +{add fixme=continue} [0x2f0b resolution 24 default_name 'Parking'] amenity=pharmacy [0x2e05 resolution 24] amenity=place_of_worship [0x2c0b resolution 24] amenity=police [0x3001 resolution 24]
It did not suppress the warnings, because the way parser would interpret the original tags for nodes, not processed ones. Any ideas how to resolve this? I do not feel like adding checks for the parking and entrance tags to the way parser.
Best regards,
Marko _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, On Mon, Mar 04, 2013 at 10:47:17AM +0100, Gerd Petermann wrote:
looking at the source in HighwayHooks.java I think the tag shoud be "fixme" or "FIXME", not "fixme=continue".
Does that work?
I wrote the code to suppress the dead-end warnings if one of the oneway endpoints carries a key FIXME or fixme. fixme=continue is key='fixme', value='continue'. It would qualify if it existed in the source data. I routinely suppress warnings by adding fixme=continue to the node, for example when the error cannot be fixed without survey (e.g., recently started highway=construction would not show in aerial images). The problem is that style rules cannot suppress the dead-end warnings by setting a tag on the node. If the 'points' file were able to set tags in the ways (lines or polygons) connected to the points, then that would solve the problem. We could simply set the magic mkgmap:dead-end-checks=false on all ways connected to a point such as an underground or multi-storey parking lot entrance. FWIW, I solved the problem by extrapolating an underground driveway. I also connected it to a footway or stairs that were obviously leading to the parking facility. Marko
Hi Marko,
I wrote the code to suppress the dead-end warnings if one of the oneway endpoints carries a key FIXME or fixme. fixme=continue is key='fixme', value='continue'. It would qualify if it existed in the source data. I routinely suppress warnings by adding fixme=continue to the node, for example when the error cannot be fixed without survey (e.g., recently started highway=construction would not show in aerial images).
okay, got it.
The problem is that style rules cannot suppress the dead-end warnings by setting a tag on the node. If the 'points' file were able to set tags in the ways (lines or polygons) connected to the points, then that would solve the problem. We could simply set the magic mkgmap:dead-end-checks=false on all ways connected to a point such as an underground or multi-storey parking lot entrance.
Hmm, looks easy to me. The points file is used before the lines file, so all nodes are converted before the ways are converted. If I got that right, we have to check all nodes of oneway roads for the fixme tag? This would just mean to move the corresponding code from HighwayHooks to StyledConverter. Do you agree? Gerd
GerdP wrote
The problem is that style rules cannot suppress the dead-end warnings by setting a tag on the node. If the 'points' file were able to set tags in the ways (lines or polygons) connected to the points, then that would solve the problem. We could simply set the magic mkgmap:dead-end-checks=false on all ways connected to a point such as an underground or multi-storey parking lot entrance.
Hmm, looks easy to me. The points file is used before the lines file, so all nodes are converted before the ways are converted. If I got that right, we have to check all nodes of oneway roads for the fixme tag? This would just mean to move the corresponding code from HighwayHooks to StyledConverter. Do you agree?
Sorry, it's not that simple. I mixed nodes with coords. We do also need a new field in the Coord class to carry the information that a node at this coord has the fixme tag. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Suppressing-dead-end-checks-for-parking-entra... Sent from the Mkgmap Development mailing list archive at Nabble.com.
On Sun, Mar 10, 2013 at 01:05:20AM -0800, GerdP wrote:
Sorry, it's not that simple. I mixed nodes with coords. We do also need a new field in the Coord class to carry the information that a node at this coord has the fixme tag.
Your added method StyledConverter.checkFixmeCoords() is checking the FIXME tag in every node of the way, while the old behaviour was to check the end points only. This method could also be static. I would rather keep the mkgmap:dead-end-check option name, to allow style rules to do this kind of stuff: # Disable dead-end-checks for unaccessible oneways highway=* & oneway=yes & (access=private|access=no) {add mkgmap:dead-end-check=false} Best regards, Marko
Hi Marko, Marko Mäkelä wrote
On Sun, Mar 10, 2013 at 01:05:20AM -0800, GerdP wrote:
Sorry, it's not that simple. I mixed nodes with coords. We do also need a new field in the Coord class to carry the information that a node at this coord has the fixme tag.
Your added method StyledConverter.checkFixmeCoords() is checking the FIXME tag in every node of the way, while the old behaviour was to check the end points only. This method could also be static.
I would rather keep the mkgmap:dead-end-check option name, to allow style rules to do this kind of stuff:
# Disable dead-end-checks for unaccessible oneways highway=* & oneway=yes & (access=private|access=no) {add mkgmap:dead-end-check=false}
if you think that we only have to check the end points, I'll change that. Besides that do you think it does what it should? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Suppressing-dead-end-checks-for-parking-entra... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hallo Gerd,
if you think that we only have to check the end points, I'll change that.
Yes, I think that there could be some FIXME in the middle of some long highway=trunk way that has been drawn as two oneways, for example in a junction with another road. We do not want to suppress the dead-end checks too lightly.
Besides that do you think it does what it should?
Yes, it looks good, based on my limited knowledge of the code. I did not test it yet. I guess I will have to introduce some error to finland.osm.pbf to ensure that it does not suppress too much. Best regards, Marko
Hi Marko, attached is version 2 of the patch which checks only first and last node of a road. Please check: I think the code in RouteNode.reportDeadEnds() does not report a dead end oneway if the routeNode contains a normal (twoway) road because both flags noWayOut and noWayIn are set to false in this case. Is this intended? Gerd
Date: Sun, 10 Mar 2013 15:44:26 +0200 From: marko.makela@iki.fi To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Suppressing dead-end-checks for parking entrance/exit
Hallo Gerd,
if you think that we only have to check the end points, I'll change that.
Yes, I think that there could be some FIXME in the middle of some long highway=trunk way that has been drawn as two oneways, for example in a junction with another road. We do not want to suppress the dead-end checks too lightly.
Besides that do you think it does what it should?
Yes, it looks good, based on my limited knowledge of the code. I did not test it yet. I guess I will have to introduce some error to finland.osm.pbf to ensure that it does not suppress too much.
Best regards,
Marko _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, On Mon, Mar 11, 2013 at 08:11:25AM +0100, Gerd Petermann wrote:
attached is version 2 of the patch which checks only first and last node of a road.
Thanks! I finally tested this, and it looked OK with my fabricated data and style file patch, which did { add fixme=yes } to some nodes.
Please check: I think the code in RouteNode.reportDeadEnds() does not report a dead end oneway if the routeNode contains a normal (twoway) road because both flags noWayOut and noWayIn are set to false in this case. Is this intended?
I did not implement the dead-end checks. I believe it was Mark Burton, who no longer is active in the project. Can you draw ASCII art of the situation? For example, using the following legend: = means two-way road
means one-way road | means dead-end
The cases |==== or ====| should not emit any warning; these should be common for highway=residential and highway=service etc. ====>>>>>| should emit a warning 'goes nowhere' ====<<<<<| should emit a warning 'comes from nowhere' ====>>>>>==== no warning ====<<<<<==== no warning This is my reasoning; I did not test the actual behaviour. Which case did you have in mind? Marko
Hi Marko,
On Mon, Mar 11, 2013 at 08:11:25AM +0100, Gerd Petermann wrote:
attached is version 2 of the patch which checks only first and last node of a road.
Thanks! I finally tested this, and it looked OK with my fabricated data and style file patch, which did { add fixme=yes } to some nodes.
Great! Thanks for the feedback.
Please check: I think the code in RouteNode.reportDeadEnds() does not report a dead end oneway if the routeNode contains a normal (twoway) road because both flags noWayOut and noWayIn are set to false in this case. Is this intended?
I did not implement the dead-end checks. I believe it was Mark Burton, who no longer is active in the project. Can you draw ASCII art of the
Sorry for the confusion, seems I read the name marbb as marko.
= means two-way road
means one-way road | means dead-end
The cases |==== or ====| should not emit any warning; these should be common for highway=residential and highway=service etc.
====>>>>>| should emit a warning 'goes nowhere' ====<<<<<| should emit a warning 'comes from nowhere' ====>>>>>==== no warning ====<<<<<==== no warning
This is my reasoning; I did not test the actual behaviour. Which case did you have in mind?
I don't have a picture in mind. I found the problem while testing the patch. I used a download containing both ways and removed one. To my surprise I did not see the expected message from the dead-end check. I added option --report-dead-ends=2 and still got no message. So I looked at the source and found what I reported. I'll have a closer look today. Gerd
Marko _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
GerdP wrote
This is my reasoning; I did not test the actual behaviour. Which case did you have in mind?
I don't have a picture in mind. I found the problem while testing the patch. I used a download containing both ways and removed one. To my surprise
Oops, I mixed that with the check for unconnected roads. I did this: start JOSM download way 187642343 download the area around it delete the way 208398612 to have a dead end oneway again save as deadend.osm GerdP wrote
I did not see the expected message from the dead-end check. I added option --report-dead-ends=2 and still got no message. So I looked at the source and found what I reported. I'll have a closer look today.
OK, here are my findings: 1) The oneway 187642343 is connected to the normal roads 136599044 and 34133276, mkgmap creates two RouteNodes for these connections. 2) In the reportDeadEnds() method the dead-end oneway is ignored because it is connected with the normal road. I consider this to be an error in the method. Do you agree? I wondered why you saw the message, I assume that in your case it lies on a tile boundary? And shouldn't we disable the dead-end-check for ways that lie on such a boundary as well? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Suppressing-dead-end-checks-for-parking-entra... Sent from the Mkgmap Development mailing list archive at Nabble.com.
On Fri, Mar 15, 2013 at 12:25:08AM -0700, GerdP wrote:
I did this: start JOSM download way 187642343 download the area around it delete the way 208398612 to have a dead end oneway again save as deadend.osm
OK, it is not dead-end for everyone, because the highway=pedestrian area (plaza) 35826685 is connected to the driveway. We may route pedestrians on the edges of the highway=pedestrian area. We might route bicycles too (AFAIU, it is allowed in Finland with maxspeed=20, but not allowed in Germany). It is the same thing if you had a oneway highway=service that ends in a path or steps. It is not dead-end for pedestrians, but would be a dead-end for cars. I wrote some months ago about a possible project to highlight dead-ends on the map, but nobody replied. I think it should be a set of 'dead-end layers', one for each mode of routing. Then you could easily survey all those nearby suspectable cases when going for a walk or a bicycle trip. Pedestrians can use steps, cannot legally use highway=cycleway. For bicycles it is vice versa. Both can use paths and most ways except motorways. Cars can use all ways except those meant for bicycles and pedestrians. There are really multiple routing graphs to consider if you want to check for dead-ends properly. Marko
Hi Marko,
OK, it is not dead-end for everyone, because the highway=pedestrian area (plaza) 35826685 is connected to the driveway. We may route pedestrians on the edges of the highway=pedestrian area. We might route bicycles too (AFAIU, it is allowed in Finland with maxspeed=20, but not allowed in Germany).
It is the same thing if you had a oneway highway=service that ends in a path or steps. It is not dead-end for pedestrians, but would be a dead-end for cars.
I wrote some months ago about a possible project to highlight dead-ends on the map, but nobody replied. I think it should be a set of 'dead-end layers', one for each mode of routing. Then you could easily survey all those nearby suspectable cases when going for a walk or a bicycle trip.
Pedestrians can use steps, cannot legally use highway=cycleway. For bicycles it is vice versa. Both can use paths and most ways except motorways. Cars can use all ways except those meant for bicycles and pedestrians. There are really multiple routing graphs to consider if you want to check for dead-ends properly.
I agree that it would be better to check each road network separately, but I don't think that mkgmap is the right program for this. Maybe you can use different styles for that? On the other hand, I think the dead end check that is implemented now is incorrect because it doesn't report all "individual oneway roads that go nowhere" as documented. I did not find a simple way to fix that in the existing routine, but it can be done in the StyledConverter, because it is very similar to the check for unconnected roads implemented with r2530. Gerd
Hi Gerd,
I wrote some months ago about a possible project to highlight dead-ends on the map, but nobody replied. I think it should be a set of 'dead-end layers', one for each mode of routing. Then you could easily survey all those nearby suspectable cases when going for a walk or a bicycle trip.
Pedestrians can use steps, cannot legally use highway=cycleway. For bicycles it is vice versa. Both can use paths and most ways except motorways. Cars can use all ways except those meant for bicycles and pedestrians. There are really multiple routing graphs to consider if you want to check for dead-ends properly.
I agree that it would be better to check each road network separately, but I don't think that mkgmap is the right program for this. Maybe you can use different styles for that?
Yes, I guess it would call for a separate preprocessor tool. It is a bit like programming language compilers and static analysis tools. Compilers can generate warnings for some things, especially when you crank up the optimization level, but their main purpose is to translate the code, not to find all errors. The same goes for mkgmap; it can only detect 'easy' errors as a byproduct of the map-making. In this case, it can detect easy cases of unconnected roads or dead-end oneways, but it cannot possibly analyze the full routing graph.
On the other hand, I think the dead end check that is implemented now is incorrect because it doesn't report all "individual oneway roads that go nowhere" as documented.
I did not find a simple way to fix that in the existing routine, but it can be done in the StyledConverter, because it is very similar to the check for unconnected roads implemented with r2530.
I think that a stand-alone routing graph analysis tool could be useful, for flagging dead ends, computing routing islands, and computing strongly connected components in the routing graph (to flag 'trap' areas, which you can only enter but not exit, or vice versa). It might even consider turn restrictions. (I do not think that we currently complain about a T crossing where the vertical line of the T is an oneway pointing down, and there are turn restrictions from both arms of the T, prohibiting a turn to the downward-pointing way.) The tool would input the OSM data and a list of way tags that are to be considered when building the routing graph. The oneway tag would not be hardwired; it could be dropped for pedestrians, for example. I think that the 'routing style language' could be a subset of the mkgmap style language. Based on the tool output, the map translation toolchain could add new pseudo tags, such as routing:bicycle=deadend or routing:motorcar:island=1, which could then be highlighted by custom map translation or rendering styles. This would not be limited to mkgmap; it could also be used for (say) OsmAndMapCreator, or for visualization in JOSM. Marko
Hi Marko, I don't think this would be a prepro. It's the style system that decides what ways are routable or not, so if one wants to analyse the routing graph he has to read the img file created by mkgmap. The display tool already provides most of that functionality. Gerd
Date: Sat, 16 Mar 2013 22:44:12 +0200 From: marko.makela@iki.fi To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Routing graph analysis
Hi Gerd,
I wrote some months ago about a possible project to highlight dead-ends on the map, but nobody replied. I think it should be a set of 'dead-end layers', one for each mode of routing. Then you could easily survey all those nearby suspectable cases when going for a walk or a bicycle trip.
Pedestrians can use steps, cannot legally use highway=cycleway. For bicycles it is vice versa. Both can use paths and most ways except motorways. Cars can use all ways except those meant for bicycles and pedestrians. There are really multiple routing graphs to consider if you want to check for dead-ends properly.
I agree that it would be better to check each road network separately, but I don't think that mkgmap is the right program for this. Maybe you can use different styles for that?
Yes, I guess it would call for a separate preprocessor tool.
It is a bit like programming language compilers and static analysis tools. Compilers can generate warnings for some things, especially when you crank up the optimization level, but their main purpose is to translate the code, not to find all errors.
The same goes for mkgmap; it can only detect 'easy' errors as a byproduct of the map-making. In this case, it can detect easy cases of unconnected roads or dead-end oneways, but it cannot possibly analyze the full routing graph.
On the other hand, I think the dead end check that is implemented now is incorrect because it doesn't report all "individual oneway roads that go nowhere" as documented.
I did not find a simple way to fix that in the existing routine, but it can be done in the StyledConverter, because it is very similar to the check for unconnected roads implemented with r2530.
I think that a stand-alone routing graph analysis tool could be useful, for flagging dead ends, computing routing islands, and computing strongly connected components in the routing graph (to flag 'trap' areas, which you can only enter but not exit, or vice versa). It might even consider turn restrictions. (I do not think that we currently complain about a T crossing where the vertical line of the T is an oneway pointing down, and there are turn restrictions from both arms of the T, prohibiting a turn to the downward-pointing way.)
The tool would input the OSM data and a list of way tags that are to be considered when building the routing graph. The oneway tag would not be hardwired; it could be dropped for pedestrians, for example. I think that the 'routing style language' could be a subset of the mkgmap style language.
Based on the tool output, the map translation toolchain could add new pseudo tags, such as routing:bicycle=deadend or routing:motorcar:island=1, which could then be highlighted by custom map translation or rendering styles. This would not be limited to mkgmap; it could also be used for (say) OsmAndMapCreator, or for visualization in JOSM.
Marko _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, On Tue, Mar 19, 2013 at 10:52:23AM +0100, Gerd Petermann wrote:
I don't think this would be a prepro. It's the style system that decides what ways are routable or not, so if one wants to analyse the routing graph he has to read the img file created by mkgmap. The display tool already provides most of that functionality.
What I had in mind would be to create a map layer that highlights dead-end streets or routing islands or similar. It would have to process the mkgmap routing graph(s) [one per mode of transportation] from the 'main' map .img and then generate the extra layer(s) [car dead-ends, bicycle dead-ends, pedestrian dead-ends, etc.]. Marko
Hallo Herr Samadi, ich hoffe, Ihnen geht es wieder besser. Machen Sie bitte neue Terminvorschläge. mfg Gerd Petermann
Date: Fri, 15 Mar 2013 00:05:00 +0200 From: marko.makela@iki.fi To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Suppressing dead-end-checks for parking entrance/exit
Hi Gerd,
On Mon, Mar 11, 2013 at 08:11:25AM +0100, Gerd Petermann wrote:
attached is version 2 of the patch which checks only first and last node of a road.
Thanks! I finally tested this, and it looked OK with my fabricated data and style file patch, which did { add fixme=yes } to some nodes.
Please check: I think the code in RouteNode.reportDeadEnds() does not report a dead end oneway if the routeNode contains a normal (twoway) road because both flags noWayOut and noWayIn are set to false in this case. Is this intended?
I did not implement the dead-end checks. I believe it was Mark Burton, who no longer is active in the project. Can you draw ASCII art of the situation? For example, using the following legend:
= means two-way road
means one-way road | means dead-end
The cases |==== or ====| should not emit any warning; these should be common for highway=residential and highway=service etc.
====>>>>>| should emit a warning 'goes nowhere' ====<<<<<| should emit a warning 'comes from nowhere' ====>>>>>==== no warning ====<<<<<==== no warning
This is my reasoning; I did not test the actual behaviour. Which case did you have in mind?
Marko _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (3)
-
Gerd Petermann -
GerdP
-
Marko Mäkelä