Re: [OSM-talk-fr] Re: Espé devient Inspé

[Christian Quest]

C'est ce que fait le rendu FR ;)

Si il n'y a plus de place pour le name, short_name est utilisé en plan B.

Exemple avec la Bibliothèque Nationale de France:
https://demo.addok.xyz/#16/48.8327/2.3765


Le mar. 29 oct. 2019 à 20:32, Adrien André via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Le 19-10-29 à 15 h 20, Yves P. a écrit :
> > name est trop long à afficher sur le rendu. C’est illisible, prend
> > trop de place.
> Ne serait-ce justement pas le travail du code de rendu
> d'afficher short_name plutôt que name dans certaines conditions ?
>
>
> ___
> 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] bridge=simple_brunnel

[Christian Quest]

C'est le côté itératif d'OSM ;)

Un noeud commun taggué c'est mieux que rien et moins bien que des
géométries bien séparées...


"Certes, mais très souvent l'imagerie aérienne permet de le voir."

Nous sommes chanceux en France d'avoir accès à une imagerie de qualité, ce
qui est quand même rare sur le monde entier. N'oublions pas non plus qu'OSM
est à des degrés de maturité et d'accès à des sources très variés et qu'il
faut donc prendre en compte aussi cela dans la façon de décrire "au mieux"
avec ce qu'on a à disposition.


Le mar. 29 oct. 2019 à 23:23,  a écrit :

> Le 29/10/2019 22:53, pepilepi...@ovh.fr a écrit :
> > Le 29/10/2019 à 18:14, Yves P. a écrit :
> >
> >>> Du coup, vous êtes pour accepter tunnel=culvert sur des nœuds ou
> >>> pas ?-
> >> Oui
> >
> > +1
>
> Non ; c'est une question de topologie des objets.
>
> S'ils partagent géométriquement une zone commune (assimilable à un
> point), on met un point en commun et un tag dessus.
> C'est le cas d'un gué : il existe physiquement une zone qu'on peut
> passer à pied (en se mouillant les chaussures éventuellement), et où
> l'eau passe aussi.
>
> Pour les ruisseaux busés, les deux flux sont bien séparés. La buse
> canalise l'eau, pas le passage humain/véhicules, donc c'est inapproprié
> de mettre un tag tunnel sur la voie.
>
> Pour moi "brunnel" est un tag sale mais temporaire, acceptable en tant
> que "on n'a pas assez de données pour trancher".
> tunnel=culvert est un tag propre et définitif, il est réservé au passage
> de l'eau, il ne doit pas se trouver sur un highway.
>
> ___
> 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] Re: Espé devient Inspé

[Yves P.]

> C'est ce que fait le rendu FR ;)
> 
> Si il n'y a plus de place pour le name, short_name est utilisé en plan B.
Bravo 😀

On fait comment pour faire adopter ceci sur les principaux rendus ?

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

Re: [OSM-talk-fr] Espé devient Inspé

[marc marc]

Le 30.10.19 à 09:14, Yves P. a écrit :
> 
>> C'est ce que fait le rendu FR ;)
>>
>> Si il n'y a plus de place pour le name, short_name est utilisé en plan B.

> On fait comment pour faire adopter ceci sur les principaux rendus ?

on regarde s'il y a déjà un ticket dans le github osm-carto
et si c'est pas le cas, on en ouvre un, en y expliquant l'idée
et on peux y référencer l'url d'un exemple sur le rendu fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] bridge=simple_brunnel

[Yves P.]

> Christian :
> Un noeud commun taggué c'est mieux que rien et moins bien que des géométries 
> bien séparées…
+1

> Guillaume :
> Pour les ruisseaux busés, les deux flux sont bien séparés. La buse canalise 
> l'eau, pas le passage humain/véhicules,
On est d’accord

> donc c'est inapproprié de mettre un tag tunnel sur la voie.
tunnel: tu voulais dire brunnel ?

La « carte » est — et reste — une interprétation / modélisation de la réalité.
Il faut trouver un compromis entre exactitude (qui sera impossible : toute 
carte est fausse), lisibilité, facilité de mise à jour.

C’est beaucoup plus simple de mettre un noeud avec un tag commun à la route et 
au ruisseau…
Le jour où on a une meilleure orthophoto, on peut le déplacer facilement…
Et dès que la résolution et suffisante (ou qu’on peut aller voir sur le 
terrain), on trace «  fidèlement » l’intersection, avec les bons attributs.

En attendant, il n’existe pas — à ma connaissance de logiciel — de routage qui 
va te proposer de suivre le ruisseau, ou d’utilisateur qui va suivre son GPS 
docilement 😁

> Pour moi "brunnel" est un tag sale mais temporaire, acceptable en tant que 
> "on n'a pas assez de données pour trancher".
Oui pour le temporaire. Sale me parait un peu fort.

On pourrait mettre « yes » mais ça prête à confusion.
Ou mettre « unknown » qui serait plus clair ? On voit tout de suite qu’il faut 
aller chercher l’info sur le terrain…

Ou ne pas mettre de noeud / chemin « bridge »  sur la route ?
En pratique, il n’y a presque jamais de parapet, et parfois il faut descendre 
10 m au fond du ravin pour voir si on a un tunnel ou des tuyaux pour le passage 
de l’eau.
Quand on a un tunnel qui passe sous une route, on ne met pas bridge=yes sur la 
route du dessus, non ?

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

Re: [OSM-talk-fr] Espé devient Inspé

[Yves P.]

>> On fait comment pour faire adopter ceci sur les principaux rendus ?
> 
> on regarde s'il y a déjà un ticket dans le github osm-carto
> et si c'est pas le cas, on en ouvre un, en y expliquant l'idée
> et on peux y référencer l'url d'un exemple sur le rendu fr

Ma remarque était ironique (désolé, un émoticône s’imposait).

