Gulf of Mexico object / Rendering of Large Seas

[stevea]

The Gulf of Mexico is a marginal sea, defined as “a division of an ocean, partially enclosed by islands, archipelagos, or peninsulas, adjacent to or widely open to the open ocean at the surface, and/or bounded by submarine ridges on the sea floor.”

As such, and because the existing polygon @ZeLonewolf references is both crudely drawn and tagged place=sea, whereas a node tagged place=sea seems much more correct (Tag:place=sea - OpenStreetMap Wiki discusses the history of nodes tagged place=sea controversially re-tagged as often crudely- and inaccurately-drawn polygons), I “have no serious objections” about his proposed change.

In fact, I do not consider his proposed change as “tagging for the renderer” at all. It might appear to be this at first view, but rather, it is exactly the opposite: it is “undoing some tagging for the renderer” which has persisted in OSM since late 2018 / early-2019. It does indeed to seem to be a tagging error in the class of our wiki-denoted entire series of these happening around the same timeframe. As our wiki says, “The trend to map seas as multipolgyons is related to the increase in mapping bays and straits as multipolygons, which also became more common at the same time, most likely due to a controversial change in rendering by the Openstreetmap-carto style sheet, the style used by the standard map layer.” So, we can “classify this class of object as as tagging error:” what Brian is doing is actually restoring correct tagging, which has been systematically undone by trying to tag for the Carto renderer.

See, fellow mappers: here is another example of why we shouldn’t tag for any specific renderer! It adds confusion, often lasting years (while real tagging errors are extant) and the need for extra tagging work which must be both discovered and corrected. For goodness’ sake, don’t tag for the renderer!

And thank you, Brian, for both your discovery of this as well as taking the polite corrective action of posting this here and soliciting wider community input. Now you have mine!

[woodpeck (Frederik Ramm)]

Hi,

Creating a tight coastline multipolygon relation, such as is done for
Hudson Bay https://www.openstreetmap.org/relation/9441240 and James
Bay https://www.openstreetmap.org/relation/13360255 is at best
controversial and definitely unwieldy.

I hate these beasts with all my heart and thank you for not suggesting
that as a serious solution. Among other things, these relations will
usually require the introduction of more ore less random guesswork lines
that separate them from neighbouring named water areas.

Most people introduce these giant water-area-on-sea relations for the
single purpose of getting nice labels. If we can find a workable
solution that allows people to create labels without having these
polygons, that would be a huge step forward.

Bye
Frederik

[stevea]

Once again, we are enlightened that part of the reason “people map” is to see the results of their mapping. And there is absolutely nothing wrong with that, it is part of the enjoyment of OSM mapping. Mostly, Carto indulges us in this “thrill of seeing our mapping efforts blossom” — often in mere seconds or minutes!

However, there are cases (like this one) where Carto has chosen (often for very good reasons that are subtle, may be controversial or be difficult to achieve consensus about…) to not map what is correct tagging. These choices Carto (or any renderer) makes are quite deliberate, and “are what they are.” In many people’s minds, because they don’t understand the entire toolchain of “data in OSM + any-given-renderer = visual map,” they eschew “good data” (what OSM is all about) for the petty indulgence of “a pretty visual map representation I can make and then see.” If you are generating bad data so you can see something you’d like to see: No! This is not what OSM is about.

How do some mappers do this? They tag for the (usually Carto) renderer to achieve their desired rendering. This actively puts incorrect data into our map, and we get abominations like the current (sloppy) Gulf of Mexico polygon, and strong negative reactions like Frederik “hating these beasts.” I don’t recommend actual “hate,” but I also share strong negative reaction to bad data entering our map (database).

Fellow mappers, PLEASE: understand that your data into OSM is what’s crucial. NOT “how you see it rendered.” Yes, we all understand that “seeing what you want to see” is important — that “thrill” drives a lot of motivated mappers to map — but it is far more important for our database to contain correctly-tagged data than it is for you to “see something pretty in a fashion you’d like to” (especially when that is incorrect).

I hope this thread can be one more inspiration for similar corrective actions which undo bad tagging, tagging for a renderer, and “hopeful” tagging (which isn’t true, but renders as somebody would like it to). Eventually, as people understand that “not everything one maps will be rendered,” we will get pure data into OSM, not “data as I wish to see it.” There is a difference, it is important for us to keep pointing that out, so that it doesn’t continue to happen, and so it can actually be corrected where it is incorrect (like here).

I hope this channel isn’t preaching to the converted, and I don’t mean to beat this drum so loudly that it isn’t heard anymore, but we (as a project) still have quite a bit of work to do here. Both about the awareness of “don’t tag for the renderer,” and to correct a lot of tagging which does. Regarding the former, I think that novice, less-experienced mappers are the most to blame here, and while our admonishment of “don’t do this” is fairly widespread in our project, I think a simplified educational process (maybe a wiki or ten-or-twelve slide/graphics presentation) can go a long way to explaining our “full toolchain” of how data become renderings and how bad data can seem like good renderings, when they are not. It has been tricky (and not especially successful) so far for us to “educate amongst ourselves” on this topic, and we can do better.

[ZeLonewolf (Brian M Sperlongano)]

@woodpeck

Most people introduce these giant water-area-on-sea relations for the
single purpose of getting nice labels. If we can find a workable
solution that allows people to create labels without having these
polygons, that would be a huge step forward.

Thanks for bringing this up. I think the objective of nice labels is entirely achievable today, and you’ve chosen the right adjective to describe the cartographic objective.

Below is an OSM Americana clip of the North Atlantic. It renders place=ocean and place=sea nodes, and both categories are readily rendered.

You’ll notice that the label for Mediterranean Sea is rendered, however the label for Tyrrhenian Sea is not. The reason for this is that, in this renderer, land labels take precedence over sea labels, and the labels for Sardinia, Italy, and Basilicata collide with the spot where Tyrrhenian Sea would be, so it’s dropped. In effect, this acts as a natural solution for dealing with dropping labels at lower zooms for smaller seas.

As you zoom in, the relative size of these waterbodies increases on the screen, and by zoom 5, labels for Tyrrhenian Sea and Sea of Crete now have enough separation from nearby land labels that they appear. However, no label appears for the Adriatic Sea, as it is one of those beast multipolygons that you so passionately hate.

As I see it, there are two possible objectives for waterbody labeling strategies:

1. Render water labels only when they fit entirely within the waterbody; labels are not allowed to touch land (contained labels).
2. Render an “attractive” label, and it’s acceptable if the overlap a land area somewhat (overlapping labels).

To achieve contained labels, there’s no getting around the fact that you need a constraining polygon to do this. That’s of course the motivation for mappers drawing tight coastline polygons - the renderer can guarantee containment of the label. Some have suggested that an algorithmic approach might be possible, where the software could detect the shape of the surrounding land and make the label the right size, but as yet I’m not aware of anyone that has demonstrated this in practice. As such, this suggestion tends to be a red herring offered by people opposed to the complex polygons that doesn’t actually solve the problem because it requires technology not readily available.

However, I suggest that constrained labels is not really an important objective for ocean and sea sized bodies of water. At these low zoom zooms, it’s still an attractive label (in my non-professional opinion) if it touches land. And in fact, if you look closely at the first clip, you’ll see that the “Mediterranean Sea” label actually covers a tiny bit of the island of Crete, which is barely large enough to be shown at that zoom.

The worst-case scenario for overlapping labels is a sea that is very narrow and runs in a general north-south direction. In other words, the Gulf of California, which looks like this at zoom 4:

This label overlaps land a lot but in my opinion this looks perfectly fine. After all, land labels are dangling into the ocean as well, and that looks okay, and it’s not in the way of any other label that would otherwise render.

In summary, I think that fitting labels perfectly within waterbodies is not a real problem in rendering attractive labels, and it’s a niche requirement for a renderer that desires that behavior.

As of right now, these so-called “beast multipolygons” are blocking my renderer’s ability to render attractive labels, and my desire would be to systematically replace them with nodes. Should this not be acceptable to the community, I have the technical know-how to add render support to OpenMapTiles to add support for labeling beast multipolygons, but I would prefer not to. I don’t share the same passionate hate for them, but they’re in my way and conversion to nodes is by far the easiest path to get there.

However, I want to caveat this already too-long post with a note that I am unaware of what other data consumers may be doing with these features and so I wouldn’t want to impose such a change unilaterally at global scale. I will note that osm-carto is labeling neither style of object and thus it seems it would be no impact on the standard tile layer to apply the solution that we both prefer.

[ezekielf (Zeke Farwell)]

@ZeLonewolf

osm-carto is labeling neither style of object

Except when natural=water is incorrectly added to a “beast multipolygon”. OSM carto happily renders a label in that case. See the Gulf of Saint Lawrence (link warning: may consume excessive CPU cycles)

[ZeLonewolf (Brian M Sperlongano)]

I’ve made the change to the Gulf of Mexico polygon.

To codify this practice, I have also opened a new proposal.

[Minh_Nguyen (Minh Nguyễn)]

@ZeLonewolf

The worst-case scenario for overlapping labels is a sea that is very narrow and runs in a general north-south direction. In other words, the Gulf of California, which looks like this at zoom 4:

This label overlaps land a lot but in my opinion this looks perfectly fine. After all, land labels are dangling into the ocean as well, and that looks okay, and it’s not in the way of any other label that would otherwise render.

This point-placed label may look fine by the standard of avoiding overlapping text, but the Gulf of California is actually a great example of why some mappers probably think it’s beneficial to map some seas as areas. Conventionally, whenever a body of water is long and narrow, a map strings out the label along its “centerline”, spacing out the letters to cover the entire length:

OSM Americana does render line-placed labels for some bodies of water, especially reservoirs like Lake Mead:

These inland bodies of water are mapped only as areas, which are apparently turned into lines when generating the vector tiles. I’d imagine that’s a pretty expensive process compared to piggybacking off a linear waterway feature, such as the Colorado River. A mapmaker could choose to supplement OSM data with a hard-coded line feature, seeing as the Gulf of California doesn’t move very often. I’m surprised Natural Earth doesn’t include sea centerlines in one of its layers.

I agree that it would be overkill to map the boundary of a sea just to get a line-placed label, but maybe a waterway of some sort should be an option for some seas.

[seav (Eugene Alvin Villar)]

I think one possible reason (and I’m not saying this is why some mappers do this) why the polygon-style of mapping large water areas is done is because this allows labeling of such areas in atlas-style maps where the water area is visible, but doesn’t contain the center node. Minh’s example map above showing a diagonal label for the Gulf of California also renders a label for the Pacific Ocean, but you can definitely agree that that patch of the Pacific wouldn’t contain any conceivable place=ocean/sea node named “Pacific Ocean” or even the “Northern Pacific Ocean”. If you render such an atlas-style map using OSM data clipped to the (maybe buffered) area covered by the map, you obviously can’t automatically render the “Pacific Ocean” label without the node but could do so if you have a polygon. I don’t know of any way to do these nicely labeled maps automatically unless you have polygons or you resign to semi-automated methods and manually add such sea/ocean labels.

[aighes (Henning)]

What would be your suggestion for how to do it in a better way?

For me areas sounds like the typical approach for describing an object like this. Using a node only will not help. Most likely rendering a map of the US from an US extract will miss Pacific and Atlantic node and therefore be without a label.

[Minh_Nguyen (Minh Nguyễn)]

@seav

If you render such an atlas-style map using OSM data clipped to the (maybe buffered) area covered by the map, you obviously can’t automatically render the “Pacific Ocean” label without the node but could do so if you have a polygon. I don’t know of any way to do these nicely labeled maps automatically unless you have polygons or you resign to semi-automated methods and manually add such sea/ocean labels.

In principle, the oceans and seas are being mapped as a set of anonymous, conjoined polygons, formed by all the natural=coastlines on the planet – at least when the process for merging them doesn’t break due to a data inconsistency. Theoretically, an algorithm such as the conveniently named flood fill algorithm could be used to associate one logical portion of the world’s sea area with a node lying within it. A data consumer would probably need to perform quite a bit of geometry simplification to make this process more efficient.

With the right parameters, a flooding algorithm could probably identify most of the oceans and the relatively sheltered seas such as the Gulf of Mexico, the Mediterranean, and the South China Sea. Maybe it’s also possible to identify “peninsulas” of water such as the Gulf of California. However, the Sargasso Sea and Southern Ocean cannot be defined by coastlines. A manual approach would be necessary, but maybe a companion dataset such as Natural Earth or a one-off GeoJSON file would be more suitable for these features than something hard-coded in OSM, where there’s a tendency toward hyperlocal precision that would be counterproductive in these cases.

[ZeLonewolf (Brian M Sperlongano)]

@Minh_Nguyen

This point-placed label may look fine by the standard of avoiding overlapping text, but the Gulf of California is actually a great example of why some mappers probably think it’s beneficial to map some seas as areas. Conventionally, whenever a body of water is long and narrow, a map strings out the label along its “centerline”, spacing out the letters to cover the entire length:

(snip)

I agree that it would be overkill to map the boundary of a sea just to get a line-placed label, but maybe a waterway of some sort should be an option for some seas.

Thanks, I tend to agree that in some cases, a linear feature is probably appropriate, though not a waterway. There are already plenty of examples of this for natural=strait:

• Strait of Magellan
• Kattegat
• Skagerrak, which is amusingly mapped both as a linear strait and separately as a 2,300-member place=sea megapolygon.
• Falkland Sound
• Anegada Passage

While it wouldn’t be appropriate to tag the Gulf of California as a strait, it seems like it would be perfectly workable to simply tag it as a place=sea linear way down the middle of the gulf. And, I would extend that perhaps to other long, skinny seas such as the Red Sea or the Adriatic Sea, for which a central place node is a particularly poor representation.

[Minh_Nguyen (Minh Nguyễn)]

@ZeLonewolf

While it wouldn’t be appropriate to tag the Gulf of California as a strait, it seems like it would be perfectly workable to simply tag it as a place=sea linear way down the middle of the gulf. And, I would extend that perhaps to other long, skinny seas such as the Red Sea or the Adriatic Sea, for which a central place node is a particularly poor representation.

Sounds good to me. An interesting test case would be the Mediterranean. Most maps label it with a line-placed label, but the label is normally not at the midpoint of the centerline, where it could run aground in Sicily.

By the way, several of the sea nodes are also dual-tagged as natural=sea. On a centerline way, this tag would have a nice ring to it, reminiscent of how natural=valley typically follows a valley floor.

[pyram]

Hi all,
you know OpenTopoMap (Example with curved lettering) try to solve this problem without a line?

[Minh_Nguyen (Minh Nguyễn)]

It looks like this only works for bodies of water mapped as areas or massive multipolygons, right? Areas can be a problem, not necessarily the solution.

[ZeLonewolf (Brian M Sperlongano)]

@pyram

Hi all,
you know OpenTopoMap (Example with curved lettering) try to solve this problem without a line?

Thanks for sharing that example. That technique is achieved by computing a skeleton geometry off a polygon, and it’s readily available in GIS processing tool stacks. OpenMapTiles does this also, and I agree they are quite attractive (location):

However, this requires a polygon as a starting point. This is no problem for continental areas because the lake geometries are necessary for rendering the areas, and labels are an artifact derived from them.

For offshore areas, this is more problematic, for example, there’s a pretty artificial Labrador Sea megapolygon with 11,000 member ways that’s so unwieldy that it times out loading on osm.org. Here’s a screenshot from JOSM of it:

I think it’s silly to draw such complicated features to give a geometry for label processing, especially if they’re just converted to lines or points in the end. Hence why I suggested points for seas except for lines in the case of seas that are more linear in shape. I’m open to other suggestions that don’t result in these monstrosity objects.

[SK53]

There were a couple of other experimental renderings about a decade ago which looked at this issue. I can’t find the one showing the Gulf of Finland (iffy memory says OpenMapSurfer), but this example for alpine mountain ranges is still available, and the methodology was briefly described on the wiki.

[Richard (Richard Fairhurst)]

I’m not convinced that “geometries for the purposes of nice labels in certain renderers at small scales” belong in OSM at all, whether they’re points or monsterpolygons or whatever.

It seems better to me to create/distribute them as separate datasets, as per GitHub - leefrance/geolabels: OpenSource lines for cartographic labeling of physical geographic features and GitHub - lukasmartinelli/osm-lakelines: Calculate nice centered linestrings for labelling OpenStreetMap lakes etc. etc.

[stevea]

Thanks, Richard, I agree with you here: OSM must avoid/eliminate whole “geometries” as in Franken-polygons.

At the same time, I simultaneously believe that a node succinctly establishes (de minimus) the name of a sea. So, OSM should strive to eliminate Franken-polygons which exist solely for purposes of labeling in renderers, and do so using a single node per single sea, at least.

Furthermore, it seems an OSM way (GeoJSON LineString…) can be a sweet-spot solution for those pesky cases where simply / only a node poses difficulties to nice rendering (and we certainly see these do exist). “Simply a node” wouldn’t be wholly wrong, more like “enough to name, but insufficient to pretty-print.” A way, however, presents a path for a renderer to follow with text which wraps along it. (A similar situation exists for mountain ranges, which might be entered as a way made up of nodes labelled natural=peak, but I don’t want to get side-tracked with that here).

Strictly speaking, a node defines the name, but is often enough insufficient to “nicely” render. That isn’t the fault of OSM as a database, it is a renderer faced with difficulty of how and where to put a label (prettily) based on a quite-minimal amount of information (a single node). Our discussion here might ask if an OSM way is a compromise solution or “too much data” which is in OSM only to “help a renderer” (and as @Richard suggests, might properly belong in in a separate dataset).

I am of a “tentative, I continue to listen” opinion that if a node is too little, and Franken-polygons are (much, much) too much, a way might be a nice compromise. A problem I have with using a way as a potential solution is that it still feels like “entering data / tagging for the renderer,” and if we’re being “data purists,” that isn’t ideal. On the other hand, a way compared to a Fraken-polygon is a big improvement in “cleaner data,” and as such is something both I and @woodpeck would find to be a “big improvement.”

Excellent discussion so far.

Edit: Perhaps we could could coin a new tag for “centerline ways” (which offer hints to renderers) tagged centerline=* or something like that?

[pyram]

@stevea

Perhaps we could could coin a new tag for “centerline ways” (which offer hints to renderers) tagged centerline=* or something like that?

Sounds like a version of role=label in boundary relations !?
=> add a line with role=label_line to the monstrosity multipolygon objects ?

[stevea]

@pyram

Sounds like a version of role=label in boundary relations !?
=> add a line with role=label_line to the monstrosity multipolygon objects ?

Yes, it’s kind of like that, except I’m suggesting that we eliminate the monstrosity (multi)polygon objects and “agree” (come to consensus) that an OSM way be a “compromise solution” to “node not enough, (multi)polygon too much.”

@pyram, you and I have noticed that similar issues exist for mountain ranges, and again, I don’t want to get side-tracked about that here in this thread, but I believe similar oddities (“how do I best tag this so it renders nicely without ‘tagging for the renderer’?”) exist for many “linear features” of OSM.

Edit: Refining this a bit more, what if we coin a new relation type (I’m open to a good value for type=) consisting of simply a name= tag and members which are a line (to describe a render path) and perhaps a single node (centered, “identifying,” similar to role=label in boundary relations). Seems it needs some further sharpening of focus, but we can invent such things, and maybe in this case / these cases, we should.