[OSRM-talk] Island hopping

[Zenon Panoussis]

Florian, I don't think you and I will ever agree. In that sense we
are essentially polluting the list with unnecessary noise, because
nothing is going to come out of this discussion. At the same time
the issue is well worth arguing. If at any point you agree with this,
you are welcome to take it to mail.

> Okay - So by the bug you reported this is easy. Its a broken OSM Dataset
> by the definition of OSM reading the wiki.

I know. I said so myself in my very first posting: "The routes ...
do not fully connect to the harbour (this is an OSM mapping error),
but they do connect to each-other...".

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

> Nope - I speak for neither. I speak for myself as a software
> developer for 25 years, OSM contributer for 7 years,
> professional OSM data consumer for 3 years and an OSRM user for
> 18 months.

In that case I apologise for assuming you are an OSRM maintainer.
Perhaps your categorical way of replying to my first posts contributed
to my erroneous impression.

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

> I repeat - Its not an OSRM bug - Its an OSM bug. You reported a bug
> against OSRM and me and Dennis told you thats its a bug in the OSM
> Dataset.

What I said was that "this is also a bug in OSRM: it calculates routes
that require a mid-sea change of ship. It shouldn't".

Try to detatch from OSRM and look at this as an abstract problem. Say
you coded a calculator that uses some math library. It uses it 100%
correctly and by the book. But the linked library is buggy and causes
the calculator to return 2 + 2 = 5. The bug is in the library, not in
the calculator. That's what you're saying about OSRM and OSM. I agree.

However, the purpose of a calculator is to calculate *correctly*. A
calculator that returns 2 + 2 = 5 is buggy and useless by definition.
So when you say "Its not an OSRM bug - Its an OSM bug", you are correct
with regard to causality, but wrong with regard to functionality. The
user doesn't care who is the culprit; he only cares about the thing
doing correctly what it's supposed to do.

What would you do if you were the maintainer of this calculator? You
would (a) file a bug with the maintainer of the math library, (b) try
to patch the library, (c) use another library, (d) add a function in
your calculator to correct the error. (d) is the worst possible option
and that is yet another point on which we agree.

But in the case of OSRM and OSM, options a-c are simply not available.
There is no-one you can ask to fix the errors in OSM, no way that you
can fix them yourself and no alternative data source either. (d) is
all you have left. Either you do (d), or your calculator will remain
broken.

I look at it as elementary error handling. "Garbage in, garbage out"
is a colloquial explanatory expression and a bad excuse, but it is
not an acceptable principle in software development. You are supposed
to validate and sanitize your input, so that you never produce garbage
out, no matter how much garbarge in you get. "SQL injection? Not my
problem, GIGO". "XSS? Not my problem, GIGO". Would you ever say things
like that? I think not. But when OSM users vandalise OSM - usually for
lack of understanding and only seldom on purpose - and render OSRM
output useless in the process, you just shrug your shoulders and say
"GIGO". Would you ever hire a developer who expresses such a cavalier
attitude to functional problems in his interview?

> 7 years ago we had zero, nil, nada routing applications. New OSM bugs show up
> every day. This is the because people not only map but start to USE the data
> for navigational purposes. Every day i fix problems in the dataset which
> influences routing. keepright is full of unconnected routes. I am actively
> searching for those problems with software i write. Other people simply use
> Skobbler, OSMAnd, Mapfactor Navigator and whenever they discover a bug in
> routing they fix it in the data or if just a simple user open an OSM Note.

I am not arguing that. What I am arguing is that the problem must be
addressed on multiple levels and not only on one. If you can't solve
a problem instantly and fully, you have to (a) work on solving it and
(b) try to mitigate its effects in the meanwhile. You are stubbornly
pointing at (a) and refusing to even consider (b).

> Are you also assuming that OSRM should allow routing of crossing
> streets without a shared node? No you dont. Its easy. It the mathematical
> description of a graph. Whenever you want to go from one edge to another
> edge you require it to be connected by a node. No Node - No routing
> from one way to the other.

That's not the problem I reported. The problem I reported is that
there are shared nodes at sea. Thousands of them. They make a total
mess of routing and not only at sea. The subsequent land routing goes
wrong as well.

> Ferry routes are correct but they NEED TO CONNECT TO ROADS TO WORK.
> This is in the Wiki for years - If you dont connect it the ferry
> routes are not part of the routable network - full stop. Nothing
> can be done here.

No, something can be done. If one ferry route connects to another
without first connecting to land, *do not route between the two*.
You have a fine example of it here:

http://s4.postimg.org/fhj50g599/connecting_routes.png

You see those five dashed lines coming from the west and converging
into one just northwest of Rhodes? That's one connecting node between
all of them, which causes OSRM to route as if you could change ferries
at that point and make a U-turn in the middle of the sea. You shout
that ferry routes "NEED TO CONNECT TO ROADS TO WORK" and I fully agree,
but why isn't OSRM implementing that? if !road_connection: drop_this_shit()
That is precisely what I suggested and you opposed.

That connecting node and the simplification of five routes into one
were put there by someone who neither read the OSM guidelines, nor
gave the subject any thought. The world is full of those people.
Some of them do a lot of valuable work on OSM despite their
shortcomings and OSM is full of their work. If we followed your
reasoning that responsibility for fixing errors lies squarely where
the errors originate, we would have to ban those people from editing
OSM and turn OSM into an elitist project. That's the exact opposite
of the open collaborative spirit that OSM is based, so and it's not
going to happen. So therefore you will always have piles upon piles
of such errors. So therefore OSRM and all other data consumers need
to implement safeguards against OSM errors. And that's what I've been
saying all along.

BTW, tonight I fixed yet another bunch of bad ship routes in Greece.
I bet you seven beers that a very intelligent person with all the
good intentions will soon unleash a bot to find and merge duplicate
ways in OSM using some proximity algorithm. Obviously you can't have
two streets running 100% parallel to each-other for many kilometres
only 2 metres from each-other. Obviously it is a mapping error,
probably caused by some projection mismatch. Automerge. And there
go my painstakingly added route corrections. What are you going to
tell me then? To do them again because OSRM refuses to correct OSM
errors?

Z