Warning: New GrabOSM campaign

Redirecting GrabOSM here to discuss mapping updates and how to prevent further issues relating to their new campaign:


I have informed Grab a few months ago to contact us through the forum and review the note companies that @stephankn has added at the top of the Thailand wiki page:

Grab stopped mapping for a few months, didn’t respond to my request, but started this week a new campaign, so I have asked them to join the discussion here asap before doing any further damage.

Like Facebook in the past, Grab recent mapping campaigns brought a lot of frustrations among the local mapper community, I have personally literally spent dozens if not hundreds of hours fixing minor road classifications, exaggerated curves… but only managed to correct small geographical areas.

First, it’s important to know that most Grab mappers are sitting in India (Bangalore) and doing changes only with imagery in neighboring countries for which they have no local knowledge.

Past issues have been:

  • conflicting minor road classification: even after we improved the wiki to address this issue, I learned directly from Grab mappers that they were asked to continue tagging any road with visible rooftops as residential…
  • no consistency or internal quality check: I found mappers tagging the exact same type of road as service, unclassified, or residential even next to each other.
  • overriding existing classifications: without local knowledge Grab mappers literally went through existing correctly tagged service roads (universities, gov facilities, parks) and changed them to residential (because of rooftops)…
  • taking control of maps: at some point, Grab mappers were assigned areas to watch and were literally reverting local mappers changes (e.g. reverting their classification) within hours
  • long roads with unnecessary and exaggerated curves: in areas with little coverage, Grab mappers are connecting highways to houses with a single road segment even if the way involved 5 different roads intersection with hard turns and a private driveway. The worst part: the road will be curved at straight intersections with dozens of nodes, so you end up with a curved zig zag that will need to eventually split into multiple segments, the curves make it too much work to fix so I usually delete these when I find them.

In this new Grab campaign, I see so far mostly minor changes like adding dead-end (noexit=yes) or fixing not properly connected road segments for routing and I really hope these are based on feedback from local knowledge (e.g. Grab drivers).

My main requests for GrabOSM to prevent further damage would be to:

  • tag new roads based strictly on the Thailand wiki minor road classification
  • NOT change any classification to existing roads without local knowledge (leave this to local mappers)
  • quality control your mappers’ changes
  • combine mappers changes in fewer changesets so it’s easier to review and revert in case of conflicts
  • stop curving roads at visible straight intersections

@ Other local mappers: especially those who had to deal with Facebook campaigns, please kindly give your suggestions or advice on how to move forward.

@ GRABOSM: have any of these previous issues been addressed internally and what is your goal for your next campaign(s) ?

OMG! Here we go again.

This is the main problem with allowing anybody and everybody to add and edit OSM data. Those clowns from Grab aren’t going to pay attention to the Wiki or to our guidelines. They’re getting paid to add data. Period.

At least, one of them notified me about his crappy change:
The residential instead of unclassifiedtagging is an old issue of OSM Thailand.

Hello cmoffroad,

Thank you and we appreciate for sharing your concerns with us and we would like to give clarification for all your points below. Firstly, we apologize for missing out on adding the query on the forum for TH Campings, our understanding was that once we start a new project, we would start a thread on the forum, but rest assured, we will ensure that all the queries and project updates in Thailand are shared through the forum along with GitHub going forward.

And also note that the Grab Thailand Campaign is not a new one, in fact, we have been doing campaigns here since 2020. Refer https://github.com/GRABOSM/Grab-Data/issues/49. And Yes, recently we have halted the Thailand Campaign for a couple of months as we have some other cities that were prioritized in other SEA countries.

  • Conflicting minor road classification and no consistency or internal quality check

Residential: We are tagging the highway as residential for the roads serve as access to housing, without the function of connecting settlements.

  • Often lined with housing.
  • Roads within the housing/residential areas.
  • Used by local people within the residential areas.
  • Less speeds compared to unclassified.
  • Can be a dead end
  • Can also carry traffic between different locations, although they should still be relatively less-traveled roads.

We are tagging a highway as service when a highway is generally for access to a building, serving a group of buildings at the same area <30mts, service station, beach, campsite, industrial estate, business park, etc. And also commonly used for access to parking, driveways, and alleys.

Overriding existing classifications and taking control of maps

The Grab map data team always respects the community/local mapper edits and retains the edits when mentioned as local knowledge. It is often a judgment call on some of the instances that might be tricky, one thing that would help us would be if the community could mention local knowledge in changeset comments, it’ll help us identify the local mapper edits vs something that is incorrectly tagged by a mapper.

Long roads with unnecessary and exaggerated curves

For the exaggerated curves issue, we have already had a healthy discussion in the past. And we started following to cut down the smooth curves at turns in TH. refer: https://github.com/GRABOSM/Grab-Data/issues/49#issuecomment-728220652, please let us know if you have any concerns on the same.

Thank you for sharing your suggestions and we have added them to our mapping practices in Thailand. Thank You again and happy mappy new year!

Hi jinalfoflia, I appreciate your answer and feedback but some of your points will need to be clarified further:

As far as I am concerned, the new note to the companies that were added in the Thailand wiki applies to new and current campaigns.
Your campaign may have started in 2020 but it is still active today and referenced by your mappers in 2022. You are not exempt from any new community policies.

In the referred comment, you agreed to cut down on curves at turns in November 2020. Yet in 2021, I have seen hundreds of these issues popping up everywhere. Whether it’s an internal quality control or a policy issue, the problem remains.

Absolutely not. Please consider that only corporations like yours and non-profit organizations use remote mappers in Thailand (directly or through maproulette.org). Most mappers in Thailand are local mappers doing changes based on local knowledge and priority should be given to them.

Of course, there will be mistakes done by local mappers, and these will be resolved in time by others in the local community.
Without local knowledge, your remote mappers should simply not be allowed to alter locals’ contributions. Period.

In fact, the few times you reverted some of my own changes ( and within hours ), my changesets were marked as “ground survey”, tags added included “source=GPS” and even a GPX trace was listed in the sources, this clearly shows you did not care and you cannot be simply relied on to alter any existing tags.

Your own policy above has worked fine in urban areas, but it has been a complete disaster in rural areas.

Under the pretext of visible “rooftops”, your mappers continuously added residential roads everywhere outside of settlements. Most of these “roads” are actually agricultural tracks leading to farms, and many are unpaved, 4WD only.
Many visible “rooftops” are often huts used for rest, and even if some villagers choose to live permanently in their farming estate, it does not change the main purpose of the road. Maps in these areas became towns redirecting traffic through unusable agricultural tracks.

I believe you misunderstood the overall message. The local community came up with minor road classification definitions so that everyone including your organization should use them. These are not mere suggestions as you imply, but a standard to reach higher quality and to prevent conflicts between mappers.

If you have any concerns about these definitions, the community will be happy to revisit them if there is a valid use-case from your side:

PS: I apologize for the tone of my message but you have to understand I have been in contact with you for about 1 year and I have seen not seen any improvements, so my patience is simply running out. I have invested a lot of effort in improving OSM in my region and will not accept to go through these conflicts again. Happy new year.

To begin, I’d like to express my appreciation for the large corporation’s mapping initiative, as it is beneficial to countries with a low number of active local mappers, such as Thailand. On the other hand, if the quality control is poor, it will generate confusion since their mapping style will quickly spread and dominate the region, rather than local standards.

Also, I applaud Grab’s work because it makes OSM data in Thailand more valuable, particularly for mapping unmapped roads. Apart from what cmoffroad has said, my main worry is:

  1. While your guidelines for residential and service roads appear to be similar to those of our community, I’d want to emphasize that you should follow existing local guidelines rather than making your own, even if they are equivalent.
  2. Your number of <30mts for the service road may be challenged. There are several private roads that are longer than 30mts and should be tagged as service. I understand that it can be difficult to identify whether a road is private or public from satellite, which leads to difficult decisions between residential and service roads. By the way, it can be predicted based on the number of houses served by that road. But if you’re mapping a new road, it’s okay to guess, even if it’s inaccurate, because it’s better than not mapping it at all.
  3. I’m glad to see your effort on unmapped roads, even if it is occasionally incorrectly tagged, but when modifying existing roads, you should proceed with caution.

Thank you and happy new year too.

What about using import yes as did Facebook?
A diligent map maker can show such roads different then.

Great idea from Bernhard. It would be fair instead that @GRABOSM:

  • adds an additional tag e.g. import=yes to any new roads additions (or a custom tag of your choice e.g. grabremote=yes)
  • refrain from changing any road classification that doesn’t have (anymore) the import=yes tag.

This way the local community will be able to quickly identify roads that have been added by organizations’ remote mappers, local mappers can then correct their classification (if needed) and the extra import=yes tag can be removed after verification.

Does anyone have a better idea?

Dear GRAB,

the organized editing guidelines is not something new. We placed the note on the wiki page to make it even obvious to the most ignorant. It simply emphasizes that there are guidelines.

And as others have already mentioned: We wand high quality edits. Those bad edits harm OSM. I have a tendency top use Google Maps in favor of OSM when driving unknown areas, as route guiding on OSM data too frequently leads to unsuitable roads. This is a direct effect of the aim to classify each and every bit of way which appears on aerial imagery.

This might be good bor some benchmark statistics, but it harms the overall quality.

The points of cmoffroad are very valid. Can you please go a bit into detail on how you plan to prevent such issues from happening in the future? currently you just stated that you follow rules and everything is fine from your perspective.

Obviously this estimation of your mapping quality is not in line with the estimation of the community.

We are all aiming to get the best data in OSM possible. This strive for quality is what was leading our mappers to get in touch with you. The simpler approach would be to ask DWG to block and revert your edits in Thailand.

So please work together with us to improve the quality of your edits.

What quality assurance procedures do you currently have in place? What further optimizations do you plan to implement?
When looking at your recent edits: Have you checked about Objects where your edit was reverted and analyzed what was leading to this? Did you use such feedback to optimize your internal processes? Did this lead to some additional training for your editors?
Have you added a review process to double check such kind of edits? Especially those where the exact tagging is not 100% clear?

The community appreciates companies improving the data. But notice the word “improving”. It is not about selling services to do as many data edits as possible. The resulting data after your edits has to be substantially better than before.

Thanks for your understanding and looking forward to get some details on how you plan to improve the mapping quality.


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.


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:
(south-east of bridge
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=amazon AI


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.


facebook AI=yes




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,

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:


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).