Re: [OSM-talk-fr] relation network <> tags network

2017-08-24 Par sujet Philippe Verdy 
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

Re: [OSM-talk-fr] relation network <> tags network

2017-08-24 Par sujet marc marc 
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

2017-08-24 Par sujet Philippe Verdy 
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

2017-08-24 Par sujet marc marc 
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

2017-08-24 Par sujet Philippe Verdy 
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=318=
> 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

2017-08-24 Par sujet Jo 
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=318=
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

2017-08-24 Par sujet François Lacombe 
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

2017-08-24 Par sujet 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

Re: [OSM-talk-fr] relation network <> tags network

2017-08-24 Par sujet lenny.libre 



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

2017-08-23 Par sujet Philippe Verdy 
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

[OSM-talk-fr] relation network <> tags network

2017-08-23 Par sujet marc marc 
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