I was going to create a “boundary” for North America and South America using the coastlines surrounding them. As an example, I would map North America’s “continent” relation like this:
All the natural=coastline ways surrounding North America and the Panama Canal would get the role “outer.”
The node would get the role “label.”
Similar to South America. Then, with these new multipolygon/boundary relations, I create a new relation with the following members:
The North America relation gets the role subarea.
The South America relation gets the role subarea.
(Optional) All natural=coastline ways that surround one continent, but not both (Panama Canal, I’m looking at you), get the role outer.
The node with the name “America” (alt_name:en=The Americas) gets the role label.
Of course, this would be impossible to do in either iD or Vespucci, so I would need to wait to have access to JOSM. How does this “proposal” sound?
I live in the United States, which definitely does NOT consider America to be a single continent, hence the subarea roles. On an unrelated note, why is the node tagged with place=continent anyway?
We’ve had big long debates about how many continents there are. It’s kind of a distraction, since data consumers don’t do a whole lot with these features anyways. Renderers use Natural Earth or other curated GIS layers at that scale; elaborate continent relation structures in OSM won’t change that.
subarea was conceived with the mistaken notion that data consumers need explicit help determining which geometries lie inside other geometries. It’s unnecessary and counterproductive, except temporarily in the case of tribal boundaries, where we grapple with an unfortunate assumption that governments are strictly hierarchical.
There would now be an outline defining the edge of North America. Of course, North America is not a country, which is why I said “boundary” in quotation marks. I’ll provide a picture to illustrate what I mean.
Edit: I tried to do this. However, there were 12000+ ways making up the coastline of North America! I guess that’s too much for even JOSM to handle…
Also, no, that’s not a typo. Twelve THOUSAND ways, not twelve hundred. (That means 1.2 × 10⁴.) I don’t even know if (multi)linearstrings would work, since approximately nothing supports them as of October 7, 2025.
There is no reason you couldn’t easily do this on your phone (but I am, at this very moment, working on code to suppress subareas in a lot of functions in Vespucci as they are -very- annoying).
Yes, there is. North America is large, so trying to download the coastlines as I’m adding them to this relation feels like something Vespucci cannot do right now, especially when you consider how many ways make up the coastline and the Panama Canal (watch Atlas Pro for why I used that instead of the Panama–Colombia border).
Would every continent have its own multipolygon relation? Note that there is a hard limit of 32,000 members in a relation. But forget Eurasia: one national forest in one corner of the Alaska coast has so many members that some users have accidentally throttled themselves by trying to load it on the website. And that’s a boundary without quotation marks.
I do appreciate the reasons why you might want to do this but super huge multipolygons are challenging for our data model to handle and for the editors. Consider that if you did all of this work, it would:
Be very hard to maintain in the fluid environment of the coastline.
Be hard for you to even see this once completed (likely would crash the browser.
Be against the community guidelines as people are reacting here.
A multilinestring sometimes does represent a border line with an especially well-known identity, such as the Mason–Dixon Line or the Twelve-Mile Circle. These things are meaningful enough to map even though no software exposes them. But something more mundane, such as the boundary line between Colorado and Wyoming, doesn’t have a dedicated relation, because it would just be a category of various boundary ways that happen to be members of the same two boundary relations, something you can query for on the fly. Similarly, you can query for all the natural=coastline within a relatively simple polygon to get the data you need – or just get it from the usual source. This avoids the need to maintain any complex structures and exacerbate tensions about what exactly is the coastline.
That particular limit only applies to immediate members of a relation. But a superrelation structure doesn’t seem like a solution to your problem statement, because the website won’t download it recursively to visualize the overall geometry.
As it is, we aren’t even representing the Gulf of Mexico as an area anymore. The former area was unwieldy as it was crude.
Nice as it would be to have access to the precise area for some geographic (“the X peninsula”, “the Y sea”) or political/social (“the Z treaty area”, “the A timezone”) constructs, building OSM relations that contain thousands of coastline ways cannot be the answer to that. I know it is being tried, and done, many times over (e.g. Relation: Iberian Peninsula (3870917) | OpenStreetMap or Relation: UTC+01:00 standard time (16819467) | OpenStreetMap or Relation: Bay of Biscay (7156290) | OpenStreetMap ) but ultimately all these mega relations will get deleted because of the problems inherent with the concept, like endless upload time when you split a coastline way, version numbers in the 1000s (good luck finding out how many of the 1757 edits to “Iberian Peninsula” were an actual edit or just an accidental one), and constant breakage. Don’t add more of them, it is a waste of everybody’s time.
Not quite but nearly off topic: I believe you should actually be using a single linestring (even less supported than multilinestring) for modelling that, as a multilinestring is simply a bunch of lines(trings) with no expectation of them being continuous, which you would typically expect even if the border isn’t closed.
As a matter of fact, one shouldn’t assume that these named boundary lines are necessarily continuous. The Twelve-Mile Circle consists of three disconnected arcs that form parts of the Delaware state line.
Technically no relation represents the entire survey line by Mason and Dixon, only the parts concurrent with the Pennsylvania–Maryland and Maryland–Delaware state lines, including part of the Twelve-Mile Circle. This is what maps for a general audience might label as the Mason–Dixon Line. Otherwise, it would be exclusive OpenHistoricalMap material, as the note=* tag suggests.
Personally, I consider multilinestring to be a backstop when nothing else applies. By the time I got around to documenting this relation type, the one common use case that seemed unavoidable to me was for mapping geoglyphs and other things that spell out words in a non-cursive writing system.
(multilinestring has taken on a life of its own in OHM, to the point that some mappers avoid mapping anything as simple ways, essentially so that they can browse all their objects of interest in JOSM’s Relations panel. We should not adopt the same approach in OSM, because the disruption to routing use cases would be extreme.)
Lets assume that you actually wanted to create a monster MP for a continent, then one way of doing it would be to construct the rings by using linestrings (nothing supports this just to be clear and it doesn’t make the idea of such a relation any better, just theoretically more manageable) which in turn would contain the coastline ways. For example: you could have a linestring for US-East coast, Canada-East coast, etc.. IMHO you would not want to use a multilinestring as it wouldn’t have useful guaranteed semantics.
in Vespucci as they are -very- annoying).