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

[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 ?

[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 ?

[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 ?

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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 ?

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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" ?

[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" ?

[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" ?

[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" ?

[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" ?

[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" ?

[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" ?

[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" ?

[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

[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

Re: [OSM-talk-fr] Vitesses maximales autorisées sur route

[Gwenaël Jouvin]

Merci pour vos réponses.

J’ai mis à jour la valeur correspondante.


Le 09/01/2019 à 17:50, Christian Quest a écrit :
> Le 09/01/2019 à 12:28, marc marc a écrit :
>> Le 09.01.19 à 12:23, Gwenaël Jouvin a écrit :
>>> question plus générale, comment fonctionne cette relation
>> a ma connaissance aucun outil "important" ne l'utilise et aucune le dit
>> le faire dans taginfo :
>> https://taginfo.openstreetmap.org/relations/defaults#projects
>>
>> chaque routeur fait sa propre roue pour trouver les bonnes valeurs
>> (certains analyse la page du wiki, d'autres doivent sûrement avoir qlq
>> qui le fait à la main).
>>
>> L'idée est bonne mais il manque la finition.
> 
> 
> Ceci n'empêche pas de mettre à jour le contenu... même si il est peu exploité 
> ;)
> 

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

[OSM-talk-fr] Vitesses maximales autorisées sur route

[Gwenaël Jouvin]

Bonjour,

Au détour du wiki, je découvre la relation précisant les diverses limitations 
de vitesse en vigueur en France : https://www.openstreetmap.org/relation/934933
Je crois donc comprendre que ces valeurs étant définies par défaut, il n’est 
pas utile de préciser maxspeed ni maxspeed:type lorsque la limitation 
correspond à ces valeurs par défaut.

— on remarque cependant que Fr:rural est toujours fixé à 90 km/h, ne 
faudrait-il pas la mettre à jour étant donné que la proportion de routes 
restant à 90 km/h devient minoritaire* ?

— question plus générale, comment fonctionne cette relation, est-elle prise en 
compte par les applications lorsque l’on met un tag maxspeed=FR:urban ?


Gwenaël


* Décret 2018-487 abaissant la V.M.A à 80 km/h sur les routes bidirectionnelles 
: https://www.legifrance.gouv.fr/jo_pdf.do?id=JORFTEXT37076517

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

Re: [OSM-talk-fr] Fusion de communes... LE chantier annuel ;)

[Gwenaël Jouvin]

Merci pour ce boulot.

Pour ma part, j’aurai 2 communes (simples) à vérifier dans ma zone :-)


Par contre je constate avec agacement que les règles d’écriture des toponymes 
n’est toujours pas correctement appliquée ni par les conseillers municipaux, ni 
par les préfets…
Exemples : Bresse Vallons (01), Porte des Pierres Dorées (69).

C’est pourtant pas faute de leur rappeler :
http://www.maire-info.com/upload/files/Circulaire_nom_communes_nouvelles.pdf


Doit-on, par cohérence avec les documents réglementaires, restituer ces fautes 
dans OSM ?



Le 29/12/2018 à 14:52, Christian Quest a écrit :
> Comme chaque fin d'année, c'est le chantier des fusions qui s'ouvre ;)
> 
> 608 communes fusionnent en 232 communes nouvelles d'après wikipédia:
> 
> https://fr.wikipedia.org/wiki/Liste_des_communes_nouvelles_cr%C3%A9%C3%A9es_en_2019
> 
> J'ai donc ressorti mes scripts de mise à jour, car faire tout ça à la main 
> sans erreur c'est assez chaud !
> 
> Première étape, récupérer les données du tableau wikipédia: c'est fait, j'ai 
> un json prêt à consommer.
> 
> Deuxième étape: appliquer les modifications... je suis en train de tester.
> 
> C'est complexe car certaines communes nouvelles ont déjà été créées, et il ne 
> faut pas se mélanger avec le cas de communes nouvelles créées ces dernières 
> années qui absorbent encore quelques communes.
> 
> Troisième étape: vérification... là un peu d'humain sera bien utile, donc si 
> ça vous intéresse, ce fil de discussion est là pour ça !
> 
> Je compte appliquer les modifications aujourd'hui et demain pour laisser le 
> 31 et le 1er pour faire les vérifications et corrections.
> 
> -- 
> Christian Quest - OpenStreetMap France
> 
> ___
> 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: Places PMR ?

[Gwenaël Jouvin]

Ne faudrait-il pas également tenir compte de disabled ?
Par exemple, acces=no + disabled=yes


Le 28/11/2018 à 14:53, Jérôme Seigneuret a écrit :
> tu peux ajouter designated
> 
> amenity=parking_space + wheelchair=yes/only/designated
> 
> Bonne journée 
> 
> Le mer. 28 nov. 2018 à 14:43, Christian Quest  > a écrit :
> 
> Bonjour Hélène,
> 
> Voici une requête overpass qui permet de facilement visualiser ces places:
> 
> https://overpass-turbo.eu/s/E5t
> 
> On voit via overpass que sur Paris, une partie des arrondissements a été
> importée, mais pas tous: https://overpass-turbo.eu/s/E5v
> 
> Elle prend en compte:
> 
> - amenity=parking_space + wheelchair=yes/only
> 
> - amenity=parking/parking_space + capacity:disabled=1..9
> 
> 
> Sur le rendu FR ces tags sont en principe rendus, mais bien sûr le
> placement d'objets faits que l'icône peut être masquée par autre chose
> et elle n'est pas forcément non plus très mise en avant...
> 
> Exemple:
> 
> https://tile.openstreetmap.fr/?zoom=20=48.80492=2.48482=B00FF
> 
> 
> 
> Le 28/11/2018 à 11:23, Hélène PETIT a écrit :
> > Bonjour à tous !
> > Je suis désormais confrontée à la nécessité de localiser une place pmr
> > avant d'entreprendre de me déplacer en voiture.
> >
> > J'ai relu un certain nombre de pages du wiki, mais la question du
> > rendu est peu abordée.
> >
> > Quels sont les fonds de carte qui font apparaître ces données :
> > 
> https://www.data.gouv.fr/fr/reuses/integration-des-donnees-dans-openstreetmap-et-visualisation-stationnement-pmr/
> >
> >
> > Merci !
> >
> >
> > Le 18/03/2018 à 19:39, PanierAvide a écrit :
> >> Bonjour,
> >>
> >> En lisant le wiki, je me rends compte que pour décrire les places de
> >> parking individuelles (amenity=parking_space), on est pas sensé
> >> pouvoir utiliser les variantes de capacity:*=* [1], mais plutôt
> >> restreindre avec des critères d'accessibilité plus classiques.
> >>
> >> En ce qui concerne les places PMR, j'ai pour habitude de renseigner
> >> un combo amenity=parking_space + capacity:disabled=1 + wheelchair=yes
> >> (si la place est vraiment accessible, ce qui n'est pas toujours le
> >> cas). J'ai cru comprendre qu'il y avait aussi possibilité d'utiliser
> >> parking_space=disabled.
> >>
> >> Ma question est la suivante : quelle est donc la bonne pratique sur
> >> la question des places PMR ? Car ça vaudrait le coup de s'accorder et
> >> de l'expliciter sur le wiki :-)
> >>
> >> Cordialement,
> >>
> >> Adrien.
> >>
> >> [1] https://wiki.openstreetmap.org/wiki/FR:Tag:amenity%3Dparking_space
> >>
> >
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org 
> > https://lists.openstreetmap.org/listinfo/talk-fr
> 
> -- 
> Christian Quest - OpenStreetMap France
> 
> 
> ___
> 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] Multipolygones, zone de rencontre et rendu

[Gwenaël Jouvin]

Merci pour vos réponses.

Je n’avais pas pensé que passer l’espace en pedestrian conviendrait mais comme 
le dit Christian, ça se tient puisque les chaussées existent toujours.
Ce qui m’a trompé est que sur cette place, soit il n’y a jamais eu de trottoirs 
(côté historique), soit ils ont été supprimés (côté moderne rénové).

Pour le polygone du parc, effectivement il n’y a pas d’emprise nette et ce 
n’est pas un endroit intégralement dédié au stationnement comme pourrait l’être 
un parc de supermarché et si les attributs seraient un peu plus complexes, la 
représentation reste possible avec un mélange de 
parking:lane:right:perpendicular, etc.


Gwenaël


Le 26/11/2018 à 14:31, deuzeffe a écrit :
> Le 26/11/2018 à 10:50, Rpnpif a écrit :
>> Bonjour,
>>
>> C'est vrai que le rendu osm-fr est souvent meilleur. Merci Christian.
>> Comment inciter les gens qui s'occupent de celui d'osm.org à le
>> modifier ?
> 
> En demandant ici : https://github.com/gravitystorm/openstreetmap-carto/issues 
> après avoir vérifié qu'il n'y avait pas d'autre demande du même style ?
> 

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

Re: [OSM-talk-fr] Les voies vertes

[Gwenaël Jouvin]

Bonjour,

Les graphismes de ces panneaux (B 52 et C 115) sont trompeurs et ne reflètent 
pas véritablement la réglementation.

S’il y a en effet une différence de dimension entre les pictogrammes, en zone 
de rencontre le piéton est prioritaire sur tous les véhicules. Il peut se 
déplacer librement sur la chaussée mais doit veiller à ne pas faire entrave à 
la circulation.
En zone de rencontre, contrairement à ce que suggère le signal et à ce qui 
prétendent certaines « références » (y compris en association de cyclistes !), 
le cycliste ne bénéficie d’aucune priorité particulière sur les autres 
conducteurs.

Sur une voie verte c’est un peu plus flou car si c’est bien une route, elle est 
tout de même dédiée aux piétons.
Sur une route normale, le piéton peut marcher sur la chaussée *par exception*. 
Je crois que sur une voie verte, ce caractère exceptionnel n’a plus lieu d’être.

Les définitions de ces concepts sont à retrouver à l’article R. 110-2 du code :
https://www.legifrance.gouv.fr/affichCodeArticle.do?idArticle=LEGIARTI23095873=LEGITEXT06074228

Méfiez-vous des sites gouvernementaux type sécurité-routière ou service-public, 
ils sont pleins d’approximations. Le seul avantage est d’y retrouver les 
articles de référence.

Gwenaël


Le 28/11/2018 à 09:19, Pierre L. a écrit :
> Bonjour,
> 
> Le 27/11/2018 à 20:04, Axelos a écrit :
>> Dans cette logique, je rappelle juste que la voie verte est considéré
>> comme étant une route et non pas un chemin d’après le code de la route,
>> et que les cyclistes, en plus de tenir leurs droites doivent laisser la
>> priorité aux piétons. On y retrouve le même concept que les zones de
>> rencontres, à la seule différence de l’absence de véhicules motorisées.
> Si justement on se base sur le concept des zones de rencontres, il y a
> un code visuel qui montre de manière explicite "un piéton (adulte ou
> enfant), en premier plan, puis un cycliste et un conducteur dans sa
> voiture qui les laisse passer vise à montrer clairement la priorité
> piétonne dans l’idée de partage de la voirie à vitesse réduite."
> Page 6 du pdf :
> http://www.securite-routiere.gouv.fr/content/download/3189/28063/version/1/file/guide_techn_fiche3_technique_zone_rencontre_cle0262fe.pdf
> disponible depuis cette page :
> http://www.securite-routiere.gouv.fr/connaitre-les-regles/la-route-la-rue/le-code-de-la-rue2
> 
> En se basant sur ce fait, on voit sur le panneau de la "voie verte" un
> cycliste en premier plan, on pourrait comprendre à la priorité du vélo
> sur le piéton.
>> S'il faut choisir cycleway ou footway pour représenter toutes voies
>> vertes, ce serait footway qui devrait être privilégié.
> Vu le cycliste représenté au premier plan, cycleway donc... ;)
> 
> Cependant, je n'ai pas réussi à mettre la main sur un texte qui
> stipulerait que ce soit l'un ou l'autre (piéton/vélo) qui soit
> "prioritaire" sur ces voies vertes. En testant le site
> www.legifrance.gouv.fr, je trouve que c'est un bordel sans nom pour
> chercher une info...
> 
> Un petit mot cependant par ici...
> https://af3v.org/-Code-du-bon-usage-des-voies-vertes-.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] Les voies vertes

[Gwenaël Jouvin]

La voie verte est définie dans l’article R. 110-2 du Code de la route, sans « 
hiérarchie » parmi les utilisateurs :

-voie verte : route exclusivement réservée à la circulation des véhicules non 
motorisés, des piétons et des cavaliers ;
https://www.legifrance.gouv.fr/affichCodeArticle.do?idArticle=LEGIARTI23095873=LEGITEXT06074228


Une voie verte est signalée par le panneau C 115.
http://routes.wikia.com/wiki/Panneau_de_type_C115

La fin de voie verte est signalée par le panneau C 116.

Remarquons que l’accès aux cavaliers est conditionné au montage du panonceau 
M4y :
http://routes.wikia.com/wiki/Liste_des_panonceaux_routiers_fran%C3%A7ais

IISR 5, art. 75.1 :
[…] Si l’autorité de police compétente n'interdit pas la circulation des 
cavaliers sur ces voies, le panneau C115 est complété par le panonceau M4y 
désignant les cavaliers. […]
http://www.equipementsdelaroute.equipement.gouv.fr/IMG/pdf/IISR_5ePARTIE_VC_20160215_cle2135a7.pdf

Cette dernière disposition est donc un peu contradictoire avec le principe 
général de voie réservée aux cavaliers.


Sur le terrain, les voies vertes sont très flous, d’une part parce que dans la 
com’, on appelle tout et n’importe quoi « vert » pour faire bien, mais aussi 
parce que des services n’hésitent pas à créer des voies vertes « fourre-tout », 
par exemple sur des trottoirs…


Gwenaël



Le 27/11/2018 à 14:11, jabali a écrit :
> Pierre L. wrote
>> La première représente une voie verte, destinées aux vélos,
>> autorisée aux piétons...
> 
> Sans vouloir chipoter il y a un arrêté qui stipule que c'est destiné
> initialement aux vélos mais aussi autorisés aux pietons?
> 
> […]
> 
> --
> 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] Multipolygones, zone de rencontre et rendu

[Gwenaël Jouvin]

Bonsoir,

J’ai cherché à modéliser plus fidèlement une place classée en zone de rencontre.
Pour ça, j’ai créé une zone « area » selon les limites visibles sur place 
(bitume coloré).

Étant donné qu’il y a des places de stationnement dans l’emprise et connaissant 
le problème de rendu des area 
(https://forum.openstreetmap.org/viewtopic.php?id=7590), j’ai créé un 
multipolygone :
https://www.openstreetmap.org/relation/9044886

Problème : malgré le multipolygone, le stationnement et les rues laissées pour 
le routage n’apparaîssent pas.

Soupçonnant un problème de rendu, j’ai temporairement remplacé living_street 
par pedestrian et, comme vous pourrez le voir sur la gauche de l’image à 
l’adresse ci-dessous, tout s’affiche correctement.
http://pix.toile-libre.org/?img=1543097960.png

Le rendu FR, lui, fonctionne correctement :
http://tile.openstreetmap.fr/?zoom=19=48.68628=-1.36001=B00FF
Contrairement au rendu OSM « standard » :
http://tile.openstreetmap.fr/?zoom=19=48.68628=-1.36001=00BFF

Dans JOSM j’ai constaté que lorsque l’on a highway=pedestrian, les contours du 
multipolygones sont renforcés par un contour translucide le long des frontières 
outer et inner.
Ce contour disparaît si l’on met autre chose que pedestrian.

Tout donne l’impression qu’il n’a pas été prévu d’avoir des multipolygones avec 
« highway » autrement qu’en « pedestrian ». Est-ce volontaire ?
Faudrait-il y remédier en « trichant » sans passer par un multipolygone, par 
exemple avec un chemin qui contournerait tous les objets (bonjour la complexité 
!) ?


Gwenaël

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

[OSM-talk-fr] Open data public, bases de données perso

[Gwenaël Jouvin]

Bonsoir à tous,

Comme nous le montre le projet du mois de novembre avec l’intégration des 
brigades de gendarmerie, la profusion de données publiques est parfois 
difficile à surmonter.
Le mode de diffusion en texte de fichiers parfois volumineux comme le registre 
des établissements sanitaires & sociaux FINESS fait qu’ils sont peu utilisables 
en l’état.
https://www.data.gouv.fr/

Pour ma part, je me suis fait quelques bases de données sous PostgreSQL pour 
certains fichiers comme le code officiel géographique de l’INSÉÉ, le fichier 
des boîtes aux lettres de la Poste, FINESS… afin de trouver l’info rapidement 
et avoir un format de sortie adapté à mes besoins.


J’aimerais savoir comment vous utilisez ces fichiers, sous quelle forme, à 
quelle sauce vous les rendez digestes…
… et si vous aussi vous râlez quand ils ne sont pas en UTF-8 :-)

Merci,


Gwenaël

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

Re: [OSM-talk-fr] Comment tagguer une demi-barrière ?

[Gwenaël Jouvin]

Bonsoir,

L’état actuel des tags ne me paraît pas du tout inapproprié, la voie est bien 
libre pour les piétons et les cyclises, étant donné que le chemin concerné est 
une voie verte (ici interdite aux cavaliers faute de panonceau M4y).

J’irai même jusqu’à dire qu’y mettre barrier=cycle_barrier, dans ce contexte, 
n’est pas si incohérent que ça.
https://wiki.openstreetmap.org/wiki/Tag%3Abarrier%3Dcycle_barrier

La largeur avec width ou maxwidth est une information très utile pour ceux qui 
souhaitent utiliser la voie verte avec des vélos plus larges que ce qu’on 
considère comme étant la « normale » : vélos couchés, tricycles, cargos.


Gwenaël


Le 11/11/2018 à 19:04, pepilepi...@ovh.fr a écrit :
> Bonsoir,
> 
> Un p'tit dessin  vaut mieux qu'un grand baratin. 
> Actuellement c'est taggué "barrier=swing_gate". Mais elle laisse passer tout 
> ce qui fait moins d'un mètre de large, piéton, vélo, poussette, etc.
> 
> Quel serait le bon tag ? Pour l'instant j'ai juste ajouté foot=yes et 
> bicycle=yes.
> 
> Merci, bonne soirée
> 
> Jean-Pierre
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 

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

Re: [OSM-talk-fr] Chemin en bois sur pilotis

[Gwenaël Jouvin]

Ah merci ! Il me semblait bien avoir déjà vu cette page mais je cherchais 
l’info dans les pages highway ou forest… j’étais loin !

Plus qu’à attendre la fin de la pluie pour aller vérifier tout ça sur place :-) 
(et ne pas glisser dessus !)

Gwenaël


Le 10/11/2018 à 12:14, Johnparis a écrit :
> C'est un boardwalk en anglais
> 
> https://en.m.wikipedia.org/wiki/Boardwalk
> 
> Alors ...
> 
> bridge=boardwalk
> 
> https://wiki.openstreetmap.org/wiki/Tag:bridge%3Dboardwalk

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

[OSM-talk-fr] Chemin en bois sur pilotis

[Gwenaël Jouvin]

Bonjour à tous,

Récemment j’ai vu dans une forêt, un chemin construit en lattes de bois, le 
tout surélevé d’environ 30 cm à 50 cm au-dessus du sol à l’aide de pilotis.

Je ne connais pas le terme technique qui désigne ce genre de chose, alors voici 
une illustration :
https://www.visorando.com/images/original/chemin-sureleve-par-un-platelage-visorando-30127.jpg


Actuellement il est taggé
highway=path
surface=wood

… ce qui ne transcrit pas la particularité de l’aménagement. On pourrait 
éventuellement y ajouter la largeur.

Cependant, existe-t-il un attribut particulier pour indiquer précisément que 
c’est un platelage surélevé ?


Merci.

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

Re: [OSM-talk-fr] Epreuve Cyclo-randonnée Paris-Brest-Paris dans OSM

[Gwenaël Jouvin]

Y a-t-il des cyclistes qui suivent cet itinéraire ?
Oui, assurément… puisque chacun circule — presque — où il veut en France !

Pour moi le problème n’est pas l’usage de la route mais le fait que ce soit un 
événement ponctuel et non un itinéraire pérenne et balisé comme peuvent l’être 
les itinéraires de randonnée.
Sans rien retirer au sérieux des organisateurs — ce n’est pas la question ici 
—, cet itinéraire n’est pas « officialisé » comme le sont les véloroutes 
visibles sur le rendu Opencyclemap, n’est pas « entretenu » comme tel et n’est 
pas dédié à la circulation régulière, ce n’est donc pour moi pas une route 
(locale, nationale…) comme décrite dans le wiki :
https://wiki.openstreetmap.org/wiki/FR:Itin%C3%A9raires_cyclables


Par contre, j’ai l’impression que telle qu’elle est cartographiée actuellement, 
cette route=bicycle ne trompe plus les logiciels de routage en étant 
systématiquement favorisée. C’est un bon point car c’est précisément à cause de 
cet effet secondaire dans brouter que j’avais remarqué l’existence de la 
relation.

Croyez-moi, à moins d’être un cycliste qui cherche la performance, le bruit ou 
la mort, nul n’aura envie de s’aventurer à vélo sur des routes de transit comme 
peut l’être l’ancienne nationale 164 (D 764)…



Le 04/11/2018 à 22:51, Florimond Berthoux a écrit :
> Je reviens sur l'argument : "l'itinéraire change tous les x années"
> Je pense qu'il n'est pas recevable, on considère généralement qu'une 
> modification peut avoir un intérêt si le changement dur plus de 1 mois.
> Quatre années c'est très long en temps informatique, openstreemap permet 
> l'édition autant en profiter.
> 
> Je me répète, le point fondamental est y-a-t-il des cyclistes qui suivent 
> cette itinéraire en dehors de la compétition elle même ?
> Je pense que non, mais je ne sais pas vraiment en réalité.
> 
> Le sam. 3 nov. 2018 à 17:53, jabali  > a écrit :
> 
> J'ai finalement laissé un commentaire sur le CS
> https://www.openstreetmap.org/changeset/63513088
> 
> De plus le collègue contributeur à laissé une explication suite à une
> demande d'un membre d'un forum vélo.
> Je ne sais pas si je peux la reproduire mais voici au moins le lien.
> 
> http://forum.velotaf.com/topic/19182-opencyclemap-cartographie-cycliste-participative/page__view__findpost__p__932114
> 
> 
> 
> --
> 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
> 
> 
> 
> -- 
> 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] Carto+ et le plateau de Saclay — Essonne

[Gwenaël Jouvin]

Salut,

Je ne saurais t’en dire plus, je découvre le projet ce jour.

Je sais simplement que d’autres contributeurs OSM du secteur sont en contact 
avec des personnes de ce projet depuis plusieurs années et communiquent 
régulièrement sur OSM…
Si ça peut amener des gens à contribuer au projet de fond qu’est OSM, tant 
mieux…

J’ai aussi l’impression que leur fond n’est pas à jour, ça se voit au niveau du 
giratoire du Christ où la déviation pour travaux n’apparaît pas.

Gwenaël


Le 03/11/2018 à 18:33, JB a écrit :
> En fait, j'ai pas vraiment l'impression qu'ils reversent dans OSM ni qu'ils 
> l'utilisent, à part comme fond de carte (sans attribution directe, en plus…) 
> ? Tu as des éléments qui me contredisent ? Le crédit « Site construit à 
> partir des données OpenStreetMap » me laisse pensif.
> Ça ressemble un peu à du don pour financer une base de données privée ?
> JB.
> 
> Le 03/11/2018 à 12:30, Gwenaël Jouvin a écrit :
>> Bonjour à tous,
>>
>> Un article du Parisien relate un projet cartographie en Essonne et 
>> particulièrement au plateau de Saclay :
>> http://www.leparisien.fr/essonne-91/plateau-de-saclay-souscrivez-pour-une-application-mobile-sur-la-vie-locale-02-11-2018-7933959.php
>>
>> Et je peux vous dire qu’il y a du boulot dans cette zone en plein 
>> chambardement :-)
>>
>> Le site utilise les données d’OSM : http://saclay.carte-ouverte.org/
>>
>>
>> Gwenaël
> 
> ___
> 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] Carto+ et le plateau de Saclay — Essonne

[Gwenaël Jouvin]

Bonjour à tous,

Un article du Parisien relate un projet cartographie en Essonne et 
particulièrement au plateau de Saclay :
http://www.leparisien.fr/essonne-91/plateau-de-saclay-souscrivez-pour-une-application-mobile-sur-la-vie-locale-02-11-2018-7933959.php

Et je peux vous dire qu’il y a du boulot dans cette zone en plein chambardement 
:-)

Le site utilise les données d’OSM : http://saclay.carte-ouverte.org/


Gwenaël

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

Re: [OSM-talk-fr] Borne de puisage

[Gwenaël Jouvin]

Bonsoir,

Merci pour ce tuyau (d’arrosage) !

J’ai récemment ajouté un « poteau incendie » dont je me demandais pourquoi il 
était vert et si peu visible dans l’ombre… ce serait donc une borne de puisage 
? Pourtant, c’est physiquement un poteau utilisé ailleurs pour les points d’eau 
incendie de la région.
J’avais aussi ajouté color=green :-)

Pour les véritables poteaux incendie, attention j’en ai déjà vu avec un 
demi-capot jaune et l’autre rouge, impossible de savoir si c’est de la haute 
pression dedans.
Il y a également ce document qui permet d’apprendre un peu : 
http://www.sdis17.fr/sites/sdis17/files/fichiers/rddeci.pdf

Pour les points d’aspiration, ceci conviendrait-il ?
https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dsuction_point


Gwenaël


Le 29/10/2018 à 11:55, Nicolas Moyroud a écrit :
> Merci Vincent (l'autre !) pour ces précisions.
> 
>> Tu en as de ces TOCs toi ;) 
> Oui tout plein, mais j'ai même pas envie de me faire soigner !
>> Certaines communes ne respectent pas ce code couleur. Je pense par exemple à 
>> Senlis (60) où une bonne proportion des "vrais" poteaux incendie sont du 
>> même vert que les bornes de puisage, juste pour une raison esthétique : 
> MDR. Pour des raisons esthétiques c'est un peu comme tagguer pour le rendu ça 
> ! D'après mon contact la réglementation devrait bientôt obliger à respecter 
> les codes par catégories d'hydrant. A voir...
>> pour les jaunes (je n'en ai jamais vues sauf à... Disneyland Paris :) ) je 
>> suppose qu'une valeur numérique pour ce même tag doit aller. Voir 
>> https://taginfo.openstreetmap.org/keys/fire_hydrant%3Apressure.
> 
> Pour les jaunes pas forcément évident de connaître la pression si ce n'est 
> pas indiqué dessus (mais peut-être que ça l'est systématiquement?). Y'a moyen 
> d'indiquer "supérieur à" pour une valeur numérique ? J'ai jamais fait ça...
> 
> On dirait que Disneyland aime mettre la pression. :-P
> 
> Nicolas
> 
> 
> ___
> 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] signification multiple crossing=zebra

[Gwenaël Jouvin]

Bonsoir,

Lors de mes relevés je m’efforce de placer les passages (au moins ceux qui 
apparaissent sur mes photos) et surtout, s’il y a des bandes d’éveil de 
vigilance (tactile_paving=yes|no) et s’ils sont accessibles 
(wheelchair=yes|limited|no).

Par contre, je ne vois pas véritablement la pertinence de l’attribut zebra car, 
s’il a certainement une signification au Royaume-Uni ; c’est différent en 
France où, par définition, tout passage pour piétons est marqué sur la 
chaussée, donc ils sont tous « zebra » par défaut.

Bien sûr, on trouve dans certaines villes des « passages » mieux intégrés dans 
l’urbanisme, par exemple délimités par des pavés, des clous voire un revêtement 
ou des pierres colorées.
Si ce sont bien des passages pour piétons par l’usage, ce n’en sont pas du 
point de vue de la signalisation routière [1, art. 118].
Je pense que l’on pourrait ajouter crossing=unmarked pour ces cas clairs par 
l’usage mais litigieux par la loi.

Enfin pour finir sur les points litigieux, on voit aussi des passages 
intégralement peints, en rouge par exemple. C’est illégal [2, II-1], en plus 
d’être périlleux pour les deux-roues.

Gwenaël


[1] IISR 7 : 
http://www.equipementsdelaroute.equipement.gouv.fr/IMG/pdf/IISR_7ePARTIE_VC_20160215_cle217e65.pdf
[2] Circulaire du 15-05-1996 : 
https://www.legifrance.gouv.fr/jo_pdf.do?id=JORFTEXT00376640


Le 25/10/2018 à 23:51, marc marc a écrit :
> Bonjour,
> 
> j'aurais du vous proposer une édition de masse sur ce sujet.
> c'était en préparation depuis longtemps depuis que le problème avait été 
> identifié lors d'une discussion cartomobilité qui discute entre autre 
> des problèmes de comment osm peux aider pour renseigner l'accessibilité 
> multiple.
> mais voila, ces oir josm a poussé un patch qui complique encore la 
> chose. je vais donc vous exposer le problème en français, traduction
> de celui que je viens de poster sur tagging (la ml mondiale anglaise 
> pour les problèmes de tag).
> 
> Bonjour. Bonjour,
> 
> J'ai un gros problème avec crossing=zebra.
> il empêche de remplir d'autre valeur pour le croisement comme 
> crossing=traffic_signals (passage piéton avec un feu de circulation) 
> crossing=uncontrolled (passage piéton sans feu)
> le wiki[1] dit que crossing=zebra est un raccourci pour 
> crossing=uncontrolled + crossing_ref=zebra au Royaume-Uni
> mais beaucoup de zébra tant au Royaume-Uni, qu'en France et ailleur
> ont des zébra avec feu qui doivent donc être renseign avec 
> crossing=traffic_signals
> donc à la fin, crossing=zebra n'a pas de sens... peut-être
> que le contributeur précédent voulait dire crossing=uncontrolled + 
> crossing_ref=zebra
> mais peut-être qu'il veut dire seulement crossing_ref=zebra et qu'il n'a 
> aucune idée de la présence de feu ou pas (ajout depuis l'imagerie sat 
> par exemple).
> J'ai corrigé il y a quelques semaines beaucoup de crossing=zebra 
> crossing_1=signals_traffic_signals
> ou crossing=zebra;traffic_signals qui montrent que c'est un problème.
> 
> un ticket a été fermé dans iD[2] il y a quelque temps parce que "son dev 
> n'aime pas crossing_ref" (c'est en fait un nom très laid pour le tag)
> en ce moment josm[3] change le preset pour supprimer cossing_ref=zebra
> en faveur du croissing=zébra
> 
> Je fais partie d'un groupe de cartographes travaillant sur 
> l'accessibilité yant l'intention d'ouvrir une discussion pour y 
> remédier, mais l'actualité des commit nous a précédés.
> 
> donc ma requête est : comment éviter à nouveau une balise multi sens ?
> 
> Peut/doit-on séparer le type de croisement du marquage au sol ?
> en résumé : changer les crossing=zebra au profit d'une autre balise ?
> si oui crossing_Ref est-il si laid que dans le même temps un autre tag 
> en a besoin à utiliser pour le marquage au sol ?
> (ajout hors traduction : perso je suis partisant d'étape limité séparée
> et donc initialement j'aurais changer crossing=zebra en 
> crossing_ref=zebra et reporté le choix d'un meilleur non pour le 
> marquage dans un autre sujet)
> 
> évitons l'argument "il y a trop de cas à régler",
> cela ne m'effraie pas de proposer une édition de masse une fois qu'un 
> schéma cohérent a été établi.
> mais le fait d'avoir la moité des outils qui remplissent une valeur avec 
> une autre signification que l'autre ou que la signification historique 
> est un gros problème pour l'utilisation. des données.
> 
> [1] https://wiki.openstreetmap.org/wiki/Key:crossing
> [2] https://github.com/openstreetmap/iD/issues/4788
> [3] https://josm.openstreetmap.de/ticket/16793
> https://taginfo.openstreetmap.fr/search?q=%3Dzebra
> 
> 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] Bien qu'étant abonné, je ne reçois pas tous les mails

[Gwenaël Jouvin]

Bonsoir,

J’ai le même problème et je remarque que nous sommes tous deux chez la Poste.

Je suppose que c’est dû à cet hébergeur. J’ai subi de gros problèmes de 
réception de messages sur cette boîte il y a quelques mois, des messages 
arrivaient 2, 3 jours après leur envoi…
Les soucis se sont calmés mais reviennent çà et là.
Faudrait vraiment que tout le monde envoie ses mails avec un timbre rouge :-)

Ma parade : inscrit avec une autre adresse pour tout avoir ou consulter les 
archives.

Gwenaël


Le 20/10/2018 à 15:31, Paul Desgranges a écrit :
> Bonjour
>  Bien qu'étant abonné a talk-fr@openstreetmap.org, je ne reçois qu'un mail 
> sur cinq à peu près, j'ai vérifié la gestion des indésirable bien sûr sans y 
> trouver d'explication. Ça m'oblige à aller consulter sur les archives de osm 
> talk fr 
>  
> pour avoir les fils de discussions complets, puis de copier-coller à la main 
> les messages pris dans les archives dans un des messages qui est arrivé dans 
> ma mailbox pour faire une réponse en citant l'émetteur. Ça entre-melle les 
> réponses que je peux faire pas au bon endroit dans le fil de discussion, 
> c'est un peu embêtant tout ça. Je ne sais pas si je suis le seul dans ce cas, 
> et/ou si qqun aurait une explication?   
> Merci
> Paul
> 
> 
> 
> ___
> 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] Epreuve Cyclo-randonnée Paris-Brest-Paris dans OSM

