Routing website using Gosmore routing engine

Heh, I guess it isn’t actually time, but time related perhaps. In the gosmore stylesheet (that also contains the routing parameters) the routing parameters are something that can be described as ‘speed’. If you choose pedestrian routing you can give a footway a ‘speed’ of 20 and a primary road a ‘speed’ of 1 so that footways are preferred over primary roads. But this example makes it clear that the parameter is not actually ‘speed’ and times cannot accurately be calculated based on these parameters.

It would probably be best to contact Nic Roets about this.

I’ve two questions about the YOURS backend:

  1. The help page says “The route data is updated approximately once a week”, but that doesn’t seem to happen. Is there a problem or is the help page incorrect? I don’t care about really fast updates, but a data set that’s over two months old is not very good.
  2. IMO, walking should be allowed by default if cycling is allowed. Take this example. Here, the shortest route is to walk over the cycleway, but the planner doesn’t allow that. Since it’s allowed to walk on any cycleway if not stated otherwise, I would like to allow routing over any way which allows bicycles and has no foot=* tag. Of course, I could tag this way with foot=yes, but IMHO that should not be necessary.

You’re right, but I am currently unable to start an update myself since the (new) server that hosts the routing database isn’t under my command. I’ll ping Nic Roets about it.

Indeed, looking at the default definition file for Gosmore I note that pedestrians aren’t allowed on cycleways but cyclists are allowed on footways (albeit at walking speed).

Personally I would agree that pedestrians should be allowed on cycleways but in Germany this seems not allowed unless explicitly specified. I think, internationally, in osm, pedestrians aren’t allowed to use a cycleway unless specified, and because of that I add foot=yes to the cycleways I map.

See e.g. http://wiki.openstreetmap.org/wiki/Tag:access%3Ddesignated
And since you’re Dutch: http://forum.openstreetmap.org/viewtopic.php?id=4143

Thanks for the fast reaction. I see your point, but about the bicycle tag, the wiki says: “Usage of bicycle=dismount and bicycle=no will vary in different countries. If according to local traffic rules a bicycle is no longer seen as a bicycle when there’s no one driving it, then there’s no need for using bicycle=dismount.” So the usage about the tag bicycle depends on local regulations, therefore I think the usage of the foot tag can depend on local regulations too, which means that it is correct to omit foot=yes inside the Netherlands.

I think this is subject to personal preferences. One can add extra tags to be more explicit (some might say ‘more complete’) or one might assume a lot of things and do not tag explititly. Both have pro’s and con’s.

Regarding Gosmore (and OSRM too): they can’t handle differences between countries except when you do a heck of a lot of preprocessing (i.e. add the foot=yes tags on all the cycleways in the Netherlands before feeding the data into Gosmore). Such preprocessing is computationally heavy and prone to errors (e.g. incomplete borders). So don’t expect ‘assumed foot routing over cycleways’ in yournavigation.org anytime soon.

You could, for example, expand this ‘assumptional localized tagging’ to maxspeeds in municipallies. In the Netherlands some have a 60km/h speedlimit on the local roads and others have an 80 km/h limit. Why not assume that any router will know that the municipally Voorst allows 80km/h and the municipally Apeldoorn allows 60km/h and not tag the maxspeed explicitly? Expanding assumptions in tagging gets darn complex very quickly.

The mantra in OSM is ‘don’t tag for the renderer’. I agree, but tagging something as something else because it looks better on the map is different from the assumptional v.s. explicit tagging methods. Explicit tagging makes things much easier on the dataconsumers while assumptional tagging is easier for the mapper.

I’m in favor, as a data consumer and mapper, of defining a strict set of implicit tags that is the same globally for all tags (e.g. highway=trunk implies bicycle=no which means that in the UK all trunk highways should have an explicitly tag bicycle=yes but saves the rest of the world the need to add bicycle=no).

It looks like there’s a bug in the distance calculation somewhere. For example, take the following route: http://yournavigation.org/api/dev/route.php?flat=52.300322610759&flon=6.9410813421612&tlat=52.305302706492&tlon=6.935482870303&v=bicycle&fast=0&layer=mapnik. It is a very simple route, but the distance is NaN.

pls help me, approximately, when will be the next map update?

pls help me, approximately, when will be the next map update??

10x

An update is running as we speak. It will take about a week before it’s ready (this is what I’m told).

The update was finished on the 28th. I’ve updated the information on the website accordingly.

I do notice that there are some strange routing decisions taken after this update, which I can’t relate to OSM data errors. I’ll relay this to the Gosmore author.

What happens here with YOURS?
from 48.90929 8.64634 to 49.27942 7.23073 using fastest “circles” aorund the target.

