Re: [OSM-talk-fr] ref et ref:FR

[Jérôme Seigneuret]

Bonjour,

Il me semble que pour les conventions de nommage on évite des accents
*ref:FR:Tisséo
*dans les balises


Le mer. 12 févr. 2020 à 00:34, marc marc  a
écrit :

> on ets en plein dogme, cfr Réseau Arc en ciel de bus en france
>
> Le 12.02.20 à 00:21, François Lacombe a écrit :
> > En corollaire à ces propositions, je pensais suggérer à l'international
> > de ne laisser sur la page ref que les références mondiales
> > J'ai déjà supprimé le peu de ref:FR qui s'y trouvaient, en laissant
> > évidemment les liens vers la page française des références nationales.
> >
> > Cela permettra de clarifier les choses entre mondial/national et
> > d'inciter les pays à créer leurs propres page et namespace
> >
> > Penser qu'il y a aussi un niveau continental, avec quelques entrées en
> > Europe par exemple
> > https://wiki.openstreetmap.org/wiki/FR:Key:ref:EU:EVSE
> > https://wiki.openstreetmap.org/wiki/Key:ref:EU:ENTSOE_EIC
> >
> > Bonne soirée
> >
> > François
> >
> > Le mar. 11 févr. 2020 à 23:47, François Lacombe
> > mailto:fl.infosrese...@gmail.com>> a écrit :
> >
> > Bonsoir à vous
> >
> > +1 avec vous, bonne idée de séparer le tableau, pourquoi pas par
> > thèmes, comme nous le faisons pour les Map Features ?
> > Sur le caractère national/local, pourquoi pas ajouter une colonne
> > dans les tables pour le préciser ?
> >
> > Globalement, tout ce qui favorise l'adoption de ref:FR:* est bon à
> > prendre.
> >
> > François
> >
> > Le mar. 11 févr. 2020 à 18:57, deuzeffe  > > a écrit :
> >
> > Hello,
> >
> > Le 11/02/2020 à 18:25, leni a écrit :
> > > Bonjour
> > >
> > > En attendant que nous trouvions une meilleure solution pour
> > certaines
> > > ref:FR:*** , je pense qu'il serait bien de partager le tableau
> > de la
> > > page
> > >
> >
> https://wiki.openstreetmap.org/wiki/France/Liste_des_r%C3%A9f%C3%A9rences_nationales
> >
> > > (1) en deux parties :
> > > - une première partie avec les références qui s'appliquent sur
> > > l'ensemble du territoire (ref:FR:ARCEP=* ; ...) en y ajoutant
> > celles que
> > > j'ai trouvées dans le wiki (2)
> > > - une partie pour les autres (ref:FR:CRTA=*en Aquitaine ;
> > > ref:FR:BSPP:=* ; ref:FR:RATP=*) en y ajoutant celles que
> j'ai
> > > trouvées dans le wiki (3)
> > > - Faut-il y ajouter ref:FR:TransGironde et ref:FR:CUB qui sont
> > dans osm
> > > et que je n'ai pas trouvées dans le wiki ?
> > >
> > > Qu'en pensez-vous ?
> >
> > Sur le partage, que du bien. Et peut-être "l'ordonner" voire le
> > découper
> > par thème ?
> > Il me semble que j'en avais déjà parlé, sans grand succès...
> >
> > --
> > deuzeffe - qui n'a pas oublié la page transport à toiletter.
> >
> > ___
> > 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
>


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

Re: [OSM-talk-fr] Nouvelles communes françaises issues de fusion et OSM

[Jérôme Amagat]

Le mar. 11 févr. 2020 à 15:17, Rpnpif via Talk-fr 
a écrit :

> Je voudrais proposer de modifier la façon de traiter les communes
> nouvelles françaises dans OSM.
>
> Je considère qu'une nouvelle commune devrait être enregistrée de la même
> façon qu'une ancienne commune issue de fusion de plusieurs communes.
>
> C'est traité de la même façon dans osm.
Comme la grande majorité des communes porte le nom du village (ou la ville)
principal on confond souvent les 2 mais dans osm la commune et le village
sont indiqués de 2 façons différentes.
relation boundary admin_level=8 pour les communes et place=village pour les
village.

Pour des communes fusionnées il y a longtemps avec un nom de commune
différents de celui du village principal, j'ai des cas pas loin de chez moi
:
Hautecourt-Romanèche : https://www.openstreetmap.org/relation/140516
Bohas-Meyriat-Rignat : https://www.openstreetmap.org/relation/140527
fusionnées dans les années 70
Pour les 2, les noms de communes sont l'addition des noms des anciennes
communes.

Pour des communes qui ne porte pas le nom d'un village, je connais Alleuze
: https://www.openstreetmap.org/relation/1223480 qui porte le nom d'un
château en ruine.
J'ai pas d'autres exemples en tête mais il y en a d'autres.

Pour ce qui est de l'utilisation de place=municipality :
l'ajout de la population de la municipalité serait logique.
Mais par contre, ce n'est pas l'admin_centre de la commune. (label ?)
Par contre où placer le node, dans un endroit dégagé pour pouvoir avoir le
nom des villages qui apparaissent aussi, au centre de la commune ou près de
l'admin_centre de la commune ?

:) par contre, 2 règles importantes d'osm serait enfreintes, "One feature,
one OSM element" et "ne pas taguer pour le rendu" :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] ref et ref:FR

[marc marc]

on ets en plein dogme, cfr Réseau Arc en ciel de bus en france

Le 12.02.20 à 00:21, François Lacombe a écrit :
> En corollaire à ces propositions, je pensais suggérer à l'international
> de ne laisser sur la page ref que les références mondiales
> J'ai déjà supprimé le peu de ref:FR qui s'y trouvaient, en laissant
> évidemment les liens vers la page française des références nationales.
> 
> Cela permettra de clarifier les choses entre mondial/national et
> d'inciter les pays à créer leurs propres page et namespace
> 
> Penser qu'il y a aussi un niveau continental, avec quelques entrées en
> Europe par exemple
> https://wiki.openstreetmap.org/wiki/FR:Key:ref:EU:EVSE
> https://wiki.openstreetmap.org/wiki/Key:ref:EU:ENTSOE_EIC
> 
> Bonne soirée
> 
> François
> 
> Le mar. 11 févr. 2020 à 23:47, François Lacombe
> mailto:fl.infosrese...@gmail.com>> a écrit :
> 
> Bonsoir à vous
> 
> +1 avec vous, bonne idée de séparer le tableau, pourquoi pas par
> thèmes, comme nous le faisons pour les Map Features ?
> Sur le caractère national/local, pourquoi pas ajouter une colonne
> dans les tables pour le préciser ?
> 
> Globalement, tout ce qui favorise l'adoption de ref:FR:* est bon à
> prendre.
> 
> François
> 
> Le mar. 11 févr. 2020 à 18:57, deuzeffe  > a écrit :
> 
> Hello,
> 
> Le 11/02/2020 à 18:25, leni a écrit :
> > Bonjour
> >
> > En attendant que nous trouvions une meilleure solution pour
> certaines
> > ref:FR:*** , je pense qu'il serait bien de partager le tableau
> de la
> > page
> >
> 
> https://wiki.openstreetmap.org/wiki/France/Liste_des_r%C3%A9f%C3%A9rences_nationales
> 
> > (1) en deux parties :
> > - une première partie avec les références qui s'appliquent sur
> > l'ensemble du territoire (ref:FR:ARCEP=* ; ...) en y ajoutant
> celles que
> > j'ai trouvées dans le wiki (2)
> > - une partie pour les autres (ref:FR:CRTA=*en Aquitaine ;
> > ref:FR:BSPP:=* ; ref:FR:RATP=*) en y ajoutant celles que j'ai
> > trouvées dans le wiki (3)
> > - Faut-il y ajouter ref:FR:TransGironde et ref:FR:CUB qui sont
> dans osm
> > et que je n'ai pas trouvées dans le wiki ?
> >
> > Qu'en pensez-vous ?
> 
> Sur le partage, que du bien. Et peut-être "l'ordonner" voire le
> découper
> par thème ?
> Il me semble que j'en avais déjà parlé, sans grand succès...
> 
> -- 
> deuzeffe - qui n'a pas oublié la page transport à toiletter.
> 
> ___
> 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] ref et ref:FR

[François Lacombe]

En corollaire à ces propositions, je pensais suggérer à l'international de
ne laisser sur la page ref que les références mondiales
J'ai déjà supprimé le peu de ref:FR qui s'y trouvaient, en laissant
évidemment les liens vers la page française des références nationales.

Cela permettra de clarifier les choses entre mondial/national et d'inciter
les pays à créer leurs propres page et namespace

Penser qu'il y a aussi un niveau continental, avec quelques entrées en
Europe par exemple
https://wiki.openstreetmap.org/wiki/FR:Key:ref:EU:EVSE
https://wiki.openstreetmap.org/wiki/Key:ref:EU:ENTSOE_EIC

Bonne soirée

François

Le mar. 11 févr. 2020 à 23:47, François Lacombe 
a écrit :

> Bonsoir à vous
>
> +1 avec vous, bonne idée de séparer le tableau, pourquoi pas par thèmes,
> comme nous le faisons pour les Map Features ?
> Sur le caractère national/local, pourquoi pas ajouter une colonne dans les
> tables pour le préciser ?
>
> Globalement, tout ce qui favorise l'adoption de ref:FR:* est bon à prendre.
>
> François
>
> Le mar. 11 févr. 2020 à 18:57, deuzeffe  a
> écrit :
>
>> Hello,
>>
>> Le 11/02/2020 à 18:25, leni a écrit :
>> > Bonjour
>> >
>> > En attendant que nous trouvions une meilleure solution pour certaines
>> > ref:FR:*** , je pense qu'il serait bien de partager le tableau de la
>> > page
>> >
>> https://wiki.openstreetmap.org/wiki/France/Liste_des_r%C3%A9f%C3%A9rences_nationales
>> > (1) en deux parties :
>> > - une première partie avec les références qui s'appliquent sur
>> > l'ensemble du territoire (ref:FR:ARCEP=* ; ...) en y ajoutant celles
>> que
>> > j'ai trouvées dans le wiki (2)
>> > - une partie pour les autres (ref:FR:CRTA=*en Aquitaine ;
>> > ref:FR:BSPP:=* ; ref:FR:RATP=*) en y ajoutant celles que j'ai
>> > trouvées dans le wiki (3)
>> > - Faut-il y ajouter ref:FR:TransGironde et ref:FR:CUB qui sont dans osm
>> > et que je n'ai pas trouvées dans le wiki ?
>> >
>> > Qu'en pensez-vous ?
>>
>> Sur le partage, que du bien. Et peut-être "l'ordonner" voire le découper
>> par thème ?
>> Il me semble que j'en avais déjà parlé, sans grand succès...
>>
>> --
>> deuzeffe - qui n'a pas oublié la page transport à toiletter.
>>
>> ___
>> 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] ref et ref:FR

[François Lacombe]

Bonsoir à vous

+1 avec vous, bonne idée de séparer le tableau, pourquoi pas par thèmes,
comme nous le faisons pour les Map Features ?
Sur le caractère national/local, pourquoi pas ajouter une colonne dans les
tables pour le préciser ?

Globalement, tout ce qui favorise l'adoption de ref:FR:* est bon à prendre.

François

Le mar. 11 févr. 2020 à 18:57, deuzeffe  a écrit :

> Hello,
>
> Le 11/02/2020 à 18:25, leni a écrit :
> > Bonjour
> >
> > En attendant que nous trouvions une meilleure solution pour certaines
> > ref:FR:*** , je pense qu'il serait bien de partager le tableau de la
> > page
> >
> https://wiki.openstreetmap.org/wiki/France/Liste_des_r%C3%A9f%C3%A9rences_nationales
> > (1) en deux parties :
> > - une première partie avec les références qui s'appliquent sur
> > l'ensemble du territoire (ref:FR:ARCEP=* ; ...) en y ajoutant celles que
> > j'ai trouvées dans le wiki (2)
> > - une partie pour les autres (ref:FR:CRTA=*en Aquitaine ;
> > ref:FR:BSPP:=* ; ref:FR:RATP=*) en y ajoutant celles que j'ai
> > trouvées dans le wiki (3)
> > - Faut-il y ajouter ref:FR:TransGironde et ref:FR:CUB qui sont dans osm
> > et que je n'ai pas trouvées dans le wiki ?
> >
> > Qu'en pensez-vous ?
>
> Sur le partage, que du bien. Et peut-être "l'ordonner" voire le découper
> par thème ?
> Il me semble que j'en avais déjà parlé, sans grand succès...
>
> --
> deuzeffe - qui n'a pas oublié la page transport à toiletter.
>
> ___
> 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]

Ok, je vais tenter avec cela. 
Pour le documenter, comment ça se passe? 


Merci! 

- Mail original -

De: "Florimond Berthoux"  
À: "Discussions sur OSM en français"  
Envoyé: Mardi 11 Février 2020 19:38:44 
Objet: Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & 
villages 



Tout bien réfléchi je pense que c'est une erreur de considérer le sol ou le 
béton comme étant le support du poteau (c'est pas faux, mais pas top non plus). 
Je verrais plutôt un tag pour préciser si le poteau est scellé ou non dans du 
béton. 


propositions : 
support:sealed=yes|concrete 
ou 

pole:sealed=yes|concrete 


(sealed ou embedded ?) 



@Onésime oui il n'y a pas de tag documenté pour différencier les poteaux scellé 
des non scellé. 
Dans l'absolue vaut mieux inventer inventer un nouveau tag, le documenter, et 
s'il faut le changer un peu plus tard on pourra le faire de façon presque 
automatique. 




Le mar. 11 févr. 2020 à 14:34, marc marc < marc_marc_...@hotmail.com > a écrit 
: 


Le 11.02.20 à 14:05, Florimond Berthoux a écrit : 
> support=pole 
> support:pole:support=ground 
> 
> plutôt parce que s’il y a plusieurs support (support=pole;wall) on 
> pourra pas préciser le support de quel support. 

une photo d'un panneau supporté à la fois par un poteau et un mur ? 
j'ai l'impression qu'on est une fois de + entrain de faire une usine à 
gaz "par défaut" pour au cas oü il y a besoin de traiter un cas plus 
complexe que le cas par défaut. et le contributeur lambda est largé 
depuis longtemps par la marche toujours plus grande à entrée... 

> Le mar. 11 févr. 2020 à 00:15, marc marc a écrit : 
> 
> 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 




-- 

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

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

Re: [OSM-talk-fr] Nouvelles communes françaises issues de fusion et OSM

[Philippe Verdy]

Le mar. 11 févr. 2020 à 15:17, Rpnpif via Talk-fr 
a écrit :

> La possibilité de fusion des communes en France est très ancienne, elle
> a plus de 50 ans. Par exemple, certaines communes sont issues d'une
> campagne de fusion des années 1970. Ces dernières portent souvent le nom
> des deux communes séparées d'un trait d'union. Dans OSM, elles ne sont
> pas distinguées des communes non issues de fusion (ou plutôt, celles
> dont on se souvient qu'elles ne sont pas issues de fusion ; si on
> remonte très loin, au Moyen-Âge, ces communes non issues de fusion
> doivent être assez rares).


Effectivement puisque'au moyen-âge il n'y avait encore aucune "commune" en
France (en tout cas pas dans le sens civil de droit commun qu'on entend
aujourd'hui.
Les communes sont une création après la révolution française et l'abolition
des privilèges et de tous les anciens domaines seigneuriaux et
ecclésiastiques, et certains domaines pour des collèges de marchands (qui
avaient divers statuts très changeants selon les successions, invasions,
etc. seuls les bourgs semblaient délimités, les domaines ruraux n'avaient
pas de réelle frontière autre que naturelle et certains points de passage
sur les routes et chemins, plus ou moins défendus, selon la présence
militaire locale et le bon vouloir de la population locale et les moyens
des voyageurs).
Si on veut faire une cartographie des domaines seigneuriaux, cela va être
très compliqué car il va falloir gérer les dates dont bon nombre sont mal
connues. C'est un peu plus facile pour les domaines ecclésiastiques, bien
que leur usage pour le statut civil n'a pas suivi non plus les prétentions
seigneurales (Cela s'est compliqué avec les guerres de religion et nombreux
conflits de succession, mais aussi du fait des mobilisations et migrations
forcées de population par les seigneurs de passage sur "leurs" terres).
Les archives des communes ne remontent jamais avant la révolution, d'autant
plus que la toponymie est aussi incertaine et des tas de villages
différents ont été confondus.
___
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]

Tout bien réfléchi je pense que c'est une erreur de considérer le sol ou le
béton comme étant le support du poteau (c'est pas faux, mais pas top non
plus).
Je verrais plutôt un tag pour préciser si le poteau est scellé ou non dans
du béton.

propositions :
support:sealed=yes|concrete
ou
pole:sealed=yes|concrete

(sealed ou embedded ?)

@Onésime oui il n'y a pas de tag documenté pour différencier les poteaux
scellé des non scellé.
Dans l'absolue vaut mieux inventer inventer un nouveau tag, le documenter,
et s'il faut le changer un peu plus tard on pourra le faire de façon
presque automatique.

Le mar. 11 févr. 2020 à 14:34, marc marc  a
écrit :

> Le 11.02.20 à 14:05, Florimond Berthoux a écrit :
> > support=pole
> > support:pole:support=ground
> >
> > plutôt parce que s’il y a plusieurs support (support=pole;wall) on
> > pourra pas préciser le support de quel support.
>
> une photo d'un panneau supporté à la fois par un poteau et un mur ?
> j'ai l'impression qu'on est une fois de +  entrain de faire une usine à
> gaz "par défaut" pour au cas oü il y a besoin de traiter un cas plus
> complexe que le cas par défaut. et le contributeur lambda est largé
> depuis longtemps par la marche toujours plus grande à entrée...
>
> > Le mar. 11 févr. 2020 à 00:15, marc marc a écrit :
> >
> > 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
>


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

Re: [OSM-talk-fr] ref et ref:FR

[deuzeffe]

Hello,

Le 11/02/2020 à 18:25, leni a écrit :

Bonjour

En attendant que nous trouvions une meilleure solution pour certaines 
ref:FR:*** , je pense qu'il serait bien de partager le tableau de la 
page 
https://wiki.openstreetmap.org/wiki/France/Liste_des_r%C3%A9f%C3%A9rences_nationales 
(1) en deux parties :
- une première partie avec les références qui s'appliquent sur 
l'ensemble du territoire (ref:FR:ARCEP=* ; ...) en y ajoutant celles que 
j'ai trouvées dans le wiki (2)
- une partie pour les autres (ref:FR:CRTA=*en Aquitaine ; 
ref:FR:BSPP:=* ; ref:FR:RATP=*) en y ajoutant celles que j'ai 
trouvées dans le wiki (3)
- Faut-il y ajouter ref:FR:TransGironde et ref:FR:CUB qui sont dans osm 
et que je n'ai pas trouvées dans le wiki ?


Qu'en pensez-vous ?


Sur le partage, que du bien. Et peut-être "l'ordonner" voire le découper 
par thème ?

Il me semble que j'en avais déjà parlé, sans grand succès...

--
deuzeffe - qui n'a pas oublié la page transport à toiletter.

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

[OSM-talk-fr] ref et ref:FR

[leni]

Bonjour

En attendant que nous trouvions une meilleure solution pour certaines 
ref:FR:*** , je pense qu'il serait bien de partager le tableau de la 
page 
https://wiki.openstreetmap.org/wiki/France/Liste_des_r%C3%A9f%C3%A9rences_nationales 
(1) en deux parties :
- une première partie avec les références qui s'appliquent sur 
l'ensemble du territoire (ref:FR:ARCEP=* ; ...) en y ajoutant celles que 
j'ai trouvées dans le wiki (2)
- une partie pour les autres (ref:FR:CRTA=*en Aquitaine ; 
ref:FR:BSPP:=* ; ref:FR:RATP=*) en y ajoutant celles que j'ai 
trouvées dans le wiki (3)
- Faut-il y ajouter ref:FR:TransGironde et ref:FR:CUB qui sont dans osm 
et que je n'ai pas trouvées dans le wiki ?


Qu'en pensez-vous ?

Cordialement

leni




(1) Ce tableau est appelé par 
https://wiki.openstreetmap.org/wiki/FR:Key:ref#Valeurs_du_projet_France


(2) ref:FR:geofer ; ref:FR:uic8 ; ref:FR:SIREN ; ref:FR:Orange_mobile ; 
ref:FR:ANFR ; ref:FR:SFR ; ref:FR:prix-carburants ; ref:ark


(3) ref:fr_illenoo ; ref:fr_tim ; ref:FR:STIF ; ref:IFOPT ; 
ref:FR:SMTC:STOPS ; ref:FR:CD38:STOPS ; ref:FR:STAR ; ref:FR:RATP ; 
ref:FR:aec31 ; ref:FR:Tisséo ; ref:=* ; ref:FR:commune ; 
ref:Metz Métropole


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

Re: [OSM-talk-fr] Nouvelles communes françaises issues de fusion et OSM

[Christian Quest]

Prenons un exemple pour réfléchir:

- Montholon (commune nouvelle): place=municipality + population=1500

  - Aillant-sur-Tholon (commune chef-lieu): place=village + population=1000

  - Volgré (commune déléguée): place=village + population=300

  - Villiers-sur-Tholon (commune déléguée): place=village + population=200

Chaque noeud est admin_centre d'une relation admin_level=8 ou 9


Sur le rendu, Montholon sera placé en priorité, puis Aillant, puis 
Volgré, puis Villiers.


Comme on aura plus le détail des populations des communes déléguées 
(quoique*) on peut conserver ce qu'on a de plus récent et on a le 
millésime en source:population


De toute façon, quelqu'un qui aurait besoin des populations à jour 
ferait quand même bien mieux (en France) de prendre le fichier de l'INSEE ;)



Place sur la relation + sur le noeud ? Bof bof bof, ça ne me semble pas 
cohérent car on a un doublon de place=* (qui décrit un objet, 
contrairement à population=* qui n'est pas un "objet" en tant que tel 
mais un attribut d'un objet).



* avec le carroyage INSEE on pourrait très bien déduire 
approximativement la population d'un hameau, d'un écart, etc...



Le 11/02/2020 à 17:44, osm.sanspourr...@spamgourmet.com a écrit :

Bonjour Christian,

J'ai fait des essais assez exhaustifs afin d'avoir une modélisation de
place avec une zone pour confirmer tes dires : il faut ceinture et
bretelles, place sur la relation (logique) et place sur le nœud label
(ou admin_centre).

https://www.openstreetmap.org/relation/10060749

Oui ici ça n'avait pas de sens de dire admin_centre pour un lotissement,
mais c'est aussi valable pour admin_centre.

> je sais, je suis lourd
Pas toi, c'est le modèle qui est lourd.

Reste qu'on a des admin_centre de niveaux 8 et 9 pour les communes
déléguées et assimilées.

Si on force municipality comme type de place, on indique bien que la
valeur porte sur l'ensemble de la commune et non sur une des
communes/zone agglomérée. Heu, quoique : Audierne-Esquibien (niveau 8) a
pour admin centre l'admin centre d'Audierne (9).

Comment sait-on si la population du nœud Audierne concerne Audierne ou
Audierne-Esquibien ?

population:admin_level= 8 ou 9 pourrait le résoudre.

Est-ce qu'il y a mieux en stock dans vos méninges ?

Jean-Yvon

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

J'ai l'impression que le rendu osm.org ne prends en compte que les
noeuds place=*, pas les boundary.

Il fut une époque où il utilisait les deux, mais cela donnait des noms
en double.

Dans le rendu FR, j'ai une requête compliquée pour éviter ça... elle
prends le place=* en priorité (car mieux positionné) et le centroid du
boundary en second quand il n'y a pas de place pour un même nom.


Un noeud place=municipality avec un population pour prioriser quand on
manque de place (je sais, je suis lourd) permettrait de s'en sortir à
moindres frais.


Le 11/02/2020 à 15:32, marc marc a écrit :

Le 11.02.20 à 15:16, Rpnpif via Talk-fr a écrit :

ne pas les repérer par un nœud place=* contrairement aux communes
d'avant 2010

je pense qu'il y a une erreur de modélisation dans ta vision
place=town/city représente un village/ville, peu importe que la commune
où il se trouve n'ai jamais fusionné ou fusionnée jadis ou récemment.
un polygone ou une relation boundary administrative admin_level=8
représente une commune, peu importe qu'elle ai jamais fusionné ou
fusionnée jadis ou récemment.
il n'y a aucune différence de traitement selon leur origine.

il se fait qu'il y a des villages/villes qui portent le même nom que la
commune et d'autre pas, c'est le choix des intéressés de garder
(fréquent en cas de fusion gros avec petit) ou de changer (fréquent en
cas de fusion entre +- égaux en taille) le nom d'une commune lors de la
fusion.

cela ne va pas du tout de créer un faux place=town/city juste pour 
faire

apparaître le nom d'une commune parce que invisible sur un rendu donné.
cela ne va pas mieux de créer un lieu-dit inhabité pour forcer
un rendu a afficher le nom d'une commune n'ayant pas de lieu habité
avec le même nom.

si tu veux vraiment créer un objet place=* dupliqué ce serrait
place=municipality qui serrait lui aussi tout aussi invisible par le
rendu que tu critiques (et je partage ton avis sur le côté pas génial
de ne pas voir les communes de manière + claire qu'un nom à la
frontière).

une piste de solution : rendre les (toutes) communes + visible sur le
rendu osm-fr pour ensuite en discuter sur le rendu osm-carto
___
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


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

[onesime31]

Bonsoir, 


Merci pour vos échanges... la date de la session de cartoparty approche 
(vendredi)... et je suis toujours dans le flou. 


Comme je l'ai évoqué, la commande est de faire: 
- une mise à jour des panneaux de villes et villages, 
- renseigner le EB10 ou EB20 (entrée ou sortie de village), 
- renseigner si les 2 panneaux sont au même niveau, 

- renseigner si le panneau est zérophyto ou non => si le poteau est ancré dans 
le sol directement ou s'il y a un carré de béton au pied (qui ne nécessite pas 
de désherbant). 


C'est une cartoparty avec une classe de géomaticien, et pour faire découvrir 
OSM et l'enrichir par la même occasion, on se base sur OSM pour répondre à la 
commande qui nous est faite (en général, ça se passe en classe en se basant sur 
des ressources libres telles que Mapillary, OpenStreetCam, etc.). 


Là, j'avoue que les différents échanges font que je n'y voit toujours pas plus 
claire. Je suis entrain de préparer les consignes avec les tags, etc. 

- on est d'accord pour utiliser traffic_sign=city_limit , puis éventuellement 
name= pour le nom du village. 
- pour le sens, par contre, on a le choix 

- entre traffic_sign:forward= city_limit et traffic_sign:backward = city_limit 

- OU traffic_sign=city_limit,FR:EB10 et traffic_sign=city_limit,FR:EB20 
- pour le poteau, si je comprends bien, il faut utiliser support=pole dans tous 
les cas si le panneau est sur un poteau... par contre, il n'y a pas trop de 
solution pour renseigner si le poteau est sur du béton ou non? 


Il y aurait une 30ne d'élèves pour bosser dessus sur une journée... et ce 
serait dommage qu'OSM ne profite pas de cette aubaine? (renseigner OSM est du 
bonus, on nous demande juste un shapefile avec les infos). 
Concernant le département, c'est le Gers, donc on est pas trop sur la 
problématique de passer d'une agglo à l'autre avec les histoires de vitesse, on 
est vraiment dans un contexte rural. 


