Le col est fermé en hiver.
C’est déjà le cas.
Différencier plus fortement les pages points de passage / itinéraire / sortie
C’est l’altitude minimale en hiver. Ou aussi pour les accès qui ne sont pas 1 parking, mais toute une série de petits parkings le long d’une route.
Ça permet aussi de trouver des accès en filtrant sur l’altitude minimale accessible en hiver, par exemple en filtrant sur > 1500m. Si on n’a qu’une altitude, la maximale, ce filtre renvoie le col de la colombiere, alors que c’est faux en hiver. En filtrant sur l’altitude minimale, ça élimine cet accès.
Bon le filtre sur l’altitude minimale n’est pas en place, mais c’est l’idée.
Pour les doublons, il y a en effet tout plein de fusions a faire entre des secteurs de grandes voies et des secteurs de couenne, qui étaient séparés sur la v5. A voir ici si c’est effectivement au même endroit et pas à 500m l’un de l’autre.
In fine, ces document points accès n’auraient guère de sens, si tous les itinéraires avaient une trace GPS partant du parking. Il suffirait d’utiliser le 1er point de la trace GPS comme parking/accès.
Mais, la diversité des types d’itinéraires c2c complique significativement le problème. Par exemple, ça n’a aucun sens de faire débuter les itinéraires techniques (escalade, cascade, alpinisme) au parking. Pour les itinéraires techniques, les traces GPS devraient débuter au pied de la partie technique afin de repérer aisément l’attaque sur la carto sans surcharger inutilement la carto. La trace partant du parking est intéressante surtout pour les disciplines « non techniques » (randonné, VTT, ski …).
Dans le cas de la Colombière c’est quasi du copier coller entre
falaise de la colombière
et
col de la colombière
A noter aussi que l’itinéraire d’accès pédestre à la falaise Col de la Colombière : accès pédestre est vide de toute info utile pour trouver la falaise mais semble uniquement servir d’itinéraire « fictif » pour y associer des sorties en couenne sur la falaise sans avoir à rentrer un iti escalade pour chaque couenne. Du coup on a que des sorties escalade associées à un itinéraire rando… Je ne sais pas quelle est la pratique habituelle/recommandée pour entrer ce genre de sorties mais c’est étrange.
Quant à moi j’ai associé un iti randonnée (pointe blanche par le versant sud-est) à un point de passage « site d’escalade » (col de la colombière) parce que ce point de passage décrit mieux l’itinéraire d’accès à la falaise (qu’emprunte mon iti rando) que l’itinéraire rando « col de la colombière : accès pédestre » !
A charge des contributeurs de le mettre à jour.
Ces milliers d’itinéraires « accès pédestre à une falaise de couenne/bloc » ont été créés automatiquement au lancement de la V6 pour y associer les sorties escalades V5 couennes/blocs qui étaient associés dans la V5 directement au document « site couenne/bloc ».
Au lieu d’appeler ces milliers d’itinéraire « itinéraire bidon pour associer les sorties couennes V5 », nous l’avons appelé « accès pédestre » afin de l’utiliser pour décrire les accès pédestre aux falaises (tous en l’utilisant pour les sorties V5).
In fine, l’organisation « falaise » :
- Un point de passage décrivant l’ensemble de la falaise, géolocalisation = 1 point.
- Un point de passage « accès/parking », géolocalisation = 1 point.
- Des itinéraires décrivant les voies
- 1 itinéraire accès « pédestre », géolocalisation = 1 trace GPS
- Des sorties pointant sur les itinéraires, géolocalisation = 1 trace GPS.
A « terme », il est « prévu » d’afficher la trace de l’accès dans le document falaise.
Comme pour la montée de version V4-V5, la montée de version V5-V6 nécessitent de faire évoluer des milliers de documents. Comme pour la V5, il faudra des années pour cela.
L’idéal aurait été que l’organisation de la base donné soit la bonne au lancement de c2c dans les années 90. Mais, à moins d’être devin, il est difficile de prévoir la bonne organisation pour plusieurs décennies.
Avec la nouvelle UI, on peut déplacer le picto itinéraire à l’attaque :
Le picto cache l’attaque. Mais c’est « juste » un problème d’ergonomie à l’affichage. Quand il y a une trace gpx, on pourrait avoir le picto décalé, avec une sorte de fleche jusqu’au point precis.
Ok.
Mais, tant qu’il n’y pas de labandisation (*) des itinéraires, on ne peut pas faire propre.
Ca n’a pas de sens d’avoir des traces GPS des itinéraires démarrant au parking pour les secteurs avec des dizaines/centaines d’itinéraires dans le même secteur. Il faut 1 et 1 seul itinéraire décrivant proprement l’accès/approche (avec une bonne trace GPS), et les itinéraires débutent au bout de l’approche commune, avec donc seulement la trace GPS spécifique.
L’exemple le plus « extrême » est le bloc. La trace localisant un itinéraire bloc doit débuter au bloc en question, et pas au parking. En procédant de cette manière, il suffit ensuite d’afficher l’ensemble des traces blocs sur une carto pour avoir quasi automatiquement un schéma de localisation des blocs. Ce n’est pas possible si les traces partent du parking.
(*) Labandisation : terme utilisé sur c2c pour des descriptions d’itinéraires par tronçons, comme dans les topos de F. Labande des Ecrins, par « opposition » aux descriptions globales type 100 Plus Belles. La Labandisation est évoqué depuis 1 décennie afin de faciliter la maintenance du topoguide.
Oui oui. C’est pour ca que les itinéraires où j’ai ajouté une trace gpx, c’est seulement depuis l’attaque ou depuis le fond du vallon.
En plus, les itinéraires que j’ai modifié possèdent souvent plusieurs approches possibles, depuis des accès éloignés (typiquement pour un parcours d’arete depuis un col, on peut excéder au col par ses 2 versants, même si un versant est plus classique).
@Moderation.Forum, est-il possible de mettre la disgression sur la confusion Point d’accès / itinéraire accès pédestre et le géoréférencement des itinéraires dans un sujet à part ?
@pasinvite, Pour le col de la Colombière, cela fait partie des nombreux doublons créés au passage v5 >v6. Comme explique Bubu, cela vient du fait qu’avant il y avait un distingo site de couenne et site de GV. Vu que comme dans ton exemple le nom n’est pas toujours tout à fait le même (col vs falaise), aucun algo ne pouvait les fusionner automatiquement. Dans ce genre de cas, il faut demander à @Modo_Topo_FR_contact de fusionner. On peut leur faciliter la tache et faire gagner du temps en passant au préalable toutes les infos dans un seul des deux documents (à garder).
Quant à la « labandisation » chère à @Schnockeloch, elle demande un vrai changement technique pour pouvoir factoriser les textes. Et il y a des obstacles, par exemple:
Pour l’arête S de la Pointe claire, l’approche se fait en trois étapes: 1) accès aux refuges du plan de l’alpes, commun par exemple avec tout les iti vers le col d’Arsine - deux accès possibles.
2) Accès à Valfourche, commun avec tout les iti du coté de Planchard.
3) Accès au Vallon Claire (emplecement bivouac) par la grotte des Pichettes, commun avec d’autre voies (Gaspard SSE, Col Claire, VN pointe Claire etc)
4) une partie spécifique.
Ce n’est qu’un exemple parmi d’autre qui montre les limites de la factorisation.
C’est totalement faux. L’avantage est de pouvoir voir tous les itinéraires au départ d’un point d’accès identifié, avec des infos potentielles dedans factorisées (parking payant, accès en TC etc). C’est particulièrement utile pour la mobilité douce.
Par ailleurs, je suis bien surpris que tu n’aies pas connaissance du géoreférencement des itinéraires. Vu que tu es assez vindicatif sur le sujet.
La limite est que c’est peut etre fastidieux de se taper la creation de tous les tronçons possibles. C’est parfois un gros boulot, oui. Mais la labandisation est faisable (ceci dit, les createurs de sorties ont parfois la flemme de rechercher puis d’associer chaque tronçon, mais ça, c’est un autre sujet).
Merci @alexduchablais et @Bubu pour les retours constructifs.
Avec le changement d’UI de l’hiver, le « badge » indiquant le type dans le titre a été remplacé par un lien « A proximité de … ». Car le badge était en fait un lien avec cette fonction. Le fait est que du coup les pages sont moins identifiables « intuitivement », comme le confirme le sondage.
Mettre l’altitude en avant pour un Sommet est surement une bonne idée.
Mettre en valeur la date sur une sortie est surement une bonne idée.
Pour les icônes d’activité, c’est surement bien, mais cela amplifie notre problème de distinction intuitive entre une page sortie et itinéraire (vu que les icônes seraient les mêmes).
Inverser l’ordre sommet : Itinéraire sur le titre des itinéraires, je trouve pas cela pertinent.
J’ai vraiment le sentiment que la solution passe principalement par un code couleur, plutôt qu’une réorganisation de l’affichage des infos. Maintenant, il faudrait prendre le temps de faire des propositions concrètes (avec screenshot) …
Perso, j’ai le sentiment que la solution passe principalement par la recherche de développeurs bénévoles. Des bonnes idées il y en a…, mais la réalisation passe sans doute d’abord par l’établissement d’une nouvelle liste de sujets prioritaires à développer.
(my 2 cents).
vient peut-etre quand même du fait qu’il faille :
Différencier plus fortement les pages points de passage / itinéraire
Sans être un codeur, je n’ai aucun doute qu’il n’y ait aucun soucis pour récupérer le 1er point de toutes les traces GPS des itinéraires, et donc avoir automatiquement tous les parkings.
Le 1er soucis pour les déplacements en transport en commun est simplement que l’information factorisée permettant d’atteIndre le parking n’existe pas vraiment et/ou que d’éventuels liens sont très rapidement obsolètes (pour la France). Ça ne se joue pas sur c2c.
Il y a effectivement quelques rares informations à mettre dans quelques rares parking. Mais la quasi totalité des documents Parking sont vides. Dans la v5, le document parking permettait d’avoir en 1 clic l’itineraire routier (et donc distance) pour se rendre au parking depuis la localisation de son compte. Le document parking apportait donc une importante valeur ajoutée.
Oui je vais le faire d’autant que j’en ai quelques autres en tête dans le style (pas dus au passage à la V6 pour le coup)
1 Like
La labandisation nécessite une remise à plat de l’ensemble, y compris de l’organisation de la base de données, avec les itinéraires décrits par la somme des descriptions de documents tronçons. Ca doit être quasi transparent pour le néophyte pouvant sélectionner comme aujourd’hui un itinéraire, avec éventuellement des variantes. Ça ne peut pas se faire dans la V6.
Avant même de parler code, il faudrait avoir bouclé/simulé l’intégralité du concept sur le « papier », ce que nous n’avons jamais fait.
C’est un énorme chantier qui a relativement peu de chance de se faire compte tenu de sa complexité et du risque. C’est un truc à écœurer 99% des contributeurs si ce n’est pas aux petits oignions.
J’espère bien que la v6 permettra de faire ça.
Mais ça demande des modifs dans l’api.
On sera bien obligé de le faire quand d’autres sites proposant des topos montagne le feront et montreront toute la puissance du concept.
Tu as raison. Il n’y pas de raison que cela ne puisse pas se faire avec la V6. Cela aurait tout autant pu se faire dans la v5 (plus difficilement avec la V4 n’ayant pas la géo localisation). Mais, c’est un gros chantier dont le retour sur investissement est difficile à évaluer, et avec une importante prise de risque sur le cœur du projet.
J’espère juste, que comme pour d’autr concept que nous avons étudié, que d’autres ne le lanceront pas avant c2c pour la montagne. Ça existe déjà plus ou moins en VTT ou même chez Strava avec une sélection automatique des tronçons par géo-localisation en temps réel.
C’est plus simple à lancer quand tu pars de zéro.
N’hésite pas à mettre cette requête sur Github, faut regarder la doc googlemap. Un lien à mettre sur les waypoints de type accès. Idéalement avec la fonction « accès en transport public » activé.
1 Like
Des idées concrètes pour avancer sur ce point ?