Re: [OSM-talk-fr] Suffixe :covid19

2020-11-20 Par sujet Yves P. 

> Par ici les horaires covid sont spécifique aux confinement. Généralement 
> ouvert de 14h à 16h du mardi au samedi. Voir encore plus restrictive
> Le reste de l'année les horaires sont habituelle.

On est tous d'accord :)


> Si la modifications se fait dans un sens qui va faire les relevés le mois 
> d'après pour contrôler les horaires habituelle ? Autant passer une seule fois 
> pour ajouter la condition horaire covid. Hors confinement elles ne doivent 
> plus être prises en compte.

Là encore, on est aussi tous d'accord :)

C'est la question du verre à moitié vide, ou à moitié plein :

1. Une application comme CRO va afficher les horaires en période covid à partir 
du tag opening_hours:covid19 (comment sait-elle qu'il y a un confinement ??)
2. Mais les applications non prévues pour ça (la majorité ??) va affiché les 
horaires "normaux" (tag opening_hours)

Avec la proposition d'Éric, toutes les applications vont afficher les horaires 
du moment : tag opening_hours :)

Pour répondre à ta remarque, si on note les horaires d'avant confinement dans 
le tag opening_hours:before_covid19, alors on pourra faire facilement du 
nettoyage (manuellement ou automatiquement).
Et ainsi ne passer qu'un seule fois pour ajouter "la condition horaire covid".


> De ce côté osmose fait très bien le job en proposant de transformer les 
> horaires covid en habituelles si elles n'existerait pas (après contrôle sur 
> place). Autrement la suppression des heures covid est proposé (pas le moment 
> de les supprimer)

L'analyseur Osmose le fera tout aussi bien en utilisant les clés 
opening_hours:before_covid19 et opening_hours (plutôt que opening_hours:covid19 
et opening_hours)

L'autre alternative est de ne rien changer, et d'espérer que toutes les 
applications utilisent opening_hours:covid19.
A-t-on une liste ?
Exhaustive ??

D'après Taginfo 
 il y a :
 Ça reste ouvert (It stays open) 

 iD Editor 
 AnyFinder - The universal POI finder and locator app 


__
Yves

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

Re: [OSM-talk-fr] Suffixe :covid19

2020-11-20 Par sujet Gad Jo 
Je ne suis pas d'accord. Par ici les horaires covid sont spécifique aux 
confinement. Généralement ouvert de 14h à 16h du mardi au samedi. Voir encore 
plus restrictive

Le reste de l'année les horaires sont habituelle.

Si la modifications se fait dans un sens qui va faire les relevés le mois 
d'après pour contrôler les horaires habituelle ? Autant passer une seule fois 
pour ajouter la condition horaire covid. Hors confinement elles ne doivent plus 
être prises en compte.
De ce côté osmose fait très bien le job en proposant de transformer les 
horaires covid en habituelles si elles n'existerait pas (après contrôle sur 
place). Autrement la suppression des heures covid est proposé (pas le moment de 
les supprimer)

Le 20 novembre 2020 14:55:18 UTC, "Éric Gillet"  a 
écrit :
>Bonjour,
>
>Le suffixe :covid19 (opening_hours:covid19, delivery:covid19 etc.) a été 
>créé pour le premier confinement, lorsque beaucoup de monde espérait 
>qu'il soit de courte durée et enraye la pandémie.
>La covid19 n'a pas disparu après le premier confinement, mais beaucoup 
>de commerces "non-essentiels" ont rouvert, ou on retrouvé un 
>fonctionnement "classique". D'ici quelques semaines (croisons les 
>doigts), on aura la même situation : déconfinement, peut-être 
>couvre-feu, mais néanmoins covid19 toujours présente.
>
>Ce suffixe ne fait malheureusement pas la distinction entre pandémie et 
>confinement (et couvre-feu etc.), il est donc difficile de connaître son 
>application. De plus, même si l'on dit qu'il ne s'applique que pour le 
>confinement, il est difficile de savoir si les horaires (ou autre) sont 
>revenues à la version pré-confinement, sont restées telle-quelles ou ont 
>été modifiées.
>
>Ne faudrait-il pas de nouveau utiliser les tags sans suffixe :covid19, 
>gérer ces modifications comme des changements classiques ? Que ce soit 
>pour les descriptions, horaires, livraisons, service à emporter etc.
>
>Cela a également l'avantage que ces tags sont affichés et modifiés par 
>la plupart des applications, contrairement aux suffixes :covid19. Cela 
>engendre des contradictions si les contributeurs ou applications ne 
>gèrent pas les deux.
>
>Qu'en pensez-vous ?
>
>Éric
>
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Suffixe :covid19

2020-11-20 Par sujet Yves P. 
> 
> En revanche avec le déconfinement progressif on devrait voir les magasins 
> retrouver leurs horaires habituels. Je serais plutôt partisan de conserver le 
> tag avec des horaires décrits finements lorsqu'il y a de vraies différences 
> mais pour les cas où les horaires sont les mêmes, privilégier la valeur 
> "same" plutôt que de copier les valeurs de opening_hours.

Il me semble que opening_hours:covid19=same était prévue pour ça.
Il aurait donc des interprétations de la "norme" ;)

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

Re: [OSM-talk-fr] Suffixe :covid19

2020-11-20 Par sujet Pierre-Olivier GREGOIRE 
Re-bonjour ;)

J'avais la même idée initialement quand je suis reparti dans la mise à jour
des magasins sur Lyon, en supposant que les horaires d'origines n'avaient
plus de valeur.

De ce que j'ai pu voir sur Lyon, il y a quand même beaucoup de magasins qui
ont clairement des horaires "spécifiques confinement". Les horaires
habituels restent sur le site web et sur la vitrine mais une annonce sur
facebook ou sur le site web indique les modifications apportées
temporairement pendant le confinement.

Pour les magasins qui ne peuvent pas faire de vente en magasin en
particulier, les horaires affichés pendant le confinement sont souvent des
horaires de retrait de commande.

Je viens de faire un essai dans 3 magasins que je viens de vérifier (sans
sélection promis) :
* https://www.caresteouvert.fr/@45.759447,4.834247,18.06/place/n6920787480
(charcuterie) :
 - habituellement Tu-Sa 08:30-13:30, 15:00-19:30. Ce sont toujours les
horaires indiqués sur le site web
 - pendant le confinement : le site indique un service "spécialement
adaptés" et les horaires sont légèrement réduis : Tu-Sa
08:30-13:00,15:00-18:30
* https://www.caresteouvert.fr/@45.750527,4.888045,17.47/place/n6655041936
(sushi) :
 - habituellement mo-sa 11:00-14:30, 18:00-21:30; su off . Ce sont les
horaires indiquée sur le site web
 - pendant le confinement : Mo-Sa 11:30-13:30,18:00-21:00. Le site
indiqué ces horaires spécifiquement pendant le confinement par un message
dédié
* https://www.caresteouvert.fr/@45.751035,4.887766,17.47/place/n6222998836
(librairie) :
 - habituellement : Tu-Fr 09:30-13:00,14:30-19:30; Sa
09:00-13:00,15:00-19:00
 - en ce moment ouvert uniquement pour les retraits donc Mardi –
Mercredi – Vendredi de 9h30 à 12h30 et de 14h30 à 19h Samedi de 9h à 13h et
c'est affiché comme un horaire exceptionnel sur leur site.

En revanche avec le déconfinement progressif on devrait voir les magasins
retrouver leurs horaires habituels. Je serais plutôt partisan de conserver
le tag avec des horaires décrits finements lorsqu'il y a de vraies
différences mais pour les cas où les horaires sont les mêmes, privilégier
la valeur "same" plutôt que de copier les valeurs de opening_hours.

Pierre-Olivier


Le ven. 20 nov. 2020 à 16:29, David Faure via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> On vendredi 20 novembre 2020 15:55:18 CET Éric Gillet wrote:
> > Le suffixe :covid19 (opening_hours:covid19, delivery:covid19 etc.) a été
> > créé pour le premier confinement, lorsque beaucoup de monde espérait
> > qu'il soit de courte durée et enraye la pandémie.
> > La covid19 n'a pas disparu après le premier confinement, mais beaucoup
> > de commerces "non-essentiels" ont rouvert, ou on retrouvé un
> > fonctionnement "classique". D'ici quelques semaines (croisons les
> > doigts), on aura la même situation : déconfinement, peut-être
> > couvre-feu, mais néanmoins covid19 toujours présente.
> >
> > Ce suffixe ne fait malheureusement pas la distinction entre pandémie et
> > confinement (et couvre-feu etc.), il est donc difficile de connaître son
> > application. De plus, même si l'on dit qu'il ne s'applique que pour le
> > confinement, il est difficile de savoir si les horaires (ou autre) sont
> > revenues à la version pré-confinement, sont restées telle-quelles ou ont
> > été modifiées.
> >
> > Ne faudrait-il pas de nouveau utiliser les tags sans suffixe :covid19,
> > gérer ces modifications comme des changements classiques ? Que ce soit
> > pour les descriptions, horaires, livraisons, service à emporter etc.
> >
> > Cela a également l'avantage que ces tags sont affichés et modifiés par
> > la plupart des applications, contrairement aux suffixes :covid19. Cela
> > engendre des contradictions si les contributeurs ou applications ne
> > gèrent pas les deux.
>
> Je suis 100% d'accord.
>
> --
> David Faure, fa...@kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>
>
>
>
> ___
> 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] Suffixe :covid19

2020-11-20 Par sujet Yves P. 
> Ne faudrait-il pas de nouveau utiliser les tags sans suffixe :covid19, gérer 
> ces modifications comme des changements classiques ? Que ce soit pour les 
> descriptions, horaires, livraisons, service à emporter etc.
> 
> Cela a également l'avantage que ces tags sont affichés et modifiés par la 
> plupart des applications, contrairement aux suffixes :covid19. Cela engendre 
> des contradictions si les contributeurs ou applications ne gèrent pas les 
> deux.

A priori je suis d'accord.


Les horaires pré covid sont imprimés, gravés sur beaucoup de vitrines, plaques…
En allant sur le terrain on peut toujours les voir, avec en plus une affiche 
collée sur la porte.

Du coup pouvoir voir les 2 dans l'objets OSM sans consulter l'historique est 
pratique.

Ne faudrait-il pas renommer les tags ?

opening_hours = horaires actuels (ça revient à ta proposition).
opening_hours:before_covid = les "anciens".

Comme ça si on se débarrasse du corona virus, on pourra nettoyer facilement les 
tags.
opening_hours ← opening_hours:before_covid
puis suppression de opening_hours:before_covid

__
Yves

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

Re: [OSM-talk-fr] Suffixe :covid19

2020-11-20 Par sujet David Faure via Talk-fr 
On vendredi 20 novembre 2020 15:55:18 CET Éric Gillet wrote:
> Le suffixe :covid19 (opening_hours:covid19, delivery:covid19 etc.) a été
> créé pour le premier confinement, lorsque beaucoup de monde espérait
> qu'il soit de courte durée et enraye la pandémie.
> La covid19 n'a pas disparu après le premier confinement, mais beaucoup
> de commerces "non-essentiels" ont rouvert, ou on retrouvé un
> fonctionnement "classique". D'ici quelques semaines (croisons les
> doigts), on aura la même situation : déconfinement, peut-être
> couvre-feu, mais néanmoins covid19 toujours présente.
> 
> Ce suffixe ne fait malheureusement pas la distinction entre pandémie et
> confinement (et couvre-feu etc.), il est donc difficile de connaître son
> application. De plus, même si l'on dit qu'il ne s'applique que pour le
> confinement, il est difficile de savoir si les horaires (ou autre) sont
> revenues à la version pré-confinement, sont restées telle-quelles ou ont
> été modifiées.
> 
> Ne faudrait-il pas de nouveau utiliser les tags sans suffixe :covid19,
> gérer ces modifications comme des changements classiques ? Que ce soit
> pour les descriptions, horaires, livraisons, service à emporter etc.
> 
> Cela a également l'avantage que ces tags sont affichés et modifiés par
> la plupart des applications, contrairement aux suffixes :covid19. Cela
> engendre des contradictions si les contributeurs ou applications ne
> gèrent pas les deux.

Je suis 100% d'accord.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

[OSM-talk-fr] Suffixe :covid19

2020-11-20 Par sujet Éric Gillet 

Bonjour,

Le suffixe :covid19 (opening_hours:covid19, delivery:covid19 etc.) a été 
créé pour le premier confinement, lorsque beaucoup de monde espérait 
qu'il soit de courte durée et enraye la pandémie.
La covid19 n'a pas disparu après le premier confinement, mais beaucoup 
de commerces "non-essentiels" ont rouvert, ou on retrouvé un 
fonctionnement "classique". D'ici quelques semaines (croisons les 
doigts), on aura la même situation : déconfinement, peut-être 
couvre-feu, mais néanmoins covid19 toujours présente.


Ce suffixe ne fait malheureusement pas la distinction entre pandémie et 
confinement (et couvre-feu etc.), il est donc difficile de connaître son 
application. De plus, même si l'on dit qu'il ne s'applique que pour le 
confinement, il est difficile de savoir si les horaires (ou autre) sont 
revenues à la version pré-confinement, sont restées telle-quelles ou ont 
été modifiées.


Ne faudrait-il pas de nouveau utiliser les tags sans suffixe :covid19, 
gérer ces modifications comme des changements classiques ? Que ce soit 
pour les descriptions, horaires, livraisons, service à emporter etc.


Cela a également l'avantage que ces tags sont affichés et modifiés par 
la plupart des applications, contrairement aux suffixes :covid19. Cela 
engendre des contradictions si les contributeurs ou applications ne 
gèrent pas les deux.


Qu'en pensez-vous ?

Éric


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

Re: [OSM-talk-fr] Changements "anciens" de limites communales

2020-11-20 Par sujet Philippe Verdy 
Les communes associées sont toujours des communes (au même titre que les
communes déléguées dans les communes nouvelles) même si elles ne sont pas
de plein exercice. Et ont une identité légale, juridique et comptable. La
seule chose vraiment changé c'est la fusion en un conseil municipal unique,
mais pourtant il y a bien une identité réelle, leur code INSEE est toujours
valide, il y a toujours des références dessus sur les identités de
personnes physiques et morales qui y sont enregistrées, et elles ont
conservé leur toponymie propre.
Elles devraient toutes être présentes. Un certain nombre sont dans OSM,
mais il en manque encore (et pourtant on a des tracés précis dans le
cadastre, où on les repère par le découpage zonal, avec les planches codées
pas seulement en lettres mais avec en préfixe les 3 chiffres initiaux
correspondant au code commune (sauf la commune chef-lieu, qui porte le
numéro "000" s'il y en a un, ou alors pas indiqué du tout) pour éviter les
lettrages identiques (certaines communes ont opté pour un relettrage par
exemple en ajoutant une lettre, ou lorsque le zonage des communes membres a
été redécoupé, tout en conservant l'ancienne limite toujours en vigueur,
par exemple pour aménager une zone d'activité ou un nouveau quartier à
lotir).
Ce zonage cadastral fait toujours référence (par exemple dans les actes
notariés): le cadastre a donc des limites précises (autant que les
frontières communales actuelles, sauf qu'elles ont rarement besoin de
conflation manuelle d'une commune à l'autre.
Tant qu'il n'y a pas eu de fusion pleine, le découpage zonal cadastral doit
conserver ces limites dans le plan d'assemblage de la commune.


Le jeu. 19 nov. 2020 à 00:38, Jérôme Amagat  a
écrit :

> En anciennes communes qui ont encore une "existence" aujourd'hui, il y a
> les communes qui sont devenues communes associées mais ça date des années
> 70. Il en manque beaucoup dans OSM.
>
> Le mer. 18 nov. 2020 à 18:48, Christian Quest  a
> écrit :
>
>> Le 18/11/2020 à 18:23, Yann-Vari Gwiader a écrit :
>> > Bonjour,
>> >
>> > Avant les incitations récentes aboutissant au regroupement de
>> > certaines communes en France, les modifications des délimitations
>> > communales ont été des phénomènes courants au XXème siècle. Il
>> > s'agissait souvent de regrouper plusieurs communes en une, ou alors de
>> > démembrer une ou plusieurs communes pour en créer une nouvelle, ou
>> > alors de transferts de bouts de territoires d'une commune à une autre.
>> >
>> > La page suivante du wiki :
>> >
>> https://wiki.openstreetmap.org/wiki/Talk:France/Limites_administratives/Tracer_les_limites_administratives#Anciennes_limites_administratives_.28r.C3.A9gion.2Fd.C3.A9partement.2Farrondissement.2Fcommune.29
>> >
>> > indique : "Il est toujours pertinent de conserver les anciennes
>> > limites (en positionnant disused:boundary sur la relation + en
>> > complétant par end_date la date de fin de vie de la limite, ainsi que
>> > source et source:url pour fournir la référence du changement)".
>> >
>> > J'ai un certain nombre d'exemples en tête concernant des modifications
>> > territoriales de communes qui ont été réalisées dans les années 1950
>> > et pour lesquelles des éléments (décrets + indications portées sur le
>> > cadastre napoléonien) permettent de reconstituer les changements qui
>> > ont eu lieu. Ces éléments ne sont pas, à cette heure, stockés dans
>> > OpenStreetMap pour les exemples que j'ai en tête.
>> >
>> > La question que je me pose est de savoir si le mode opératoire
>> > mentionné sur la page wiki ci-dessus est à jour et complet (dans
>> > l'hypothèse où l'inclusion de telles informations est validée par la
>> > communauté).
>> >
>> > Merci pour vos éclairages,
>> > Yann
>>
>>
>> C'est essentiellement pour les fusions récentes que l'on a conservé les
>> limites, je ne pense pas que pour des changements antérieurs (année 50
>> !) on ait quoi que ce soit dans OSM en France.
>>
>> Ajouter ces infos passerait sûrement mal au niveau de la communauté,
>> assez attaché à cartographier le monde tel qu'il est et pas tel qu'il
>> était il y a 70 ans. On a l'exemple des anciennes voies ferrées ou déjà
>> il y a presque une sorte de tolérance à avoir ces tracés alors qu'il n'y
>> a plus rien de visible sur le terrain.
>>
>> Il faudrait voir si Open Historical Map est encore actif et si ça ne
>> pourrait pas être ajouté là bas.
>>
>> --
>> Christian Quest - OpenStreetMap France
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Proposition - Vote - Les pompes

2020-11-20 Par sujet Jacques Lavignotte 



Le 19/11/2020 à 20:19, François Lacombe a écrit :

le vote sur la proposition traitant des pompes est finalement ouvert


A voté !


--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

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

Re: [OSM-talk-fr] Proposition - Vote - Les pompes

2020-11-20 Par sujet François Lacombe 
Merci Cyrille

C'est bien par la discussion qu'on arrivera à trouver la meilleure solution.
J'ai bien conscience que la proposition prévoit des changements, en
contrepartie de concepts plus largement définis définis qu'actuellement

Bon weekend

François

Le ven. 20 nov. 2020 à 13:35, Cyrille37 OSM via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Hello again
>
> Je suis aux bouts de mes arguments, les points de vue différents sont
> indissociables de notre humanité :-) Je laisse donc mon vote "pour" en
> confiance et en encouragement de ton implication :-D
>
> Cyrille37.
> Le 20/11/2020 à 13:08, François Lacombe a écrit :
>
> Cyrille,
>
> Parfois, les usages établis l'ont été à des époques où nous partions d'une
> feuille blanche.
> S'interdire de les améliorer (donc de remplacer certaines choses parfois)
> parce qu'ils existent aurait pu être opposé à OSM lorsqu'il remplace
> d'autres choses.
>
> En l'occurrence, pump=powered a beau être simple, il ne veut
> malheureusement rien dire et posera certainement des problèmes quand il
> s'agira de mettre osm en correspondance avec d'autres standards.
> Si il s'agit d'indiquer que la pompe n'est pas activable à la main, on
> peut mettre handle=no
>
> Je le redis, pump=* actuel ne parle pas de pompe, uniquement de puis et de
> moteurs éventuels. Pas des pompes.
>
> François
>
> Le ven. 20 nov. 2020 à 12:55, Cyrille37 OSM via Talk-fr <
> talk-fr@openstreetmap.org> a écrit :
>
>> François
>>
>> Je rejoins assez "Jeisenbe" sur le fait de ne pas déprécier les valeurs
>> précédentes qui correspondent à un usage établi. Pourquoi ne pas seulement
>> enrichir l'existant ?
>>
>> Pour ma part je trouve excellent les tags pump=manual et pump=powered,
>> c'est exactement de mon niveau. Ensuite s'ils peuvent être enrichis par
>> d'autres tags, yes, no problemo :-)
>>
>> C/.
>> Le 20/11/2020 à 12:25, Cyrille37 OSM a écrit :
>>
>> François
>>
>> Ceux qui sont contre disent que c'est "pump=powered" qui disparaît dans
>> la proposition, ce qui enlève la permission de tagger simplement.
>>
>> Cyrille.
>> Le 20/11/2020 à 10:37, François Lacombe a écrit :
>>
>> Bonjour Cyrille,
>>
>> Merci pour ton commentaire.
>>
>> Le ven. 20 nov. 2020 à 10:10, Cyrille37 OSM via Talk-fr <
>> talk-fr@openstreetmap.org> a écrit :
>>
>>> Je suis sensible au contre argument :
>>> *Any tagging scheme allowing to tag extreme detail uninteresting to
>>> nearly all people must allow also tagging basic info without making
>>> mandatory to specify details*
>>>
>> Cela tombe bien parce que je ne comprends pas cette phrase.
>> Il n'y a aucun tag obligatoire (sinon évidemment le man_made, mais c'est
>> une évidence), surtout pas le mechnical_driver.
>>
>>> Mais je n'ai pas analysé précisément la proposition pour confirmer sa
>>> véracité, seulement lu les 3 oppositions qui je trouve se rejoignent sur la
>>> nécessité de tagger simplement un pompe.
>>>
>> C'était bien le but je vous rassure, visiblement on est tous d'accord
>> (mais certains se sentent quand même obligés de voter contre)
>>
>>> Cette proposition permet-elle de continuer à tagger très simplement une
>>> pompe avec un seul tag, sans autre connaissance des détails ?
>>>
>> Oui, man_made=pump : c'est une pompe et suffit à lui-même, on est pas
>> obligé de faire plus.
>>
>> Le point central de la proposition est de cesser d'utiliser "pump" pour
>> parler du moteur puisque c'est le cas aujourd'hui.
>> Une pompe est souvent animée par un moteur, on a donc deux appareils
>> pompe + moteur, il me semble logique qu'OSM ait deux tags pour parler
>> respectivement de la pompe et du moteur.
>>
>> Bonne fin de semaine à vous tous
>>
>> François
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Proposition - Vote - Les pompes

2020-11-20 Par sujet Cyrille37 OSM via Talk-fr 

Hello again

Je suis aux bouts de mes arguments, les points de vue différents sont 
indissociables de notre humanité :-) Je laisse donc mon vote "pour" en 
confiance et en encouragement de ton implication :-D


Cyrille37.

Le 20/11/2020 à 13:08, François Lacombe a écrit :

Cyrille,

Parfois, les usages établis l'ont été à des époques où nous partions 
d'une feuille blanche.
S'interdire de les améliorer (donc de remplacer certaines choses 
parfois) parce qu'ils existent aurait pu être opposé à OSM lorsqu'il 
remplace d'autres choses.


En l'occurrence, pump=powered a beau être simple, il ne veut 
malheureusement rien dire et posera certainement des problèmes quand 
il s'agira de mettre osm en correspondance avec d'autres standards.
Si il s'agit d'indiquer que la pompe n'est pas activable à la main, on 
peut mettre handle=no


Je le redis, pump=* actuel ne parle pas de pompe, uniquement de puis 
et de moteurs éventuels. Pas des pompes.


François

Le ven. 20 nov. 2020 à 12:55, Cyrille37 OSM via Talk-fr 
mailto:talk-fr@openstreetmap.org>> a écrit :


François

Je rejoins assez "Jeisenbe" sur le fait de ne pas déprécier les
valeurs précédentes qui correspondent à un usage établi. Pourquoi
ne pas seulement enrichir l'existant ?

Pour ma part je trouve excellent les tags pump=manual et
pump=powered, c'est exactement de mon niveau. Ensuite s'ils
peuvent être enrichis par d'autres tags, yes, no problemo :-)

C/.

Le 20/11/2020 à 12:25, Cyrille37 OSM a écrit :


François

Ceux qui sont contre disent que c'est "pump=powered" qui
disparaît dans la proposition, ce qui enlève la permission de
tagger simplement.

Cyrille.

Le 20/11/2020 à 10:37, François Lacombe a écrit :

Bonjour Cyrille,

Merci pour ton commentaire.

Le ven. 20 nov. 2020 à 10:10, Cyrille37 OSM via Talk-fr
mailto:talk-fr@openstreetmap.org>> a
écrit :

Je suis sensible au contre argument :
/Any tagging scheme allowing to tag extreme detail
uninteresting to nearly all people *must allow also tagging
basic info without making mandatory to specify details*/

Cela tombe bien parce que je ne comprends pas cette phrase.
Il n'y a aucun tag obligatoire (sinon évidemment le man_made,
mais c'est une évidence), surtout pas le mechnical_driver.

Mais je n'ai pas analysé précisément la proposition pour
confirmer sa véracité, seulement lu les 3 oppositions qui je
trouve se rejoignent sur la nécessité de tagger simplement
un pompe.

C'était bien le but je vous rassure, visiblement on est tous
d'accord (mais certains se sentent quand même obligés de voter
contre)

Cette proposition permet-elle de continuer à tagger très
simplement une pompe avec un seul tag, sans autre
connaissance des détails ?

Oui, man_made=pump : c'est une pompe et suffit à lui-même, on
est pas obligé de faire plus.

Le point central de la proposition est de cesser d'utiliser
"pump" pour parler du moteur puisque c'est le cas aujourd'hui.
Une pompe est souvent animée par un moteur, on a donc deux
appareils pompe + moteur, il me semble logique qu'OSM ait deux
tags pour parler respectivement de la pompe et du moteur.

Bonne fin de semaine à vous tous

François

___
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] Proposition - Vote - Les pompes

2020-11-20 Par sujet François Lacombe 
Cyrille,

Parfois, les usages établis l'ont été à des époques où nous partions d'une
feuille blanche.
S'interdire de les améliorer (donc de remplacer certaines choses parfois)
parce qu'ils existent aurait pu être opposé à OSM lorsqu'il remplace
d'autres choses.

En l'occurrence, pump=powered a beau être simple, il ne veut
malheureusement rien dire et posera certainement des problèmes quand il
s'agira de mettre osm en correspondance avec d'autres standards.
Si il s'agit d'indiquer que la pompe n'est pas activable à la main, on peut
mettre handle=no

Je le redis, pump=* actuel ne parle pas de pompe, uniquement de puis et de
moteurs éventuels. Pas des pompes.

François

Le ven. 20 nov. 2020 à 12:55, Cyrille37 OSM via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> François
>
> Je rejoins assez "Jeisenbe" sur le fait de ne pas déprécier les valeurs
> précédentes qui correspondent à un usage établi. Pourquoi ne pas seulement
> enrichir l'existant ?
>
> Pour ma part je trouve excellent les tags pump=manual et pump=powered,
> c'est exactement de mon niveau. Ensuite s'ils peuvent être enrichis par
> d'autres tags, yes, no problemo :-)
>
> C/.
> Le 20/11/2020 à 12:25, Cyrille37 OSM a écrit :
>
> François
>
> Ceux qui sont contre disent que c'est "pump=powered" qui disparaît dans la
> proposition, ce qui enlève la permission de tagger simplement.
>
> Cyrille.
> Le 20/11/2020 à 10:37, François Lacombe a écrit :
>
> Bonjour Cyrille,
>
> Merci pour ton commentaire.
>
> Le ven. 20 nov. 2020 à 10:10, Cyrille37 OSM via Talk-fr <
> talk-fr@openstreetmap.org> a écrit :
>
>> Je suis sensible au contre argument :
>> *Any tagging scheme allowing to tag extreme detail uninteresting to
>> nearly all people must allow also tagging basic info without making
>> mandatory to specify details*
>>
> Cela tombe bien parce que je ne comprends pas cette phrase.
> Il n'y a aucun tag obligatoire (sinon évidemment le man_made, mais c'est
> une évidence), surtout pas le mechnical_driver.
>
>> Mais je n'ai pas analysé précisément la proposition pour confirmer sa
>> véracité, seulement lu les 3 oppositions qui je trouve se rejoignent sur la
>> nécessité de tagger simplement un pompe.
>>
> C'était bien le but je vous rassure, visiblement on est tous d'accord
> (mais certains se sentent quand même obligés de voter contre)
>
>> Cette proposition permet-elle de continuer à tagger très simplement une
>> pompe avec un seul tag, sans autre connaissance des détails ?
>>
> Oui, man_made=pump : c'est une pompe et suffit à lui-même, on est pas
> obligé de faire plus.
>
> Le point central de la proposition est de cesser d'utiliser "pump" pour
> parler du moteur puisque c'est le cas aujourd'hui.
> Une pompe est souvent animée par un moteur, on a donc deux appareils pompe
> + moteur, il me semble logique qu'OSM ait deux tags pour parler
> respectivement de la pompe et du moteur.
>
> Bonne fin de semaine à vous tous
>
> François
>
> ___
> 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] Proposition - Vote - Les pompes

2020-11-20 Par sujet Cyrille37 OSM via Talk-fr 

Le 20/11/2020 à 12:42, François Lacombe a écrit :
* pump=powered, s'il est vu comme une manière simple de taguer, est 
trop vague : il y a une multitude de solutions pour motoriser une pompe.


C'est à mon avis justement ce qu'est OSM, ça richesse et son 
accessibilité : à partir de l'information "man_made=pump" permettre au 
"kidam" de signaler qu'il a vu des gens manœuvrer la pompe "pump=manual" 
ou appuyer sur un bouton "pump=powered". Les précisions supplémentaires 
doivent être dans de nouveau tags ou valeurs supplémentaires, 
spécifiques à des usages, mais pas annuler les valeurs simples 
accessibles au plus grand nombre.


Cyrille37.


Il est en plus toujours possible d'utiliser une valeur style 
mechanical_driver=powered en palliatif le temps que quelqu'un donne 
plus de détails si nécessaire.


On en parle sur les bornes à incendie, la question est la même pour 
les services d'urgence ici : si je sais que la pompe du puits est 
motorisée sans plus d'infos et que je ne viens qu'avec du gasoil, 
alors que c'est un moteur électrique, ca ne servira à pas grand chose.


Je constate aussi que ceux qui critiquent maintenant le remplacement 
de pump=powered affirment aussi ne pas savoir pourquoi ces tags ont 
été définis à la base, ça me gêne un peu.


Bon apétit

François

Le ven. 20 nov. 2020 à 12:28, Cyrille37 OSM via Talk-fr 
mailto:talk-fr@openstreetmap.org>> a écrit :


François

Ceux qui sont contre disent que c'est "pump=powered" qui disparaît
dans la proposition, ce qui enlève la permission de tagger simplement.

Cyrille.

Le 20/11/2020 à 10:37, François Lacombe a écrit :

Bonjour Cyrille,

Merci pour ton commentaire.

Le ven. 20 nov. 2020 à 10:10, Cyrille37 OSM via Talk-fr
mailto:talk-fr@openstreetmap.org>> a
écrit :

Je suis sensible au contre argument :
/Any tagging scheme allowing to tag extreme detail
uninteresting to nearly all people *must allow also tagging
basic info without making mandatory to specify details*/

Cela tombe bien parce que je ne comprends pas cette phrase.
Il n'y a aucun tag obligatoire (sinon évidemment le man_made,
mais c'est une évidence), surtout pas le mechnical_driver.

Mais je n'ai pas analysé précisément la proposition pour
confirmer sa véracité, seulement lu les 3 oppositions qui je
trouve se rejoignent sur la nécessité de tagger simplement un
pompe.

C'était bien le but je vous rassure, visiblement on est tous
d'accord (mais certains se sentent quand même obligés de voter
contre)

Cette proposition permet-elle de continuer à tagger très
simplement une pompe avec un seul tag, sans autre
connaissance des détails ?

Oui, man_made=pump : c'est une pompe et suffit à lui-même, on est
pas obligé de faire plus.

Le point central de la proposition est de cesser d'utiliser
"pump" pour parler du moteur puisque c'est le cas aujourd'hui.
Une pompe est souvent animée par un moteur, on a donc deux
appareils pompe + moteur, il me semble logique qu'OSM ait deux
tags pour parler respectivement de la pompe et du moteur.

Bonne fin de semaine à vous tous

François

___
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] Proposition - Vote - Les pompes

2020-11-20 Par sujet Cyrille37 OSM via Talk-fr 

François

Je rejoins assez "Jeisenbe" sur le fait de ne pas déprécier les valeurs 
précédentes qui correspondent à un usage établi. Pourquoi ne pas 
seulement enrichir l'existant ?


Pour ma part je trouve excellent les tags pump=manual et pump=powered, 
c'est exactement de mon niveau. Ensuite s'ils peuvent être enrichis par 
d'autres tags, yes, no problemo :-)


C/.

Le 20/11/2020 à 12:25, Cyrille37 OSM a écrit :


François

Ceux qui sont contre disent que c'est "pump=powered" qui disparaît 
dans la proposition, ce qui enlève la permission de tagger simplement.


Cyrille.

Le 20/11/2020 à 10:37, François Lacombe a écrit :

