Grab / GlobalLogic India directed editing

Communities ประเทศไทย (Thailand)
1

Hi,

Tom mentioned a bunch of suspicious edits he saw by other mappers.

If I remembered the name right (forgot to note it), then it is one of the Grab editing team. Based on some other comments and blocks received before based in India.

They seem not related to the Grab team trained by mishari, see
https://forum.openstreetmap.org/viewtopic.php?id=63105
https://forum.openstreetmap.org/viewtopic.php?id=62959

and
https://www.openstreetmap.org/user/harrymahar/diary/43671

For reference, here the list of known associated user accounts. I wished we could have a flag to highlight bots and directed edits user-accounts.

In case you observe something unusual, Tom mentioned a strange source for the amount of names, please add comments to the changesets and also add a reference here.


Alekhya5
Harishpuppala
Kolla6
Malka7
Neethu5
Pabbas
Rakesh9
Sajjad1
Tejan7
akhil2
anushalanka
apurva2
ardhavara
damaraju
kawle
marupally
motkar
naik4
neela1
parveen5
poornima1
renuka1
saisokam
srivastav5
stella9
surya8
udaykiran3
vaidha1
zakriya1
2

Here’s the full list of them.

This is their detail on Bangkok Map Enhancement Efforts.

3

They just announced to get active in Chiang Mai:
https://forum.openstreetmap.org/viewtopic.php?id=64196

4

Reposted here as it applies to the Grab project as a whole:

I guess this is the logical thread to carry on any discussion.

5

As a local resident in Bangkok, and a surveying contributor, let’s say I’m not happy with Grab’s editing team.

Original rant: https://forum.openstreetmap.org/viewtopic.php?pid=720788#p720788

As already said, Grab’s “involvement” with OSM is not brought to my attention by the announcements, but by “obvious wrongs” appearing on the area that I’m familiar with.

From their edits alone, this is what I see of Grab’s OSM team (i.e. Indian GlobalLogic company):

  • They are armchair mappers.

  • They are newbies.

  • They are careless.

It seems that their team, comprised of people with no prior experience on OSM, made several (actually: lots of) textbook mistakes in their armchair mapping process; and they tend span their single-changeset edit on a rather large area, which is really non-conductive to audits.

To add insult to the injury, they all use a heavy-duty editing tools (JOSM) to make edits in a very fast pace, faster than any resident/patrolling OSM contributors –as few as we are– could independently audit, verify, and warn them about mistakes.

The lack of experiences (in both OSM and the area) also led them to misjudge the accuracy of imagery data; this greatly exacerbate the scale of problem, and it is not limited to Bangkok area anymore.

This doesn’t even count the accuracy issue inherent to armchair mapping (no matter how “well” they are done); these will be obvious once you look closely at each example.

In the downtown area surrounding Dusit and Phra Nakhon district in Bangkok alone, there are already ~100+ changesets waiting for me to verify after the fact. (Each of changeset is as large as a city block, some larger) Doing in-the-field verification of these are painful, and really non-productive.

Verifying them all will take years. (And guess who bear the cost of these surveys?)

6

Since OSMF Data Working Group insisted that case-by-case evidences be provided, so here we are:

Example A: Samsen 9 drive, Dusit district, Bangkok

The wrongs:

  • Attempting to re-align existing object data to imagery without good reason

  • Breaking of local consistency

  • Overwriting of local contributor’s data

  • Failure to verify changes before saving

  • Attempting to upgrade existing footway without ground verification to back it up

Example B: Suankularb Wittayalai Alumni Association, Dusit district, Bangkok

The wrongs:

  • Attempting to armchair-edit micro-level details from imagery

  • Inattention to local consistency of newly-added data (the new driveway overshot the wall)

  • Lack of ground survey to confirm the edit

Example C: Chakkrawat Ratchawat Temple, Samphanthawong district, Bangkok

The wrongs:

  • Severe mis-retagging of an object (temple → road)

  • Failure to verify result of the edit on the main Mapnik view

This is just the first set of my encounters. And these are just from less than 0.1 percent of their edits; I have spotted many, many, more “oops” attributed to them that I don’t yet to find time to verify, and some are also dangerous for routing. All of these are done without access to heavy-duty anti-vandalism tool.