Merci, bonne fin de journée, 


Onésime 





- Mail original -

De: "Christian Quest"  
À: talk-fr@openstreetmap.org 
Envoyé: Mardi 11 Février 2020 17:00:25 
Objet: Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & 
villages 

Le 11/02/2020 à 14:33, marc marc a écrit : 
> Le 11.02.20 à 14:05, Florimond Berthoux a écrit : 
>> support=pole 
>> support:pole:support=ground 
>> 
>> plutôt parce que s’il y a plusieurs support (support=pole;wall) on 
>> pourra pas préciser le support de quel support. 
> une photo d'un panneau supporté à la fois par un poteau et un mur ? 
> j'ai l'impression qu'on est une fois de + entrain de faire une usine à 
> gaz "par défaut" pour au cas oü il y a besoin de traiter un cas plus 
> complexe que le cas par défaut. et le contributeur lambda est largé 
> depuis longtemps par la marche toujours plus grande à entrée... 

+1000 ! 

KISS 

-- 
Christian Quest - OpenStreetMap France 


___ 
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] Nouvelles communes françaises issues de fusion et OSM

[osm . sanspourriel]

Bonjour Christian,

J'ai fait des essais assez exhaustifs afin d'avoir une modélisation de
place avec une zone pour confirmer tes dires : il faut ceinture et
bretelles, place sur la relation (logique) et place sur le nœud label
(ou admin_centre).

https://www.openstreetmap.org/relation/10060749

Oui ici ça n'avait pas de sens de dire admin_centre pour un lotissement,
mais c'est aussi valable pour admin_centre.

> je sais, je suis lourd
Pas toi, c'est le modèle qui est lourd.

Reste qu'on a des admin_centre de niveaux 8 et 9 pour les communes
déléguées et assimilées.

