Alex a écrit 11 commentaires

Alors c'est vrai que le nom GraphDash peut induire en erreur, mais l'objet principal de l'outil est de pouvoir partager des graphes, même s'ils ne sont vus que comme des images. En réalité, tu peux même ne pas mettre d'image (il suffit de ne pas écrire l'attribut name dans les métadonnées), juste texte et titre qui pourront être formaté via markdown (s'il y a du code, il sera coloré avec Pygments). Ainsi tu pourras en faire un blog ;).

Tous les formats sont gérés tant qu'ils le sont par le navigateur. Pour l'extension txt, j'ai ouvert une issue sur GitHub. La raison initiale était que les fichier txt sont directement affichés dans le navigateur et que cela facilitait le debugging, mais il n'y a aucune raison de se limiter à cela.

Je préfère avoir des métadonnées indépendantes de l'image. Comme cela on peut facilement mettre à jour l'image sans toucher aux métadonnées. Aussi les métadonnées sont simples à éditer, par un humain ou par un programme. De plus, tous les formats d'images affichables dans un navigateur sont supportés (jpg, png, etc.), pas uniquement le svg. Les chemins sont relatifs dans les métadonnées (le chemin de l'image par rapport au fichier de métadonnées), donc pas de soucis pour déplacer des dossiers/sous dossiers. Enfin, c'est l'attribut "family" qui permet de classer les images dans des groupes, et on peut passer une liste afin de pouvoir créer une arborescence complète au niveau du site (comme ["category 1", "subcategory"] pour un graphe donné).

GraphDash ajoute la possibilité de naviguer, chercher et partager les graphes facilement (il peut y en avoir des milliers). C'est par exemple utile pour un job qui génère des graphes quotidiennement, et qui seront ensuite disponibles sur cette interface où plusieurs personnes peuvent accéder. En outre, l'interface est configurable (textes, titres, mots-clés).
L'idée est inspirée de Jekyll, le moteur de blog qui se base sur du markdown pour générer un site web statique.

Tout à fait!

L'interface en ligne de commande permet de couvrir beaucoup de cas d'utilisations (recherche, affichage). Pour aller plus loin (requêtes avancées, personnalisation poussée de l'affichage), il faut effectivement utiliser l'API Python (qui est plutôt simple).

Personnellement, je ne suis pas un expert de la chaîne OpenLayer / Geoserver / Postgis. D'après ce que j'ai pu comprendre, les différences sont:

• le stockage: GeoBases utilise des fichiers (en clair), alors que Postgis est une extension de PostgreSQL, donc le stockage est une base de données relationnelle.
• les interfaces: GeoBases permet de faire beaucoup de choses en ligne de commande, et utilise Python "en dessous".
• GeoBases ne se restreint pas aux données géographiques, et permet d'afficher dynamiquement des jeux de données divers.

Nous pensons ajouter d'autres types de visualisations dans les prochaines releases, comme des vues aggrégées.

Comme précisé dans les autres commentaires, OSM est utilisé par défaut depuis hier matin. Nous avons commencé à collecter les différentes remarques, questions et réponses sur le wiki du projet.

Toute critique est la bienvenue :).

En effet pour les input, pour l'instant, je ne supporte que lat/lon, qui est un format très standard.

J'ai quelques outils de conversion déjà présents ici, mais je suppose que je pourrais soit nativement supporter d'autres formats (ce qui me semble ajouter de la complexité pour un gain pas évident), soit juste fournir les outils de conversion directement dans le package.

Tu pensais à un format particulier? Mercator?

Effectivement il devient urgent de créer des pages de wiki :).
Si le fichier est formaté en CSV, l'utilisation suivante doit fonctionner:

$ cat file.csv | GeoBase -i delimiter headers indexes


Avec headers pour le nom des colonnes séparées par un '/', indexes pour les colonnes qui servent d'index. Par exemple:

$ cat file.csv
d1 48.22 2.33
d2 49.33 2.24
$ cat file.csv | GeoBase -i ' ' name/lat/lng name

Pour rajouter file.csv comme un nouvelle source de données permanente, il faut effectivement modifier le fichier YAML.

Si le fichier n'est pas formaté en CSV, il faut utiliser l'API Python pour remplir la base à la main.

Soit on arrive à transformer la source sous forme de file-like, auquel cas on peut loader d'un coup comme ceci (en reprenant le même fichier comme exemple):

>>> from GeoBases import GeoBase
>>> g = GeoBase(data='feed', 
...             source=open('file.csv'),
...             delimiter=' ',
...             headers=['name', 'lat', 'lng'],
...             indexes = ['name'])
>>> g.getLocation('d1')
(48.22, 2.33)
>>> g.visualize()

Soit il faut créer l'objet vide et le remplir à la main comme cela:

>>> from GeoBases import GeoBase
>>> g = GeoBase('feed')
>>> g.set('d1', 'lng', 2.4)  # ces données proviennent d'ailleurs
>>> g.set('d1', 'lat', 48.2)
>>> g.visualize()

Je viens de fixer un bug pour que la dernière ligne fonctionne :).

Enfin "à terme", je voulais dire demain :).

Je viens de commiter l’intégration d'OSM pour la partie fond de carte. Maintenant l'utilisateur a le choix du fond de carte, mais celui par défaut est bien OSM.

L'API javascript utilisée est en revanche toujours Google Maps, le passage à leaflet requiert cependant un peu plus de code à écrire. J'ai mis à jour les images sur le site.

Dans la mesure où ce projet sert notamment à vérifier des jeux de données géographiques en les plaçant avec des fonds de carte, il me semble utile de laisser le choix afin de pouvoir croiser les informations. Par exemple :

$ echo 'd1 48.22 2.33\nd2 49.33 2.24' |GeoBase --map


Effectivement Google Maps a de bonnes alternatives. Je pense que c'est envisageable d'utiliser des fonds de carte libres à terme.