[OSM-talk-fr] Rues, routes nationales, départementales & RNIL

2019-08-14 Thread Gwenaël Jouvin via Talk-fr 
Bonsoir à tous,


J’ai récemment eu à chercher des routes et OSM m’est d’une grande aide pour les 
localiser.

Malheureusement, il m’a été difficile de trouver certaines références car, 
outre le fait que certains noms ne soient pas à jour (par exemple, l’A5b est 
devenue A105 en 1996 mais les panneaux étant toujours en place, il faut 
fouiller dans nat_ref https://www.openstreetmap.org/way/217154007), on voit 
certaines routes référencées "RNIL".

Exemple : l’ancienne N 3 en Seine-Saint-Denis :
https://www.openstreetmap.org/way/30077579

Le sujet a déjà été abordé il y a quelques années :
https://lists.openstreetmap.org/pipermail/talk-fr/2016-December/082728.html


Cette dénomination ne me paraît vraiment pas officielle et encore moins visible 
sur des panneaux.

Est-il prévu de reprendre les références de ces routes, qui, à certains 
endroits, ont peut-être même été déclassées en départementales ?
J’ai bien conscience que trouver des sources fiables n’est pas évident…


Merci.

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

Re: [OSM-talk-fr] Re: Comment tagger cette ex-départementale à une voie ?

2019-05-20 Thread Gwenaël Jouvin via Talk-fr 
Erratum : tracktype=grade1
https://wiki.openstreetmap.org/wiki/Key:tracktype

« It is primarily used in combination with highway=track (around 96% of uses) 
but it is also noticeable usage on highway=service, highway=path, 
highway=unclassified. This tag is useful to provide info about road quality, 
especially for unpaved roads. »



Le 20/05/2019 à 23:46, Gwenaël Jouvin via Talk-fr a écrit :
> access=yes est inutile, les routes de ces catégories sont en accès pour tout 
> le monde par défaut.
> 
> Restreindre les types d’utilisateurs interdits suffit, en l’occurence les 
> motorisés avec motor_vehicle=no.
> On pourrait affiner en vérifiant si les cavaliers sont autorisés ou non.
> 
> Pourquoi pas pour path, ça collerait avec les dimensions.
> Dans ce cas, pas besoin de la restriction d’accès qui est implicite.
> Par contre, ajouter surface=asphalt voire tracktype=1 me parraissent 
> intéressants pour se démarquer de l’usage « classique » de path, le chemin de 
> terre.
> 
> Important aussi, indiquer la largeur maximale admissible par la barrière 
> (maxwidth) et si elle est compatible avec les fauteuils roulants (wheelchair).
> 
> Gwenaël
> 
> 
> Le 20/05/2019 à 23:30, Shohreh a écrit :
>> France mailing list wrote
>>> On peut ajouter motor_vehicle=no, avec éventuellement agricultural=yes si
>>> les engins d’exploitation agricole sont toujours autorisés.
>>
>> Dans mon dos, voici à quoi ressemble la barrière piéton/vélo (-cargo
>> welcome):
>>
>> https://postimg.cc/75KjDkB6
>>
>> On ne dirait pas que les engins agricoles y soient les bienvenus. Première
>> fois que je vois un truc de ce genre :-/
>>
>> Quid de ça ?
>> highway=unclassified
>> access=yes, motor_vehicle=no
>>
>>
>>
>> --
>> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>>
>> ___
>> 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] Comment tagger cette ex-départementale à une voie ?

2019-05-20 Thread Gwenaël Jouvin via Talk-fr 
access=yes est inutile, les routes de ces catégories sont en accès pour tout le 
monde par défaut.

Restreindre les types d’utilisateurs interdits suffit, en l’occurence les 
motorisés avec motor_vehicle=no.
On pourrait affiner en vérifiant si les cavaliers sont autorisés ou non.

Pourquoi pas pour path, ça collerait avec les dimensions.
Dans ce cas, pas besoin de la restriction d’accès qui est implicite.
Par contre, ajouter surface=asphalt voire tracktype=1 me parraissent 
intéressants pour se démarquer de l’usage « classique » de path, le chemin de 
terre.

Important aussi, indiquer la largeur maximale admissible par la barrière 
(maxwidth) et si elle est compatible avec les fauteuils roulants (wheelchair).

Gwenaël


Le 20/05/2019 à 23:30, Shohreh a écrit :
> France mailing list wrote
>> On peut ajouter motor_vehicle=no, avec éventuellement agricultural=yes si
>> les engins d’exploitation agricole sont toujours autorisés.
> 
> Dans mon dos, voici à quoi ressemble la barrière piéton/vélo (-cargo
> welcome):
> 
> https://postimg.cc/75KjDkB6
> 
> On ne dirait pas que les engins agricoles y soient les bienvenus. Première
> fois que je vois un truc de ce genre :-/
> 
> Quid de ça ?
> highway=unclassified
> access=yes, motor_vehicle=no
> 
> 
> 
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
> 
> ___
> 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] Comment tagger cette ex-départementale à une voie ?

2019-05-20 Thread Gwenaël Jouvin via Talk-fr 
On peut ajouter motor_vehicle=no, avec éventuellement agricultural=yes si les 
engins d’exploitation agricole sont toujours autorisés.
Voir la liste sur la page access :
https://wiki.openstreetmap.org/wiki/Key:access#Land-based_transportation

Un exemple de cas similaire où il a été carrément mis track, un choix qui me 
paraît discutable : la route est toujours en l’état, bitumée et large.
https://www.openstreetmap.org/way/182210028


Gwenaël


Le 20/05/2019 à 21:43, Shohreh a écrit :
> Bonjour,
> 
> Cette départementale à une voie ("Tertiary Road") est à présent fermée aux
> véhicules motorisés — une barrière se trouve en travers pour ne laisser
> passer que les piétons et les vélos :
> 
> https://postimg.cc/rRtjKshs
> 
> Comment taggeriez-vous ça ?
> 
> https://wiki.openstreetmap.org/wiki/Tag:highway%3Dpath
> 
> Merci.
> 
> 
> 
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
> 
> ___
> 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] Requête overpass pour récupérer les ponts au dessus d'une voie ferrée

2019-05-17 Thread Gwenaël Jouvin via Talk-fr 
Pour savoir si le pont est lézardé, ajouter
[disused:bridge]


je suis déjà loin…


Le 17/05/2019 à 22:10, marc marc a écrit :
> Le 17.05.19 à 21:47, mga_geo via Talk-fr a écrit :
>> - extraction des voies ferrées (railway)
>> - extraction des ponts (highway + bridge=yes)
>> puis intersection géométrique entre ces deux extractions.
> 
> tu peux imposer le critère que l'un doit être proche de l'autre
> https://wiki.openstreetmap.org/wiki/FR:Overpass_API/Overpass_QL#Autour_de_.28around:.29
> avec 0 c'est suposé être ceux qui se croise (selon le wiki :
> uniquement aux points de l'objet mais en testant, il trouve
> bien ceux qui se croise sans noeud commun)
> 
> cela donne
> [out:xml][timeout:25];
> {{geocodeArea:Rennes}}->.searchArea;
> way[railway](area.searchArea);
> way(around:0)[highway][bridge][bridge!=no];
> out geom meta;
> 
> a noter qu'il y a aussi plein de valeur différente de bridge=yes
> j'ai donc utilisé [bridge][bridge!=no]
> 
> par contre pour savoir si un lézard l'emprunte, je te laisse faire :)
> ___
> 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] Licence des Permis de construire, compatibilité OSM

2019-05-16 Thread Gwenaël Jouvin via Talk-fr 
Bonjour,

Je ne saurais préciser quel est le type de licence d’un tel document, je serais 
même choqué d’apprendre que de tels documents soient soumis au droit d’auteur.
Pour moi, comme tout document produit et publié par une administration, c’est 
dans le domaine public ?
Des éléments ici :

https://www.service-public.fr/particuliers/vosdroits/F2467

https://www.legifrance.gouv.fr/affichCodeArticle.do?idArticle=LEGIARTI33218942=LEGITEXT31366350


Gwenaël


Le 16/05/2019 à 17:35, Vincent Bergeot a écrit :
> Bonjour,
> 
> dans les échanges suivants 
> (https://www.openstreetmap.org/changeset/45891332), la question est posée de 
> la licence des permis de construire consultable en mairie.
> 
> Il me semble que la discussion a déjà eu lieu sur cette liste mais je n'ai 
> pas retrouvé. Je cherche un texte, décret, truc de loi qui valide ou invalide 
> la licence ouverte des permis de construire (je suis dubitatif).
> 
> une idée, piste ?
> 
> à plus
> 

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

Re: [OSM-talk-fr] Association du souvenir français

2019-05-13 Thread Gwenaël Jouvin via Talk-fr 
Merci pour vos réponses.

Étant donné le flou sur le gestionnaire ou le manque d’infos sur ce que j’ai pu 
voir sur le terrain, je vais laisser en l’état ;-)

Gwenaël


