Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

2020-07-09 Par sujet Donat ROBAUX 
Hello,

Concernant l'adresse, j'applique la règle de Christian, sinon je ne sais
plus où j'avais vu ca, mais sur les casernes de pompiers, j'utilise le le
tag *addr:full=* avec l'adresse complète en langage naturel, c'est-à-dire
"23 rue du Général de Gaulle XXYYY Trifouillis-les-Oies".

Ca permet de ne pas dupliquer le noeud addresse et permet des
réutilisations faciles, par exemple dans uMap.

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

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

2020-07-09 Par sujet Florian LAINEZ 
>
> J'ai regardé le fichier CNC, je ne vois pas d'adresse dedans. Comment
> ont-elles été ajoutées dans OSM ?
>
A la force de l'huile de coude des contributeurs en se basant sur diverses
sources à notre dispo.

Les données sont extraites d'OSM tous les jours via
https://geodatamine.fr/dump/ puis publiées sur
https://www.data.gouv.fr/fr/datasets/cinemas-issus-dopenstreetmap/
Tant que nous discutons du bon tag à utiliser dans cette discussion, les
adresses ne sont pas encore incluses dans l'export.
Adrien peut te détailler encore plus le process d'export si besoin. C'est
lui le "faiseur" ;)

A-t-on 100% des adresses correspondantes aux cinémas déjà dans OSM ? (Et
> correctement mappées en tant que telles ?)
>
Non, pas du tout mais c'est bien l'objectif.


> J'ai regardé celui près de chez moi, aucune info d'adresse dessus, quelle
> adresse aura-t-il dans l'export ? La plus proche qu'on trouve (donc un
> simple géocodage inverse) ?
>
A ce stade nous n'avons réalisé que des opérations manuelles.

> Je sent qu'on va créer une nouvelle règle... "ne pas taguer pour faciliter
> un export" ;)
>
Je comprends la logique mais l'usage "contact" vaut bien autant que l'usage
"adresse" ;)
Bien que l'on devrait faire un max d'effort pour faciliter la maintenance,
la donnée ne devrait pas non plus être créée pour ne pas être utilisable en
aval, au risque de rendre OSM inutile. Le principe d'une base de données
est bien de pouvoir faire des requêtes automatiques pour extraire des
données en masse. Trouvons ensemble le meilleur moyen d'y parvenir sans
tout casser :P

Le jeu. 9 juil. 2020 à 08:57, Christian Quest  a
écrit :

> Le 08/07/2020 à 17:42, Florian LAINEZ a écrit :
>
> Merci pour la prise de recul qui me paraît également nécessaire Christian.
> J'ai tout comme toi un problème avec l'info dupliquée qui pose
> indubitablement problème. Dans un monde idéal, l'adresse
> n'apparaîtrait qu'une fois et qu'une seule. Malheureusement le seul moyen
> d'y parvenir me semble être de créer des relations, ce qui complique
> vraiment le modèle et que l'on devrait donc éviter dans la mesure du
> possible.
>
> On est d'accord que pour l'usage "adresse", le point tel qu'il est défini
> et utilisé aujourd'hui fait le taff. Ce que nous essayons maintenant de
> trouver, c'est donc le moyen de gérer au mieux l'utilisation "contact".
>
>> Pourquoi dupliquerai-t-on l'adresse sur chaque entrée/accès et pas le
>> type de POI (c'est une entrée... de cinéma, un sortie de secours... de
>> cinéma, etc) ? Où est la cohérence globale ? Pourquoi répéter l'un mais pas
>> l'autre ?
>
> C'est un bon point. J'ai toujours été embêté par ces entrées qui ne sont
> pas reliées au bâtiment et il me paraissait que l'adresse soit un moyen
> élégant d'y parvenir mais tu as raison, je dois faire fausse route en
> associant les deux problématiques. Tant pis pour les pompiers qui ne seront
> pas guidés vers l'issue de secours
>
>
> Un noeud entrance=* se situe sur le polygone du building=*... tu oublies
> qu'OSM c'est de la donnée géo ?
>
> L'abus de relation vient souvent du manque d'exploitable géographique des
> données OSM. Les multipolygones qui entourent une commune (relations par
> commodité pour segmenter les boundary et non par besoin sémantique), font
> qu'on ne met plus de is_in=* partout depuis un bon bout de temps ;)
>
> C'est quand on ne peut plus résoudre sans ambiguïté un lien entre deux par
> la géographie qu'on passe à la relation où qu'on ajoute des tags pour lever
> l'ambiguïté (par exemple les forward/backward sur les stop).
>
>
> On en revient donc à l'usage "contact". Dans le use case que j'ai exposé,
> il s'agit d'exporter tous les cinémas de France accompagnés de leur adresse
> sur data.gouv
> 
>
> Je sent qu'on va créer une nouvelle règle... "ne pas taguer pour faciliter
> un export" ;)
>
>
> *On a 3 solutions :*
> *1. *on considère que l'adresse ne doit pas être dupliquée : on la laisse
> donc sur un node flottant
> C'est plus avantageux pour la maintenance, c'est parfait pour l'usage
> "adresse" mais c'est un cauchemar pour l'export et l'usage "contact".
> Quel node avec la bonne adresse associer au POI ? C'est très difficile de
> retrouver cette info non explicite.
>
> *2. *on utilise contact:XXX pour dupliquer l'adresse sur le POI.
> Pas top pour la maintenance, incompatible avec les outils d'édition
> internationaux mais l'utilisation est très claire car les tags sont
> différents pour les 2 usages. Parfait pour les 2 usages donc.
> C'est la solution que nous avons choisi à Montrouge pour l'instant.
>
> *3. *on duplique l'adresse du point sur le POI en lui rajoutant
> addr:role=contact
> Pas top pour la maintenance, compatible avec les outils d'édition
> internationaux, bien adapté pour tous les lieux où il n'existe aucun point
> adresse (ce qui représente la majorité des cas pour les cinémas), mais il
> est nécessaire de faire une évolution pour l'utilisation

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

2020-07-09 Par sujet Christian Quest 

Le 08/07/2020 à 17:42, Florian LAINEZ a écrit :


Merci pour la prise de recul qui me paraît également nécessaire Christian.
J'ai tout comme toi un problème avec l'info dupliquée qui pose 
indubitablement problème. Dans un monde idéal, l'adresse 
n'apparaîtrait qu'une fois et qu'une seule. Malheureusement le seul 
moyen d'y parvenir me semble être de créer des relations, ce qui 
complique vraiment le modèle et que l'on devrait donc éviter dans la 
mesure du possible.


On est d'accord que pour l'usage "adresse", le point tel qu'il est 
défini et utilisé aujourd'hui fait le taff. Ce que nous essayons 
maintenant de trouver, c'est donc le moyen de gérer au mieux 
l'utilisation "contact".


Pourquoi dupliquerai-t-on l'adresse sur chaque entrée/accès et pas
le type de POI (c'est une entrée... de cinéma, un sortie de
secours... de cinéma, etc) ? Où est la cohérence globale ?
Pourquoi répéter l'un mais pas l'autre ?

C'est un bon point. J'ai toujours été embêté par ces entrées qui ne 
sont pas reliées au bâtiment et il me paraissait que l'adresse soit un 
moyen élégant d'y parvenir mais tu as raison, je dois faire fausse 
route en associant les deux problématiques. Tant pis pour les pompiers 
qui ne seront pas guidés vers l'issue de secours



Un noeud entrance=* se situe sur le polygone du building=*... tu oublies 
qu'OSM c'est de la donnée géo ?


L'abus de relation vient souvent du manque d'exploitable géographique 
des données OSM. Les multipolygones qui entourent une commune (relations 
par commodité pour segmenter les boundary et non par besoin sémantique), 
font qu'on ne met plus de is_in=* partout depuis un bon bout de temps ;)


C'est quand on ne peut plus résoudre sans ambiguïté un lien entre deux 
par la géographie qu'on passe à la relation où qu'on ajoute des tags 
pour lever l'ambiguïté (par exemple les forward/backward sur les stop).



On en revient donc à l'usage "contact". Dans le use case que j'ai 
exposé, il s'agit d'exporter tous les cinémas de France accompagnés de 
leur adresse sur data.gouv 



Je sent qu'on va créer une nouvelle règle... "ne pas taguer pour 
faciliter un export" ;)




*On a 3 solutions :*
*1. *on considère que l'adresse ne doit pas être dupliquée : on la 
laisse donc sur un node flottant
C'est plus avantageux pour la maintenance, c'est parfait pour l'usage 
"adresse" mais c'est un cauchemar pour l'export et l'usage "contact".
Quel node avec la bonne adresse associer au POI ? C'est très difficile 
de retrouver cette info non explicite.


*2. *on utilise contact:XXX pour dupliquer l'adresse sur le POI.
Pas top pour la maintenance, incompatible avec les outils d'édition 
internationaux mais l'utilisation est très claire car les tags sont 
différents pour les 2 usages. Parfait pour les 2 usages donc.

C'est la solution que nous avons choisi à Montrouge pour l'instant.

*3. *on duplique l'adresse du point sur le POI en lui rajoutant 
addr:role=contact
Pas top pour la maintenance, compatible avec les outils d'édition 
internationaux, bien adapté pour tous les lieux où il n'existe aucun 
point adresse (ce qui représente la majorité des cas pour les 
cinémas), mais il est nécessaire de faire une évolution pour 
l'utilisation "adresse" afin que ce nouveau tag soit pris en compte.


Cette dernière option a ma préférence, qu'en pensez-vous ?



J'ai regardé le fichier CNC, je ne vois pas d'adresse dedans. Comment 
ont-elles été ajoutées dans OSM ?


A-t-on 100% des adresses correspondantes aux cinémas déjà dans OSM ? (Et 
correctement mappées en tant que telles ?)


J'ai regardé celui près de chez moi, aucune info d'adresse dessus, 
quelle adresse aura-t-il dans l'export ? La plus proche qu'on trouve 
(donc un simple géocodage inverse) ?


Je ne comprends pas trop le processus...


--
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

2020-07-08 Par sujet Yves P. 
>
> Malheureusement le seul moyen d'y parvenir me semble être de créer des
> relations
>
Non

Tant pis pour les pompiers qui ne seront pas guidés vers l'issue de secours.
>
On a besoin d'avoir  l'adresse principale, ensuite trouver l'issue de
secours n'est pas trop le problème.  Pour les ERP importants il y a des
plans fait à l'avance.

*1. *on considère que l'adresse ne doit pas être dupliquée : on la laisse
> donc sur un node flottant
> C'est plus avantageux pour la maintenance, c'est parfait pour l'usage
> "adresse" mais c'est un cauchemar pour l'export et l'usage "contact".
>
Tu fais un geocodage une fois pour toute. La personne qui saisie le POI
vérifié si c'est bon.

Pour les ciné tu as déjà l'adresse pour la plupart.  Il suffit de comparer
automatiquement  les 2 adresses, et de corriger manuellement ce qui nest
pas cohérent.

>
*2. *on utilise contact:XXX pour dupliquer l'adresse sur le POI.
>
Non

>
> *3. *on duplique l'adresse du point sur le POI en lui rajoutant
> addr:role=contact
>
Non plus (mon clavier a 2 touches et la "oui" est cassée )

Si il n'y a pas d'adresse, tu prends le temps de la créer...
Si tu n'as pas le temps, tu l'as met sur le POI et quelqu'un fera le
ménage...

Cette dernière option a ma préférence, qu'en pensez-vous ?
>
NON (mon clavier est toujours coincé )

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

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

2020-07-08 Par sujet Florian LAINEZ 
Merci pour la prise de recul qui me paraît également nécessaire Christian.
J'ai tout comme toi un problème avec l'info dupliquée qui pose
indubitablement problème. Dans un monde idéal, l'adresse
n'apparaîtrait qu'une fois et qu'une seule. Malheureusement le seul moyen
d'y parvenir me semble être de créer des relations, ce qui complique
vraiment le modèle et que l'on devrait donc éviter dans la mesure du
possible.

On est d'accord que pour l'usage "adresse", le point tel qu'il est défini
et utilisé aujourd'hui fait le taff. Ce que nous essayons maintenant de
trouver, c'est donc le moyen de gérer au mieux l'utilisation "contact".

> Pourquoi dupliquerai-t-on l'adresse sur chaque entrée/accès et pas le type
> de POI (c'est une entrée... de cinéma, un sortie de secours... de cinéma,
> etc) ? Où est la cohérence globale ? Pourquoi répéter l'un mais pas l'autre
> ?

C'est un bon point. J'ai toujours été embêté par ces entrées qui ne sont
pas reliées au bâtiment et il me paraissait que l'adresse soit un moyen
élégant d'y parvenir mais tu as raison, je dois faire fausse route en
associant les deux problématiques. Tant pis pour les pompiers qui ne seront
pas guidés vers l'issue de secours.

On en revient donc à l'usage "contact". Dans le use case que j'ai exposé,
il s'agit d'exporter tous les cinémas de France accompagnés de leur adresse
sur data.gouv


*On a 3 solutions :*
*1. *on considère que l'adresse ne doit pas être dupliquée : on la laisse
donc sur un node flottant
C'est plus avantageux pour la maintenance, c'est parfait pour l'usage
"adresse" mais c'est un cauchemar pour l'export et l'usage "contact".
Quel node avec la bonne adresse associer au POI ? C'est très difficile de
retrouver cette info non explicite.

*2. *on utilise contact:XXX pour dupliquer l'adresse sur le POI.
Pas top pour la maintenance, incompatible avec les outils d'édition
internationaux mais l'utilisation est très claire car les tags sont
différents pour les 2 usages. Parfait pour les 2 usages donc.
C'est la solution que nous avons choisi à Montrouge pour l'instant.

*3. *on duplique l'adresse du point sur le POI en lui rajoutant
addr:role=contact
Pas top pour la maintenance, compatible avec les outils d'édition
internationaux, bien adapté pour tous les lieux où il n'existe aucun point
adresse (ce qui représente la majorité des cas pour les cinémas), mais il
est nécessaire de faire une évolution pour l'utilisation "adresse" afin que
ce nouveau tag soit pris en compte.

Cette dernière option a ma préférence, qu'en pensez-vous ?

Le mer. 8 juil. 2020 à 16:58, Éric Gillet  a
écrit :

> Je suis 100% d'accord et j'applique ce qu'indique Christian.
>
> Le 08/07/2020 à 16:17, Christian Quest a écrit :
>
> En général ce qui me gêne c'est :
>
> - la duplication de l'information,
>
> - et pour dédupliquer le besoin de vérifier des tags en plus pour se dire
> que non, ce n'est pas ce que je cherche (ça complique beaucoup la
> réutilisation des données, on a déjà eu le cas avec les "disused")
>
>
> Pourquoi dupliquerai-t-on l'adresse sur chaque entrée/accès et pas le type
> de POI (c'est une entrée... de cinéma, un sortie de secours... de cinéma,
> etc) ? Où est la cohérence globale ? Pourquoi répéter l'un mais pas l'autre
> ?
>
>
> On prends un peu de recul ? A quoi servent le plus souvent les adresses ?
>
> 1) à retrouver la position d'un lieu quand on n'a pas d'autre information
> pour s'y rendre (adresse géographique) avec une description hiérarchique
> (commune > voie > numéro > complément comme le bâtiment ou un numéro
> d'entrée, d'escalier)
>
> 2) à faire des envois à un destinataire (adresse postale), là il n'y a pas
> forcément concordance géographique (cas des CEDEX, BP et autre, mais aussi
> des secrétariats qui ne sont pas sur place).
>
> De mon point de vue, contact:xxx répond à ce besoin d'adresse postale, çàd
> quelle adresse je met pour un contact par courrier. Elle ne devrait jamais
> être utilisée pour du routage pour cette raison.
>
>
> L'adresse géo, elle, servira à déterminer une position pour un calcul
> d'itinéraire si on n'a pas mieux, car si je cherche "Ciné Montrouge", je
> n'ai pas besoin de son adresse... la position du POI suffit à calculer
> l'itinéraire, qui d'ailleurs quand on fournit juste une adresse va chercher
> la position géographique correspondant pour faire ensuite son routage.
>
> Si je veux aller au 88 rue Racine (sans savoir que c'est là où il y a le
> ciné, l'espace Colucci, etc), un seul noeud suffit pour ça.
>
> Donc dans les exemples que tu donnes:
>
>
> Voici donc l'exemple de la mairie de Montrouge, constitué d'un
> bâtiment avec 3 accès :
> - le bâtiment https://www.openstreetmap.org/way/83237614
>   addr:role=contact
> - l'entrée principale https://www.openstreetmap.org/node/2232200912
>   addr:role=entrance;visitors
> - l'entrée secondaire https://www.openstreetmap.org/node/2443190668
>   addr:role=entrance;delivery
> - l'entrée

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

2020-07-08 Par sujet Éric Gillet 

Je suis 100% d'accord et j'applique ce qu'indique Christian.

Le 08/07/2020 à 16:17, Christian Quest a écrit :


En général ce qui me gêne c'est :

- la duplication de l'information,

- et pour dédupliquer le besoin de vérifier des tags en plus pour se 
dire que non, ce n'est pas ce que je cherche (ça complique beaucoup la 
réutilisation des données, on a déjà eu le cas avec les "disused")



Pourquoi dupliquerai-t-on l'adresse sur chaque entrée/accès et pas le 
type de POI (c'est une entrée... de cinéma, un sortie de secours... de 
cinéma, etc) ? Où est la cohérence globale ? Pourquoi répéter l'un 
mais pas l'autre ?



On prends un peu de recul ? A quoi servent le plus souvent les adresses ?

1) à retrouver la position d'un lieu quand on n'a pas d'autre 
information pour s'y rendre (adresse géographique) avec une 
description hiérarchique (commune > voie > numéro > complément comme 
le bâtiment ou un numéro d'entrée, d'escalier)


2) à faire des envois à un destinataire (adresse postale), là il n'y a 
pas forcément concordance géographique (cas des CEDEX, BP et autre, 
mais aussi des secrétariats qui ne sont pas sur place).


De mon point de vue, contact:xxx répond à ce besoin d'adresse postale, 
çàd quelle adresse je met pour un contact par courrier. Elle ne 
devrait jamais être utilisée pour du routage pour cette raison.



L'adresse géo, elle, servira à déterminer une position pour un calcul 
d'itinéraire si on n'a pas mieux, car si je cherche "Ciné Montrouge", 
je n'ai pas besoin de son adresse... la position du POI suffit à 
calculer l'itinéraire, qui d'ailleurs quand on fournit juste une 
adresse va chercher la position géographique correspondant pour faire 
ensuite son routage.


Si je veux aller au 88 rue Racine (sans savoir que c'est là où il y a 
le ciné, l'espace Colucci, etc), un seul noeud suffit pour ça.


Donc dans les exemples que tu donnes:



Voici donc l'exemple de la mairie de Montrouge, constitué d'un 
bâtiment avec 3 accès :

- le bâtiment https://www.openstreetmap.org/way/83237614
  addr:role=contact
- l'entrée principale https://www.openstreetmap.org/node/2232200912
  addr:role=entrance;visitors
- l'entrée secondaire https://www.openstreetmap.org/node/2443190668
addr:role=entrance;delivery
- l'entrée reservée au personnel 
https://www.openstreetmap.org/node/6245192824

  addr:role=staff

L'adresse pourrait être simplement sur le bâtiment, ensuite chaque 
entrée/accès avec un noeud entrance=* et décrivant les règles d'accès.


Pas besoin de dupliquer addr:xxx partout dans un tel cas.



Pour un exemple plus classique et simple d'un cinéma, on aurait :
- le bâtiment https://www.openstreetmap.org/way/83233476
  addr:role=contact
- l'entrée principale https://www.openstreetmap.org/node/5914047022
  addr:role=entrance
- la sortie de secours https://www.openstreetmap.org/node/7694884485
  addr:role=emergency

Il me semble que ce modèle est solide et remplacerait avantagement 
addr:contact
Assigner des /usages/ aux adressses : Christian n'est pas l'évolution 
dont tu rêves depuis des lustres ?


Sur ce cas, l'Espace Colucci me semble être le site entier, la 
parcelle, car on y trouve aussi un théâtre d'extérieur et le cinéma 
fait partie de cet espace (je suis allé voir sur leur site web). Les 3 
adresses serait bien à leur place en limite de la parcelle entière, le 
88 au début du footway qui mène à l'entrée, le 129 sûrement plutôt à 
la grille, le 131 à l'escalier qui donne sur la rue.



On a, je pense, trop tendance à ramener tout aux bâtiments, des tags, 
des noeuds d'adresse, etc


Sur le centre sportif juste à côté, le sport_centre est sur le site 
entier... les adresses en limite de parcelle (no comment sur les deux 
name=Gymnase).


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

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

2020-07-08 Par sujet Christian Quest 

En général ce qui me gêne c'est :

- la duplication de l'information,

- et pour dédupliquer le besoin de vérifier des tags en plus pour se 
dire que non, ce n'est pas ce que je cherche (ça complique beaucoup la 
réutilisation des données, on a déjà eu le cas avec les "disused")



Pourquoi dupliquerai-t-on l'adresse sur chaque entrée/accès et pas le 
type de POI (c'est une entrée... de cinéma, un sortie de secours... de 
cinéma, etc) ? Où est la cohérence globale ? Pourquoi répéter l'un mais 
pas l'autre ?



On prends un peu de recul ? A quoi servent le plus souvent les adresses ?

1) à retrouver la position d'un lieu quand on n'a pas d'autre 
information pour s'y rendre (adresse géographique) avec une description 
hiérarchique (commune > voie > numéro > complément comme le bâtiment ou 
un numéro d'entrée, d'escalier)


2) à faire des envois à un destinataire (adresse postale), là il n'y a 
pas forcément concordance géographique (cas des CEDEX, BP et autre, mais 
aussi des secrétariats qui ne sont pas sur place).


De mon point de vue, contact:xxx répond à ce besoin d'adresse postale, 
çàd quelle adresse je met pour un contact par courrier. Elle ne devrait 
jamais être utilisée pour du routage pour cette raison.



L'adresse géo, elle, servira à déterminer une position pour un calcul 
d'itinéraire si on n'a pas mieux, car si je cherche "Ciné Montrouge", je 
n'ai pas besoin de son adresse... la position du POI suffit à calculer 
l'itinéraire, qui d'ailleurs quand on fournit juste une adresse va 
chercher la position géographique correspondant pour faire ensuite son 
routage.


Si je veux aller au 88 rue Racine (sans savoir que c'est là où il y a le 
ciné, l'espace Colucci, etc), un seul noeud suffit pour ça.


Donc dans les exemples que tu donnes:



Voici donc l'exemple de la mairie de Montrouge, constitué d'un 
bâtiment avec 3 accès :

- le bâtiment https://www.openstreetmap.org/way/83237614
  addr:role=contact
- l'entrée principale https://www.openstreetmap.org/node/2232200912
  addr:role=entrance;visitors
- l'entrée secondaire https://www.openstreetmap.org/node/2443190668
  addr:role=entrance;delivery
- l'entrée reservée au personnel 
https://www.openstreetmap.org/node/6245192824

  addr:role=staff

L'adresse pourrait être simplement sur le bâtiment, ensuite chaque 
entrée/accès avec un noeud entrance=* et décrivant les règles d'accès.


Pas besoin de dupliquer addr:xxx partout dans un tel cas.



Pour un exemple plus classique et simple d'un cinéma, on aurait :
- le bâtiment https://www.openstreetmap.org/way/83233476
  addr:role=contact
- l'entrée principale https://www.openstreetmap.org/node/5914047022
  addr:role=entrance
- la sortie de secours https://www.openstreetmap.org/node/7694884485
  addr:role=emergency

Il me semble que ce modèle est solide et remplacerait avantagement 
addr:contact
Assigner des /usages/ aux adressses : Christian n'est pas l'évolution 
dont tu rêves depuis des lustres ?


Sur ce cas, l'Espace Colucci me semble être le site entier, la parcelle, 
car on y trouve aussi un théâtre d'extérieur et le cinéma fait partie de 
cet espace (je suis allé voir sur leur site web). Les 3 adresses serait 
bien à leur place en limite de la parcelle entière, le 88 au début du 
footway qui mène à l'entrée, le 129 sûrement plutôt à la grille, le 131 
à l'escalier qui donne sur la rue.



On a, je pense, trop tendance à ramener tout aux bâtiments, des tags, 
des noeuds d'adresse, etc


Sur le centre sportif juste à côté, le sport_centre est sur le site 
entier... les adresses en limite de parcelle (no comment sur les deux 
name=Gymnase).



--
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

2020-07-08 Par sujet Jérôme Amagat 
Le mer. 8 juil. 2020 à 13:25, Florian LAINEZ  a écrit :

> OK, en effet Christian j'ai pris un mauvais exemple, mais la logique tient
> toujours.
>
> Voici donc l'exemple de la mairie de Montrouge, constitué d'un
> bâtiment avec 3 accès :
> - le bâtiment https://www.openstreetmap.org/way/83237614
>   addr:role=contact
> - l'entrée principale https://www.openstreetmap.org/node/2232200912
>   addr:role=entrance;visitors
> - l'entrée secondaire https://www.openstreetmap.org/node/2443190668
>   addr:role=entrance;delivery
> - l'entrée reservée au personnel
> https://www.openstreetmap.org/node/6245192824
>   addr:role=staff
>
> Pour un exemple plus classique et simple d'un cinéma, on aurait :
> - le bâtiment https://www.openstreetmap.org/way/83233476
>   addr:role=contact
> - l'entrée principale https://www.openstreetmap.org/node/5914047022
>   addr:role=entrance
> - la sortie de secours https://www.openstreetmap.org/node/7694884485
>   addr:role=emergency
>
> beaucoup de ces cas font doublons avec le tag entrance=*
https://wiki.openstreetmap.org/wiki/Key:entrance
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

2020-07-08 Par sujet Philippe Verdy 
Tant que "addr:role=contact" n'est PAS interprété comme une adresse de
courrier mais bien comme une adresse géographique pour s'y rendre, ça
marche.

Pour le courrier (ou les autres communications à distance) je maintiens que
ce n'est pas approprié, surtout s'il est externalisé: dans ce cas c'est
contact:role=* et les champs contact:* d'adresse postale ou de
téléphone/fax/mail/site web etc. qui convient car ce n'est pas géographique
du tout, ce sont des "adresses" virtuelles qui n'ont pas de matérialisation
directe sur la carte où on situe le POI lui-même car pour ces usages on ne
se rend pas au POI lui-même au point situé sur la carte mais on s'adresse
ailleurs (qui peut être n'importe où dans le monde, au choix de
l'exploitant du POI et de sa propre politique de communication et de
gestion interne).

Bref on a toujours "addr:*=*" (pour les adresses géographiques uniquement)
ET "contact:*=*" (et "tel=*", "fax=*", "website=*", "wikipedia=*",
"wikidata=*") pour tout le reste des infos non strictement géolocalisées au
même endroit que le noeud ou l'objet marqué dans OSM.


Le mer. 8 juil. 2020 à 13:25, Florian LAINEZ  a écrit :

> OK, en effet Christian j'ai pris un mauvais exemple, mais la logique tient
> toujours.
>
> Voici donc l'exemple de la mairie de Montrouge, constitué d'un
> bâtiment avec 3 accès :
> - le bâtiment https://www.openstreetmap.org/way/83237614
>   addr:role=contact
> - l'entrée principale https://www.openstreetmap.org/node/2232200912
>   addr:role=entrance;visitors
> - l'entrée secondaire https://www.openstreetmap.org/node/2443190668
>   addr:role=entrance;delivery
> - l'entrée reservée au personnel
> https://www.openstreetmap.org/node/6245192824
>   addr:role=staff
>
> Pour un exemple plus classique et simple d'un cinéma, on aurait :
> - le bâtiment https://www.openstreetmap.org/way/83233476
>   addr:role=contact
> - l'entrée principale https://www.openstreetmap.org/node/5914047022
>   addr:role=entrance
> - la sortie de secours https://www.openstreetmap.org/node/7694884485
>   addr:role=emergency
>
> Il me semble que ce modèle est solide et remplacerait avantagement
> addr:contact
> Assigner des *usages* aux adressses : Christian n'est pas l'évolution
> dont tu rêves depuis des lustres ?
>
> Le mer. 8 juil. 2020 à 13:01, Yves P.  a écrit :
>
>> Oui mais non ;)
>>
>> En fait là tu décris des entrées, des accès... à un bâtiment ou un site,
>> pas à une "adresse". Le bâtiment/site peut en avoir plusieurs, il peut
>> contenir plusieurs POI, etc…
>>
>> +1
>>
>> Excellente proposition Jean-Yvon de créer un tag du type
>> addr:role=contact;entrance;mailbox;registry;water;electricity;gas;FTTH;plaque
>>
>> Ce que décrit Jean-Yvon serait plutôt une relation (à créer) du type
>> associatedHouseNumber ?
>>
>> Le n° de rue "principal" serait celui dans la relation associatedStreet
>> avec le rôle house.
>> Dans cette nouvelle relation on pourrait relier associer la boite à
>> lettre, la plaque avec le n°, les différents réseaux (fibre…)
>>
>> Ainsi ça évite de compliquer l'existant.
>>
>> Au fait, ces différentes adresses ne sont pas modélisées dans le PCRS
>> (plan corps de rue simplifié) ?
>>
>> __
>> Yves
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> --
>
> *Florian Lainez*
> @overflorian 
> ___
> 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] édition en masse sur les adresses des cinémas

2020-07-08 Par sujet Florian LAINEZ 
OK, en effet Christian j'ai pris un mauvais exemple, mais la logique tient
toujours.

Voici donc l'exemple de la mairie de Montrouge, constitué d'un
bâtiment avec 3 accès :
- le bâtiment https://www.openstreetmap.org/way/83237614
  addr:role=contact
- l'entrée principale https://www.openstreetmap.org/node/2232200912
  addr:role=entrance;visitors
- l'entrée secondaire https://www.openstreetmap.org/node/2443190668
  addr:role=entrance;delivery
- l'entrée reservée au personnel
https://www.openstreetmap.org/node/6245192824
  addr:role=staff

Pour un exemple plus classique et simple d'un cinéma, on aurait :
- le bâtiment https://www.openstreetmap.org/way/83233476
  addr:role=contact
- l'entrée principale https://www.openstreetmap.org/node/5914047022
  addr:role=entrance
- la sortie de secours https://www.openstreetmap.org/node/7694884485
  addr:role=emergency

Il me semble que ce modèle est solide et remplacerait avantagement
addr:contact
Assigner des *usages* aux adressses : Christian n'est pas l'évolution dont
tu rêves depuis des lustres ?

Le mer. 8 juil. 2020 à 13:01, Yves P.  a écrit :

> Oui mais non ;)
>
> En fait là tu décris des entrées, des accès... à un bâtiment ou un site,
> pas à une "adresse". Le bâtiment/site peut en avoir plusieurs, il peut
> contenir plusieurs POI, etc…
>
> +1
>
> Excellente proposition Jean-Yvon de créer un tag du type
> addr:role=contact;entrance;mailbox;registry;water;electricity;gas;FTTH;plaque
>
> Ce que décrit Jean-Yvon serait plutôt une relation (à créer) du type
> associatedHouseNumber ?
>
> Le n° de rue "principal" serait celui dans la relation associatedStreet
> avec le rôle house.
> Dans cette nouvelle relation on pourrait relier associer la boite à
> lettre, la plaque avec le n°, les différents réseaux (fibre…)
>
> Ainsi ça évite de compliquer l'existant.
>
> Au fait, ces différentes adresses ne sont pas modélisées dans le PCRS
> (plan corps de rue simplifié) ?
>
> __
> Yves
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 

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

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

2020-07-08 Par sujet Yves P. 
> Oui mais non ;)
> 
> En fait là tu décris des entrées, des accès... à un bâtiment ou un site, pas 
> à une "adresse". Le bâtiment/site peut en avoir plusieurs, il peut contenir 
> plusieurs POI, etc…
> 
+1
>> Excellente proposition Jean-Yvon de créer un tag du type 
>> addr:role=contact;entrance;mailbox;registry;water;electricity;gas;FTTH;plaque

Ce que décrit Jean-Yvon serait plutôt une relation (à créer) du type 
associatedHouseNumber ?

Le n° de rue "principal" serait celui dans la relation associatedStreet avec le 
rôle house.
Dans cette nouvelle relation on pourrait relier associer la boite à lettre, la 
plaque avec le n°, les différents réseaux (fibre…)

Ainsi ça évite de compliquer l'existant.

Au fait, ces différentes adresses ne sont pas modélisées dans le PCRS (plan 
corps de rue simplifié) ?

__
Yves

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

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

2020-07-08 Par sujet Christian Quest 

Oui mais non ;)

En fait là tu décris des entrées, des accès... à un bâtiment ou un site, 
pas à une "adresse". Le bâtiment/site peut en avoir plusieurs, il peut 
contenir plusieurs POI, etc...


Mélange des genres, non ?


On parlait à la base de l'ajout de l'adresse postale à un POI, car pour 
l'adresse "géographique", le lien étant géographique, la proximité avec 
le point addr le plus proche suffit (si on a besoin d'une adresse, ce 
qui n'est même pas le cas pour calculer un itinéraire si on a le POI et 
donc sa localisation).



Le 08/07/2020 à 11:45, Florian LAINEZ a écrit :
Excellente proposition Jean-Yvon de créer un tag du type 
addr:role=contact;entrance;mailbox;registry;water;electricity;gas;FTTH;plaque 

J'ajouterai aussi emergency;delivery;visitors;customers;staff mais 
aussi user defined tellement il me semble que les possibilités sont 
nombreuses.


Je plussoie pour les mêmes raisons que toi cette évolution.
Cela nécessiterait un évolution côté BANO mais il me semble que le jeu 
en vaut la chandelle : tous ceux à qui j'ai parlé d'adresses dans la 
vie m'ont dit la même chose : l'adresse est toujours reliée à une 
problématique métier.


Cas d'usage avec l'exemple du siège du Crédit Agricole à Montrouge :
- une entrée principale piétonne : 
https://www.openstreetmap.org/node/5727568854

  addr:role=entrance;visitors
  motor_vehicle=no
La valeurs entrance et visitors sous-entendant access=yes
- une entrée piétonne pour le personnel : 
https://www.openstreetmap.org/node/5727568912

  addr:role=staff
  motor_vehicle=no
- un accès au parking voiture : 
https://www.openstreetmap.org/node/5727636052

  addr:role=staff;visitors
- un accès au parking à vélo : 
https://www.openstreetmap.org/node/6007268275

  addr:role=staff
  motor_vehicle=no
- un accès d'urgence : https://www.openstreetmap.org/node/5727636053
  addr:role=emergency
- un accès reservé aux livraisons : 
https://www.openstreetmap.org/node/5830054281

  addr:role=delivery
- une entrée piétonne réservée au personnel : 
https://www.openstreetmap.org/node/4268525407

  addr:role=staff
  motor_vehicle=no
- une entrée de service : https://www.openstreetmap.org/node/5899781377
  addr:role=delivery;emergency

Question subsidiaire : quelle(s) adresses à mettre dans
associatedStreet ? Toutes ? Que celles registry et/ou plaque ?

Bonne question, je n'ai pas la réponse


Le mar. 7 juil. 2020 à 19:58, Philippe Verdy > a écrit :


Non je pense que addr:* est encore adapté quand la rue la plus
proche n'est pas la bonne mais il faut indiquer une adresse du
point lui-même (son adresse d'accès pour s'y rendre).

Alors que contact:* c'est pour des adresses de contact (par
courrier, mais PAS pour y aller physiquement: cette adresse
peut-être partout **ailleurs** dans le monde) et ne sont utiles
que justement ce n'est pas l'adresse physique du lieu pour s'y
rendre. Ces adresses dans "contact:*" ne doivent RIEN géolocaliser
du tout (on y trouve des adresses "virtuelles", notamment des
CEDEX spéciaux et boites postales/poste restantes, des services
externalisés chez un tiers)

Aucune "addr:*" ne devrait contenir un CEDEX ou boite postale en
poste restante: si c'est le cas, il FAUT mettre l'adresse dans
CONTACT (au moins le code postal et le nom du CEDEX, le code de
distribution spéciale sans adresse géographique)


Le mer. 1 juil. 2020 à 18:56, Yves P. mailto:yves.prat...@gmail.com>> a écrit :


Si il n'y a pas de addr:xxx déjà présent, il faudrait
l'ajouter à sa place et pas comme un effet de bord de tel ou
tel import de POI.

Ou prendre le temps de créer le point adresse et ne pas
rajouter de contact:* 

Je vois l'intérêt de contact:* quand l'adresse postale est
différente du n° de rue le plus proche.

__
Yves

___
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



--

*Florian Lainez*

@overflorian 

--
Ce message a été vérifié par *MailScanner* 
pour des virus ou des polluriels et rien de
suspect n'a été trouvé.

___
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] édition en masse sur les adresses des cinémas

2020-07-08 Par sujet Philippe Verdy 
Cela peut marcher à condition d'avoir une seule adresse; s'il y a des
adresses différentes pour des rôles différents; il reste "contact:*=*" pour
le courrier

Sinon "addr::*" pour d'autres rôles avec
"addr::role=;;..." pour mentionner les rôles associés,
la clé "" pouvant être un des rôles indiqués dans
"addr::role= ;;..." (s'il n'y a qu'un seul rôle en
valeur ici, ce tag "addr::role=" est facultatif et implicite).

On peut aussi ajouter "contact:role=; " pour indiquer les
rôles pour le courrier (official/ legal/fiscal;
consumers/billing/claims/b2b; information;
advertizing/press/communication...)




Le mer. 8 juil. 2020 à 11:45, Florian LAINEZ  a écrit :

> Excellente proposition Jean-Yvon de créer un tag du type
> addr:role=contact;entrance;mailbox;registry;water;electricity;gas;FTTH;plaque
> J'ajouterai aussi emergency;delivery;visitors;customers;staff mais aussi user
> defined tellement il me semble que les possibilités sont nombreuses.
>
> Je plussoie pour les mêmes raisons que toi cette évolution.
> Cela nécessiterait un évolution côté BANO mais il me semble que le jeu en
> vaut la chandelle : tous ceux à qui j'ai parlé d'adresses dans la vie m'ont
> dit la même chose : l'adresse est toujours reliée à une problématique
> métier.
>
> Cas d'usage avec l'exemple du siège du Crédit Agricole à Montrouge :
> - une entrée principale piétonne :
> https://www.openstreetmap.org/node/5727568854
>   addr:role=entrance;visitors
>   motor_vehicle=no
> La valeurs entrance et visitors sous-entendant access=yes
> - une entrée piétonne pour le personnel :
> https://www.openstreetmap.org/node/5727568912
>   addr:role=staff
>   motor_vehicle=no
> - un accès au parking voiture :
> https://www.openstreetmap.org/node/5727636052
>   addr:role=staff;visitors
> - un accès au parking à vélo :
> https://www.openstreetmap.org/node/6007268275
>   addr:role=staff
>   motor_vehicle=no
> - un accès d'urgence : https://www.openstreetmap.org/node/5727636053
>   addr:role=emergency
> - un accès reservé aux livraisons :
> https://www.openstreetmap.org/node/5830054281
>   addr:role=delivery
> - une entrée piétonne réservée au personnel :
> https://www.openstreetmap.org/node/4268525407
>   addr:role=staff
>   motor_vehicle=no
> - une entrée de service : https://www.openstreetmap.org/node/5899781377
>   addr:role=delivery;emergency
>
> Question subsidiaire : quelle(s) adresses à mettre dans associatedStreet ?
>> Toutes ? Que celles registry et/ou plaque ?
>
> Bonne question, je n'ai pas la réponse
>
>
> Le mar. 7 juil. 2020 à 19:58, Philippe Verdy  a écrit :
>
>> Non je pense que addr:* est encore adapté quand la rue la plus proche
>> n'est pas la bonne mais il faut indiquer une adresse du point lui-même (son
>> adresse d'accès pour s'y rendre).
>>
>> Alors que contact:* c'est pour des adresses de contact (par courrier,
>> mais PAS pour y aller physiquement: cette adresse peut-être partout
>> **ailleurs** dans le monde) et ne sont utiles que justement ce n'est pas
>> l'adresse physique du lieu pour s'y rendre. Ces adresses dans "contact:*"
>> ne doivent RIEN géolocaliser du tout (on y trouve des adresses
>> "virtuelles", notamment des CEDEX spéciaux et boites postales/poste
>> restantes, des services externalisés chez un tiers)
>>
>> Aucune "addr:*" ne devrait contenir un CEDEX ou boite postale en poste
>> restante: si c'est le cas, il FAUT mettre l'adresse dans CONTACT (au moins
>> le code postal et le nom du CEDEX, le code de distribution spéciale sans
>> adresse géographique)
>>
>>
>> Le mer. 1 juil. 2020 à 18:56, Yves P.  a écrit :
>>
>>> Si il n'y a pas de addr:xxx déjà présent, il faudrait l'ajouter à sa
>>> place et pas comme un effet de bord de tel ou tel import de POI.
>>>
>>> Ou prendre le temps de créer le point adresse et ne pas rajouter de
>>> contact:* 
>>>
>>> Je vois l'intérêt de contact:* quand l'adresse postale est différente du
>>> n° de rue le plus proche.
>>>
>>> __
>>> Yves
>>>
>>> ___
>>> 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
>>
>
>
> --
>
> *Florian Lainez*
> @overflorian 
> ___
> 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] édition en masse sur les adresses des cinémas

2020-07-08 Par sujet Florian LAINEZ 
Excellente proposition Jean-Yvon de créer un tag du type
addr:role=contact;entrance;mailbox;registry;water;electricity;gas;FTTH;plaque
J'ajouterai aussi emergency;delivery;visitors;customers;staff mais aussi user
defined tellement il me semble que les possibilités sont nombreuses.

Je plussoie pour les mêmes raisons que toi cette évolution.
Cela nécessiterait un évolution côté BANO mais il me semble que le jeu en
vaut la chandelle : tous ceux à qui j'ai parlé d'adresses dans la vie m'ont
dit la même chose : l'adresse est toujours reliée à une problématique
métier.

Cas d'usage avec l'exemple du siège du Crédit Agricole à Montrouge :
- une entrée principale piétonne :
https://www.openstreetmap.org/node/5727568854
  addr:role=entrance;visitors
  motor_vehicle=no
La valeurs entrance et visitors sous-entendant access=yes
- une entrée piétonne pour le personnel :
https://www.openstreetmap.org/node/5727568912
  addr:role=staff
  motor_vehicle=no
- un accès au parking voiture :
https://www.openstreetmap.org/node/5727636052
  addr:role=staff;visitors
- un accès au parking à vélo : https://www.openstreetmap.org/node/6007268275
  addr:role=staff
  motor_vehicle=no
- un accès d'urgence : https://www.openstreetmap.org/node/5727636053
  addr:role=emergency
- un accès reservé aux livraisons :
https://www.openstreetmap.org/node/5830054281
  addr:role=delivery
- une entrée piétonne réservée au personnel :
https://www.openstreetmap.org/node/4268525407
  addr:role=staff
  motor_vehicle=no
- une entrée de service : https://www.openstreetmap.org/node/5899781377
  addr:role=delivery;emergency

Question subsidiaire : quelle(s) adresses à mettre dans associatedStreet ?
> Toutes ? Que celles registry et/ou plaque ?

Bonne question, je n'ai pas la réponse


Le mar. 7 juil. 2020 à 19:58, Philippe Verdy  a écrit :

> Non je pense que addr:* est encore adapté quand la rue la plus proche
> n'est pas la bonne mais il faut indiquer une adresse du point lui-même (son
> adresse d'accès pour s'y rendre).
>
> Alors que contact:* c'est pour des adresses de contact (par courrier, mais
> PAS pour y aller physiquement: cette adresse peut-être partout **ailleurs**
> dans le monde) et ne sont utiles que justement ce n'est pas l'adresse
> physique du lieu pour s'y rendre. Ces adresses dans "contact:*" ne doivent
> RIEN géolocaliser du tout (on y trouve des adresses "virtuelles", notamment
> des CEDEX spéciaux et boites postales/poste restantes, des services
> externalisés chez un tiers)
>
> Aucune "addr:*" ne devrait contenir un CEDEX ou boite postale en poste
> restante: si c'est le cas, il FAUT mettre l'adresse dans CONTACT (au moins
> le code postal et le nom du CEDEX, le code de distribution spéciale sans
> adresse géographique)
>
>
> Le mer. 1 juil. 2020 à 18:56, Yves P.  a écrit :
>
>> Si il n'y a pas de addr:xxx déjà présent, il faudrait l'ajouter à sa
>> place et pas comme un effet de bord de tel ou tel import de POI.
>>
>> Ou prendre le temps de créer le point adresse et ne pas rajouter de
>> contact:* 
>>
>> Je vois l'intérêt de contact:* quand l'adresse postale est différente du
>> n° de rue le plus proche.
>>
>> __
>> Yves
>>
>> ___
>> 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
>


-- 

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

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

2020-07-07 Par sujet Philippe Verdy 
Non je pense que addr:* est encore adapté quand la rue la plus proche n'est
pas la bonne mais il faut indiquer une adresse du point lui-même (son
adresse d'accès pour s'y rendre).

Alors que contact:* c'est pour des adresses de contact (par courrier, mais
PAS pour y aller physiquement: cette adresse peut-être partout **ailleurs**
dans le monde) et ne sont utiles que justement ce n'est pas l'adresse
physique du lieu pour s'y rendre. Ces adresses dans "contact:*" ne doivent
RIEN géolocaliser du tout (on y trouve des adresses "virtuelles", notamment
des CEDEX spéciaux et boites postales/poste restantes, des services
externalisés chez un tiers)

Aucune "addr:*" ne devrait contenir un CEDEX ou boite postale en poste
restante: si c'est le cas, il FAUT mettre l'adresse dans CONTACT (au moins
le code postal et le nom du CEDEX, le code de distribution spéciale sans
adresse géographique)


Le mer. 1 juil. 2020 à 18:56, Yves P.  a écrit :

> Si il n'y a pas de addr:xxx déjà présent, il faudrait l'ajouter à sa place
> et pas comme un effet de bord de tel ou tel import de POI.
>
> Ou prendre le temps de créer le point adresse et ne pas rajouter de
> contact:* 
>
> Je vois l'intérêt de contact:* quand l'adresse postale est différente du
> n° de rue le plus proche.
>
> __
> Yves
>
> ___
> 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] édition en masse sur les adresses des cinémas

2020-07-02 Par sujet Christian Rogel 

> Le 1 juil. 2020 à 19:20, osm.sanspourr...@spamgourmet.com a écrit :
> Christian R., non, adresse n'implique pas bâti. On a déjà évoqué sur la liste 
> le cas des lotissements où les nom de rue et les numéros sont fixées avant la 
> construction. Il y a aussi des cas limites intéressants comme cette adresse 
> de bateau-restaurant détruit .
> 

Une commune n’attribue jamais une adresse dans le vide, car, c’est toujours lié 
quelque chose de concret ou qui doit bientôt le devenir.
Les adresses des lotissements sont prévues par anticipation. Ce peut être le 
cas pour un atelier ou même une carrière proche d’un lieu habité.
A chaque fois, c’est une parcelle ou une fraction de parcelle qui est visée par 
l’arrêté.

Christian R.

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

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

2020-07-01 Par sujet osm . sanspourriel 

Le 01/07/2020 à 17:49, Christian Quest - cqu...@openstreetmap.fr a écrit :


Voilà pourquoi on a toujours poussé pour séparer et ne pas mélanger.


Entièrement d'accord sur le raisonnement.

Maintenant si on regarde les règles en France il y a en fait un
qualificatif en plus de l'adresse. "Type de position" selon
adresse.data.gouv.fr mais je n'ai pas trouvé la définition. J'ai trouvé
entrée, inconnu.

Procéder de cette manière permettrait d'avoir plusieurs adresses tout en
sachant à quoi ça correspond.

addr:role=contact par exemple.

*Le gros avantage c'est que c'est compatible avec les éditeurs
existants* (il faut "juste" convaincre d'ajouter un champ, pas de tout
casser pour que les addr: des POI atterrissent dans les contact:addr:*).

Et transformer les contact:addr:* en addr: se ferait sans perte.

C'est sans doute plus facile que d'imposer un schéma de facto
franco-français.

En rêvant tout haut :
contact;entrance;mailbox;registry;water;electricity;gas;FTTH;plaque;entrance.

Registry : l'adresse là où la met le cadastre, le SIG de la ville, unicité

Mailbox : là où se trouve la boîte-aux-lettres pour distribuer le
courrier à cette adresse (peut être loin dans le cas des CIDEX
), unicité

Contact : tous les POI ayant cette adresse ont au moins
addr:role=contact mais ça peut aussi être addr:role=contact;registry.
Pas nécessairement unique.

Plaque : là ou se trouve la plaque de rue, unicité. Pas nécessairement
unique.

Entrance : l'endroit par lequel on arrive à cette adresse. Pas
nécessairement unique.

J'ajoute volontairement water;electricity;gas;FTTH pour provoquer des
réactions : là où se trouvent les différents compteurs (eau,
électricité, gaz) ou entrées (FTTH). Pour l'électricité c'est peut-être
plutôt l'endroit d'entrée dans la place.

En effet, j'ai vu le concessionnaire de l'eau potable relever les
positions géographiques des compteurs. Actuellement ces relevés il les
garde pour lui. Je me dis comme François que préparer le terrain ne peut
nuire ;-).

Christian R., non, adresse n'implique pas bâti. On a déjà évoqué sur la
liste le cas des lotissements où les nom de rue et les numéros sont
fixées avant la construction. Il y a aussi des cas limites intéressants
comme cette adresse de bateau-restaurant détruit
.

Pour compléter le tableau, si certaines fois Nominatim se plante sur les
lieux-dits bornés c'est que Nominatim ne se sert pas des adresses mais
des rues
.

Question subsidiaire : quelle(s) adresses à mettre dans associatedStreet
? Toutes ? Que celles registry et/ou plaque ?

Jean-Yvon

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

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

2020-07-01 Par sujet Yves P. 
> Si il n'y a pas de addr:xxx déjà présent, il faudrait l'ajouter à sa place et 
> pas comme un effet de bord de tel ou tel import de POI.
Ou prendre le temps de créer le point adresse et ne pas rajouter de contact:* 

Je vois l'intérêt de contact:* quand l'adresse postale est différente du n° de 
rue le plus proche.

__
Yves

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

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

2020-07-01 Par sujet Christian Quest 

Le 30/06/2020 à 23:18, Florian LAINEZ a écrit :
@jérome @jean-yvon @Yves je suis très conscient des effets de bords 
que vous mentionnez et je suis embêté.
A vrai dire je suis à deux doigts de suggérer d'abandonner totalement 
ces "contact:" à tout jamais.


Je constate en effet que 9500 contact:street sont en France sur les 
10300 utilisés de par le Monde, soit 92%. Autant dire que c'est un tag 
franco-français.


Cela me fait réfléchir sérieusement : @christian @vdct pourriez-vous 
svp rappeler les raisons qui nous ont poussé à utiliser ces tags ?
Y a-t-il d'autres raisons que celle, évidente, d'éviter les doublons 
d'adresse ? Est-ce que cela justifie vraiment de créer tout un jeu de 
tags qui n'est utilisé que par les français et qui restera durablement 
incompatible avec les outils d'édition prédominants ?


Ces tags n'apparaissent pas sur les pages
https://wiki.openstreetmap.org/wiki/FR:Adresses
https://wiki.openstreetmap.org/wiki/FR:Key:contact
Par ailleurs le graphique en haut de la page 
https://wiki.openstreetmap.org/wiki/Key:contact indique la popularité 
déclinante des tags "contact:" ces dernières années.


Désolé de ressortir ce vieux squelette du placard mais je ne m'étais 
pas rendu compte que la France faisait exception sur le sujet et j'ai 
l'impression qu'on a fait fausse route depuis des années.

Ne serait-il pas temps de tuer le monstre ?

Florian, qui donne entre 2 mails un avis totalement opposé (après 
avoir creusé le sujet)



Les adresses... un sujet sans fin ;)

Comment différencier la définition d'une adresse (sa localisation, son 
rattachement à une voie, etc) et l'adresse à laquelle se trouve un POI 
qui n'est pas "lui même" l'adresse ?


Si on utilise le même tag pour les deux, faire la différence devient 
complexe voire impossible.


addr:xxx est bien adapté à définir l'adresse, sa position, et ce tag 
devrait normalement être présent une seule fois dans les données OSM 
pour chaque adresse.


contact:xxx indique plein d'infos liées au POI, et son adresse peut en 
être une, on peut avoir plusieurs POI à la même adresse, etc.


Voilà pourquoi on a toujours poussé pour séparer et ne pas mélanger.

https://wiki.openstreetmap.org/wiki/Key:contact indique bien que 
contact:xxx sert à indiquer le numéro, la rue, le code postal et la 
ville où se trouve le POI.


Aucune idée du manque d'adoption ailleurs qu'en France. Peut-être est-ce 
parce qu'on s'est intéressé plus en détail sur le sujet des adresses 
avec BANO ?



C'est bien souvent lors d'imports qu'on se retrouve avec une adresse 
dans les données d'origine et qu'on veut la conserver dans OSM.


Si il n'y a pas de addr:xxx déjà présent, il faudrait l'ajouter à sa 
place et pas comme un effet de bord de tel ou tel import de POI. 
D'ailleurs, en laissant contact:xxx sur le POI, une analyse osmose 
pourrait être faite pour détecter les contact:xxx existants sans 
addr:xxx correspondants... si elle n'existe pas déjà !



--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

2020-07-01 Par sujet Philippe Verdy 
A mon avis si l'adresse de contact est la même que l'adresse de situation
du commerce/service, il ne faut pas la renseigner. Le but est plutôt de
renseigner une adresse postale d'un service externalisé (ou centralisé
ailleurs, au siège d'une organisation multi-site, quand le "brand" ne
suffit pas car cela concerne des franchises qui légalement sont séparées,
la maison-mère de la franchise ne s'occupant pas de tout), ou une boite
postale poste restante.

Cependant dans divers cas, une seule adresse de contact ne suffit pas:
commerces multifranchises, avec différentes adresses selon le service vendu
ou si on désigne l'adresse du gérant des lieux ou l'adresse légale de
l'entité locale (celle enregistrée au registre du commerce et figurant sur
les factures/devis/tickets de caisse avec son propre nom, pas affiché du
tout sur place : nombre de cafés, restaurants, tabacs ont une désignation
légale du gérant avec son nom et son adresse privée qui n'a rien à voir
avec l'adresse physique du commerce ou celle des sièges des franchises
auquel il a adhéré ; c'est le cas même pour des chaînes très connues comme
McDonald ou Quick, ou les stations-services comme Leclerc, et la quasi
totalité des supermarchés et hypers de Carrefour, Leclerc, Géant/Casino,
Lidl, But, Conforama, etc.). Concernant les drives et autres points de
retraits l'adresse de contact (légal ou service consommateur) n'est
quasiment jamais sur place.

Même les services publics ont d'autres adresses de contact que celle de
l'agence locale (y compris les services municipaux dont l'adresse de
contact est un service interne à la mairie, ou celle de la mairie
elle-même, et non celle du local lui-même; de même les services fiscaux, et
même aujourd'hui les services postaux, qui sont sectorisés selon le mode de
distribution et le service : pour les retraits et livraisons de colis c'est
déjà séparé du bureau de poste local).

Bref "contact:*" c'est bien mais même pas suffisant si on en veut plusieurs
selon le service. En revanche "addr:*" est à bannir sur les POI (sauf si le
numéro est ambigu et pas facile à déterminer géographiquement parmi les
points d'adresse proches, auquel cas on peut avoir juste addr:housenumber
qui peut inclure un intervalle de numéro, et éventuellement addr:street
pour indiquer par laquelle des voies proches on accède principalement) et
ne devrait plus servir que sur les noeuds d'adresse anonymes.

Dans certains cas, un commerce a plusieurs points d'accès publics sur des
rues différentes, et il peut être justifié d'avoir plusieurs jeux de tags
"addr:". Mais indiquer la commune est redondant sauf si l'accès est sur une
commune voisine ou si le bâtiment est à cheval sur plusieurs communes et a
plusieurs accès (le commerce ou service peut élire domicile dans une
d'elles ce n'est pas déterminé facilement par la géométrie ou même par le
positionnement du noeud POI arbitrairement sur une des communes ou un de
ses accès, et il n'est pas question non plus de mettre plusieurs noeuds POI
quand c'est un seul et même service)

Pour les points d'accès, je pense qu'il on n'a pas besoin de leur donner
une adresse ou les attribuer à un noeud POI proche, c'est plutôt une
caractéristique physique et l'interconnexion entre eux est sur un domaine
privé: les champs "addr:*" du POI suffisent à déterminer l'adresse ou les
adresses d'accès, les noeuds des points d'accès (entry) sont à taguer
physiquement sur les bâtiments/clôtures, et complétés éventuellement par
des voies privées (highway=* + access=*) y compris internes au
bâtiment (exemple: galeries marchandes pour relier les commerces "indoor",
voire souterrains dans les tunnels des gares ferroviaires et stations
métro).

D'une façon générale, ne pas faire de règle préétablie interdisant ou
obligeant à utiliser certains tags : la géographie a besoin de
nombreuses exceptions aux règles. Mais ces exceptions doivent être
justifiées par un besoin et ne pas devenir une règle introduisant beaucoup
de redondance totalement inutile, ou empêchant d'indiquer une précision
nécessaire non couverte correctement par les règles géographique de
"proximité" ou d'inclusion dans une aire administrative).

Les adresses postales sont connues pour justement échapper aux règles de
divisions administratives (et pas seulement pour les codes postaux) pour
ceux qui habitent dans des zones frontalières desservies et accessibles
uniquement par une autre commune (en pratique, en excluant les autres accès
privés, par de petits chemins piétons ou privés à travers les jardins, ou
les voies de garage ou parking strictement privé, ou via un droit de
passage par une autre propriété réservé aux occupants et aux services
publics autorisés).

Le mar. 30 juin 2020 à 23:19, Florian LAINEZ  a écrit :

> @jérome @jean-yvon @Yves je suis très conscient des effets de bords que
> vous mentionnez et je suis embêté.
> A vrai dire je suis à deux doigts de suggérer d'abandonner totalement ces
> "contact:" à tout jamais.
>
> Je constate en effet que 9500

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

2020-07-01 Par sujet Christian Rogel 
B
> Le 1 juil. 2020 à 08:16, Topographe Fou  a écrit :
> Personnellement et même si le raisonnement est fragile j'ai toujours perçu 
> les addr: comme des propriétés d'un objet, le tag "principal" qui fait la 
> nature d'un objet étant amenity ou shop ou building ou office ou...
>> Désolé de ressortir ce vieux squelette du placard mais je ne m'étais pas 
>> rendu compte que la France faisait exception sur le sujet et j'ai 
>> l'impression qu'on a fait fausse route depuis des années.
>> Ne serait-il pas temps de tuer le monstre ?

L’adresse est fondamentalement une propriété de la parcelle habitée ou siège 
d’activité (la mairie ne met, en principe, pas d’adresse à un terrain nu).
Building et shop ont beau être des tags « principaux », ils ne sont pas au même 
niveau, puisque l’existence des activités dépend, in fine, de l’espace et non 
des objets qui s’y trouvent.

De toute façon, une « décision communautaire française » non discutée à 
l’échelon international, ça ne peut pas valoir grand-chose.

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

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

2020-07-01 Par sujet Topographe Fou 
  Personnellement et même si le raisonnement est fragile j'ai toujours perçu les addr: comme des propriétés d'un objet, le tag "principal" qui fait la nature d'un objet étant amenity ou shop ou building ou office ou... Ce qui ne m'empêche pas de trouver une pertinence à leur usage sur des noeuds isolés comme la plupart des objets ayant une adresse à ma connaissance car il faut bien localiser les adresses. Avec un tag type amenity=addr là on pourrait gérer une notion d'unicité d'adresse en rentrant de plein pied dans la règle une feature = un objet et sans s'interdire d'avoir la même adresse sur un cinéma. Mais c'est probablement trop tard pour changer. Pour le coup on peut décider de le faire en France sans tout casser/nous isoler (transparent pour les consommateurs de données, les outils de QA sont assez souples, reste le pb des éditeurs).Je comprend l'esprit de la "décision communautaire" en France mais les adresses sont un pilier des données géographiques que l'on ne peut guère gérer à notre guise. Surtout quand les outils ne suivent pas et incitent à remplir addr:xxx  Reste que l'adresse postale/cadastre n'est pas forcément l'adresse de contact...  LeTopographeFou   De: winner...@free.frEnvoyé: 30 juin 2020 11:30 PMÀ: talk-fr@openstreetmap.org; christian.qu...@gmail.com; v...@laposte.netRépondre à: talk-fr@openstreetmap.orgObjet: Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas  Pour en rajouter une couche, quand on voit la progression de la courbe des tags "contact:" liée aux adresses, elle est carrément flat :https://taghistory.raifer.tech/#***/contact:street/&***/contact:housenumber/&***/contact:postcode/&***/addr:street/&***/addr:housenumber/&***/addr:postcode/Le mar. 30 juin 2020 à 23:18, Florian LAINEZ <winner...@free.fr> a écrit :@jérome @jean-yvon @Yves je suis très conscient des effets de bords que vous mentionnez et je suis embêté.A vrai dire je suis à deux doigts de suggérer d'abandonner totalement ces "contact:" à tout jamais.Je constate en effet que 9500 contact:street sont en France sur les 10300 utilisés de par le Monde, soit 92%. Autant dire que c'est un tag franco-français.Cela me fait réfléchir sérieusement : @christian @vdct pourriez-vous svp rappeler les raisons qui nous ont poussé à utiliser ces tags ?Y a-t-il d'autres raisons que celle, évidente, d'éviter les doublons d'adresse ? Est-ce que cela justifie vraiment de créer tout un jeu de tags qui n'est utilisé que par les français et qui restera durablement incompatible avec les outils d'édition prédominants ?Ces tags n'apparaissent pas sur les pages https://wiki.openstreetmap.org/wiki/FR:Adresseshttps://wiki.openstreetmap.org/wiki/FR:Key:contactPar ailleurs le graphique en haut de la page https://wiki.openstreetmap.org/wiki/Key:contact indique la popularité déclinante des tags "contact:" ces dernières années.Désolé de ressortir ce vieux squelette du placard mais je ne m'étais pas rendu compte que la France faisait exception sur le sujet et j'ai l'impression qu'on a fait fausse route depuis des années.Ne serait-il pas temps de tuer le monstre ?Florian, qui donne entre 2 mails un avis totalement opposé (après avoir creusé le sujet)Le mar. 30 juin 2020 à 15:59, Yves P. <yves.prat...@gmail.com> a écrit :On en déduira que quelqu'un a vérifié que le cinéma a été transformé en toilettes^^.Ça ressemble plus à un nettoyage partiel.+1Ou trop rapide :D__Yves___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
-- 


	
	
	
	




	
	
	
	

Florian
Lainez@overflorian
-- 


	
	
	
	




	
	
	
	

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

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

2020-06-30 Par sujet Florian LAINEZ 
Pour en rajouter une couche, quand on voit la progression de la courbe des
tags "contact:" liée aux adresses, elle est carrément flat :
https://taghistory.raifer.tech/#***/contact:street/&***/contact:housenumber/&***/contact:postcode/&***/addr:street/&***/addr:housenumber/&***/addr:postcode/

Le mar. 30 juin 2020 à 23:18, Florian LAINEZ  a écrit :

> @jérome @jean-yvon @Yves je suis très conscient des effets de bords que
> vous mentionnez et je suis embêté.
> A vrai dire je suis à deux doigts de suggérer d'abandonner totalement ces
> "contact:" à tout jamais.
>
> Je constate en effet que 9500 contact:street sont en France sur les 10300
> utilisés de par le Monde, soit 92%. Autant dire que c'est un tag
> franco-français.
>
> Cela me fait réfléchir sérieusement : @christian @vdct pourriez-vous svp
> rappeler les raisons qui nous ont poussé à utiliser ces tags ?
> Y a-t-il d'autres raisons que celle, évidente, d'éviter les doublons
> d'adresse ? Est-ce que cela justifie vraiment de créer tout un jeu de tags
> qui n'est utilisé que par les français et qui restera durablement
> incompatible avec les outils d'édition prédominants ?
>
> Ces tags n'apparaissent pas sur les pages
> https://wiki.openstreetmap.org/wiki/FR:Adresses
> https://wiki.openstreetmap.org/wiki/FR:Key:contact
> Par ailleurs le graphique en haut de la page
> https://wiki.openstreetmap.org/wiki/Key:contact indique la popularité
> déclinante des tags "contact:" ces dernières années.
>
> Désolé de ressortir ce vieux squelette du placard mais je ne m'étais pas
> rendu compte que la France faisait exception sur le sujet et j'ai
> l'impression qu'on a fait fausse route depuis des années.
> Ne serait-il pas temps de tuer le monstre ?
>
> Florian, qui donne entre 2 mails un avis totalement opposé (après avoir
> creusé le sujet)
>
> Le mar. 30 juin 2020 à 15:59, Yves P.  a écrit :
>
>> On en déduira que quelqu'un a vérifié que le cinéma a été transformé en
>> toilettes^^.
>>
>> Ça ressemble plus à un nettoyage partiel.
>>
>> +1
>> Ou trop rapide :D
>>
>> __
>> Yves
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> --
>
> *Florian Lainez*
> @overflorian 
>


-- 

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

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

2020-06-30 Par sujet Florian LAINEZ 
@jérome @jean-yvon @Yves je suis très conscient des effets de bords que
vous mentionnez et je suis embêté.
A vrai dire je suis à deux doigts de suggérer d'abandonner totalement ces
"contact:" à tout jamais.

Je constate en effet que 9500 contact:street sont en France sur les 10300
utilisés de par le Monde, soit 92%. Autant dire que c'est un tag
franco-français.

Cela me fait réfléchir sérieusement : @christian @vdct pourriez-vous svp
rappeler les raisons qui nous ont poussé à utiliser ces tags ?
Y a-t-il d'autres raisons que celle, évidente, d'éviter les doublons
d'adresse ? Est-ce que cela justifie vraiment de créer tout un jeu de tags
qui n'est utilisé que par les français et qui restera durablement
incompatible avec les outils d'édition prédominants ?

Ces tags n'apparaissent pas sur les pages
https://wiki.openstreetmap.org/wiki/FR:Adresses
https://wiki.openstreetmap.org/wiki/FR:Key:contact
Par ailleurs le graphique en haut de la page
https://wiki.openstreetmap.org/wiki/Key:contact indique la popularité
déclinante des tags "contact:" ces dernières années.

Désolé de ressortir ce vieux squelette du placard mais je ne m'étais pas
rendu compte que la France faisait exception sur le sujet et j'ai
l'impression qu'on a fait fausse route depuis des années.
Ne serait-il pas temps de tuer le monstre ?

Florian, qui donne entre 2 mails un avis totalement opposé (après avoir
creusé le sujet)

Le mar. 30 juin 2020 à 15:59, Yves P.  a écrit :

> On en déduira que quelqu'un a vérifié que le cinéma a été transformé en
> toilettes^^.
>
> Ça ressemble plus à un nettoyage partiel.
>
> +1
> Ou trop rapide :D
>
> __
> Yves
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 

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

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

2020-06-30 Par sujet Yves P. 
> On en déduira que quelqu'un a vérifié que le cinéma a été transformé en 
> toilettes^^.
> 
> Ça ressemble plus à un nettoyage partiel.
> 
+1
Ou trop rapide :D

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

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

2020-06-30 Par sujet osm . sanspourriel 

Le 30/06/2020 à 15:22, Yves P. - yves.prat...@gmail.com a écrit :

https://www.openstreetmap.org/relation/11186492
Les relations type=site sont à éviter : pas rendu, peuvent être
remplacer par un polygone ou un multipolygone

C'est curieux ?
Relier des toilettes au bout d'un dédale de souterrain? qui mène au
cinéma (le polygone du bâtiment) ?
Et pour l'autre relier une entrée sur une autre rue avec la salle de
cinéma ??


Justement les dédales ne sont pas dans la relation :
https://www.openstreetmap.org/way/445308489. Est-ce des couloirs publics
? J'imagine mal des toilettes réservées aux clients en dehors du
bâtiment (même si je connais le cas).

Alors j'ai d'autres problèmes :

- toilet=yes Indicates that a feature has a toilet.

Ce n'est donc pas les toilettes elles-mêmes (qui sont publiques amenity
=toilets
).

Donc je mettrais simplement toilet=yes sur le cinéma.

Je suppose que les gens utilisent OSM pour trouver des toilettes
publiques mais par contre que dans un cinéma ils suivent les flèches (et
non les mouches^^ ou OSM).

Mais y a-t-il des cinémas sans toilettes ? Hormis les cinémas en plein
air peut-être.

À voir l'historique du point ça semble avoir été considéré comme le
cinéma. Une entrée ?

source=survey reste depuis le début.

On en déduira que quelqu'un a vérifié que le cinéma a été transformé en
toilettes^^.

Ça ressemble plus à un nettoyage partiel.

Jean-Yvon

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

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

2020-06-30 Par sujet Yves P. 
> Sur les relations, je pense qu'il y a des choses à modifier comme 
> https://www.openstreetmap.org/relation/11186531 
>  et 
> https://www.openstreetmap.org/relation/11186492 
> 
> Les relations type=site sont à éviter : pas rendu, peuvent être remplacer par 
> un polygone ou un multipolygone
C'est curieux ?
Relier des toilettes au bout d'un dédale de souterrain? qui mène au cinéma (le 
polygone du bâtiment) ?
Et pour l'autre relier une entrée sur une autre rue avec la salle de cinéma ??

Je pige, tu veux mettre des tags sur un polygone avec une adresse (beurk) sans 
mélanger ces tags avec avec ceux du polygone building=* + addr:*=* (+ 
toilets=yes )

KISS 

Admettons que je mette le noeud amenity=cinema près de l'entrée : 48.8321269, 
2.3758317

Voici les adresses géocodées :
Google  : 162 Avenue de France 128, 
75013 Paris
Site du Mk2  : 128/162 av. de 
France 75013 Paris
Fichier du CNC : 128 A 162 AVENUE DE FRANCE Paris 13e Arrondissement
Nominatim 

 : 128-162, Avenue de France, 75013, Paris
Photon  : 
128-162 Avenue de France 75013 Paris
adresse.data.gouv.fr 
 134 
Avenue de France 75013 Paris

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

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

2020-06-30 Par sujet Jérôme Amagat 
Le mar. 30 juin 2020 à 09:13, Yves P.  a écrit :

> Yves : en France on veut l'unicité des points adresse.
>
> Oui, et je suis d'accord avec ça.
>
> L'idée de Florian est bonne, le résultat risque de l'être moins (cf. ton
> explication et celle de Jérôme).
>
> Par rapport au cas du ciné sur le bâtiment, je règle le problème en
> séparant le POI (ici le ciné) du bâtiment :
> Je met un noeud pour le POI vers son entrée, et laisse building=*,
> source=cadastre… sur le polygone.
>
> Pour le moment je fais ça manuellement.
>
> Je viens de regarder, d'après TagInfo FR, il y a 676 chemins et 9
> relations
>  avec
> amenity=cinema.
>
> Sur les relations, je pense qu'il y a des choses à modifier comme
https://www.openstreetmap.org/relation/11186531 et
https://www.openstreetmap.org/relation/11186492
Les relations type=site sont à éviter : pas rendu, peuvent être remplacer
par un polygone ou un multipolygone
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

2020-06-30 Par sujet Yves P. 
> Yves : en France on veut l'unicité des points adresse.
> 
Oui, et je suis d'accord avec ça.

L'idée de Florian est bonne, le résultat risque de l'être moins (cf. ton 
explication et celle de Jérôme).

Par rapport au cas du ciné sur le bâtiment, je règle le problème en séparant le 
POI (ici le ciné) du bâtiment :
Je met un noeud pour le POI vers son entrée, et laisse building=*, 
source=cadastre… sur le polygone.

Pour le moment je fais ça manuellement.

Je viens de regarder, d'après TagInfo FR, il y a 676 chemins et 9 relations 
 avec 
amenity=cinema.

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

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

2020-06-29 Par sujet Jérôme Amagat 
Ces contact:*=* c'est pour avoir un unique objet par adresse, le plus
souvent un node qui représente seulement une adresse mais pas
obligatoirement. Mais les addr:*=* des cinémas sont surement pour bon
nombre d'entre elles déjà uniques donc les changer en contact:*=* fera
disparaître des adresses de osm.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

2020-06-29 Par sujet osm . sanspourriel 

STOP !

Malgré ce qui précède je suis pour.

Mais avec précautions.

Je vais à nouveau de me faire avoir avec iD. Tu me diras qu'en utilisant
iD il ne faut pas se plaindre après.

Un cinéma était donné comme étant le chemin building=yes.

Id propose de l'extraire.

Sans toucher à la relation associatedStreet.

Du coup je me suis retrouvé avec un membre house sans addr:housenumber
ou addr:housename. Heureusement Osmose est passé derrière.

Là tu risques d'avoir le même problème : il ne faut pas perdre d'adresse.

Si le cinéma est dans une associatedStreet il faut créer un point
d'adresse dans le bâtiment ayant cette adresse, le mettre dans la
relation, supprimer le cinéma de la relation puis roule ma poule.

Yves : en France on veut l'unicité des points adresse.

Jean-Yvon

Le 29/06/2020 à 22:03, Florian LAINEZ - winner...@free.fr a écrit :

Hello,
On avance bien sur le référencement des cinémas en france et leur
publication sur
https://www.data.gouv.fr/fr/datasets/cinemas-issus-dopenstreetmap et
il est temps de s'occuper de leurs adresses.

Comme beaucoup d'entre vous le savent, en france, une décision
communautaire est de créer un node séparé du cinéma (ou de tout autre
POI) pour indiquer sont adresse.
En conséquence, en théorie, les tags suivants n'ont pas leur place sur
les objets amenity=cinema : addr:housenumber, addr:street,
addr:postcode, addr:city ainsi que les autres tags commençant par
"addr". Ces informations doivent apparaître sur un nœud séparé.

En conséquence, dans la ville de Montrouge, on a déjà fait le choix de
passer toutes les addr en contact (voir la discussion
).
/exemple : addr:housenumber=* en contact:housenumber=*
/

Le problème principal de cette solution est la non-comptabilité avec
les éditeurs iD et Maps.Me, qui proposent tous les 2 la seule édition
des adresses formatées de manière standard.
Malgré cette limitation je compte respecter la décision (très
européano-centrée
) de
la communauté Française et en conséquence changer sur tous les cinémas :
addr:housenumber -> contact:housenumber
addr:housename -> contact:housename
addr:street -> contact:street
addr:postcode -> contact:postcode
addr:city -> contact:city
addr:district -> contact:district
addr:place -> contact:place
addr:suburb -> contact:suburb
addr:territoire -> contact:territoire
addr:unit -> contact:unit

Je suis preneur d'éventuels commentaires avant de lancer l'édition de
masse avec le compte "overflorian-mass-edits".

--

*Florian Lainez*

@overflorian 

___
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] édition en masse sur les adresses des cinémas

2020-06-29 Par sujet Yves P. 
> Malgré cette limitation je compte respecter la décision (très 
> européano-centrée 
> ) de la 
> communauté Française et en conséquence changer sur tous les cinémas :
> addr:housenumber -> contact:housenumber
> addr:housename -> contact:housename
> …

Autre décision franco-française ? Un effet de bord de la première ?
Je ne suis pas chaud.

Dans le cas des cinoches, on a l'adresse dans le fichier du CNC.
On peut déjà comparer celle-ci avec les quelques tags addr:*=* déjà dans OSM 
(normalement ça doit être identique) ou les quelques adresses dans wikidata.
Et surtout, comparer avec un géocodage inversé.

Si effectivement il y a de grosses différences, voir si l'agit d'un point 
adresse régle le problème.
Si non, se résoudre à mettre des tags adresses et à les faire accepter par la 
communauté mondiale et les développeurs d'éditeurs.

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