Signaler une donnée erronée

Les données ouvertes canadiennes sont inégales. Une municipalité renomme une rue et l'extraction provinciale rattrape son retard deux trimestres plus tard; une adresse rurale existe sur un plan d'arpentage et dans aucun fichier lisible par machine. Nous publions les lacunes que nous connaissons dans Couverture, et celles que nous ignorons sont la raison d'être de ce point d'accès.

POST /feedback dépose un signalement de correction de données. Il est authentifié comme tous les autres points d'accès et n'est jamais facturé. Nous dire que nos données sont fausses ne doit pas vous coûter un appel.

curl -X POST https://api.unmap.dev/feedback \
  -H "Authorization: Bearer $UNMAP_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "product": "geocoding",
    "category": "incorrect_location",
    "description": "« 17 Ave SW, Calgary » retourne une rue à Edmonton."
  }'

{
  "id": "fb_20260917143055_9f3ab201",
  "status": "new",
  "created_at": "2026-09-17T14:30:55.114Z",
  "context_stored": false
}

Conservez l'id. C'est ce qu'il faut citer si vous nous écrivez plus tard au sujet du signalement.

Un signalement exige une description, un result_id, ou les deux. Un signalement qui n'a ni l'un ni l'autre dit qu'un produit est faux quelque part, ce sur quoi personne ne peut agir, et il est refusé par un 400.

await unmap.feedback.submit({
  product: "geocoding",
  category: "incorrect_location",
  description: "« 17 Ave SW, Calgary » retourne une rue à Edmonton.",
});
 
await unmap.feedback.aboutPlace("um:place:1234", {
  category: "wrong_place_name",
  description: "Inscrit sous son nom de 1968.",
});

Le client ne règle jamais include_context de lui-même. Ne transmettez un context que si la personne qui soumet y a consenti; l'indicateur l'accompagne alors.

Champs

Catégories : incorrect_location, incorrect_address, missing_place, wrong_place_name, wrong_category, bad_route, missing_road_closure, incorrect_road_condition, incorrect_transit_result, other.

La liste des catégories est la nôtre et elle sera légèrement fausse pour votre cas. La description est le champ qui compte, elle est conservée mot pour mot, et other reste toujours disponible.

curl -X POST https://api.unmap.dev/places/um:place:calgary-tower/feedback \
  -H "Authorization: Bearer $UNMAP_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "category": "wrong_place_name", "description": "Inscrit sous son nom de 1968." }'

product et result_id proviennent du chemin. Un corps qui contredit l'URL est remplacé plutôt qu'honoré.

La passerelle caviarde les chaînes de requête dans ses propres journaux. Un point d'accès de signalement qui joindrait discrètement votre requête et vos coordonnées à chaque rapport annulerait cela sous une étiquette plus aimable. Il ne le fait donc pas.

Rien de votre requête n'est conservé à moins que vous n'envoyiez context et que vous ne mettiez include_context à true. L'API refuse context sans cet indicateur plutôt que de l'abandonner en silence : un client qui se croyait en train de joindre une requête apprend qu'il ne l'a pas fait.

{
  "product": "geocoding",
  "category": "incorrect_location",
  "description": "Mauvaise municipalité.",
  "include_context": true,
  "context": { "endpoint": "/geocode/search", "q": "17 Ave SW, Calgary", "limit": 3 }
}

context_stored dans la réponse vous dit ce qui a réellement été conservé.

Si vous construisez votre propre contrôle de signalement par-dessus ceci, posez la question à voix haute et laissez-la désactivée par défaut. Le signalement est une donnée diagnostique volontaire. Ce n'est pas de la télémétrie, et la différence tient entièrement à la décision de la personne qui le soumet.

Tout signalement commence à new. Ensuite :

upstream est un vrai dénouement et non un refus poli. Une bonne part de ce qui est signalé est fidèlement ingéré d'un fichier provincial ou municipal qui est lui-même faux, et la chose honnête à dire est lequel.

Une régression confirmée devient un cas de test permanent partout où c'est possible. C'est la boucle à laquelle tout ceci sert :

signalement → reproduction → correctif → test de non-régression → journal des versions

Limites

200 signalements par compte et par jour. Au-delà, le point d'accès répond 429 avec un Retry-After.

Il n'existe pas de GET /feedback. Vous ne pouvez pas encore relire vos propres signalements, ce qui est une vraie lacune et figure comme telle.