Cursed Ajaccio Gulf

If I understand the issue correctly, you find the new islands (or rocks) you added, don’t show up on the standard tile layer (Carto) on You believe this is caused by a multipolygon tagged natural=bay.

From what I’ve read on Github I’m under the impression just the name of a bay is rendered, the (blue) fill color for bays was removed after this discussion. Apparently, changing the bay from a multipolygon to a node, will not cause the islands to appear.

I think the blue color for the sea is caused by the ways tagged natural=coastline, and to make your newly added islands appear, you have to add this tag to the outside of these islands. Because of the difficulty of rendering the coastline, some patience is needed before the islands will appear. Possibly several days, according to the wiki.

Let me now rephrase my question more clearly thanks to the previous answers.

I fear that there is a relationship between the “outer” polygon “Golfe d’Ajaccio” and the multitude of small rocks emerging along the coast line which are deleted from the map because they are not defined as “inner” of the multipolygon of which the “Golfe d’Ajaccio” polygon is the outer. Is that the case ?
If, even without being inner part of the multipolygon the rocks appear, tomorrow, in a month, in a year, then the question is closed, do not read the following.

If it is necessary for all the rocks emerging at the edge of the coast to include them as inner in the multipolygon so that they appear, then the question is serious!

I have an example:
If this rock was not inner in the multipolygon, will it appear one day, even far…?

I read on the wiki, page “Tag:natural=bay”:
When mapping large bays as areas the resulting multipolygon relations will often be extremely large and complex so mapping with nodes is preferable, like for place=ocean and place=sea.

Can I apply this recommendation, delete this multipolygon, replace it with a node, then see the small “natural=coastline” polygons that border the coast appear, delete a large number of them because they are fanciful, replace them with real data from an official and certified source, giving them their local name, not attaching them to a cursed ghost, obtaining relevant data and quality cartographic rendering?

I found an example of an island in a bay, which is not a member of the multipolygon as inner.

If you look at this island in the Gulf of Gabes, it appears not to be an inner of the multipolygon describing the Gulf. In spite of this fact, it is visible on the standard tile layer on
Apparently the rendering of the island is not dependant on it being an inner in the surrounding bay.

Aside of the rendering issue, the question remains whether it is ‘good mapping’ not to include such islands in the multipolygon. I think one could argue that you should make such islands an inner in a multipolygon describing the bay, because they are not part of the bay. But opinions on this might vary. If you consider a bay an area between two capes, instead of a large area of water, you might feel any islands are part of the bay.

Excellent! It sounds convincing and it satisfies me.
So let’s patiently wait for the end of the sea containment measures to be certain.

They are very small rocks and there are a lot!

There is something incredibly illogical in the creation of a multipolygon whose outer polygon is natural=bay and the inner polygon of natural=coastline. The bays represent the minor notion of small part of the sea. The coastline represents the essential notion of border between the sea and the land. The only multipolygon, in the logical sense of the term to which the coastline belongs, is the earth! The rest, in Corsican in the text is monta sega, an incredible claim of the cartographer to dominate the world!

I think I just came across the definitive answer to my question :
Frankly, I would prefer to convert the multipolygon into a node because I think it would be better in all but I am too beginner to take this initiative without your advice: Yes or No?
Better still, would someone with experience want to do it properly?

Actually, it is easy to “convert” the big multipolygon to a node. The only problem is, the original mapper might be angry if you do it without a consultation before proceeding. He did a lot of work to create it and likely still thinks it is a good idea. So while this method will work, I don’t want to take the responsibility for actually doing it. If it was in my neighborhood (Alaska, Thailand) I would reach out to mappers I’m familiar with before doing anything.

Like the person who created the Golfe d’Ajacci multipolygon, I once thought mapping bays as multipolygons made sense. My goal was to let the rendering software figure out where the centroid of the area was located rather than an arbitrarily placed node. But my thinking has changed. I started a long thread in the Tagging group about this topic a couple of years ago. Anyway, the added complexity for newer mappers is one big reason I abandoned my scheme. Your issue is a case in defense of that decision.

Should you get agreement with the original mapper(s), deleting the Relation is easy. But before proceeding, make a list of the tags and values already assigned, the name:ar, Wikidata value, etc. because there’s no way to copy them to the new node you will create. Place a node somewhere in the middle of the bay and assign those tags to it. Now you’re ready.

I don’t know how to do this using the iD Editor or Potlatch so my steps will only work inside JOSM.

In JOSM you merely select the Golfe d’Ajacci multipolygon, click the Edit button, then once the Edit Relation window opens, just click the button that looks like a trash can at the top of the Relation Editor. You will get a warning that the operation cannot be undone. Continue. The Relation is gone. No ways are deleted. All the pieces of coastline will still be present and tagged with natural=coastline. The other relations that also include those pieces of coastline are unaffected. By the way, those pieces of coastline are included in many boundaries. I’ve never seen anything like that before.

Hope this helps


