routing issues with multiple lines & address search

I've noticed that routing breaks if I search for an address, where the street consists of multiple lines in the style file. For instance a tertiary road plus a tunnel. Or a bike path with a cycle route. In those cases both lines were routable. In cases where I use overlay lines (with the continue statement) that are non routable, routing doesn't seem to break. On Mapsource or on the GPS it routes fine if you point to that road on the map. With the address search on the GPS however, the street is found but if i want to calculate a route, the device says either 'there are no routable streets' or the route makes very weird jumps to the tile end and bounces back to to the destination in a straight line. I think I can prevent this behaviour by using non-routable lines for overlays, but maybe some improvements can be made in the mkgmap code?

I have made some screenshots for this weird routing behaviour: http://sites.google.com/site/openfietsmap/routing Conclusions: -If two routable lines are combined, routing breaks when address search is used (btw I have used mkgmap-locator-r1912.jar, same happened with previous version) -Instead of routing to the destination, the route goes to the end of the tile, and from there a direct straight line to the destination -If you point to the same road on the map, routing is fine The reason why I use two routable lines is because 0x01 and 0x02 have a very high draw priority so it is displayed under all circumstances on top of any other line. So this makes it convenient to indicate bike routes or no bicycle allowed roads. ----- Oorspronkelijk bericht ----- I've noticed that routing breaks if I search for an address, where the street consists of multiple lines in the style file. For instance a tertiary road plus a tunnel. Or a bike path with a cycle route. In those cases both lines were routable. In cases where I use overlay lines (with the continue statement) that are non routable, routing doesn't seem to break. On Mapsource or on the GPS it routes fine if you point to that road on the map. With the address search on the GPS however, the street is found but if i want to calculate a route, the device says either 'there are no routable streets' or the route makes very weird jumps to the tile end and bounces back to to the destination in a straight line. I think I can prevent this behaviour by using non-routable lines for overlays, but maybe some improvements can be made in the mkgmap code? _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

