[Strategic] Featured routing services

Frederik Ramm frederik at remote.org
Fri Mar 4 09:26:44 GMT 2011


Eugene,

On 03/04/11 10:03, Eugene Usvitsky wrote:
> ... or let others do it for us and use it. I prefer the
> second variant partly because commercial companies make money with it
> so they do their best to make everything as good as possible.

I was just saying that if we want to make use of the MapQuest routing 
service then why not simply redirect people to the MapQuest site instead 
of spending time to access their API from our site (with all that 
entails - e.g. if there is a bug in routing, people would then come to 
our mailing list instead of contacting MapQuest etc.).

You can become attracted to OSM just the same whether you use routing 
here or there.

>> OSM thrives on the "unexpected" uses people find for our data. It will be
>> the same with a routing engine that can be used for quality checking -
>> people would not be limited to the two things that you can currently think
>> of; people would find their own uses.
>
> Here I don't currently understand the situation. AFAIK, internal
> checker is "internal" because it will not provide API for anyone
> outside core project developers.

No; you are the first person I hear talking about two different routing 
services. Until now discussion has always been "Do we need routing and 
if so, why)", and some people answered "to make OSM web site more 
attractive to outsiders" and others answered "to improve quality 
internally". There was never talk of two different routing engines for 
the different purposes; it was assumed that if we were to offer a fast 
routing engine with some sort of API, then various "power mappers" - 
certainly outside the core project developers - would start writing cool 
applications, for example generating distance matrices or other stuff 
that we cannot foresee.

In my eyes, whether or not OSM wants to offer routing (using an external 
routing service like MQ) on the web site is an more of a  cosmetic 
choice which doesn't affect the budget and I am slightly surprised that 
Strategic should even concern themselves with it.

Whether or not OSM wants to operate their *own* routing server is a 
question that has budget implications, and that question is one that 
Strategic should discuss.

If one of the first points you make is that you think we shouldn't 
operate our own routing server (and your concerns are certainly valid!), 
then in my opinion the question leaves the realm of Strategic at that 
point, unless Strategic view themselves as the OSM Web Site Design Team.

Bye
Frederik



More information about the Strategic mailing list