[OSRM-talk] Island hopping

Florian Lohoff f at zz.de
Wed Oct 15 19:26:29 UTC 2014


Hi Zenon,

On Wed, Oct 15, 2014 at 03:07:47AM +0200, Zenon Panoussis wrote:
> 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.

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

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

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.

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

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

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.

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.

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

So OSRM does it right and OSMAnd and all other routing applications
are broken even more?

> I don't need the ferry routes. They just mess things up for me.

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.

> 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

Argueing over and over again wont make it right. Dennis and me
told you that its about fixing the data not putting more semantic
assuption into the OSRM preparation. I also think that i
gave you some more examples on why this is not as easy as you
wrote in pseudo code.

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

Its your choice to remove the data. Map data is broken everywhere. 
HERE, Google, Bing wherever you look you'll find broken data.
The difference in OSM is that you can fix it yourself.

If you choose to hide the problem - do so. I'd rather show it
publicly thats something is broken like keepright, osm inspector
etc do and fix the data. Otherwise we loose the biggest advantage
of OSM.

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

OSRM uses OSM data to calculate the shortest path on a given graph.
If OSM gives a broken graph the calculated shortest path is broken.

Shit in - Shit out.

> broken data. OSRM is a separate project that should try to do a
> good job irrespective and despite of OSM's shortcomings.

Some long term observations here. I worked for different Internet
Service Providers in the past 20 years in the area of software
development for network management systems. All big ISP have
databases of their assets and configuration. All data which
has direct operational dependency e.g. the "hostname" of a device
which ends in DNS is one of the best maintained data items.
All values which have no direct usage like a line card serial number
contain garbage.

So whenever you work around problems people start entering even
more bullshit and you need to work around even more. So whenever
i start something new i make a VERY TIGHT dependency on the data
i need. If its bullshit its broken. Take care the user gets a very
direct feedback and voila - Your data gets maintained.

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

I am not the/a maintainer/developer of OSRM and as such 
i cant decide whether OSRM will gain workarounds for problems like this.

Dennis has commented on this thread aswell and i remember him
beeing very clear that your reported problem is an OSM dataset
problem and should be fixed in the data.

Flo
-- 
Florian Lohoff                                                 f at zz.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <http://lists.openstreetmap.org/pipermail/osrm-talk/attachments/20141015/4d130253/attachment.sig>


More information about the OSRM-talk mailing list