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

2020-02-12 Par sujet Philippe Verdy 
Des admin_level=8 correspondent à plusieurs statuts communaux, ayant un
conseil élu et une autonomie financière (communes simples, communes
nouvelles, associations de communes, communes spéciales à arrondissements),
ou pas (mais qui ont une identité administrative inclue dans une entité
plus grande dont elle fait partie du découpage).

Dans le Pacifique il n'y a pas toujours un admin_centre désigné car les
compétences sont sur plusieurs iles simultanément, les conseils ont bien un
adresse postale, mais le lieu des conseils peut changer (conseils
itinérants) et les services communaux sont répartis sur les iles qui ont
des sortes de "mairies annexes" pour la représentation publique, la plupart
des iles étant de tous petits villages, ou les iles ayant des populations
très saisonnières, et une grande partie des services sont en fait délégués
à un service territorial qui centralise gestion pour chaque commune pour
des économies de moyens (cela est conjugué aux difficultés de transport et
aux coûts). Les communes ont pourtant une entité juridique et une autonomie
comptable mais le gros de leur travail est délégué sur chacune des iles par
des conseils locaux, la commune validant leurs décisions (où figurent aussi
des conseils de droit coutumier qui ne suivent pas non plus la logique du
découpage communal). Les communes sont assez théoriques, en pratique ce
sont les conseils "îliens" (réunis autour des conseillers locaux élus dans
la commune pour représenter chaque ile) qui font le travail et travaillent
pour plusieurs collectivités (la commune, le territoire, et le domaine
coutumier) et sous la supervision préfectorale/haut-commissariat pour
valider les décisions. C'est beaucoup moins centralisé et hiérarchisé qu'en
métropole.

C'est le cas en Polynésie, à Wallis-et-Futuna et en nouvelle-Calédonie où
le droit coutumier est reconnu et où cohabitent plusieurs domaines publics,
que les communes ne représentent pas et ne peuvent décider seules.

Se baser uniquement sur admin_level=8 et boundary=adminsitrative ne permet
pas de différencier tous les cas. C'est pour ça qu'on a des
"admin_type:FR=*" différents. Les statuts "communaux" ont même tendance à
se multiplier (et cela va continuer avec les fusions de compétence)
l'admin_level=8 désigne juste des communes ou *assimilées*, nécessaires
pour assurer la complétude du découpage territorial des entités
territoriales plus grandes.

Le jeu. 13 févr. 2020 à 04:56, Jérôme Amagat  a
écrit :

>
>
> Le mer. 12 févr. 2020 à 19:20,  a
> écrit :
>
>> Le 12/02/2020 à 18:02, Christian Quest - cqu...@openstreetmap.fr a
>> écrit :
>>
>> place=municipality est dans un tableau "administratively declared
>> places", ce qui va très bien avec nos communes nouvelles rurales. Il est
>> par contre très peu utilisé: quelques milliers à peine sur le monde entier
>> !
>>
>> On ne va pas non plus en ajouter des milliers
>> 
>> (713).
>>
>>  Ce ne sont pas que des communes nouvelles ! et certaines communes
> nouvelles portent le nom d'une ville ou d'un village.
>
> J'ai fait cette requête sur overpass turbo :
> https://overpass-turbo.eu/s/QFS
> On peut faire des truc bien compliqué maintenant ! c'est la première fois
> que j'y utilise un if :)
>
> Et j'obtiens 943 communes qui n'ont pas comme nom celui de leur
> admin_centre.
>
> dans le tas il y en a une quinzaine qui n'ont pas d'admin_centre
> tout est dans le pacifique en Polynésie et Clipperton (qui n'est pas une
> commune mais qui a sa relation admin_level=8 ?)
> sauf un truc (créé par Philippe) une relation admin_level=8 pour le
> domaine public maritime dans le golfe du morbillan :
> https://www.openstreetmap.org/relation/8687577
> relation inutile d’après moi.
>
> Il y en a 513 avec le tag admin_type:FR=commune nouvelle donc le reste
> (~400) a priori des communes qui n'ont pas bougé ses dernière années.
>
> Il y en a peut être un peu moins que ça, en regardant rapidement je vois
> des trucs bizarres :
> un name=Saint-Pierre-d'Entremont (Isère) et un
> name=Saint-Pierre-d'Entremont (Savoie)
> Rémire-Montjoly écrit avec ou sens accens.
>
> Je vois un autre problème non lié aux noms :
> "Matis73" a changer des place=village en place=quarter dans les alpes
>
> Comme évoqué par Florimond, il y a le cas des noms de villages et de
> communes avec "-sur-machin", '-en-bidule",... il y en a plein la France
> mais il ont souvent été ajouté au 20e siècle au nom du village ou de la
> ville. Je suis totalement contre les enlever du nom des villages mais que
> fait t on pour les nouveaux créé avec l’arrivée des communes nouvelles ?
> Cherbourg-en-Cotentin, Neuvéglise-sur-Truyère  c'est pas encore rentré
> dans les tête comme un changement du nom de la ville ou du village donc on
> les laisse comme nom de commune mais pas plus ou on les intègre au name des
> villes et villages ou en alt_name?
> ___
> Talk-fr mailing list
>

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

2020-02-12 Par sujet Jérôme Amagat 
Le mer. 12 févr. 2020 à 19:20,  a écrit :

> Le 12/02/2020 à 18:02, Christian Quest - cqu...@openstreetmap.fr a écrit :
>
> place=municipality est dans un tableau "administratively declared places",
> ce qui va très bien avec nos communes nouvelles rurales. Il est par contre
> très peu utilisé: quelques milliers à peine sur le monde entier !
>
> On ne va pas non plus en ajouter des milliers
> 
> (713).
>
>  Ce ne sont pas que des communes nouvelles ! et certaines communes
nouvelles portent le nom d'une ville ou d'un village.

J'ai fait cette requête sur overpass turbo : https://overpass-turbo.eu/s/QFS
On peut faire des truc bien compliqué maintenant ! c'est la première fois
que j'y utilise un if :)

Et j'obtiens 943 communes qui n'ont pas comme nom celui de leur
admin_centre.

dans le tas il y en a une quinzaine qui n'ont pas d'admin_centre
tout est dans le pacifique en Polynésie et Clipperton (qui n'est pas une
commune mais qui a sa relation admin_level=8 ?)
sauf un truc (créé par Philippe) une relation admin_level=8 pour le domaine
public maritime dans le golfe du morbillan :
https://www.openstreetmap.org/relation/8687577
relation inutile d’après moi.

Il y en a 513 avec le tag admin_type:FR=commune nouvelle donc le reste
(~400) a priori des communes qui n'ont pas bougé ses dernière années.

Il y en a peut être un peu moins que ça, en regardant rapidement je vois
des trucs bizarres :
un name=Saint-Pierre-d'Entremont (Isère) et un
name=Saint-Pierre-d'Entremont (Savoie)
Rémire-Montjoly écrit avec ou sens accens.

Je vois un autre problème non lié aux noms :
"Matis73" a changer des place=village en place=quarter dans les alpes

Comme évoqué par Florimond, il y a le cas des noms de villages et de
communes avec "-sur-machin", '-en-bidule",... il y en a plein la France
mais il ont souvent été ajouté au 20e siècle au nom du village ou de la
ville. Je suis totalement contre les enlever du nom des villages mais que
fait t on pour les nouveaux créé avec l’arrivée des communes nouvelles ?
Cherbourg-en-Cotentin, Neuvéglise-sur-Truyère  c'est pas encore rentré
dans les tête comme un changement du nom de la ville ou du village donc on
les laisse comme nom de commune mais pas plus ou on les intègre au name des
villes et villages ou en alt_name?
___
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 ?

2020-02-12 Par sujet marc marc 
Le 12.02.20 à 23:02, Victor/tuxayo a écrit :
> Est-ce qu'il aurai a un moyen pour indiquer l'absence de panneau alors
> que c'est légalement requis? (caméra dans un lieu publique en France par
> exemple)

perso je suis fan de l'extention de unsigned sous forme
de  unsigned=
exemple unsigned=addr:housenumber : la plaque du no est absente
sur le terrain (mais l'info est vérifiable en opendata par ex)
donc dans ton cas, quand tu auras trouvé comment renseigner le panneau,
tu auras le moyen de renseigner son absence :-D
___
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 ?

2020-02-12 Par sujet Philippe Verdy 
là je suis d'accord, cette information est générale et ne vise pas
spécialement les touristes mais tout le monde.

On peut comparer avec la situation des panneau d'affichage électoraux qui
eux ne visent pas du tout les "touristes" mais les électeurs résidents et
qui n'ont rien à faire dans la catégorie tourisme.
De même pour les panneaux d'annonces légales.

Bref la clé de base importante, c'est "information=board" pour tout panneau
d'information plus "board_type=*" (qu'on peut compléter par
"tourism=information" *seulement* quand l'information affichée a une valeur
touristique).

Il n'y a pas de raison de "chaîner" les tags pour ce qui ne doit pas
l'être, car cela ajoute des restrictions fausses.





Le jeu. 13 févr. 2020 à 00:04, Florimond Berthoux <
florimond.berth...@gmail.com> a écrit :

> Relis mon mail...
>
> Ça serait bien que les sous clés ou les valeurs ne violent pas la
> définition de la clé principale, non ?
> J'en remet une couche :
> «Places and things of specific interest to tourists including places to
> see, places to stay, things and *places providing information and support
> to tourists.*»
> https://wiki.openstreetmap.org/wiki/Key:tourism
>
> On est là pour faire une base de données (facilement) utilisable ou pas ?
>
> Tout ce que je propose c'est juste ne pas mettre tourism=information,
> moins de travail.
>
> Le mer. 12 févr. 2020 à 22:40, Victor/tuxayo  a écrit :
>
>> On 20-02-12 22:05, Florimond Berthoux wrote:
>> > Le problème c'est que les consommateurs de cette données vont
>> > l'interpréter comme une information touristique alors que ça ne l'est
>> pas.
>> > Exemple, ça sera affiché sur CyclOSM comme n'importe qu'elle autre
>> > panneau d'info à valeur touristique.
>>
>> On tombe dans le problème que les consommateurs ne doivent pas se fier
>> uniquement aux clefs et aux valeurs mais à la documentation.
>> Sans la doc, il y a un nombre énorme de clefs+valeurs qui seraient mal
>> interprétés.
>>
>> À++
>>
>> --
>> Victor/tuxayo
>>
>> ___
>> 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] Tag panneau zone vidéo surveillance ?

2020-02-12 Par sujet Florimond Berthoux 
Relis mon mail...

Ça serait bien que les sous clés ou les valeurs ne violent pas la
définition de la clé principale, non ?
J'en remet une couche :
«Places and things of specific interest to tourists including places to
see, places to stay, things and *places providing information and support
to tourists.*»
https://wiki.openstreetmap.org/wiki/Key:tourism

On est là pour faire une base de données (facilement) utilisable ou pas ?

Tout ce que je propose c'est juste ne pas mettre tourism=information, moins
de travail.

Le mer. 12 févr. 2020 à 22:40, Victor/tuxayo  a écrit :

> On 20-02-12 22:05, Florimond Berthoux wrote:
> > Le problème c'est que les consommateurs de cette données vont
> > l'interpréter comme une information touristique alors que ça ne l'est
> pas.
> > Exemple, ça sera affiché sur CyclOSM comme n'importe qu'elle autre
> > panneau d'info à valeur touristique.
>
> On tombe dans le problème que les consommateurs ne doivent pas se fier
> uniquement aux clefs et aux valeurs mais à la documentation.
> Sans la doc, il y a un nombre énorme de clefs+valeurs qui seraient mal
> interprétés.
>
> À++
>
> --
> Victor/tuxayo
>
> ___
> 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] Tag panneau zone vidéo surveillance ?

2020-02-12 Par sujet Florimond Berthoux 
Visitor :
« someone who visits
 a person
 or place
:»
https://dictionary.cambridge.org/fr/dictionnaire/anglais/visitor

Visit :
« to go to a place *in order to look at it*, or to a person in order to
spend time with them:»
https://dictionary.cambridge.org/fr/dictionnaire/anglais/visit

British English, OSM tout ça...


Le mer. 12 févr. 2020 à 22:35, Jérôme Seigneuret <
jerome.seigneu...@gmail.com> a écrit :

> C'est pas chez toi donc t'es un visiteur suivi d'un consommateur
>
> Le mer. 12 févr. 2020 à 22:06, Florimond Berthoux <
> florimond.berth...@gmail.com> a écrit :
>
>> «An *information* source for tourists, travellers and visitors.»
>> Je visite rarement les supermarchés, les halls d'entreprises ou les
>> piscines municipales.
>> J'y vais mais je ne visite pas.
>>
>> Le problème c'est que les consommateurs de cette données vont
>> l'interpréter comme une information touristique alors que ça ne l'est pas.
>> Exemple, ça sera affiché sur CyclOSM comme n'importe qu'elle autre
>> panneau d'info à valeur touristique.
>>
>> (Pour préciser, je ne suis contre que sur l'utilisation du tag 
>> tourism=information
>> pour ce cas)
>>
>>
>> Le mer. 12 févr. 2020 à 21:07,  a
>> écrit :
>>
>>> Si on regarde ce qui touche à la surveillance côté taginfo:
>>>
>>> surveillance=outdoor/public/indoor.
>>> surveillance:type=camera
>>> surveillance:zone=traffic/building/town/parking...
>>>
>>> Ça me semble possible de l'indiquer aussi ici.
>>>
>>> Certes ce n'est pas du tourisme mais board_type=sport ou
>>> board_type=public_transport non plus.
>>>
>>> Simplement on a/aurait la chaîne tourism=information / information=board
>>> / board_type=surveillance.
>>>
>>> C'est bien ce qu'a écrit Shohreh
>>> 
>>> sur le wiki.
>>>
>>> Et non ça ne me choque pas. Même si la caméra n'a pas de reconnaissance
>>> faciale pour ne fliquer que les touristes^^.
>>>
>>> Jean-Yvon
>>> Le 12/02/2020 à 20:49, Florimond Berthoux - florimond.berth...@gmail.com
>>> a écrit :
>>>
>>> Mon avis que ce tourism=information est une erreur, il y a rien de
>>> touristique dans ce panneau.
>>> information=board et board_type=* se suffisent à eux même.
>>>
>>> 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.
>>>
>>> ___
>>> 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
>


-- 
Florimond Berthoux
___
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 ?

2020-02-12 Par sujet osm . sanspourriel 

D'accord avec Jérôme, sinon une caméra qui ne respecte pas la loi on la
fait enlever.

Éventuellement on ajoute une clé style legal=no ou
law_violation=missing_sign...

Juste une idée à mûrir : c'est bien par rapport à la caméra qui existe
que quelque chose manque.

Données exploitables dans une umap par exemple.

Peut-être voir ce que font les RAP par rapport à la publicité illégale.

Jean-Yvon

Le 12/02/2020 à 23:14, Jérôme Seigneuret - jerome.seigneu...@gmail.com a
écrit :

On tag l'existant pas le manque mais une umap avec un symbologie
propre au caméra les panneaux d'entrée de ville et la panneau
d'information de ville sous vidéo surveillance devrait faire ton affaire

Le mer. 12 févr. 2020 à 23:03, Victor/tuxayo mailto:vic...@tuxayo.net>> a écrit :

On 20-02-11 16:26, Shohreh wrote:
> tourism=information
> information=board
> board_type=surveillance

Est-ce qu'il aurai a un moyen pour indiquer l'absence de panneau
alors
que c'est légalement requis? (caméra dans un lieu publique en
France par
exemple)

Car là on peut juste indiquer la présence d'un panneau.

Cas concret: Dans le cadre de contribuer à la campagne
Technopolice[1] à
Marseille, il y a pour plan de faire une cartopartie des caméras de
surveillance.
Et pour aller plus loin, des gens seraient intéressés par indiquer si
une caméra viole la législation sur l'affichage. Et de les
extraire sur
une carte pour que cela serve lors de plaintes.[2] (à différents buts
dont obtenir en open data la position des caméras de certaines villes)

Donc cette discussion tombe très bien :D Est-ce que qu'un a une idée
pour indiquer de manière propre l'absence de signalétique d'une
caméra?
Au pire écrire un truc joli dans l’attribut "description" (ou un truc
pas joli dans "note") et homogénéiser ce qu'il y est mit à l'échelle
d'une ville mais c'est du gros bricolage. (non)

À++

[1] https://technopolice.fr/
[2]

https://forum.technopolice.fr/topic/403/plainte-collective-cnil-obliger-paris-%C3%A0-publier-une-carte-de-ses-cam%C3%A9ras

--
Victor/tuxayo

___
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] Demande d'intervention de tiers sur un conflit d'édition

2020-02-12 Par sujet Thomas Ruchin 
Voici un des échanges que j'avais eu voici quelques mois avec ce
contributeur :
https://www.openstreetmap.org/changeset/62907425
C'est dommage de perdre tant d'énergie, et plutôt désagréable de le croiser
sur sa route.

Thomas


Le mercredi 12 février 2020, Stéphane Péneau  a
écrit :

> Le 12/02/2020 à 13:31, Charles MILLET a écrit :
>
>>
>> Je ne suis pas à l'aise avec l'idée de faire un signalement au DWG car en
>>> dehos de ce genre de comportement, ses contributions sont bonnes.
>>> Pensez-vous qu'il faille le faire ?
>>>
>>
>
> Oui, mais j'ai un point de vue biaisé puisque partie prenante.
>
> Stf
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2020-02-12 Par sujet Jérôme Seigneuret 
On tag l'existant pas le manque mais une umap avec un symbologie propre au
caméra les panneaux d'entrée de ville et la panneau d'information de ville
sous vidéo surveillance devrait faire ton affaire

Le mer. 12 févr. 2020 à 23:03, Victor/tuxayo  a écrit :

> On 20-02-11 16:26, Shohreh wrote:
> > tourism=information
> > information=board
> > board_type=surveillance
>
> Est-ce qu'il aurai a un moyen pour indiquer l'absence de panneau alors
> que c'est légalement requis? (caméra dans un lieu publique en France par
> exemple)
>
> Car là on peut juste indiquer la présence d'un panneau.
>
> Cas concret: Dans le cadre de contribuer à la campagne Technopolice[1] à
> Marseille, il y a pour plan de faire une cartopartie des caméras de
> surveillance.
> Et pour aller plus loin, des gens seraient intéressés par indiquer si
> une caméra viole la législation sur l'affichage. Et de les extraire sur
> une carte pour que cela serve lors de plaintes.[2] (à différents buts
> dont obtenir en open data la position des caméras de certaines villes)
>
> Donc cette discussion tombe très bien :D Est-ce que qu'un a une idée
> pour indiquer de manière propre l'absence de signalétique d'une caméra?
> Au pire écrire un truc joli dans l’attribut "description" (ou un truc
> pas joli dans "note") et homogénéiser ce qu'il y est mit à l'échelle
> d'une ville mais c'est du gros bricolage. (non)
>
> À++
>
> [1] https://technopolice.fr/
> [2]
>
> https://forum.technopolice.fr/topic/403/plainte-collective-cnil-obliger-paris-%C3%A0-publier-une-carte-de-ses-cam%C3%A9ras
>
> --
> Victor/tuxayo
>
> ___
> 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] Tag panneau zone vidéo surveillance ?

2020-02-12 Par sujet Victor/tuxayo 

On 20-02-11 16:26, Shohreh wrote:

tourism=information
information=board
board_type=surveillance


Est-ce qu'il aurai a un moyen pour indiquer l'absence de panneau alors 
que c'est légalement requis? (caméra dans un lieu publique en France par 
exemple)


Car là on peut juste indiquer la présence d'un panneau.

Cas concret: Dans le cadre de contribuer à la campagne Technopolice[1] à 
Marseille, il y a pour plan de faire une cartopartie des caméras de 
surveillance.
Et pour aller plus loin, des gens seraient intéressés par indiquer si 
une caméra viole la législation sur l'affichage. Et de les extraire sur 
une carte pour que cela serve lors de plaintes.[2] (à différents buts 
dont obtenir en open data la position des caméras de certaines villes)


Donc cette discussion tombe très bien :D Est-ce que qu'un a une idée 
pour indiquer de manière propre l'absence de signalétique d'une caméra?
Au pire écrire un truc joli dans l’attribut "description" (ou un truc 
pas joli dans "note") et homogénéiser ce qu'il y est mit à l'échelle 
d'une ville mais c'est du gros bricolage. (non)


À++

[1] https://technopolice.fr/
[2] 
https://forum.technopolice.fr/topic/403/plainte-collective-cnil-obliger-paris-%C3%A0-publier-une-carte-de-ses-cam%C3%A9ras


--
Victor/tuxayo

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

2020-02-12 Par sujet Victor/tuxayo 

On 20-02-12 22:05, Florimond Berthoux wrote:
Le problème c'est que les consommateurs de cette données vont 
l'interpréter comme une information touristique alors que ça ne l'est pas.
Exemple, ça sera affiché sur CyclOSM comme n'importe qu'elle autre 
panneau d'info à valeur touristique.


On tombe dans le problème que les consommateurs ne doivent pas se fier 
uniquement aux clefs et aux valeurs mais à la documentation.
Sans la doc, il y a un nombre énorme de clefs+valeurs qui seraient mal 
interprétés.


À++

--
Victor/tuxayo

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

2020-02-12 Par sujet Jérôme Seigneuret 
C'est pas chez toi donc t'es un visiteur suivi d'un consommateur

Le mer. 12 févr. 2020 à 22:06, Florimond Berthoux <
florimond.berth...@gmail.com> a écrit :

> «An *information* source for tourists, travellers and visitors.»
> Je visite rarement les supermarchés, les halls d'entreprises ou les
> piscines municipales.
> J'y vais mais je ne visite pas.
>
> Le problème c'est que les consommateurs de cette données vont
> l'interpréter comme une information touristique alors que ça ne l'est pas.
> Exemple, ça sera affiché sur CyclOSM comme n'importe qu'elle autre panneau
> d'info à valeur touristique.
>
> (Pour préciser, je ne suis contre que sur l'utilisation du tag 
> tourism=information
> pour ce cas)
>
>
> Le mer. 12 févr. 2020 à 21:07,  a
> écrit :
>
>> Si on regarde ce qui touche à la surveillance côté taginfo:
>>
>> surveillance=outdoor/public/indoor.
>> surveillance:type=camera
>> surveillance:zone=traffic/building/town/parking...
>>
>> Ça me semble possible de l'indiquer aussi ici.
>>
>> Certes ce n'est pas du tourisme mais board_type=sport ou
>> board_type=public_transport non plus.
>>
>> Simplement on a/aurait la chaîne tourism=information / information=board
>> / board_type=surveillance.
>>
>> C'est bien ce qu'a écrit Shohreh
>> 
>> sur le wiki.
>>
>> Et non ça ne me choque pas. Même si la caméra n'a pas de reconnaissance
>> faciale pour ne fliquer que les touristes^^.
>>
>> Jean-Yvon
>> Le 12/02/2020 à 20:49, Florimond Berthoux - florimond.berth...@gmail.com
>> a écrit :
>>
>> Mon avis que ce tourism=information est une erreur, il y a rien de
>> touristique dans ce panneau.
>> information=board et board_type=* se suffisent à eux même.
>>
>> 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.
>>
>> ___
>> 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] Tagger correctement les panneaux entrées de villes & villages

2020-02-12 Par sujet Florimond Berthoux 
Sur le wiki en créant une page, par exemple en anglais tu suis un des liens
et tu appuies sur "créer"
https://wiki.openstreetmap.org/wiki/Key:pole:sealed
ou https://wiki.openstreetmap.org/wiki/Key:support:sealed

Le mar. 11 févr. 2020 à 21:30,  a écrit :

> Ok, je vais tenter avec cela.
> Pour le documenter, comment ça se passe?
>
> Merci!
>
> --
> *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  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
>


-- 
Florimond Berthoux
___
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 ?

2020-02-12 Par sujet Florimond Berthoux 
«An *information* source for tourists, travellers and visitors.»
Je visite rarement les supermarchés, les halls d'entreprises ou les
piscines municipales.
J'y vais mais je ne visite pas.

Le problème c'est que les consommateurs de cette données vont l'interpréter
comme une information touristique alors que ça ne l'est pas.
Exemple, ça sera affiché sur CyclOSM comme n'importe qu'elle autre panneau
d'info à valeur touristique.

(Pour préciser, je ne suis contre que sur l'utilisation du tag
tourism=information
pour ce cas)


Le mer. 12 févr. 2020 à 21:07,  a écrit :

> Si on regarde ce qui touche à la surveillance côté taginfo:
>
> surveillance=outdoor/public/indoor.
> surveillance:type=camera
> surveillance:zone=traffic/building/town/parking...
>
> Ça me semble possible de l'indiquer aussi ici.
>
> Certes ce n'est pas du tourisme mais board_type=sport ou
> board_type=public_transport non plus.
>
> Simplement on a/aurait la chaîne tourism=information / information=board /
> board_type=surveillance.
>
> C'est bien ce qu'a écrit Shohreh
> 
> sur le wiki.
>
> Et non ça ne me choque pas. Même si la caméra n'a pas de reconnaissance
> faciale pour ne fliquer que les touristes^^.
>
> Jean-Yvon
> Le 12/02/2020 à 20:49, Florimond Berthoux - florimond.berth...@gmail.com
> a écrit :
>
> Mon avis que ce tourism=information est une erreur, il y a rien de
> touristique dans ce panneau.
> information=board et board_type=* se suffisent à eux même.
>
> 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.
>
> ___
> 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] Tag panneau zone vidéo surveillance ?

2020-02-12 Par sujet osm . sanspourriel 

Si on regarde ce qui touche à la surveillance côté taginfo:

surveillance=outdoor/public/indoor.
surveillance:type=camera
surveillance:zone=traffic/building/town/parking...

Ça me semble possible de l'indiquer aussi ici.

Certes ce n'est pas du tourisme mais board_type=sport ou
board_type=public_transport non plus.

Simplement on a/aurait la chaîne tourism=information / information=board
/ board_type=surveillance.

C'est bien ce qu'a écrit Shohreh

sur le wiki.

Et non ça ne me choque pas. Même si la caméra n'a pas de reconnaissance
faciale pour ne fliquer que les touristes^^.

Jean-Yvon