More examples will follow…

7

After my first three encounters, I started putting #WhatInGrabsNameIsThis hashtag in edit summary whenever I have to revert or fix bad armchair edits done by Grab team.

If you are also doing this, I encourage you to do the same.

Statistics of recent changesets with #WhatInGrabsNameIsThis in edit summary could be viewed on Pascal Neis’ website.

Note: In case you are just pointing out their mistakes, using the hashtag in changeset discussion works too. (So they could be found by more specialized tools)

8

The stream of errors continues…

Example D: Dinso road, east side of Wat Bowonniwet School, Phra Nakhon district, Bangkok

The wrongs:

  • Attempting to armchair-edit micro-level details from imagery

  • Lack of ground survey to confirm the edit

Example E: Petchaburi road, from Thanapoom Tower to Saint Dominic School, Ratchathewi district, Bangkok

The wrongs:

  • Nontrivial violation of “keep straight way straight” in spite of editor software’s ability

  • Nonsensical retagging of building, ruining other contributor’s work

  • Attempt to draw driveway that goes into building, without confirming that with ground survey

  • Addition of excessive segments in road turn; signifies lack of ground survey experience

  • Improper handling of JOSM validatation error; signifies lack of training

Example F: Phradabos foundation, Samsen road, Dusit district, Bangkok

The wrongs:

  • Attempting to armchair-edit micro-level details from imagery

  • Lack of ground survey to confirm the tag

  • Lack of awareness about existing OSM data in the area

Example G: Mahajesadabodin Royal Pavillion park, Phra Nakhon district, Bangkok

The wrongs:

  • Attempting to armchair-edit micro-level details from imagery

  • Lack of ground survey to confirm the edit

Example H: Phetchaburi road, across Palladium mall, Ratchathewi district, Bangkok

The wrongs:

  • Addition of excessive segments in road turn; signifies the lack of ground survey experience

  • Addition of navigator’s false-turns hazard; signifies the lack of knowledge about how OSM data is used

  • Addition of dangling node; signifies failure to verify changes before saving

Note that false-turns hazard, depending on the circumstance and satellite unit used, can turn a plesant 60 km/h green wave cruising at night into a deadly accident.

9

And I will kindly let you know that, while they “looked” cooperative in their response; it doesn’t do much good, because:

  • Too many damages had been done.

  • Faults are found after-the-fact via independent ground verification by me.

  • The firm does not seem to have a proactive policy to prevent or fix their own errors, and…

  • They completely lacked proper training necessary to fix the problem themselves; or to make a clean, usable map in the first place.

  • They don’t use OSM, as seen from their unawareness regarding main Mapnik render.

  • Their edit lacks ground truth.

Dealing with their edits in a “proper OSM way” (audit, survey, revert, fix, comment) is also actually a huge time sink in my solo mapping expedition, which is billable to no one. I did these anyway as an effort to uncover incompetence and lack of training of Grab’s contractors that would be otherwise be swept under the rug.

The encounters are really eye-opening, and they completely flipped my opinion on armchair mapping and imports from mildly positive to overwhelmingly negative. And yes, “living there” matters.

If there are other companies planing to “involve” with OSM like this, you can count that I will be there to object it.

Revert, Block, Ban.

10

And don’t anyone think it’s too much of a coincidence that some “unnamed” outsource company in India recently mass-applied their employees to be OSMF members?

Disgusting is an understatement.

Where is Conflict of Interest investigation when we need it?

11

The OSMF Membership Working Group noticed this too, and we released our report on this matter today:

https://openstreetmap.lu/MWGGlobalLogicReport20181226.pdf

Edit: We are reasonably confident that the 100 signups were not from the Grab team at Global Logic.

12

I’ve created an overpass query so that you can see the extent of the edits made by the Grab / Global Logic Team in case anybody’s interested. I’ve imported it into JOSM and have found a whole bunch of errors already, enjoy!

https://gist.github.com/mishari/b76a5ec16110352d1ab774d761c9134f

13

Unfortunately, your query takes quite some time. I posted an improved version in your github gist.

14

