Produits Entr'ouvert » Passerelle

Ça a un rapport avec #20546 ?

Oui, mais je préfère bosser sur ce ticket car dans la plupart des cas le filtre se fera sur plusieurs propriétés.

eval

Plutôt que construire une requête interprétée côté SIG (ce que j'imaginais par "requête CQL"), ça me semble tout récupérer puis lancer du Python dessus.

La requete CQL pourra être écrite dans query_filters. Par exemple:

typeName:"ref_nom_voies_par_commune" 
cql_filter: "strEqualsIgnoreCase(nom_commune, '" + commune + "') = true" 

et tout ça sera envoyé en paramètres au SIG.

Je pensais moi qu'on proposerait,pour une requête donnée, de spécifier TYPENAMES, PROPERTYNAME sous forme de deux charfield classiques, et un CQL_FILTER sous forme d'un textarea contenant un template Django. Template qui recevra request, et "basta". Ça sera plus simple àmha.

Je ne veux pas inventer une nouvelle façon de redefinir de paramètres. Comme la syntaxe des expressions/projections dans le connecteur CSV est déjà plus ou moins familière, je préfère me baser dessus.

Petites interrogations fonctionnelles. Dans ton exemple d'appel, tu ne spécifie pas de propriété, pourtant c'est un paramètre requis de l'endpoint features. Est-ce qu'on garde ce caractère obligatoire, et si oui, est-ce qu'on le spécifie dans la requête qu'on crée ou dans l'URL ?

Le système de requêtes dans arcgis permet les deux, mais ici j'ai l'impression que tu imagines quelque chose de moins souple. Ça a des conséquences pour ce qui est de la mise en cache : si on autorise des paramètres d'url supplémentaires à destination du serveur, comme c'est fait dans arcgis, il va falloir mettre en cache suivant une clé dynamique, type un hash des ces paramètres. Sinon, pas la peine de s'embêter.

Et question technique en passant, le cache de django suffit, pas la peine de mettre les chose en db comme dans base_adresse ?

OK, et encore une question par rapport à ta description au dessus :

Frédéric Péters a écrit :

On définirait aussi dans ces requêtes un paramètre de cache, et le code de filtrage géographique serait directement intégré dans le connecteur; ainsi
on l'aurait genre toutes les heures récupérer les données de data.grandlyon puis nos requêtes pouvant s'exécuter uniquement en local.

Il n'y a pas une contradiction ici ? Tel que je le vois c'est soit on utilise la méthode hourly et les données sont récupérées toutes les heures, soit on introduit un paramètre de cache et la récupération se fait autrement (en supposant que « paramètre de cache » veuille dire « quelque chose qui spécifie la durée du cache »).

Perso je préférerais faire autrement qu'avec hourly, ça risque d'être bien bien frustrant voire inutilisable d'attendre une heure entre chaque modif de la requête pour vérifier qu'elle marche. On peut viser un truc hybride, synchro toutes les heures + à chaque modif de la requête le cache est invalidé et une requête quand le cache est invalide déclenche la vraie récup des données (et si c'est trop long et que la page timeout, on fait confiance à la personne derrière pour comprendre pourquoi).

Oui, ça peut être cron horaire + job asynchrone lors de la création/modification pour bootstrapper ça. Quand je parlais de duréee de cache c'était de l'ordre de la journée (c'est ce qu'on a aujourd'hui pour d'autres données récupérées de data.grandlyon aujourd'hui), tout à fait compatible avec un job toutes les heures.

Commentaires sur des premiers tests, sans encore avoir regardé attentivement le code (juste en passant, renommer "q" en "query", parce que les méthodes d'une lettre c'est vraiment trop court).

À la création d'une requête, trace,

  File "/home/fred/src/eo/venv1.11/local/lib/python2.7/site-packages/django/views/generic/edit.py", line 45, in get_form
    return form_class(**self.get_form_kwargs())
  File "/home/fred/src/eo/venv1.11/local/lib/python2.7/site-packages/django/forms/models.py", line 298, in __init__
    self.instance = opts.model()
  File "/home/fred/src/eo/passerelle/passerelle/apps/opengis/models.py", line 434, in __init__
    self.endpoint = self.resource.features
  File "/home/fred/src/eo/venv1.11/local/lib/python2.7/site-packages/django/db/models/fields/related_descriptors.py", line 194, in __get__
    "%s has no %s." % (self.field.model.__name__, self.field.name)
RelatedObjectDoesNotExist: Query has no resource.

contournée en local,

     def __init__(self, *args, **kwargs):
         super(Query, self).__init__(*args, **kwargs)
-        self.endpoint = self.resource.features
-        self.called_from = self.resource.q
+        if self.resource_id:
+            self.endpoint = self.resource.features
+            self.called_from = self.resource.q

Ensuite fail avec #41143.

Ensuite fail parce que erreur 400, "'JSON' is not a permitted output format for layer"; c'est en fait geojson qui est attendu, est-ce là une différence entre versions ? Ou geojson marcherait toujours ? Ou il faut parser https://download.data.grandlyon.com/wfs/grandlyon?service=WFS&request=GetCapabilities pour voir ? (TODO: regarder où le connecteur est utilisé et les réponses obtenues).

En modifiant,

-            'OUTPUTFORMAT': 'json',
+            'OUTPUTFORMAT': 'geojson',

ça passe et j'obtiens bien les infos en base.

Pour tester, mon paramétrage :

• URL du service WFS : https://download.data.grandlyon.com/wfs/grandlyon
• feature type : pvo_patrimoine_voirie.pvoparking
• xml filter : <Filter><PropertyIsEqualTo><PropertyName>typeparking</PropertyName><Literal>Aire de covoiturage</Literal></PropertyIsEqualTo></Filter>

(en passant, il y aurait sans doute à rendre query_layer optionnel dans le paramétrage du connecteur).

• +          query['resource'] = instance
             q = Query.import_json(query)
  -            q.resource = instance
  

  ça semble gratuit comme changement, les deux fonctionnent.

• J'aime pas vraiment le self.endpoint / self.called_from c'est très spécifique à ces deux implémentations que les query correspondent à un endpoint existant dont on va pré-remplir des paramètres, je ne sais pas trop ce qu'on y gagne à part que c'est plus complexe à comprendre (trop d'indirections) ; on avait un appel direct à self.resource.mapservice_query qui était assez clair et ça devient un appel à self.endpoint qui est en fait self.resource.mapservice_query :/

• Ne pas garder query_set comme "reverse related name" définir "queries" plutôt (related_name="queries" sur la foreignkey vers resources, je reconnais que ça rajoute de la convention mais query_set c'est trop proche de queryset)

• Tu n'utilises par tes nouveaux delete_view / edit_view dans arcgis.Query

• Dans BaseQuery.as_endpoint() ne pas appeler la copie de endpoint_info, endpoint, ça reste un endpoint_info.

• Je ne comprends pas à quoi sert extra_params..

Je trouve ça bien mais je ne voudrais pas que ça complexifie les vues, le reste ça va.

Merci pour les remarques, je vais les intégrer.

Benjamin Dauvergne a écrit :

• J'aime pas vraiment le self.endpoint / self.called_from

Oui c'est la partie pas sympa du patch.

c'est très spécifique à ces deux implémentations que les query correspondent à un endpoint existant dont on va pré-remplir des paramètres

OK, moi j'imaginais que ce cas d'usage pourrait être amené à se répandre.

je ne sais pas trop ce qu'on y gagne à part que c'est plus complexe à comprendre (trop d'indirections)

Factoriser du code, mais c'est peut-être vouloir trop en faire, je vais m'y repencher, probablement bouger le code dans une méthode statique qui sera appelée si besoin au cas par cas.

• Dans BaseQuery.as_endpoint() ne pas appeler la copie de endpoint_info, endpoint, ça reste un endpoint_info.

Pourtant,

-> endpoint = copy.copy(self.endpoint.endpoint_info)
(Pdb) endpoint.__class__.__name__
'endpoint'

• Je ne comprends pas à quoi sert extra_params.

Le endpoint_info.parameters est utilisé pour construire l'URL d'exemple, mais dans la description de l'endpoint, la liste des paramètre vient du argspec de l'endpoint, donc le extra_params sert dans ce second cas.

Ok, il me semble juste manquer :

+    class Meta:
+        verbose_name = _('Query')