Le 12/02/2020 à 20:49, Florimond Berthoux - florimond.berth...@gmail.com
a écrit :

Mon avis que ce tourism=information est une erreur, il y a rien de
touristique dans ce panneau.
information=board et board_type=* se suffisent à eux même.

Le mar. 11 févr. 2020 à 16:27, Shohreh mailto:codecompl...@free.fr>> a écrit :

Ok, donc c'est parti pour

tourism=information
information=board
board_type=surveillance

Merci.

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

Re: [OSM-talk-fr] Demande d'intervention de tiers sur un conflit d'édition

2020-02-12 Par sujet Philippe Verdy 
Attention, on ne peut pas parler de "piste cyclable" quand les cyclistes
sont incités à devoir utiliser un trottoir, déjà peu large car rétréci par
les emplacements de stationnement, les emplacements de dépôt des poubelles
et conteurs de recyclage et des barrières de protection bloquand le passage
des piétons et cyclistes vers la chaussée, et les arbres: les cyclistes
partagent alors le trottoir... mais à pied, ils ne peuvent pas y rouler

(je parle de là où il n'y a pas de "ségrégation" possible des piétons ou
cyclistes faute de place, par au moins un marquage au sol, ou alors ils
doivent rester sur la chaussée séparée (même si ici c'est une nationale
avec un très fort trafic le long de la Seine rive droite vers la Défense).
Un trottoir de moins de 3 mètres de large ne permet pas cette ségrégation,
c'est alors juste un trottoir même si à une extrémité il y a eu une courte
ségrégation ou un fléchage de vélo pour demander aux cyclistes de se
diriger vers le trottoir... et de descendre de vélo avant la fin de
marquage sur quelques mètres.

On peut noter dans cette zone un découpage fin des trottoirs et des places
de stationnement individuelles, et de diverses barrières et plots de
séparation (il y a aussi des difficultés à ces troittoirs concernant les
sorties de parkings privés: rouler sur le trottoir ne donne pas assez de
visibilité, un vélo ne peut pas y rouler en sécurité sans risque pour les
autres usagers du trottoir: entrées/sorties de garages, et piétons. Le
cycliste doit devenir piéton, ce n'est donc plus un piste "cyclable" du
tout, juste un trottoir.


Le mer. 12 févr. 2020 à 15:53, Stéphane Péneau 
a écrit :

> Le 12/02/2020 à 13:31, Charles MILLET a écrit :
> >
> >> Je ne suis pas à l'aise avec l'idée de faire un signalement au DWG
> >> car en dehos de ce genre de comportement, ses contributions sont
> >> bonnes. Pensez-vous qu'il faille le faire ?
>
>
> Oui, mais j'ai un point de vue biaisé puisque partie prenante.
>
> Stf
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2020-02-12 Par sujet Florimond Berthoux 
Mon avis que ce tourism=information est une erreur, il y a rien de
touristique dans ce panneau.
information=board et board_type=* se suffisent à eux même.

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
>


-- 
Florimond Berthoux
___
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

2020-02-12 Par sujet Philippe Verdy 
Il serait temps de commencer à réfléchir à la différenciation du découpage
administratif et du découpage urbain du territoire, comme le fait l'INSEE
justement.

Le premier (communes, etc.) évolue à coup de lois et décrets préfectoraux,
le second (agglomérations, zones urbaines) en fonction de l'activité et des
permis de construire ou lotir des communes (et maintenant du PLU communal
ou communautaire devenu obligatoire), mais une décision de lotir ou
construire ne signifie pas qu'il y a une occupation réelle, c'est
désynchronisé dans le temps (et des zones bâties disparaissent aussi par
des démolitions ou reconversions, y compris les démolition sur le littoral
ou les zones inondables).

Le découpage urbain de l'INSEE ne tient donc pas compte du zonage
d'aménagement des communes et de leur PLU mais de la situation réelle, pour
le découpage fin seulement, car au delà l'INSEE fait des regroupements de
communes entières (ou communes déléguées/associées) en incluant à la fois
leur domaine rural et urbain, en prenant le niveau administratif le plus
approprié pour faire ces regroupements statistiques. Ce découpage a une
finalité statistique et devrait donc être de type boundary=statistical (en
dessous du niveau des agglomérations, pour les communes les plus peuplées,
l'INSEE ajoute les RIS qu'on n'a pas encore modélisés, mais correspondent
au modèle du recensement, boundary=census_unit, mais qui ne tient pas
compte du découpage urbain mais des frontières administratives des communes
au niveau 8, ou celles des arrondissements, ou communes déléguées/associées
au niveau 9, ce découpage servant aussi en partie à délimiter les
circonscriptions électorales mais avec des exceptions notamment pour les
cantons, car les seuils dépendent des lois électorales pour "égaliser" la
population sans forcément tenir compte du découpage administratif, ou
statistique en RIS).

Vient ensuite le découpage de la réglementation routière qui définit les
"agglomérations routières" en fonction de la signalisation décidée ou
concertée par les communes et préfets. Ces agglomérations ne correspondent
pas non plus exactement aux agglomérations de l'INSEE. Ce zonage routier
(impliqué par les panneaux EB10/EB20 là où il y en a) est à part et a de
nombreuses exceptions qui ne tiennent pas du tout compte des autres
découpages, mais aussi de la nature des voies, leur équipement, les zones
de danger, la présence d'écoles ou zones sportives et de loisirs, ou encore
des nécessités environnementales.

Ce découpage des agglomérations routières pour l'instant a été tenté en
divers endroits en utilisant une relation "boundary=urban", qui ne me
semble pas être le bon tag mais dont le tracé remplit cet objectif (celui
de définit une limite de vitesse par défaut sur les voies qui y sont
incluses). Mais les limites de vitesse sont compliquées car elles sont
définies voie par voie (et même selon le sens de circulation), cela n'a pas
beaucoup de sens de délimiter des zones et il est plus simple de définir
directement le "maxspeed=*" sur les voies elles-mêmes. Si on conserve ces
relations, je verrais d'un bon oeil le changement du tag en quelque chose
de plus clair ("boundary=restriction"+"maxspeed=*").




Le mer. 12 févr. 2020 à 19:20,  a écrit :

> Le 12/02/2020 à 18:02, Christian Quest - cqu...@openstreetmap.fr a écrit :
>
> place=municipality est dans un tableau "administratively declared places",
> ce qui va très bien avec nos communes nouvelles rurales. Il est par contre
> très peu utilisé: quelques milliers à peine sur le monde entier !
>
> On ne va pas non plus en ajouter des milliers
> 
> (713).
>
> La troisième règle non écrite d'OSM: toujours, toujours relire le wiki ;)
>
> Relire la bonne page du wiki, car il arrive qu'on trouve des infos pas à
> jour, incomplètes (traduction françaises pas à jour) ou incohérentes avec
> d'autres pages toujours sur le wiki.
>
> Je suis pour mettre des place=municipality avec les populations qui vont
> bien sur les communes nouvelles.
>
> Je maintiens que mettre la population sur l'admin_centre c'est ambigu dans
> le cas où la commune (municipality) n'est pas uniquement urbaine : est-ce
> celle du town/village ou celles additionnées des town/village/hamlet... ?
>
> Maintenant on peut décider qu'en France :
>
> -soit les population=* ne sont mis que sur les admin_centre/label des
> communes (niveau 8 ou aussi niveau 9 ?).
> - soit que les population=* qui sont mis sur admin_centre/label des
> communes (niveau 8 ou aussi niveau 9 ?) sont ceux de l'INSEE pour la
> commune et que les éventuels autres sont des informations autres qui ne
> s'ajoutent pas au total (et donc on met place=municipality pour lever
> l'ambiguïté ? Bof, c'est bien de savoir si le bourg est un town ou un
> village). Mais alors, pourquoi avoir enlevé INSEE= sur ces nœuds ?
> - autre ?
>
> Dans le cas d'une commune nouvelle où on met place=municipality sur un
> label, pas de

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

2020-02-12 Par sujet osm . sanspourriel 

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


place=municipality est dans un tableau "administratively declared
places", ce qui va très bien avec nos communes nouvelles rurales. Il
est par contre très peu utilisé: quelques milliers à peine sur le
monde entier !

On ne va pas non plus en ajouter des milliers

(713).

La troisième règle non écrite d'OSM: toujours, toujours relire le wiki ;)


Relire la bonne page du wiki, car il arrive qu'on trouve des infos pas à
jour, incomplètes (traduction françaises pas à jour) ou incohérentes
avec d'autres pages toujours sur le wiki.

Je suis pour mettre des place=municipality avec les populations qui vont
bien sur les communes nouvelles.

Je maintiens que mettre la population sur l'admin_centre c'est ambigu
dans le cas où la commune (municipality) n'est pas uniquement urbaine :
est-ce celle du town/village ou celles additionnées des
town/village/hamlet... ?

Maintenant on peut décider qu'en France :

-soit les population=* ne sont mis que sur les admin_centre/label des
communes (niveau 8 ou aussi niveau 9 ?).
- soit que les population=* qui sont mis sur admin_centre/label des
communes (niveau 8 ou aussi niveau 9 ?) sont ceux de l'INSEE pour la
commune et que les éventuels autres sont des informations autres qui ne
s'ajoutent pas au total (et donc on met place=municipality pour lever
l'ambiguïté ? Bof, c'est bien de savoir si le bourg est un town ou un
village). Mais alors, pourquoi avoir enlevé INSEE= sur ces nœuds ?
- autre ?

Dans le cas d'une commune nouvelle où on met place=municipality sur un
label, pas de soucis.

Jean-Yvon

___
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

2020-02-12 Par sujet Christian Quest 

Le 12/02/2020 à 17:04, Rpnpif via Talk-fr a écrit :
Merci d'avoir pris en compte ce problème et merci pour vos suggestions 
(place=municipality) qui me font réfléchir..


Le problème est assez peu différent pour les communes anciennes et non 
fusionnées récemment ayant plusieurs agglomérations séparées. 
L'admin-centre n'est pas forcément l'agglomération la plus grande mais 
celle où est se situe le bâtiment de la mairie et on y met un place=* 
(Oui, Florimond, j'ai bien compris tes griefs et exemples).


J'aurais une suggestion qui va peut-être choquer : ce serait de 
remplacer place=village/town des anciennes communes incluses dans la 
fusion par des place=quarter/neighborough et de placer le nom de la 
nouvelle commune sur l'admin-centre en place=village/town/city comme 
on le fait pour Nantes, Paris, etc. toutes issues de fusions plus ou 
moins anciennes (oui bon la différence, c'est que ces communes ont 
gardé le nom de la commune principale).


Parce que, à priori, les communes dites déléguées ne sont que de 
futurs arrondissements ou quartiers de la nouvelle. Aujourd'hui, ce 
sont des sortes de quartiers à statut spécial.


Il me semble qu'on peut parler de quartiers quand c'est un sous ensemble 
d'une agglomération (fusion ou pas), mais pour le cas de la majorité des 
communes nouvelles, on est en zone rurale et on a des bourgs séparés, 
isolés les uns des autres.


Vu du terrain, ce sont des villages, qui oui, sont regroupés 
(uniquement) administrativement, mais on ne peut pas les considérer 
comme des quartiers.


Je m'appuie sur mon expérience locale autour de mon point de chute 
bourguignon avec plusieurs communes nouvelles à proximité. Si je 
demandais aux habitants leur point de vue, je doute fort qu'un seul se 
considère comme habitant d'un quartier de la commune nouvelle.


De même, ma commune point de chute (non fusionnée) se compose en fait de 
7 hameaux... et pas de quartiers non plus.


Petit tour sur https://wiki.openstreetmap.org/wiki/Key:place pour se 
remettre la logique de place=* en tête...


Le wiki est plutôt clair avec 4 tableaux... quarter et neighbourhood 
sont des parties de suburb qui est lui même une partie de city/town, 
donc de grosses agglomérations. C'est d'ailleurs uniquement dans un 
tableau "urban".


Pour le tableau "rural", on a town, village, hamlet, isolated_dwelling, 
farm, allotments... et rien d'autre ce qui me semble logique et lié à la 
population (le retour) qui se trouve sur ces place=*.


place=municipality est dans un tableau "administratively declared 
places", ce qui va très bien avec nos communes nouvelles rurales. Il est 
par contre très peu utilisé: quelques milliers à peine sur le monde entier !


La troisième règle non écrite d'OSM: toujours, toujours relire le wiki ;)

--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Structures de soins en addictologie (CSAPA, CAARUD…)

2020-02-12 Par sujet Rpnpif via Talk-fr 

Réponse rapide.

Le 12/02/2020 à 11:01, Yves P. a écrit :

Bonjour,

[...]
*Faut-il nettoyer les données OSM ?*
Une recherche (NOMINATIM) avec le terme CSAPA 
 renvoi 
« Clinique », « Hospital », « Service social » , « Salle polyvalente ».


Une recherche Overpass avec "social_facility:for"=drug_addicted en 
France  montre que les tags 
amenity=social_facility et social_facility=* ne sont pas toujours 
présents.
Je dirais plutôt proposer une règle Osmose au lieu d'une modification 
massive.


--
Rpnpif


___
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

2020-02-12 Par sujet Rpnpif via Talk-fr 
Merci d'avoir pris en compte ce problème et merci pour vos suggestions 
(place=municipality) qui me font réfléchir..


Le problème est assez peu différent pour les communes anciennes et non 
fusionnées récemment ayant plusieurs agglomérations séparées. 
L'admin-centre n'est pas forcément l'agglomération la plus grande mais 
celle où est se situe le bâtiment de la mairie et on y met un place=* 
(Oui, Florimond, j'ai bien compris tes griefs et exemples).


J'aurais une suggestion qui va peut-être choquer : ce serait de 
remplacer place=village/town des anciennes communes incluses dans la 
fusion par des place=quarter/neighborough et de placer le nom de la 
nouvelle commune sur l'admin-centre en place=village/town/city comme on 
le fait pour Nantes, Paris, etc. toutes issues de fusions plus ou moins 
anciennes (oui bon la différence, c'est que ces communes ont gardé le 
nom de la commune principale).


Parce que, à priori, les communes dites déléguées ne sont que de futurs 
arrondissements ou quartiers de la nouvelle. Aujourd'hui, ce sont des 
sortes de quartiers à statut spécial.


--
Rpnpif

Le 11/02/2020 à 18:03, Christian Quest a écrit :

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





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

Re: [OSM-talk-fr] Demande d'intervention de tiers sur un conflit d'édition

2020-02-12 Par sujet Stéphane Péneau 

Le 12/02/2020 à 13:31, Charles MILLET a écrit :


Je ne suis pas à l'aise avec l'idée de faire un signalement au DWG 
car en dehos de ce genre de comportement, ses contributions sont 
bonnes. Pensez-vous qu'il faille le faire ?



Oui, mais j'ai un point de vue biaisé puisque partie prenante.

Stf


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

Re: [OSM-talk-fr] Demande d'intervention de tiers sur un conflit d'édition

2020-02-12 Par sujet Charles MILLET 

Pardon, mauvais lien, voilà le bon :

https://www.openstreetmap.org/changeset/80853048

On 12/02/2020 13:24, Charles MILLET wrote:

Bonjour à tous,

Voilà donc, sans surprise, Meersbrook a supprimé le chemin qui était 
en question et en a profiter pour en supprimer d'autres. Pour c'est 
clairement de la malveillance et une forme de vengeance. Aucune 
discussion sur ces suppressions.


Voilà le changeset en question : 
https://www.openstreetmap.org/changeset/80698774


Je ne suis pas à l'aise avec l'idée de faire un signalement au DWG car 
en dehos de ce genre de comportement, ses contributions sont bonnes. 
Pensez-vous qu'il faille le faire ? Je serais également favorable à un 
revert sur ce changeset, qu'en pensez vous ?


Charles.

On 07/02/2020 15:49, Charles MILLET wrote:

Bonjour à tous

J'ai à nouveau un problème de conflit d'édition avec l'utilisateur 
Meersbrook. cf. https://www.openstreetmap.org/changeset/79878637


En résumé il a supprimé l'ajout d'une piste cyclable (discutable mais 
ce n'est pas le sujet) pour la remplacer par un track. Ce sujet a 
déjà été discuté avec lui pour des pratique identique à Caen et je 
suppose qu'il le fait malheureusement régulièrement. Je suis à la 
recherche des discussions à ce sujet pour reprendre les arguments.


Pour info cette "piste cyclable" est utilisable par les piétons et 
donc nécessite un way séparé et la précision du segregated=yes


Je suis à la recherche d'un peu d'arbitrage car mes échanges avec 
Meersbrook sont insupportables et totalement non constructif à cause 
de son ton ultra arrogant et différents reproches totalement délirant.


Charles


___
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

2020-02-12 Par sujet leni 

Le 12/02/2020 à 00:33, marc marc a écrit :

on ets en plein dogme,
Il me semble que c'est plutôt un état de l'existant (il me semblait que 
tu avais dit qu'il était difficile de retrouver les ref:FR: ...)

  cfr Réseau Arc en ciel de bus en france
Que t'a-t-il fait ? il me semble qu'il n'a rien inventé, il n'a fait que 
ce qui est dans le wiki ; et je n'ai pas encore d'avis sur l’intérêt de 
ta solution (pour les transport en commun) est-elle mieux ? peut-être ? 
mais elle me parait ne pas être assez avancée pour être appliquée. 
Lorsqu'elle pourra régler tous les cas, on verra.


Car, Il n'y a pas que des arrêts communs que entre régional et local, et 
je ne sais pas où est BATO.


Voir https://transport.data.gouv.fr/ : Je n'ai pas tout analysé dans les 
gtfs, mais on a des n° d'arrêts différents pour chaque réseau.


On aura des arrêts communs pour les réseaux longue distance ; exemple 
avec la Gare routière de Toulouse qui voit les réseaux longue distance 
et régionaux :


Flixbus :
FLIXBUS:4878,,Toulouse,"68 - 70 Boulevard Pierre Semard, 31500 Toulouse, 
France",43.612522,1.452612,,,0,,Europe/Paris,2,


Eurolines :
NB:Stop:2596,Toulouse Gare Routière,,43.6126,1.452641,NB:Zone:2596,0,

Ouibus :
XTS,,Toulouse,,43.61329878,1.452226002,Europe/Paris,1

Arc-en-Ciel (Réseau régional en Haute-Garonne liO31) :
STOPPOINT:02001,61103,TOULOUSE - Gare 
Routière,,43.612939,1.452511,,,0,STOPAREA:02001,,1


Réseau régional en Ariège liO09 :
S03228,,"TOULOUSE - GARE ROUTIERE","",43.613276,1.452145,,,1,,,

On aura des arrêts communs à l'intérieur d'une même région entre deux 
départements d'un réseaux régional  (comme ci-dessus)


Entre régions différentes

Entre réseau régional scolaire et réseau régional lignes régulières

entre réseau régional lignes régulières et réseau de regroupement de 
communes


entre réseau régional scolaire et réseau de regroupement de communes

entre réseau regroupement de communes et communal

et j'en oublie ...


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

Re: [OSM-talk-fr] Demande d'intervention de tiers sur un conflit d'édition

2020-02-12 Par sujet Charles MILLET 

Bonjour à tous,

Voilà donc, sans surprise, Meersbrook a supprimé le chemin qui était en 
question et en a profiter pour en supprimer d'autres. Pour c'est 
clairement de la malveillance et une forme de vengeance. Aucune 
discussion sur ces suppressions.


Voilà le changeset en question : 
https://www.openstreetmap.org/changeset/80698774


Je ne suis pas à l'aise avec l'idée de faire un signalement au DWG car 
en dehos de ce genre de comportement, ses contributions sont bonnes. 
Pensez-vous qu'il faille le faire ? Je serais également favorable à un 
revert sur ce changeset, qu'en pensez vous ?


Charles.

On 07/02/2020 15:49, Charles MILLET wrote:

Bonjour à tous

J'ai à nouveau un problème de conflit d'édition avec l'utilisateur 
Meersbrook. cf. https://www.openstreetmap.org/changeset/79878637


En résumé il a supprimé l'ajout d'une piste cyclable (discutable mais 
ce n'est pas le sujet) pour la remplacer par un track. Ce sujet a déjà 
été discuté avec lui pour des pratique identique à Caen et je suppose 
qu'il le fait malheureusement régulièrement. Je suis à la recherche 
des discussions à ce sujet pour reprendre les arguments.


Pour info cette "piste cyclable" est utilisable par les piétons et 
donc nécessite un way séparé et la précision du segregated=yes


Je suis à la recherche d'un peu d'arbitrage car mes échanges avec 
Meersbrook sont insupportables et totalement non constructif à cause 
de son ton ultra arrogant et différents reproches totalement délirant.


Charles


___
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

2020-02-12 Par sujet leni 

Le 11/02/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 ?
J'ai préparé un tableau avec lbo (plus facile à trier) avec une colonne 
(qui ressemble Map Features) et une national/local, je le mettrais ici 
quand j'aurais avancé




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


désolé, ce devait être pendant une de mes absences



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



Il me semblait t'avoir répondu et modifié le chapitre Occitanie
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2020-02-12 Par sujet François Lacombe 
Bonjour

Des arguments sont toujours attendus pour faire autrement.

3 points :
* Qui sommes-nous pour affirmer que le nom de la ref ne collisionnera pas
ailleurs ?

* Le namespace permet de spécialiser la ref, d'y associer une documentation
complète et de séparer les concepts.
En ce qui me concerne, toutes les ref crées selon ce motif sont documentées
et vous serez bien inspirés non seulement de proposer cette documentation
sur une clé unique et aussi d'aller les valider dans les éditeurs

* Dans des cas de multi-ref (plus souvent le cas qu'on ne le pense), on
distingue clairement les différents concepts en jeu.
Avoir ref=* + ref:autre n'est pas acceptable à plusieurs titres : on
perdrait l'info de ce qui est effectivement lu sur le terrain (qui peut
contenir plusieurs champs)
Exemple : https://www.openstreetmap.org/relation/6668144

J'ai reporté ces arguments sur le wiki
https://wiki.openstreetmap.org/wiki/Talk:France/Liste_des_r%C3%A9f%C3%A9rences_nationales#Arguments_pour.2Fcontre_le_recours_aux_namespaces_locaux

Qu'il y ait des références mal définies, c'est vrai et du temps est
nécessaire pour les reformuler
De là à parler de dogme, c'est pas le cas n'est-ce pas ?

Bonne journée

François

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

[OSM-talk-fr] Structures de soins en addictologie (CSAPA, CAARUD…)

2020-02-12 Par sujet Yves P. 
Bonjour,

La page FR:Comment cartographier un (santé) 
 
décrit comment définir un Centre de Soins d'Accompagnement et de Prévention en 
Addictologie 

 (CSAPA).
J’ai ajouté Centre d’accueil et d’accompagnement à la réduction des risques 
pour usagers de drogues 

 (CAARUD)

Plusieurs questions se posent :

Quelles valeurs de social_facility utiliser ?
Les CSAPA sont parfois des lieux d’hébergement (group_home ou assisted_living 
?) mais ce n’est pas la règle.
Faut-il alors proposer ambulatory_care ou outreach ?

Les CAARUD peuvent être mobiles : les intervenants éducateurs ou infirmiers se 
déplacent alors dans d’autres structures, aux domiciles des usagers, voir dans 
la rue.
Faut-il utiliser ambulatory_care (la page FR:Key:social_facility 

 parle de « maraude » mais ça ne correspond pas à l’usage en France) ou plutôt 
outreach (ce qui correspond bien à la définition de wikipedia en anglais 
) ?

Comment nommer ces structures pour les retrouver facilement avec Nominatim tout 
en ne surchargeant pas la carte ?
Les CSAPA et/ou CAARUD sont souvent des structures internes à des associations 
loi 1901, parfois à des cliniques ou hôpitaux.
Ces termes (CSAPA, CAARUD) ne font pas à proprement partie du nom.

Pour celui de Lons-le-Saunier 
,
 j’ai utilisé :

name
Passerelle 39
Le nom de l’association locale
short_name
CSAPA

alt_name
Centre de Soins, d'Accompagnement et de Prévention en Addictologie

operator
Oppelia
Le nom de l’association « mére »

Il y a aussi un CAARUD à l’autre bout du bâtiment (qui est aussi mobile 
certains jours de la semaine).

Faut-il créer un autre POI avec le même nom ?
Ou regrouper CAARUD et CSAPA dans le même POI avec des valeurs multiples pour 
short_name, alt_name et type:FR:FINESS ?

Faut-il nettoyer les données OSM ?
Une recherche (NOMINATIM) avec le terme CSAPA 
 renvoi « Clinique », « 
Hospital », « Service social » , « Salle polyvalente ».

Une recherche Overpass avec "social_facility:for"=drug_addicted en France 
 montre que les tags amenity=social_facility 
et social_facility=* ne sont pas toujours présents.

Il y a parfois uniquement office=association comme tag principal.

La recherche Overpass globale  montre 
l’utilisation des tags suivants :
amenity=college, clinic, doctors, hospital, nursing_home, social_centre ou 
social_facility

social_facility=advice, ambulatory_care, assisted_living, clinic, day_care, 
day_centre, drugs, group_home, healthcare, nursing_home, outreach, 
rehabilitation, residential_home, safe_injection_site, shelter, social_club, 
workshop ou yes

Et parfois quelques tags complémentaires :
health_facility:type=counselling_centre

health_service:counselling=yes
health_service:prevention=yes

healthcare:speciality=addiction, physiatry ou psychiatry
healthcare=clinic, doctor, hospital ou rehabilitation

counselling_type:addiction=yes
counselling_type:drugs=yes

—
Yves

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

2020-02-12 Par sujet Shohreh 
Jérôme Seigneuret-3 wrote
> penses à le décrire sur le wiki en Anglais et Français au moins

Fait.



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

2020-02-12 Par sujet Florimond Berthoux 
Le mer. 12 févr. 2020 à 05:08, Jérôme Amagat  a
écrit :

>
>
> Le mar. 11 févr. 2020 à 15:17, Rpnpif via Talk-fr <
> talk-fr@openstreetmap.org> 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.
>

La plus part des noms de communes sous la forme XXX leṣ|lès|des|en|sur...
sont souvent que des formes administrative pour différencier des homonymies
à l’échelle nationale.
Exemple : j’ai habité dans la commune de Lassay les Châteaux en campagne,
et j’allais au collège à Lassay.

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