Mapsource crashes while calculating a route
Hi, I have observed crashes for some time. Mapsource 6.16.3 indicates a bug in module MPL_MAP.CPP. Basecamp reports an error or goes into infinite loop. Now I have extracted minimal source data, which creates faulty map. Removing any road or even a crossing point restore routing. Bug exist in mkgmap r2815, r2857, r2889, r2975 and r2976. Map created by mkgmap r2795 works correctly. I'm attaching here files to reproduce problem: mkgmap.bat - batch, which I have used to create the map, test-a.pbf - very simple OSM source data, route.gpx - short route, which causes a crash in Mapsource. -- Best regards, Andrzej
Hi Andrzej, thanks for reporting. I can reproduce the problem and I see that the display tool claims that there is an error: ERROR: Last point of a joined line without node-flag This error message doesn't show up for the img file created with r2795. In opposite to r2795, the later versions do not split the road with > 250 points in StyledConverter, but later. It seems that the write routine in LinePreparer still needs corrections for this case, it already contains a comment. /* * Current thought is that the node indicator is set when * the point is a node. There's a separate first extra bit * that always appears to be false. The last points' extra bit * is set if the point is a node and *this is not the last* * *polyline making up the road*. * *Todo: special case the last bit* */ @Steve: Did you learn something new regarding this extra bit? If not, I will revert the changes to the line splitting algo. Gerd popej wrote
Hi,
I have observed crashes for some time. Mapsource 6.16.3 indicates a bug in module MPL_MAP.CPP. Basecamp reports an error or goes into infinite loop.
Now I have extracted minimal source data, which creates faulty map. Removing any road or even a crossing point restore routing.
Bug exist in mkgmap r2815, r2857, r2889, r2975 and r2976. Map created by mkgmap r2795 works correctly.
I'm attaching here files to reproduce problem: mkgmap.bat - batch, which I have used to create the map, test-a.pbf - very simple OSM source data, route.gpx - short route, which causes a crash in Mapsource.
-- Best regards, Andrzej
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgm.bat (63 bytes) <http://gis.19327.n5.nabble.com/attachment/5793545/0/mkgm.bat>; route.gpx (1K) <http://gis.19327.n5.nabble.com/attachment/5793545/1/route.gpx>; test-a.pbf (6K) <http://gis.19327.n5.nabble.com/attachment/5793545/2/test-a.pbf>;
-- View this message in context: http://gis.19327.n5.nabble.com/Mapsource-crashes-while-calculating-a-route-t... Sent from the Mkgmap Development mailing list archive at Nabble.com.
On 19/01/14 06:39, GerdP wrote:
/* * Current thought is that the node indicator is set when * the point is a node. There's a separate first extra bit * that always appears to be false. The last points' extra bit * is set if the point is a node and*this is not the last* **polyline making up the road*. **Todo: special case the last bit* */
@Steve: Did you learn something new regarding this extra bit? If not, I will revert the changes to the line splitting algo.
The test in NetCheck does seem not fully correct. I think it is always true that: - the last point of the last line in a NET entry never has the node-flag set. The test in NetCheck is circular because it does not know if the last point in a line is really a 'node'. So it doesn't properly test the condition 'if the point is a node'. Maybe the test is worthless. I will change it so that we only test the last line. ..Steve
Hi Andrzej, with r2977 this problem seems to be fixed @Steve: The display tool netCheck sometimes complains about wrong node-flag settings even when it displays true. It also seems to explect a different logic compared to that used in mkgmap. To me it seems plausible that the logic in mkgmap r2977 is correct. Sample for my Garmin basemap: - 1044224/-3726080(22,40662,-79,95300) true - 1044224/-3726336(22,40662,-79,95850) true - 1044736/-3728256(22,41760,-79,99969) false ERROR: Last point of a joined line without node-flag - 0/4868/66 Type=2 part=2 - 1044736/-3728256(22,41760,-79,99969) false - 1044608/-3728768(22,41486,-80,01068) true - 1044608/-3730304(22,41486,-80,04364) false - 1045376/-3730816(22,43134,-80,05463) false - 1045504/-3731840(22,43408,-80,07660) false - 1046144/-3732864(22,44781,-80,09857) true ERROR: Last point of a joined line without node-flag - 0/4867/31 Type=2 part=3 Gerd Date: Sat, 18 Jan 2014 21:59:33 +0100 From: popej@poczta.onet.pl To: mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] Mapsource crashes while calculating a route Hi, I have observed crashes for some time. Mapsource 6.16.3 indicates a bug in module MPL_MAP.CPP. Basecamp reports an error or goes into infinite loop. Now I have extracted minimal source data, which creates faulty map. Removing any road or even a crossing point restore routing. Bug exist in mkgmap r2815, r2857, r2889, r2975 and r2976. Map created by mkgmap r2795 works correctly. I'm attaching here files to reproduce problem: mkgmap.bat - batch, which I have used to create the map, test-a.pbf - very simple OSM source data, route.gpx - short route, which causes a crash in Mapsource. -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 19/01/14 08:20, Gerd Petermann wrote:
@Steve: The display tool netCheck sometimes complains about wrong node-flag settings even when it displays true.
- 1044224/-3726336(22,40662,-79,95850) true - 1044736/-3728256(22,41760,-79,99969) *false* *ERROR: Last point of a joined line without node-flag* - 0/4868/66 Type=2 part=2 - 1044736/-3728256(22,41760,-79,99969) false - 1044608/-3728768(22,41486,-80,01068) true - 1044608/-3730304(22,41486,-80,04364) false - 1045376/-3730816(22,43134,-80,05463) false - 1045504/-3731840(22,43408,-80,07660) false - 1046144/-3732864(22,44781,-80,09857) *true* E*RROR: Last point of a joined line without node-flag* - 0/4867/31 Type=2 part=3
It is complaining that there is no node-flag on the previous line joining to this one. So I think that the test is correctly doing what it thinks it is doing. As per my previous mail, the check is probably worthless though. Now that I have a NodCheck program, it may be possible to investigate re-doing the test and actually checking if the point is really a node. ..Steve
Hi Steve, I think the problem is somewhere else. Attached is the NetCheck output of r346 with -vv for my Basemap. If I see this right, this line 1046144/-3732864(22,44781,-80,09857) true says that the last point of the part 2 of the road is a node, as well as the last point of part 3: 1059712/-3761664(22,73895,-80,71655) true Maybe line 300 in NetCheck should be lastline.getLastPoint().getId() != 0); instead of line.getLastPoint().getId() != 0); Gerd
Date: Sun, 19 Jan 2014 11:27:41 +0000 From: steve@parabola.me.uk To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Mapsource crashes while calculating a route
On 19/01/14 08:20, Gerd Petermann wrote:
@Steve: The display tool netCheck sometimes complains about wrong node-flag settings even when it displays true.
- 1044224/-3726336(22,40662,-79,95850) true - 1044736/-3728256(22,41760,-79,99969) *false* *ERROR: Last point of a joined line without node-flag* - 0/4868/66 Type=2 part=2 - 1044736/-3728256(22,41760,-79,99969) false - 1044608/-3728768(22,41486,-80,01068) true - 1044608/-3730304(22,41486,-80,04364) false - 1045376/-3730816(22,43134,-80,05463) false - 1045504/-3731840(22,43408,-80,07660) false - 1046144/-3732864(22,44781,-80,09857) *true* E*RROR: Last point of a joined line without node-flag* - 0/4867/31 Type=2 part=3
It is complaining that there is no node-flag on the previous line joining to this one. So I think that the test is correctly doing what it thinks it is doing.
As per my previous mail, the check is probably worthless though.
Now that I have a NodCheck program, it may be possible to investigate re-doing the test and actually checking if the point is really a node.
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
ahh, just understood it. The message is printed at the end of a line segment and it is related to the last point of the previous segment. I think the test is not useful. At least when mkgmap splits a road with > 250 it doesn't care whether the split point is a CoordNode or not and it doesn't change a normal node to a CoordNode, and that seems to be okay. Gerd From: gpetermann_muenchen@hotmail.com To: mkgmap-dev@lists.mkgmap.org.uk Date: Sun, 19 Jan 2014 16:20:53 +0100 Subject: Re: [mkgmap-dev] Mapsource crashes while calculating a route Hi Steve, I think the problem is somewhere else. Attached is the NetCheck output of r346 with -vv for my Basemap. If I see this right, this line 1046144/-3732864(22,44781,-80,09857) true says that the last point of the part 2 of the road is a node, as well as the last point of part 3: 1059712/-3761664(22,73895,-80,71655) true Maybe line 300 in NetCheck should be lastline.getLastPoint().getId() != 0); instead of line.getLastPoint().getId() != 0); Gerd
Date: Sun, 19 Jan 2014 11:27:41 +0000 From: steve@parabola.me.uk To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Mapsource crashes while calculating a route
On 19/01/14 08:20, Gerd Petermann wrote:
@Steve: The display tool netCheck sometimes complains about wrong node-flag settings even when it displays true.
- 1044224/-3726336(22,40662,-79,95850) true - 1044736/-3728256(22,41760,-79,99969) *false* *ERROR: Last point of a joined line without node-flag* - 0/4868/66 Type=2 part=2 - 1044736/-3728256(22,41760,-79,99969) false - 1044608/-3728768(22,41486,-80,01068) true - 1044608/-3730304(22,41486,-80,04364) false - 1045376/-3730816(22,43134,-80,05463) false - 1045504/-3731840(22,43408,-80,07660) false - 1046144/-3732864(22,44781,-80,09857) *true* E*RROR: Last point of a joined line without node-flag* - 0/4867/31 Type=2 part=3
It is complaining that there is no node-flag on the previous line joining to this one. So I think that the test is correctly doing what it thinks it is doing.
As per my previous mail, the check is probably worthless though.
Now that I have a NodCheck program, it may be possible to investigate re-doing the test and actually checking if the point is really a node.
..Steve _______________________________________________ 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
On 19/01/14 15:33, Gerd Petermann wrote:
I think the test is not useful. At least when mkgmap splits a road with > 250 it doesn't care whether the split point is a CoordNode or not and it doesn't change a normal node to a CoordNode, and that seems to be okay.
Yes, it seems that there is nothing special about the last point in a line, apart from the last segment in a NET entry, where the node-flag is always false. I changed the code to remove that error and add one for the last line case. ..Steve
Hi Andrzej,
I can confirm that it fixes routing on my map with 24-bit level 0. I still get similar crashes when using 23-bit for level 0.
Do you get them with the same sample? I don't. For testing, I created a copy of style default and replaced all "resolution 24" by "level 0" and changed the options file to have levels = 0:23, 1:22, 2:20, 3:18 (see attachment ) Gerd
-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, here simple example with 23-bit level 0, where Mapsource crashes. test3-l.osm.pbf - small data with highways only, route23.gpx - route which makes Mapsource crash. I create map executing mkgmap like that: java -jar mkgmap.jar --route --levels=0:23,1:22,2:20,3:18 test3-l.osm.pbf -- Best regards, Andrzej
Hi Andrzej, thanks, I can reproduce the error, will investigate later. Gerd popej wrote
Hi Gerd,
here simple example with 23-bit level 0, where Mapsource crashes.
test3-l.osm.pbf - small data with highways only, route23.gpx - route which makes Mapsource crash.
I create map executing mkgmap like that: java -jar mkgmap.jar --route --levels=0:23,1:22,2:20,3:18 test3-l.osm.pbf
-- Best regards, Andrzej
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
test3-l.osm.pbf (5K) <http://gis.19327.n5.nabble.com/attachment/5793669/0/test3-l.osm.pbf>; route23.gpx (1K) <http://gis.19327.n5.nabble.com/attachment/5793669/1/route23.gpx>;
-- View this message in context: http://gis.19327.n5.nabble.com/Mapsource-crashes-while-calculating-a-route-t... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Andrzej, the problem is this: All routines that prepare the road data are calculating the coordinates in map units (resolution 24). The rounding to resolution 23 happens later. This rounding can produce arcs with two equal points, and that is known to cause crashes. It seems that I was a bit naive to think that routing on resolution < 24 can be done that easy :-( Now I see at least these problems: - we need a factory method that creates Coord instances rounded to the highest used resolution, in your case 23. - we have to make sure that we don't create bounding boxes with coordinates in higher resolution anywhere - maybe we have to add extra logic regarding tile boundaries I'd like to finish the work on the high-prec-coord branch first, so my motivation is low. this really a useful feature? Gerd
Date: Sun, 19 Jan 2014 21:06:16 -0800 From: gpetermann_muenchen@hotmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Mapsource crashes while calculating a route
Hi Andrzej,
thanks, I can reproduce the error, will investigate later.
Gerd
popej wrote
Hi Gerd,
here simple example with 23-bit level 0, where Mapsource crashes.
test3-l.osm.pbf - small data with highways only, route23.gpx - route which makes Mapsource crash.
I create map executing mkgmap like that: java -jar mkgmap.jar --route --levels=0:23,1:22,2:20,3:18 test3-l.osm.pbf
-- Best regards, Andrzej
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
test3-l.osm.pbf (5K) <http://gis.19327.n5.nabble.com/attachment/5793669/0/test3-l.osm.pbf>; route23.gpx (1K) <http://gis.19327.n5.nabble.com/attachment/5793669/1/route23.gpx>;
-- View this message in context: http://gis.19327.n5.nabble.com/Mapsource-crashes-while-calculating-a-route-t... 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,
I'd like to finish the work on the high-prec-coord branch first, so my motivation is low. this really a useful feature?
Thanks for your work. I agree this is low priority. I'm publishing maps of Africa and Asia using 23-bit resolution to make reasonably small mapsets. Would be nice to add routing, but definitely I would prefer to get improvements for standard resolutions first. -- Best regards, Andrzej
Hi Gerd, for some time mkgmap prints following messages, when compiling routable map with 23 bits on layer 0: SEVERE (RoadDef): 29467460.osm.pbf: internal error? The nodeCount doesn't match value calculated by RoadNetWork: (http://www.openstreetmap.org/browse/way/41895544) My guess is, that this is still the same problem, as in this old thread:
All routines that prepare the road data are calculating the coordinates in map units (resolution 24). The rounding to resolution 23 happens later.
I think 23 bits for routable map is not a priority, but maybe you could look at it again? It would be a nice feature for creating maps for car navigation, where details aren't important but size of the map is. -- Best regards, Andrzej
participants (4)
-
Andrzej Popowski -
Gerd Petermann -
GerdP
-
Steve Ratcliffe