Are these areas tagged area=yes? Because that’s the other longstanding wart in the data model that you’re about to uncover.
:: screeching tires sound ::
It would have been nice if you lead with that in the first place.
Maybe let’s take a step back and examine why we’re asking to upend the method for tagging boundaries across the database, because someone invented a novel way to tag parking laws in Poland 
I think the tagging you linked on that object is perfectly fine, because I doubt any data consumer is using it or cares about it. Just please don’t mess with the objects that are widely consumed by software all over the world.
1 Like
What is a defaults relation if not an unnecessary duplicate of a restriction relation? 
As you might’ve noticed, I’m not proposing to deprecate type=boundary even though it doesn’t exist in my perfect OSM. What I want is not requiring creating unnecessary relations for objects that are just small areas which is already prevalent and what should be done is changing some things that are written on the wiki.
Key:boundary probably requires most changes since it explicitly states:
Avoid using the tag on closed ways
When in other pages like Tag:boundary=protected_area it’s stated that you can tag it on ways.
It’s a bit different with multipolygons because the usage of boundary=* on them is prevalent but not described anywhere on the wiki. I’d say this usage is fine as long as the boundary type doesn’t require extra roles which is only the administrative ones, as far as I know.
Welp, I guess that could be an issue but is it ever an issue for other values than =administrative? Do you have examples of data consumers misinterpreting such objects?
I was curious about what the community’s thoughts about this over a decade long case are.
In my opinion it’s pretty reasonable not to use relations where they’re not necessary. It’s like creating a mutipolygon for a regular urban grassland.
I’m not sure if everyone here understands what I mean. type=boundary + boundary=forest and type=multipolygon + boundary=forest have idential tagging and ‘roling’ aside from just a different type of relation.
Off the top of my head, not quite but close: this changeset descriptively named the inner and outer members of the boundary relation for Cary, North Carolina. Although it didn’t add a boundary=administrative tag to each of these ways, it was enough for Nominatim to think “Town of Cary, Inner Boundary”, was a distinct place from “Town of Cary, Outer Boundary”, or Cary itself.
Things like this happen with alarming regularity. In order for a data consumer to distinguish the “inner boundary” from one of the simple boundary ways you care about, it would need to consider whether the way is a member of a somewhat similarly named boundary relation. In other words, it would need to copy the information from boundaries onto their members – basically what led to that Planetiler bug.
This is just one example of the minefield you’d have us navigate with data consumers. Nothing is impossible, but the big question is whether it’s all worth it. The onus is on you to make a compelling case when proposing a change from the status quo. You don’t have a compelling case yet. Unlike many other kinds of features, boundaries are so frequently modeled as relations that users and software are more used to working with them as relations. This reverses the usual tendency to avoid relations as unnecessary complexity.
1 Like
Neither is correct OSM tagging imho/fsvo.
Mulitpolygons are used as a meta geometry type together with the tagging for toplevel objects.
On that aside, there’s also closed ways vs. areas. Formally, you need to add area=yes to every element which is a closed way to denote that an element is clearly an area. In practice, this turns out to be redundant because you can exclude all elements which are only defined as areas but not ways as well as all any multipolygon which are areas by definition. This leaves you with elements which can be both lines and areas but even there you can conclude that for most of these, it makes no sense for an element to be a linear (e.g. highway=platform and how it’s used to represent platform edges or the linear way on the platform, neither of which make any sense on a long rectangle). highway=pedestrian is a notable exception because like any path it can be a loop but can also be rendered as areas and there area=yes must be used.
The punchline is that type=boundary is a type of type=multipolygon much like how building:part=* is an area=yes and if there are any more multipolygon-types with their own roles, you’re probably better of defining a new relation than trying to dilute type=multipolygon.
1 Like
Multipolygon relations are and always have been a messy hack, encoding geometry in metadata, only necessary because we don’t have a proper area datatype. I don’t see that type=boundary breaks any notion of data purity, because the model wasn’t pure to begin with.
You did ask 
Boundary inside boundary… had a look at the Vatican and San Marino. What’s on those in relations is scary.
I would point out that GeoJSON has geometry collections that can contain multiple different types of geometry objects. With other words It isn’t that far fetched what we are doing with boundaries, the structure is simply flattened a bit compared to a hypothetical boundary relation that would contain a MP as a member.
1 Like
I would say that a boundary is marking a linear/line object that is the outer border of an area, whereas a multipolygon is mapping the area constrained within its edges. So one type represents a (usually closed) linear way around an area, and the other represents the enclosed area itself. Thus having two distinct data types / names for the OSM relation makes sense to me.
1 Like
I don’t think there is any happiness to be found in going down that specific rabbit hole, you can argue both ways and it applies for example to buildings too.
I suppose I should point to GitHub - simonpoole/osm-area-tags: Data on which OpenStreetMap tags imply areas on the topic of tags that imply areas.
Slightly related question. The Wiki page for boundary=place instructs mappers to replicate the boundary=place tag (but not the place=, name= etc tags) on the outer ways.
This is different from the wiki page for boundary=administriave which says “This tag is also often duplicated on the ways that build the relation, but such tagging is optional and may be safely skipped.”
It sounds like people in this thread agree that adding a boundary=<anything> tag to the outer ways is actually a bad idea? Then maybe the wiki page that currently says please do it should at least be updated to say it’s optional, or maybe even both pages should say it’s a bad idea?
2 Likes
Reminds me of a large park boundary as multipolygon like 500 square km area which for whatever reason got tagged with natural=grassland and the whole region for a long time looked there was nothing much left to map there in landcover. Removed the MP tags and 80+ percent turned white, then mapped for months to fill in…15-20% still needs filling, but cant be correctly done from poor aerials, and will, a mix of bare rock, scree, scrub, wood, heath and whatnot. Whoever feels like surveying the terrain and map it with some modicum of accuracy is most very welcome. (Maybe revisit the aerials and see if Mr Bing has updated the zone, since it’s been about 7 months since last touched.
