Proposal:High seas

High seas
Proposal status:	Proposed (under way)
Proposed by:	ZeLonewolf
Tagging:	place=sea Data item
Applies to:	node
Definition:	Marginal seas and named portions of oceans
Statistics:
Rendered as:
Draft started:	2023-01-01
RFC start:	2023-01-02

Proposal

Proposed are that:

• The OSM community recommends that marginal seas and named portions of oceans, when located on the ocean side of the global coastline, are modeled as a node tagged place=sea.
• The OSM community regards the use of place=sea on an area feature (closed way or multipolygon) as a tagging error if the area feature is located on the ocean side of the global coastline.

This proposal takes no position on the tagging of the following features, although this may be addressed in a future proposal:

• Water bodies inside the coastline, such as the Caspian Sea Caspian Sea.
• Smaller water features tagged natural=bay.

Rationale

• Seas modeled as an area which hug the coastline (so-called "beast" multipolygons) result in excessively complex multipolygon relations which are difficult to maintain. For example, Hudson Bay Hudson Bay contains over 4,000 members and is frequently broken by mappers. The largest,Labrador Sea Labrador Sea, is so big at over 11,000 members that it frequently fails to load when accessing it on osm.org. This is a problem because:
  • They add unnecessary additional relations to coastline ways that complicate coastline editing for mappers.
  • They require editing software (such as iD or JOSM) to have to download large amounts of geometry data in order to make simple edits, or risk breaking polygons
  • They increase the computational burden on data consumers to process these polygons
  • Fitting labels perfectly within waterbodies is not needed to render attractive water labels, and it’s a niche requirement for a renderer that desires that behavior (see discussion below).
• Place nodes for oceans and seas are supported in major data consumers such as OpenMapTiles.
• Areas tagged place=sea without natural=water do not render in major renderers such as OpenMapTiles or the Standard Tile Layer. Thus, converting these areas to nodes would allow them to render in data consumers that support them.
• It is redundant to add natural=water to area features that are on top of the ocean.
• The alternative approach is for data consumers to add support for rendering place=sea areas that lack a natural=water tag. However, this would encourage mappers to create more "beast" multipolygons when a simple node would accomplish the desire of waterbody labeling.
• Areas outside the coastline currently tagged place=sea + natural=water are redundant because they're water features placed on top of the ocean, which is a water feature. Thus, this is double-tagging of an ocean area and is a case of Mistagging for the renderer.
• The exact water boundary of an oceanic sea is inexact and not verifiable. However, because these megapolygons are drawn with defined areas, it gives the impression of a distinct boundary. Consider the example of the Laccadive Sea Laccadive Sea, which was mapped with arbitrary decisions about the exact extent of the sea:

Due to the complexity of the coastline along some marginal seas, as well as large numbers of tiny islands, some of these "beast" megapolygons have gotten quite large. Below is a listing of all beast megapolygons that are larger than 2,000 members, as of 2 January 2023:

Rank	Object	# of members
1	Labrador Sea Labrador Sea	11,087
2	Cooperation Sea Cooperation Sea	8,147
3	Sea of Japan Sea of Japan	5,720
4	Barents Sea Barents Sea	4,967
5	Hudson Bay Hudson Bay	4,067
6	Adriatic Sea Adriatic Sea	3,459
7	Aegean Sea Aegean Sea	3,423
8	Red Sea Red Sea	2,483
9	Black Sea Black Sea	2,327
10	Skagerrak Skagerrak	2,308
11	Kara Sea Kara Sea	2,294
12	Laccadive Sea Laccadive Sea	2,020

This table was generated by overpass

Tagging

Tag	Usage
place=sea	Indicates the this location is the approximate center of a sea
name=* name:xx alt_name=* alt_name:xx	Indicates the name(s) of the sea, consistent with currently-documented conventions for tagging the names of features
natural=water	Sea nodes should not be tagged as a water area.
wikidata=*	Large seas meet the notability requirements for wikidata and thus a wikidata QID should be tagged

Rendering Discussion

High seas "beast" multipolygons are created usually with the objective of providing an object that results in attractive labelling of water features. However, the objective of nice labels is achievable with nodes alone. Below is a clip of the North Atlantic. It renders place=ocean and place=sea nodes provided by the OpenMapTiles schema, and both categories are readily rendered.

The label for the Mediterranean Sea Mediterranean Sea is rendered, however the label for Tyrrhenian Sea 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 Sea of Crete now have enough separation from nearby land labels that they appear. However, no label appears for the Adriatic Sea Adriatic Sea, which is modeled as a place=sea multipolygon with over 3,400 members.

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).

The motivation for mappers drawing tight coastline polygons is to achieve constrained labels - in theory 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 nobody has demonstrated this in practice. However, constrained labels are not an important objective for ocean- and sea-sized bodies of water. At these low zoom zooms, attractive labels are still possible even if they touch land. If you examine the first clip, note 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, such as the Gulf of California Gulf of California, which looks like this at zoom 4:

This label overlaps land a lot but still 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.

Examples

• Various sea nodes rendered as point labels

Features/Pages affected

• Updates to Tag:place=sea consistent with this proposal

External discussions

• Community forum discussion "Rendering of Large Seas"
• Abandoned proposal for tagging seas
• RFC announcement on the (mailing list) and (community forum)

Related discussions:

• June 2015 osm-carto ticket Lake Ontario does not render at zoom 5 or below
• October 2018 deletion of the Gulf of Bothnia
• November 2018 Using multipolygons to map bays in Alaska
• April 2019 osm-carto ticket Render name labels of bays and straits from z14 only, lakes from z5 only
• August 2020 Rio de la Plata edit war
• November 2020 Chesapeake Bay incident
• May 2022 osm-carto ticket Bay/Strait area labelling leads mappers to create huge polygons

Comments

Please comment on the discussion page.