Re: [OSM-talk-fr] ligne de bus en site propre

[Jo]

Moi aussi, en effet. J'ai regardé la plupart des autres langues et il n'y
en a qu'une qui en fait mention. Je l'aurais déjà fait, mais puis j'avais
remarqué qu'il y a une page dédiée pour ce tag. Il faudrait donc
probablement passer par la liste tagging.

Jo

2017-08-21 0:48 GMT+02:00 Jérôme Amagat :

> Sur la page : https://wiki.openstreetmap.org/wiki/Key:service
> il y a bien service=bus mais cela a été ajouté, si on regarde
> l'historique, le 17 mai 2017.
> Et la page : https://wiki.openstreetmap.org/wiki/Tag:service%3Dbus
> et un peu plus vieille novembre 2016 et donne comme raison pour la
> création de ce tag :
> "Some bus companies using OSM for routing exclude all highway
> =service
>  from their
> routers unless they are also tagged service
> =*bus*, so in order for
> these routers to work appropriately, service lanes at bus stations used by
> the mentioned companies need to be tagged with this."
> ça ne me semble pas être une bonne raison pour utiliser ce tag.
> Je pense donc que ce tag devrait disparaître du wiki.
>
>
> Le 20 août 2017 à 22:48, Axelos  a écrit :
>
>> Coucou,
>>
>> Le 20/08/2017 à 22:21, osm.sanspourr...@spamgourmet.com a écrit :
>> > Merci de montrer l'utilité de ne pas partir chacun dans son coin ;-).
>> >
>> > Ça me va, c'est ce que j'ai fait (hormis le psv, je vais vérifier ce que
>> > je dois mettre).
>> >
>> > Donc tu n'as pas de service=bus non plus ? Pourtant le wiki incite à
>> > mettre service=bus.
>>
>> De mon coté j'utilise plutôt psv=yes aussi ( exemple
>> http://osm.org/way/149797721 )
>> De mémoire le choix est simplement dû au fait que psv inclus les taxis
>> en plus des bus.
>>
>> --
>>
>> Je cherche à protéger ma vie privée numérique,
>> s’il vous plaît faites-le aussi pour moi,
>> choisissez une adresse de courriel alternative respectueuse.
>>
>> ___
>> 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] Bornes à incendie : proposition en cours d'écriture

[marc marc]

Le 21. 08. 17 à 07:57, François Lacombe a écrit :
> Pour le split, si il n'y a pas d'harmonisation entre fire_hydrant et 
> suction_point, tout peut être traité d'un seul coup non ?
il y a la dépréciation de type=pond sur laquelle j'aurais voulu éviter 
qu'on vote vu que cela conforte la séparation entre hydrant et suction.

Par contre pour ta proposition de réduire flow_capacity en capacity,
je ne suis pas favorable. capacity est trop générique.
sans lire le wiki, cela pourrait tout aussi bien représenter le nombre 
de tuyaux qu'on peux connecter simultanément.
De plus je pense qu'il est utile, pour les éditeurs, d'avoir un seul 
type d'unité par clé afin de pouvoir l'afficher lors de la saisie.
sinon les éditeurs doivent avoir une liste hard-codée des unités en 
fonction de l'objet, c'est contre-productif à l'effet souhaité d'une 
harmonisation des clefs.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Création de la liste OSM tagging-fr

[Jean-Marc Liotier]

On 2017-08-20 00:12, marc marc wrote:
> C'est en soi une très bonne idée que de fédérer la francophonie.
>
> Mais quand je vois que pour la discussion de certains tag, on n'est
> parfois pas nombreux à en discuter sur talk-fr, je me demande si diviser
> avec une ml supplémentaire n'est pas contre productif,

Vues les premières réactions, la fragmentation des canaux est un
problème auquel nous devrons prêter une attention accrue.

D'un autre côté, la fragmentation des canaux et également une réponse au
problème de la fragmentation des publics: la langue est une dimension
culturelle, mais pas la seule - l'affinité pour une technologie de
communication ou une autre est aussi une dimension culturelle.

Côté langue, je peux témoigner vu mes échanges notamment Ouest-Africains
qu'il existe un public de contributeurs tout à fait savants de
géographie mais pour qui l'anglais est un obstacle majeur - il me semble
donc que l'opportunité de discussions en Français est une offre
intéressante. Peut-être que talk-fr pourrait être ce lieu - ou peut-être
qu'il est trop connoté "France" pour la Francophonie non-Française.

Côté technique, le débat me semble moins clair mais je crois deviner un
positionnement possible: les listes de diffusions ont tendance à fédérer
des contributeurs technophiles expérimentés - la barrière de
l'inscription et de la gestion des messages n'est pas franchie
spontanément par les contributeurs moins engagés. Donc, on peut
s'attendre a avoir rapidement un petit groupe d'experts prêts à discuter
tout sujet qui émergera dans leur boite aux lettres. Mais il y a aussi
des contributeurs demandeurs de clarifications, que nous rencontrons
parfois sur les listes Francophones nationales (talk-sn, talk-ml etc.),
en messages directs dans la messagerie Openstreetmap ou dans les
changeset discussions - avoir un guichet garni d'experts responsifs vers
lequel les orienter me semble être réponse potentiellement pertinente au
besoin de traiter des problématiques émergentes sur lesquelles butent
des contributeurs locaux mais auxquelles les experts en question n'ont
pas été confronté faute d'un terrain les suscitant - reste à savoir si
le choix d'une liste de diffusion leur conviendra.

En tout cas je participerai à tagging-fr  et nous verrons bien si
quelque chose émerge.

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

Re: [OSM-talk-fr] le festival de tout les highway :-)

[marc marc]

En relisant, je trouve qu'il y a une assez grande cohérence puisque 
hormis residential, les autres valeurs dépendent des panneaux routiers.

Le 21. 08. 17 à 02:42, Jérôme Amagat a écrit :
> le panneau veux dire plusieurs choses sur son "aspect" minimum 2x2 voies 
> séparées bandes d’arrêt d'urgence... et sur les règles a respecter, pas 
> de velo, vitesse minimum, vitesse maximum plus élevé que sur les autres 
> routes...

Oui mais c'est inévitable. il n'y a aucune autoroute aménagée comme un 
living_street et inversement.
alors oui fatalement autoroute implique à la fois l'importance de la 
route (sa fonction première) et une série de valeur par défaut.
Vouloir séparer cela reviendrait à devoir mettre des milliers de tag de 
valeur par défaut juste pour avoir un tag "purement" limité à 
l'importance de la route, je ne vois pas ce qu'on gagnerait en pratique 
malgré la "pureté" du critère. Et puis surtout comment pratiquement 
évaluerais-tu ce critère d'importance de la route sans panneau ?

Le 21. 08. 17 à 02:42, Jérôme Amagat a écrit :
 > Certaine route tertiaire sont plus proche en passant dessus d'une
 > autoroute que certaine route primaire.
l'autoroute Metz-Strasbourg est par endroit dans un état plus proche de 
la route de compagne abandonnée que de l'autoroute. est-ce pour autant 
que le classement est mauvais ? je trouve qu'il y a assez de clef pour 
gérer les cas "tordu", ici en l’occurrence smoothness.
Dans ton exemple, la route tertiaire est peut-être mal classé. ou alors 
c'est simplement parce que localement il y a des routes secondaires et 
primaires plus importante. ou simplement l’age de la route.

la seule chose qui me semble mériter réflexion, c'est le fait que des 
nationales deviennent des départementales pour des raisons de 
décentralisation et que du coup des départementale peuvent être ou pas 
être en primary ou secondary, là le critère n'a pas été définit de 
manière objective.
En Suisse par comparaison, c'est uniquement le panneau routier qui fait 
la différence entre primaire, secondaire et tertiaire.

Le 21. 08. 17 à 02:42, Jérôme Amagat a écrit :
 >>> Pour trunk, on c'est pas c'est quoi le critère
 >> c'est "quasi-autoroute" mais il manque souvent qlq détails à
 >> ces routes pour être des autoroutes, souvent entrée trop courte.
 > c'est quoi qui manque exactement
si tu connaissais la raison, que vas-tu en faire niveau osm ?
exemple : je connais des tunnels en ville 2x2 en trunk. La raison est 
l'absence de bretelle d'entrée puisque le tunnel remonte parfois à la 
surface pour être en contact avec une rue classique.
Je ne vois pas ce que tu voudrais faire niveau osm avec cette info.
Par contre l'avoir en trunk est utile, le routage devrait autant que 
possible te faire utiliser le trunk et non pas les voies de classe 
inférieur même si celle-ci font gagner quelques mètres sur le trajet.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Trunk

[djakk djakk]

Complètement d'accord avec toi Jérôme.
J'ai l'impression que ça vient de la culture anglo-saxonne : on retrouvait
les mêmes travers dans le HTML. Mais cet "état d'incohérence" permet de
débuter rapidement un projet. Un Français voudrait que tout soit parfait
dès le départ du projet ce qui prend plus+ de temps.

Pour les voies ferrées, il existe une clé "importance" avec comme valeurs
régionale ou nationale. Par contre les voies de service sont cartographiée
avec une clé "service" ...


djakk

Le lun. 21 août 2017 à 01:28, Jérôme Amagat  a
écrit :

> Le 20 août 2017 à 15:22, djakk djakk  a écrit :
>
>> Cela dit, l'idéal serait de distinguer importance du réseau et type de
>> route : on pourrait avoir des "motorway primary" et des "motorway
>> secondary" (ou plutôt des "motorway trunk" et des "motorway primary"),
>> exemple avec l'A106 en région parisienne qui pourrait être qualifiée
>> d'autoroute secondaire.
>>
>
> oui pour moi c'est c'est un gros problème des tag highway=*, on mélange
> des choses différentes et donc après c'est difficiles de choisir le bon tag.
> motorway c'est un type de route on utilise ce tag en regardant son aspect
> et les règle qui s'y applique.
> primary, secondary, tertiary c'est en fonction de l'importance dans le
> réseau routier, en gros utiliser pour faire des grandes distances, des
> moyennes ou des plus courtes.
> Pour trunk, on c'est pas c'est quoi le critère, quand je lis çà : (
> https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtrunk) "highway=trunk
> for high performance roads that don't meet the requirement for motorway" je
> dirais qu'il faut choisir a la tête : si on y roule plus vite que sur
> d'autre type de route. Mais ici :
> https://wiki.openstreetmap.org/wiki/Key:highway on place trunk au dessus
> de primary et donc comme les routes les plus importantes du pays.
>
> D'ailleurs il y  a d'autres problèmes avec highway=*
> highway=residential, c'est juste une route en zone résidentiel (donc choix
> à la tête) ou c’est une route qui sert qu'aux résidents de la rue (et des
> quelques rue environnantes) (donc choix grâce à son utilisation)?
>
> highway=living_street, il faut utiliser ce tag suivant les règle qui s'y
> applique mais qu'est ce qu'on fait quand cette route est aussi un morceau
> de route du réseau tertiary, par exemple? highway=living_street;tertiary ?
>
> il y a aussi highway=path choisi à la tête et highway=footway et cycleway
> choisit en fonction des utilisateurs de la voie mais qui permet de supers
> combos footway avec bicycle=yes et cycleway avec foot=yes.
>
> ___
> 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

[marc marc]

Le 21. 08. 17 à 02:05, Jérôme Amagat a écrit :
> les relations network n'est sur le wiki qu'a l’état de proposition
Tu as raison, on s'est un peu emballé.
je change donc mon avis, chaque fois que je préconisais l'utilisation 
d'une relation network devient l'utilisation du tag network.
Par contre cela ne change pas mon avis sur la limite de où l'utiliser : 
oui sur les objets non physique du réseau de bus, au + haut au mieux.
mais inadéquoi sur le mobilier urbain, le marquage routier etc

> Si c'est pour pouvoir mettre quelque part le vrai nom
>  du réseau pourquoi ne pas le mettre directement dans le tag network=*.
ä la base,la discussion avait commencé parce que pour le réseau arc en 
ciel, le nom même du réseau est très hétéroclite et de plus 2 réseaux 
différents semblent exister en France avec ce nom.
il aurait été pratique d'avoir 2 relations pour permettre au moins de 
classer les objets dans le bon groupe même si la typo exact du nom doit 
être affinée (celui de leur site web, celui écrit sur les bus, ..)
Mais puisqu'il est mieux de faire sans relation network, le débat est 
rouvert sur comment les séparer facilement.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] le festival de tout les highway :-)

[djakk djakk]

Alors je connais des "living_street" d'importance "primary" (Rennes, place
de la République), ainsi que des "pedestrian" d'importance "primary" (la
rue Le Bastard à Rennes) :-)


djakk

Le lun. 21 août 2017 à 12:06, marc marc  a
écrit :

> En relisant, je trouve qu'il y a une assez grande cohérence puisque
> hormis residential, les autres valeurs dépendent des panneaux routiers.
>
> Le 21. 08. 17 à 02:42, Jérôme Amagat a écrit :
> > le panneau veux dire plusieurs choses sur son "aspect" minimum 2x2 voies
> > séparées bandes d’arrêt d'urgence... et sur les règles a respecter, pas
> > de velo, vitesse minimum, vitesse maximum plus élevé que sur les autres
> > routes...
>
> Oui mais c'est inévitable. il n'y a aucune autoroute aménagée comme un
> living_street et inversement.
> alors oui fatalement autoroute implique à la fois l'importance de la
> route (sa fonction première) et une série de valeur par défaut.
> Vouloir séparer cela reviendrait à devoir mettre des milliers de tag de
> valeur par défaut juste pour avoir un tag "purement" limité à
> l'importance de la route, je ne vois pas ce qu'on gagnerait en pratique
> malgré la "pureté" du critère. Et puis surtout comment pratiquement
> évaluerais-tu ce critère d'importance de la route sans panneau ?
>
> Le 21. 08. 17 à 02:42, Jérôme Amagat a écrit :
>  > Certaine route tertiaire sont plus proche en passant dessus d'une
>  > autoroute que certaine route primaire.
> l'autoroute Metz-Strasbourg est par endroit dans un état plus proche de
> la route de compagne abandonnée que de l'autoroute. est-ce pour autant
> que le classement est mauvais ? je trouve qu'il y a assez de clef pour
> gérer les cas "tordu", ici en l’occurrence smoothness.
> Dans ton exemple, la route tertiaire est peut-être mal classé. ou alors
> c'est simplement parce que localement il y a des routes secondaires et
> primaires plus importante. ou simplement l’age de la route.
>
> la seule chose qui me semble mériter réflexion, c'est le fait que des
> nationales deviennent des départementales pour des raisons de
> décentralisation et que du coup des départementale peuvent être ou pas
> être en primary ou secondary, là le critère n'a pas été définit de
> manière objective.
> En Suisse par comparaison, c'est uniquement le panneau routier qui fait
> la différence entre primaire, secondaire et tertiaire.
>
> Le 21. 08. 17 à 02:42, Jérôme Amagat a écrit :
>  >>> Pour trunk, on c'est pas c'est quoi le critère
>  >> c'est "quasi-autoroute" mais il manque souvent qlq détails à
>  >> ces routes pour être des autoroutes, souvent entrée trop courte.
>  > c'est quoi qui manque exactement
> si tu connaissais la raison, que vas-tu en faire niveau osm ?
> exemple : je connais des tunnels en ville 2x2 en trunk. La raison est
> l'absence de bretelle d'entrée puisque le tunnel remonte parfois à la
> surface pour être en contact avec une rue classique.
> Je ne vois pas ce que tu voudrais faire niveau osm avec cette info.
> Par contre l'avoir en trunk est utile, le routage devrait autant que
> possible te faire utiliser le trunk et non pas les voies de classe
> inférieur même si celle-ci font gagner quelques mètres sur le trajet.
> ___
> 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] Bornes à incendie : proposition en cours d'écriture

[François Lacombe]

Le 21 août 2017 à 10:58, marc marc  a écrit :

> il y a la dépréciation de type=pond sur laquelle j'aurais voulu éviter
> qu'on vote vu que cela conforte la séparation entre hydrant et suction.
>

Ok, en effet
Par contre si il n'est pas déprécié, il faudra quand même le passer dans
water_source plutôt que de le laisser dans le type d'hydrant


>
> Par contre pour ta proposition de réduire flow_capacity en capacity,
> je ne suis pas favorable. capacity est trop générique.
>
Sa généricité est un avantage en fait


> sans lire le wiki, cela pourrait tout aussi bien représenter le nombre
> de tuyaux qu'on peux connecter simultanément.
>
Sans lire la notice, on a généralement des problèmes
Cela dit, on a pas indiqué de clé où donner le nombre de connexions
possibles et la confusion peut en effet régner.
Là, un namespace peut etre utile et vu qu'il y a déjà des sous-clés de
capacity, que penses-tu de
capacity:flow et capacity:pipes ?


> De plus je pense qu'il est utile, pour les éditeurs, d'avoir un seul
> type d'unité par clé afin de pouvoir l'afficher lors de la saisie.
> sinon les éditeurs doivent avoir une liste hard-codée des unités en
> fonction de l'objet, c'est contre-productif à l'effet souhaité d'une
> harmonisation des clefs.
>
Problématique intéressante que je n'ai pas rencontré jusque là.
JOSM par exemple, n'affiche pas d'unité dans les presets il me semble ?

Est-ce que tu étend cela aux multiples ? Parce que pour height, même si le
défaut est en mètres, on peut préciser des valeurs en km en l'ajoutant à la
fin de la valeur.
Ainsi l'éditeur ne gère pas cette partie

capacity:flow réglera le problème de l'unité en tout cas si c'est ce qui
est retenu.


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

Re: [OSM-talk-fr] le festival de tout les highway :-)

[djakk djakk]

On aurait donc 5 clés différentes pour caractériser une route :
1) son importance (primaire, secondaire ...)
2) son classement administratif (panneau d'entrée ou de sortie d'autoroute
ou de "motorroad")
3) ses caractéristiques physiques (carrefours dénivelés, living_street,
route classique ...)
4) la largeur de ses voies (une route d'importance primaire peut être
étroite : exemple = Rennes - Angers autour de Martigné-Ferchaud)
5) la qualité de son revêtement (surtout utile dans les pays en voie de
développement)


djakk

Le lun. 21 août 2017 à 12:38, djakk djakk  a écrit :

