Notification to prevent an edit war in Qatar with Mapbox

We are a team that maps different areas in the world, composed of:

We have been contacted to work on a construction area in Doha, Qatar. They provided us this authorization to use the data in OpenStreetMap: File:Authorization sharing data .pdf - OpenStreetMap Wiki

This area has been changed a lot because of the construction; some roads were destroyed, and many new roads have been changed. You can see the details in this recent image from Sentinel (imagery from Esri or Bing does not show the changes because they are not recent).

Sentinel:

Bing:

This is how OSM was mapped, when we started our mapping:

Our first task was removing the area’s nonexistent roads based on Sentinel and the data that could collide with the data provided to avoid overlapping issues.

Then, based on the provided data, we started to map the area, focusing on the geometry of the roads and connecting roads to the existing network.

This is the list of changeset in chronological order of the additions:

Our person on the field constantly gave feedback about what exists and what does not exist (removed).

For example, he insisted that this round about does not longer exist (and it could be verified in the sentinel image).
image

This was our work from yesterday, that shows our focus on geometries and network road connections.

Today, we wanted to start improving the tagging (put service in driveways and other tags), but we faced a massive deletion of our work. We don’t want to enter an Edit war.

The following users from Mapbox:

Performed these changes:

Now, we can see that this Mapbox team, put the round about (the one at the right) back in the map:

JuanMelo contacted marinapatsevich from internal OSM messaging, but she insisted that we should not touch this area until they finish.

How can we stop this Edit War, and tell Mapbox to stop reverting our changes that do not represent the current reality?

7 Likes

Members of the Mapbox team are duplicating data themselves. This is one example, the road was mapped twice from south to north to the round about.

Query features

This is an example of the many issues we are facing in this area, and our work cannot be completed with the people on the field.

Can you explain what you meant by achavi - Augmented OSM Change Viewer  [attic] - this latticework of “highway=residential” stubs is very unusual, and your changeset comment does not explain what these are meant to be. There are hundreds of these stubs and they are only about 10 meters apart from each other, so they can’t even be driveways leading to yet-to-be-built houses…? And why are the roads named S17-R33 and so on - are you sure these are not refs?

3 Likes

These highways were present in the provided data, and they will be used to connect on the lowered kerbs, one for the driveway, one for the footway. This is the reason they are so close. As we said, we wanted to improve the tagging today, to specify the highway type (footway, service, residential). Yesterday, we were working on the geometries and integrating with the rest of the road network.

Regarding the names of the streets, these are the current names from the construction project. We could change them to REF, but the current names are these, and it is unsure when they will be changed to real names.

Tagging the Mapbox project managers according to this page: Mapbox - OpenStreetMap Wiki :

  • @Takogin Tatsiana Koval
  • @mirikaaa Yuliya Razukevichus

An the Mapbox mappers involved in this area:

  • @marinapatsevich
  • @zelenol
  • @Alex-a
  • @lxbarth
1 Like

We listen to the community. We are looking for your feedback on how to make a better map. Get any time in touch with any of our team members. For general feedback message osm-edit-escalation@mapbox.com or create a ticket with your question on this Github

Have you tried these routes?

So you are entering data in OSM that you know to be wrong with the intention of cleaning it up later? That doesn’t sound like a good idea. If I were mapping in this area, I would do the same cleanup that Mapbox folks did.

Also, the driveways/footways in question have a maxspeed=60 (presumably kpm). This seems unlikely.

Also, the diamond-shaped intersections look suspect and are not supported by the imagery you cite.

The changeset comment on the changeset you cited isn’t particularly helpful: “Creating new elements in the area #Sysmates_Trading_&_SolutionsWLL” - It is pretty obvious that the changeset author had “created new elements”

You mention that you have special permission to use some data: “They provided us this authorization to use the data in OpenStreetMap” Where can the rest of us see this data? Given that you are not verifying it prior to upload (e.g. driveways and footways marked as highway=residential), this sounds like an import.

6 Likes

These are still not name= , and not likely ref= unless you know it will be signposted for public navigation. Seems unsigned_ref= / official_ref= / highway_authority_ref=
You should finish your work before uploading. There’s no rush to take over the territory. Quite the opposite, uploading flawed data causes the problem you have now.
I’m doubting whether all intersections have right-turn slip lanes for all 4 right-turns as well. Aside from the obvious mistake of maxspeed= on =footway , it’s not quite necessary to have it on =driveway unless there’s some law or zone.

2 Likes

Hello @AngocA,

Thank you for raising this topic for discussion. We understand that both our companies are working toward the same goal. However, it’s essential to remember that all edits in OSM must adhere to its guidelines and contribute to improving the shared, open dataset for the benefit of the entire community.

We have no objection to edits made to our data if they are based on more accurate or up-to-date information. In fact, we encourage contributions that enhance the quality of OSM data overall.

As mentioned in private messages, your changesets unfortunately introduced a significant number of errors that replaced our less complete—but accurate—data. If the edits had been accurate, their replacement would not have raised concerns, as our shared goal is to maintain precise and reliable data that reflects reality. However, due to the volume of errors and their substantial impact on navigation, reverting the changes was a more practical and efficient solution than addressing each issue individually.

We fully support updates and refinements to existing data, provided they are accurate and adhere to OSM’s mapping standards.

At this point, we see that you are still making adjustments to the area. However, we noticed that your previous deletions left some roads disconnected, and some road names appear to be closer to a ref designation rather than actual names. Additionally, the assignment of a 60 km/h speed limit to all highways, while not necessarily incorrect, seems to resemble imported data and does not account for likely areas with lower speed limits (e.g., 30–50 km/h for quieter zones).

We’re happy to collaborate and provide feedback if needed. Please feel free to reach out to us anytime.

4 Likes

Hi, @Takogin

We appreciate your feedback and the time you have taken to express your concerns. Our goal in generating this notification was precisely to prevent a situation that could be perceived as a conflict over who is mapping correctly or incorrectly. Such dynamics do not benefit the community or the shared dataset that we all aim to improve.

We acknowledge that both parties have identified errors in the edits made. On our side, we detected roads duplicated up to five times on the same location, some disconnected roads, and the persistence of mapping roundabouts and roads that, based on local knowledge and updated imagery, no longer exist. We understand that you have also identified issues in our edits. However, when uploading the data, we considered that tagging errors are usually easier to correct compared to the topological issues we encountered in the area. This does not diminish the value of your observations but highlights that both sides faced similar challenges and made mistakes during the process.

We recognize that, from the beginning, we made the mistake of deleting elements in the area without consulting your team first. While our intention was to address what we perceived as inconsistencies, we understand that this may have caused discomfort. As soon as your team contacted us, we responded with the aim of fostering a coordinated effort to improve the mapping of the area. We proposed meetings to exchange information and make joint decisions. However, since these discussions did not materialize, we decided to turn to this forum, which we believe has allowed both sides to better align their work and collaborate in the same area without conflicts. We regret if this caused friction, as our intention was always to seek collaboration.

We want to reiterate that we do not seek to generate controversy or discredit anyone’s work. We recognize that mapping is a collaborative effort and that errors are an inherent part of this process. Our intention has always been to contribute to improving the data for the benefit of the entire OpenStreetMap community.

To bring this matter to a close, we have made adjustments to the tags, replacing provisional names with “ref” and removing “maxspeed” limits until more accurate information is available. We trust that these actions will help conclude this discussion in a constructive manner.

We deeply value the lessons learned from this experience and appreciate the opportunity to reflect on how to improve our approach in future collaborations. We hope that you have also found valuable takeaways from this situation, just as we have.

I am grateful for your attention.

3 Likes