Skip to content

Instantly share code, notes, and snippets.

@govvin
Last active December 25, 2018 22:55
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save govvin/6c8c9df8106c667b6c28823131419d1e to your computer and use it in GitHub Desktop.
Save govvin/6c8c9df8106c667b6c28823131419d1e to your computer and use it in GitHub Desktop.
randomized review of Grab/Global Logic OSM contributions in TH

Grab / GL edits in Thailand

This voluntary review is prompted by discussions in the OpenStreetMap Asia Telegram channel by a recent article published on TechCrunch. My observations are limited to interpretation of available public aerial imagery (Bing, DigitalGlobe, ESRI, Mapbox, Strava), or street-level imagery (via Pic4Carto, if any) -- and an understanding of the limitations of any remote mapping / validation effort.

Review Tools and Processes

(Pseudo)random selection of changesets using this OsmCha filter of GL/Grab edits in Thailand: , not reviewed by any other volunteers of this exercise.

Tools used: JOSM validation, OSM History Viewer, OSM Deep History.

Workflow

  1. Randomly select a changeset from the OsmCha filter
  2. Review what has changed using any of the tools mentioned above.
  3. Review against existing imagery.
  4. Review history of affected elements in the area, if any.
  5. Mark changeset as appropriate. Leave notes in the changesets, especially for those marked as Bad.
  6. Annotate list of changesets reviewed. Add notable remarks, where applicable.

Notes

  • No effort were made to correct any issues or concerns found; to preserve the current state of edits. If any concern is found, the observations to the relevant changets are noted in the table below, for later action.
  • Editors are using a variety of imagery sources, and knowing how offsets between imagery exists, they don't record these offsets (in the Imagery Offset Database), and appears to use multiple unadjusted imagery within the same changeset.

Changeset specific observations

Changeset Mark/Severity Notable observations
64222985 Bad, low Covered two discontinous areas, which ideally could've been split to two. Edits to the west are okay, but edits to the east removed the valid driveway tag, and changed the previously better geometry. The editor misinterpreted the angle of features in the imagery and the perceived space between features.

Checking other imagery could've avoided this. This is typical for beginners and easily addressable with proper on-boarding.
64219875 Good Improved the existing geometry, added a residential road.
64219682 Good "source=premium" seems to refer to DigitalGlobe Premium
64219494 Ok Editor is noted to have deleting existing roads and re-adding the same instead of just improving them - which isn't a good practice. Of course, there are known cases where deleting and adding a road is acceptable, but that isn't even the case here.
64219476 G
64219447 G
64219422 G
64218992 G
64217305 G
63748679 G
63748679 Ok Elements in this changeset could've been improved, in particularly a segment of w99193540 that shows an offset of 4-6m, as highligthed by the red segment here
63743979 Ok Again, why delete and then re-place the same segment?
63743769 Ok Another case of delete and replace (D&R) of certain segments within the changeset. Some segments' offsets could've been improved.
63222048 Ok Major offset errors could've been corrected.
63222388 Ok D&R
63219933 G
63219817 G
63219200 G
63219299 G
63745582 G
63747914 Ok Geometry offset errors could've been improved.
63744136 G
64397067 G
64391678 G Although, w643248396 was subsequently deleted in c64763083, the original editor appears correct, and Mapillary imagery does show what seems like a service road, albeit incorrectly tagged as residential.

w242719186 tagged as scrub, could also have been deleted, as well.
64315740 B New road based on outdated Bing imagery and appears to be temporary, as road and building it serves is no longer visible in newer imagery (ESRI, DG, Mapbox)
64763083 B Is the editor a validator? Changeset appears to be mostly deletions, but from the imagery appear to be valid edits, although many are incorrectly tagged - buy why delete when they may be corrected instead?
64315582 G
64315202 G
64281932 Ok In the same changeset, editor appears to add features using multiple imagery sources - but does not factor offsets between imagery.
64280160 G
64278779 G
64222469 G
64222234 G
64222014 B, low Based on imagery, w30477604 appears residential with a lower section that appears to be an unpaved service road.

A verbal tussle between a local mapper and the Grab editor regarding w30477604 could've been avoided with better comms. The incorrect action here pointed out by the local mapper is that the way should've been split at the point where the road surface has changed (visible in imagery), and tagged differently, instead of merely extending the way. There are other edits in this changeset, but only edits for w30477604 had a minor issue. The local mapper made the correction in changeset 64998866
64220061 G
64217973 G
64217538 G
64217120 G
64216940 Ok Added redundant oneway=yes tags on junction=roundabout ways , which are already implied for all such tags: w200605189, w200605190, w200605197
64216227 G
64197629 Ok Editors should avoid working on huge areas in one changeset - edits in WA, USA and Kedah, MY. Also, described as "editing lanes" but no such lane editing was made in that changeset.
64189091 Ok Another huge changeset covering edits in Thailand and Panama's coastline!
64187103 B Deletion of w283153259, which appears to be a valid feature from the imagery. Other edits in this changeset seems okay.
64186885 Ok Added unnecessary oneway=yes tag on roundabout. Deleted a road segment, then replaced it with a new one.
64185771 B w641104670 doesn't seem like a road. Other edits look okay.
64185021 G
63889963 G
63888811 G
63888724 G
63888462 G
63887733 G
63886770 G
63886665 G
63819169 G
63818171 G
63816783 G
63815061 B,low w637347194 seems better tagged as service
63814868 G Another case where part of a segment was deleted, then later re-added as new segment.
63785350 B, low w637107125 looks like a service road, rather than residential. Other edits look okay.
63782397 G
63781883 G
63781889 G
63760440 G
63760155 G
63760070 G
63759540 G
63758822 G
63758048 G
63756717 G
63755684 G
63755305 G
63755065 G
63754717 G
63752131 G
63751172 G
63750248 G
63748599 G
63747644 G
63746877 Ok Why delete w636724435 and w636724435, only to have them added back later in a newer changeset?
63746922 Ok Another case of certain segments being deleted and replaced.
63746754 Ok Another case of certain segments being deleted and replaced.
63746277 G
63745896 G
63744667 B Road segment classification changed from secondary_link to motorway_link , misintepreting imagery. Eventually corrected in changeset 65684358
63744273 G
63219847 G
63218477 G
63215910 G
63215732 G
63215502 G
63215371 G
63215152 G
63215065 G
63215062 G
63214337 G
63214112 G
63214071 G
63213916 G
63186847 G
65684358 G

Conclusion

The TH OpenStreetMap community is lucky to have many diligent, and prolific contributors who passionately map their favorite neighbourhoods and surrounding areas. I've seen usernames which became familar after a number of changeset validation, simply because I keep seeing the same names again and again. Kudos to these contributors.

Overall, I find no substantive evidence to support the allegation of massive detrimental edits, or systematic errors by the Grab/GL mapping team. They appear isolated, and not at all unusual considering the volume of edits made. Their internal QA team could do better with catching whatever we found here.

A few changesets were marked as bad, but all are low-types. There are also a number I marked as "Ok", just to differentiate them from the "good" ones because I noticed something unusual, or ideally could've been improved on. Those marked "bad" should be addressed as soon as possible, but certainly none are critical or urgent.

Some unusual behaviors were noticed: deleting road segments and re-adding them, redundantly adding oneway=yes to roundabouts, or that their JOSM settings appear some users use a different/edited source strings for the same imagery, instead of what's available by default from JOSM. These are unusual, but not critical or error-causing.

There are a few inconsistencies with imagery interpretation: tagging, use of various imagery and adjusting for offsets. The mappers' training and on-boarding process can improve in these areas, and all other mappers could have refresher/re-orientation.

The Grab/GL team should look into supplementing their imager source with Mapillary/OpenStreetCam imagery collected by the local community. They've been helpful in more than a few instances during this validation effort.

This is not to say that the complaints from the local community are unsound - local knowledge trumps imagery interpretation - feedback from the community should be considered, and investigated closer. Remote mapping, validation and on-the-ground validation plays important roles in the mapping process. Grab/GL can do better with engaging the local community, or communicating better what needs to be validated on-the-ground.

Validating edits from organized editing activities is not the responsibility of the community, and the Grab/GL team (which applies to any other organized editing effort) should be more mindful of edits made by mappers when the imagery shows something else (especially from trusted/prolific contributors) who have the advantage of local knowledge. If in doubt, communicate with the editors.

Version changelog 1 - initial version 2 - typo corrections 3 - formatting corrections

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment