L'ennui c'et que toutes les applications qui ont commencé à utiliser
network=* ont supposé que le nom indiqué derrière était unique, ce qu'il
n'est pas. En fait ils voulaient que ce soit bien un identifiant.
Comme cet identifiant rendu unique ne correspond pas au nom qu'on voudrait
donner aux
Le 22/08/2017 à 21:47, Noémie Lehuby a écrit :
Hello,
Si je peux me permettre un petit résumé intermédiaire :
On veut indiquer que les lignes (relations route_master) et les
parcours (relation route) appartiennent à un réseau. Je laisse de côté
pour le moment l'autre sujet sur le réseau sur
Hello,
Si je peux me permettre un petit résumé intermédiaire :
On veut indiquer que les lignes (relations route_master) et les parcours
(relation route) appartiennent à un réseau. Je laisse de côté pour le
moment l'autre sujet sur le réseau sur d'autres objets.
Je reprends mon exemple fictif
Le 22. 08. 17 à 20:32, lenny.libre a écrit :
> Le 20/08/2017 à 12:02, marc marc a écrit :
>>> - _"public_transport=platform"_ il me semble que les tags "network"
>>> sont nécessaires, surtout lorsque l'objet n'est pas encore membre d'une
>>> relation "route" ou "public_transport=stop_area"
>> ce
Le 20/08/2017 à 12:02, marc marc a écrit :
- _"public_transport=platform"_ il me semble que les tags "network"
sont nécessaires, surtout lorsque l'objet n'est pas encore membre d'une
relation "route" ou "public_transport=stop_area"
ce n'est pas "pas utile", c'est erroné que de dire
ä la base,la discussion avait commencé parce que pour le réseau arc en
ciel, le nom même du réseau est très hétéroclite et de plus 2 réseaux
différents semblent exister en France avec ce nom.
il aurait été pratique d'avoir 2 relations pour permettre au moins de
classer les objets dans le bon
Le 20/08/2017 à 12:02, marc marc a écrit :
Le 20. 08. 17 à 11:20, lenny.libre a écrit :
4- Bien que le wiki l'indique sur chaque objet,
quelle page ?
indiqué sur chaque objet, mais avec des degrés d'importance :
https://wiki.openstreetmap.org/wiki/Public_transport "recommended"
Les ref stables et id wikidata permettent à des scripts d'accéder sans
équivoque aux infos.
Les name (pourquoi pas network:name) sont destinés à des humains... les
deux se complètent et pour l'instant network=* fait (mal) un peu les deux.
Dans beaucoup de scripts, j'utilise les ref:INSEE
Le 21. 08. 17 à 23:20, osm.sanspourr...@spamgourmet.com a écrit :
>> MM> puisqu'il est mieux de faire sans relation network,
>> MM> le débat est rouvert sur comment les séparer facilement.
J>>> network:wikidata ...
MM>> cela implique de dépendre de wikipedia pour afficher/trouver le nom
MM>>
Le 21/08/2017 à 20:28, lenny.libre - lenny.li...@orange.fr a écrit :
Le wikidata qui me plaisait (en permettant avec osmose de contrôler)
m'a un peu refroidi depuis que je vois qu'il y a des manques de
rigueur et que si le nom change, il faudra certainement changer le
network et aussi le
Entre les deux mon cœur balance, au fur et à mesure de ce que je lis, je
change ... Je n'avais pas d'avis au départ, mais maintenant je n'en ai
pas plus.
Le 21/08/2017 à 02:05, Jérôme Amagat a écrit :
Je rappelles que les relations network n'est sur le wiki qu'a l’état
de proposition, que
MM> puisqu'il est mieux de faire sans relation network,
MM> le débat est rouvert sur comment les séparer facilement.
Le 21. 08. 17 à 13:42, Jo a écrit :
> network:wikidata ...
C'est une bonne solution pour contourner temporairement le problème.
Mais cela implique de dépendre de wikipedia pour
Le 21 août 2017 à 02:05, Jérôme Amagat a écrit :
> Je rappelles que les relations network n'est sur le wiki qu'a l’état de
> proposition, que cette proposition date de 2008, que rien n'a bougé sur
> cette proposition depuis 2013 (et plus après 2009 ce n'est que pour
network:wikidata ...
2017-08-21 12:30 GMT+02:00 marc marc :
> Le 21. 08. 17 à 02:05, Jérôme Amagat a écrit :
> > les relations network n'est sur le wiki qu'a l’état de proposition
> Tu as raison, on s'est un peu emballé.
> je change donc mon avis, chaque fois que je
Le 21. 08. 17 à 02:05, Jérôme Amagat a écrit :
> les relations network n'est sur le wiki qu'a l’état de proposition
Tu as raison, on s'est un peu emballé.
je change donc mon avis, chaque fois que je préconisais l'utilisation
d'une relation network devient l'utilisation du tag network.
Par contre
Je rappelles que les relations network n'est sur le wiki qu'a l’état de
proposition, que cette proposition date de 2008, que rien n'a bougé sur
cette proposition depuis 2013 (et plus après 2009 ce n'est que pour ajouté
des exemples). Il y a des ajouts sur la page de discutions un peu plus
récent
Le 20/08/2017 à 12:13, Jo a écrit :
Pouvez-vous me pointer sur une relation network utilisé dans le schéma
public transport? Je n'en ai jamais vu et je n'ai jamais eu un cas où
il me semblerait utile.
La relation
https://wiki.openstreetmap.org/wiki/Relations/Proposed/Network est sur
Rennes et Nantes l'utilisent, ce qui facilite le gros du chantier (même
s'il y a une page wiki dédiée, mais tout le monde ne sait pas éditer le
wiki non plus, c'est un autre outil de suivi).
Les autoroutes françaises l'utilisent. Les routes européennes l'ont
utilisé, mais ça a été supprimé depuis
Pouvez-vous me pointer sur une relation network utilisé dans le schéma
public transport? Je n'en ai jamais vu et je n'ai jamais eu un cas où il me
semblerait utile.
Mais j'ajoute network et operator sur tous les objets, les relations route
et route_master et les noeuds
Le 20. 08. 17 à 11:39, Philippe Verdy a écrit :
> L'outil semble aussi vouloir chercher les arrêts avec cette clé
quel outil ?
ce serrait l'occasion de leur soumettre le problème vu qu'en l'état
1) leur outil ne trouve pas tous les arrêts vu le mix de façon de faire
2) cela est un frein pour
Le 20. 08. 17 à 11:20, lenny.libre a écrit :
> 4- Bien que le wiki l'indique sur chaque objet,
quelle page ?
> est-il nécessaire de mettre "network" (et "network:wikidata") sur tous les
> objets ?
selon moi, non c'est une mauvaise habitude.
il faudrait le mettre sur la relation la + haute,
"network=*" sur les relations "type=route" est pour l'instant nécessaire
pour pas mal d'outils qui justement cherchent ces routes en utilisant cette
clé (et aussi la clé "operator=*" comme discriminant quand il y a plusieurs
opérateurs d'un même réseau), car le numéro de ligne n'est pas suffisant.
Le 09/08/2017 à 00:03, marc marc a écrit :
Le 08. 08. 17 à 21:51,osm.sanspourr...@spamgourmet.com a écrit :
4- est-il nécessaire de mettre operator sur tous les objets ?
Je voulais, sur ce fil, rester sur "network" et j'ai écris "operator",
je plane vraiment.
Après quelques jours
Un autre avantage de ne pas avoir le trajet c'est qu'il sera inutile de
découper les ronds points pour avoir de bons tracés.
Le 19/08/2017 à 20:20, osm.sanspourr...@spamgourmet.com a écrit :
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
> vous laisserez fr_arc_en_ciel sur tous les autres objets ?
Pourquoi ? Si c'est une référence Wikidata, a priori elle ne changera pas.
Et comme c'est un identifiant unique, on peut faire une modification
globale sans se poser de questions (à condition qu'il soit clair pour
les utilisateurs
Bonjour,
Excusez-moi de revenir là-dessus, mais continue de me chiffoner...
Si je comprend bien, vous mettez un identifiant de réseau dans le tag
network pour deux raisons :
* pour pouvoir stocker dans OSM des informations sur le réseau
(website, contact, etc) sans les dupliquer sur
Le 08. 08. 17 à 21:51, osm.sanspourr...@spamgourmet.com a écrit :
>> 4- est-il nécessaire de mettre operator sur tous les objets ?
> Tous les objets n'ont pas même "operator". La plateforme en tant
> qu'abris peut être géré par un pubeux. C'est pour ça que tu mets "oui" ?
> Si on mettait
Le 08/08/2017 à 13:34, lenny.libre - lenny.li...@orange.fr a écrit :
Le 07/08/2017 à 22:10, osm.sanspourr...@spamgourmet.com a écrit :
Le 07/08/2017 à 20:41, Jean-Yvon a écrit :
Je pense à l'outil générant le squelette d'une ligne.
Je pensais que ça avait à voir avec l'Overpass.
Trouvé :
Le 07/08/2017 à 04:58, Jo a écrit :
2017-08-06 23:44 GMT+02:00 lenny.libre >:
Le 06/08/2017 à 07:11, Jo a écrit :
Si tu vas faire passer à la revue tous les arrêts, il ne serait
pas très compliqué de créer un 'preset' pour
Le 07/08/2017 à 22:10, osm.sanspourr...@spamgourmet.com a écrit :
Le 07/08/2017 à 20:41, Jean-Yvon Landrac a écrit :
Je pense à l'outil générant le squelette d'une ligne.
Je pensais que ça avait à voir avec l'Overpass.
Trouvé :
http://www.overpass-api.de/public_transport.html
En fait avec
Le 07/08/2017 à 20:41, Jean-Yvon Landrac a écrit :
Je pense à l'outil générant le squelette d'une ligne.
Je pensais que ça avait à voir avec l'Overpass.
Trouvé :
http://www.overpass-api.de/public_transport.html
En fait avec Operator il est possible d'avoir des réseaux de même nom.
Mais pour
Le 07/08/2017 à 11:20, lenny.libre - lenny.li...@orange.fr a écrit :
Le 07/08/2017 à 10:50, osm.sanspourr...@spamgourmet.com a écrit :
(...)
Mais qu'est-ce qui empêche un outil de présenter CTRL - Compagnie de
transport de la région lorientaise (les /short name///et les /label/)
au lieu de
Le greffon wikidata montre déjà les 'balises'/label de wikidata.
Jo
2017-08-07 10:50 GMT+02:00 :
> Certes, plus c'est facile pour l'utilisateur, mieux c'est.
>
> Mais il ne faut pas confondre l'enregistrement en base et l'entrée par
> l'utilisateur.
>
> Oui
Le 07/08/2017 à 10:50, osm.sanspourr...@spamgourmet.com a écrit :
Certes, plus c'est facile pour l'utilisateur, mieux c'est.
Mais il ne faut pas confondre l'enregistrement en base et l'entrée par
l'utilisateur.
Oui entrer la valeur via le-s wikidata, tu peux oublier.
Mais qu'est-ce qui
Certes, plus c'est facile pour l'utilisateur, mieux c'est.
Mais il ne faut pas confondre l'enregistrement en base et l'entrée par
l'utilisateur.
Oui entrer la valeur via le-s wikidata, tu peux oublier.
Mais qu'est-ce qui empêche un outil de présenter CTRL - Compagnie de
transport de la
2017-08-06 23:44 GMT+02:00 lenny.libre :
> Le 06/08/2017 à 07:11, Jo a écrit :
>
> Si tu vas faire passer à la revue tous les arrêts, il ne serait pas très
> compliqué de créer un 'preset' pour standardiser tous les arrêts. Le preset
> peut contenir 3 'sjablônes' .
>
>
Le 06/08/2017 à 07:11, Jo a écrit :
Si tu vas faire passer à la revue tous les arrêts, il ne serait pas
très compliqué de créer un 'preset' pour standardiser tous les arrêts.
Le preset peut contenir 3 'sjablônes' .
Qu'entends-tu par "preset" ?
Lorsque nous avions effectué le changement de nom
Si tu vas faire passer à la revue tous les arrêts, il ne serait pas très
compliqué de créer un 'preset' pour standardiser tous les arrêts. Le preset
peut contenir 3 'sjablônes' .
L'autre option est d'en sélectionner une vingtaine à la fois, puis changer
les tags tous ensemble, puis les inspecter
Salut Lenny,
J'ai créé un style MapCSS appelé "Public Transport". Il montre les noms et
les ref pour les arrêts de bus, d'une façon bien plus visible.
Le style est disponible pour touse en JOSM. En anglais il est sous Map
paint styles.
Jo
2017-08-05 19:57 GMT+02:00 lenny.libre
Le 05/08/2017 à 12:00, Jo a écrit :
J'ai regardé un peu à Toulouse. PT_Assistant reporte des choses qui
seraient très faciles à corriger.
Vour préférez que je fasse un Hangout on Air ce soir pour faire un
screencast avec une démo? Ou vous préférez un hangout interactif
demain soir?
Jo
J'ai regardé un peu à Toulouse. PT_Assistant reporte des choses qui
seraient très faciles à corriger.
Vour préférez que je fasse un Hangout on Air ce soir pour faire un
screencast avec une démo? Ou vous préférez un hangout interactif demain
soir?
Jo
2017-08-05 10:00 GMT+02:00 lenny.libre
Le 05/08/2017 à 00:35, Jo a écrit :
Le mobilier urbain est entretenu par les communes (ou la région à
Bruxelles), pour moi il est moins intéressant si c'est JCDecaux ou qui
que ce soit pour les abribus et la pub dessus.
Pour moi, ces noeuds qui représentent les arrêts sont des objets
Voici une requête Overpass qui me permet de télécharger tous les arrêts
desservis par STIB/MIVB:
[timeout:120][out:xml];
(
node["highway"="bus_stop"]["operator"~"(^|;)(STIB/MIVB)(;|$)"];
);
out meta;
Même avant que toutes les relations route sont déjà renseignées.
Maintenant, ça devient facile
Le 05. 08. 17 à 01:26, Éric Gillet a écrit :
> Le 5 août 2017 à 01:04, marc marc a écrit :
>
> Pour ma part, le poteau, l'abribus, le marquage au sol sont des réalités
> physiques, celle que je vois par "survey"
> Je suis justement d'accord que le détail de JCDecaux n’intéresse pas
>
Peutetre nzije pas ete clair que he ne oarlais pzs de la Belgique qui est
encore tres différente de lz france en terme d'obligations légales des
collectivités locales ou de l'état et du fait du regime federal et des
instances differentes qui se recouvrent partiellement entre region et
communautés
Le 5 août 2017 à 01:04, marc marc a écrit :
> Pour ma part, le poteau, l'abribus, le marquage au sol sont des réalités
> physiques, celle que je vois par "survey"
> Je suis justement d'accord que le détail de JCDecaux n’intéresse pas
> grand monde- Mais ce n'est pas
Pour ma part, le poteau, l'abribus, le marquage au sol sont des réalités
physiques, celle que je vois par "survey"
Je suis justement d'accord que le détail de JCDecaux n’intéresse pas
grand monde- Mais ce n'est pas une raison pour y mettre une info erronée
par exemple pour l'ensemble de
Le mobilier urbain est entretenu par les communes (ou la région à
Bruxelles), pour moi il est moins intéressant si c'est JCDecaux ou qui que
ce soit pour les abribus et la pub dessus.
Pour moi, ces noeuds qui représentent les arrêts sont des objets
'logiques'./'abstraits'. Les bus/trams d'un
Bonsoir,
J>>> network=DLVB;TECB;TECCJ>>> operator=De Lijn;TEC
DC>> qu'il y ait 2 opérateurs m'interpelle
PV> Si l'arrêt est sur le domaine public,
PV> c'est de la compétence des communes,
non, ce n'est pas le cas partout.
entre Tec et De Lijn hors Bruxelles, j'ignore comment cela se passe.
Si l'arrêt est sur le domaine public, c'est de la compétence des communes,
elle fera payer le ou les opérateurs présents qu'elle a autorisé ou leur
demandera de faire les travaux nécessaires. La commune pourtant ne gère pas
nécessairement l'équipement, les opérateurs eux-mêmes pouvant se mettre
Bonjour
Le 04/08/2017 à 19:07, Jo a écrit :
network=DLVB;TECB;TECC
operator=De Lijn;TEC
Dans l'histoire, qu'un arrêt soit utilisé par plusieurs réseaux pourquoi
pas. Mais qu'il y ait 2 opérateurs m'interpelle. Comment un arrêt
peut-il être géré par 2 opérateurs ?
Dans cette philosophie, il
>
> A minima, il faut qu'on indique que ce n'est pas un réseau qu'on a dans
> network, mais un identifiant de réseau (tag network_id ? network:wikidata ?
> ;) )
>
>
>
> Date: Fri, 4 Aug 2017 09:08:35 +0200
> From: Jo <winfi...@gmail.com>
> To: Discussions sur OSM en f
>
> To: Discussions sur OSM en français <talk-fr@openstreetmap.org>
> Subject: Re: [OSM-talk-fr] bus : lignes de transport en commun
> Haute-Garonne : réseau
> Message-ID:
>
Salut Lenny,
Le Conseil Départemental de la Haute-Garonne organise les transports
publics sur le Département hors Métropole y compris les transports
scolaires (le lien de la page du wiki qui renvoi vers Tisséo est
erroné).
Un exemple, la commune de Ondes http://www.mairie-ondes31.fr/f
L'idée serait d'avoir
operator=
operator:wikidata=Q...
ensemble, le même pour network, S'il y a ambiguité, les tags wikidata
seront différents et ça permet d'utiliser des valeus 'concis' pour
operator/network/brand.
Polyglot
2017-08-04 9:00 GMT+02:00 Christian Quest
Attention, les tags wikidata sont utiles pour établir un lien avec
wikidata, mais si c'est pour aller y chercher le nom du réseau ce n'est
pas une bonne solution.
Il est déjà complexe de retrouver certaines infos qui sont dans OSM par
un usage parfois abusif des relations, mais si il faut en
Ce cas n'est pas unique: les transports en commun dans un territoire n'ont
l'exclusivité de leur organisation que dans les EPCI de type métropole,
communauté urbaine, ou communauté d'agglomération. Sinon les EPCI peuvent
décider de partager certaines lignes entre leurs communes, ou bien les
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
Le 01/08/2017 à 21:44, Noémie Lehuby 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)
Tisséo gère
Autre argument: les lignes de transport sont souvent (et de plus en plus)
cogérées: plusieurs opérateurs, ou appartiennent à plusieurs réseaux
simultanément.
Le 2 août 2017 à 11:35, Philippe Verdy a écrit :
> Et tu ajoutes tout un tas de tags redondants en plus, dont la
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
<winfi...@gmail.com>
> To: "Discussions sur OSM en français" <talk-fr@openstreetmap.org>
> Cc:
> Bcc:
> Date: Wed, 2 Aug 2017 08:18:57 +0200
> Subject: Re: [OSM-talk-fr] bus : lignes de transport en commun
> Haute-Garonne : réseau
> Pour les réseaux de cyc
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
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
Le 2 août 2017 à 02:51, Philippe Verdy 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
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
Le cas bizarre de network=rcn/lcn/ncn/icn pour le réseaux cyclistes, comme
nwn (randonnée) et rhn (équestre) était en usage avant que le tag network
était utilisé pour les réseaux de transport en commun.
Il sert á colorier les différent niveaux sur les rendu cyclisme et de
randonnée.
Polyglot
Le 2 août 2017 à 01:35, Philippe Verdy 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
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
Le 1 août 2017 à 23:51, Philippe Verdy 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,
"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 à
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 ?
72 matches
Mail list logo