Discussion :

[cmail]

Suite à ce fil , pourriez-vous me dire comment opérer basiquement, mais très concrètement, pour résoudre ce petit problème si simple dans son énoncé :

J'affiche une carte centrée sur un département.
L'utilisateur clique sur un lieu.
L'application retourne dans un champ le code INSEE du point cliqué.

Qui serait si pratique, au lieu de bidouiller avec des kml

Ne serait-il pas possible de créer une page exemple IGN avec cette fonction, comme vous avez fait avec les 4 pages sur le moteur de recherche d'adresse?

[cmail]

Pour alimenter un peu le débat!
Voici une page de test où j'aimerais bien afficher en continu le nom de la commune survolée par le curseur...

Je ne sais pas si c'est possible, et si la voie empruntée est la bonne.

Parfois, j'ai des réponses correctes, mais souvent la réponse n'est pas renseignée.

????

[mga_geo]

Afficher en continu la commune par une interrogation d'une API suppose que la souris est déplacée par un escargot.
Typiquement en 1/10ème de seconde, ma souris vient de parcourir plus de 800 pixels. Une API très performante répond dans les 100 millisecondes (celle de l'IGN est plutôt à 500ms). On a quasiment un rapport de 100 entre le besoin et le service fourni.

Pour obtenir ce service, une solution est de charger une couche kml des communes et de tester dans quelle commune est le point.
Cette solution ne dépend que des ressources du PC.

[cmail]

Merci Marc pour ta réponse qui rejoint mes conclusions. Mais comme je suis assez isolé avec mes réflexions, j'ai parfois besoin de retour d'autres plus expérimentés. Et parfois même, je n'envisage pas certaines solutions techniques faute de connaissance.... Je posais aussi la question, car j'avais évoqué oralement cette approche avec Tcoupin, et il m'avait semblé qu'il me disait que c'était possible. Mais la rapidité de nos échanges à ce moment-là fait qu'il y a certainement eu un quiproquo. A voir...

Pour obtenir ce service, une solution est de charger une couche kml des communes et de tester dans quelle commune est le point.

Cela est la technique que j'utilise actuellement, mais c'est assez lourd (dessin des kml) à mettre en oeuvre à l'échelle du département, et quand on atteint une échelle assez faible, OL est confronté au "problème des trous" toujours pas résolu (voir cette discussion). Et dans ce dernier cas, celui qui me préoccupe vraiment en fait, comment faire?
D'autres idées ou opinions?

[mga_geo]

Le temps de chargement d'un kml produit à partir de GEOFLA pour le département 35 est effectivement limite.

Au niveau bibliothèque, j'avais fait joujou avec JSTS qui a un peu moins de problèmes qu'OpenLayers.

Je viens de faire un test en faisant une recherche OLS à chaque clic, et j'ai énormément de non réponse, il faut être très proche d'un lieudit pour avoir une réponse.

[gcebelieu]

Afficher en continu la commune par une interrogation d'une API suppose que la souris est déplacée par un escargot.
Typiquement en 1/10ème de seconde, ma souris vient de parcourir plus de 800 pixels. Une API très performante répond dans les 100 millisecondes (celle de l'IGN est plutôt à 500ms). On a quasiment un rapport de 100 entre le besoin et le service fourni.

Pour obtenir ce service, une solution est de charger une couche kml des communes et de tester dans quelle commune est le point.
Cette solution ne dépend que des ressources du PC.

Je te rejoins Marc : il ne faut pas invoquer le service au survol, ou à la rigueur lorsque la souris est immobile un instant...

Je viens de faire un test en faisant une recherche OLS à chaque clic, et j'ai énormément de non réponse, il faut être très proche d'un lieudit pour avoir une réponse.

en effet, mais tu peux jouer sur le rayon de recherche du géocodage inverse.

[cmail]

à la rigueur lorsque la souris est immobile un instant

Peut-être que je vais essayer cette solution (si souris immobile pendant x ms alors request) si j'arrive à bien maitriser le comportement de la souris et l'envoi de la requete...

[mga_geo]

L'API donne les coordonnées du lieudit le plus proche. Ces coordonnées sont souvent à une distance certaine des coordonnées du point demandé. Cet écart fait que que dans 5 à 10 % des cas (test sur des observations d'oiseau du site site faune-bretagne) la commune est erronée !

Il faut donc trouver/faire une API qui donne effectivement la commune d'un point car la solution à base de kml ne fonctionne pas avec des contours précis des communes.

[jrenard]

L'API donne les coordonnées du lieudit le plus proche. Ces coordonnées sont souvent à une distance certaine des coordonnées du point demandé. Cet écart fait que que dans 5 à 10 % des cas (test sur des observations d'oiseau du site site faune-bretagne) la commune est erronée !

Bonjour,

C'est une limite logique et connue qui provient du fait que le géocodage se fait au point et non au polygone. Avec un géocodage au polygone on pourrait assurer que le code INSEE retourné est bien celui de la commune sur laquelle on a cliqué, mais ce n'est pas encore une option disponible avec l'API. Comme le géocodage se fait au point, le moteur recherche le point matérialisant une commune qui est le plus proche du point requêté, et il est donc possible que le point retourné soit celui d'une autre commune dans le cas où l'on se situe sur le territoire d'une commune tout en étant plus proche du centre d'une commune voisine. Cela peut arriver si l'on est assez éloigné du centre de la commune sur laquelle on se situe.

[cmail]

Merci pour ces explications

mais ce n'est pas encore une option disponible avec l'API

Ok, mais est-ce un sujet sur lequel vous travaillez car cela semble important. Non?
Si oui, avez-vous un vague échéancier...

[jrenard]

Effectivement, c'est un sujet important. Mais c'est aussi un sujet plus complexe qu'il n'y paraît.
C'est donc une option en cours de développement, mais il est impossible de prévoir une quelconque échéance à l'heure actuelle.
Une information sera faite sur le forum lorsque nous aurons avancé sur le sujet.

[mga_geo]

Je viens de tester une solution à base des contours de la base GEOFLA : http://mga.alwaysdata.net/geoportail...s_commune.html
Ces derniers ont très simplifiés et cela induit des erreurs.
Il est possible de tester via un clic la commune au sens GEOFLA, j'obtiens l'info via cette requête sql:

SELECT insee_com, nom_comm FROM geofla_commune WHERE ST_Within(ST_GeomFromText('POINT(-1.515813 48.116488)', 4326), geofla_commune.geom4326);

En utilisant une base moins simplifiée (ROUTE500, OSM), les résultats devraient être meilleurs.

[gcebelieu]

L'API donne les coordonnées du lieudit le plus proche. Ces coordonnées sont souvent à une distance certaine des coordonnées du point demandé. Cet écart fait que que dans 5 à 10 % des cas (test sur des observations d'oiseau du site site faune-bretagne) la commune est erronée !

Il faut donc trouver/faire une API qui donne effectivement la commune d'un point car la solution à base de kml ne fonctionne pas avec des contours précis des communes.

je reviens sur l'idée du Géocodage Inverse :

la solution évoquée jusqu'à présent concernait un Géocodage Inverse sur les lieux dits uniquement. Je pense qu'une utilisation de ce service à la fois sur les lieux dits ET LES ADRESSES pourrait réduire de façon assez conséquente le taux d'erreurs du au manque de réponses proches du point cliqué en limite de commune.

[cmail]

je reviens sur l'idée du Géocodage Inverse

Très bien! Revenons-y!
Jusqu'à présent, j'utilise des kml invisibles perso, portant sur les limites des communes, en fond de couche. Par une détection en over, j'affiche le nom des communes. Ce procédé est totalement dynamique mais pose quelques problèmes quand on se rapproche des limites des communes, et surtout pose un problème avec le bug d'OL sur les kml quand l'échelle est faible.

La solution de géocodage inverse pourrait éviter la lourdeur de création de ces kml, mais ne serait pas totalement dynamique (voir les premières réflexions sur le sujet). Peut-être qu'en ajoutant un géocade inverse sur les adresses cela améliorerait la précision, encore faudrait-il avoir un exemple IGN sur lequel on puisse se faire les dents (le tester et tirer des conclusions)! Pour ma part, j'ai déjà quelques problèmes avec le géocodage inverse sur les toponymes, si en plus je dois le doubler, je ne suis pas prêt de conclure...
...

[gcebelieu]

encore faudrait-il avoir un exemple IGN sur lequel on puisse se faire les dents (le tester et tirer des conclusions)!

Oui, oui, pour l'instant, je me contente de jeter des idées en l'air, car on est mobilisé sur la finalisation de l'API 2.1.0 (dont j'annonce la publication depuis bientôt un an )