[OSM-talk-fr] Tags multiples dans OSM (API v0.7)

[Philippe Verdy]

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. <yves.pratter at gmail.com> 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
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20200506/08d92b5f/attachment.htm>