Problem with turn restriction
Hi, attached test file shows a problem with turn restrictions defined on very short streets that are removed by mkgmap. When routing from the parking space in the west to the parking space in the north the route should go over the oneway in the south. But because the turn restriction at the end of street 1 has a very short to-way the turn restriction is removed by mkgmap. @Gerd: do you see any chance to fix that so that the turn restriction is not removed? (I have not tested the high precision branch). WanMil
Hi WanMil, the branch tries harder to avoid that such a small road is removed, e.g. in some cases the way is made a bit longer, but it still might happen that it is removed. I see a similar problem when this short way e.g. a highway=steps. Anyhow, the branch has another problem with your example, it seems to remove a way segment from way with name "Should use this way" , the one goes from to the south - eastern boundary. When I add a small forest so that the way is not on a boundary all looks good, the short way is not removed, and MapSource routes the way you want it. So, I will first check where the way segement gets lost. Gerd Date: Sun, 2 Feb 2014 23:08:13 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] Problem with turn restriction Hi, attached test file shows a problem with turn restrictions defined on very short streets that are removed by mkgmap. When routing from the parking space in the west to the parking space in the north the route should go over the oneway in the south. But because the turn restriction at the end of street 1 has a very short to-way the turn restriction is removed by mkgmap. @Gerd: do you see any chance to fix that so that the turn restriction is not removed? (I have not tested the high precision branch). WanMil _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi, GerdP wrote
So, I will first check where the way segement gets lost.
well, this is quite special, and I am not sure where to fix it. The input file contains no bbox, so mkgmap calculates it (using 24 bit resolution). Later, the way -47698 is clipped against this bbox using high precision, and in high prec two points are outside of the calculated bbox. In r3001 I'v fixed that by enlarging the calculated bbox, but I still have to check that this also works when the bbox is calculated by the tile splitter. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Problem-with-turn-restriction-tp5795049p57950... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi,
GerdP wrote
So, I will first check where the way segement gets lost.
well, this is quite special, and I am not sure where to fix it.
The input file contains no bbox, so mkgmap calculates it (using 24 bit resolution). Later, the way -47698 is clipped against this bbox using high precision, and in high prec two points are outside of the calculated bbox.
In r3001 I'v fixed that by enlarging the calculated bbox, but I still have to check that this also works when the bbox is calculated by the tile splitter.
Gerd
Hi Gerd, uups, I wanted to add bounds information but obviously I missed that and you got and unintended second test case ;-) I am thinking how to fix the problem with the very short way and the relation. Do you think it is possible to detect that the short way consists of two points with identical Garmin coords. In this case it might be possible to change the restriction in such a way that the ways connected to the short way are used in the restriction instead. I want to make a small statistic why restriction relations become invalid. Maybe the problem is so seldom that it's not worthy... WanMil
Hi WanMil, in the branch the problem occurs if the way is so short that the two end points are highPrecEqual(). This is very unlikely, as we talk about <= 4 cm here. The problem probably only occurs with ways close to the tile boundary that are clipped. I don't know if we can save a route restriction when the to-node or from-node lies outside of the boundary. Gerd
Date: Mon, 3 Feb 2014 18:35:27 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Problem with turn restriction
Hi,
GerdP wrote
So, I will first check where the way segement gets lost.
well, this is quite special, and I am not sure where to fix it.
The input file contains no bbox, so mkgmap calculates it (using 24 bit resolution). Later, the way -47698 is clipped against this bbox using high precision, and in high prec two points are outside of the calculated bbox.
In r3001 I'v fixed that by enlarging the calculated bbox, but I still have to check that this also works when the bbox is calculated by the tile splitter.
Gerd
Hi Gerd,
uups, I wanted to add bounds information but obviously I missed that and you got and unintended second test case ;-)
I am thinking how to fix the problem with the very short way and the relation. Do you think it is possible to detect that the short way consists of two points with identical Garmin coords. In this case it might be possible to change the restriction in such a way that the ways connected to the short way are used in the restriction instead.
I want to make a small statistic why restriction relations become invalid. Maybe the problem is so seldom that it's not worthy...
WanMil
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd,
Hi WanMil,
in the branch the problem occurs if the way is so short that the two end points are highPrecEqual(). This is very unlikely, as we talk about <= 4 cm here.
Sounds great!
The problem probably only occurs with ways close to the tile boundary that are clipped. I don't know if we can save a route restriction when the to-node or from-node lies outside of the boundary.
Would it solve the problem if the boundary nodes are added earlier just before the RestrictionRelation.addRestriction(MapCollector) is called? WanMil
Gerd
Date: Mon, 3 Feb 2014 18:35:27 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Problem with turn restriction
Hi,
GerdP wrote
So, I will first check where the way segement gets lost.
well, this is quite special, and I am not sure where to fix it.
The input file contains no bbox, so mkgmap calculates it (using 24 bit resolution). Later, the way -47698 is clipped against this bbox using high precision, and in high prec two points are outside of the calculated bbox.
In r3001 I'v fixed that by enlarging the calculated bbox, but I still have to check that this also works when the bbox is calculated by the tile splitter.
Gerd
Hi Gerd,
uups, I wanted to add bounds information but obviously I missed that and you got and unintended second test case ;-)
I am thinking how to fix the problem with the very short way and the relation. Do you think it is possible to detect that the short way consists of two points with identical Garmin coords. In this case it might be possible to change the restriction in such a way that the ways connected to the short way are used in the restriction instead.
I want to make a small statistic why restriction relations become invalid. Maybe the problem is so seldom that it's not worthy...
WanMil
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi WanMil,
The problem probably only occurs with ways close to the tile boundary that are clipped. I don't know if we can save a route restriction when the to-node or from-node lies outside of the boundary.
Would it solve the problem if the boundary nodes are added earlier just before the RestrictionRelation.addRestriction(MapCollector) is called?
The boundary nodes are added for all ways before style processing, even for all non-routable ways and shapes. This wastes a few cpu cycles, but I don't see a problem or a solution here. Gerd
Hi WanMil,
The problem probably only occurs with ways close to the tile boundary that are clipped. I don't know if we can save a route restriction when the to-node or from-node lies outside of the boundary.
Would it solve the problem if the boundary nodes are added earlier just before the RestrictionRelation.addRestriction(MapCollector) is called?
The boundary nodes are added for all ways before style processing, even for all non-routable ways and shapes. This wastes a few cpu cycles, but I don't see a problem or a solution here.
Gerd
As far as I understand the to-node and the from-node are calculated by mkgmap. So I don't understand why there is a problem if the boundary nodes are available. Can you explain a bit more in detail? WanMil
Hi WanMil, I am just guessing. Will have a closer look tomorrow. Gerd
Date: Mon, 3 Feb 2014 20:19:46 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Problem with turn restriction
Hi WanMil,
The problem probably only occurs with ways close to the tile boundary that are clipped. I don't know if we can save a route restriction when the to-node or from-node lies outside of the boundary.
Would it solve the problem if the boundary nodes are added earlier just before the RestrictionRelation.addRestriction(MapCollector) is called?
The boundary nodes are added for all ways before style processing, even for all non-routable ways and shapes. This wastes a few cpu cycles, but I don't see a problem or a solution here.
Gerd
As far as I understand the to-node and the from-node are calculated by mkgmap. So I don't understand why there is a problem if the boundary nodes are available. Can you explain a bit more in detail?
WanMil
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi
I am thinking how to fix the problem with the very short way and the relation. Do you think it is possible to detect that the short way consists of two points with identical Garmin coords. In this case it might be possible to change the restriction in such a way that the ways
Today I've come to the conclusion that zero length arcs are allowed at least in some circumstances. Don't know if that will help. Could be that they are used for restrictions but I haven't looked into that yet. .. Steve
connected to the short way are used in the restriction instead.
I want to make a small statistic why restriction relations become invalid. Maybe the problem is so seldom that it's not worthy...
WanMil
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Steve, yes, in the branch I changed the checks so that mkgmap only complains when an arc starts and ends with the same node (same node id). Maybe the solution would be to make sure that all boundary nodes added by the clipper get unique coord instances, so that they also get different node ids. Gerd
From: steve@parabola.me.uk Date: Mon, 3 Feb 2014 18:43:37 +0000 To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Problem with turn restriction
Hi
I am thinking how to fix the problem with the very short way and the relation. Do you think it is possible to detect that the short way consists of two points with identical Garmin coords. In this case it might be possible to change the restriction in such a way that the ways
Today I've come to the conclusion that zero length arcs are allowed at least in some circumstances.
Don't know if that will help. Could be that they are used for restrictions but I haven't looked into that yet.
.. Steve
connected to the short way are used in the restriction instead.
I want to make a small statistic why restriction relations become invalid. Maybe the problem is so seldom that it's not worthy...
WanMil
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
I want to make a small statistic why restriction relations become invalid. Maybe the problem is so seldom that it's not worthy...
I have made a short stat with the high-prec branch: There are around 850 relations that are valid (RestrictionRelation.isValid() == true) after loading but that are not valid when the StyledConverter calls RestrictionRelations.convertRelation(MapCollector ...). So it seems to me as if the problem is greater than expected. WanMil
I want to make a small statistic why restriction relations become invalid. Maybe the problem is so seldom that it's not worthy...
I have made a short stat with the high-prec branch: There are around 850 relations that are valid (RestrictionRelation.isValid() == true) after loading but that are not valid when the StyledConverter calls RestrictionRelations.convertRelation(MapCollector ...). So it seems to me as if the problem is greater than expected.
WanMil
The stats are made with a Germany map...
WanMil wrote
I want to make a small statistic why restriction relations become invalid. Maybe the problem is so seldom that it's not worthy...
I have made a short stat with the high-prec branch: There are around 850 relations that are valid (RestrictionRelation.isValid() == true) after loading but that are not valid when the StyledConverter calls RestrictionRelations.convertRelation(MapCollector ...). So it seems to me as if the problem is greater than expected.
Yes, sounds too much. The only good case that I can think of is that the relation is saved by splitter because one of the related ways has at least one point within the boundary, but another part of the relation is outside of the boundary. If the via node is within the tile boundary we should be able to create the restriction. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Problem-with-turn-restriction-tp5795049p57951... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi WanMil, up to now I found these reasons for problems: 1) one error in the branch: via coords were replaced without updating the corrresponding restrictions and the hash map 2) "no_u_turn" restrictions were not added if from-way and to-way are equal. They are evaluated to be valid, but I don't know if they really make sense? 3) restrictions are added to the restrictions hash map even if the via coord is not contained in the bounding box. 4) restrictions that have a from-way or to-way which is not added with a routable type or not at all, e.g. way http://www.openstreetmap.org/way/225540783 has no tags but is part of three restriction relations. Another example: http://www.openstreetmap.org/relation/2880411 refers to ways that are tagged lane=tertiary and the default style ignores them. In high-prec-coords branch r3003 I've fixed 1) to 3), please check again. Gerd
Date: Mon, 3 Feb 2014 13:01:40 -0800 From: gpetermann_muenchen@hotmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Problem with turn restriction
WanMil wrote
I want to make a small statistic why restriction relations become invalid. Maybe the problem is so seldom that it's not worthy...
I have made a short stat with the high-prec branch: There are around 850 relations that are valid (RestrictionRelation.isValid() == true) after loading but that are not valid when the StyledConverter calls RestrictionRelations.convertRelation(MapCollector ...). So it seems to me as if the problem is greater than expected.
Yes, sounds too much. The only good case that I can think of is that the relation is saved by splitter because one of the related ways has at least one point within the boundary, but another part of the relation is outside of the boundary. If the via node is within the tile boundary we should be able to create the restriction.
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/Problem-with-turn-restriction-tp5795049p57951... 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 Gerd,
2) "no_u_turn" restrictions were not added if from-way and to-way are equal. They are evaluated to be valid, but I don't know if they really make sense?
GPSMapEdit adds these restrictions when splitting a map. I think they aren't important but maybe adding a node in a middle of the road adds an additional point, where routing can make u-turn? In this case adding restriction would prevent from changes in routing. -- Best regards, Andrzej
Hi Gerd, I think your changes are good. Anyhow for my special purpose I don't see any difference after your fixes. So I will explain what and how I am checking the restrictions (see attached patch with the check code). All restrictions that are valid after loading but which cannot be written to the map because there is a problem when the RestrictionRelation.addRestriction(..) is called are logged with the (not very useful...) text "Late invalid: "+URL of restriction. See relation_problems.txt with the results. There are 851 problems in Germany using the tiles created with attached areas.list. I am not sure if really all logged restrictions are completely valid but all I checked should make its way into the mkgmap compiled map. I hope this helps you to find some other problematic places! WanMil
Hi WanMil,
up to now I found these reasons for problems: 1) one error in the branch: via coords were replaced without updating the corrresponding restrictions and the hash map 2) "no_u_turn" restrictions were not added if from-way and to-way are equal. They are evaluated to be valid, but I don't know if they really make sense? 3) restrictions are added to the restrictions hash map even if the via coord is not contained in the bounding box.
4) restrictions that have a from-way or to-way which is not added with a routable type or not at all, e.g. way http://www.openstreetmap.org/way/225540783 has no tags but is part of three restriction relations. Another example: http://www.openstreetmap.org/relation/2880411 refers to ways that are tagged lane=tertiary and the default style ignores them.
In high-prec-coords branch r3003 I've fixed 1) to 3), please check again.
Gerd
Date: Mon, 3 Feb 2014 13:01:40 -0800 From: gpetermann_muenchen@hotmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Problem with turn restriction
WanMil wrote
I want to make a small statistic why restriction relations become invalid. Maybe the problem is so seldom that it's not worthy...
I have made a short stat with the high-prec branch: There are around 850 relations that are valid (RestrictionRelation.isValid() == true) after loading but that are not valid when the StyledConverter calls RestrictionRelations.convertRelation(MapCollector ...). So it seems to me as if the problem is greater than expected.
Yes, sounds too much. The only good case that I can think of is that the relation is saved by splitter because one of the related ways has at least one point within the boundary, but another part of the relation is outside of the boundary. If the via node is within the tile boundary we should be able to create the restriction.
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/Problem-with-turn-restriction-tp5795049p57951... 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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi WanMil, that's strange. With r3000 I saw many problems for Niedersachen, with r3002 only 4, and those were the two examples. I am downloading latest Germany now. Gerd WanMil wrote
Hi Gerd,
I think your changes are good. Anyhow for my special purpose I don't see any difference after your fixes. So I will explain what and how I am checking the restrictions (see attached patch with the check code).
All restrictions that are valid after loading but which cannot be written to the map because there is a problem when the RestrictionRelation.addRestriction(..) is called are logged with the (not very useful...) text "Late invalid: "+URL of restriction.
See relation_problems.txt with the results. There are 851 problems in Germany using the tiles created with attached areas.list.
I am not sure if really all logged restrictions are completely valid but all I checked should make its way into the mkgmap compiled map.
I hope this helps you to find some other problematic places!
WanMil
Hi WanMil,
up to now I found these reasons for problems: 1) one error in the branch: via coords were replaced without updating the corrresponding restrictions and the hash map 2) "no_u_turn" restrictions were not added if from-way and to-way are equal. They are evaluated to be valid, but I don't know if they really make sense? 3) restrictions are added to the restrictions hash map even if the via coord is not contained in the bounding box.
4) restrictions that have a from-way or to-way which is not added with a routable type or not at all, e.g. way http://www.openstreetmap.org/way/225540783 has no tags but is part of three restriction relations. Another example: http://www.openstreetmap.org/relation/2880411 refers to ways that are tagged lane=tertiary and the default style ignores them.
In high-prec-coords branch r3003 I've fixed 1) to 3), please check again.
Gerd
Date: Mon, 3 Feb 2014 13:01:40 -0800 From:
gpetermann_muenchen@
To:
mkgmap-dev@.org
Subject: Re: [mkgmap-dev] Problem with turn restriction
WanMil wrote
I want to make a small statistic why restriction relations become invalid. Maybe the problem is so seldom that it's not worthy...
I have made a short stat with the high-prec branch: There are around 850 relations that are valid (RestrictionRelation.isValid() == true) after loading but that are not valid when the StyledConverter calls RestrictionRelations.convertRelation(MapCollector ...). So it seems to me as if the problem is greater than expected.
Yes, sounds too much. The only good case that I can think of is that the relation is saved by splitter because one of the related ways has at least one point within the boundary, but another part of the relation is outside of the boundary. If the via node is within the tile boundary we should be able to create the restriction.
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/Problem-with-turn-restriction-tp5795049p57951... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
relation_check.patch (1K) <http://gis.19327.n5.nabble.com/attachment/5795291/0/relation_check.patch>; areas.list (14K) <http://gis.19327.n5.nabble.com/attachment/5795291/1/areas.list>; relation_problems.txt (71K) <http://gis.19327.n5.nabble.com/attachment/5795291/2/relation_problems.txt>;
-- View this message in context: http://gis.19327.n5.nabble.com/Problem-with-turn-restriction-tp5795049p57952... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd, your fixes for 3) were already sorted out by my checks. So relations without via coord in the bbox were not counted. I wonder why your fixes for 1) do not help. I have expected that it removes some of the 851 problems... By the way: 2) mmh, I don't mind adding that but I think it can be addressed with very low priority. If there is a street where u-turns are not allowed the street should be mapped with separate ways for each direction (that's my opinion - don't know if that matches with the official mapping guidelines). 4) Ok, they can be ignored. Would be great if we can detect them to output different log messages for them. WanMil
Hi WanMil,
that's strange. With r3000 I saw many problems for Niedersachen, with r3002 only 4, and those were the two examples.
I am downloading latest Germany now.
Gerd
WanMil wrote
Hi Gerd,
I think your changes are good. Anyhow for my special purpose I don't see any difference after your fixes. So I will explain what and how I am checking the restrictions (see attached patch with the check code).
All restrictions that are valid after loading but which cannot be written to the map because there is a problem when the RestrictionRelation.addRestriction(..) is called are logged with the (not very useful...) text "Late invalid: "+URL of restriction.
See relation_problems.txt with the results. There are 851 problems in Germany using the tiles created with attached areas.list.
I am not sure if really all logged restrictions are completely valid but all I checked should make its way into the mkgmap compiled map.
I hope this helps you to find some other problematic places!
WanMil
Hi WanMil,
up to now I found these reasons for problems: 1) one error in the branch: via coords were replaced without updating the corrresponding restrictions and the hash map 2) "no_u_turn" restrictions were not added if from-way and to-way are equal. They are evaluated to be valid, but I don't know if they really make sense? 3) restrictions are added to the restrictions hash map even if the via coord is not contained in the bounding box.
4) restrictions that have a from-way or to-way which is not added with a routable type or not at all, e.g. way http://www.openstreetmap.org/way/225540783 has no tags but is part of three restriction relations. Another example: http://www.openstreetmap.org/relation/2880411 refers to ways that are tagged lane=tertiary and the default style ignores them.
In high-prec-coords branch r3003 I've fixed 1) to 3), please check again.
Gerd
Date: Mon, 3 Feb 2014 13:01:40 -0800 From:
gpetermann_muenchen@
To:
mkgmap-dev@.org
Subject: Re: [mkgmap-dev] Problem with turn restriction
WanMil wrote
I want to make a small statistic why restriction relations become invalid. Maybe the problem is so seldom that it's not worthy...
I have made a short stat with the high-prec branch: There are around 850 relations that are valid (RestrictionRelation.isValid() == true) after loading but that are not valid when the StyledConverter calls RestrictionRelations.convertRelation(MapCollector ...). So it seems to me as if the problem is greater than expected.
Yes, sounds too much. The only good case that I can think of is that the relation is saved by splitter because one of the related ways has at least one point within the boundary, but another part of the relation is outside of the boundary. If the via node is within the tile boundary we should be able to create the restriction.
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/Problem-with-turn-restriction-tp5795049p57951... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
relation_check.patch (1K) <http://gis.19327.n5.nabble.com/attachment/5795291/0/relation_check.patch>; areas.list (14K) <http://gis.19327.n5.nabble.com/attachment/5795291/1/areas.list>; relation_problems.txt (71K) <http://gis.19327.n5.nabble.com/attachment/5795291/2/relation_problems.txt>;
-- View this message in context: http://gis.19327.n5.nabble.com/Problem-with-turn-restriction-tp5795049p57952... 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, with your patch I see more messages for my Niedersachsen data, but not a single one starts with "Late invalid". Maybe you are looking at an old result file? Gerd
Date: Tue, 4 Feb 2014 21:21:31 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Problem with turn restriction
Hi Gerd,
your fixes for 3) were already sorted out by my checks. So relations without via coord in the bbox were not counted.
I wonder why your fixes for 1) do not help. I have expected that it removes some of the 851 problems...
By the way: 2) mmh, I don't mind adding that but I think it can be addressed with very low priority. If there is a street where u-turns are not allowed the street should be mapped with separate ways for each direction (that's my opinion - don't know if that matches with the official mapping guidelines).
4) Ok, they can be ignored. Would be great if we can detect them to output different log messages for them.
WanMil
Hi WanMil,
that's strange. With r3000 I saw many problems for Niedersachen, with r3002 only 4, and those were the two examples.
I am downloading latest Germany now.
Gerd
WanMil wrote
Hi Gerd,
I think your changes are good. Anyhow for my special purpose I don't see any difference after your fixes. So I will explain what and how I am checking the restrictions (see attached patch with the check code).
All restrictions that are valid after loading but which cannot be written to the map because there is a problem when the RestrictionRelation.addRestriction(..) is called are logged with the (not very useful...) text "Late invalid: "+URL of restriction.
See relation_problems.txt with the results. There are 851 problems in Germany using the tiles created with attached areas.list.
I am not sure if really all logged restrictions are completely valid but all I checked should make its way into the mkgmap compiled map.
I hope this helps you to find some other problematic places!
WanMil
Hi WanMil,
up to now I found these reasons for problems: 1) one error in the branch: via coords were replaced without updating the corrresponding restrictions and the hash map 2) "no_u_turn" restrictions were not added if from-way and to-way are equal. They are evaluated to be valid, but I don't know if they really make sense? 3) restrictions are added to the restrictions hash map even if the via coord is not contained in the bounding box.
4) restrictions that have a from-way or to-way which is not added with a routable type or not at all, e.g. way http://www.openstreetmap.org/way/225540783 has no tags but is part of three restriction relations. Another example: http://www.openstreetmap.org/relation/2880411 refers to ways that are tagged lane=tertiary and the default style ignores them.
In high-prec-coords branch r3003 I've fixed 1) to 3), please check again.
Gerd
Date: Mon, 3 Feb 2014 13:01:40 -0800 From:
gpetermann_muenchen@
To:
mkgmap-dev@.org
Subject: Re: [mkgmap-dev] Problem with turn restriction
WanMil wrote
> I want to make a small statistic why restriction relations become > invalid. Maybe the problem is so seldom that it's not worthy...
I have made a short stat with the high-prec branch: There are around 850 relations that are valid (RestrictionRelation.isValid() == true) after loading but that are not valid when the StyledConverter calls RestrictionRelations.convertRelation(MapCollector ...). So it seems to me as if the problem is greater than expected.
Yes, sounds too much. The only good case that I can think of is that the relation is saved by splitter because one of the related ways has at least one point within the boundary, but another part of the relation is outside of the boundary. If the via node is within the tile boundary we should be able to create the restriction.
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/Problem-with-turn-restriction-tp5795049p57951... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
relation_check.patch (1K) <http://gis.19327.n5.nabble.com/attachment/5795291/0/relation_check.patch>; areas.list (14K) <http://gis.19327.n5.nabble.com/attachment/5795291/1/areas.list>; relation_problems.txt (71K) <http://gis.19327.n5.nabble.com/attachment/5795291/2/relation_problems.txt>;
-- View this message in context: http://gis.19327.n5.nabble.com/Problem-with-turn-restriction-tp5795049p57952... 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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Arghhh.... I started mkgmap from the wrong workspace. I should have been more alarmed that I got exactly the same number of problems! Ok, I will try again and hopefully the number of problems will be reduced *very* much. Sorry!! WanMil
Hi WanMil,
with your patch I see more messages for my Niedersachsen data, but not a single one starts with "Late invalid".
Maybe you are looking at an old result file?
Gerd
Date: Tue, 4 Feb 2014 21:21:31 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Problem with turn restriction
Hi Gerd,
your fixes for 3) were already sorted out by my checks. So relations without via coord in the bbox were not counted.
I wonder why your fixes for 1) do not help. I have expected that it removes some of the 851 problems...
By the way: 2) mmh, I don't mind adding that but I think it can be addressed with very low priority. If there is a street where u-turns are not allowed the street should be mapped with separate ways for each direction (that's my opinion - don't know if that matches with the official mapping guidelines).
4) Ok, they can be ignored. Would be great if we can detect them to output different log messages for them.
WanMil
Hi WanMil,
that's strange. With r3000 I saw many problems for Niedersachen, with r3002 only 4, and those were the two examples.
I am downloading latest Germany now.
Gerd
WanMil wrote
Hi Gerd,
I think your changes are good. Anyhow for my special purpose I don't see any difference after your fixes. So I will explain what and how I am checking the restrictions (see attached patch with the check code).
All restrictions that are valid after loading but which cannot be written to the map because there is a problem when the RestrictionRelation.addRestriction(..) is called are logged with the (not very useful...) text "Late invalid: "+URL of restriction.
See relation_problems.txt with the results. There are 851 problems in Germany using the tiles created with attached areas.list.
I am not sure if really all logged restrictions are completely valid but all I checked should make its way into the mkgmap compiled map.
I hope this helps you to find some other problematic places!
WanMil
Hi WanMil,
up to now I found these reasons for problems: 1) one error in the branch: via coords were replaced without updating the corrresponding restrictions and the hash map 2) "no_u_turn" restrictions were not added if from-way and to-way are equal. They are evaluated to be valid, but I don't know if they really make sense? 3) restrictions are added to the restrictions hash map even if the via coord is not contained in the bounding box.
4) restrictions that have a from-way or to-way which is not added with a routable type or not at all, e.g. way http://www.openstreetmap.org/way/225540783 has no tags but is part of three restriction relations. Another example: http://www.openstreetmap.org/relation/2880411 refers to ways that are tagged lane=tertiary and the default style ignores them.
In high-prec-coords branch r3003 I've fixed 1) to 3), please check again.
Gerd
Date: Mon, 3 Feb 2014 13:01:40 -0800 From:
gpetermann_muenchen@
To:
mkgmap-dev@.org
Subject: Re: [mkgmap-dev] Problem with turn restriction
WanMil wrote >> I want to make a small statistic why restriction relations become >> invalid. Maybe the problem is so seldom that it's not worthy... > > I have made a short stat with the high-prec branch: > There are around 850 relations that are valid > (RestrictionRelation.isValid() == true) after loading but that are not > valid when the StyledConverter calls > RestrictionRelations.convertRelation(MapCollector ...). > So it seems to me as if the problem is greater than expected.
Yes, sounds too much. The only good case that I can think of is that the relation is saved by splitter because one of the related ways has at least one point within the boundary, but another part of the relation is outside of the boundary. If the via node is within the tile boundary we should be able to create the restriction.
Gerd
-- View this message in context:
http://gis.19327.n5.nabble.com/Problem-with-turn-restriction-tp5795049p57951...
Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
relation_check.patch (1K)
<http://gis.19327.n5.nabble.com/attachment/5795291/0/relation_check.patch>;
areas.list (14K) <http://gis.19327.n5.nabble.com/attachment/5795291/1/areas.list>; relation_problems.txt (71K)
<http://gis.19327.n5.nabble.com/attachment/5795291/2/relation_problems.txt>;
-- View this message in context: http://gis.19327.n5.nabble.com/Problem-with-turn-restriction-tp5795049p57952... 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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
no problem. I also think your patch is also complaining about invalid restrictions with the wrong messages. Attached my proposal. Gerd
Date: Tue, 4 Feb 2014 21:44:33 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Problem with turn restriction
Arghhh.... I started mkgmap from the wrong workspace. I should have been more alarmed that I got exactly the same number of problems!
Ok, I will try again and hopefully the number of problems will be reduced *very* much.
Sorry!! WanMil
Hi WanMil,
with your patch I see more messages for my Niedersachsen data, but not a single one starts with "Late invalid".
Maybe you are looking at an old result file?
Gerd
Date: Tue, 4 Feb 2014 21:21:31 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Problem with turn restriction
Hi Gerd,
your fixes for 3) were already sorted out by my checks. So relations without via coord in the bbox were not counted.
I wonder why your fixes for 1) do not help. I have expected that it removes some of the 851 problems...
By the way: 2) mmh, I don't mind adding that but I think it can be addressed with very low priority. If there is a street where u-turns are not allowed the street should be mapped with separate ways for each direction (that's my opinion - don't know if that matches with the official mapping guidelines).
4) Ok, they can be ignored. Would be great if we can detect them to output different log messages for them.
WanMil
Hi WanMil,
that's strange. With r3000 I saw many problems for Niedersachen, with r3002 only 4, and those were the two examples.
I am downloading latest Germany now.
Gerd
WanMil wrote
Hi Gerd,
I think your changes are good. Anyhow for my special purpose I don't see any difference after your fixes. So I will explain what and how I am checking the restrictions (see attached patch with the check code).
All restrictions that are valid after loading but which cannot be written to the map because there is a problem when the RestrictionRelation.addRestriction(..) is called are logged with the (not very useful...) text "Late invalid: "+URL of restriction.
See relation_problems.txt with the results. There are 851 problems in Germany using the tiles created with attached areas.list.
I am not sure if really all logged restrictions are completely valid but all I checked should make its way into the mkgmap compiled map.
I hope this helps you to find some other problematic places!
WanMil
Hi WanMil,
up to now I found these reasons for problems: 1) one error in the branch: via coords were replaced without updating the corrresponding restrictions and the hash map 2) "no_u_turn" restrictions were not added if from-way and to-way are equal. They are evaluated to be valid, but I don't know if they really make sense? 3) restrictions are added to the restrictions hash map even if the via coord is not contained in the bounding box.
4) restrictions that have a from-way or to-way which is not added with a routable type or not at all, e.g. way http://www.openstreetmap.org/way/225540783 has no tags but is part of three restriction relations. Another example: http://www.openstreetmap.org/relation/2880411 refers to ways that are tagged lane=tertiary and the default style ignores them.
In high-prec-coords branch r3003 I've fixed 1) to 3), please check again.
Gerd
> Date: Mon, 3 Feb 2014 13:01:40 -0800 > From:
gpetermann_muenchen@
> To:
mkgmap-dev@.org
> Subject: Re: [mkgmap-dev] Problem with turn restriction > > WanMil wrote > >> I want to make a small statistic why restriction relations become > >> invalid. Maybe the problem is so seldom that it's not worthy... > > > > I have made a short stat with the high-prec branch: > > There are around 850 relations that are valid > > (RestrictionRelation.isValid() == true) after loading but that are not > > valid when the StyledConverter calls > > RestrictionRelations.convertRelation(MapCollector ...). > > So it seems to me as if the problem is greater than expected. > > Yes, sounds too much. The only good case that I can think of > is that the relation is saved by splitter because one of the > related ways has at least one point within the boundary, but > another part of the relation is outside of the boundary. > If the via node is within the tile boundary we should be able > to create the restriction. > > Gerd > > > > -- > View this message in context:
http://gis.19327.n5.nabble.com/Problem-with-turn-restriction-tp5795049p57951...
> Sent from the Mkgmap Development mailing list archive at Nabble.com. > _______________________________________________ > mkgmap-dev mailing list >
mkgmap-dev@.org
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
relation_check.patch (1K)
<http://gis.19327.n5.nabble.com/attachment/5795291/0/relation_check.patch>;
areas.list (14K) <http://gis.19327.n5.nabble.com/attachment/5795291/1/areas.list>; relation_problems.txt (71K)
<http://gis.19327.n5.nabble.com/attachment/5795291/2/relation_problems.txt>;
-- View this message in context: http://gis.19327.n5.nabble.com/Problem-with-turn-restriction-tp5795049p57952... 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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, I get an exception when running the branch: java.lang.NullPointerException at uk.me.parabola.mkgmap.general.RoadNetwork.addRestriction(RoadNetwork.java:275) at uk.me.parabola.mkgmap.general.MapDetails.addRestriction(MapDetails.java:130) at uk.me.parabola.mkgmap.osmstyle.StyledConverter.createRouteRestrictionsFromPOI(StyledConverter.java:855) at uk.me.parabola.mkgmap.osmstyle.StyledConverter.end(StyledConverter.java:587) at uk.me.parabola.mkgmap.reader.osm.ElementSaver.convert(ElementSaver.java:239) at uk.me.parabola.mkgmap.reader.osm.bin.OsmBinMapDataSource.load(OsmBinMapDataSource.java:67) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:127) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:167) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:63) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:220) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:1) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) I'll try again with assertions enabled to find the restriction which causes the problem. WanMil
no problem.
I also think your patch is also complaining about invalid restrictions with the wrong messages. Attached my proposal.
Gerd
Date: Tue, 4 Feb 2014 21:44:33 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Problem with turn restriction
Arghhh.... I started mkgmap from the wrong workspace. I should have been more alarmed that I got exactly the same number of problems!
Ok, I will try again and hopefully the number of problems will be reduced *very* much.
Sorry!! WanMil
Hi WanMil,
with your patch I see more messages for my Niedersachsen data, but not a single one starts with "Late invalid".
Maybe you are looking at an old result file?
Gerd
Date: Tue, 4 Feb 2014 21:21:31 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Problem with turn restriction
Hi Gerd,
your fixes for 3) were already sorted out by my checks. So relations without via coord in the bbox were not counted.
I wonder why your fixes for 1) do not help. I have expected that it removes some of the 851 problems...
By the way: 2) mmh, I don't mind adding that but I think it can be addressed with very low priority. If there is a street where u-turns are not allowed the street should be mapped with separate ways for each direction (that's my opinion - don't know if that matches with the official mapping guidelines).
4) Ok, they can be ignored. Would be great if we can detect them to output different log messages for them.
WanMil
Hi WanMil,
that's strange. With r3000 I saw many problems for Niedersachen, with r3002 only 4, and those were the two examples.
I am downloading latest Germany now.
Gerd
WanMil wrote
Hi Gerd,
I think your changes are good. Anyhow for my special purpose I don't see any difference after your fixes. So I will explain what and how I am checking the restrictions (see attached patch with the check code).
All restrictions that are valid after loading but which cannot be written to the map because there is a problem when the RestrictionRelation.addRestriction(..) is called are logged with the (not very useful...) text "Late invalid: "+URL of restriction.
See relation_problems.txt with the results. There are 851 problems in Germany using the tiles created with attached areas.list.
I am not sure if really all logged restrictions are completely valid but all I checked should make its way into the mkgmap compiled map.
I hope this helps you to find some other problematic places!
WanMil
> Hi WanMil, > > up to now I found these reasons for problems: > 1) one error in the branch: via coords were replaced without updating > the corrresponding restrictions and the hash map > 2) "no_u_turn" restrictions were not added > if from-way and to-way are equal. They are evaluated to be valid, but > I don't know if they really make sense? > 3) restrictions are added to the restrictions hash map even if the via > coord is > not contained in the bounding box. > > 4) restrictions that have a from-way or to-way which > is not added with a routable type or not at all, > e.g. way http://www.openstreetmap.org/way/225540783 > has no tags but is part of three restriction relations. > Another example: > http://www.openstreetmap.org/relation/2880411 > refers to ways that are tagged lane=tertiary > and the default style ignores them. > > In high-prec-coords branch r3003 I've fixed 1) to 3), please > check again. > > Gerd > > > > > Date: Mon, 3 Feb 2014 13:01:40 -0800 > > From:
gpetermann_muenchen@
> > To:
mkgmap-dev@.org
> > Subject: Re: [mkgmap-dev] Problem with turn restriction > > > > WanMil wrote > > >> I want to make a small statistic why restriction relations become > > >> invalid. Maybe the problem is so seldom that it's not worthy... > > > > > > I have made a short stat with the high-prec branch: > > > There are around 850 relations that are valid > > > (RestrictionRelation.isValid() == true) after loading but that are > not > > > valid when the StyledConverter calls > > > RestrictionRelations.convertRelation(MapCollector ...). > > > So it seems to me as if the problem is greater than expected. > > > > Yes, sounds too much. The only good case that I can think of > > is that the relation is saved by splitter because one of the > > related ways has at least one point within the boundary, but > > another part of the relation is outside of the boundary. > > If the via node is within the tile boundary we should be able > > to create the restriction. > > > > Gerd > > > > > > > > -- > > View this message in context: >
http://gis.19327.n5.nabble.com/Problem-with-turn-restriction-tp5795049p57951...
> > Sent from the Mkgmap Development mailing list archive at Nabble.com. > > _______________________________________________ > > mkgmap-dev mailing list > >
mkgmap-dev@.org
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > _______________________________________________ > mkgmap-dev mailing list >
mkgmap-dev@.org
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
relation_check.patch (1K)
<http://gis.19327.n5.nabble.com/attachment/5795291/0/relation_check.patch>;
areas.list (14K)
<http://gis.19327.n5.nabble.com/attachment/5795291/1/areas.list>;
relation_problems.txt (71K)
<http://gis.19327.n5.nabble.com/attachment/5795291/2/relation_problems.txt>;
-- View this message in context:
http://gis.19327.n5.nabble.com/Problem-with-turn-restriction-tp5795049p57952...
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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Ah, forgot to say that the number of "Late invalid" message reduced dramatically. It seems that all remaining late-invalids are caused by your number 4). Good :-) WanMil
Hi Gerd,
I get an exception when running the branch:
java.lang.NullPointerException at uk.me.parabola.mkgmap.general.RoadNetwork.addRestriction(RoadNetwork.java:275)
at uk.me.parabola.mkgmap.general.MapDetails.addRestriction(MapDetails.java:130)
at uk.me.parabola.mkgmap.osmstyle.StyledConverter.createRouteRestrictionsFromPOI(StyledConverter.java:855)
at uk.me.parabola.mkgmap.osmstyle.StyledConverter.end(StyledConverter.java:587)
at uk.me.parabola.mkgmap.reader.osm.ElementSaver.convert(ElementSaver.java:239)
at uk.me.parabola.mkgmap.reader.osm.bin.OsmBinMapDataSource.load(OsmBinMapDataSource.java:67)
at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:127)
at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:167) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:63) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:220) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:1) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source)
I'll try again with assertions enabled to find the restriction which causes the problem.
WanMil
no problem.
I also think your patch is also complaining about invalid restrictions with the wrong messages. Attached my proposal.
Gerd
Date: Tue, 4 Feb 2014 21:44:33 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Problem with turn restriction
Arghhh.... I started mkgmap from the wrong workspace. I should have been more alarmed that I got exactly the same number of problems!
Ok, I will try again and hopefully the number of problems will be reduced *very* much.
Sorry!! WanMil
Hi WanMil,
with your patch I see more messages for my Niedersachsen data, but not a single one starts with "Late invalid".
Maybe you are looking at an old result file?
Gerd
Date: Tue, 4 Feb 2014 21:21:31 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Problem with turn restriction
Hi Gerd,
your fixes for 3) were already sorted out by my checks. So relations without via coord in the bbox were not counted.
I wonder why your fixes for 1) do not help. I have expected that it removes some of the 851 problems...
By the way: 2) mmh, I don't mind adding that but I think it can be addressed with very low priority. If there is a street where u-turns are not allowed the street should be mapped with separate ways for each direction (that's my opinion - don't know if that matches with the official mapping guidelines).
4) Ok, they can be ignored. Would be great if we can detect them to output different log messages for them.
WanMil
Hi WanMil,
that's strange. With r3000 I saw many problems for Niedersachen, with r3002 only 4, and those were the two examples.
I am downloading latest Germany now.
Gerd
WanMil wrote > Hi Gerd, > > I think your changes are good. > Anyhow for my special purpose I don't see any difference after your fixes. > So I will explain what and how I am checking the restrictions (see > attached patch with the check code). > > All restrictions that are valid after loading but which cannot be > written to the map because there is a problem when the > RestrictionRelation.addRestriction(..) is called are logged with the > (not very useful...) text "Late invalid: "+URL of restriction. > > See relation_problems.txt with the results. There are 851 problems in > Germany using the tiles created with attached areas.list. > > I am not sure if really all logged restrictions are completely valid but > all I checked should make its way into the mkgmap compiled map. > > I hope this helps you to find some other problematic places! > > WanMil > >> Hi WanMil, >> >> up to now I found these reasons for problems: >> 1) one error in the branch: via coords were replaced without updating >> the corrresponding restrictions and the hash map >> 2) "no_u_turn" restrictions were not added >> if from-way and to-way are equal. They are evaluated to be valid, but >> I don't know if they really make sense? >> 3) restrictions are added to the restrictions hash map even if the via >> coord is >> not contained in the bounding box. >> >> 4) restrictions that have a from-way or to-way which >> is not added with a routable type or not at all, >> e.g. way http://www.openstreetmap.org/way/225540783 >> has no tags but is part of three restriction relations. >> Another example: >> http://www.openstreetmap.org/relation/2880411 >> refers to ways that are tagged lane=tertiary >> and the default style ignores them. >> >> In high-prec-coords branch r3003 I've fixed 1) to 3), please >> check again. >> >> Gerd >> >> >> >> > Date: Mon, 3 Feb 2014 13:01:40 -0800 >> > From:
> gpetermann_muenchen@
>> > To:
> mkgmap-dev@.org
>> > Subject: Re: [mkgmap-dev] Problem with turn restriction >> > >> > WanMil wrote >> > >> I want to make a small statistic why restriction relations become >> > >> invalid. Maybe the problem is so seldom that it's not worthy... >> > > >> > > I have made a short stat with the high-prec branch: >> > > There are around 850 relations that are valid >> > > (RestrictionRelation.isValid() == true) after loading but that are >> not >> > > valid when the StyledConverter calls >> > > RestrictionRelations.convertRelation(MapCollector ...). >> > > So it seems to me as if the problem is greater than expected. >> > >> > Yes, sounds too much. The only good case that I can think of >> > is that the relation is saved by splitter because one of the >> > related ways has at least one point within the boundary, but >> > another part of the relation is outside of the boundary. >> > If the via node is within the tile boundary we should be able >> > to create the restriction. >> > >> > Gerd >> > >> > >> > >> > -- >> > View this message in context: >>
http://gis.19327.n5.nabble.com/Problem-with-turn-restriction-tp5795049p57951...
>> > Sent from the Mkgmap Development mailing list archive at Nabble.com. >> > _______________________________________________ >> > mkgmap-dev mailing list >> >
> mkgmap-dev@.org
>> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> >> >> _______________________________________________ >> mkgmap-dev mailing list >>
> mkgmap-dev@.org
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> > > > _______________________________________________ > mkgmap-dev mailing list
> mkgmap-dev@.org
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > relation_check.patch (1K) >
<http://gis.19327.n5.nabble.com/attachment/5795291/0/relation_check.patch>;
> areas.list (14K) > <http://gis.19327.n5.nabble.com/attachment/5795291/1/areas.list>; > relation_problems.txt (71K) >
<http://gis.19327.n5.nabble.com/attachment/5795291/2/relation_problems.txt>;
-- View this message in context:
http://gis.19327.n5.nabble.com/Problem-with-turn-restriction-tp5795049p57952...
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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
thanks. I think the code in RoadNetwork should be changed to print error messages in such a case instead of ending with an NPE or assertion. Gerd
Date: Tue, 4 Feb 2014 22:06:13 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Problem with turn restriction
Hi Gerd,
I get an exception when running the branch:
java.lang.NullPointerException at uk.me.parabola.mkgmap.general.RoadNetwork.addRestriction(RoadNetwork.java:275) at uk.me.parabola.mkgmap.general.MapDetails.addRestriction(MapDetails.java:130) at uk.me.parabola.mkgmap.osmstyle.StyledConverter.createRouteRestrictionsFromPOI(StyledConverter.java:855) at uk.me.parabola.mkgmap.osmstyle.StyledConverter.end(StyledConverter.java:587) at uk.me.parabola.mkgmap.reader.osm.ElementSaver.convert(ElementSaver.java:239) at uk.me.parabola.mkgmap.reader.osm.bin.OsmBinMapDataSource.load(OsmBinMapDataSource.java:67) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:127) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:167) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:63) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:220) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:1) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source)
I'll try again with assertions enabled to find the restriction which causes the problem.
WanMil
no problem.
I also think your patch is also complaining about invalid restrictions with the wrong messages. Attached my proposal.
Gerd
Date: Tue, 4 Feb 2014 21:44:33 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Problem with turn restriction
Arghhh.... I started mkgmap from the wrong workspace. I should have been more alarmed that I got exactly the same number of problems!
Ok, I will try again and hopefully the number of problems will be reduced *very* much.
Sorry!! WanMil
Hi WanMil,
with your patch I see more messages for my Niedersachsen data, but not a single one starts with "Late invalid".
Maybe you are looking at an old result file?
Gerd
Date: Tue, 4 Feb 2014 21:21:31 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Problem with turn restriction
Hi Gerd,
your fixes for 3) were already sorted out by my checks. So relations without via coord in the bbox were not counted.
I wonder why your fixes for 1) do not help. I have expected that it removes some of the 851 problems...
By the way: 2) mmh, I don't mind adding that but I think it can be addressed with very low priority. If there is a street where u-turns are not allowed the street should be mapped with separate ways for each direction (that's my opinion - don't know if that matches with the official mapping guidelines).
4) Ok, they can be ignored. Would be great if we can detect them to output different log messages for them.
WanMil
Hi WanMil,
that's strange. With r3000 I saw many problems for Niedersachen, with r3002 only 4, and those were the two examples.
I am downloading latest Germany now.
Gerd
WanMil wrote > Hi Gerd, > > I think your changes are good. > Anyhow for my special purpose I don't see any difference after your fixes. > So I will explain what and how I am checking the restrictions (see > attached patch with the check code). > > All restrictions that are valid after loading but which cannot be > written to the map because there is a problem when the > RestrictionRelation.addRestriction(..) is called are logged with the > (not very useful...) text "Late invalid: "+URL of restriction. > > See relation_problems.txt with the results. There are 851 problems in > Germany using the tiles created with attached areas.list. > > I am not sure if really all logged restrictions are completely valid but > all I checked should make its way into the mkgmap compiled map. > > I hope this helps you to find some other problematic places! > > WanMil > >> Hi WanMil, >> >> up to now I found these reasons for problems: >> 1) one error in the branch: via coords were replaced without updating >> the corrresponding restrictions and the hash map >> 2) "no_u_turn" restrictions were not added >> if from-way and to-way are equal. They are evaluated to be valid, but >> I don't know if they really make sense? >> 3) restrictions are added to the restrictions hash map even if the via >> coord is >> not contained in the bounding box. >> >> 4) restrictions that have a from-way or to-way which >> is not added with a routable type or not at all, >> e.g. way http://www.openstreetmap.org/way/225540783 >> has no tags but is part of three restriction relations. >> Another example: >> http://www.openstreetmap.org/relation/2880411 >> refers to ways that are tagged lane=tertiary >> and the default style ignores them. >> >> In high-prec-coords branch r3003 I've fixed 1) to 3), please >> check again. >> >> Gerd >> >> >> >> > Date: Mon, 3 Feb 2014 13:01:40 -0800 >> > From:
> gpetermann_muenchen@
>> > To:
> mkgmap-dev@.org
>> > Subject: Re: [mkgmap-dev] Problem with turn restriction >> > >> > WanMil wrote >> > >> I want to make a small statistic why restriction relations become >> > >> invalid. Maybe the problem is so seldom that it's not worthy... >> > > >> > > I have made a short stat with the high-prec branch: >> > > There are around 850 relations that are valid >> > > (RestrictionRelation.isValid() == true) after loading but that are >> not >> > > valid when the StyledConverter calls >> > > RestrictionRelations.convertRelation(MapCollector ...). >> > > So it seems to me as if the problem is greater than expected. >> > >> > Yes, sounds too much. The only good case that I can think of >> > is that the relation is saved by splitter because one of the >> > related ways has at least one point within the boundary, but >> > another part of the relation is outside of the boundary. >> > If the via node is within the tile boundary we should be able >> > to create the restriction. >> > >> > Gerd >> > >> > >> > >> > -- >> > View this message in context: >>
http://gis.19327.n5.nabble.com/Problem-with-turn-restriction-tp5795049p57951...
>> > Sent from the Mkgmap Development mailing list archive at Nabble.com. >> > _______________________________________________ >> > mkgmap-dev mailing list >> >
> mkgmap-dev@.org
>> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> >> >> _______________________________________________ >> mkgmap-dev mailing list >>
> mkgmap-dev@.org
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> > > > _______________________________________________ > mkgmap-dev mailing list
> mkgmap-dev@.org
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > relation_check.patch (1K) >
<http://gis.19327.n5.nabble.com/attachment/5795291/0/relation_check.patch>;
> areas.list (14K) > <http://gis.19327.n5.nabble.com/attachment/5795291/1/areas.list>; > relation_problems.txt (71K) >
<http://gis.19327.n5.nabble.com/attachment/5795291/2/relation_problems.txt>;
-- View this message in context:
http://gis.19327.n5.nabble.com/Problem-with-turn-restriction-tp5795049p57952...
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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, the problem was caused by the node http://www.openstreetmap.org/node/1707492416. I am using the --link-pois-to-ways option. WanMil
thanks. I think the code in RoadNetwork should be changed to print error messages in such a case instead of ending with an NPE or assertion.
Gerd
Date: Tue, 4 Feb 2014 22:06:13 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Problem with turn restriction
Hi Gerd,
I get an exception when running the branch:
java.lang.NullPointerException at
uk.me.parabola.mkgmap.general.RoadNetwork.addRestriction(RoadNetwork.java:275)
at
uk.me.parabola.mkgmap.general.MapDetails.addRestriction(MapDetails.java:130)
at
uk.me.parabola.mkgmap.osmstyle.StyledConverter.createRouteRestrictionsFromPOI(StyledConverter.java:855)
at
uk.me.parabola.mkgmap.osmstyle.StyledConverter.end(StyledConverter.java:587)
at
uk.me.parabola.mkgmap.reader.osm.ElementSaver.convert(ElementSaver.java:239)
at
uk.me.parabola.mkgmap.reader.osm.bin.OsmBinMapDataSource.load(OsmBinMapDataSource.java:67)
at
uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:127)
at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:167) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:63) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:220) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:1) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source)
I'll try again with assertions enabled to find the restriction which causes the problem.
WanMil
no problem.
I also think your patch is also complaining about invalid restrictions with the wrong messages. Attached my proposal.
Gerd
Date: Tue, 4 Feb 2014 21:44:33 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Problem with turn restriction
Arghhh.... I started mkgmap from the wrong workspace. I should have been more alarmed that I got exactly the same number of problems!
Ok, I will try again and hopefully the number of problems will be reduced *very* much.
Sorry!! WanMil
Hi WanMil,
with your patch I see more messages for my Niedersachsen data, but not a single one starts with "Late invalid".
Maybe you are looking at an old result file?
Gerd
Date: Tue, 4 Feb 2014 21:21:31 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Problem with turn restriction
Hi Gerd,
your fixes for 3) were already sorted out by my checks. So relations without via coord in the bbox were not counted.
I wonder why your fixes for 1) do not help. I have expected that it removes some of the 851 problems...
By the way: 2) mmh, I don't mind adding that but I think it can be addressed with very low priority. If there is a street where u-turns are not allowed the street should be mapped with separate ways for each direction (that's my opinion - don't know if that matches with the official mapping guidelines).
4) Ok, they can be ignored. Would be great if we can detect them to output different log messages for them.
WanMil
> Hi WanMil, > > that's strange. With r3000 I saw many problems for Niedersachen, with > r3002 only 4, and those were the two examples. > > I am downloading latest Germany now. > > Gerd > > > > WanMil wrote >> Hi Gerd, >> >> I think your changes are good. >> Anyhow for my special purpose I don't see any difference after your fixes. >> So I will explain what and how I am checking the restrictions (see >> attached patch with the check code). >> >> All restrictions that are valid after loading but which cannot be >> written to the map because there is a problem when the >> RestrictionRelation.addRestriction(..) is called are logged with the >> (not very useful...) text "Late invalid: "+URL of restriction. >> >> See relation_problems.txt with the results. There are 851 problems in >> Germany using the tiles created with attached areas.list. >> >> I am not sure if really all logged restrictions are completely valid but >> all I checked should make its way into the mkgmap compiled map. >> >> I hope this helps you to find some other problematic places! >> >> WanMil >> >>> Hi WanMil, >>> >>> up to now I found these reasons for problems: >>> 1) one error in the branch: via coords were replaced without updating >>> the corrresponding restrictions and the hash map >>> 2) "no_u_turn" restrictions were not added >>> if from-way and to-way are equal. They are evaluated to be valid, but >>> I don't know if they really make sense? >>> 3) restrictions are added to the restrictions hash map even if the via >>> coord is >>> not contained in the bounding box. >>> >>> 4) restrictions that have a from-way or to-way which >>> is not added with a routable type or not at all, >>> e.g. way http://www.openstreetmap.org/way/225540783 >>> has no tags but is part of three restriction relations. >>> Another example: >>> http://www.openstreetmap.org/relation/2880411 >>> refers to ways that are tagged lane=tertiary >>> and the default style ignores them. >>> >>> In high-prec-coords branch r3003 I've fixed 1) to 3), please >>> check again. >>> >>> Gerd >>> >>> >>> >>> > Date: Mon, 3 Feb 2014 13:01:40 -0800 >>> > From: > >> gpetermann_muenchen@ > >>> > To: > >> mkgmap-dev@.org > >>> > Subject: Re: [mkgmap-dev] Problem with turn restriction >>> > >>> > WanMil wrote >>> > >> I want to make a small statistic why restriction relations become >>> > >> invalid. Maybe the problem is so seldom that it's not worthy... >>> > > >>> > > I have made a short stat with the high-prec branch: >>> > > There are around 850 relations that are valid >>> > > (RestrictionRelation.isValid() == true) after loading but that are >>> not >>> > > valid when the StyledConverter calls >>> > > RestrictionRelations.convertRelation(MapCollector ...). >>> > > So it seems to me as if the problem is greater than expected. >>> > >>> > Yes, sounds too much. The only good case that I can think of >>> > is that the relation is saved by splitter because one of the >>> > related ways has at least one point within the boundary, but >>> > another part of the relation is outside of the boundary. >>> > If the via node is within the tile boundary we should be able >>> > to create the restriction. >>> > >>> > Gerd >>> > >>> > >>> > >>> > -- >>> > View this message in context: >>>
http://gis.19327.n5.nabble.com/Problem-with-turn-restriction-tp5795049p57951...
>>> > Sent from the Mkgmap Development mailing list archive at Nabble.com. >>> > _______________________________________________ >>> > mkgmap-dev mailing list >>> > > >> mkgmap-dev@.org > >>> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >>> >>> >>> _______________________________________________ >>> mkgmap-dev mailing list >>> > >> mkgmap-dev@.org > >>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >>> >> >> >> _______________________________________________ >> mkgmap-dev mailing list > >> mkgmap-dev@.org > >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> >> relation_check.patch (1K) >>
<http://gis.19327.n5.nabble.com/attachment/5795291/0/relation_check.patch>;
>> areas.list (14K) >> <http://gis.19327.n5.nabble.com/attachment/5795291/1/areas.list>; >> relation_problems.txt (71K) >>
<http://gis.19327.n5.nabble.com/attachment/5795291/2/relation_problems.txt>;
> > > > > > -- > View this message in context:
http://gis.19327.n5.nabble.com/Problem-with-turn-restriction-tp5795049p57952...
> 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 >
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi WanMil, thanks. The code still used Coord.equals() in one place and in this special case, the Node http://www.openstreetmap.org/node/1707492378 was too close for the low precision. I've committed r3004 to fix this problem. Gerd
Date: Tue, 4 Feb 2014 22:41:51 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Problem with turn restriction
Hi Gerd,
the problem was caused by the node http://www.openstreetmap.org/node/1707492416. I am using the --link-pois-to-ways option.
WanMil
thanks. I think the code in RoadNetwork should be changed to print error messages in such a case instead of ending with an NPE or assertion.
Gerd
Date: Tue, 4 Feb 2014 22:06:13 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Problem with turn restriction
Hi Gerd,
I get an exception when running the branch:
java.lang.NullPointerException at
uk.me.parabola.mkgmap.general.RoadNetwork.addRestriction(RoadNetwork.java:275)
at
uk.me.parabola.mkgmap.general.MapDetails.addRestriction(MapDetails.java:130)
at
uk.me.parabola.mkgmap.osmstyle.StyledConverter.createRouteRestrictionsFromPOI(StyledConverter.java:855)
at
uk.me.parabola.mkgmap.osmstyle.StyledConverter.end(StyledConverter.java:587)
at
uk.me.parabola.mkgmap.reader.osm.ElementSaver.convert(ElementSaver.java:239)
at
uk.me.parabola.mkgmap.reader.osm.bin.OsmBinMapDataSource.load(OsmBinMapDataSource.java:67)
at
uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:127)
at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:167) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:63) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:220) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:1) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source)
I'll try again with assertions enabled to find the restriction which causes the problem.
WanMil
no problem.
I also think your patch is also complaining about invalid restrictions with the wrong messages. Attached my proposal.
Gerd
Date: Tue, 4 Feb 2014 21:44:33 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Problem with turn restriction
Arghhh.... I started mkgmap from the wrong workspace. I should have been more alarmed that I got exactly the same number of problems!
Ok, I will try again and hopefully the number of problems will be reduced *very* much.
Sorry!! WanMil
Hi WanMil,
with your patch I see more messages for my Niedersachsen data, but not a single one starts with "Late invalid".
Maybe you are looking at an old result file?
Gerd
> Date: Tue, 4 Feb 2014 21:21:31 +0100 > From: wmgcnfg@web.de > To: mkgmap-dev@lists.mkgmap.org.uk > Subject: Re: [mkgmap-dev] Problem with turn restriction > > Hi Gerd, > > your fixes for 3) were already sorted out by my checks. So relations > without via coord in the bbox were not counted. > > I wonder why your fixes for 1) do not help. I have expected that it > removes some of the 851 problems... > > By the way: > 2) mmh, I don't mind adding that but I think it can be addressed with > very low priority. If there is a street where u-turns are not allowed > the street should be mapped with separate ways for each direction > (that's my opinion - don't know if that matches with the official > mapping guidelines). > > 4) Ok, they can be ignored. Would be great if we can detect them to > output different log messages for them. > > WanMil > > > Hi WanMil, > > > > that's strange. With r3000 I saw many problems for Niedersachen, with > > r3002 only 4, and those were the two examples. > > > > I am downloading latest Germany now. > > > > Gerd > > > > > > > > WanMil wrote > >> Hi Gerd, > >> > >> I think your changes are good. > >> Anyhow for my special purpose I don't see any difference after your fixes. > >> So I will explain what and how I am checking the restrictions (see > >> attached patch with the check code). > >> > >> All restrictions that are valid after loading but which cannot be > >> written to the map because there is a problem when the > >> RestrictionRelation.addRestriction(..) is called are logged with the > >> (not very useful...) text "Late invalid: "+URL of restriction. > >> > >> See relation_problems.txt with the results. There are 851 problems in > >> Germany using the tiles created with attached areas.list. > >> > >> I am not sure if really all logged restrictions are completely valid but > >> all I checked should make its way into the mkgmap compiled map. > >> > >> I hope this helps you to find some other problematic places! > >> > >> WanMil > >> > >>> Hi WanMil, > >>> > >>> up to now I found these reasons for problems: > >>> 1) one error in the branch: via coords were replaced without updating > >>> the corrresponding restrictions and the hash map > >>> 2) "no_u_turn" restrictions were not added > >>> if from-way and to-way are equal. They are evaluated to be valid, but > >>> I don't know if they really make sense? > >>> 3) restrictions are added to the restrictions hash map even if the via > >>> coord is > >>> not contained in the bounding box. > >>> > >>> 4) restrictions that have a from-way or to-way which > >>> is not added with a routable type or not at all, > >>> e.g. way http://www.openstreetmap.org/way/225540783 > >>> has no tags but is part of three restriction relations. > >>> Another example: > >>> http://www.openstreetmap.org/relation/2880411 > >>> refers to ways that are tagged lane=tertiary > >>> and the default style ignores them. > >>> > >>> In high-prec-coords branch r3003 I've fixed 1) to 3), please > >>> check again. > >>> > >>> Gerd > >>> > >>> > >>> > >>> > Date: Mon, 3 Feb 2014 13:01:40 -0800 > >>> > From: > > > >> gpetermann_muenchen@ > > > >>> > To: > > > >> mkgmap-dev@.org > > > >>> > Subject: Re: [mkgmap-dev] Problem with turn restriction > >>> > > >>> > WanMil wrote > >>> > >> I want to make a small statistic why restriction relations become > >>> > >> invalid. Maybe the problem is so seldom that it's not worthy... > >>> > > > >>> > > I have made a short stat with the high-prec branch: > >>> > > There are around 850 relations that are valid > >>> > > (RestrictionRelation.isValid() == true) after loading but that are > >>> not > >>> > > valid when the StyledConverter calls > >>> > > RestrictionRelations.convertRelation(MapCollector ...). > >>> > > So it seems to me as if the problem is greater than expected. > >>> > > >>> > Yes, sounds too much. The only good case that I can think of > >>> > is that the relation is saved by splitter because one of the > >>> > related ways has at least one point within the boundary, but > >>> > another part of the relation is outside of the boundary. > >>> > If the via node is within the tile boundary we should be able > >>> > to create the restriction. > >>> > > >>> > Gerd > >>> > > >>> > > >>> > > >>> > -- > >>> > View this message in context: > >>>
http://gis.19327.n5.nabble.com/Problem-with-turn-restriction-tp5795049p57951...
> >>> > Sent from the Mkgmap Development mailing list archive at Nabble.com. > >>> > _______________________________________________ > >>> > mkgmap-dev mailing list > >>> > > > > >> mkgmap-dev@.org > > > >>> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > >>> > >>> > >>> _______________________________________________ > >>> mkgmap-dev mailing list > >>> > > > >> mkgmap-dev@.org > > > >>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > >>> > >> > >> > >> _______________________________________________ > >> mkgmap-dev mailing list > > > >> mkgmap-dev@.org > > > >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > >> > >> relation_check.patch (1K) > >>
<http://gis.19327.n5.nabble.com/attachment/5795291/0/relation_check.patch>;
> >> areas.list (14K) > >> <http://gis.19327.n5.nabble.com/attachment/5795291/1/areas.list>; > >> relation_problems.txt (71K) > >>
<http://gis.19327.n5.nabble.com/attachment/5795291/2/relation_problems.txt>;
> > > > > > > > > > > > -- > > View this message in context:
http://gis.19327.n5.nabble.com/Problem-with-turn-restriction-tp5795049p57952...
> > 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 > > > > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (5)
-
Andrzej Popowski -
Gerd Petermann -
GerdP
-
Steve Ratcliffe -
WanMil