Bonjour Cyrille,

Merci pour ton commentaire.

Le ven. 20 nov. 2020 à 10:10, Cyrille37 OSM via Talk-fr 
mailto:talk-fr@openstreetmap.org>> a écrit :


Je suis sensible au contre argument :
/Any tagging scheme allowing to tag extreme detail uninteresting
to nearly all people *must allow also tagging basic info without
making mandatory to specify details*/

Cela tombe bien parce que je ne comprends pas cette phrase.
Il n'y a aucun tag obligatoire (sinon évidemment le man_made, mais 
c'est une évidence), surtout pas le mechnical_driver.


Mais je n'ai pas analysé précisément la proposition pour
confirmer sa véracité, seulement lu les 3 oppositions qui je
trouve se rejoignent sur la nécessité de tagger simplement un pompe.

C'était bien le but je vous rassure, visiblement on est tous d'accord 
(mais certains se sentent quand même obligés de voter contre)


Cette proposition permet-elle de continuer à tagger très
simplement une pompe avec un seul tag, sans autre connaissance
des détails ?

Oui, man_made=pump : c'est une pompe et suffit à lui-même, on est pas 
obligé de faire plus.


Le point central de la proposition est de cesser d'utiliser "pump" 
pour parler du moteur puisque c'est le cas aujourd'hui.
Une pompe est souvent animée par un moteur, on a donc deux appareils 
pompe + moteur, il me semble logique qu'OSM ait deux tags pour parler 
respectivement de la pompe et du moteur.


Bonne fin de semaine à vous tous

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

Re: [OSM-talk-fr] Proposition - Vote - Les pompes

2020-11-20 Par sujet François Lacombe 
Cyrille,

Oui c'est ce à quoi j'étais en train de répondre.

Il y a plusieurs problèmes auxquels je souhaite apporter une solution
durable :
* pump=* est actuellement réservé aux puits et traite des moteurs au lieu
de parler des pompes elles-même.
* pump=powered, s'il est vu comme une manière simple de taguer, est trop
vague : il y a une multitude de solutions pour motoriser une pompe.
Il est en plus toujours possible d'utiliser une valeur style
mechanical_driver=powered en palliatif le temps que quelqu'un donne plus de
détails si nécessaire.

On en parle sur les bornes à incendie, la question est la même pour les
services d'urgence ici : si je sais que la pompe du puits est motorisée
sans plus d'infos et que je ne viens qu'avec du gasoil, alors que c'est un
moteur électrique, ca ne servira à pas grand chose.

Je constate aussi que ceux qui critiquent maintenant le remplacement de
pump=powered affirment aussi ne pas savoir pourquoi ces tags ont été
définis à la base, ça me gêne un peu.

Bon apétit

François

Le ven. 20 nov. 2020 à 12:28, Cyrille37 OSM via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> François
>
> Ceux qui sont contre disent que c'est "pump=powered" qui disparaît dans la
> proposition, ce qui enlève la permission de tagger simplement.
>
> Cyrille.
> Le 20/11/2020 à 10:37, François Lacombe a écrit :
>
> Bonjour Cyrille,
>
> Merci pour ton commentaire.
>
> Le ven. 20 nov. 2020 à 10:10, Cyrille37 OSM via Talk-fr <
> talk-fr@openstreetmap.org> a écrit :
>
>> Je suis sensible au contre argument :
>> *Any tagging scheme allowing to tag extreme detail uninteresting to
>> nearly all people must allow also tagging basic info without making
>> mandatory to specify details*
>>
> Cela tombe bien parce que je ne comprends pas cette phrase.
> Il n'y a aucun tag obligatoire (sinon évidemment le man_made, mais c'est
> une évidence), surtout pas le mechnical_driver.
>
>> Mais je n'ai pas analysé précisément la proposition pour confirmer sa
>> véracité, seulement lu les 3 oppositions qui je trouve se rejoignent sur la
>> nécessité de tagger simplement un pompe.
>>
> C'était bien le but je vous rassure, visiblement on est tous d'accord
> (mais certains se sentent quand même obligés de voter contre)
>
>> Cette proposition permet-elle de continuer à tagger très simplement une
>> pompe avec un seul tag, sans autre connaissance des détails ?
>>
> Oui, man_made=pump : c'est une pompe et suffit à lui-même, on est pas
> obligé de faire plus.
>
> Le point central de la proposition est de cesser d'utiliser "pump" pour
> parler du moteur puisque c'est le cas aujourd'hui.
> Une pompe est souvent animée par un moteur, on a donc deux appareils pompe
> + moteur, il me semble logique qu'OSM ait deux tags pour parler
> respectivement de la pompe et du moteur.
>
> Bonne fin de semaine à vous tous
>
> François
>
> ___
> 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] Proposition - Vote - Les pompes

2020-11-20 Par sujet Cyrille37 OSM via Talk-fr 

François

Ceux qui sont contre disent que c'est "pump=powered" qui disparaît dans 
la proposition, ce qui enlève la permission de tagger simplement.


Cyrille.

Le 20/11/2020 à 10:37, François Lacombe a écrit :

Bonjour Cyrille,

Merci pour ton commentaire.

Le ven. 20 nov. 2020 à 10:10, Cyrille37 OSM via Talk-fr 
mailto:talk-fr@openstreetmap.org>> a écrit :


Je suis sensible au contre argument :
/Any tagging scheme allowing to tag extreme detail uninteresting
to nearly all people *must allow also tagging basic info without
making mandatory to specify details*/

Cela tombe bien parce que je ne comprends pas cette phrase.
Il n'y a aucun tag obligatoire (sinon évidemment le man_made, mais 
c'est une évidence), surtout pas le mechnical_driver.


