Bonjour Florent, merci pour l’ouverture de ce nouveau service en version beta ! En terme d’interface pas grand chose à redire, on est sur quelque chose qui reste strictement dans le paradigme des portails open data tels qu’ils se font depuis 10 ans. Donc ni mieux ni moins bien que CKAN, OpenDataSoft et compagnie. Je pense que c’était votre objectif, cela peut donc déjà être considéré comme une réussite pour un projet qui part de zéro.
Par contre il me semblait comprendre, après vous avoir aperçu dans le programme des dernières Journées du logiciel libre, qu’il allait s’agir d’un logiciel libre justement. Est-ce que c’est prévu à court terme d’ouvrir votre code ? Cela me paraît essentiel, à fortiori dès la beta, si vous souhaitez réellement recevoir des retours, critiques et propositions.
Par ailleurs, si ne m’abuse, vous n’êtes pas sans savoir que les licences des logiciels que vous dites utiliser vous obligent à citer les titulaires des droits les concernant, voire à redistribuer votre code sous la même licence…
J’ai tenté de créer un compte, mais pas de mail de confirmation.
Sur les données sans compte.
Les points positifs :
super réactif dans la plupart des cas !
beaucoup de jeux de données, y compris courageux (comme les pics de pollution par exemple) !
Proposer les données par fournisseur de données : extra !
La porte d’entrée est forcément une recherche texte ? On ne peut pas directement naviguer par thématique ? (ah, si en faisant une recherche sur champs vide)
J’ai essayer la représentation surfacique des bibliothèques, j’ai cru n’obtenir qu’un fond de carte vierge… parce que les bâtiments en bleu, pou un non-lyonnais, ça peut ressembler à … des pièces d’eau !
Sur la représentation des points de distribution du magazine de la métropole, le principe de l’agrégation en dézoom qui, lorsqu’on zoome, s’éclate jusuq’à donner les points uniques est très bien. Mais comme ça demande un peu de temps, on ne sait pas si cela fait quelque chose ou pas. Mettre un indicateur de moulinage (genre icone de chargement en transparence)
Sur les cartes : “représentation pontuel” ponctuelle, plutôt ?
Mettre la barre de scroll horizontal en haut sur les tableaux de données permettrait de voir les noms de colonne en même temps qu’on y navigue
Faire un jeu de données par année alourdit un peu la navig par rapport à mettre un jeu de donnée avec l’année en colonne (exemple pluviométrie) et oblige des telech multiples pour faire des analyse pluriannuelles.
Certains jeux font un peu “remplissage” par exemple observatoire du bruit : il n’y a que les positions des stations, pas les mesures… utilité ?
En résumé : c’est un bel outil, avec pas mal de données. Je regrette un peu qu’on ne puisse pas faire de croisement entre les jeux de données (par un identifiant de parcelle ou d’iris ou quoi), mais c’est le cas sur tous les portails que j’ai vus àjusqu’à maintenant.
J’espère que ce petit brin de recette t’aide et encore bravo.
Concernant le logiciel libre : nous avons comme ambition de rendre le code open source et exploitable ! Nous sommes donc entrain de créer la documentation nécessaire à l’exploitation, ce qui est assez fastidieux et qui risque de nous prendre encore un peu de temps.
À propos des logiciels utilisés, notre page Crédit en construction les accueillera tous. On espère bien mettre en valeur la construction open source de ce portail.
tes remarques sur l’interface sont très pertinentes.
La représentation surfacique va changer de couleur, car même les lyonnais ne connaissent pas tous les plans d’eau de la ville.
La représentation ponctuelle va elle aussi évoluer en n’agrégeant plus les données proches comme maintenant. Le nombre de données était jusqu’ici trop lent à charger, mais nous avons trouver une solution (passage du WFS au MVT de mapbox).
Ta solution pour la scrollbar dans le tableau va être intégrée, merci !
Le jeu de données par année dépend surtout du fournisseur de la donnée, nous pouvons donc lui suggérer de saisir ses données dans un seul jeu. Ce sera d’ailleurs la même réponse pour les observatoires du bruit, nous avons conscience que toutes les données ne sont pas optimales.
Le croisement de jeux de données est un objectif à plus long terme, qui nécessite un poil de travail en plus.
Pourquoi ne pas ouvrir le code dès à présent ? Cela ne devrait même pas être une question : vu les licences des briques que vous utilisez, vous êtes obligés légalement d’ouvrir le code maintenant, pas dans un futur plus ou moins lointain.
Je serais sincèrement curieux de connaître les réelles frictions qui vous empêchent de le faire. Contacte moi en privé si tu veux en discuter plus tranquillement.
Merci pour le partage d’information. Je rejoins la remarque de m.gousset, il me semble que les thématiques devraient être présenté dés la page d’accueil, car elles permettent à l’internaute de structurer sa recherche.
la vitesse de recherche et d’affichage est « bluffante » et c’est trés agréable de rechercher, parcourir les données (4 onglets clairs et concis).
Juste une remarque dans la prévisualisation carto’, on peut consulter chaque objet géographique, et un clic permet d’avoir en infobulle les attributs de l’objet, pourtant, il n’y a pas de « highlight » de l’objet cliqué, c’est assez déroutant, cf test rapide sur les parcelles cadastrales.
Alors que la selection est visible sur des données à représentation ponctuelle.
De plus, un bouton repoussoir est présent pour masquer les info’ attributaires, ce qui est trés bien, mais les habitudes font que l’on s’attend ce que est plié puis être de nouveau déplié.
La partie pris est ici, une fois « replié », on a perdu la « selection… », c’est peut être un choix de votre part.
Par ailleurs, prévoyez vous une fonctionnalités de catalogue d’attribut ? permettant de connaitre rapidement les noms de champs d’un dataset (et d’avoir un descriptif francisé).
C’est ce que l’on retrouve dans les portail OD classiques.
L’idée de présenter les thématiques sur la page d’accueil est en discussion.
La visualisation carto sur votre exemple dépend du jeu de données. Nous n’avons pour celui-ci que le service WMS qui nous permet l’affichage de png sans pouvoir utiliser le highlight. Le service WFS nous le permet afin de rendre plus interactive l’expérience de la map. Les données cadastrales vont très bientôt passées au format WFS, mais nous aurons encore ce genre de soucis sur d’autres jeux de données. Par contre il semble effectivement logique que le bouton repoussoir reste présent à l’écran, ce retour sera vite intégré.
Rendre les attributs plus compréhensibles reste un soucis car à cause de la grande hétérogénéité des données, on ne peut pas automatiser ce service. On pousse donc à ce que les fournisseurs joignent cette information à leur datasets.
Je vais parler d’expérience, peut-être que ça ne correspond pas tout à fait à la situation du portail du Grand Lyon.
Plus longtemps la base de code est développée de manière fermée, plus ça demande de travail et de vérification pour s’assurer qu’il n’y a pas une bourde tragique : mot de passe qui traine, dette technique plus difficile à corriger qu’à prévenir.
Je comprends aussi que la documentation nécessite du taf’, et que c’était une fonctionnalité attendue pour ouvrir le code. Peut-être que ce n’est pas nécessaire, la décision leur appartient.
J’ai souvent vu des ralentissements d’ordre psychologique (“est-ce qu’on est vraiment prêt ?”) et non technique. On ne sait pas ce qu’il se passe en arrière-boutique, et je trouve ça super que @flaust fasse de son mieux pour assurer la maintenance et assurer le dialogue de l’aspect libre et ouvert.
vu les licences des briques que vous utilisez, vous êtes obligés légalement d’ouvrir le code maintenant
@johan Tu les as vu où les briques justement ? J’en n’ai pas vu trace dans les Mentions Légales (du coup je ne vois pas de quelles licences on parle).
Bien sûr c’est super comme intention d’ouvrir le code et j’ai bien compris que si c’était @flaust qui décidait, ça serait déjà fait. Mais d’expérience, aussi, les projets qui ont dit qu’ils allaient le faire on en vu beaucoup…
Plus longtemps la base de code est développée de manière fermée, plus ça demande de travail
C’est pour ça qu’en général les projets qui ne sont pas développés de façon ouverte ne le sont pas par la suite. S’il n’y a pas de demande venant de l’extérieur, un peu de pression…
Je propose juste mon aide pour y remédier, peut-être de façon maladroite je le concède.
@johan Tu les as vu où les briques justement ? J’en n’ai pas vu trace dans les Mentions Légales (du coup je ne vois pas de quelles licences on parle).
C’est un peu light pour être obligé à ouvrir du code qui s’appuie sur ces briques mais qui n’en fait sans doute pas partie.
Ce n’est pas parce qu’on utilise nginx (qui est en BSD 2-clauses… une licence sans partage à l’identique), qu’on doit ouvrir tout son code en lien sûrement très indirect avec !
D’accord par contre sur le principe d’ouvrir dès le développement… c’est toujours plus compliqué après. Assumer le côté non finalisé fait partie du changement nécessaire de culture.
Outre les diverses remarques déjà faites que je partage, je dois dire que je suis assez bluffé par la qualité de ce portail - sans équivalent à ma connaissance aujourd’hui en libre. Je partage l’invitation à ouvrir - et à documenter la stack technique et, ce qui serait encore plus appréciable, les difficultés rencontrées, les coûts, etc -, on a besoin d’une belle réussite comme celle-ci pour pouvoir offrir le cas échéant aux clients des exemples de différents modèles économiques et techniques.
Dans le détail, je trouve aussi que la home manque un peu de points d’entrée pour les données - thématiques, peut-être données les plus consultées ou autre forme d’éditorialisation.
Dommage quand-même. Les “autres licences” sont de l’OdBL. Les licences associées et engagées correspondent à l’utilisation de services en temps “réel”, soumis à redevance.
il suffit de consulter les licences indiquées. Les OdBL viennent d’ailleurs exclusivement d’ATMO et est tout à fait standard. Sinon toutes les données GrandLyon sont maintenant en Licence ouverte, sauf les Déchetteries mais c’est plutôt un oubli d’attribution je pense (https://data.beta.grandlyon.com/fr/datasets/a589452e-dad2-4168-aa85-5d02299074b3/info)