Je me suis usé à faire des tickets, avec des réponses bornées et décourageantes 
des admins.
Si je le fait tout seul dans mon coin, c’est quasiment peine perdu.

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

Re: [OSM-talk-fr] bridge=simple_brunnel

[allegre . guillaume]

Le 30/10/2019 09:35, Yves P. a écrit :

Christian :



Un noeud commun taggué c'est mieux que rien et moins bien que des
géométries bien séparées…

 +1


Guillaume :



Pour les ruisseaux busés, les deux flux sont bien séparés. La
buse canalise l'eau, pas le passage humain/véhicules,

 On est d’accord


donc c'est inapproprié de mettre un tag tunnel sur la voie.

 tunnel: tu voulais dire brunnel ?


Non.
Je veux dire que je veux garder un truc clair :
On ne met pas tunnel=* sur un noeud, on garde ce tag pour des tronçons, 
comme le wiki l'indique.


Si on veut mettre un noeud "incertain", on a "brunnel" faute de mieux.
(mais si c'est pour tagguer à l'économie alors qu'on sait que c'est un 
tunnel=culvert c'est moche).




En attendant, il n’existe pas — à ma connaissance de logiciel —
de routage qui va te proposer de suivre le ruisseau, ou
d’utilisateur qui va suivre son GPS docilement 😁


C'est pas le problème : s'il y a un truc qui passe au-dessus de l'autre, 
ils n'ont pas à partager un noeud àmha.

Un gué, oui. Une buse, non.




Pour moi "brunnel" est un tag sale mais temporaire, acceptable en
tant que "on n'a pas assez de données pour trancher".

 Oui pour le temporaire. Sale me parait un peu fort.


Alors "temporaire et perfectible".



On pourrait mettre « yes » mais ça prête à confusion.
Ou mettre « unknown » qui serait plus clair ? On voit tout de suite
qu’il faut aller chercher l’info sur le terrain…

Ou ne pas mettre de noeud / chemin « bridge »  sur la route ?
En pratique, il n’y a presque jamais de parapet, et parfois il faut
descendre 10 m au fond du ravin pour voir si on a un tunnel ou des
tuyaux pour le passage de l’eau.


Là tu te places sur le terrain.
Dans ce cas tunnel=yes sur le cours d'eau OU bridge=yes sur la voie, 
mais pas sur un point.


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

Re: [OSM-talk-fr] Projet OpenMultiMaps

[Cyrille37 OSM]

Très chouette application, merci!

Cyrille37.

Le 29/10/2019 à 18:43, Cédric Frayssinet a écrit :


Bonjour à tous,

Dernier message pour cette application qui commence à arriver à 
maturité. La version 1.10 vient de sortir sur F-Droid : 
https://f-droid.org/packages/app.fedilab.openmaps/


Depuis la dernière fois, nous avons ajouté de nombreuses cartes :

  * BenMaps, permet d'avoir le trafic et une vue aérienne
  * QwantMaps
  * OpenRailWay
  * OsmHydrant

Les cartes Occitan et Basque sont en accès direct sans passer par un 
menu sur la carte.


Dans la prochaine version sera intégrée une page 'à propos' avec tous 
les noms des projets, les URL, les mainteneurs, les liens vers les 
donations... en espérant que quelques contributeurs s'intéressent à 
des projets méconnus.


Dernière info, l'application s'appelle dorénavant *OpenMultiMaps* et 
est disponible en anglais, français, basque, un peu de catalan, 
neerlandais, allemand, hongrois, occitan, portugais, espagnol et suédois.


Cédric

PS : N'hésitez pas à remonter des problèmes ou des évolutions ici : 
https://framagit.org/tom79/openmaps/



Le 10/10/2019 à 18:09, Cédric Frayssinet a écrit :



Bonjour à tous,

L'application est dorénavant disponible sur le store F-Droid : 
https://f-droid.org/packages/app.fedilab.openmaps/


Elle est déjà traduite en 5 langues, dont le français.

N'hésitez pas à proposer des améliorations sur le dépôt : 
https://framagit.org/tom79/openmaps/issues . J'essaierai de qualifier 
les demandes sachant que Thomas n'est pas du tout expert OSM, il se 
contente de coder et il le fait plutôt bien et vite :)


A noter que le nom risque de changer car OpenMaps est visiblement 
plutôt beaucoup pris sur internet... Faudrait pas avoir un procès 
pour une histoire de nom :)


Cédric

Le 06/10/2019 à 15:27, Cédric Frayssinet a écrit :


Bonjour,

Et merci pour vos retours. Je n'ai pas forcément pensé immédiatement 
l'application comme outils de contributions mais plutôt un outil à 
avoir sur soi pour switcher facilement entre les services éparpillés 
sur le web.


On peut imaginer le scénario suivant (purement fictif, hein ^^) : Je 
veux aller manger dans un restau végétarien au centre d'une petite 
ville de province.


- je lance l'application et OpenRouteService pour trouver le trajet 
adapté,

- je switche sur OpenfuelMap pour faire le plein moins cher,
- je switche sur FreeParking pour trouver un parking gratuit,
- je switche sur OpenVegeMap et avant, je peux avoir basculé sur 
OpenBeerMap pour trouver le bar avec ma bière préféré :)


Bref, l'idée est une application simple et je trouve que 
l'application s'y prête mieux qu'un navigateur sur mobile.
De plus, je suis de plus en plus surpris par l'usage des smartphones 
des gens 'normaux'. La plupart se contente de recherches dans le 
champ Google pour afficher le navigateur, ils n'ont pas l'usage des 
marque-pages, historique ou raccourcis sur le bureau du smartphone.


Concernant la contribution, je l'ai rajouté après car il m'arrive 
souvent de lancer la navigateur pour avoir le rendu osm.org afin de 
savoir si certains POI que je croise sont déjà dans la base. C'est 
la contribution avec OsmAnd qui me rend méfiant. En ajoutant, 
OpenAdvert ou MapContrib, cela pourrait être pratique de tout avoir 
sous la main.


Cédric

Le 06/10/2019 à 14:46, Stéphane Péneau a écrit :

Question peut-être idiote :
Pourquoi une appli et pas un site web ?

Stf

Le 06/10/2019 à 14:03, PanierAvide a écrit :

Bonjour Cédric,

Content de découvrir cette application, ça me semble très 
prometteur pour faire la promotion de la diversité des données 
d'OSM. Avec quelques fonctionnalités en plus (liens vers les 
applis mobiles, ajout de notes ?) ça pourrait même devenir un bon 
couteau suisse de contribution ;-)


Cordialement,

Adrien P.

Le 06/10/2019 à 10:43, Cédric Frayssinet a écrit :

Bonjour à tous,

Quand je suis en formation SNT, pour présenter OpenStreetMap, j'ai
tendance à afficher quelques cartes thématiques pour montrer la 
richesse
de l'éco-système OpenStreetMap. Et puis, jeudi, lors d'une 
formation, je
me suis dit que ce serait pas mal d'avoir une appli qui me 
recense ces

cartes.

J'en ai parlé à Tom79, le talentueux développeur de Fedilab 
(application
pour Mastodon, PeerTube, Pleroma, PixelFed...) qui m'a codé cela 
hier.


L'application OpenMaps est donc née et elle propose un unique bouton
menu qui permet de switcher très rapidement sur les différentes 
cartes

basées sur OSM, classées par catégories.

J'ai donc la toute première version à vous soumettre, l'apk est 
sur la

page du projet ici : https://framagit.org/tom79/openmaps

Dites-moi ce que vous en pensez :)

Bon dimanche !

Cédric

PS : il y a un bug sur MapContrib, je ne sais pas bien pourquoi...





--

Sur Mastodon : @bristow...@framapiaf.org 



Promouvoir et soutenir le logiciel libre 


___
Talk-fr mailing list
Talk-fr@

Re: [OSM-talk-fr] bridge=simple_brunnel

[osm . sanspourriel]

Le 29/10/2019 à 23:22, allegre.guilla...@free.fr a écrit :


Du coup, vous êtes pour accepter tunnel=culvert sur des nœuds ou
pas ?-

Oui


+1


Non ; c'est une question de topologie des objets.

S'ils partagent géométriquement une zone commune (assimilable à un
point), on met un point en commun et un tag dessus.
C'est le cas d'un gué : il existe physiquement une zone qu'on peut
passer à pied (en se mouillant les chaussures éventuellement), et où
l'eau passe aussi.

Pour les ruisseaux busés, les deux flux sont bien séparés. La buse
canalise l'eau, pas le passage humain/véhicules, donc c'est
inapproprié de mettre un tag tunnel sur la voie.


J'avoue ne pas comprendre cette "logique" : dans les deux cas la largeur
de la route traversée est la même. Et assimilable à un point puisqu'on a
modélisé le réseau routier en linéaire.

Pour la longueur traversée, elle est plus petite quand le ruisseau est
busé que quand il peut s'étaler sur la route.

Et là tu dis :
large = représentation ponctuelle possible
étroit = représentation linéaire obligatoire (mais dans l'autre sens qui
n'a pourtant pas changé).

Comme tu dis il y a un problème de topologie... mais dans ta logique !

J'ai l'impression que tu fais la différence entre frontière floue (gué
le long de la route) et nette (route, busage). Avec cette logique tu
devrais refuser de taguer les routes en filaire puisque leur largeur est
nette.

Ton argument tient peut-être... mais je ne vois pas comment^^.

Jean-Yvon

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

Re: [OSM-talk-fr] bridge=simple_brunnel

[Nicolas Moyroud]

S'ils partagent géométriquement une zone commune (assimilable à un 
point), on met un point en commun et un tag dessus.
C'est le cas d'un gué : il existe physiquement une zone qu'on peut 
passer à pied (en se mouillant les chaussures éventuellement), et où 
l'eau passe aussi.


Pour les ruisseaux busés, les deux flux sont bien séparés. La buse 
canalise l'eau, pas le passage humain/véhicules, donc c'est 
inapproprié de mettre un tag tunnel sur la voie. 


J'avoue ne pas comprendre cette "logique" : dans les deux cas la 
largeur de la route traversée est la même. Et assimilable à un point 
puisqu'on a modélisé le réseau routier en linéaire.


Pour la longueur traversée, elle est plus petite quand le ruisseau est 
busé que quand il peut s'étaler sur la route.


Et là tu dis :
large = représentation ponctuelle possible
étroit = représentation linéaire obligatoire (mais dans l'autre sens 
qui n'a pourtant pas changé).


Comme tu dis il y a un problème de topologie... mais dans ta logique !

J'ai l'impression que tu fais la différence entre frontière floue (gué 
le long de la route) et nette (route, busage). Avec cette logique tu 
devrais refuser de taguer les routes en filaire puisque leur largeur 
est nette.


Ton argument tient peut-être... mais je ne vois pas comment^^.

Je ne vois pas le rapport qu'il y a avec large / étroit. Dans le cas du 
gué les deux objets physiques routes / rivières passent au même niveau 
et en suivant l'un on passe forcément par l'autre. Dans le cas du 
ruisseau busé il passe en-dessous de la route et on n'est pas censé 
mettre les pieds dans l'eau quand on emprunte la route. Donc aucune 
raison topologique de mettre un point commun entre les deux. Je rajoute 
d'ailleurs systématiquement layer=-1 sur le tronçon tunnel=culvert pour 
bien indiquer qu'il est en-dessous.


Nicolas



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

Re: [OSM-talk-fr] Espé devient Inspé

[osm . sanspourriel]

Le 29/10/2019 à 20:52, Yves P. - yves.prat...@gmail.com a écrit :


mais évitons de tager pour le rendu en rentrant des données erronées

C’est, me semble-t-il, une question d’usage. Dans tout les cas ça
s’affiche et on retrouve l’objet en fonction de ses noms.

Dans le même genre, on trouve MDPH et Maison départementale des
personnes handicapées.


Tu en as oublié un à rondelles : MDA 56 (Maison départementale de
l'autonomie Morbihan), voir
https://www.morbihan.fr/mdph/vos-formulaires-et-demandes-aupres-de-la-mda/.

Ceci dit, la question est de savoir si on utilise usuellement les
abréviations ou pas.

Local CFDT ou ou local du syndicat de la Confédération française
démocratique du travail ? Tu vois Donat, j'ai tenu compte de ta
remarque. Mais du coup la probabilité de comprendre qu'il s'agit de la
CFDT faiblit à mon avis.

Je ne crois pas qu'on attende autre chose que CFDT sur une carte.
Et je pense que les panneaux indiqueront INSPÉ. A-t-on des locaux
pouvant observer la pratique sur le terrain ?

INSPÉ et non INSPÉ de Brest puisqu'on est à Brest.

Par contre INSPÉ de Bretagne à Rennes puisque c'est à la fois le siège
et le site de formation ?

Ceci dit il y a aussi une alternative : mettre les noms en long et
laisser le moteur de rendu raccourcir automatiquement.

C'est ce que fait le rendu FR pour les types de voies dans les noms des
chemins (Avenue, Boulevard...) tout comme il utilise le short_name.

Sinon entre les sites et le siège académique, n'est-ce pas un office=
qui doit distinguer le siège des autres ?

Jean-Yvon

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

Re: [OSM-talk-fr] Re: Espé devient Inspé

[Christian Quest]

Pour le rendu osm.org, le mieux c'est je pense d'ouvrir une issue pour
discuter l'idée, puis de proposer une PR avec la modif dans la feuille de
style en reprenant ce que j'ai fait comme base.

Le mer. 30 oct. 2019 à 09:16, Yves P.  a écrit :

>
> C'est ce que fait le rendu FR ;)
>
> Si il n'y a plus de place pour le name, short_name est utilisé en plan B.
>
> Bravo 😀
>
> On fait comment pour faire adopter ceci sur les principaux rendus ?
>
> —
> Yves
> ___
> 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] bridge=simple_brunnel

[ades]

> Je ne vois pas le rapport qu'il y a avec large / étroit. Dans le cas du gué 
> les deux objets physiques routes / rivières passent au même niveau et en 
> suivant l'un on passe forcément par l'autre. Dans le cas du ruisseau busé il 
> passe en-dessous de la route et on n'est pas censé mettre les pieds dans 
> l'eau quand on emprunte la route. Donc aucune raison topologique de mettre un 
> point commun entre les deux. Je rajoute d'ailleurs systématiquement layer=-1 
> sur le tronçon tunnel=culvert pour bien indiquer qu'il est en-dessous.
> 
> Nicolas

+1
C’est l’eau qui passe en dessous, pas la route qui passe au dessus (si on 
considère la route au niveau 0 ) donc ne pas tagger la route ni par un point ni 
par autre chose (…brunnel) si on peut utiliser ‘culvert’ pour un point, 
pourquoi pas, mais sur le cour d’eau exclusivement avec le tag -1.
Maintenant dans le cas d’une « levée » (tag ‘embankement’) je crois que ça 
reste ‘culvert’ sur le cours d’eau si c’est une buse unique de petit diamètre 
(moins de 1m) pour un petit cour d’eau (‘ditch' en gnl) ; mais que si on a 6 
buses de diamètre d’env. 6m ça devient un pont. D’ailleurs sont appelés comme 
ça par les ddt (ex dde) dans les inventaires de ponts.


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

Re: [OSM-talk-fr] Espé devient Inspé

[Adrien André via Talk-fr]

Le 19-10-30 à 04 h 16, marc marc a écrit :

C'est ce que fait le rendu FR;)

Si il n'y a plus de place pour le name, short_name est utilisé en plan B.

On fait comment pour faire adopter ceci sur les principaux rendus ?

on regarde s'il y a déjà un ticket dans le github osm-carto


Celui-ci est similaire :

https://github.com/gravitystorm/openstreetmap-carto/issues/3569

--
Adrien

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

[OSM-talk-fr] Faire des demandes d'ouverture de données -> madada.fr

[Vincent Bergeot]

Bonjour,

je me permets de relayer ici cette information qui concerne les demandes 
d'accès aux documents administratifs, dont certaines données 
cartographiques peuvent faire parties !!


" Nous souhaitons vous informer du lancement du site https://madada.fr, 
*un service en ligne pour simplifier les demandes d'accès aux documents 
administratifs.*


Porté par l'association Open Knowledge France, avec le soutien de 
l’association ouvre-boîte et du réseau européen Access Info, l'objectif 
de la plate-forme est *d'accompagner*les demandeu.r.se.s dans leurs 
démarches et de *renforcer la visibilité*de leurs actions individuelles.


Elle est propulsée par un logiciel open source conçu par l'ONG MySociety 
_Alavateli _et permet, à l'instar 
de ses équivalents dans _25 pays_ 
, de faciliter vos demandes en 
mettant à disposition une _liste d'organisations publiques_ 
, un _formulaire d'envoi_ 
de votre demande d'accès à une 
information publique, ainsi qu'un _récapitulatif_ 
des demandes effectuées via la 
plate-forme.


Ce site est actuellement en phase de test et vos retours sur son 
fonctionnement sont les bienvenus !


Un article publié sur le blog d'Okfn France détaille les objectifs de 
nouveau site : 
https://fr.okfn.org/2019/10/24/madada-fr-ma-demande-dacces-a-un-document-administratif/


Merci de faire circuler ce message dans vos réseaux.

L'équipe Madada.fr"

PS : ce n'est pas "directement" lié à OSM mais il me semble qu'il y a 
suffisamment de surfaces communes pour que cela ne soit pas hors-sujet 
(mais je peux me tromper !).


--
Vincent Bergeot

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

Re: [OSM-talk-fr] Le futur des boutiques "Thomas Cook" ?

[Florian LAINEZ]

Hello, merci pour toutes vos réponses, je sentais la question compliquée,
c'est pourquoi je l'ai posée !
Quel est donc la suite maintenant avec ce fichier ?

Vous m'avez bien calmé, de mon coté je n'ai fait que modifier l'agence de
Montrouge  ;)

Le mar. 29 oct. 2019 à 20:56,  a écrit :

> Ce qui donne le fichier suivant.
>
> Quelqu'un pour continuer ?
> Le 29/10/2019 à 20:26, marc marc - marc_marc_...@hotmail.com a écrit :
>
> Le 29.10.19 à 19:18, osm.sanspourr...@spamgourmet.com a écrit :
>
> est-ce que Visiteurs et Asia sont des marques ?
>
> oui
> ___
> 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
>


-- 

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

Re: [OSM-talk-fr] Faire des demandes d'ouverture de données -> madada.fr

[ades]

très bien, mais ce qui m’emmerde c‘est qu’en général  je n’ai rien à faire avec 
des « autorités publiques » mais avec des « services publics » et si j’ai envie 
de demander quelque chose, je demande, à qui détient la chose, pas à n’importe 
qui…

> Le 30 oct. 2019 à 15:45, Vincent Bergeot  a écrit :
> 
> Bonjour,
> 
> je me permets de relayer ici cette information qui concerne les demandes 
> d'accès aux documents administratifs, dont certaines données cartographiques 
> peuvent faire parties !!
> 
> " Nous souhaitons vous informer du lancement du site https://madada.fr 
> , un service en ligne pour simplifier les demandes 
> d'accès aux documents administratifs.
> 
> Porté par l'association Open Knowledge France, avec le soutien de 
> l’association ouvre-boîte et du réseau européen Access Info, l'objectif de la 
> plate-forme est d'accompagner les demandeu.r.se.s dans leurs démarches et de 
> renforcer la visibilité de leurs actions individuelles.
> 
> Elle est propulsée par un logiciel open source conçu par l'ONG MySociety 
> Alavateli  et permet, à l'instar de 
> ses équivalents dans 25 pays , de 
> faciliter vos demandes en mettant à disposition une liste d'organisations 
> publiques  , un formulaire d'envoi 
>  de votre demande d'accès à une 
> information publique, ainsi qu'un récapitulatif 
>  des demandes effectuées via la 
> plate-forme.
> 
> Ce site est actuellement en phase de test et vos retours sur son 
> fonctionnement sont les bienvenus !
> 
> Un article publié sur le blog d'Okfn France détaille les objectifs de nouveau 
> site : 
> https://fr.okfn.org/2019/10/24/madada-fr-ma-demande-dacces-a-un-document-administratif/
>  
> 
> 
> Merci de faire circuler ce message dans vos réseaux.
> 
> L'équipe Madada.fr"
> 
> PS : ce n'est pas "directement" lié à OSM mais il me semble qu'il y a 
> suffisamment de surfaces communes pour que cela ne soit pas hors-sujet (mais 
> je peux me tromper !).
>  -- 
> 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] bridge=simple_brunnel

[osm . sanspourriel]

Le 30/10/2019 à 10:41, Nicolas Moyroud - nmoyr...@free.fr a écrit :


Je ne vois pas le rapport qu'il y a avec large / étroit.


La... largeur peut-être ?


Dans le cas du gué les deux objets physiques routes / rivières passent
au même niveau et en suivant l'un on passe forcément par l'autre.


Si la route n'est pas poreuse, l'eau passe au dessus^^. Ceci dit je
comprends maintenant ce que voulait dire Guillaume.


Donc aucune raison topologique de mettre un point commun entre les deux.
Je rajoute d'ailleurs systématiquement layer=-1 sur le tronçon
tunnel=culvert pour bien indiquer qu'il est en-dessous.


C'est ce que fait iD. Comme layer=1 pour les ponts.

Implicitement si une route traverse une rivière, c'est la route qui est
au dessus de la rivière, pas la rivière qui passe par le pont.

De même c'est la rivière, pas la route, qui se fait buser.

Et dans les cas exceptionnels où c'est le contraire, les dimensions font
qu'on ne sera plus sur du rendu ponctuel.

Donc pour moi, un rendu ponctuel est correct. Je ne suis pas par exemple
pour inventer des longueurs de buses là où l'imagerie ne permet pas de
les voir.

Correct, pas parfait. La nature (water ou highway) fait qu'on garde deux
graphes distincts : tu dédoublonnes le point avec layer= si ça te pose
soucis.

*Et donc, quand tu ne vois pas, tu ne dis pas que ce n'est pas un gué,
un pont ou une buse ?*

*Tu crées un pont ou une buse de taille "standard" (inventant de la
donnée) ?*

Avec un point, c'est un intermédiaire.

Jean-Yvon


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

Re: [OSM-talk-fr] Faire des demandes d'ouverture de données -> madada.fr

[Christian Quest]

Quand on sait qui détient, on a déjà résolu une part non négligeable du
problème !

On joue ?

Qui trouve le premier les données de régularité/ponctualité des transports ?


Le mer. 30 oct. 2019 à 17:02, ades  a écrit :

> très bien, mais ce qui m’emmerde c‘est qu’en général  je n’ai rien à faire
> avec des « autorités publiques » mais avec des « services publics » et si
> j’ai envie de demander quelque chose, je demande, à qui détient la chose,
> pas à n’importe qui…
>
> Le 30 oct. 2019 à 15:45, Vincent Bergeot  a écrit :
>
> Bonjour,
>
> je me permets de relayer ici cette information qui concerne les demandes
> d'accès aux documents administratifs, dont certaines données
> cartographiques peuvent faire parties !!
>
> " Nous souhaitons vous informer du lancement du site https://madada.fr, *
> un service en ligne pour simplifier les demandes d'accès aux documents
> administratifs.*
> Porté par l'association Open Knowledge France, avec le soutien de
> l’association ouvre-boîte et du réseau européen Access Info, l'objectif
> de la plate-forme est *d'accompagner* les demandeu.r.se.s dans leurs
> démarches et de *renforcer la visibilité* de leurs actions individuelles.
>
> Elle est propulsée par un logiciel open source conçu par l'ONG MySociety
> *Alavateli* et permet, à l'instar de ses équivalents dans *25 pays*, de
> faciliter vos demandes en mettant à disposition une *liste
> d'organisations publiques*  , un *formulaire
> d'envoi*  de votre demande
> d'accès à une information publique, ainsi qu'un *récapitulatif*
>  des demandes effectuées via la
> plate-forme.
>
> Ce site est actuellement en phase de test et vos retours sur son
> fonctionnement sont les bienvenus !
>
> Un article publié sur le blog d'Okfn France détaille les objectifs de
> nouveau site :
> https://fr.okfn.org/2019/10/24/madada-fr-ma-demande-dacces-a-un-document-administratif/
>
> Merci de faire circuler ce message dans vos réseaux.
>
> L'équipe Madada.fr"
>
> PS : ce n'est pas "directement" lié à OSM mais il me semble qu'il y a
> suffisamment de surfaces communes pour que cela ne soit pas hors-sujet
> (mais je peux me tromper !).
>
> --
> 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
>


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

Re: [OSM-talk-fr] Faire des demandes d'ouverture de données -> madada.fr

[Yves P.]

> On joue ?

Je n'ai mis que les 2 premiers liens (saisie tactile sur le smartphone
laborieuse).

https://www.data.gouv.fr/fr/datasets/regularite-quotidienne-lignes-sncf/

https://www.data.gouv.fr/fr/datasets/regularite-mensuelle-transilien/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Faire des demandes d'ouverture de données -> madada.fr

[marc marc]

> On joue ?
> Qui trouve le premier les données de régularité/ponctualité des transports ?
il n'y a pas de régularité/ponctualité, donc pas de donnée à gérer :-D
par contre les données sur les retards/annulations, c'est autre chose :-D
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OSM transport] booking=* <> reservation=*

[Topographe Fou]

Merci marc marc de faire le suivi.

Pour les urls à simplifier et la cohérence des langues cela pourrait je pense 
faire l'objet d'une routine Osmose.

LeTopographeFou


  Message original  



De: marc_marc_...@hotmail.com
Envoyé: 29 octobre 2019 11:33 PM
À: talk-fr@openstreetmap.org; transp...@listes.openstreetmap.fr
Répondre à: marc_marc_...@hotmail.com
Objet: Re: [OSM transport] [OSM-talk-fr] booking=* <> reservation=*


Bonsoir,

Personne ne s'y étant opposée, la migration de booking=* vers
reservation=* a été effectuée en France.
Plusieurs relations (de train) concernées ont des arrêts hors France,
il n'est évidement pas réaliste de couper la relation en 2.

LeTopographeFou tu as totalement raison sur les 3 critiques à propos
des url booking.com
Il faudrait en effet supprimer les paramètres
de traçages (tout ce qui est après le ?)
pour booking=* <> reservation:booking=*, la discussion n'a pas
vraiment abouti sur tagging, alors je vais m'abstenir, histoire
de ne pas créer un tag franco-français.

Cordialement,
Marc

Le 04.07.19 à 23:16, LeTopographeFou a écrit :
> Je pense également que réserver "booking=*" au seul site Booking n'est
> pas souhaitable. Il existe plein d'autres services et on est pas à
> l'abris qu'il y en ai un qui s'appelle "amenity" ou "building". Il
> faudrait à minima l'isoler dans un namespace, "reservation:booking" ou
> même "reservation:url:booking" pour pouvoir différencier différents
> moyens de réservation.
>
> Cependant il serait bon de ne pas résumer le débat à "Booking" mais
> parler de tous les sites de location entre particuliers et, en allant
> plus loin, aux plateformes de réservation de rendez-vous médicaux, de
> soins de beautés, de cours, de billets de train/avion/bus, de courses,
> de restauration, de voiture (y compris entre particuliers type Drivy),
> de places de théatre/cinéma...
>
> Cela dit mettre du Booking dans OSM présente aujourd'hui quelques
> soucis. Je ne suis pas opposé mais je dis 'attention' :
>
>  1. Ils n'ont pas de système de clé unique, publique et international
> partageable dans un "ref:booking" et attaquable via API Booking (ce
> qui serait bien plus propre qu'une URL)
>  2. Leurs URL sont moches, tout le monde ne sait pas les simplifier à
> leur stricte nécessaire en virant les éléments qui ne sont là que
> pour faire du suivi de navigation dans le cadre d'une recherche (ce
> qui n'a plus de sens dès qu'on le met dans OSM)
>  3. Dans l'URL il y a la langue (du moins quand je consulte un
> hébergement j'ai un '/fr/'), il conviendrait probablement de
> préciser le code ISO dans la clé (sinon un allemand peut se
> retrouver avec un lien en chinois)
>
> Cordialement,
>
> LeTopographeFou
>
> Le 04/07/2019 à 15:29, marc marc a écrit :
>> Bonjour,
>>
>> je fais écho ici d'une discussion qui a commencé sur la ml tagging
>> pour indiquer qu'un POI accepte/refuse/recommande une réservation,
>> la clef la plus courante est reservation=*
>> un contributeur avait crée une page booking=* et l'avait
>> ajout en recommandation sur plusieurs autres pages.
>> mais outre le fait d'avoir 2 clefs pour la même chose,
>> cela entrait en conflit avec booking=l'url booking.com
>> En est arrivé la conclusion de migrer
>> - booking=* vers reservation=* lorsque concerne la possibilité ou non de
>> réserver
>> - garder dans booking=* les url booking
>> - il y a aussi quelques urls de réservation non booking.
>> rien n'a été décidé mais sans doute que reservation:website serrait le +
>> cohérent.
>>
>> a noter que le plus grand nombre de cas (125) sont des lignes de
>> train passant par la France. à vos correcteurs, prêt ? partez :D
>> et si cela ne motive personne, je m'y collerai :)
>>
>> Cordialement
>> Marc
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>

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

