I wanted to share how anyone can contribute to suspicious reasons in OSMCha. Recent events have only highlighted that we can tackle the problem of validation by working together and not by isolated efforts.

Wille is working on a new version of this process that would make it easier to flag features in OSMCha but I wanted to document this current way. When the new version lands in a few weeks time, I will document that process publicly too.

What do we need

• a geojson of a OSM feature with metadata tags
• a suspicious reason
• a OSMCHA production token

---

#### 1. Geojson of OSM Feature

At Mapbox, we use the standard geojson schema as per http://geojson.org/. This is the reason why, OSMCHA was created to expect a geojson as an input when we want to post a suspicious reason. Please see the example geojson feature below.

Example Geojson feature with suspicious reason added in properties

{ "type": "Feature", "id": "relation!6517677!3", "properties": { "osm:type": "relation", "osm:id": 6517677, "osm:version": 3, "osm:changeset": 61091946, "osm:timestamp": 1532618174000, "osm:uid": 3769434, "osm:user": "manoharuss", "suspicions": [ { "reason": "Test", "is_visible": true } ] }, "geometry": { "type": "MultiPolygon", "coordinates": [ [ [ [ -93.0056853, 44.9494124 ], [ -93.00572, 44.9494125 ], [ -93.0057205, 44.9493367 ], [ -93.0059132, 44.9493373 ], [ -93.0059135, 44.9492833 ], [ -93.0060122, 44.9492836 ], [ -93.0060123, 44.9492746 ], [ -93.0061143, 44.9492749 ], [ -93.0061143, 44.9492634 ], [ -93.0062995, 44.949264 ], [ -93.0062998, 44.949214 ], [ -93.0064018, 44.9492143 ], [ -93.006402, 44.9491715 ], [ -93.0056853, 44.9494124 ] ] ] ] } }

Pain points

• Currently, OSMCHA expects all the feature metadata tags and full geojson notation including geometry even though all we want is to post are featureId, feature version and suspicious reason. This will change in v2. V2 may also introduce a way to send in an extra instruction. Example: Profanity detectors can send a note mentioning which word was detected profane.

2. Suspicion reason

This can be any name that we can choose. From mapbox, we have decided that, we will have detections named similar to Mapbox: *detection type* apart from the reasons that we already have from osm-compare. When we post to OSMCha, the suspicious reason should be added into the feature properties.

{ ..., "suspicions": [ { "reason": "Test", "is_visible": true } ] }

Note: is_visible must be true, other wise the reason will not be visible in OSMCHA publicly

3. OSMCHA production token

Once you login into OSMCHA, a new production token is automatically generated for your account. You can usually snoop on any API request in networks panel in your browser, to see your token under the request headers.

Entire selected part in the above image is used for authorization.

---

POST to OSMCHA API

With these 3 resources, we can do a POST request to OSMCHA API and it should show up on OSMCHA instantly.You can use this node js snippet to post to OSMCha.

This is my changeset I tested this script on 61091946. I have greyed out my token code, but it should work as is, if you test with your own production token.

---

We are aware that there is currently a lot of noise in OSMCha reasons and we are hoping to clean those up soon from our end. If you are going to have a service continuously running that posts suspicious reasons, please let Wille know.

Thanks :)