I noted at our meeting with Grab, was that they clearly reiterated that Global logic had stopped playing with the map.
Of course the problem is now obvious … we keep coming across all those “optimistic road connections” by chance, and on two occasions, I have written to the GL mapper involved (via a changeset comment), only to get no response.
As with the Facebook employees, I expect they have all have moved onto other things.

So, as they are not going to fix their mess, DWG - how difficult will it be to revert all their work in one fell swoop ?

Edit - I just had a look at the Overpass query, and it essentially shows any way they have got their grubby hands on. Most might have just been the moving of a node or a simple realignment of existing way.
As our (or at least my) biggest gripe is the creation of roads that are not there… can the Overpass query be modified to just shows ways existing as Version 1 that were added by GL ? If not, maybe those roads lacking a source as they were too lazy to show us what aerial pic they took the inspiration to dream up that road from ! :smiley:

I’ll start cleaning up CM, but Mishari, you had better make a start on BKK.

15

Yes, that’s possible:

16

Hello from DWG! If there’s consensus from the local community, we can revert anything, and block the organised editing teams that are creating bad changesets.

I understand that there were local meetings with the companies, so it would be nice if we could discuss here what happened at the meeting and what the community would like to happen.

When consensus is reach and you’d like to make a formal request, please email us at data@osmfoundation.org and we’ll take it from there.

17

Here are some notes that I took from the meeting, any mistakes are mine alone:

–begin note–
Present from Grab were Ajay, Pimlada, Adrian (sorry I didn’t get the name of the others)
OSM Side: jrcarlsen, AlaskaDave, Russ McD and Myself

The overall atmosphere of the meeting was good, Ajay was quite sincere about working with the community and displayed good faith.

Ajay said if we need any high res imagery he’s happy to coordinate with the imagery providers and get it for us.
Grab has also started collecting imagery for Mapillary The idea is both Grab and the community will have a single source of truth.

We agreed on the principle “If you don’t see it, don’t map it” this should eliminate many of the errors. Grab has agreed to go back and rectify problematic edits.

Grab has also agreed to put their Quality Control Standard Operating Procedure document on the Wiki (it should be up soon)

– end note–

I would like to add that the document should give us insights into what is causing the quality issues. If we can work on a modified document that brings the quality up to community standards, there’s no reason why we can’t have a successful collaboration.

Best Regards
Mishari

18

Grab has posted their Quality Standard Operating Procedure up at the wiki. The community’s comments and help in plugging the gap to make sure that the quality remains high are much appreciated.

19

Yes, but the document, apart from being written in a grammatically confusing way, does not really address the main problems we have seen…
GL added many roads that clearly did not exist on the ground. They also chose to change the status of roads from what local mappers had already entered. Clearly the validation did not pick that up.
I also see in the Techcrunch article https://techcrunch.com/2018/12/19/grab-maps-osm-thailand-southeast-asia/ they claim 0.03% were wrong. This is misleading as they are basing this number on what local mappers have stumbled across and taken the time to report via a changeset comment. There were hundreds of other errors we simply corrected without reporting due to the time consuming process of writing a changeset comment, and the the fact that these comments are now going unanswered.
Im positive there are hundreds of more “mistakes” yet to be found in Thailand, and while Grab appear to display a willingness to fix these, I have yet to see actual action.

Moving forward, I would want to see the Quality SOP include some concrete rules, such as adding an source (or import tag) to easily identify the work of commercial mappers, and instructions not to change things such as road status & Geometry. I also believe they should be adding fixme tags where they are unsure adding a significant new road actually exists on the ground. Im sure there will be many more rules we can ask for.

So while I appreciate Stereo’s response from the DWG, we can’t agree locally on a total revert, so no point going down that route. There are only two options, one being we fix ourselves, and the other being that Grab instruct GL to go over every edit and delete all connecting roads and status changes that they made. After that, using the recent Grab Mapillary images, they can re-add only those roads where a proven connection can be made.

20

Exactly, that’s our normal way of handling errors: just fix them when we detect them.
On the other hand, that makes a calculation of an error rate impossible: not every change to some mapped features implies an error.
I prefer to silently correct - I may report in some cases, but overall that’s far to much effort: during a mapping session, an error is corrected in 3 seconds, a report written in 2 minutes.