Discussion :

[Max_B]

Sur les premiers tests que je viens de faire, je constate que les données retournées pas le serveur API sont différentes de celles retournées par le Géoportail, pour la même recherche.

Outre l'idiome xml complètement différents, le nombre d'informations et moindre en API. Une recherche sur un lieu dit sur le Géoportail retourne le code postal, la ville proche, le pays et le territoire, informations absentes du retour API, qui retourne par contre comme "postal code" une typologie de lieu.
L'API a aussi le plus d'être en UTF8 et d'avoir des accents sur les toponymes qui manque de la plupart des retours géoportail.

Je constate aussi une légère différence de valeurs de position, ce qui me laisse plus perplexe. Par défaut l'API est en EPSG:4326. Je suppose que le Géoportail aussi. Cela semble plutôt des différences d'arrondi donc de méthode de calcul.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
	<!-- position API -->
          <Point xmlns="http://www.opengis.net/gml">
            <pos dimension="2">44.745066 5.447321</pos>
          </Point>
	<!-- position géoportail -->
	<gc:x>5.447318</gc:x>
	<gc:y>44.745068</gc:y>

Vous me direz peut être que c'est pas grand chose, mais tout de même curieux.

En résumé, quelques précisions sur ces données seraient bienvenues.

Bon, j'ai l'impression que Didier est absent ces jours ci, on risque de ne pas avoir de réponse tout de suite.

[Max_B]

J'ai fait d'autres tests, en mode "freeFormAddress" comme en mode "StreetAddress".
On obtient des résultats mais la base ne me paraît pas bien mature et digne du label production.
Le code postal n'est jamais renseigné, il est toujours utilisé comme typologie, les rues ne sont pas retournées non plus.
Il me semble que l'on a que les communes et les lieux dit. C'est déjà pas mal surtout pour les toponymes qui n'ont pas d'équivalent, mais pour les adresses c'est pas ça.

Ou alors j'ai manqué un truc ?

[Unusual]

Bonjour,
J'ai intégrer depuis longtemps le code pour avoir les outils de recherche dans la barre d'outils, mais cela ne fonctionne pas chez moi (hormis le positionnement sur coordonnées). Y a-t-il du code à ajouter pour que cela marche ? Comment réalises-tu ces recherches ? Y a-t-il des pré-requis (déclarations, propriétés, code, ajouts de couches,...) ? As-tu un exemple ?

[Max_B]

Comment réalises-tu ces recherches ? Y a-t-il des pré-requis (déclarations, propriétés, code, ajouts de couches,...) ? As-tu un exemple ?

Comme je l'ai mentionné dans l'autre fil sur le sujet, le pré-requis majeur est de disposer d'une clé qui donne accès à la couche TOPONYMS.ALL et fournit donc l'url du serveur openLS. Ensuite, je pense que les exemples dispo, comme celui de la page de mga_géo doivent tourner. Mes tests qui s'intéressent au protocole requête/réponse au niveau xml utilisent un mini-script php dont la requête est justement copiée de cet exemple. Pour le géoportail, je m'intéresse au xml retourné par une requête de recherche.

[dgrichard]

Sur les premiers tests que je viens de faire, je constate que les données retournées pas le serveur API sont différentes de celles retournées par le Géoportail, pour la même recherche.

Je t'avais prévenu ...

Outre l'idiome xml complètement différents, le nombre d'informations et moindre en API. Une recherche sur un lieu dit sur le Géoportail retourne le code postal, la ville proche, le pays et le territoire, informations absentes du retour API, qui retourne par contre comme "postal code" une typologie de lieu.

Normal, l'API utilise seulement la BD NYME®, le Géoportail, construit avant l'API utilise une vieille structure de la BD NYME® qui n'est plus maintenue. Nous effectuons des contortions pour ajouter par nous-même ces informations pour le moteur de recherche du Géoportail.
Par contre, avec OpenLS nous restons avec la BD NYME® telle qu'elle nous est fournie.

L'API a aussi le plus d'être en UTF8 et d'avoir des accents sur les toponymes qui manque de la plupart des retours géoportail.

Ah, un truc bien ...

Je constate aussi une légère différence de valeurs de position, ce qui me laisse plus perplexe. Par défaut l'API est en EPSG:4326.

Disons compatible EPSG:4326 (qui a une précision de 10 mètres ne l'oublions pas)

Je suppose que le Géoportail aussi. Cela semble plutôt des différences d'arrondi donc de méthode de calcul.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
    <!-- position API -->
          <Point xmlns="http://www.opengis.net/gml">
            <pos dimension="2">44.745066 5.447321</pos>
          </Point>
    <!-- position géoportail -->
    <gc:x>5.447318</gc:x>
    <gc:y>44.745068</gc:y>

Vous me direz peut être que c'est pas grand chose, mais tout de même curieux.

Pas vraiment, le moteur de recherche du Géoportail retourne les coordonnées selon un schéma distinct de l'API (Cf. supra sur la chaîne de traitement).

En résumé, quelques précisions sur ces données seraient bienvenues.

Simple: n'utilise pas le moteur du Géoportail qui utilise un processus que nous maintenons à bout de bras.
Sinon, les informations sont là
Globalement, la résolution est métrique, mais les toponymes anciens ont une précision hectométrique ...

Bon, j'ai l'impression que Didier est absent ces jours ci, on risque de ne pas avoir de réponse tout de suite.

Pas absent, sur-booké ... il me reste le dimanche pour répondre

[Max_B]

Merci Didier pour ces réponses, avec mes excuse pour le travail du dimanche.
Quelques points:
- je n'utilise le moteur géoportail que pour des requêtes manuelles de comparaison/référence.

-je suis un peu surpris de la transcription des classes et attributs de la bdnymes en xml. Voici par exemple un extrait de retour sur un toponyme divers, en recherche freeFormAdress:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
        <GeocodedAddress>
          <Point xmlns="http://www.opengis.net/gml">
            <pos dimension="2">44.815521 5.782869</pos>
          </Point>
          <Address countryCode="BDNYME">
            <StreetAddress>
              <Street></Street>
            </StreetAddress>
            <Place type="Municipality">pierre des sacrifices</Place>
            <PostalCode>Rochers</PostalCode>
          </Address>
          <GeocodeMatchCode accuracy="1" matchType="City"/>
        </GeocodedAddress>

Ce qui me surprend c'est que je m'attendais à ce que la nature du toponyme "Rochers" soit listé dans l'attribut "type" de l'élément <Place> et non dans l'élément <PostalCode>
Ce n'est qu'une question de convention mais je voulais m'assurer que c'est bien un choix et non un bug.
Voici un extrait sur une recherche StreetAddress, avec une demande sur 'place de la Bastille' et 'Paris' :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
        <GeocodedAddress>
          <Point xmlns="http://www.opengis.net/gml">
            <pos dimension="2">43.643166 0.098159</pos>
          </Point>
          <Address countryCode="FR">
            <StreetAddress>
              <Street></Street>
            </StreetAddress>
            <Place type="Municipality">paris</Place>
            <PostalCode>Lieu-dit habité</PostalCode>
          </Address>
          <GeocodeMatchCode accuracy="1" matchType="City"/>
        </GeocodedAddress>

On a une position, c'est le principal (et même plein pour cette adresse), le nom et la nature "Lieu-dit habité", dans le code postal. L'adresse n'est pas retournée, <StreetAddress> est vide. La spécif mentionne les attributs suivants:

• ID Identifiant du lieu-dit
• ORIGIN_NOM Origine du toponyme
• NOM Nom du lieu-dit habité
• IMPORTANCE Importance du lieu-dit
• NATURE Nature du lieu-dit

L'origine du toponyme et l'importance du lieu-dit semblent absents mais on s'en fout un peu. La BDNYMES ne mentionne pas de code postal, donc on a ce qui est prévu.
Donc, on est bien d'accord que l'attribut xml "type" de l'élément <Place> n'a pas de signification et que là aussi l'attibut "NATURE" de la BDNYME est retourné dans l'élément xml <PostalCode>.

C'est pas pour pinailler, juste pour partir sur de saines bases ;-)

[Max_B]

En relisant pon post précédent je remarque seulement que la position retournée est curieuse : dans le sud-ouest de la France en zone rurale. Certes, la recherche en question retourne de nombreux résultats, mais le tri n'est pas évident avec les infos disponibles…

J'ai l'impression que les recherches toponymes sont bien utile, mais les recherches adresses, peu.

[dgrichard]

C'est pas pour pinailler, juste pour partir sur de saines bases ;-)

Non, les choix ont été faits et les résultats que tu obtiens sont les bons. Nous utilisons OpenLS pour remonter les résultats, mais n'avons pas toutes les possibilités de dispatcher l'information sur les balises dans le cas de la recherche par lieux.

Ce qui sera possible, c'est que des développeurs de mon équipe travaillent sur un autre protocole pour les toponymes en Europe (projet EuroGeoNames) et que ce protocole (WFS-G) va devoir s'insérer dans la pile des protocoles du Géoportail ... L'utilisation d'OpenLS pour la recherche par lieux est donc un pis aller...

en OpenLS: les bons champs restent bien Place, PostalCode et GeocodeMatchCode@accuracy (pour décider duquel prendre).

Par contre, pour les adresses rien ne changera : OpenLS est le protocole choisi et le restera !

[Max_B]

Note: j'ai totalement effacé et repris ce message après avoir finalement noté que les serveurs TOPONYMS.ALL et ADDRESSES.CROSSINGS ont des url différents. Je faisais toutes les requêtes de test vers le serveur toponyme…

Donc maintenant, mes tests donnent des résultats plus probants. J'ai maintenant deux questions :
- les requêtes de type freeFormAdresse vont vers l'url de TOPONYMS.ALL et les SteetAdress vers ADDRESSES.CROSSINGS, c'est bien ça?

- les retours du serveur ADDRESSES.CROSSINGS sont satisfaisantes sur mes essais sur Grenoble, par exemple. Mais sur Paris, toutes les adresses me retourne le même point, le square de l'ile de la cité. ?

Edit: Comme pour Paris, les requêtes Lyon et Marseille ne retournent qu'un seul point, quelle que soit l'adresse. Y aurait il une ruse pour les villes à arrondissement?

Note : Attention au code postal dans la recherche. Ce n'est pas le code postal mais le code INSEE de la commune qui est retourné/utilisé dans la recherche. Du coup, si on met un code postal (stricto sensu) on surdétermine la requête et elle ne retourne rien. Le bon truc c'est qu'on trouve facilement le code INSEE d'une commune par son nom.

[cmail]

Si cela peut aider:
http://www.insee.fr/fr/methodes/nome...chargement.asp

[dgrichard]

- les requêtes de type freeFormAdresse vont vers l'url de TOPONYMS.ALL et les SteetAdress vers ADDRESSES.CROSSINGS, c'est bien ça?

Oui

- les retours du serveur ADDRESSES.CROSSINGS sont satisfaisantes sur mes essais sur Grenoble, par exemple. Mais sur Paris, toutes les adresses me retourne le même point, le square de l'ile de la cité. ?

C'est un boggue sur le serveur de développement, ce phénomène n'existait pas et je viens de le constater ...[/QUOTE]

Edit: Comme pour Paris, les requêtes Lyon et Marseille ne retournent qu'un seul point, quelle que soit l'adresse. Y aurait il une ruse pour les villes à arrondissement?

C'est une piste pour moi ...

Note : Attention au code postal dans la recherche. Ce n'est pas le code postal mais le code INSEE de la commune qui est retourné/utilisé dans la recherche. Du coup, si on met un code postal (stricto sensu) on surdétermine la requête et elle ne retourne rien. Le bon truc c'est qu'on trouve facilement le code INSEE d'une commune par son nom.

C'est pourquoi le code postal est désactivé dans le Geoportal.Control.LocationUtilityService.Geocode ... en attendant de trouver la soluce !

[Max_B]

En tous cas, les recherches toponymes c'est de la balle!

[dgrichard]

En tous cas, les recherches toponymes c'est de la balle!

Lieu-dit habité aux coordonnées suivantes :

POINT(-1.229273 48.694770)

[Max_B]

C'est un boggue sur le serveur de développement, ce phénomène n'existait pas et je viens de le constater

Didier, je viens de m'apercevoir qu'une recherche adresse, sans la ville, mais avec le code INSEE, donne de bon résultats, qui donnent à leur tour des pistes:
- les codes postaux sur Paris sont retournés de la forme 75101 pour le 1er, 75104 pour le 4eme, etc.
- si on utilise ces codes, ou bien, comme "ville", la même chose que ce qu'il retourne: "Paris 1er Arrondissement", la recherche marche.

Aucun utilisateur ne tapera "Paris 1er Arrondissement" mais on a la piste je pense.

[Max_B]

POINT(-1.229273 48.694770)

et aussi (lat/long)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<pos dimension="2">42.937000 -0.644389</pos>

[dgrichard]

Le boggue sur le moteur de recherche par adresses a été corrigé hier en production : il s'agissait d'une mauvaise configuration de ce celui-ci.

[Max_B]

Le boggue sur le moteur de recherche par adresses a été corrigé hier en production : il s'agissait d'une mauvaise configuration de ce celui-ci.

Confirmé :