Le 09/12/2013 17:49, Christian Quest a écrit :
On peut commencer une sorte de cahier des charges de ce que devrait
faire un tel outil d'extraction de données ?
Chic !
Il y a les formats de sortie: CSV, json, geojson, topojson, XML,
shapefile, autres...
Il me semble qu'il y a quatre grandes catégories de formats.
1. pour les **néophytes** : CSV en priorité **mais** je crois me
rappeler que le CSV ne s'ouvre pas toujours facilement dans Excel (en
fait j'ai jamais testé, quelqu'un pour confirmer ?) ; donc ods en xls
seraient bienvenus d'autant qu'on pourrait intégrer la doc des données
dans un onglet de ces fichiers.
Je signale au passage que l'activité Semantic Web du W3C a disparue pour
céder sa place à l'activité Data, tout simplement. Et, acte
emblématique, l'un des deux premiers nouveaux groupes de travail de
l'activité Data est "CSV on the Web" :
http://www.w3.org/2013/05/lcsv-charter.html (ou comment réconcilier web
sémantique et CSV).
2. Pour les développeurs : vont probablement apprécier le JSON et le
CSV, et s'intéresser très timidement au XML, Shapefile, etc.
3. Pour les géogeeks qui apprécieront probablement les *json, XML,
shapefile, etc.
4. Pour linkeddatageeks qui apprécieront du RDF
Voir http://data.ign.fr/ et http://data.insee.fr/ .
Je sais que ça ne va pas être simple mais je ne balancerais pas au
débutant une kyrielle de 10+ formats. A tout le moins, je séparerais les
formats pour débutants avec les autres formats en précisant par exemple
"Exports/formats avancés" ou quelque mention du genre.
On n'est pas obligé d'avoir tous ces formats tout de suite. La catégorie
3 se débrouille déjà bien toute seule. Je pense qu'il vaut mieux
concentrer l'effort sur la catégorie 1.
Il y a les fonctionnalités complémentaires:
- wizard de sélection des POI à extraire
Avant de songer au wizard il peut s'agir de types de POI listés
manuellement (je l'ai fait dans un message plus haut mais je peux le
refaire en listant précisément les tags).
Quelque chose me dit que le wizard ne va pas être simple à établir car
je pense qu'il y a plein de cas bizarres.
- reverse géocodage à différents niveaux (adresse complète, commune, etc)
Le couple code INSEE / nom de commune me paraît essentiel. On sait
certains départements possèdent plusieurs communes homonymes, le code
INSEE doit desambiguiser. Le nom c'est pour lire d'un seul coup d'oeil
ou faire des trucs sympas avec mon tableur : filtres, totaux
intermédiaires, etc. Une fois que le gus a le code INSEE il va pouvoir
croiser ces données avec plein d'autres choses, déduire les
départements, régions, etc.
L'adresse complète ça risque d'être un peu lourd à générer non ? Et j'ai
peur qu'on ai beaucoup d'erreur aujourd'hui non ?
- sélection des "colonnes" (ne récupérer que certains attributs, par
forcément tous
Bof. Moi je mettrais tout. Quel est le problème ? Les débutants feront
le tri dans leur tableur. Sélectionner des colonnes me paraît
complexifier inutilement le process. Ou alors il faut que ce soit une
option qui ne rajoute pas une étape. Ou bien encore on pourrait décider
de supprimer les colonnes qui possèdent moins de 1% d'informations.
En revanche il faut que la liste des colonnes utilisées soit bien
documentée. Chaque jeux de donnée produit devrait donc inclure une page
de doc automatique avec des liens sur le wiki d'OSM. Cette page de doc
pourrait idéalement être produite en plusieurs langues et renvoyer à des
langues différentes sur le wiki.
- simplification géométrique (par exemple ne sortir que le X/Y du
centroid pour les POI surfaciques)
Pourquoi pas, il faudrait voir à l'usage. Mon bémol est que toute donnée
calculée/transformée doit être bien documentée. Idéalement, le travail
de simplification ne doit pas empêcher de télécharger des données plus
brutes.
à compléter bien sûr...
Bé oui. il va falloir voir à l'usage.
je vais essayer de rédiger quelques cas d'usage pour comprendre comment
l'outil pourrait répondre à divers besoins.
Dans les fonctionnalités j'ajouterais :
-- la prévisualisation des X premières lignes de chaque jeu
-- pour chaque colonne la complétude des informations (combien de
cellules remplies sur le total)
-- pour chaque colonne un score de qualité des données (en prenant
certaines des erreurs détectées par osmose)
-- un process d'import automatique dans uMap ou autres outils en ligne
Après il y a des fonctions beaucoup plus anecdotiques dont certaines
font le succès de certains portails open data :
-- le calcul d'un taux de "renouvellement" des données
-- la vue correspondante sur overpass-turbo ou autre
-- la production d'un catalogue DCAT pour que d'autres outils puissent
venir moissonner ces données (dont Etalab)
-- pour chaque jeu, des mots-clés tirés du vocabulaire Eurovoc (utilisé
par plusieurs portails open data)
-- etc.
Dans un premier temps je commencerais par un truc à la Geofabrik
http://download.geofabrik.de/europe.html mais au lieu d'avoir seulement
des zones je mettrais deux entrées :
-- Pages Zone : liste des fichiers CSV-ODS-XLS de X types de POI ; liens
vers les sous-zones (un peu comme Geofabrik)
-- Pages POI : listes des fichiers CSV-ODS-XLS de toutes les zones et
sous-zones pour ce POI
ChN
--
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
