Re: [OSM-talk-fr] Problème pour taguer un poste de gaz

2017-08-02 Par sujet François Lacombe 
Hello,

pipeline=substation est bien la bonne piste, normalisée il y a 1 ou 2 ans
pour suivre ce qui avait été fait pour les réseaux électriques.
https://wiki.openstreetmap.org/wiki/Tag:pipeline%3Dsubstation

Par contre il ne faut pas mettre man_made=pipeline dessus.

Il y a une clé substation=* à mettre pour donner la fonction du poste.
Je serai prenneur de la photo de la plaque indicative jaune sur la grille
pour aider à en déterminer la valeur.
=> Logique à indiquer sur une traduction française de la page


Bonne soirée

François
___
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-02 Par sujet Adrien Grellier 
Bonjour,

Dans ma région natale, les agriculteurs font comme ceci pour
s'approprier des chemins communaux :

– tu bloques le passage, par un tas de cailloux, ou tu laboures
carrément le chemin.
– Comme les gens du conseil municipal font tous de même, le cantonnier
ne remet pas le chemin en état
– le temps passe, et au bout de 30 ans le chemin est à toi.

Certains vont même recréer un chemin 10m plus loin, qui lui sera privé !

Pour ceux qui s'oppose à ce genre de pratique, il faut prouver que le
chemin existe depuis moins de 30 ans. À ce titre, OpenStreetMap est très
intéressant, puisqu'on peut avoir une trace datée de la contribution, et
le tracé est utilisable sur le terrain directement, par exemple sur OSMand.

À noter aussi : si la commune n'entretient pas le chemin, rien n'empêche
légalement un particulier de l'entretenir… C'est ainsi que des chemins
réapparaissent, au gré des gens motivés ou d'associations. Tant que les
arbres n'ont pas trop poussés, il est relativement aisé se
débroussailler un chemin.

Bonne soirée

Adrien


On 02/08/2017 21:04, pepilepi...@ovh.fr wrote:
> Le 02/08/2017 à 15:52, marc marc a écrit :
>> Cela dépend le but.
>> Si le but est de faire disparaître le chemin du rendu tout en pouvant le 
>> ressusciter, par édition c'est le mieux.
>> Mon avis est différent, si ce chemin à une existence légale, ll devrait 
>> rester sur le rendu quitte à mette grade5 visibilité horrible (j'ignorais ce 
>> tag et son utilisation) et un accès=no avec description=chemin impraticable 
>> par manque d'entretient.
>> À mes yeux cela a l'avantage de le garder sur le rendu donc plus facile à 
>> ressusciter en pratique (je parle de l'utilisateur qui voyant un chemin peux 
>> agir sans devoir faire une requête pour retrouver le chemin)
> L'un des principes que j'ai retenus d'OSM est "tu cartographies ce que
> tu vois". Donc même si un bureaucrate a décidé qu'il y avait un chemin
> (ce que tu appelles existence légale), si sur le terrain je vois un
> roncier il n'y a pas de chemin. Et ce serait induire les gens en erreur
> que de le faire apparaître sur une carte.
>
> Je vais donc prendre la solution JB.
>
> Merci,
>
> JP
>
>>> Le 2 août 2017 à 12:38, althio  a écrit :
>>>
>>> JB
 J'opte pour le "disused:highway=*". Si le chemin est rouvert un jour, il 
 n'y
 a qu'un tag à changer. Sur les rendus classiques, il n'est pas présent.
 Et quand j'essaye d'y passer, j'ai souvent un sécateur. Au bout de quelques
 fois, il repasse en highway=path…
>>> +1
>>>
>>> cela reflète la réalité du terrain,
>>> c'est toujours dans la base pour qui veut chercher ce type d'éléments
>>> (entretien, veille des riverains, promeneurs et associations),
>>> en cas d'entretien plus régulier, le chemin peut être facilement mis à jour.
>>>
>>> ___
>>> 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




signature.asc
Description: OpenPGP digital signature
___
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-02 Par sujet Christian Rogel 
Il me semble que nous avons déjà discuté des chemins ruraux communaux.
Il me semble aussi que l’appropriation des chemins au bout de 30 ans relève de 
la légende… rurale.
Seulement, c’est la théorie.
En pratique, beaucoup de communes ferment les yeux et entérinent en douce sur 
le cadastre, ne serait-ce que pour faire des économies.
Il a été mentionné (ici ?) que quelques rares communes veulent revenir en 
arrière et invoquer la loi sur l’inaliénabilité (qui date de la Restauration) 
pour récupérer des chemins qui les intéressent pour les randonnées.
Evidemment, c’est très marginal.


Christian R.
___
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-02 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

Re: [OSM-talk-fr] source sur l'objet <> sur le changeset

2017-08-02 Par sujet Nicolas Dumoulin 



Le 27/07/2017 à 20:37, Noémie Lehuby a écrit :
Mais quelque soit l'endroit où on met l'info, le problème c'est 
l'invalidation :
Que vaut un tag source = Bing 2010, quand la position et la quasi 
totalité des infos de l'objet ont changé depuis que le tag a été ajouté ?
Ça donne des éléments d'historique mais en effet plus rien sur les 
donnés non présentes sur cette source obsolète. Le temps fait son affaire.


--
Nicolas Dumoulin


___
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-02 Par sujet Philippe Verdy 
Le 2 août 2017 à 22:09, Adrien Grellier  a écrit :

> À noter aussi : si la commune n'entretient pas le chemin, rien n'empêche
> légalement un particulier de l'entretenir…
>

Pas évident: pour faire l'entretien il faut aussi des autorisations: on ne
peut pas apporter des cailloux, goudronner, creuser des fossés; ce qui est
évacué doit respecter des règles concernant les déchets (même végétaux), on
ne peut pas faire des brûlis comme on veut. On ne peut pas couper des
arbres comme on veut, ou déloger certaines faunes protégées, ou employer
des désherbants chimiques. Le bruit aussi des travaux et la poussière peut
pousser un riverain à porter plainte pour trouble du voisinage (sur son
terrain privé).

Ok pour les outils à main, mais même une simple tondeuse, une tronçonneuse,
ou la remise en place d'un cours d'eau ou le comblement de certains fossés
peuvent poser des problèmes. Dans certains cas l'encombrement peut venir
d'un arbre planté sur le terrain privé: on ne peut pas intervenir pour
l'élaguer sans que le propriétaire n'ait été en obligation de le faire et
ne l'a pas fait et se voit contraint d'accepter que la collectivité s'en
charge en désignant un prestataire ou en autorisant une asso ou d'autres
riverains à le faire.

On ne peut pas non plus ouvrir des clôtures librement (même si sa pose
était illégale et empiétait le domaine public) si cela permet à des animaux
de sortir et venir sur le domaine public voir aller chez les autres
riverains piétiner ou brouter les plantations ou venir encombrer la route
où elles pourraient causer des accidents.

