@SomeoneElse: My specific example is this: Mappers ocasionally incorrectly set the roles for multipolygon members, and so some holes erroneously become "outer" members. There are probably thousands of these types of multipolygons out there. But to a piece of software they look exactly like your sub-woods! So either all of these multipolygons need to be fixed permanently. Or - by majority vote - their semantics (that an outer ring inside an outer ring is an error and should be interpreted as "inner") and not yours represent the most widely used interpretation of overlapping "outer" rings in multipolygons.

@SK53: I completely disagree. Yes, OSM is about mapping things. But mapping things is all about giving meaning. And meaning depends on existing specifications - even if there are only de-facto specifications. If you create something that is explicitly forbidden by a specification - and usually for good reason - you are not adding meaning. OSM data can only have meaning if there is a specification that describes it, because it is only this specification that all software implementors and human readers can rely on to interpret the data. Meaning is not given by things through "osm2pgsql does it that way!", because the current interpretation of osm2pgsql may change any day without notice, while a specification won't.

Yes, if current tools cannot handle real-world cases, then by all means adjust the tools. But first find a sensible way of doing so. Multipolygons are a concept to represent areas, not to represent hierarchies. If they can be extended to represent hierarchies without sacrificing robustness - fine, do it. But if they cannot - and it seems to me that multipolygons are ill-suited for this case - then create an orthogonal concept and make sure that the existing concepts stays unaffected.

I did not know that this area is an important experiment in working out how to map woodland areas in detail. I found the two areas based on a tool that finds geometrically invalid multipolygons, and those cases were two out of only about 200 broken multipolygons in all of the British Isles. That both woods appeared in such a short list of geometric errors indicates to me that the used way of mapping was not in line with usual OSM best practices.

My edits also did not fix only a putative problem. They fixed a data incosistency that potentially affects all software that parses OSM data - even if osm2pgsql rather coincidently gave the desired output. And they only potentiall negatively affect a tiny fraction of all mappers - namely those that want to actually edit one of these two tiny woods in the UK.

I won't stand in the way of a reversion if that is the consensus. But I think that the important more general questions raised here (1. How should hierarchies of information be modelled in OSM? 2. Are overlapping or touching outer rings a reasonable way of modelling multipolygons in OSM?) should first be discussed in a broader context.

'There's lots of "mays" and "coulds" above'
.
- Yes, and these are exactly the point: The multipolgon specification requires valid mulitpolygons to have certain properties, and unambiguously specifies the semantics for those valid multipolygons. Thus, as long as multipolygon parsers are implemented correctly, they will all yield the same results - but only for *valid* multipolygons. For any multipolygon *violating* the specification, the "mays" and "could" above apply. That's exactly why formally invalid multipolygons are undesirable.

Now one might be inclined to ignore the specification and model geographic features just so that they render correctly when using the osm2pgsql workflow. But this would not be future-proof (osm2pgsql may change its opinion of what to do in a given situation of an invalid multipolygon at any time without violating the specification), and IMHO is an instance of osm.wiki/Tagging_for_the_renderer (section "General Meaning"), which is generally frowned upon in the OSM community.

Being invalid practically means that multipolygon parsers (e.g. those in osm2pgsql, imposm, etc.) will go into quirks mode and use *heuristics* (=guesses) to make it into a valid multipolygon. This may mean that they will just ignore the inner ring - which is possibly what you intend them to do for rendering. It is also possible that such a parser just assumes this to be a valid inner ring with an invalid role "outer", assumes that the role was supposed to be "inner", and cuts a hole into the multipolygon. A parser could also just drop all but the first of a set of overlapping rings, meaning that it might omit the whole wood and just keep the small part. Or, a parser might ignore this inconsistency and keep the overlapping areas, which will lead to rendering issues if the areas are rendered with an outline (in this case the outline of the subarea may be displayed or may be overdrawn, depending on the - random - rendering order) or are rendered semi-transparently (in which case the overlap will render in a darker shade than the remaining wood).

Overall, being invalid means that using a different parser will produce a different result from the same data. Put another way, it means that there is no unambiguous interpretation of this data, reducing its practical value.

As a side note, to me the underlying issue here seems to be that you are trying to use object hierarchy semantics ("OSM entity X has property A. And OSM entity Y is a part of entity X, inheriting all its properties and adding property D"), but OSM has currently no way to validly specify such hierarchies. It might be worthwhile to specify such semantics first, for example based on the "part" role of building relations (osm.wiki/Relations/Proposed/Buildings ).

"I would at some stage like to continue mapping both of these areas but it will be impossible to do so until you undo your changes."

Have you tried using a different editor? I find it reasonably efficient to work with multipolygons in the iD editor, and find it quite efficient in JOSM.

"Similarly there's no indication now that way/359674428/history forms part of Cuckney Hay Wood at all - this was present (see http://osm.mapki.com/history/relation.php?id=5353764 ) until your edit."

That is true, but is unavoidable with the current specification of OSM multipolygons. For a valid multipolygon, two rings *must not* overlap, unless one represents a hole in the other. But exactly that was happening with way/359674428 being a subarea - and not a hole - of relation/5353764.

"way/359674431/history was previously a polygon of a specific type of trees; you've made it into one edge of a relation."

I actually I made it into an edge in *two* relations: relation relation/5397178 still represents your polygon with specific types of trees. And it is also a part of the overall Cuckney Hay Wood relation, relation/5353764 to represent the overall wood's outline.

Hi, the root issue was that Walton Wood was an invalid multipolygon: it was made up of many closed outer ways that *shared edges*. As I understand it, this is is not allowed for OSM multipolygons, and will lead to inconsistent results. For example, Mapnik treated Walton Wood not as a single merged multipolygon area, but treated every closed way separately and put a separate label on it.

As I understand it, the usual solution is to modify the multipolygon so that in contains only the outline for the whole area (plus any existing holes) and not the individual subareas anymore. But this means either adding additional ways that will overlap completely with the existing ones. Or it means to split the existing ways so that they can be used to define the individual lots (which get turned into multipolygons themselves) as well as the overall multipolygon. Both approaches are suboptimal (you either get overlapping ways that are hard to edit and keep in sync, or you get many multipolygons with a similar problem). I have seen both approaches used in OSM about equally, and somewhat arbitrarily chose the latter approach as it felt cleaner (since it does not introduce any redundancies).

Ah, ja, mit "building:part=roof" würde es Sinn machen. Dann würde es auch in den 3D-Renderern (OsmBuildings, etc.) korrekt dargestellt werden.
BTW: wenn der Durchgang im 1. OG ist, dann stimmt "building:min_level=2" am Gebäude zu dem dieser building:part gehört nicht (way/255568200, letzter Edit ist von dir): laut der Simple 3D Buildings Spezifikation (osm.wiki/Simple_3D_Buildings ) würde ein "building:min_levels=2" bedeuten "die ersten zwei Stockwerke existieren nicht" - aber du meintest ja, das 1. OG existiert durchaus.

Der neu erstellte 1-Stockwerk-Building-Part zwischen Aloria und KreativPoint (neuer way/330278676) scheint mir falsch. An der Stelle ist doch ein offener Durchgang?

Ok, then I'll be more careful to identify those arrows and either leave them be or map the area from aerial imagery before deleting them.

Ah, ok, I didn't know that. I was removing these ways assuming that they were remnants, either when people forgot to tag ways they mapped, or when ways supposed to be used in multipolygons were either removed without being deleted, or were never added in the first place.

Is there any community consent as to what to do with untagged ways when they are not used in relations (e.g. delete them, convert them to notes, ...)? I don't want to delete other people's work, but I would like to clean up fragments that look like mapping accidents when I encounter them.

Hi, it was not my intention to delete anything useful. I'm not familiar with the concept of "fixme arrows". Could you please elaborate?

So are you saying that for every single change to every single tag that isn't an obvious typo, there has to be a discussion beforehand? In accordance with the first point of the OSM Editing Good Practices ("If you find elements with tags that you think are wrong then do correct them. OSM similar to wiki [sic], your corrections can always be reverted, so be bold."), I was assuming that the usual way to correct potential problems is *without* having to contact anybody. My assumption was (and still is), that dialog is only necessary once actual conflict arises, i.e. when two or more mappers are in expressed disagreement.

Is there any OSM document that outlines that your suggested process ("ask before you change anything") is the suggested or required standard for OSM?

Indeed, I did. The tag in question was the only instance of a "maker" tag worldwide, and it was ambiguous (which part of the aqueduct did William Hazledine make?). Having such exotic tags - especially if their meaning is ambiguous - does not in any way improve the data in OpenStreetMap; it dilutes it. So I verified the meaning of that information using the Wikipedia, and replaced the ambiguous tag with a note containing more specific information ("cast by ..."), thereby adding information to OSM.

However, given that there is no official policy on how to handle rare tags (some community members seem in favor of reducing the number of unique tags; you seem against it), this seems to be a question that should be discussed in a broader context.

As a side note: I find it counter-productive to start a discussion on somebody's changeset and at the same time (temporarily) blocking the changeset creator from participating in said discussion.

So you *did* only guess after all. Now your guess may be right or may be wrong, but the big picture is that there is no documentation to unambiguously interpret that tag (for example, the interpretation as "not present" as opposed to "not allowed" would also be consistent). And this makes that tag worthless. Deletable.

How are you sure that the meaning you guessed is indeed the meaning the original author wanted to convey?

I don't see how that was clear. Since the tag was not standardized (no wiki entry), there was no meaning attached to "bull=no". It could have meant that there are no bulls left, that bulls are numbered, that bulls may not enter, that a bull called "no" resides there, or any other possible meaning. So it really only cluttered the data set without providing any information.
If someone indeed wished to convey the meaning "no bulls allowed" (which was not conveyed using "bull=no"), this information should be given human-readably in a "note" tag.

Yes, it was. Those were extremely rarely-used tags (less then ten instances world-wide) from the http://taginfo.openstreetmap.org/reports/similar_keys list. If the data was relevant, I converted it to the corresponding standardized tag. Otherwise, I dropped it.