Heu... Philippe, je voulais surtout plaisanter avec cette histoire de tiret quadratin en XML, je m'excuse que ça n'ait pas été clair. C'était par rapport au flot de messages sur ce sujet, fort intéressant d'ailleurs, mais l'énormité des discussions pour un simple caractère me semblait propice à quelque humour ? Le mien semble maladroit, bon...
Merci tout de même pour cette analyse critique du XML dans un champ name : comme je débute OSM, cela me permet de me faire une idée de ce qu'on peut faire et ne pas faire, ainsi que tout le débat sur le tiret quadratin d'ailleurs. Avec toutes mes excuses encore une fois. Le 30 novembre 2012 07:41, Philippe Verdy <verd...@wanadoo.fr> a écrit : > Heuuu... du XML au milieu des champs name ??? Franchement non (même si le > shéma OSM peut être exporté en XML, ce n'est définitivement pas la seule > option. Voire du XML natif importé dans une base OpenGIS et supposer que > les moteurs de rendus ou d'analyse devront en plus réanalyser du XML n'est > pas une bonne idée). > > Les champs name=* ne doivent contenir que du texte destiné à être lu par > un humain (la seule exception étant pour les langues qui ne satisfont pas > du seul jeu de caractère codé dans leur écriture, comme les hiéroglyphes, > et qui nécessitent un protocole supplémentaire pour les afficher sous forme > lisible par l'homme. > > Et pourquoi tu penses que le tiret cadratin est juste franco-français ? Là > où il est il n'a pas de langue attachée. On précise la langue dans les > suffixes de code langue des clés OSM pour la valeur entière. Bref rien à > voir. > > Un seul caractère suffit par lui-même ici, sans aucun autre protocole et > sans supposer qu'il désigne une quelconque langue ou une orthographe (pas > plus que la lettre "a" ne désigne pas autre chose que cette lettre mais pas > les langues ou orthographes qui en font usage). > > En plus techniquement c'est bien plus compliqué à supporter (alors qu'il > n'y a aucun soucis pour le rendu ou l'analyse et les recherches avec le > seul caractère codé) et ta solution obligerait à modifier TOUS les outils > actuels en dégradant sévèrement en plus leurs performances (une couche de > parseur XML en plus, pour la moindre chaîne de libellé localisable et plus > moyen de faire fonctionner les outils sans aucun parseur XML difficilement > intégrable par exemple dans un moteur SQL, alors que les moteurs SQL font > parfaitement de la recherche plein texte avec leur support des > "collations", alias UCA). > > Bref tu dis "compatible", mais avec qui ou quoi ? Si c'est pour une seule > appli particulière, c'est contre les fondements de la base de données OSM. > > Le 30 novembre 2012 07:02, Ista Pouss <ista...@gmail.com> a écrit : > >> >> Pour moi la difficulté est maintenant de trouver l'ID d'une ligne ; j'ai >> lu ta page http://wiki.openstreetmap.org/wiki/Caen/Transports_en_communque >> tu as indiqué dans ton premier message, mais je n'ai pas compris >> comment je faisais pour trouver un ID avec ça. J'ai trouvé par chance une >> ligne de bus sur Caen, avec une relation "route_master_bus" et un ID de >> 2589274/1 (à http://osm.org/go/ervfqnf64-- ), mais ton logiciel a >> rouspété à cause du "/1", je l'ai supprimé (vous voyez que je suis un vrai >> geek), et j'ai obtenu ce que je donne en intro de ce message. >> >> De plus, je tiens à dire qu'il me semble que le tiret quadratin pourrait >> être avantageusement remplacé par l'expression <tiretQuadratin >> id="58901:AI97" class="onTiretQuadratin" lang="FR-fr"/> qui a l'avantage >> d'être compatible.. >> >> _______________________________________________ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-fr >> >> > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
