Aucun avis sur la proposition (pas assez aguerrie, je suis).
En revanche, j'abonde avec le fait qu'on ne peut pas mettre 2x2 panneaux
sur le même nœud, et pourtant sur le terrain, de nombreux panneaux
doubles sont pile face à face sur le bas-côté droit de chaque voie. Et
comme je ne sais pas faire, je n'y ai pas touché dans ma zone.
--
deuzeffe
Le 18/03/2019 à 21:36, Florimond Berthoux a écrit :
Bonjour,
J'ai pas tout suivit, mais visiblement il n'est pas décrit sur le wiki
comment mettre plusieurs panneau sur un même nœud (un même poteau) ?
Chose très courante pourtant.
Il y a un trou dans la spec je dirais.
proposition:
traffic_sign:forward:1=toto
1 étant l'ordre de haut en bas sur le poteau.
Le lun. 18 mars 2019 à 19:24, Bernard Lefrançois
<bernard.lefranc...@free.fr <mailto:bernard.lefranc...@free.fr>> a écrit :
N'oubliez pas que même si le panneau de sortie et celui d'entrée de
la commune suivante sont sur le même support, il s'agit de deux
panneaux distincts.
Si l'on ajoute des attributs il faut savoir de quel panneau on parle.
Même s'il sont sur le même poteau, je placerais deux nœuds
rapprochés avec:
pour la sortie
traffic_sign=city_limit
traffic_sign=FR:EB20
et pour l'entrée
traffic_sign=city_limit
traffic_sign=FR:EB10
Quant au tag name, est-ce vraiment le tag approprié?
Le nom écrit sur la plaque, c'est celui de la commune, pas celui de
la plaque.
Je verrais plutôt le tag inscription=Nomdeville
le wiki est assez large pour l'utilisation de ce tag /(//text of
inscriptions on buildings, memorials, advertising signs and other
objects)/.
Il y aurait bien aussi le champ [value] à placer après l'ID du
panneau, ce qui donnerait:
traffic_sign=FR:EB10[Nomdeville]
mais je ne sait pas si ce champ accepte des valeurs alphabétiques.
*direction* c'est en effet la direction du panneau tel que l'on peut
l'observer. Ce détail existe déjà et est renseigné sur pas mal de panneaux
de type trafic_sign. le fait de modéliser les panneaux sur un point hors du
réseau et aussi un autre modèle de saisie (valide) à condition de
renseigner la direction.
Qui plus est le problème reste le même que pour les intersections de
tronçon. sachant que l'on qualifie la vitesse de toute façon en entrée de
ville en sortie de ville on a forcément un découpage au niveau du nœud
entrée sortie. D'où l'exploitation de cette modélisation.
Du côté left and right, c'est en effet des cas qui existe. dans mon mode de
saisie left and right n'a aucun intérêt. Et du coup c'est la même
problématique avec forward-backward.
le panneau peut être placé à gauche ou à droite de la voirie généralement à
droite pour l'entrée. Mais dans certains cas comme toujours en France il y
a des exceptions. Le panneau peut être a l'opposé.
l'objectif de mettre le panneau d'entrée et de sortie et double étant donné
que ça permet aux collectivités de savoir où est-ce qu'il pourrait manquer
des panneaux de sortie ou des panneaux d'entrée le cas échéant.
les panneaux d'entrée et de sortie sont normalisées donc normalement on
pourrait utiliser la même procédure que pour les trafic_ sign. Garder name
par défaut pour l'entrée
Le lun. 18 mars 2019 à 18:01, <osm.sanspourriel at spamgourmet.com
<https://lists.openstreetmap.org/listinfo/talk-fr>> a écrit :
>/J'aurais aussi laissé l'entrée dans name tout simplement.
/>//>/name:entrance et name:exit, sachant que entrance et exit ne sont
pas des />/codes de langue n'est pas vraiment ambigu mais peut entraîner des
problèmes />/pour les outils d'importation. />//>/name:fr:exit serait le nom en français
de la commune de sortie. />//>/N. B. : contrairement à ce qu'indique Marc ce n'est pas le nom de
la />/commune mais aussi le nom de l'agglomération suivi de "commune de
XXX". />//>/Exemple : https://www.openstreetmap.org/node/3347836570,
Guidel-Plages />/alors qu'il s'agit de la commune de Guidel. />/Ou avec Mapillary :
/>/https://www.mapillary.com/app/?focus=photo&lat=47.79721754166424&lng=-3.4809542&z=17&pKey=RxO4q1ZookumCATmH2Ct3g&x=0.5334449075931347&y=0.3798607750491876&zoom=3
/>/. />/Oui un panneau de lieu-dit suffit mais le maire devait avoir un
tarif sur />/les panneaux ;-). />//>/Remarquez qu'on entre en français et
breton mais on ne sort qu'en
français />/! />//>/D'ailleurs comment entreriez-vous : />//>/Guidel-Plages />/Commune de Guidel
/>/? />//>/Vous laissez tomber "Cne de Guidel" ? />//>/Note : si on ne connait la direction du
panneau, on ne sait si
c'est une />/entrée ou une sortie. Sur le Wiki on n'entre que le nom de
l'agglomération />/dans laquelle on entre. />/> on a donc croisé un panneau
qui a donné son nom />/Et non, ça c'est seulement dans le cas droit où toute route menant
à X a />/son panneau d'entrée. />/Typiquement avec des panneaux indiquant
des sous-parties de la
commune il />/n'est pas évitent que toutes les limites internes soient
indiquées, par />/exemple dans des culs-de-sac. Mais dans ce cas on n'a pas le panneau
/>/d'entrée dans l'autre zone. />/Ceci dit je suis à peu-près sûr d'arriver à entrer
via "Les Cinq
Chemins - />/Cne de Guidel" et à ressortir par "Guidel", il suffit de passer
par des />/petites rues. />//>/Le 18/03/2019 à 16:59, marc marc -
marc_marc_irc at hotmail.com
<https://lists.openstreetmap.org/listinfo/talk-fr> a écrit : />//>/Le 18.03.19 à
16:05, Charles MILLET a écrit : />//>/il me semble qu'il n'y a pas d’ambiguïté donc des
name:* devraient
être bon. />//>/Pourtant name:abc est "name" dans la langue "abc" (ex
name:fr
name:de) />/Dans les zones multilingue, un panneau est parfois multilingue
dont />/multiple name. et un name:abc qui ne se rapport pas à un langue
entre en />/conflit avec cette logique bien établie. />/Je n'ai tjs pas
saisis l'intérêt, mais si on veux vraiment
renseigner />/le nom de la ville qu'on quitte lorsqu'on rentre dans une autre, />/*:name me semble
préférable pour éviter cet ambiguïté. />//>/Et si on veux garder des données utilisable par une majorité
d'app, />/j'aurais gardé la ville entrante dans name tout simplement. />/Au moins les utilisations des
données qui ignorent cet "extension" />/pourront quand même utiliser l'info initiale./
_______________________________________________
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
