Show names of seas and oceans on the map

[clhenrick]

Looking on Overpass Turbo I see these features exist as nodes:

Oceans:

Seas:

It seems like these are features that should render at low to mid range zooms, and that implementing labels for them would be simple. Is there a reason this has not yet been done? Or would a PR help?

[matthijsmelissen]

Thank you for your suggestion! I think one problem is deciding the zoom level for these labels. For example, at the zoom level of your screenshot, rendering the seas in Japan does not make sense, but rendering oceans any later than this would be weird too. I think that problem might not be easy to avoid.

804 and #788 might provide useful information.

[clhenrick]

No problem, I don't see why rendering labels for seas at z4 or z5+ would be an issue, their labels would make good use of all the negative space that currently exists in the water area. Ocean labels would make sense to render at z3+ when country labels first start to render. These conventions seem to be followed by other web map providers as well for comparison. I don't believe collision with other labels would be an issue either, but could be proven wrong.

A simple test would be to add the following in the .text block on line 281 in water.mss:

  [feature = 'place_ocean'],
  [feature = 'place_sea'] {
    #text-point[zoom >= 5] {
      text-name: "[name]";
      text-halo-radius: 1;
      text-halo-fill: rgba(255,255,255,0.6);
      text-fill: @water-text;
      text-size: 12;
      text-face-name: @oblique-fonts;
    }
  }

and make sure that place_sea and place_ocean are being captured in the SQL for text-point layer on line 2236 of project.yaml.

[clhenrick]

Some samples of sea labels rendering in Asia:

z5

z6

Will work on Ocean label tests as well, need to add them as a shapefile as I don't have a full planet extract.

[sommerluk]

Thanks for bringing this up. I like the idea to use these labels.

However, I for oceans I would suggest to render it from z1 inclusive to z4 incluse only – or, maybe even more restricted, only at z2 and z3.

[gravitystorm]

We need to be careful with these labels, for a few reasons. Using a single point to represent an ocean is quite an oversimplification! These points are also arbitrarily placed, so mappers could get into endless edit wars about where to put them. Many mappers will use them as "labelling positions" rather than ensuring the position has some kind of geographic basis.

The Arctic Ocean label is a good example. From the overpass screenshot I assume the node is outwith the range we render. Do we want just the bottom half of the label showing?

Normally oceans and sea labels are "hand placed" by cartographers, since the challenge of automating the label placement is so high. But we can solve the technical challenges here; while doing so lets remember not to end up rendering "labelling nodes" by mistake.

[clhenrick]

On first glance they seem fairly accurately placed to me, but will double check against some printed atlases.

Would it make sense to use ocean & sea polygons from Natural Earth to derive the labels from as a way to discourage edit wars? Or are edit wars something that will inevitably come up with OSM contributors around certain features?

[dieterdreist]

sent from a phone

Il giorno 15 ago 2016, alle ore 20:20, Chris Henrick notifications@github.com ha scritto:

Would it make sense to use ocean & sea polygons from Natural Earth to derive the labels from as a way to discourage edit wars?

they are providing only English names (AFAIK) and are missing a lot of the smaller sea areas. If we don't want people to improve the data there's no point in showing it in this style anyway...

[pnorman]

Would it make sense to use ocean & sea polygons from Natural Earth

We've been trying to get away from external sources.

Because the extreme low zoom labels come down to almost purely a cartographic choice I'd be okay in principle with supplying a geojson file with the points for the dozen or so big features. Or possibly a CSV data source.

[dieterdreist]

sent from a phone

Il giorno 15 ago 2016, alle ore 22:56, Paul Norman notifications@github.com ha scritto:

Because the extreme low zoom labels come down to almost purely a cartographic choice I'd be okay in principle with supplying a geojson file with the points for the dozen or so big features. Or possibly a CSV data source.

