Re: [OSM-talk-fr] Suppression *covid19=*

[osm . sanspourriel]

Deuzeffe parle de *sa* commune sur [OSM-talk-*fr*], elle participe à
OpenStreetMap *France*.

Qu'est-ce qui fait penser dans *sa* question et *ma* réponse qu'il
puisse d'agir du Brésil, des USA, de la Russie du Mexique ou encore de
l'Afrique ou de la Chine ?

Qu'est ce qui fait penser que dans *sa* commune qu'en cas de
confinement  il suffira de réactiver le mode de confinement pratiqué par
les divers commerces, artisans, services publics sans avoir rien appris
et en revenant à l'état de semi-déconfinement ?

Jean-Yvon

Le 08/07/2020 à 20:46, Philippe Verdy - ver...@gmail.com a écrit :

La COVID19 n'est pas partie, il est toujours pleinement actif dans le
monde et déjà on voit revenir des mesures de confinements en Europe.
Et certainement une fois l'été passé, on y reviendra (même si
maintenant on a des moyens de lutte et de protection). Le Brésil est
en plein boom comme aussi les USA, et c'est pour ça que la Guyane
n'est pas déconfinée.
La COVID n'a jamais été aussi active qu'aujourd'hui, dont les pays qui
ont prétendu le contraire (en reportant la faute sur les autres dont
la Chine qui est parvenue à contenir la maladie) qui sont maintenant
les plus touchés (USA, Brésil, Russie, Mexique). Et même en Afrique
qui a échappé au gros de la première vague (liée au tourisme, aux
voyageurs d'affaires, aux étudiants et aux pays à forte immigration et
nombreux échanges inernationaux, ce qui a été contenu par la
fermeture des lignes aériennes et des voyages maritimes et croisières)
n'est plus épargnée.
Tant qu'il n'y aura pas de vaccin massivement servi à la population,
on sera toujours exposé, tout ce qu'on peut faire pour l'instant c'est
la freiner et repousser un peu l'échéance.
Les mesures prises pendant le confinement si elles reviennent
nécessiteront les mêmes moyens, ce serait dommage de supprimer pour
l'instant alors qu'on n'a pas encore de prévention ni de traitement
efficace.
Ces données peuvent rester là pendant au moins un an ou deux, le temps
de voir ce qu'il advient: au moins on serait déjà prêt pour l'essentiel.
Ceci dit tout n'est pas perdu car ça peut concerner d'autres maladies
(dont aussi la grippe saisonnière qui tue depuis des années, et toute
nouvelle forme virale : on sait qu'il y en a beaucoup possibles; on
doit retenir aussi les leçons du H1N1, dont l'oubli a été la cause du
retard pris pour la COVID19... et qui n'a pas dit non plus son dernier
mot et a déjà des tas de nouvelles variantes)


Le sam. 4 juil. 2020 à 20:03, mailto:osm.sanspourr...@spamgourmet.com>> a écrit :

1) Osmose est ton ami.

2) je pense que le mieux c'est de regarder les principales clés.

3) sinon une expression régulière


le fait si tu es sur une petite zone (ici forma CSV, pas forcément
idéal mais pourquoi pas).

Jean-Yvon

Le 04/07/2020 à 17:50, deuzeffe - opensm@deuzeffe.org
 a écrit :

Bonjour,

Peu d'équipements de ma commune ont encore des restrictions
d'ouverture/accès adaptées à la crise sanitaire (hors masques et
SHA/GHA, simplement recommandés). Comment supprimer les tags
appropriés sans faire une revue manuelle de chaque POI ?
Probablement par une requête overpass ? Certes, mais laquelle ? À
vos claviers !

Merci pour votre aide.

___
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] OverPass et rue sans éclairage en ville

[Gad.Jo]

Merci pour le retour, je comprend mieux pourquoi ça ne fonctionne pas.

C'était pour affiner une mission sur Pic4Review pour indiquer les voies 
avec éclairage. En agglomération je comptait prendre tout type de chemin 
(y compris piste, chemin) et en dehors seulement les voies courante (de 
primary à residential)