D'une façon générale avant de faire quelque chose sur le domaine public il
vaut mieux obtenir l'autorisation avec un permis en bonne et due forme (qui
sera publié sur l'affichage communal), sinon un riverain ne trouvera pas
normal qu'on laisse faire n'importe qui mais pas le riverain lui-même, et
ça peut dégénérer...  Le jour prévu où le particulier interviendra, la
commune pourra faire contrôler ce qui est fait, et veillera à la sécurité
des intervenants et à régler les problèmes de troubles causés au voisinage
(un arrêté municipal autorisant ces travaux donne ce droit d'intervenir, et
donne à la commune un moyen de contrôle, les personnes autorisées étant
responsables sur ce à quoi elles se sont engagées tant auprès de la commune
que des riverains, et qu'elles ne doivent pas aller au delà).
___
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-02 Par sujet pepilepi...@ovh.fr 
Le 02/08/2017 à 11:23, JB a écrit :
> J'opte pour le "disused:highway=*". Si le chemin est rouvert un jour,
> il n'y a qu'un tag à changer. Sur les rendus classiques, il n'est pas
> présent.
> Et quand j'essaye d'y passer, j'ai souvent un sécateur. Au bout de
> quelques fois, il repasse en highway=path…
> JB.

Ça, ça me va bien, merci !

JP

>
> Le 02/08/2017 à 10:46, pepilepi...@ovh.fr a écrit :
>> Le 01/08/2017 à 22:18, Jean-Claude Repetto a écrit :
>>> 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
>> Non, c'est bien pire que ça ! Le deuxième on ne PEUT PAS y passer, sauf
>> à se promener avec une machette ou une débroussailleuse.
>>
>> JP
>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr



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

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

2017-08-02 Par sujet pepilepi...@ovh.fr 
Le 02/08/2017 à 15:52, marc marc a écrit :
> Cela dépend le but.
> Si le but est de faire disparaître le chemin du rendu tout en pouvant le 
> ressusciter, par édition c'est le mieux.
> Mon avis est différent, si ce chemin à une existence légale, ll devrait 
> rester sur le rendu quitte à mette grade5 visibilité horrible (j'ignorais ce 
> tag et son utilisation) et un accès=no avec description=chemin impraticable 
> par manque d'entretient.
> À mes yeux cela a l'avantage de le garder sur le rendu donc plus facile à 
> ressusciter en pratique (je parle de l'utilisateur qui voyant un chemin peux 
> agir sans devoir faire une requête pour retrouver le chemin)

L'un des principes que j'ai retenus d'OSM est "tu cartographies ce que
tu vois". Donc même si un bureaucrate a décidé qu'il y avait un chemin
(ce que tu appelles existence légale), si sur le terrain je vois un
roncier il n'y a pas de chemin. Et ce serait induire les gens en erreur
que de le faire apparaître sur une carte.

Je vais donc prendre la solution JB.

Merci,

JP

>
>> Le 2 août 2017 à 12:38, althio  a écrit :
>>
>> JB
>>> J'opte pour le "disused:highway=*". Si le chemin est rouvert un jour, il n'y
>>> a qu'un tag à changer. Sur les rendus classiques, il n'est pas présent.
>>> Et quand j'essaye d'y passer, j'ai souvent un sécateur. Au bout de quelques
>>> fois, il repasse en highway=path…
>> +1
>>
>> cela reflète la réalité du terrain,
>> c'est toujours dans la base pour qui veut chercher ce type d'éléments
>> (entretien, veille des riverains, promeneurs et associations),
>> en cas d'entretien plus régulier, le chemin peut être facilement mis à jour.
>>
>> ___
>> 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-02 Par sujet lenny 
J'avoue ne pas avoir compris la discussion, trop complexe pour moi, je 
n'ai donc pas d'avis sur la question ; ce qui me gênait c'était d'avoir 
des valeurs différentes. Il y a pour les réseaux [1] et [2] des 
relations de type=network


https://www.openstreetmap.org/relation/1518272
Attributs
description Réseau des transports en commun de l'agglomération 
toulousaine

name Tisséo
network fr_tisseo
operator Tisséo
phone +33 5 61 41 70 70
type network
url http://www.tisseo.fr/sites/default/files/plan_detaille_reseau.pdf
website http://www.tisseo.fr
wikipedia fr:Tisséo

https://www.openstreetmap.org/relation/1546978
Attributs
name Arc-en-ciel
network fr_arc_en_ciel
operator Conseil Départemental de la Haute-Garonne
type network
website http://www.haute-garonne.fr/bus.asp
wikipedia fr:Réseau Arc-en-ciel de la Haute-Garonne

n'est-ce pas là qu'il faudrait ajouter le wikidata ? comment 
l'utilise-t-on : wikidata=Q3456528 ?


faut-il créer un network particulier pour les transports scolaires ? Y 
a-t-il d'autres lignes de transports scolaires ? je n'ai pas trouvé avec 
bus=yes


Leni

Le 02/08/2017 à 11:35, Philippe Verdy a écrit :

Et tu ajoutes tout un tas de tags redondants en plus, dont la maintenance
sera encore plus "bordélique". Plus on met de redondance et plus on voit la
qualité se dégrader rapidement (et les "trous" apparaissent très vite): il
n'y a plus de suivi, cela devient vite disparâtre. Bref cela crée en plus
de la complexité à gérer ça au lieu de centraliser les infos à un endroit.


Le 2 août 2017 à 08:18, Jo  a écrit :


Pour les réseaux de cyclisme et de randonné/équestres il me semble très
raisonnable d'avoir les relations route et les relations network pour
indiquer lesquels forment des groupes. J'ai créé des scripts dans le passé
pour valider ces réseaux de noeuds numérotés.

Pour le transport en commun, il me semble que ce genre de relations
deviendra très grandes et trop compliquées à gérer/maintenir.

Je pense que les tags operator / network, ensemble avec operator:wikidata
/ network:wikidata / brand:wikidata sont plus adéquats pour cela.

Polyglot

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



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

[OSM-talk-fr] Problème pour taguer un poste de gaz

2017-08-02 Par sujet Alain VASSAULT 
Hello,
Après moult fouille du wiki j'ai tag un poste de gaz qui consiste à une zone 
clôturée où les pipeline sorte de terre avec des vannes de condamnation.
Je l'ai renseigné ainsi:
name : Courtois-sur-Yonne PDT
operator : GRTGaz
pipeline : substation
pipeline:ref : 5734
substance : gas
substation : distribution

Je peut avoir fait une bêtise mais sur Vespucci (éditeur Android) je n'ai pas 
d'apparence spécifique.

Tranquille

Le 2 août 2017 16:33:57 GMT+02:00, Lionel Allorge 
 a écrit :
>Bonjour,
>
>Je cherche comment définir au mieux ce poste de gaz :
>https://www.openstreetmap.org/way/508479132#map=19/46.77234/0.54257
>J'ai essayé man_made=pipeline mais du coup l'objet devient une ligne au
>lieu d'être une surface...
>Si quelqu'un a une idée sur comment définir cet objet je suis preneur.
>
>Librement.
>
>-- 
>Lionel Allorge
>April : http://www.april.org
>Lune Rouge : http://www.lunerouge.org
>Wikimedia France : http://wikimedia.fr
>OpenStreetMap France : http://www.openstreetmap.fr/
>
>« Le fait le plus terrifiant à propos de l'univers n'est pas
> qu'il est hostile, mais qu'il est indifférent »
>Stanley Kubrick
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.___
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-02 Par sujet lenny 



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 les transports sur Toulouse Métropole y compris les 
transports scolaires sur la Métropole.


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/fr/vie-pratique/transports.html et la 
première ligne 
http://www.mairie-ondes31.fr/_resources/Transport%2520scolaire/S7105%2520RPI%2520-%2520ONDES-GRENADE%2520-%2520ST%2520CAPRAIS.pdf?download=true 
où l'on peut voir qu'il n'y a aucun lien, ni avec Tisséo, ni avec le 
Réseau Arc-en-Ciel
Les arrêts sont parfois communs (par exemple un arrêt couvert de CD31 à 
côté d'un poteau Tisséo) et quand ils ne sont pas communs, il y a 3 
signalétiques différentes.
Dans l'opendataHG on a bien des data pour le réseau Arc-en-ciel et 
d'autres pour les arrêts/lignes des transports scolaires 
https://data.haute-garonne.fr/explore/?sort=modified=transport


Leni



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





___
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-02 Par sujet Philippe Verdy 
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
communes peuvent faire exception et organiser leur propre transport public
avec les opérateurs qu'elles souhaitent. On peut donc se retrouver avec les
morceaux de lignes cogérés, des arrêts partagés. Les usagers peuent avoir à
acquitter plusieurs billets de transports, ou des compléments selon leurs
abonnement.

Qui va gérer les équipements (zones d'arrêts, signalisation, abris)? En
général ce sera la commune ou la collectivité qui a en charge la voie de
transport, et il n'y a pas de garantie que la comune ou l'EPCI participe;
un exploitant peut aussi financer une partie de l'équipement, ou dans
certains cas les résidents riverains eux-mêmes ou une asso qui les
représente (avec l'accord de la collectivité s'il faut un permis de
construire) quand l'équipement se situe sur un terrain privé comme une zone
commerciale ou un secteur résidentiel privé ; la ligne n'est pas
entièrement d'intérêt public mais peut être paritaire. On parle alors
difficilement de réseau, même si la ligne peut participer à plusieurs
réseaux et y être mentionnée sans y être totalement intégrée (avec une
tarification spéciale et des restrictions sur la validité des abonnements).
La ligne aura un nom ou juste un parcours indicatif. La ligne peut même
être totalement privée mais accessible au public selon les conditions
fixées par le transporteur et l'octroi de subventions facultative pour
fixer un tarif à certaines catégories usagers munis d'abonnements et que la
commune veut bien aider à financer.

La commune peut le faire sans passer de contrat exclusif avec un
transporteur exploitant et renouveler les contrats au coup par coup ou en
faisant appel à la concurrence des transporteurs. En zone très rurale en
effet les besoins de transport sont très aléatoires et changent souvent
radicalement d'une année sur l'autre à cause du petit nombre d'usagers et
de leur fréquentation très irrégulière. aussi de nombreuses lignes rurales
ont des trajets indicatifs avec des parcours optionnels et des arrêts
possibles uniquement à la demande (sur réservation).

Le 2 août 2017 à 20:39, lenny  a écrit :

>
>
> 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 les transports sur Toulouse Métropole y compris les transports
> scolaires sur la Métropole.
>
> 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
> r/vie-pratique/transports.html et la première ligne
> http://www.mairie-ondes31.fr/_resources/Transport%2520scolai
> re/S7105%2520RPI%2520-%2520ONDES-GRENADE%2520-%2520ST
> %2520CAPRAIS.pdf?download=true où l'on peut voir qu'il n'y a aucun lien,
> ni avec Tisséo, ni avec le Réseau Arc-en-Ciel
> Les arrêts sont parfois communs (par exemple un arrêt couvert de CD31 à
> côté d'un poteau Tisséo) et quand ils ne sont pas communs, il y a 3
> signalétiques différentes.
> Dans l'opendataHG on a bien des data pour le réseau Arc-en-ciel et
> d'autres pour les arrêts/lignes des transports scolaires
> https://data.haute-garonne.fr/explore/?sort=modified=transport
>
> Leni
>
>
>>
>> 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"'
>>>
>>>

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

2017-08-02 Par sujet Philippe Verdy 
Et tu ajoutes tout un tas de tags redondants en plus, dont la maintenance
sera encore plus "bordélique". Plus on met de redondance et plus on voit la
qualité se dégrader rapidement (et les "trous" apparaissent très vite): il
n'y a plus de suivi, cela devient vite disparâtre. Bref cela crée en plus
de la complexité à gérer ça au lieu de centraliser les infos à un endroit.


Le 2 août 2017 à 08:18, Jo  a écrit :

> Pour les réseaux de cyclisme et de randonné/équestres il me semble très
> raisonnable d'avoir les relations route et les relations network pour
> indiquer lesquels forment des groupes. J'ai créé des scripts dans le passé
> pour valider ces réseaux de noeuds numérotés.
>
> Pour le transport en commun, il me semble que ce genre de relations
> deviendra très grandes et trop compliquées à gérer/maintenir.
>
> Je pense que les tags operator / network, ensemble avec operator:wikidata
> / network:wikidata / brand:wikidata sont plus adéquats pour cela.
>
> Polyglot
>
> 2017-08-02 3:16 GMT+02:00 Jérôme Amagat :
>
>>
>>
>> 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

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

2017-08-02 Par sujet pepilepi...@ovh.fr 
Le 01/08/2017 à 22:18, Jean-Claude Repetto a écrit :
> 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

Non, c'est bien pire que ça ! Le deuxième on ne PEUT PAS y passer, sauf
à se promener avec une machette ou une débroussailleuse.

JP

>
> ___
> 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-02 Par sujet Philippe Verdy 
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 sont connus exhaustivement, et finis. Je ne vois pas où est
la compelxité à gérer ça, la complexité est surtout sur les relations
route! Le reste est vraiment trivial et fort pratique.

Le 2 août 2017 à 08:18, Jo  a écrit :

> Pour les réseaux de cyclisme et de randonné/équestres il me semble très
> raisonnable d'avoir les relations route et les relations network pour
> indiquer lesquels forment des groupes. J'ai créé des scripts dans le passé
> pour valider ces réseaux de noeuds numérotés.
>
> Pour le transport en commun, il me semble que ce genre de relations
> deviendra très grandes et trop compliquées à gérer/maintenir.
>
> Je pense que les tags operator / network, ensemble avec operator:wikidata
> / network:wikidata / brand:wikidata sont plus adéquats pour cela.
>
> Polyglot
>
> 2017-08-02 3:16 GMT+02:00 Jérôme Amagat :
>
>>
>>
>> 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

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

2017-08-02 Par sujet Philippe Verdy 
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 maintenance
> sera encore plus "bordélique". Plus on met de redondance et plus on voit la
> qualité se dégrader rapidement (et les "trous" apparaissent très vite): il
> n'y a plus de suivi, cela devient vite disparâtre. Bref cela crée en plus
> de la complexité à gérer ça au lieu de centraliser les infos à un endroit.
>
>
> Le 2 août 2017 à 08:18, Jo  a écrit :
>
>> Pour les réseaux de cyclisme et de randonné/équestres il me semble très
>> raisonnable d'avoir les relations route et les relations network pour
>> indiquer lesquels forment des groupes. J'ai créé des scripts dans le passé
>> pour valider ces réseaux de noeuds numérotés.
>>
>> Pour le transport en commun, il me semble que ce genre de relations
>> deviendra très grandes et trop compliquées à gérer/maintenir.
>>
>> Je pense que les tags operator / network, ensemble avec operator:wikidata
>> / network:wikidata / brand:wikidata sont plus adéquats pour cela.
>>
>> Polyglot
>>
>> 2017-08-02 3:16 GMT+02:00 Jérôme Amagat :
>>
>>>
>>>
>>> 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

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

2017-08-02 Par sujet althio 
JB
> J'opte pour le "disused:highway=*". Si le chemin est rouvert un jour, il n'y
> a qu'un tag à changer. Sur les rendus classiques, il n'est pas présent.
> Et quand j'essaye d'y passer, j'ai souvent un sécateur. Au bout de quelques
> fois, il repasse en highway=path…

+1

cela reflète la réalité du terrain,
c'est toujours dans la base pour qui veut chercher ce type d'éléments
(entretien, veille des riverains, promeneurs et associations),
en cas d'entretien plus régulier, le chemin peut être facilement mis à jour.

___
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-02 Par sujet JB 
J'opte pour le "disused:highway=*". Si le chemin est rouvert un jour, il 
n'y a qu'un tag à changer. Sur les rendus classiques, il n'est pas présent.
Et quand j'essaye d'y passer, j'ai souvent un sécateur. Au bout de 
quelques fois, il repasse en highway=path…

JB.

Le 02/08/2017 à 10:46, pepilepi...@ovh.fr a écrit :

Le 01/08/2017 à 22:18, Jean-Claude Repetto a écrit :

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

Non, c'est bien pire que ça ! Le deuxième on ne PEUT PAS y passer, sauf
à se promener avec une machette ou une débroussailleuse.

JP


___
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-02 Par sujet Donat ROBAUX 
Le 2 août 2017 à 08:19,  a écrit :

> Envoyez vos messages pour la liste Talk-fr à
> talk-fr@openstreetmap.org
>
> Pour vous (dés)abonner par le web, consultez
> https://lists.openstreetmap.org/listinfo/talk-fr
>
> ou, par email, envoyez un message avec 'help' dans le corps ou dans le
> sujet à
> talk-fr-requ...@openstreetmap.org
>
> Vous pouvez contacter l'administrateur de la liste à l'adresse
> talk-fr-ow...@openstreetmap.org
>
> Si vous répondez, n'oubliez pas de changer l'objet du message afin
> qu'il soit plus spécifique que "Re: Contenu du digest de Talk-fr..."
>
> Thèmes du jour :
>
>1. Re: bus : lignes de transport en commun Haute-Garonne :
>   réseau (Jo)
>
>
> -- Message transféré --
> From: Jo 
> To: "Discussions sur OSM en français" 
> 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 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
>

Je pensais exactement à ca Polyglot!
Après je ne sais pas quel est le tag le plus approprié operator:wikidata /
network:wikidata / brand:wikidata
Au-delà de la question du tag approprié pour le network du réseau de
transport, les tags wikidata présente l'avantage d'être unique. On le voit
bien avec les 2 réseaux de transport Arc-en-Ciel en France qui par la clé
network ne peuvent pas être différenciés (même en rajoutant :FR dedans).
On aurait beaucoup à gagner à plus utiliser les tags wikidata et ca rejoint
la discussion sur les réseaux de magasins suite à la libération du fichier
SIRET. Certes c'est moins interprétable du 1er coup, mais ca facilite à mon
avis grandement la maintenance de grands réseaux (de transport ou de
magasin) et on a plus ce problème de multiples orthographes pour désigner
la même chose.

Donat
___
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-02 Par sujet marc marc 
Cela dépend le but.
Si le but est de faire disparaître le chemin du rendu tout en pouvant le 
ressusciter, par édition c'est le mieux.
Mon avis est différent, si ce chemin à une existence légale, ll devrait rester 
sur le rendu quitte à mette grade5 visibilité horrible (j'ignorais ce tag et 
son utilisation) et un accès=no avec description=chemin impraticable par manque 
d'entretient.
À mes yeux cela a l'avantage de le garder sur le rendu donc plus facile à 
ressusciter en pratique (je parle de l'utilisateur qui voyant un chemin peux 
agir sans devoir faire une requête pour retrouver le chemin)

> Le 2 août 2017 à 12:38, althio  a écrit :
> 
> JB
>> J'opte pour le "disused:highway=*". Si le chemin est rouvert un jour, il n'y
>> a qu'un tag à changer. Sur les rendus classiques, il n'est pas présent.
>> Et quand j'essaye d'y passer, j'ai souvent un sécateur. Au bout de quelques
>> fois, il repasse en highway=path…
> 
> +1
> 
> cela reflète la réalité du terrain,
> c'est toujours dans la base pour qui veut chercher ce type d'éléments
> (entretien, veille des riverains, promeneurs et associations),
> en cas d'entretien plus régulier, le chemin peut être facilement mis à jour.
> 
> ___
> 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] Problème pour taguer un poste de gaz

2017-08-02 Par sujet David Crochet 

Bonjour


Le 02/08/2017 à 16:33, Lionel Allorge a écrit :

Si quelqu'un a une idée sur comment définir cet objet je suis preneur.

Pour le moment je fais du « landuse=industrial » avec cela.

Cordialement

--
David Crochet


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

[OSM-talk-fr] Problème pour taguer un poste de gaz

2017-08-02 Par sujet Lionel Allorge 
Bonjour,

Je cherche comment définir au mieux ce poste de gaz :
https://www.openstreetmap.org/way/508479132#map=19/46.77234/0.54257
J'ai essayé man_made=pipeline mais du coup l'objet devient une ligne au
lieu d'être une surface...
Si quelqu'un a une idée sur comment définir cet objet je suis preneur.

Librement.

-- 
Lionel Allorge
April : http://www.april.org
Lune Rouge : http://www.lunerouge.org
Wikimedia France : http://wikimedia.fr
OpenStreetMap France : http://www.openstreetmap.fr/

« Le fait le plus terrifiant à propos de l'univers n'est pas
 qu'il est hostile, mais qu'il est indifférent »
Stanley Kubrick

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