Label oceans and large seas from a static file

[pnorman]

This is a proof of concept of using a static file to label seas and large oceans with hand-placed labels.

• The placements are designed for a webmap which wraps around +/- 180. This allows placement of a single North Pacific label, while many printed maps use two, one on each edge. Other webmaps use a single label but place it so it doesn't cross 180. I believe what I am doing is unique among webmaps. Not worrying about the +/- 180 allows for more flexibility in positions
• Positions and sea selections are designed for Mercator. osm-carto will never make a good map for viewing the entire world at once with its projection, but it's what we use.

There are a number of outstanding issues

• Even with the increased size, the smallest labels seem faint. We might need to adjust the water colour. Many maps use white.
• With the syntax used it seems necessary to specify the same point multiple times even when it's at the same location in order to increase its size on higher zooms.
• Labels on z4+ haven't been given huge consideration
• I'm not sure what to do with the southern ocean. It's geometry is unlike other oceans because the on-globe centroid is on land, and in Mercator it is a very large ocean.
• Some of the seas should probably be in the local language
• Right now line breaks are done through wrapping. Since these are manual labels it might make more sense to turn off wrapping and use manual newlines

I drew technical ideas from osm2vectortiles seas.geojson and cartographic/labeling ideas from Natural Earth and Tim Patterson's Physical Map of the World. I specifically avoided looking at MapBox Streets as they have falsely claimed ownership over similar files to what I was making.

[pnorman]

Needed for labels crossing +/- 180

[imagico]

I do not like this for several reasons:

• not basing the names shown on the place nodes in OSM seems inappropriate for a community project. I think a script that generates the geojson from unnamed geometries and the place nodes in OSM (easy to do using an overpass query) would be much better.
• the selection of seas is highly subjective. You have the Kara Sea but not the Laptev, East Siberian, Chukchi and Beaufort Seas. You have two marginal seas in the Indian Ocean but none in the Atlantic (like the Caribbean Sea) or Pacific (like Philippine Sea, Bering Sea)
• your Kara Sea node is very close to Vize Island.
• the division of the Atlantic and Pacific into Northern and Southern part is coming from the IHO limits of oceans and seas, i.e. is a politically motivated artificial division not based in any previous practical use of language - people living at the coast of these call it the Atlantic or Pacific, not the southern/northern. So this labeling is questionable.
• I think it is probably feasible to create a reasonable automatic label placement based on the place nodes and the simplified coastline that does not lead to mapping for the renderer and still produces visually pleasing results. While for just about a dozen sea labels this probably seems unnecessary work it would be very useful for labeling smaller maritime waterbodies, i.e. straits and bays - see also discussion in Add rendering for natural=strait #804, Rendering of natural=bay vanishes too early and is too small #2068.

Regarding the Southern Ocean - if you want a single label the best place is probably south of Bouvet Island - in common use of the term the northern limit of the Southern Ocean is the Antarctic Convergence and this extents furthest north here:

https://commons.wikimedia.org/wiki/File:Antarctic-Convergence-Map.TIF

Again the commonly used limit at 60 degrees latitude is based on the IHO definition and politically motivated.

If you want multiple labels you could well place a second one at about 150 degrees west and possibly a third one south of Heard Island.

[pnorman]

not basing the names shown on the place nodes in OSM seems inappropriate for a community project. I think a script that generates the geojson from unnamed geometries and the place nodes in OSM (easy to do using an overpass query) would be much better.

We want to avoid the use of place nodes as "labelling positions". See #2278 (comment) for Andy's view, mine is that label placement of oceans is purely a cartography decision and belongs in the style, not a data one which belongs in OSM.

Going with a static file was a design choice I consciously made

[concerns about seas]

I've only got seas on z4+, and I didn't do much work on them, just enough for the proof of concept to test multiple zoom levels.

people living at the coast of these call it the Atlantic or Pacific, not the southern/northern

Yes, that's the main but not exclusive usage. I was thinking even without southern/northern the pacific would need two labels, but without the need to break at the date line that paper maps have, I see some alternatives. The Atlantic will probably need two.

If you want multiple labels you could well place a second one at about 150 degrees west and possibly a third one south of Heard Island.

For spacing I was going for very approximately an average of one label visible on average for a screen of map.

---

In many ways it would be easier to only do oceans from a static file, then all seas could be done from OSM data. I'm not convinced that it's best.

[imagico]

We want to avoid the use of place nodes as "labelling positions". See #2278 (comment) for Andy's view, mine is that label placement of oceans is purely a cartography decision and belongs in the style, not a data one which belongs in OSM.

Note i said "basing the names shown on the place nodes", not using the place nodes. It should be possible to match the nodes with manually placed coordinates and only use the name tag.

This is especially for the language matter - which language a certain sea is labeled in should be decided by the community in an open process, not by the maintainers here. Since the place nodes are in the database it would be natural to use these to implement this process.

[pnorman]

• Seas removed from the scope to keep this PR smaller and defer consideration of seas

• Tried a single label for the pacific on a line. Wasn't happy with it.

  

Preview of z1 and z2

[imagico]

I will probably get in trouble for this but an argument could be made for labeling the Arctic Ocean in Russian - after all the Russian coast towards it is significantly longer than the US and Canadian combined...

Not sure if using curved labels for the Arctic Ocean is necessary - it is kind of odd with all other labels being point based.

