J'avoue ne pas avoir compris la discussion, trop complexe pour moi, je
n'ai donc pas d'avis sur la question ; ce qui me gênait c'était d'avoir
des valeurs différentes. Il y a pour les réseaux [1] et [2] des
relations de type=network
https://www.openstreetmap.org/relation/1518272
Attributs
description Réseau des transports en commun de l'agglomération
toulousaine
name Tisséo
network fr_tisseo
operator Tisséo
phone +33 5 61 41 70 70
type network
url http://www.tisseo.fr/sites/default/files/plan_detaille_reseau.pdf
website http://www.tisseo.fr
wikipedia fr:Tisséo
https://www.openstreetmap.org/relation/1546978
Attributs
name Arc-en-ciel
network fr_arc_en_ciel
operator Conseil Départemental de la Haute-Garonne
type network
website http://www.haute-garonne.fr/bus.asp
wikipedia fr:Réseau Arc-en-ciel de la Haute-Garonne
n'est-ce pas là qu'il faudrait ajouter le wikidata ? comment
l'utilise-t-on : wikidata=Q3456528 ?
faut-il créer un network particulier pour les transports scolaires ? Y
a-t-il d'autres lignes de transports scolaires ? je n'ai pas trouvé avec
bus=yes
Leni
Le 02/08/2017 à 11:35, Philippe Verdy 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
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