[OSM-talk-fr] hebdoOSM Nº 483 2019-10-15-2019-10-21

[theweekly . osm]

Bonjour,

Le résumé hebdomadaire n° 483 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

http://www.weeklyosm.eu/fr/archives/12467/

Bonne lecture !

Saviez-vous que vous pouvez vous aussi soumettre des messages pour la note 
hebdomadaire sans être membre ? Il vous suffit de vous connecter sur 
https://osmbc.openstreetmap.de/login avec votre compte OSM. Pour en savoir plus 
sur la rédaction d'un article, cliquez ici: 
http://www.weeklyosm.eu/fr/this-news-should-be-in-weeklyosm

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Le futur des boutiques "Thomas Cook" ?

[osm . sanspourriel]

Florian ça complète ce que j'avais dit en MP.

Pour changer de couche on appréciera les raccourcis claviers de JOSM^^.

Voici pour la recette de cuisine :

- d'abord ci-joint deux ingrédients les fichiers :

 * *geocoded.csv, le même qu'avant mais sans espaces en début ou fin de nom
 * *geocoded.simplified.csv, le même mais sans colonnes en trop. Je
   n'ai pas retenu addr:full, ça serait sans doute pertinent (pas de
   conflit avec des éventuels points adresse).

- la recette proprement dite :

 * démarrer JOSM (mode expert) avec le greffon todolist
 * charger l'imagerie OpenStreetMap (ça évite de faire des conneries en
   voyant ce qui est en base, j'ai ainsi trouvé un magasin de fringues
   et une agence de voyage à la même adresse).

 * charger la couche des agences de voyage par requête SQL :

[out:json][timeout:2500];

  {{geocodeArea:france}}->.searchArea;

  (

    nwr["name"="Thomas Cook"](area.searchArea);

    nwr[skop=travel_agency](area.searchArea);

);

  out body;

  >;

  out skel qt;

C'est notre couche de travail, nommée Calque de données 1.

 * charger le fichier Univarmer2.geocoded.simplified.csv

C'est notre couche de référence

 * charger le fichier Univarmer2.geocoded.csv, c'est juste pour pouvoir
   voir l'adresse en cas de doute.
 * sélectionner la couche Univarmer2.geocoded.simplified.csv
 * sélectionner toutes les agences
 * dans la Liste des tâches, cliquer /Ajouter/
 * c'est parti, sélectionner le premier, différents cas :
 o l'agence n'est pas en base
 + sélectionner la couche Univarmer2.geocoded.simplified.csv
 + copier l'objet
 + sélectionner la couche Calque de données 1
 + coller au bon endroit (environ le même)
 o l'agence est en base avec un autre nom
 + sélectionner la couche Univarmer2.geocoded.simplified.csv
 + copier les attributs
 + sélectionner la couche Calque de données 1
 + sélectionnez l'agence existante
 + renommer name en old_name
 + coller les attributs. Attention : en cas de conflit il y a
   écrasement des anciennes valeurs.
 + là il est vivement conseillé de faire une recherche (pages
   jaunes, journaux, ...) pour savoir le nom actuel qui peut
   être différent... des deux. J'ai trouvé une agence
   anciennement Jet Tours nommée Univairmer selon Univairmer
   mais ripolinée Jet tours & Univairmer (oui Donat, un nom
   pour toi !) dans les couleurs Univairmer. Du coup j'ai
   ajouté Jet Tours en brand. Oui j'avoue avec deux majuscules.
   Souvent la presse locale (PQR, France 3)  a relaté les
   différents cas des agences TC du coin.
 * contempler son travail, satisfait (sinon changer ce qu'il faut).
 * expédier en mettant en commentaire

Passe agences de voyages Univairmer/Asia/Visiteurs/Kuomi/Thomas Cook

 * cliquer /Marquer /dans la Liste des tâches
 * on recommence.

Pour le suivi
:https://osmcha.mapbox.com/filters?aoi=c20ea9a1-08ad-4fea-b53b-bca7cea6e8c7


à condition de bien mettre comme commentaire :

Passe agences de voyages Univairmer/Asia/Visiteurs/Kuomi/Thomas Cook

Bon hormis à découper le fichier en plusieurs parties ou à ne pas
commencer la liste par le début, difficile de se partager le boulot à
beaucoup.

Commentaires pour améliorer le processus bienvenus.

> Vous m'avez bien calmé, de mon coté je n'ai fait que modifier
l'agence de Montrouge  ;)

Faut pas, faut trouver soit d'autres chaînes de franchisés ayant
travaillé avec TC soit tester la recette ci-dessus.

Un exemple : tu utilises ces couches non pour intégrer mais pour
regarder les agences TC non concernées et tu nous les signales ou/et tu
les traites en allant à la pêche aux infos.

Jean-Yvon

Le 30/10/2019 à 16:52, Florian LAINEZ - winner...@free.fr a écrit :

Hello, merci pour toutes vos réponses, je sentais la question
compliquée, c'est pourquoi je l'ai posée !
Quel est donc la suite maintenant avec ce fichier ?

Vous m'avez bien calmé, de mon coté je n'ai fait que modifier l'agence
de Montrouge  ;)

