Hello.
I work on the coast line of my micro-region by correcting the current one which is very imprecise with government data certified to be in conformity with the OSM charter (SHOM TCH French).
I am proud of the result which reveals the meaning of toponymy.
However, I have a problem, a big problem!
The coast is dotted with many small rocks that emerge. Most of them have names.
Unfortunately, they do not appear in the sea. The trap is the existence of a multipolygon whose exterior is “https://www.openstreetmap.org/relation/9375697”. It is horrible because for each grain of “natural = coastline” inside this trap it would be necessary to define a relation!
The usefulness of the Gulf of Ajaccio multipolygon is low in view of the fact that it objectively hides the coastal islets.
Can I:
Either delete the “type = multipolygon” in the polygon.
Delete the useless polygon by replacing it with a single point in the middle.
3)?
Thanks for your advice.
The usefulness depends on what you (and others OSM users) do with the data. If the multipolygon is real data you should not delete it.
It’s a rendering problem.
I think Option #2 is the best answer. The wiki page for natural=bay suggests mapping it as a node, not as area, and in fact most bays are mapped as a simple node…
I noticed, some of the islands in that bay, the ones that do render properly, are mapped doubly; one way as natural=coastline, and an overlapping way tagged natural=bare_rock. I think that’s probably unnecessary (once the multipolygon interference is removed); do ocean islands really need natural=coastline? (I couldn’t find the answer on the wiki, and my own experience is all fresh water.)
PS… We typed at the same time. Good point above. But if it’s a rendering problem, it might be a big one. I browsed around the coastline and found lots of invisible islands that existed only in the data, not the display. Also… moving the tags from multipolygon to a simple node doesn’t really remove any information, other than removing a rough estimate of the bay’s boundary … right?
Thank you all for helping me.
Of course I warned the creator of the multipolygon when I created the thread, with the link.
Option 2) is logic. Information “Golfe d’Ajaccio” is of course important. On the other hand, nothing justifies that it interferes with the small rocks emerging near the coast. This has nothing to do with.
I fear that option 2) will reduce the size of the text “Gulf of Ajaccio” too much. Perhaps another solution would be to create a large polygon but a bit far from the coasts, inside which there are no islands?
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 www.openstreetmap.org. 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 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 www.openstreetmap.org.
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.
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!
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.
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.
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:
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: https://www.openstreetmap.org/node/7367542817#map=14/45.0577/-3.3279 .
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.
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)
