Finalement mon modèle ci n'est pas un schéma "v3", en fait il est
totalement compatible avec le v1 par défaut, mais réintègre le shéma v2
avec des règles plus précise et plus aucun besoin de préciser la version v2.
Il retient cependant de la v2 la possibilité de séparer les sens (en créant
des variantes de sens ou de parcours explicitement dans les relations
"route" qui représentent une ligne grace à un attribut
"route:variants=yes", ce qui peut aussi s'écrire en utilisant le tag "v2"
actuel, mais SANS rendre obsolète le schéma "v1" par défaut, qui reste très
utile pour indiquer que la route est bidirectionnelle).

Bref ce que je propose ne fait que préciser ce que le schéma v2 omettait de
fixer par des règles, et là où le schéma v1 seul (lignes uniquement
bidirectionnelles et contenant toutes les variantes de parcours mélangées)
était insuffisant.


Le dim. 31 mai 2020 à 14:20, Philippe Verdy <ver...@gmail.com> a écrit :

> Maintenant une "section" (relation "route" ou chemin unique) peut être une
> ligne entière: elle porte son numéro et son attribut de réseau en tant que
> ligne, mais pas si ce n'est qu'un sens de parcours d'une ligne (elle a des
> noeuds membres "from"/"to"/"via1"/via2") ou une des variantes de cette ligne
>
> Reste la question des lignes:
> - une ligne peut être constitué d'une seule ou plusieurs sections (évoqué
> ci-dessus), unidirectionnelles ou pas, ou bien être une collection de
> trajets (un membre par variante ou par sens distingué): il faut un attribut
> à la route (pas de role pour chaque membre) pour indiquer que les chemins
> ou relations membres sont exclusifs les une des autres et ne se raboute
> pas: un attribut comme "route:variants"="yes" (par défaut c'est "no" et
> tous les membres se mettent bout à bout et ne doivent dormer qu'une seule
> ligne continue éventuellement cyclé sur elle-même
> - si la ligne indique l'attribut  "route:variants"="yes", les éventuels
> noeuds membres "from"/"to"/"via1"/"via2" sont informatifs mais ne
> déterminent strictement rien (on devrait les éliminer)
> - les noeuds "via" existants ne servent à rien, ils ne sont jamais
> discriminants et pas suffisant pour les parcours cycliques car il en faut
> au moins deux clairement distingués (au moins "via1" et "via2" détermine
> leur ordre relatif, alors qu'avec "via" ce serait l'ordre des membres dans
> la relation et on sait qu'il n'est pas stable ni significatif).
> - si la ligne contient plusieurs sections, soit elles sont toutes
> bidirectionnelles alors la ligne est bidirectionnelle, soit elles sont
> toutes unidirectionnelles, et la ligne est unidirectionnelle. On ne peut
> pas avoir un mix sans transformer la relation en collection de variantes,
> avec une sous-relation pour chaque sens ou variante.
>
> Là on a des règles précises, on peut abolument tout modéliser: sections
> tarifaires, complexité des circuits, sens de parcours, détours facultatifs,
> prolongations facultatives de lignes (en ajoutant une variante contenant le
> premier parcours plus cours déjà ajouté comme une des variantes de la
> ligne).
>
> Dernier ajout:
> - les neuds "from"/"to"/via1" et "via2" requis pour les sections DOIVENT
> être des noeuds terminaux parmi chemins listés (ce ne sont pas des "arrêts"
> au sens des transports qui peuvent eux être sur les chemins mais pas
> nécessairement à l'extrémité, ou être juste proche des chemins). Si ceux
> noeuds sont facultatifs (comme décrit plus haut), ou s'ils ne respectent
> pas ces conditions, cex noeuds ne déterminent PAS les parcours et la
> topologie, ils sont juste informatifs (comme aussi les noeuds des positions
> d'arrêts s'ils sont placés ailleurs qu'à l'extrémité d'un chemin d'une
> section)
>
> Le traitement automatisé des lignes et la vérification complète est
> possible pour TOUTES les lignes les plus compliquées et ayants diverses
> variantes de parcours, sens, prolongations, variantes saisonnières. Ce
> modèle est totalement séparé de la liste des arrêts desservis qui sont des
> noeuds membres. Cependant les arrêts décrits comme des "stop_position"
> (suer les chemins) pourraient correspondre à un des noeuds
> "from/to/via1/via2" nécessaires à la topologie des parcours; les rôles
> "from/to/via1/via2" peuvent donc s'ajouter aux rôles "stop_position" sur un
> même noeud membre, l'un des premier rôles ne remplacant pas le dernier (par
> exemple cela peut demander un rôle "from;stop_position" en utilisant un
> point-virgule séparateur)
>
>
> Le dim. 31 mai 2020 à 13:55, Philippe Verdy <ver...@gmail.com> a écrit :
>
>> Maintenant il reste à définir les règles pour les "sections":
>>>
>> - une section est modélisée soit par une unique chemin, soit par une
>> relation "route"
>> - une section est constituée d'un ou plusieurs chemins
>> - le ou les chemins constituant la section ne comportent aucun boucle
>> intermédiaire, aucune variante ou branche, aucun chemin parcouru plusieurs
>> fois
>> - la section peut être cependant fermée sur elle-même constituant un
>> seule cycle: elle doit comporter un noeud "from" ou un noeud "to" (les deux
>> étant le même noeud on n'a pas besoin de l'ajouter deux fois) correspondant
>> à son unique terminus
>> - sinon la section forme une ligne dont les deux terminus sont déterminés
>> automatiquement en joignant les chemins : il ne doit rester alors que deux
>> noeuds
>> - une section, cyclique ou pas, est par défaut bidirectionnelle, ou
>> unidirectionnelle. si elle est bidirectionnelle, aucun autre noeud ou
>> attribut n'est nécessaire (les noeuds membres "from/to" sont facultatifs)
>> - si elle est unidirectionnelle, alors deux cas :
>>    * (1): la section est cyclique, il FAUT lui ajouter deux noeuds
>> membres distincts (rôles "via1" et "via2", le cycle est orienté de
>> "from/to" à "via1", puis "via2" puis "from/to"; on n'a qu'un seule noeud
>> membre avec le rôle "from" ou "to", peu importe, mais il faut deux autres
>> noeuds). tous les chemins du cycle sont joints et par un unique noeud de
>> jonction, tous les noeuds de jonction sont liés chacun à deux chemins, s'il
>> n'y a qu'un seule chemin c'est un chemin fermé, son terminus est son noeud
>> de début et de fin, le noeud "from" ou "to" n'est pas nécessaire dans la
>> section, mais il faut quand même une relation pour ajouter des membres
>> "via1" et "via2" (ce qui n'est pas nécessaire pour une section cyclique
>> bidirectionnelle constituée d'un seul chemin fermé sans relation)
>>    * (2): la section n'est pas cyclique, pas besoin de noeuds "via1" et
>> "via2": on peut les ajouter mais cela ne détermine pas le sens, c'est juste
>> informatif, mais il faut alors deux noeuds membres "from" et "to" distincts
>> pour indiquer le sens de parcours
>> - les relations "route" représentant une section n'ont aucun ordre fixé
>> pour les membres, les chemins membres ne sont membres qu'une seule fois
>> (sans doublon et sans jamais aucun rôle nécessaire), 2 ou trois noeuds
>> membres distincts peuvent exister eux aussi dans un ordre quelconque (et
>> seulement si la section est à un seul sens): soit "from" et "to" pour les
>> sections non cycliques; soit "from" (ou "to") et "via1" et "via2" pour les
>> sections cycliques
>>
>
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Répondre à