Proposal:High seas

From OpenStreetMap Wiki
(Redirected from Proposed features/High seas)
Jump to navigation Jump to search
High seas
Proposal status: Proposed (under way)
Proposed by: ZeLonewolf
Tagging: place=sea
Applies to: node node
Definition: Marginal seas and named portions of oceans
Statistics:

Rendered as: Caribbean sea.png
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 relation 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, relation Hudson Bay contains over 4,000 members and is frequently broken by mappers. The largest,relation 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 relation Laccadive Sea, which was mapped with arbitrary decisions about the exact extent of the sea:

Laccadive sea.png

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 relation Labrador Sea 11,087
2 relation Cooperation Sea 8,147
3 relation Sea of Japan 5,720
4 relation Barents Sea 4,967
5 relation Hudson Bay 4,067
6 relation Adriatic Sea 3,459
7 relation Aegean Sea 3,423
8 relation Red Sea 2,483
9 relation Black Sea 2,327
10 relation Skagerrak 2,308
11 relation Kara Sea 2,294
12 relation Laccadive Sea 2,020

This table was generated by overpass[1]

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.


Atlantic ocean.jpeg


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


Mediterranean Americana.jpg


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 node Gulf of California, which looks like this at zoom 4:


Gulf of California.png


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

Features/Pages affected

External discussions

Related discussions:

Comments

Please comment on the discussion page.

  1. The following overpass query was executed in JOSM:
    [out:json][timeout:250]; rel[place=sea]; out body;
    This query downloads all place=sea relations (63 objects as of 3 Jan 23), but does not download their member ways. Then, I did a visual scan in the JOSM relation view to identify the ones that were over 2,000 members in size.