<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">Le 10 décembre 2013 11:36, Charles Nepote <span dir="ltr"><<a href="mailto:charles@nepote.org" target="_blank">charles@nepote.org</a>></span> a écrit :<br>


<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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 ?)<br>


</blockquote><div>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</div><div><br></div><div>(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)</div>


</div></div><div class="gmail_extra"><br></div><div class="gmail_extra">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).</div>


<div class="gmail_extra"><br></div><div class="gmail_extra">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...).</div>


<div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>


<div class="gmail_extra"><br></div><div class="gmail_extra">----</div><div class="gmail_extra"><br></div><div class="gmail_extra">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).</div>


<div class="gmail_extra"><br></div><div class="gmail_extra">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 :</div><div class="gmail_extra">


<br></div><div class="gmail_extra">* des jointures (entre relations parentes et objets enfants, pour les "dénormaliser") ; et</div><div class="gmail_extra"><br></div><div class="gmail_extra">* 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) ;</div>


<div class="gmail_extra"><br></div><div class="gmail_extra">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").</div>


<div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>


<div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>


<div class="gmail_extra"><br></div></div>