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 )
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 ?
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.
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.
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
@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.
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) ?
Bravo à toute l’équipe, heureusement que je ne suis pas tout seul sur ce projet !
Concernant les fichiers CSV : non, il n’est pas possible de les pré-visualiser. @samgoeta, quel fichier souhaiterais-tu pré-visualiser, en particulier ?
deux ans après ce post initial, je viens aux nouvelles concernant la publication du code. Je n’ai pas réussi à le trouver sur le compte github du Grand Lyon, mais c’est peut-être ailleurs. @gsueur@n_vernus_prost vous sauriez me renseigner ?
J’avais cherché récemment et à ma connaissance tout est là :
Si le premier point est strictement respecté (licence AGPLv3 sur tous les dépôts), le deuxième l’est beaucoup moins ! En effet, bon courage à celui qui voudra s’y retrouver dans l’architecture du projet et encore davantage pour espérer faire fonctionner à partir de ce code un portail qui n’est pas en tout point identique à data.grandlyon.com.
Par ailleurs, impossible de créer un compte utilisateur sur forge.grandlyon.com donc je ne peux pas signaler un problème ni faire une proposition de modification (merge request).
Bonjour,
Dans le context d’un cours de Masters à propos de la gouvernance des données géospatiales, un collègue et moi avons choisi la métropole de Lyon comme étude de cas. Notre but est de mieux comprendre le processus de transition vers une infrastructure de données ouvertes. Jusqu’à present, nous avons exploré le portail Data Grand Lyon, étudié les rapports produits pendant les premiers “experiments” ainsi que la litérature académique à propos des infrastructures de données géospatiales et données ouvertes. Nous aimerions aussi inclure des réflexions à ce sujet de la part de personne(s) qui ont participé à son développement. Veuillez m’envoyer un message avant le vendredi 11 mars si vous seriez ouvert(e)s à répondre à nos questions.
)