Mais je n'ai pas analysé précisément la proposition pour confirmer
sa véracité, seulement lu les 3 oppositions qui je trouve se
rejoignent sur la nécessité de tagger simplement un pompe.

C'était bien le but je vous rassure, visiblement on est tous d'accord 
(mais certains se sentent quand même obligés de voter contre)


Cette proposition permet-elle de continuer à tagger très
simplement une pompe avec un seul tag, sans autre connaissance des
détails ?

Oui, man_made=pump : c'est une pompe et suffit à lui-même, on est pas 
obligé de faire plus.


Le point central de la proposition est de cesser d'utiliser "pump" 
pour parler du moteur puisque c'est le cas aujourd'hui.
Une pompe est souvent animée par un moteur, on a donc deux appareils 
pompe + moteur, il me semble logique qu'OSM ait deux tags pour parler 
respectivement de la pompe et du moteur.


Bonne fin de semaine à vous tous

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

[OSM-talk-fr] Get-Together CartONG en ligne : formations gratuites, bilan 2020, rencontres et plus!

2020-11-20 Par sujet Kelly Green 


 
 
  
   
Bonjour à tou.te.s !  

   
   

   
   
Vous êtes invité.e.s à rejoindre le staff et les bénévoles de CartONG du lundi 23 novembre au samedi 28 novembre lors d'un Get-Together en ligne ! C’est l’occasion de participer à des formations gratuites, de découvrir des projets de cartographie et autres, de partager vos expériences, ou de discuter de futurs horizons ! 
   
   
Comment faire pour y participer ? Nous vous invitons à piocher dans les sessions qui vous intéressent. Le programme complet est accessible en ligne sur ce lien. Pas besoin de vous inscrire, c'est gratuit et il suffit de vous connecter sur le lien Skype ou Zoom de la session à l’heure indiquée ! 
   
   
  
Aperçu du programme. Les descriptions des sessions et les liens pour s’y connecter sont accessibles sur ce lien 
   
   
https://mensuel.framapad.org/p/programme-g2g-9k2h 

Un rendez-vous à ne pas manquer le samedi

 Samedi 28 novembre - 14h30-17h30 /  CartONG à l'horizon 2023 : reprenons le cheminement ! FR 
Mais aussi des sessions réparties du lundi au vendredi !

 Lundi 23 novembre - 12h30-13h30 /  À la découverte … des styles & templates CartONG sur QGIS - FR 
 Mardi 24 novembre - 18h30-20h00 / ️ Missing Maps  : Bilan 2020 et perspectives pour demain - FR 
 Mercredi 25 novembre - 12h30-13h30 /  GeOnG 2020 : Partage d'expérience - FR + ENG 
 Mercredi 25 novembre - 19h00-20h00 /  Initiation à JOSM - FR 
 Jeudi 26 novembre - 12h30-13h30 /  Le Webmapping, une réponse aux attentes cartographiques des petites structures de solidarité - FR 
 Jeudi 26 novembre - 18h30-19h30 / ️ Des cartes contre la peine de mort - FR 
 Vendredi 27 novembre - 12h30-13h30 /  Un nouvel envol pour le projet Cartes d'ici & d'ailleurs - FR 
 -
   
   

   
   
L'équipe de CartONG (contact : i...@cartong.org)
   
  
 


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

Re: [OSM-talk-fr] Proposition - Vote - Les pompes

2020-11-20 Par sujet François Lacombe 
Bonjour Cyrille,

Merci pour ton commentaire.

Le ven. 20 nov. 2020 à 10:10, Cyrille37 OSM via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Je suis sensible au contre argument :
> *Any tagging scheme allowing to tag extreme detail uninteresting to
> nearly all people must allow also tagging basic info without making
> mandatory to specify details*
>
Cela tombe bien parce que je ne comprends pas cette phrase.
Il n'y a aucun tag obligatoire (sinon évidemment le man_made, mais c'est
une évidence), surtout pas le mechnical_driver.

> Mais je n'ai pas analysé précisément la proposition pour confirmer sa
> véracité, seulement lu les 3 oppositions qui je trouve se rejoignent sur la
> nécessité de tagger simplement un pompe.
>
C'était bien le but je vous rassure, visiblement on est tous d'accord (mais
certains se sentent quand même obligés de voter contre)

> Cette proposition permet-elle de continuer à tagger très simplement une
> pompe avec un seul tag, sans autre connaissance des détails ?
>
Oui, man_made=pump : c'est une pompe et suffit à lui-même, on est pas
obligé de faire plus.

Le point central de la proposition est de cesser d'utiliser "pump" pour
parler du moteur puisque c'est le cas aujourd'hui.
Une pompe est souvent animée par un moteur, on a donc deux appareils pompe
+ moteur, il me semble logique qu'OSM ait deux tags pour parler
respectivement de la pompe et du moteur.

Bonne fin de semaine à vous tous

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

Re: [OSM-talk-fr] Proposition - Vote - Les pompes

2020-11-20 Par sujet Cyrille37 OSM via Talk-fr 

Bonjour

Le 19/11/2020 à 20:19, François Lacombe a écrit :
Suite aux annonces faites plus tôt cette année, le vote sur la 
proposition traitant des pompes est finalement ouvert

https://wiki.openstreetmap.org/wiki/Proposed_features/Pumping_proposal


Je suis sensible au contre argument :
/Any tagging scheme allowing to tag extreme detail uninteresting to 
nearly all people *must allow also tagging basic info without making 
mandatory to specify details*/


Mais je n'ai pas analysé précisément la proposition pour confirmer sa 
véracité, seulement lu les 3 oppositions qui je trouve se rejoignent sur 
la nécessité de tagger simplement un pompe.


Cette proposition permet-elle de continuer à tagger très simplement une 
pompe avec un seul tag, sans autre connaissance des détails ?


Merci
Cyrille37.

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