Testing inter-tile routing with mapsource
I have spent quite a while crawling around a 13 tile map using mapsource and, so far, I can route anywhere that's actually connected. N/S/E/W it doesn't seem to care. Sometimes, it will just draw a straight line but if you break the route down into smaller pieces it can route. It seems like that it's a complexity thing. It just gives up when it thinks the route is too tough to compute (computer says no). Felix's point about the OSM data being not perfectly connected is interesting but we can't control how the gps behaves and we can't just go around linking up roads that look close enough to be connected but aren't actually. So I don't know if we can do much about that. Cheers, Mark
Using maps generated with r915 I've spent a while trying to route to places all over the UK. Places within my start tile work fine as expected. Inter-tile routing works but I have the following observation If you route to somewhere just inside the adjacent tile then the route selected is usually fine. If you route to somewhere deep inside the adjacent tile then the route chosen is far from optimal. It's as though motorways are being avoided until you are out of your starting tile after which the route takes the shortest path to a motorway and proceeds as expected. This seems to happen if travelling North, South or East (I'm not in a position to test West) Similarly routing to places beyond adjacent tiles is not optimal but presumably this is due to the above e.g. going from Manchester to Taunton doesn't hit the M6 until near Stoke. After that it leaves the M5 north of Bristol, goes through the middle of Bristol and then rejoins the M5 but this is near the NW corner of one tile and the SW corner of another so I would expect oddities at this point. The work that's been done so far on inter-tile routing is fantastic and I don't want anyone to think I'm having a go I just thought the info would be useful Thanks Paul Mark Burton wrote:
I have spent quite a while crawling around a 13 tile map using mapsource and, so far, I can route anywhere that's actually connected. N/S/E/W it doesn't seem to care.
Sometimes, it will just draw a straight line but if you break the route down into smaller pieces it can route.
It seems like that it's a complexity thing. It just gives up when it thinks the route is too tough to compute (computer says no).
Felix's point about the OSM data being not perfectly connected is interesting but we can't control how the gps behaves and we can't just go around linking up roads that look close enough to be connected but aren't actually. So I don't know if we can do much about that.
Cheers,
Mark
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Paul,
Using maps generated with r915 I've spent a while trying to route to places all over the UK. Places within my start tile work fine as expected.
Inter-tile routing works but I have the following observation
If you route to somewhere just inside the adjacent tile then the route selected is usually fine. If you route to somewhere deep inside the adjacent tile then the route chosen is far from optimal. It's as though motorways are being avoided until you are out of your starting tile after which the route takes the shortest path to a motorway and proceeds as expected. This seems to happen if travelling North, South or East (I'm not in a position to test West)
Similarly routing to places beyond adjacent tiles is not optimal but presumably this is due to the above e.g. going from Manchester to Taunton doesn't hit the M6 until near Stoke. After that it leaves the M5 north of Bristol, goes through the middle of Bristol and then rejoins the M5 but this is near the NW corner of one tile and the SW corner of another so I would expect oddities at this point.
The work that's been done so far on inter-tile routing is fantastic and I don't want anyone to think I'm having a go I just thought the info would be useful
Not for one moment, do I think you're "having a go" - the feedback is really useful to have. Here's a thought off the top of my head. For optimal routing over long distances, could the map also contain tiles that cover a larger area but with less detail? Steve, Robert any thoughts on that idea? Cheers, Mark
Mark Burton wrote:
Here's a thought off the top of my head. For optimal routing over long distances, could the map also contain tiles that cover a larger area but with less detail? Steve, Robert any thoughts on that idea?
When zooming out to, e.g. all of Germany, a cgpsmapper map is drawn very fast by my eTrex. A mkgmap map takes a much longer time. Both show motorways only. Perhaps there is really less data in the zoomed out tiles?
When zooming out to, e.g. all of Germany, a cgpsmapper map is drawn very fast by my eTrex. A mkgmap map takes a much longer time. Both show motorways only. Perhaps there is really less data in the zoomed out tiles?
Yes, I'he noted too, that zooming out takes a lot more time than with other maps. This was one reason for me to try simplify ways. I'm working on it, but have not enough spare time at the moment.
On Sat, 21 Feb 2009, Johann Gail wrote:
When zooming out to, e.g. all of Germany, a cgpsmapper map is drawn very fast by my eTrex. A mkgmap map takes a much longer time. Both show motorways only. Perhaps there is really less data in the zoomed out tiles?
Yes, I'he noted too, that zooming out takes a lot more time than with other maps. This was one reason for me to try simplify ways. I'm working on it, but have not enough spare time at the moment.
If you zoom out with original Garmin maps far enough, it switches to the basemap. This is why it becomes fast for overviews.
On Sat, Feb 21, 2009 at 09:05:52AM +0100, Ralf Kleineisel wrote:
Mark Burton wrote:
Here's a thought off the top of my head. For optimal routing over long distances, could the map also contain tiles that cover a larger area but with less detail? Steve, Robert any thoughts on that idea?
When zooming out to, e.g. all of Germany, a cgpsmapper map is drawn very fast by my eTrex. A mkgmap map takes a much longer time. Both show motorways only. Perhaps there is really less data in the zoomed out tiles?
This post: http://www.mail-archive.com/qlandkarte-users@lists.sourceforge.net/msg00221.... to the qlandkarte mailing list by Oliver contains several reason why mkgmap maps are slow to draw in QLandkarte. Its more than likely that these same reasons apply to the device too. A summary and comments on the ones that are relevent here: 1. The default style is very heavyweight and has many more levels than other maps. We should have a style that has fewer levels for making large area maps. 2. Staircase lines in the outer zoom levels. This is where smoothing would be really welcome. I think (I could be wrong) that at the high zoom levels you will have to join the different parts of a road up before smoothing them (or something that has the same effect). 3. Motoway ramps. I guess we can leave them out at outer zoom levels if it doesn't affect routing. 4. Lakes, forests at outer zoom layers. We should have a way of leaving out smaller polygon features at outer zoom levels, while leaving in the larger ones. ..Steve
When zooming out to, e.g. all of Germany, a cgpsmapper map is drawn very fast by my eTrex. A mkgmap map takes a much longer time. Both show motorways only. Perhaps there is really less data in the zoomed out tiles?
2. Staircase lines in the outer zoom levels. This is where smoothing would be really welcome. I think (I could be wrong) that at the high zoom levels you will have to join the different parts of a road up before smoothing them (or something that has the same effect).
I'm trying this at the moment, but it destroys my map. Seems to have some bug in it. Could it be a problem with some linking of nodes to ways pointing to the original way?
3. Motoway ramps. I guess we can leave them out at outer zoom levels if it doesn't affect routing.
This is my opinion too. This should also be achieved by setting a reasonable MIN_SIZE. See below.
4. Lakes, forests at outer zoom layers. We should have a way of leaving out smaller polygon features at outer zoom levels, while leaving in the larger ones.
This should be possible already with the MIN_SIZE in SmoothingFilter. Maybe neccessary to set different values for lines and polygons. (Btw. In a previous patch I have extracted this code to a separate SizeFilter.) If you set a MIN_SIZE=1 it nearly doubles drawing speed on my etrex in the lowest zoom levels.
Mark Burton escribió:
Felix's point about the OSM data being not perfectly connected is interesting but we can't control how the gps behaves and we can't just go around linking up roads that look close enough to be connected but aren't actually. So I don't know if we can do much about that.
IMHO unconnected ways are a problem from the data and must be fixed there, not in mkgmap. Validator plugin in JOMS is quite useful to detect/correct crossing roads and also detects end nodes near a road but unconnected to it. Cheers Carlos
participants (7)
-
Carlos Dávila -
Johann Gail -
Mark Burton -
Paul -
Ralf Kleineisel -
Steve Ratcliffe -
Wolfgang v. Hansen