Le mar. 29 oct. 2019 à 20:56, mailto:osm.sanspourr...@spamgourmet.com>> a écrit :

Ce qui donne le fichier suivant.

Quelqu'un pour continuer ?

Le 29/10/2019 à 20:26, marc marc - marc_marc_...@hotmail.com
 a écrit :

Le 29.10.19 à 19:18,osm.sanspourr...@spamgourmet.com  
  a écrit :

est-ce que Visiteurs et Asia sont des marques ?

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

___
Talk-fr mailing list
Talk-fr@openstreetmap.org 

Re: [OSM-talk-fr] Le futur des boutiques "Thomas Cook" ?

[osm . sanspourriel]

Attention !

Jet tours est une marque de Thomas Cook donc :

- ne pas laisser Jet tours en brand.

- chercher aussi les boutiques Jet tours !

Cf. https://www.jettours.com/ ou
https://france3-regions.francetvinfo.fr/hauts-de-france/faillite-thomas-cook-incertitude-9-agences-aisne-oise-somme-1726387.html

Le 30/10/2019 à 21:33, Jean-Yvon Landrac a écrit :


Florian ça complète ce que j'avais dit en MP.

Pour changer de couche on appréciera les raccourcis claviers de JOSM^^.

Voici pour la recette de cuisine :

- d'abord ci-joint deux ingrédients les fichiers :

  * *geocoded.csv, le même qu'avant mais sans espaces en début ou fin
de nom
  * *geocoded.simplified.csv, le même mais sans colonnes en trop. Je
n'ai pas retenu addr:full, ça serait sans doute pertinent (pas de
conflit avec des éventuels points adresse).

- la recette proprement dite :

  * démarrer JOSM (mode expert) avec le greffon todolist
  * charger l'imagerie OpenStreetMap (ça évite de faire des conneries
en voyant ce qui est en base, j'ai ainsi trouvé un magasin de
fringues et une agence de voyage à la même adresse).

  * charger la couche des agences de voyage par requête SQL :

[out:json][timeout:2500];

   {{geocodeArea:france}}->.searchArea;

   (

     nwr["name"="Thomas Cook"](area.searchArea);

     nwr[skop=travel_agency](area.searchArea);
);

   out body;

   >;

   out skel qt;

C'est notre couche de travail, nommée Calque de données 1.

  * charger le fichier Univarmer2.geocoded.simplified.csv

C'est notre couche de référence

  * charger le fichier Univarmer2.geocoded.csv, c'est juste pour
pouvoir voir l'adresse en cas de doute.
  * sélectionner la couche Univarmer2.geocoded.simplified.csv
  * sélectionner toutes les agences
  * dans la Liste des tâches, cliquer /Ajouter/
  * c'est parti, sélectionner le premier, différents cas :
  o l'agence n'est pas en base
  + sélectionner la couche Univarmer2.geocoded.simplified.csv
  + copier l'objet
  + sélectionner la couche Calque de données 1
  + coller au bon endroit (environ le même)
  o l'agence est en base avec un autre nom
  + sélectionner la couche Univarmer2.geocoded.simplified.csv
  + copier les attributs
  + sélectionner la couche Calque de données 1
  + sélectionnez l'agence existante
  + renommer name en old_name
  + coller les attributs. Attention : en cas de conflit il y a
écrasement des anciennes valeurs.
  + là il est vivement conseillé de faire une recherche (pages
jaunes, journaux, ...) pour savoir le nom actuel qui peut
être différent... des deux. J'ai trouvé une agence
anciennement Jet Tours nommée Univairmer selon Univairmer
mais ripolinée Jet tours & Univairmer (oui Donat, un nom
pour toi !) dans les couleurs Univairmer. Du coup j'ai
ajouté Jet Tours en brand. Oui j'avoue avec deux
majuscules. Souvent la presse locale (PQR, France 3)  a
relaté les différents cas des agences TC du coin.
  * contempler son travail, satisfait (sinon changer ce qu'il faut).
  * expédier en mettant en commentaire

Passe agences de voyages Univairmer/Asia/Visiteurs/Kuomi/Thomas Cook

  * cliquer /Marquer /dans la Liste des tâches
  * on recommence.

Pour le suivi
:https://osmcha.mapbox.com/filters?aoi=c20ea9a1-08ad-4fea-b53b-bca7cea6e8c7


à condition de bien mettre comme commentaire :

Passe agences de voyages Univairmer/Asia/Visiteurs/Kuomi/Thomas Cook

Bon hormis à découper le fichier en plusieurs parties ou à ne pas
commencer la liste par le début, difficile de se partager le boulot à
beaucoup.

Commentaires pour améliorer le processus bienvenus.

> Vous m'avez bien calmé, de mon coté je n'ai fait que modifier
l'agence de Montrouge  ;)

Faut pas, faut trouver soit d'autres chaînes de franchisés ayant
travaillé avec TC soit tester la recette ci-dessus.

Un exemple : tu utilises ces couches non pour intégrer mais pour
regarder les agences TC non concernées et tu nous les signales ou/et
tu les traites en allant à la pêche aux infos.

Jean-Yvon

Le 30/10/2019 à 16:52, Florian LAINEZ - winner...@free.fr a écrit :

Hello, merci pour toutes vos réponses, je sentais la question
compliquée, c'est pourquoi je l'ai posée !
Quel est donc la suite maintenant avec ce fichier ?

Vous m'avez bien calmé, de mon coté je n'ai fait que modifier
l'agence de Montrouge  ;)

Le mar. 29 oct. 2019 à 20:56, mailto:osm.sanspourr...@spamgourmet.com>> a écrit :

Ce qui donne le fichier suivant.

Quelqu'un pour continuer ?

Le 29/10/2019 à 20:26, marc marc - marc_marc_...@hotmail.com
 a écrit :

Le 29.10.19 à 19:18,osm.sanspourr...@spamgourmet.com