I have made some screenshots for this weird routing behaviour: http://sites.google.com/site/openfietsmap/routing
Conclusions: -If two routable lines are combined, routing breaks when address search is used (btw I have used mkgmap-locator-r1912.jar, same happened with previous version)
I think (I haven't confirmed) that the address point of a street is the center point of the streets bounding box which lies not mandatorily on the street. Maybe that's the reason. If so this should be fixed quite easily. WanMil
-Instead of routing to the destination, the route goes to the end of the tile, and from there a direct straight line to the destination -If you point to the same road on the map, routing is fine
The reason why I use two routable lines is because 0x01 and 0x02 have a very high draw priority so it is displayed under all circumstances on top of any other line. So this makes it convenient to indicate bike routes or no bicycle allowed roads.
----- Oorspronkelijk bericht -----
I've noticed that routing breaks if I search for an address, where the street consists of multiple lines in the style file. For instance a tertiary road plus a tunnel. Or a bike path with a cycle route. In those cases both lines were routable. In cases where I use overlay lines (with the continue statement) that are non routable, routing doesn't seem to break.
On Mapsource or on the GPS it routes fine if you point to that road on the map. With the address search on the GPS however, the street is found but if i want to calculate a route, the device says either 'there are no routable streets' or the route makes very weird jumps to the tile end and bounces back to to the destination in a straight line.
I think I can prevent this behaviour by using non-routable lines for overlays, but maybe some improvements can be made in the mkgmap code? _______________________________________________ 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

Hmm maybe it helps if I edit my style file rules, it could be an error in the style files... Routing goes well though in Mapsource and on the GPS when pointing on the map. This was not going to work in combination with address routing: highway=primary & bicycle=no [0x0301 road_class=0 road_speed=0 resolution 23] highway=primary & bicycle!=no [0x03 road_class=1 road_speed=3 resolution 23] type 0x0301 is in the overlays file defined: 0x03, 0x01 But this is working fine now without address routing issues: highway=primary [0x03 road_class=1 road_speed=3 resolution 23 continue with_actions] highway=primary & bicycle=no [0x01 road_class=0 road_speed=0 resolution 23] For the 0x02 (bicycle routes) on top of other highways, I didnt use the overlays file, but used the continue statement. This caused problems with address routing: highway=primary [0x03 road_class=1 road_speed=3 resolution 23 continue with_actions] ..... (more highway rules) ..... bicycleroute=yes [0x02 resolution 22] But since I have added highway=* plus road_class / road speed to the 0x02 line this seems to work: highway=* & bicycleroute=yes [0x02 road_class=3 road_speed=3 resolution 22] (note: bicycleroute=yes contains all the highways that have relations with route=rcn, lcn ncn etc) Another problem with address search is that although Mapsource finds the streets with the corresponding place, in the GPS a lot of those streets are not connected to places. h=The GPS lists those streets, but it can't find a place and location. I can't find any pattern here, it can be an adjacent street in the same district, not close to any tile border, with the same tags as a street that can be found with a placename. It looks like Mapsource doesn't send the complete index to the GPS but only part of it.

BTW it seems to happen more often with the locator jar than the regular mkgmap version. In Mapsource it works ok, but when the map is send to the device, some streetnames are not connected to a placename. I wrote: Another problem with address search is that although Mapsource finds the streets with the corresponding place, in the GPS a lot of those streets are not connected to places. h=The GPS lists those streets, but it can't find a place and location. I can't find any pattern here, it can be an adjacent street in the same district, not close to any tile border, with the same tags as a street that can be found with a placename. It looks like Mapsource doesn't send the complete index to the GPS but only part of it. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Conclusions: -If two routable lines are combined, routing breaks when address search is used (btw I have used mkgmap-locator-r1912.jar, same happened with previous version)
I think (I haven't confirmed) that the address point of a street is the center point of the streets bounding box which lies not mandatorily on the street. Maybe that's the reason. If so this should be fixed quite easily.
WanMil
My idea seems to be nonsense. The center point of a way is not used for creating the index. WanMil

Wanmil, Speaking about the index, do you have an idea why when in Mapsource the address search streets are connected with the right city (map made with the locator jar) on the gps the address search is not as good and many streets are not connected to a place name? If I compile the map with the regular mkgmap the gps finds more of those streetnames with connecting placenames but the results are less reliable than maps made with the locator (placenames are not always the correct ones). Another thing: If I dont specify country-name: and country-abbr: in the args file (because I have a map with several countries), I get a very ugly "ABC" as substitute for country. Can we get rid of this, better nothing specified than this which makes no sense at all. Same for "fix me" in the address properties. It only fills the map with unneccesary data. WanMil wrote:
My idea seems to be nonsense. The center point of a way is not used for creating the index.

Wanmil,
Speaking about the index, do you have an idea why when in Mapsource the address search streets are connected with the right city (map made with the locator jar) on the gps the address search is not as good and many streets are not connected to a place name?
I have no idea. Mapsource creates its own index when uploading the map to the GPS. Maybe somethings wrong with the mkgmap index and that's the point where it is revealed.
If I compile the map with the regular mkgmap the gps finds more of those streetnames with connecting placenames but the results are less reliable than maps made with the locator (placenames are not always the correct ones).
Can you isolate the problem or give some examples where MapSource and gps find works and some where gps does not work? Please post your mkgmap settings also so that I can reproduce the behaviour.
Another thing: If I dont specify country-name: and country-abbr: in the args file (because I have a map with several countries), I get a very ugly "ABC" as substitute for country. Can we get rid of this, better nothing specified than this which makes no sense at all. Same for "fix me" in the address properties. It only fills the map with unneccesary data.
I don't know if the country information is mandatory for searchable garmin objects. That would be a reason for the default country. The "fix me" is a relict of the old locator and can be removed. WanMil
WanMil wrote:
My idea seems to be nonsense. The center point of a way is not used for creating the index.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Sorry I was mistaken, I didnt search well. If I don't specify the place name, all the streets are found. If I specify a place name, less results show up. About the other routing problems, I think I've found a solution to the overlay lines which are routable (had to add road_speed and road_class in the style file) ---------- Wanmil wrote:
Wanmil,
Speaking about the index, do you have an idea why when in Mapsource the address search streets are connected with the right city (map made with the locator jar) on the gps the address search is not as good and many streets are not connected to a place name?
I have no idea. Mapsource creates its own index when uploading the map to the GPS. Maybe somethings wrong with the mkgmap index and that's the point where it is revealed.
participants (2)
-
Minko
-
WanMil