[OSM-talk-fr] relation network <> tags network
Dans le but d'éviter de noyer l'autre discussion avec ce point, j'en fais un sujet séparé. Si je résumé les différents avis, il y a : 1) les relations network ont des avantages (l'unicité même en cas de nom identique, sélectionner tout un réseau) pour un coût réduit donc utilisons les. 2) les relations de catégorie sont pour l'instant refusée dans osm, donc utile ou pas, il faut s'en passer. 3) l'important est d'avoir une ref unique (wikidata et/ou ref osn) ce qui permet d'avoir les avantages des relations (même si coût + élevé) Lever l’ambiguïté en cas de nom identique est possible avec cette ref et/ou par géographique de la même manière que lorsqu'il existe 2 rues avec le même nom. est-ce que j'ai bien résumé la situation ? 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. Parce que les exemples théoriques, tout le monde est d'accord, une relation est plus pratique que sélectionner les x route_master ayant le tag du réseau. A l'inverse sélectionner x route_master d'un réseau n'est pas un drame non plus. Mon avis : aucun consensus pour le 1 donc à éviter parce que sinon yo-yo entre les pro-relation et les pro-tag-network. mais rien ne t'empêche Philippe, voir même je te conseille, de raviver la proposition à ce sujet afin d'essayer de la faire adopter. d'accord avec le 2 et le 3 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] relation network <> tags network
Le 24 août 2017 à 01:31, marc marc 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 c
Re: [OSM-talk-fr] relation network <> tags network
Le 24/08/2017 à 01:31, marc marc a écrit : Dans le but d'éviter de noyer l'autre discussion avec ce point, j'en fais un sujet séparé. Si je résumé les différents avis, il y a : 1) les relations network ont des avantages (l'unicité même en cas de nom identique, sélectionner tout un réseau) pour un coût réduit donc utilisons les. 2) les relations de catégorie sont pour l'instant refusée dans osm, donc utile ou pas, il faut s'en passer. 3) l'important est d'avoir une ref unique (wikidata et/ou ref osn) ce qui permet d'avoir les avantages des relations (même si coût + élevé) Lever l’ambiguïté en cas de nom identique est possible avec cette ref et/ou par géographique de la même manière que lorsqu'il existe 2 rues avec le même nom. est-ce que j'ai bien résumé la situation ? 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. Parce que les exemples théoriques, tout le monde est d'accord, une relation est plus pratique que sélectionner les x route_master ayant le tag du réseau. A l'inverse sélectionner x route_master d'un réseau n'est pas un drame non plus. Mon avis : aucun consensus pour le 1 donc à éviter parce que sinon yo-yo entre les pro-relation et les pro-tag-network. mais rien ne t'empêche Philippe, voir même je te conseille, de raviver la proposition à ce sujet afin d'essayer de la faire adopter. d'accord avec le 2 et le 3 ___ 1) Quand je vais sur le site du réseau que je consulte, je télécharge le plan des lignes (c'est un network) - dans osm si je consulte la relation network correspondante je vois les lignes qui la composent Ensuite sur le site, je prends une ligne, j'ai le tracé emprunté par la ligne et les arrêts - dans osm si je consulte la relation route, j'obtiens la même chose Je peux naviguer sur les lignes des deux réseaux sur la Haute-Garonne en partant des arrêts ou des relations que ce soit dans l'interrface d'osm https://www.openstreetmap.org/relation/3814393 ou dans josm, juste en cliquant sur les liens 2) d'accord, mais je ne vois pas bien la différence entre une relation network et une relation route, je ne comprends pas pourquoi la relation network serait une relation catégories 3) je ne programme pas, à partir d'overpass, je sais retrouver des éléments qui ont une info, mais pas deux, je passe d'accord avec 1 et 2 leni ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] relation network <> tags network
Le 24. 08. 17 à 02:41, Philippe Verdy a écrit : > Le 24 août 2017 à 01:31, marc marc 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. Est-ce que tu peux alors stp me dire CLAIREMENT+SOMMAIREMENT quel argument/problème je n'ai pas compris lorsque j'ai essayé de résumer ton avis avec la phrase suivante : "les relations network ont des avantages (l'unicité même en cas de nom identique, sélectionner tout un réseau) pour un coût réduit donc utilisons les." Tu réponds en 3 pages allant du train à l'Europe. Mais après les avoir lues, je ne n'ai pas mieux compris mon erreur. Le 24. 08. 17 à 02:41, Philippe Verdy a écrit : > problème des applis qui attendent une valeur précise Nous sommes visiblement au moins 3 à n'avoir toujours pas compris non plus de quel appli tu parles. pas d'exemple ? donc aucune ? donc on a toute liberté de mettre cela en ordre, c'est justement l'objet des 2 sujets (l'un pour le sens du tag network, celui-ci pour "choisir" relation network ou pas relation) Au niveau applicatif, la différence est : avec relation network : sélectionner relation type=network oü network=xyz + ses fils sans relation network : sélectionner relation type=route_master oü network=xyz + ses fils Une différence d'UN mot, les vrais problèmes sont ailleurs, non ? Le 24. 08. 17 à 02:41, Philippe Verdy a écrit : > mythe façon OSM qui confond ça avec des collections ouvertes comme je te le disais, participe donc à la proposition relation network Parce que me redire leur utilité que je connais ne sert à rien. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] relation network <> tags network
Hello, Je m'invite un peu dans la discussion. Ca me rappelle cet échange de l'année dernière à la même période où il était aussi question des relations vs utilisation de ref sur les routes départementales Le 24 août 2017 à 10:45, lenny.libre a écrit : > 1) Quand je vais sur le site du réseau que je consulte, je télécharge le > plan des lignes (c'est un network) - dans osm si je consulte la relation > network correspondante je vois les lignes qui la composent > Ensuite sur le site, je prends une ligne, j'ai le tracé emprunté par la > ligne et les arrêts - dans osm si je consulte la relation route, j'obtiens > la même chose > Je peux naviguer sur les lignes des deux réseaux sur la Haute-Garonne en > partant des arrêts ou des relations que ce soit dans l'interrface d'osm > https://www.openstreetmap.org/relation/3814393 ou dans josm, juste en > cliquant sur les liens > Très bon point sur les fonctionnalités de visualisation d'osm.org qui privilégie clairement les relations sur les communautés d'attributs > 2) d'accord, mais je ne vois pas bien la différence entre une relation > network et une relation route, je ne comprends pas pourquoi la relation > network serait une relation catégories > Une relation de route est une suite nécessairement d'objets continus, et avec bien souvent un seul itinéraire pour aller de A à B. Un network n'est pas forcément continu et avec une multiplicité d'itinéraires. A+ François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] relation network <> tags network
Salut Lenny, J'espère que je vais pas troubler encore plus "l'eau"... Pour l'exemple de l'application: http://www.overpass-api.de/api/sketch-line?network=DLVB&ref=318&operator= http://www.overpass-api.de/public_transport.html Ce que moi je préfère avec la solution de tagger les objets c'est qu'il n'y a pas de relation à entretenir. Maintenir des relations est moins évident que cela ne le semble. S'il y a quelqu'un qui enlève un membre, combien de temps se passe-t-il avant que l'on s'en rend compte? Les mettre dans les tags implique que des fois un object (arrêt, route) appartient à plusieurs réseaux, mais cela ne pose pas de problème. On peut les séparer par ; Jo 2017-08-24 11:10 GMT+02:00 marc marc : > Le 24. 08. 17 à 02:41, Philippe Verdy a écrit : > > Le 24 août 2017 à 01:31, marc marc 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. > > Est-ce que tu peux alors stp me dire CLAIREMENT+SOMMAIREMENT > quel argument/problème je n'ai pas compris lorsque j'ai essayé > de résumer ton avis avec la phrase suivante : > "les relations network ont des avantages (l'unicité même en cas de nom > identique, sélectionner tout un réseau) pour un coût réduit donc > utilisons les." > > Tu réponds en 3 pages allant du train à l'Europe. > Mais après les avoir lues, je ne n'ai pas mieux compris mon erreur. > > Le 24. 08. 17 à 02:41, Philippe Verdy a écrit : > > problème des applis qui attendent une valeur précise > Nous sommes visiblement au moins 3 à n'avoir toujours pas compris non > plus de quel appli tu parles. > pas d'exemple ? donc aucune ? donc on a toute liberté de mettre cela en > ordre, c'est justement l'objet des 2 sujets (l'un pour le sens du tag > network, celui-ci pour "choisir" relation network ou pas relation) > Au niveau applicatif, la différence est : > avec relation network : sélectionner relation type=network oü > network=xyz + ses fils > sans relation network : sélectionner relation type=route_master oü > network=xyz + ses fils > Une différence d'UN mot, les vrais problèmes sont ailleurs, non ? > > Le 24. 08. 17 à 02:41, Philippe Verdy a écrit : > > mythe façon OSM qui confond ça avec des collections ouvertes > comme je te le disais, participe donc à la proposition relation network > Parce que me redire leur utilité que je connais ne sert à rien. > ___ > 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
Re: [OSM-talk-fr] relation network <> tags network
Le 24 août 2017 à 12:04, Jo a écrit : > Salut Lenny, > > J'espère que je vais pas troubler encore plus "l'eau"... > > Pour l'exemple de l'application: > http://www.overpass-api.de/api/sketch-line?network=DLVB&ref=318&operator= > http://www.overpass-api.de/public_transport.html > > Ce que moi je préfère avec la solution de tagger les objets c'est qu'il > n'y a pas de relation à entretenir. > > Maintenir des relations est moins évident que cela ne le semble. S'il y a > quelqu'un qui enlève un membre, combien de temps se passe-t-il avant que > l'on s'en rend compte? > Concernant les relations "type=network" on se rend compte **immédiatement** qu'il manque une ligne à la liste qui est très synthétique: ses membres sont chacune des lignes numérotées (et normalement classées dans des numéros de ligne, bien que ce ne soit pas une obligation), et on en connait le nombre avant même d'avoir commencé à les tracer ou les chercher. On sait immédiatement quelles lignes sont fermées et qu'on peu retirer. Si toutes les lignes ont leur relations réseau attachées (et il ne doit y encore qu'une sauf cas exceptionnel des lignes cogérées sur plusieurs réseaux et qui reconnaissent sur ces lignes la validité des titres de transport émis par l'un ou l'autre des réseaux...), on ne peut pas créer de doublon sans que ça se voit aussi **immédiatement** dans la relation parente. > Les mettre dans les tags implique que des fois un object (arrêt, route) > appartient à plusieurs réseaux, mais cela ne pose pas de problème. On peut > les séparer par ; > - un unique tag "network=" par route (dans les liste de ses tags) ne suffit pas on l'a vu, et n'est pas clair du tout, souvent erroné. - une seule relation parente "type=route" par route (ou bien une seule relation parente "super-route" ou "route_master", jamais simultanément) suffit à tout et est clairement identifiée, on ne fait pas d'erreur et en cas de doute on peut cliquer dessus pour en voir le contenu et les tags de description et toutes ses références utiles. Ce n'est pas plus long ni plus compliqué à éditer et jamais ambigu. - la présence de l'un n'empêche pas l'autre mais en cas de doute ou conflit, l'ambiguïté intrinsèque du tag (historique issu du schéma v1) ne résout rien facilement, et le tag n'est pas nécessaire si on a la relation parente, c'est juste une redondance pour la compatiblité v1, alors que la relation parente est toujours non ambiguë. Quant à la présence aussi bien du tag "network=*" ou d'une relation parente "type=network" ailleurs que les relations "type=route" (ou "type=super_route" ou "type=route_master"), elle ne se justifie pas dans aucun des deux cas : - Les arrêts et plateformes et sont référencés par les relations "type=route" ou "type=stop_area" qui les incluent. - il n'y a aucun arrêt ou plateforme dans une super_route ou route_master dont les membres ne sont que des relations routes ou super_route. Donc aucun ajout de tag ou ni de relation network nécessaire sur les arrêts et plateformes (s'il y en a c'est de la redondance pour la compatibilité v1 sur les "highway=bus_stop" qui sont en fait des plateformes en v2, mais le plus souvent les plateformes ne font pas partie directement d'un réseau mais ne concernent qu'un "operator=*" exploitant). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] relation network <> tags network
Le 24. 08. 17 à 21:42, Philippe Verdy a écrit : > Le 24 août 2017 à 12:04, Jo a écrit : > S'il y a quelqu'un qui enlève un membre, combien de temps se > passe-t-il avant que l'on s'en rend compte? > Concernant les relations "type=network" on se rend compte > **immédiatement** qu'il manque Des objets network arc-en-ciel Haute-Garonne sont absente de la relation network, qui les as vu ? moi uniquement maintenant, sans utiliser la relation network. Le 24. 08. 17 à 22:20, Philippe Verdy a écrit : Le 24 août 2017 à 12:29, marc marc a écrit : Le 23. 08. 17 à 21:43, Philippe Verdy a écrit : >>> comment savoir alors les distinguer quand dans >>> les deux cas ce sont des objets très étendus >> Par géographie, comme lorsqu'il y a 2 rues du même nom. > Pas du tout. tu oublies la contrainte "très étendue" Si pour toi c'est impossible de séparer arc en ciel Nord et Haute-Garonne, moi, pas au courant de la difficulté, je le fais dans le message suivant (alors qu'ils n'ont pas encore d'id unique) Si tu as un exemple de 2 réseaux de bus ayant le même nom et ayant une couverture tellement "étendue" que TU n'arrive pas à les séparer géographiquement, donne leur nom stp. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] relation network <> tags network
Le 24 août 2017 à 23:47, marc marc a écrit : > Le 24. 08. 17 à 21:42, Philippe Verdy a écrit : > > Le 24 août 2017 à 12:04, Jo a écrit : > > S'il y a quelqu'un qui enlève un membre, combien de temps se > > passe-t-il avant que l'on s'en rend compte? > > Concernant les relations "type=network" on se rend compte > > **immédiatement** qu'il manque > Des objets network arc-en-ciel Haute-Garonne sont absente > de la relation network, qui les as vu ? > moi uniquement maintenant, sans utiliser la relation network. > Parce que tu travailles sur ces lignes. D'une façon générale il faut être contributeur actif pour savoir qu'il y en a et qu'on en utilise. OSM étant incrémental, et les réseaux étant à peine commencés dans OSM, c'est normal qu'elles soient encore incomplètes. Mais quand un gros chantier est entreprise localement, on ne peut pas ne pas les remarquer et en tirer profit. > Le 24. 08. 17 à 22:20, Philippe Verdy a écrit : > Le 24 août 2017 à 12:29, marc marc a écrit : > Le 23. 08. 17 à 21:43, Philippe Verdy a écrit : > >>> comment savoir alors les distinguer quand dans > >>> les deux cas ce sont des objets très étendus > >> Par géographie, comme lorsqu'il y a 2 rues du même nom. > > Pas du tout. tu oublies la contrainte "très étendue" > Si pour toi c'est impossible de séparer arc en ciel Nord et > Haute-Garonne, moi, pas au courant de la difficulté, je le fais dans le > message suivant (alors qu'ils n'ont pas encore d'id unique > Ca c'est parce que tu t'intéresse à cette donnée en tant que contributeur sur une zone précise. Si on veut en faire un usage plus générale dans des outils de consultation grand public, il faudra bien régler ce problème de cohérence pour que ces outils ne soient pas trompés par les ambiguïtés avec des objets inattendus situés n'importe où dans le monde, l'outil pouvant lui même avoir une utilisation globale (comme OSRM) en partant de n'importe où dans le monde et aller n'importe où et profiter des transports en commun à l'arrivée et des possibilités de corespondances pour son séjour: lors de la recherche sur une destination, les noms des réseaux sont totalement indéterminés. Même un outil moins ambitieux (par exemple européen ou seulement national) tombera sur ces difficultés: les réseaux sont de complexité et de taille TRES différente (surtout si on tient compte de l'intermodalité: avions, trains, voitures, bus, ferries, parcours à vélo ou à pied). Prévois un voyage touristique et tu peux te demander s'il vaut mieux y aller en train ou voiture, et selon ce choix et la durée maximale prévue pour ce séjour, tu ne choisiras pas les mêmes hôtels, gites ou campings, tu n'auras pas le même équipement à emporter ou trouver sur place, ni les mêmes visites sur place. Si c'est pour travailler tu peux envisager un déménagement et tu chercheras les services à proximité et comment y aller et organiser ta vie. Les transports en commun ne se limitent pas à un itinéraire sur une seule ligne, ils sont fortement liés à tes autres activités et besoins et fonctionnent à des échelles très différentes qui se combinent entre elles. Au lieu de lignes simples (instables et difficiles à maintenir), les réseaux organisés offrent un vrai plus en terme de stabilité. Les sociétés de transport justement se construisent non pas sur une seule ligne majeure et quelques arrêts, mais sur un ensemble plus vaste relié au reste. Les réseaux en plus associent de nombreux acteurs et des collectivités de nature et taille très différentes. Bref tu ne sauras pas que ce que tu cherches se limite à la Haute-Garonne ou au Nord, même si dans cet exemple ces départements sont très éloignés. Tu peux vouloir faire une application spécialisée pour ces deux zones, mais les utilisateurs trouveront plus pratique une application globale permettant de tout trouver, de la même façon qu'OSM est une base de données mondiale qu'on consulte de n'importe où vers n'importe où. Bref ton point de vue manque d'ambition et crois qu'on sera efficace en se concentrant d'abord et seulement sur le détail sans s'intéresser en premier lieu à la vision globale qui permet de planifier le travail à faire et le rendre cohérent, sans retirer aucun intérêt pour les modifications locales (qui n'ont pas beaucoup d'usage et de sens si on n'envisage même pas de les relier au reste). Plus au aura de données, et plus le besoin de les organiser de façon cohérente et sans ambiguïté se fera sentir, permettant des recherches efficaces et précises. Je pense que tu ne t'en rend pas compte encore car même en France seulement le travail n'a commencé que dans les agglomérations les plus denses où les transports sont les plus fréquentés. Mais même là on a des difficultés avec les homonymies (notamment les noms des arrêts!) et les cas de réorganisation des réseaux et évolutions des coopérations entre collectivités et la concurrence des transporteurs imposée à l'échelle européenne: les réseaux se chevauchent de plus en plus. _
Re: [OSM-talk-fr] relation network <> tags network
Le 25. 08. 17 à 00:38, Philippe Verdy a écrit : comment savoir alors les distinguer quand dans les deux cas ce sont des objets très étendus Par géographie, comme lorsqu'il y a 2 rues du même nom. >>> Pas du tout. tu oublies la contrainte "très étendue" >> Si pour toi c'est impossible de séparer arc en ciel Nord et >> Haute-Garonne, moi, pas au courant de la difficulté, je le fais > Ca c'est parce que tu t'intéresse à cette donnée en tant que > contributeur sur une zone précise. Je n'ai aucune affinité ni avec le sujet ni avec la zone précise. Je me propose pour le faire parce que 1) c'est utile pour améliorer la situation. 2) c'est simple et rapide. Mais malgré de nombreuses demandes, tu n'as aucun exemple de problème REEL à fournir, tu parles de potentiels futurs réseaux de bus mondiaux multiples avec le même nom. Et vu que tu préfère ignorer qu'on a AUSSI parlé d'un id unique, le jour où cela arrivera, l'id unique fait que ce serra encore plus facile (= en une ligne) pour les identifier que pour les réseaux "Arc en ciel". Bref, la solution d'unicité est possible avant même qu'une application qui n'existe pas encore ai un problème pour séparer 2 réseaux de même noms lorsqu'ils auront une étendues imbriquée. woaw la solution avant le problème. Cela n’empêche PAS que les relations ONT aussi des avantages. Qu'attends-tu pour proposer ton aide à son adoption ? Bref on tourne en rond. Si personne n'a envie de mettre ses mains dans le cambouis pour faire avancer cette proposition, elle restera en l'état. Sauf avancée, je ferrai un dernier résumé des pour<>contre au cas où quelqu'un veux s'y mettre ou si le sujet reviens dans X temps. Après cela, je pense que la discussion sur ce point est stérile. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] relation network <> tags network
Le 25 août 2017 à 01:20, marc marc a écrit : > Le 25. 08. 17 à 00:38, Philippe Verdy a écrit : > comment savoir alors les distinguer quand dans > les deux cas ce sont des objets très étendus > Par géographie, comme lorsqu'il y a 2 rues du même nom. > >>> Pas du tout. tu oublies la contrainte "très étendue" > >> Si pour toi c'est impossible de séparer arc en ciel Nord et > >> Haute-Garonne, moi, pas au courant de la difficulté, je le fais > > Ca c'est parce que tu t'intéresse à cette donnée en tant que > > contributeur sur une zone précise. > Je n'ai aucune affinité ni avec le sujet ni avec la zone précise. > Je me propose pour le faire parce que > 1) c'est utile pour améliorer la situation. > 2) c'est simple et rapide. > Dans ton cas où tu t'intéresses à tes contributions dans une ville que tu connais bien et que tu situes facilement tu n'as pas de difficultés à ajouter un critère. Dans une utilisation plus générale et vu des autres contributeurs qui s'intéressaient à une autre zone, et tombe tout à coup sur des éléments inattendus situés dans ton coin, là oui ça pose problème et ça peut les bloquer: lequel des deux ira modifier le tag utilisé en conflit par l'autre? On risque de faire du yoyo à coup de reverts mutuels stériles entre les besoins des uns et des autres qui ont des outils et méthodes de travail différents et pas concertés du tout, alors qu'on peut s'en prémunir facilement. > Mais malgré de nombreuses demandes, tu n'as aucun exemple > de problème REEL à fournir, tu parles de potentiels futurs > réseaux de bus mondiaux multiples avec le même nom. > Faux, j'en ai parlé. Et j'ai cité le cas des réseaux officiellement multilingues (en Suisse et Belgique, il y en a aussi en Espagne). Le nom n'est pas un identifiant unique comme on a cru le faire avec le tag "network=*" pas fait pour ça. Et maintenant ce que je critique c'est la nécessité de collectionner les tags "network:=*" pour désigner en fin de compte un même réseau (quel que soit le ou les noms qu'on lui donne) et de penser qu'on devra maintenir ce fatras dans des tas d'objets. Wikidata, Wikipedia, et autre c'est bien comme info, mais autant regrouper ça dans un seul objet OSM et pas des centaines. Et vu que tu préfère ignorer qu'on a AUSSI parlé d'un id unique, C'est un peu fort de me dire ça à moi, alors que c'est moi qui ait justement abordé ce problème qui commence à être un peu compris ! Et là dessus certains ont embarqué en proposant des identifiants externes (hors OSM dans des bases qui ne sont pas mises à jour avec la même politique d'inclusion, pas consultables avec les mêmes outils, pas synchronisées, et pas connues de tout le monde et qui obligerait la communauté à se diviser entre ceux qui connaissent et comprennent la base tierce, et les autres à qui on demande d'accepter une politique d'édition et de publication très différente, avec des interlocuteurs très différents dont la majorité n'a que faire des besoins propres à OSM et ne veut pas avoir à se charger de ce qu'OSM ne voudrait pas faire lui-même avec sa propre communauté et ses propres outils partagés). Cela n’empêche PAS que les relations ONT aussi des avantages. > Qu'attends-tu pour proposer ton aide à son adoption ? > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr