Re: [OSM-talk-fr] Tag panneau zone vidéo surveillance ?

[marc marc]

Le 10.02.20 à 23:14, Shohreh a écrit :
> des panneaux qui indiquent qu'une zone est vidéo-surveillée ?

à chaud, j'aurais créé traffic_sign=surveillance
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages

[marc marc]

Bonsoir,

Le 10.02.20 à 21:59, onesim...@free.fr a écrit :
> Je pense qu’on va partir sur des points à proximité de la route, à
> l’emplacement exact du panneau.

je me demande s'il y un logiciel de routage qui l'utilisera

> Il n’est pas possible de mettre 2 fois la même clé par ex. :

si : clef=valeur1;valeur2 (exemple avec la clef cuisine

> donc une alternative et une meilleure manière de le noter est la suivante :
> - traffic_sign=city_limit,FR:EB20.

je comprend pas ce que tu veux dire avec cette totologie.
une limite urbaine est un panneau EB20 et vice-versa.
a-t-on besoin de dire que si on suit le chemin inverse d'une entrée
c'est une sortie ? cela me semble lourd pour un gain qui m’échappe.

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

Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages

[marc marc]

Le 10.02.20 à 22:23, osm.sanspourr...@spamgourmet.com a écrit :
> pour préciser l'ancrage :
> pole_mount=ground ou concrete_slab  à la manière de
> https://wiki.openstreetmap.org/wiki/Key:lamp_mount


lamp_mount est une horreur à ne pas suivre.
support=pole : le panneau est porté par un poteau
support:support=ground : le poteau est directement mis dans le sol
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Tag panneau zone vidéo surveillance ?

[Shohreh]

Bonjour,

Une caméra de vidéo-surveillance dans la rue peut être taggée avec
"man_made=surveillance", mais quid des panneaux qui indiquent qu'une zone
est vidéo-surveillée ?

Ces panneaux ne semblent pas normalisés.

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

Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages

[osm . sanspourriel]

Bonjour,

J'ai un problème avec ça car pour moi le support dans les deux cas c'est
un poteau, donc pole.

Ce qui change c'est l'ancrage : avec ou sans plot béton.

Peut-être :

https://wiki.openstreetmap.org/wiki/Key:support

 * support=ground The feature is directly put on the ground.
 * support=pedestal The feature is supported by a pedestal.

Mais ce n'est pas le panneau, c'est le poteau qui est dans le sol.

Donc pole et pedestal ? Bof pour pedestal.

J'aurais tendance à dire support=pole dans les deux cas.

et pour préciser l'ancrage :
pole_mount=ground ou concrete_slab  à la manière de
https://wiki.openstreetmap.org/wiki/Key:lamp_mount

Jean-Yvon

Le 10/02/2020 à 21:59, onesim...@free.fr a écrit :


Concernant le type de fixation du poteau, que pensez vous de ce qu’on
pensais faire :

- support= post quand le panneau est simplement planté

- support = pole si le panneau est scellé au sol avec du béton

?

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

Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages

[Philippe Verdy]

Ce qui existe réellement c'est la sortie d'une commune et l'entrée dans une
autre, superposés sur le même poteau du même côté droit de la route dans
une direction donnée; et un autre panneau de l'autre côté de la route avec
les deux panneaux de sortie et d'entrée superposés. Dans ce cas il n'y a
habituellement pas de changement de limite de vitesse (cela reste 50 km/h
par défaut avant et après car on reste en agglomération), mais il arrive
aussi qu'un panneau EB10 ou EB20 soit aussi accompagné d'un panneau de
limitation de vitesse différent de la valeur par défaut (par exemple un
30km/h en zone urbaine dense, ou un 70 km/h en agglomération peu dense sur
une départementale avec peu de piétons et de commerce et pas d'écoles, et
qu'il y ait donc là un changement de limite au passage d'une commune à
l'autre: le panneau de limitation de vitesse modifie en priorité le sens du
panneau d'entrée ou sortie d'agglomération dont la limite par défaut est
alors à ignorer).

Le lun. 10 févr. 2020 à 21:59,  a écrit :

> Bonsoir,
>
>
> Je pense qu’on va partir sur des points à proximité de la route, à
> l’emplacement exact du panneau.
>
>
> Si je récapitule :
>
> Il n’est pas possible de mettre 2 fois la même clé par ex. :
>
> - traffic_sign=city_limit
>
> et
>
> - traffic_sign=FR:EB20
>
> donc une alternative et une meilleure manière de le noter est la
> suivante :
>
> - traffic_sign=city_limit,FR:EB20.
>
>
> Même si je doute que l’on ai le panneau d’entrée et de sortie du village
> sur le même poteaux, si ça arrive, on se base sur le sens de création du
> trait, puis on définit si c’est backward ou forward.
>
> traffic_sign:backward=city_limit
> traffic_sign:forward=city_limit
>
>
> Concernant le type de fixation du poteau, que pensez vous de ce qu’on
> pensais faire :
>
> - support= post quand le panneau est simplement planté
>
> - support = pole si le panneau est scellé au sol avec du béton
>
> ?
>
>
> Merci pour votre aide !
>
>
> Bonne soirée, Onesime
>
>
> --
> *De: *"leni" 
> *À: *talk-fr@openstreetmap.org
> *Envoyé: *Lundi 10 Février 2020 18:17:49
> *Objet: *Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de
> villes & villages
>
> Désolé, mon message a été envoyé à la liste au lieu d'à la poubelle
>
> leni
>
>
> ___
> 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] Tagger correctement les panneaux entrées de villes & villages

[onesime31]

Bonsoir, 


Je pense qu’on va partir sur des points à proximité de la route, à 
l’emplacement exact du panneau. 


Si je récapitule : 
Il n’est pas possible de mettre 2 fois la même clé par ex. : 
- traffic_sign=city_limit 
et 
- traffic_sign=FR:EB20 
donc une alternative et une meilleure manière de le noter est la suivante : 
- traffic_sign=city_limit,FR:EB20. 


Même si je doute que l’on ai le panneau d’entrée et de sortie du village sur le 
même poteaux, si ça arrive, on se base sur le sens de création du trait, puis 
on définit si c’est backward ou forward. 
traffic_sign:backward=city_limit 
traffic_ sign:forward=city_limit 


Concernant le type de fixation du poteau, que pensez vous de ce qu’on pensais 
faire : 
- support= post quand le panneau est simplement planté 
- support = pole si le panneau est scellé au sol avec du béton 
? 


Merci pour votre aide ! 


Bonne soirée, Onesime 

- Mail original -

De: "leni"  
À: talk-fr@openstreetmap.org 
Envoyé: Lundi 10 Février 2020 18:17:49 
Objet: Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & 
villages 

Désolé, mon message a été envoyé à la liste au lieu d'à la poubelle 

leni 


___ 
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] Tagger correctement les panneaux entrées de villes & villages

[leni]

Désolé, mon message a été envoyé à la liste au lieu d'à la poubelle

leni


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

Re: [OSM-talk-fr] Proposition de mise à jour : la population des communes

[leni]

Le 10/02/2020 à 12:29, Stéphane Péneau a écrit :

Si je récapitule :

- Vincent lance l'outil aidant la maj de la population sur les 
relations des communes.


- Je soulève l'idée de supprimer le tag "population" des noeuds car ce 
n'est pas cohérent.


- Christian indique qu'il l'utilise

- Discussions sur les différents cas qui se présentent. Avec plusieurs 
propositions de supprimer "population" des noeuds.


- J'indique que si c'est utilisé par le rendu FR, ça bloque un peu ce 
processus.



Dans ma tête, j'en suis resté à l'idée qu'il fallait le conserver pour 
l'instant, et sur les maj que j'ai effectuées, j'ai copié la valeur de 
"population" sur le noeud "admin_centre".


j'ai fait pareil après avoir lu le message de Christian



D'autres sont partis du principe qu'il fallait le supprimer.

Stf


___
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] Tagger correctement les panneaux entrées de villes & villages

[marc marc]

Le 10.02.20 à 16:00, Jérôme Seigneuret a écrit :
> comment matérialiser la face arrière du panneau qui est sur le même poteau 
> Si l'on fait deux point très proches ce qui fera qu'entre les deux
> points on aura 1 mètre hors agglomération?

simplifie toi la vie :-)
2 points soit exactement au même endroit
soit séparé de 1mm (vu que iD par exemple rend très compliqué
la sélection d'un objet précis parmis plusieurs superposés)

OU

traffic_sign:backward=city_limit
traffic_sign:forward=city_limit
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages

[Florimond Berthoux]

Le dim. 9 févr. 2020 à 23:07, onesime31  a écrit :

> Bonsoir,
>
> Ce n'est pas taguer 2 fois le même feature, vu qu'ils sont distingués par
> leur code eb20 ou eb10 qui sont des standards en France.
>
Feature : objet du monde réel que l’on souhaite modéliser dans OSM

Ici le feature c’est le panneau, placer sur deux nœuds traffic_sign=
pour le même panneau c’est tagguer deux fois le même panneau, c’est dire
qu’il y a deux panneaux.

Pour avoir les deux info sur le même nœud j’ai peut-être une solution :
traffic_sign=city_limit,FR:EB20
https://wiki.openstreetmap.org/wiki/Key:traffic_sign#Traffic_sign_IDs
« If traffic signs are related, the additional sign IDs should be separated
from the main sign by comma , »


> Pour le forward ou backward, comment différenciez vous le sens? !
> Encore une fois, c'est un département rural,  et ce sont majoritairement
> des villages, traversés par une simple voie à double sens, sans marquage au
> sol.
>
> Bonne soirée
>
>  Message d'origine 
> De : Florimond Berthoux 
> Date : 09/02/2020 21:06 (GMT+01:00)
> À : Discussions sur OSM en français 
> Objet : Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de
> villes & villages
>
> Bonsoir,
>
> Non il ne faut pas tagguer deux fois la même feature (bonjour la cohérence
> des données et la maintenance).
> Si on veut être sympa pour le routeur on met le nœud sur le way de la
> route avec:
> traffic_sign:forward=city_limit
> traffic_sign:backward=city_limit
> à la hauteur du panneau de début ou de fin d'agglomération.
> Attention le forward et le backward se réfère au sens du way dans le quel
> le panneau est lu.
>
> https://wiki.openstreetmap.org/wiki/FR:Key:traffic_sign#Sur_un_way_ou_une_zone_.28area.29
>
> Le dim. 9 févr. 2020 à 17:38, David Marchal  a écrit :
>
>>
>>
>> > Le 9 févr. 2020 à 13:43, onesime31  a écrit :
>> >
>> >
>> > Bonjour,
>> Bonsoir.
>>
>> >
>> > Nous avons un projet avec une classe de géomaticiens en formation.
>> > On a une commande et on aimerait faire cela en utilisant OSM, faire une
>> cartoparty dans le cadre de leur formation. La commande est de
>> cartographier les entrées et sorties de villes et villages.
>> >
>> > Pour le panneau d'entrée de village, voici le key et le value qu'on
>> pensait utiliser: traffic_sign=city_limit
>> > à priori, il n'y a pas possibilité de préciser si c'est le panneau
>> d'entrée ou de sortie du village?
>> > On peut les distinguer via le code EB10 et EB20...  est ce une bonne
>> manière de référencer comme cela:
>> > - traffic_sign=city_limit
>> > - traffic_sign=FR:EB20
>> > ?
>> À mon avis, il vaudrait mieux garder la convention de mettre un nœud
>> traffic_sign=city_limit sur la route, à l’endroit où le panneau est placé,
>> car ça permet aux utilisateurs des données de savoir, par exemple, à partir
>> de quel point les règles de circulation en agglomération s’appliquent. En
>> revanche, ça n’empêche pas de placer un autre nœud traffic_sign=FR:EB20 à
>> l’emplacement précis du panneau, et sans lien avec la route. Faire les deux
>> fait plus de travail, mais au moins tout le monde est content.
>>
>
> --
> Florimond Berthoux
> ___
> 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

Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages

[Christian Quest]

Le 10/02/2020 à 12:30, leni a écrit :


Il me semble que si on lit la version anglaise 
https://wiki.openstreetmap.org/wiki/Tag:traffic_sign%3Dcity_limit :


direction=* should be specified. The traffic sign should be faced when 
you drive into the city.


on ne regarde que le sens du tronçon qui va vers la commune


Avec direction=* indiqué, c'est mieux, mais ça complique pas mal les 
réutilisations.


La modélisation c'est essentiellement un processus pour que des données 
puissent être facilement réutilisées par une machine sans avoir à faire 
des analyses spatiales complexes. Pour ce type de choix il faut donc 
avoir aussi (avant tout ?) la réutilisation automatisée en tête.


Le forward/backward à la jointure de plusieurs way me semble exploitable 
si les ways vont dans le même sens. Il faudrait vérifier que les 
éditeurs mettent bien à jour les forward/backward dans le cas où le 
noeud est terminal. Je viens de vérifier, JOSM le gère comme il faut.


Il manque par contre une analyse pour détecter les incohérences quand on 
a deux ways de directions opposées.



--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages

[Jérôme Seigneuret]

Soit  || mon panneau à deux faces

cas A
---> || <---
cas B
<---  || <---
cas C
 <--- || --->
Si l'on ne prend que la géométrie en bout de noeud le forward backward va
avoir un problème

sens normal de circulation -->  direction à prendre en compte pour le
vecteur du panneau   <--- ||

comment matérialiser la face arrière du panneau qui est sur le même poteau
Si l'on fait deux point très proches ce qui fera qu'entre les deux points
on aura 1 mètre hors agglomération?

Ca c'est dans le schéma où l'on matérialise le panneau sur le réseau

L'autre solution c'est de dissocié les points d'entrée du réseau pour les
mettre à leur implantation réelle. Cela ne fix pas de problème de double
faces mais traite le problème de topologie.
C'est le même problème au final que pour les panneaux de destination mais
pour les destinations de ce type il me semble que c'est mis dans une
relation

face A face B
\   \
 \ ° \
   \   \
direction pour A = 240
  direction pour B = 60

L'avantage de prendre l'angle c'est qu'on se dissocié du problème de sens
de circulation

Si l'on met ça dans une relation on se retrouve avec la possibilité de
mettre ce que l'on veut sur le point concerné et de respecter le sens
d'entrée sortie avec from via to


Le lun. 10 févr. 2020 à 15:37, Jérôme Seigneuret <
jerome.seigneu...@gmail.com> a écrit :

> e
>
> Le lun. 10 févr. 2020 à 13:38, marc marc  a
> écrit :
>
>> Le 10.02.20 à 12:30, leni a écrit :
>> > https://wiki.openstreetmap.org/wiki/Tag:traffic_sign%3Dcity_limit :
>> >
>> > direction=* should be specified. The traffic sign should be faced when
>> > you drive into the city.
>> >
>> > on ne regarde que le sens du tronçon qui va vers la commune
>>
>>
>   En effet sauf quand ton panneau sert à la fois à l'entrée de deux
> agglomérations et à la sortie de ces même agglomération. Dans ce cas il
> faut bien choisir un sens et son opposé
>
>

-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages

[Jérôme Seigneuret]

e

Le lun. 10 févr. 2020 à 13:38, marc marc  a
écrit :

> Le 10.02.20 à 12:30, leni a écrit :
> > https://wiki.openstreetmap.org/wiki/Tag:traffic_sign%3Dcity_limit :
> >
> > direction=* should be specified. The traffic sign should be faced when
> > you drive into the city.
> >
> > on ne regarde que le sens du tronçon qui va vers la commune
>
>
  En effet sauf quand ton panneau sert à la fois à l'entrée de deux
agglomérations et à la sortie de ces même agglomération. Dans ce cas il
faut bien choisir un sens et son opposé
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages

[marc marc]

Le 10.02.20 à 12:30, leni a écrit :
> https://wiki.openstreetmap.org/wiki/Tag:traffic_sign%3Dcity_limit :
> 
> direction=* should be specified. The traffic sign should be faced when
> you drive into the city.
> 
> on ne regarde que le sens du tronçon qui va vers la commune

bien vu... ce serrait à tester si les apps s'en sorte lorsque les 2 way
ont une direction opposée.

>> On reste à la merci d'un contributeur qui retournerait ultérieurement
>> le(s) way(s) pour une raison ou une autre (aménagement latéral
>> disymétrique...) et qui n'aurait pas conscience de l'impact sur les
>> panneaux entré/sortie.

tu as constaté ce cas ? si oui tu te souviens de sa localisation ?
c'est le genre de chose qu'il faut remonter aux éditeurs, c'est pas à
l'humain de passer en revue tous les noeuds d'un way pour les inverse.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages

[Philippe Verdy]

on peut toujours placer le noeud en position non terminale avec un petit
écart (la signalisation routière de toute façon impose au minimum 50 mètres
de visibilité, dans cette distance on peut placer le noeud facilement même
si on le décale de 50 centimètres), pour couper ensuite au changement de
maxspeed; dans ce cas, "forward" et "backward" marchent ("opposite" aussi,
car cela nécessite aussi une direction du way en sens unique).

Personnellement je pense que ces noeuds de panneaux devraient être hors de
la voie et à leur place réelle à côté de la chaussée, et une frontière
"boundary=urban" passera par ce noeud panneau. Il n'y a alors plus
d'ambiguité et peu importe où les voies sont découpées. C'est la solution
la plus propre.

On peut discuter du tag "boundary=urban" pour ces relations qui existent
déjà mais ne tiennent pas compte des limites communales dans la même
agglomération, où il ne me semble pas utile de créer des relations
limitrophes reprenant les frontières communales (ce qui n'empêche pas pour
autant de placer des noeuds de panneaux à coté des voies, même si aucune
frontière "boundary=urban" ne passe dessus, ni même la frontière
"boundary=adminsitrative".

Les noeuds ensuite peuvent être orientés vers la voie pour indiquer leur
face visible depuis la voie concernée. un tag avec une direction angulaire
approximative (points cardinaux ou intercardinaux devrait suffire et pour
les cas où il y a plusieurs rues candidates proches).


Le lun. 10 févr. 2020 à 09:00, Jérôme Seigneuret <
jerome.seigneu...@gmail.com> a écrit :

> Dans les archives j'avais abordé le problème sur les panneaux en double
> face.
> On a aussi le problème lié à la topologie car si le panneaux est placé sur
> le noeud terminal des deux voies la notion de forward backward ne peux pas
> fonctionner
>
> Exemple 1 : changement de nom de rue
>   entrée
> et sortie
>d'agglomération
> [===]°[]
>rue A rue B
>
> Exemple 2 : changement de nom de rue
>   entrée
> et sortie
>d'agglomération
> [===]°[]
>   rue A rue A
>  vitesse 30km/hvitesse 50km/h
>
> Et autant de cas qui fond que forward et backward ça ne peut dans certains
> cas ne pas marcher
>
> Après une des solutions que j'avais pas envisager à l'époque c'est
> d'utiliser opposite
>
> la notion de direction peut être mentionné avec un angle en degré en
> partant du nord à 0
> L'angle permet de définir la direction de la face visible
>
>
> Le lun. 10 févr. 2020 à 01:48, Philippe Verdy  a écrit :
>
>> Quasiment toutes les communes ont au moins une agglomération (sauf les
>> rares communes sans habitants). le mot "agglomération" au sens des panneaux
>> EB10 et EB20 existe donc aussi en milieu rural (autant que de villages dans
>> la commune, mais même en milieu rural on a des villages à cheval sur plus
>> d'une commune, le plus souvent autour d'un pont sur une rivière frontière,
>> ou autour d'un carrefour avec une des routes faisant frontière: c'est ce
>> carrefour, ce pont, et l'activité qui s'est développée autour qui a conduit
>> à ces villages multicommunes, au départ peut-être juste un corps de ferme
>> ou une usine, ensuite les dépendances, habitations ou commerces qui se sont
>> ajoutés, justement du fait de la facilité d'accès et du passage local
>> important).
>>
>> "Agglomération" ne signifie pas grande ville : même un hameau de moins de
>> 100 âmes peut être une agglomération formant un ilôt urbanisé dans la
>> commune rurale. Un très grand nombre de communes rurales ont plusieurs
>> agglomérations, une d'elle étant le "bourg" centre et ayant donné son nom à
>> la commune, mais pas toujours (une agglo excentrée peut être aujourd'hui
>> plus peuplée et plus dense que le bourg centre historique, notamment en
>> frontière d'une autre commune voisine beaucoup plus urbanisée et ayant
>> étendu son agglomération sur la commune rurale voisine).
>>
>> "Agglomération" ne signifie donc pas non plus "commune".
>>
>>
>> Le dim. 9 févr. 2020 à 22:59, onesime31  a écrit :
>>
>>> Bonsoir,
>>> Merci pour votre réponse.
>>> Ce serait pour un département rural qui n'a pas d'agglomération... donc
>>> je parlais surtout des panneaux des entrées de village, et de quelques
>>> villes.
>>>
>>> Bonne soirée
>>>
>>>
>>>
>>>  Message d'origine 
>>> De : Philippe Verdy 
>>> Date : 09/02/2020 15:53 (GMT+01:00)
>>> À : Discussions sur OSM en français 
>>> Objet : Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de
>>> villes & villages
>>>
>>> Un ennui : l'entrée d'une commune et la sortie d'une autre peuvent être
>>> au même emplacement (même poteau support) dans le cas d'une frontière
>>> communale au sein d'une même agglomération.
>>> Ce qui a été déjà fait dans certaines agglomération pour les distinguer
>>> c'est de créer des boundary=urban, passant par ces 

Re: [OSM-talk-fr] Proposition de mise à jour : la population des communes

[marc marc]

Le 10.02.20 à 12:29, Stéphane Péneau a écrit :
> - Christian indique qu'il l'utilise

j'ai beau relire le message de Christian à propos du rendu fr [1],
je ne sais toujours pas qu'est ce qu'il disait d'autre que "le rendu fr
l'utilise"
- était-ce juste une information neutre ? c'est ce qu’apparemment la
majorité à compris (comme dire "j'ai un rendu des bâtiments ne dit rien
s'il faut garder ou supprimer des bâtiments fantaisistes)
- est-ce une demande de temps pour analyser + en profondeur ?
- est-ce favorable à la suppression des données erronées afin
d'augmenter en qualité ?
- est-ce favorable à garder des données parfois fausses d'un facteur 3
parce que le rendu est + joli que sans la donnée ?
un peu comme une façon de faire des place=* intermédiaire

bref, on a foiré mais + sur la comm que sur le fond.
et sur le fond, on fait quoi ? comment sortir par le haut ?
- dupliquer la population communale sur l'unique place=* habité d'une
commune me parait (bof) mais réaliste si on confie la tâche
à un bot (et d'inévitable temps humain pour traiter les anomalies
détectées par osmose)
- pour les communes multi place=* habités, les catégories actuelles ne
suffisent pas à détecter l'écart ? sinon il n'y a pas de source
pour mettre une valeur permettant de les départager ?
- un exemple de rendu avant/après pour montrer un exemple réel ?
ou c'est juste un problème théorique ?

[1]
https://lists.openstreetmap.org/pipermail/talk-fr/2020-January/096266.html
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages

[leni]

Le 10/02/2020 à 12:16, Eric SIBERT via Talk-fr a écrit :
Je dirais que quasi-systématiquement, il y a rupture des ways au 
niveau du panneau d'entrée/sortie d'agglomération parce que les 
limites de vitesse changent généralement de part et d'autre (ou au 
moins le source:maxspeed=*, ou le nom de rue si on saute d'une commune 
urbaine à l'autre...).


Le 10/02/2020 à 10:34, osm.sanspourr...@spamgourmet.com a écrit :

Peut ne pas fonctionner et non ne peut pas fonctionner.

Il faut pour que ça ne marche pas que les voies soient tracées en 
sens opposé.


En général on peut retourner une voie.

[===>]°[>]
        rue A                     rue B
Pas de soucis.

[===>]°[<]
        rue A                     rue B
Soucis. Retourner l'une des voies résout le problème.


Il me semble que si on lit la version anglaise 
https://wiki.openstreetmap.org/wiki/Tag:traffic_sign%3Dcity_limit :


direction=* should be specified. The traffic sign should be faced when 
you drive into the city.


on ne regarde que le sens du tronçon qui va vers la commune



On reste à la merci d'un contributeur qui retournerait ultérieurement 
le(s) way(s) pour une raison ou une autre (aménagement latéral 
disymétrique...) et qui n'aurait pas conscience de l'impact sur les 
panneaux entré/sortie.

oui, et c'est dommage


Eric

___
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] Proposition de mise à jour : la population des communes

[Stéphane Péneau]

Si je récapitule :

- Vincent lance l'outil aidant la maj de la population sur les relations 
des communes.


- Je soulève l'idée de supprimer le tag "population" des noeuds car ce 
n'est pas cohérent.


- Christian indique qu'il l'utilise

- Discussions sur les différents cas qui se présentent. Avec plusieurs 
propositions de supprimer "population" des noeuds.


- J'indique que si c'est utilisé par le rendu FR, ça bloque un peu ce 
processus.



Dans ma tête, j'en suis resté à l'idée qu'il fallait le conserver pour 
l'instant, et sur les maj que j'ai effectuées, j'ai copié la valeur de 
"population" sur le noeud "admin_centre".

D'autres sont partis du principe qu'il fallait le supprimer.

Stf


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

Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages

[Eric SIBERT via Talk-fr]

Je dirais que quasi-systématiquement, il y a rupture des ways au niveau 
du panneau d'entrée/sortie d'agglomération parce que les limites de 
vitesse changent généralement de part et d'autre (ou au moins le 
source:maxspeed=*, ou le nom de rue si on saute d'une commune urbaine à 
l'autre...).


Le 10/02/2020 à 10:34, osm.sanspourr...@spamgourmet.com a écrit :

Peut ne pas fonctionner et non ne peut pas fonctionner.

Il faut pour que ça ne marche pas que les voies soient tracées en sens 
opposé.


En général on peut retourner une voie.

[===>]°[>]
        rue A                     rue B
Pas de soucis.

[===>]°[<]
        rue A                     rue B
Soucis. Retourner l'une des voies résout le problème.


On reste à la merci d'un contributeur qui retournerait ultérieurement 
le(s) way(s) pour une raison ou une autre (aménagement latéral 
disymétrique...) et qui n'aurait pas conscience de l'impact sur les 
panneaux entré/sortie.


Eric

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

Re: [OSM-talk-fr] OSM :: Ateliers au lycée.

[Jacques Lavignotte]

Merci Vincent et Cedric.

Je vous tiens informé des suites possibles lors de :


https://emf.fr/34306

Jacques


Le 10/02/2020 à 11:39, Jacques Lavignotte a écrit :

Bonjour,

je ne retrouve pas le thread dans lequel il était question des ateliers 
OSM dans l'EducNat (lycée).


Voulez-vous me diriger vers les infos relatives aux « recommandations et 
bonnes pratiques » à transmettre aux enseignants qui voudraient se 
lancer, ainsi que les tetxes officiels.


merci, Jacques


--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

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

Re: [OSM-talk-fr] OSM :: Ateliers au lycée.

[Cédric Frayssinet]

Bonjour,

Le 10/02/2020 à 11:39, Jacques Lavignotte a écrit :
>
> je ne retrouve pas le thread dans lequel il était question des
> ateliers OSM dans l'EducNat (lycée).
>
> Voulez-vous me diriger vers les infos relatives aux « recommandations
> et bonnes pratiques » à transmettre aux enseignants qui voudraient se
> lancer, ainsi que les tetxes officiels.
>
> merci, Jacques

Je pense que c'est cet article dont tu parles :
https://dane.ac-lyon.fr/spip/Les-bonnes-pratiques-pour

Quant au programme, il est là :
https://cache.media.education.gouv.fr/file/SP1-MEN-22-1-2019/08/5/spe641_annexe_1063085.pdf

J'aimerai aussi écrire un article sur "Organiser une cartopartie avec
ses élèves". J'en suis à ma 2ème, ce n'est pas forcément évident,
surtout quand les élèves font de petites erreurs :)

Cédric

-- 

Sur Mastodon : @bristow...@framapiaf.org 

Promouvoir et soutenir le logiciel libre 

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

Re: [OSM-talk-fr] OSM :: Ateliers au lycée.

[Vincent Bergeot]

Le 10/02/2020 à 11:39, Jacques Lavignotte a écrit :

Bonjour,

je ne retrouve pas le thread dans lequel il était question des 
ateliers OSM dans l'EducNat (lycée).


Voulez-vous me diriger vers les infos relatives aux « recommandations 
et bonnes pratiques » à transmettre aux enseignants qui voudraient se 
lancer, ainsi que les tetxes officiels.



https://dane.ac-lyon.fr/spip/Les-bonnes-pratiques-pour



merci, Jacques


avec plaisir

--
Vincent Bergeot


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

[OSM-talk-fr] OSM :: Ateliers au lycée.

[Jacques Lavignotte]

Bonjour,

je ne retrouve pas le thread dans lequel il était question des ateliers 
OSM dans l'EducNat (lycée).


Voulez-vous me diriger vers les infos relatives aux « recommandations et 
bonnes pratiques » à transmettre aux enseignants qui voudraient se 
lancer, ainsi que les tetxes officiels.


merci, Jacques
--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

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

Re: [OSM-talk-fr] Proposition de mise à jour : la population des communes

[osm . sanspourriel]

Le 10/02/2020 à 11:10, Vincent de Château-Thierry - osm.v...@free.fr a
écrit :


- j'étais totalement en phase avec la remarque/proposition de Stéphane dans le 
droit fil des suppressions de tag ref:INSEE qui n'ont pas fait hurler que je 
sache (alors que 'est bien pratique d'avoir ce tag sur les place=*)


J'avais eu une remarque d'un contributeur (qui qui s'en servait pour
lier des données de l'Eurométropole de Lille et les republier en OD avec
citations des sources et de la licence ^^).

Vu le commentaire de ma modification :Deleting ref:INSEE from ways in
France. This changeset was discussed on talk-fr :
https://lists.openstreetmap.org/pipermail/talk-fr/2019-November/094947.html
 il avait lu la
discussion et cherchait juste un moyen de faire sans.

Donc oui, expliquer c'est important.

Non seulement ici et sur le wiki mais aussi comment par exemple faire en
sorte qu'un prétraitement permette de mettre les population= sur les
nœuds à partir des relations admin_level=8 si c'est plus simple pour
utiliser les données.

N. B. : lors de la discussion précédente je n'avais pas compris qu'on
supprimait ref:INSEE sur les nœuds mais comme là encore c'était de
l'information redondante.


* 6 utilisations de population=* sur place=* dans le rendu FR... je
ne sais pas exactement quel impact ça va avoir sur les tuiles.

Reims sera écrit plus petit / plus tard que Châlons-en-Champagne, idem pour 
Brest par rapport à Quimper


A priori les place= (absent sur Brest et Quimper) pourraient aussi être
utilisés.

Jean-Yvon

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

Re: [OSM-talk-fr] Proposition de mise à jour : la population des communes

[Vincent de Château-Thierry]

Bonjour,

> De: "Christian Quest" 
> 
> Ce que je regrette c'est qu'on décide parfois beaucoup trop
> facilement (et localement) de changements qui peuvent avoir des impacts non
> négligeables pour les réutilisateurs des données.

C'est bien de prendre le point de vue du client. Tu as en effet pointé l'impact 
possible sur le rendu FR, mais j'avoue qu'à aucun moment je n'ai pris ce point 
comme problématique, pour plusieurs raisons :
- le tag population est déjà largement utilisé sur les relations 
administratives : 10 selon Taginfo, donc quand même 7 hors France. Donc 
pour utiliser cette info mondialement il faut déjà aller la pêcher sur les 
nodes et les relations 
- la population sur les relations se constatait déjà en France *avant* de 
proposer le chantier de màj 2020, au point que pour BANO j'avais adapté le 
contenu de ma base de référence [1] pour en tenir compte 
- j'étais totalement en phase avec la remarque/proposition de Stéphane dans le 
droit fil des suppressions de tag ref:INSEE qui n'ont pas fait hurler que je 
sache (alors que 'est bien pratique d'avoir ce tag sur les place=*)
- que la modélisation des populations ne puisse pas être homogène au niveau 
Monde n'a rien d'étonnant, il faut plutôt prendre ce point comme un élément de 
complexité associé aux découpages administratifs, cf ce tableau où chaque pays 
a sa propre implémentation : 
https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative#10_admin_level_values_for_specific_countries
 Les unités de recensement n'ont aucune chance d'être homogènes d'un pays à 
l'autre donc imposer une modélisation unique de la population est au mieux 
acrobatique au pire un non sens. 

> Qui a regardé sur taginfo où les population=* se trouvaient
> majoritairement ? 85% sont sur les place=*, il est donc normal que
> les réutilisateurs les attendent là aujourd'hui même si pour la beauté de
> la modélisation ce n'est pas parfait.

Oui mais non, cf plus haut : si tu ignores à l'échelle du monde les 100k infos 
de populations sur les relations tu rates un truc... Pour moi c'est un 
non-débat au même titre que les schémas d'adresse entre noeud et relation : si 
tu focalises sur juste un des deux schémas tu passes à côté d'une part 
importante de l'info, donc il *faut* adapter la consommation à cette 
modélisation à multiples facettes. 

> * 6 utilisations de population=* sur place=* dans le rendu FR... je
> ne sais pas exactement quel impact ça va avoir sur les tuiles.

Reims sera écrit plus petit / plus tard que Châlons-en-Champagne, idem pour 
Brest par rapport à Quimper

Pour conclure : je pense que le souci aujourd'hui est moins un souci de 
modélisation que d'information préalable, pas forcément pour demander l'avis de 
la terre entière sur la cohérence de notre modélisation mais pour *annoncer* 
cette mise en cohérence. Je rejoins Marc quand il suggère une action en 2 temps 
:
- ajout (ici de la pop sur les relations) et annonce de la future suppression 
(ici sur les noeuds) dans un délai X. Annonce mondiale tant qu'à faire (talk, 
tagging)
- à l'issue du délai X, suppression sur les noeuds

vincent

[1] : https://github.com/osm-fr/bano/blob/packaging/bano.yml#L118-L119 issu de 
https://github.com/osm-fr/bano/commit/1ba36ac827757ac8f58cd4d4f11b6ba4680c9c95#diff-f7f0660e9aaf13a75255370b85ec6dc2R112-R113

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

Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages

[osm . sanspourriel]

Peut ne pas fonctionner et non ne peut pas fonctionner.

Il faut pour que ça ne marche pas que les voies soient tracées en sens
opposé.

En général on peut retourner une voie.

[===>]°[>]
       rue A                     rue B
Pas de soucis.

[===>]°[<]
       rue A                     rue B
Soucis. Retourner l'une des voies résout le problème.

Jean-Yvon

Le 10/02/2020 à 08:59, Jérôme Seigneuret - jerome.seigneu...@gmail.com a
écrit :

Dans les archives j'avais abordé le problème sur les panneaux en
double face.
On a aussi le problème lié à la topologie car si le panneaux est placé
sur le noeud terminal des deux voies la notion de forward backward ne
peux pas fonctionner

Exemple 1 : changement de nom de rue
                      entrée
                    et sortie
               d'agglomération
[===]°[]
       rue A                     rue B

Exemple 2 : changement de nom de rue
                      entrée
                    et sortie
               d'agglomération
