Hi,

I noticed you added back in the Seoul node e.g. the Seoul boundary relation. That by itself is fine, however, I would recommend to set the *node* to admin_level=2 instead of 4, the highest level it represents.

It is a frequent misconception that people think the *node* needs to have the same admin_level of a boundary *relation* it is part of.

This is not true.

The simple proof of that is already in the fact that this node is part of both a boundary *relation* with admin_level 2 representing the entire country of South Korea:
osm.org/relation/307756

And a local admin_level=4 relation representing the Seoul administrative or metropolitan area:
osm.org/relation/2297418

In this case, almost all other countries in the world have the *node* of the country capital set to admin_level=2, not 4 or whatever lower admin_level is appropriate for a corresponding boundary *relation*.

This allows renderers to properly display the node as country capital, without having to parse all possible relations the node is part of in search of the one with the highest (country) level admin_level tag, which is cumbersome.

Done, also after contacting the original author of the node to ask for the reasons and source of the addition of this node, see this changeset discussion: osm.org/changeset/141871724

Hi Martin,

As you've probably seen from the links I posted, it is not just a problem of location (which is clearly wrong), but also a tagging issue.

I intend to agree with the Saudi member that tagging this feature as natural=desert is inappropriate.

Due to these two issues, I think the best course of action for now is to delete the node.

If you do feel such a node is needed, please do not re-add it tagged as natural=desert, again, see the tagging discussion in the other changeset discussion.

Marco

Hi Martin,

In this changeset, you added a node named "Arabian Desert" referencing the eco-region of the Arabian Desert on the Arabian Peninsula via a Wikimedia link.

However, the node was placed in Egypt. I subsequently moved it to the Arabian Peninsula in Saudi Arabia, but this let to a discussion with a Saudi OSM member that noted that no such geographical feature exists or is recognized in Saudi Arabia, see this changeset discussion:

osm.org/changeset/145744747

I intend to agree, and have some plans to clean up this node, as with a false location in Egypt, it is just wrong information.

The point is that the "Arabian Desert", as per the Wikipedia page (https://en.wikipedia.org/wiki/Arabian_Desert) represents not so much a known geographic landmark in Saudi Arabia (there isn't), but is a more general term for a large eco-region covering almost the majority of the Arabian Peninsula.

With this context, what was your intention of adding this node with these tags and in Egypt?

The only other viable alternative would be to re-tag it clearly as "eco-region", e.g. by removing the "natural=desert" tag, and replacing it by a new, yet to be documented tag, of something like "natural=eco_region" / "eco_region=desert" (and where something like the Amazone Forest could be tagged like "natural=eco_region" / "eco_region=tropical_rainforest").

But I think for now is best to delete this node.

Hi Abdullah,

Let me first say that I agree to a large extent with your reasoning, and I do agree the best course of action is to delete the node. So this is what I will do as a next step.

Leaving a node that is supposed to indicate a region on the Arabian Peninsula located in Egypt, is just nonsense.

Cross checking also with two of my printed "World Atlasses", also confirm your claims about geographical landmarks, as both do not list the "Arabian Desert", while something like the "Rub' al Khali" is.

As to the Wiki: at least the English version may still have some merit to it, in the sense that it clearly states the "Arabian Desert" not as a geographical landmark, but an "eco-region", so a name to indicate a region having a rather uniform and distinct ecological context. So this is different from what we generally consider a landmark.

Whether "eco-regions" like the "Arabian Desert" or "Amazone Forest", or whatever else that could classify as "eco-region", should be mapped in OSM is a different discussion, that I won't go into here now, and as usual, essentially anyone is free to map what he wants in OSM, although the data also stands to be corrected.

Best regards,

Marco

Hi Abdullah,

There *is* an Arabic language Wiki page of the "Arabian Desert" as well:

https://ar.wikipedia.org/wiki/%D8%A7%D9%84%D8%B5%D8%AD%D8%B1%D8%A7%D8%A1_%D8%A7%D9%84%D8%B9%D8%B1%D8%A8%D9%8A%D8%A9

I appreciate this may not reflect how Saudis generally talk about the deserts in their country, as the "Arabian Desert" is essentially not directly associated with any distinct "desert" feature in any of the countries on the Arabian Peninsula, but more a kind of higher level geographical name to recognize most of the Arabian Peninsula having desert like conditions.

However, with Wikipedia pages in 69 languages, including Arabic, Persian and Urdu, I think it is fair to say this is not an "unknown" or unrecognized feature, even in the Middle East.

The current node clearly references the Arabian Desert as the feature meant to be located on the Arabian Peninsula, as the Wikimedia link references it.

I thus think we have 2 choices here:
- Re-locate it back on the Arabian Peninsula, with the slight risk that your fellow country people just like you won't recognize it.
- Delete the node entirely. I see little point in having an "Arabian Desert" node referencing a geographical region supposed to be on the Arabian Peninsula lying in Egypt. This doesn't make sense, it is just wrong information, harming the map.

Marco

Hi Abdullah,

I noticed you reverted a change of the location of the node for the "Arabian Desert" that I made recently to put the node on the Arabian Peninsula, from an apparently false location in Egypt.

After your change, now the node is back in Egypt. Can you explain why? Is this part of Egypt's deserts also called "Arabian Desert", because all the pages I have seen, including the Wikidata page linked in the nodes tags, reference the "Arabian Desert" as being on the Arabian Peninsula, not in Egypt?

E.g. all these encyclopedia pages references to "Arabian Desert" exclusively talk about the Arabian Peninsula, not Egypt:

https://en.wikipedia.org/wiki/Arabian_Desert
https://www.britannica.com/place/Arabian-Desert
https://www.worldatlas.com/articles/where-does-the-arabian-desert-lie.html

If this desert part of Egypt is also called "Arabian Desert", I think it would be good if you corrected the Wikidata tag of the node to reference the correct data in Wikidata (or add a new entry to Wikidata if missing), instead of the one referencing the Arabian Peninsula, so as to avoid confusion.

Hi Dylan,

I have now downloaded official CanVec data from the "Government of Canada" website and its "Geospatial Extraction Tool" at 1:50k scale from one of the areas you recently added to OSM, to be able to compare the imported data with the official data.

I then loaded it in ArcGIS to have a look at the data. I learned two important things from this:

- CanVec data uses a classification for the density of the forest with four classes: 'Forest','Dense','Open' and 'Sparse'. You are undoubtedly already aware of this, but it definitely seems anything classified as 'Open' or 'Sparse' should not be imported as woodland in OpenStreetMap. Such often waterlogged and bog type acidic environments with sparse trees because few can survive, would not qualify.

- There is definitely an issue with your current workflow. The 'whitish' tiles with few forest polygons, seem to properly match 'Forest' and 'Dense' classifications, and seem OK. The almost entirely green tiles, where the entire tile was imported as woodland, seem wrong, they don't match.

I wrapped up a direct comparison in a screenshot of exactly the same area in OSM and ArcGIS, including a quick legend for the official CanVec data in ArcGIS, that shows the different classifications and issues, see the below DropBox link where you can download it:
https://www.dropbox.com/scl/fi/3tekmykdwwp7vdxlj0xxu/Canvec_issue.png?rlkey=z6x7p3h6hgtbrya6iwtkg5bnx&dl=0

There is now also a tough decision to make. It may be hard to fix this in any (semi-)automated manner. Maybe you need to revert the entire import of all of these tiles, and start from scratch after you've corrected your workflow and are absolutely sure it will now produce proper results.

Hi Dylan,

At least part of the issue is likely related to this page, and the translation between CANVEC data to the OSM node,way,relation model, which isn't 100% clear cut solution:

osm.wiki/CanVec:_Geometric_Model

By the way, looking at some of the CANVEC data, I do wonder how exactly this data was generated?

This other page: osm.wiki/CanVec:_Vegetation_(VE)

already suggests that some, or most, maybe not surprisingly given the immense size of Canada and the task to manually digitize such data from aerial imagery, is fully automatically derived from e.g. satellite imagery. I do see strange mismatches between actual imagery forest e.g. along streams and rivers, and the data in CANVEC. The data related to forests seems pretty coarse and generalized, and doesn't match imagery very well.

But alas, there is not a lot you can do about that if Natural Resources Canada doesn't deliver better data...

Marco

Hi Dylan,

I am not a Canadian, and only slightly familiar with the CANVEC data, and not at all with the actual import processes available and used in the past.

My remarks are solely based on the current rendering of the data you added and comparison against aerial imagery in e.g. iD / JOSM, and what I see happening at the boundary lines between what are apparently CANVEC 'tiles', where in many cases there is a mismatch between one and the other tile related to the forest polygons.

I would recommend to try to discuss this with some fellow Canadians before continuing to add data, e.g. in the Canadian subforum of the OpenStreetMap Community Forum: https://community.openstreetmap.org/c/communities/ca/95

It would be a shame to see your work go to waist because you haven't yet completely figured out the correct workflow for getting this data into OpenStreetMap.

Marco

Hi dmich9,

I have noticed you have been importing new tiles from CANVEC. It is nice to see someone picking up CANVEC import again in an attempt to enhance the landscape rendering of Canada and reduce the current patchwork. However, I have noticed, and this was already visible and a problem in old > 10 year ago imported CANVEC data in OpenStreetMap, that many of the new tiles you added seem to get the Multipolygon representation of forest wrong, where the areas that should be forested are blank, and the majority of the tile's area displays green, even though these high latitude tiles only contain a minority of truly forested area due to mostly sparse tree vegetation. This leads to a false and severe over-representation of forest in the tiles that have this wrong. This is currently clearly visible in the patchwork of green and whitish tiles where the "whitish" tiles with minority green patches seem to represent properly defined forest polygons, and the almost entirely green tiles seem to have it wrong. Are you aware of this major issue in your current workflow, and do you plan to fix this is in a second edit round? (it would be preferable to get it wright the first time, so a not to confront data consumers with problematic data).

Regards,

Marco

Well, that is your call.

As I've said, I wouldn't recommend it, but instead add the building parts of the ground floor to the building relation as well, as is best practice, and add another part for the true total ground surface outline as role=outline. This is clearly the recommended practice from the 3D buildings' specification.

If you do not do this, you will still have a JOSM validator "Warning" flagged type=building relation, that may trigger other users' attention and you may end up in a similar situation.

But enough said, its your call.

"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".