"Volamont" sur moteur de recherche

**cmail** · 28/04/2010, 11h19

Constat étonnant, et récurrent:
quand je recherche le toponyme "volamont" http://api.ign.fr/geoportail/api/doc/examples/geoportalAlert.html
j'ai 50 résultats mais que deux qui correspondent à ma demande.

Sauf erreur de ma part.

**dgrichard** · 28/04/2010, 11h32

Envoyé par cmail

Constat étonnant, et récurrent:
quand je recherche le toponyme "volamont" http://api.ign.fr/geoportail/api/doc/examples/geoportalAlert.html
j'ai 50 résultats mais que deux qui correspondent à ma demande

Le moteur de recherche retourne jusqu'à 50 résultats.
La pertinence des résultats n'est pas vérifiée dans l'implémentation actuelle (aucun tri dessus ou retrait de réponse), c'est du brut !

**cmail** · 28/04/2010, 11h49

Je comprends bien, mais quand même il y a un problème . Certaines fois, le résultat de la recherche est bien ciblé, d'autres fois pas du tout.
Par exemple:

La recherche sur "renne" donne seulement trois résultats et n'intègre pas par exemple "rennes" et consorts (par exemple varenne). Dans ce cas on n'étend pas la recherche à 50 exemplaires. Très bien, mais là, ce n'est pas du "brut"!

Alors que la recherche sur "renn" donne 50 résultats allant de "renne" à "penn énez" en passant par "pont lenn" etc. mais pas par "rennes" ou "varenne". Bigre!
Quand à la recherche sur "ren" (voire "arenne"), les réultats n'intègrent pas ceux ci-dessus et sont aussi exotiques...

Ou est la logique?

**dgrichard** · 28/04/2010, 14h33

Envoyé par cmail

Je comprends bien, mais quand même il y a un problème . Certaines fois, le résultat de la recherche est bien ciblé, d'autres fois pas du tout.
Par exemple:

La recherche sur "renne" donne seulement trois résultats et n'intègre pas par exemple "rennes" et consorts (par exemple varenne). Dans ce cas on n'étend pas la recherche à 50 exemplaires. Très bien, mais là, ce n'est pas du "brut"!

Alors que la recherche sur "renn" donne 50 résultats allant de "renne" à "penn énez" en passant par "pont lenn" etc. mais pas par "rennes" ou "varenne". Bigre!
Quand à la recherche sur "ren" (voire "arenne"), les réultats n'intègrent pas ceux ci-dessus et sont aussi exotiques...

Ou est la logique?

Dans la configuration des règles du moteur, je dois demander des explications - patience (comme d'hab)

**cmail** · 29/04/2010, 08h08

Quelques premiers sentiments sur ce moteur de recherche :

Il me semble que la règle prioritaire d'affichage des résultats pourrait s'énoncer de la manière suivant:
On affiche les "bons" résultats quand le nombre de retour est >= à 3, en dessous on complète (suivant un critère inconnu) jusqu'à 50.

A cela j'émettrai trois souhaits, en cas de modification orchestrée par DGrichard;

Que la limite qui est à 3, soit supprimée (ou paramétrable).
S'il y a extension à 50 résultats, que cette limite soit paramétrable.
Qu'il soit possible de sélectionner une zone géographique rectangulaire de recherche (paramétrable par les coordonnées lat.lon de deux sommets opposés).

Pour cette dernière condition qui me semble très intéressante, si jamais elle n'est pas hélas retenue, elle devrait être accessible à l'utilisateur doué en programmation. Si je ne dis pas encore une fois une grosse bêtise.

Soit en triturant le fichier xml de retour au niveau du proxy (php dans mon cas)
Soit en surchargeant le control "SearchToolbar".

Avant de me lancer dans de longs et douloureux travaux, une orientation me serait utile.
Merci

**mga_geo** · 29/04/2010, 08h50

Je joins le début de la réponse du serveur.
Il doit être effectivement possible de patouiller au niveau du proxy, mais cela demande une certaine maitrise de php et de xml!
J'ai l'impression que dès qu'il n'y a pas de réponses exactes (accuracy="1"), le moteur de recherches fait des hypothèses hasardeuses ...
Si tu fais la recherche avec "Le Volamont", tu n'as plus qu'une réponse.

<GeocodeResponse>
<GeocodeResponseList numberOfGeocodedAddresses="50">
<GeocodedAddress>
<Point xmlns="http://www.opengis.net/gml">
<pos dimension="2">45.029823 4.240785</pos>
</Point>
<Address countryCode="BDNYME">
<StreetAddress>
<Street></Street>
</StreetAddress>
<Place type="Municipality">le volamont</Place>
<PostalCode>Sommet</PostalCode>
</Address>
<GeocodeMatchCode accuracy="0.926898" matchType="City"/>
</GeocodedAddress>
<GeocodedAddress>
<Point xmlns="http://www.opengis.net/gml">
<pos dimension="2">45.026571 4.236590</pos>
</Point>
<Address countryCode="BDNYME">
<StreetAddress>
<Street></Street>
</StreetAddress>
<Place type="Municipality">la chau de volamont</Place>
<PostalCode>Lieu-dit habité</PostalCode>
</Address>
<GeocodeMatchCode accuracy="0.922836" matchType="City"/>
</GeocodedAddress>
<GeocodedAddress>
<Point xmlns="http://www.opengis.net/gml">
<pos dimension="2">48.368753 7.111495</pos>
</Point>
<Address countryCode="BDNYME">
<StreetAddress>
<Street></Street>
</StreetAddress>
<Place type="Municipality">solamont</Place>
<PostalCode>Sommet</PostalCode>
</Address>
<GeocodeMatchCode accuracy="0.881247" matchType="City"/>
</GeocodedAddress>

**cmail** · 29/04/2010, 09h34

Je suis ok avec toi.

Mais au-delà, je reviens sur cette possibilité de sélectionner la recherche sur une zone rectangulaire géographique prédéterminée.
En effet, dans la plupart des recherches sur des applications limitées à des zones géographiques spécifiques (département, canton, commune, massif, etc.), ce critère géolocalisant ferait tomber les réponses non pertinentes.

Par exemple, pour une interface carto en direction des habitants de mon canton, la recherche sur "Volamont" si elle était "localisée" à une zone rectangulaire encadrant ce canton, les réponses seraient excellentes. "Le Volamont" et "la Chaud du Volamont" et pas "Solamont" qui se trouve en dehors du rectangle...
Certes, la trituration du php est nécessaire pour repérer

Code :

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

<pos dimension="2">45.026571 4.236590</pos>

dans le retour du fichier xml et le comparer à ses références rectangulaires géographiques pour ensuite ignorer la séquence

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
<GeocodedAddress>
          <Point xmlns="http://www.opengis.net/gml">
            <pos dimension="2">45.026571 4.236590</pos>
          </Point>
          <Address countryCode="BDNYME">
            <StreetAddress>
              <Street></Street>
            </StreetAddress>
            <Place type="Municipality">Réponse en dehors de la zone</Place>
            <PostalCode>Lieu-dit habité</PostalCode>
          </Address>
          <GeocodeMatchCode accuracy="0.922836" matchType="City"/>

qui se trouve hors zone.

Mais le jeu en vaut la chandelle...
Certes pour l'instant, vu mes grandes aptitudes, j'ai quelques difficultés avec la trituration de ce code php, mais on devrait pouvoir y arriver...

**dgrichard** · 01/05/2010, 10h55

Envoyé par cmail

Je suis ok avec toi.

Mais au-delà, je reviens sur cette possibilité de sélectionner la recherche sur une zone rectangulaire géographique prédéterminée.
En effet, dans la plupart des recherches sur des applications limitées à des zones géographiques spécifiques (département, canton, commune, massif, etc.), ce critère géolocalisant ferait tomber les réponses non pertinentes.

Il suffit d'étendre le contrôle Geoportal.Control.LocationUtilityService.Geonames, méthode LUSsuccess() pour ne prendre qu'une emprise donnée ...

**cmail** · 01/05/2010, 12h02

Il suffit d'étendre le contrôle Geoportal.Control.LocationUtilityService.Geonames, méthode LUSsuccess() pour ne prendre qu'une emprise donnée ..

Bon!, j'ai regardé (et j'analyse toujours) cette méthode. J'ai beaucoup de test à faire pour en extraire quelques choses (tu imagines!). Mais je suis déjà un peu déstabilisé par l'écriture de ton control : Geoportal.Control.LocationUtilityService.Geonames ... que j'ai du mal à projeter ... Et pas beaucoup d'exemple sur le sujet...

**mga_geo** · 01/05/2010, 12h15

Je viens d'essayer sur http://atlasnw.free.fr/geoportail/ex...recherche.html
et la surcharge perturbe l'affichage des résultats.

Il y a des erreurs de casse dans le nom de la fonction, j'ai utilisé Geoportal.Control.LocationUtilityService.GeoNames.prototype.LUSSuccess

**cmail** · 01/05/2010, 12h39

J'ai regardé ton code.
Tu sais comme je suis un grand débutant, et que je dis souvent des bêtises.
Mais crois-tu que la définition de l'emprise en fin de ton code

Code :

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

1
2
3
// filtrage sur un polygone
  var cercleOrigine = new OpenLayers.Geometry.Point(-1.50, 48.15 );
  OpenLayers.Geometry.Polygon.createRegularPolygon( cercleOrigine, 10000, 20, 0 );

est opérationnelle à cette place?

J'aurai tendance à l'intégrer plus haut dans la surcharge de
LUSSuccess au moment ou

Code :

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

var features= this.layer.queriedAddresses[0].features;

renvoie les réponses sous forme d'objet. Il me semble qu'à ce moment, il serait astucieux de comparer les lat et lon de ces objets pour savoir s'ils sont dans le périmètre de l'emprise.
A ce propos, il me semblerait plus facile de déterminer une emprise rectangulaire (plutot qu'un polygone) déterminée par deux sommets opposées (lat0,lon0) et (lat1,lon1) qui permettrait de faire des comparaisons simples du type if (lat0<lat && lat>lat1 && lon0<lon && lon>lon1) alors on garde sinon on rejette.

Mais bon, à ce niveau je suis plus contemplatif qu'actif

Encore faut-il que l'affichage du panneau de résultat soit OK

**mga_geo** · 01/05/2010, 14h36

Merci la pluie, je viens de mettre à jour ma page et maintenant je sélectionne bien sur une zone donnée.
J'affiche avec un petit popup par résultat.
La forme de la zone de recherche est définie par un polygone, et OpenLayers offre la fonction qui permet de tester si un point est contenu dans un polygone.

**cmail** · 01/05/2010, 14h49

Vive la pluie.

Bien qu'il reste quelques points à gratter. Notamment l'affichage des résultats qui est très embêtante. Une idée SVP dgrichard?

**Max_B** · 05/05/2010, 00h52

Pour ma part, dans l'implémentation iPhiGéNie, j'élimine tout ce qui a un taux de satisfaction (GeocodedAddress accuracy) inférieur à 0,7 et je trie sur la distance au point de référence, centre de la carte par ex.

**dgrichard** · 03/10/2010, 11h09

Testé ce matin sur notre environnement de développement

(renne -> rennes, varenne)
(brétigny -> brétigny-sur-orge)

**cmail** · 03/10/2010, 13h09

Bonne nouvelle, mais quand nous sera-t-il accessible?
J'ai fait des essais sur http://api.ign.fr/geoportail/api/doc/examples/geoportalAlert.html
mais c'est toujours avec l'ancien moteur. Non?

**dgrichard** · 03/10/2010, 13h13

Envoyé par cmail

Bonne nouvelle, mais quand nous sera-t-il accessible?
J'ai fait des essais sur http://api.ign.fr/geoportail/api/doc/examples/geoportalAlert.html
mais c'est toujours avec l'ancien moteur. Non?

N'ai-je pas écrit :

sur notre environnement de développement

J'ai envoyé un courriel de validation à la production, j'attends donc un retour pour avoir la date de bascule, mais à priori, je dirais la semaine prochaine (lundi 11) ...

**cmail** · 03/10/2010, 13h43

Quand on ne connait pas le mode de fonctionnement des services de l'IGN, on peut tout imaginer... L'environnement de développement peut-être plus ou moins intégré à la production, avec une grande réactivité entre les deux... Maintenant, je vois que non.
D'autant plus que tu nous réponds positivement (sans notions de délais) à nos questions, ce qui me (nous) laisse penser à de possibles et accessibles vérifications immédiates.
On attendra donc la semaine prochaine pour tester

**dgrichard** · 03/10/2010, 14h34

Envoyé par cmail

Quand on ne connait pas le mode de fonctionnement des services de l'IGN, on peut tout imaginer...

Pourquoi se poser plus de questions ? J'essaie de communiquer toutes les informations utiles, le reste, c'est de la mécanique de coudes !

Envoyé par cmail

L'environnement de développement peut-être plus ou moins intégré à la production, avec une grande réactivité entre les deux... Maintenant, je vois que non.

Et cela change quoi ?

Envoyé par cmail

D'autant plus que tu nous réponds positivement (sans notions de délais) à nos questions, ce qui me (nous) laisse penser à de possibles et accessibles vérifications immédiates.
On attendra donc la semaine prochaine pour tester

Répondre à des questions est différent de mettre en production.