Le 10 décembre 2013 11:36, Charles Nepote <char...@nepote.org> a écrit :
> 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 ?) > C'est vrai et une des premières difficultés c'est l'ambiguïté du format et le fait qu'il soit sensible à la langue de l'utilisateur (particulièrement pour les formats de nombre et de dates, en mettant de côté les gros problèmes d'interprétation et de calcul des dates dans Excel qui utilise un calendrier assez "étrange" pour le moins) Si Excel permet encore de choisir les séparateurs de champs (qui sont eux aussi dépendants de la langue), c'est loin d'être suffisant et ses automatismes qui n'offrent pas de choix sont très agaçants et vont au delà de la nécessité d'utiliser des guillemets ASCII pour éviter qu'il fasse ces fausses interprétations dès l'ouverture (et ensuite d'avoir à tout recorriger manuellement, ce qui est pénible pour ouvrir un fichier contenant de nombreuses lignes). On ne peut pas réellement parler de format CSV universel. Il n'y a même aucun moyen d'éviter des fausses interprétations en cas d'occurrence, au sein d'un champ, de caractères de de ponctuation semblables aux séparateurs de champs, aucun mécanisme d'échappement comme peut en disposer XML ou SGML (et tous les formats basés sur XML ou SGML, dont HTML, XLSX et ODS...). Le format CSV n'est donc adapté que pour des petits fichiers sur lesquels un contrôle manuel est viable, c'est une solution rapide qui ne fait gagner du temps que dans ce cas-là, sinon on a parfois plus vite fait de resaisir entièrement. ---- Mais à mon avis, plutôt que de générer des fichiers plats, on aurait intérêt à plutpot développer une interface de base de données type ODBC (oui c'est un peu vieillot aujourd'hui comme interface même si ça ne gère pas bien le mode transactionnel, mais c'est compatible avec plein de choses, dont la quasi-totalité des moteurs ou clients de base de données) , ou encore plus simplement un schéma XML permettant à Excel d'interpréter directement les extractions en format XML brut (mais pas un format sur le schéma XML basique pour OSM, celui des fichiers .osm, qui n'est pas assez fourni pour faciliter les filtrages et extractions simples). Si on doit avoir une interface facilement réutilisable, le moteur qui les génère doit non seulement pouvoir faire du filtrage, mais aussi pouvoir faire : * des jointures (entre relations parentes et objets enfants, pour les "dénormaliser") ; et * des agrégats (sommes, moyennes... ou assemblage de listes d'éléments en champs unique séparés par des point-virgules, mesures géométriques (longueur de chemin, surface d'un objet, coordonnées d'un centroïde, distance "à vol d'oiseau" mesurée sur une corde ou le long d'un arc d'une projection cartographique courante) ; pour produire alors un fichier "plat" au format XML avec une ligne d'entête interprétable avec un schéma unique, ou au format table HTML (qu'Excel ouvre aussi sans difficulté et sait aussi utiliser comme "source de données"). Actuellement aucune API ne propose des jointures ou agrégats, on n'a que des filtres plus ou moins avancés sur les objets OSM de base. On pourrait aussi ajouter une fonction de tri des données extraites, mais ce n'est pas une nécessité et ça demande des resources plus faciles à gérer du côté du client demandeur plutôt que sur un serveur. Idéalement un certain nombre d'extractions ne devraient même pas nécessiter de générer des fichiers à télécharger mais pourraient n'être que des requêtes accessibles avec une URL unique sur un serveur générant la table associée aux paramètres demandée. Dans Excel alors tout ce qu'on a à préciser c'est l'URL de la source de données, il se charge alors de la télécharger et la garder en cache pour permettre à l'utilisateur de sélectionner les champs qui l'intéressent, et de se remettre à jour plus tard si la source a changé, d'un simple clic.
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
