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.