If you map the bay as a node, there is loss of information, no in/out like with a polygon, so you cannot tell if you are in the bay or not.

Yes, that is one argument for the use of a multipolygon and it’s one that was discussed at length in the thread I referred to. In those prior discussions, that loss of information was not as important an issue as the complexity one. In the end, it’s up to the mappers involved to decide what’s best in any given situation.

I will find that discussion later if you’re interested. I can’t do it immediately as I have an appointment.

Here are two discussions from the Tagging listserv that are relevant to this one:

I think you’ll find the next one particularly interesting as it involves comments from some of OSM’s big contributors, Frederik Ramm among them. It’s a contentious conversation but worth your time:

Using multipolygons to map large bays in Alaska

From the beginning I am in private contact with the creator of this multipolygon. He (she ?) is someone courteous, convinced and an educator. It actually helped me better understand all the ins and outs. He does not wish to participate in this thread because of the language barrier.
Once all the arguments have been spread out, we do not select the sames aguments and remain in antagonistic positions. This is not the first time that one of his polygon is deleted, but it is the first time that somebody ask his opinion!
In a location in which I am preparing to make a big effort I consider myself justified in making this replacement.
There is however an real argument against. Here is the illustration: .
It seems that the polygon is the only way to appreciate the difference in importance between the Bay of Biscay and a tiny cove in Corsica because the key:nature=bay cannot be calibrated. Do you have a idea to help this problem?

Actually, in your argument example, user:woodpeck did exactly what you propose to do in your situation. He deleted a huge multipolygon that outlined the Bay of Biscay and replaced it with a node. The reason he did it was to simplify the OSM data structure and to make editing other objects in the bay easier.

Woodpeck, by the way, is an account used by a major OSM guru, Frederik Ramm, that I mentioned above. He has argued strongly AGAINST using multipolygons to map bays. He would definitely support your move to get rid of that big multipolygon.

You are also correct when you say that by using nodes to represent large bays, the difference in relative size compared to smaller bays is lost. Smaller bays inside the Golfe d’Ajacci will have the same text size when rendered and will therefore appear to be just as important as the bigger bay that surrounds them. There is no way at present to, as you say, “calibrate” the size. That’s the trade-off one must make when using a simple node to represent a large bay. You can’t have it both ways.

Every model is a simplification of reality, simplified so that it represents the characteristics that we need to take into account so that the model can give answers.

Simplifications have to be properly balanced to continue representing reality. If we oversimplify, as is what (in this case) arises and was done, we will not be able to answer some questions, such as where is outside or inside a bay.

The territorial extension of a bay is clearly a geographic data. That for simplicity it is feasible to map it as a node, or because no one has yet mapped it as a polygon does not imply that other collaborators have the possibility and the need to do so, they are prevented from doing so, and that the bays already mapped as polygons are changed to node as it was done in that case. There should be room in OSM for this type of data.

This polygon, simple, marking the limit of the gulf, away from any risk of emergence of an inner coastline before a good time, large enough to induce a visible text, would it be suitable?

You need to read the threads I offered in one of my replies. Your arguments are good but they’ve all been argued before in those conversations. The same with the solution of using an approximate shape that would give navigators, for instance, a solid indication that they were inside of or outside of a bay or strait.

In the case of straits, (see the second thread) I argued that it would be important for a navigator or pilot of a ship to know if he was in the Shelikof Strait or in a sheltering bay adjoining it and that this situation could be better treated by using a rough shape like your polygon Philippe. People opposed pointed out that the OSM method of mapping a strait is with a line, a string of points that roughly follows the center of the strait. I didn’t like that idea at all. A string of points does nothing but put a name on the map — it tells you nothing about geographical extent. Also, a 4-sided multipolygon is a simple structure to maintain. I went ahead and mapped it as an area described by a multipolygon.

Shelikof Strait
(The Shelikof Strait is a passage between Kodiak Island and the Alaska mainland that is a very dangerous area)

The idea of representing a bay or strait with a multipolygon might seem the best method but I can tell you for sure that if you use one in a situation like your gulf, it is subject to removal by the OSM high command. I decided to use a simple multipolygon for several straits in Alaska but decided not to use multipolygons as a device to make big bays stand out above smaller ones because of the complexity issues, both in the data structures and for maintenance afterward. And the fact that they might be removed by Mr. Ramm (user:woodpeck)



Thank you for your great patience!
And this possibility: ?

As an aside, I’m really surprised that renders at all - hats off to the OSM Carto people! :slight_smile:

Well, it’s an interesting experiment but of course it wouldn’t work at all for a long narrow bay like a fjord.

I hope this conversation has been helpful. Good luck and keep mapping!


Thank you all :slight_smile:
Put into practice, critics welcome :

I don’t recommend this approach. I’m sure you will draw criticism from other mappers as well.

What amazes me is that the name of the gulf renders so large and appears in the same place as the other one. I suspect that’s because the rendering hasn’t yet “caught up” with your recent edit.

I strongly recommend using a node to represent the Golfe d’Ajaccio.