from my experience, because of the shape and orientation, some seas should not be labeled horizontally but would require rotated labels, ideally we would have curved text following the geometry roughly in the middle. Example that comes to mind is the red sea. Nodes are generally bad as starting point because they don't convey information like extent/size, shape and orientation. It would be better to map areas in osm and derive shapefiles from these (from time to time as we do for the coastline)

[clhenrick]

@dieterdreist imo having a data requirement to map polygon areas for oceans and seas seems like overkill for rendering these labels. Also, how does one accurately determine where one ocean or sea starts and another ends?

It is a cartographic convention to render labels along a line that transects the middle of an area as you mention with the Red Sea, but it is also a subjective design decision, and I'm not sure what the OSM guidelines are when it comes to this. Creating a linear feature for something like a ridge or fault line and labeling such a feature along a line seems sensible, but I'm not certain about creating a linear feature just for a sea label.

To me it seems the sea & ocean label points are similar to the country and state / province label points that exist in OSM and should be treated as such.

[clhenrick]

@pnorman if we were to use a GeoJSON file for ocean and sea label points I assume it would be necessary to incorporate the generation of the GeoJSON into the script that grabs data and populates the data/ directory?

I'm thinking something like

wget -O place_sea.osm "http://overpass-api.de/api/interpreter?data=node[place=\"sea\"];out;"

and piping the output from that to osmtogeojson ?

[pnorman]

@pnorman if we were to use a GeoJSON file for ocean and sea label points I assume it would be necessary to incorporate the generation of the GeoJSON into the script that grabs data and populates the data/ directory?

It would be a hand crafted geojson, not one you get from an overpass query.

[clhenrick]

@pnorman and others, I realize there is a reluctance to use data sets from other sources, but perhaps instead of hand crafting GeoJSON data we could use the marine areas from Natural Earth's 1:10m Physical Labels? Benefit is that this data is fairly comprehensive. We would be labeling polygons so this would allow for filtering by way_pixels at varying zoom levels as well.

[clhenrick]

Sample screen shot from QGIS of Indonesia, labeling could of course be improved with CartoCSS rules:

[pnorman]

I'm reluctant to rely on Natural Earth for names as they tend to be in a language other than the local language. I'm okay with using English when it's a large ocean bordering many countries speaking different languages because there is no clear local language but for the various Indonesian seas, those should be the local name.

[pnorman]

relevant is osm2vectortiles' seas.geojson, documented under https://github.com/osm2vectortiles/osm2vectortiles/pull/394#issuecomment-238073484

[clhenrick]

So seas.geojson is suitable to use in this case?

[Ircama]

Would it be worthwhile condisering OSM ways to tag oceans in order to discourage edit wars (rather than nodes)? If such lines are placed with appropriate number of nodes and are also long enough to avoid disputes between mappers on precise positions, they might be directly exploited as cartographic features, with the advantage of defining all necessary data on OSM rather than within other resources or hardcoded in the style (as well as allowing rotated labels when cartographically appropriate). Ways in this case should be just used to define and render text names (and not to be represented as lines).

[imagico]

Would it be worthwhile condisering OSM ways to tag oceans in order to discourage edit wars (rather than nodes)?

How would that discourage edit wars?

The problem with mapping oceans and seas is verifiability - mapping them as nodes is the simplest way to have the tags, in particular the names in various languages, in the database (which are verifiable). The coordinates are essentially meaningless.

[dieterdreist]

sent from a phone

Il giorno 18 set 2016, alle ore 13:08, Christoph Hormann notifications@github.com ha scritto:

The problem with mapping oceans and seas is verifiability - mapping them as nodes is the simplest way to have the tags, in particular the names in various languages, in the database (which are verifiable). The coordinates are essentially meaningless.

yes, but shape and size could be interesting too, if you want more fancy labels like curved lines for instance, or decide when to display a name at all

[Ircama]

How would that discourage edit wars?

I would imagine reduced probability of relevant updates referred to long and well documented lines. Also, tags and names can be added to ways.

