[OSM-talk-fr] Limite de 255 caractères dans les tags OSM

Philippe Verdy verdyp at gmail.com
Mar 5 Mai 21:45:57 UTC 2020 

Cela ne dit pas comment les clés _1, _2 seront assemblées en une seule: en
séparant les valeurs par des point-virgules, des virgules, des espaces ou
rien du tout (concaténation simple).

L'usage actuel serait que des valeurs multiples sont dans des _1, _2, etc.
séparés et que leur séparation par défaut serait alors le point-virgule (ce
que fait déjà iD et certains éditeurs pour des valeurs multiples ou
différentes après une fusion de deux objets: ces _2 sont plutôt
l'indication d'une erreur ou ambiguïté à traiter manuellement, l'éditeur
ayant été incapable de choisir entre des valeurs potentiellement
incompatibles)...

Mais alors cela ne résoud toujours pas le problème des valeurs longues où
ce point-virgule "'implicite" sera faux (par exemple les balises
"opening_hours" qui ont des règles spécifiques de séparation).

Si OSM doit évoluer, c'est pour permettre des valeurs de balises
"structurées". Actuellement les balises sont de simple tableaux
unidimensionnels avec une clé unique quasiment opaque.

L'évolution normale serait d'avoir un balisage de type DOM: chaque objet
OSM dispose d'un tableau associatif de clés dont les valeurs seraient: soit
une chaine, soit un autre tableau associatif avec ses propres sous-clés; de
quoi mettre fin alors aux conventions de nommage des clés avec le ":" et
autres "_" ; la seule nouveauté étant en fait sur les valeurs de clés et
non les clés principales des balises).

Et sa représentation en JSON ou XML est simplissime: actuellement un tag
OSM est un unique élément XML, et la valeur du tag OSM est codée comme la
clé OSM dans des attributs d'élement XML; cette valeur OSM pourrait être
plutôt dans le contenu de cet élément, qui serait: soit du texte, soit
d'autres tags OSM... (un peu comme le HTML avec son "mixed content model").
Mais encore mieux: on peut aussi garder cet attribut XML mais n'admettre
alors dans le contenu de la balise XML QUE d'autres tags OSM
réprésentés comme éléments XML

Et dans ce cas, un tag OSM est valide si l'attribut de valeur est vide mais
s'il y a des tags OSM codés dans le contenu de l'éléments XML. Il est alors
possible de faire une bijections avec une représentation "compacte" où les
valeurs simples ou composées seraient toutes codées en JSON : si une valeur
en attribut commence par "{", elle doit finir par "}" et doit être un
tableau associatif au format JSON valide ; si cette valeur commence par
"[", elle doit finir par un "]" et être une liste ordonnées JSON valide
(équivalente aussi à un tableau associatif indexé par des entiers naturels
implicites).

L'avantage de cette méthode serait que dans la base de données, on n'a plus
de limites en nombre de clés, les valeurs trop longues sont convertibles en
liste ordonnée (tableau associatif indexé par des entiers), aucun
séparateur implicite n'est imposé, on n'a plus besoin des ";" dans les
valeurs qui seront plutôt converties en sous-liste:

Par exemple le tag:
    "truc" = "valeur1;valeur2"
devient
    "truc" = "[_1='valeur1','_2='valeur2'}"
en format JSON préservant la séparation des valeurs par l'utilisation de
clés "_1", "_2" arbitraires dans une table associative. Toutes les valeurs
longues sont encore possibles:
    "truc" = "{_1=['valeur1a', 'valeur1b'], '_2='valeur2'}"

Cela représente l'arbre "DOM" suivant (où les "valeurs longues" ont été
concaténées :

  'truc'
    |
    +--> '_1' --> 'valeur1avaleur1b'
    |
    +--> '_2' --> 'valeur2'

Ou encore les tags OSM classiques (si y admet les valeurs longues, et en
supposant que ":" reste utilisé pour structurer les clés qui du coup ont un
problème de taille et de duplication des préfixes):

    "truc:_1" = "valeur1avaleur1b"
   "truc:_2" = "valeur2"

Et si on veut pour OSM, on peut utiliser un format JSON "simplifié" pour
les tables et listes: pas d'obligation de mettre les clés ou valeurs entre
quotes simples ou double, tant qu'elles ne contiennent pas de ',' ni
parenthèses ni crochets, ni guotes, et les espaces touchant les "{}", ou
"[]", ou "," ou"," sont non-significatifs:
    truc = { _1 = [valeur1a, valeur1b], _2 = valeur }
équivalent aussi à
    truc = {_1=[valeur1a,valeur1b],_2=valeur}

On peut encore simplifier JSON plus en imposant aucun signe "=" dans les
clés OSM valides, et dans ce cas pas besoin de distinguer "{}" et "[]"
comme en JSON, on peut aussi bien utiliser "[]" partout:
   truc = [_1=[valeur1a,valeur1b],_2=valeur]
toujours équivalent aussi à
   truc = [_1=valeur1avaleur1b,_2=valeur]

