Excel ne sait pas traiter n'importe quel XML ou fait n'importe quoi si on
ne lui donne pas un schéma d'accompagnement.
Pour les cas compliqués, il faut parfois utiliser une source type ODBC ou
autre interface base de données pour XML.
On pourrait imaginer le développement d'un plugin connecteur de base de
données pour Excel qui facilite les requêtes.
Oui je sais, yakafaucon... Pour ça il faut un développeur pour le réaliser
et le maintenir. Mais ça existe peut-être déjà avec un connecteur GIS, sans
doute préférable et plus facile à utiliser qu'un connecteur XML générique
sans schéma.
D'autant plus qu'OSM n'a pas de schéma stable, on doit s'appuyer sur une
conversion OSM vers GIS maintenue à part; la solution avec Overpass ne fait
guère que rapporter des données OSM sans réel schéma autre que les 3 types
d'objets de base (noeud, chemin et relation) et oblige à chercher soi-même
les correspondances ou équivalences de tags (le résultat est une requête
Overpass assez compliquée à réaliser et lire, et qui oublie bien des tas de
cas compliqués, pourtant résolus et maintenus à jour dans OSM2GIS).
Bref si on veut faciliter la réutilisation des données, c'est moins les
exports OSM bruts (y compris Overpass) qu'il faut promouvoir, que leur
conversion dans un format GIS exploitable de différentes façons.
Et pourquoi pas avoir une base GIS en ligne directement chargée et
maintenue à jour avec les données OSM en live ? Avec une riche palette de
"features" supportés et documentés ? (la base OSM native ne serait plus que
la base de travail pour les éditeurs et importations de données).
Et peut-être aussi à l'avenir la possibilité d'éditer des données en
passant par la base GIS (laquelle relaiera les infos vers la base OSM
native, en utilisant le compte OSM associé au compte GIS et en utilisant
les meilleurs tags recommandés). Cela aurait aussi un avantage : ne pas
noyer les nouveaux-venus sous des tas d'autres données, en lui permettant
de sélectionner les couches GIS qui l'intéresse sans toucher au reste. Mais
le problème est sans doute l'absence d'assez d'outils libres pour
travailler en ligne sur une base GIS.
Pourtant un tel développement permettrait à nos fournisseurs actuels de
données libres de pouvoir contribuer à OSM directement avec leurs outils
GIS (même propriétaires) et un connecteur simplifié (qui facilite le long
travail manuel de fusion avant importation).
Le 5 décembre 2013 20:03, Ista Pouss <ista...@gmail.com> a écrit :
> De mon coté je suis peu réceptif aux idées style "le XML (et maintenant le
> JSon, donc ! ) ( Arf ! Arf ! Arf ! ) c'est compliqué le reste (CSV, ici)
> c'est bien" ("je caricature / je plaisante" précise toujours l'émetteur).
>
> S'il caricature, qu'il dise en quoi ? Établit-on un projet informatique
> avec des caricatures ?
>
> S'il est sérieux, qu'il assume et qu'il explique mieux.
>
> Avec Excel, on peut transformer n'importe quel XML en CSV. Donc, c'est
> bon, non ?
>
>
>
> (Je plaisante...)
>
>
>
> Le 5 décembre 2013 19:13, Charles Nepote <char...@nepote.org> a écrit :
>
>> Bonjour à tous !
>>
>>
>> **Résumé du message** : comment diffuser et voir réutilisées les données
>> d'OSM auprès d'un public plus large, qui, dans un cercle vertueux, pourra
>> devenir contributeur.
>>
>> Souvent j'ai l'occasion de dire ici ou là que "telle donnée est dispo
>> dans OSM". Par ailleurs, je pousse depuis un certains temps les acteurs
>> publics à référencer sur leurs portails les données d'OSM : ainsi de
>> Montpellier, le CG de la Gironde, la Région PACA, etc.
>>
>> Mais aujourd'hui, les jeux de données ou les outils de consultation d'OSM
>> ont du mal à répondre à plein de petits cas tout simples comme : "je veux
>> la liste des pharmacies de ma région". Et "je veux pouvoir manipuler cette
>> liste dans mon tableur favori parce que c'est l'outil que je connais bien".
>>
>> Je me suis donc interrogé : comment produit-on simplement des données
>> d'OSM sous forme de fichiers CSV ? Je sais bien que tout n'est pas
>> extractible en CSV mais il y a un champ d'usage immense sur les données
>> comme :
>> * les bâtiments publics
>> * les médecins, hôpitaux, pharmacie...
>> * les lieux/services de secours (casernes de pompier, défibrilateurs,
>> pompes incendies, téléphones de secours)
>> * les lieux de culture (Théâtres, Musées, etc.)
>> * les lieux d'histoire et du patrimoine
>> * les arrêts de transports en commun
>> * les terrains/équipements sportifs
>> * les lieux touristiques
>> * les systèmes de surveillance (caméras de surveillance)
>> * les commerces
>> * les hameaux
>> * les services relatifs aux déchets (bennes de recyclage, poubelles,
>> déchetteries, composteurs publics, etc.)
>> * etc.
>>
>> Je suis donc allé grenouiller dans les outils (je précise que je n'ai
>> jamais installé QGIS, Postgis, etc., je n'ai jamais utilisé l'API OSM, je
>> ne fais pas dev mais j'ai quelques années d'expérience sous Linux).
>> Et le plus simple que j'ai trouvé c'est la combinaison de osmconvert e et
>> osmfilter.
>> http://wiki.openstreetmap.org/wiki/Osmconvert
>> http://wiki.openstreetmap.org/wiki/Osmfilter
>>
>> Je peux obtenir le fichier CSV de toutes les pharmacies de PACA en 4
>> lignes de commande :
>> $ wget http://download.geofabrik.de/europe/france/provence-alpes-
>> cote-d-azur-latest.osm.pbf # télécharge le fichier OSM de la Région PACA
>> $ ./osmconvert32 provence-alpes-cote-d-azur-latest.osm.pbf
>> -o=provence-alpes-cote-d-azur-latest.o5m # conversion du dit fichier
>> dans un format lisible pour osmfilter
>> $ ./osmfilter32 provence-alpes-cote-d-azur-latest.o5m
>> --keep="amenity=pharmacy" > PACA-pharmacies.o5m # filtrage proprement dit
>> pour ne retenir que les pharmacies
>> $ ./osmconvert32 PACA-pharmacies.o5m --all-to-nodes --csv="@id @lon @lat
>> amenity shop name" --csv-headline > PACA-pharmacies.csv # conversion du
>> fichier filtré en CSV
>>
>> (Peut-être qu'on peut faire encore plus simple et plus rapide mais cette
>> méthode à l'avantage d'être scriptable et automatisable facilement pour
>> publier ces fichiers sur un serveur web.)
>> Résultat : 1220 pharmacies identifiées et géolocalisées. J'aurais pu
>> ajouter les adresses, les téléphones, etc. quand ils sont renseignés (c'est
>> rare). (Il y a cependant des petits problèmes dans ce fichier comme les
>> distributeurs de préservatifs (n'est-ce pas utilisateur cquest
>> http://www.openstreetmap.org/node/2368452297 :D .)
>> Il faut compter environ 8-10 minutes pour l'ensemble du process sur ma
>> machine (compris le téléchargement des 200+ Mo du fichier PACA).
>>
>> **Pourquoi je creuse ça ?**
>> * OSM est une platforme déjà bien en place pour crowdsourcer énormément
>> de données et s'enrichit à grande vitesse
>> * OSM a une dimension nationale et internationale
>> * Mais OSM a du mal à fournir ses données autrement que par la carte ou
>> par des fichiers XML assez obscurs et difficiles à manipuler par le
>> néophyte (je caricature un peu et je ne connais sans doute pas toutes les
>> initiatives)
>> * Produire régulièrement des extractions en CSV devrait permettre :
>> 1. de fournir des données à des néophytes qui pourront la réutiliser
>> de manière simple
>> 2. de permettre à des tas de gens de découvrir et utiliser OSM comme
>> plateforme de coproduction de données
>> 3. de faciliter la coproduction de certains types de données : avec
>> ces tableaux, je peux maintenant plus facilement organiser une cartopartie
>> thématique sur les cinémas, les bibliothèques, les sex shop ou que sais-je
>> encore...
>>
>> Aujourd'hui, un des problèmes des fichiers open data des acteurs publics
>> est que le feedback (ajouts, correction) est une fonctionnalité très mal
>> organisée (c'est un euphémisme). OSM permet d'aller au-delà.
>>
>> Ma question est la suivante : est-ce que ça ne vaudrait pas le coup de
>> réserver un espace, par exemple sur http://openstreetmap.fr , où publier
>> de l'information pré-mâchée en CSV ?
>> L'idéal pourrait aller jusqu'à fournir une interface permettant de
>> générer soit-même des fichiers en rendant public ces fichiers pour les
>> autres.
>> Je veux bien aider à la définition des catégories de données et je
>> passerai aussi du temps à convaincre les acteurs publics de référencer ces
>> données sur leurs portails open data.
>> Qu'en pensez-vous ?
>>
>>
>> Charles Nepote.
>> http://www.openstreetmap.org/user/CharlesNepote
>>
>>
>> _______________________________________________
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
>
> --
> Les dérives de rue :
> C’est chanter que je veux <http://drivrsdu.fr/cest-chanter-que-je-veux/>
> <http://drivrsdu.fr/profession-emotion/>
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
