This definition leads to some problems when encountering overhanging rock along the coast. An overhang crossing the ocean creates an area that is simultaneously land and sea when seen from above, with land occupying a higher level than the sea.
It seems that this is usually dealt with in OSM by ignoring the problem. The coastline is mapped at the edge of the overhang, where the ocean becomes visible in aerial photography. This approach, however leads to problems down the road. For instance in this case: Way: 1167228743 | OpenStreetMap. Here we have a bay that stretches in under a rock arch and appears on the other side. Following the mapping approach described above leads me to have to map an isolated ocean. This isn’t ideal as it hides the fact that this piece of sea can be traveled to by boat.
An other alternative would be to follow the tag definition more closely and map the coastline as it appears at sea level. That would result in me mapping this as a bay. However, I find this problematic as it hides the fact that the area of the arch is also land.
In Norway I have a similar conundrum, where the ocean goes though a culvert: Way: 1156824482 | OpenStreetMap. In this case I’ve taken the opposite approach. I hope this illustrates why I fint this style unsatisfying.
Is there a standard approach to mapping such land/sea conflicts in OSM that I don’t know about?
Besides man_made=tunnel + tunnel=culvert, you could consider natural=water + salt=yes (which is used in =canal ) + tunnel=culvert (although type=tunnel suggests location=tunnel, it seems to be unnecessarily limiting, and redundant when bridge= or tunnel= is already used for other features)
What would you have the arch area cover? Just the span of the arch, or also a wider area including the supports on either side? The latter seems tempting when the arch columns are well delimited, like in this case: Es Pontàs - Wikipedia. But in the case I mentioned earlier the “support” of the arch isn’t clearly outlined, so I guess it makes more sense to cover just the span.
One of the things I want to respect is the fact that the coastline actually goes though the culvert, which is the reality on the ground. Tagging as natural=water without coastlines kind of disguises this fact. I guess I could tag as both though. An alternative, following the pattern of natural=arch could be to revive natural=land with layer=1 for the land area above the culvert.
It would be great to include the columns. However, this leaves the gap ill-defined. There is an open question in https://wiki.openstreetmap.org/wiki/Talk:Tag:natural=arch#Mapping_as_a_way_or_area? related to this. Furthermore, natural columns are often tilted or grow wider upwards, so the open-space underneath ideally has to be defined in 3D. Maybe an eg =arch_opening is needed in some form, similar to the difference between =cave and =cave_entrance to be comprehensive.
You might add tidal=yes as well. The problem with =coastline alone is the underground sea area becomes implicitly defined. A renderer will have to interpret the situation somehow, which is unreliable. So at minimal, it is better to further relate them by eg type=area .
Instead of =land, can it be considered a short =embankment ?
I wonder how Norway’s Stad Ship Tunnel will be added.
I didn’t even consider these issues. Thanks for the heads up!
I’m unsure if I understand you correctly here. I do recognize that the underground sea area becomes implicit to an extent. The question is whether I could tag the overhanging land bit such that it becomes less implicit. I feel like layer=1 is a strong indicator that something special is going on at least. I haven’t encountered type=area before, and am struggling to find docs on it, could you expand a bit on what you mean by this tag?
Arguably it’s both. The reason I went with =land is because I’m looking fore something that would be applicable in the general case of land overhanging sea. Be it an embankment with a culvert, a natural sea cave, and arch, an artificial ship tunnel or anything else. To me it makes sense to start general and then add more specific tags as the need arises.
This is a very interesting case study, and, I’ll admit, it was floating in the back of my mind when I posted this thread. If - or when - it will be built, it would be nice to know that OSM has a schema that allows us to express such a structure.