I was intrigued by this news story and decided to have a look at the road in OSM.
It is apparently flooded and inaccessible for four hours a day at high tide. while the current tag flood_prone=tidal seems accurate, it also seems a bit of an understatement. This road is not just prone to flooding at high tide, it floods every day at high tide. Perhaps a conditional access tag might give more information here? Something like access:conditional=no @ high_tide?
Another indication is that this road is outside of the natural=coastline way (high tide line) and is not tagged bridge=yes. Theoretically a data consumer could use this spatial information to determine that this road is underwater at high tide, but it is unclear to me if this would a be a reasonable expectation.
Please share any thoughts on how this situation should be tagged.
That said, if you use a keyword as a Boolean condition, it needs to use snake_case, similar to a well-defined OSM tag value.
So far, intermittent=yes is only documented with respect to watercourses and waterbodies. It’s an unconventional solution, but quite logical. I don’t know of any renderer or router that currently looks for this tag on a roadway, but it would be much more straightforward than parsing a rare condition out of the conditional restriction syntax, which precious few data consumers support.
Yeah, it may not have come across that some of my suggestions were a little tongue-in-cheek, and half-joking but also half-serious in that it might almost work.
This case reminds me of the similar case where a trail might sometimes be a stream instead, so similarly having the road be both a highway=residential and a natural=water (or waterway= of some sort) almost makes sense?
In practice I doubt a general router or data consumer is going to take the time to look up local tidal information and do different routing based on it, unless it’s really specialized for the specific road, even if we were to come up with and standardize the perfect tagging scheme for it. Just using hazard=flooding and/or the existing flood_prone is probably going to be about as good as one can do to try to make consumers aware to alert users that the road isn’t always passable.
Seems reasonable. A general sort of “be aware of potential flooding” warning is all I’d really expect from a data consumer in this case, but it seems like it could be a bit more specific like “this road floods every day at high tide”. Maybe something like hazard=flooded_at_high_tide?
“Causeway” doesn’t imply “floods at high tide” to me, but that may be my American ears.
I do like how that example you linked includes a description=; I think that’s generally an underutilized key and can be helpful for a lot of these “Hey, this thing is weird and users looking at this might want to know about…” situations
On a more serious note, the access=tidal there has a little bit of use and may not be a bad option to add to other places like this as well. I’m curious how common routers generally handle otherwise-unknown/undocumented access values.
The handling of undefined access tag values is naturally undefined, so data consumers behave differently. Some equate an unrecognized access tag value with yes, such as OSRM’s default driving profile and OSM Carto. Others equate it with no.
For example, this residential road bridge across Hamburg’s Fährbuernfleet is tagged access=disabledbicycle=yesfoot=yes. I suppose a car with the appropriate disabled permit would be legally allowed to drive on the bridge, if they can get there first. OSM Carto doesn’t depict anything out of the ordinary:
There’s nothing really stopping us from using a novel access tag to indicate this situation, but it would be obscure enough that we wouldn’t be able to count on data consumers to get it right. Previously, Amazon Logistics got away with tagging access=customers en masse on parking lot aisles because most people don’t normally want or need to use a parking lot as a through route. access=permit was proposed without so much regard for existing data consumer behavior, under the assumption that data consumers are already mishandling the situation anyways. After all, it isn’t very easy to get permit-required cases right:
Unlike most causeways, this road is not raised up on an embankment. There is a little raised bridge over the permanent water channel, which is the only part that doesn’t get covered by the tide. The rest is at ground level. Here’s a video:
Even though there’s no embankment, it might still technically be considered a causeway since it’s surrounded by squishy marshland but the roadway is obviously made of firmer stuff. Regardless, there are plenty of causeways that are permanently above water so I think “this road is a causeway” is a different piece of information than “this road is flooded at high tide”.
The wiki says (and I tend to agree) that “a ford is usually safe to cross when covered in water”, but this road is generally thought to be unsafe when water-covered (if I’m understanding correctly).
Causeway implies a raised section of road. One I can think of in my part of the world is Swarkestone Causeway, which isn’t tidal but does carry a road over a wide floodplain. I have never known the road to flood.
The wiki states that this tag “indicates that an element is in the tidal range”. Definitely applicable to this case. I’ve added it here. I also added hazard=tide and a description based on this example:
I like that, and it looks like it has a handful of usages already for this sort of thing. I just tried creating a wiki page to try to document it, mainly by copying parts of the hazard=flooding one and it’s just a bare minimum for now. I’d be more than happy for others to improve it.
