"At its core, OSM thrives on tolerance and respect for one another."

Yes, but there is a second mantra that is well established:

At its core, OSM thrives by people freely being able to correct each others work (no single person "owns" stuff in OSM), and to enhance or fix broken stuff.

Well, it is hard to talk about something unless you can view the actual historic object in JOSM, but your own blog post's screenshot appears to show otherwise. The image of the established MP appears to show intersecting inner and outer rings.

I do not make it a practice to delete other users stuff without carefully verifying it in JOSM, also through the included validator there, so I assume JOSM flagged it.

But again, talking about something that was, is hard. If you can point to some history viewer for OSM that shows the actual historic object at the time of creation, maybe we can have a more productive discussion of this issue.

It is fine to have your own interpretations of OpenStreetMap tagging, but if you clearly violate some of the basic best practices that by now are quite well established around building relations and multipolygon relations to bend them to your own view, you deliberately choose to risk people correcting your work.

There was nothing to repair, as this MP did not pass JOSM mulitpolygon validation due to inner and outer rings intersecting which was a conscious choice by you, which leaves only one real option, that is to delete it, as there is no sensible way to correct it. Likely, with the enhanced validation in iD, iD will now also no longer allow you to build such invalid multipolygons.

The relation between building parts you tried to model, is easily able to be mapped with the type=building relation you already tried to create, but you then also deliberately made that one invalid by not including the role=outline feature (and JOSM complains about this as well with a "Warning"), because in your view, it needed to be a separate feature mapped as that invalid MP, which again is not best practice around how to model type=building relation with building parts.

Honestly, I really recommend you to stick with best practices, if I hadn't done it, someone else was really likely to have fixed this issue in the past three years since these edits because automated online validation tools would have flagged it also as problematic, so you would have ended up in exactly the same situation anyway by another users edit.

Hi Rafael,

I am totally fine with this change, and especially with you also adding the 'admin_level=2' tag that Madrid was missing.

That said, and that is good thing, things have somewhat changed from a couple of years ago and become more consistent.

A few years ago, there were quite a few country capital nodes having 'capital=2' if I remember well, instead of 'capital=yes'

Even today, the situation isn't as simple as the Wiki suggests. E.g., if you just select 'capital=yes' in Overpass Turbo, you end up with 216 nodes, which is more than what is generally seen as country capitals:
https://overpass-turbo.eu/

If you select on both 'capital=yes' and 'admin_level=2', you end up with 198 nodes:
https://overpass-turbo.eu/s/1xDp

Some countries are just more complicated. Quite a few, including the Netherlands where I live, have both a legislative, and an executive capital, both of which may be tagged with 'capital=yes' and 'admin_level=2' as is the case in South Africa with Pretoria as executive and Cape Town as legislative (but not the Netherlands).

South Africa even has a third 'capital=yes' tagged node for Bloemfontein, and is the 'judicial' capital (but has no 'admin_level=2' tag like the other two nodes).

Hoi, beetje late respons. Je hebt gelijk, geef toe dat mijn edit van de "surface", los van wat andere veranderingen en verbeteringen in dezelfde changeset, gebaseerd was op verouderde luchtfoto beelden, en een meer algemene "hunch" dat een dergelijk klein vliegveldje toch wel niet over een verharde baan zou beschikken, en de eerder toegevoegde "surface=asphalt" wel fout zou zijn. Niet dus. Zal de juiste surface weer toevoegen.

Sorry if the comments appeared to harsh. I just think it important to be consistent with these things in an global context wherever possible, as this data is used by multiple styles, that may depend on accurate information regarding such features as basic huts used for survival in mountainous areas.

I have indeed attempted to contact one of the people mentioned on that page you linked. Let's see if there is a response...

I agree they are "amenity=shelter", even if they are likely only historic ones, and probably rarely used nowadays.

But I disagree they are "shelter_type=basic_hut".

If you look at the English Wiki page (osm.wiki/Tag:shelter_type%3Dbasic_hut), it clearly states that the structure should be fully closed, and provide some form of (bunk) bed. This tag is meant for survival type huts in trekking and mountaineering areas, not for historic weather shelters for humans or cattle.

The French version of the page seems wrong (osm.wiki/FR:Tag:shelter_type%3Dbasic_hut), as it suggests these structures do not have to be fully closed ("n'est pas totalement fermée"), this seems a deliberate adaptation to facilitate this type of "capitelles" only, which seems to me a contestable tagging practice.

E.g., also look at the German or Spanish versions of the page (osm.wiki/DE:Tag:shelter_type%3Dbasic_hut and osm.wiki/ES:Tag:shelter_type%3Dbasic_hut) and notice they both list the page similar to the English one, with fully closed and bedding provided as requirements.

If you re-tag them to a more appropriate "amenity=shelter" + "shelter_type=weather_shelter", they will still be visible on the map, but not be equated with survival type huts in mountains as they are now.