ça m'a l'air compromis sauf à limiter la zone à inspecter au lieu 
d'indiquer le nom de la ville (qui englobe toute la limite 
administrative)... sauf si après ces explications une solution simple 
peut être appliquée


Le 08/07/2020 à 19:51, Éric Gillet a écrit :

Le 03/07/2020 à 15:13, Percherie OnDaNet a écrit :
Je suis en train de regarder comment extraire les voies sans 
éclairage en ville et les voies principale hors aglo. Je part de la 
requête suivante :

[out:json][timeout:250];
(
   way["highway"][!"lit"]({{bbox}})(if: length() > 30);
);
// print results
out body;
>;
out skel qt;

Comment ajouter une zone englobante ayant les tags suivant  : 
landuse=residential|retail|commercial|industrial


En dehors de ces zones, je compte exclure les tag suivant : 
highway=track|path|road


Pas toutes les "aires" présentes dans OSM sont utilisables dans 
Overpass, sûrement pour des raisons de performance : 
https://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#By_area_.28area.29


Les landuses sans nom sont concernés. Exemple de la différence entre 
une aire présente et non-présente : https://overpass-turbo.eu/s/VVB


Je vois deux solutions :

- Considérer que ce qui est dans les limites administratives de ville 
est "en agglomération". Exemple : https://overpass-turbo.eu/s/VVC
- Importer la zone dans une base de données Postgis et faire les 
requêtes "à la main"



___
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] Suppression *covid19=*

[Philippe Verdy]

La COVID19 n'est pas partie, il est toujours pleinement actif dans le monde
et déjà on voit revenir des mesures de confinements en Europe. Et
certainement une fois l'été passé, on y reviendra (même si maintenant on a
des moyens de lutte et de protection). Le Brésil est en plein boom comme
aussi les USA, et c'est pour ça que la Guyane n'est pas déconfinée.
La COVID n'a jamais été aussi active qu'aujourd'hui, dont les pays qui ont
prétendu le contraire (en reportant la faute sur les autres dont la Chine
qui est parvenue à contenir la maladie) qui sont maintenant les plus
touchés (USA, Brésil, Russie, Mexique). Et même en Afrique qui a échappé au
gros de la première vague (liée au tourisme, aux voyageurs d'affaires, aux
étudiants et aux pays à forte immigration et nombreux échanges
inernationaux, ce qui a été contenu par la fermeture des lignes aériennes
et des voyages maritimes et croisières) n'est plus épargnée.
Tant qu'il n'y aura pas de vaccin massivement servi à la population, on
sera toujours exposé, tout ce qu'on peut faire pour l'instant c'est la
freiner et repousser un peu l'échéance.
Les mesures prises pendant le confinement si elles reviennent
nécessiteront les mêmes moyens, ce serait dommage de supprimer pour
l'instant alors qu'on n'a pas encore de prévention ni de traitement
efficace.
Ces données peuvent rester là pendant au moins un an ou deux, le temps de
voir ce qu'il advient: au moins on serait déjà prêt pour l'essentiel.
Ceci dit tout n'est pas perdu car ça peut concerner d'autres maladies (dont
aussi la grippe saisonnière qui tue depuis des années, et toute nouvelle
forme virale : on sait qu'il y en a beaucoup possibles; on doit retenir
aussi les leçons du H1N1, dont l'oubli a été la cause du retard pris pour
la COVID19... et qui n'a pas dit non plus son dernier mot et a déjà des tas
de nouvelles variantes)


Le sam. 4 juil. 2020 à 20:03,  a écrit :

> 1) Osmose est ton ami.
>
> 2) je pense que le mieux c'est de regarder les principales clés.
>
> 3) sinon une expression régulière
> 
> le fait si tu es sur une petite zone (ici forma CSV, pas forcément idéal
> mais pourquoi pas).
>
> Jean-Yvon
> Le 04/07/2020 à 17:50, deuzeffe - opensm@deuzeffe.org a écrit :
>
> Bonjour,
>
> Peu d'équipements de ma commune ont encore des restrictions
> d'ouverture/accès adaptées à la crise sanitaire (hors masques et SHA/GHA,
> simplement recommandés). Comment supprimer les tags appropriés sans faire
> une revue manuelle de chaque POI ? Probablement par une requête overpass ?
> Certes, mais laquelle ? À vos claviers !
>
> Merci pour votre aide.
>
> ___
> 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] OverPass et rue sans éclairage en ville

[Éric Gillet]

Le 03/07/2020 à 15:13, Percherie OnDaNet a écrit :
Je suis en train de regarder comment extraire les voies sans éclairage 
en ville et les voies principale hors aglo. Je part de la requête 
suivante :

[out:json][timeout:250];
(
   way["highway"][!"lit"]({{bbox}})(if: length() > 30);
);
// print results
out body;
>;
out skel qt;

Comment ajouter une zone englobante ayant les tags suivant  : 
landuse=residential|retail|commercial|industrial


En dehors de ces zones, je compte exclure les tag suivant : 
highway=track|path|road


Pas toutes les "aires" présentes dans OSM sont utilisables dans 
Overpass, sûrement pour des raisons de performance : 
https://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#By_area_.28area.29


Les landuses sans nom sont concernés. Exemple de la différence entre une 
aire présente et non-présente : https://overpass-turbo.eu/s/VVB


Je vois deux solutions :

- Considérer que ce qui est dans les limites administratives de ville 
est "en agglomération". Exemple : https://overpass-turbo.eu/s/VVC
- Importer la zone dans une base de données Postgis et faire les 
requêtes "à la main"


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

Re: [OSM-talk-fr] Lignes de bus à Courchevel : au secours !

[leni]

Le 08/07/2020 à 13:11, Yves P. a écrit :

Bonjour,

Soit la T5 qui va de Moûtiers à Courchevel 1850 (avec semble-t-il un 
A/R à la Tania)

https://www.openstreetmap.org/relation/8292018#map=14/45.4201/6.6372

Soit la B qui va de Courchevel 1850 à Saint-Bon-en-Tarentaise
https://www.openstreetmap.org/relation/1919549#map=14/45.4201/6.6372

LA B fait l'aller/retour mais elle est cassée à plusieurs endroits, et 
à cause des sens-uniques et des ronds points le trajet n'est pas tout 
à fait identique à l'aller et au retour.
Le départ et un rond point cassé à la sortie : 
https://www.openstreetmap.org/relation/1919549#map=17/45.41440/6.63779


Il me parait plus simple et plus clair de faire une B Aller et une B 
retour ?

(de plus JOSM n'arrive pas à trier correctement les membres)
Comme l'a indiqué Percherie il vaut mieux créer la route_master qui 
regroupe les deux relations route (aller et retour) il y a un greffon 
qui aide à la gestion des lignes, en numérotant les arrêts ce qui permet 
de voir ceux qui ne sont pas dans l'ordre


J'ai vu aussi des ronds-points "découpés". J'ai fait ça aussi au 
début, mais en fait ça complique la saisie.


J'avais fait des stats dans mon département et constaté que le découpage 
créait pas mal d'erreurs dans le temps.


cordialement

Leni

Un rond point "intégral" ne pose pas de problème pour le routage, ça 
fait seulement moche sur le rendu.


Il y a eu beaucoup de discutions dans le temps, mais il n'y a pas de 
consensus.


Il y a aussi une liste osm transport : transp...@listes.openstreetmap.fr

Cordialement

Leni



Merci de votre éclairage,

__
Yves

Horaires de la T5 : 
https://www.transdevsavoie.com/media/upload/FHCourchevelChampagnyPralognanEte2020.pdf 







___
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] Lignes de bus à Courchevel : au secours !

[Eric SIBERT]

Pour répondre à Christian, je commence par un ballon d'essai au niveau 
de la communauté locale avant d'attaquer au niveau global pour qu'on 
entame la discussion sur ce qui doit être dans OSM et ce qui n'a pas 
vocation à y être ;-).


Techniquement, sortir les limites administratives de tout poil ne paraît 
pas trop compliqué.


Le 08/07/2020 à 16:42, Yves P. a écrit :


La vraie question est : quand est-ce qu'on vire tous ces trucs
immatériels d'OSM et qu'on les met dans des bases externes?

