Warning: New GrabOSM campaign

Hello everyone, apologies for the delay in response, I haven’t been keeping well. First of all, thank you all for the comments and feedback, we are learning and this is helping us get better.

@cmoffroad

Sure thing, there was some misunderstanding at our end, but noted, we will ensure that any new campaigns will be shared on this forum as well as Github.

Noted, going forward, if there’s a change, we will be leaving OSM notes for the community to help us with or ask a question on the changeset.

Make sense, and thank you for the explanation on the usage of roads in rural areas. We are here to learn from the community. Going forward will tag the unpaved roads in the agricultural or forestry areas as tracks referring to https://wiki.openstreetmap.org/wiki/WikiProject_Thailand.

We do like the idea of using the Grabremote=yes tag when we are mapping at scale, but the question is, would the community be okay to verify and remove the tag post verification? As a practice we have been using a unique changeset comment for all our campaigns/projects, that helps folks and us to filter changesets pertaining to a particular project. We mention them in our Github ticket too. One can use OSMCha to filter them out - https://osmcha.org/filters?aoi=0fa187ae-ce9b-4def-a17d-db9c2b0c9549. Just want to ensure that we don’t have an additional step for the community.

This is a valid comment, @stephen, as mentioned in one of the comments, the policies that we have are okay for urban areas but when it comes to rural locations, that’s where we would require the community’s help, and if you take a look into our past discussions on Github https://github.com/GRABOSM/Grab-Data/issues?q=is%3Aissue+label%3A%22Community+Review%22+is%3Aclosed, we have been consistently communicating and seeking community guidance to better understand and modify our policies accordingly. We will continue to ask questions so that it’ll help us map and understand the data better.

Rest assured, going forward we will be using forum to communicate, improve our mapping policies and collaborate with the community. Thank you again everyone for the feedback and this discussion. :slight_smile:

No, do not create a new tag, use the existing “import” key, just with a new value, e.g. “grab” or “grabremote” or whatever you like and differentiates your imports from Facebook’s.

Why? Because filtering for the existence if the “import” key is enough during map creation, no further filters required (just imagine an extra filter for any current or future company - that’s a horror).
While I was travelling in Thailand last January, I collected a lot of data regarding Facebook’s imports. I will add that soon.

But I’ve detected that not all mappers remove the “import” tag when they verified a highway - I found such imported highways which have meanwhile received a reference number but still have that tag.

First of all, I want to thank you @jinalfoflia for your honest feedback, and I really appreciate you took the initiative to move your specific questions to this forum. This will make the community more involved and will be the perfect place to share knowledge and reach a general consensus on specific issues.

As a side note, not everyone may be able to respond quickly, so please allow a few weeks to collect a general consensus from the community before applying any decisions.

A changeset description would not be sufficient, because as it is very often the case, once a road segment get split (when separate tags are needed), new road segments are created and the original segment history is lost.

As Bernhard mentioned, using an existing OSM tag key would be best instead of creating a new one e.g. import=grab
Since you are using JOSM, it should be possible to add a preset to include the new tag automatically.

Since the verification and removal of these tags may take time, I would suggest for now to follow @nitinatsangsit advice to exercise great caution when you want to change existing road classifications.

In urban areas, there are many instances where highway=living_street and highway=service+service=alley have been wrongly used, and I would be more than happy if you could help us fix these. In the meantime, we don’t want actual agricultural tracks or service roads to be changed again to residential.

If you find an area where you believe many roads have been wrongly classified according to the wiki definitions and decision tree, please create a new post and ask for the community feedback as you did here: https://github.com/GRABOSM/Grab-Data/issues/96