I also think it wise if the French Wiki pages for "shelter_type=basic_hut" and the page about these "capitelles" (osm.wiki/FR:Garrigues#Patrimoine_en_pierres_s%C3%A8ches) was adjusted to reflect the other language pages, and adapt the tagging for the "capitelles".

Hi,

I noticed you tagged a series of what appears to be historic dry stone shelters as amenity=shelter, shelter=basic_hut.

However, that tag is meant for true survival type shelters, usually including basic accommodations to sleep, like a bunk bed, and usually located in mountainous areas.

I think these historic (cattle/human?) shelters are better re-tagged to amenity=shelter, shelter=weather_shelter, as a more suitable tag for their purpose and build.

I wouldn't call widespread pretty much established tagging "a common mistake", rather the Wiki likely needs updating to reflect it.

There is quite a bit of undocumented established tagging, that really should be taken into account before assuming the Wiki is "right".

Notes *do* contain admin_level tags. In fact, almost all capital cities in the world have the admin_level=2 set on the node, and it is currently the most consistent way to get all country capital. For admin_centre role nodes, that may be part of multiple admin boundary relation, it is quite established tagging to add the highest level admin_level to the node, while the atual admin_level of the relations it is part of, will generally differ.

E.g. a country capital node may have admin_level=2 set, and subsequently be part of boundary=administrative relations with admin_level=2 / 3 / 4 / 7 / 8 or whatever.

Hi,

In this changeset, you removed admin_level=2 from the Beijing node, despite it being the capital city of China, and added notes it should be "removed" if re-added. I think this is incorrect.

Essentially *all* other country capital nodes in OSM have admin_level=2 set to signify in a standard way that they are country level capitals, and this is used for cartography as well.

If the city has a lower "admin_level" in the country itself, that admin_level (e.g. "admin_level=4"), is usually set on the corresponding "type=boundary" + "boundary=administrative" relation.

So the relation's admin_level can, and usually will, differ from the corresponding and associated node's one in the case of country capitals.

Please review some of the other country capitals to understand what I mean.

I recommend you to re-add the "admin_level=2" tag, so that Beijing correctly shows up as country capital of China in maps that use this information, and remove the "note" tags, because there is currently no other tag to fully cover this particular aspect related to country capitals.

Thanks for pointing out. This was an accidental error, I had intended to edit the node of Lomé, not the boundary relation.

This is now fixed.

Hi Odiz,

I noticed that there are a lot of free_flying sites in Norway that you have been editing and that don't have any path connecting them to the outside world.

Now I don't know if it is common practice in Norway to stroll through wild forests and heaths to get to a take-off site, but I do think adding paths where they do exist, would add value to the data.

Still, I guess it is not uncommon that many will not have a formal path, as the usage of the take-off sites is likely only sporadic in a sparsely populated country like Norway.

"rever" should have been "revert" of course...

Hi Colin,

I personally do not consider the tagging of this island "inappropriate", considering what happened.

Establishing whether the decontamination rendered it truely safe to visit, I guess is hard, as people are likely still avoiding the island due to an abundance of caution, and it being private property, and varying opinions related to this.

The only reason I suggested you might pick this up, is that I consider the ultimate say to be with the local communities in these cases.

If you prefer me to rever it, I can do that for you, no problem.

I also don't mind if you revert the edit, if you feel that's more appropriate or the easier option to avoid discussions.

Hi Colin,

Feel free to do this yourself as part of the British community, if you know a more appropriate tagging. It is just a well known historic event.

Of course, this was bound to be a little bit contentious edit, as establishing the true safety is virtually impossible, considering the type of hazard, and no official guideline seems available (e.g. using the "Search" textbox on something like www.gov.uk or www.gov.scot doesn't turn up any reference to Gruinard Island).

Here in the Netherlands, we have the so called "pestbosjes", small patches of forest often situated well away of farm yards, where carcacesses of diceased sick livestock were buried before a national destruction law came into being in the 50/60's. They still pose a thread, decades on, if accidently not left undisturbed due to redevelopment.

Hi Marc,

Sorry to answer in English, but I can read and understand your question well enough.

As you noticed, I haven't removed these tree features, just retagged them to what I think in this situation is more appropriate.

I really personally feel that these kind of exceptional features (only very few buildings have true trees in them), should not be tagged with a main tag like natural=tree, without any additional information attached to them.

It is confusing to see trees appear on top of a building feature, suggesting a digitization error, even if this situation is becoming more common.

Using a main tag like natural=tree for these kind of exceptional features, will also mean that no cartographer will be able to easily filter them out, without resorting to some elaborate point-in-polygon automated check on every tree and building feature in OSM (which would be a pain to do on a global scale).

I feel the "indoor=x" tagging scheme is quite appropriate for this kind of feature, even if it is not currently rendered in the Default map. That is why I changed them to indoor=tree. This will still allow specialized (indoor) renderers to show the features, but not have the confusing tree features appear in every map derived from OSM's database.

Marco

Vermoedde al zoiets, volgens mij ben jij een te ervaren mapper voor een dergelijke fout. Het is nu in ieder geval snel opgelost.

Marco

Hoi padvinder,

Ik zag dat je in de Wimmenummerduinen bij Bergen aan Zee de tags voor een vogelkijkhut op een hele grote polygoon voor "scrub" had toegevoegd. Dit is echt "bad tagging practice", en ik wil je vriendelijk vragen dit niet meer te doen. Ik heb deze tags dan ook weer verwijderd.

Maak in plaats daarvan een nieuwe node aan op het punt waar de vogelkijkhut staat, of digitaliseer de outline van het gebouwtje (als het dat is), en voeg dan ook "building=yes" toe.

Happy mapping!

Marco