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