Use flow_direction for waterway error detection

[emil813-cmd]

Description

Currently, the Warning message

"<Subject> flows against/{away from} a connected waterway"

is controlled by the oneway Key, even though that Key actually relates to traffic direction.

Thus, one may be tempted to add "oneway=no" when the water flows two ways or in an unknown direction, despite this being objectively the incorrect tag.

Please let the Warning messages and the displayed arrows be controlled by the flow_direction Key instead, when it comes to waterways specifically.

Waterways should function as having "flow_direction=forward" by default, which would be overruled by tagging flow_direction and setting it to a different value. If flow_direction is set to an undefined value like "unknown", then the waterway should behave the same as a highway without the oneway Key, i.e. give no errors and have no arrows.

In theory, flow_direction Key should perhaps be modified to use the same values as the oneway Key.

Screenshots

No response

[matkoniecz]

relevant code is https://github.com/openstreetmap/iD/blob/e8c4642d63553d61c41c169dd8184cd804f122c7/modules/validations/impossible_oneway.js

[emil813-cmd]

Yes, I thought it'd be like that.

The same code is used for checking traffic on highways and waterflow on waterways. But these use different keys to determine direction.

Also, waterways can have traffic too, so they should really be checked for both oneway and flow_direction separately.

(Waterways may even be part of the highway traffic to some degre, through leisure=slipway and waterway=access_point. But that is a question for another time.)

Perhaps one should write a more generic procedure that can analyze either traffic or "substrate" (i.e. liquids or gasses), and is called several times depending on network and flow type.

I suspect this change will have to happen eventually, but it is FAR beyond my abilities to implement.

Pseudo-code follows:

//flowType controls if key "oneway" (traffic) or "flow_direction" (substrate) is used.
//network controls which ways are considered part of the graph.
function genericDirectionValidator(flowType, network) {...};

//osmRoutableHighwayTagValues is only relevant for this particular combination of parameters.
genericDirectionValidator('traffic', 'highwaysAndFerries');

genericDirectionValidator('traffic', 'waterways');

//natural=spring is only relevant for this particular combination of parameters.
genericDirectionValidator('substrate', 'waterways');

//NB: oneway and flow_direction use different values to form tags.

[k-yle]

Also, waterways can have traffic too, so they should really be checked for both oneway and flow_direction separately.

is this documented anywhere? the wiki page is a stub, and the proposal only mentions flow_direction once, without any of this detail.

---

ignoring that part, the simple interpretation of this tag could be implemented by simply adding flow_direction to these constants.

[emil813-cmd]

Well, waterway=river says that it implies boat=yes, and leisure=slipway is used to connect highwayd and waterways, so waterway=* is used as traffic elements in some sense.

I don't know if there is enough boat traffic on waterways to necessitate checking for traffic there, but it is offensive to OSM that the iD-editor encourages using the traffic-controlling oneway=no instead of the correct flow_direction=both.

I'm not sure what "detail" @k-yle is referring to.

Those constants...
Yes, adding constants for flow_direction would fix the immediate issue. Could I ask you to do it, @k-yle ? While it looks simple, I don't have the courage for it...

• If you do, please also add flow_direction=unknown to osmOneWayBiDirectionalTags. 🙇

But the issue remains that one could potentially have a side stream on a waterway where it is only legal to sail against the flow_direction. In that scenario, the iD-editor's warnings for traffic and waterflow would still act up...

Bonus details, if desired:

• I notice that there are no recognized constants for disabling directedness, like what oneway=no or conveying=no would imply. In theory, flow_direction=unknown should also belong in this group.
• I've tested that oneway=no removes arrows on a waterway, but that conveying=no doesn't for some reason.

[emil813-cmd]

Should be fixed in emil813-cmd@cf84510.

[k-yle]

reopening, PR is not merged yet