Re: [OSM-talk-fr] Élections au board de la Fondation OSM

[thevenon . julien]

- Mail original 
De: "Vincent Bergeot" 
À: talk-fr@openstreetmap.org
Envoyé: Lundi 9 Décembre 2019 10:15:12
Objet: [OSM-talk-fr] Élections au board de la Fondation OSM

> Bonjour, 

> Vote à la fondation jusqu'au 14 décembre (2019-12-14 16:00 UTC ) pour les 
> votant(-e)s et pour la curiosité des autres : 
>  * l'ensemble des réponses et des manifestes (en anglais) : 
> https://wiki.openstreetmap.org/wiki/Foundation/AGM19/Election_to_Board/Answers_and_manifestos
>  
> Des analyses et propositions de votes : 
>* 
> http://blog.imagico.de/2019-osmf-board-candidates-analysis-and-recommendations/
>  
>* https://wiki.openstreetmap.org/wiki/User:Westnordost/AGM19_Cheatsheet 
>* https://www.openstreetmap.org/user/SJFriedl/diary/391453 

Hello,

Petit rappel pour ceux qui ont recus les bulletins mais qui n auraient pas 
encore votes !
Pour les autres n hesitez pas a lire les manifestes des candidats ou l analyse 
de Christoph Hormann ( 
http://blog.imagico.de/2019-osmf-board-candidates-analysis-and-recommendations/ 
), ca illustre bien les enjeux de l election

Julien

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

Re: [OSM-talk-fr] Élections au board de la Fondation OSM

[Christine Karch]

Il y a aussi les changements en articles d'association. Recommandation
de Simon Pool est "yes" pour tous les trois changements ...

Am 12.12.19 um 09:42 schrieb thevenon.jul...@free.fr:
> - Mail original 
> De: "Vincent Bergeot" 
> À: talk-fr@openstreetmap.org
> Envoyé: Lundi 9 Décembre 2019 10:15:12
> Objet: [OSM-talk-fr] Élections au board de la Fondation OSM
> 
>> Bonjour, 
> 
>> Vote à la fondation jusqu'au 14 décembre (2019-12-14 16:00 UTC ) pour les 
>> votant(-e)s et pour la curiosité des autres : 
>>  * l'ensemble des réponses et des manifestes (en anglais) : 
>> https://wiki.openstreetmap.org/wiki/Foundation/AGM19/Election_to_Board/Answers_and_manifestos
>>  
>> Des analyses et propositions de votes : 
>>* 
>> http://blog.imagico.de/2019-osmf-board-candidates-analysis-and-recommendations/
>>  
>>* https://wiki.openstreetmap.org/wiki/User:Westnordost/AGM19_Cheatsheet 
>>* https://www.openstreetmap.org/user/SJFriedl/diary/391453 
> 
> Hello,
> 
> Petit rappel pour ceux qui ont recus les bulletins mais qui n auraient pas 
> encore votes !
> Pour les autres n hesitez pas a lire les manifestes des candidats ou l 
> analyse de Christoph Hormann ( 
> http://blog.imagico.de/2019-osmf-board-candidates-analysis-and-recommendations/
>  ), ca illustre bien les enjeux de l election
> 
> Julien
> 
> ___
> 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] adresse mail rejetée

[Alain Rpnpif]

Le 10/12/2019 à 18:01, marc marc a écrit :

quelqu'un a un message d'erreur d'un de ces emails rejetté ?


Bonjour,

Je aais par une autre adresse que OVH est inscrit à tort comme spammeur chez 
spamhaus.

Ce qui explique que certains reçoivent des messages marqués [SPAM] et 
que d'autres ne les reçoivent pas car leur serveur est abonné à Spamhaus.


-- Rpnpif

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

Re: [OSM-talk-fr] gestion du hstore dans qgis

[Tony Emery via Talk-fr]

Je n'utilise pas quickOSM car les données sont déjà dans Postgresql via
osm2pgsql.

Mon problème est que si je demande à osm2pgsql d'extraire tous les champs
(via le fichier de config), je vais en avoir beaucoup dont la majorité sera
vide et cela rendra mes requêtes futures compliquées à gérer.

Du coup, j'ai fait quelques requêtes post intrégration dans postgresql pour
créer des tables thématiques (highway, landuse,...) à partir d'une table
dans laquelle se trouvent la clés principale et toutes les clés à extraire.
Sauf que ces clés doivent être déjà extraite par osm2pgsql et si je veux en
ajouter d'autres, c'est pas très souple.

J'avais pensé à mettre mon extracteur de hstore ( tags->'bridge' AS bridge )
dans la table mais les guillemets me font planter la requête.

Du coup, je me tourne vers qgis pour savoir si on peut faire des analyses
carto en utilisant directement le champ "tags" contenant le hstore dans la
sémiologie.



-
Tony EMERY
OpenStreetMap.fr
Ingénieur SIG
--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

[OSM-talk-fr] CA Physique

[Tony Emery via Talk-fr]

Bonjour à toutes et à tous,

Petit rappel !

Le prochain conseil d'administration physique (CAP) de l'association
OpenStreetMap France (OSM-FR) aura lieu les 15 et 16 février 2020 à la
Turbine à Grenoble. L'adresse est la suivante : 3-5 esplanade Andry Farcy,
38000 Grenoble.

Ce CAP n'est pas réservé qu'aux membres du conseil d'administration mais,
plus encore que l'an dernier, est élargi à toutes les personnes qui veulent
faire, ont l'intention de faire ou font quelque chose au niveau de
l'association OSM-France.
L'objectif de ce week-end est de faire connaissance, d'échanger et de
travailler collectivement autour du projet associatif OSM-FR. Nous en
profiterons pour faire un point plus général sur OSM.

Dans un premier temps, et afin d'organiser au mieux cette rencontre, nous
avons besoin :
- de savoir si nous pouvons compter sur votre présence ;
- que vous répondiez à ce questionnaire 
https://lite.framacalc.org/caphysiqueosm-fr
   (dates et heures d'arrivée
et de départ, hébergement) ;
- que vous veniez avec une spécialité locale à boire ou à manger afin de
partager le repas du samedi midi ;

Un temps convivial aura lieu le vendredi soir en fonction des heures
d'arrivée de chacun. Nous vous donnons rendez-vous dès 20h dans un lieu
restant à définir.

Afin de réserver dès maintenant et au plus vite vos billets de train, sachez
que le CAP aura lieu de samedi 15 février 9h au dimanche 16 février 16h.

Comme convenu, l'association prendra en charge les déplacements, les repas
du vendredi soir, samedi soir et dimanche midi. Nous cherchons également des
hébergements pour celles et ceux qui le souhaitent.
Concernant les modalités de prise en charge par l'association de votre
déplacement, veuillez contacter Donat (dona...@gmail.com ) ou Louis-Julien
(ljbou...@openstreetmap.fr ).
Nous vous recontacterons par la suite pour avoir vos avis et vos attentes et
pour vous donner le programme du week-end.

Attention, nous avons besoin de votre réponse urgemment et avant le dimanche
22 décembre 2019.

Bonne réception,

Tony EMERY



-
Tony EMERY
OpenStreetMap.fr
Ingénieur SIG
--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-talk-fr] Appel à l'aide à propos d'une série de premières contributions assez catastrophiques

[FR via Talk-fr]

Bonjour

Et bien je constate que mon alerte n’aura pas été inutile ;-) Les bonnes 
pratiques énoncées dans ce texte recoupent tout à fait en creux les bugs 
que j'ai pu constater.
J'espère seulement que le ou la prof des chiapacans qui nous ont mis le 
waï dans OSM (1) ne se formalise pas trop de cette aventure. D'une part 
il-elle essuie les plâtres d'une réforme des programmes dont les auteurs 
manifestement ne se sont pas demandé ce que ça impliquait de temps de 
prise en main pour des profs découvrant OSM. D'autre part ce n'est pas 
qu'à propos d’OSM que nos ados se défoulent : 
.


Quant aux corrections, elles sont en cours (22 contributions repérées). 
Personnellement j’ai priorisé de ce qui impactait les lignes de bus et 
le réseau ferré et je tente de récupérer ce qui a été effacé. Mais un 
"revert" aurait été un peu moins bouffe temps.


Il y a un problème avec certaines corrections faites avec iD par 
d'autres contributeurs. Elles ont abouti à la suppression d’objets 
faute de remonter à l'état précédent. Par ex. le chemin du 
"highway=service" qui avait été transformé en "railway" a été effacé.
Est-ce qu’il est possible avec iD de remonter dans l’historique comme on 
le fait avec JOSM, afin de récupérer les anciens attributs ainsi que les 
coordonnées des objets déplacés ? J'ai pas trouvé (mais je ne connais 
que JOSM).


FR

(1) si toutefois il se confirme qu'il s'agit bien d'un cours de SNT, 
après tout j'en sais toujours rien...



Le 11/12/2019 à 21:23, Cédric Frayssinet a écrit :
vous informe que suite aux mauvaises contributions marseillaises, un 
courriel est parti dans toutes les DANE (Délégation Académique au 
Numérique Éducatif) de France. Il a été envoyé ce matin et il devrait 
redescendre chez tous les enseignants de SNT en académie.


Je vous le mets pour info là : https://cloud.mesdatas.org/s/omfk7aoefegrHFA

Il a été validé par certaines membres du CA OSM-Fr et notamment Vincent 
Bergeot.


J'ai déjà été contacté, et notamment par un auteur du manuel Bordas qui 
avait vu arriver les soucis possibles.


Espérons que cela ait un effet positif, n'hésitez pas à remonter les 
éventuels soucis.


Cédric





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

Re: [OSM-talk-fr] Appel à l'aide à propos d'une série de premières contributions assez catastrophiques

[marc marc]

> Le 12 déc. 2019 à 16:13, FR via Talk-fr  a écrit :
> 
> Est-ce qu’il est possible avec iD de remonter dans l’historique

Il y a un lien en bas à gauche vers osm.org pour afficher l'historique.
Mais iD comme Josm sans plugin reverter ne permet à ma connaissance pas 
d'annuler la supression.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] gestion du hstore dans qgis

[HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT GE PPE)]

Salut Tony,

Essaie ceci :
Dans ton projet tu définis une (ou plusieurs) variable(s) dont la valeur est le 
nom de la clé que tu veux extraire
champ : 'building' par exemple
Dans ta couche de données osm, ajoute un champ virtuel de type texte (ou autre 
suivant besoin) qui contient la formule : map_get( tags,  @champ  ) où tags est 
le champ qui contient ton hstore
Qgis mettra dans ta colonne virtuelle la valeur de la clé dont le nom est 
spécifié par la variable.
Il te suffira de changer la valeur de la variable pour changer de clé à 
extraire. 
Tu peux faire autant de champs virtuels que tu veux pour extraire plusieurs clés

J'espère que cela répondra à ton besoin
Denis

-Message d'origine-
De : Tony Emery via Talk-fr  
Envoyé : jeudi 12 décembre 2019 13:56
À : talk-fr@openstreetmap.org
Cc : Tony Emery 
Objet : Re: [OSM-talk-fr] gestion du hstore dans qgis

Je n'utilise pas quickOSM car les données sont déjà dans Postgresql via 
osm2pgsql.

Mon problème est que si je demande à osm2pgsql d'extraire tous les champs (via 
le fichier de config), je vais en avoir beaucoup dont la majorité sera vide et 
cela rendra mes requêtes futures compliquées à gérer.

Du coup, j'ai fait quelques requêtes post intrégration dans postgresql pour 
créer des tables thématiques (highway, landuse,...) à partir d'une table dans 
laquelle se trouvent la clés principale et toutes les clés à extraire.
Sauf que ces clés doivent être déjà extraite par osm2pgsql et si je veux en 
ajouter d'autres, c'est pas très souple.

J'avais pensé à mettre mon extracteur de hstore ( tags->'bridge' AS bridge ) 
dans la table mais les guillemets me font planter la requête.

Du coup, je me tourne vers qgis pour savoir si on peut faire des analyses carto 
en utilisant directement le champ "tags" contenant le hstore dans la sémiologie.



-
Tony EMERY
OpenStreetMap.fr
Ingénieur SIG
--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
---
Ce message et toutes les pièces jointes sont établis à l'intention exclusive de 
ses destinataires et sont confidentiels. L'intégrité de ce message n'étant pas 
assurée sur Internet, la SNCF ne peut être tenue responsable des altérations 
qui pourraient se produire sur son contenu. Toute publication, utilisation, 
reproduction, ou diffusion, même partielle, non autorisée préalablement par la 
SNCF, est strictement interdite. Si vous n'êtes pas le destinataire de ce 
message, merci d'en avertir immédiatement l'expéditeur et de le détruire.
---
This message and any attachments are intended solely for the addressees and are 
confidential. SNCF may not be held responsible for their contents whose 
accuracy and completeness cannot be guaranteed over the Internet. Unauthorized 
use, disclosure, distribution, copying, or any part thereof is strictly 
prohibited. If you are not the intended recipient of this message, please 
notify the sender immediately and delete it. 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] adresse mail rejetée

[Philippe Verdy]

Il y a une autre raison: lorsqu'on envoie un mail à la liste, celle-ci
tente d'identifier si l'utilisateur est abonné. Si on s'est inscrit
initialement avec une adresse NOM@DOMAINE1 et que maintenant on a changé de
fournisseur mail, et redirigé les messages, on continue de recevoir les
messages de la liste. Et normalement ces messages reçus mentionnent dans
les entêtes le chemin suivi (y compris la redirection) et le chemin devrait
être repris dans un client mail quand on répond à la liste via ce message.

Mais le serveur de la liste voit un message venant d'un fournisseur SMTP
différent de celui d'origine sur un autre DOMAINE2. Il tente de vérifier
que l'expéditeur NOM@DOMAINE1 indiqué dans la réponse se conencte bien d'un
serveur de DOMAINE1, hors la réponse vient d'un fournisseur DOMAINE2 qui ne
correspond pas à DOMAINE1. Le serveur de la liste doit alors tenter
d'aurthentifier le chemin suivi en vérifiant les entêtes MIME. Mais bien
qu'ils soient en tout point conforme aux entêtes émis par le fournisseur de
liste, et que le chemion de réponse fait le chemin inverse des domaines, il
est très pointilleux et tente de vérifier la confiance entre chacun des
sauts. Mais il échoue car les serveurs de messagerie ont souvent des
"sauts" internes via des adresses IP privées que le serveur de liste ne
peut pas vérifier et il ne semble pas aller plus loin pour repérer que le
serveur d'entrée et le serveur de sortie sont bien dans les bons domaines
et avec des IP publiques authentifiées.

Malheuseument l'authentification des domaines suit des tas de règles
différentes (secure DNS, inscriptions de champs TXT dans plusieurs formats
selon ce qu'exige Google ou d'autres, et il n'y a pas d'accord complet
entre les différents fournisseurs.

Ici il semble qu'OSM a changé son logiciel de gestion de listes et que le
nouveau ne connait pas certaines règles de vérification de domaines ou bien
a un bogue dans l'analyse des entêtes MIME. Cela aboutit à un échec, le
message de réponse reçu par la liste est accepté mais ne va pas plus loin,
il est simplement jeté, et aucun retour n'est fait à l'émetteur de la
réponse.

Le problème est qu'on ne sait généralement pas quand on répond à un message
quel chemin a été suivi. Et ces chemins changent avec le temps et aucune
garantie que le chemin suivi par les mails envoyés par la lsite et ceux de
nos réponses vers la liste suivent les mêmes domaines : ce n'est en fait
généralement plus le cas depuis longtemps et diverses techniques ont été
utilisées, pas toujours équivalentes,  mais nécessaitant chacune des
méthodes de vérification différentes. Visiblement il y a eu un retour en
arrière avec le gestionnaire de listes.

Noter aussi que cela correspond à l'entrée en vigueur de règles plus
strictes par Google pour les listes de diffusion au printemps dernier, puis
cela a suivi dans le désordre dans différentes autres sites, qui auraient
du se mettre à jour pour comprendre les nouvelles règles.

Le serveur de listes a pu également expérimenter un certain nombre de
"bounces" avec nos anciennes adresses redirigées, et pour faire le ménage
et éviter la saturation de son espace de stockage a pu décider d'éliminer
massivement les adresses en défaut pendant une période trop prolongée : ces
messages de la liste ne sont donc plus remis du tout alors qu'on y est
toujours abonné théoriquement:
le serveur de listes d'OSM oublie de faire des vérifications régulières de
nos accès en adressant un mail par mois de rappel pour gérer nos
inscriptions et revalider les chemins suivis et éviter les "bounces"
prolongés qui saturent son espace de stockage de mails en attente de
diffusion.

Quelquechose a donc bien eu lieu en mars dernier: soit l'absence d'une mise
à jour nécessaire pour pouvoir continuer à envoyer à certains fournisseurs
de messagerie et authentifier les chemins avec les nouvelles méthodes, soit
un changement de logiciel chez OSM avec un logiciel en fait moisn
performant et bogué. Gérer un serveur de diffusion de listes est compliqué,
les bons logiciels qui font ça bien ne sont pas légion, et ild fonctionnent
dans des configurations très précises des systèmes internes et frontaux du
serveur qui l'héberge: ce devrait être un serveur dédié à ça tellement
c'est "casse-gueule" (et avec des configs de caches, DNS, outils antispams
eux aussi à jour, y compris les DNSBL tiers nécessaires qui nécessitent
souvent aussi un abonnement actif pour rester à jour des règles, et aussi
joignables : un parefeu frontal mal reconfiguré peut bloquer les requêtes
DNSBL et produire alors des faux positifs et des rejets inattendus).