> Alors je connais des "living_street" d'importance "primary" (Rennes, place
> de la République), ainsi que des "pedestrian" d'importance "primary" (la
> rue Le Bastard à Rennes) :-)
>
>
> djakk
>
> Le lun. 21 août 2017 à 12:06, marc marc  a
> écrit :
>
>> En relisant, je trouve qu'il y a une assez grande cohérence puisque
>> hormis residential, les autres valeurs dépendent des panneaux routiers.
>>
>> Le 21. 08. 17 à 02:42, Jérôme Amagat a écrit :
>> > le panneau veux dire plusieurs choses sur son "aspect" minimum 2x2 voies
>> > séparées bandes d’arrêt d'urgence... et sur les règles a respecter, pas
>> > de velo, vitesse minimum, vitesse maximum plus élevé que sur les autres
>> > routes...
>>
>> Oui mais c'est inévitable. il n'y a aucune autoroute aménagée comme un
>> living_street et inversement.
>> alors oui fatalement autoroute implique à la fois l'importance de la
>> route (sa fonction première) et une série de valeur par défaut.
>> Vouloir séparer cela reviendrait à devoir mettre des milliers de tag de
>> valeur par défaut juste pour avoir un tag "purement" limité à
>> l'importance de la route, je ne vois pas ce qu'on gagnerait en pratique
>> malgré la "pureté" du critère. Et puis surtout comment pratiquement
>> évaluerais-tu ce critère d'importance de la route sans panneau ?
>>
>> Le 21. 08. 17 à 02:42, Jérôme Amagat a écrit :
>>  > Certaine route tertiaire sont plus proche en passant dessus d'une
>>  > autoroute que certaine route primaire.
>> l'autoroute Metz-Strasbourg est par endroit dans un état plus proche de
>> la route de compagne abandonnée que de l'autoroute. est-ce pour autant
>> que le classement est mauvais ? je trouve qu'il y a assez de clef pour
>> gérer les cas "tordu", ici en l’occurrence smoothness.
>> Dans ton exemple, la route tertiaire est peut-être mal classé. ou alors
>> c'est simplement parce que localement il y a des routes secondaires et
>> primaires plus importante. ou simplement l’age de la route.
>>
>> la seule chose qui me semble mériter réflexion, c'est le fait que des
>> nationales deviennent des départementales pour des raisons de
>> décentralisation et que du coup des départementale peuvent être ou pas
>> être en primary ou secondary, là le critère n'a pas été définit de
>> manière objective.
>> En Suisse par comparaison, c'est uniquement le panneau routier qui fait
>> la différence entre primaire, secondaire et tertiaire.
>>
>> Le 21. 08. 17 à 02:42, Jérôme Amagat a écrit :
>>  >>> Pour trunk, on c'est pas c'est quoi le critère
>>  >> c'est "quasi-autoroute" mais il manque souvent qlq détails à
>>  >> ces routes pour être des autoroutes, souvent entrée trop courte.
>>  > c'est quoi qui manque exactement
>> si tu connaissais la raison, que vas-tu en faire niveau osm ?
>> exemple : je connais des tunnels en ville 2x2 en trunk. La raison est
>> l'absence de bretelle d'entrée puisque le tunnel remonte parfois à la
>> surface pour être en contact avec une rue classique.
>> Je ne vois pas ce que tu voudrais faire niveau osm avec cette info.
>> Par contre l'avoir en trunk est utile, le routage devrait autant que
>> possible te faire utiliser le trunk et non pas les voies de classe
>> inférieur même si celle-ci font gagner quelques mètres sur le trajet.
>> ___
>> 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] Création de la liste OSM tagging-fr

[marc marc]

Le 21. 08. 17 à 11:27, Jean-Marc Liotier a écrit :
> l'affinité pour une technologie de
> communication ou une autre est aussi une dimension culturelle.
C'est exact. mais talk-fr et tagging-fr sont la même technologie.
on ne résout pas celui qui n'aime pas la technologie ml en créant une 
autre ml.

> Peut-être que talk-fr pourrait être ce lieu - ou peut-être
> qu'il est trop connoté "France" pour la Francophonie non-Française.
à nouveau je suis tout a fait d'accord sur la barrière de la langue, ma 
première phrase était même positive sur l'utilité de fédérer la 
francophonie.
mais si talk-fr est trop france aux yeux de certains, tagging-fr l'est 
tout autant. si le but était de regrouper la francophonie, il aurait 
fallu un "-francais".

donc la solution d'une ml de + ne résous pas les problèmes exposés.

De toute façon à mes yeux, le cas est limpide et caricatural.
Un inconnu arrive sans discussion pour présenter son "bébé" et ne dit 
pas un mot aux réaction, c'est un projet purement personnel de son 
auteur, y a qu'à cliquer. Pour caricaturer, c'est un spam :-)

En l'absence de volume suffisant que pour couper talk-fr en 2, pour ma 
part j'éviterai de nous disperser encore plus.
Pour prendre un exemple caricatural, un problème de tag operator sur 
l'arrêt de bus de la ligne flexibus a Bâle pourrait être traité dans les 
ml talk-ch (sa position géographique), transport (sa spécificité), 
talk-fr (la langue du contributeur), talk (le côté international), 
tagging-fr, tagging sans compter les forums ayant le même sujet, les 
canaux irl, les changeset, les pages wiki et les messages privés.
on s'étonnera pas de la difficulté d'harmonisation et de vitalité.

Ce qui me semblerait utile c'est d'abolir les barrières techniques entre 
ces différentes canaux.
Par exemple la ml talk-fr a déjà une interface web.
il ne manque pas grand chose pour rendre la ml utilisable comme un forum 
(on sait déjà s'identifier et lire, il manque juste la possibilité de 
faire une réponse via page web au lieu de l'ouverture d'un client mail)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Route en sens unique, mais pas pour tous

[Jean-Claude Repetto]

Bonjour,

J'ai vu hier un panneau de sens interdit, avec la mention "SAUF POIDS
LOURDS ET RIVERAINS".

Comment décrire ces restrictions dans OSM ?

___
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

[Jo]

network:wikidata ...

2017-08-21 12:30 GMT+02:00 marc marc :

> Le 21. 08. 17 à 02:05, Jérôme Amagat a écrit :
> > les relations network n'est sur le wiki qu'a l’état de proposition
> Tu as raison, on s'est un peu emballé.
> je change donc mon avis, chaque fois que je préconisais l'utilisation
> d'une relation network devient l'utilisation du tag network.
> Par contre cela ne change pas mon avis sur la limite de où l'utiliser :
> oui sur les objets non physique du réseau de bus, au + haut au mieux.
> mais inadéquoi sur le mobilier urbain, le marquage routier etc
>
> > Si c'est pour pouvoir mettre quelque part le vrai nom
> >  du réseau pourquoi ne pas le mettre directement dans le tag network=*.
> ä la base,la discussion avait commencé parce que pour le réseau arc en
> ciel, le nom même du réseau est très hétéroclite et de plus 2 réseaux
> différents semblent exister en France avec ce nom.
> il aurait été pratique d'avoir 2 relations pour permettre au moins de
> classer les objets dans le bon groupe même si la typo exact du nom doit
> être affinée (celui de leur site web, celui écrit sur les bus, ..)
> Mais puisqu'il est mieux de faire sans relation network, le débat est
> rouvert sur comment les séparer facilement.
> ___
> 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] Route en sens unique, mais pas pour tous

[Jo]

oneway:hgv=no
oneway:destination=no

2017-08-21 13:03 GMT+02:00 Jean-Claude Repetto :

> Bonjour,
>
> J'ai vu hier un panneau de sens interdit, avec la mention "SAUF POIDS
> LOURDS ET RIVERAINS".
>
> Comment décrire ces restrictions dans OSM ?
>
> ___
> 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] le festival de tout les highway :-)

[Philippe Verdy]

Les living_street et pedestrian prennent le pas sur les
primary/secondary/tertiary qui sont très orientés pour les voitures (s'il y
a des piétons ils ont leurs trottoirs pour les protéger, ce n'est pas le
cas des living_street et pedestrian où les piétons sont invités en
permanence à utiliser toute la chaussée et n'ont pas nécessairement des
trottoirs (qui sont même enlevés ou mis à niveau par surélévation de la
bande roulante des living_street, pour faciliter l'accessibilité en
fauteuil).

Noter aussi que des pedestrian interdisent normalement l'entrée des
véhicules motorisés (de jour comme de nuit), mais il y a des accès limités
pour certains véhicules (comme les bus, services d'urgence, police, convois
de fonds et l'accès à des places de stationnement plus proches pour
handicapés, et sur autorisation préalable les engins de chantier et
déménageurs) qui peuvent y rouler au pas. Ces permissions ne sont pas
accordées en revanche aux résidents et il n'y a pas de place de
stationnement de véhicules sur la voie (juste éventuellement des parcs à
vélo, interdits au deux-roues motorisés).

Une rue living_street ou pedestrian peut avoir une importance économique et
avoir un traffic (piéton) important mais ça n'en fait pas une "primary". La
Rue Le Bastard de Rennes, même si elle est très fréquentée, n'est en fait
plus importante que les rues piétonnes adjascentes: son importance est
surtout commerciale mais elle n'est pas un itinéraire plus privilégié que
les autres pour dé&terminer un parcours à pied: ce n'est pas en
l'empruntant en priorité qu'on ira plus vite que par les autres rues ou
places piétonnes.

La Place de la République est clairement living_street et l'essentiel du
trafic a clairement été détourné vers le sud (par le Boulevard de la
Liberté). Elle était dans le passé "primary" mais ce n'est plus le cas du
tout et les derniers véhicules qui y circulent encore sans encombre (tout
en roulant au pas), ce sont les bus de transport en commun de la ville (les
autres bus et cars doivent passer au sud vers la gare puis par le boulevard
de la Liberté pour rejoindre la place de Bretagne)... Elle n'est
aujourd'hui d'importance que pour les piétons et cyclistes, mais uniquement
parce que c'est le trajet le plus court et le plus accessible et parce que
c'est un noeud d'échange important des transports en commun (bus et métro).
En journée aux heures chargées, les voitures peuvent y perdre pas mal de
temps pour laisser passer les nombreux piétons qui traversent à tout moment
et même empruntent la bande roulante dans sa longueur. Les bus aussi sont
très ralentis, et il y a beaucoup de piétons qui attendent aux multiples
stations ou à descendre des bus sans regarder, ça impose de rouler au pas
et attendre sans doubler quand un bus est à l'arrêt.

Rien qu'avec le monde attendant aux stations, les autres piétons (et
cyclistes) sont amenés à emprunter toute la largeur de la rue et à y
zigzaguer. On peut se demander alors pourquoi il n'y a pas de barrières
contre les véhicules (barrières télécommandées que peuvent relever les bus
entrant dans la zone), à défaut de police pour les surveiller (comme sur
port de la Rochelle durant weekends et fêtes, même en l'absence de
manifestation culturelle ou commerciale, mais maintenant c'est remplacé par
des barrières automatiques aussi pour les bus et camions de ramassage des
poubelles, et ouvertes seulement aux heures de livraison autorisées tôt le
matin mais avec cependant une interdiction permanente d'accès pour les
autres véhicules motorisés; les taxis du port ont vus leur parcours modifié
et ont un accès limité uniquement pour rejoindre la station et devraient
disposer de la télécommande ; en haute saison, la police est toujours
présente à l'entrée du port pour demander aux véhicules de faire demi-tour
d'où ils viennent et prendre les avenues périphériques)


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

> Alors je connais des "living_street" d'importance "primary" (Rennes, place
> de la République), ainsi que des "pedestrian" d'importance "primary" (la
> rue Le Bastard à Rennes) :-)
>
>
> djakk
>
> Le lun. 21 août 2017 à 12:06, marc marc  a
> écrit :
>
>> En relisant, je trouve qu'il y a une assez grande cohérence puisque
>> hormis residential, les autres valeurs dépendent des panneaux routiers.
>>
>> Le 21. 08. 17 à 02:42, Jérôme Amagat a écrit :
>> > le panneau veux dire plusieurs choses sur son "aspect" minimum 2x2 voies
>> > séparées bandes d’arrêt d'urgence... et sur les règles a respecter, pas
>> > de velo, vitesse minimum, vitesse maximum plus élevé que sur les autres
>> > routes...
>>
>> Oui mais c'est inévitable. il n'y a aucune autoroute aménagée comme un
>> living_street et inversement.
>> alors oui fatalement autoroute implique à la fois l'importance de la
>> route (sa fonction première) et une série de valeur par défaut.
>> Vouloir séparer cela reviendrait à devoir mettre des milliers de tag de
>> valeur par défaut juste pour avoir un tag "purement" limité à
>> 

Re: [OSM-talk-fr] Route en sens unique, mais pas pour tous

[David Crochet]

Le 21/08/2017 à 13:03, Jean-Claude Repetto a écrit :

J'ai vu hier un panneau de sens interdit, avec la mention "SAUF POIDS
LOURDS ET RIVERAINS".

Comment décrire ces restrictions dans OSM ?


Et de l'autre côté, il y est dit quoi ?

Cordialement

--
David Crochet


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

Re: [OSM-talk-fr] Manque un feu tricolore : volontaire?

[Christian Quest]

C'est bien plus courant qu'on ne pense, j'en ajoute encore beaucoup 
partout où je passe et sur des endroits très urbanisés?


Il y a beaucoup de détails de ce type qui manquent, mais leur absence 
n'est pas si visible dans les données, alors qu'une route manquante, un 
nom de rue manquant ça se voir bien plus vite sur les rendus et autres 
usages.



Le 18/08/2017 à 23:30, Shohreh a écrit :

Merci pour les infos.

En cherchant ailleurs dans le coin, je me rends compte qu'il y a d'autres
carrefours où il n'y a carrément /aucun/ feu tricolore dans OSM :

http://www.openstreetmap.org/?mlat=48.83436&mlon=2.31362#map=18/48.83446/2.31405

Je m'étonne que personne n'ait entré ces feux tricolores dans un coin
pourtant hyper-urbanisé et hyper-renseigné par ailleurs. Comment se fait-ce
?



--
Christian Quest - OpenStreetMap France


___
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

[Philippe Verdy]

Le 21 août 2017 à 02:05, Jérôme Amagat  a écrit :

> Je rappelles que les relations network n'est sur le wiki qu'a l’état de
> proposition, que cette proposition date de 2008, que rien n'a bougé sur
> cette proposition depuis 2013 (et plus après 2009 ce n'est que pour ajouté
> des exemples). Il y a des ajouts sur la page de discutions un peu plus
> récent 2014 mais il sont négatif a l'ajout de ces relations.
>

Je ne vois pas pourquoi ils sont négatifs alors que chaque réseau a ses
outils et méthodes pour travailler et se mettre à jour. Si on ne le fait
pas, ces données seront de toute façon externalisées et le plus souvent
sous forme non libre et très peu accessible. Sans ces relations il est
quasiment impossible de faire un suivi de ce qui est dans la base, alros
qu'on a en permanance besoin de se référer à ces réseaux, pour faire des
plans, calculer des itinéraires et temps de parcours, déterminer les
options tarifaires. Le simple tag "network=*" ne suffit pas et ce n'est pas
en multipliant les tags que cela va s'arranger, alors que ces relations ont
un coût quasi nul dans la base, et sont très facilement accessibles et même
bien plus simple à mettre à jour pour s'assurer de leur complétude:

Elles ne s'étendent pas à une quantité illimitée et non définie d'objets,
on sait exhaustivement ce qui doit être dedans, et ce n'est pas pour des
milliers d'objets ou beaucoup plus: à côté de ça les relations "route" sont
beaucoup plus compliquées, lourdes, instables, et on ne peut pas prédire du
tout le nombre nécessaire de leurs membres. Elles sont un outil de suivi
aussi pratique (sinon plus) pour gérer l'avancement de leur construction ou
de leur mise à jour, elles sont très sélectives, et permettent de diviser
les tâches à faire.

On en revient donc au même débat initial sur les "boundaries" qui ont eu le
même problème (et qui elles aussi demandent des mises à jour): c'est
toujours lors des mises à jour que cela se complique et que les outils
externes sont les plus inefficaces, obligeant les contributeurs à jongler
entre plein d'outils qui ne comprennent pas le même "langage" et ne
s'accordent jamais sur les tags qu'ils reconnaissent et la façon dont ils
gèrent leur sélectivité.

Wikidata c'est bien mais ce n'est pas plus une solution: les objets
Wikidata obéissent à une logique différente (dont celle de "notoriété" qui
peut amener à joindre deux objets différents, ou des logiques de
surclassification qui vont les diviser sans même souvent les relier entre
eux), qui n'a rien à voir avec la couverture géospatiale exhaustive, ni
même la cohérence globale: il va scinder des objets en sous-classes selon
des critères supplémentaires non liés à l'information géospatiale, ajouter
des informations historiques (et les sous-classer) et au final on ne pourra
pas non plus gérer l'exhaustivité voulue par OSM (qui est de représenter
correctement l'état **actuel** et effectif de la carte du monde, sans tenir
compte du passé ou des projections futures qui en revcanche ont une
importance élevée dans Wikidata et ses projets frères qui n'ont pas la même
notion de ce qui est "important" en tant que base de "connaissance"
universelle).

Donc je pense sincèrement que ne pas vouloir les utiliser dans OSM (où leur
mise en oeuvre est on ne peut plus simple et claire) c'est juste rendre
service aux bases de données propriétaires (qui toutes le font dans leurs
données): continuez comme ça, vous soutenez Google et le groupe des "Big
Data", ne vous plaignez pas alors que des services publics soient tentés
ensuite de ne plus utiliser OSM mais passent chez Google pour gérer leur
données de façon cohérente et stable, ou refusent la stratégie Open Data et
vont ne faire confiance qu'à l'IGN qui sera tenté de leur vendre son
"expertise exclusive".
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Bornes à incendie : proposition en cours d'écriture

[Christian Quest]

Le 21/08/2017 à 12:44, François Lacombe a écrit :


Par contre pour ta proposition de réduire flow_capacity en capacity,
je ne suis pas favorable. capacity est trop générique.

Sa généricité est un avantage en fait

capacity=* est utilisé pour dénombrer, souvent pour un nombre de places 
(places de stationnement, sièges dans une salle de spectacle, etc)... 
pour des m3/mn ça me semble bien peu cohérent.




sans lire le wiki, cela pourrait tout aussi bien représenter le nombre
de tuyaux qu'on peux connecter simultanément.

Sans lire la notice, on a généralement des problèmes
Cela dit, on a pas indiqué de clé où donner le nombre de connexions 
possibles et la confusion peut en effet régner.
Là, un namespace peut etre utile et vu qu'il y a déjà des sous-clés de 
capacity, que penses-tu de

capacity:flow et capacity:pipes ?


ça me semblerait bien mieux

--
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] Route en sens unique, mais pas pour tous

[Christian Rogel]

> Le 21 août 2017 à 13:03, Jean-Claude Repetto  a écrit :
> 
> Bonjour,
> 
> J'ai vu hier un panneau de sens interdit, avec la mention "SAUF POIDS
> LOURDS ET RIVERAINS".
> 
> Comment décrire ces restrictions dans OSM ?

Ce genre de bizarrerie fait douter de sa légalité, y compris de l'arrêté 
municipal (réel ou fantôme).
Il pourrait y avoir "sauf livraisons", mais, on peut penser à un entrepreneur 
utilisant des camions et pour qui on prend une mesure de complaisance, tout en 
satisfaisant illégalement des riverains.
Quelle est la base légale d'une limitation aux riverains ? Où trouver la stat 
des amendes pour infractions ?


Christian R.

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

Re: [OSM-talk-fr] Bornes à incendie : proposition en cours d'écriture

[marc marc]

François Lacombe a écrit :

 > Bnhynoteam
c'est quoi/qui ?

> il y a la dépréciation de type=pond sur laquelle j'aurais voulu éviter
> qu'on vote vu que cela conforte la séparation entre hydrant et suction.
> Ok, en effet
> Par contre si il n'est pas déprécié, il faudra quand même le passer dans 
> water_source plutôt que de le laisser dans le type d'hydrant
j'ai répondu en ce sens ce midi sur la ml mondiale avec une phrase de 
remplacement qui ne ferme pas la porte à une fusion des 2 tag emergency.
A voir ce qu'il en pense.

> Par contre pour ta proposition de réduire flow_capacity en capacity,
> je ne suis pas favorable. capacity est trop générique.
> sans lire le wiki, cela pourrait tout aussi bien représenter le nombre
> de tuyaux qu'on peux connecter simultanément.
> Sans lire la notice, on a généralement des problèmes
tu ne peux pas espérer que ceux qui utilisent id ou un éditeur mobile 
commencent par lire le wiki pour chaque tag utilisé.
Je trouve que le nom d'un tag doit vraiment être très parlant.
les preset pour les clefs ayant une liste de valeur courante.
le wiki étant là pour la qualité des détails ou des explications.

> Cela dit, on a pas indiqué de clé où donner le nombre de connexions 
> possibles et la confusion peut en effet régner.
> Là, un namespace peut etre utile et vu qu'il y a déjà des sous-clés de 
> capacity, que penses-tu de
> capacity:flow et capacity:pipes ?

flow_capacity existe déjà. 6000+ occurrences.
Lui faire perdre son préfixe pour le rendre commun aux suction_point 
serait déjà une avancé.
Depuis le temps que + de 80% de la proposition est accepté unanimement, 
je pense qu'à un moment, il vaut mieux valider ce qui est unanime quitte 
à ouvrir un nouveau chantier pour le reste.
c'est en ce sens que je n'ai pas réagit à propos de fire_hydrant:count
c'est obscur, y compris la description du wiki.
mais comme la propal n'y touche pas, je préférais ne pas ouvrir un point 
supplémentaire de discussion afin que le reste soie validé.

> De plus je pense qu'il est utile, pour les éditeurs, d'avoir un seul
> type d'unité par clé afin de pouvoir l'afficher lors de la saisie.
> sinon les éditeurs doivent avoir une liste hard-codée des unités en
> fonction de l'objet, c'est contre-productif à l'effet souhaité d'une
> harmonisation des clefs.
> Problématique intéressante que je n'ai pas rencontré jusque là.
> JOSM par exemple, n'affiche pas d'unité dans les presets il me semble ?
Je n'en ai jamais vu mais ce serrait utile. Rien ne bloque techniquement

> Est-ce que tu étend cela aux multiples ? Parce que pour height, même si 
> le défaut est en mètres, on peut préciser des valeurs en km en 
> l'ajoutant à la fin de la valeur.
Si je devais coder un éditeur, je ferrai une différence entre ce que 
l'utilisateur encode et ce qui est mis en base.
une largeur encodée comme 100cm serrait transformé par 1 en base.
J'avais fais la réflexion lorsqu'il a mis l/min devant m3/h.
Mais à nouveau je pense que c'est un tout autre sujet, qui ne doit pas 
bloquer la validation de la proposition actuelle.
___
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

[marc marc]

MM> puisqu'il est mieux de faire sans relation network,
MM> le débat est rouvert sur comment les séparer facilement.
Le 21. 08. 17 à 13:42, Jo a écrit :
 > network:wikidata ...
C'est une bonne solution pour contourner temporairement le problème.
Mais cela implique de dépendre de wikipedia pour afficher/trouver le nom 
d'une réseau de bus... et n'avoir aucune solution lorsqu'un petit réseau 
de bus n'a pas la notoriété suffisante que pour être dans wikipedia

Le 21. 08. 17 à 14:47, Philippe Verdy a écrit :
 > ces données seront de toute façon externalisées et le plus
 > souvent sous forme non libre et très peu accessible.
aucun rapport. un tag network dans osm est tout aussi libre/accessible.

Le 21. 08. 17 à 14:47, Philippe Verdy a écrit :
> pour faire des plans, calculer des itinéraires
Utiliser les tag network sur les relations routes ne suffit pas ?

Le 21. 08. 17 à 14:47, Philippe Verdy a écrit :
 > ces relations ont un coût quasi nul dans la base
Ce point là est un argument positif.

 > c'est toujours lors des mises à jour que cela se complique
je suis justement TRES favorable à la non duplicité des infos pour cette 
raison. Mais un tag sur les route_master me semble être un compromis.
Pourrais-tu (sommairement) préciser ce qui est pénalisant avec un tag 
network sur les relations route_master à la place d'une relation network 
(qui n'existe pas beaucoup) ? un cas concret par exemple
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] le festival de tout les highway :-)

[marc marc]

Le 21. 08. 17 à 12:38, djakk djakk a écrit :
> je connais des "living_street" d'importance "primary" (Rennes, 
> place de la République), ainsi que des "pedestrian" d'importance 
> "primary" (la rue Le Bastard à Rennes) :-)
c'est à mes yeux tellement incohérent que je n'arrive même à imaginer ce 
que tu veux dire.
primary = route donc la fonction première est d’assurer le trafic de 
transit entre des lieux/routes importants.
living_street = route dont la fonction est d'être un espace de vie 
piéton et où l'automobile est toléré et subalterne au piéton.

Je ne vois pas comment un même lieu peux être les 2 à la fois.

Le 21. 08. 17 à 12:46, djakk djakk a écrit :
 > 1) son importance (primaire, secondaire ...)
 > 2) son classement administratif (panneau d'entrée ou de sortie
 > d'autoroute ou de "motorroad")
 > 3) ses caractéristiques physiques (carrefours dénivelés,
 > living_street, route classique ...)
panneau/utilité/aménagement sont 3 faces d'une même pièce même s'il y a 
des variations sur les détails.

 > 5) la qualité de son revêtement (surtout utile dans les pays
 > en voie de développement)
et aux mobilités alternatives. le vélo de vile ou le roller sur une 
route dégradée, c'est inconfortable.
___
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

[lenny.libre]

Entre les deux mon cœur balance, au fur et à mesure de ce que je lis, je 
change ... Je n'avais pas d'avis au départ, mais maintenant je n'en ai 
pas plus.


Le 21/08/2017 à 02:05, Jérôme Amagat a écrit :
Je rappelles que les relations network n'est sur le wiki qu'a l’état 
de proposition, que cette proposition date de 2008, que rien n'a bougé 
sur cette proposition depuis 2013 (et plus après 2009 ce n'est que 
pour ajouté des exemples). Il y a des ajouts sur la page de discutions 
un peu plus récent 2014 mais il sont négatif a l'ajout de ces relations.


Cette relation, ça serait juste, mettre tous les éléments qui ont le 
même tag network=* dans une même relation (ou que les 
type=route_master) donc c'est faire une liste, une catégorie ce qui ne 
se fait pas dans osm. Si l'on veux tous les élément d'un même réseau 
il y a d'autre moyen de les obtenir que de créer ce type de relation. 
Si c'est pour pouvoir mettre quelque part le vrai nom du réseau 
pourquoi ne pas le mettre directement dans le tag network=*.
Le principal avantage que je vois dans la relation c'est ce qu'il m'a 
semblé comprendre de ce disait Philippe : le tag "network", c'est 
uniquement un code donc au lieu de fr_tisseo on pourrait avoir 
FR:pt_tlse - dans la relation, on peut aussi y mettre wikidata pour 
avoir l'unicité) le jour ou le nom du réseau change, il suffirait de 
changer le name (et éventuellement le wikidata) dans la relation network 
; il y a quelques temps à Bordeaux (où il n'y a pas de relation 
network), tous les tags "network" on été modifiés de "TBC" -> "TBM".


