The multipolygon natural=bay has nothing to do with your problem, it only adds the name=* which is displayed without having to zoom in very much, unlike the node.
All this leaves us orphaned from our coastal rocks and it’s very sad! I feel it as a bullying to Corsica.
The “natural” key is very often used on relations. Woods with holes in and lakes with islands are common examples.
Edit: I’ve changed this. The wiki is confused (quelle surprise) because it talks about “nodes”, “ways”, “areas” and “relations” rather than “points”, “lines”, “polygons” and “things with no geometry”. https://wiki.openstreetmap.org/wiki/Relation covers all relations, which can have various different sorts of geometry or none, and the first example given there is “multipolygon”, which obviously does have a geometry. It’s pretty meaningless to tag something with no geometry as “natural=wood”, for example, but a multipolygon “natural=wood” makes perfect sense. If someone wants to edit that page to say that “it makes no sense to use the ‘natural’ key on objects with no geometry” that would help further.
Hi,
I answered on the changeset in French. Here are the arguments I give:
2 multipolygons had been replaced by a node but also by a way that would close the bay. I don’t think anyone on a forum said to replace the bays with this:
I forgot to remove the tags on this one…
The multipolygon natural=bay have nothing to do with these problems of rocks not visible on the rendering, it only adds the name=* which is displayed at a zoom adapted to the size of the multipolygon unlike the node which can represent a bay a few meters or several hundred km.
An example of natural=bare_rock that does not appear on the render and is not part of a bay:
If they were present on the rendering before and they are no longer present, there may have been a modification in the rendering, the blue of the sea which is added over the rendering of the bare_rock and before it was the opposite, maybe…
Rendering is manage here, if you want to ask:
The other solution is to surround the islets with a natural=coastline. But natural=coastline means that the islets are almost always above sea level.
If you do that, you will have to be patient, updating the “blue” of the sea sometimes took several weeks or months.
The islets need to be natural=coastline to appears on the sea.
The natural=coastline islets does not appears on the see if there are inside a natural=bay polygon but not part of the relation.
Inserting hundred islets in the relation is too complex, not done and so islets are erased.
The islets have names and/or explain the names of the capes and bays. They are needed to give sense to the map. What did Corsica and Sardinia do to you to make you want to erase their coastline?
You are so convinced that these relations are a problem that you do not try to understand what you are being told…
How do you explain that this rock Way: 664753630 | OpenStreetMap is not visible on the OSM Carto renderer? There is no relation natural=bay here. The rock next to it Way: 664037971 | OpenStreetMap is visible because there is natural=coastline Way: 4843142 | OpenStreetMap.
I can give other examples without bay that are invisible : le way 669471392, 504644564…
there are probably thousands of them…
If this is the case for natural=gulf also, then you are right, I have no more worries!
I propose an honest deal: I take out of the Gulf of Ajaccio relationship all the islets. If the natural=coastline still appear then I apologize and I recognize my (big) mistake. Otherwise, we replace the Gulf of Ajaccio by a node.
Do you agree ?
In the rendering of the islets area marked as natural=coastline.
Because of a reason I don’t understand, Olyon included all these islets in the natural=bay relationship of the Gulf of Ajaccio. I thought it was necessary for them to appear. Why did he do this? Already without it this relation is a monster.
The official data of the coastline in France (an Corsica) is evolving and I would have liked to be able to update it without unnecessary difficulties.
Moreover, the coastline toponyms require for their understanding the representation of these islets. For example i setti navi, the seven boats, are seven islets, not two as today on OSM!
These tangible data seem to me more important than an artifice of presentation, but I don’t want to offend anyone.
From the point of view of someone rendering OSM data, as far as I’m concerned the most important thing is that any natural=bay polygons only duplicate coastline-enclosed areas.
We have had the situation in the past where an inland bay (not coastline-enclosed) and sea bays (coastline-enclosed) have both been mapped as natural=bay. This makes it really hard for renderers to know what to do. Not everything chooses the same rendering order as openstreetmap-carto.
I feel it’s very interesting but I’m not sure I understand it well because my English is poor. Can I rephrase you like this ?
The most important thing is that the natural=bay polygons consist only of natural=coastline areas.
Does this mean that depending on the rendering order chosen by the programmer the islets that are natural=coastline but not part of the polygon are hidden or not?
If so, then there is a real problem of complexity because there are too many islets to include them into the polygon fluently. In practice this forbids any evolution under the risk of losing data.
Put simply, someone developing a stylesheet needs to consider “do I need to fill a natural=bay polygon in blue?”.
If all natural=bay polygons just duplicate the coastline, then the answer is no, because the coastline is already filled.
If some natural=bay polygons cover areas not covered by the coastline, then the answer is yes, because otherwise there’ll be missing water areas.
But if this is the case, and islets aren’t included in the natural=bay polygon, then renderers are at risk of colouring islets in blue. (And yes, I’ve seen this happen.)
Conclusion: make sure your polygons only duplicate the coastline. (Or just use nodes.)
