> Yes: I think you misunderstand standard OSM mapping practice. I'm afraid I don't. I have seen it with my own eyes and I spent hours yesterday trying to fix some of it. Something which, incidentally, is made very difficult and time-consuming by the very large scale zooming that the editors require. Necessary on land, but crippling at sea.
> The tagging guidance is that two ferries can share a coastline > 'arrival'/'departure' node - quite valid as there is, indeed, > a routable connection here. > It does not say that ferries should share at-sea nodes. I know what the guidance says. In fact I quoted it verbatim in the posting that you are replying to. But the formal guidance has very little impact on the real-life practice. Just like wikipedia, OSM starts with incomplete, often malformed and sometimes plainly wrong information, which is then gradually improved. That's part of the very concept of collaborative editing that is open to everyone. You will NEVER have perfect data in OSM. And even when errors are fixed, some mapping features become obsolete and have to be re-done, so you get new errors. It is a never-ending process and that is why data consumers must never assume that the mapping is correct and should try, if and when possible, to correct it. > So the two 'correct' solutions would be: [...] Yes. But 1 is not supported by the current state of the OSM data and 2 is neither supported by OSRM nor by the OSM data. So no matter how "correct" these solutions might be, they are both inapplicable. - Wake up. The house is on fire. Take out the kids and call the fire brigade while I gather some of our stuff. - The problem is not the kids, but the fire. The fire brigade should do its job properly and put out the fire, so we don't have to evacuate. I think this sums up the argument whether OSRM should do something about the broken data or wait and hope for OSM to fix it. Z _______________________________________________ OSRM-talk mailing list [email protected] https://lists.openstreetmap.org/listinfo/osrm-talk