I would probably move the Southern Ocean label south of the Atlantic somewhat to the east - it now extents over the South Sandwich Islands and there is sufficient room to the east to avoid that at least at z2.

[dieterdreist]

sent from a phone

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

I will probably get in trouble for this but an argument could be made for labeling the Arctic Ocean in Russian - after all the Russian coast towards it is significantly longer than the US and Canadian combined...

I support this

[jojo4u]

So english is the default label language for osm-carto? According to OSM principles the ocean labels should probably be without name=* but only with name:[lang]=*

[matkoniecz]

not basing the names shown on the place nodes in OSM seems inappropriate for a community project. I think a script that generates the geojson from unnamed geometries and the place nodes in OSM (easy to do using an overpass query) would be much better.

Big problem here is that low zoom levels are rerendered only on style update. So fixing deliberate/accidental problems would require style update or manual cache invalidation.

Also, it is a bit tricky to decide language for labels of Arctic, Southern and Indian oceans. English would be probably the most readable choice for biggest share of our users but so far problem of default language was shifted to editors of name.

[imagico]

Big problem here is that low zoom levels are rerendered only on style update. So fixing deliberate/accidental problems would require style update or manual cache invalidation.

Actually the low zooms are regularly re-rendered once per month without style updates and i don't think it would be a performance issue to increase that to weekly or even daily update for z=0-4.

Also, it is a bit tricky to decide language for labels of Arctic, Southern and Indian oceans. English would be probably the most readable choice for biggest share of our users but so far problem of default language was shifted to editors of name tah/

I think using English as a convenience default is a slippery slope. With the same argument we could essentially label the whole map in English language. But we deliberately chose to use local languages as selected by mappers individually and it is difficult to find a convincing argument why this should be different for the oceans.

As far as tagging is concerned - yes, there is potential for edit warring to influence the labels but not more than there is for other prominently labeled features i think. The primary problem is that no matter how you'd extend the on-the-ground rule to oceans - be it in form of the most frequently used name on the open ocean or the most frequently used name among the inhabitants of the coast - for nearly none of the world oceans there will be an absolute majority for any single language (the most likely candidate would probably be the Arctic Ocean for Russian, especially with the coast inhabitants definition).

To avoid problems with name change and update cycle interference it would be possible to only render changed names for the oceans in the map if the name change has proven to be stable. For that you'd maintain a history of previous names and change the actually rendered name only when it has been the constant name for said feature for some time.

[dieterdreist]

sent from a phone

Il giorno 27 ott 2016, alle ore 18:02, Christoph Hormann notifications@github.com ha scritto:

But we deliberately chose to use local languages as selected by mappers individually and it is difficult to find a convincing argument why this should be different for the oceans.

I don't find this difficult: we chose local language to name the places by default how the people that live there call them. As nobody (almost) lives on the oceans the situation is significantly different.

[imagico]

So you say we should label all parts of earth that are not or very sparsely populated (like < 1 person/square kilometer) in English?

[mboeringa]

So you say we should label all parts of earth that are not or very sparsely populated (like < 1 person/square kilometer) in English?

I think @dieterdreist only refers to possibly disputed areas outside territorial waters of countries. I think no one with any experience on OSM would start to re-label names in an another country to its own local language or "default" English (even forgetting the local name policy for the "name" tag that has been OSM standard for years).

[matkoniecz]

Actually the low zooms are regularly re-rendered once per month without style updates

Thanks, I was unaware about that - especially if changed to daily update it reduces problem of poor names. Still, it give big potential for things going wrong.

[dieterdreist]

I did not explicitly say we should use English for labeling of international waters, but there might be arguments to do so (also Russian and Chinese might be defendable alternatives, and maybe even fillipine languages if you go by actually spoken languages on sea, but I couldn't find relevant statistics on the fly).

[imagico]

I think no one would deny we already have a de facto English default for the name tag in many cases where there is no obvious most common language for the feature in question. But this is just a de facto situation the OSM community can change any time if it feels like it. And i don't think this style has any kind of mandate to cast this de facto situation as it is right now into static code.

Another point to consider: There are many derivatives of this style implementing maps with localized labels like the German and French styles. Currently this requires only modifying references to the name tag from within SQL in some way. If we add a hardcoded list of features with name attributes in English this list would need to be modified as well complicating things quite a bit.

[kocio-pl]

I also think we should stay with a "name" tag - this is default, generic key and its value can be changed any time the community feels it should be.

[Ircama]

Apart from the appraisable discussion on labels, @pnorman’s proposal is quite interesting and I’d love to see the names of the oceans represented with the standard OSM style.

Hopefully, the following basic design might be of some help.

Maybe the LUA script planned in the LUA branch could be also used to separate the preprocessing of specific tags (e.g., preset in the configuration file) like the oceans.

To load these tags to the DB, their names and other relevant attributes could be read from the OSM input file, while their geometry might be taken from a different table set, to be separately maintained.

For features like oceans that are managed as nodes in OSM, the LUA process could also be used to change their type from node to way, so that a standard rendering can be designed within openstreetmap-carto for these lines.

References not matching the separate tables can be processed normally (as nodes), in order to avoid the issue on subjective selection of seas mentioned by @imagico.

[imagico]

The more practical way probably is to have a script get the nodes via overpass API, merge their name tags into a geometry data template and write that to a shapefile/geojson to be used by this style. This could be run daily, possibly with the suggested name change dampening.

[pnorman]

Closing, no ETA on when I'll be able to look at this and it's not a current priority for me.