L# - Prise de décision (vote)

#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.

#9

Au delà de la numérotation, il y a la mise en forme avec des tables qui facilitent grandement la lecture.

Après, la numérotation automatique, ou explicite, c’est le coeur du débat :slight_smile:

#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
#14

Par contre, ce diff n’est pas conforme à la récente discussion sur l’usage des abréviations. J’ai corrigé.

#15

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

#16

J’ai pas touché au fond. Pour être franc, j’ai pas trop d’avis sur la meilleure facon de compter ces points : dans une voie équipée, tu ne vas pas indiquer les lunules comme de points, mais en TA, si. Et du coup, dans toutes les voies qui se situent entre les deux, ca devient ambigu.

Dans le doute, je m’abstiens, et laisse lâchement à d’autre la lourde tâche de choisir :sunglasses:

#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.

#21

Dans ton exemple, avec la syntaxe V5, la dernière ligne aurait été L6Bis, et non L6, car tout était fait pour économiser le nombre de caractères (mais pas forcément les neurones du contributeurs :stuck_out_tongue:) : le suffixe était répété jusqu’à l’utilisation du suffixe spécial L#_.

Cela dit, le souci de ta proposition, c’est que ca nécessite une « mémoire » pour chaque longueur avec suffixe, y compris la principale. Ca peut sembler assez simple, mais les ramifications du problème sont vraiment pénibles à coder.

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é.

#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.