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 _______________________________________________ OSRM-talk mailing list [email protected] https://lists.openstreetmap.org/listinfo/osrm-talk