[Gwenaël Jouvin]

Bonsoir,

Merci d’amener ce sujet ici : en préparant une rando il y a quelques semaines, 
j’étais surpris que brouter m’emmène par l’ancienne nationale 164 (une route 
vraiment pas drôle pour rouler à vélo)… il a simplement suivi la relation 
indiquée comme ncn !

Pour moi c’est une erreur : le Paris – Brest – Paris est une épreuve cycliste 
et pas du tout un itinéraire balisé par une institution comme le sont la 
Véloscénie ou la Scandibérique :
https://www.openstreetmap.org/relation/7163558
https://www.openstreetmap.org/relation/2345035

Peut-être faudrait-il contacter ses auteurs afin de comprendre leur motivation ?

À mon avis, il faudra au minimum retirer l’attribut network=ncn car il est ici 
inapproprié.


Le 12/10/2018 à 17:26, jabali a écrit :
> Je viens de tomber sur ceci
> https://www.openstreetmap.org/relation/8595631
> vous en pensez quoi ?
> Itinéraire cyclable ?
> 
> 
> 
> 
> 
> --
> 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] Abus de topologie surfacique

[Gwenaël Jouvin]

C’est effectivement un « boulot de dingue ». Les tracés collent bien avec la BD 
Ortho IGN, en haute définition dans cette région.

Quelques problèmes tout de même :
— un décalage avec le cadastre, a priori les trottoirs devraient suivre le pied 
du mur des bâtiments ;
— les places de stationnement ne sont pas intégrées à un amenity=parking et 
restent invisibles ;
— la piste cyclable sur trottoir qui devrait être indiquée par un chemin dédié 
plutôt qu’intégrée au trottoir (https://www.openstreetmap.org/way/627875672) ;
— les bordures « kerb » qui sont présentes même au niveau des passages pour 
piétons abaissés ;
— absence des connexions footway=crossing aux passages pour piétons.

C’est un boulot colossal qui appelle finalement encore plus de boulot pour 
compléter avec une visite de terrain. Et il reste certainement plein de trucs à 
ajouter : toilettes, bancs, points d’eau, poubelles, armoires techniques, 
bouches à incendie enterrées, stationnement vélo…
J’aurais tendance à faire le cheminement inverse, mettre « l’utile » d’abord et 
compléter avec l’imagerie ensuite :-)

Après, tant que ça ne chamboule pas l’existant, je pense pas que ce niveau de 
détail dérange ?



On 08/10/2018 19:05, Antoine Riche wrote:
> Bonjour,
> 
> Que pensez-vous du travail de Meersbrook autour la rue Olympe de Gouges à 
> Asnières ? Tous les trottoirs sont mappés en surfacique, les places de 
> parkings cartographiées une à une. Un sacré boulot mais j'ai un doute sur la 
> validité de la chose. Ça se passe ici : https://osm.org/go/0BPJJt4Jt--
> 
> Antoine.

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

Re: [OSM-talk-fr] Horaires d'ouverture

[Gwenaël Jouvin]

Je profite de ces messages pour indiquer ou rappeler l’existence de ce très 
pratique outil de vérification :
http://openingh.openstreetmap.de/evaluation_tool/?setLng=fr

et bien sûr, la page principale du wiki :
https://wiki.openstreetmap.org/wiki/FR:Key:opening_hours

Waxy, la réponse à ta question est dedans (je taquine en mode RTFM ;-) )


On 06/10/2018 16:34, Philippe Verdy wrote:
> Sa[1] = 1er samedi du mois
> 
> Le sam. 6 oct. 2018 à 16:18, Waxy  > a écrit :
> 
> Salut,
> 
> Comment on dit "tous les premiers samedis du mois" en opening_hours ? 樂
> 
> Pour https://www.facebook.com/Marche-Paysan-De-Coconi-1469553479997566/
> 
> @+
> 
> ___
> 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] On en parle dans l'actu: floutage des prisons françaises

[Gwenaël Jouvin]

Merci pour le texte.

Il y a quand même un paradoxe pour certains sites tels que le centre d’études 
nucléaires du commissariat à l’énergie atomique de Saclay.
Il est dans la liste et la BD Ortho est floue, très difficile à exploiter.
Pourtant, c’est un centre civil et les bâtiments sont cadastrés et importés 
dans OSM.
https://www.openstreetmap.org/way/45674130

À titre de comparaison d’autres centres comme celui de Cadarache (mi-civil, 
mi-militaire) à Saint-Paul-lès-Durance est quasiment vide faute de cadastre.
https://www.openstreetmap.org/way/27827611

Celui de Gramat (militaire, ancien site de la Direction générale de l’armement) 
est totalement absent d’OSM, pourtant visible sur la BD Ortho censurée.
https://www.openstreetmap.org/relation/123059


Le 03/10/2018 à 20:41, Philippe Verdy a écrit :
> Autre référence : L'article Article D133-10 du code de l'aviation civile 
> (version de 29 juillet 2005 en vigueur) qui précise les conditions d'usage 
> qui peut être fait des relevés photographiques, cinématographiques (et tout 
> autre capteur, donc aussi les GPS, radars, etc.).
> 
> https://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT06074234
> 
> à partir de cet article il y a les autres références concernant les types 
> d'installations visés. Cependant cela ne semble pas limiter les photos et 
> captages de données au niveau du sol.
> 
> Le mer. 3 oct. 2018 à 20:33, Philippe Verdy  > a écrit :
> 
> note: la liste ne concerne pas que des prisons, on trouve par exemple la 
> plus grande partie du port et de la rade de Brest (zone militaire), et des 
> zones dictées par d'autres ministères (y compris celui de l'écologie et du 
> développement durable). Elles aussi sont particulièrement détaillées (mais 
> font aussi partie de parcs naturels, et pas totalement fermés, comme la rade 
> de Brest et les passages civils dans le port de Brest, essentiels aux 
> transports publics).
> 
> 
> Le mer. 3 oct. 2018 à 20:20, Philippe Verdy  > a écrit :
> 
> Un arrêté passé inaperçu mais qui concerne nos sources (IGN BDOrtho 
> notamment)
> 
> Voir références de l'arrêté ministériel sur
> 
> https://www.legifrance.gouv.fr/jo_pdf.do?id=JORFTEXT35932840
> 
> Doit-on faire quelque chose et arrêter de détailler l'intérieur des 
> prisons (ou juste ces 247 listées dans l'arrêté) sur la base des ortho photos 
> IGN BDOrtho si l'arrêté pris le 31 octobre 2017 n'est pas rétroactif et ne 
> concerne donc pas les photos IGN de mi-2017 (les mêmes que celles utilisées 
> par Google qui est critiqué pour le niveau de détail et même le rendu 3D des 
> installations) ?
> 
> Que dire alors des autres données comme celles du cadastre sur les 
> bâtiments ?
> 
> En attendant on voit parfaitement tous ces établissements dans 
> l'éditeur iD OSM avec les images BDOrtho et bon nombre sont déjà détaillées 
> 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] Comment taguer une piste cyclable à double sens sur chaussée ?

[Gwenaël Jouvin]

Bonsoir,

Pour être exact sur le 1er argument, une piste cyclable n’est pas définie comme 
une voie — au sens général du terme — mais comme une chaussée, à l’article R. 
110-2 du Code de la route [1].
Les voies, au sens du Code de la route, sont des sous-éléments d’une chaussée. 
En gros, elles n’accueillent qu’un seul véhicule dans un seul sens de 
circulation, peuvent être matérialisées ou non : la plupart des chaussées sont 
à 2 voies de sens opposés.

Sur le 3e argument, c’est exact et on en voit souvent en milieu semi-urbain 
dense.
Par contre, lorsqu’une piste cyclable franchit la chaussée principale le long 
d’un passage pour piétons et sont dénuées de feux spécifiques R 13c [3, art. 
109-3, p. 4], les cyclistes doivent se conformer aux indications des feux pour 
piétons R 12 comme le précise l’article R. 412-30 du Code.


Pour les mêmes raisons évoquées, je préfère voir les pistes tracées comme des 
chemins indépendants. Ça permet, d’un coup d’œil rapide sur la carte, de faire 
la différence avec les bandes cyclables qui, elles, sont de simples voies d’une 
chaussée matérialisées par du marquage au sol [4, art. 114-3, p. 13].
Pour les cyclistes, les caractéristiques propres et les différences de chacun 
de ces aménagements sont très importantes.


[1] 
https://www.legifrance.gouv.fr/affichCodeArticle.do?idArticle=LEGIARTI23095873=LEGITEXT06074228
[2] 
https://www.legifrance.gouv.fr/affichCodeArticle.do?idArticle=LEGIARTI33842020=LEGITEXT06074228
[3] 
http://www.equipementsdelaroute.equipement.gouv.fr/IMG/pdf/IISR_6ePARTIE_VC_20160215_cle217f7b.pdf
[4] 
http://www.equipementsdelaroute.equipement.gouv.fr/IMG/pdf/IISR_7ePARTIE_VC_20160215_cle217e65.pdf


Le 02/10/2018 à 13:47, Francescu GAROBY a écrit :
> Le 1er argument que je donnerais, c'est qu'une piste cyclable est clairement 
> définie dans le Code de la route comme étant une voie physiquement séparée de 
> la chaussée, par opposition à la bande cyclable (voie faisant partie de la 
> chaussée, et séparée des autres voies par un "simple coup de peinture").
> Le 2ème argument, c'est qu'on ne peut entrer/sortir d'une piste cyclable 
> qu'aux endroits prévus à cet effet (dans OSM => node à l'intersection entre 2 
> ways). Là où l'entrée/sortie d'une bande cyclable ne nécessite rien d'autre 
> que de changer de voie.
> 3ème argument : une piste cyclable peut avoir des feux de circulation 
> différents de ceux de la chaussée qu'elle longe, là où la bande cyclable a 
> forcément les mêmes que le reste de la chaussée à laquelle elle appartient.
> Enfin, 4ème argument : sa solution n'est, pour l'heure actuelle, pas prise en 
> compte par les calculateurs d'itinéraires ! C'est un peu con de supprimer une 
> way correctement prise en compte, et qui reflète bien la réalité, pour la 
> remplacer par des tags mal gérés...
> 
> Francescu

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

Re: [OSM-talk-fr] Vincennes

[Gwenaël Jouvin]

Bonsoir,

Ces segments peuvent paraître étranges mais découlent du fait qu’OSM définit 
les voies de circulation par des segments et non par des surfaces.

Un choix a été fait avenue de Paris : la tracer en séparant les voies et en les 
mettant à sens unique. Je ne connais pas le quartier mais je suppose qu’il y a 
un terre-plein central au milieu de l’avenue.
Par conséquent, le routage entre la rue Aubert 
(https://www.openstreetmap.org/way/460941519) et l’avenue Pasteur 
(https://www.openstreetmap.org/way/22736543) est coupé.
Pour rétablir la connexion entre ces deux rues et éviter que le chemin suive 
l’avenue de Paris et fasse demi-tour à la jonction des 2 segments à sens unique 
(ce qui serait absurde), il faut tracer un lien qui existe bien sur le terrain 
mais n’est pas flagrant : ce sera, par exemple, la continuité de la route qui 
traverse un terre-plein — bien qu’en réalité, on perçoit la chose à l’inverse, 
c’est le terre-plein qui coupe la route.

Ces segments bizarres sont encore plus flagrants pour les chemins piétons où, 
toujours pour des soucis de routage, on doit tracer des chemins inexistants en 
réalité puisque sur le terrain, il y a un trottoir qui serait mieux représenté 
par une surface, ce qui n’est pas envisageable dans OSM.

Encore plus représentatif de ce « travers » : les traversées piétonnes 
https://wiki.openstreetmap.org/wiki/Tag:footway%3Dcrossing


Gwenaël


Le 27/09/2018 à 18:12, nicolas parizet a écrit :
> Le 27/09/2018 à 17:41, nicolas parizet a écrit :
>> C'est la première fois que je vois des segments de rue entre deux voies
>> d'une route.
> 
> Bon en fait, c'est courant sur Paris.
> 
> J'avoue ne pas comprendre la logique. Je regarde une avenue Victor Hugo
> près d'Orly.
> 
> Les segments entre les deux voies indiquent
> 
> - soient l'avenue Victor Hugo
> 
> - soient une rue perpendiculaire à cette avenue comme la rue
> d'Alsace-Lorraine.
> 
> Bon sinon, je crois comprendre que ces segments indiquent qu'on peut
> traverser les deux voies et qu'il n'y a pas de terre-plein entre les
> deux voies.
> 
> Si quelqu'un peut m'envoyer vers la bonne section du wiki pour que je
> comprenne…
> 
> Merci.
> 
> Nicolas
> 
> 
> 
> 
> 
> ___
> 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] restrictions d'accès dans les voies de cimetières

[Gwenaël Jouvin]

Bonsoir,

highway=track est en effet très connoté chemin de terre, tant par sa définition 
que par le ou les rendus.

Pour les voies où les véhicules peuvent circuler dans un cimetière, 
highway=service ne serait-il pas plus approprié ?
Avec highway=footway voire path pour les allées trop étroites…



Le 23/09/2018 à 20:48, marc marc a écrit :
> Le 23. 09. 18 à 19:19, Philippe Verdy a écrit :
>> Quelle valeur indiquer ?
> 
> mapper ce qui existe et non la législation.
> highway=path si c'est étroit ou track si c'est assez large
> que pour un véhicule de service y passe (sujet à controverse,
> certain ne voyant dans track que l'aspect rural/agricole/forestier)
> + access selon les panneaux présents
> + barrier éventuelle à leur emplacement
> + opening_hour éventuel
> 
> 
>> - propriété publique mais d'accès restreint et réglementé dans un espace 
>> délimité
>> - propriété privée mais d'accès "permissif".
> 
> on ne mape pas la propriété dans osm.
> donc les 2 sont access=permissif
> si tu veux maper l'opérateur public du parc operator:type=public
> ___
> 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] arrêt de bus sans attribut name

[Gwenaël Jouvin]

Merci pour le site : il n’est vraiment pas pratique (euphémisme) mais si je 
n’ai pas trouvé les arrêts en question, j’en ai vu d’autres informellement 
nommés… par les lieux-dits où ils sont implantés. Je ne suis donc qu’à moitié 
dans le faux, ouf mon honneur (et mon changeset) est sauf.

Il serait pourtant tellement plus simple pour tout le monde d’avoir des cartes 
ou des plans de ligne, comme ce que peut faire la RATP…

Merci aussi pour le point réglementaire. Par ici, ce sont des privés qui ont 
délégation de service public, Manéo n’est pas partout.


Le 22/09/2018 à 18:08, deuzeffe a écrit :
> Le 22/09/2018 à 14:42, Gwenaël Jouvin a écrit :
>> Malheureusement je n’ai trouvé aucun document officiel.
> 
> Damnède! Mais que fait la mission OD du gouvernement ? ^^
> 
>> Sur le site de Manéo [1], il est indiqué que l’on peut faire appel à
>> une navette en cas de besoin : les arrêts semblent donc être là
>> surtout pour les scolaires (des société privées ?) et, pour les
>> autres, à la demande…
> 
> Reprenons. Les transports scolaires sont obligatoirement opérés par les 
> régions depuis septembre 2017 et non plus les départements (loi NOTRe). Les 
> régions décident (ou pas) de garder une structure qui s'occupe plus ou moins 
> d'un département (en général oui, puisque les locaux, anciens opérateurs, 
> connaissent mieux le terrain que l'administration régionale). L'ancienne 
> structure départementale décide à quel transporteur elle va confier le 
> transport des enfants sur telle ou telle ligne. In fine, c'est soit 
> l'ancienne régie départementale soit un privé qui reçoit une délégation de 
> service public. Donc, sauf rares exceptions (type PPP, et encore...) qui 
> doivent bien exister sur le territoire, le transport scolaire est *public*.
> 
> So, dans la Manche (région Normandie), tu peux regarder ici 
> https://transports-scolaires.normandie.fr/manche/horaires/ (mais tu l'as 
> peut-être déjà fait ?), si un de tes arrêts auto-nommés par toi-même 
> correspond à un trajet scolaire. Dommage qu'ils n'aient pas mis à dispo. les 
> fiches complètes des lignes scolaires, c'est quand même vachement plus simple 
> quand on veut les mapper...
> 
> D'ailleurs, ça va entraîner refonte des pages TP du wiki pour prendre en 
> compte cette nouvelle organisation (déjà évoqué sur la ML).
> 
> HTH (ou pas).

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

Re: [OSM-talk-fr] arrêt de bus sans attribut name

[Gwenaël Jouvin]

Malheureusement je n’ai trouvé aucun document officiel.
Sur le site de Manéo [1], il est indiqué que l’on peut faire appel à une 
navette en cas de besoin : les arrêts semblent donc être là surtout pour les 
scolaires (des société privées ?) et, pour les autres, à la demande…

À vrai dire, certains arrêts ont juste un abri en bois sans aucun document 
affiché, on ne sait donc pas quel transporteur y passe.

Il paraît évident qu’il faille nommer les arrêts au moins avec le nom de la 
commune… mais ça ne l’est pas pour tout le monde :-)


[1] https://www.manche.fr/transports/navettes-maneo.aspx


Le 22/09/2018 à 13:52, deuzeffe a écrit :
> Et les cartes/horaires des lignes disent quoi ?
> 
> Dans mon dép. rural, les lignes non métropolitaines comportent des arrêts 
> notés -, ce qui fait qu'on peut aisément 
> différencier les nombreux arrêts "Le Bourg" ;)

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

Re: [OSM-talk-fr] arrêt de bus sans attribut name

[Gwenaël Jouvin]

Je sais que c’est pas très correct, mais sur beaucoup d’arrêts que j’ai pu 
voir, il n’y a qu’un abri sans aucun nom. Pas très pratique pour se repérer, 
d’où ce choix.

A contrario, dans beaucoup d’arrêts dans les communes environnantes, on n’a 
rien trouvé de mieux que tous les nommer « le Bourg ». Il est bien beau ce nom, 
mais totalement inutile pour se repérer :
https://www.openstreetmap.org/node/5824305002
https://www.openstreetmap.org/node/5825302362
https://www.openstreetmap.org/node/5760790682


Le 22/09/2018 à 13:18, David Crochet a écrit :
> Bonjour
> 
> 
> Le 22/09/2018 à 13:12, Gwenaël Jouvin a écrit :
>> J’ai pris l’initiative de les nommer du nom du lieu-dit le plus proche, en 
>> le précisant avec une note.
> 
> Ce serait plutot au gérant ou à l'utilisateur de demander à nommer ce lieu.
> imagine que tu leur donnes un nom et que la mairie est l'usage d'un autre nom 
> ?
> 
> Crodialement
> 

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

Re: [OSM-talk-fr] arrêt de bus sans attribut name

[Gwenaël Jouvin]

Bonjour,

Si l’arrêt est matérialisé au sol avec une ligne en dents de scie jaune et par 
un panneau carré bleu C 6 (http://routes.wikia.com/wiki/Panneau_de_type_C6), on 
peut considérer que c’est bien un arrêt et non un simple emplacement de 
stationnement.

Je croise parfois des arrêts de bus sans nom en pleine campagne, utilisés par 
diverses lignes, locales à la demande, scolaires…
J’ai pris l’initiative de les nommer du nom du lieu-dit le plus proche, en le 
précisant avec une note.
https://www.openstreetmap.org/node/5750269437
https://www.openstreetmap.org/node/5750268639


Le 22/09/2018 à 12:42, PanierAvide a écrit :
> Bonjour,
> 
> Le fameux arrêt de bus DesGayeullesKaPaDeNom :-) Ça ressemble quand même à un 
> arrêt de bus, mais j'imagine que c'est pour des bus de tourisme ou scolaires 
> de manière ponctuelle. Un tag noname=yes ?
> 
> Cordialement,
> 
> Adrien.
> 
> 
> Le 22/09/2018 à 12:20, mga_geo a écrit :
>> Bonjour à tous,
>> En comparant les données "transport" opendata de la région Bretagne avec
>> osm, je viens de trouver des nodes sans attribut "name", par exemple
>> https://www.openstreetmap.org/node/4339678814#map=18/48.13454/-1.64472
>> Cela correspond effectivement à une zone de stationnement pour les cars.
>> Mais aucune ligne régulière n'utilise cet arrêt.
>> Faut-il modifier les attributs ?
>> Marc
>>
>>
>>
>> -- 
>> 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] Parc de stationnement en Zone de rencontre

[Gwenaël Jouvin]

Merci pour l’info sur la hiérarchisation des voies. J’y ferai attention (et 
j’aurai certainement des choses à corriger) car par habitude, j’ai également 
commis l’erreur.


Ma remarque précédente concernait le choix de l’aménageur : il faut garder à 
l’esprit que la zone de rencontre est une adaptation française, maladroite et 
incomplète, des concepts de shared space ou de woonerf [1] que l’on trouve dans 
d’autres pays européens et qui est très adapté, comme indiqué, aux abords 
d’écoles (quoique, ça se discute : la zone 30 avec fermeture périodique est 
certainement plus cohérente avec une activité très hétérogène) mais surtout aux 
rues à faible circulation motorisée de centre-ville, à forte dominante 
piétonne, mais nécessitant tout de même un minimum de circulation qui empêche 
de les classer en aire piétonne.

Bref, l’idée générale est : des enfants peuvent y courir après un ballon sans 
danger. Tout le contraire d’un parc de stationnement…

Je crois que beaucoup se font berner par le panneau de la zone de rencontre 
avec son « 20 » et le confondent avec une « zone 20 », dénomination que l’on 
lit malheureusement trop souvent. Seuls 2 panneaux en Europe présentent une 
limite de vitesse… [2] … et dans une zone de rencontre, ce n’est pas la vitesse 
qui est centrale, mais l’usage de la chaussée. 20 est indiqué car il faut 
croire qu’en France, on ne raisonne qu’en termes de vitesse.
La bonne pratique est que lorsque l’on souhaite limiter la vitesse à 20 km/h, 
on met un panneau « 20 ». Quand on souhaite indiquer une zone à circulation 
fortement restreinte où la vie locale est prépondérante, on crée une zone de 
rencontre, mais un panneau n’y suffit pas.

Bon, on s’éloigne de la carto, mais il est bon parfois de faire le point sur ce 
que l’on ajoute ;-)

Gwenaël


[1] 
https://rouelibreblog.wordpress.com/2016/01/17/zone-de-rencontre-et-shared-space-un-meme-esprit-3-nuances/
[2] 
https://fr.wikipedia.org/wiki/Comparaison_des_panneaux_de_signalisation_routi%C3%A8re_en_Europe


Le 18/09/2018 à 21:27, Jérôme Seigneuret a écrit :
> @gwenael.jou...@laposte.net   Les voies de 
> stationnement n'ont pas à toute être mise en service=parking_aisle. Si c'est 
> une voies majeur servant à diriger le traffic sur le parking c'est juste un 
> highway=service. C'est aussi ce qui permet de conditionner le routing. On ne 
> met pas parking_aisle sur les voies servant à diriger le flux vers les 
> entrées ou sorties des parkings ni vers des accès à des routes supérieurs. 
> Seul exception acceptable à mon sens c'est la voie voie de parking unique 
> sans sortie.
> 
> L'erreur est souvant faite et c'est aussi ID qui est en cause car il met 
> automatiquement cette balise service=parking_aisle
> Pour moi il manque la décomposition sur ID voie majeur de parking et voie 
> secondaire de parking
> 
> https://www.openstreetmap.org/#map=17/43.58307/3.93005
> D'ailleurs quand je voie le lien je me rends compte qu'il y a des erreurs sur 
> certaines voies :|  J'ai raté des bouts de voies
>
> […]

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

Re: [OSM-talk-fr] Parc de stationnement en Zone de rencontre

[Gwenaël Jouvin]

Mettre un parc de stationnement en zone de rencontre, on aura vraiment tout vu !
Ces aménageurs sont vraiment prêts à tout pour qu’on n’y comprenne plus rien… à 
se demander si eux-mêmes y comprennent quoi que ce soit.

Bref, à mon avis, les voies d’un parc de stationnement n’ont pas à être 
classées en  mais en .

Dans ce cas, on est confronté à une incompétence en matière de voirie qui 
détourne la signalisation abusivement.
Que faire ? Respecter aveuglément le terrain ou, par discernement, déformer un 
peu la réalité et rester rationnel ?

Personnellement, je choisirai sans hésiter la seconde option, en mettant une 
note explicative et un .


Gwenaël


Le 18/09/2018 à 20:05, Axelos a écrit :
> Bonjour,
> 
> Devant mon lieu de travail, il y a un parc de stationnement de plusieurs
> centaines de places qui est passé intégralement en zone de rencontre il
> y quelques mois.
> Les voies pour y accéder au parc en général, mais aussi les voies pour
> accéder aux places de stationnements.
> 
> Les données ont été que partiellement implémenté pour le moment, mais je
> me pose la question si la balise highway=living_street est suffisante
> sur les voies accédants aux places de stationnements ? N'est-il pas
> judicieux d'ajouter une autre balise en plus ?
> 
> Cordialement, Axel.
> 
> ___
> 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] Besoin d'avis sur cette pratique

[Gwenaël Jouvin]

Bonsoir,

Sans connaître le contexte, à la lecture des commentaires il est dommage que ça 
parte d’un si mauvais pied par des phrases courtes inévitablement mal 
interprétées à l’écrit.

Après, je comprends la réaction épidermique du contributeur initial qui voit 
son travail supprimé : il aurait, je crois, été plus prudent de le contacter au 
préalable ou de mettre une note.
Je pense que je serais également pas très content si quelqu’un passait derrière 
mes contributions de terrain en cassant tout… c’est récemment arrivé à un 
collègue et il est obligé de tout refaire (chemins coupés, toponymes mélangés, 
historiques perdus…), y a de quoi enrager.

Évidemment, il est également confortable de bosser sur une carte où il existe 
déjà plein d’éléments mis par d’autres personnes qui maîtrisent les imports de 
jeux de données.

Contributeurs d’intérieur et d’extérieurs sont complémentaires !


Sur l’objet en lui-même, ce n’est clairement pas un  puisque ce n’est 
pas une voie de circulation mais la trace laissée par une machine.


Gwenj


Le 12/09/2018 à 22:46, Romain MEHUT a écrit :
> Bonsoir,
> 
> Sur la base d'un commentaire "J'ai une question à la con : c'est quoi ce truc 
> ?" dans ce changeset https://www.openstreetmap.org/changeset/62500260 j'ai 
> supprimé tous les highway=footway qui à mon sens n'en sont pas.
> 
> Le contributeur à l'origine des contributions proteste contre mes 
> suppressions comme vous pourrez le lire dans la suite de commentaires du 
> changeset.
> 
> Quel est votre avis ?
> 
> Merci.
> 
> Romain

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

Re: [OSM-talk-fr] Limites de vitesse et incohérences

[Gwenaël Jouvin]

Le 11/09/2018 à 23:22, Patrick BEGOU a écrit :
> Il y a un problème avec le "sauf riverains" ?


Bonsoir,

Oui, cette notion de « sauf riverains » n’a pas de réel fondement juridique : 
comment définir un riverain ?

Si on regarde dans la 9e édition du dico de l’Académie, on trouve :
« Dérivé de rivière, au sens de « rive ». Celui, celle qui habite ou possède 
une propriété située le long d'un cours d'eau, d'une étendue d'eau. Les 
riverains de la Garonne. Riverains d'amont, d'aval. Par anal. Les riverains 
d'une rue, d'un parc. »

Mais dans le monde réel, celui qui habite le lotissement au bout de la rue et 
qui souhaite éviter de faire un détour prendra le sens interdit, l’ami que l’on 
a invité à dîner aussi, le livreur également, le plombier qui vient déboucher 
les toilettes lui aussi…

Ces sens interdits « sauf riverains » (B 1 + M 9z) sont en réalité des 
prescriptions destinées à limiter la circulation dans un sens sur une route, 
certainement pas tant par souci de sécurité que par souci de plaire à un 
certain électorat.

En l’état, si l’infraction est constituée, elle est quasiment impossible à 
verbaliser. En somme, le panneau ne sert à rien, c’est une forme de 
signalisation inutile et détournée de son rôle premier, une très mauvaise 
habitude puisque cela tend à la dévaloriser lorsqu’elle est réellement fondée.


Dans le même genre, on croise parfois des panneaux « sans issue » à l’entrée de 
routes pourtant débouchantes comme on peut le voir sur une carte : le but est 
clair, dissuader la circulation de transit en délivrant une fausse information.

Ces méthodes sont vraiment déloyales et très pénalisantes pour les piétons & 
les cyclistes qui, croyant l’information fondée, s’obligent à faire des détours 
alors qu’un itinéraire direct et généralement sécurisé existe.
Dans les milieux de piétons et de cyclistes que je côtoie, une cartographie 
précise et libre (tiens, ça rappelle quelque chose !) permettant la création 
d’itinéraires sûrs, rapides & directs par des chemins peu visibles sur le 
terrain suscite de fortes attentes.

Salutations,

Gwenaël

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

Re: [OSM-talk-fr] micro-mapping de parkings

[Gwenaël Jouvin]

La question se pose en effet…

Pour ma part j’ai créé des relations car il est indiqué que parking_space ne 
peut exister que dans une relation [1]…
« Parking spaces always have to be grouped together in a site relation tagged 
with type=site + site=parking. »

Je suis de ton avis pour les places pour handicapés. Dessiner les places 
individuelles peut servir à avoir une meilleure visibilité sur la place laissée 
à ces personnes, la bonne ou mauvaise organisation du stationnement qui leur 
est dédié ; plus généralement la place occupée par l’automobile en ville.

Un avantage de la relation, elle peut mettre en évidence la propriété de 
différents parcs lorsqu’ils ne sont pas contigus, par exemple de part et 
d’autre d’un bâtiment.

Au passage, quelqu’un aurait-il des conseils pour mes questions à ce sujet sur 
tagging-fr ?
https://lists.openstreetmap.org/pipermail/tagging-fr/2018-September/69.html


Et vu le temps que j’ai passé à trier les membres de celui de Longjumeau, 
pitié, qu’on ne me dise pas que c’est inutile ;-) !

Merci,

Gwenaël

[1] https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking_space


Le 11/09/2018 à 21:20, marc marc a écrit :
> Bonsoir,
> 
> je pense que la conseil sur le wiki de créer une relation site est erroné.
> tu as un polygone qui regroupe le tout,je ne vois pas ce que la relation 
> ajoute hormis de lister tout ce qui est deja présent et que la 
> géographie renseigne deja comme faisant un ensemble.
> d'ailleurs à ma connaissance aucun outil n'utilise cette proposition.
> 
> par contre les parking_space sont bien utile, par exemple si on veux 
> affiner pour les places PMR ou simplement comme micromapping
> 
> Cordialement,
> Marc
> 

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

Re: [OSM-talk-fr] micro-mapping de parkings

[Gwenaël Jouvin]

Bonsoir,

Je me permets un commentaire sur cet ajout.

Il me semble qu’il faut connecter les parcs de stationnement à un chemin pour 
un routage correct ?
Osmose crie souvent là-dessus…

Pour symboliser les places de stationnement de manière précise, on peut 
utiliser  et mettre tout ça dans une relation 
 + .

J’ai récemment essayé cette formule :
https://www.openstreetmap.org/relation/8634646
https://www.openstreetmap.org/relation/8671246



Le 11/09/2018 à 12:23, Dlareg a écrit :
> Bonjour,
> 
> Je profite du thread pour soumettre ce que j'ai fait sur le long d'une
> voie :
> https://www.openstreetmap.org/relation/74090#map=19/47.32690/5.03973
> 
> Librement

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

Re: [OSM-talk-fr] Limites de vitesse et incohérences

[Gwenaël Jouvin]

Bonsoir,


Version courte :

Lorsque la signalisation n’est pas conforme, par exemple zone 30 sans panneau 
de fin, je me contente de travailler uniquement sur la route « dans l’axe » du 
panneau et parfois je m’arrête à la grosse intersection suivante car 
l’aménagement sur le terrain n’est pas du tout compatible avec la limitation. 
Ce sont des considérations très subjectives.

Je fais comme Alain, je coupe le chemin et mets un , avec 
éventuellement une note et le  correspondant (car je fais partie 
des dingues qui connaissent les codes ;-) )

À mon avis OSM n’a pas vocation à devenir une carte de la réglementation 
routière et dans ces — trop nombreux — cas douteux, nous n’avons pas à 
extrapoler quelque chose d’inexistant sur le terrain. C’est avant tout au 
conducteur de maîtriser sa conduite.


Astuce : le plugin maxspeed pour JOSM qui permet d’avoir une chouette vision 
sur ce qui est taggé et éviter les trous.



Version longue :

Ah la signalisation, vaste sujet.
Avant toute chose, j’aimerais rappeler que si dans le Code de la route, comme 
dans les lois générales, « tout ce qui n’est pas interdit est autorisé » ; en 
matière de signalisation c’est l’inverse : tout ce qui n’est pas homologué et 
décrit dans l’Instruction interministérielle de la signalisation routière est 
considéré comme non-conforme et donc, interdit.
Ce principe inversé n’est pas explicitement écrit mais transparaît dans 
l’article 2 de l’IISR [1].

En ce qui concerne la signalisation des vitesses maximales autorisées, on 
distingue 3 cas :

— les prescriptions zonales
Les panneaux qui définissent des zones 30 et des zones de rencontre limitent, 
par définition, la vitesse à 30 km/h et 20 km/h respectivement. Les aires 
piétonnes, elles, sont à accès très restreint et imposent l’allure du pas [2].

Dès que l’on franchit un de ces panneaux, on entre dans une « zone » et ils 
n’ont pas à être répétés à chaque intersection. La zone se termine soit par un 
panneau de fin de zone correspondant au panneau d’entrée, soit par un panneau 
d’entrée dans une autre zone [3, art. 63-1 à 63-3].
En conséquence, la vitesse maximale autorisée imposée à l’entrée de la zone 
change lors du franchissement de la frontière de cette zone.

— les prescriptions implicites
Certaines vitesses sont implicites car édictées par des règles générales. 
Ainsi, on ne verra jamais (normalement) de panneau « 50 » en entrée 
d’agglomération puisque c’est le panneau EB10 d’entrée qui porte cette 
prescription [3, art. 63 al. d].
De même, en zone rurale, il n’y a pas lieu de placer des panneaux « 80 » 
puisque cette V.M.A. est définie dans le Code de la route comme valeur par 
défaut [4].

Par contre, il est autorisé, dans certaines circonstances, de rappeler ces 
vitesses maximales autorisées en plaçant le panneau B 14 accompagné d’un 
panonceau « RAPPEL » M 9z [3, art. 64 al. d].

— les prescriptions explicites
Certaines voies présentent une V.M.A. différente du régime général, par exemple 
abaissement à 70 dans la traversée d’un hameau, abaissement à 30 en ville 
devant une école…
Ces indications sont faites par un panneau B 14 indiquant la valeur de vitesse 
à ne pas dépasser.

Cette prescription est annulée de plusieurs manières :
— à l’intersection suivante où, pour être prolongée, un nouveau panneau 
devra être implanté ;
— par un panneau de fin de limitation B 33 ou de fin de prescription B 
31 ;
— de manière implicite.

Ce dernier cas est délicat à interpréter. Il y a eu une question parlementaire 
à ce sujet [5].
La réponse proposée par le ministère des transports est surprenante car si elle 
cite l’art. 68 de l’IISR [3], ce même article parle « d’indication ponctuelle 
évidente » et jamais de ralentisseur, de virage ni de passage à niveau. Parier 
sur les évidences est un jeu dangereux…


Pour m’intéresser au sujet, j’ai eu plusieurs fois à signaler des 
non-conformités de signalisation à des municipalités. À vrai dire, c’est assez 
effarant, il n’y a même pas besoin de chercher pour les trouver — 
particulièrement en matière de signalisation des aménagements cyclables. Forcer 
est de constater que la tâche est considérable et que ce n’est pas 
véritablement un sujet pour les interlocuteurs, services techniques ou élus… On 
trouve alors des panneaux non-homologués, des vieux classiques comme le « sauf 
riverains », des mâts avec 3, 4 voire 5 signaux, des panneaux répétés 3 fois à 
quelques mètres d’intervalle…

Il y a également, je crois, une forte pression des marchands de panneaux qui, 
eux-mêmes, fabriquent des panneaux non-conformes (!) que l’on retrouve un peu 
partout.
Il y a clairement un déficit de l’État dans l’application des règles 
élémentaires de signalisation rappelées au préambule de l’IISR [1], un document 
public pourtant en accès libre.


Le 10/09/2018 à 12:22, djakk djakk a écrit :
> Salut !
> 
> Faut-il aller jusqu’à regarder les arrêtés municipaux ?
> Je vois souvent des débuts de limitation à 30 avant un 

Re: [OSM-talk-fr] OSMAnd et les boîtes aux lettres de la Poste

[Gwenaël Jouvin]

Alors ça c’est une subtilité !

Merci Julien d’avoir cherché et trouvé le problème.
Je vais en avertir les contributeurs contactés, qu’ils puissent se remettre à 
ajouter ces chères boî-boîtes.


Le 06/09/2018 à 10:18, Julien Lepiller a écrit :
> Le 2018-09-05 18:34, Gwenaël Jouvin a écrit :
>> Bonjour,
>>
>> Il y a quelques jours, j’ai remarqué plusieurs contributions avec des
>> ajouts de plusieurs .
>> Étant donné que les boîtes aux lettres privées ne sont pas forcément
>> hyper-prioritaires, j’étais surpris d’en voir autant apparaître.
>>
>> Après un coup de StreetView (je m’en fouette encore ;-) ), mes
>> craintes étaient fondées : c’était bien des boîtes (de dépôt) de la
>> Poste qui avaient la mauvaise valeur de clef.
>>
>> J’ai contacté quelques contributeurs qui ont tous en commun d’avoir
>> OSMAnd en clef  sur le changeset :
>> https://www.openstreetmap.org/changeset/61799892
>> https://www.openstreetmap.org/changeset/61725926
>> https://www.openstreetmap.org/changeset/58855160
>>
>> Je me demande donc s’il n’y a pas un biais, voire une erreur dans le
>> module de contribution de cette application ; je ne peux pas en juger
>> car je ne l’utilise pas pour ça.
>> Si quelqu’un en sait plus sur le sujet…
> 
> En regardant sur l'appli, si on sélectionne le type de POI « boite aux 
> lettres », on obtient un « amenity=letter_box », et si on sélectionne le type 
> de POI « boîte aux lettres », on obtient un « amenity=post_box ». C'est 
> ridicule que la différence se fasse sur un accent, donc je suis allé sur le 
> weblate (https://hosted.weblate.org/projects/osmand/phrases/fr/) pour 
> corriger. Voilà ce qui sera affiché à la prochaine mise à jour :
> 
> boite aux lettres -> post_box
> boite aux lettres privée -> letter_box
> 
> osmand est sensible à la différence entre boite et boîte, donc j'ai aussi 
> ajouté cette variante (si j'ai bien compris, on peut ajouter des variantes en 
> les séparant par des points-virgules).
> 
> N'hésitez pas à corriger si j'ai fait une bêtise !
> 
>>
>> Merci !
>>
>> ___
>> 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

[OSM-talk-fr] OSMAnd et les boîtes aux lettres de la Poste

[Gwenaël Jouvin]

Bonjour,

Il y a quelques jours, j’ai remarqué plusieurs contributions avec des ajouts de 
plusieurs .
Étant donné que les boîtes aux lettres privées ne sont pas forcément 
hyper-prioritaires, j’étais surpris d’en voir autant apparaître.

Après un coup de StreetView (je m’en fouette encore ;-) ), mes craintes étaient 
fondées : c’était bien des boîtes (de dépôt) de la Poste qui avaient la 
mauvaise valeur de clef.

J’ai contacté quelques contributeurs qui ont tous en commun d’avoir OSMAnd en 
clef  sur le changeset :
https://www.openstreetmap.org/changeset/61799892
https://www.openstreetmap.org/changeset/61725926
https://www.openstreetmap.org/changeset/58855160

Je me demande donc s’il n’y a pas un biais, voire une erreur dans le module de 
contribution de cette application ; je ne peux pas en juger car je ne l’utilise 
pas pour ça.
Si quelqu’un en sait plus sur le sujet…

Merci !

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

Re: [OSM-talk-fr] Nom des routes

[Gwenaël Jouvin]

Une petite remarque sur le format de la nomenclature qui apparaît dans les 
cartouches routiers : je suis bien de ton avis de respecter celle communément 
admise, présente sur le terrain et illustrée en annexe 24 de la 5e partie de 
l’IISR [1], soit :
— A pour les autoroutes (blanc sur rouge) ;
— N pour les nationales (idem) ;
— D pour les départementales (noir sur jaune) ;
— C pour les voies communales (noir sur blanc) ;
— R pour les chemins ruraux (idem);
— F pour les routes forestières (blanc sur vert).

On peut y ajouter 2 catégories :
— E pour les itinéraires européens, nomenclature parallèle que l’on voit sur 
certaines autoroutes et peut-être ailleurs (blanc sur vert) ;
— M, qui n’a pas l’air vraiment réglementaire mais fait l’objet d’une 
expérimentation [2], que l’on peut voir à Nice, pour « route métropolitaine » 
(blanc sur cyan).


C’est pour cela que sur les voies communales & chemins ruraux, je crois qu’il 
vaut mieux éviter les usages « VC » et « CR » tout comme on n’utilisera pas « 
RN » ni « RD » voire « CD ».
Par contre, puisqu’il faut toujours une exception, je pense que l’on peut 
utiliser « CE » pour les chemins d’exploitation puisque d’une part ils ne 
semblent pas concernés par la réglementation sur la signalisation et qu’il ne 
faudrait pas les désigner comme des routes européennes.


[1] 
http://www.equipementsdelaroute.equipement.gouv.fr/les-versions-actualisees-a-fevrier-2016-de-l-a442.html
[2] 
http://www.securite-routiere.gouv.fr/la-securite-routiere/actualites/une-nouvelle-signaletique-routiere-pour-les-metropoles-la-signalisation-s-adapte-aux-evolutions-du-reseau-routier


Le 30/08/2018 à 15:40, Jérôme Seigneuret a écrit :
> […]
>> Le cas du voie communale n°12 en ref = c12 ok le nom surement pas. C'est le 
>> cas mentionné ci-dessus.
> pour les ref faut voir pour les autres type de voies avec des ref : *R*ural, 
> *E*xploitation, *F*orestière, (c'est juste ce que j'ai en tête) *Voie *rentre 
> -il en conflit avec les *Route *ou *Chemin* dans la numérotation?
> 
> Normalement ces noms sont remontés dans le cadastre mais comme la gestion est 
> communale, elle doit se trouvé dans les POS , CC et PLU
> qui plus est les PLUI n'ont il pas changer la numérotation des voies vu que 
> cela englobe l'ensemble de L'EPCI???
> 
> Bref le cadastre pour les référence oui mais pour du old_ref...

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

Re: [OSM-talk-fr] Nom des routes

[Gwenaël Jouvin]

… ce message me remémore un point que j’ai oublié dans mon message initial et 
mes excuses pour la digression à venir !

Ce type de nom peut actuellement se retrouver sur les « plaques de cocher » 
qu’il reste parfois aux détour de bâtiments, par exemple « Chemin de Grande 
communication nº0 de X à Y par Z ».
https://fr.wikipedia.org/wiki/Plaque_de_cocher

Bon, ça reste assez artificiel mais ces dénominations peuvent être très 
anciennes, héritées des routes impériales, etc.
Je comprendrais parfaitement que l’on considère ce genre d’info un peu trop 
historique pour entrer dans OSM, d’autant que sur les routes inter-urbaines, 
elle se retrouve peu sur le terrain (contrairement aux voies communales où les 
lieux-dits sont bien réels).

Pour l’anecdote historique, je serais intéressé par des éléments de source sur 
cette numérotation éventuellement due à Michelin. Je sais qu’ils en faisaient 
la pub lorsqu’ils ont lancé l’équipement des routes en signalisation en lave 
émaillée (commencée vers env. 1920 jusqu’à  env. 1970), mais la numérotation 
semble antérieure, comme en attestent les plaques de cocher bien plus anciennes 
que la signalisation Michelin. À moins que cette numérotation n’ait concerné 
que les voies locales, Vo et Ic à l’époque.


Le 29/08/2018 à 19:19, Christian Quest a écrit :
> "Route de X à Y" ?
> 
> Oui, on trouve ce genre de libellés sur le cadastre, mais ce ne sont de mon 
> point de vue que des éléments d'habillage et de contexte (un peu comme les 
> Nord/Sud Est/Ouest sur les lieux-dits).
> 
> Pour moi, ce n'est pas à mettre en name=*, car c'est au mieux une description 
> de l'itinéraire sur laquelle elle se trouve plus qu'autre chose, résidu des 
> noms des "voies de grande communication" avant qu'on ne procède à une 
> numérotation systématique de ces routes (initiée il me semble par Michelin 
> via une pétition).
> 
> Pour les "Route de X" c'est un peu différent car bien souvent ce sont des 
> noms vraiment utilisés sur le terrain, voire même des éléments d'adresses.
> 
> Bien sûr, comme toujours, on a de multiples zones grises et cas particuliers 
> où il est difficile de trancher de façon binaire !

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

[OSM-talk-fr] Nom des routes

[Gwenaël Jouvin]

Bonsoir à toutes & tous,

Parallèlement à la discussion sur les lieux-dits [1], je pense qu’il y a une 
carte à jouer sur le nommage des voies de communication — principalement /hors 
agglomération/, en ville les routes étant connues sous le terme de « rue ».

Si les routes ont généralement une nomenclature sous la clef ref=, elles ont 
aussi un nom que l’on peut renseigner dans name=.
Plusieurs cas se présentent :
— la route a été nommée par la municipalité et ce qualificatif entre 
logiquement dans "name"="Route de …" ;
— la route n’a pas de nom spécifique mais est nommée « administrativement » par 
ses embranchements, information trouvable dans le cadastre : "name"="Route 
départementale nº512 de Saint-Laurent à Sainte-Marie".
Si elle bénéficie de deux noms, je pense que l’info du cadastre, bien que moins 
pertinente, peut tout de même être rangée dans alt_name.

Cependant, cette dernière information peut poser problème lorsque la route est 
une ancienne nationale déclassée. Effectivement, les départements ont 
successivement repris la gestion d’anciennes nationales (au moins en 1972 et en 
2006) [2] et la nomenclature a parfois complètement changé, anéantissant les 
possibilités d’orientation par numéro pourtant si logique. De fait, le nom « 
Route de X à Y », inter-départemental voire inter-régional ; ne colle plus au 
numéro qui est devenu intra-départemental.
On trouve d’ailleurs dans le cadastre des départementales actuelles toujours 
nommées « Route nationale… », donc, méfiance.


Finalement, les noms des voies ont plutôt un intérêt au niveau local et on 
rejoint là le sujet des lieux-dits.
Les voies communales et les chemins ruraux [3], si on ne voit pas 
systématiquement leur nomenclature sur le terrain, sont numérotés et nommés 
dans le cadastre (parfois, l’info est coupée dans le rendu, il faut aller sur 
le site internet officiel).
Le nom de la voie donne parfois une autre orthographe des lieux-dits, ce qui 
peut permettre de trancher.

Je me pose tout de même une question pratique : ces noms sont parfois longs, 
par exemple « Voie communale numéro 5 dite du Lieudit de Bas au Lieudit de Haut 
».
Étant donné que le numéro sera enregistré comme "ref"="C 5", il est possible de 
rendre le nom plus lisible, sous la forme « Voie communale du Lieudit de Bas au 
Lieudit de Haut ». Ça s’intègre mieux à la carte, on évite une redondance 
d’information sans trop dénaturer la source et l’expression est plus lisible 
pour l’utilisateur.

Comme pour leurs grandes sœurs, on privilégiera le nom officiel s’il existe 
dans name= et le nom « cadastral » dans alt_name (ou autre clef ?).


Étant néophyte, j’aimerais connaître vos pratiques sur le sujet.

Merci.


P.S. : certaines routes forment parfois frontière entre deux communes et, 
histoire de simplifier les choses, portent des nomenclatures et des noms 
propres à chacune d’entre-elles.
Je pense que dans ce cas, nous ne pouvons guère que se reposer sur 
ref:[right|left] et name:[right|left], exemple : 
https://www.openstreetmap.org/way/83277707


[1] https://lists.openstreetmap.org/pipermail/talk-fr/2018-August/089765.html
[2] 
http://routes.wikia.com/wiki/Route_nationale_fran%C3%A7aise#Liste_historique_des_routes_nationales_fran.C3.A7aises
[3] 
https://www.legifrance.gouv.fr/affichCodeArticle.do?idArticle=LEGIARTI06582168=LEGITEXT06071367

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

Re: [OSM-talk-fr] Lieux-dits

[Gwenaël Jouvin]

En effet il y a également ce souci de vocabulaire.
J’ai pris l’habitude de nommer « lieu-dit » tout ce qui n’est pas une commune 
ni une rue et indiquer par des panneaux à fond noir ou bleu marine — mais 
parfois aussi par des panneaux à fond crème ou blanc…

Voici ce qu’en dit l’instruction interministérielle sur la signalisation 
routière [1], à son article 83-1 :
« Le panneau D29 est utilisé pour signaler les hameaux, les fermes, les 
lieux-dits isolés […] »


Les valeur de la clef  ne me sont pas toujours aisées à interpréter car 
elles ne reflètent pas toujours précisément les localités que je peux trouver 
dans mon secteur où ce sont, en règle générale :
— des exploitations agricoles étendues avec l’agriculture intensive, qui 
entrent logiquement dans farm, toute considération de surface mise à part ;
— des agglomérations de quelques maisons qui collent assez bien à 
isolated_dwelling — mais quand il y a plusieurs de ces groupes les uns à côté 
des autres, sont-ils encore si « isolated » que ça ?
— des agglomérations d’une dizaine de foyers qui ne rentrent pas dans la 
catégorie précédente mais qui, d’après le wiki, ne sont pas pour autant des 
hamlet (être ou ne pas être…).

Pour ma part, dès que sur la carte je vois un peu plus d’une demi-douzaine de 
maisons, je passe d’isolated_dwelling à hamlet. Ça ne colle pas au carré avec 
le wiki mais comme les limites à se fixer sont spécifiques au lieu concerné, 
j’espère que ce n’est pas pour autant une erreur.


[1] Partie 5, indication : 
http://www.equipementsdelaroute.equipement.gouv.fr/les-versions-actualisees-a-fevrier-2016-de-l-a442.html


Le 28/08/2018 à 23:04, Stéphane Péneau a écrit :
>> […]
>
> Sur cet exemple, ce qu'on voit, ce ne sont pas des lieux-dits, qui sont 
> inhabités et taggés place=locality, mais des "hameaux" qui sont taggés
> place=hamlet ou isolated_dwelling ou farm ou etc...
> 
> Oui, on utilise des mots différents selon sa région d'origine. Par chez moi, 
> un "hameau" c'est appelé "village".
> 
> Stf

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

Re: [OSM-talk-fr] Lieux-dits

[Gwenaël Jouvin]

Je rejoins les derniers messages de mes camarades et, pour illustrer leurs 
réflexions, vous invite à regarder la carte de la commune de la Chaise-Baudouin 
:
https://www.openstreetmap.org/relation/1014724

Bien que détaillée jusqu’aux haies bocagères, elle ne me semble pas pour autant 
illisible, en tous cas comme il a été dit, bien moins qu’en ville où l’on 
trouve pléthore noms de rues, de commerces et de numéros sur le bâti.


Si en ville il reste encore des plaques de rue, en zone rurale les nombreuses 
routes communales ne sont pas systématiquement indiquées puisqu’il n’y a pas 
toujours de panneaux directionnels et que lorsqu’il en existe, il n’ont pas 
forcément de cartouche numéroté.

Dans ces conditions, seuls les lieux-dits apportent une information de 
localisation pertinente. Si la position des panneaux ne préjuge pas de la 
position du lieu-dit puisque le signal est logiquement implanté le long d’une 
voie routière, il donne tout de même un repère essentiel au voyageur… et au 
cartographe.

Des municipalités ont tout de même numéroté des lieux-dits ruraux, parfois en 
renommant des routes avec des noms étranges, pas forcément en lien avec le 
territoire. Je trouve ça regrettable puisque le nom existe déjà depuis des 
lustres et qu’une route rurale ne sera à mon sens jamais une « rue », à moins 
de « construire la ville à la campagne ».
Les numéros peuvent alors être regroupés sous les panneaux, « Le Lieudit, nº7 à 
15 », sans plaque sur les habitations. Si le facteur peut se fier au nom sur 
les boîtes aux lettres, le contributeur OSM, lui, ne peut guère se référer qu’à 
la numérotation du plan cadastral.



Le 28/08/2018 à 13:53, Philippe Verdy a écrit :
> Je ne vois pas en quoi ces lieux-dits sont gênants alors qu'en milieu rural 
> ils sont essentiels au repérage (cherchez les numéros de rue, vous ne les 
> trouverez pas), et pourtant ils sont finalement très peu nombreux (en gros 
> 200 par commune, c'est très loin du nombre d'autres libellés).
> […]
> 
>> Le mar. 28 août 2018 à 11:24, Rpnpif > > a écrit :
>> […]

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

[OSM-talk-fr] Présentation Gwenj

[Gwenaël Jouvin]

Bonsoir à tous,

Nouveau sur cette liste, un rapide message de présentation.

Venu à Openstreetmap par le vélo, c’est maintenant OSM qui m’en fait faire… La 
précision du piéton avec la portée de la voiture ;-)

Plutôt contributeur « de terrain », mes centres d’intérêt ont été, au début, 
les aménagements cyclables ; puis j’ai lentement dérivé vers les « 99% 
invisibles », points d’eau incendie, bornes de gaz & équipements ERDF (merci 
François !) et un fort attrait pour les boîtes aux lettres de la Poste.

En zone rurale, je traite un secteur où il ne semble pas y avoir beaucoup de 
contributeurs. J’ai commencé un inventaire des lieux-dits autour de Brécey, 
bien avancé sur le terrain et en cours de cartographie : 
http://umap.openstreetmap.fr/fr/map/brecey-decoupage_234207
Ça tombe bien puisque vous en parlez en ce moment.
Parallèlement, ce genre de recherche exhaustive permet de vérifier voire 
découvrir des chemins non-remembrés si pratiques pour les randonneurs, 
malheureusement rares, déconnectés, voire délaissés — les chemins, pas les 
randonneurs !

Je suis heureux de retrouver ici des pseudos « croisés » dans l’historique.

À bientôt,


Gwenaël

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