Mais à tout moment on conserve des donnés structurées, on n'a plus aucune
limite sur les clés ou les longueurs de valeur et on a le même arbre DOM,
qu'on peut représenter en JSON valide (mais avec des valeurs longues non
limitées en taille:
  truc =  { '_1' = 'valeur1avaleur1b', '_2' = 'valeur' }
Dans cette structure les clés "_1', _2" sont arbitrairement générées et
n'ont aucune notion d'ordre, les valeurs n'ont pas de clé d'accès unique
identifiable autrement qu'en les parcourant toutes depuis une clé de base,
un peu comme le ";" des clés OSM contenant une ou plusieurs valeurs
actuellement mais sans aucun ordre précis entre elles.

Si un ordre est requis, c'est sous forme de tableau indexé JSON:
  truc =  [ 'valeur1avaleur1b', 'valeur' ]
ou en syntaxe JSON simplifée pour OSM (qui autorise de supprimer les quotes
si on peut ):
  truc =  [valeur1avaleur1b,valeur]
équivalent au tableau associatif JSON (les clés '1', '2' sont implicites
dans le format précédent et forment une séquence d'entiers naturels):
  truc =  { '1' = 'valeur1avaleur1b', '2' = 'valeur' ]
équivalent aussi en format XML:
  <tag key="truc"><tag key="1"> valeur1avaleur1b</tag><tag
key="2">valeur2</2></tag>
ou encore (pas équivalent au sens du DOM XML, mais équivalent pour OSM):
  <tag key="truc"><tag key="1"> valeur1avaleur1b</tag><tag key="2"
value="valeur2"/></tag>
ou encore (si on ne veut pas de valeurs longues même en XML):
  <tag key="truc"><tag key="1">valeur1a</tag><tag key="1">
valeur1b</tag><tag key="2" value="valeur2"/></tag>
ou encore
  <tag key="truc"><tag key="1" value="valeur1a"/><tag key="1"
value="valeur1b"/><tag key="2" value="valeur2"/></tag>

Pour que cela marche, il faut seulement affirmer que :
* les clés "1", "2", etc... soient réservées à la notion de liste ordonnée
(avec des numéros entiers arbitraires mais à trier dans l'ordre de leur
valeur, et si possible formant une séquence ininterrompue de 1 à N) ; et
que :
* les clés "_1",  "_2", etc... soient réservées à la notion de liste non
ordonnée (avec des numéros arbitraires, comme des identifiants uniques ou
générés aléatoirement, ne formant pas nécessairement une séquence, ou bien
réserver pour cet usage toute clé commençant par "_" et suivi d'un
identifiant unique opaque sans signification ailleurs que pour identifier
une même valeur découpée en plusieurs tronçons d'une même clé OSM)

Dans ce cas la base de données n'a pas besoin de "blobs" et peut tout
stocker dans des chaines de 255 caractères, ou dans un "hashstore". Les
recherches de "sous-clés" sont optimisées car remplacées le plus
souvent par des recherches de clés complètes et sélectives (d'après leur
chemin dans l'arbre DOM). Et on a une grande souplesse de représentation et
une compression implicite: JSON devient le format universel (même si on
peut encore utiliser un format XML, avec un modèle de document précisant
les conditions de bijection d'un format à l'autre, XML étant trop permissif
et JSON plus restrictif mais plus que suffisant pour les données OSM qui
peuvent avoir des contraintes comme évoquées ci-dessus pour encore plus de
compacité)

Les anciennes syntaxes de listes basés sur le ";" seront ensuite
abandonnées car ambiguës (ordonnées ou pas, associées ou pas avec des tags
utilisant quels autres clés?), ou seront converties par un bot utilisant
certaines règles à définir.

La seule grosse évolution est que tous les tags peuvent avoir des valeurs
structurées : chaines ou tables associatives pouvant inclure d'autres
chaines ou tables associatives, et que les clés de tags sont soient des
entiers naturels commençant par un chiffre (pour distinguer les membres de
listes ordonnées). soit des identifiants opaques commençant par "_" (pour
distinguer les membres de les listes désordonnées, aussi appelées
"ensembles"), soit des clés commençant par une lettre (comme "landuse",
"boundary", etc.  et dans ce cas ces clés sont à documenter et obéissent à
un schéma concerté par la communauté)

Et on n'a plus aucune limite sur les longueurs de valeurs (ni non plus sur
les longueurs de clés puisque ces clés forment en fait un schéma en arbre
dont les branches sont identifiées par des sous-clés courtes)



Le mar. 5 mai 2020 à 16:17, Yves P. <yves.pratter at gmail.com> a écrit :

> Bonjour,
>
> 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>
>
> 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
>
> Exemple:
>
> En v0.7
>
> exemple_key="super long value…"
>
> ça donnerait pour la v0.6 :
>
> exemple_key="super long value"
> exemple_key_1="super long value part 2…"
> exemple_key_2="super long value part 3…"
> …
>
> c'est compatible avec iD :) (qui fait déjà çà :/ )
> c'est compatible avec les autres éditeurs :)
>
> Une fois tout le monde en v0.7, les clés _1, _2… vont disparaitre
> (presque) toutes seules :)
>
> __
> 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/20200505/984afebc/attachment-0001.htm>

Plus d'informations sur la liste de diffusion Talk-fr