Spec du service Recherche

[petzlux]

Dans le géoportail existant, la recherche fonctionne avec deux calls:

Premièrement, le service autocomplete (locationsearch) retourne les résultats appropriés dans le format suivant:

{
    "results": [
                {
        "listlabel": "<b>54,</b> <b>Avenue</b> de la Lib\u00e9ration, L-3850 Schifflange", 
        "label": "54, Avenue de la Lib\u00e9ration, L-3850 Schifflange", 
        "bbox": [68443.23350000006, 63409.329097340989, 68443.23350000006, 63409.329097340989], 
        "fk": "108A04030007119", 
        "type": "Adresse", 
        "id": 1071501
            }, 
            { ... 
            }
        ] 
    "success": true
}

Quand un résultat est sélectionné par l'utilisateur, une deuxième requête au service geometry est lancée, qui transmet l'id du feature sélectionnée, et qui retourne la géométrie (point, ligne ou polygone) du feature.

Est ce que cette distinction reste dans le nouveau systeme de recherche, ou est-ce que dans la requete autocomplete déjà, on transmet la géométrie (point, ligne ou polygone) et bbox des différents résultats?

Je vois ceci peut devenir lourd si l'on fait une recherche autocomplete qui aboutit a plusieurs polygones compliqués ?

[elemoine]

Stéphane et moi avons brièvement discuté de ce point. Il nous semble qu'il est pertinent de faire deux requêtes, pour éviter de payer pour des coordonnées qui ne seront pas utilisées.

[petzlux]

Est ce qu'on peut alors rédéfinir les deux interfaces ?

L'interface autocomplete sera alors sans geometry du tout, puis un service qui prend une ID et retourne geometry et attributs ?

[elemoine]

À qui poses-tu ces questions ?

[jaykayone]

@sbrunner fait la spec de son service de recherche et @petzlux pourra l'implémenter avec elasticsearch pour que ce soit compatible

[sbrunner]

The server interface as I imagine:

Result Query: Parameters:

• query: Text to search
• details: should be 'no', default is 'yes'.
• callback: For JSONP Result:

{
  "results": [{
    "id": <>,
    "label": <>,
    "layer_name": <>,
    "params": <>, // {} in our case
    "bbox": <>, // optional, only if no details
    "has_details": <true|false>,
  }, ...]
}

Details query: Parameters:

• id: element id
• callback: For JSONP Result: GeoJson with one geometry and the following parameters: 'id', 'label', 'layer_name', 'params'.

Is it ok for you ?

[jaykayone]

@sbrunner @petzlux is this finished? can we close this issue?

[sbrunner]

For me we can close it :-)

[elemoine]

Where are the specs? Is https://github.com/Geoportail-Luxembourg/geoportailv3/wiki/Specification-du-service-de-recherche up to date?

[petzlux]

Yes, as it stands now, it is uptodate

[elemoine]

Is there a URL I can use to test the search service?

[petzlux]

But, need to redefine interface following discussion to support two queries,

"L'interface autocomplete sera alors sans geometry du tout, puis un service qui prend une ID et retourne geometry et attributs"

[jaykayone]

http://devv3.geoportail.lu/main/wsgi/fulltextsearch?query=%2054%20did

[elemoine]

Thanks @jaykayone.

[petzlux]

@elemoine I have seen the example in ngeo for search and it seems to work fine, but it rests on the interface as it stands now.

Did we ever agree if we are going to redefine interface as discussed here or not ? Does ngeo code need adaptation if we change interface ?

[elemoine]

@petzlux Sorry, I don't understand. What do mean by « if we change interface »? What is this interface you are referring to?

[petzlux]

as @sbrunner said:

The server interface as I imagine: Result Query: Parameters: query: Text to search details: should be 'no', default is 'yes'. callback: For JSONP Result: { "results": [{ "id": <>, "label": <>, "layer_name": <>, "params": <>, // {} in our case "bbox": <>, // optional, only if no details "has_details": <true|false>, }, ...] } Details query: Parameters: id: element id callback: For JSONP Result: GeoJson with one geometry and the following parameters: 'id', 'label', 'layer_name', 'params'. Is it ok for you ?

[elemoine]

The ngeo component knows nothing about the response format. There just it a GeoJSON Bloodhound factory that one can use when the search responses are GeoJSON responses. We could add other factories in the future.