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.
It’s good to think aloud, that is good brainstorming.
Recall, we are talking about placing labels here, not drawing coastlines or bay / sea extents. (That’s already done by coastlines and isn’t what this topic is about).
That seems the best solution to me for very large areas which have subjective borders and various competing definitions of where they end.
See Borders of the oceans - Wikipedia for an example.
If I would be labelling oceans/continents/mountain ranges I would not base labels on OSM nodes. Likely the same for seas.
1 Like
This kind of situation is quite relevant and unfortunately cannot be solved with either a node or a “centre line”. It’s not that nobody needs polygons (or rather: information about the extent, shape, position and orientation, even if it is disputed or approximate).
It is also relevant for a digital, zoomable and panable map.
But I also agree that having large (multi)polygons in OSM for every ocean, sea and other huge named geographical areas (with often unsharp boundaries) is not a solution either (for all the reasons already mentioned, clearly there was a reason for the way we implemented the sea area modelling with the coastline mechanism, and despite it is occasionally done (“landmass” objects, geographical region objects, …).
The OSM data model is not particularily well suited for such polygons, because of the level of detail in our data: people add locally observable facts (i.e. human scale), and the sum of all these results in unnecessarily complex, huge geometries for something that will mostly be used in global and regional scale views.
Despite not being able to satisfy all requirements, a way for water bodies would IMHO be a huge improvement compared to a node, and probably good enough for many users. Length of the way would give an idea about hierarchy when several objects are close, and about relevance in general (not saying it will always work, and not knowing the size (“width”) that is represented is still an issue – would it be acceptable to estimate the extent, similar to how we do it with population, i.e. tagging an approximate surface size?).
Someone interested in polygons could still use OSM data in combination with other datasets (for the names and other information) to benefit from our detailed (coastline / island) data where needed, by creating a derived dataset.
I have also proposed to collaboratively create a parallel, “mid-scale” dataset with “precise enough” borders, that would remove the burden of having to deal with these huge scale objects when editing on the local scale.
2 Likes
I am thinking about what information you need in OSM to place correct labels correctly.
You need a part of the feature in focus to know that a label is needed.
I think you also need some idea how important / big the feature is.
I think you also need some information about the area in which to put the label.
And you want this in cases where you have no outline object, because the megabeast solution is not manageable.
Coastlines do not normaly carry the bay / sea / ocean names, do they?
I’ll reply to this, think about the rest, and get some sleep (it is 0335 in my Pacific Standard Time zone).
No, coastlines do not normally carry sea names, like for labels, but they DO mark where “the name stops.” Returning to the original problem (Brian wondering why he couldn’t get a well-labelled Gulf of Mexico using some particular renderer code), it is already known that the coastline (of Texas, of Quintana Roo…) demarcates where the Gulf of México “stops” (because it is land, not a Gulf any longer). And that is true for any trio of waterbodies, labels for them and coastlines where they “stop.”
Whew, an intense discussion. I’m sure other cartographers have wrestled with this, especially digital cartographers. When I was at Adobe, getting PostScript to “draw text along an arbitrary curved line” was a neat trick, but a pretty complex one to do with machine logic / code, and that was over a quarter-century ago. It still isn’t easy, even to discuss.
This is a sensible position for the most part, though it may still be necessary to conflate an external data source with OSM. For example, an external data source may have a criterion for inclusion that differs from the cutoff between natural=mountain_range and natural=ridge. This may be true of seas as well; some data sources probably disagree about some seas being bays or vice versa.
I agree that this would be a nice user experience. But the point of a linear representation would be to enable a more basic understanding of the waterbody’s “path”, if applicable. This is already done for some straits where the shape is conducive to a linear representation. I’ll admit that, when working on renderings, I’ve occasionally been tempted to just take the Gulf of Mexico point and rotate its label by 45 degrees clockwise to make its label look more reasonable. 
Data consumers with more advanced needs would probably need to pull in an external dataset that represents the waterbody as an area. The existing coastlines dataset is anonymous, as is the version that splits out more manageable water polygons, but I’ve gesticulated in the direction of a possible approach to generating a comprehensive named dataset:
To elaborate on this idea a little (on the other side of the napkin):
- Rasterize the OSM coastline file.
- Apply the flood fill algorithm to match a
place=oceannode to a portion of the coastline. - Trace it back to the vector coastline data using a map-matching algorithm, so now you have megapolygons (or gigapolygons).
- Repeat the process for any unfilled nooks in the coastline, this time matching them to
place=seaandplace=baynodes. - For each polygon that’s round enough, calculate a centroid. For each polygon that’s elongated enough, skeletonize it. (A non-interactive map would first intersect each polygon with the map bounds.)
The main benefit over maintaining a completely independent dataset is that the polygons would carry any attributes that OSM wants to add to the nodes, like names. Then again, name gets tricky with any waterbody that borders many countries.
While I think it would be cool to see this kind of postprocessing based on OSM, mainly I’m bringing up the possibility of a linear representation as a compromise for elongated seas. Someone is going to map the sea anyways, so we might as well make it minimally useful.
1 Like
While thinking a bit about it, I don’t see with our current mapping possibilities a better way than creating such “beast”-polygons. So I started thinking about how to solve it on the data-user side and was thinking back to the times, my Garmin was limited for the length of a track and how such problems got solved in that time. More or less, the very detailed track got simplified and the problem was solved.
So the idea could be, that while importing relations, create a very rough version geometry (e.g., by Douglas-Peuker-algorithm) of such kind of “beast”-polygon and only use the rough version for further steps.
This approach that you’ve described is exactly how these objects are handled today. However, storing an 250,000 node unverifiable polygon for the sole purpose of later running a simplification algorithm seems like a poor way to express data.
1 Like
We do “only” have whole-integer values for dimension (2 as polygon, 1 as way, 0 as node). So, if 2 is too big (many say so), 0 is too small (some say so, many agree?) and so 1 is the obvious compromise choice, let’s try it!
Let’s invent and develop the concept that a way (linestring of one dimension) can be a “hint” to renderers for labels. These do not describe exact scope, they are “helpful data, on a reasonable diet.” (Not a beast who seems to be overfed). Could be a bay, bight, sound, estuary…or ocean. Might need to be repeated in the case of ocean or “very large things.” Probably could do something quite clever with existing data (“the other half of the dimension?”) where “the coastline is” (already) and “the waterway name ends.”
Maybe we discover that with a way denoting this, plus some clever back-end code, renderers can draw something pretty smart and rather pretty 80% of the time. With some polish that might become 90% or 98%.
I continue to nod my head here, as this reminds me of six people (no comment on how well we see) touching a pachyderm: we are not all of us saying “elephant,” but I think we describe the scope of the thing in our own ways, and there is quite a bit of harmony, actually. It’s a (decent) emergence of what seems like a workable idea with many positive observations and contributions about it. Good for us.
It looks like “the whole planet” (geography_10m.geojson in the repository) is just shy of 7 megabytes or so, which seems quite lean. By comparison, it’s possible a single OSM beast could be that large or larger.
However, geography_10m.geojson also displays “©2023 Tom Tom” (lower right corner) and links to Microsoft (corporate logo) and azuremaps dot com (smily face in square). Huh? Are the data (the 7 MB of geojson, say) copyrighted or only the presentation of the map?
Maybe “all as ways” would be an improvement, I’m not sure, but this “looks good for what it is.” I am not quite sure how it might mesh with OSM, but indeed, it might.
I’m not wishy-washy (indecisive), I’d rather say “I have an open mind.” (To potential solutions).
Edit: Ah, I see, it is cc0.
You’re looking at GitHub’s preview of the GeoJSON file. This copyright notice pertains to the basemap, not the GeoJSON data. Last year, GitHub switched its GeoJSON previews from an OSM-based Mapbox map to a TomTom-based Microsoft Azure map. (GitHub is owned by Microsoft.)
2 Likes