Inter tile routing problems
Hi, In general it's working great now did a couple of tests with a Etrex Vista and Mapsource Main problem is the Garmin algorithm not the map itself. It will always try to find the way crossing less tiles instead choosing the shortest/fastest route. If I insert a through point the whole route is perfect. Is there an option for the splitter to create chessboard like tiles same as in Garmin maps? Still like to use the maxnode feature and the alignment to the map grid. This way the chance is much lower that the fast/short route crosses more tiles than the slow/long route.
On Tue, 10 Mar 2009, Apollinaris Schoell wrote:
In general it's working great now did a couple of tests with a Etrex Vista and Mapsource Main problem is the Garmin algorithm not the map itself. It will always try to find the way crossing less tiles instead choosing the shortest/fastest route. If I insert a through point the whole route is perfect.
This is an interesting observation. Do you experience the same with the original Garmin maps? OTOH, my experience with Garmin routing for long distances (on City Navigator) is that you normally get a route along the Autobahn. Often the result will be neither the shortest nor the fastest path.
Is there an option for the splitter to create chessboard like tiles same as in Garmin maps? Still like to use the maxnode feature and the alignment to the map grid.
No. You would need a real chessboard pattern for that as any adaptive approach has small tile sizes in densely populated areas and large ones outside. Maybe you want to be routed around large towns anyway? :-) I think the splitter could be programmed as such quite easily (though I don't know the source code). For instance, you could start with a raster of large square tiles and divide each into four quarters if there are too many nodes inside. -Wolfgang
0> In article <alpine.WNT.2.00.0903110815010.3464@WLT181.domina.fom>, 0> Wolfgang v. Hansen <URL:mailto:wvhansen@fom.fgan.de> ("Wolfgang") wrote: Wolfgang> On Tue, 10 Mar 2009, Apollinaris Schoell wrote:
Is there an option for the splitter to create chessboard like tiles same as in Garmin maps? Still like to use the maxnode feature and the alignment to the map grid.
Wolfgang> No. You would need a real chessboard pattern for that as any Wolfgang> adaptive approach has small tile sizes in densely populated Wolfgang> areas and large ones outside. Maybe you want to be routed Wolfgang> around large towns anyway? In general, it might not help anyway. Consider a route that goes due north/south, close to the tile boundary. If it weaves slightly east/west and back a few times, it will cross tiles quite a lot - even more so if all the tiles are aligned.
On Wed, Mar 11, 2009 at 12:56 PM, Toby Speight <T.M.Speight.90@cantab.net> wrote:
In general, it might not help anyway. Consider a route that goes due north/south, close to the tile boundary. If it weaves slightly east/west and back a few times, it will cross tiles quite a lot - even more so if all the tiles are aligned.
A naive question: could some of the inter-tile routing problems be caused by the lack of an overview map? Could it be that Garmin falls back to the larger routes defined in the overview map for longer distances, thus avoiding the intervening tiles completely? This is pure speculation; I have no evidence to support this. But could this make sense? Cheers.
On 11 Mar 2009, at 6:46 , Clinton Gladstone wrote:
On Wed, Mar 11, 2009 at 12:56 PM, Toby Speight <T.M.Speight.90@cantab.net> wrote:
In general, it might not help anyway. Consider a route that goes due north/south, close to the tile boundary. If it weaves slightly east/west and back a few times, it will cross tiles quite a lot - even more so if all the tiles are aligned.
A naive question: could some of the inter-tile routing problems be caused by the lack of an overview map?
Could it be that Garmin falls back to the larger routes defined in the overview map for longer distances, thus avoiding the intervening tiles completely?
This is pure speculation; I have no evidence to support this. But could this make sense?
good point. on the Etrex it seems sometimes it falls back to basemap routing for some parts. other times I get a out of memory message. it's just a random effect. Even Mapsource gives up on very long routes but can route all of it in shorter segments.
Cheers. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 11 Mar 2009, at 4:56 , Toby Speight wrote:
Wolfgang> No. You would need a real chessboard pattern for that as any Wolfgang> adaptive approach has small tile sizes in densely populated Wolfgang> areas and large ones outside. Maybe you want to be routed Wolfgang> around large towns anyway?
In general, it might not help anyway. Consider a route that goes due north/south, close to the tile boundary. If it weaves slightly east/west and back a few times, it will cross tiles quite a lot - even more so if all the tiles are aligned.
agree it doesn't solve the problem. Still it can reduce the number of failures a lot
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 11 Mar 2009, at 24:26 , Wolfgang v. Hansen wrote:
On Tue, 10 Mar 2009, Apollinaris Schoell wrote:
In general it's working great now did a couple of tests with a Etrex Vista and Mapsource Main problem is the Garmin algorithm not the map itself. It will always try to find the way crossing less tiles instead choosing the shortest/fastest route. If I insert a through point the whole route is perfect.
This is an interesting observation. Do you experience the same with the original Garmin maps? OTOH, my experience with Garmin routing for long distances (on City Navigator) is that you normally get a route along the Autobahn. Often the result will be neither the shortest nor the fastest path.
Don't have any City Navigator maps to confirm. Have only the Natinalpark map. But this one doesn't have many roads and it's a regular pattern.
-Wolfgang _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Is there an option for the splitter to create chessboard like tiles same as in Garmin maps? Still like to use the maxnode feature and the alignment to the map grid.
No. You would need a real chessboard pattern for that as any adaptive approach has small tile sizes in densely populated areas and large ones outside. Maybe you want to be routed around large towns anyway? :-)
I think the splitter could be programmed as such quite easily (though I don't know the source code). For instance, you could start with a raster of large square tiles and divide each into four quarters if there are too many nodes inside.
But this would leave you again with different sized tiles (one big square beside 4 samller ones), which could disturb the routing, if the previous observations are correct.
Hi, I've discovered some routing hickups I don't quite understand. Here is a link to the motorway ramp/exit in question: http://www.openstreetmap.org/?lat=50.90594&lon=11.0078&zoom=15&layers=B000FT... Trying to route from the 'B4' (coming from north) onto the 'A4' going west fails. It looks as if the ramp going onto the autobahn is not connected. I've observed this behavior on my etrex legend (compiled with data some weeks old and mkgmap r925), but also today with recent data and mkgmap r975 routing with mapsource. I've looked through the osm data (in JOSM) but found no irregularities. All nodes are connected, there's no oneway in the wrong direction or anything. The ramps are tagged with ref=A4;B4 which seems odd, but I don't know the proper handling of ramps regarding ref numbers. To go east onto the A4 seems to be no problem. (To turn around on the next exit is the proposal mapsource gives to me to reach my goal). the only difference I can see between the western and eastern ramp is the node with the traffic lights. Could someone investigate any further? Thanks Stefan
stefan@binaervarianz.de wrote:
I've looked through the osm data (in JOSM) but found no irregularities. All nodes are connected, there's no oneway in the wrong direction or anything. The ramps are tagged with ref=A4;B4 which seems odd, but I don't know the proper handling of ramps regarding ref numbers.
Motorway and motorway_link are implicitely oneway. This is correct according to the OSM wiki and the style rules of mkgmap reflect this. In your example there is a part of the ramp which is common for both directions. This part must be set "oneway=no". I made that change a minute ago. Please try again.
I've looked through the osm data (in JOSM) but found no irregularities. All nodes are connected, there's no oneway in the wrong direction or anything. The ramps are tagged with ref=A4;B4 which seems odd, but I don't know the proper handling of ramps regarding ref numbers.
Motorway and motorway_link are implicitely oneway. This is correct according to the OSM wiki and the style rules of mkgmap reflect this.
In your example there is a part of the ramp which is common for both directions. This part must be set "oneway=no". I made that change a minute ago. Please try again.
Thanks very much! I never mapped a motorway_link myself, so this was new to me. I can't try it now, 'cause I don' have a Windows machine until tomorrow afternoon, but I suppose it's working now. regards Sefan
Hi again, let me just start with an apology: I have about half an hour each day to test mkgmap. The other time I don't even have access to that (and any other) windows machine. So anything said here is from memory, with no possibiliy to go back and copy & paste some log data or try again. But I hope somebody still finds some feedback usefull. It's not meant as an request for fixing, but just as another usage report. So what I did was: - Downloaded .osm.bz files from geofabrik for thuringia(GER), bavaria (GER) and austria. - unpacked each file and processed each with splitter (I used the - mapid= switch to produce files with consecutive names) - thuringia produced 1 tile, bavaria 4 tiles and austria 6 - used mkgmap(r975) to produce a map of all tiles (options included -- route, --gmapsupp, --net, --road-name-pois) - used mapsettool to bring it in mapsource, uploaded to erex legend hcx What I observed: Output of mkgmap run: - Some bad turning restrictions - Some areas containing to much points (for some autogeneration of names I think) (this is really bad quality of information for a bug report, isn't it?) Routing in Mapsource: A route from erfurt (thuringia) to bad reichenhall (southern bavaria) fails. Inserting more and more waypoints in between results in narrowing the not-routable part down to the border between thuringia and bavaria. POI search on etrex: While "Bad Reichenhall" is findable in mapsource, it isn't on the etrex. Neither under 'citys' nor under 'all'. Same for some street names there. I think the routing problem originates in the overlapping or otherwise missaligning tile borders between the tiles generated from different .osm files. Is the intended workflow really: download the whole of europe, use splitter and mkgmap, use mapsource to identify interesting tiles, throw away the other ones and run mkgmap again? Or is there a way of telling splitter to take care of that? Does splitter allow more than one input file at once? regards Stefan
Stefan Aschenbach wrote:
- Downloaded .osm.bz files from geofabrik for thuringia(GER), bavaria(GER) and austria. - unpacked each file and processed each with splitter (I used the -mapid= switch to produce files with consecutive names) - thuringia produced 1 tile, bavaria 4 tiles and austria 6
Inter-tile routing will only work if you split _one_ OSM file with the mkgmap splitter.
Output of mkgmap run:
- Some bad turning restrictions
Most probably wrong OSM data.
Is the intended workflow really: download the whole of europe, use splitter and mkgmap, use mapsource to identify interesting tiles, throw away the other ones and run mkgmap again?
Yes. You can cut out a part of the europe OSM file before splitting, e.g. with osmosis. That's what I do for generating my hiking map (http://www.kleineisel.de/ralf/gps/garmin/, not routable yet). Otherwise you cannot predict where the borders of the tiles will be.
Is the intended workflow really: download the whole of europe, use splitter and mkgmap, use mapsource to identify interesting tiles, throw away the other ones and run mkgmap again?
Yes. You can cut out a part of the europe OSM file before splitting, e.g. with osmosis. That's what I do for generating my hiking map (http://www.kleineisel.de/ralf/gps/garmin/, not routable yet). Otherwise you cannot predict where the borders of the tiles will be.
I haven't used osmosis yet. But accourding to there wiki page i suppose it would also be possible to join the region osm files together befor giving them as a whole to splitter. I imagine this would be easier than cutting away from a europe file. At least for regions smaller than whole countries. Thanks for the advise, Stefan
I haven't used osmosis yet. But accourding to there wiki page i suppose it would also be possible to join the region osm files together befor giving them as a whole to splitter.
I imagine this would be easier than cutting away from a europe file. At least for regions smaller than whole countries.
I haven't tried myself, but I think merging two osm files should be nearly as simple as copy them both into one file. Should only need small work whit the header lines to get a valid xml file.
participants (8)
-
Apollinaris Schoell -
Clinton Gladstone -
Johann Gail -
Ralf Kleineisel -
Stefan Aschenbach -
stefan＠binaervarianz.de
-
Toby Speight -
Wolfgang v. Hansen