France · Auvergne-Rhône-AlpesValence
retenu
lieu habité · préfecture départementale
API
Intégrateur GeoNames API : relier villes, codes et fuseaux à votre SI
GeoNames référence des toponymes, pays, subdivisions, codes postaux, coordonnées et fuseaux via de nombreux webservices. Dawap transforme ces réponses en objets métier : identifiant accepté, granularité, langue, provenance, qualité, crédits consommés, cache, attribution et solution de reprise.
APIs, données et infrastructures que nos projets savent connecter
Du besoin métier au run mesurable
01
Contrat
versionné
02
Sécurité
explicite
03
Reprise
testée
04
Supervision
actionnable
Réponse immédiate
GeoNames doit transformer un lieu ambigu en référence explicable.
Dawap relie searchJSON, get, hierarchy ou timezone à une identité métier stable. GeoNames localise surtout des lieux et référentiels ; il ne garantit pas seul une adresse de livraison. Aucun cas client GeoNames nommé n’est publié à ce jour.
- Choisir le webservice précis selon la question : chercher un toponyme, relire un identifiant, rattacher un point ou déterminer un fuseau.
- Distinguer countryBias qui réordonne les résultats de country ou d’une bounding box qui restreignent la recherche.
- Dimensionner crédits, cache, offre gratuite ou premium et reprise avant de partager un username entre plusieurs parcours.
Résoudre avant de partager
Un nom de lieu n’est pas encore une identité.
L’atelier de rapprochement compare les candidats, valide pays, type et hiérarchie, puis publie une clé interne avec le contexte GeoNames utile. Le libellé affiché peut changer sans casser CRM, BI ou support.
Simulation searchJSONRésoudre « Valence »
3 candidats
q=Valencelang=frcountryBias=FRLe biais ne filtre pas
Espagne · Comunitat ValencianaValència
refus pays
lieu habité · autre pays
France · entrée homonymeValence
refus type
type et hiérarchie non conformes
Le candidat est choisi par contrat. Le rang seul ne publie jamais une dimension géographique.
Golden recordDimension géographique
simulation · GEO-0042
Identité métierGEO-0042clé partagée CRM · ERP · BI
geonameId externe29•••••snapshot et date conservés
- 01PaysFrance
- 02RégionAuvergne-Rhône-Alpes
- 03DépartementDrôme
- 04LieuValence
Frontière de précisionUn point postal reste un centroïde.Il enrichit le référentiel ; il ne valide pas une adresse de livraison.
Quand un nom devient une dimension SI
Trois raccourcis rendent un référentiel GeoNames fragile.
Le premier résultat peut sembler plausible alors que le biais n’a rien filtré, que le point postal n’est qu’un centroïde ou que la limite de crédits se fait passer pour une absence de lieu.
01
Homonymes
countryBias est pris pour une contrainte de pays
Pays, feature class, feature code et hiérarchie doivent confirmer le candidat ; le biais ne fait que le favoriser.
02
Précision
Un centroïde postal devient une adresse livrable
Couverture, granularité et validateur aval doivent empêcher une coordonnée d’enrichissement de devenir une fausse preuve.
03
Crédits
Une limite GeoNames ressemble à un non-résultat
Status, compteur, consommateur, cache et fallback doivent distinguer lieu absent, quota atteint et service indisponible.
Architecture GeoNames
Un geonameId ne suffit pas : le SI doit aussi savoir ce que le lieu représente
GeoNames agrège des toponymes et expose plusieurs familles de services. La même chaîne peut désigner une ville, une subdivision, un site ou un relief ; pays, feature class, feature code, langue et hiérarchie rendent le rapprochement défendable.
Search et get
Rechercher avec searchJSON, borner pays et types, paginer, puis relire un résultat accepté via get et son geonameId.
Noms et langues
Distinguer name localisé de toponymName, conserver la langue demandée et ne jamais rapprocher sur le seul libellé affiché.
Classes et hiérarchies
Utiliser featureClass, featureCode, children et hierarchy sans supposer qu’une relation administrative vaut une zone métier.
Codes postaux
Contrôler pays, couverture et niveau de précision : hors premier résultat américain, la documentation décrit les coordonnées comme des centroïdes.
Fuseaux horaires
Conserver timezoneId pour appliquer les règles de changement d’heure ; gmtOffset et dstOffset sont documentés comme dépréciés.
Crédits et erreurs
Centraliser username, éventuel token premium, consommation, plafonds et status GeoNames, y compris limite dépassée ou service surchargé.
Méthode
On commence par les lignes que vos équipes corrigent déjà à la main
Un échantillon réel révèle les homonymes, graphies, codes et granularités qui comptent. Le premier lot prouve ensuite le taux de match, les refus utiles et le coût d’exploitation avant d’étendre pays ou consommateurs.
Choisir la dimension
Toponyme, subdivision, code postal, proximité ou fuseau avec sa granularité.
Résoudre l’identité
Candidats, pays, feature, hiérarchie, geonameId et clé interne durable.
Qualifier la précision
Nom localisé, centroïde, date de lecture et usage autorisé par consommateur.
Protéger la continuité
Crédits, status, cache, dump, fallback et rapport de non-match testés.
Premier lot GeoNames
Fiabiliser une dimension GeoNames avant de la partager dans le SI.
Nous choisissons un flux — ville CRM, code postal ou fuseau support — puis mesurons ambiguïtés, couverture et crédits sur les données qui circulent réellement.
1 dimension métier
1 jeu d’homonymes
1 reprise chiffrée
Décisions de sortie
Champ & usage Endpoint, paramètres, granularité, consommateurs et propriétaire du référentiel.
Qualité & ambiguïté Homonymes, langues, fautes, subdivisions, frontières et codes incomplets.
Crédits & cache Coût par service, plafonds, cache admissible, offre et criticité des flux.
Identité & reprise Clé interne, geonameId, snapshot, attribution, status et non-match.
Recette GeoNames
Trois contre-tests propres à GeoNames
La recette cible les erreurs typiques du référentiel : un biais de pays traité comme un filtre, un centroïde postal pris pour une adresse et un code de limite ignoré parce que la réponse HTTP est lisible.
countryBias remonte un pays sans exclure les homonymes étrangers
Une recherche de ville utilise countryBias=FR et le premier résultat paraît français. Ce paramètre favorise le pays ; il ne remplace ni country=FR, ni une bounding box, ni la vérification de featureClass, featureCode et hiérarchie.
- Entrée
- q, name ou name_equals, countryBias, country, bbox, lang, fuzzy, ordre, name, toponymName, geonameId, featureClass et featureCode.
- Sortie
- Contrat de recherche qui sépare biais, filtre dur, libellé localisé et identifiant accepté selon le parcours.
- Décision
- N’écrire le lieu qu’après validation du pays, du type et de la hiérarchie ; utiliser un filtre dur quand le périmètre l’exige.
Le point d’un code postal ne localise pas une adresse de livraison
postalCodeSearch renvoie une coordonnée exploitable sur la carte. La documentation précise que les résultats postaux hors premier ZIP américain reposent sur des centroïdes, avec en plus une couverture réduite dans certains pays comme le Canada.
- Entrée
- Pays, service appelé, couverture postalCodeCountryInfo, code complet ou partiel, placename, coordonnées, précision attendue et validateur postal aval.
- Sortie
- Statut postal explicite — couvert, partiel, centroïde, non trouvé ou validation externe requise — sans fabriquer une précision adresse.
- Décision
- Utiliser le point pour enrichir ou rapprocher ; ne jamais en déduire seul qu’un colis peut être livré à cette coordonnée.
Un username partagé atteint sa limite et tous les flux semblent sans résultat
La gratuité actuelle porte 10 000 crédits par jour et 1 000 par heure par application ; tous les services ne coûtent pas un crédit. GeoNames renvoie des status distincts pour absence, autorisation, limite horaire ou journalière et surcharge.
- Entrée
- Appels par endpoint, coût unitaire, username, consommateurs, cache, pics horaires, codes 10 à 27 utiles, retry, offre gratuite ou premium et dump disponible.
- Sortie
- Budget de crédits par parcours, circuit breaker, cache, tableau de bord des status et mode dégradé par criticité.
- Décision
- Ne pas traduire une limite en “lieu inconnu” ; protéger les parcours critiques et choisir premium, dump local ou autre reprise selon le SLA.
Maillage API
Poursuivre dans le bon univers API
Ces liens permettent de repartir vers la page principale ou vers les univers proches quand le besoin dépasse le seul connecteur.
Avis & exigence projet
Ce que l’on sécurise avec GeoNames
5/5★★★★★Avis clients Dawap
“
Identifiant, nom, langue, pays, type, hiérarchie et décision restent liés.
“
Toponyme, centroïde postal, subdivision, fuseau et adresse ne sont jamais confondus.
“
Crédits, cache, status, taux de match, anomalies, attribution et reprise sont observés.
Attractivité-locale.fr transforme un portail de collectivité en point d’entrée vers les entreprises, leurs offres d’emploi et leur carte OpenStreetMap. Dawap a relié le référentiel géographique de l’État, un back-office multi-rôles et treize routes API de lecture, sans confondre données territoriales et données d’entreprise.
GeoNames structure toponymes, pays, codes postaux, hiérarchies, timezones et lieux proches, mais son intégration demande plus qu'un appel REST. La méthode cadre username, crédits, searchJSON, geonameId, cache, licences, limites, support, retour arrière et modèle interne pour CRM, ERP, PIM et datawarehouse.
Une API cartographie et géoloc fiable doit arbitrer entre géocodage, ETA, cache, quotas et fallback, sinon la promesse client se dégrade vite. Cette synthèse met l'accent sur le vrai point de contrôle : garder la précision, la source et le coût sous surveillance avant de promettre un itinéraire ou une zone pour chaque flux.
Questions d’achat
Questions fréquentes sur l’intégration GeoNames API
Questions fréquentes sur GeoNames API, searchJSON, geonameId, codes postaux, hiérarchies, timezoneId, crédits, erreurs, cache et attribution.
01GeoNames remplace-t-il un géocodeur d’adresses ?
Non, pas dans tous les pays ni pour toutes les précisions. GeoNames excelle sur les toponymes, pays, subdivisions, codes postaux, proximité et fuseaux. Une adresse de livraison peut nécessiter BAN, Nominatim, Pelias ou un fournisseur postal.
02Quel identifiant GeoNames faut-il conserver ?
Le geonameId relit une feature via get et évite une jointure sur le seul nom. On conserve aussi identité interne, nom localisé, toponymName, pays, codes administratifs, featureClass, featureCode, coordonnées et date de lecture.
03countryBias limite-t-il searchJSON à un pays ?
Non. countryBias favorise les résultats du pays. Pour les exclure réellement, on utilise country, continentCode, codes administratifs ou bounding box selon le besoin, puis on contrôle le résultat accepté.
04Peut-on utiliser une coordonnée de code postal pour livrer ?
Pas comme preuve d’adresse. GeoNames décrit généralement ces coordonnées comme des centroïdes et certaines couvertures sont partielles. Elles servent à rapprocher ou enrichir avant une validation postale adaptée.
05Quelles limites s’appliquent au service gratuit ?
La page officielle annonce actuellement 10 000 crédits par jour et 1 000 par heure, par application identifiée par username. Le coût varie selon le service et le compte demo ne doit pas servir à une application ou à ses tests.
06Comment rendre l’intégration GeoNames résiliente ?
On distingue status d’erreur et absence réelle, budgète les crédits, met en cache les réponses admissibles, supervise chaque consommateur et choisit selon le besoin une offre premium, un dump local ou un fallback documenté.
Intégration d’un référentiel mondial de lieux
Vous voulez faire de GeoNames un référentiel, pas une réponse opaque ?
On peut cadrer le bon webservice, livrer un premier rapprochement et rendre identifiants, précision, crédits, attribution et reprise vérifiables.
Cadrer mon intégration GeoNames