Si on force municipality comme type de place, on indique bien que la
valeur porte sur l'ensemble de la commune et non sur une des
communes/zone agglomérée. Heu, quoique : Audierne-Esquibien (niveau 8) a
pour admin centre l'admin centre d'Audierne (9).

Comment sait-on si la population du nœud Audierne concerne Audierne ou
Audierne-Esquibien ?

population:admin_level= 8 ou 9 pourrait le résoudre.

Est-ce qu'il y a mieux en stock dans vos méninges ?

Jean-Yvon

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

J'ai l'impression que le rendu osm.org ne prends en compte que les
noeuds place=*, pas les boundary.

Il fut une époque où il utilisait les deux, mais cela donnait des noms
en double.

Dans le rendu FR, j'ai une requête compliquée pour éviter ça... elle
prends le place=* en priorité (car mieux positionné) et le centroid du
boundary en second quand il n'y a pas de place pour un même nom.


Un noeud place=municipality avec un population pour prioriser quand on
manque de place (je sais, je suis lourd) permettrait de s'en sortir à
moindres frais.


Le 11/02/2020 à 15:32, marc marc a écrit :

Le 11.02.20 à 15:16, Rpnpif via Talk-fr a écrit :

ne pas les repérer par un nœud place=* contrairement aux communes
d'avant 2010

je pense qu'il y a une erreur de modélisation dans ta vision
place=town/city représente un village/ville, peu importe que la commune
où il se trouve n'ai jamais fusionné ou fusionnée jadis ou récemment.
un polygone ou une relation boundary administrative admin_level=8
représente une commune, peu importe qu'elle ai jamais fusionné ou
fusionnée jadis ou récemment.
il n'y a aucune différence de traitement selon leur origine.

il se fait qu'il y a des villages/villes qui portent le même nom que la
commune et d'autre pas, c'est le choix des intéressés de garder
(fréquent en cas de fusion gros avec petit) ou de changer (fréquent en
cas de fusion entre +- égaux en taille) le nom d'une commune lors de la
fusion.

cela ne va pas du tout de créer un faux place=town/city juste pour faire
apparaître le nom d'une commune parce que invisible sur un rendu donné.
cela ne va pas mieux de créer un lieu-dit inhabité pour forcer
un rendu a afficher le nom d'une commune n'ayant pas de lieu habité
avec le même nom.

si tu veux vraiment créer un objet place=* dupliqué ce serrait
place=municipality qui serrait lui aussi tout aussi invisible par le
rendu que tu critiques (et je partage ton avis sur le côté pas génial
de ne pas voir les communes de manière + claire qu'un nom à la
frontière).

une piste de solution : rendre les (toutes) communes + visible sur le
rendu osm-fr pour ensuite en discuter sur le rendu osm-carto
___
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] Nouvelles communes françaises issues de fusion et OSM

[Christian Quest]

J'ai l'impression que le rendu osm.org ne prends en compte que les 
noeuds place=*, pas les boundary.


Il fut une époque où il utilisait les deux, mais cela donnait des noms 
en double.


Dans le rendu FR, j'ai une requête compliquée pour éviter ça... elle 
prends le place=* en priorité (car mieux positionné) et le centroid du 
boundary en second quand il n'y a pas de place pour un même nom.



Un noeud place=municipality avec un population pour prioriser quand on 
manque de place (je sais, je suis lourd) permettrait de s'en sortir à 
moindres frais.



Le 11/02/2020 à 15:32, marc marc a écrit :

Le 11.02.20 à 15:16, Rpnpif via Talk-fr a écrit :

ne pas les repérer par un nœud place=* contrairement aux communes
d'avant 2010

je pense qu'il y a une erreur de modélisation dans ta vision
place=town/city représente un village/ville, peu importe que la commune
où il se trouve n'ai jamais fusionné ou fusionnée jadis ou récemment.
un polygone ou une relation boundary administrative admin_level=8
représente une commune, peu importe qu'elle ai jamais fusionné ou
fusionnée jadis ou récemment.
il n'y a aucune différence de traitement selon leur origine.

il se fait qu'il y a des villages/villes qui portent le même nom que la
commune et d'autre pas, c'est le choix des intéressés de garder
(fréquent en cas de fusion gros avec petit) ou de changer (fréquent en
cas de fusion entre +- égaux en taille) le nom d'une commune lors de la
fusion.

cela ne va pas du tout de créer un faux place=town/city juste pour faire
apparaître le nom d'une commune parce que invisible sur un rendu donné.
cela ne va pas mieux de créer un lieu-dit inhabité pour forcer
un rendu a afficher le nom d'une commune n'ayant pas de lieu habité
avec le même nom.

si tu veux vraiment créer un objet place=* dupliqué ce serrait
place=municipality qui serrait lui aussi tout aussi invisible par le
rendu que tu critiques (et je partage ton avis sur le côté pas génial
de ne pas voir les communes de manière + claire qu'un nom à la frontière).

une piste de solution : rendre les (toutes) communes + visible sur le
rendu osm-fr pour ensuite en discuter sur le rendu osm-carto
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


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

[Christian Quest]

Vous connaissez Lyas ? charmante bourgade de 601 âmes, désormais mise en 
avant sur le rendu FR dès le zoom 6


Tout comme Acon... 468 habitants, ou Y... 92 habitants

Voilà :(


J'accepte volontiers la PR pour corriger ça dans le rendu...

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

[Christian Quest]

Le 11/02/2020 à 14:33, marc marc a écrit :

Le 11.02.20 à 14:05, Florimond Berthoux a écrit :

support=pole
support:pole:support=ground

plutôt parce que s’il y a plusieurs support (support=pole;wall) on
pourra pas préciser le support de quel support.

une photo d'un panneau supporté à la fois par un poteau et un mur ?
j'ai l'impression qu'on est une fois de +  entrain de faire une usine à
gaz "par défaut" pour au cas oü il y a besoin de traiter un cas plus
complexe que le cas par défaut. et le contributeur lambda est largé
depuis longtemps par la marche toujours plus grande à entrée...


+1000 !

KISS

--
Christian Quest - OpenStreetMap France


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

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

[Jérôme Seigneuret]

penses à le décrire sur le wiki en Anglais et Français au moins

Le mar. 11 févr. 2020 à 16:27, Shohreh  a écrit :

> Ok, donc c'est parti pour
>
> tourism=information
> information=board
> board_type=surveillance
>
> 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
>


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

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

[Shohreh]

Ok, donc c'est parti pour

tourism=information
information=board
board_type=surveillance

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] Tag panneau zone vidéo surveillance ?

[Jérôme Seigneuret]

*tourism *est plus large que l'on peut l'entendre. les panneaux de
direction sont aussi utilisé avec cette clé

Le mar. 11 févr. 2020 à 16:20, Jérôme Seigneuret <
jerome.seigneu...@gmail.com> a écrit :

> bon ben tu t'es répondu tout seul ;-)
>
> Le mar. 11 févr. 2020 à 16:17, Shohreh  a écrit :
>
>> Shohreh wrote
>> > Quid de man_made=surveillance avec board_type=surveillance +
>> > information=board ?
>>
>> Mauvaise idée, puisque c'est pour marquer la caméra, pas un panneau pour
>> indiquer une zone :-/
>>
>>
>>
>> --
>> 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
>>
>
>
> --
> Cordialement,
> Jérôme Seigneuret
>


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

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

[Jérôme Seigneuret]

bon ben tu t'es répondu tout seul ;-)

Le mar. 11 févr. 2020 à 16:17, Shohreh  a écrit :

> Shohreh wrote
> > Quid de man_made=surveillance avec board_type=surveillance +
> > information=board ?
>
> Mauvaise idée, puisque c'est pour marquer la caméra, pas un panneau pour
> indiquer une zone :-/
>
>
>
> --
> 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
>


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

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

[Shohreh]

Shohreh wrote
> Quid de man_made=surveillance avec board_type=surveillance +
> information=board ?

Mauvaise idée, puisque c'est pour marquer la caméra, pas un panneau pour
indiquer une zone :-/



--
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] Tag panneau zone vidéo surveillance ?

[Shohreh]

Merci pour l'idée (et désolé pour le doublon : le message n'apparaissait pas
dans les archives et sur Nabble).

tourism=information
information=board
board_type=surveillance

Difficile quand même d'utiliser un panneau de tourisme pour ce genre d'info.

Quid de man_made=surveillance avec board_type=surveillance +
information=board ?

https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dsurveillance



--
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] Tag panneau zone vidéo surveillance ?

[Jérôme Seigneuret]

non information est un sous élément de tourism donc j'ai mis à chaud met
pas par hasard

Description
Clé pour décrire de façon complète les panneaux d'informations
touristiques [image:
Edit or translate this description.]

*Groupe:* Tourisme

Utilisé pour ces éléments


[image: peut être utilisé sur des nœuds]
[image: ne devrait pas
être utilisé sur des chemins]
[image: peut être utilisé
sur des zones] [image: ne
devrait pas être utilisé sur des relations]

Nécessite

   - tourism =
   information
   

Combinaisons utiles

   - tourism =
   information
   


tourism=information
information=bord
bord_type=surveillance


Le mar. 11 févr. 2020 à 15:25, Rpnpif via Talk-fr 
a écrit :

> Le 11/02/2020 à 10:37, Jérôme Seigneuret a écrit :
>
>
>>
>> à chaud, j'aurais créé traffic_sign=surveillance
>> ___
>>
> Pour moi c'est pas en lien avec le traffic
>
> A chaud ;-)
> tourism=information
> information=bord
> bord_type=surveillance
>
>
> Tu veux dire :
>
> Information=board
> board_type=surveillance
>
> ;)
>
> --
> Rpnpif
>
> ___
> 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

Re: [OSM-talk-fr] Nouvelles communes françaises issues de fusion et OSM

[marc marc]

Le 11.02.20 à 15:16, Rpnpif via Talk-fr a écrit :
> ne pas les repérer par un nœud place=* contrairement aux communes
> d'avant 2010

je pense qu'il y a une erreur de modélisation dans ta vision
place=town/city représente un village/ville, peu importe que la commune
où il se trouve n'ai jamais fusionné ou fusionnée jadis ou récemment.
un polygone ou une relation boundary administrative admin_level=8
représente une commune, peu importe qu'elle ai jamais fusionné ou
fusionnée jadis ou récemment.
il n'y a aucune différence de traitement selon leur origine.

il se fait qu'il y a des villages/villes qui portent le même nom que la
commune et d'autre pas, c'est le choix des intéressés de garder
(fréquent en cas de fusion gros avec petit) ou de changer (fréquent en
cas de fusion entre +- égaux en taille) le nom d'une commune lors de la
fusion.

cela ne va pas du tout de créer un faux place=town/city juste pour faire
apparaître le nom d'une commune parce que invisible sur un rendu donné.
cela ne va pas mieux de créer un lieu-dit inhabité pour forcer
un rendu a afficher le nom d'une commune n'ayant pas de lieu habité
avec le même nom.

si tu veux vraiment créer un objet place=* dupliqué ce serrait
place=municipality qui serrait lui aussi tout aussi invisible par le
rendu que tu critiques (et je partage ton avis sur le côté pas génial
de ne pas voir les communes de manière + claire qu'un nom à la frontière).

une piste de solution : rendre les (toutes) communes + visible sur le
rendu osm-fr pour ensuite en discuter sur le rendu osm-carto
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Rpnpif via Talk-fr]

Le 11/02/2020 à 10:37, Jérôme Seigneuret a écrit :




à chaud, j'aurais créé traffic_sign=surveillance
___

Pour moi c'est pas en lien avec le traffic

A chaud ;-)
tourism=information
information=bord
bord_type=surveillance


Tu veux dire :

Information=board
board_type=surveillance

;)

--
Rpnpif

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

[OSM-talk-fr] Nouvelles communes françaises issues de fusion et OSM

[Rpnpif via Talk-fr]

Je voudrais proposer de modifier la façon de traiter les communes 
nouvelles françaises dans OSM.


Je considère qu'une nouvelle commune devrait être enregistrée de la même 
façon qu'une ancienne commune issue de fusion de plusieurs communes.


La possibilité de fusion des communes en France est très ancienne, elle 
a plus de 50 ans. Par exemple, certaines communes sont issues d'une 
campagne de fusion des années 1970. Ces dernières portent souvent le nom 
des deux communes séparées d'un trait d'union. Dans OSM, elles ne sont 
pas distinguées des communes non issues de fusion (ou plutôt, celles 
dont on se souvient qu'elles ne sont pas issues de fusion ; si on 
remonte très loin, au Moyen-Âge, ces communes non issues de fusion 
doivent être assez rares).


De façon que je considère arbitraire, les communes issues de fusion 
d'après 2010 (pourquoi ne pas prendre celles avant 2010 ?) , il a été 
décidé ici même de traiter à part les communes nouvelles en ne les 
enregistrant que par leur frontière et sous forme de relation avec leurs 
anciennes communes membres et leur admin_centre. Il a aussi été décidé 
de ne pas les repérer par un nœud place=* contrairement aux communes 
d'avant 2010 même issues de fusion (donc beaucoup comme on l'a vu).


La conséquence la plus visible est que ces communes sont totalement 
invisibles dans le rendu officiel osm.org qui n'affiche pas le nom des 
zones englobées par une frontière sans place=*.  Il y a pourtant 
d'autres limites dont le nom est affiché comme les forêts, etc. 
Geoportail de l'IGN affiche bien, lui, ces nouvelles communes.


On répond que les nouvelles communes ne sont que des délimitations 
administratives qui n'ont pas vocation à être des lieux-dits. Cette 
opinion est contestable car c'est pourtant comme cela que l'on note les 
anciennes communes issues ou non de fusion. De plus dans l'esprit du 
législateur, les nouvelles communes issues de fusions récentes ont 
vocation à fonctionner comme les autres communes en intégrant 
complètement les anciennes qui ne deviennent que des sortes de quartiers 
ou arrondissements. Ces anciennes communes peuvent être des villages et 
parfois des petites villes (plus de 1 habitants aux abords d'une 
grande agglomération).


Par exemple, une commune classique non issue de fusion récente comporte 
souvent un bourg qui est appelé Le Bourg par les habitants et est 
rarement repéré par ce nom dans Osm.org (alors que BANO peut le 
marquer). En général, la mairie décide de noter sur les panneaux 
d'entrées du bourg le nom de la commune. Donc la commune est aussi un 
lieu-dit qui devrait être noté par place=* au niveau du bourg ou de 
l'agglomération principale. Dans le cas d'une commune issue de fusion 
récente, certaines mairies n'affichent que le nom de la commune issue de 
fusion et pas l'ancienne. D'autres affichent le nom de l'ancienne 
commune avec mention du nom de la nouvelle dessous. Évidemment, quand le 
nom de la commune issue de la fusion est le même que celle de celui de 
la commune admin_centre, le problème est plus simple.


Les habitants et autres partenaires des nouvelles communes récentes font 
de moins en moins la distinction avec le fonctionnement des communes non 
fusionnées récemment que ce soit pour leurs relations avec la mairie, la 
Poste, etc. (bien sûr après un temps d'adaptation plus ou moins facile 
et plus ou moins heureux). Ils ont donc de plus en plus besoin de 
repérer leur commune nouvelle sur une carte.


En conséquence de ce que j'écris ci-dessus, ma proposition est la suivante :

Traiter les nouvelles communes comme les anciennes avec une relation 
frontière (boundary) et un nœud place=* mis aux abords de l'admin-centre 
ou bien vers le centre de la commune.


Garder le nœud place=* et la relation frontière (boundary) des anciennes 
communes comme on le fait déjà pour les place=village des lieux-dits 
d'agglomération de plus de 200 et de moins de 1 habitants à 
l'intérieur d'une commune « non fusionnée » récemment.


Cette proposition permet de simplifier les contributions ainsi que les 
moteurs de rendus.


--
Rpnpif


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

>
> j'ai visiblement mal formulé ma remarque :
> FAIT: quand on passe de "hors zone urbaine" à "zone urbaine" en
> croissant donc un panneau EB10 dans un sens et un panneau EB20 dans
> l'autre sens, cela se MODELISE dans osm par traffic_sign=city_limit
> QUESTION : si on modélise l'entrée sur un way bi-directionnel,
> a-t-on besoin de dire que dans le sens inverse c'est une sortie ?
>
Non sauf si tu modélise le matériel en tant que tel. Donc on peut définir :
un niveau 1 de précision en lien avec juste l'information routière et son
découpage simple
on considère que le cas par défaut c'est
traffic_sign=city_limit+ direction=forward
traffic_sign:forward=FR:EB10[agglo];traffic_sign:backward=FR:EB20[agglo]
Avec 1 noeud à la limite des zones


>
> On pourrait réserver ce niveau de précision au cas des voie en
> sens-unique puisque dans ce cas (seulement ?) le panneau entrée n'est pas

dans ce cas en effet tu as une notion de sortie
en entrée
traffic_sign:forward=FR:EB10[agglo];
en sortie
traffic_sign:backward=FR:EB20[agglo]

Dans les autres (99% ?) cas, c'est une complexification dont
> je ne vois l'information supplémentaire qu'elle apporte.
>
Toi peut être mais on me modélise pas tous pour les même chose et certains
pas pour le routing

@marc il suffirait de limiter le niveau de détail (ou d'abstraction) que
l'on souhaite c'est aussi ça une base... Mais c'est pas fait (tous du moins
pas jusqu'a un certain niveau)
On voit ça sur l'électricité ou l'on atteint le niveau de précision d'une
base métier

D'où la multiplicité des méthodes et niveaux détails sur les données.

Pour revenir au niveau des support:
Pour éviter de renter dans l'usine à gaz on prend l'objet en tant que tel.
L'objet que l'on décrit est matérialisé sous forme de point est situer où?
sur un mur ou au sol? si tu veux aller plus loin dans ce cas on va dans du
commentaire ( regrouper sur un poteau)
On doit pouvoir comme on le disait plus haut trouver certains modèles et
les décrire assez bien pour que des outils puissent exploiter les données
et que des contributeurs puissent fournir des informations.
Si l'on commence à avoir des imbrications d'un même éléments (chose que je
ne pensais pas accepté) ça va aller super loin. Et plus loin jusqu'à
présent s'était ailleurs

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

Re: [OSM-talk-fr] Proposition de Hack Weekend à Toulouse (Avril)

[Frédéric Rodrigo]

J'ai créer un framadate pour trouver le weekend qui convient le mieux

https://framadate.org/lugSTfQkmgibtAL9

l'idée est d’arrêter une date assez vite.

Frédéric


Le 07/02/2020 à 22:29, Vincent Privat a écrit :

Très bon choix de ville, je viens ! :D

Le ven. 7 févr. 2020 à 16:38, Christine Karch > a écrit :


Idée géniale :)

On pourrait demander l'Asso de supporter le coût du transport ...


Am 07.02.20 um 16:28 schrieb PanierAvide:
> Bonjour,
>
> Ce serait sympa en effet, à voir selon la date et le coût du
transport
> car Rennes c'est pas à côté.
>
> Cordialement,
>
> Adrien P.
>
> Le 07/02/2020 à 15:36, Vincent de Château-Thierry a écrit :
>> Bonjour,
>>
>>> De: "Frédéric Rodrigo" mailto:fred.rodr...@gmail.com>>
>>>
>>> Avec mon employeur, Makina Corpus, je propose d'organiser une Hack
>>> Weekend à Toulouse, sur le modèle de ce que fait par exemple
>>> Geofabrik.
>>> Il n'y a pas encore de date, mais l'idée est de le faire vers
avril.
>>> J'ai commencé à préparer une page sur le wiki pour cela:
>>>
https://wiki.openstreetmap.org/wiki/Toulouse_Hack_Weekend_April_2020
>>>
>>> J'aurais aimé avoir vos retours sur cette proposition et notamment
>>> pour
>>> choisir une date.
>> Bonne idée ça :)
>>
>> Tu lances un https://framadate.org/ pour trouver le bon WE ?
>>
>> vincent
>>
>> ___
>> 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


___
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 11.02.20 à 14:00, Florimond Berthoux a écrit :
> 
> 
> Le mar. 11 févr. 2020 à 00:18, marc marc a écrit :
> 
> > 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.
> 
> 
> city_limit c’est FR:EB10 *ou* EB20, le city_limit ne définit pas si
> c’est une entrée ou une sortie
> (oui city_limit est pas top comme tag)

j'ai visiblement mal formulé ma remarque :
FAIT: quand on passe de "hors zone urbaine" à "zone urbaine" en
croissant donc un panneau EB10 dans un sens et un panneau EB20 dans
l'autre sens, cela se MODELISE dans osm par traffic_sign=city_limit
QUESTION : si on modélise l'entrée sur un way bi-directionnel,
a-t-on besoin de dire que dans le sens inverse c'est une sortie ?

On pourrait réserver ce niveau de précision au cas des voie en
sens-unique puisque dans ce cas (seulement ?) le panneau entrée n'est pas
sur le même way que celui de sortie.
Dans les autres (99% ?) cas, c'est une complexification dont
je ne vois l'information supplémentaire qu'elle apporte.
___
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 11.02.20 à 14:05, Florimond Berthoux a écrit :
> support=pole
> support:pole:support=ground
> 
> plutôt parce que s’il y a plusieurs support (support=pole;wall) on
> pourra pas préciser le support de quel support.

une photo d'un panneau supporté à la fois par un poteau et un mur ?
j'ai l'impression qu'on est une fois de +  entrain de faire une usine à
gaz "par défaut" pour au cas oü il y a besoin de traiter un cas plus
complexe que le cas par défaut. et le contributeur lambda est largé
depuis longtemps par la marche toujours plus grande à entrée...

> Le mar. 11 févr. 2020 à 00:15, marc marc a écrit :
> 
> 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

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

[Florimond Berthoux]

support=pole
support:pole:support=ground

plutôt parce que s’il y a plusieurs support (support=pole;wall) on pourra
pas préciser le support de quel support.

(support:pole:support:ground:support=earth
support:pole:support:ground:support:earth:support=space
:D)

Le mar. 11 févr. 2020 à 00:15, marc marc  a
écrit :

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


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

[Florimond Berthoux]

Le mar. 11 févr. 2020 à 00:18, marc marc  a
écrit :

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

city_limit c’est FR:EB10 *ou* EB20, le city_limit ne définit pas si c’est
une entrée ou une sortie
(oui city_limit est pas top comme tag)

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

[Stéphane Péneau]

Bonjour,

Dupliquer la population sur l'admin-centre me semble une mauvaise idée 
surtout sur les nouvelles communes. En effet, elle a pu être mise à 
jour pour cette ancienne commune seulement et n'a donc pas la même 
valeur que la nouvelle. Je rappelle que beaucoup (la majorité ?) de 
nouvelles communes n'ont pas le même nom que l'ancienne et aussi que 
l'ancienne peut avoir deux relations admin_centre (pour elle-même et 
pour la nouvelle).


Exact, et dans ce cas, je n'ai pas dupliqué la population de la commune 
nouvelle sur l'"admin_centre"


Stf

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

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

[Jérôme Seigneuret]

>
>
>
> à chaud, j'aurais créé traffic_sign=surveillance
> ___
>
Pour moi c'est pas en lien avec le traffic

A chaud ;-)
tourism=information
information=bord
bord_type=surveillance

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

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

[Jérôme Seigneuret]

Pas à ma connaissance
C'est un panneau informatif au même titre que ceux pour signaler le 0
phyto, ville fleuri ...

Si je ne me trompe pas c'est juste un élément qui répond à une
recommandation de la CNIL en terme de signalement au usager.



Le mar. 11 févr. 2020 à 10:10, Shohreh  a écrit :

> Bonjour,
>
> Les panneaux indiquant les zones vidéosurveillées ne semblent pas
> standardisés.
>
> Existe-t-il néammoins un tag pour tagger ces panneaux correctement ?
>
> 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
>


-- 
Cordialement,
Jérôme Seigneuret
___
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,

Les panneaux indiquant les zones vidéosurveillées ne semblent pas
standardisés.

Existe-t-il néammoins un tag pour tagger ces panneaux correctement ?

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

[Jérôme Seigneuret]

*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éec'est une sortie ? cela me semble lourd
pour un gain qui m’échappe.  *

Je suis d'accord sur ce sujet. Un FR:EB20 c'est égal à la valeur de sortie
du city_limit

Ducoup c'est soit l'un soit l'autre dans le cas du point sur le réseau
traffic_sign=city_limit
ou
traffic_sign=FR:EB20 pour la sortie d'une voie en sens unique
traffic_sign=FR:EB10  pour les autre cas on peut considéré que c'est le cas
implicite

Sinon c'est hors topologie avec placement au réel du panneau ce qui permet
d'identifier la présence ou absence de matériel sur le terrain.
Graphiquement. L'analyse de vitesse on s'en fou un peu puisse que le
maxspeed doit être saisie sur la voie et que la source d'information est
matérialisé.

traffic_sign=FR:EB10 et traffic_sign=FR:EB20 Prennent tous leur sens et
c'est les problème que l'on a toujours entre Montpellier Lattes et
Saint-Jean de Védas où on a de réel problème pour les vitesses
portion à 50 ou à 80 voir 90 avant l'entrée sur le rond point.

sortie 1  90
https://www.mapillary.com/map/im/ixB69C61ZJJIDtY3KLZzrw
entrée 1 50
https://www.mapillary.com/map/im/Zo3aje8wMAYuV5kjF0QLdA

sortie 2 90
https://www.mapillary.com/map/im/wst74HSo9hjkXTabdGlKxQ
entrée 2 50
https://www.mapillary.com/map/im/OoJ7Mk2eXmhsA0fy6LUD-w

sortie 3 80
https://www.mapillary.com/map/im/KSwwyWu3Pl53VKzXhj4CdQ
entrée 3 50
ici suivant d'où je viens j'ai un problème clair de vitesse

J'ai pas de photo mais au bout de la sortie 3 le l'autre coté du rond point
on a un panneau d'entrée mais pas de sortie ce qui génère un problème de
topologie. Et en base on fait quoi? et les outils traite le problème
comment?
C'est un peu comme le trou ou le chevauchement sur des limites de
frontières dont les pays sont en désaccord.

C'est pour cela que je préfère les implantations réelles puis fournir sur
le tronçon l'information de vitesse correspondantes (ou une erreur à
corriger).

Je vais pas reprendre le cours sur le traitement des vitesses du code de la
route mais on pourrait envisager de détailler ce point sur le wiki vu la
problématique.


*Si l’autorité détentrice du pouvoir de police souhaite abaisser la
vitesse, il doit en principe rappeler cette limite après chaque
intersection. Mais il dispose également de différents outils qui permettent
de ne pas rappeler la vitesse à chaque intersection (cas des panneaux de
zones)  *

Le problème c'est le suivi du développement urbain qui n'est pas forcément
réanalysé en terme de signalisation
Pour moi ces panneaux sont dans tous les cas indispensable à leur
emplacement pour bien interpréter la réalité terrain. Si on met l'info de
vitesse sur le tronçon c'est pour éviter ces cas d'interprétation par les
outils vu que c'est pas performant et que ça pause aussi des problèmes
problème de responsabilité. C'est pour cela que l'on a autant de problème à
trouver des sources fiable sur le sujet alors que les DDTM on des infos sur
les implantations de leurs panneaux. Pour les communes j'en parle pas car
vu les problèmes il est clair que l'on ne retrouvera des infos que dans 30%
des cas.

Ne pas oublier qu'un panneau 30 sous un panneau de ville transpose
l'ensemble de l'agglomération à 30km/h sauf signalisation au sol ou
vertical signalant le contraire dans l'agglomération (oui la ville peut
être limité à 30km/h sauf axes majeurs qui peuvent être élevé à une vitesse
de 70km/h
https://www.ornikar.com/code/cours/panneaux/interdiction/limitation-vitesse#les-panneaux-en-agglomeration-1


J'ai corrigé la ville de Beauvoisin  en ce sens.
https://www.openstreetmap.org/node/7121675138  Nœud simple sur le réseau
(pour le moment)
Le problème reste les chemins sur lesquels il manque les panneaux d'entrée
et sortie et qui retombent sur la départementale hors agglomération... Les
chemin sont carrossés...

Bonne journée

Le mar. 11 févr. 2020 à 00:18, marc marc  a
écrit :

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


-- 
Cordialement,
Jérôme Seigneuret

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

[Rpnpif via Talk-fr]

Le 10/02/2020 à 18:00, leni a écrit :


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 


Bonjour,

Dupliquer la population sur l'admin-centre me semble une mauvaise idée 
surtout sur les nouvelles communes. En effet, elle a pu être mise à jour 
pour cette ancienne commune seulement et n'a donc pas la même valeur que 
la nouvelle. Je rappelle que beaucoup (la majorité ?) de nouvelles 
communes n'ont pas le même nom que l'ancienne et aussi que l'ancienne 
peut avoir deux relations admin_centre (pour elle-même et pour la nouvelle).


D'ailleurs, le traitement des nouvelles communes et particulièrement 
leur rendu est un problème à part entière qui est très mal traité par le 
rendu osm.org, contrairement à Géoportail (de l'IGN) qui fait bien 
apparaître son nom.


Je vais lancer un autre fil de discussion sur ce problème des nouvelles 
communes.


Rpnpif


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