[===]°[]
      rue A                     rue A
 vitesse 30km/h  vitesse 50km/h

Et autant de cas qui fond que forward et backward ça ne peut dans
certains cas ne pas marcher

Après une des solutions que j'avais pas envisager à l'époque c'est
d'utiliser opposite

la notion de direction peut être mentionné avec un angle en degré en
partant du nord à 0
L'angle permet de définir la direction de la face visible


Le lun. 10 févr. 2020 à 01:48, Philippe Verdy mailto:ver...@gmail.com>> a écrit :

Quasiment toutes les communes ont au moins une agglomération (sauf
les rares communes sans habitants). le mot "agglomération" au sens
des panneaux EB10 et EB20 existe donc aussi en milieu rural
(autant que de villages dans la commune, mais même en milieu rural
on a des villages à cheval sur plus d'une commune, le plus souvent
autour d'un pont sur une rivière frontière, ou autour d'un
carrefour avec une des routes faisant frontière: c'est ce
carrefour, ce pont, et l'activité qui s'est développée autour qui
a conduit à ces villages multicommunes, au départ peut-être juste
un corps de ferme ou une usine, ensuite les dépendances,
habitations ou commerces qui se sont ajoutés, justement du fait de
la facilité d'accès et du passage local important).

"Agglomération" ne signifie pas grande ville : même un hameau de
moins de 100 âmes peut être une agglomération formant un ilôt
urbanisé dans la commune rurale. Un très grand nombre de communes
rurales ont plusieurs agglomérations, une d'elle étant le "bourg"
centre et ayant donné son nom à la commune, mais pas toujours (une
agglo excentrée peut être aujourd'hui plus peuplée et plus dense
que le bourg centre historique, notamment en frontière d'une autre
commune voisine beaucoup plus urbanisée et ayant étendu son
agglomération sur la commune rurale voisine).

"Agglomération" ne signifie donc pas non plus "commune".


Le dim. 9 févr. 2020 à 22:59, onesime31 mailto:onesim...@free.fr>> a écrit :

Bonsoir,
Merci pour votre réponse.
Ce serait pour un département rural qui n'a pas
d'agglomération... donc je parlais surtout des panneaux des
entrées de village, et de quelques villes.

Bonne soirée



 Message d'origine 
De : Philippe Verdy mailto:ver...@gmail.com>>
Date : 09/02/2020 15:53 (GMT+01:00)
À : Discussions sur OSM en français mailto:talk-fr@openstreetmap.org>>
Objet : Re: [OSM-talk-fr] Tagger correctement les panneaux
entrées de villes & villages

Un ennui : l'entrée d'une commune et la sortie d'une autre
peuvent être au même emplacement (même poteau support) dans le
cas d'une frontière communale au sein d'une même agglomération.
Ce qui a été déjà fait dans certaines agglomération pour les
distinguer c'est de créer des boundary=urban, passant par ces
panneaux indicateurs.

Mais "boundary=urban" ne traite pas encore ces cas de
frontières communales intra-agglomération où c'est la
frontière communale (boundary=administrative et
admin_level<=8) qui tient lieu de limite. Et il reste aussi
des cas de frontières au sein des communes nouvelles (ou
associations de communes), entre les communes déléguées ou
associées (admin_level=9), où la toponymie de chaque commune
déléguée (ou associée) est conservée (même si les panneaux
annotent en dessous et plus petits caractères "(Commune de
)".

Le "boundary=urban" est surtout destiné à limiter les
frontières d'agglomération pour la régulation routière: le
tracé des contours reste approximatif (pas exactement sur les
limites de propriétés) mais passe par des points précis sur
les voies publiques où ces panneaux limites d'agglomération
  

Re: [OSM-talk-fr] Proposition de mise à jour : la population des communes

[Christian Quest]

Le 09/02/2020 à 22:12, marc marc a écrit :

Le 09.02.20 à 18:59, Christian Quest a écrit :

Le 09/02/2020 à 18:34, Stéphane Péneau a écrit :

Je vois des discussions et des changesets avec des suppressions du tag
"population" sur le node "admin_centre"


J'avoue que ces changements massifs, nationaux,
précipités ne me plaisent guère.

c'était p'tre précipité sur les détails (formulation de la source et de
la date)
cela aurait mérité d'être diviser en 2 pour traiter séparement les 2
(maj de la population communale <> erreur d'objet sur le place=*)
mais garder une commune de X habitants avec plus d'un place=* de X
c'est loin d'être une bonne chose
mais tu met 3 semaines à réagir, cela n'aide pas non plus
https://lists.openstreetmap.org/pipermail/talk-fr/2020-January/096261.html

Marc qui doit encore faire son édition de masse qui n'a pas reçu
d'objection depuis de nombreux mois.


Je n'ai pas mis 3 semaines à réagir mais 6 minutes pour indiquer au 
moins un impact* que pouvait avoir le déplacement du tag suggéré non pas 
initialement par Vincent mais par Stéphane.


Dans les mises à jour que j'ai fait avec l'outil de Vincent, je n'ai pas 
retiré le population=* sur les place=*


Ce que je regrette c'est qu'on décide parfois beaucoup trop facilement 
(et localement) de changements qui peuvent avoir des impacts non 
négligeables pour les réutilisateurs des données.


Qui a regardé sur taginfo où les population=* se trouvaient 
majoritairement ? 85% sont sur les place=*, il est donc normal que les 
réutilisateurs les attendent là aujourd'hui même si pour la beauté de la 
modélisation ce n'est pas parfait.


La recherche de perfection dans la modélisation et la cohérence peut 
parfois rendre compliqué la contribution et la réutilisation des 
données. Allons-y molo car on remonte la marche à l'entrée pour les 
contributeurs et on décourage potentiellement les réutilisateurs avec 
l'instabilité que cela engendre.


Prenons donc à l'avenir un peu plus de recul (en discuter ailleurs 
qu'uniquement sur talk-fr) et de temps avant des modifications de ce niveau.



* 6 utilisations de population=* sur place=* dans le rendu FR... je ne 
sais pas exactement quel impact ça va avoir sur les tuiles.


--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages

[Jérôme Seigneuret]

Dans les archives j'avais abordé le problème sur les panneaux en double
face.
On a aussi le problème lié à la topologie car si le panneaux est placé sur
le noeud terminal des deux voies la notion de forward backward ne peux pas
fonctionner

Exemple 1 : changement de nom de rue
  entrée
et sortie
   d'agglomération
[===]°[]
   rue A rue B

Exemple 2 : changement de nom de rue
  entrée
et sortie
   d'agglomération
[===]°[]
  rue A rue A
 vitesse 30km/hvitesse 50km/h

Et autant de cas qui fond que forward et backward ça ne peut dans certains
cas ne pas marcher

Après une des solutions que j'avais pas envisager à l'époque c'est
d'utiliser opposite

la notion de direction peut être mentionné avec un angle en degré en
partant du nord à 0
L'angle permet de définir la direction de la face visible


Le lun. 10 févr. 2020 à 01:48, Philippe Verdy  a écrit :

> Quasiment toutes les communes ont au moins une agglomération (sauf les
> rares communes sans habitants). le mot "agglomération" au sens des panneaux
> EB10 et EB20 existe donc aussi en milieu rural (autant que de villages dans
> la commune, mais même en milieu rural on a des villages à cheval sur plus
> d'une commune, le plus souvent autour d'un pont sur une rivière frontière,
> ou autour d'un carrefour avec une des routes faisant frontière: c'est ce
> carrefour, ce pont, et l'activité qui s'est développée autour qui a conduit
> à ces villages multicommunes, au départ peut-être juste un corps de ferme
> ou une usine, ensuite les dépendances, habitations ou commerces qui se sont
> ajoutés, justement du fait de la facilité d'accès et du passage local
> important).
>
> "Agglomération" ne signifie pas grande ville : même un hameau de moins de
> 100 âmes peut être une agglomération formant un ilôt urbanisé dans la
> commune rurale. Un très grand nombre de communes rurales ont plusieurs
> agglomérations, une d'elle étant le "bourg" centre et ayant donné son nom à
> la commune, mais pas toujours (une agglo excentrée peut être aujourd'hui
> plus peuplée et plus dense que le bourg centre historique, notamment en
> frontière d'une autre commune voisine beaucoup plus urbanisée et ayant
> étendu son agglomération sur la commune rurale voisine).
>
> "Agglomération" ne signifie donc pas non plus "commune".
>
>
> Le dim. 9 févr. 2020 à 22:59, onesime31  a écrit :
>
>> Bonsoir,
>> Merci pour votre réponse.
>> Ce serait pour un département rural qui n'a pas d'agglomération... donc
>> je parlais surtout des panneaux des entrées de village, et de quelques
>> villes.
>>
>> Bonne soirée
>>
>>
>>
>>  Message d'origine 
>> De : Philippe Verdy 
>> Date : 09/02/2020 15:53 (GMT+01:00)
>> À : Discussions sur OSM en français 
>> Objet : Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de
>> villes & villages
>>
>> Un ennui : l'entrée d'une commune et la sortie d'une autre peuvent être
>> au même emplacement (même poteau support) dans le cas d'une frontière
>> communale au sein d'une même agglomération.
>> Ce qui a été déjà fait dans certaines agglomération pour les distinguer
>> c'est de créer des boundary=urban, passant par ces panneaux indicateurs.
>>
>> Mais "boundary=urban" ne traite pas encore ces cas de frontières
>> communales intra-agglomération où c'est la frontière communale
>> (boundary=administrative et admin_level<=8) qui tient lieu de limite. Et il
>> reste aussi des cas de frontières au sein des communes nouvelles (ou
>> associations de communes), entre les communes déléguées ou associées
>> (admin_level=9), où la toponymie de chaque commune déléguée (ou associée)
>> est conservée (même si les panneaux annotent en dessous et plus petits
>> caractères "(Commune de )".
>>
>> Le "boundary=urban" est surtout destiné à limiter les frontières
>> d'agglomération pour la régulation routière: le tracé des contours reste
>> approximatif (pas exactement sur les limites de propriétés) mais passe par
>> des points précis sur les voies publiques où ces panneaux limites
>> d'agglomération sont posés.
>>
>> En principe il y a des panneaux de chaque côté de la voie mais ils ne
>> sont pas toujours en vis-à-vis (par exemple quand l'entrée ou la sortie
>> d'agglomération se fait par des voies séparées comme des bretelles de
>> ronds-points ou par un séparateur de chaussée visant aussi à renforcer la
>> limite de vitesse, ou des bretelles d'accès de routes express, ou quand il
>> y a des feux dans un seul sens, ou quand la partie habitée commence d'un
>> seul côté, l'autre étant encore agricole ou forestier (et hors zone
>> constructible selon les PLU en vigueur).
>>
>> Délimiter les agglomérations peut avoir plusieurs significations:
>> * celle de l'INSEE se base sur des distances minimales entre bâtis (50
>> mètres?), et permet à l'INSEE de définir les secteurs de