I just had a discussion at Advrider about duplicated ford tags, having a way with ford=yes and a node tagged on that way, also with ford=yes.
The question is, how to handle this? IMHO duplication is bad, and the two fords should be merged into one, either as way or as node. Personally, I believe that the way would be the better tag. Is there a general approach or opinion on that?
Apparently, the reason why the fords are tagged twice is that some renderers do not render fords tagged as ways, and that some routers handles nodes different to ways.
What do you think? Is there a general consensus on this? I couldn’t find anything.
BTW: An overpass query showing these duplications can be found here
Well I disagree with the “Tagging for the renderer” expression, I see more it as tagging for the user. Where you have a country that have perhaps millions of fords even in major roads; those become a hazard for driving (day or night) so you need something that alert you of what is coming ahead, several fords are just seasonal and mostly are just a small ditch that cross the road; others off-course could be dozens of meters wide depending of the flow of the river or the riverbanks. Tagging the Ford as a way is the most common when you have a distance for the area to cross, but proved that many navigators do not make difference with a regular road or bridge; so adding the Node Ford make the alert to be triggered. Mostly of the GPS used are Garmin, Maps.me and OSMAND and None of them gave “problems” with these “double” marking…
The issue I see with duplication is that we have to enter the data twice. If a ford is seasonal, we have to add seasonal to the node and the way. If one is not updated, results (e.g. routing) might be incorrect, as only one ford has been updated.
Wouldn’t this be an issue we should raise with Garmin, Maps.me, and OSMAND then? Since OSM allows both ways, also GPS devices should be able to support both ways?
The OSM policy is that you should fix the navigator, not duplicate features on the map.
In any case people should not be relying on a crowd sourced map for safety critical information.
The OSM policy is that OSM should attempt to describe the real world and it is the responsibility of the navigators, map tile generators, etc. to present that information in an a form that is useful to human users. There is only one ford in the real world, so there should only be one OSM object describing it, and generally that should be a way, unless no details of its two dimensional structure were known to the mapper.
The Wiki clearly state that the “way” fords should be marked in the drawn “riverbank” and this is not the case because riverbanks are not drawn in mostly of the cases, due that majority of the rivers are intermittent, the ford is there not necessarily the water, and it’s almost impossible establish the “deep” or when in the year could be “traversable” or not.
I do prefer to mark the fords with nodes at both ends of the “theoretic” riverbank than marking a way that is unsure it is actually a ford
I agree with hadw that a ford should only be in the database as either a node or a way, but not both. The “one feature, one OSM element” rule is a good principle to follow here. When in doubt, the way is preferable, as it gives information about the extent of the ford.
If some application does not work with a correctly mapped ford, then that software is flawed and needs to be fixed. Please don’t add questionable data to “work around” the issues in those applications: That only punishes developers who implement their software correctly, as they will now be the ones showing wrong information on their maps.
Wiki.
This does not say the polygon natural=water water=river must be drawn first, if you draw ford way first, that is not a problem, the man who later draw the polygon must attach to the fordwaynode. Then the rule is correctly executed.
Otherwise we never could draw way ford, when there is not drawn in polygon. This is not intended.
When way ford is drawn on the aerial riverbank, then this is correct. This is what i read from the wiki, must be set on the riverbank.
Misunderstanding: riverbank on the aerial versus riverbankline of polygon.
The best is to draw a line way, that is a ford, this has much more information about the ford. Even such ford can be cut in parts, with other tags, part is surface=concrete.
If a gps/app does not/can not work with line way ford, that is the problem op de gps software/app. And should be asked to change it by the makers.
I understand your need for warnings, I agree with that, but setting two elements is wrong, there other solutions.
The best is, gps/app, makes it work.
Or
Work around: to make you own POI file, like they do with speed camera.
If the gps/app can work with promixity alerts. POI, Locus does. Which other gps/app can do this? Like to see a list.
Now also on the carto map (Openstreetmap basemap) there mostly two icons for one feature. This is not right!
On a ford, the way, the icon is set in the middle.
On a ford node, where the connection is to the node of the waterway, …this connection node, could be, not in the middle of the riverbank… and give a problem.
Such situations. http://www.openstreetmap.org/node/354519060
There is only one ford, and two icons. WRONG.
Sometimes there so close, that a render projects one, but this is only because it does not project two over each other for readability, the problem stays.
A ford could be: cut in parts.
--------------\incline,…intermittent part of ford…_wet part of ford__/…intermittent part of ford…,incline/--------
A good render could see this as one ford, because he see connecting highways ford=yes, and set one icon.
He can visualise it, as it is.
Or set special icons for in or out of the ford.
About alerts, depends on from what side your coming, he can give the right distance in front, where the intermittent part starts and the wet part. Even a voice spoken warning. All possibilities.
This is not possible with a ford=yes on a node!
Contradictory tags must be avoided, now and future, this can not with two elements.
We must do it right, like the situation is. The best is on a way.
I like to see a mechanical edit to change this world wide and keep the way.
Firstly, thanks to @boldtrn for that overpass query - it’s actually identified lots of places not that far from me where someone’s added ford=yes to a way by mistake on one of the highways leading into the ford which isn’t remotely ever wet.
I don’t think that it makes sense to render ford ways (which might be quite long) with just a single icon so I actually went with https://map.atownsend.org.uk/maps/map/map.html#zoom=19&lat=53.198859&lon=-1.888956 on a different rendering. There’s always room for improvement - perhaps only a central bit of the “ford=yes” track in that example should really be ford=yes? As ever, things get improved as they are resurveyed over time in OSM.
To summarise:
Sometimes there are valid reasons for tagging both ford=yes on a node (usually the wet bit is essentially a single point) and a way (sometimes it isn’t). Data consumers can figure out when a ford=yes way has a ford=yes node on it and can ignore the latter if they wish to.
I think the OSM Carto rendering isn’t doing a good job of rendering ford=yes ways currently, but to be fair what they’re doing now is very much a first iteration.
A mechanical edit to remove ford=yes nodes where they are part of ford=yes ways would be a bad idea because most of the data are mistaggings.
Whether you mean “in OSM” or “in real life” the answer can be yes - there are certainly “long fords” not far from me where the road and the water cross a couple of times. When there’s a lot of water flowing you’d share the same path as the water for a while; when there isn’t it might go “dry wet dry wet dry” etc.
Riding through the river in the length of the river is riding through the ford, parts water, parts intermittent, still a ford. There for we have the intermittent tag! When you mean goes in/out the river, that is a other situation, land, river, land, river, land, then you have multiple fords.
There also set ford nodes, in to the ford and out of the ford, this is wrong, only waterway connection nodes are possible.
These are set for specifically use in apps to get a warning, as mentioned above.
When a ford way is drawn. There is no need to set ford nodes, these can be calculated for the connected point with waterway. Icon could be set by the app, if needed.
One element, one feature, is the way to go!
When only node ford is set this a limited information.
I need for calculating the point where the driver goes in the ford, also as the first part is intermittent, sometimes still wet slippery, because of coming out vehicles, wet tyres, triple caution, algae vegetation and ford is sometimes concrete for the full length of the ford with low water and with high water reached the riverbank to it’s full width.
Ford ways give much more information and should be recommended to tag.
What is the best way to tag a ford, node or way?
Rule: You can only answer with yes/no, here, node or way.
Hoped to solve the problem, which is also on the tagging side.
By asking a single question.
When is a ford better tagged.
To make the database better, more correct to the situation.
Yes.
Either a node or way can work, depending on the specific circumstances. I see no reason to dictate that only one or the other can be used for all situations, because all situations are not equal.
That being said, I also agree that either a node or way should be tagged for a single ford, not both. One feature, one element.
