[OSM-talk] Why quality is more important than routing speed

[John F. Eldredge]

Speaking of using routing as a verification tool reminds me of a Potlatch question.  Recently, I have been using Potlatch, with the Yahoo aerial-photos background, to clean up some errors in data that originated with the TIGER import.  According to the Potlatch documentation on the wiki, if I drag a node belonging to one way onto a node belonging to another way, the nodes in that segment of the second way should turn blue to show that the ways will be joined. In practice, however, this doesn't always happen, and I sometimes appear to end up with overlapping, but not joined, ways.  What can I do to force the ways to be joined?

-- 
John F. Eldredge -- john at jfeldredge.com
"Reserve your right to think, for even to think wrongly is better than not to think at all." -- Hypatia of Alexandria

-----Original Message-----
From: Kai Krueger <kakrueger at gmail.com>
Sender: talk-bounces at openstreetmap.org
Date: Sun, 4 Jul 2010 15:46:49 
To: <talk at openstreetmap.org>
Subject: Re: [OSM-talk] Why quality is more important than routing speed



Frederik Ramm 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.
>
> ...
>
> 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.
>

That is an interesting line of argument and gets at the (usual) question of
how much end user support we want to provide. I.e. do we want to build a
routing service for anyone to use, or do we want to include routing on the
main page as an important debugging tool to ensure high quality routing data
for others to build upon.

I can't answer that question and I don't know who could, but I suspect that
(initially) focusing on integrating a router with the aim to use it as a
debugging tool would be less contentious. In that setting, the question of
how many tags you can support (and how frequent you can update the data)
very much becomes the main question.

So as long as OSMF can afford the resources to run it (and it appears as if
it is at least in the correct order of magnitude) going for the option that
is (more or less) available now and supports a large variety of relevant OSM
tagging seems like a reasonable solution. Then improve things iteratively
where there is demand.

If the load does turn out to be too large, then one can try and reduce it by
e.g. hideing it off the bottom of the screen as was done with the search
box, or by e.g. only offering it to logged in users as it is only meant as a
support for editing data.


Kai
--
View this message in context: http://gis.638310.n2.nabble.com/Why-quality-is-more-important-than-routing-speed-tp5252052p5254398.html
Sent from the General Discussion mailing list archive at Nabble.com.

_______________________________________________
talk mailing list
talk at openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk