Hi zsadler,

This is an uncommon sort of dispute, where a country does not recognize another's provinces or believes them to be of a different classification. In this case, it is marking that Palestine does not view Israel's province boundaries as admin_level=4. The purpose of the relation is allow for country specific views of boundaries while still using just OSM data.

This and all the other disputes I mapped recently are being pulled from the Natural Earth dataset if you are curious on the source.

I think the name I gave was overly vague and dispute can be a charged word. Maybe something like "External Viewpoints on Administrative Boundary Levels" would be a little more clear and neutral sounding. What do you think?

Happy to chat more if you have additional concerns or questions as well.

-Jeff

Hello OrDal,

I appreciate you taking the time to reply.

1. In some cases, the dispute names may be somewhat imprecise and are there to just help clarify what they represent. Some borders or claims are recognized by other countries while the “claimant” themselves has undefined or broader claims themselves.
2. Border disputes are almost always cases such as this. Although some are active conflict zones, the majority are simply stated disagreements over a territory. In this case, Syria still claims the territory and many countries of the world still recognize it as occupied territory. The relation is not adding legitimacy to the claim, instead, trying to reflect the complex reality of the world.
3. These sorts of relations are admittedly a little weird looking. In this case, it is Palestine not acknowledging the districts of Israel. Instead, the relation marks them as admin_level=8 for Palestine specifically to lower their prominence. The other countries are defined explicitly as still having admin_level=4 just for completeness.

User nvk has two great diaries detailing this work that you may find interesting here
@nvk/diary/390496

Wikipedia documents these disputes of course, but it is not a geographic database. OpenStreetMap is increasingly the primary datasource for the world’s maps and having complete administrative data is a pretty important part of that. “On the ground” is a good policy for mapping country borders, but the laws and expectations of various countries make this not a complete solution for downstream users. Dispute relations can fill in this gap while being unobtrusive and invisible to the majority of users.

Our main source for mapping these is the free datasource Natural Earth which you can peruse here if you are interested. It is a collaborative effort and the disputes are still pretty new so if you see issues or mistakes you can report them to the GitHub for corrections. NE is a low resolution datasource that is meant for big picture maps, while this mapping project helps to create OSM data that can take over for high resolution maps.

https://www.naturalearthdata.com/downloads/10m-cultural-vectors/10m-admin-0-breakaway-disputed-areas/

-Jeff

Hello OrDal,

These relations mark lines of contention that exist in the real world. The intent is not to make judgement on the validity of any particular claim, dispute, or reference line, only to accurately document them. Additionally, these relations will not affect anything as far as rendering goes unless a data consumer actively builds support for them.

I'm happy to chat about these with you further as I understand these can be very sensitive, in the meantime I'm going to restore them though.

-Jeff

Just an update that I have moved the tags onto a relation in both Israel and Palestine now.

Thanks for your patience and feedback!
-Jeff

Hello, sorry I forgot to update the source. These edits are based on disputed borders contained in the Natural Earth dataset. Province level admin level viewpoints are part of the admin 1 dataset here.

https://www.naturalearthdata.com/downloads/10m-cultural-vectors/10m-admin-1-states-provinces/

Nvk's diary posts here help explain the tagging and rationale behind the edits. @nvk/diary

Essentially, these tags are to allow downstream users to display borders in different ways depending on the localities being served in OSM based maps.

I totally understand that these are sensitive edits and am happy to discuss them further.

-Jeff

Hey ivanbranco,

You are totally right. I missed it somehow when I was looking for an existing feature to attach to the relation. I removed my duplicate and add the existing one to the relation instead.

Thanks for the heads up
Jeff

Hey user_5359,

Just want to give an update that I'm looking into how best to move these onto a relation and will get back to you soon.

-Jeff

Hello Supaplex,

This is tagging related to disputed borders. These admin_level:iso_code tags allow for ways to be reclassified for certain country views in downstream maps. nvk has a good diary detailing the use case here @nvk/diary/390496.

This is definitely sensitive work and no offense is meant by adding them. I'm happy to have a dialogue on how best to represent these that would be acceptable to the OSM Taiwan community.

-Jeff

Oh totally, just cleaned it up. Sorry about that.

I had some NE ways in JOSM to help with the digitization and missed cleaning up one of them.

Hello again!

Currently, our map renderer expects these tags on ways. Is there any particular concern with them remaining there? They will not affect any rendering on the OSM website or any downstream map that doesn't specifically choose to use them.

Totally open to dialogue on this so hope to hear your thoughts :)

-Jeff

Hi highflyer74,

These admin_level:iso_code tags are used specifically to redefine boundaries to alternate levels such as a country border being defined as a state border instead. nvk's diary here shows a good example of the use case using India, Pakistan, and China here. @nvk/diary/390496

mueschel was pointing out that I used lower case iso codes by mistake which has now been fixed, but the tags themselves do serve a purpose.

Happy to continue discussing these edits if you have more questions or concerns about them. :)

-Jeff

Yeah go for it. The current names for the disputes are not necessarily the best names.

Hey mueschel,

Good call. I just cleaned that up. Thanks for letting me know!

-Jeff

Hello!

I fixed the lower case typo. Thanks for pointing it out.

-Jeff

Hello!

This is follow disputed tagging work that user nvk started. You can read his diary post about his previous work here. @nvk/diary/390496

We are using relations for all the country border disputes but for these lower level perspective differences we planned to just tag the ways. I'll sync with him on Monday and see if we can just move these tags to a relation as well then get back to you. Sound good?

This is sensitive tagging work so I appreciate the feedback!

-Jeff

Hey NM$L, thanks for quick feedback. This is sensitive work that I want to make sure is done right.

For the first issue, I had included way823046242 in the new relation (relation/13559369) but missed pulling out the old incorrect ways from the parent relation. Good catch there and I have now fixed it.

The eastern section is still included as this relation relation/13559373 and attached to the parent relation if you check the members. Unfortunately, the OSM website doesn't really display relations containing relations well, which is one downside to this approach.

-Jeff

Hi Andy,

Yes, you are correct that this check was based on a pbf where the road names were still present. Thank you for pointing out the error. I removed the invalid name and will discuss with my team to look out for similar instances.

Thanks,
Jeff

Hi Yppenpark,

Thanks for your contributions to OSM

This park relation is currently broken due to the interior ways overlapping each other. Generally, a park should cover all the area within it and not cut out minor interior features, so removing the flowerbeds and manmade features from the relation would solve the issue.

Let me know if I can help :)

-Jeff

Hi Jmilot,

This user left our team recently.

Sure thing. The goal of this mapping is to capture all pedestrian ways and crossings, but I can see we missed some here. I ran through the area and added any that I noticed were missing.

We will also have an additional validation pass as the area gets filled in further as well.

Thanks for reaching out
-Jeff

Hi Baloo Uriza,

Thanks for the feedback. This changeset is part of a project to identify mismatched names on road segments. The connecting roads here carry the State Highway 82A name tag while this one had N4514 Road which is the reason it was flagged.

We appreciate the heads up on the deprecated highway name. Looking at the route, State Highway 82A is still the name on quite a few segments. If I understood your feedback correctly, we can go ahead and remove the State Highway 82A tag and promote the local road names to name. Sound good?

-Jeff