Yes, the latest update produced weird results. I’ve moved back to to the update from March 18th. I’ve sent an email to the Gosmore author to inform him of the problem with the update.

Routing data from planet file: 2011-06-28
would you update, please?

Hello,

I’ve been using yournavigation.org for quite some time. But recently I needed a permalink to a route I’ve made, calculated right and as expected, but upon clicking on the permalink I saw a different way around added to the correct one, like this. If I move starting/ending point or tell it to recalculate the route, it shows the correct one, but permalink always adds that strange route around. Sharing such routes will confuse people.
If this problem was reported before, I beg your pardon, didn’t find any references.

Oeps didn’t notice this before. Update is already running for a few days and should finish this weekend.

Looks like a bug where opening the permalink always generates a route for motorcar AND the requested route type. I’ll see if this can be fixed.

Hey Lambertus,

I’m trying to set up a gosmore-based “routing backend” - I guess quite similar to yours - and I’m running into a lot of frustrating little issues, mostly due to missing documentation.

Currently I’m trying to get routing to work for “outside germany”, but creating a .pak file for say europe is impossible on 32 bit hardware (needs more than the addressable 2G Ram), my local system only runs 32bit, and Amazon EC2 is giving me major headaches.

I guess I’ll get it done at some point, and I’ll document how I got it done, but I wonder - how do you build the .pak files, do you split into limited boxes before, and what about “international routing”?

As I need the routing to be able to cross box borders (i.e. from Hamburg to Stockholm), I think there’s a lot of stuff that needs to be done to make this happen?

I’ve read the gosmore rebuild page on the osm wiki, but somehow I can’t make it fit to the current dev state… scratchinghead

Any advise welcome.

I’ve also noted that headless support was broken by some Android changes, but I was able to edit around them and will discuss that with “the author” (I guess Nic) by mail.

I guess a mailing list could or dedicated message board would be really helpful for the project :confused:

The author of Gosmore is indeed Nic Roets. And he also provides the routing backend for yournavigation.org since about a year or so. I also had lots of problems trying rebuilds. Some of these problems are due to difference in locale settings. E.g Dutch use ‘,’ as decimal separator while English countries use ‘.’. But this particular bug has been fixed long time ago, there may be other bugs lurking around. A 64-bit machine is very useful while working with OSM data (especially if you use large areas). I’ve switched to 64-bit a long time ago (not only for Gosmore but for the Garmin maps as well), I don’t know if Gosmore is capable of rebuilding a PAK file on 32 bit platforms. Windows won’t work anyway for PAK rebuilding.

For problems with Gosmore I will have to redirect questions to Nic Roets, but you can ask here as Nic reads these forums as well and it will probably help others. Just open a new topic in the Development forum for your project. Btw, there is a low traffic generic osm-routing mailinglist.

So the routing backend is run by Nic himself? I’ll ask him about details on how to build the proper PAK files in that case. Or maybe he stumbles over this post. I also have his mail address (it’s in the sources for Gosmore) so I can contact him directly.

Currently I’m only using the data for private use and for some experiments, so until recently, I did not need more than the german pak file I obtained somewhere in the internet; now, I have to plan a trip to Finland and need more than that :wink:

My EC2 instance is now happily crunching on the europe area, it has finished parsing the XML and is stable at 4.9G RAM, I just go to bed now and hope the best.

I’d use my local MacBook which sure is 64bit, but Gosmore does not compile on that for some Linux dependencies and I just don’t have the time to go fix on that. My older Linux boxes still run on 32 bit, and my web server is shared with other people so I can’t block it completely with such a task.

Yes, since about a year. I was having performance problems on the limited VM it was running. He found a server sponsor and volunteered to manage Gosmore there.

It will probably very difficult technically, as there are so many components that need to work together. But do you think it would be possible to get “social driving” to a routing server? The kind of driving that is found in the app Waze.

I was thinking of the following scheme:

  • a client app (on a smartphone) such as OsmAnd sends statistics to a server about the speed and direction over a short distance.
  • the server processes that speed information to see if there is a problem. In short term, the router will know something (like an accident) happened and wont give routes that pass along that point for a certain time (say 2 hours). In the long term, the routing service will learn from it, knowing that it’s not a good idea to send people to certain streets at 5PM.
  • client apps can use the better routing

Next to the problem of having a lot of instances working together, there is also a problem with the nature of OSM. First of all is, if a way is edited, the already processed data might be worthless (as the way can have a completely different form or length). So the raw (maybe privacy sensitive) data should be kept for a long time, and processed each time somthing changes.

Do you think it would be possible to develop this? Or am I just dreaming?