Hi, On 9 August 2010 10:54, Marko Mäkelä <marko.makela@iki.fi> wrote:

Hi Paul,

...

I wanted to report that routing through Europe is broken.  I have noticed it in December 2009, but did not report it then because I thought that my nüvi got broken.

I think that we have two variables at play here: software revisions (mkgmap and splitter) and data revisions (Geofabrik extracts).

Do you happen to have old europe.osm.bz2 files lying around? Do they process fine with current splitter and mkgmap? It could be that the data (or the mkgmap default style) has grown so much that more stuff is pulled in and some internal limit is exceeded.

You might be right. Sorry, I have no old copies of europe.osm.bz2 to check it.

For what it is worth, in early 2009 I was able to compile a routable Finland in 2 tiles (and soon thereafter in 3 tiles). Now I need 6 tiles.

...

I generate my maps always with latest svn HEAD using the following commands: java -Xmx3000m -jar splitter.jar --max-nodes=400000 europe.osm.bz2 --cache=/tmp java -Xmx3600m -jar mkgmap.jar --index --description="EU" --route --series-name=OSM_EU --remove-short-arcs --description=OSM_EU_routing --tdbfile --add-pois-to-areas *.osm.gz The maps get written to destination img file using MapSource 6.13.7.

Did you try a smaller --max-nodes? Do you archive the areas.list or the software revision numbers that you are using? That could be a good idea for the future. I keep my scripts in a local Subversion repository, but I do not archive the source .osm.bz2 file.

My scripts have not been changed in last year. I'll try again with smaller --max-nodes. Should I expect, that routing in MapSource should work? Paul -- Don't take life too seriously; you will never get out of it alive.                                         -- Elbert Hubbard

Paul Ortyl schrieb am 09.08.2010 18:00:

Should I expect, that routing in MapSource should work?

Yes. I do not use the default style, but in general routing does work (atleast when the routes are not to long). Gruss Torsten

On Mon, Aug 09, 2010 at 09:45:33PM +0200, Valentijn Sessink wrote:

Since r1431 (2009-12-10) bike routing has, IMHO and for my situation, degraded. When I'm building biking maps for the Amsterdam region, I'm using a style file from r1430.

Relying on bicycles for most of my transportation needs, I take this seriously. Let me try to reason what is causing the breakage. r1431 changed the minimum resolution of a few items. I believe that it has been established that the resolution will not affect routing, as the routing will take place at resolution 24. It also changed the road_class or road_speed of the following: junction=roundabout: road_speed=2 or 1 instead of 5,4,3,2 road_class unchanged highway=motorway: road_speed=7 instead of road_speed=6 highway=motorway_link: road_speed=2 instead of road_speed=3 road_class=3 instead of road_class=4 highway=trunk: add bicycle=no, foot=no (these were not added previously) road_class=4 instead of road_class=3 highway=trunk_link: add bicycle=no, foot=no (these were not added previously) road_class=3 or 4 instead of road_class=3 road_speed=2 instead of road_speed=3 highway=* & motorroad=yes: add bicycle=no, foot=no (these were not added previously) highway=primary_link, secondary_link, tertiary_link: road_speed=1 instead of 2 or 3 highway=minor: road_speed=3 instead of 2 highway=unclassified: road_speed=3 instead of 2 road_class=0 instead of 1 highway=living_street: road_speed=1 instead of 2 highway=service: road_speed=2 instead of 1 highway=path: road_speed=1 instead of 0 highway=road: road_class=0 instead of 1 road_speed=1 instead of 2

Please note that this is for the Netherlands (which has many, many roads and and abundance of bicycle paths on OSM) and for bike routing, which has it's peculiarities on it's own.

I seem to remember that someone (Felix?) mentioned that Garmin bicycle routing knows two values of road_speed: zero and nonzero. Before r1431, highway=path and highway=cycleway got different road_speed: 0 and 1, respectively. Starting with r1431, both have road_speed=1. Could that be the source of the breakage? If it is (please test road_speed=0 on highway=path in the current default style), then I would change the default style so that highway=path & bicycle=(designated|official) gets road_speed=1 and all other highway=path get road_speed=0. Best regards, Marko

On Tue, Aug 10, 2010 at 11:33:43AM +0200, Valentijn Sessink wrote:

...

I seem to remember that someone (Felix?) mentioned that Garmin bicycle routing knows two values of road_speed: zero and nonzero. Before r1431, highway=path and highway=cycleway got different road_speed: 0 and 1, respectively. Starting with r1431, both have road_speed=1. Could that be the source of the breakage?

I thought it was having unclassified roads get road_class 0. But to be honest: I never tested. I just rely on r1430 for my bicycle maps. Then again, when I cycled from Copenhagen to Amsterdam this summer, I used the regular maps and they worked pretty well - in Denmark and Germany, that is. So most likely it has something to do with the density of bicycle roads, combined with the road class changes.

So please ignore my comments for now - if I have time, I'll try to test a more fine grained r1430-1431 change and report my findings.

I am planning to remove the { add bicycle=no; add foot=no } from highway=trunk and to restore non-bicycle paths to road_speed=0. Do you have test cases in mind? Can you try the attached patch? Long term, I would remove the "Convert generic path to most specific" and translate the highway=(cycleway|footway|bridleway) to highway=path instead. In that way, we can better keep the access tags intact. Best regards, Marko

On Tue, Aug 10, 2010 at 02:37:42PM +0200, Valentijn Sessink wrote:

Marko Mäkelä schreef:

...

I am planning to remove the { add bicycle=no; add foot=no } from highway=trunk and to restore non-bicycle paths to road_speed=0.

I'd suggest you don't. I do not know why bicycle routing differs. Adding random patches to my random reports won't help.

It is not totally random. Someone just yelled that defaulting bicycle=no on highway=trunk is not right, and I cannot disagree with that. If there is no traffic sign that prohibits bicycles and pedestrians, then they are allowed. And I haven't seen such traffic signs in Finland, except in some places when there is a cycleway next to the highway=trunk.

Please note that r1431 was quite carefully engineered by Felix Hartmann (at least, that is what I understood from it), and you shouldn't change these back just because I'm yelling something ;-)

The road_speed=1 for a non-bicycle highway=path does not seem to make too much sense. It may be possible to ride some bicycles on a 20cm wide unofficial forest path, but not with a bicycle trailer or a tandem/triplet/quad or at the same speed as on a purpose-built cycleway. Maybe Felix had too much emphasis on mountain bikers?

...

Do you have test cases in mind? Can you try the attached patch?

I will. But not now.

No hurry, this has (or may have) been broken such a long time :-) Marko

On 10.08.2010 15:12, Marko Mäkelä wrote:

On Tue, Aug 10, 2010 at 02:37:42PM +0200, Valentijn Sessink wrote:

...

Marko Mäkelä schreef:

...

I am planning to remove the { add bicycle=no; add foot=no } from highway=trunk and to restore non-bicycle paths to road_speed=0. I'd suggest you don't. I do not know why bicycle routing differs. Adding random patches to my random reports won't help. It is not totally random. Someone just yelled that defaulting bicycle=no on highway=trunk is not right, and I cannot disagree with that. If there is no traffic sign that prohibits bicycles and pedestrians, then they are allowed. And I haven't seen such traffic signs in Finland, except in some places when there is a cycleway next to the highway=trunk.

...

Please note that r1431 was quite carefully engineered by Felix Hartmann (at least, that is what I understood from it), and you shouldn't change these back just because I'm yelling something ;-) The road_speed=1 for a non-bicycle highway=path does not seem to make too much sense. It may be possible to ride some bicycles on a 20cm wide unofficial forest path, but not with a bicycle trailer or a tandem/triplet/quad or at the same speed as on a purpose-built cycleway. Maybe Felix had too much emphasis on mountain bikers?

...

...

Do you have test cases in mind? Can you try the attached patch? I will. But not now. No hurry, this has (or may have) been broken such a long time :-)

Marko

I designed the routing in such a way, that it works much better for motorcars/motorcycles (bare the Mapsource intertileroutingproblems). As you cannot have different road_speed for cyclists vs cars, one should better compromise on the bicycle side, as proper bicycle routing will anyhow not work on a map that is rather made for motorcars. highway=trunk and bicycle=no --- well that is based on the crap introduced by having country defaults. Were an international map, but we fuck it up by introducing different rules by country (and those not clear either). Usually trunk roads suck outright for cyclists, if you don't add bicycle=no, bicycles will primarily be routed on primaries and trunk roads. That's good for people that take a pleasure in being able to calculate a route for 200 or 300km distance, but bullshit if you want to be routed on roads without much traffic. As long as there is no consensus worldwide whether or not cyclists by default are allowed on trunk roads, I wouldn't add them (and even then it probably makes not much sense, you would have to enter them as road_class=0, road_speed=0 --> but that clashes with motorcar usage). highway=path has usually tags like sac_scale, mtb:scale, tracktype and similar attached, if not than it should be added, therefore roadspeed=1 is IMHO correct. Else pathes won't be chosen at all (except for tiny distances). Only road_speed=0 and road_speed=1 are taken for route priority, however TTP is still valid for bicycles as for motorcars, which of course is clearly a default in the Garmin GPS Software, because even on a trunk_road you will never need say 2 minutes to turn as a cyclist, but this TTP is calculated. As I wrote back then, routing for cars would still work much better, if indicated max_speed can only decrease road_speed, not increase it. Loads of problems related to this fact here.

On 08/10/2010 11:32 PM, Marko Mäkelä wrote:

kilometers of the route. In the middle of the route (after riding a couple of kilometers), it will instruct me to turn from the cycleway to the car road and continue on that. If the car road is tagged bicycle=no, it will instruct me to take a detour. For example, the 2*70 km route that I made last weekend would have been something like 280 km with the bicycle routing option, using lesser car roads. With car routing

I did some testing recently using Oregon 550 and Nuvi 755. My impressions were as follows. It seemed that Garmin uses first road_class to select larger roads. That helps in making the road network reasonable in size I guess. If the larger roads are not connected, it uses smaller roads to get from a larger road to another. Same applies for the start and endpoint where you usually have to use small roads. If you set a via point, it uses smaller roads to get into it as well (after getting nearby using the larger roads). (You can guide the autorouting quite a lot with those). After it has selected the road network it starts computing the route such as faster or shorter. Shorter will yet prefer large roads becacuse the network consists mostly of them (or the smaller roads are ignored on a long route). I got very good bicycle routing when I used road_class=4 or 3 for paved/unpaved cycleways. It always preferred the cycleway instead of the parallel car road (which was lower in road_class). Unfortunately that had a major impact. By raising all the cycleways to high road_class the computation time for the route was very unacceptable. Route calculation (and recalculation!) time for a 20km test route in Helsinki was about 2-3 minutes with Oregon. The end result was that raising the road_class is the major parameter and speed being far behind that. My impression was that the route length matters a lot too. Longer route would have a huge network of small roads ie. Garmin starts ignoring them. For a short route that is not an issue.

...

Only road_speed=0 and road_speed=1 are taken for route priority,

I'm interested in that one too! (even if my results were that speed is not that important. However, I had speeds 0-2 -- Harri

On 10 August 2010 16:27, Felix Hartmann <extremecarver@googlemail.com> wrote:

to be routed on roads without much traffic. As long as there is no consensus worldwide whether or not cyclists by default are allowed on trunk roads, I wouldn't add them (and even then it probably makes not much sense, you would have to enter them as road_class=0, road_speed=0 --> but that clashes with motorcar usage).

The question here is whether you exclude bikes, not whether you add them. I get the fact that a "smaller" road less trafficked by motor vehicles will often be better for cycling and that this is at odds with how Garmin devices will try to route them. But they problem is that highway=trunk can occur in important places in a road network that are not so nice to have to avoid on a bike. As an example, have a look at the trunk roads that occur in the centre of Dublin: http://www.openstreetmap.org/?lat=53.34725&lon=-6.2653&zoom=16&layers=M Certainly, as a city centre, these roads can be full of cars, but no more so than any other city streets, and having these routes prohibited to cyclists gets in the way of reasonable routing. Worse, if you disallow them to pedestrians, a route to, say, a shop located on the trunk road can't even be calculated. And keep in mind here that I'm not asking for a special case to support some strange quirk of Irish mapping. The assumptions of build quality or access restrictions are the special cases here, we're just using the tag as originally conceived. I wish I had a better suggestion, though... Dermot -- -------------------------------------- Iren sind menschlich