Mais ça ne résoud pas la question des valeurs réellement trop longues (dont opening_hours, qu'on ne peut toujours pas découper facilement, d'autant que cette proposition pour v0.7 ne concerne QUE les valeurs multiples sans aucun ordre de tri significatif, alors que opening_hours impose un ordre précis d'interprétation). Si on doit respecter un ordre et pouvoir découper les valeurs longues, il faut un système permettant le réassemblage correct des multiples valeurs et ne pas imposer un découpage seulement sur certains caractères (comme le seul point-virgule qui ne suffit pas aux données structurées).
C'est pour ça que j'ai émis la proposition de valeurs dans un format compatible JSON (mais un JSON simplifié, avec quelques règles d'équivalence, et où on n'impose pas les quotes) et où existe des règles sur les noms des clés (distinction des clés qui sont des entiers pour les valeurs séparées mais ordonnées, des identifiants opaques pour les valeurs dans un ensemble sans tri significatif, et des autres identifiants clairement nommés pour les tags conventionnels et documentés). Dans ce cas on peut tout représenter plus facilement sous forme d'objets structuré contenant des propriétés et sous-propriétés, comme autant de tags et sous-tags possédant chacun une clé suivant les conventions et la possibilité de créer un "chemin de clés" bien défini (mais potentiellement très long) vers n'importe quel propriété ou sous-propriété, au lieu d'une syntaxe limités avec beaucoup de redondance avec le système des préfixes et suffixes délimités par des ":") Ce JSON simplifié, compactable, aurait des règles d'analyse précises et non ambiguës. Il resterait très lisible même pour une utilisation directe, juste quelques règles pour encapsuler les quotes dans les valeurs ou les crochets ou signes "="), et éventuellement si on a besoin d'un signe d'échappement comme "\" pour les quelques caractères encore réservés si on les veut dans les valeurs: \\ ou \" ou \' ou \= ou \[ ou \] ou \ (concernant les quotes je suis plutôt partisan de les ôter partout comme délimiteurs de chaines, pour ne pas avoir non plus à les échapper avec un "\". Il ne resterait alors plus que \[ ou \= ou \] ou \\ qui se rencontreront très peu souvent dans quelques valeurs, et pas du tout dans les noms des clés standards. Donc peu de risques d'erreurs. Et cela n'empêche pas d'avoir des "valeurs très longues" étant donné qu'on peut les fragmenter et les réassembler dans un ordre précis, sans aucun séparateur supposé (comme le ";" séparateur des listes non ordonnées, ou le "," pour certaines listes ordonnées et pour le ":" dans les clés actuelles). Le mar. 5 mai 2020 à 16:44, Yves P. <[email protected]> a écrit : > Pour faire suite à mon message précédent sur les tags longs, j'aimerais > aussi discuter à propos des tags avec des valeurs multiples (séparées par > des ; ) > > J'ai lu un article d'Andy Allan (l'un des développeurs du site web d'OSM) > au sujet d'une mise à jour en "douceur" de l'API : > Smoother API upgrades for OpenStreetMap > <https://blog.gravitystorm.co.uk/2019/10/17/smoother-api-upgrades-for-openstreetmap/> > > Il ne parle pas de ce point. Par contre on l'avait abordé sur cette liste. > Il est accessoirement évoqué sur la page concernant la future API v0.7 > <https://wiki.openstreetmap.org/wiki/API_v0.7#Areas> > > > Ce point est explicitement évoqué dans la page précédente : > https://wiki.openstreetmap.org/wiki/API_v0.7#Multiple_Tags > > Je propose que la version 0.7 gère des tags de plus de 255 caractères :) > Et pour le passage en douceur, que ce tag soit découpé/réasssemblé > automatiquement en plusieurs tags pour les logiciels fonctionnant en v0.6 > > > La solution proposé ressemble assez à ma proposition pour les grands tags > (on coupe la valeur arbitrairement tous les 255 caractères). > > Ici, on coupe/réassemble à chaque séparateur (fonctions SPLIT / EXPLODE de > certains langages) > > Exemple : > > v0.7 > > my_tag=value 1 > my_tag=value 2 > my_tag=value 3 > > donnerait en 0.6 > my_tag=value 1;value 2;value 3 > > Si la valeur est trop grande, on combine ça avec ma proposition précédente > (en essayant si possible de couper au niveau d'un séparateur) > > C'est compatible avec tous les éditeurs et une fois tous les outils en > v0.7, TagInfo permettra de compter "correctement' les tags utilisés. > > __ > Yves > _______________________________________________ > Talk-fr mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk-fr >
_______________________________________________ Talk-fr mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-fr
