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…
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.
@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.