The coordinates are essentially meaningless.

Appropriate documentation (also referred within these tags) could warn mappers that in the case of oceans features, ways are used to render the text names.

[imagico]

I would imagine reduced probability of relevant updates referred to long and well documented lines.

I have no idea what you mean by this.

Appropriate documentation (also referred within these tags) could warn mappers that in the case of oceans features, ways are used to render the text names.

Data with the sole purpose of facilitating rendering without any possibility of verification in the real world (and also specific to the map projection i would add) has no place in the OSM database.

Anyway this is turning into a mapping discussion for which this is not the right place.

[matkoniecz]

Because the extreme low zoom labels come down to almost purely a cartographic choice I'd be okay in principle with supplying a geojson file with the points for the dozen or so big features. Or possibly a CSV data source.

I agree that in this case handcrafted data is preferable over using OSM data.

[jeisenbe]

There are 86 nodes, 8 ways and 43 relations tagged with place=sea as of 16-March-2019. I've downloaded all of the nodes; the smallest "seas" tagged as nodes are in the Philippines and Japan (though the latter should be a bay in my opinion), and can be displayed at z7 without problems (z6 is too soone for the smallest seas in the Philippines).

But do we want to render only from the points, or also support polygons?

The nodes are much easier to use, while tagging a sea as a way or multipolygon is very complex if the coastline is followed.

While the Mediterranean Sea, Black Sea and Caspian sea could be verifiably tagged as a polygon, many marginal seas are only loosely bounded and their extents will be debatable, so this would suggest encouraging the use of nodes only.

On the other hand, the wiki page has suggested that multipolygons can be used since January 2011, according to the page history, which is the same month when the page was first created. But it doesn't look like this tag was formally approved, and the first versions of the page recommended tagging with a node.

z7 Philippines