En attendant que ça soit pris en compte par la communauté mondiale, 
j'aimerais des conseils sur les relations bus 


Au hasard :
- lignes de transports en commun

C'est matériel,  il y a des arrêts...


Pour moi, la partie matérielle (arrêt, abribus, quai, voie bus...) a sa 
place dans OSM. C'est la partie immatérielle, le concept de ligne, que 
je voudrais sortir. En pratique, la relation sur laquelle tu t'arraches 
les cheveux et qui rend très difficile l'édition de certaines routes 
(suite à l'ajout d'un terre-plein central par exemple). Quand il y 20 
relations de bus sur un bout de chaussée, des fois, je renonce à 
modifier. Mon seul conflit d'édition, c'est une fois où je modifiais la 
voirie à un endroit où passait une ligne de bus pendant qu'un autre 
contributeur faisait des modifs sur la même ligne de bus à des 
kilomètres de là.


Après, je suis conscient qu'avoir une base de donnée externe de ligne de 
bus (ou itinéraires de rando(c)) et maintenir un lien correct avec leur 
représentation physique dans OSM va être techniquement très difficile ;-).


Eric

___
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

[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

[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] Lignes de bus à Courchevel : au secours !

[Percherie OnDaNet]

Normalement il doit y avoir une relation route_master qui contient tout 
les trajets possible pour une ligne. Comme éléments dans cette relation 
tu doit avoir une relation par trajet. Cela permettra de recaler tout ça 
proprement.


Exemple :

type=route_master
route_master=bus
name=T5

Avec comme relation enfant
type=route
route=bus
name=T5 : Courchevel -> Moûtiers
from=Courchevel
to=Moûtiers

type=route
route=bus
name=T5 : Moûtiers -> Courchevel
from=Moûtiers
to=Courchevel

Tu a un exemple pratique sur 
https://www.openstreetmap.org/relation/2667720 mais le contenu de la 
page du wiki est en cours de refonte (passage du modèle de transport T1 
à T2). Pense à définir la couleur, opérateur, réseau, version 1 ou 2 du 
réseau.


J'ai également proposé à Adrien Pavie l'ajout de mission Pic4Review 
permettant de détailler les arrêts de bus  (mission en bas de liste) : 
https://pic4review.pavie.info/#/mission/copy "Arrêt de bus - Attente des 
passagers". Je l'utilise avec succès sur plusieurs villes autour de chez 
moi.


Le 08/07/2020 à 13:11, Yves P. a écrit :

Bonjour,

Soit la T5 qui va de Moûtiers à Courchevel 1850 (avec semble-t-il un 
A/R à la Tania)

https://www.openstreetmap.org/relation/8292018#map=14/45.4201/6.6372

Soit la B qui va de Courchevel 1850 à Saint-Bon-en-Tarentaise
https://www.openstreetmap.org/relation/1919549#map=14/45.4201/6.6372

LA B fait l'aller/retour mais elle est cassée à plusieurs endroits, et 
à cause des sens-uniques et des ronds points le trajet n'est pas tout 
à fait identique à l'aller et au retour.
Le départ et un rond point cassé à la sortie : 
https://www.openstreetmap.org/relation/1919549#map=17/45.41440/6.63779


Il me parait plus simple et plus clair de faire une B Aller et une B 
retour ?

(de plus JOSM n'arrive pas à trier correctement les membres)

J'ai vu aussi des ronds-points "découpés". J'ai fait ça aussi au 
début, mais en fait ça complique la saisie.
Un rond point "intégral" ne pose pas de problème pour le routage, ça 
fait seulement moche sur le rendu.


Merci de votre éclairage,

__
Yves

Horaires de la T5 : 
https://www.transdevsavoie.com/media/upload/FHCourchevelChampagnyPralognanEte2020.pdf 







___
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

[É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] Lignes de bus à Courchevel : au secours !

[Yves P.]

> La vraie question est : quand est-ce qu'on vire tous ces trucs
> immatériels d'OSM et qu'on les met dans des bases externes?
>
En attendant que ça soit pris en compte par la communauté mondiale,
j'aimerais des conseils sur les relations bus 

Au hasard :
> - lignes de transports en commun
>
C'est matériel,  il y a des arrêts...
Et surtout c'est utile pour voyager

J'en ai rien à faire de connaitre... à côté de
> chez moi, en dehors des aspects pollution ;-)
>
Idem pour les itinéraires de rando pédestre ou cyclable ? 
Et les transports en commun participent à la réduction de la pollution 

Ce qui est certain, c'est que la saisie et la maintenance des itinéraires
est lourde.

Un outil pour vérifier automatiquement leur "continuité" à chaque
modification serait un plus, mais ne règle pas tous les problèmes.

__
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

[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] preset Défibrillateur dans JOSM et iD 略

[leni]

Bonjour

Le 29/06/2020 à 18:28, Yves P. a écrit :

Bonsoir,

Dans JOSM : 略 "Tous modes de transport : " pas top pour indiquer (dans de rares cas ?) si 
un défibrillateur est "privé".


En effet cette traduction de l'attribut "acces" affiché "General Access" en anglais, ne 
convient pas dans ce cas, il faudrait trouver une autre traduction qui convienne également pour les autres 
objets : 
https://translations.launchpad.net/josm/trunk/+pots/josm/fr/+translate?batch=10=all=Tous+modes+de+transport


L'ergonomie n'est pas des plus lumineuses : "Situé à l'intérieur d'un bâtiment 
?" coché / décoché / grisé.
On pourrait mettre 2 ou 3 boutons radios : intérieur / extérieur / inconnu


Il me semble que le défibrillateur fait partie des préréglages internes, tu 
peux donc faire une proposition sur le site 
https://josm.openstreetmap.de/newticket



C'est guerre mieux dans iD pour "intérieur".

iD propose par défaut le tag "Code d'identification" (pour la référence) (mais 
pas JOSM).


comme plus haut



Quelles informations importantes faut-il saisir pour un défibrillateur ?
Et dans quel tags ?

__
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] Lignes de bus à Courchevel : au secours !

