[OSM-talk-fr] OSM 2 CSV : l'open data d'OSM pour tous publics ?

[Charles Nepote]

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/