L# - Prise de décision (vote)

#1

Bonjour à tous,

Cette discussion va permettre de décider quelle doit être la syntaxe cible de la balise L#. Le vote est ouvert aux personnes ayant au moins une contribution dans le topo-guide avant l’ouverture de cette discussion, et se terminera le 12 avril.

Rationnels

  • la balise L# est une balise qui permet de mettre en forme une liste de longueurs, ce qui est indispensable pour les topos de grandes voies. Voir l’aide pour plus d’infos.
  • la syntaxe V5 n’a pas été porté sur la V6, car le code s’est avéré très complexe,
  • Néanmoins, lors de la dernière mise à jour, une version de cette balise permettant de réaliser tous les besoins a été livrée :
    • il est à noter que cette version est une sous-partie de la balise L# V5 originelle, bien plus restreint et simple,
    • mais par ailleurs, cette syntaxe V5 est comprise dans sa totalité par très peu de personnes,
    • et également, sa complexité rebute le contributeur occasionnel qui ne peut intervenir sur une syntaxe difficilement compréhensible
    • cependant, cette complexité offre une puissance qui est une aide appréciable aux contributeurs (très) habitués pour la maintenance des topos.
  • Dernier point : au vu du temps (plus d’un an) qu’il a fallu aux développeurs pour proposer cette alternative, il est probable qu’il faille patienter encore avant d’avoir une syntaxe équivalente à celle V5. Pour être tout à fait clair, nous n’avons pas les moyens aujourd’hui de retrouver cette syntaxe originelle dans un temps raisonnable.
Exemples de syntaxe simple et supportée 
L#     => L1
L#3    => L3
L#     => L4
L#5-6  => L5-6
L#     => L7

Suffixes, si tous les numéros sont précisés (numérotation absolue)

L#1      => L1
L#1bis   => L1bis
L#2      => L2
L#3bis-4 => L3bis-4bis
Exemples de syntaxe complexe et non supportée

Numérotation relatives complexes :

L#      => L1
L#+     => L2
L#+2    => L4
L#-+2   => L5-6
L#+2-+3 => L8-9

Raffinements de suffixes :

L#   => L1
L#!  => L2
L#   => L3
L#'  => L2'
L#   => L3'
L#"  => L2"
L#   => L3"
L#_  => L4
L#   => L5

Mélange de tout cela :

L#+    => ...
L#-+!  => ...
L#'    => ...
L#3-+2 => ...
L#_    => ...
L#     => Saurez vous trouver tous ces numéros?

Conséquences

Si l’on décide d’arrêter les développements :

  • On retrouve rapidement un topo-guide propre
  • On conserve une syntaxe facilement compréhensible
  • Mais l’écriture et la maintenance est plus fastidieuse

A contrario, si l’on décide de ré-implémenter toutes les possibilités V5

  • le topo-guide reste peu lisible pour un gros millier d’itinéraires, le temps de trouver les ressources de développement
  • mais à terme nous retrouvons une syntaxe puissante

Vote

La question est la suivante :

Pensez vous qu’il faille arrêter les développements de la balise L#, et modifier les documents du topoguide afin qu’ils respectent la version « simple » de la balise actuellement en ligne?

  • Oui
  • Non

0 votant

#2

pendons les nerds avec les tripes des geeks… :smiley:

#4

J’en profite pour poser une question de béotien : c’était quoi l’intérêt de ces balises # au lieu de bêtement numéroter les longueurs avec des chiffres arabes ?

#5

De toutes façons, il y a les deux :slight_smile: :

  • L# relatif (sans chiffre),
  • L# absolu (L#1, L#1bis, L#2 …).

On utilise l’un ou l’autre … selon les besoins et les envies.

HS : comment vas tu aujourd’hui ? Tjs l’hosto ?

#6

oui mais pourquoi se faire chier avec ces # dans la v5 ? J’ai participé au Ellediésothon pour remettre en forme « V5 complient » des itinéraires décrits L1, L2, L3.
Concrètement, ça a apporté quoi ? Vu que quel que soit ce qu’il y a dans le code le lecteur du topo lit L1, L2,…

#7

S’il y a des suffixes (type bis), il faut utiliser L#1, L#1bis, L#2 … (« numerotation absolue »)

Sinon, on peut utiliser les L# tout nus, et la numerotation se fait automatiquement.

#8

Si tu ne vois pas de différence de qualité de lecture entre
https://www.camptocamp.org/routes/version/985669/fr/1834571
et
https://www.camptocamp.org/routes/985669/fr/montrebei-paroi-d-aragon-cacadors-de-boletaires
, ça signifie que la mise en forme permise par la balise L# ne te sert à rien.
Mais ton cas n’est pas une généralité.
Sache que certains sont sensibles à la qualité de lecture des topos. Tu as pu remarquer qu’il y a des débats sur le fait d’ajouter un espace ou non entre un nb et une unité, sur les règles de ponctuation et typographie, etc.
Et bien pour la mise en forme au niveau de l’ensemble d’un texte, c’est pareil.

#10

oui, c’est plus lisible.

mais on aurait pu le faire à la main :

L1 IV+ 55m Monter droit dans des dalles facile puis un peu plus raides en fin de longueur avant de rejoindre la vire qui mène au pilier des vautours; relai dans un genévrier
L2 V 55 m démarrer à une flèche piquée dans le rocher; monter droit (1 spit à 20 m) puis partir à gauche à un pont de rocher, traverser un couloir herbeux et remonter un éperon au dessus (2 points au relai)
L3 V+ 55 m Monter droit dans le mur à strates magnifique; les points sont rares et on rajoute peu de chose…relai à droite sur deux points

#11

Non, tu n’as pas les info sous forme de table :

#12

@Bubu, je pinaille, mais :

R2 (2 points).
R3 à droite (2 points).

C’est probablement des goujons, mais ce n’est en fait pas spécifié ds l’original.

#13

Oui mais je sais que ce contributeur veut dire « goujon » quand il écrit « point » pour les relais, quand la voie est équipée majoritairement sur goujons.
Et le tracé que j’ai mis dans ressource externe confirme cela.

1 Like
#15

Pour L2, cela fait probablement 2 points (2pt), vu la lunule.

#18

Ta question est bonne.
2 problématiques ont été traité par les # dans la V5.

  1. Mise en forme des contenus avec des tableaux. C’est très intéressant pour les voies sportives et les couennes. C’est moins intéressant pour le TA/cascade (tout en restant intéressant) et pas intéressant pour l’alpi.
    A terme dans la V6, il n’y aura plus les tableaux de couenne. Mais la mise en forme tableau reste une importante valeur ajouté en escalade grande voie.
  2. La numérotation automatique. Hormis dans les cas simples et avec plus de 10 longueurs, la numérotation automatique présente plus d’inconvénient que d’avantage, à fortiori lors des montées de version cassant tous les itinéraires.

Les propositions OUI du vote a justement pour objectif de ne conserver que les bonnes choses des # (qui étaient tout de même une très bonne chose dans la V5).

#19

J’ai répondu non, pas que je souhaite retrouver l’intégralité des fonctionnalités de la V5, mais parce que j’ai l’impression qu’il manque un tout petit poil dans la version actuelle sauf si j’ai mal compris un truc (ce qui est possible). Ce qui me semblerait pratique (et sans doute pas trop usine à gaz) serait de pouvoir mettre des suffixes sans perdre totalement la numérotation auto. C’est-à-dire d’avoir la syntaxe suivante :

  • L# : numérotation automatique, classique
  • L#4, L#4-12 : numérotation absolue
  • L#nimp et L#4nimp (avec nimp prenant toute valeur autre qu’un nombre ou un intervalle 2-7) : numérotation soit automatique soit absolue selon le cas, mais suivi de nimp laissé tel quel et surtout dans le cas automatique, pas d’incrément du numéro de longueur (car L4bis suit souvent L4).

En gros (et même si la numérotation de mon exemple est bizarre) :
L#
L#2-3
L#
L#’
L#5bis
L#

donne

L1
L2-3
L4
L4'
L5bis
L6
1 Like
#20

Je pense qu’il s’agit d’un problème de moyens, insuffisants pour établir une numérotation mixte.

Une autre source de « non » (@Chti.nain ?) est peut être l’absence du bouton L# de la V5.

#22

Euh non, une seule mémoire, la numérotation globale. Quand tu as un L#truc tu n’incrémentes simplement pas le compteur, mais tu gardes un unique compteur global.[quote=« CharlesB, post:21, topic:212217 »]
Par ailleurs, le fait que ca ne soit équivalent V5 (c’est à dire un même code donne une interprétation différente, au lieu de rendre une erreur) va rendre la migration hyper pénible, et dangereuse. En plus clair, il faut que ca soit au mieux égale à la V5, au pire non supporté.
[/quote]

Difficile de contredire cet argument ! Et avec ce point de vue, je pense que je penche plutôt vers l’arrêt des modifs.

#23

Tout cela dit, si on choisit de rester sur la version simple, une fois les documents migrés, ta proposition sera possible car le code L#nimp ne sera présent nulle part.

On pourra alors en discuter.

#24

Up !

(à deux jours de la clôture du vote)

1 Like
#25

Fun du vote :

Vote Oui Non Total
Migration 27 2 29

Ignored votes : @Fitaine (merci pour ta participation tout de même).

Je modifie la page d’aide en conséquence.