[Christian Rogel]

> Le 8 juil. 2020 à 13:42, Eric SIBERT  a écrit :
> La vraie question est : quand est-ce qu'on vire tous ces trucs immatériels 
> d'OSM et qu'on les met dans des bases externes?
> Au hasard :
> - lignes de transports en commun
> - limites administratives, politiques religieuses, d'aires protégées...
> J'en ai rien à faire de connaitre toutes les lignes MachinBus et autres 
> dessertes d'aéroports régionaux qui passent sur la nationale à côté de chez 
> moi, en dehors des aspects pollution ;-)

Si cette belle revendication a pour destin de dépasser le niveau provincial 
d’une liste talk-Fr, il faudra, peut-être, envisager d’en parler à la 
communauté OSM.
Voire, de se faire élire au Board. Et, encore, il faudrait circonvenir une 
partie de « l’écosystème ».
Y’a du boulot ! ;-)

Christian R.

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

Re: [OSM-talk-fr] Transiscope (cela utilise GoGoCarto, voire discussion récente)

[European Water Project]

Et pourquoi ne pas citer le sdg # dans un tague correspondant à l'utilité
de l'objet ?

https://sustainabledevelopment.un.org/?menu=1300

On Wed, 8 Jul 2020 at 11:27, Vincent Bergeot  wrote:

