Re: [OSM-talk-fr] Données nominatives dans OSM

2017-08-01 Par sujet osm . sanspourriel 
Bonne réponse valable pour opening_hours avec les mêmes restrictions 
signalées si on référence l'url (voir ci-dessous).


Une personne qui utilise son nom comme nom de société perd le côté privé 
de son nom.
Si la « Pharmacie Gouiffès » a pour enseigne « Pharmacie Gouiffès », il 
ne s'agit plus vraiment d'une information nominative au sens usuel du 
terme et name=Pharmacie Gouiffès est correct.
Ici 
 
je vois ANNIE & GERMAINE GOUIFFES comme nom de société donc pas de soucis.


Jean-Yvon

Le 26/07/2017 à 21:37, Philippe Verdy - verd...@wanadoo.fr a écrit :
L'autre solution c'est de mettre en valeur une URI vers un document 
externe contenant la chaîne complète. Mais on sort de la base de 
données pour aller n'importe où sur des données potentiellement non 
libres et jamais sous contrôle direct de la communauté OSM qui ne 
saura jamais quand cette ressource externe est modifiée sans aller la 
chercher explicitement (avec le risque que quelqu'un aille y mettre 
des gigaoctets de données aléatoires et planter un utilisateur de la 
base) ni qui l'a fait, et aussi le risque de fermer l'accès aux 
modications (raison pour laquelle on admet wikipedia= 
ou wikidata=Q et non pas des URLs libres en valeur (qui ne sont 
admises que pour website sur un objet précis directement associable à 
un domaine).



Le 28/07/2017 à 03:39, Philippe Verdy - verd...@wanadoo.fr a écrit :
Une URL accessible, publiée et indexée volontairement par les sites en 
question sur tous les moteurs de recherche (sans restriction du type 
robots.txt) est une donnée publique non soumise au copyright, le 
copyright s'applique seulement aux contenus diffusés via cette URL et 
sinon il y a des clauses d'usage raisonnable protégeant les sites des 
abus ou les protégeant des attaques massives de déni de service. C'est 
d'autant plus vrai si l'URL est limitée au nom de domaine publié et ne 
contient pas d'autres données: en principe une URL simple sans 
paramètres (juste le chemin) est libre sauf spécification contraire 
par le site en question indiquant que les noms dans les chemins sont 
aussi protégés.
Je n'ai jamais vu nulle part le moindre problème judiciaire relatif à 
la publication d'une URL vers un contenu diffusé légalement par le 
site en question: si problème il y a c'est chez le titulaire du site, 
mais on n'est pas là pour enquêter et vérifier ses propres droits de 
diffusion, on pourra juste retiter des sites a posteriori en voyant 
que cela ne concerne pas la donnée OSM elle-même ou si on constate que 
ce site est malveillant lors de son accès.


Le 28 juillet 2017 à 01:14, Muselaar > a écrit :



Le 10/01/2017 à 22:29, Vincent de Château-Thierry a écrit :

Bonsoir,

[…]
Parmi les informations que vous allez recueillir, celles qui
ont leur place dans OSM sont celles qui à la fois :
[…]
- ne contiennent pas d'informations nominatives (nom du
gérant, etc)

Bonsoir,

En recherchant des informations à d'autres propos, je tombe sur ce
passage qui m'interpelle, puisque je viens justement d'indiquer
des noms sur des POI, sous la clé « operator ». Y a-t-il quelque
part sur le wiki des précisions sur la règle à suivre à ce sujet ?
Je n'ai pas trouvé.
La question ne me semble pas simple : si l'on indique un
professionnel qui n'a pas d'autre élément d'identification que ses
nom et prénom, faut-il quand même les omettre, et indiquer
uniquement la profession ? Autre cas, si l'enseigne indique «
Pharmacie Gouiffès », du nom de son propriétaire, faut-il aussi
l'omettre ? Si le professionnel dispose d'une enseigne, mais
distribue des petites cartes avec ses nom et prénom en gros,
l'enseigne n'apparaissant qu'en sous-titre, faut-il aussi les
omettre ? Et si l'enseigne comporte le nom du propriétaire intégré
à d'autres mots ? Si l'adresse de contact d'un établissement est
celle de son propriétaire, indiquant en clair ses nom et prénom,
faut-il aussi se passer de l'adresse mail ?
En cherchant des infos sur OSM (au moyen d'OsmAnd) pendant mes
vacances, j'ai trouvé plusieurs professionnels libéraux dont le
nom était indiqué sous la clé « name », est-ce erroné, faut-il les
retirer quand on en trouve ?

[…]
- et bien sûr sont issues de sources dont le copyright est
compatible avec l'ODbL. S'il s'agit de vos propres relevés de
terrain c'est a priori sans souci.

Là, je me pose la question des adresses de site web, quid du
copyright ?

Dans l'attente fiévreuse de ses éclaircissements,

Muselaar

___
Talk-fr mailing list
Talk-fr@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk-fr





_

Re: [OSM-talk-fr] Données nominatives dans OSM

2017-08-01 Par sujet Philippe Verdy 
Je parlais juste du tag opening_hours et du fait que sa valeur est limitée
en taille. pour aller au delà on n'a pas d'autres solutions que d'éclater
en plusieurs tags ou mettre une référence externe aux données complètes. Et
là le problème est alors l'accès à cette ressource externe: les URLs posent
problème car elles sont incontrôlables et leur contenu n'est pas soumis à
la licence OdBL et sont intrinsèquement non sûres (au moins les reférénces
de type URN comme Wikipedia=* ou wikidata=* sont sur une base externe
accessible et libre, mais pas avec la même licence). Il manque à OSM le
support de données plus libres et pas aussi contraintes que les tags
actuels. Ce serait bien de pouvoir mettre des données JSON dans un
catalogue annexe mais supporté par la licence ODbL et obéissant aux mêmes
conditions des contributeurs que le reste de la base.

Rien à voir donc avec le problème des données nomitatives (là c'est une
question de protection de la vie privée et des droits exclusifs des
personnes, pas du tout lié à la représentation des données dans la base ou
à une contrainte technique comme leur taille)

Le 1 août 2017 à 12:21,  a écrit :

> Bonne réponse valable pour opening_hours avec les mêmes restrictions
> signalées si on référence l'url (voir ci-dessous).
> Une personne qui utilise son nom comme nom de société perd le côté privé
> de son nom.
> Si la « Pharmacie Gouiffès » a pour enseigne « Pharmacie Gouiffès », il ne
> s'agit plus vraiment d'une information nominative au sens usuel du terme et
> name=Pharmacie Gouiffès est correct.
> Ici
> 
> je vois ANNIE & GERMAINE GOUIFFES comme nom de société donc pas de soucis.
>
> Jean-Yvon
>
> Le 26/07/2017 à 21:37, Philippe Verdy - verd...@wanadoo.fr a écrit :
>
> L'autre solution c'est de mettre en valeur une URI vers un document
> externe contenant la chaîne complète. Mais on sort de la base de données
> pour aller n'importe où sur des données potentiellement non libres et
> jamais sous contrôle direct de la communauté OSM qui ne saura jamais quand
> cette ressource externe est modifiée sans aller la chercher explicitement
> (avec le risque que quelqu'un aille y mettre des gigaoctets de données
> aléatoires et planter un utilisateur de la base) ni qui l'a fait, et aussi
> le risque de fermer l'accès aux modications (raison pour laquelle on admet
> wikipedia= ou wikidata=Q et non pas des URLs libres en
> valeur (qui ne sont admises que pour website sur un objet précis
> directement associable à un domaine).
>
> Le 28/07/2017 à 03:39, Philippe Verdy - verd...@wanadoo.fr a écrit :
>
> Une URL accessible, publiée et indexée volontairement par les sites en
> question sur tous les moteurs de recherche (sans restriction du type
> robots.txt) est une donnée publique non soumise au copyright, le copyright
> s'applique seulement aux contenus diffusés via cette URL et sinon il y a
> des clauses d'usage raisonnable protégeant les sites des abus ou les
> protégeant des attaques massives de déni de service. C'est d'autant plus
> vrai si l'URL est limitée au nom de domaine publié et ne contient pas
> d'autres données: en principe une URL simple sans paramètres (juste le
> chemin) est libre sauf spécification contraire par le site en question
> indiquant que les noms dans les chemins sont aussi protégés.
> Je n'ai jamais vu nulle part le moindre problème judiciaire relatif à la
> publication d'une URL vers un contenu diffusé légalement par le site en
> question: si problème il y a c'est chez le titulaire du site, mais on n'est
> pas là pour enquêter et vérifier ses propres droits de diffusion, on pourra
> juste retiter des sites a posteriori en voyant que cela ne concerne pas la
> donnée OSM elle-même ou si on constate que ce site est malveillant lors de
> son accès.
>
> Le 28 juillet 2017 à 01:14, Muselaar  a écrit :
>
>>
>> Le 10/01/2017 à 22:29, Vincent de Château-Thierry a écrit :
>>
>>> Bonsoir,
>>>
>>> […]
>>> Parmi les informations que vous allez recueillir, celles qui ont leur
>>> place dans OSM sont celles qui à la fois :
>>> […]
>>> - ne contiennent pas d'informations nominatives (nom du gérant, etc)
>>>
>> Bonsoir,
>>
>> En recherchant des informations à d'autres propos, je tombe sur ce
>> passage qui m'interpelle, puisque je viens justement d'indiquer des noms
>> sur des POI, sous la clé « operator ». Y a-t-il quelque part sur le wiki
>> des précisions sur la règle à suivre à ce sujet ? Je n'ai pas trouvé.
>> La question ne me semble pas simple : si l'on indique un professionnel
>> qui n'a pas d'autre élément d'identification que ses nom et prénom, faut-il
>> quand même les omettre, et indiquer uniquement la profession ? Autre cas,
>> si l'enseigne indique « Pharmacie Gouiffès », du nom de son propriétaire,
>> faut-il aussi l'omettre ? Si le professionnel dispose d'une enseigne, mais
>> distribue des petites cartes avec ses nom et prénom en gros, l'enseigne
>> n'apparaissant qu'

[OSM-talk-fr] Ancien chemin plus utilisable : suppression ou tag ?

2017-08-01 Par sujet pepilepi...@ovh.fr 

  
  
Bonjour,
Hier comme à mon habitude je me suis préparé une petite promenade
  dans la lande bretonne en m'appuyant sur OSM, et en arrivant sur ce chemin
  je me suis rendu compte qu'il était noyé dans les herbes hautes.
  On arrive à deviner çà et là quelques traces de passages, mais ce
  n'est plus vraiment un chemin.
Quant à celui-ci
  j'ai dû revenir sur mes pas en observant attentivement les bords
  du chemin pour finalement découvrir un vestige de sentier envahi
  par les broussailles.
Ces chemins qui n'existent plus vraiment, que faut-il en faire ?
  Les supprimer purement et simplement ? Leur mettre un tag comme
  les railway=abandoned ? Je sais pour l'avoir lu plusieurs fois ici
  qu'on ne taggue pas pour le rendu, mais une carte qui indique des
  chemins inexistants c'est quand même pas terrible...
Merci,
Jean-Pierre


  


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Ancien chemin plus utilisable : suppression ou tag ?

2017-08-01 Par sujet Jo 
Alerter les services municipales? :-)

2017-08-01 17:28 GMT+02:00 pepilepi...@ovh.fr :

> Bonjour,
>
> Hier comme à mon habitude je me suis préparé une petite promenade dans la
> lande bretonne en m'appuyant sur OSM, et en arrivant sur ce chemin
>  je me suis rendu compte
> qu'il était noyé dans les herbes hautes. On arrive à deviner çà et là
> quelques traces de passages, mais ce n'est plus vraiment un chemin.
>
> Quant à celui-ci
> 
> j'ai dû revenir sur mes pas en observant attentivement les bords du chemin
> pour finalement découvrir un vestige de sentier envahi par les broussailles.
>
> Ces chemins qui n'existent plus vraiment, que faut-il en faire ? Les
> supprimer purement et simplement ? Leur mettre un tag comme les
> railway=abandoned ? Je sais pour l'avoir lu plusieurs fois ici qu'on ne
> taggue pas pour le rendu, mais une carte qui indique des chemins
> inexistants c'est quand même pas terrible...
>
> Merci,
>
> Jean-Pierre
>
>
> ___
> 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] Ancien chemin plus utilisable : suppression ou tag ?

2017-08-01 Par sujet Philippe Verdy 
Les municiplaités n'entretiennent plus la plupart des chemins, elles ont
seulement laissé des servitudes de passage avec pour elle la loi qui
demande aux riverains de les entretenir. Mais il n'y a plus personne à
surveiller cette obligation. Pendant des décennies on a laissé faire et des
tas de chemins publics sont devenus de facto privés, encombrés
volontairement avant de disparaitre faute d'usage, jusqu'à ce qu'un
propriétaire décide de tout aplanir au milieu, installe des clotures et
fasse des plantations que personne n'osera déranger. Il faut dire aussi que
jusqu'à présent on avait peu facilement accès aux ressources
cartographiques, même si thérioquement le cadastre mentionnait ces
servitudes.
Les choses commencent à bouger dans le bon sens mais surtout sur le domaine
maritime public. Dans nos campagnes on laisse faire et on ne compte plus le
nombre de chemins encombrés par d'énormes tas de fumier, de rocailles et de
déchets sauvages, et où le désherbage est aussi volontairement abandonné.
alors commence à s'installer une petite faune et plus personne ne vient
contester ces lieux encombrés. Le chémin se ferme définitivement et ce qui
se passe derrière ensuite est un libre usage par le riverain qui s'installe
pour longtemps (et au bout de quelques décennies, la loi lui donne raison,
les communes ne peuvent plus rien faire pour s'y opposer; c'est quand c'est
entériné comme une nouvelle propriété qu'on voit alors ce qui encombrait
les accès être nettoyé et finalement officiellement clos "proprement").
Que peut-on faire: justement signaler. Les communes ne surveillent rien du
tout et n'ont plus la capacité de le faire. Les cantonniers d'en-temps ont
disparu partout, les "services techniques" municipaux s'occupent juste de
la propreté des rues et des espaces verts des lieux les plus en vue, et
d'entretenir les arbres qui encombrent les fenêtres des riverains ou
peuvent gêner la circulation ou le stationnement, mais plus souvent
seulement de l'état des chaussées (avec de plus en plus de mal car ça coûte
cher), et de nos égouts et du recyclage de nos déchets ménagers. Les
déchets industriels ne sont, eux, plus surveillés du tout (contrôle
uniquement déclaratif à postériori).

OSM peut être un moyen de signaler, pour peu que les municipalités écoutent
ce qui est constaté. Dans certaines villes dans le monde, des plateformes
communautaires sont mises en place pour signaler ce qui n'est pas en état
afin de planifier les interventions ou de mettre en demeure les riverains à
leurs obligations. La cartographie participative peut être même plus
efficace qu'un simple fil Twitter dont le suivi n'est pas assuré et ne
permet de rien planifier du tout, et qui peut mener à des actions de
"clientélisme" à visée électorale favorisant certains secteurs sans le
dire. Une carte parle mieux qu'une liste, elle donne une vue homogène d'un
territoire et de ses occupants, elle facilite l'argumentation et les prises
de décision plus objectives.

Le 1 août 2017 à 18:24, Jo  a écrit :

> Alerter les services municipales? :-)
>
> 2017-08-01 17:28 GMT+02:00 pepilepi...@ovh.fr :
>
>> Bonjour,
>>
>> Hier comme à mon habitude je me suis préparé une petite promenade dans la
>> lande bretonne en m'appuyant sur OSM, et en arrivant sur ce chemin
>>  je me suis rendu compte
>> qu'il était noyé dans les herbes hautes. On arrive à deviner çà et là
>> quelques traces de passages, mais ce n'est plus vraiment un chemin.
>>
>> Quant à celui-ci
>> 
>> j'ai dû revenir sur mes pas en observant attentivement les bords du chemin
>> pour finalement découvrir un vestige de sentier envahi par les broussailles.
>>
>> Ces chemins qui n'existent plus vraiment, que faut-il en faire ? Les
>> supprimer purement et simplement ? Leur mettre un tag comme les
>> railway=abandoned ? Je sais pour l'avoir lu plusieurs fois ici qu'on ne
>> taggue pas pour le rendu, mais une carte qui indique des chemins
>> inexistants c'est quand même pas terrible...
>>
>> Merci,
>>
>> Jean-Pierre
>>
>>
>> ___
>> 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

Re: [OSM-talk-fr] Ancien chemin plus utilisable : suppression ou tag ?

2017-08-01 Par sujet marc marc 
Je la passerais en tracktype grade5 qui correspond à ce que tu décris : le 
chemin existe en mode théorique et devinette sur le terrain

Le 1 août 2017 à 17:29, "pepilepi...@ovh.fr" 
mailto:pepilepi...@ovh.fr>> a écrit :


Bonjour,

Hier comme à mon habitude je me suis préparé une petite promenade dans la lande 
bretonne en m'appuyant sur OSM, et en arrivant sur ce 
chemin je me suis rendu compte 
qu'il était noyé dans les herbes hautes. On arrive à deviner çà et là quelques 
traces de passages, mais ce n'est plus vraiment un chemin.

Quant à 
celui-ci 
j'ai dû revenir sur mes pas en observant attentivement les bords du chemin pour 
finalement découvrir un vestige de sentier envahi par les broussailles.

Ces chemins qui n'existent plus vraiment, que faut-il en faire ? Les supprimer 
purement et simplement ? Leur mettre un tag comme les railway=abandoned ? Je 
sais pour l'avoir lu plusieurs fois ici qu'on ne taggue pas pour le rendu, mais 
une carte qui indique des chemins inexistants c'est quand même pas terrible...

Merci,

Jean-Pierre

___
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] bus : lignes de transport en commun Haute-Garonne : réseau

2017-08-01 Par sujet Noémie Lehuby 

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 
To: OSM liste 
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-des-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

Re: [OSM-talk-fr] Ancien chemin plus utilisable : suppression ou tag ?

2017-08-01 Par sujet Jean-Claude Repetto 

Le 01/08/2017 à 21:38, marc marc a écrit :
Je la passerais en tracktype grade5 qui correspond à ce que tu décris : 
le chemin existe en mode théorique et devinette sur le terrain




Non, ce serait plutôt le tag trail_visibility qu'il faudrait utiliser.
Par exemple:
trail_visibility=horrible

Jean-Claude

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] bus : lignes de transport en commun Haute-Garonne : réseau

2017-08-01 Par sujet Philippe Verdy 
"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.)


Le 1 août 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)
>
>
> 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 
>> To: OSM liste 
>> 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

Re: [OSM-talk-fr] bus : lignes de transport en commun Haute-Garonne : réseau

2017-08-01 Par sujet Jérôme Amagat 
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, 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  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 
>>> To: OSM liste 
>>> 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

Re: [OSM-talk-fr] bus : lignes de transport en commun Haute-Garonne : réseau

2017-08-01 Par sujet Philippe Verdy 
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).


Le 2 août 2017 à 01:16, Jérôme Amagat  a écrit :

>
>
> 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, 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  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 
 To: OSM liste 
 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:

Re: [OSM-talk-fr] bus : lignes de transport en commun Haute-Garonne : réseau

2017-08-01 Par sujet Jérôme Amagat 
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 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  a écrit :
>
>>
>>
>> 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, 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’ét

Re: [OSM-talk-fr] bus : lignes de transport en commun Haute-Garonne : réseau

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

2017-08-02 1:16 GMT+02:00 Jérôme Amagat :

>
>
> 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, 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  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 
 To: OSM liste 
 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

Re: [OSM-talk-fr] bus : lignes de transport en commun Haute-Garonne : réseau

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

Le 2 août 2017 à 01:48, Jérôme Amagat  a écrit :

>
>
> 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 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 unique

Re: [OSM-talk-fr] bus : lignes de transport en commun Haute-Garonne : réseau

2017-08-01 Par sujet Jérôme Amagat 
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
> 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,
brandet d'autres.
 il faut créé des relation type=operator .?


> Le 2 août 2017 à 01:48, Jérôme Amagat  a écrit :
>
>>
>>
>> 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 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é

Re: [OSM-talk-fr] bus : lignes de transport en commun Haute-Garonne : réseau

2017-08-01 Par sujet Jo 
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 :

>
>
> 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
>> 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,
> brandet d'autres.
>  il faut créé des relation type=operator .?
>
>
>> Le 2 août 2017 à 01:48, Jérôme Amagat  a écrit :
>>
>>>
>>>
>>> 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 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
>>