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)
3 Likes
I’ve made the change to the Gulf of Mexico polygon.
To codify this practice, I have also opened a new proposal.
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.
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.
1 Like
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.
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.
1 Like
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=seamegapolygon. - 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.
1 Like
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.
1 Like
Hi all,
you know OpenTopoMap (Example with curved lettering) try to solve this problem without a line?
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.
1 Like
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.
2 Likes
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.
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.
3 Likes
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?
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.
Just read this tread, trying to see if I understand the basic information problem.
Is it correct to say that, in order to have enough information to properly render the name of an area (including huge and irregularly shaped areas), you need the polygon, but not necessarily all the details?
And that some details are important, e.g. Italy protruding into the Mediterranean sea, but you don’t need every indentation and protrusion of the entire coastline of Italy?
Peter, you are on the right track, as some of what you identify is true, yet so is more: there are numerous issues, some subtle and technically complex.
We are trying to render “large things,” (seas in particular) and their hugeness and irregularity are part of the problem. Part of it is that monster polygons are both unwieldy, far too large, and almost always inaccurate (similar to how coastlines attempt to model a fractal-based boundary which can’t accurately be done, except to some level of error which might or might not be acceptably not-too-wrong).
And part of it is that it seems to be emerging that it is “correct” (as @ZeLonewolf 's proposal makes clear) that a node can suffice to denote such things. (Again, a “sea” in particular). But we also recognize that a node is often insufficient to allow “decent” (pretty, accurate…) rendering. And so, we bump against our tenet “don’t tag for the renderer.”
This is very much “wet paint” right now; the discussion is ongoing. It seems it has been for at least a decade or longer, too.
Does “monster polygon” refer to the geographical size of the thing or to the number of nodes needed to represent it?
Yes. (Both). If a (multi)polygon is >2000 nodes, some toolchains choke or struggle or die. Same for >2000 ways as segment members of a multipolygon, for example. And as “seas” are some of the geographically largest objects OSM represents, and various “solutions” (more like ad hoc implementations — no harsh judgement by me as I say that, I’m all for “refining our data” with a sloppy version 1 that becomes a better v2 and a wide-consensus, essentially what-we-do-now v3, for example) have been entered, not only do these become apparent on a global scale, we get different flavors of them. And large and unwieldy examples of them. And “hey, we’ve had this problem for at least 10 or 12 years, also on mountain ranges…”. And here’s a potential solution that can help simplify by reducing things to just one node. And “well, what about how we’re going to render those?”
All at the same time.
We can do this. We keep talking to each other, that’s how.