z6 Philippines - too soon for the smallest sea (it's blocked by another sea text label)

z7 Japan

z7 Greece

z7 Wattenmeer - Netherlands

[jeisenbe]

I downloaded all of the ways that are tagged place=sea. Several were clearly mistagged, but there are two that are useable: the Irish Sea (between Great Britain and Ireland) and the Kattegat sea, between Denmark and Sweden:

z7 Irish Sea

• Mapping this area as a closed way is not really correct, because it includes the Isle of Man in the Sea

z7 Kattegat Sea

It was impossible to download all of the place=sea relations from Overpass API; some of these relations are enormous. Fortunately, there are no seas tagged as ways or relations in Japan, the Philippines or Indonesia (these are the places with the smallest named seas).

I was able to download the area around Greece, which has huge multipolygons for the Aegean, Adriatic and Ionian seas. These take quite a while to render and are a pain to open in the JOSM editor application:

z7 Marmara Sea (Turkey)

z7 Aegean - nodes and relations (Aegean, Ionian)

[imagico]

I think we have already established in the above discussion and in #2345 that we do not want to render sea and ocean labels based on mapper placed geometries from the OSM database (either nodes or polygons) and thereby have the map painted by mappers based on subjective preferences and the specifics of the labeling style here and the mercator projection.

IMO there are two decent options:

• render by combining the tagging from place nodes in OSM with hand placed labeling geometries based on cartographic considerations for this style (like done by #2345). This is feasible for oceans but not for seas due to the number of features. Special consideration should be given to avoiding vandalism in combination with slow low zoom update cycles.
• auto-generate labeling geometries based on place nodes and the (simplified) coastline geometry. This is more challenging but would scale better.

In both variants i would only use place nodes to specifically discourage mappers from pointless polygon drawings. There is simply no case where for a sea or ocean a polygon is the most suitable way to map in OSM.

[jeisenbe]

“auto-generate labeling geometries > based on place nodes and the coastline geometry”

That sounds great, especially if it can be extended to labeling for bays (and straits?)

Would this preprocessing be used to generate shapefiles available on osmdata.openstreetmap.de (for example) or could it be a script included in this repository?

[imagico]

Would this preprocessing be used to generate shapefiles available on osmdata.openstreetmap.de (for example) or could it be a script included in this repository?

Yes. But of course someone would have to implement it.

Generally speaking we should be careful with adding a lot of external data dependencies or internal data preprocessing because that makes using this style more complicated. But this particular case is relatively simple and it would not require a lot of resources to run. It would essentially not be much more than one of the scripts we already have (like for generating road colors and shields).

Contributions of new ideas to osmdata.openstreetmap.de are certainly welcome as well. See https://github.com/fossgis/osmdata. Those will of course need to be evaluated regarding suitability, resource needs and robustness.

[jeisenbe]

I've opened a github issue at https://github.com/fossgis/osmdata/issues/3 to discuss adding sea and bay polygons to osmdata.openstreetmap.de - this is important so that other database users will have access to such shapefiles.

However, we could still consider using a script directly in the repository that would create these polygons based on the coastline or the water polygon shapefiles. This would reduce the amount of external data that would need to be downloaded before rendering. Unfortunately, I don't know how to make such a script myself. Any volunteers?

[jeisenbe]

If anyone would like to see the text labels for seas, we could use help to create a script that would produce label placement nodes from the coastlines plus the location of place=sea nodes.

[jeisenbe]

There has been discussion on the Talk mailing list about the validity of the name= tag for the oceans and some seas. There is not a consistent way to determine the value of the name= for seas that border more than one country with several different languages, for example, the Baltic Sea or the Mediterranean. This would need to be considered before rendering the names of seas.

[jeisenbe]

For placing the labels, instead of a script it would be possible to use a geo.json file as mentioned above, with an initial zoom level selected for each node. This would have the disadvantage of requiring more manual work and would be harder to maintain.

[imagico]

Note compared to what i said in #2345 i have meanwhile become much more critical of the idea of using the name tags for labeling seas and oceans because it would massively incentivize abusing them as label tags as it has been amply demonstrated by the effect the low zoom rendering of bay and strait polygons had. It is highly unfortunate that the idea of abolishing the name tag did not find sufficient support - largely because too many people explicitly wanted to retain the possibility to use the name tag as a label tag.

[jeisenbe]

The linked proposal (https://wiki.openstreetmap.org/wiki/Proposed_features/Default_Language_Format) was not intended to abolish the name= tag, but to allow database users (like this style) to use the correct name:<language>= tag(s) when appropriate.

It would be more important for another style, like an Indonesian-specific map which wants to show both the name:id=I and the name:<local language>= tag for the same feature without getting near-duplicates sometimes.

I now agree that it will be difficult to find any appropriate label for large, multi-national seas, and I would suggest dropping the idea of rendering name labels for the oceans at all.

But the small seas like the many found in Southeast Asia are often bording only 1 or 2 countries and might be rendered, as long as we don't use the node (or area) to determine rendering level or location.

This will not be an easy thing to do correctly.

[imagico]

As you mentioned size is not really indicative of how well defined the primarily used language for the name of a feature is.

I also would be highly reluctant to support labeling of seas and oceans using any reasonably simple method of name selection i could currently think of.

[jeisenbe]

We are currently labeling any "sea" which happens to be called a "bay" (e.g. Bay of Bengal) or "Gulf" in a European language, due to natural=bay, and some sea-sized Straits.

For consistency if rendering seas is rejected, we should also stop rendering large bays and straits.

[jidanni]

Currently I see the Gulf of Thailand OK. Hudson Bay is missing. Bay of Bengal is missing. Red Sea is missing. Oceans are nameless (I see it turns out to be a political problem.) Any name would be fine for now, even if not in a familiar alphabet. I mean these are places kids learn in kindergarten. They've got high quality coastlines already on the map. All they are missing is their names. OK multilingual https://www.openstreetmap.org/relation/9348353 looks great.