Le 12/05/2019 à 19:50, Yannick a écrit :
> Le 12/05/2019 à 16:30, Gwenaël Jouvin via Talk-fr a écrit :
>> Bonjour à tous,
>>
>>
>> En ce qui concerne la cartographie des monuments aux morts, certains 
>> connaissent déjà le tag ref:FR:MemorialGenWeb [1] qui permet de lier OSM à 
>> la base de Memorial Gen Web.
>>
>> Par ailleurs, il existe une association dénommée « Le souvenir français » 
>> qui, entre autres, entretien certains monuments et tombes [2].
>> J’aimerais savoir si, lorsqu’il est évident que le monument est entretenu ou 
>> a été offert par cette association (cas de certaines plaques, présence de 
>> cocardes) il serait approprié d’ajouter la combinaison :
>> "operator"="le souvenir français"
>>
>> Dans ce qui existe, je n’ai trouvé que 2 points par taginfo et sur "name" :
>> https://taginfo.openstreetmap.org/tags/name=Le%20Souvenir%20Fran%C3%A7ais
>>
>> Merci.
>>
>>
>> Gwenaël
>>
>> 1. http://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:MemorialGenWeb
>> 2. http://le-souvenir-francais.fr/lessentiel/entretenir/
> 
> Bonsoir,
> 
> Les Monuments aux Morts des communes sont entretenus par celles-ci.
> Par contre les nombreux monuments et plaques sises dans les rues et
> routes de campagne sont sous un statut très aléatoire.
> En cas que de besoin on signale à la mairie qui fait le nécessaire et
> seulement si cela ne bouge pas on avise le Souvenir Français et/ou les
> associations d'anciens combattants.
> Les carrés militaires des cimetières sont aussi dans cette mouvance où
> le SF intervient en cas de défaut de la mairie.
> Les cimetières militaires sont entretenus par l'État sous le contrôle du SF
> 
> Amitiés
> 
> 
> ___
> 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

[OSM-talk-fr] Association du souvenir français

2019-05-12 Thread Gwenaël Jouvin via Talk-fr 
Bonjour à tous,


En ce qui concerne la cartographie des monuments aux morts, certains 
connaissent déjà le tag ref:FR:MemorialGenWeb [1] qui permet de lier OSM à la 
base de Memorial Gen Web.

Par ailleurs, il existe une association dénommée « Le souvenir français » qui, 
entre autres, entretien certains monuments et tombes [2].
J’aimerais savoir si, lorsqu’il est évident que le monument est entretenu ou a 
été offert par cette association (cas de certaines plaques, présence de 
cocardes) il serait approprié d’ajouter la combinaison :
"operator"="le souvenir français"

Dans ce qui existe, je n’ai trouvé que 2 points par taginfo et sur "name" :
https://taginfo.openstreetmap.org/tags/name=Le%20Souvenir%20Fran%C3%A7ais

Merci.


Gwenaël

1. http://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:MemorialGenWeb
2. http://le-souvenir-francais.fr/lessentiel/entretenir/

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

Re: [OSM-talk-fr] Borne Michelin

2019-05-10 Thread Gwenaël Jouvin via Talk-fr 
Pour entrer dans la technique, chaque panneau ou borne fabriqués par Michelin 
est constitué de 2 éléments :
— la partie « signal » est en lave émaillée, sous la forme d’une ou plusieurs 
dalles ;
— le corps est en béton armé, le signal est surmoulé dedans ;
— après séchage, le corps est peint en blanc sur la face utile, en gris foncé 
sur la face masquée.

Selon le type de panneau, les dalles ont chacune une référence ou une date qui 
sont inscrites à l’émaillage (à main levée, pas au pochoir), avant cuisson : ça 
donne, en gros, la date de la cuisson (du moins, d’une des cuissons) au jour 
près.
Pour moi, difficile de remettre ça en cause puisqu’il y a une contrainte 
technique : l’émail est appliqué sous forme liquide.

Le corps en béton est daté à l’année près et, selon l’état du béton, bien 
souvent illisible. Ça donne la date du moulage.
De la même manière, le béton se travaille à l’échelle de l’heure, donc peu de 
doute possible.

La mise en service est indéterminable puisque ça correspond à la date de pose 
du panneau. On peut se douter que c’est dans la ou les années qui suivent sa 
fabrication, mais va savoir…


La signalisation Michelin n’a de « pierre » que le support en lave qui est 
totalement invisible sur un panneau en bon état car il est émaillé sur la face 
utile.
Sur les panneaux abîmés, on voit que la dalle fait environ 2 cm d’épaisseur.

Les bornes kilométriques en béton peint ou en pierre massive ne sont pas des 
Michelin qui, elles, on 3 faces émaillées.


Michelin était fabricant au même titre que l’était Neuhaus et d’autres sociétés 
vendeuses de signaux.
Les opérateurs étaient les gestionnaires des routes le long desquels les 
signaux étaient installés.


Gwenaël


Le 10/05/2019 à 11:08, marc marc a écrit :
> Le  8 mai 2019, Gwenaël Jouvin via Talk-fr a écrit :
>> date de fabrication et date de mise en service sont différentes
>> Dans ce genre de cas, la date de mise en service est inconnue.
> 
> ce qui me faisait réagir c'est "fabriquer une pierre" (= la formation 
> géologique), enfin bref c'est du détail.
> Mais il y a une source qui dit que la date connue n'est pas celle
> de mise en service ? j'ai du mal à croire que quelqu'un a taillé/peint
> une borne, l'ai gardé des années dans un coin pour ne l'utiliser
> que + tard. c'est en cela que je réagissais aux différents _date :
> ne pas en arriver à ce que l'un dise que c'est pas la date de mise
> en service mais celle de fabrication, un autre dira que c'est la date
> de la commande, un autre dira que c'est la date de l'inauguration...
> alors que travailler sur des éléments aussi vieux a une précision
> très relative, hormis les cas où c'est écrit sur l'élément
> (c'est ce que tu avais évoqué pour les abribus)
> 
> Le 10.05.19 à 10:42, Rpnpif a écrit :
>> Par contre, name=Ancienne borne Michelin ne convient pas 
>> car c'est plutôt une description que le nom.
> 
> ce n'est en effet pas un nom.
> mais cela mériterait sans doute d'être structuré dans un tag.
> Michelin était-il le fabriquant et/ou l'opérateur ?
> qlq chose genre manufacter=Michelin ou was:operator=Michelin
> permettrait aux passionnés de les retrouver.
> voir de leur proposer d'intégrer leur bdd 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] Borne Michelin

2019-05-08 Thread Gwenaël Jouvin via Talk-fr 
Nous en avons récemment parlé pour les boîtes aux lettres, j’ai repris ton idée 
;-)

Pour moi, date de fabrication et date de mise en service sont différentes, même 
si ça peut paraître être un faible écart 60 ans après…
Dans ce genre de cas, la date de mise en service est inconnue.


Le 08/05/2019 à 22:13, marc marc a écrit :
> Le 08.05.19 à 22:09, Gwenaël Jouvin via Talk-fr a écrit :
>> En signalisation Michelin, la plupart des panneaux d’indication de direction 
>> ont un numéro unique
>> Ça peut valoir le coup d’ajouter ça sous la clef ref ?
> 
> oui
> 
>> build_date peut également être renseigné :-)
> 
> c'est vraiment utile d'inventer un nouveau _date
> pour chaque type d'objet ?
> start_date ne fait pas l'affaire ?
> surtout que la construction d'une pierre... hum... :)
> une date de mise en service me semble plus cohérent.
> 
> Cordialement,
> Marc
> ___
> 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] Borne Michelin

2019-05-08 Thread Gwenaël Jouvin via Talk-fr 
En signalisation Michelin, la plupart des panneaux d’indication de direction 
ont un numéro unique de la forme
numéro – lettre complémentaire – département.
Par exemple, 8807c78 pour un panneau situé à Ris-Orangis… en Seine-et-Oise ;-)
Autre exemple, 9252-II-h75 pour un panneau auparavant situé dans la Seine.

Ça peut valoir le coup d’ajouter ça sous la clef ref ?


La signalisation de police (panneaux de virage, etc.), plus rare de nos jours, 
n’est, a priori, pas référencée mais juste datée et pas systématiquement.
Les plans comme ceux de l’A 6, se contentent parfois juste d’un numéro dans le 
lot, 1-2-3… selon le nombre de plans installé sur le site.

Par contre, la plupart des panneaux sont datés, donc build_date peut également 
être renseigné :-)

Les indications du coup de tampon dans le béton, quand elles sont lisibles, 
restent cryptiques, parfois la date du moulage ne colle pas avec la date de la 
plaque émaillée.


Gwenaël


Le 08/05/2019 à 21:35, Vincent de Château-Thierry a écrit :
> Bonsoir
> J'ai croisé tout récemment une plaque émaillée Michelin sur une aire de l'A6 :
> https://twitter.com/_vdct/status/1122878841956065280
> Je n'ai pas eu le réflex de la poster sur Commons, il faudra. En revanche 
> j'en ai fait un node sur OSM :
> https://www.openstreetmap.org/node/6432511885
> vincent
> 
> Le 08/05/2019, 18:12 PanierAvide  a écrit:
> 
> Bonjour, À tout hasard si tu as une photo, tu peux la mettre sur 
> Wikimédia Commons [1], et faire le lien côté OSM avec le tag 
> wikimedia_commons=* [2]. Ça fait un bon complément de la description 
> textuelle :-) Cordialement, Adrien. [1] 
> https://commons.wikimedia.org/wiki/Category:Michelin_road_signs_in_Bretagne 
> [2] https://wiki.openstreetmap.org/wiki/Key:wikimedia_commons Le 08/05/2019 à 
> 12:05, Jacques Foucry a écrit : > Bonjour, > > Il y a pas loin de ma campagne 
> une vieille borne Michelin d'indication > de direction. > > Y a-t-il un 
> intérêt à la signaler ? Si oui comment, si non je retourne me > coucher. :-) 
> > ___ 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] Borne Michelin

2019-05-08 Thread Gwenaël Jouvin via Talk-fr 
Bonjour,

Un exemple ici : https://www.openstreetmap.org/node/2286603898

Il y a une communauté assez pointue sur le sujet mais j’ai l’impression qu’elle 
n’utilise pas OSM :
https://routes.fandom.com/wiki/Cartes_de_localisation_des_Panneaux_Michelin

Personnellement, je ne les ajoute pas car ça reste de la signalisation, même 
s’il s’y rattache un côté patrimonial voire atypique.


Gwenaël


Le 08/05/2019 à 12:05, Jacques Foucry a écrit :
> Bonjour,
> 
> Il y a pas loin de ma campagne une vieille borne Michelin d'indication
> de direction.
> 
> Y a-t-il un intérêt à la signaler ? Si oui comment, si non je retourne me
> coucher. :-)
> 

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

Re: [OSM-talk-fr] Changement de réglementation

2019-04-28 Thread Gwenaël Jouvin via Talk-fr 
maxweight se met sur le segment concerné par l’interdiction, comme 
motor_vehicle :-)

Pour la valeur, on peut préciser l’unité mais sans précision, la valeur est 
considérée comme exprimée en tonnes.
C’est décrit sur la page envoyée par Yves il y a quelques minutes.

Plus généralement, sur les unités par défaut : 
https://wiki.openstreetmap.org/wiki/FR:Map_Features/Units#Unit.C3.A9s_accept.C3.A9s:_unit.C3.A9s_par_d.C3.A9faut


Gwenaël


Le 28/04/2019 à 14:36, Jacques Foucry a écrit :
> Le dimanche 28 avr. 2019 à 14:27:52 (+0200), Gwenaël Jouvin via Talk-fr à 
> écrit:
>> Bonjour,
>>
>> Merci pour les modifications.
>>
>> Sur les highways clairement routières (secondary etc.), motor_vehicle 
>> s’entend par nature, il est donc inutile.
> 
> Il semble que ce soit le défaut en effet.
>>
>> Par contre, si certaines portions ont une charge limitée, il faudra découper 
>> selon les segments correspondants (à partir du panneau) et ajouter 
>> maxweight=3.5
> 
> La route est déjà découpée en segments, tout va bien ce de coté. Mais où
> dois-je indiquer le maxweight=3.5 ? Est-il évident que le système
> métrique est bien utilisé ? (Ie n'y a t'il une façon d'indiquer que ce
> sont des tonnes dont il est question et de non de poireaux à la
> vinaigrette).
> 
>> Autre chose, il y a souvent confusion, y compris dans les services de 
>> voirie, entre les panneaux « interdit aux véhicules de transport de 
>> marchandises » qui présente un pictogramme de poids-lourd et « interdit aux 
>> véhicules de plus de 3,5 t » qui indique la masse maxi autorisée.
>> Il faut parfois interpréter car ces prescriptions n’ont rien à voir (un 
>> utilitaire léger est un transport de marchandises).
> 
> Il s'agit bien du panneau rond bordé de rouge avec l'indique 3,5T.
> 

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

Re: [OSM-talk-fr] Changement de réglementation

2019-04-28 Thread Gwenaël Jouvin via Talk-fr 
Bonjour,

Merci pour les modifications.

Sur les highways clairement routières (secondary etc.), motor_vehicle s’entend 
par nature, il est donc inutile.

Par contre, si certaines portions ont une charge limitée, il faudra découper 
selon les segments correspondants (à partir du panneau) et ajouter maxweight=3.5


Autre chose, il y a souvent confusion, y compris dans les services de voirie, 
entre les panneaux « interdit aux véhicules de transport de marchandises » qui 
présente un pictogramme de poids-lourd et « interdit aux véhicules de plus de 
3,5 t » qui indique la masse maxi autorisée.
Il faut parfois interpréter car ces prescriptions n’ont rien à voir (un 
utilitaire léger est un transport de marchandises).


Gwenaël


Le 28/04/2019 à 14:20, Jacques Foucry a écrit :
> Bonjour toutes et tous,
> 
> Dans le village de ma campagne, il y a eu un gros incendie qui a un
> impacte certain et durable sur la circulatin dans la région.
> 
> Par exemple la route principale du village est interdite aux véhicules` de
> plus de 3,5 T. Que ce ne soit pas respecté n'est pas de notre ressort,
> mais l'indiquer dans la base l'est.
> 
> Je vois dans les attributs d'un des segements « accès autorisé » avec
> les possibilités Tous/à pied/véhicule motorisé/vélos/Cavaliers.
> 
> J'ai modifié pour véhicule motorisé de yes à designated (d'après le
> tooltip, se référer à la signalisation locale).
> 
> Ais-je bien fait ?
> 
> Le groupe de modification est celui-ci :
> https://www.openstreetmap.org/changeset/69662180
> 
> Merci de vos commentaires et aides.
> 

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

Re: [OSM-talk-fr] Re: hauteur minimale de pont/tunnel

2019-04-26 Thread Gwenaël Jouvin via Talk-fr 
Par minimale, tu entends bien « hauteur maximale admissible » (maxheight=)?

Pour moi, quand il n’y a pas de panneau, c’est soit :
— un défaut de signalisation, ce qui est assez grave car quand ça coince… ça 
casse, et assez violemment :-p
— aucun besoin de signalisation car, comme sur autoroute, les ponts dépassent 
les hauteurs « communes » des véhicules.

Notons qu’en France, le code de la route ne définit pas de hauteur maximale 
autorisée pour les véhicules.

Des détails en page 3 de ce document consacré aux tunnels : 
http://www.cetu.developpement-durable.gouv.fr/IMG/pdf/CETU-Note_info_18_2009_cle718261.pdf


Pour les transports exceptionnels style charpente c’est autre chose, mais on 
s’arrange.


Gwenaël


Le 26/04/2019 à 18:46, osm.sanspourr...@spamgourmet.com a écrit :
> Et si j'ai bien compris 4,75 m sur autoroute.
> 
> https://fr.wikipedia.org/wiki/Panneau_de_signalisation_d%27une_limitation_de_hauteur_en_France
> 
> Le 26/04/2019 à 18:42, Jean-Yvon Landrac a écrit :
>>
>> Bonjour,
>>
>> Osmose couine quand un pont/tunnel n'a pas de hauteur minimale.
>>
>> D'après le code de la route un tel ouvrage doit disposer d'un panneau 
>> indiquant la limite de hauteur si celle-ci est inférieure à 4,3 m.
>>
>> S'il n'y a pas de panneau :
>> - vous prenez votre pentamètre et mesurez ;-)
>> - mettez 4,3 m. Pour les ponts standard ça doit être bon
>> - vous mettez un faux positif dans Osmose. Dommage car vous savez qu'il n'a 
>> au moins 4,3 m
>> - vous détruisez le pont, comme ça il n'y a pas de hauteur minimale ^^
>> - autre
>>
>> Jean-Yvon
>>
> 
> ___
> 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] Re: Fabricant et modèle de produit

2019-04-18 Thread Gwenaël Jouvin via Talk-fr 
Je te rejoins et sait-on jamais, ça intéressera forcément quelqu’un.
C’est à mon avis une force et un intérêt d’OSM, à l’instar d’autres projets 
libres, de n’imposer aucune limite.

Sur les boîtes aux lettres « manufacturer=Dejoie » que je relève, j’ajoute un 
manufacturer:date pour la date de fabrication, différente de la date de mise en 
service start_date.
J’utilise également un manufacturer:ref pour le numéro de série du fabricant 
lorsqu’il existe, qui n’a rien à voir avec ref, matricule attribué par la Poste.


Gwenaël


Le 18/04/2019 à 21:49, osm.sanspourr...@spamgourmet.com a écrit :
> Meilleur rendu 3D par exemple, on l'a bien sur les abris de bus.
> 
> Ça peut aussi donner la capacité : ça donne toutes les caractéristiques 
> communes à ces abris.
> 
> Le 18/04/2019 à 21:43, marc marc - marc_marc_...@hotmail.com a écrit :
>>> Modèle de produit : Ca me semble intéressant d'ajouter cette
>>> information, mais je veux bien d'autres avis.
>> je ne vois pas personnellement à quoi cela va servir.
>> mais si tu y vois un intérêt, n'hésites pas.
>>
> 
> ___
> 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] Cycleway : lane ou shoulder ?

2019-04-16 Thread Gwenaël Jouvin via Talk-fr 
Bonjour,

Les deux premiers cas ne sont pas des bandes cyclables mais des bandes dérasées 
multifonctionnelles.
Ce sont, réglementairement, des accotements.
Ces espaces en bord de chaussée permettent, en début de sortie de route, grâce 
à leur qualité de revêtement, de rattrapper une situation qui pourrait dériver 
vers un accident.

Il y a souvent confusion avec un aménagement cyclable car en zone 
inter-urbaine, les cyclistes sont « vivement encouragés » à y circuler, que ce 
soit par la densité et la vitesse de circulation des autres véhicules que par 
certains panneaux de signalisation.
Les engins agricolent peuvent également partiellement y rouler.
Du fait de leur manque d’entretien ou de leur mauvaise réalisation en matériaux 
instables, ces accotements sont souvent impraticables à vélo.

Le marquage des accotements est différent de celui des voies réservées.

Le troisième cas est signalé comme bande cyclable mais de la mauvaise manière 
puisque le marquage séparatif n’est pas du bon modèle.


Donc pour moi, les 2 premiers sont bel et bien des accotements « shoulder » et 
le troisième cas, bien que bancal, est un « cycleway=lane ».


Gwenaël


Le 16/04/2019 à 18:57, pepilepi...@ovh.fr a écrit :
> Bonjour,
> 
> Que faut-il mettre ici 
> ,
>  et là 
> 
>  ? Je suis perplexe, car ces deux là sont taggués "shoulder" alors que 
> celui-ci 
> 
>  est taggué "lane".
> 
> (/Oui, je sais. Mais j'ai pas envie de me casser les pieds à aller faire des 
> photos.../)
> 
> Respectivement https://www.openstreetmap.org/way/449039306, 
> https://www.openstreetmap.org/way/609992932 et 
> https://www.openstreetmap.org/way/188758058.
> 
> Je vois pas de grosse différence, si ce n'est que dans le 3° cas il y a par 
> ci par là quelques restes de dessins de vélo à la peinture, dessins fort 
> défraichis sur les deux autres...
> 
> Merci, bonne soirée
> 
> Jean-Pierre
> 
> -- 
> --
> 
> Si ma réponse n'a pas résolu ton problème, c'est que tu n'as pas posé la 
> bonne question
> 
> 
> 
> ___
> 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] [Paris] Remaniement des lignes de bus RATP

2019-04-14 Thread Gwenaël Jouvin via Talk-fr 
Oups, honteux que je suis de ne pas avoir vérifié la carte :-p

Bravo et merci !


Le 14/04/2019 à 22:35, marc marc a écrit :
> Le 14.04.19 à 22:32, Gwenaël Jouvin via Talk-fr a écrit :
>> Bonsoir à tous et particulièrement aux cartographes des transports en commun 
>> parisiens.
>>
>> Je vois ça : 
>> https://www.lemonde.fr/economie/article/2019/04/14/la-ratp-lance-son-big-bang-pour-ramener-les-parisiens-dans-le-bus_5449951_3234.html
>>
>> Du boulot en persepective ?
> 
> John (et d'autres) ont quasi tout fait, la discussion a eu lieu sur la 
> liste transport
> ___
> 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

[OSM-talk-fr] [Paris] Remaniement des lignes de bus RATP

2019-04-14 Thread Gwenaël Jouvin via Talk-fr 
Bonsoir à tous et particulièrement aux cartographes des transports en commun 
parisiens.

Je vois ça : 
https://www.lemonde.fr/economie/article/2019/04/14/la-ratp-lance-son-big-bang-pour-ramener-les-parisiens-dans-le-bus_5449951_3234.html

Du boulot en persepective ?

Bon courage !


Gwenaël

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

Re: [OSM-talk-fr] emergency:hydrant:puisage:bleu

2019-04-05 Thread Gwenaël Jouvin via Talk-fr 
Bonjour,

Un sujet analogue a été abordé il y a quelques temps :
https://lists.openstreetmap.org/pipermail/talk-fr/2018-October/090759.html

Il me semble qu’il y a bien des bornes de puisage, de couleur vertes, elles, 
qui sont ouvertes à tous et ne sont pas réservées aux services d’urgence contre 
les incendies.

Des références ici :
http://www.sdis17.fr/sites/sdis17/files/fichiers/rddeci.pdf
http://www.sdis17.fr/sites/sdis17/files/fichiers/fiche-01_poteaux-incendie.pdf


Gwenaël


Le 05/04/2019 à 18:44, Jacques Lavignotte a écrit :
> 
> 
> Le 05/04/2019 à 18:31, Vincent de Château-Thierry a écrit :
>> Ça se taggue fire_hydrant:pressure = suction
> 
> Bin voilà !
> 
>> vincent
> 
> Merci Vincent.
> 
> J.
> 
> Pas de photo, du coup.
> 

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

Re: [OSM-talk-fr] OSM et postgresql

2019-04-04 Thread Gwenaël Jouvin via Talk-fr 
Bonsoir,

En m’inspirant de cette méthode :
https://stackoverflow.com/a/39096027

j’ai essayé ça avec succès dans psql, sur des tables temporaires du schéma 
pg_temp_4 :
> BEGIN;
> SELECT FORMAT(
'ALTER TABLE %I RENAME TO %I',
table_name,
regexp_replace(table_name, ':', '_') )
FROM information_schema.tables
WHERE table_schema='pg_temp_4';
> \gexec
> \dt pg_temp_4.*
> COMMIT; (ou ROLLBACK si ça plante ;-) )


Gwenaël


Le 04/04/2019 à 17:30, Tony Emery via Talk-fr a écrit :
> Bonjour à tous,
> 
> J'ai une petite question technique concernant l'exploitation des clés
> OpenStreetMap dans PosgreSQL.
> Je voudrais modifier le noms des colonnes qui contiennent des ":" en les
> remplaçant par des "_", par exemple.
> 
> Et plutôt que d'avoir des "ALTER TABLE public.habillage_osm_point RENAME
> COLUMN "addr:housenumber" TO "addr_housenumber"; et faire ça pour chaque
> clé, je voudrais avoir :
> "Bon, Postgresql, à chaque fois que tu vois un ":" dans le nom d'une colonne
> de la table public.habillage_osm_point, tu le remplaces par "_" et avec le
> sourire s'il te plait".
> 
> Je suppose qu'il faut une petite fonction avec une boucle mais je ne vois
> pas bien comment la monter.
> 
> Merci d'avance,
> 
> 
> 
> -
> Tony EMERY
> Administrateur OpenStreetMap.fr
> Mandataire Grand Sud-Est
> Géomaticien & chef de projets
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
> 
> ___
> 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

[OSM-talk-fr] Feu de signalisation tramway, bus

2019-03-30 Thread Gwenaël Jouvin via Talk-fr 
Bonsoir,

Apparemment, il n’y a pas de valeur pour décrire les feux spécifiques aux 
transports en commun (types R17 et R18) que l’on peut voir sur les voies 
réservées aux bus ou le long des lignes de tramway ou le long des lignes de 
transport en commun en site propre (TCSP).

Dans le wiki, il y a bien « bus_priority », par contre il semble décrire le feu 
implanté sur les voies générales « then changes to red to allow or facilitate 
passage for the bus or tram », pas du tout le feu dédié au machiniste du 
véhicule de transport en commun.
https://wiki.openstreetmap.org/wiki/Key:traffic_signals

Rien d’autre ne ressort dans taginfo.

Des idées ?

Merci,


Gwenaël

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

Re: [OSM-talk-fr] Repères de nivellement

2019-03-29 Thread Gwenaël Jouvin via Talk-fr 
Bonjour à tous,


Je profite de ce message pour évoquer les repères de nivellement — et non les 
repères géodésiques massivement intégrés dans OSM avec la note « ne pas 
déplacer ce point ».
Les RN, qui sont extrêmement nombreux, ne servent a priori pas de référence de 
géolocalisation mais sont bien utiles pour l’altitude (par exemple calibrer un 
altimètre barométrique).

Lorsque j’en ajoute sur la carte, j’ai constaté que les coordonnées fournies 
dans leur fiche ne collait pas au terrain, j’ai donc pris le parti de les 
placer approximativement, par exemple pour que le point colle au calvaire où 
est enfiché le repère et le retrouver facilement sur le terrain.

Est-ce correct, y a-t-il des recommandations ?

https://wiki.openstreetmap.org/wiki/FR:Tag:man_made%3Dsurvey_point


Gwenaël


Le 29/03/2019 à 14:45, ades a écrit :
> Bonjour
> j’aimerais savoir comment les points de nivellement ont été placé. Quand je 
> regarde le PDF de l’IGN, les coordonnée (epsg 2154) ont une précision 
> décamétrique, ce qui ne semble pas le cas sur OSM.
> J’ai jeté un coup d’oeil sur les fichiers csv trouvés sur le wiki, pareil…
> 
> 
> ___
> 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] Code officiel géographique de l'Insee

2019-03-17 Thread Gwenaël Jouvin via Talk-fr 
Bonsoir,

À propos des noms dénués de trait(s) d’union, c’est une erreur car les mots 
composant les noms doivent être séparés par ce symbole.
Ces erreurs de dénomination devraient — lorsqu’elles existent — être corrigées.

Christian avait suggéré de mettre ces noms erronnés dans official_name : 
https://lists.openstreetmap.org/pipermail/talk-fr/2018-December/091387.html


Gwenaël


Le 17/03/2019 à 23:40, Jérôme Amagat a écrit :
> 
> L'insee a sorti son code officiel géographique pour 2019 
> https://www.insee.fr/fr/information/3720946
>  et j'ai regarder les différences avec osm.
> Sur les communes, 2 différences notables, 2 communes en moins dans osm à 
> cause de 2 communes nouvelles créées au 28 février en Côte d'Or 
> (Collonges-et-Premières et Neuilly-Crimolois). (Le cog c'est la situation au 
> 1er janvier.)
> 
> Pour les noms des communes beaucoup de petites différences avec le name=* de 
> osm. Beaucoup de problèmes de tiret "-" présent dans osm et pas dans le cog 
> sur les communes nouvelles, problème de majuscules aussi dans ces communes 
> nouvelles. et aussi des différences d'orthographe entre les locaux et l'Etat 
> :) (pas mal d'entre elles ont un tag alt_name ou official_name avec le nom 
> officiel)
> je vous mets la liste :) (dans la 2e partie c'est que des problèmes de tiret) 
> :
> 
> code INSEE    osm    cog
> 05139    Le Dévoluy    Dévoluy
> 07011    Vallées-d'Antraigues-Asperjoc    Vallées-d’Antraigues-Asperjoc
> 07084    Éclassan    Eclassan
> 08116    Bairon-et-ses-Environs    Bairon et ses environs
> 14281    Formigny-la-Bataille    Formigny La Bataille
> 16052    Bors-de-Montmoreau    Bors (Canton de Tude-et-Lavalette)
> 16053    Bors-de-Baignes    Bors (Canton de Charente-Sud)
> 16082    Boisné-la-Tude    Boisné-La Tude
> 17340    Saint-Pierre-la-Noue    Saint-Pierre-La-Noue
> 19252    Sarroux-Saint-Julien    Sarroux - Saint Julien
> 22084    Jugon-les-Lacs Commune nouvelle    Jugon-les-Lacs - Commune nouvelle
> 24269    Miallet    Mialet
> 27693    Sylvains-lès-Moulins    Sylvains-Lès-Moulins
> 28406    Eole-en-Beauce    Éole-en-Beauce
> 29021    Plounéour-Brignogan-Plages    Plounéour-Brignogan-plages
> 29158    Penmarc'h    Penmarch
> 38273    Nantes-en-Rattier    Nantes-en-Ratier
> 42031    Çaloire    Caloire
> 44066    Grandchamp-des-Fontaines    Grandchamps-des-Fontaines
> 48116    Pont-de-Montvert-Sud-Mont-Lozère    Pont de Montvert - Sud Mont 
> Lozère
> 49160    Ingrandes-le-Fresne-sur-Loire    Ingrandes-Le Fresne sur Loire
> 50090    Buais-les-Monts    Buais-Les-Monts
> 50168    Ducey-les-Chéris    Ducey-Les Chéris
> 50209    Gonneville-le-Theil    Gonneville-Le Theil
> 50431    Remilly-les-Marais    Remilly Les Marais
> 56046    Crac'h    Crach
> 56162    Plœmeur    Ploemeur
> 56262    Le Bono    Bono
> 62705    Réty    Rety
> 64166    Çaro    Caro
> 71204    Fragnes-la-Loyère    Fragnes-La Loyère
> 74049    Brison    Brizon
> 74112    Épagny-Metz-Tessy    Epagny Metz-Tessy
> 79217    Prailles-la-Couarde    Prailles-La Couarde
> 84151    Vitrolles-en-Luberon    Vitrolles-en-Lubéron
> 85008    Aubigny-les-Clouzeaux    Aubigny-Les Clouzeaux
> 85082    Les Épesses    Les Epesses
> 86265    Sossay    Sossais
> 97603    Bandrélé    Bandrele
> 97607    Dembéni    Dembeni
> 
> 01015    Arboys-en-Bugey    Arboys en Bugey
> 01130    Bresse-Vallons    Bresse Vallons
> 01185    Plateau-d'Hauteville    Plateau d'Hauteville
> 01286    Parves-et-Nattages    Parves et Nattages
> 02053    Vallées-en-Champagne    Vallées en Champagne
> 02458    Dhuys-et-Morin-en-Brie    Dhuys et Morin-en-Brie
> 04120    Val-d'Oronaye    Val d'Oronaye
> 05118    Val-Buëch-Méouge    Val Buëch-Méouge
> 08491    Vrigne-aux-Bois    Vrigne aux Bois
> 12177    Palmas-d'Aveyron    Palmas d'Aveyron
> 12224    Saint-Geniez-d'Olt-et-d'Aubrac    Saint Geniez d'Olt et d'Aubrac
> 12270    Sévérac-d'Aveyron    Sévérac d'Aveyron
> 14061    Souleuvre-en-Bocage    Souleuvre en Bocage
> 15108    Val-d'Arcomie    Val d'Arcomie
> 16175    Val-des-Vignes    Val des Vignes
> 17295    Réaux-sur-Trèfle    Réaux sur Trèfle
> 24035    Pays-de-Belvès    Pays de Belvès
> 24064    Brantôme-en-Périgord    Brantôme en Périgord
> 24376    Saint-Aulaye-Puymangou    Saint Aulaye-Puymangou
> 24490    Saint-Privat-en-Périgord    Saint Privat en Périgord
> 25424    Les Premiers-Sapins    Les Premiers Sapins
> 27105    Grand-Bourgtheroulde    Grand Bourgtheroulde
> 27191    Clef-Vallée-d'Eure    Clef Vallée d'Eure
> 27302    Le Bosc-du-Theil    Le Bosc du Theil
> 27638    Le Thuit-de-l'Oison    Le Thuit de l'Oison
> 28103    Cloyes les Trois Rivières    Cloyes-les-Trois-Rivières
> 35257    Maen-Roch    Maen Roch
> 38225    Autrans-Méaudre-en-Vercors    Autrans-Méaudre en Vercors
> 38359    Saint-Antoine l'Abbaye    Saint Antoine l'Abbaye
> 38439    Crêts-en-Belledonne    Crêts en Belledonne
> 39258    Grande-Rivière-Château    Grande-Rivière Château
> 39378    Les Trois-Châteaux    Les Trois Châteaux
> 46063   

Re: [OSM-talk-fr] Accès réservé au transport de fonds

2019-02-08 Thread Gwenaël Jouvin via Talk-fr 
À cet endroit il n’y a pas de panneau mais le marquage au sol, tracé sur 
l’ancien modèle des places de livraison (cadre jaune avec une croix de St-André 
jaune) porte le mot « sécurité ».
La proximité d’un établissement bancaire ne laisse guère de doute sur l’usage.

J’avais au départ la même idée, du style delivery=yes mais avec quelque chose 
de plus précis que la livraison générale. Rien vu sur taginfo non plus…


Le 08/02/2019 à 19:35, marc marc a écrit :
> Le 08.02.19 à 17:59, Jean-Claude Repetto a écrit :
>> Le 08/02/2019 à 17:43, Gwenaël Jouvin via Talk-fr a écrit :
>>> réservé aux véhicules de transport de fonds
> 
> qu'est-ce qui est écrit exactement sur le panneau ?
> je penche pour un access=no + access:=yes
> 
>> access=delivery me paraît convenir.
> 
> c'est pour les livraisons au sens large (y compris la camionnette du 
> magasin du coin ou la livraison fr pizza
> ___
> 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] Relations de cédez-le-passage cycliste incomplètes

2019-02-08 Thread Gwenaël Jouvin via Talk-fr 
Pour moi c’est invalide car on ne connaît pas les mouvements autorisés, qui se 
déduisent des membres from et to, les rues d’origine et d’arrivée.

Ceci dit je comprends bien le raccourci pris ici puisque ces relations sont 
vraiment pénibles à cartographier, je m’étais « amusé » à Antony, à cet endroit 
où tous les mouvements sont autorisés…
http://overpass-turbo.eu/s/FVB


Gwenaël

P.S. : peut-être que dans cette rue, le contributeur veut encore 20 000 F pour 
créer les relations…



Le 08/02/2019 à 18:51, Phyks a écrit :
> Bonjour,
> 
> Le wiki mentionne qu'une relation de cédez-le-passage cycliste (aux
> feux) devrait être une relation de type restriction, avec un membre
> from, un membre to et un membre via
> (https://wiki.openstreetmap.org/wiki/FR:Bicycle#Panonceaux_de_C.C3.A9dez-le-passage_cycliste_au_feu).
> 
> Pourtant, de nombreuses telles relations sont incomplètes avec
> uniquement un membre "via". Cela ne me semble pas très utilisable. C'est
> le cas par exemple de https://www.openstreetmap.org/relation/7507011.
> 
> Y a-t-il un sens particulier dans ce cas-ci, absent du wiki ? On
> pourrait comprendre qu'il s'agit de tous les mouvements de "tourne à
> droite" possibles, mais cela me paraît hasardeux vu qu'on voit désormais
> apparaître des panneaux "cédez le passage" pour des mouvements "va tout
> droit ou à droite", voir pour tous les mouvements possibles.
> 
> Si ces relations sont invalides, je pourrais regarder pour essayer
> d'ajouter une règle à Osmose (je ne crois pas qu'il y en ait).
> 
> Merci !
> Bonne soirée,
> 

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

[OSM-talk-fr] Accès réservé au transport de fonds

2019-02-08 Thread Gwenaël Jouvin via Talk-fr 
Bonjour,

J’aimerais indiquer qu’un emplacement de stationnement est réservé aux 
véhicules de transport de fonds, peinturlurées « sécurité » comme on en croise 
près des banques, mais je ne vois pas cette catégorie (cash transport ?) sur la 
page access :
https://wiki.openstreetmap.org/wiki/Key:access

Des idées ? Merci.

Gwenaël

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

Re: [OSM-talk-fr] Re: Moulinette pour ajouter "oneway:bicycle=no" ?

2019-02-06 Thread Gwenaël Jouvin via Talk-fr 
Pour cycleway:left, ça ne paraît effectivement pas utile puisque par défaut, on 
circule à droite en France, donc les voies en double-sens cyclable sont 
fatalement à gauche de la chaussée vu par le sens « tous véhicules » — et donc 
le sens du segment OSM, à moins de travailler en oneway=-1 !

Par contre, cycleway:right me semble utile pour représenter certains cas tordus 
de voie cyclable implantée réellement à contre-sens (c’est rare mais ça arrive, 
malheureusement) et qui correspondrait au cas M3b pour les pays où l’on circule 
à droite de la chaussée.

Dans ces cas, la précision du côté de circulation est importante puisqu’il est 
en contradiction avec le côté de circulation normal et il me semble dommage de 
ne pas l’indiquer.

La valeur de clef, elle, est à choisir parmi celles communément utilisées.


Le 06/02/2019 à 21:38, Romain MEHUT a écrit :
> Le mer. 6 févr. 2019 à 10:49, Florimond Berthoux 
> mailto:florimond.berth...@gmail.com>> a écrit :
> 
> La table est une liste d'exemples de cas, elle n'est pas limitative.
> 
> 
> Comme Antoine, j'insiste, il convient de respecter les tags documentés dans 
> le wiki et cycleway:left=opposite ne l'est pas pour le cas S1 présenté 
> initialement.
> 
> Romain
> 
> ___
> 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] Re: Moulinette pour ajouter "oneway:bicycle=no" ?

2019-02-06 Thread Gwenaël Jouvin via Talk-fr 
Attention, ce n’est pas parce que les voies ne sont pas matérialisées par du 
marquage séparatif qu’elles n’existent pas…
En l’occurrence, dans une rue à double-sens cyclable non matérialisé, il y a au 
moins deux voies de circulation, une dans chaque sens : une pour tout véhicule, 
une réservée aux cycles.

Sinon, peut-on considérer que sur une seule voie, on puisse circuler dans tous 
les sens ?
Ce serait contraire au principe de voie :

« -voie de circulation : subdivision de la chaussée ayant une largeur 
suffisante pour permettre la circulation d'une file de véhicules »

Un des problèmes, je crois, est qu’on prend toujours comme étalon la largeur 
d’une voiture, ce qui fait qu’on ne perçoit qu’une seule voie là où en prenant 
comme référence un cycle, il y en a deux.


Dans le wiki de shared_lane, on est assez loin du DSC franco-belge, on parle 
bien d’une seule voie, ouverte à tous les véhicules et dans un seul et même 
sens de circulation.
https://wiki.openstreetmap.org/wiki/Proposed_features/shared_lane

J’ai l’impression que cet attribut a été créé sur-mesure pour cartographier les 
sharrows d’amérique du nord, qui ne sont pas utilisés dans le même contexte que 
les pictogrammes tracés dans les DSC en France, même si les symboles sont 
identiques (ce qui ne facilite pas la distinction, j’en conviens).



[1] 
https://www.legifrance.gouv.fr/affichCodeArticle.do?idArticle=LEGIARTI23095873=LEGITEXT06074228



Le 06/02/2019 à 15:15, osm.sanspourr...@spamgourmet.com a écrit :
> S'il n'y pas de marquage au sol, il n'y pas séparation donc tu as une 
> différence d'accès (double sens cycliste, sens unique motorisé) mais c'est 
> bien la totalité de la voie qui y est sujette.
> 
> Toute la question est : y a-t-il dans ce cas une voie, à double sens pour les 
> cycles ou deux voies dont une réservée aux cycles.
> 
> Faute de marquage au sol autre que les picto je dirais une voie donc 
> shared_lane. Je suis donc d'accord avec Jérôme.
> 
> Jean-Yvon
> 
> Le 06/02/2019 à 14:34, Gwenaël Jouvin via Talk-fr - talk-fr@openstreetmap.org 
> a écrit :
>> En ce qui concerne les double-sens cyclables, shared_lane ne peut pas 
>> s’appliquer puisque justement, la voie est réservée aux cyclistes, elle 
>> n’est donc pas partagée.
>>
>>
>>
>> Le 06/02/2019 à 14:29, Jérôme Seigneuret a écrit :
>>> en effet si c'est q'un picto sans bande séparative c'est de la voie partagé 
>>> sans information de ségrégation  shared_lane 
>>> <https://wiki.openstreetmap.org/wiki/Tag:cycleway%3Dshared_lane>
>>>
>>> Même problème sur les trottoirs piétons avec picto uniquement
>>>
>>> Le mer. 6 févr. 2019 à 13:24, Florimond Berthoux 
>>> mailto:florimond.berth...@gmail.com>> a 
>>> écrit :
>>>
>>> Je ne pense pas que cycleway:lane puisse s'appliquer à un contre sens 
>>> cyclable avec seulement des pictos vélos au sol.
>>> Pour qu'il y ait lane il faut... une ligne, et c'est justement bien la 
>>> différence entre des pictos et une bande cyclable, les pictos ne délimite 
>>> pas de voie de circulation, une bande si.
>>>
>>> L'intérêt de cycleway:lane est de faire la distinction entre bande 
>>> interdite ou autorisé aux motorisés.
>>> Et préciser le cas d'une voie conseillé pour les vélos avec des 
>>> "sharrows" américain.
>>> Il explicite d'ailleurs que le contre sens cyclable avec picto est 
>>> différent de ces "sharrows"  :
>>> « Not to be confused with bicycle pictograms that are painted on some 
>>> one-way streets to indicate that cyclists are allowed to use the street in 
>>> contraflow direction. »
>>>
>>>
>>>
>>> Le mer. 6 févr. 2019 à 12:37, Antoine Riche via Talk-fr 
>>> mailto:talk-fr@openstreetmap.org>> a écrit :
>>>
>>> Le 06/02/2019 à 10:48, Florimond Berthoux a écrit :
>>>> Ma conclusion est que opposite est un tag fourre-tout et qu'il 
>>>> n'est pas possible de décrire l'infrastructure pictogramme vélo seul. :(
>>> Je m'excuse d'insister, mais il me semble que c'est pour cela que 
>>> la clef cycleway:lane a été ajoutée. Elle est documentée sur le wiki, je 
>>> n'ai fait que traduire de l'anglais vers le français.
>>>
>>> Antoine.
>>>
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org>
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>>
>>> -- 
>

Re: [OSM-talk-fr] Re: Moulinette pour ajouter "oneway:bicycle=no" ?

2019-02-06 Thread Gwenaël Jouvin via Talk-fr 
En ce qui concerne les double-sens cyclables, shared_lane ne peut pas 
s’appliquer puisque justement, la voie est réservée aux cyclistes, elle n’est 
donc pas partagée.



Le 06/02/2019 à 14:29, Jérôme Seigneuret a écrit :
> en effet si c'est q'un picto sans bande séparative c'est de la voie partagé 
> sans information de ségrégation  shared_lane 
> 
> 
> Même problème sur les trottoirs piétons avec picto uniquement
> 
> Le mer. 6 févr. 2019 à 13:24, Florimond Berthoux 
> mailto:florimond.berth...@gmail.com>> a écrit :
> 
> Je ne pense pas que cycleway:lane puisse s'appliquer à un contre sens 
> cyclable avec seulement des pictos vélos au sol.
> Pour qu'il y ait lane il faut... une ligne, et c'est justement bien la 
> différence entre des pictos et une bande cyclable, les pictos ne délimite pas 
> de voie de circulation, une bande si.
> 
> L'intérêt de cycleway:lane est de faire la distinction entre bande 
> interdite ou autorisé aux motorisés.
> Et préciser le cas d'une voie conseillé pour les vélos avec des 
> "sharrows" américain.
> Il explicite d'ailleurs que le contre sens cyclable avec picto est 
> différent de ces "sharrows"  :
> « Not to be confused with bicycle pictograms that are painted on some 
> one-way streets to indicate that cyclists are allowed to use the street in 
> contraflow direction. »
> 
> 
> 
> Le mer. 6 févr. 2019 à 12:37, Antoine Riche via Talk-fr 
> mailto:talk-fr@openstreetmap.org>> a écrit :
> 
> Le 06/02/2019 à 10:48, Florimond Berthoux a écrit :
>> Ma conclusion est que opposite est un tag fourre-tout et qu'il n'est 
>> pas possible de décrire l'infrastructure pictogramme vélo seul. :(
> 
> Je m'excuse d'insister, mais il me semble que c'est pour cela que la 
> clef cycleway:lane a été ajoutée. Elle est documentée sur le wiki, je n'ai 
> fait que traduire de l'anglais vers le français.
> 
> Antoine.
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> 
> -- 
> Florimond Berthoux
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> 
> -- 
> Cordialement,
> Jérôme Seigneuret
> 
> ___
> 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] Re: Moulinette pour ajouter "oneway:bicycle=no" ?

2019-02-04 Thread Gwenaël Jouvin via Talk-fr 
De la description anglophone de cycleway=lane + cycleway:lane=advisory, ça 
correspond presque point par point à la chaussée à voie centrale banalisée 
récemment apparue en France :

Points communs :
— les véhicules motorisés peuvent s’y arrêter ;
— les cyclistes peuvent y circuler, sans pour autant y être contraints.

Différences :
En France, les marquages délimitent un accotement, donc les véhicules motorisés 
ne peuvent pas y circuler, sauf contrainte majeure comme l’encombrement pour 
croiser un autre véhicule.
De même, ces accotements ne sont pas des itinéraires cyclables et ne doivent 
pas recevoir de pictogrammes « cyclistes ». Les chevrons seuls sont par contre 
autorisés [1]. Le type de marquage est une ligne de rive, pas un marquage de 
bande cyclable. Sur ces derniers points, il y a régulièrement des erreurs sur 
le terrain, par confusion avec des bandes cyclables.



[1] CÉREMA, Chaussée à voie centrale banalisée, Éléments de recommandation, 
Fiche n° 37 - Mai 2017
https://www.cerema.fr/fr/centre-ressources/boutique/velo-amenagements-recommandations-retours-experiences


Le 04/02/2019 à 09:52, Antoine Riche via Talk-fr a écrit :
> Le 03/02/2019 à 22:07, Florimond Berthoux a écrit :
>> entre rien sur la chaussée et des pictos...
>> Bref, le opposite ne permet pas décrire précisément l'infrastructure.
> Si : le tag cycleway:lane permet de préciser la matérialisation d'une bande 
> cyclable, cela inclut les pictogrammes 
> :https://wiki.openstreetmap.org/wiki/FR:Key:cycleway:lane
> 
> Cette page ne décrit pas le cas des double-sens, mais cycleway=shared_lane 
> correspond bien à cycleway=opposite (inutile donc d'inventer un 
> cycleway=opposite_shared_lne ;)  Je proposerais donc  cycleway=opposite + 
> cycleway:lane=pictogram
> 
> Bien qu'ayant traduit cette page je ne comprends pas vraiment la valeur 
> cycleway:lane=advisory. Peut-être qu'un contributeur belge pourrait nous 
> éclairer ?
> 
> Antoine.
> 
> 
> 
> ___
> 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] Re: Moulinette pour ajouter "oneway:bicycle=no" ?

2019-02-03 Thread Gwenaël Jouvin via Talk-fr 
On peut raisonnablement considérer que l’information donnée par le panneau, ou, 
plus précisément par le panonceau, est parfaitement traduite dans OSM par la 
clef oneway:bicycle=no.
Le panonceau en lui-même n’est pas un aménagement, il ne fait que traduire une 
prescription sur les règles d’accès des véhicules à la voie concernée.

La clef cycleway, elle, ne s’intéresse pas aux règles d’accès mais aux 
aménagements, qu’ils soient légers par du marquage ou lourds par une chaussée 
séparée (track).
S’il n’y a aucun aménagement, ce qui est en soi une information (et 
intéressante pour faire remarquer à une entité publique un manque à la sécurité 
des usagers), la clef cycleway=no me paraît appropriée.


Le 03/02/2019 à 21:32, Romain MEHUT a écrit :
> Un panneau ce n'est pas rien. C'est bien le sens du "et/ou".
> 
> Le dim. 3 févr. 2019 à 21:23, Florimond Berthoux 
> mailto:florimond.berth...@gmail.com>> a écrit :
> 
> Et si on suit cela on ne peut cartographier la différence entre rien et 
> des pictos, donc le tag cycleway ne répond plus à son rôle premier de décrire 
> l'infrastructure, donc la version française est mauvaise.
> 
> 
> ___
> 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] Moulinette pour ajouter "oneway:bicycle=no" ?

2019-02-02 Thread Gwenaël Jouvin via Talk-fr 
Il y a 2 autres catégories que l’on peut distinguer et qui, si j’ai bien 
compris, sont décrites comme ceci selon Florimond :
— pas de voie matérialisée mais pictogrammes au sol : cycleway=opposite
les pictogrammes pouvant être le modèle « cycliste », ou « cycliste + 
flèche » ou encore « cycliste + chevrons » ;
— pas de voie matérialisée ni aucun autre marquage au sol : cycleway=no.


Le 02/02/2019 à 17:41, Thomas Ruchin a écrit :
> Le "sens interdit sauf vélo" et pas d'aménagement type piste/bande cyclable, 
> c'est ce qui se tague cycleway=opposite.
> Là, on a deux manières de taguer la même chose (y avait eu un débat similaire 
> sur les piscines...)
> Je pense que la rue de Charenton n'est pas bien taguée.
> 
> Thomas
> 
> Le sam. 2 févr. 2019 à 17:05, Gwenaël Jouvin via Talk-fr 
> mailto:talk-fr@openstreetmap.org>> a écrit :
> 
> Merci pour ces précisions intéressantes, surtout celle sur le cycleway=no.
> 
> Il n’est en effet pas rare de voir des rues qui sont bien à double-sens 
> dont un réservé aux cycles (signalés par un des panonceaux « sauf… » de type 
> M9v, mais où il n’y a aucun marquage au sol.
> C’est d’ailleurs réglementaire, le marquage au sol étant facultatif.
> 
> Je vais avoir des rues à corriger…
> 
> 
> Le 02/02/2019 à 16:44, Florimond Berthoux a écrit :
> > Bonjour,
> >
> > Bonne question. Tout d'abord pourquoi il faut les deux tags ?
> > Ce n'est pas un doublon d'information car les deux tags n'ont pas la 
> même signification,
> > Le oneway est un tag d'accès il définit le droit ou non à rouler dans 
> un sens.
> > Le cycleway définit l'infrastructure, c'est à dire l'aménagement 
> physique mis en place sur la route piste, bande, rien, picto, etc.
> > Concrètement il est possible (malheureusement) d'avoir des rue avec 
> l'un mais pas l'autre.
> > Exemple:
> > Rue de Charenton à Paris a un bout avec un panneau sens interdit "sauf 
> vélo" mais aucune infrastructure : oneway:bicycle=no, cycleway=no
> > https://www.openstreetmap.org/way/172644796
> > L'inverse est possible une infrastructure (des pictos vélo par 
> exemples) mais pas de panneauçon sauf vélo.
> > Vous pouvez aussi imaginer le cas d'une piste cyclable fermée le temps 
> de long travaux.
> >
> > Pour répondre à T. Ruchin, non ce n'est pas comme si on mettait 
> access=yes, on ne parle pas de mettre la valeur par défaut ici.
> > Le problème est d'inférer la valeur d'un tag à partir d'un autre tag.
> > Pratique que je trouve mal saine pour la qualité des données et la 
> facilité de traitement des celles-ci.
> > Un routeur basique pour vélo ne devrait regarder que le oneway:bicycle 
> au lieu devoir lire la doc, l'interpréter et de traiter 3×3 cas possibles.
> > Ça peut être à l'outil (ie au développeur) à s'adapter aux données, ou 
> alors le développeur ira voir ailleurs si les données sont de meilleurs 
> qualités et plus facilement traitables.
> >
> > Voilà, donc ma règle et d'ajouter oneway:bicycle=yes, et de préciser 
> l'infrastructure.
> > En considérant que opposite signifie des pictos vélo.
> >
> > Pour revenir à la question initiale, je dirais qu'il faudrait éviter un 
> traitement systématique du fait des explications susmentionnés, le opposite 
> n'impliquant pas le oneway:bicycle=no.
> > C'est presque toujours le cas mais pas toujours.
> >
> > Cordialement.
> >
> > Le ven. 1 févr. 2019 à 14:47, Gwenaël Jouvin via Talk-fr 
> mailto:talk-fr@openstreetmap.org> 
> <mailto:talk-fr@openstreetmap.org <mailto:talk-fr@openstreetmap.org>>> a 
> écrit :
> >
> >     Bonjour,
> >
> >     En effet Thomas, il y a probablement, à l’origine, une histoire de 
> compatibilité et de doublon.
> >
> >     Une page du Wiki décrivait très bien le problème, mais elle a été 
> modifiée depuis [1]. Voici le texte qui me servait de référence à l’époque :
> >     « Oneway can be used in conjunction with vehicle type in order to 
> tag exceptions. I.e. oneway:moped=no for a one-way streets where mopeds are 
> allowed to drive in the opposite direction. Bicycles (oneway:bicycle=no) are 
> handled specially and  cycleway=opposite/opposite_lane/opposite_track needs 
> to be added for compatibility: (See Key:access for sub-values or Bicycle for 
> examples). »
> >
> >     Pour ma part, j’avais découvert la « nécessité » de 
> cycleway=opposite car le rendu OCM n’affichait pas les double-sens cyclables 
> qui n’avaient pas cet attribut.
>

Re: [OSM-talk-fr] Moulinette pour ajouter "oneway:bicycle=no" ?

2019-02-02 Thread Gwenaël Jouvin via Talk-fr 
Merci pour ces précisions intéressantes, surtout celle sur le cycleway=no.

Il n’est en effet pas rare de voir des rues qui sont bien à double-sens dont un 
réservé aux cycles (signalés par un des panonceaux « sauf… » de type M9v, mais 
où il n’y a aucun marquage au sol.
C’est d’ailleurs réglementaire, le marquage au sol étant facultatif.

Je vais avoir des rues à corriger…


Le 02/02/2019 à 16:44, Florimond Berthoux a écrit :
> Bonjour,
> 
> Bonne question. Tout d'abord pourquoi il faut les deux tags ?
> Ce n'est pas un doublon d'information car les deux tags n'ont pas la même 
> signification,
> Le oneway est un tag d'accès il définit le droit ou non à rouler dans un sens.
> Le cycleway définit l'infrastructure, c'est à dire l'aménagement physique mis 
> en place sur la route piste, bande, rien, picto, etc.
> Concrètement il est possible (malheureusement) d'avoir des rue avec l'un mais 
> pas l'autre.
> Exemple:
> Rue de Charenton à Paris a un bout avec un panneau sens interdit "sauf vélo" 
> mais aucune infrastructure : oneway:bicycle=no, cycleway=no
> https://www.openstreetmap.org/way/172644796
> L'inverse est possible une infrastructure (des pictos vélo par exemples) mais 
> pas de panneauçon sauf vélo.
> Vous pouvez aussi imaginer le cas d'une piste cyclable fermée le temps de 
> long travaux.
> 
> Pour répondre à T. Ruchin, non ce n'est pas comme si on mettait access=yes, 
> on ne parle pas de mettre la valeur par défaut ici.
> Le problème est d'inférer la valeur d'un tag à partir d'un autre tag.
> Pratique que je trouve mal saine pour la qualité des données et la facilité 
> de traitement des celles-ci.
> Un routeur basique pour vélo ne devrait regarder que le oneway:bicycle au 
> lieu devoir lire la doc, l'interpréter et de traiter 3×3 cas possibles.
> Ça peut être à l'outil (ie au développeur) à s'adapter aux données, ou alors 
> le développeur ira voir ailleurs si les données sont de meilleurs qualités et 
> plus facilement traitables.
> 
> Voilà, donc ma règle et d'ajouter oneway:bicycle=yes, et de préciser 
> l'infrastructure.
> En considérant que opposite signifie des pictos vélo.
> 
> Pour revenir à la question initiale, je dirais qu'il faudrait éviter un 
> traitement systématique du fait des explications susmentionnés, le opposite 
> n'impliquant pas le oneway:bicycle=no.
> C'est presque toujours le cas mais pas toujours.
> 
> Cordialement.
> 
> Le ven. 1 févr. 2019 à 14:47, Gwenaël Jouvin via Talk-fr 
> mailto:talk-fr@openstreetmap.org>> a écrit :
> 
> Bonjour,
> 
> En effet Thomas, il y a probablement, à l’origine, une histoire de 
> compatibilité et de doublon.
> 
> Une page du Wiki décrivait très bien le problème, mais elle a été 
> modifiée depuis [1]. Voici le texte qui me servait de référence à l’époque :
> « Oneway can be used in conjunction with vehicle type in order to tag 
> exceptions. I.e. oneway:moped=no for a one-way streets where mopeds are 
> allowed to drive in the opposite direction. Bicycles (oneway:bicycle=no) are 
> handled specially and  cycleway=opposite/opposite_lane/opposite_track needs 
> to be added for compatibility: (See Key:access for sub-values or Bicycle for 
> examples). »
> 
> Pour ma part, j’avais découvert la « nécessité » de cycleway=opposite car 
> le rendu OCM n’affichait pas les double-sens cyclables qui n’avaient pas cet 
> attribut.
> 
> 
> Gwenaël
> 
> [1] 
> https://wiki.openstreetmap.org/w/index.php?title=Key:oneway=1576104=1576102
> 
> 
> Le 01/02/2019 à 13:47, Thomas Ruchin a écrit :
> > Je pense que c'est du doublon d'information qui n'apporte pas grand 
> chose et qui est difficile à maintenir. Je ne sais pas quelle est la 
> discussion qui a conduit à cette rédaction du wiki.
> > C'est comme si le wiki recommandait d'ajouter access=yes sur les routes 
> qui n'ont pas de restriction particulières d'accès.*
> > Par contre, rechercher à mieux caractériser les voies sur lequel est 
> présent le oneway:bicycle=non sans plus de détail sur l'aménagement cyclable 
> serait intéressant.
> >
> > Thomas
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> 
> -- 
> Florimond Berthoux
> 
> ___
> 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] Moulinette pour ajouter "oneway:bicycle=no" ?

2019-02-01 Thread Gwenaël Jouvin via Talk-fr 
Bonjour,

En effet Thomas, il y a probablement, à l’origine, une histoire de 
compatibilité et de doublon.

Une page du Wiki décrivait très bien le problème, mais elle a été modifiée 
depuis [1]. Voici le texte qui me servait de référence à l’époque :
« Oneway can be used in conjunction with vehicle type in order to tag 
exceptions. I.e. oneway:moped=no for a one-way streets where mopeds are allowed 
to drive in the opposite direction. Bicycles (oneway:bicycle=no) are handled 
specially and  cycleway=opposite/opposite_lane/opposite_track needs to be added 
for compatibility: (See Key:access for sub-values or Bicycle for examples). »

Pour ma part, j’avais découvert la « nécessité » de cycleway=opposite car le 
rendu OCM n’affichait pas les double-sens cyclables qui n’avaient pas cet 
attribut.


Gwenaël

[1] 
https://wiki.openstreetmap.org/w/index.php?title=Key:oneway=1576104=1576102


Le 01/02/2019 à 13:47, Thomas Ruchin a écrit :
> Je pense que c'est du doublon d'information qui n'apporte pas grand chose et 
> qui est difficile à maintenir. Je ne sais pas quelle est la discussion qui a 
> conduit à cette rédaction du wiki.
> C'est comme si le wiki recommandait d'ajouter access=yes sur les routes qui 
> n'ont pas de restriction particulières d'accès.*
> Par contre, rechercher à mieux caractériser les voies sur lequel est présent 
> le oneway:bicycle=non sans plus de détail sur l'aménagement cyclable serait 
> intéressant.
> 
> Thomas

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

Re: [OSM-talk-fr] Origine des données Waze

2019-01-21 Thread Gwenaël Jouvin via Talk-fr 
Bonsoir,

Je fais une petite digression sur les « œufs de pâques », à mon avis il n’est 
pas acceptable de placer de fausses informations dans OSM puisque d’après ce 
que j’ai compris (ou comme je vois ce projet ;-) ), OSM se doit d’être la plus 
exacte possible, justement pour se démarquer des cartes commerciales ou 
privatives qui regorgent de ces pièges contre la contrefaçon.

Par contre j’aime beaucoup l’idée de placer des chemins privés, il y en existe 
d’ailleurs déjà et ce sont des informations pertinentes afin de s’assurer que 
tel ou tel trajet est réalisable ou non.

Gwenaël


Le 21/01/2019 à 12:07, osm.sanspourr...@spamgourmet.com a écrit :
> Je pense qu'on devrait mettre (plus) d’œufs de Pâques dans OpenStreetMap.
> 
> C'est-à-dire ajouter des informations qui ne sont pas ailleurs.
> 
> Soit des informations qui manquent réellement mais il faut prendre quelque 
> chose qui ne soit pas dans des données libres comme le cadastre soit (mieux 
> ?) des informations fausses comme l'ajout d'un nom à une rue sans nom et 
> suffisamment mineure pour que ça ne gène pas. Ou ajouter des chemins privés 
> (avec les gate et autres barrier qui sont bien) afin de voir si nos 
> informations diffusent.
> 
> Ajouter un chemin comme Glyo l'a fait c'est bien mais a priori quelqu'un 
> d'autre peut l'avoir fait. Ajouter une branche sans intérêt en cul de sac ne 
> devrait pas gêner grand monde et si ça gène un cartographe amateur nettoiera 
> ou un utilisateur lambda laissera une note. Et un utilisateur bêta pestera 
> ;-).
> 
> Jean-Yvon
> 
> Le 21/01/2019 à 11:33, Vincent Bergeot - vinc...@bergeot.org a écrit :
>> Le 20/01/2019 à 22:13, deuzeffe a écrit :
>>> Et j'ai été très surprise d'y trouver des objets que j'ai récemment ou pas 
>>> (plus ou moins mal) mapés comme des parkings, des chemins piétons, des 
>>> landuse de forme bizarre, etc., bref des trucs pour lesquels, sans verser 
>>> dans la paranoïa ou le complexe de supériorité, j'ai l'intime conviction 
>>> qu'ils proviennent d'osm (ou de quelqu'un qui waze dans mon coin en étant 
>>> très précis - et ce n'est pas moi ^^).
>>
>> Bonjour,
>>
>> je partage ton sentiment et je suis allé voir dans des coins perdus !!!
>>
>> Et là je n'ai plus beaucoup de doutes, ceux sont les mêmes données (j'ai 
>> regardé à plusieurs endroits et on retrouve plusieurs cas similaires comme 
>> ci-dessous)
>>
>>   * https://www.openstreetmap.org/way/200440664#map=13/-12.2717/49.3513
>>   * 
>> https://www.waze.com/ul?ll=-12.27710852%2C49.34886932=yes=14 
>> (c'est au milieu de l'eau le fond de carte ne doit pas être bien calé)
>>
>> Donc sans verser non plus dans la paranoïa, c'est la même personne qui a 
>> contribué aux 2 sites dans ce cas ?
>>
>> Mon autre interrogation c'est : certaines données sont dans le domaine 
>> public (si acceptation de les verser dans le domaine public lors de la 
>> création d'un compte). Peut-on "isoler" ces données ?
>>
>> à plus
>>
>>
>> -- 
>> Vincent Bergeot
>>
>> ___
>> 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