mkgmap hangs forever with --link-pois-to-ways --route
Hi, when trying to build a map from the us-west geofabrik extract, mkgmap hangs forever on some tiles. I could strip down the problem reproduceable to the following command: java -Xmx2048M -jar mkgmap.jar --link-pois-to-ways --route 71530048.osm.gz You can find the osm input file at: http://osm.thkukuk.de/files/71530048.osm.gz It's happening with all versions up today beginning from r1867. I haven't tested older versions yet since I don't have jar files. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Hi
It's happening with all versions up today beginning from r1867. I haven't tested older versions yet since I don't have jar files.
It is another manifestation of the bug described here: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q2/011591.html In this case the road name causing the problem is: 'Continental Divide NST'. This name seems to be mostly used on nodes, so is being transferred to the way by the link-pois-to-ways option. I don't know if that is expected behaviour. I'm not sure what to do about the problem as I don't know how essential joining up the roads with the same name is. If it isn't required then we should probably just not do it when the number of such roads is large. ..Steve
It is another manifestation of the bug described here:
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q2/011591.html
To be clear, although that message was discussing a particular case on the branch code, the fact that the routine is extremely slow for large number of identically named roads that are all joined together is a situation that is not unique to the locator branch nor is it recently introduced as far as I know. Particular triggers of the hang may of course be more recent, I'm a bit surprised that it hasn't been reported before. ..Steve
On Wed, Jun 01, Steve Ratcliffe wrote:
It is another manifestation of the bug described here:
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q2/011591.html
To be clear, although that message was discussing a particular case on the branch code, the fact that the routine is extremely slow for large number of identically named roads that are all joined together is a situation that is not unique to the locator branch nor is it recently introduced as far as I know.
What I'm wondering about is, why does this only happen with "--link-pois-to-ways --route" together? If I remove one of the two options, doesn't matter which one, mkgmap needs only 15 seconds to process the tile. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
What I'm wondering about is, why does this only happen with "--link-pois-to-ways --route" together?
The routine that 'hangs' is only called with --route, so you need that. I don't know what --link-pois-to-ways is doing to create all those same name roads, but there are only a handful of roads that have the name normally. There are thousands of nodes with that name and I am assuming that the option causes them to be added to the way somehow. I am not sure how though and it might well be unintentional. ..Steve
Hi
I don't know what --link-pois-to-ways is doing to create all those same name roads, but there are only a handful of roads that have the name normally. There are thousands of nodes with that name and I am assuming that the option causes them to be added to the way somehow. I am not sure how though and it might well be unintentional.
OK I see what happens now. The ways are hiking routes and every node of the way has access=public on it. This results in the way being split up into two node segments, when link-pois-to-ways is specified. The model is, I think, that a node with an access tag is expected to be a some kind of gate/barrier or entrance which regulates the access to the rest of the way. This data breaks that model. ..Steve
participants (2)
-
Steve Ratcliffe -
Thorsten Kukuk