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> 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, > <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 > > <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 > https://lists.openstreetmap.org/listinfo/talk-fr > -- Florimond Berthoux
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
