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
