Le 24 août 2017 à 01:31, marc marc <[email protected]> a écrit :
> Si une app ne survit pas à l'absence de relation (qui n'existe quasi > pas), Philippe merci de donner son NOM pour ceux qui l'ignorent. > histoire de réfléchir au problème. > Je n'ai PAS DU TOUT évoqué ce problème, tu as compris de travers. J'ai parlé en revanche du problème des applis qui attendent une valeur précise du tag network=* et s'attendent à la fois : - à son unicité (pour rechercher et localiser une ligne précise, tout en ne connaissant pas précisément sa localisation, pas même une bounding box qui peut aussi ne pas suffire) ce qui conduit à ajouter des affixes de désambiguisation (dont la forme n'est franchement pas standardisée en dépit des efforts faits sur les autres tags pour uniformiser les suffixes de langues BCP 47 en minuscules seulement après ":", et des préfixes de codes pays ISO 3166-1 en capitales seulement) - et à l'afficher tel quel comme si ce nom unique était lisible par un humain (qui n'aime pas trop les affixes), suffisant, et en plus le seul approprié pour ce réseau (cas de pays officiellement multilingues qui tiennent à ces noms multiples : là on a besoin d'un "name=*" localisable), et d'autres désignations comme les abréviations courantes ou les noms commerciaux et historiques (conservés encore comme "marques") et encore voulus pour les recherches On a tous évoqué ici le "m*rdier" des valeurs du tag network=* qui sont quasi inutilisables, instables, pas uniformisés, avec quantité d'oublis et différentes variantes pas faciles à trouver. C'est cela que la relation "type=network" règle une fois pour toute, clairement, sans aucun effort supplémentaire et sans aucune utilisation d'outils externes hors de la communauté et souvent pas maintenus longtemps ou contenant des restrictions d'accès (ce qui rend la base non libre: un vrai problème aussi). Bref merci de ne pas ignorer ces éléments importants. Je n'ai en revanche jamais dit qu'il faudrait supprimer ce tag, mais qu'il était NON maintenable sur des objets aussi étendus (et pas complètement connexes) que les réseaux de transport dans lequel vient la complexité de la multimodalité. ---- On a peu de réseaux dans la base tout bonnement car peu de régions ont encore construit les lignes qui devraient être modélisées, et on a énormément d'essais dispersés et pas beaucoup de réussites (et on a vu la lenteur d'adoption du schéma v2, ne serait-ce même que pour une seule ligne, tout en voyant que des solutions très différentes ont été établies de fait, sans aucune discussion préalable selon le mode de transport: train, métro, tram, bus, cable, liaisons fluviales ou maritimes, parcours vélo, ski, sans compter aussi le "m*rdier" en France des randonnées pédestres !) Les efforts sont nombreux mais chacun essaye de commencer avec ses outils. Supprimer un outil simple alors qu'il n'y a même pas de solution de remplacement faible et commune est une curieuse idée qui ne facilitera certainement jamais le développement des données pour les transports en commun (qui nécessitent des parcours précis sur des lignes, des exploitants, une administration et une planification sur ces réseau). L'intermodalité est une nécessité partout dans le monde (et même une urgence à gérer dans toutes les grandes métropoles). Sans cette représentation correcte des réseaux, OSM restera juste une base montrant une carte statique d'infrastructures déconnectées (des paquets de rues dans tous les sens, des restrictions un peu partout, où même le piéton se perd et ne sait pas à quoi servent et ou vont les arrêts de transports mis en place). Les usagers voient juste qu'il y a des lignes, ne savent pas ce qu'elles desservent, ni où et quand, ou à quelle fréquence, à quel prix et en combien de temps. Cette absence dans OSM ne favorisera jamais QUE les transports individuels et JAMAIS les transports en commun (qui sont pourtant concernés fortement par les efforts européens imposant l'Open Data dans ce domaine même au delà de la seule Union européenne et des collaborations) qui sont avant tout structurés en réseaux connectés (couvrants et finalement assez stables dans le temps) et non en lignes individuelles (qui elles sont très changeantes et se créent et disparaissent un peu partout sans prévenir). Le réseau a plus de raison même d'exister en premier dans OSM que la ligne simple (et d'ailleurs un réseau ne comprend pas non plus que des lignes à trajet fixe, il y a des endroits avec du transport à la demande entre des stations établies à l'avance mais sans parcours indiqué qui sera établi selon les usagers qui ont réservé et négocié avec le transporteur un temps de trajet prévisionnel et des horaires de passage dans des plages horaires pouvant dépasser l'heure sans que ce soit considéré comme du "retard") Toutes les utilisations des transports en commun ont besoin d'identifier précisément les lignes qu'ils gèrent, ainsi que les zones d'arrêts qu'ils peuvent desservir et de les trouver dans un réseau de lignes bien connecté permettant celles permettant la planification des trajets, ils ont aussi mission de vendre ce service aux usagers qui pourront compter dessus. Sinon ils n'utiliseront QUE les transports individuels. L'information du public sur ces réseaux est donc indispensable, sinon ces lignes ne servent presque à rien hormis quelques déplacements locaux à l'occasion. Dans tous les cas on a des listes exhaustives et parfaitement connues, construisant un objet géographique qui n'a rien d'une "collection" (ça c'est le mythe façon OSM qui confond ça avec des collections ouvertes d'objets n'ayant aucune relations ni responsabilité communes entre ceux qui les mettent en place sans aucune concertation ni planification) mais bien d'un objet complet: les plans de réseau (même schématiques) qu'on voit partout le traduisent clairement, les fiches horaires et les plans aux stations ont nettement plus de détail et mettent l'accent sur les correspondances et accès et solutions intermodales pour que ce réseau serve au plus grand nombre, et sans surprise une fois sur place pour constater qu'un trajet ne sera finalement pas possible ou ne se fera pas dans les temps (vrai problème pour les usagers qui ont du réserver leurs destinations et payent leur voyages à l'avance à qui le transporteur doit garantir de les amener à l'endroit prévu)
_______________________________________________ Talk-fr mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-fr
