On Sun, Jul 4, 2010 at 2:20 AM, Frederik Ramm <frede...@remote.org> wrote:
> Nic, > > > Nic Roets wrote: > >> There is a lot of talk around better algorithms (e.g. contraction >> hierarchies), distributed routing, stress tests etc. So I'm going to >> put in into perspective with a few calculations. >> >> For a 40km journey, Gosmore takes 50ms*. >> > > It's all a question of user experience. Of course if I want to plan a route > it is not a big deal if I have to wait 50ms or even a few seconds. > > However if you have a fast service you can switch over to a more > interactive way of route planning (think Google's UI where you grab a via > point and drag it and get a new route instantly, even while dragging; or > where it computes a number of routes for you initially instead of just one). > This is also an aspect of quality, and allows the user to find a better > route. > That's a great point. Being able to quickly recalculate a route, when going off course (intentionally or unintentionally), or when traffic conditions change, is very important. On the other hand, I'm sure it's possible to cache some extra detail when creating the route which should make this relatively simple. If nothing else, finding a shortest (*) path when you've already got a relatively short (*) path calculated, is much quicker than finding a shortest path from scratch. Really I think the biggest cost factor contributing to quality is going to be keeping up to date with things like traffic, construction, etc. I don't foresee OSM being very useful on that front, especially up-to-the-minute traffic conditions. (*) With "short" defined however desired, not necessarily in kilometers. > Quality is not just how many tags you support, although in a rich > environment like OSM it is of course desirable to use as much information > from the data as possible. > The problem with that is that once you get past the most popular tags you're going to have very spotty coverage. How do you use speed limit tags when only 5% of the roads are tagged with them? Based on the title of this thread I thought Nic was actually going to say pretty much the opposite of what he said: that using high quality OSM data is more important than trying to squeeze a few minutes of time savings using less well-maintained OSM ways.
_______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
