Trop grande ou difficile à gérer??? Franchement même les plus grandes avec quelques centaines de membres ce n'est vraiment pas la mort, en comparaison de la taille et la complexité des relations route ! Une référence unique par route (ou route_master si on les utilise pour la v2). Leurs membres sont connus exhaustivement, et finis. Je ne vois pas où est la compelxité à gérer ça, la complexité est surtout sur les relations route! Le reste est vraiment trivial et fort pratique.
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