> Bonjour,
>
> il y a quelques jours, nous avons eu une discussion Transiscope (qui
> utilise GoGoCarto) et "OSM" (Mieux trier à Nantes/ChrisRen et moi). Plus
> d'infos sur Transiscope (https://transiscope.org/qui-sommes-nous/).
>
> Transiscope a une charte (https://transiscope.org/charte/) : notion de
> communs, citoyens, initiatives d'individus ou de groupes d'intérêts et plus
> si vous allez voir.
>
> Pour apparaître sur le portail de Transiscope, il s'agit de "respecter" la
> charte. Des données OSM sont déjà utilisées sur transiscope, car le respect
> de la charte est assurée par l'association Mieux Trier à Nantes qui valide
> les données envoyées à Transiscope. Une page wiki a été créée pour rappeler
> le contexte /
> https://wiki.openstreetmap.org/wiki/Proposed_features/transiscope.
>
> "L'envie, l'idée, le souhait" est d'arriver à mieux faire converger des
> "communautés" pour monter en qualité les données ouvertes disponibles.
> Transiscope est favorable à ce que son réseau puisse contribuer à OSM, avec
> cependant cette notion de "respect de la charte".
>
> Et donc comment arriver à qualifier le respect de la charte Transiscope
> dans OSM :
>
>- taguer des objets dans OSM avec un tag "transiscope" transiscope=yes
>(?) / aujourd'hui c'est plutôt "français mais transiscope s'ouvre de plus
>en plus au niveau européen"
>- network, cela a été évoqué pour les amap, brand c'est trop détourné,
>???
>- nous avons évoqué wikidata / transiscope:wikidata=#id_wikidata
>
> Il me semble qu'il y a des enjeux à pouvoir faire collaborer des
> communautés ayant des points en communs et évidemment leurs différences !
>
> à vous lire ici ou sur le wiki
> https://wiki.openstreetmap.org/wiki/Proposed_features/transiscope
>
> PS : Pour rappel, la récente discussion GoGoCarto sur des points d'eau /
> https://lists.openstreetmap.org/pipermail/talk-fr/2020-July/100284.html
>
> --
> Vincent Bergeot
>
> ___
> 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

[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

[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] Lignes de bus à Courchevel : au secours !

[Eric SIBERT]

La vraie question est : quand est-ce qu'on vire tous ces trucs 
immatériels d'OSM et qu'on les met dans des bases externes?

Au hasard :
- lignes de transports en commun
- limites administratives, politiques religieuses, d'aires protégées...

J'en ai rien à faire de connaitre toutes les lignes MachinBus et autres 
dessertes d'aéroports régionaux qui passent sur la nationale à côté de 
chez moi, en dehors des aspects pollution ;-)


Eric


Le 2020-07-08 13:11, Yves P. a écrit :

Bonjour,

Soit la T5 qui va de Moûtiers à Courchevel 1850 (avec semble-t-il un
A/R à la Tania)
https://www.openstreetmap.org/relation/8292018#map=14/45.4201/6.6372

Soit la B qui va de Courchevel 1850 à Saint-Bon-en-Tarentaise
https://www.openstreetmap.org/relation/1919549#map=14/45.4201/6.6372

LA B fait l'aller/retour mais elle est cassée à plusieurs endroits,
et à cause des sens-uniques et des ronds points le trajet n'est pas
tout à fait identique à l'aller et au retour.
Le départ et un rond point cassé à la sortie :
https://www.openstreetmap.org/relation/1919549#map=17/45.41440/6.63779

Il me parait plus simple et plus clair de faire une B Aller et une B
retour ?
(de plus JOSM n'arrive pas à trier correctement les membres)

J'ai vu aussi des ronds-points "découpés". J'ai fait ça aussi au
début, mais en fait ça complique la saisie.
Un rond point "intégral" ne pose pas de problème pour le routage,
ça fait seulement moche sur le rendu.

Merci de votre éclairage,

__
Yves

Horaires de la T5 :
https://www.transdevsavoie.com/media/upload/FHCourchevelChampagnyPralognanEte2020.pdf



___
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

[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

[OSM-talk-fr] Lignes de bus à Courchevel : au secours !

[Yves P.]

Bonjour,

Soit la T5 qui va de Moûtiers à Courchevel 1850 (avec semble-t-il un A/R à la 
Tania)
https://www.openstreetmap.org/relation/8292018#map=14/45.4201/6.6372

Soit la B qui va de Courchevel 1850 à Saint-Bon-en-Tarentaise
https://www.openstreetmap.org/relation/1919549#map=14/45.4201/6.6372

LA B fait l'aller/retour mais elle est cassée à plusieurs endroits, et à cause 
des sens-uniques et des ronds points le trajet n'est pas tout à fait identique 
à l'aller et au retour.
Le départ et un rond point cassé à la sortie : 
https://www.openstreetmap.org/relation/1919549#map=17/45.41440/6.63779

Il me parait plus simple et plus clair de faire une B Aller et une B retour ?
(de plus JOSM n'arrive pas à trier correctement les membres)

J'ai vu aussi des ronds-points "découpés". J'ai fait ça aussi au début, mais en 
fait ça complique la saisie.
Un rond point "intégral" ne pose pas de problème pour le routage, ça fait 
seulement moche sur le rendu.

Merci de votre éclairage,

__
Yves

Horaires de la T5 : 
https://www.transdevsavoie.com/media/upload/FHCourchevelChampagnyPralognanEte2020.pdf
 




___
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

[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

[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] Mise à jour BANO

[Philippe Verdy]

Les postulat de BANO était que le code FANTOIR correspond uniquement aux
codes INSEE des communes de plein exercice.
Hors dans les communes nouvelles, les communes déléguées **conservent**
leur code INSEE propre (et les codes FANTOIR qui leur sont associés, ainsi
que leur toponymie/odonymie et toutes les désignations locales...)
La commune nouvelle est une structure adminsitrative de gestion, elle a une
identité légale mais les communes déléguées aussi: le code INSEE de la
commune chef-lieu n'est pas suffisant pour distinguer ça, c'erst le code
SIREN qui fait la distinction des personnes morales.

BANO ne doit pas se baser sur seulement le code INSEE communal à 5 chiffres
des seules communes de plein exercice (donc seulement les communes
nouvelles et pas les communes déléguées) et doit conserver les codes INSEE
des communes déléguées. Et je pense même que BANO ne devrait pas dut tout
utiliser les codes des communes nouvelles mais seulement ceux des communes
déléguées.

La remarque vaut aussi pour les recherches cadastrales. Les planches
cadastrales sont distinguées: hormis la commune déléguée chef-lieu de la
commune nouvelle, dont les planches sont désignées par 1 lettre et
plusieurs chiffres, les planches des communes déléguées sont préfixées par
le code communal à 3 chiffres de chaque commune déléguée. Il arrive que le
code communal à 3 chiffres de la commune chef-lieu soit utilisé aussi en
préfixe, ou que ce préfixe soit "000".

Le code INSEE géographique à 5 chiffres (ou lettre A/B en Corse) des
communes est une version simplifiée du code communal, il ne désigne pas
nécessairement une commune en exercice, ou une personne morale, c'est juste
un code **géographique*.




Le mer. 8 juil. 2020 à 00:14, Vincent de Château-Thierry 
a écrit :

> Bonsoir,
>
> > De: "Jérôme Amagat" 
> >
> > Je pense que bano v2 ne gère pas toutes les communes nouvelles vu que
> > le nom de la commune indiquée par bano est Saint-Jean-sur-Couesnon
> > qui n'existe plus alors que la commune nouvelle "Rives-du-Couesnon"
> > créée en 2019 a le même code insee, Saint-Marc-sur-Couesnon est
> > aussi toujours present
> > https://bano.openstreetmap.fr/fantoir/index.html#insee=35293=3
>
> Un postulat de base pour BANO était qu'on ne rencontrait qu'une seule
> occurrence de chaque nom de voie sur le terrain, pour une commune donnée.
> Pas de bol avec les fusions, qui provoquent le casse-tête (pour tout le
> monde, pas juste pour BANO) d'homonymies infra-communales, avec x rues de
> l'Eglise, y place de la Mairie, etc. Je n'ai pas d'idée immédiatement de
> correctif pour gérer ça proprement, car ça casse un des fondamentaux de
> BANO. De là à dire qu'il faudrait tout casser pour bien gérer les
> homonymies, il y a peu.
> Pour répondre à Pierre-Yves : dispatcher le code Fantoir sur les ways ne
> changera (hélas) rien au problème.
> On peut imaginer casser le paradigme de BANO, en donnant l'ascendant au
> code FANTOIR sur le nom. Ca résoudra les homonymies, pas sûr que ça ne
> casse pas autre chose...
> On peut continuer d'en discuter ici, n'hésitez pas à détailler les
> problèmes directement sur le repo aussi :
> https://github.com/osm-fr/bano/issues
>
> merci
>
> vincent
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[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

[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

[OSM-talk-fr] Transiscope (cela utilise GoGoCarto, voire discussion récente)

[Vincent Bergeot]

Bonjour,

il y a quelques jours, nous avons eu une discussion Transiscope (qui 
utilise GoGoCarto) et "OSM" (Mieux trier à Nantes/ChrisRen et moi). Plus 
d'infos sur Transiscope (https://transiscope.org/qui-sommes-nous/).


Transiscope a une charte (https://transiscope.org/charte/) : notion de 
communs, citoyens, initiatives d'individus ou de groupes d'intérêts et 
plus si vous allez voir.


Pour apparaître sur le portail de Transiscope, il s'agit de "respecter" 
la charte. Des données OSM sont déjà utilisées sur transiscope, car le 
respect de la charte est assurée par l'association Mieux Trier à Nantes 
qui valide les données envoyées à Transiscope. Une page wiki a été créée 
pour rappeler le contexte / 
https://wiki.openstreetmap.org/wiki/Proposed_features/transiscope.


"L'envie, l'idée, le souhait" est d'arriver à mieux faire converger des 
"communautés" pour monter en qualité les données ouvertes disponibles. 
Transiscope est favorable à ce que son réseau puisse contribuer à OSM, 
avec cependant cette notion de "respect de la charte".


Et donc comment arriver à qualifier le respect de la charte Transiscope 
dans OSM :


 * taguer des objets dans OSM avec un tag "transiscope" transiscope=yes
   (?) / aujourd'hui c'est plutôt "français mais transiscope s'ouvre de
   plus en plus au niveau européen"
 * network, cela a été évoqué pour les amap, brand c'est trop détourné, ???
 * nous avons évoqué wikidata / transiscope:wikidata=#id_wikidata

Il me semble qu'il y a des enjeux à pouvoir faire collaborer des 
communautés ayant des points en communs et évidemment leurs différences !


à vous lire ici ou sur le wiki 
https://wiki.openstreetmap.org/wiki/Proposed_features/transiscope


PS : Pour rappel, la récente discussion GoGoCarto sur des points d'eau / 
https://lists.openstreetmap.org/pipermail/talk-fr/2020-July/100284.html


--
Vincent Bergeot

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

Re: [OSM-talk-fr] Mise à jour BANO

[Pierre-Yves Mevel via Talk-fr]

Merci Vincent pour ces précisions. Je vais aller reporter ce problème sur
Github pour éviter de flooder cette liste de discussion.

P-Y

Le mer. 8 juil. 2020 à 00:14, Vincent de Château-Thierry 
a écrit :

> Bonsoir,
>
> > De: "Jérôme Amagat" 
> >
> > Je pense que bano v2 ne gère pas toutes les communes nouvelles vu que
> > le nom de la commune indiquée par bano est Saint-Jean-sur-Couesnon
> > qui n'existe plus alors que la commune nouvelle "Rives-du-Couesnon"
> > créée en 2019 a le même code insee, Saint-Marc-sur-Couesnon est
> > aussi toujours present
> > https://bano.openstreetmap.fr/fantoir/index.html#insee=35293=3
>
> Un postulat de base pour BANO était qu'on ne rencontrait qu'une seule
> occurrence de chaque nom de voie sur le terrain, pour une commune donnée.
> Pas de bol avec les fusions, qui provoquent le casse-tête (pour tout le
> monde, pas juste pour BANO) d'homonymies infra-communales, avec x rues de
> l'Eglise, y place de la Mairie, etc. Je n'ai pas d'idée immédiatement de
> correctif pour gérer ça proprement, car ça casse un des fondamentaux de
> BANO. De là à dire qu'il faudrait tout casser pour bien gérer les
> homonymies, il y a peu.
> Pour répondre à Pierre-Yves : dispatcher le code Fantoir sur les ways ne
> changera (hélas) rien au problème.
> On peut imaginer casser le paradigme de BANO, en donnant l'ascendant au
> code FANTOIR sur le nom. Ca résoudra les homonymies, pas sûr que ça ne
> casse pas autre chose...
> On peut continuer d'en discuter ici, n'hésitez pas à détailler les
> problèmes directement sur le repo aussi :
> https://github.com/osm-fr/bano/issues
>
> merci
>
> vincent
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr