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

2020-02-09 Par sujet Philippe Verdy 
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 populations
> urbaines ou rurales, ces frontières du découpage urbain du territoire aux
> fins statistiques sont évolutives.
> * celle décidée par les communes qui décident de mettre en place des
> limitations vitesse, et accéder aux demandes des "riverains" (peu importe
> la définition de l'INSEE, la commune peut considérer d'autres facteurs
> comme la présence de parcs de loisirs ou terrrains de sports ou des
> équipements publics comme un cimetière communal, ou certaines autres
> activités de loisir ou touristiques, même si elles ne sont pas habitées, ou
> simplement une activité commerciale ou industrielle attirant de nombreux
> piétons): la limitation de vitesse "urbaine" n'est pas la même définition
> que .l'INSEE.
>
> On n'a pas de distinction des deux types de découpage urbain (statistique
> de l'INSEE, ou routier au sens du code de la route et de la réglementation
> communale/préfectorale et des panneaux EB10 et EB20, qui ne sont pas
> disposés partout sur toutes les voies résidentielles "mineures" ni sur les
> voies privées).
>
>
> Le dim. 9 févr. 2020 à 13:44, onesime31  a écrit :
>
>>
>> Bonjour,
>>
>> Nous avons un projet avec une

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

2020-02-09 Par sujet Philippe Verdy 
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.
>
> Pour le forward ou backward, comment différenciez vous le sens?
>

C'était expliqué: si tu poses le noeud sur le way, c'est selon le sens de
tracé du way "highway=*"; (cependant ces panneaux sont plutôt à côté du way
et sur un côté spécifique, il pourrait théoriquement y en avoir suspendus
au dessus s'il y a un portique ou si c'est situé sur le tablier d'un pont,
ou au dessus de l'entrée d'un tunnel). C'est comme les emplacements
d'arrêts de bus, ou les "highway=giveway" et "stop" qui ont aussi une
"direction=forward/backward" selon le sens du tracé, et aussi "oneway=yes"
qui indique que le sens unique est dans le sens du tracé et "oneway=-1"
quand le sens unique est dans le sens opposé.

Ce qui me chagrine c'est qu'on peut avoir une entrée et sortie de commune
au même endroit et dans le même sens, donc concurrence des panneaux EB10 et
EB20 pour le même sens forward ou backward.

Si on place le panneau à coté de la route, là où il est réellement et qu'on
veut taguer son support (y compris son piétement au sol si on veut
distinguer les bases béton, mais ce panneau pourrait aussi être sur le
support d'un luminaire ou d'un feu de circulation, ou contre un mur de
bâtiment ou de clôture le long de la voie, même d'un bâtiment privé, pour
ne pas empiéter un trottoir peu large), alors plus moyen de distinguer
forward/backward, et la solution des relations boundary=urban résoud le
problème car les noeuds de panneaux peuvent être placé hors de la voie de
circulation.

Ce problème de placement vient quand on veut faire du mapping plus fin avec
plus de détails. Ça et là dans certaines communes déjà bien avancées mais
denses, on commence à voir les trottoirs, les barrières et plots de
protection, les luminaires, les équipements publics, et l'emplacement exact
des panneaux constituent aussi des obstacles pour les piétons et notamment
le déplacement en fauteuil sur des trottoirs peu larges (raison pour
laquelle, les panneaux peuvent alors être placés sur les murs, ou fixés un
peu plus en hauteur et accrochés par un portique au mur pour laisser le
trottoir libre (cela concerne surtout les limites de communes dans la même
agglomération urbaine; aux limites urbain/rural, il y a normalement de la
place et on peut presque toujours trouver un emplacement correct un peu
avant ou après l'entrée/sortie d'agglomération laissant un espace libre
suffisant et n'entravant pas la circulation des véhicules.

J'ai aussi vu des panneaux aussi fixés au tronc d'un arbre (ou sur sa
barrière de protection), et sur des piliers de ponts (mieux placés là que
suspendus au tablier trop haut ou mal orientés quand il y a un virage juste
avant le franchissement sous le pont.
___
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

2020-02-09 Par sujet onesime31 
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. 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_limittraffic_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.29Le
 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

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

2020-02-09 Par sujet onesime31 
Bonsoir, C'est ce qu'il me semble le plus cohérent. Et en effet noter les 2 
panneaux Par contre,  il me reste à voir pour les plots béton. Bonne soirée 
 Message d'origine De : David Marchal  Date : 
09/02/2020  17:40  (GMT+01:00) À : Discussions sur OSM en français 
 Objet : Re: [OSM-talk-fr] Tagger correctement les 
panneaux entrées de villes & villages > 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.> Il nous faudrait également 
indiquer s'ils sont zérophyto: c'est à dire que les poteaux de ces panneaux 
aient un dé ou une dalle béton au pied (et qu'on  utilise pas de pesticide pour 
enlever l'herbe au pied de ceux-ci).> Pour la fixation du panneau, on pensait 
utiliser le key "support" puis les value suivant pour les distinguer:> - 
support= post quand le panneau est simplement planté (donc pas zerophyto)> - 
support = pole si le panneau est scellé au sol (= zerophyto pour nous)> Existe 
t-il une autre manière de tagger s'il y a un dé, ou une dalle béton au pied du 
panneau?> > L'idée serait de travailler sur OSM, et de faire une extraction 
pour répondre à la commande qui nous est faite.> > Si vous avez des conseils, 
précisions, ressources, etc. n'hésitez pas.> > Bonne soirée, 
Onésime.Cordialement.___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

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

2020-02-09 Par sujet onesime31 
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 populations 
urbaines ou rurales, ces frontières du découpage urbain du territoire aux fins 
statistiques sont évolutives.* celle décidée par les communes qui décident de 
mettre en place des limitations vitesse, et accéder aux demandes des 
"riverains" (peu importe la définition de l'INSEE, la commune peut considérer 
d'autres facteurs comme la présence de parcs de loisirs ou terrrains de sports 
ou des équipements publics comme un cimetière communal, ou certaines autres 
activités de loisir ou touristiques, même si elles ne sont pas habitées, ou 
simplement une activité commerciale ou industrielle attirant de nombreux 
piétons): la limitation de vitesse "urbaine" n'est pas la même définition que 
.l'INSEE.On n'a pas de distinction des deux types de découpage 

urbain 

(statistique de l'INSEE, ou routier au sens du code de la route et de la 
réglementation communale/préfectorale et des panneaux EB10 et EB20, qui ne sont 
pas disposés partout sur toutes les voies résidentielles "mineures" ni sur les 
voies privées).Le dim. 9 févr. 2020 à 13:44, onesime31  a 
écrit :Bonjour,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?Il nous faudrait également 
indiquer s'ils sont zérophyto: c'est à dire 
que les poteaux de ces panneaux aient un dé ou une dalle béton au pied (et 
qu'on 
utilise pas de pesticide pour enlever l'herbe au pied de ceux-ci).Pour la 
fixation du panneau, on pensait utiliser le key "support" puis les value 
suivant pour les distinguer:- support= post quand le panneau est simplement 
planté (donc pas zerophyto)- support = pole si le panneau est scellé au sol (= 
zerophyto pour nous)Existe t-il une autre manière de tagger s'il y a un dé, ou 
une dalle béton au pied du panneau?L'idée serait de travailler sur OSM, et de 
faire une extraction pour répondre à la commande qui nous est faite.Si vous 
avez des conseils, précisions, ressources, etc. n'hésitez pas.Bonne soirée, 
Onésime.___
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

2020-02-09 Par sujet marc marc 
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.
___
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

2020-02-09 Par sujet osm . sanspourriel 

Et que désignes place=city ? La ville ? La zone urbaine ?

/Populated places (in particular //place=city
//, //place=town
//,
//place=village
//,
//place=hamlet
//and
//place=isolated_dwelling
//)
are usually mapped as nodes since in most cases they have a well defined
centre but not a //verifiable
//outline./

Donc la zone urbaine, or la population est celle de la commune.

Rennes jouxte d'autres villes, tu passes de la commune de Rennes à la
commune de Chantepie sans le savoir.

Si tu considères que c'est juste la commune, alors tu mets sur la commune.

Si tu considère que... merde Rennes Métropole n'est pas un continuum
urbain (par exemple Corps-Nuds
 comporte de la campagne
et n'a pas de continuité urbaine avec Rennes).

Alors Rennes/Cesson/Chantepie/Saint-Grégoire ?

Non, sur une frontière on sait compter ; sur un truc mal défini c'est
plus difficile.

Et la population de place=city, name=Rennes n'est pas la population de
la commune de Rennes.

Jean-Yvon

Le 09/02/2020 à 21:00, rainerU - ra...@sfr.fr a écrit :

Am 09.02.20 um 20:42 schrieb osm.sanspourr...@spamgourmet.com:

Exemple : la Bretagne

administrative a une population

3217767 et Rennes en est l'admin_centre.

Pourtant Rennes (admin_centre) n'a pas 3,2 millions d'habitants mais
population

215366. Tiens une population qui reste et qui est de 2015.


La valeur population=* sur un objet de type place=city, c'est la
population de la ville, aucun rapport avec la région dont cette ville
est l'admin_centre.


___
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

2020-02-09 Par sujet Florimond Berthoux 
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

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

2020-02-09 Par sujet rainerU 
Am 09.02.20 um 20:42 schrieb 
osm.sanspourr...@spamgourmet.com:
Exemple : la Bretagne 
 
administrative a une population 
 3217767 et 
Rennes en est l'admin_centre.


Pourtant Rennes (admin_centre) n'a pas 3,2 millions d'habitants mais population 
 215366. Tiens 
une population qui reste et qui est de 2015.


La valeur population=* sur un objet de type place=city, c'est la population de 
la ville, aucun rapport avec la région dont cette ville est l'admin_centre.



___
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

2020-02-09 Par sujet Jacques Lavignotte 



Le 09/02/2020 à 20:42, osm.sanspourr...@spamgourmet.com a écrit :

Vincent (vdct) a enlevé parce qu'il y avait des incohérences. On a aussi 
supprimé les ref:INSEE= sur les nœuds.


J'ai fait de même.

J'arrête mes mises à jour de la campagne

http://dev.cadastre.openstreetmap.fr/fantoir/maj_population_2017.html

pour le moment.

J.

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

2020-02-09 Par sujet osm . sanspourriel 

Le 09/02/2020 à 18:59, Christian Quest - cqu...@openstreetmap.fr a écrit :


Retirer ce tag des noeuds place=* n'est pas conforme à ce qui est
préconisé dans le wiki (non traduit en français) qui ne parle de
population=* qu'en lien avec place=* et pas avec les relations boundary.


C'est sûr que les wikis ne disent pas la même chose...

Tu penses à "If you have a way of knowing the population of a place
(from a free data source), the population
=* tag typically is
added to the same object the place tag appears on." ?

Donc si l'objet est une boundary, tu mets sur la boundary.

Vincent (vdct) a enlevé parce qu'il y avait des incohérences. On a aussi
supprimé les ref:INSEE= sur les nœuds. Si on conteste l'un on doit AMHA
critiquer l'autre. Et je comprends les deux points de vue.

Là c'est cohérent et si on veut on peut une fois le nettoyage terminé
créer une info dérivée (mettre sur les nœuds admin_centre des relations
la population des relations).

Mais seulement à mon avis si la relation porte un attribut place= ou si
c'est un admin_level=8. Est-ce à nous d'ajouter ce genre de données
dérivées ou au consommateur de données ? Question ouverte.

Sinon on ne sait à quoi on fait référence. Une population sur un point,
sémantiquement, ça me pose soucis. Si la frontière est floue, je vois
mal comment donner une population exacte.

Exemple : la Bretagne

administrative a une population
 3217767
et Rennes en est l'admin_centre.

Pourtant Rennes (admin_centre) n'a pas 3,2 millions d'habitants mais
population
 215366.
Tiens une population qui reste et qui est de 2015.

Rennes est l'admin_centre de pas mal de choses :

 * Pôle métropolitain Loire-Bretagne (3531638)
   
 * Rennes-Nord-Ouest (2555741)
   
 * Rennes Métropole (2005861)
   
 * Rennes (54517)
   
 * Académie de Rennes (5962796)
   
 * Brittany (102740) 
 * Ille-et-Vilaine (7465) 
 * Rennes (canton de Rennes-5) (3562586)
   
 * Rennes-5 (3559420) 
 * Rennes-Centre-Ouest (2555735)
   
 * Rennes-Sud-Ouest (2555717)
   
 * Rennes-6 (3559371) 
 * Rennes-4 (3562588) 
 * Rennes-2 (3558541) 
 * Rennes-3 (3558912) 
 * Rennes-1 (3558540) 
 * Rennes-Sud-Est (2555361)
   
 * Rennes (canton de Rennes-Nord-Ouest) (6578928)
   
 * Rennes-le-Blosne (2555358)
   
 * Rennes (canton de Rennes-3) (3559370)
   
 * Rennes-Bréquigny (2555348)
   
 * Rennes (canton de Rennes-Sud-Ouest) (6578930)
   
 * Rennes-Est (2555956) 
 * Rennes-Nord-Est (2555954)
   
 * Rennes-Nord (2555747) 
 * Rennes (canton de Rennes-Sud-Est) (6578929)
   
 * Pays de Rennes (8631103)
   
 * Rennes (1655027) 
 * Rennes (canton de Rennes-6) (3562587)
   
 * Rennes-Centre (2555970) 
 * Rennes-Centre-Sud (2555382)
   

La commune de Rennes a bien une population de 2017 :population
 216815.

Ça c'est clair.

Et pas de place=town ;-).

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

2020-02-09 Par sujet Christian Quest 

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", mais on a réellement décidé 
de les supprimer ? Je croyais qu'on devait les laisser puisque c'est 
utilisé pour le rendu FR.


Stf

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


population=* sur les noeuds place est largement utilisé partout dans le 
monde. Ce n'est pas parce que nous avons la chance d'avoir nos 
découpages administratifs communaux complets que c'est le cas partout 
dans le monde.


Retirer ce tag des noeuds place=* n'est pas conforme à ce qui est 
préconisé dans le wiki (non traduit en français) qui ne parle de 
population=* qu'en lien avec place=* et pas avec les relations boundary.


Le wiki indique aussi que c'est utilisé par divers outils... et d'une 
façon générale retirer (ou déplacer/renommer) une info doit toujours 
être pris avec de grosses pincettes.


Le mieux (c'est à voir) est l'ennemi du bien...

--
Christian Quest - OpenStreetMap France


___
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

2020-02-09 Par sujet Stéphane Péneau 
Je vois des discussions et des changesets avec des suppressions du tag 
"population" sur le node "admin_centre", mais on a réellement décidé de les 
supprimer ? Je croyais qu'on devait les laisser puisque c'est utilisé pour le 
rendu FR.

Stf


6 févr. 2020 a écrit :
>Le 06/02/2020 à 15:04, Vincent de Château-Thierry a écrit :
>
 Il semble que quelqu'un conteste tes mises à jour ou plutôt ne
 les as pas comprises. C'est sur :
 
 https://forum.openstreetmap.org/viewtopic.php?id=68546
>> 
>> Merci Alain pour le pointeur. Comme dit par Marc on a reçu en
>> parallèle un message de Clinton par un autre canal. Toutes nos
>> réponses convergent donc il devrait pouvoir synthétiser. Je vois qu'à
>> l'instant il a remercié Marc ici.
>Il y a même un breton qui a répondu sur le forum.
>-- 
>deuzeffe - je n'ai pas le nom
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- Envoyé de mon téléphone Android avec K-@ Mail. Excusez la brièveté.___
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

2020-02-09 Par sujet David Marchal 


> 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.

> Il nous faudrait également indiquer s'ils sont zérophyto: c'est à dire que 
> les poteaux de ces panneaux aient un dé ou une dalle béton au pied (et qu'on  
> utilise pas de pesticide pour enlever l'herbe au pied de ceux-ci).
> Pour la fixation du panneau, on pensait utiliser le key "support" puis les 
> value suivant pour les distinguer:
> - support= post quand le panneau est simplement planté (donc pas zerophyto)
> - support = pole si le panneau est scellé au sol (= zerophyto pour nous)
> Existe t-il une autre manière de tagger s'il y a un dé, ou une dalle béton au 
> pied du panneau?
> 
> L'idée serait de travailler sur OSM, et de faire une extraction pour répondre 
> à la commande qui nous est faite.
> 
> Si vous avez des conseils, précisions, ressources, etc. n'hésitez pas.
> 
> Bonne soirée, Onésime.
Cordialement.


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

Re: [OSM-talk-fr] protect_class -du périmètre de protection autour de la réserve géologique

2020-02-09 Par sujet Arnaud Champollion 

Le 26/01/2020 à 13:50, Philippe Verdy a écrit :

Regarde les autres relations concernant les "aires d'adhésion",


Fait, j'ai mis "5", comme l'aire d'adhésion du Parc National des Ecrins.

https://www.openstreetmap.org/relation/10615882#map=9/44.0440/6.3221



___
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

2020-02-09 Par sujet Philippe Verdy 
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 populations
urbaines ou rurales, ces frontières du découpage urbain du territoire aux
fins statistiques sont évolutives.
* celle décidée par les communes qui décident de mettre en place des
limitations vitesse, et accéder aux demandes des "riverains" (peu importe
la définition de l'INSEE, la commune peut considérer d'autres facteurs
comme la présence de parcs de loisirs ou terrrains de sports ou des
équipements publics comme un cimetière communal, ou certaines autres
activités de loisir ou touristiques, même si elles ne sont pas habitées, ou
simplement une activité commerciale ou industrielle attirant de nombreux
piétons): la limitation de vitesse "urbaine" n'est pas la même définition
que .l'INSEE.

On n'a pas de distinction des deux types de découpage urbain (statistique
de l'INSEE, ou routier au sens du code de la route et de la réglementation
communale/préfectorale et des panneaux EB10 et EB20, qui ne sont pas
disposés partout sur toutes les voies résidentielles "mineures" ni sur les
voies privées).


Le dim. 9 févr. 2020 à 13:44, onesime31  a écrit :

>
> Bonjour,
>
> 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
> ?
>
> Il nous faudrait également indiquer s'ils sont zérophyto: c'est à dire que
> les poteaux de ces panneaux aient un dé ou une dalle béton au pied (et
> qu'on utilise pas de pesticide pour enlever l'herbe au pied de ceux-ci).
> Pour la fixation du panneau, on pensait utiliser le key "support" puis les
> value suivant pour les distinguer:
> - support= post quand le panneau est simplement planté (donc pas zerophyto)
> - support = pole si le panneau est scellé au sol (= zerophyto pour nous)
> Existe t-il une autre manière de tagger s'il y a un dé, ou une dalle béton
> au pied du panneau?
>
> L'idée serait de travailler sur OSM, et de faire une extraction pour
> répondre à la commande qui nous est faite.
>
> Si vous avez des conseils, précisions, ressources, etc. n'hésitez pas.
>
> Bonne soirée, Onésime.
> ___
> 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] hebdoOSM Nº 498 2020-01-28-2020-02-03

2020-02-09 Par sujet theweekly . osm 
Bonjour,

Le résumé hebdomadaire n° 498 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

http://www.weeklyosm.eu/fr/archives/12843/

Bonne lecture !

Saviez-vous que vous pouvez vous aussi soumettre des messages pour la note 
hebdomadaire sans être membre ? Il vous suffit de vous connecter sur 
https://osmbc.openstreetmap.de/login avec votre compte OSM. Pour en savoir plus 
sur la rédaction d'un article, cliquez ici: 
http://www.weeklyosm.eu/fr/this-news-should-be-in-weeklyosm

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2020-02-09 Par sujet onesime31 

Bonjour,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?Il nous faudrait également indiquer s'ils sont zérophyto: 
c'est à dire 
que les poteaux de ces panneaux aient un dé ou une dalle béton au pied (et 
qu'on 
utilise pas de pesticide pour enlever l'herbe au pied de ceux-ci).Pour la 
fixation du panneau, on pensait utiliser le key "support" puis les value 
suivant pour les distinguer:- support= post quand le panneau est simplement 
planté (donc pas zerophyto)- support = pole si le panneau est scellé au sol (= 
zerophyto pour nous)Existe t-il une autre manière de tagger s'il y a un dé, ou 
une dalle béton au pied du panneau?L'idée serait de travailler sur OSM, et de 
faire une extraction pour répondre à la commande qui nous est faite.Si vous 
avez des conseils, précisions, ressources, etc. n'hésitez pas.Bonne soirée, 
Onésime.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Équitation et attributs proposés

2020-02-09 Par sujet Jérôme Seigneuret 
Pour rebondir sur le sujet et améliorer l'usage et le rendu qu'il peut en
être fait

1) Aborder les sujets et améliorer le wiki pour les tags en question et les
soumettre au processus de validation (tagging list et autres)
2) Voir avec les différents dev de fond de plan pour intégrer des rendus
génériques ou spécifiques  de manière à avoir une visibilité ou
l'améliorer (rendu général osm.org, rendu hiking)
3) Communiquer auprès des communautés si ces éléments seraient pertinents à
être exploité pour les itinéraires par exemple.
4) Si plusieurs tag sont proches ou similaires, proposer d'en supprimer un
au profit de l'autre la la mailing list qui va bien. > adapter le wiki et
présenté la solution adaptée.

Un exemple simple de choses possible et non prise en compte dans le rendu
c'est de mettre un portail comme linéaire alors que les outils et le rendu
utilise le point. Deux choses se passent dans ce cas:
- les utilisateurs voulant un rendu mais pas dégrader le détail mettent
barrier=gate sur le point d'intersection
- les utilisateurs qui considèrent que ça ne répond pas au modèle et
supprime le linéaire pour faire un point unique à l'intersection.
Par dessus ça il y a les contributeurs qui supprime les infos car osmose
émet une alerte si un portail n'est pas connecté à la voirie

Donc comme signalé précédemment, il faut dissocier le contenu, le rendu,
l'exploitation des données, l'analyse qualité. A chaque niveau des
décisions sont prise et la base évolue au rythme des contributions et des
sujets que l'on veut bien y intégrer (des fois sans validation complet du
processeur)

Bon weekend



Le sam. 8 févr. 2020 à 13:51, marc marc  a
écrit :

> Le 08.02.20 à 13:21, Arnaud Champollion a écrit :
> > beaucoup d'attributs "proposés" mais pas validés.
> >
> > Est-ce que ça veut dire que pour l'instant on ne les utilise pas ?
>
> dans osm, tout le monde est libre d'utiliser n'importe quel tags.
> un tag validé est simplement un tag qui a fait l'objet d'une discussion
> au niveau mondial et qui au moment du vote a paru être de qualité.
> c'est totalement indépendent d'être présent ou pas dans la bdd,
> être ou pas utilisé par le rendu par défaut ou par n'importe quel autre
> rendu ou par une application
> ___
> 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