Lieux

curl "https://api.unmap.dev/places/nearby?category=boulangerie&near=-114.07,51.04&key=$UNMAP_KEY"

/geocode/nearby est inchangé et continue de fonctionner. Lieux est une présentation de premier plan des enregistrements de points d'intérêt que le corpus de géocodage porte déjà, non un second entrepôt.

Ce que /places/search ajoute à /geocode/search

Il retourne des lieux. /geocode/search trouve ce qui correspond le mieux à votre requête, ce qui pour « Calgary » est la ville elle-même : la bonne réponse pour un géocodeur, la mauvaise quand vous cherchiez un endroit où aller.

Le géocodeur n'avait aucune recherche par identifiant. Si vous conserviez un résultat, vous n'aviez aucun moyen de le rafraîchir. Maintenant si :

curl "https://api.unmap.dev/places/um:place:1234?key=$UNMAP_KEY"

Un identifiant malformé donne un 404, pas un 400. De votre côté, « ce lieu n'existe pas » et « ceci n'est pas un identifiant bien formé » sont la même réponse, et les distinguer révélerait notre type de stockage dans le contrat. L'identifiant est opaque : une reconstruction du corpus peut le renuméroter, n'analysez donc pas sa fin.

import { Unmap } from "@unmap/sdk";
const unmap = new Unmap({ key: process.env.UNMAP_KEY! });
 
const { data, meta } = await unmap.places.nearby("boulangerie", { near: [-73.57, 45.5] });
await unmap.places.search("calgary tower");
await unmap.places.get("um:place:1234");

meta est retourné plutôt qu'escamoté : sans attribution, vous ne pouvez pas respecter la licence sous laquelle les données vous parviennent. Places est aussi exporté par @unmap/geocoding, si vous le voulez sans le reste du SDK.

Les champs que nous n'avons pas

La réponse porte un identifiant, des noms dans chaque langue du corpus, une catégorie, des coordonnées et une adresse. Elle ne porte pas phone, website, opening_hours, accessibility, operator ni un sac d'attributs structuré.

Ces champs sont absents de la réponse, non présents et nuls. La différence est délibérée :

• "phone": null est une affirmation sur le lieu, et généralement fausse.
• Une clé absente est une affirmation sur notre couverture, et elle est vraie.

Les chargeurs ne les extraient pas aujourd'hui. Les remplir exige du travail sur les chargeurs et une reconstruction complète du corpus. Couverture dit la même chose.

{
  "data": [
    {
      "id": "um:place:1234",
      "source_id": "1234",
      "name": "RBC Royal Bank",
      "names": { "en": "RBC Royal Bank", "fr": "Banque Royale" },
      "category": "finance.bank",
      "category_group": "finance",
      "coordinates": [-114.0676, 51.0447],
      "address": { "housenumber": "339", "street": "8 Avenue SW", "city": "Calgary", "region": "AB" },
      "distance": 313,
      "source": "places.osm-poi"
    }
  ],
  "meta": { "attribution": "(c) OpenStreetMap contributors", "status": "current" }
}

distance n'apparaît que sur /places/nearby. Les parties d'adresse absentes sont omises pour la même raison que les champs absents plus haut.

Catégories

La même taxonomie de 89 catégories qu'utilise /geocode/nearby, avec les alias anglais et français résolus à la passerelle : ?category=boulangerie fonctionne depuis un simple curl. Voir Géocodage pour le tableau complet.

Les bornes de recharge sont une catégorie de Lieux, non une API distincte :

curl "https://api.unmap.dev/places/nearby?category=ev+charger&near=-114.07,51.05&key=$UNMAP_KEY"

transport.charging_station est l'identifiant canonique; ev charger et charging station sont des alias.

La couverture est mince hors des villes, et nous l'avons mesurée plutôt que devinée. Le 2026-09-17, dans un rayon de 25 km autour d'un point du centre-ville : les grandes villes ont atteint le plafond de 50 résultats; Halifax en a retourné 27; le long de la Transcanadienne, Banff 16, Swift Current 3, Kenora 2; Whitehorse 2; Yellowknife et Iqaluit zéro.

L'absence de résultat à Yellowknife relève plus probablement d'un enregistrement manquant que d'une borne manquante, et ce sera la première chose vérifiée contre un inventaire faisant autorité. Le zéro d'Iqaluit est peut-être exact : la ville est hors du réseau routier.

Aucun réseau, type de connecteur, puissance, nombre de bornes, accès ni état. Même raison que les champs ci-dessus : le corpus n'a pas de colonnes pour cela, ils sont donc absents plutôt que nuls.

Aucun inventaire canadien faisant autorité ne se trouve derrière ceci. Le localisateur de RNCan n'est pas publié comme jeu de données sur open.canada.ca, et les jeux de données fédéraux de projets financés listent des projets subventionnés plutôt que des bornes existantes : ils ne servent donc délibérément pas de substitut.

Lacunes connues

• Aucune déduplication entre sources. Le corpus fusionne les localités, pas les commerces. Une chaîne présente dans deux sources peut apparaître deux fois, et une identité de lieu persistante qui y survivrait n'est pas construite.
• La couverture est celle d'OpenStreetMap. Dense en ville, mince en milieu rural, et variable d'une rue à l'autre plutôt que selon une règle publiée.
• /places/{id} exige un conteneur de géocodage à jour. Face à un conteneur plus ancien, il répond 404 et le corps indique que la route peut précéder le déploiement, plutôt que de prétendre que le lieu n'existe pas.

Vous avez trouvé une erreur ? Signalez-la : POST /places/{id}/feedback accepte un signalement portant sur un seul lieu.