I am now adding all those data collected during my holidays… Grab imports seem to be very special.
Obviously, Grab mappers cannot imagine that a road starts as an “unclassified” (or “residential”, and at the end of the village just continues as a track. No, it is mapped as a “residential” for kilometers into rubber plantations…

And, seriously, that is not a service:
https://www.openstreetmap.org/way/965914261/history
(south-east of bridge
https://www.openstreetmap.org/way/311932114
in case it cannot be shown anymore after my correction…)

Thank you, everyone, here’s what we are going to be doing, and would love to seek consensus on the same

Post doing some research, we realized that there are already so many import=yes Overpass link and ideally import tags are used for edits that are automated, these edits are manually made by mappers following the traditional mapping process. So for all the mapping campaigns, we would like to add grabremote=yes tag instead, so it doesn’t cause confusion as well as serves the community’s suggestion on being able to differentiate.

We will ensure that we do not modify existing classification and if there’s a need to, we will leave a note for the community.

Noted, we will take a look into it and see the possible next steps.

Thank you folks for all the help!

My strong suggestion is to leave “import” as a top-level tag and add different values to that key as more and more corporate entities sign on to add details and unfortunately, confusion, to OSM. That way, when we search for future culprits we can search a single key to find all edits from a particular contributor, e.g.,

import=Facebook AI

import=grabremote

import=amazon AI

etc.

Otherwise, someone will have to maintain a list of all the contributors outside of the OSM database. This will be another nightmare for future maintenance efforts.

grabremote=yes

facebook AI=yes

amazon=yes

other_company=yes

Yikes!

Agree with @AlaskaDave. import=* is better.

Thank you folks for the suggestion, we would like to go with import=grabremote as the tag we will additionally use when we are mapping for a mapping project by our remote team.

One kind request to the community - if we can make these guidelines a part of the Thailand wiki too, helpful for any new teams mapping in TH as well as helps folks from other regions understand that this is not an ‘import’ import but more of a convention we are using post consensus with the community. (Imports are usually used automated edits and these aren’t). We have added this in our OSM wiki.

Thank you once again, for this discussion and I’m glad that we have a consensus on the next steps. Looking forward to working together and mapping in Thailand.

Happy Mapping,
Jinal

Thanks @jinalfoflia !

One kind request to the community - if we can make these guidelines a part of the Thailand wiki too,
helpful for any new teams mapping in TH as well as helps folks from other regions understand that this
is not an 'import' import but more of a convention we are using post consensus with the community.

Agreed, the tag “import” doesn’t describe what you’re doing. It’s a poor descriptor. I suggested it because it’s already in use:

https://taginfo.openstreetmap.org/search?q=import%3D

Unfortunately, the very vague tag import=yes has 2.3 million uses already which is way ahead of the next most popular import=budovy201004 with about 800K uses.

@AlaskaDave, makes perfect sense, we also do not want to create new tags as well. Going ahead with import=grabremote made complete sense. Just ensuring that it’s defined well, will help others to get better context. That’s why suggested adding it in the wiki for reference (especially to folks who aren’t a part of this conversation).

@jinolfia: Great to hear.

Could you please make sure to only use the new tag for new road additions, or roads you previously added and were not modified by anyone else ?

If you believe an existing road classification is wrong based on imagery alone and you wish to change it, please:

1 - ensure its additional tags do not contain any reference to a ground survey (e.g. a note, or source=GPS, survey, mapillary) or off-road conditions (surface=unpaved|dirt|ground, tracktype=gradeX)
2 - contact the original mapper through its changeset comment
3 - if you don’t hear from the mapper or see a general pattern in an area that needs clarification/correction, please collect road ids and submit a new topic on this forum

This I believe will ensure we don’t run into similar past issues. If you have any other suggestions, please let us know.

@others:

who would like to contribute a small section in the wiki describing the usage of import=* for companies/organizations?
e.g. import=yes for Facebook, import=grabremote for Grab. New campaigns by other organizations should also use a new value e.g. import=hotosm…

Even trunk_link is not safe from being re-tagged to residential:
https://www.openstreetmap.org/way/803763833
I commented the changeset already.

Hello folks, our team encountered a specific instance where the existing feature already had the ‘import=yes’ tag, in that scenario, we are replacing that import tag with ‘import=grabremote’ if we make any change to the feature from our side. While looking into that feature, one will be able to see the history through the version. Let us know in case there are any concerns from your end on this approach. Thank you!

As far as I am aware the original import tag concept was used only for new additions (imports) by Facebook based on aerial imagery/artificial intelligence, and its main usage has been to correct possibly wrong highway classification.

If you change other tags (e.g. noexit, name) based on local information (e.g ground survey, mapillary, kartavia), you should use instead the prefix source tag to indicate on the data was gathered or improved, e.g.

  • source:noexit=survey
  • source:name=kartaview

@jinolfia Thanks for the updates on your mini-campaigns in Thailand.

Going through your company guidelines, I found a few concerning elements:

Country wikis take precedence over the global wiki definitions.

I see absolutely no mention of the Thailand Wiki road classifications which have been discussed in length and are the main source of conflicts between GrabOSM and the Thailand community.

First, you will not be able to distinguish major roads from satellites and you should refrain from tagging those unless you have the official actual reference data that matches the official Thailand wiki classification table.

Second, I see no mention of Tracks which is the most common road classification in rural areas and the greatest source of conflicts with the Thailand local community.

This is a great addition but no mention that it’s really meant for new additions, or what should GrabOSM mappers do when they want to change the existing classification added by a local mapper.

I would like to remind you that import=grabremote is not a blank check so you can continue doing the exact same work as before.

It depends. I dare to do so. And when I later get there and see the ground truth, it generally fits. And often, I can also collect reference numbers on ground which then also make those ref believers follow my tagging.
But… if Grab can do so, too, … that’s a different issue…

You are a local mapper and do ground survey verification, I don’t see any issues with it.
Grab on the other hand does mass additions and modifications without caring about the ground truth, this is definitely an issue.

Hello @cmmoffroad, thank you for your comments, here are a few pointers from our end, related to the usage of import=grabremote tag

  • Going forward, we will use this tag while making a new edit on OSM
  • Modifications such as re-alignment will not require the change in tag, only if we add new road geometry we will be using this tag
  • When it comes to the addition of source, this is automatically captured in the changeset that is created, all the editors automatically take the source such as KartaView in the changeset comment, we would not want to add another tag as that would be redundant data
  • When it comes to our policy, as we have worked closely with the communities our local policies have been updated. We always give local policies preference over the global ones. Our wiki page is a common page for all the regions that we are working and collaborating with, thus the statement.
    Let us know if there’s any further clarification needed on the same. Thank you!

@jinalfoflia, thanks for your late reply and clarifications, and your initiative to start responding to my changeset comments from 6 months ago…

Unfortunately, this might come a little bit late. I have introduced recently a vote for the community on how to deal with remote organized editing teams like yours and, without exceptions, everyone wants stricter rules and possibly a ban on mass modifications: https://forum.openstreetmap.org/viewtopic.php?id=75315

import=grabremote tag will be a useful addition for future analysis but it won’t solve any past recurring quality issues alone.

As a next step, our small community will need to come up with clear written rules for organized editing teams e.g.

  • single point of contact: responsibilities, e.g. proactively reviewing changes and responding to changeset comments, incidents
  • scale of edits: how many mappers, how many changesets, what tags can be changed
  • post-event clean up: review previous campaign issues and fix them
  • incidents response: conditions for warning, block, ban, and duration

Until these new written rules are ready, we expect you to suspend your mapping campaigns in Thailand and respect the wishes of the local community.

Reminder: https://wiki.osmfoundation.org/wiki/Organised_Editing_Guidelines