Yes, it is a suggestion / idea right now. I like your questions about this “thought experiment” very much!
I believe you have the situation sized up essentially correctly.
Yes, it is an idea to tag elongated seas with place=sea tagging on a line. However, this style of tagging is already used today for natural=strait along with all forms of river tagging waterway=river/canal/stream/ditch/drain, which are used for labeling in the exact same way. There are 1.7million river ways which all represent the “approximate middle” of a river, and I’m suggesting that the same should be allowable for a sea that has that kind of shape.
1 Like
The waterways are at the same time used for connectivity and routing.
In fact for roads it’s the same. Mapping and tagging the center line eliminates the need to map the road area. Mappers now generally map the road area by not mapping it. The surrounding land use / land cover shows the area. Sort of not mapping for the renderer.
Agreed, they are multi-purpose, not just for labeling. I was really trying to highlight that we draw a waterway=river line more or less arbitrarily in more or less the middle of the river, and this arbitrariness doesn’t seem to cause problems.
As an aside, and encouragement (as I think we are on the right track in this thread), I had / have experience with rail tagging in OSM, where I was faced with the largest import of rail on Earth into OSM (the USA’s Census Bureau 2007-8 TIGER import included hundreds of thousands of km of railway=rail). I struggled for a couple of years trying to reconcile this with how people in Germany developing early versions of OpenRailwayMap and tagging in Germany as well as greater Europe and indeed the world over didn’t “blend and merge” very well with what was “ideal” tagging, what had been imported, and how others around the world were tagging rail.
A shortened version of what I/we did in a case like this was to notice that in Germany, there were three “levels” of rail (relations): route=tracks and route=railway for track infrastructure plus route=train for passenger routes. The route=tracks relations (especially as entered in and around Germany) seriously and repeatedly confused many in the USA and North America. So, as I explored what seemed to be their superfluous nature, I did some small-scale experimentation with conflating these “three into two” by eliminating route=tracks as potential/possible or even actual relations in the USA. This simplified version of “only two” relation types (route=railway relations for “infrastructure only,” effectively conflating tracks and railways, plus route=train for passenger routes, that didn’t change) meant that rail tagging and improving our TIGER import data became understandable, accessible and hence, was “off and running.” We’ve spent the last decade substantially cleaning this up, and we did it because we were “bold enough” to try a “new version of something” (it is actually a simplified version). We have found it didn’t really “break” anything downstream (routers, renderers, including OpenRailwayMap itself).
The moral of this story is that something similar appears to be happening here with “better data representations for very large objects like seas.” We have learned that a node is sufficient, it is likely a way is better, and that indeed, ways have been used for things like river courses and other (even navigable) waterways. It can be surprising, as I and others noticed back around 2012-14 with rail, and Brian notes above about rivers, that “this arbitrariness doesn’t seem to cause problems.” I’d like OSM to continue with that spirit of positive experimentation, as indeed, it seems we are gaining altitude in making “big improvements” (to paraphrase @woodpeck ) to “beast” (multi)polygons. Yay, us!
1 Like
In practice, it often is an eyeballed centerline, but some mappers try to make it represent the thalweg. Either way, we can think of it as an abstraction. The “centerline” of a V-shaped valley is another example of an abstraction. In that case, thankfully no one expects mappers to delineate the valley floor based on precisely where it meets the foothills.
As a sidenote, mapping the thalweg is especially useful for rivers that run through reservoirs, as in the Lake Mead example earlier. An algorithmically generated lakeline has no context about where the river ran before the valley was inundated. In my own mapping, I’ve used public domain topographic maps or existing boundaries to determine where the thalweg ran. In cases where no such sources are readily available, eyeballing based on the lakeshore is certainly better than nothing. And ultimately the river channel may not be so great for labeling anyways, as in this reservoir that inundated quite a meander:
It’s still not random, nor just to indicate where the label should be or where to sail exactly. I don’t exactly know how it’s worded in the wiki, but from what I see mappers do try to map the middle line just as a way representing a road is drawn in the middle. I think estimating is fine for this, it will approximate a calculated middle line well enough.
A canal, no problem finding the centerline there. Elongated bodies of water with irregular outlines could be harder, but still I think a reasonable centerline can be drawn on sight. You just picture the area leaving out all the small details, think of crossing lines and put nodes in the middle of the imaginary crossing lines.
With a large irregular area, you probably would do the same: first reduce the outline to lose details which shouldn’t determine the centerline. Then sort of picture crossing lines and pick the middle points of those. I imagine these would not form a simple line, but a cloud of dots. A “center cloud”. Then I imagine you could apply the same procedure to find the center (point or line) of the “center cloud”.
I can see problems arising when e.g. large Islands or peninsilas are present, which may or may not be deemed important, and importance may be dependent of zoom level.
And, what if the information is attached to a centerpoint or centerline, but you are focussed/zoomed in on an area that does not contain the centerpoint or centerline?
No actual smoke 
but the fans on my quad-core did kick up a few notches after I clicked the link to display Chesapeake Bay.
A point cloud is not really fundamentally different from a polygon. A renderer would draw an envelope around the points, make a polygon, then skeletonize it to effectively produce a line, or else centroid it to come up with a point. And if we’re talking rough polygons then I think that’s a slippery slope to a beast megapolygon.
At that point, you’re zoomed in beyond the level where it’s appropriate to show a label. Take a look at what other commercial digital maps do in this exact case. A smart renderer is only rendering ocean labels at ocean-level zoom, sea labels at sea-level zoom, etc.
For clipped maps at “ocean level zoom” it is possible to see just the edge of the ocean. A “smart renderer” would label it.
See for example the Atlantic Ocean Label in this map of spain:
3 Likes
I was thinking more of digital maps that you can pan and zoom on, and not hand-curated maps where you can artfully place the label. If there are examples of how general-purpose pan/zoom maps handle this issue, that would be interesting to examine.
1 Like
The BRT map of the Dutch government labels seas at high zoom level. It does so by semi-regularly repeating the label within the water body.
On a related note, I wonder how you’d want to convert the Wadden Sea multipolygon into a node.
2 Likes
The other question is how would you arrange a text?
The more I think about it, the better it would be to draw a long center line (see label/centerline above). A renderer could then use this line (or the part of the line that lies in the map section) and put the text there.
It’s easy and KISS for data-users.
In my opinion, and again, this remains somewhere around an idea / talking point / suggestion, such “beasts” might better (best?) be represented by an OSM way. A node was a “beginning seed idea” and “as of now” (we can and should keep talking about this) it seems to be more widely acknowledged (in this thread) that a way can characterize this much better than a single, simple node could. (We have also discussed a newly-coined relation flavor, but its type=* remains unspecified, open to suggestions).
Clearly, a node is “not enough,” and “beast” (multi)polygons we’re seeing are both overwhelming to our database, sensibilities and correctness. So, a way, as a “line string” that follows the centerline of such large objects seems a suitable compromise, so much so it might prove a workable solution in many or all cases.
The relation idea I suggested earlier might work also, but then we’d be back to “what are its components?” That’s fine, though there is a risk of these, too, becoming “beasts,” but a potential relation solution has the benefit it can have a mix nodes and ways. I think if proper role tags are established to denote what we mean by any nodes and ways in such a relation type (similar to a “label” role tag in a type=boundary relation), this could prove to be a quite versatile solution. For example, it could work with more than “large seas,” it could work for mountain ranges and other geographically large items where rendering now proves difficult.
But for now, let’s stick with (the idea, talking point, suggestion of) a simple way, as I think @ZeLonewolf might be refining something (beyond his initial Proposal) which would include a proposed method of defining a single OSM way to do this. I await seeing something from him on that (but he is a busy man!)
Good dialog here, good progress on brainstorming here!
1 Like
Which problems would occur if we simplify the beast polygon to a maximum of about 100 nodes and position the nodes that it does not touch mainland?
- people converting it back into beast multipolygon
- ways/nodes of it appearing and being confusing while editing something local (for example island near its border)
- its borders are still arbitrary and there are often conflicting ideas how far it should reach
1 Like
Yes, I think Mateusz is correct here. Shrinking a big beast down to a baby beast makes the problem not smaller, but worse. Because now there isn’t something very complex and very large, instead there is something too crude and too small. I think as soon as more-experienced OSM editors saw it, they’d have a natural temptation to “beef it up” (make it larger and more complex). And we’re back to where we started.
This is why we fundamentally stripped it down from 2-dimensional (a polygon) to 1-dimensional (a way). We initially stripped it down even further, to 0-dimensional (a node), but that strips it down too far. Remember, this compromise remains only an idea, and we’d like it to be Goldilocks-sized: “just right.”
Whether describing the extent of a sea, a mountain range or others we haven’t yet mentioned, think of this “centerline way” as something that proudly expresses what is “down the middle,” expanding outward (with your imagination, not actual data in the map) until, well, until it just doesn’t need to expand any more. For a sea, this is the coastline. For a mountain range, this is “the foothills” or “the valley floor.” This might feel unusual for OSM, which usually sharply defines edges, but when you think about it, maps do this all the time. When you see “Atlantic Ocean” labelled on a map, you know it ends at the coast. And that’s already defined by a coastline way.
But if you have a blobby polygon, whether huge and complex or “100 nodes or less,” it’s simply not going to capture this idea and it’s going to look wrong to somebody editing — because it is wrong. However, if instead you have “a centerline that hints where renderers should draw,” it makes sense both in the mind of a mapper and it makes sense for the renderer as to where it should actually draw the label text.
…within the water body… that implies information about what the extent of the water body is. A center node does not give any information about the area it’s supposed to represent. A center line gives one dimension, let’s call it the length, but not how far from the centerline the water body reaches.
How does this BRT map know the area in which to repeat the label at high zoom levels? Or is this done in preprocessing, where you could e.g. create a grid of naming nodes all over the area. Still, you would need to know which area.
It does not solve the “high zoom level” problem.
a. if the centerline or centerpoint is not in the frame, you don’t have the information
b. A centerline has higher probability of being somewhere in the frame, but you still don’t know how far from the centerline the area reaches. I imagine a renderer would need that information to know how to render the water (might have different colours for ocean, sea, bay,…) and the label shape and style.
Still just thinking aloud… maybe these problems have been solved in ingenious ways. E.g. you could probably estimate areas of water by “looking” around for obstacles. Wouldn’t work for large bays and gulfs, though.