Le wikidata qui me plaisait (en permettant avec osmose de contrôler) m'a 
un peu refroidi depuis que je vois qu'il y a des manques de rigueur et 
que si le nom change, il faudra certainement changer le network et aussi 
le network:wikidata, j'y vois moins d'avantages, la marque du réseau de 
Bordeaux étant passé par le stade CGFTE (wikidata=Q2990197) je n'ai pas 
trouvé TBC, puis TBM (wikidata=Q377695)  et comment je fais pour le 
réseau du transport scolaire de Haut-Garonne qui n'a pas de wikidata ?


Si vous pensez que ces relation doivent exister, remettez un peu a 
jour la page de proposition avec des exemples qui existent encore et 
allez parler d'un vote de cette proposition sur la liste tagging (en 
anglais :) ) .


Sinon pourquoi ne pas créer des relations pour tous les objets qui ont 
le même operator comme par exemple EDF et vu que le même nom pourrait 
être utilisé ailleurs dans le monde il faudrait pour tout les tag 
operator=* ajouter "fr_" devant le nom comme par exemple operator=fr_EDF.
C'est que la relation ne serait pas utilisée pour faire la liste de tous 
les objets (bâtiment, parkings, agences, ...) ce qui serait une 
catégorie, mais uniquement les éléments constitutifs du réseau.
Après avoir beaucoup écouté, fr_ (qui est associé à la langue) ne 
devrait pas être utilisé, mais plutôt FR: (associé au pays)


Pareil pour les nom de rue addr:street=*, par exemple, il faudrait 
différencier l'"Avenue du général de Gaulle" des différentes villes, 
c'est pas les mêmes. On fait quoi on préfixe avec le nom des ville? De 
toute façon les noms on les mets que sur le tag name=* donc il n'a pas 
à être sur addr:street=* donc on peut y mettre quelque chose qui 
servira de référence pour chaque rue différente dans le monde. et on 
crée une relation pour chaque rue où on met dans name=* le vrai nom de 
la rue. A mer**, ça existe déjà, c'est les relation associatedStreet 
mais là on n'a pas modifié ce qu'on met dans addr:street pour que 2 
rues différentes n'est pas la même valeurs.
voici un argument que je ne comprends vraiment pas, ce n'est pas en 
mélangeant les oranges et les navets qu'on éclaircit le débat.



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

Re: [OSM-talk-fr] Bornes à incendie : proposition en cours d'écriture

[François Lacombe]

Le 21 août 2017 à 19:27, marc marc  a écrit :

>   > Bnhynoteam
> c'est quoi/qui ?
>

La Base des Hydrants nationale ouverte ;)
Un idée d'Eric Pommereau, Yann Kacenelen, Donat Robaux et d'autres
On peut en trouver trace sur Twitter, et j'ai mis un n en trop. C'est
Bhynoteam le bon nom


> j'ai répondu en ce sens ce midi sur la ml mondiale avec une phrase de
> remplacement qui ne ferme pas la porte à une fusion des 2 tag emergency.
> A voir ce qu'il en pense.
>
Et je partage complètement
Il faut juste indiquer water_source=pond pour le moment et c'est très bien.


>
> > Par contre pour ta proposition de réduire flow_capacity en capacity,
> > je ne suis pas favorable. capacity est trop générique.
> > sans lire le wiki, cela pourrait tout aussi bien représenter le
> nombre
> > de tuyaux qu'on peux connecter simultanément.
> > Sans lire la notice, on a généralement des problèmes
> tu ne peux pas espérer que ceux qui utilisent id ou un éditeur mobile
> commencent par lire le wiki pour chaque tag utilisé.
>
Non en effet, mais les presets en tiennent compte et donc les éditeurs
donnent des conseils voire des avertissements en cas de contributions
identifiée comme maladroite.


> Je trouve que le nom d'un tag doit vraiment être très parlant.
>
Nous sommes d'accord. Néanmoins c'est une approche subjective. Ce qui est
parlant pour l'un ne l'est pas pour l'autre. Regardes comment certains
s’accommodent des clés fire_hydrant:xx

les preset pour les clefs ayant une liste de valeur courante.
> le wiki étant là pour la qualité des détails ou des explications.
>
Non c'est la seule référence, c'est pour ça que la rédaction des pages doit
être la plus complète possible en recensant tous les cas si possible.

flow_capacity existe déjà. 6000+ occurrences.
> Lui faire perdre son préfixe pour le rendre commun aux suction_point
> serait déjà une avancé.
> Depuis le temps que + de 80% de la proposition est accepté unanimement,
> je pense qu'à un moment, il vaut mieux valider ce qui est unanime quitte
> à ouvrir un nouveau chantier pour le reste.
>
C'est un piège.
On a eu le cas sur l'énergie et il y a des choses qui ne se feront jamais
(sur les supports poteaux et pylônes, qu'on aurait pu rapprocher de
man_made=tower)
En effet le périmètre de la proposition doit rester raisonnable, mais
d'expérience je ne suis pas d'accord pour faire la moitié du chemin
maintenant le reste après.
Si on laise flow_capacity, le coup d'après il sera à 80k utilisations et
indéboulonnable (parce qu'indiqué comme Approved dans le wiki entre autres)
Je ne dis pas que c'est une mauvaise chose, mais il faut choisir en ayant
ça à l'esprit.

capacity est déjà un concept largement utilisé, que l'on peut compléter en
lui ajoutant des suffixes pour gérer le cas des unités.
C'est ce que je trouve intéressant, mais conçoit que ça ne séduise pas tout
le monde.
En le choisissant, on se range du côté de l'existant et ce sera ainsi plus
facile à faire adopter.


> c'est en ce sens que je n'ai pas réagit à propos de fire_hydrant:count
> c'est obscur, y compris la description du wiki.
>
mais comme la propal n'y touche pas, je préférais ne pas ouvrir un point
> supplémentaire de discussion afin que le reste soie validé.
>
count, c'est comme type, le fourre-tout qu'on peut rendre plus explicite
dans 80% des cas.
Au contraire, il faut en parler.
Ne pas discuter des points pour accélérer ne m'attire pas trop.

> De plus je pense qu'il est utile, pour les éditeurs, d'avoir un seul
> > type d'unité par clé afin de pouvoir l'afficher lors de la saisie.
> > sinon les éditeurs doivent avoir une liste hard-codée des unités en
> > fonction de l'objet, c'est contre-productif à l'effet souhaité d'une
> > harmonisation des clefs.
> > Problématique intéressante que je n'ai pas rencontré jusque là.
> > JOSM par exemple, n'affiche pas d'unité dans les presets il me semble ?
> Je n'en ai jamais vu mais ce serrait utile. Rien ne bloque techniquement
>
> > Est-ce que tu étend cela aux multiples ? Parce que pour height, même si
> Mais à nouveau je pense que c'est un tout autre sujet, qui ne doit pas
> bloquer la validation de la proposition actuelle.
>
Ok, je partage.
On va trouver une clé adéquate pour indiquer un débit et ce sera réglé.

Accordons-nous sur ces points, et nous verrons ce qu'il est utile de lancer
dans le Talk de la propal ensuite

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

Re: [OSM-talk-fr] le festival de tout les highway :-)

[djakk djakk]

Alors une route primaire en même temps living_street c'est simple, tu mets
ce panneau carré bleu avec des piétons et une "limitation à 20 km/h"
incrusté (
https://fr.m.wikipedia.org/wiki/Panneau_de_signalisation_d%27une_zone_de_rencontre_en_France)
sur un des axes les plus importants d'une ville (quoiqu'en dise Philippe,
j'ai fait un petit sondage sur la mailing-list bzh c'est un axe "secondary"
au minimum). ;-)


djakk

Le lun. 21 août 2017 à 19:59, marc marc  a
écrit :

> Le 21. 08. 17 à 12:38, djakk djakk a écrit :
> > je connais des "living_street" d'importance "primary" (Rennes,
> > place de la République), ainsi que des "pedestrian" d'importance
> > "primary" (la rue Le Bastard à Rennes) :-)
> c'est à mes yeux tellement incohérent que je n'arrive même à imaginer ce
> que tu veux dire.
> primary = route donc la fonction première est d’assurer le trafic de
> transit entre des lieux/routes importants.
> living_street = route dont la fonction est d'être un espace de vie
> piéton et où l'automobile est toléré et subalterne au piéton.
>
> Je ne vois pas comment un même lieu peux être les 2 à la fois.
>
> Le 21. 08. 17 à 12:46, djakk djakk a écrit :
>  > 1) son importance (primaire, secondaire ...)
>  > 2) son classement administratif (panneau d'entrée ou de sortie
>  > d'autoroute ou de "motorroad")
>  > 3) ses caractéristiques physiques (carrefours dénivelés,
>  > living_street, route classique ...)
> panneau/utilité/aménagement sont 3 faces d'une même pièce même s'il y a
> des variations sur les détails.
>
>  > 5) la qualité de son revêtement (surtout utile dans les pays
>  > en voie de développement)
> et aux mobilités alternatives. le vélo de vile ou le roller sur une
> route dégradée, c'est inconfortable.
> ___
> 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] le festival de tout les highway :-)

[osm . sanspourriel]

Tes statistiques viendraient d'actuels Rennais peut-être...

Mais là tu mélanges des gens qui ont connu les quais du temps de la 
bagnole reine (sans jeu de mot) et d'autres qui connaissent la situation 
actuelle.


Ce fut un axe important et ça le reste... pour les transports en commun 
et les manifs ;-).


Il ne faut surtout pas conseiller de passer par là donc living_street et 
c'est tout.


La décision de changer le statut de la rue doit se retrouver dans OSM.

Ce qui me semble aberrant c'est de laisser le statut primary (!) aux 
quais Lamartine et Duguay Trouin 
 de 
part et d'autre.


C'est-à-dire juste en dessous des voies-express !

N.B. : Rennes, c'est la seule ville qui a réussi à boucher (cacher) une 
rivière pour mettre du gravillon à la place ou il y en a d'autres ? 
D'habitude c'est pour mettre des parkings. Là ils ont bouché pour mettre 
un parking puis ont enlevé le parking pour mettre du gravillon. C'est 
vrai que la Vilaine porte bien son nom mais quand même :-D.


Jean-Yvon


Le 21/08/2017 à 21:35, djakk djakk - djakk.dj...@gmail.com a écrit :
Alors une route primaire en même temps living_street c'est simple, tu 
mets ce panneau carré bleu avec des piétons et une "limitation à 20 
km/h" incrusté 
(https://fr.m.wikipedia.org/wiki/Panneau_de_signalisation_d%27une_zone_de_rencontre_en_France) 
sur un des axes les plus importants d'une ville (quoiqu'en dise 
Philippe, j'ai fait un petit sondage sur la mailing-list bzh c'est un 
axe "secondary" au minimum). ;-)



djakk




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

Re: [OSM-talk-fr] Bornes à incendie : proposition en cours d'écriture

[osm . sanspourriel]

Clairement capacity c'est sans unité ou une unité évidente (chambres, 
place de camping, parking).


Et pour la question des unités, soit c'est une unité directe du SI soit 
on doit la préciser.


Par exemple mph pour les vitesses car on utilise en général des 
multiples de 5 et souvent de 10.
On voit mal l'éditeur transformer en 72,4 km/h en base. Mais un 
calculateur d'itinéraire va tout convertir en valeurs numériques.

Par contre 100 cm devient 1 (m).

capacity:flow me va. Préciser l'unité par défaut.

Le 21/08/2017 à 21:10, François Lacombe - fl.infosrese...@gmail.com a 
écrit :
capacity est déjà un concept largement utilisé, que l'on peut 
compléter en lui ajoutant des suffixes pour gérer le cas des unités.
C'est ce que je trouve intéressant, mais conçoit que ça ne séduise pas 
tout le monde.
En le choisissant, on se range du côté de l'existant et ce sera ainsi 
plus facile à faire adopter.


___
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

[osm . sanspourriel]

Le 21/08/2017 à 20:28, lenny.libre - lenny.li...@orange.fr a écrit :

Le wikidata qui me plaisait (en permettant avec osmose de contrôler) 
m'a un peu refroidi depuis que je vois qu'il y a des manques de 
rigueur et que si le nom change, il faudra certainement changer le 
network et aussi le network:wikidata, j'y vois moins d'avantages, la 
marque du réseau de Bordeaux étant passé par le stade CGFTE 
(wikidata=Q2990197) je n'ai pas trouvé TBC, puis TBM 
(wikidata=Q377695)  et comment je fais pour le réseau du transport 
scolaire de Haut-Garonne qui n'a pas de wikidata ?

Tu peux aussi ajouter un wikidata.
Pour les noms, comme wikidata ça peut aussi être édité n'importe 
comment, je suis plus pour intégrer (pas importer) des wikidata dans OSM.
L'unicité du tag te permet de répercuter les changements de nom mais il 
me semble que l'action de mettre à jour les noms doit être lancée par un 
humain.

Notamment parce qu'on a des règles spécifiques.
Par exemple je ne sais pourquoi la page sur la SNSM s'appelle Société 
nationale de sauvetage en mer. Comme il s'agit d'un nom propre, ça 
devrait être Société Nationale de Sauvetage en Mer.

Je pourrais le changer mais ne connaissant pas leurs règles je m'abstiens.

Le 21/08/2017 à 19:46, marc marc - marc_marc_...@hotmail.com a écrit :

MM> puisqu'il est mieux de faire sans relation network,
MM> le débat est rouvert sur comment les séparer facilement.
Le 21. 08. 17 à 13:42, Jo a écrit :
  >network:wikidata  ...
C'est une bonne solution pour contourner temporairement le problème.
Mais cela implique de dépendre de wikipedia pour afficher/trouver le nom
d'une réseau de bus... et n'avoir aucune solution lorsqu'un petit réseau
de bus n'a pas la notoriété suffisante que pour être dans wikipedia
Non, tu intègres l'objet wikidata dans OSM ,il a donc son existence 
propres, tu t'y réfères pour mettre à jour les noms.
si tu changes le nom du wikdata, tu mets à jour les network= des objets 
ayant ce network:wikidata=.


Jean-Yvon
---
trouvé par hasard :

the map is not the territory

https://medium.com/@copyconstruct/small-functions-considered-harmful-91035d316c29

https://cdn-images-1.medium.com/max/1600/1*i5vRl8dA8docZutvy-LgYA.png


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

Re: [OSM-talk-fr] Bornes à incendie : proposition en cours d'écriture

[marc marc]

Le 21. 08. 17 à 21:10, François Lacombe a écrit :
> 
> Le 21 août 2017 à 19:27, marc marc  > a écrit :
> 
>  > Bnhynoteam
> c'est quoi/qui ?
> 
> 
> La Base des Hydrants nationale ouverte ;)
si tu les connais, préviens les qu'ils ne réagissent pas ici.

> flow_capacity existe déjà. 6000+ occurrences.
> Lui faire perdre son préfixe pour le rendre commun aux suction_point
> serait déjà une avancé.
> Depuis le temps que + de 80% de la proposition est accepté unanimement,
> je pense qu'à un moment, il vaut mieux valider ce qui est unanime quitte
> à ouvrir un nouveau chantier pour le reste.
> C'est un piège.
> Si on laise flow_capacity, le coup d'après il sera à 80k utilisations et 
> indéboulonnable (parce qu'indiqué comme Approved dans le wiki entre autres)
> Je ne dis pas que c'est une mauvaise chose, mais il faut choisir en 
> ayant ça à l'esprit.
il est vrai que la proposition concerne aussi le tag flow_capacity
ce n'est pas la même chose que si la proposition n'en parlait pas.
Donc en effet autant voter sur quelque chose d'abouti.
Mais voilà, je ne vois pas exactement le problème avec flow_capacity
capacity:flow je trouve flow assez générique. vois-tu un autre tag avec 
flow possible ? parce que sinon c'est un peu l'inverse de type, ce serra 
un tag tellement précis qu'il n'existe qu'avec capacity et dans ce cas 
flow_capacity serrait tout aussi bien.
Si t'as un exemple d'autre "flow", je me rangerai à ton avis.


> c'est en ce sens que je n'ai pas réagit à propos de fire_hydrant:count
> c'est obscur, y compris la description du wiki.
> mais comme la propal n'y touche pas, je préférais ne pas ouvrir un point
> supplémentaire de discussion afin que le reste soie validé.
> count, c'est comme type, le fourre-tout qu'on peut rendre plus explicite 
> dans 80% des cas.
> Au contraire, il faut en parler.
pourquoi rajouter un nouveau tag à discuter ? la proposition ne touche 
pas à ce tag, c'était mauvais, cela reste mauvais, cela reste à 
améliorer. sinon au final on se trouve avec une propal pour résoudre 
tous les défaut d'osm (je caricature volontairement fortement) mais qui 
reste non adoptée.


> Ne pas discuter des points pour accélérer ne m'attire pas trop.
mon avis n'est pas dans ce sens.
je voulais dire "diviser pour aboutir", un pas après l'autre

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

Re: [OSM-talk-fr] Bornes à incendie : proposition en cours d'écriture

[marc marc]

> Le 21 août 2017 à 23:23, marc marc  a écrit :
> 
> capacity:flow je trouve flow assez générique.
Je voulais l'inverse : tellement spécifique que flow n'existerait pas avec une 
autre clef
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] le festival de tout les highway :-)

[djakk djakk]

Ben oui c'est un axe très emprunté tout simplement, et tu me demanderais
ton chemin je te conseillerai en toute bonne foi de passer par là malgré la
limitation à 20km/h :)


djakk

Le lun. 21 août 2017 à 22:55,  a écrit :

> Tes statistiques viendraient d'actuels Rennais peut-être...
>
> Mais là tu mélanges des gens qui ont connu les quais du temps de la
> bagnole reine (sans jeu de mot) et d'autres qui connaissent la situation
> actuelle.
>
> Ce fut un axe important et ça le reste... pour les transports en commun et
> les manifs ;-).
>
> Il ne faut surtout pas conseiller de passer par là donc living_street et
> c'est tout.
>
> La décision de changer le statut de la rue doit se retrouver dans OSM.
>
> Ce qui me semble aberrant c'est de laisser le statut primary (!) aux quais
> Lamartine et Duguay Trouin
>  de
> part et d'autre.
>
> C'est-à-dire juste en dessous des voies-express !
>
> N.B. : Rennes, c'est la seule ville qui a réussi à boucher (cacher) une
> rivière pour mettre du gravillon à la place ou il y en a d'autres ?
> D'habitude c'est pour mettre des parkings. Là ils ont bouché pour mettre un
> parking puis ont enlevé le parking pour mettre du gravillon. C'est vrai que
> la Vilaine porte bien son nom mais quand même :-D.
>
> Jean-Yvon
>
> Le 21/08/2017 à 21:35, djakk djakk - djakk.dj...@gmail.com a écrit :
>
> Alors une route primaire en même temps living_street c'est simple, tu mets
> ce panneau carré bleu avec des piétons et une "limitation à 20 km/h"
> incrusté (
> https://fr.m.wikipedia.org/wiki/Panneau_de_signalisation_d%27une_zone_de_rencontre_en_France)
> sur un des axes les plus importants d'une ville (quoiqu'en dise Philippe,
> j'ai fait un petit sondage sur la mailing-list bzh c'est un axe "secondary"
> au minimum). ;-)
>
>
> djakk
>
>
>
>
> ___
> 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] le festival de tout les highway :-)

[Philippe Verdy]

Le 21 août 2017 à 22:54,  a écrit :

> Tes statistiques viendraient d'actuels Rennais peut-être...
>
> Mais là tu mélanges des gens qui ont connu les quais du temps de la
> bagnole reine (sans jeu de mot) et d'autres qui connaissent la situation
> actuelle.
>
> Ce fut un axe important et ça le reste... pour les transports en commun et
> les manifs ;-).
>
Tout à fait d'accord.

> Il ne faut surtout pas conseiller de passer par là donc living_street et
> c'est tout.
>
> La décision de changer le statut de la rue doit se retrouver dans OSM.
>
> Ce qui me semble aberrant c'est de laisser le statut primary (!) aux quais
> Lamartine et Duguay Trouin
>  de
> part et d'autre. C'est-à-dire juste en dessous des voies-express !
>
 D'accord aussi, on ne peut pas garder ça en primary juste en souvenir de
ce que ça a été: une grosse artère pour automobiles, mais ça ne l'est plus
du tout, tout a été fait pour décourager la voiture de ce secteur des quais
par la République

> N.B. : Rennes, c'est la seule ville qui a réussi à boucher (cacher) une
> rivière pour mettre du gravillon à la place ou il y en a d'autres ?
> D'habitude c'est pour mettre des parkings. Là ils ont bouché pour mettre un
> parking puis ont enlevé le parking pour mettre du gravillon. C'est vrai que
> la Vilaine porte bien son nom mais quand même :-D.
>
Pourtant la Vilaine porte mal son nom quand on voit les belles balades que
font les Rennais depuis longtemps le long de sa vallée. Quel Rennais l'a
jamais été au moulin du Boël ?

Les Bretonnants ne la voient pas si vilaine que ça, son nom c'est la
"Gwilen" (l'orthographe varie un peu selon les variétés dialectales du
breton, mais comme Rennes n'est pas réellement dans la zone historique du
breton mais celle du gallo, proche du normand, de l'angevin et du poitevin
et classé dans un continuum parmi les langues d'oïl, contrairement au
breton d'origine insulaire, le nom de la Vilaine n'a pas toujours été celui
qu'on lui connait maintenant en "français", une langue créée de toute pièce
très tardivement sur des bases ligériennes et non parisienne, mais
uniquement au départ pour la cour royale et qui ne s'est imposée comme
standard qu'au début de XXe siècle... le breton est beaucoup plus ancien et
se retrouve depuis plus de 13 siècles un peu partour en Europe du Nord
jusqu'au royaume de Suède et jusqu'au début du XXe siècle c'était encore
mutuellement intelligible avec le mannois de l'autre côté de la Manche)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] le festival de tout les highway :-)

[djakk djakk]

Je connais la situation actuelle. C'est une "primary" avec des limitations
à 20km/h et à 30km/h et un stop sur une rue secondaire, mais c'est toujours
une artère "toute droite" donc pas vraiment décourageant pour les voitures,
pour preuve le gros flot de voitures qu'on y observe en journée ...


djakk

Le lun. 21 août 2017 à 23:52, Philippe Verdy  a écrit :

> Le 21 août 2017 à 22:54,  a écrit :
>
>> Tes statistiques viendraient d'actuels Rennais peut-être...
>>
>> Mais là tu mélanges des gens qui ont connu les quais du temps de la
>> bagnole reine (sans jeu de mot) et d'autres qui connaissent la situation
>> actuelle.
>>
>> Ce fut un axe important et ça le reste... pour les transports en commun
>> et les manifs ;-).
>>
> Tout à fait d'accord.
>
>> Il ne faut surtout pas conseiller de passer par là donc living_street et
>> c'est tout.
>>
>> La décision de changer le statut de la rue doit se retrouver dans OSM.
>>
>> Ce qui me semble aberrant c'est de laisser le statut primary (!) aux
>> quais Lamartine et Duguay Trouin
>>  de
>> part et d'autre. C'est-à-dire juste en dessous des voies-express !
>>
>  D'accord aussi, on ne peut pas garder ça en primary juste en souvenir de
> ce que ça a été: une grosse artère pour automobiles, mais ça ne l'est plus
> du tout, tout a été fait pour décourager la voiture de ce secteur des quais
> par la République
>
>> N.B. : Rennes, c'est la seule ville qui a réussi à boucher (cacher) une
>> rivière pour mettre du gravillon à la place ou il y en a d'autres ?
>> D'habitude c'est pour mettre des parkings. Là ils ont bouché pour mettre un
>> parking puis ont enlevé le parking pour mettre du gravillon. C'est vrai que
>> la Vilaine porte bien son nom mais quand même :-D.
>>
> Pourtant la Vilaine porte mal son nom quand on voit les belles balades que
> font les Rennais depuis longtemps le long de sa vallée. Quel Rennais l'a
> jamais été au moulin du Boël ?
>
> Les Bretonnants ne la voient pas si vilaine que ça, son nom c'est la
> "Gwilen" (l'orthographe varie un peu selon les variétés dialectales du
> breton, mais comme Rennes n'est pas réellement dans la zone historique du
> breton mais celle du gallo, proche du normand, de l'angevin et du poitevin
> et classé dans un continuum parmi les langues d'oïl, contrairement au
> breton d'origine insulaire, le nom de la Vilaine n'a pas toujours été celui
> qu'on lui connait maintenant en "français", une langue créée de toute pièce
> très tardivement sur des bases ligériennes et non parisienne, mais
> uniquement au départ pour la cour royale et qui ne s'est imposée comme
> standard qu'au début de XXe siècle... le breton est beaucoup plus ancien et
> se retrouve depuis plus de 13 siècles un peu partour en Europe du Nord
> jusqu'au royaume de Suède et jusqu'au début du XXe siècle c'était encore
> mutuellement intelligible avec le mannois de l'autre côté de la Manche)
> ___
> 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] Création de la liste OSM tagging-fr

[Vincent de Château-Thierry]

Bonsoir,

Le 21/08/2017 à 12:51, marc marc a écrit :


De toute façon à mes yeux, le cas est limpide et caricatural.
Un inconnu arrive sans discussion pour présenter son "bébé" et ne dit
pas un mot aux réaction, c'est un projet purement personnel de son
auteur, y a qu'à cliquer. Pour caricaturer, c'est un spam :-)


Attention aux caricatures... Que tu ne connaisses pas Séverin est une 
chose. Le qualifier d'inconnu par ici, en revanche... non.

=> http://www.openstreetmap.org/user/sev_osm


En l'absence de volume suffisant que pour couper talk-fr en 2, pour ma
part j'éviterai de nous disperser encore plus.
Pour prendre un exemple caricatural, un problème de tag operator sur
l'arrêt de bus de la ligne flexibus a Bâle pourrait être traité dans les
ml talk-ch (sa position géographique), transport (sa spécificité),
talk-fr (la langue du contributeur), talk (le côté international),
tagging-fr, tagging sans compter les forums ayant le même sujet, les
canaux irl, les changeset, les pages wiki et les messages privés.
on s'étonnera pas de la difficulté d'harmonisation et de vitalité.


Au fil des années ont émergé un paquet de canaux, pour ne parler que des 
franco-français. On a des ML locales, des sections dédiées sur le forum, 
des ML thématiques (tech, dev...). Voir http://listes.openstreetmap.fr/ 
et http://forum.openstreetmap.fr/ pour un inventaire
Est-ce que tagging-fr trouvera sa place dans le paysage ? Aucune idée. 
Il nous est déjà arrivé de fermer des canaux, sur le constat de leur 
non-utilisation (local-idf@ par exemple).
Avant d'en arriver là, laissons-lui sa chance. Personnellement je ne 
vois aucun risque à la voir arriver. Dans sa manière d'émerger, elle 
illustre bien la do-ocratie par laquelle on qualifie parfois OSM.



Ce qui me semblerait utile c'est d'abolir les barrières techniques entre
ces différentes canaux.
Par exemple la ml talk-fr a déjà une interface web.
il ne manque pas grand chose pour rendre la ml utilisable comme un forum
(on sait déjà s'identifier et lire, il manque juste la possibilité de
faire une réponse via page web au lieu de l'ouverture d'un client mail)


Sauf erreur c'est déjà possible via Nabble :
http://gis.19327.n8.nabble.com/France-f5380434.html

vincent (vincent_95)

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