[OSRM-talk] Island hopping

[Zenon Panoussis]

> The point is either:

> a) We fix the OSM Dataset to be semantically correct with current
>    rulesets we have
> b) Try to teach each and every OSM Data consuming application 
>    how to interprete a very complicated semantically group
>    of exceptions for rare cornercases. 1)

I think you're mixing up responsibilities. The OSM data are OSM's
responsibility. OSRM is OSRM's responsibility. OsmAnd is OsmAnd's
responsibility. And so on and so forth. Each project needs to fix
its own bugs, rather than expect the others to fix theirs first.
If you are part of more than one of these projects, which would
be the most natural thing in the world, you need to keep your
project loyalties strictly separate from each-other.

> If we dont fix all other routing applications besides OSRM the
> user experience with OSM will be inconsistent (Even more than
> it is today) and OSM will be blamed.

Who do you speak for? OSM or OSRM? To me it looks as if you are
caught in a conflict of interest.

It's not at all unusual and we have had a canonical way of dealing
with it for decades already. Downstream feeds his bugs to upstream.
If upstream fixes, downstream applauds and thanks. If upstream
doesn't fix, downstream patches. If patching goes too far, downstream
forks. Standard procedure, known to mankind ever since Adam forked
the snake's recipe for apple pie.

In this case "upstream" is not a vendor or a team of contributors,
but an amorphous mass of thousands upon thousands of OSM contributors.
You can't tell them anything, because most of them are too enthusiastic
to listen. The cause of the problem I reported here today has been
described at http://wiki.openstreetmap.org/wiki/Tag:route%3Dferry
ever since 24 August 2009. "Please remember to connect each end
of the ferry route to a way on land. This is important to ensure
functional routing. The connection should be on a node shared with
the coastline". Five years down the line, these mapping errors have
multiplied exponentially. How much longer than five years do you
need to realise that the consequences of this problem must be
addressed separately from the base problem itself?

> Fixing the data will fix the user experience disregarding the application the
> user is using. 

I already followed your advice to the letter, and I fixed the
data. I did so on these principles and in this order:

1. Remove errors.
2. Replace errors with correct information as fas as possible.
3. Add new information when possible.

As a result, *all* sea routes to Piraeus are now broken and the
problem that I originally reported has been solved. I did a lot
of work fixing a number of ferry routes between Paros and Naxos
and Santorini and Folegandros according to my (2) and (3), but
I do not have the information needed to fix Piraeus itself.
Result: as 90% of all ferry traffic in Greece goes through
Piraeus, most routes between the islands and the mainland are
now gone. Is this good or bad? It depends, it could be either,
depending on what you use the data for. But at least we have no
more false data any more. That, already in itself, must surely
be good.

> OSRM is only a small part of the whole OSM ecosystem - There are
> literally thousands of applications consuming OSM Data. Consuming
> OSM Data is a hard task anyway - do you recommend making it even
> harder by construction even more semantically complicated rulesets
> to be forced on all those consumers? 

I did not suggest any change of OSM rulesets. I suggested a
change in the way that OSRM processes its data. The ecosystem
that consumes OSM data is completely unaffected by whatever
OSRM does. Only those who consume OSRM-processed data are
affected by what OSRM does. And not even necessarily.

I consume OSRM-processed data too, but from my owm osrm-routed.
Which means that I can completely remove ferry routes from the
data before I run osrm-extract and osrm-prepare on it. Now see
how tactic reasoning can backfire:

I don't need the ferry routes. They just mess things up for me.
I report the problem anyway, but you are not willing to do
anything about it because you think that not fixing the OSRM
routing algorithm will force people to fix the OSM data. So
then I remove the offending dataset from my maps and now suddenly
we have a bunch of people, my users namely, who will never even
see that there was a problem with that data in the first place,
so they'll never fix it even if they would have wanted to.
That's what happened today. To me it looks like something
counterproductive in the overall picture. For you, for me, and
for everybody else as well.

> Dont try to paint over broken data.

In principle I'm fully with you on this. But in practice you need
to have one hat at any given time. OSM should not paint over OSM
broken data. OSRM is a separate project that should try to do a
good job irrespective and despite of OSM's shortcomings.

I hope I have explained my view sufficiently without being too
polemic. I really have no interest in flame wars. If you think
that I have a valid logical argument that is based on false
factual premises, I'd be very interested to hear about them.
But if you think that my premises are correct but my evaluation
of the appropriate action is wrong, I would suggest that we agree
to disagree and leave it at that.

Z