Inter-tile routing now available in trunk
Folks, Robert heroically discovered why the inter-tile routing was not functioning at all well and I believe it's now become quite useful so I have committed the code to the trunk. I appears to work fairly well in mapsource although I have found that for long routes it gives up and draws a straight line even though it can route OK if you add some intervening waypoints. So, more work required but it would be great to get some feedback as to how it's currently performing especially on real gps units. Obviously, if you find this new code has broken the intra-tile routing, it can be backed out. All feedback welcome. Cheers, Mark
On Thu, Feb 19, 2009 at 12:56:24AM +0000, Mark Burton wrote:
I appears to work fairly well in mapsource although I have found that for long routes it gives up and draws a straight line even though it can route OK if you add some intervening waypoints. So, more work required but it would be great to get some feedback as to how it's currently performing especially on real gps units.
I'm finding that crossing a vertical edge of a tile almost never works, but that crossing a horizontal one is fine. So even the simplest route on the same road from west to east takes a long time to calculate and then ends up as a straight line or a very weird route. There is one vertical boundary that seems OK. It has positive longitude, whereas all the others on my mapset have negative longitudes. So that may be something to do with it or just a coincidence. ..Steve
On Feb 19, 2009, at 02:12, Steve Ratcliffe wrote:
There is one vertical boundary that seems OK. It has positive longitude, whereas all the others on my mapset have negative longitudes. So that may be something to do with it or just a coincidence.
Thanks for testing! Being near longitude zero is it, probably, as I was comparing unsigned map units. Could you try r911? Cheers Robert
Hi Robert,
Thanks for testing! Being near longitude zero is it, probably, as I was comparing unsigned map units. Could you try r911?
I'm afraid I don't see any difference with the latest version. Sometimes (but not always) I can route from W/E near the top of a tile. I'll look for more patterns. Cheers, ..Steve
On Feb 19, 2009, at 22:07, Steve Ratcliffe wrote:
Thanks for testing! Being near longitude zero is it, probably, as I was comparing unsigned map units. Could you try r911?
I'm afraid I don't see any difference with the latest version.
Sometimes (but not always) I can route from W/E near the top of a tile. I'll look for more patterns.
Ok, that's too bad. There's a clear difference between W/E and N/S since the boundary nodes are sorted first by longitude, then by latitude. So NOD 3 starts with the left edge from bottom to top, then the top and bottom edges mixed together, and finally the right edge from bottom to top. This appears to agree with what other maps look like, though I may be missing something. One thing to check would be whether the boundary nodes in adjacent tiles actually match up, or whether we've got a bug somewhere. Cheers Robert
On Feb 19, 2009, at 22:15, Robert Vollmert wrote:
There's a clear difference between W/E and N/S since the boundary nodes are sorted first by longitude, then by latitude. So NOD 3 starts with the left edge from bottom to top, then the top and bottom edges mixed together, and finally the right edge from bottom to top.
This is totally not what's actually happening near negative coordinates... I'll try to figure it out. Cheers Robert
On Thu, Feb 19, 2009 at 10:15:29PM +0100, Robert Vollmert wrote:
On Feb 19, 2009, at 22:07, Steve Ratcliffe wrote:
I'm afraid I don't see any difference with the latest version.
Sometimes (but not always) I can route from W/E near the top of a tile. I'll look for more patterns.
Ok, that's too bad.
OK I think the problem is that the boundary nodes on the E side of the tile are missing. ..Steve
On Thu, Feb 19, 2009 at 10:17:50PM +0000, Steve Ratcliffe wrote:
OK I think the problem is that the boundary nodes on the E side of the tile are missing.
So I've found that this is because the line is clipped twice and the second time is after the boundard node has been set which gets replaced again. Not sure why that doesn't happen on max Lat as well -- or perhaps it does and doesn't matter. So the following patch fixes it, although I think the right solution would be to move the code that fixes the roads up after being split into a LineAdder. Index: src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java =================================================================== --- src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java (revision 913) +++ src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java Thu Feb 19 23:20:25 GMT 2009 @@ -513,7 +519,8 @@ road.setInternalNodes(hasInternalNodes); } - clipper.clipLine(road, lineAdder); + lineAdder.add(road); + //clipper.clipLine(road, lineAdder); if(trailingWay != null) addRoadWithoutLoops(trailingWay, gt);
On Thu, 19 Feb 2009 23:33:58 +0000 Steve Ratcliffe <steve@parabola.demon.co.uk> wrote:
On Thu, Feb 19, 2009 at 10:17:50PM +0000, Steve Ratcliffe wrote:
OK I think the problem is that the boundary nodes on the E side of the tile are missing.
So I've found that this is because the line is clipped twice and the second time is after the boundard node has been set which gets replaced again. Not sure why that doesn't happen on max Lat as well -- or perhaps it does and doesn't matter.
Ah, yes. I remember looking at that and thinking "best not clip it twice" and then I forgot to do anything about it. Sorry.
So the following patch fixes it, although I think the right solution would be to move the code that fixes the roads up after being split into a LineAdder.
Not sure I understand what you're driving at here, which code do you think should be moved? Cheers, Mark
I'm afraid I don't see any difference with the latest version.
Sometimes (but not always) I can route from W/E near the top of a tile. I'll look for more patterns.
I've tried now with r942 on a etrex and seen the following: Crossing S/N borders seems to be no problem, routing gives more or less reasonable routes. Crossing E/W borders doesn't work ok, as described by others too. In my case it alway finds a route, but the route is really not optimal. The inter tile crossing always takes place at a highway or a secondary one, even if start and destination are only a few kilometers appart and far from a highway. My impression is, that routing on E/W borders doesn't work at all, but takes place at the basemap instead. I've verified with two different start/destination pairs. Crossing borders in E/W takes only place, if roads in the basemap are available.
Hi Johann,
My impression is, that routing on E/W borders doesn't work at all, but takes place at the basemap instead.
I've verified with two different start/destination pairs. Crossing borders in E/W takes only place, if roads in the basemap are available.
I have just tested a German map using mapsource and can route from W to E across a tile boundary from a place called Zedwitz to Trogen (a few Km) - it's crossing the boundary using a residential street. Also, the reverse route works as well. If I switch to the basemap in mapsource it just draws a straight line between the end points. Do your problems also occur in mapsource or just on the etrex? I shall now put the same map on my etrex and see if it routes across the boundary OK. Cheers, Mark
I have just tested a German map using mapsource and can route from W to E across a tile boundary from a place called Zedwitz to Trogen (a few Km) - it's crossing the boundary using a residential street.
Also, the reverse route works as well.
If I switch to the basemap in mapsource it just draws a straight line between the end points.
Do your problems also occur in mapsource or just on the etrex?
Hi Mark, thanks for your support. I have no mapsource running here but testing all on the etrex venture. I use a map of bavaria (some weeks old), downloaded from geofabrik, splitted with Splitter into four tiles automatically. I'm using the latest R942 without modifications. Inter-tile routing has never worked for me, but I thought this is the case elsewhere too, so not mentioned to the mailing list. Intra-tile routing works as expected, even if it shows me sometimes suboptimal routes, but I think this is caused by the osm data. Later I will reboot my system to windows, then I will test with mapsource.
Johann Gail wrote:
I'm afraid I don't see any difference with the latest version.
Sometimes (but not always) I can route from W/E near the top of a tile. I'll look for more patterns.
I've tried now with r942 on a etrex and seen the following:
Crossing S/N borders seems to be no problem, routing gives more or less reasonable routes.
Crossing E/W borders doesn't work ok, as described by others too. In my case it alway finds a route, but the route is really not optimal. The inter tile crossing always takes place at a highway or a secondary one, even if start and destination are only a few kilometers appart and far from a highway.
My impression is, that routing on E/W borders doesn't work at all, but takes place at the basemap instead.
I've removed the basemap from my 605 and have the same East/West problems so I can't see how it can be doing that. As I've already commented what I saw was that when routing east I would be directed along primary roads until I'd crossed the tile boundary (I didn't measure this exactly but it was close) and then directly to the motorway after which the given route was what I would have chosen myself
I've verified with two different start/destination pairs. Crossing borders in E/W takes only place, if roads in the basemap are available.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
I don't know what else to say really. I know this is a work in progress and am happy with results so far. Inter-tile routing was never going to be easy Cheers Paul
I've tried now with r942 on a etrex and seen the following:
Crossing S/N borders seems to be no problem, routing gives more or less reasonable routes.
Crossing E/W borders doesn't work ok, as described by others too. In my case it alway finds a route, but the route is really not optimal. The inter tile crossing always takes place at a highway or a secondary one, even if start and destination are only a few kilometers appart and far from a highway.
My impression is, that routing on E/W borders doesn't work at all, but takes place at the basemap instead.
I've removed the basemap from my 605 and have the same East/West problems so I can't see how it can be doing that. As I've already commented what I saw was that when routing east I would be directed along primary roads until I'd crossed the tile boundary (I didn't measure this exactly but it was close) and then directly to the motorway after which the given route was what I would have chosen myself
So you have the same effect, that routing over borders takes always highways, even without a basemap on the device.
I've verified with two different start/destination pairs. Crossing borders in E/W takes only place, if roads in the basemap are available.
Ok, the difference may then be only the road type primary one. As all primarys are in the basemap too, it is hard to distinguish.
I don't know what else to say really. I know this is a work in progress and am happy with results so far. Inter-tile routing was never going to be easy
I think it is only a small detail missing, as routing in S/N direction works fine already.
Johann Gail wrote:
I've tried now with r942 on a etrex and seen the following:
Crossing S/N borders seems to be no problem, routing gives more or less reasonable routes.
Crossing E/W borders doesn't work ok, as described by others too. In my case it alway finds a route, but the route is really not optimal. The inter tile crossing always takes place at a highway or a secondary one, even if start and destination are only a few kilometers appart and far from a highway.
My impression is, that routing on E/W borders doesn't work at all, but takes place at the basemap instead.
I've removed the basemap from my 605 and have the same East/West problems so I can't see how it can be doing that. As I've already commented what I saw was that when routing east I would be directed along primary roads until I'd crossed the tile boundary (I didn't measure this exactly but it was close) and then directly to the motorway after which the given route was what I would have chosen myself
So you have the same effect, that routing over borders takes always highways, even without a basemap on the device.
I've verified with two different start/destination pairs. Crossing borders in E/W takes only place, if roads in the basemap are available.
Ok, the difference may then be only the road type primary one. As all primarys are in the basemap too, it is hard to distinguish.
I don't know what else to say really. I know this is a work in progress and am happy with results so far. Inter-tile routing was never going to be easy
I think it is only a small detail missing, as routing in S/N direction works fine already. _______________________________________________
It's time to eat humble pie. I managed to create a single tile with all the places and roads on that I've been testing and this chooses exactly the same route as the inter-tile file. It seems it was just a coincidence that the routes hit the motorway around the tile boundary. I'm currently experimenting with different options for motorway speed and primary road class and speed as the routes being selected are (for me anyway) far from optimal Apologies for the misleading info Cheers Paul
Hi Paul,
It's time to eat humble pie. I managed to create a single tile with all the places and roads on that I've been testing and this chooses exactly the same route as the inter-tile file. It seems it was just a coincidence that the routes hit the motorway around the tile boundary.
OK.
I'm currently experimenting with different options for motorway speed and primary road class and speed as the routes being selected are (for me anyway) far from optimal
Yes, I think that is the key to getting good routes. Somehow, you need to make the GPS want to use the motorways rather than the trunk roads.
Apologies for the misleading info
No problem, it's still early days yet for the ITR so I am expecting issues. Cheers, Mark
2009/2/28 Mark Burton <markb@ordern.com>:
Yes, I think that is the key to getting good routes. Somehow, you need to make the GPS want to use the motorways rather than the trunk roads.
As long as we're on the topic of speed profiles of road types - I've seen a case where my Nuvi needs to route from one motorway to another. It's basically the route as shown here: http://data.giub.uni-bonn.de/openrouteservice/index.php?start=-6.2430356,53.... You can see here that OpenRouteService chooses a sub-optimal route, in favouring a short spell on the roundabout over a longer stretch (leading to an overall shorter route) on a motorway_link. In any case, the Nuvi makes the same mistake. Do roundabouts need to be de-prioritised somehow? Dermot -- -------------------------------------- Iren sind menschlich
Dermot McNally wrote:
2009/2/28 Mark Burton <markb@ordern.com>:
Yes, I think that is the key to getting good routes. Somehow, you need to make the GPS want to use the motorways rather than the trunk roads.
As long as we're on the topic of speed profiles of road types - I've seen a case where my Nuvi needs to route from one motorway to another. It's basically the route as shown here:
http://data.giub.uni-bonn.de/openrouteservice/index.php?start=-6.2430356,53....
You can see here that OpenRouteService chooses a sub-optimal route, in favouring a short spell on the roundabout over a longer stretch (leading to an overall shorter route) on a motorway_link.
In any case, the Nuvi makes the same mistake. Do roundabouts need to be de-prioritised somehow?
Dermot
I have to say that I've not seen this before. Whenever I encounter a similar situation there's no problem. See below for an example. http://data.giub.uni-bonn.de/openrouteservice/index.php?start=-6.2430356,53.... Your example clearly behaves differently but I can see no reason for it. If I had to guess I'd say that it's due to the very shallow angle between the start of the link road and the main carriageway as I can't see any reason for it in the data Additionally the following shows that for the same roundabout approaching from the South then the behaviour is as expected http://data.giub.uni-bonn.de/openrouteservice/index.php?start=-6.2430356,53.... Cheers Paul
2009/3/2 Paul <news@pointdee.co.uk>:
Your example clearly behaves differently but I can see no reason for it. If I had to guess I'd say that it's due to the very shallow angle between the start of the link road and the main carriageway as I can't see any reason for it in the data
One change I have made is to add traffic signals to the roundabout (they exist in reality at that junction). Are they considered for route optimisation? Dermot -- -------------------------------------- Iren sind menschlich
Hi Dermot,
One change I have made is to add traffic signals to the roundabout (they exist in reality at that junction). Are they considered for route optimisation?
No, the GPS doesn't know about the traffic signals - garmin doesn't have a code for them - I guess there's no traffic signals in the USA! Cheers, Mark
No, the GPS doesn't know about the traffic signals - garmin doesn't have a code for them - I guess there's no traffic signals in the USA!
Maybe it is possible to do it by some tricks. You have discovered is that there appears to be a time penalty for going around sharp junctions. Maybe there are some other conditions for a time penalty. I would not say that we should set two nodes with a sharp angle at each traffic light, but maybe we can tweak it a similar way. It would also be thinkable that there is another unknown section, like the turn restricition area, which contains additional information per node.
Dermot McNally wrote:
2009/3/2 Paul <news@pointdee.co.uk>:
Your example clearly behaves differently but I can see no reason for it. If I had to guess I'd say that it's due to the very shallow angle between the start of the link road and the main carriageway as I can't see any reason for it in the data
One change I have made is to add traffic signals to the roundabout (they exist in reality at that junction). Are they considered for route optimisation?
Dermot
One change I've just made is to reverse the direction of the link from the M32 on to the same roundabout under discussion as it had the oneway flag set but was pointing east so anyone on the M32 heading west couldn't get off at that point (so there was an error in the data but it wouldn't make any difference to the original question) Cheers Paul
2009/3/2 Paul <news@pointdee.co.uk>:
One change I've just made is to reverse the direction of the link from the M32 on to the same roundabout under discussion as it had the oneway flag set but was pointing east so anyone on the M32 heading west couldn't get off at that point (so there was an error in the data but it wouldn't make any difference to the original question) - Show quoted text -
Grr! Thanks for that. I was sure I'd checked that junction several times. Did you also remove the oneway=no on the M32 "mainline" (some mainline...)? I've put it back, as every so often somebody threatens to treat motorway ways as default oneway=true, and this one isn't. Thanks, Dermot PS: This is another interesting case where the generic roundabout type is a nuisance - this roundabout is under motorway restrictions. -- -------------------------------------- Iren sind menschlich
Dermot McNally wrote:
2009/3/2 Paul <news@pointdee.co.uk>:
One change I've just made is to reverse the direction of the link from the M32 on to the same roundabout under discussion as it had the oneway flag set but was pointing east so anyone on the M32 heading west couldn't get off at that point (so there was an error in the data but it wouldn't make any difference to the original question) - Show quoted text -
Grr! Thanks for that. I was sure I'd checked that junction several times. Did you also remove the oneway=no on the M32 "mainline" (some mainline...)? I've put it back, as every so often somebody threatens to treat motorway ways as default oneway=true, and this one isn't.
Yes I did remove the oneway tag but I can see where you're coming from although I can't recall ever seeing a oneway=no tag before and it would be a brave (read foolhardy) gesture to suddenly declare all motorways one way without checking each and every one first.
Thanks, Dermot
PS: This is another interesting case where the generic roundabout type is a nuisance - this roundabout is under motorway restrictions.
Cheers Paul
Paul schrieb:
Johann Gail wrote:
I've tried now with r942 on a etrex and seen the following:
Crossing S/N borders seems to be no problem, routing gives more or less reasonable routes.
Crossing E/W borders doesn't work ok, as described by others too. In my case it alway finds a route, but the route is really not optimal. The inter tile crossing always takes place at a highway or a secondary one, even if start and destination are only a few kilometers appart and far from a highway.
My impression is, that routing on E/W borders doesn't work at all, but takes place at the basemap instead.
I've removed the basemap from my 605 and have the same East/West problems so I can't see how it can be doing that. As I've already commented what I saw was that when routing east I would be directed along primary roads until I'd crossed the tile boundary (I didn't measure this exactly but it was close) and then directly to the motorway after which the given route was what I would have chosen myself
Ok, the difference may then be only the road type primary one. As all primarys are in the basemap too, it is hard to distinguish.
It's time to eat humble pie. I managed to create a single tile with all the places and roads on that I've been testing and this chooses exactly the same route as the inter-tile file. It seems it was just a coincidence that the routes hit the motorway around the tile boundary.
I cant believe that, but will experiment with it later. In my case I choose start and end left and right from the border, with a distance of only a few km. The next primary road is about 15km away. I cant believe, that it is only a matter of optimization, as there is nearly a straight connection (lower order) between the two places. I will try to get this area in a single tile and see what happens.
I'm currently experimenting with different options for motorway speed and primary road class and speed as the routes being selected are (for me anyway) far from optimal
In general i can admit, that the choosen routes are not always optimal but at least reasonable.
It's time to eat humble pie. I managed to create a single tile with all the places and roads on that I've been testing and this chooses exactly the same route as the inter-tile file. It seems it was just a coincidence that the routes hit the motorway around the tile boundary.
Sorry, my testing gaves other results. If I create a map with two tiles, then border crossing takes place at a secondary street with a rather inoptimal route. If I compile the same map into on single tile, then routing works as expected. So i conclude that definitely something with the inter-tile routing gets wrong. It is not the osm data. All tests are done on a etrex venture, as I have no running mapsource here.
Hi Johann,
It's time to eat humble pie. I managed to create a single tile with all the places and roads on that I've been testing and this chooses exactly the same route as the inter-tile file. It seems it was just a coincidence that the routes hit the motorway around the tile boundary.
Sorry, my testing gaves other results. If I create a map with two tiles, then border crossing takes place at a secondary street with a rather inoptimal route. If I compile the same map into on single tile, then routing works as expected.
So i conclude that definitely something with the inter-tile routing gets wrong. It is not the osm data.
All tests are done on a etrex venture, as I have no running mapsource here.
Fine, I believe you. Unless you provide some example data to inspect, it's hard for us to guess what's wrong. Please provide the detailed info. Cheers, mark
On Mar 1, 2009, at 00:21, Johann Gail wrote:
It's time to eat humble pie. I managed to create a single tile with all the places and roads on that I've been testing and this chooses exactly the same route as the inter-tile file. It seems it was just a coincidence that the routes hit the motorway around the tile boundary.
Sorry, my testing gaves other results. If I create a map with two tiles, then border crossing takes place at a secondary street with a rather inoptimal route. If I compile the same map into on single tile, then routing works as expected.
So you have a residential crossing a boundary that's not routed through, right? If you try to route just from one end of that street to the other, the route also takes a detour? If that's the case, things I'd try to check next were: * running both tiles through test.display.NodDisplay, does the point where the road crosses the boundary occur in NOD3? * do things improve if you thin out the residential (in the .osm, before passing to mkgmap) so nodes aren't too close, and there's no nodes close to the boundary Cheers Robert
Robert Vollmert schrieb:
On Mar 1, 2009, at 00:21, Johann Gail wrote:
It's time to eat humble pie. I managed to create a single tile with all the places and roads on that I've been testing and this chooses exactly the same route as the inter-tile file. It seems it was just a coincidence that the routes hit the motorway around the tile boundary.
Sorry, my testing gaves other results. If I create a map with two tiles, then border crossing takes place at a secondary street with a rather inoptimal route. If I compile the same map into on single tile, then routing works as expected.
So you have a residential crossing a boundary that's not routed through, right? Its not a residential, but a minor street connecting two villages. I can set the start on this street, the destination on the *same* street beyond the border and it will not route over the border. Instead it will choose a route 30km longer with a secondary crossing the border.
Even if a switch from car routing to pedestrian routing there will be no change. It routes me slightly different, but also crosses the border at the secondary street.
If you try to route just from one end of that street to the other, the route also takes a detour? Even if I exchange start and end then no routing is possible on this street. If that's the case, things I'd try to check next were: * running both tiles through test.display.NodDisplay, does the point where the road crosses the boundary occur in NOD3? * do things improve if you thin out the residential (in the .osm, before passing to mkgmap) so nodes aren't too close, and there's no nodes close to the boundary
I will try that later today. I have noted, that there is a point on the street 5m appart from the border node.
Hi Robert, On Sun, 1 Mar 2009 09:17:43 +0100 Robert Vollmert <rvollmert-lists@gmx.net> wrote:
* running both tiles through test.display.NodDisplay, does the point where the road crosses the boundary occur in NOD3?
Johann sent me some sample data and I checked that the boundary node records in the two tiles in the sample matched up. They did, the coordinates of the nodes on the E side of the W tile exactly matched the coordinates of the nodes on the W side of the E tile. I also tried routing across the boundary using my etrex and didn't see any oddness. This evening, I hope to do some more testing in case I was just lucky! Cheers, Mark
Hi Mark, thank you for testing the map at your etrex, this was the final hint. I had success!! :-)) It was a setting in the routing options. Einstellung -> Routing -> Straßennavigation -> Fahrgemeinschaftsspuren (Settings -> Rounting -> Road Navigation -> multiuser?? lanes (dont know the english word, last checkbox at bottom)) This was set on my etrex. With this option set it comes to the obscure routing only at secondaries. Whitout this setting routing works very well. Thank you again. This would mean, that there is some information in the nod network isn't set correctly.
I also tried routing across the boundary using my etrex and didn't see any oddness. This evening, I hope to do some more testing in case I was just lucky!
Cheers,
Mark
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev .
On Sun, Mar 1, 2009 at 8:53 PM, Johann Gail <johann.gail@gmx.de> wrote:
Einstellung -> Routing -> Straßennavigation -> Fahrgemeinschaftsspuren (Settings -> Rounting -> Road Navigation -> multiuser?? lanes (dont know the english word, last checkbox at bottom))
FYI, the translation of "Fahrgemeinschaftsspuren" is "Carpool lanes". Cheers.
On Fri, 27 Feb 2009, Johann Gail wrote:
I've tried now with r942 on a etrex and seen the following:
Crossing E/W borders doesn't work ok, as described by others too.
I just tried that on my StreetPilot c510 and do not have difficulties to get a route across E/W boundaries. Do different Garmins have different routing engines? -Wolfgang
I'm seeing very similar behaviour to this. Travelling North/South or South/North across a boundary seems to work fine but East/West or West/East fails. Picking North/South source/destinations I can route a considerable distance but there is a point where I can route to a town but not to the next town 5 miles further away. I have heard of a 13000 point limit on Garmin devices so this is possibly what I'm seeing here as the destinations are all on the same tile. From where I am then routing into Scotland is North/South boundary and Wales is on the same tile so this all works fine If I use the individual England, Scotland, Wales files rather than the combined great_britain and combine then with mkgmap then routing into Wales (East/West junction so would fail anyway) or Scotland (North/South) simply fails. Is this possibly related to the way in which the individual country files are created from the raw data. I don't have to run splitter against Scotland or Wales but do against England When it fails my 605 simply says "Route calculation error" and returns me to a map of my starting location Paul Steve Ratcliffe wrote:
On Thu, Feb 19, 2009 at 12:56:24AM +0000, Mark Burton wrote:
I appears to work fairly well in mapsource although I have found that for long routes it gives up and draws a straight line even though it can route OK if you add some intervening waypoints. So, more work required but it would be great to get some feedback as to how it's currently performing especially on real gps units.
I'm finding that crossing a vertical edge of a tile almost never works, but that crossing a horizontal one is fine.
So even the simplest route on the same road from west to east takes a long time to calculate and then ends up as a straight line or a very weird route.
There is one vertical boundary that seems OK. It has positive longitude, whereas all the others on my mapset have negative longitudes. So that may be something to do with it or just a coincidence.
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On Feb 19, 2009, at 17:09, Paul wrote:
I'm seeing very similar behaviour to this. Travelling North/South or South/North across a boundary seems to work fine but East/West or West/East fails. Picking North/South source/destinations I can route a considerable distance but there is a point where I can route to a town but not to the next town 5 miles further away. I have heard of a 13000 point limit on Garmin devices so this is possibly what I'm seeing here as the destinations are all on the same tile. From where I am then routing into Scotland is North/South boundary and Wales is on the same tile so this all works fine
This is with r911 or newer?
If I use the individual England, Scotland, Wales files rather than the combined great_britain and combine then with mkgmap then routing into Wales (East/West junction so would fail anyway) or Scotland (North/South) simply fails. Is this possibly related to the way in which the individual country files are created from the raw data. I don't have to run splitter against Scotland or Wales but do against England
This is to be expected. Inter-tile routing only works if the tiles were created from one osm-file with one run of the splitter. Cheers Robert
Robert Vollmert wrote:
On Feb 19, 2009, at 17:09, Paul wrote:
I'm seeing very similar behaviour to this. Travelling North/South or South/North across a boundary seems to work fine but East/West or West/East fails. Picking North/South source/destinations I can route a considerable distance but there is a point where I can route to a town but not to the next town 5 miles further away. I have heard of a 13000 point limit on Garmin devices so this is possibly what I'm seeing here as the destinations are all on the same tile. From where I am then routing into Scotland is North/South boundary and Wales is on the same tile so this all works fine
This is with r911 or newer?
r911. I can try with the latest revision tomorrow.
If I use the individual England, Scotland, Wales files rather than the combined great_britain and combine then with mkgmap then routing into Wales (East/West junction so would fail anyway) or Scotland (North/South) simply fails. Is this possibly related to the way in which the individual country files are created from the raw data. I don't have to run splitter against Scotland or Wales but do against England
This is to be expected. Inter-tile routing only works if the tiles were created from one osm-file with one run of the splitter.
I expected so but thought I'd mention it Cheers Paul
Cheers Robert
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On Thu, Feb 19, 2009 at 1:56 AM, Mark Burton <markb@ordern.com> wrote:
Robert heroically discovered why the inter-tile routing was not functioning at all well and I believe it's now become quite useful so I have committed the code to the trunk.
Thanks! I just recompiled a map of Germany with r911: I am very happy to report that inter-tile routing does work for my initial, simple test cases in Mapsource.
I appears to work fairly well in mapsource although I have found that for long routes it gives up and draws a straight line even though it can route OK if you add some intervening waypoints.
I can also confirm this behaviour: in a test crossing multiple tiles over a long distance (from Heilbronn to Cologne), Mapsource attempted several recalculations and then drew a straight line from start to destination. When I added an additional point to the route, Mapsource immediately recalculated the route correctly. Later on, I'll try some further tests on my GPS unit. It's great to finally have this feature -- even with small inconveniences. Cheers.
On Feb 19, 2009, at 11:57, Clinton Gladstone wrote:
I appears to work fairly well in mapsource although I have found that for long routes it gives up and draws a straight line even though it can route OK if you add some intervening waypoints.
I can also confirm this behaviour: in a test crossing multiple tiles over a long distance (from Heilbronn to Cologne), Mapsource attempted several recalculations and then drew a straight line from start to destination. When I added an additional point to the route, Mapsource immediately recalculated the route correctly.
If you shift this additional point towards the destination, is there a specific point where it starts going wrong? One possibility is that the routes are just getting too long. I remember somebody saying there's a limit on the number of legs when routing using Garmin units. This might be fixed by writing so-called links (shortcuts in the routing graph), which we're not doing at all at the moment. Unfortunately, they're less well understood. If there's a problem routing from Heilbronn to Cologne, it'd be interesting to see if that also shows up within a single tile. Say, a tile with all of Heilbronn and Cologne, but only motorways in between. Cheers Robert
On Thu, Feb 19, 2009 at 12:19 PM, Robert Vollmert <rvollmert-lists@gmx.net> wrote:
If you shift this additional point towards the destination, is there a specific point where it starts going wrong?
It seems that as I approach or cross the boundary to the last tile, the route starts to go wrong (the route crosses four tiles in total). I will try to create a better test case, which can be more easily reproduced. So far the behaviour seems to be as follows: 1. If the additional point is well inside the second-last tile, the route is calculated correctly. 2. If the additional point is close to the tile boundaries of the last and second-last tiles, the route is calculated as two straight lines. 3. If the additional point is well inside the last tile, the route is a straight line from the start to the additional point, but the route is calculated correctly from the additional point to the destination.
One possibility is that the routes are just getting too long. I remember somebody saying there's a limit on the number of legs when routing using Garmin units.
I tested the same route on a map created with cGPSmapper which was produced with similar, but older OSM data (available here: http://emexes.powweb.com/osm/). In this case, the route was calculated correctly. I am however not sure what can be deduced from this observation. Thanks again!
On Feb 19, 2009, at 13:18, Clinton Gladstone wrote:
On Thu, Feb 19, 2009 at 12:19 PM, Robert Vollmert
If you shift this additional point towards the destination, is there a specific point where it starts going wrong?
Thanks for testing!
It seems that as I approach or cross the boundary to the last tile, the route starts to go wrong (the route crosses four tiles in total).
So it's definitely a tiling-related issue. Are you seeing a difference between north/south and east/west edges, also? Cheers Robert
0> In article <20090219005624.45521b2e@crow>, 0> Mark Burton <URL:mailto:markb@ordern.com> ("Mark") wrote: Mark> Robert heroically discovered why the inter-tile routing was not Mark> functioning at all well and I believe it's now become quite Mark> useful so I have committed the code to the trunk. Thanks. I've just given it a quick spin on my eTrex (Legend HCx if it matters). I gave it the longest journey I regularly do - Cambridge to Lochcarron - and it came up with a sensible route via A1, A696, A68, M90 and A86 (amongst others). However, I normally drive via A66 and Penrith, so I tried adding an intermediate route point at a friend's house in Penrith. The unit spent about 10 minutes at "100%" and then gave me a basemap route; I tried routing from Cambridge to my friend (and then from Cambridge to an arbitrary point on the motorway nearby), and these both failed the same way. So I suspect a problem with that tile. I *may* still have the areas file from the splitter (if it's not been overwritten by generating new contours - as splitter always uses the same file name), if that would be useful. It definitely works enough to be useful, but I think one or two gremlins must remain.
Hi Toby,
Thanks. I've just given it a quick spin on my eTrex (Legend HCx if it matters). I gave it the longest journey I regularly do - Cambridge to Lochcarron - and it came up with a sensible route via A1, A696, A68, M90 and A86 (amongst others).
That's good.
However, I normally drive via A66 and Penrith, so I tried adding an intermediate route point at a friend's house in Penrith. The unit spent about 10 minutes at "100%" and then gave me a basemap route; I tried routing from Cambridge to my friend (and then from Cambridge to an arbitrary point on the motorway nearby), and these both failed the same way. So I suspect a problem with that tile.
Not so good!
I *may* still have the areas file from the splitter (if it's not been overwritten by generating new contours - as splitter always uses the same file name), if that would be useful.
Please zip it up and email directly to me if you still have it.
It definitely works enough to be useful, but I think one or two gremlins must remain.
Agreed. Cheers, Mark
Here's the areas list file - I know it's the right one because the map IDs match the roads tiles of my maps. Perhaps it would be nice if splitter used the map id for part of the file name?
0> In article <87vdr662ex.fsf@balti.rawlyn.homeip.net>, 0> Toby Speight <URL:mailto:T.M.Speight.90@cantab.net> ("Toby") wrote: Toby> Here's the areas list file ... That was supposed to be a personal reply - got caught out by the broken Reply-To header; sorry!
Still seeing issues, now using build 915 - it starts with an OSM route, then becomes goes straight from Colsterworth roundabout ("2nd exit to A1") to Worsley ("Right on M61). It does estimate 2 hours between the two, and it may be relevant that this segment crosses an east-west boundary (and west of the prime meridian). I routed the reverse journey, and after very long calculation ended up with something similar - though it was now the beginning that's routed on the basemap (i.e. the same area as in the forward journey). I'm using a GB extract[1], split with splitter.jar. Is it possible that the sort criterion is not as presumed on the east and west sides of tiles? [1] <URL: http://download.geofabrik.de/osm/europe/great_britain.osm.bz2 >
I'm using a GB extract[1], split with splitter.jar.
Is it possible that the sort criterion is not as presumed on the east and west sides of tiles?
[1] <URL: http://download.geofabrik.de/osm/europe/great_britain.osm.bz2 > _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
can you give all the commands and options you used ? -- Wikipedia -- http://tools.wikimedia.de/~flacus/IWLC/ OSM -- http://osm.flacus.de/
I'm using a GB extract[1], split with splitter.jar.
Is it possible that the sort criterion is not as presumed on the east and west sides of tiles?
0> In article <a79e09370902200601h6bce35dbi3c5fde0fd74d0c64@mail.gmail.com>, 0> FlaBot <URL:mailto:flabot@googlemail.com> ("Flabot") wrote: Flabot> can you give all the commands and options you used ? curl -s -S -o great_britain.osm.bz2 -z great_britain.osm.bz2 'http://download.geofabrik.de/osm/europe/great_britain.osm.bz2' bunzip2 -c great_britain.osm.bz2 >uk.osm rm -f 63240???.osm.gz && java -Xmx3500m -jar splitter.jar --max-nodes=1200000 --mapname=63240001 uk.osm java -Xmx3500m -jar /home/tms/maps/mkgmap-routing/trunk/dist/mkgmap.jar --description="UK" --latin1 --style-file=toby-style --net --route --country-name="UNITED KINGDOM" --country-abbr="GBR" --family-id=6324 --product-id=6324 --area-name="Great Britain" --family-name="Open Streetmap" --gmapsupp --net --route 63240???.osm.gz 50??????.osm.gz
On Thu, 19 Feb 2009, Mark Burton wrote:
So, more work required but it would be great to get some feedback as to how it's currently performing especially on real gps units.
I hope I'm not too late, but development here is faster than I can read this list. :-) I made a test map of Germany composed of rectangular tiles from europe.osm using r918. Routing works fine on my StreetPilot c510 for almost any destination and the chosen route is always reasonable. (Routing in MapSource is unusable, but you knew that already.) The only case where it doesn't work is when the destination of a long route is in a tile corner at the map border. If you start closer to the same destination it is able to find the route. I would guess that this is simply due to the cuts in the road network near the destination and Garmins preference for highways over long distances. -Wolfgang
Hi Wolfgang,
I hope I'm not too late, but development here is faster than I can read this list. :-)
No, you're not too late - it's still "early days" for the inter-tile routing.
I made a test map of Germany composed of rectangular tiles from europe.osm using r918. Routing works fine on my StreetPilot c510 for almost any destination and the chosen route is always reasonable. (Routing in MapSource is unusable, but you knew that already.)
The only case where it doesn't work is when the destination of a long route is in a tile corner at the map border. If you start closer to the same destination it is able to find the route. I would guess that this is simply due to the cuts in the road network near the destination and Garmins preference for highways over long distances.
Well, that's the kind of feedback I like. Sounds like it's working well for you. If you want to test another new feature, there's a patch (posted yesterday) that provides support for turn restrictions. It's not yet checked into the SVN but if you can apply the patch to the latest SVN code and try it out, I would be grateful. Cheers, Mark
On Tue, Feb 24, 2009 at 2:21 AM, Wolfgang v. Hansen <wvhansen@fom.fgan.de>wrote:
On Thu, 19 Feb 2009, Mark Burton wrote:
So, more work required but it would be great to get some feedback as to
how it's currently performing especially on real gps units.
I hope I'm not too late, but development here is faster than I can read this list. :-)
same here, amazing progress! issues are fixed before I can report them
I made a test map of Germany composed of rectangular tiles from europe.osm using r918. Routing works fine on my StreetPilot c510 for almost any destination and the chosen route is always reasonable. (Routing in MapSource is unusable, but you knew that already.)
The only case where it doesn't work is when the destination of a long route is in a tile corner at the map border. If you start closer to the same destination it is able to find the route. I would guess that this is simply due to the cuts in the road network near the destination and Garmins preference for highways over long distances.
created a map for california and routing in Mapsource doesn't find the ideal route in a case where the best route is crossing 4 tiles but Mapsource is able to find a suboptimal route crossing 3 tiles only. not sure if this is a Mapsource limitation or can be fixed in the data. On a Etrex routing failed with a out of memory message for the same map. Have only Topo maps on the Garmin and can't verify if this is more a map or device limitation another bug in the map is the rendering of water. the ocean isn't drawn at all. Lake Tahoe is drawn in low zoom levels but skipped in higher zoom levels I see that the polygons for both are not closed because they extend beyond the osm file boundary
-Wolfgang
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (11)
-
Apollinaris Schoell -
Clinton Gladstone -
Dermot McNally -
FlaBot -
Johann Gail -
Mark Burton -
Paul -
Robert Vollmert -
Steve Ratcliffe -
Toby Speight -
Wolfgang v. Hansen