Dans l'immédiat il n'y a qu'une solution pour qu'OSM admette nos réponses
et nous reconnaissent : créer un second compte d'abonné aux listes avec la
nouvelle adresse mail. pour que le serveur accepte aussi bien l'ancienne
adresse mail que la nouvelle et nous reconnaisse (pour le reste cela poste
un problème car on est abonné deux fois et cela peut faire qu'on reçoive
les messages de la list

Re: [OSM-talk-fr] gestion du hstore dans qgis

[Etienne Trimaille]

Le jeu. 12 déc. 2019 à 13:57, Tony Emery via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Je n'utilise pas quickOSM car les données sont déjà dans Postgresql via
> osm2pgsql.
>

Ah, mais on ne savait pas ;-)

Ttraite le HStore dans Postgresql directement alors?
Lors de ta requête. Cela sera plus efficace que de le faire dans QGIS.

https://www.postgresql.org/docs/10/hstore.html

Peut-être faire une vue matérialisé ou des index. À voir dans ton cas
précis.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] CA Physique

[osm . sanspourriel]

Pour que tu saches sans attendre plus : je ne serai pas des vôtres.

Bonne et fructueuse réunion.

Jean-Yvon

Le 12/12/2019 à 14:23, Tony Emery via Talk-fr -
talk-fr@openstreetmap.org a écrit :
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] adresse mail rejetée

[osm . sanspourriel]

Le 12/12/2019 à 17:55, Philippe Verdy - verd...@wanadoo.fr a écrit :

sinon ré"pondre à ces messages nous fera utiliser à nouveau l'ancienne
adresse qui ne sera plus reconnue alors qu'on est pourtant bien abonné
avec la nouvelle adresse avec laquelle on répond.


Ceci est a priori un faux problème : la personne recevra un message
d'erreur et elle expédiera à la bonne adresse.

Certaines fois j'écris par erreur à talk-fr@openstreetmap.org avec mon
adresse primaire et
talk-fr@openstreetmap.org pour
que ça passe par SpamGourmet.

Du fait du message à talk-fr@openstreetmap.org, je reçois bien un
message de talk-fr-ow...@openstreetmap.org signalant le problème (car je
ne suis pas abonné).

Jean-Yvon

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

Re: [OSM-talk-fr] adresse mail rejetée

[Philippe Verdy]

Non justement, aucun message d'erreur n'est expédié, le message est perdu
directement et complètement silencieusement.

Le jeu. 12 déc. 2019 à 20:24,  a écrit :

> Le 12/12/2019 à 17:55, Philippe Verdy - verd...@wanadoo.fr a écrit :
>
> sinon ré"pondre à ces messages nous fera utiliser à nouveau l'ancienne
> adresse qui ne sera plus reconnue alors qu'on est pourtant bien abonné avec
> la nouvelle adresse avec laquelle on répond.
>
> Ceci est a priori un faux problème : la personne recevra un message
> d'erreur et elle expédiera à la bonne adresse.
>
> Certaines fois j'écris par erreur à talk-fr@openstreetmap.org avec mon
> adresse primaire et
> osm.sanspourriel.5b67531659.talk-fr#talk-fr@openstreetmap.org pour que ça
> passe par SpamGourmet.
>
> Du fait du message à talk-fr@openstreetmap.org, je reçois bien un message
> de talk-fr-ow...@openstreetmap.org signalant le problème (car je ne suis
> pas abonné).
>
> Jean-Yvon
> ___
> 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] adresse mail rejetée

[osm . sanspourriel]

J'appelle ceci un message d'erreur, même si c'est en étranger^^ :
 Message transféré 

Sujet : Re: [OSM-talk-fr] adresse mail rejetée
Date :  Thu, 12 Dec 2019 20:57:49 +
De :talk-fr-ow...@openstreetmap.org



Your message has been rejected, probably because you are not
subscribed to the mailing list and the list's policy is to prohibit
non-members from posting to it. If you think that your messages are
being rejected in error, contact the mailing list owner at
talk-fr-ow...@openstreetmap.org.


Le 12/12/2019 à 21:13, Philippe Verdy - verd...@wanadoo.fr a écrit :

Non justement, aucun message d'erreur n'est expédié, le message est
perdu directement et complètement silencieusement.

Le jeu. 12 déc. 2019 à 20:24, mailto:osm.sanspourr...@spamgourmet.com>> a écrit :

Le 12/12/2019 à 17:55, Philippe Verdy - verd...@wanadoo.fr
 a écrit :

sinon ré"pondre à ces messages nous fera utiliser à nouveau
l'ancienne adresse qui ne sera plus reconnue alors qu'on est
pourtant bien abonné avec la nouvelle adresse avec laquelle on
répond.


Ceci est a priori un faux problème : la personne recevra un
message d'erreur et elle expédiera à la bonne adresse.

Certaines fois j'écris par erreur à talk-fr@openstreetmap.org
 avec mon adresse primaire et
osm.sanspourriel.5b67531659.talk-fr#talk-fr@openstreetmap.org

pour que ça passe par SpamGourmet.

Du fait du message à talk-fr@openstreetmap.org
, je reçois bien un message de
talk-fr-ow...@openstreetmap.org
 signalant le problème
(car je ne suis pas abonné).

Jean-Yvon

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


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

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

[Vincent de Château-Thierry]

Bonsoir,

Le 11/12/2019 à 21:53, deuzeffe a écrit :

Le 11/12/2019 à 05:10, Jérôme Amagat a écrit :

Bonjour,

D’après le wiki il faut 10 caractère dans ref:FR:FANTOIR=* 
https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR

Il y a beaucoup de valeurs pour ce tag qui compte 11 caractères :
https://overpass-turbo.eu/s/OSX


D'après la description du fichier FANTOIR 
(https://www.data.gouv.fr/fr/datasets/r/7c52d813-1e98-4772-8a7a-6a01f9d30c6e 
) c'est 11. Sauf que le code direction - fiscale ? - (deuxième "champ") 
semble avoir été ràz, donc ignoré dans la version finale ?


Si quelqu'un y voit plus clair que moi...


Disons que dans OSM depuis au moins le début de BANO (mi 214) on a 
choisi de ne pas considérer ce code direction pour composer ce qu'on 
appelle le ref:FR:FANTOIR. C'est devenu "notre" convention, massivement 
appliquée depuis, et assez pratique puisqu'elle permet très simplement 
un lien avec la commune, vu que les 5 1ères positions du code 
correspondent au code INSEE communal. Je ne sais pas quel avantage / 
quelle interopérabilité nous apporterait l'inclusion du code direction 
en 3è position, je sais en revanche qu'il nous casserait bien les pieds 
à chaque tentative de rapprochement simple entre le code ref:FR:FANTOIR 
et sa commune d'appartenance. On passerait notre temps à détricoter le 
ref:FR:FANTOIR pour en virer le code direction. Un peu pénible...


vincent


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

Re: [OSM-talk-fr] adresse mail rejetée

[Philippe Verdy]

OK pour ce message, mais il y a d'autres cas où aucun message n'est envoyé
en retour, nulle part (dans aucun dossier "spam" non plus); la liste ne
fonctionne pas (et cela pas seulement de façon temporaire, les messages ne
seront jamais transmis même plusieurs jours, semaines ou mois après), comme
cela était signalé en tête de ce fil de messages. Mystème complet mais cela
a débuté précisé&ment le 12 mars dernier.

Le jeu. 12 déc. 2019 à 22:00,  a écrit :

> J'appelle ceci un message d'erreur, même si c'est en étranger^^ :
>  Message transféré 
> Sujet : Re: [OSM-talk-fr] adresse mail rejetée
> Date : Thu, 12 Dec 2019 20:57:49 +
> De : talk-fr-ow...@openstreetmap.org
>
> Your message has been rejected, probably because you are not
> subscribed to the mailing list and the list's policy is to prohibit
> non-members from posting to it. If you think that your messages are
> being rejected in error, contact the mailing list owner at
> talk-fr-ow...@openstreetmap.org.
>
>
> Le 12/12/2019 à 21:13, Philippe Verdy - verd...@wanadoo.fr a écrit :
>
> Non justement, aucun message d'erreur n'est expédié, le message est perdu
> directement et complètement silencieusement.
>
> Le jeu. 12 déc. 2019 à 20:24,  a écrit :
>
>> Le 12/12/2019 à 17:55, Philippe Verdy - verd...@wanadoo.fr a écrit :
>>
>> sinon ré"pondre à ces messages nous fera utiliser à nouveau l'ancienne
>> adresse qui ne sera plus reconnue alors qu'on est pourtant bien abonné avec
>> la nouvelle adresse avec laquelle on répond.
>>
>> Ceci est a priori un faux problème : la personne recevra un message
>> d'erreur et elle expédiera à la bonne adresse.
>>
>> Certaines fois j'écris par erreur à talk-fr@openstreetmap.org avec mon
>> adresse primaire et
>> osm.sanspourriel.5b67531659.talk-fr#talk-fr@openstreetmap.org pour que
>> ça passe par SpamGourmet.
>>
>> Du fait du message à talk-fr@openstreetmap.org, je reçois bien un
>> message de talk-fr-ow...@openstreetmap.org signalant le problème (car je
>> ne suis pas abonné).
>>
>> Jean-Yvon
>> ___
>> 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] ref:FR:FANTOIR

[Philippe Verdy]

Mais est-ce que ça marche pour Paris (un seul code commune comme 75000 ou
plusieurs, un par arrondissement 75101 à 75120) et Marseilles? Pas de
doublon indésirables? Le dédoublonnage (renumérotation éventuelle) a-t-il
déjà eu lieu dans les anciennes directions pour avoir des codes FANTOIR
uniques par code commune (y compris les "communes nouvelles" ou récemment
fusionnées en fusion simple) ?

Le jeu. 12 déc. 2019 à 22:13, Vincent de Château-Thierry 
a écrit :

> Bonsoir,
>
> Le 11/12/2019 à 21:53, deuzeffe a écrit :
> > Le 11/12/2019 à 05:10, Jérôme Amagat a écrit :
> >> Bonjour,
> >>
> >> D’après le wiki il faut 10 caractère dans ref:FR:FANTOIR=*
> >> https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR
> >> Il y a beaucoup de valeurs pour ce tag qui compte 11 caractères :
> >> https://overpass-turbo.eu/s/OSX
> >
> > D'après la description du fichier FANTOIR
> > (
> https://www.data.gouv.fr/fr/datasets/r/7c52d813-1e98-4772-8a7a-6a01f9d30c6e
> > ) c'est 11. Sauf que le code direction - fiscale ? - (deuxième "champ")
> > semble avoir été ràz, donc ignoré dans la version finale ?
> >
> > Si quelqu'un y voit plus clair que moi...
>
> Disons que dans OSM depuis au moins le début de BANO (mi 214) on a
> choisi de ne pas considérer ce code direction pour composer ce qu'on
> appelle le ref:FR:FANTOIR. C'est devenu "notre" convention, massivement
> appliquée depuis, et assez pratique puisqu'elle permet très simplement
> un lien avec la commune, vu que les 5 1ères positions du code
> correspondent au code INSEE communal. Je ne sais pas quel avantage /
> quelle interopérabilité nous apporterait l'inclusion du code direction
> en 3è position, je sais en revanche qu'il nous casserait bien les pieds
> à chaque tentative de rapprochement simple entre le code ref:FR:FANTOIR
> et sa commune d'appartenance. On passerait notre temps à détricoter le
> ref:FR:FANTOIR pour en virer le code direction. Un peu pénible...
>
> 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] ref:FR:FANTOIR

[deuzeffe]

Le Code Officiel Géographique est ton ami.

HTH

Le 12/12/2019 à 22:19, Philippe Verdy a écrit :
Mais est-ce que ça marche pour Paris (un seul code commune comme 75000 
ou plusieurs, un par arrondissement 75101 à 75120) et Marseilles? Pas de 
doublon indésirables? Le dédoublonnage (renumérotation éventuelle) 
a-t-il déjà eu lieu dans les anciennes directions pour avoir des codes 
FANTOIR uniques par code commune (y compris les "communes nouvelles" ou 
récemment fusionnées en fusion simple) ?


Le jeu. 12 déc. 2019 à 22:13, Vincent de Château-Thierry 
mailto:osm.v...@free.fr>> a écrit :


Bonsoir,

Le 11/12/2019 à 21:53, deuzeffe a écrit :
 > Le 11/12/2019 à 05:10, Jérôme Amagat a écrit :
 >> Bonjour,
 >>
 >> D’après le wiki il faut 10 caractère dans ref:FR:FANTOIR=*
 >> https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR
 >> Il y a beaucoup de valeurs pour ce tag qui compte 11 caractères :
 >> https://overpass-turbo.eu/s/OSX
 >
 > D'après la description du fichier FANTOIR
 >
(https://www.data.gouv.fr/fr/datasets/r/7c52d813-1e98-4772-8a7a-6a01f9d30c6e

 > ) c'est 11. Sauf que le code direction - fiscale ? - (deuxième
"champ")
 > semble avoir été ràz, donc ignoré dans la version finale ?
 >
 > Si quelqu'un y voit plus clair que moi...

Disons que dans OSM depuis au moins le début de BANO (mi 214) on a
choisi de ne pas considérer ce code direction pour composer ce qu'on
appelle le ref:FR:FANTOIR. C'est devenu "notre" convention, massivement
appliquée depuis, et assez pratique puisqu'elle permet très simplement
un lien avec la commune, vu que les 5 1ères positions du code
correspondent au code INSEE communal. Je ne sais pas quel avantage /
quelle interopérabilité nous apporterait l'inclusion du code direction
en 3è position, je sais en revanche qu'il nous casserait bien les pieds
à chaque tentative de rapprochement simple entre le code ref:FR:FANTOIR
et sa commune d'appartenance. On passerait notre temps à détricoter le
ref:FR:FANTOIR pour en virer le code direction. Un peu pénible...

vincent


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


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



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

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

[deuzeffe]

Le 12/12/2019 à 22:12, Vincent de Château-Thierry a écrit :

Bonsoir,


Pareil,

D'après la description du fichier FANTOIR 
(https://www.data.gouv.fr/fr/datasets/r/7c52d813-1e98-4772-8a7a-6a01f9d30c6e 
) c'est 11. Sauf que le code direction - fiscale ? - (deuxième 
"champ") semble avoir été ràz, donc ignoré dans la version finale ?


Si quelqu'un y voit plus clair que moi...


Disons que dans OSM depuis au moins le début de BANO (mi 214) on a 
choisi de ne pas considérer ce code direction pour composer ce qu'on 
appelle le ref:FR:FANTOIR. C'est devenu "notre" convention, massivement 
appliquée depuis, et assez pratique puisqu'elle permet très simplement 
un lien avec la commune, vu que les 5 1ères positions du code 
correspondent au code INSEE communal. Je ne sais pas quel avantage / 
quelle interopérabilité nous apporterait l'inclusion du code direction 
en 3è position, je sais en revanche qu'il nous casserait bien les pieds 
à chaque tentative de rapprochement simple entre le code ref:FR:FANTOIR 
et sa commune d'appartenance. On passerait notre temps à détricoter le 
ref:FR:FANTOIR pour en virer le code direction. Un peu pénible...


Ah bin voilà, c'est parfait comme ça. Merci beaucoup !

Merci aussi pour l'icône "Télécharger en csv" ;)

--
deuzeffe - me coucherai moins ignorante.



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

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

[Philippe Verdy]

Le COG ne répond pas à ça concernant le FANTOIR, et les codes communes ne
sont pas si uniques que ça (il y a tout un historique lié aux
fusions/défusions, et réaménagement de frontières communales ou
réaffectations de voies limitrophes) ! Le définition des tues est une
compétence communale, mais comme les communes changent aussi, ce n'est pas
en passant à l'échelle départementale avec le COG actuel qu'on résoud les
ambiguités.
D'aillerus le code INSEE à 5 chiffres des communes n'est qu'une
simplification, un instantané valable à une année donnée et si on n'indique
pas le millésime, il n'indique pas de commune précise (contrairement au
code SIRET de la commune, qui change à chaque réaménagement légal, avec des
limites toutefois en cas d'échanges parcellaires d'une commune à l'autre
sans changer les entités légales).
Ensuite pour la fiscalité locale applicable et le cadastre ça devient vite
compliqu (y compris avec des communes qui ont changé de département à
l'occasion d'une fusion en commune nouvelle, les communes déléguées
conservant encore le code de leur ancien département dont elle ne font plus
partie!)
Le FANTOIR (ou RIVOLI très proche) obéit à une autre logique de
classification, où la commune n'est qu'un indicateur à une date donnée (non
précisée par le code lui-même).
De plus ce n'erst pas parce qu'une comune a cessé d'être de plein exercice
que son code disparit tout de suite, étant donné que l'INSEE doit conserver
les rapprochements statistiques d'une année sur l'autre au moins pendant
une période assez longue pour les usages réglementaires et les recours
légaux possibles : les codes historiques persistent longtemps dans les
fichiers et conservent leur validité, même si ce ne sont plus les codes
premiers pour les données concernant les nouveaux exercices: ils restent
donc réservés et normalement pas réaffectables avant très longtemps.
Le COG lui-même doit donc être millésimé en tant que référence, il n'est
pas unique.

Le jeu. 12 déc. 2019 à 22:25, deuzeffe  a écrit :

> Le Code Officiel Géographique est ton ami.
>
> HTH
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[deuzeffe]

Ne me fais pas croire que tu ne sais pas trouver les pages qui décrivent 
très précisément le COG et tous les champs. C'est sûr que c'est moins 
facile de trouver le dernier COG du printemps-été 2019 avec toutes la 
liste de toutes les communes et leur identifiant unique que de peigner 
la girafe, mais quand même.


Bref.

Le 12/12/2019 à 22:49, Philippe Verdy a écrit :
Le COG ne répond pas à ça concernant le FANTOIR, et les codes communes 
ne sont pas si uniques que ça (il y a tout un historique lié aux 
fusions/défusions, et réaménagement de frontières communales ou 
réaffectations de voies limitrophes) ! Le définition des tues est une 
compétence communale, mais comme les communes changent aussi, ce n'est 
pas en passant à l'échelle départementale avec le COG actuel qu'on 
résoud les ambiguités.
D'aillerus le code INSEE à 5 chiffres des communes n'est qu'une 
simplification, un instantané valable à une année donnée et si on 
n'indique pas le millésime, il n'indique pas de commune précise 
(contrairement au code SIRET de la commune, qui change à chaque 
réaménagement légal, avec des limites toutefois en cas d'échanges 
parcellaires d'une commune à l'autre sans changer les entités légales).
Ensuite pour la fiscalité locale applicable et le cadastre ça devient 
vite compliqu (y compris avec des communes qui ont changé de département 
à l'occasion d'une fusion en commune nouvelle, les communes déléguées 
conservant encore le code de leur ancien département dont elle ne font 
plus partie!)
Le FANTOIR (ou RIVOLI très proche) obéit à une autre logique de 
classification, où la commune n'est qu'un indicateur à une date donnée 
(non précisée par le code lui-même).
De plus ce n'erst pas parce qu'une comune a cessé d'être de plein 
exercice que son code disparit tout de suite, étant donné que l'INSEE 
doit conserver les rapprochements statistiques d'une année sur l'autre 
au moins pendant une période assez longue pour les usages réglementaires 
et les recours légaux possibles : les codes historiques persistent 
longtemps dans les fichiers et conservent leur validité, même si ce ne 
sont plus les codes premiers pour les données concernant les nouveaux 
exercices: ils restent donc réservés et normalement pas réaffectables 
avant très longtemps.
Le COG lui-même doit donc être millésimé en tant que référence, il n'est 
pas unique.


Le jeu. 12 déc. 2019 à 22:25, deuzeffe > a écrit :


Le Code Officiel Géographique est ton ami.

HTH


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



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

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

[Jérôme Amagat]

Il y a plusieurs ref:FR:FANTOIR avec un code direction différent de 0 en
région parisienne, il y en a aussi à Dunkerque et autour avec le code
direction 1 . On les enlève ?

J'ai corrigé pas mal de ref:FR:FANTOIR, sur toute la France, beaucoup de
code direction 0 et aussi des fautes de frappe. Mais il y en reste encore.
Si ça tente des gens de continuer les corrections, on trouve les codes de
11 caractères comme ça : https://overpass-turbo.eu/s/OWl

Pour tous les code qui pose problème car pas 10 caractères :
https://overpass-turbo.eu/s/OWn (il y a aussi les cas de bon code séparé
par un ; qui ne sont pas des erreurs)
Le gros des erreurs (les 3/4 environ) se trouvent dans l'agglomération
nantaise, se ne sont pas les code fantoir dans ref:FR:FANTOIR mais le code
rivoli donc il fait entre 1 et 4 caractères (les 0 du début sont absent),
on pourrait ajouter le code insee de la commune avant le code déjà présent
mais on aurait que les 9 1er caractères et il manquerait le dernier :(
Il y a aussi un gros groupe de ref:FR:FANTOIR trop long sur des adresses
car il y a après le code : "-le numéro" donc pour faire ça comme il faut il
faudrait avec ces numéros créer les relations associateStreet pour y placer
le fantoir.
Après ces 2 gros groupes, il y a d'autres erreurs un peu partout sur toute
la france...

Avis aux amateurs, si certains veulent faire des corrections...
Sinon on supprime ces codes faux...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Philippe Verdy]

Ne me fais pas croire que le FANTOIR est décrit dans le COG, même en 2019.
Là c'est toi qui confond, ce n'est même pas la même source (et il n'y a pas
de synchro directe entre les deux, toujours des décalages)!

COG: source INSEE (https://www.insee.fr/fr/information/2016807)
FANTOIR: source DGFIP (
https://www.data.gouv.fr/fr/datasets/fichier-fantoir-des-voies-et-lieux-dits/
)

Je sais faire la différence merci.

Le FANTOIR utilise des codes communes complets à 6 chiffres (3 pour le
département métropole+direction ou pour les DOM; puis 3 pour la commune
même dans les DOM, mais pas synchronisé immédiatement et partour avec le
COG du même millésime), après le code RIVOLI du type de voie (1 lettre), et
avant le numéro de voie sur 4 chiffres (unique par code RIVOLI plus code
commune à 6 chiffres); le dernier caractère est une lettre-clé calculée sur
les 11 caractères précédents (code RIVOLI du type de voie,
département+direction+commune, numéro de voie)

Bref les codes commune complets du COG et ceux du FANTOIR sont différents
en forme et en usage même si à l'origine le FANTOIR a basé ses codes
commune sur le code INSEE des commune issu du COG. Le COG n'a aucun "code
direction" et réduit les codes communes de 3 à 2 chiffres dans les DOM en
ajoutant un chiffre au département.

On peut se passer de la lettre clé finale (après la lettre RIVOLI et les
6+4 chiffres) dans la base (elle n'ajoute aucune précision, c'est juste une
vérification).

Si on réduit le code commune complet de 6 chiffres à 5 chiffres, la lettre
clé finale n'est plus correcte, mais quoi qu'il en soit elle n'est toujours
pas identifiante mais permet de déduire le chiffre manquant dans le code
commune complet à 6 chiffres).

Des corrections semi-automatiques sont possibles selon la forme trouvée:
- 4 chiffres plus 1 lettre : il manque la commune (requête géographique
semi-automatique); la lettre clé finale est présente, on peut en déduire le
code RIVOLI initial du type de voie grace à la lettre-clé finale après
avoir déduit la commune, mais problème dans les départements ayant
plusieurs directions, car alors on aura plusieurs codes RIVOLI de type de
voie déduits et on ne peut pas choisir (correction donc manuelle, le code
direction n'est pas forcément 0 à Paris, dans le Nord, dans le Rhône ou les
Bouches-du-Rhône, mais les directions sont des secteurs géographiques dans
un département, on s'en sort donc).
- 4 chiffres: on ne peut rien faire, il manque la lettre code RIVOLI
initiale pour le rendre unique, cas d'erreur.
- 1 lettre plus 4 chiffres : il manque les 6 chiffres du code
département+direction+commune FANTOIR, puis la lettre-clé calculable. On
peut cherche la commune par requête géographique (à confirmer, attention
aux pièges des communes fusionnées, il peut y avoir encore plusieurs codes
possibles car pas de synchro immédiate du FANTOIR avec le COG).
- 1 lettre plus 10 chiffres : il manque juste la lettre clé finale
calculable automatiquement.


Le jeu. 12 déc. 2019 à 22:56, deuzeffe  a écrit :

> Ne me fais pas croire que tu ne sais pas trouver les pages qui décrivent
> très précisément le COG et tous les champs. C'est sûr que c'est moins
> facile de trouver le dernier COG du printemps-été 2019 avec toutes la
> liste de toutes les communes et leur identifiant unique que de peigner
> la girafe, mais quand même.
>
> Bref.
>
> Le 12/12/2019 à 22:49, Philippe Verdy a écrit :
> > Le COG ne répond pas à ça concernant le FANTOIR, et les codes communes
> > ne sont pas si uniques que ça (il y a tout un historique lié aux
> > fusions/défusions, et réaménagement de frontières communales ou
> > réaffectations de voies limitrophes) ! Le définition des tues est une
> > compétence communale, mais comme les communes changent aussi, ce n'est
> > pas en passant à l'échelle départementale avec le COG actuel qu'on
> > résoud les ambiguités.
> > D'aillerus le code INSEE à 5 chiffres des communes n'est qu'une
> > simplification, un instantané valable à une année donnée et si on
> > n'indique pas le millésime, il n'indique pas de commune précise
> > (contrairement au code SIRET de la commune, qui change à chaque
> > réaménagement légal, avec des limites toutefois en cas d'échanges
> > parcellaires d'une commune à l'autre sans changer les entités légales).
> > Ensuite pour la fiscalité locale applicable et le cadastre ça devient
> > vite compliqu (y compris avec des communes qui ont changé de département
> > à l'occasion d'une fusion en commune nouvelle, les communes déléguées
> > conservant encore le code de leur ancien département dont elle ne font
> > plus partie!)
> > Le FANTOIR (ou RIVOLI très proche) obéit à une autre logique de
> > classification, où la commune n'est qu'un indicateur à une date donnée
> > (non précisée par le code lui-même).
> > De plus ce n'erst pas parce qu'une comune a cessé d'être de plein
> > exercice que son code disparit tout de suite, étant donné que l'INSEE
> > doit conserver les rapprochements statistiques d'une année sur l'aut

Re: [OSM-talk-fr] Appel à l'aide à propos d'une série de premières contributions assez catastrophiques

[Yves P.]

Bonjour,

J’ai (re)lus l’ensemble de ce fil très intéressant.

> Le 30 nov. 2019 à 12:21, Cédric Frayssinet  a écrit :
> 
> Par exemple ce mini-projet sur le manuel Delagrave :
> https://www.lib-manuels.fr/textbook/5d10efe207571612cb53d27c?demo=true&page=99
>  
> 

«  Les cartographes bénévoles […] utilisent […] les récepteurs GPS » 
Le commun des mortels « croit » que la position GPS est exacte.

On pourrait rajouter en « CAPACITÉS TRANSVERSALES », apprendre à être critique… 
recouper les informations… vérifier la cohérence de son outil…
A formuler de façon plus adaptée et concise, bien sûr. 

Dans « ACTIVITÉS » en 1. (voir 0.), contacter la communauté locale au préalable 
pour contribuer au besoins locaux…

« Compléter la carte de votre quartier,[…] en ajoutant des […] graffitis »
Quel est la définition d’un graffiti pour un prof, un contributeur OSM avertit, 
un ado ?
Pas évident que tout le monde soit d’accord sur la définition, alors pour les 
tags on en parle même pas 😅

Un lien pour chaque « thème » vers une page de wiki (adaptée aux SNT si besoin) 
serait utile.
Par exemple https://wiki.openstreetmap.org/wiki/Street-art 
 pour les graffitis 😀

J’ai lu aussi le courrier 
 de Cédric.
StreetComplete peut-être très bien, mais en fonction des quêtes, produire de la 
m…

Bonne journée,

—
Yves

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