Talk:Tag:highway=ford
Ford Classifications
Any suggestions by anyone how different categories of fords should be recorded?
For example how would you distinguish the following:
- Surfaced fords at a point such as Barwick Ford
- Irish Bridges at a point, such as Buntingford
- Unsurfaced fords at a point with surfaced approaches, such as Standon
- Unsurfaced fords at a point with unsurfaced approaches, such as Latchford
- Unsurfaced fords running along river beds for a distance, such as Furneaux Pelham (south from this point for about a mile.
- Surfaced fords running along river beds for a distance, such as near Hazel End
- Surfaced tidal roads running in or across the sea (e.g. to Holy Island)
- Unsurfaced tidal roads running in or across the sea (e.g. Maplin Sands)
-- ford=yes is a very good proposal. Joosep-Georg 17:26, 31 January 2010 (UTC)
In the short term, I've tried using surface=paved or surface=unpaved against the ford node to indicate whether it is surfaced or not. I'm not sure how an Irish Bridge would be recorded? I think a ford=yes tag against a highway 'way' may work, but it would need to be rendered somehow. Another suggestion for consideration that user:sk53 raised would be the addition of a depth_guage=yes tag to the ford node. Any suggestions would be most welcome.... C2r 22:53, 16 May 2009 (UTC)
Hi, I'm new here and have no experience about the correct syntax. But I'm missing information like:
- ford_depth=40 (ford is normally 40cm deep)
- ford_remark=* (e.g. "Glacier river. In the morning 30cm deep; in evening 60cm deep)
The depth could important for routing. In the future may different colors possible.
-- Speleo 22:58, 26 October 2009 (UTC)
Ford Rendering
In Mapnik a Ford is rendered by a vehicle ford image. Does somebody knows what are the action to be taken to render the ford by a different symbol when it is on a footpath ? Matclab 16:28, 16 August 2010 (BST)
Not deprecated
Why do users keep editing this page to say this tag is deprecated? The proposed ford=* hasn't yet been approved, so how could highway=ford already be deprecated?--Alester 05:33, 26 August 2012 (BST)
It seems to me that both forms are useful. ford=yes is a good option on a way, where a ford is long enough to justify specific rendering, and highway=ford is adequate on a node for small fords, and easier for contributors to map. I see no ambiguity, and I can't believe it is difficult for renders to handle both options. It's good to ask the question, though, in case we are missing something. If no sensible answer emerges, I would like to see the deprecation comments removed in order to avoid confusion. Perhaps a better option would be something along the lines of: On a way, "highway=*, ford=yes" is to be preferred over "highway=ford". --Peter Reed 10:27, 28 August 2012 (BST)
As there seems to be no objection, after three weeks, I have now removed the suggestion that this form should be deprecated
- The problem with highway=ford is that it leaves no room for the original meaning of the highway tag. Because of this, most renderers and routers do not support it. You don't tag bridges as highway=bridge do you? or tunnels? Or embankments? Or incline? or narrows? A ford is just a property of an otherwise properly tagged highway and should be tagged as such. There is no room for the asinine highway=ford.
- highway=ford on ways at least makes more sense than highway=steps (which can either mean highway=path + steps=yes or highway=footway + steps=yes), as fords are very distinctive from the other parts of the roads. E.g. how do you assign a tracktype to a ford? It's not so much the ground material (stones, concrete) that matters, but rather the depth of the water. For a main tag like highway=ford, it's easy to add attributes like depth=0.3. With a main tag like highway=unclassified or track, attributes like depth=* may be interpreted differently, eg. as the depth of the ruts. --Fkv (talk) 13:45, 11 July 2016 (UTC)
- Steps can't usually be navigated by bicycles and wheelchairs, roller skates and so on - they are more distinct from footway/path than footway/path from each other. For a ford this can't easily be said and it is more important to me to preserve the road importance. Your concerns about depth are easily circumvented by using ford:depth=*.--Jojo4u (talk) 16:51, 11 July 2016 (UTC)
- There are all nuances between steps and paths, see the highway=steps + surface=ground ways I have mapped, for example. Preserving the road type sounds fine, but do you do the same thing with ferry routes? A ford is a serious barrier which can only be passed by certain vehicles or with certain equipment (boots), and possibly only at cartain times (low water).
- As to ford:depth, I consider it evil to invent new tags for meanings that are already covered by existing tags. Imagine a peak with a cairn, and a cross on top of the cairn. You can tag it with natural=peak + summit:cairn=yes + summit:cross=yes. But when you want to add the name of the cross, you need a tag like summit:cross:name=*, because name=* could be the mountain's name. For the height and elevation of the cairn and cross, you additionally need summit:cairn:height, summit:cross:height and summit:cross:ele. It's much better to make separte OSM objects with the respective main tags natural=peak / man_made=cairn / man_made=cross. Likewise, we better make separate OSM objects for ford and road whenever we have conflicting attributes. depth=* was only one example, it could also be name=* or start_date=* etc. --Fkv (talk) 19:37, 11 July 2016 (UTC)
- Steps can't usually be navigated by bicycles and wheelchairs, roller skates and so on - they are more distinct from footway/path than footway/path from each other. For a ford this can't easily be said and it is more important to me to preserve the road importance. Your concerns about depth are easily circumvented by using ford:depth=*.--Jojo4u (talk) 16:51, 11 July 2016 (UTC)
- highway=ford on ways at least makes more sense than highway=steps (which can either mean highway=path + steps=yes or highway=footway + steps=yes), as fords are very distinctive from the other parts of the roads. E.g. how do you assign a tracktype to a ford? It's not so much the ground material (stones, concrete) that matters, but rather the depth of the water. For a main tag like highway=ford, it's easy to add attributes like depth=0.3. With a main tag like highway=unclassified or track, attributes like depth=* may be interpreted differently, eg. as the depth of the ruts. --Fkv (talk) 13:45, 11 July 2016 (UTC)
- There's also a pricipal reason for highway=ford: It's a physical feature, so it deserves a physical tag. Tags with *=yes values are only attributes, they require an additional, physical main tag. The bridge=yes tag bears that dilemma too - that's why man_made=bridge has been introduced. --Fkv (talk) 13:45, 11 July 2016 (UTC)
- Man_made=bridge is not defined for nodes, only for areas. You want to map an abstraction with a "physical tag". A ford is also not a structure like a bridge: the extent of it is often unclear. ford=yes means: this way leads trough a ford - like bridge=yes is meaning: this way leads over a bridge. As a side note: junction=yes and mountain_pass=* are also tagged without the highway key. I see the benefit of uniform tagging much greater than "key consistency"--Jojo4u (talk) 16:51, 11 July 2016 (UTC)
- Physical features are physical features, no matter whether we abstract them to nodes, lines or areas. We map peaks as nodes, and you certainly agree with me that they are physical features. When you say that bridge/ford=yes only mean that the way leads over a bridge/ford, it becomes obvious that the bridge/ford itself is missing. There are fords that physically consist of, well, nothing. But there are also fords with a base made of concrete or big stones, and a weir-like step at the downstream side to increase flow speed. These structures occupy a well-defined areas, so we could map them as areas if we wanted. However, there's no so much a need to map them as areas, as we need to do with bridges. There are often several ways (carriageways, cycleway, footway...) running over a bridge. We never have these ways separated on a ford. At least I have never seen such a case. --Fkv (talk) 19:37, 11 July 2016 (UTC)
- Man_made=bridge is not defined for nodes, only for areas. You want to map an abstraction with a "physical tag". A ford is also not a structure like a bridge: the extent of it is often unclear. ford=yes means: this way leads trough a ford - like bridge=yes is meaning: this way leads over a bridge. As a side note: junction=yes and mountain_pass=* are also tagged without the highway key. I see the benefit of uniform tagging much greater than "key consistency"--Jojo4u (talk) 16:51, 11 July 2016 (UTC)
- There's also a pricipal reason for highway=ford: It's a physical feature, so it deserves a physical tag. Tags with *=yes values are only attributes, they require an additional, physical main tag. The bridge=yes tag bears that dilemma too - that's why man_made=bridge has been introduced. --Fkv (talk) 13:45, 11 July 2016 (UTC)
- Then why should we keep it; even for nodes?
- While there are pros and cons for highway=ford on ways, highway=ford on nodes is clearly beneficial: Many rivers are mapped as both lines (waterway=*) and areas (waterway=riverbank or natural=water + water=river). When a highway=* crosses that river, you probably create a road segment with ford=yes spanning the riverbank, but you should also create an intersection node with the waterway=* line, because they do have contact in the real word too. If you tag that node with ford=yes, you get that highway=ford tag on 2 OSM objects, although the ford only exists once in the real world. Tagging one object with highway=ford and the other with ford=yes elegantly solves this issue. Two different tags, one for each abstraction level, is just the logical extension of the concept we use for rivers. --Fkv (talk) 13:45, 11 July 2016 (UTC)
- If the way is tagged with ford=yes, the intersection with the waterway does not have to be also tagged - as it is described in ford=*. Do you see any data issues with this?--Jojo4u (talk) 16:51, 11 July 2016 (UTC)
- Yes. We need to split ways for various reasons, e.g. because the highway has a certain ref=* up to a certain point, and another ref=* starting from there. This may incidentally be right in the middle of a ford, because administrative boundaries often follow rivers. (I have already split some bridges for that very reason.) When you split a way tagged with ford=yes, you get 2 ways tagged with ford=yes. When a renderer uses a point symbol for fords, it will certainly render 2 symbols, although there is really only one ford. Similarly, when a router meets the 2 ford=yes segments, it will warn of "2 fords ahead". Compare to railway=level_crossing and highway=crossing: These can be automatically determined from other data, but we use to tag these explicitly, even though that splitting problem cannot happen to them. --Fkv (talk) 19:37, 11 July 2016 (UTC)
- If the way is tagged with ford=yes, the intersection with the waterway does not have to be also tagged - as it is described in ford=*. Do you see any data issues with this?--Jojo4u (talk) 16:51, 11 July 2016 (UTC)
- While there are pros and cons for highway=ford on ways, highway=ford on nodes is clearly beneficial: Many rivers are mapped as both lines (waterway=*) and areas (waterway=riverbank or natural=water + water=river). When a highway=* crosses that river, you probably create a road segment with ford=yes spanning the riverbank, but you should also create an intersection node with the waterway=* line, because they do have contact in the real word too. If you tag that node with ford=yes, you get that highway=ford tag on 2 OSM objects, although the ford only exists once in the real world. Tagging one object with highway=ford and the other with ford=yes elegantly solves this issue. Two different tags, one for each abstraction level, is just the logical extension of the concept we use for rivers. --Fkv (talk) 13:45, 11 July 2016 (UTC)
- It has not been 'approved', but there is (soon to be more than) 20 times more ford=yes than highway=ford on ways. And more ford=yes on nodes as it is. And when did highway=ford get 'approved' in the first place? --Gorm 22:52, 28 October 2012 (UTC)
- One reason why there are more ford=yes than highway=ford is that most highway=ford have been changed to ford=yes via illegal semi-automated edits such as "keepright fixes". This is a vicious circle: Marking the feature deprecated triggers validator warnings, validator warnings trigger mass edits, mass edits change usage numbers, and usage numbers make people mark the feature deprecated. --Fkv (talk) 13:45, 11 July 2016 (UTC)
Area tagging
How do you feel should the area of a ford be tagged? Should highway=ford be used or should analogous to highway=* something like area:highway=ford be used? I lean to the latter since a ford is often not engineered more than a road. Also the double-tagging with appropriate water area tagging should be considered (see River: waterway=riverbank or natural=water)--Jojo4u (talk) 15:51, 12 July 2016 (UTC)
- highway=* + area=yes is used where you can drive/walk from any point within that area to any other point within that area. You don't do that on a ford. You head straight to the other side. That's why highway=ford + area=yes seems wrong to me. It should rather be man_made=* (but we don't use that key for anything road-related) or area:highway=*. I suppose that the latter, when approved, will need to match the corresponding highway=* value, so when you have a highway=ford, it's area:highway=ford, and when you have a highway=xxx + ford=yes, it's area:highway=xxx. --Fkv (talk) 17:11, 12 July 2016 (UTC)