Autre argument: les lignes de transport sont souvent (et de plus en plus) cogérées: plusieurs opérateurs, ou appartiennent à plusieurs réseaux simultanément.
Le 2 août 2017 à 11:35, Philippe Verdy <verd...@wanadoo.fr> a écrit : > Et tu ajoutes tout un tas de tags redondants en plus, dont la maintenance > sera encore plus "bordélique". Plus on met de redondance et plus on voit la > qualité se dégrader rapidement (et les "trous" apparaissent très vite): il > n'y a plus de suivi, cela devient vite disparâtre. Bref cela crée en plus > de la complexité à gérer ça au lieu de centraliser les infos à un endroit. > > > Le 2 août 2017 à 08:18, Jo <winfi...@gmail.com> a écrit : > >> Pour les réseaux de cyclisme et de randonné/équestres il me semble très >> raisonnable d'avoir les relations route et les relations network pour >> indiquer lesquels forment des groupes. J'ai créé des scripts dans le passé >> pour valider ces réseaux de noeuds numérotés. >> >> Pour le transport en commun, il me semble que ce genre de relations >> deviendra très grandes et trop compliquées à gérer/maintenir. >> >> Je pense que les tags operator / network, ensemble avec operator:wikidata >> / network:wikidata / brand:wikidata sont plus adéquats pour cela. >> >> Polyglot >> >> 2017-08-02 3:16 GMT+02:00 Jérôme Amagat <jerome.ama...@gmail.com>: >> >>> >>> >>> Le 2 août 2017 à 02:51, Philippe Verdy <verd...@wanadoo.fr> a écrit : >>> >>>> Blah blah blah, tu veux perpétuer les mauvaises pratiques. Dans OSM les >>>> noms d'objets sont dans name=* et ses dérivés, qu'on n'a pas à multliplier >>>> ailleurs. On l'a fait depuis longtemps pour classer plein de tags de façon >>>> symbolique (avec des tags en anglais qui ne sont plus une gêne, car ça >>>> n'empêche pas les éditeurs et les rendus de présenter les valeurs sous une >>>> forme parlante et plaisante à l'utilisateur selon ses préférences) >>>> >>>> Je sais que certains n'aiment pas les relations type=network, mais ils >>>> n'ont pas résolu les problèmes de maintenance et de recherche que la >>>> variabilité des noms imposent (et qui rendent les recherches >>>> particulièrement pénibles et les données interprétables uniquement par >>>> l'homme qui doit fouiller lui-même des gigaoctets de données.) >>>> >>>> Moralité: on construit alors des heuristiques pour y palier, mais ces >>>> heuristiques ont toutes des défauts: c'est le propre des heuristiques de ne >>>> pas être des algorithmes, et de ne pas être capable de tout trouver. On >>>> aura donc des trous inattendus dans les résultats, des cas nombreux de >>>> doublons dans la base, qui chez certains n'apparaitront pas pour autant et >>>> chez d'autres apparaitront simultanément comme des infos contradictoires >>>> entre elles et sur lesquelles il est impossible de décider quoi que ce >>>> soit. >>>> >>>> On parle de base de données mais on ne veut pas utiliser ses capacités >>>> naturelles. C'est l'éternel débat entre entrer ou pas des infos redondantes >>>> et comment décider entre elles et comment ensuite maintenir la cohésion et >>>> la cohérence. Qu'est-ce qui est vraiment choquant dans le fait d'avoir de >>>> tous petits objets relation type=network pour guider le reste? En quoi cela >>>> complique les traitements et les interprétations? Et comment ensuite on >>>> adapte les données aux attentes des utilisateurs? >>>> >>>> On a eu ce débat par exemple avec l'introduction des multipolygones. >>>> Maintenant le choix est fait. les relations ont gagné car elles >>>> permettaient une bien meilleure qualité et une maintenance en fin de compte >>>> plus facile. Ceux qui n'aiment pas les relations sont surtout perturbés par >>>> les insuffisances de certains éditeurs, mais on commence à progresser. Le >>>> frein était mis sur le fait que les contributeurs avaient du mal à s'y >>>> retrouver, mais c'est surtout à cause des éditeurs utilisés et par le fait >>>> que la documentation pour leur expliquer était insuffisante et qu'au début >>>> il y avait des choix possibles plus nombreux et des expérimentations >>>> locales. On a changé d'échelle, la base devient monstrueusement grande et >>>> les outils pour gérer la qualité doivent trouver des solutions pour >>>> clarifier les schémas et les consolider. >>>> >>>> Le fait est qu'on début on ne se complique pas trop la vie, mais quand >>>> le volume des donnes commence à exploser, l'interprétation visuelle humaine >>>> ne suffit plus et la qualité se dégrade. On doit passer à autre chose de >>>> plus formel et plus systématique. >>>> >>> >>> Quand tu parles de type=network tu parles de ça : >>> http://wiki.openstreetmap.org/wiki/Talk:Relations/Proposed/Network >>> Proposition qui n'a pas bougé depuis des années et dont les dernières >>> discussions dissent que les relations ne sont pas faite pour être des >>> catégories et qu'à la place de ce type=network le tag network=* suffit. >>> >>> le nom d'objet va dans name je suis d'accord mais ici ce n'est pas le >>> nom de l'objet. d'autre tag ont un nom comme valeur : operator, owner, >>> brand....et d'autres. >>> il faut créé des relation type=operator .....? >>> >>> >>>> Le 2 août 2017 à 01:48, Jérôme Amagat <jerome.ama...@gmail.com> a >>>> écrit : >>>> >>>>> >>>>> >>>>> Le 2 août 2017 à 01:35, Philippe Verdy <verd...@wanadoo.fr> a écrit : >>>>> >>>>>> c'est la documentation standard des relations type=network qui >>>>>> contiennent l'ensemble des lignes d'un réseau. >>>>>> netowrk=* n'est pas directement destiné à être affiché et partout >>>>>> c'est une abréviation impropre et rarement une dénomination officielle, >>>>>> et >>>>>> pas non plus adapté pour stocker d'autres informations ailleurs que dans >>>>>> la >>>>>> relation type=network (sinon redondance énorme et mise à jour >>>>>> compliquée). >>>>>> Rien que le fait qu'on ait network=FR:national devrait te convaincre >>>>>> que ce n'est pas un "nom" mais une valeur symbolique, qui devrait en plus >>>>>> être aussi unique que possible sans risque de collision. les outils >>>>>> ucherchant à représenter les lignes s'appuient sur une valeur commune >>>>>> pour >>>>>> identifier les lignes en associant network=* à une ref=* pour le numéro >>>>>> de >>>>>> ligne (la ligne ayant par ailleurs un nom et éventuellement une >>>>>> description, ainsi que d'autres propriétés). >>>>>> Ce n'est pas compliqué à comprendre, cette valeur symbolique sert >>>>>> aussi de clé complémentaires à d'autres tags liés. Les noms de réseau >>>>>> sont >>>>>> en fait plus compliqués que ce symbole, ils existent sous différentes >>>>>> formes: courte abrégée, forme longue, éventuellement aussi en plusieurs >>>>>> langues dans les pays ou régions officiellement multilingues. La clé >>>>>> permet >>>>>> de réconcilier les données indépendamment de la langue utilisée pour >>>>>> nommer >>>>>> le reste. >>>>>> >>>>>> Le préfixage avec un code pays est utile aussi, particulièrement pour >>>>>> les réseaux nationaux (avec des embranchements internationaux). On n'a >>>>>> pas >>>>>> d'équivalent aux normes IATA et OACI pour l'aviation civile, mais ça ne >>>>>> saurait tarder avec la dérégulation des transports européens et la >>>>>> multiplication des opérateurs exploitants de réseau de transport et des >>>>>> opérateurs exploitants commerciaux qui exploitent aussi plusieurs marques >>>>>> commerciales (exemple avec le "TGV" français qui n'est plus une marque >>>>>> commerciale en soi, mais a diverses dénominations selon les services). >>>>>> On a >>>>>> de plus en plus besoin de clés uniques stables, et indépendantes des >>>>>> éventuels changements de marques ou de l'existence de multiple marques >>>>>> commerciales pour les services. Mais ça obéit au même principe pour tous >>>>>> les types de transport (et d'autant plus que se développe l'intermodalité >>>>>> sous une même marque commerciale) >>>>>> >>>>>> network=* n'est donc pas fait pour donner un nom, il représente juste >>>>>> les noms possibles, sous une forme abstraite, abrégée. A terme si on a >>>>>> une >>>>>> norme d'identifiant international on pourra l'utiliser mais je pense >>>>>> qu'il >>>>>> est illusoire de l'attendre à un niveau plus grand que le niveau >>>>>> national: >>>>>> d'où les préfixes de code pays (une convention commune dans OSM et qui >>>>>> rend >>>>>> bien des services). >>>>>> >>>>>> bla bla bla... >>>>> ça c'est ce que toi tu penses. >>>>> Si on regarde le wiki pour les réseau de bus >>>>> "On route relations for bus, railway, and tram service routes, this >>>>> key indicates the bus system, if applicable. There is currently no >>>>> consensus whether the values should be abbreviated or not. >>>>> >>>>> In the United States, it is common practice to use a commonly used >>>>> abbreviation or other short name. Because names such as "RTA" and "Metro" >>>>> are exceedingly common, the initialism of the transportation agency is >>>>> often used instead to reduce ambiguity. For example, Cincinnati-area >>>>> routes >>>>> are tagged network=SORTA instead of network=Metro. >>>>> >>>>> Some ambiguity is accepted: for example, there are features tagged >>>>> network=VTA in the operating areas of both the Santa Clara Valley >>>>> Transportation Authority and the Martha's Vineyard Transit Authority, >>>>> because neither organization is known by a more specific acronym." >>>>> http://wiki.openstreetmap.org/wiki/Key:network#Public_transit_routes >>>>> >>>>> ensuite il y a des exemples et le seul exemple qui n'est pas une >>>>> abréviation du nom du réseau c'est le réseau star de rennes et c'est toi >>>>> qui l'a ajouté lors de la dernière discussion sur ce réseau que l'on a eu >>>>> sur cette liste. >>>>> >>>>> Moi ce que je comprends c'est qu'il faut mettre le nom du réseau. >>>>> Les problèmes qui existent : >>>>> abrévié ou pas? >>>>> qu'est-ce qu'on fait quand il n'y a pas de nom? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> Le 2 août 2017 à 01:16, Jérôme Amagat <jerome.ama...@gmail.com> a >>>>>> écrit : >>>>>> >>>>>>> >>>>>>> >>>>>>> Le 1 août 2017 à 23:51, Philippe Verdy <verd...@wanadoo.fr> a écrit >>>>>>> : >>>>>>> >>>>>>>> "network=*" est une clé spéciale pour les recherches; on lui donne >>>>>>>> une valeur codée le rendant unique >>>>>>>> Pour donner un nom lisible à un réseau on a la relation >>>>>>>> type=network où la même valeur codée network=* est présente, mais le >>>>>>>> libellé lisible est dans le name=* standard, et où d'autres infos à >>>>>>>> propos >>>>>>>> du réseau peuvent être données (comme website=*, wikipedia=*, >>>>>>>> wikidata=*, >>>>>>>> contact:*=*, etc.) >>>>>>>> >>>>>>> >>>>>>> Où tu as vu ça? >>>>>>> Quand je regarde les valeurs déjà existante : >>>>>>> https://taginfo.openstreetmap.org/keys/network#values >>>>>>> il y a que quelques réseaux de bus français qui cette forme idiote >>>>>>> en fr_xxx >>>>>>> Pour le reste dans network=* il y a le nom du réseau >>>>>>> sauf pour les réseaux de routes nationales ou départementales (ou de >>>>>>> région ou d’état ou de conté ...) . (il y a aussi le cas bizarre des >>>>>>> network sur les type=route pour vélo) >>>>>>> Le FR en France si il doit apparaître c'est pour les route >>>>>>> nationales avec un network=FR:national , "network=FR:01:D-road for >>>>>>> departmental roads in Ain, France" comme indiqué sur le wiki mais pas >>>>>>> pour >>>>>>> les réseaux de bus. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Le 1 août 2017 à 21:44, Noémie Lehuby < >>>>>>>> noemie.leh...@openmailbox.org> a écrit : >>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> A-t-on vraiment un réseau de transports scolaires à part entière ? >>>>>>>>> si non, j'imagine qu'on peut les mettre dans le réseau Tisséo existant >>>>>>>>> (éventuellement avec un tag school = yes/only sur les relations route >>>>>>>>> et >>>>>>>>> route_master) >>>>>>>>> >>>>>>>>> >>>>>>>>> Pourquoi les noms des réseaux sont de cette forme ? >>>>>>>>> >>>>>>>>> Autant je comprends bien l'intérêt pour les ref ou les infos >>>>>>>>> particulières (un name:fr_tisseo ou type:fr_tisseo éventuel), mais le >>>>>>>>> tag >>>>>>>>> network, on le remplit avec le nom commercial du réseau tel qu'il est >>>>>>>>> connu >>>>>>>>> des voyageurs non ? >>>>>>>>> J'ai une grille horaire Tisséo sous le nez, et le nom du réseau >>>>>>>>> n'est pas fr_tisseo ... >>>>>>>>> >>>>>>>>> Désolée par avance si on a déjà eu ce débat (d'autant plus que >>>>>>>>> j'ai déjà vu ça sur d'autres réseaux aussi), mais j'ai rien trouvé >>>>>>>>> sur le >>>>>>>>> wiki qui l'explique :( >>>>>>>>> >>>>>>>>> >>>>>>>>> nlehuby >>>>>>>>> >>>>>>>>> Date: Tue, 1 Aug 2017 00:10:33 +0200 >>>>>>>>>> From: lenny <lenny.li...@orange.fr> >>>>>>>>>> To: OSM liste <talk-fr@openstreetmap.org> >>>>>>>>>> Subject: [OSM-talk-fr] bus : lignes de transport en commun >>>>>>>>>> Haute-Garonne : réseau >>>>>>>>>> Message-ID: <2adfd834-f5e3-33cd-0362-1aa7f94d8...@orange.fr> >>>>>>>>>> Content-Type: text/plain; charset="utf-8"; Format="flowed" >>>>>>>>>> >>>>>>>>>> Bonsoir, >>>>>>>>>> >>>>>>>>>> Je me suis penché sur les lignes de transport en commun de >>>>>>>>>> Toulouse et >>>>>>>>>> de la Haute-Garonne, et j'ai quelques questions et demandes >>>>>>>>>> d'avis ; >>>>>>>>>> mais je ne pose qu'un sujet dans chaque discutions pour ne pas me >>>>>>>>>> disperser, question "network"' >>>>>>>>>> >>>>>>>>>> 1 - Toulouse [1], >>>>>>>>>> >>>>>>>>>> 2 - le Département de la Haute-Garonne [2] >>>>>>>>>> >>>>>>>>>> 3 - les transports scolaires du Département de la Haute-Garonne >>>>>>>>>> [3] >>>>>>>>>> >>>>>>>>>> En ce qui concerne le réseau, >>>>>>>>>> >>>>>>>>>> 1 - le wiki indique "network=fr_tisseo" (dans taginfo 540 avec >>>>>>>>>> "fr_tisseo" et 3 avec "Tisséo") ; La plupart des contributeurs >>>>>>>>>> ont été >>>>>>>>>> conformes au wiki. >>>>>>>>>> >>>>>>>>>> 2- Le réseau de bus de la Haute-Garonne, s'appelle "Réseau des >>>>>>>>>> cars >>>>>>>>>> Arc-en-Ciel" (dans taginfo 42 "fr_arc_en_ciel" ; 5 "Arc-en-Ciel" >>>>>>>>>> ; 1 >>>>>>>>>> "Arc-en-ciel" ; 2 "Bus Arc en Ciel" ; 1 "réseau arc en ciel") ; >>>>>>>>>> (pour >>>>>>>>>> garder une cohérence avec le réseau sur Toulouse, je pense qu'il >>>>>>>>>> faut >>>>>>>>>> conserver le "fr_arc_en_ciel" bien que le "fr_" n'apporte pas >>>>>>>>>> l'unicité, >>>>>>>>>> il y a un réseau du même nom dans le Nord. >>>>>>>>>> >>>>>>>>>> 3- "network=transports_scolairesHG" ou >>>>>>>>>> "network=transports_scolaires31" >>>>>>>>>> ? je n'ai pas su trouver d'autres réseaux de transport scolaire >>>>>>>>>> dans OSM ... >>>>>>>>>> >>>>>>>>>> merci d'avance >>>>>>>>>> >>>>>>>>>> Leni >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> [1] https://www.tisseo.fr/ >>>>>>>>>> https://wiki.openstreetmap.org/wiki/Toulouse/Transports_en_commun >>>>>>>>>> >>>>>>>>>> [2] >>>>>>>>>> https://www.haute-garonne.fr/proximite/au-quotidien/reseau-d >>>>>>>>>> es-cars-arc-en-ciel >>>>>>>>>> https://wiki.openstreetmap.org/wiki/Haute-Garonne/Transports >>>>>>>>>> _en_commun >>>>>>>>>> >>>>>>>>>> [3] https://www.transportsscolaires.haute-garonne.fr/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Talk-fr mailing list >>>>>>>>>> Talk-fr@openstreetmap.org >>>>>>>>>> https://lists.openstreetmap.org/listinfo/talk-fr >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> @nlehuby >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Talk-fr mailing list >>>>>>>>> Talk-fr@openstreetmap.org >>>>>>>>> https://lists.openstreetmap.org/listinfo/talk-fr >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Talk-fr mailing list >>>>>>>> Talk-fr@openstreetmap.org >>>>>>>> https://lists.openstreetmap.org/listinfo/talk-fr >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Talk-fr mailing list >>>>> Talk-fr@openstreetmap.org >>>>> https://lists.openstreetmap.org/listinfo/talk-fr >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Talk-fr mailing list >>>> Talk-fr@openstreetmap.org >>>> https://lists.openstreetmap.org/listinfo/talk-fr >>>> >>>> >>> >>> _______________________________________________ >>> Talk-fr mailing list >>> Talk-fr@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/talk-fr >>> >>> >> >> _______________________________________________ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> >> >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
