*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.sanspourr...@spamgourmet.com> 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_...@hotmail.com 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 > listTalk-fr@openstreetmap.orghttps://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
