en fait même pas, c’est un jeu de données parent, dont les deux enfants sont bien en licence ouverte.
On m’a interrogé sur la stack technique utilisée. Sur le front-office je n’ai pas une connaissance suffisamment précise de l’environnement pour répondre. Pour ce qui est du back-office, dont Neogeo s’occupe depuis… 6 ans déjà ?, c’est resté relativement standard : MapServer pour les services cartographiques, Geonetwork pour le catalogue (et oui!), Postgis pour les BD, avec alimentation via FME et création automatique des services lors de la publication d’une nouvelle ficher de métadonnées. Quelques développements python pour faire tourner le tout, gérer les comptes utilisateurs et leurs droits… De vraiment nouveau avec cette version il y a le moteur de recherche, sur lequel on a beaucoup travaillé afin qu’il gère les autorisations (et que vos recherches se fassent dans les jeux de données auxquels vous avez accès et pas les autres) basé sur ElasticSearch. Il indexe ainsi à la fois les métadonnées et les données, avec des profils paramétrables. Ce n’est donc pas Geonetwork qui est interrogé directement. Il y a d’autres composants en gestation, mais dans la version bêta en ligne c’est à peu près tout ce qu’il y a de “nouveau” en back-office, l’effort ayant été mis sur l’ergonomie et la performance. J’aime beaucoup le constructeur de requêtes WMS/WFS, c’est plutôt pédagogique. Tous les services carto proposent aussi du MVT maintenant (avec un petit cache Nginx), on va essayer de mieux mettre ça en valeur.
1 « J'aime »
Nous vous remercions pour toutes les contributions et vos remarques. L’enjeu de l’ouverture de cette version beta est bien de recueillir les retours des utilisateurs… et également des experts : merci à vous !
Au-delà de vos encouragements – et là encore nous vous en remercions – j’apporte quelques précisions suite aux remarques que j’ai pu parcourir et je laisserai Alessandro Cerioni (chef de produit de la plateforme et qui a brillamment porté le projet), compléter :
-
La forge métropolitaine devrait être mise en ligne dès cet été 2019 avec les briques de la plateforme data.grandlyon, nous espérons qu’une communauté active se constituera autour de ces développements,
-
Une page dédiée aux mentions/copyright/sources de toutes les technologies utilisées par la plateforme est en cours de création (nous sommes sur une beta, il y a encore des ajustements en cours) et bien entendu, elle est essentielle,
-
Concernant les licences, 99% des données de la plateforme data.grandlyon sont en Licence Ouverte. Et pour mémoire, la Métropole de Lyon a élaboré deux licences spécifiques (“engagée” et “associée”) qui ont fondé le cadre de confiance local et qui ont un objectif : s’assurer de la compatibilité des utilisations des données avec les politiques publiques, en garantissant la cohérence des actions publiques/privées menées sur le territoire, en veillant à ce qu’elles n’aillent pas à l’encontre de l’intérêt général (exemple : utilisation des données du trafic en temps réel de la Métropole pour alimenter une application encourageant explicitement l’usage de l’automobile en ville versus promotion des modes doux par la collectivité, ou encore développement d’un service réorientant le trafic automobile du fait des bouchons sur des voiries à préserver : zones résidentielles, écoles, hôpitaux…).
La Métropole de Lyon souhaite pérenniser ce socle de valorisation de la donnée, expérimenté avec succès depuis plus de 6 années, auprès des producteurs (publics ET privés) comme des réutilisateurs de données territoriales. La Métropole de Lyon a donc entamé une démarche auprès de l’État, de demande d’homologation d’une licence – Licence de réutilisation des Données d’intérêt général - amenée à remplacer ces deux licences spécifiques, et rédigée afin d’avoir une portée universelle (quel que soit le territoire où elle s’applique, le type/la catégorie de donnée…).
La Métropole de Lyon souhaite partager ainsi un outil de régulation permettant, comme cela a été fait sur le territoire métropolitain, de favoriser l’ouverture des données des acteurs publics comme privés, d’encourager globalement la valorisation des données sur les territoires et au bénéfice de ses usagers, dans le respect des politiques publiques.
-
Concernant l’éditorialisation de la donnée, nous avons deux axes de développement : une approche journalistique à chaque publication de nouvelle donnée et une valorisation des réutilisations via une page dédiée à venir par une série d’interviews, d’analyses des réutilisations opérées… La montée en puissance éditoriale se fera d’ici la fin d’année 2019.
-
Le développement de la plateforme a été réalisé en méthode agile et nous entrons dans une conduite de projet d’amélioration en continu de la plateforme : vos contributions et réflexions sont les bienvenues, un grand merci à nouveau pour vos contributions.
4 « J'aime »
Bonsoir à tous,
Merci énormément pour vos retours, qui nous aident à améliorer notre réalisation.
En attendant la mise en place d’une page spécifique, on a mis à jour la page Mentions légales avec un paragraphe, “Crédits”, qui mentionne toutes les solutions logicielles ouvertes que nous utilisons.
Concernant l’ouverture du code source, il n’y a aucune “friction”. On va sûrement le faire (j’en profite pour vous signaler ce document, Délibération de la Commission Permanente du 18/06/2018, qui précise la posture de la Métropole de Lyon vis-à-vis de l’Open Source). On se donne juste le temps de bien documenter tout ce qui a été réalisé jusqu’à présent, nettoyer le code et le généraliser le plus possible, pour que nos développements deviennent vraiment réutilisables par d’autres organisations, et pour qu’ils puissent accueillir les contributions de la communauté.
Bonne soirée,
Alessandro
P.S. : Une petite précision sur la spécification MVT : pour l’instant, on l’utilise seulement pour l’affichage du fond de carte ; prochainement on l’utilisera aussi pour afficher les points d’intérêt.
5 « J'aime »
J’adore ce genre de délibération qui ne sert finalement à rien vu que c’est la simple application de la loi.
Quelle énergie perdue… mais bon au moins la conclusion va dans le même sens que la loi, ce qui n’est pas toujours le cas !
énergie perdue je ne crois pas, ça permet aux services d’acter la politique de la Métropole et de l’appliquer sans délai, d’éviter aux citoyens de se heurter à un mur quand ils veulent accéder aux sources, et de saisir la CADA etc… donc pour une délibération technique vite votée, que de temps de gagné ensuite ! La loi a beau exister, les fonctionnaires territoriaux appliquent d’abord la politique de la maison. il n’y a qu’à voir les modalités des marchés publics, 1 loi, 100 façons différentes de faire !
Vu sous cet angle…
Je suis tellement naïf en croyant qu’il suffit juste d’appliquer la Loi !
Admettons quand même que ça devrait fonctionner comme ça même si ce n’est pas le cas.
Bonjour,
Merci pour cette nouvelle version de la plateforme. La possibilité de contacter le producteur de la donnée est particulièrement intéressante pour les chercheurs qui souhaitent comprendre plus en détail les modes de production de la donnée.
A propos des possibles évolutions pour rendre plus pertinente la mise à disposition des données, je suggère de mettre en avant les réutilisations directement sur chaque page du jeu de données. Ca permettrait de donner un premier ordre d’idée du potentiel de réutilisation et ça pourrait accroitre la confiance envers leur fiabilité. (Accessoirement, ça faciliterait les travaux de recherche qui essaye de retracer le cycle de la donnée dans l’écosystème open data lyonnais 
)
Bonjour,
félicitations encore pour le portail très réussi qui renouvelle le paysage.
Je me demandais : est-ce qu’il est possible de prévisualiser un tableau de données pour des données non-géographiques (facette type > non géo) ? J’ai cherché mais je n’ai pas trouvé. Est-ce une limitation du portail ?
Concernant les fonctionnalités, est-ce que vous envisagez la production de graphiques simples directement à partir du portail ?
Bonjour, et merci pour ces encouragements.
On peut trouver dans les facettes le filtre « Type » : géographique ou non géographique.
Nous travaillons actuellement à pouvoir filtrer parmi les datasets géographiques les objets ponctuels, linéaires et surfaciques.
Nous avons effectivement envisagé la production de graphiques, mais ils ne sont pas la fonction première du portail, et c’est donc une fonctionnalité qui peut arriver bien tardivement.
Je pense que la (première) question de @samgoeta portait sur la possibilité de voir les (premiers) enregistrements d’un jeu de données non-géographiques sans avoir à télécharger le fichier. Par exemple sur ce fichier : https://data.beta.grandlyon.com/fr/datasets/abreviation-types-voies-metropole-lyon/info.
@samgoeta, voici les réponses à tes questions :
-
Actuellement la visualisation tabulaire des données est limitée aux jeux de données géographiques. Donc oui, c’est une limitation du portail. En effet, pour l’instant toutes les données sont indexées dans Elasticsearch à partir d’une base PostGIS. Il faut qu’on implémente les connecteurs vers d’autres types de sources, notamment les fichiers CSV.
-
Oui, on aurait envie de permettre aux utilisateurs de produire des graphiques, mais ce n’est pas pour tout de suite. À court terme on publiera une évolution permettant d’afficher le tableau et la carte en même temps.
1 « J'aime »
Une base postgis est avant tout une base postgresql… et postgresql sait utiliser les csv directement sans même les importer avec son foreign data wrapper fdw_csv 
1 « J'aime »
@cquest, quelle serait la valeur ajoutée de PostgreSQL dans la tâche d’indexation dans Elasticsearch de fichiers CSV ?
N.B. : L’indexation des métadonnées - venant de GeoNetwork - et des données - venant de PostGIS - est faite, aujourd’hui, avec des scripts Python « reliés » par RabbitMQ.
Comme vous indiquez que ES indexe les données à partir d’une base postgis, j’en déduis qu’ES se connecte à postgres, et pourrait donc accéder aussi aux données CSV via postgres et un foreign data wrapper sans même importer les données dans PG.
Ce qui manquera pour des CSV, ce sont les metadonnées, mais si les dataset sont déjà présents dans la recherche c’est que des métadonnées ont été indexées pour eux mais pas leur contenu.
Une question concernant l’API rest/json afin de coder un archiveur dédié pour opendatarchives…
Je ne vois aucune métadonnée disponible via cette API, en particulier les dates de publication, de mise à jour des métadonnées et/ou du contenu du jeu de données, la licence du jeu de données, etc.
Pas trouvé non plus de moyen de récupérer via l’API la liste des pièces jointes associées à un jeu de données (si il y en a).
Dans notre workflow d’indexation, Elasticsearch ne se connecte pas directement à PostgreSQL. Comme je le disais dans mon précédent message, l’indexation est réalisée par une collection de scripts spécifiques développés en langage Python, utilisant RabbitMQ pour communiquer entre eux.
Les métadonnées sont portées par l’application GeoNetwork. Vous pouvez y accéder en utilisant ses API. Voici un exemple de requête : https://download.data.grandlyon.com/catalogue/srv/fre/q?_content_type=json&resultType=details&fast=index&buildSummary=false. Si vous souhaitez cibler un jeu de données en particulier, vous pouvez ajouter le paramètre uuid, ex. : https://download.data.grandlyon.com/catalogue/srv/fre/q?_content_type=json&resultType=details&fast=index&buildSummary=false&uuid=d58bc748-2adc-47e1-adc3-426887f2a2dc.
Côté CKAN ça avance, exemple avec :
- http://files.opendatarchives.fr/data.agglo-royan.fr/
- http://files.opendatarchives.fr/data.coeurcotefleurie.org/
C’est quand même pas le plus simple à archiver !
La fonctionnalité permettant de présenter les données sous forme à la fois tabulaire et cartographique est désormais en ligne, ex. : https://data.beta.grandlyon.com/fr/jeux-de-donnees/stations-velo-v-metropole-lyon-disponibilite-temps-reel/donnees.
Je vous remercie d’avance pour vos retours !
2 « J'aime »
Bravo @acerioni, le rendu est vraiment top !
Est-ce qu’il est possible de pré-visualiser un csv dont les enregistrements ne comportent pas de propriétés géographiques (sans carte) ?