Re: [OSM-talk-fr] Maj Cadastre vectoriel

[Jérôme Seigneuret]

https://cadastre.data.gouv.fr/datasets/cadastre-etalab

Le jeu. 24 sept. 2020 à 21:03, Yves P.  a écrit :

> Il y a des fichiers geojson sur data.gouv.fr Il y a une carte des mises à
> jour et ces éléments ont été mis à disposition en juillet.
>
>
> As-tu un lien sur un exemple précis ?
>
>
> Le fichier geojson peut être chargé il me semble dans JOSM
>
>
> Oui
>
> __
> Yves
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Maj Cadastre vectoriel

[Jérôme Seigneuret]

Bonsoir,
Il y a des fichiers geojson sur data.gouv.fr Il y a une carte des mises à
jour et ces éléments ont été mis à disposition en juillet. Il existe un
migrateur geojson vers postgresql en nodejs.

Le fichier geojson peut être chargé il me semble dans JOSM

Le ven. 18 sept. 2020 à 23:03, Eric SIBERT  a
écrit :

> Bonsoir,
>
> Ça y est, le cadastre vectoriel a été mis à jour sur la commune de Saint
> Martin d'Hères. Maintenant, il faut que je me souvienne de tous les
> chantiers rencontrés ces derniers mois ;-)
>
> Sinon, il y a le cadastre de Grenoble (raster et vecteur) qui est figé
> depuis 3 ou ans. Toujours pas de traces de bâtiments livrés depuis 3 ans
> :-(
>
> Eric
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet du mois défibrillateurs : point d'avancement

[Jérôme Seigneuret]

l on aierait avoir une carte avec une mesure de l'impact de ces
> équipements (délais d'intervention, taux d'utilisation, remises à jour ou
> en conformité, relevés des pannes ou appareils perdus/détériorés.
>
> Et si une zone n'a pas besoin de davantage de DAE (sur-équipement) les
> entreprises pourraient aussi contribuer d'une autre façon en abondant un
> fond d'équipement pour couvrir les zones blanches ou aider les sites peu
> favorisés à s'équiper et entretenir. D'ailleuis je ne suis pas sur
> qu'inciter chacun d'eux à s'équipper individellement est efficace, et s'il
> ne faudrait pas en fait que la répartition des DAE réellement installés
> soit du resort d'une autorité de planification qui approuverait ces
> équipements (en contrôlant leur installation et leur entretien) ou
> simplement recevrait des garanties financières avec une redevance ou des
> preuves comptables de contributions vers d'autres secteurs moins favorisés.
>
> Et je suis même convaincu que l'obligation d'assurer ces matériels au sein
> de chaque contrat d'entretien permettrait d'utiliser les infras
> informatiques des sociétés d'assurances ou de la sécu (lARS ne semble pas
> en mesure de le faire) en tant que mission de service publique, avec un
> "open data" qui va bien et lui aussi avec une maintenance (et une
> adéquation avec les règles légales concernant la vie privée).
>
> Et avoir des outils de mesure de l'efficacité permettrait aussi de mesurer
> l'efficacité et revoir le dispositif et les seuils d'équipement minimaux
> (ce seuils pevuent varier justement en fonction de la proximité et la
> charge des services d'urgence, très inégaux sur le territoire et de plus en
> plus centralisés avec des tas de fermeture de services locaux: le transfert
> de plein de compéttence des communes à leur agglo favorise beaucoup trop
> les communes "centre" au détriment des autres: obliger les EPCI à ouvrir
> ces données et mettre en place des outils de mesure d'efficacité me
> parait indispensable pour savoir si elle n'en fait pas assez en terme de
> concentration ou répartition des services, ou trop avec un cout qui
> pourrait servir à d'autres priorités et à arbitrer avec la population en
> réunions publiques et pas juste au sein d'une grosse agence régionale
> qui décide dans un bureau en petit comité et qui n'a même aucun moyen de
> contrôle: il faut faire confiance au contrôle direct par la population,
> donc à l'open data et non aux seules communications officielles des
> institutions publiques et ne pas croire non plus aux annonces à visée
> politique ou électorale car sans jamais aucun suivi).
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] maxspeed par défaut

[Jérôme Seigneuret]

implicite en rural dépend du nombre de voies sauf cas mentionné avec des
panneaux. Maintenant des département ont et vont remettre à 90km des
départementale. CF:
http://www.departements.fr/loi-mobilite-promulguee-retour-aux-90-kmh-possible-conditions

Donc avec c'est 80km par sens en voie unique. Sinon pour toute double voies
c'est 90km (implicite)
Le relèvement des voies de 10km doit être motivé. Donc avec panneaux
(explicite)

A+

Le mer. 2 sept. 2020 à 10:54,  a écrit :

> +0,9 ;-)
>
> > - sauf sur certaines portions de départementale dans certains
> départements
>
> Non, je crois que ça c'est une exception *explicite* car on a la liste et
> ça va figurer sur le terrain (je suppose). L'implicite c'est ce que dit le
> code de la route.
>
> En général dans les cas indiqués il y a des panneaux 90.
>
> > - On peut imaginer une route à double-sens avec un terre-plein
> temporaire pour un carrefour. Ce n'est pas pour autant que le long du
> terre-plein, la limite va passer à 90 km/h.
>
> En théorie tu as raison. En pratique
> <https://www.openstreetmap.org/way/617848166>... Je ne sais si un gars a
> eu une offre spéciale pour réutiliser les anciens panneaux !
>
> Je réserve le source:maxspeed=FR:rural au 80. Les autres ça va être du
> source:maxspeed=sign.
>
> Jean-Yvon
> Le 02/09/2020 à 10:33, Eric SIBERT via Talk-fr - talk-fr@openstreetmap.org
> a écrit :
>
> +1 avec les avis précédents: en extra-urbain, l'implicite est devenu
> tellement incompréhensible qu'il vaut mieux coder explicitement.
>
> Par défaut c'est 80 km/h sur les chaussées à double sens:
> - sauf sur certaines portions de départementale dans certains départements
> - sauf quand il y a un une voie supplémentaire pour faire un créneau de
> dépassement
> - pareil pour les routes pour automobile (panneau C107) à double-sens?
> - On peut imaginer une route à double-sens avec un terre-plein temporaire
> pour un carrefour. Ce n'est pas pour autant que le long du terre-plein, la
> limite va passer à 90 km/h.
>
> Donc l'implicite est difficile à expliquer à l'humain et à l'ordinateur.
> Je ne sais même plus ce qu'il faut mettre pour source:maxspeed dans ces cas
> là.
>
> Eric
>
>
> ___
> 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
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] BANO est-il mort?

[Jérôme Seigneuret]

@Yves il est vrai qu'il y a beaucoup de vocabulaire lié à cette
méthodologie et au fonctionnement qui tourne autour de ça. Les termes sont
en anglais mais on s'y fait rapidement.

C'est @Vincent qui actuellement porte le projet. On peut voir comment
s'organiser pour faire avancer le projet avec les personnes disponibles et
avec un mode de fonctionnement déjà utilisé sur d'autre projets Open Source
ou pas. On va pas commencer a écarter des gens mais il y a des experts dans
chaques domaines du développement informatique, d'autres en langues,
d'autres pour faites du test, et des utilisateurs !... Donc répartir les
tâches c'est moins simple mais au moins on peut essayer d'avoir un
avancement minimum.



Le dim. 30 août 2020 à 11:17, Yves P.  a écrit :

> Qu'en pensez-vous ?
>
> Intéressant on tu trouves "le"  Scrum Master :)
>
> Et ça fonctionne si on n'est pas formé à la méthode Scrum
>  et à son
> vocabulaire  ?
>
> __
> Yves
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] BANO est-il mort?

[Jérôme Seigneuret]

Salut, plutôt que de jouer à qui sera le plus ridicule dur la liste,
peut-on juste s'entendre sur un état de l'art. Voir ce qu'il reste a faire
avec un bilan. Trouver un moyen de le faire en méthode agile avec des
sprints d'un mois. Trouver des ressources (des volontaires ça ne manque pas
sachant que bon nombres de sociétés et de services publics utilisent Bano
et pas forcément dans la communauté)

Certains ont des idées d'autres des moyens.
Brefs c'est un sujet porteur. Les adressage c'est utilisé tous les jours et
la fiabilisation donnera d'autant plus de portée au projet si celle-ci sont
exploitables pleinement.

@vincent :
Veux tu continuer à porter le projet ? A la limite faire Scrum Master?
On met un bord sur le Github! Et on défini la taille des sprints. Chaque
personne défini sur le sprint le temps qu'il est près a y accorder et sur
quel partie: dev, recette, diabolisation de donnees, documentation,
communication...

Sur le board on identifie ce qui est fait, ce qui restera faire et les
idées. Au moins les tickets avanceront. Et on retrouvera un apaisement et
de la satisfaction chez tous le monde.


Qu'en pensez-vous ?
Bon weekend

Le dim. 30 août 2020 à 03:40, Philippe Verdy  a écrit :

> En plus ce que tu viens d'écrire me donne raison car tu as fait les mêmes
> constatations que moi ou n'importe qui.
>
> J'ai juste demandé de la maintenance et toi aussi tu la demande. En quoi
> ai-je eu tord ?
>
> En revanche tu as eu tord sur ta façon de réagir. Et tu confirmes ce que
> je décrivais de l'attitude malveillante de certains ici (dont tu confirmes
> on ne peut plus explicitement faire partie). Ton intention c'est bien
> d'exclure et diviser les gens. Cela n'a rien de coopératif ni constructif.
> Je ne t'avais pourtant pas désigné ni émis aucune critique contre toi, mais
> là tu viens de te le permettre honteusement (et ce n'est pas la première
> fois).
>
> Mais là tu n'as pas hésité à tenir ta rancoeur anti-personnelle
> persistante et la rendre publique. T'inquiète pas, je suis résistant, je ne
> généralise pas et ne met pas tout le monde dans le même panier. On peut
> exprimer des déceptions, des avis, des suggestions de changement,
> interroger et demander des avis, sans subit de telles attaques publiques
> personnelles comme ici.
>
>
> Le dim. 30 août 2020 à 03:32, Philippe Verdy  a écrit :
>
>> Et bravo encore pour ta "bienveillance", qui démontre encore un haut
>> niveau de tolérance.
>>
>> Le dim. 30 août 2020 à 02:23, Jérôme Amagat  a
>> écrit :
>>
>>> Vous vous faite du mal à répondre à Philippe, ça ne sert à rien. Ça fait
>>> plusieurs années que je lis ce qui se dit sur cette liste et il est
>>> coutumier de ce genre d'intervention, il ne faut pas y faire attention et
>>> même ne pas le lire, vous vous en porterez que mieux :)
>>>
>>
>> Maintenant tu donnes des ordres aux autres, monsieur le censeur bien
>> pensant qui veut se placer comme élite ? Et c'est moi qu'on traite de
>> "yakafaucon" ?
>>
>> ___
> 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] Comment créer un élément DataItem ?

[Jérôme Seigneuret]

Oui sur la base d'un dictionnaire de clés valeurs

Le dim. 28 juin 2020 à 13:07, Yves P.  a écrit :

>  bça semble être ça (mais pas ou peu documenté) :
>
> https://github.com/Sophox/sophox/tree/metabot/metabot
>
> D'après la discussion Item Creation process
>  le
> bot créait un élément pour chaque nouveau tag trouver dans OSM.
> Depuis ?, il ne le fait que pour des tag présent au moins 10 fois dans la
> base et avec des noms pas trop "bizarres".
>
> Une création manuelle comme dans Wikidata serait bien ?
>
> __
> Yves
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Comment créer un élément DataItem ?

[Jérôme Seigneuret]

Salut,

As-tu regardé cette page https://wiki.openstreetmap.org/wiki/Data_items

Le dim. 28 juin 2020 à 12:01, Yves P.  a écrit :

> Bonjour,
>
> J'ai créé une page anglaise pour une clé, mais le menu *Élément
> OpenStreetMap Wiki* n'apparait pas.
> (De même pour les pages dans les langues autres que l'anglais).
>
> Et peut-on créer un élément sans créer de page wiki ?
>
> __
> Yves
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] DCbrain rend publique une partie de son code en open source

[Jérôme Seigneuret]

Le mar. 26 mai 2020 à 06:52, Philippe Verdy  a écrit :

> Ce code source n'apporte strictement rien.
>
Ça a le mérite d'être clair!

>
> Pas même sa description qui est fonctionnellement aberrante concernant la
> formule des "node id", un pseudo-hashcode qui n'en est même pas un, qui
> réclame un nombre premier pour encoder le couple de coordonnées alors que
> cela n'a rien à voir et qu'il n'est pas nécessaire du tout que ce soit
> premier, on peut directement utiliser "180*10^precision" à la place de
> "prime" en voyant que les latitudes sont données en degrés entre -90.0
> et +90.0, ou bien  "360*10^precision" si les latitudes ne sont pas
> normalisées à cet intervalle et reboucle chaque méridien avec son
> antiméridien (au quel cas un module 360 suffit sur chacune des deux
> coordonnées à les normaliser "à moitié", sans unifier un point et son
> antipode situé à la même longitude mais à la latitude+180°)
>
>round(mod(lat, 360), precision) + round(mod(lon, 360) , precision) *
> 360*10^precision
>
Le code source est libéré je pense que tu peux proposer quelque chose en ce
sens qui permettrait à la communauté quelque choses de constructif

>
> Les arrondis sont mal exprimés aussi dans la formule originale qui va donc
> confondre une partie de la précision de la longitude en recouvrant des
> points ailleurs à une autre longitude.
>
> [Pour une unification complète des points antipodiques, il faut un test
> d'intervalle pour la latitude modulo 360, pour la ramener à un intervalle
> large de 180°, en ajoutant ou pas 180° à la longitude, selon la parité de
> l'intervalle de latitude, et en remplaçant ou pas la latitude par son
> complémentaire à 180° selon la même parité]. Et je pense même que c'est
> inutile à moins que la base QGis stocke des coordonnées non normalisées
> (avec des latitudes hors de -90.0 à +90.0, même s'il est probable qu'elle
> puisse avoir en revanche des longitudes hors de l'intervalle -180.0 à +180°
> pour la cartographie le long de la ligne de changement de date (aux îles
> Kiribati, aux île Kouryles et à travers la pointe du Kamtchatka en Sibérie
> extrême-orientale, et sinon sur le continent antarctique dans le secteur
> revendiqué par l'Australie).
>
> Et concernant le paramètres "layer" qui multiplie le tout, c'est encore
> plus stupide, sa seule valeur valide est 1, toute autre valeur n'apporte
> rien d'autre qu'un changement d'échelle des ids, sauf la valeur 0 qui rend
> tous les ids générés nuls.
>
Pareillement. Peut-être que ça a une utilité justement pour le projet
originale pour filtrer un niveau d'échelle un peu comme le fait INTERLIS

>
> J'espère qu'une telle formule (totalement fausse) n'a jamais réellement
> été utilisée pour importer des géométries dans OSM!
>
Peut-être que SeFaireConnaitre ... Non je sors

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

Re: [OSM-talk-fr] Normalisation des bis, ter…

[Jérôme Seigneuret]

Comme dit @marc on peut simplement spécifier le mode d'écriture sans espace
et majuscule pour les lettres (bâtiment entrée ) et minuscules pour bis ter
quater etc dans les bonnes pratiques.

Le lun. 25 mai 2020 à 19:01, Yves P.  a écrit :

> > il n'y a pas besoin de tableau pour lister 3-4 abréciations, parler de
> > l'espace et de capitale<>minuscule, au contraire les tableaux de 26
> > lignes pourêtre ultra complet, sont hyper lourd parce qu'on passe
> > son temps à les lire croyant qu'il y a une info particulière
> > autre que le déluge
>
> Pas sur d'avoir tout saisi. Je parlais du tableau dans la page wiki addr,
> pas d'un nouveau tableau listant tout les cas :)
>
> __
> Yves
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Normalisation des bis, ter…

[Jérôme Seigneuret]

@yves On a abordé ce sujet il y a peu de temps. Même pour certains où c'est
affiché 6 B sur le terrain il y a des cas où c'est en réalité 6 Bis. Pareil
pour T Q...

Il faut convertir autant que possible en Bis , Ter, Quarter, Quinter. Mais
c'est aussi sur une base de connaissance. Car il existe des cas ou le 1bis
côtoie le 1B (Batiment B au 1 de la rue).
BTQ est accepté sur le terrain pour Bis , Ter, Quater . comme on peut aussi
voir *266 6* pour 266sexies

La Proposition de @cquest est de mettre tout en minuscule sans espace.
Concernant les lettres des bâtiments (ou entrée) en capitales
Par opposition aux lettres des entrées de bâtiments qui donne droit à un
adressage en 1A, 1B, 1C...


C'est abordé ici
https://www.mail-archive.com/talk-fr@openstreetmap.org/msg96547.html
https://www.mail-archive.com/talk-fr@openstreetmap.org/msg90355.html
https://www.mail-archive.com/talk-fr@openstreetmap.org/msg81574.html
https://www.mail-archive.com/talk-fr@openstreetmap.org/msg68051.html

Coté forum
https://forum.openstreetmap.fr/viewtopic.php?f=2=3260=12213=bis
#p12213

 On devrait mettre ça au clair sur le wiki. C'est un sujet récurrent.


Le lun. 25 mai 2020 à 14:10,  a écrit :

> > Je favoriserait le fait de coller les indices, car on peut facilement
> les séparer si besoin et surtout ça évite de créer une ambiguïté avec le
> reste de l'adresse comme ça peut être le cas avec un "34 A" le "A" pouvant
> être un "à...".
>
> Non, ce serait À, le cadastre respectant notoirement les accents^^.
>
> J'ai habité un bâtiment A et j'écrivais 3A, 3 A ne me choque pas, par
> contre pour bis et ter l'usage est plutôt de séparer.
>
> *Sachant que pour simplifier sur le terrain il y avait un 3, un A et un B.
> Le 3B/3 B était en face du 5A/ 5B et quand les gens viennent par l'entrée
> secondaire ils voient B et B puis A et A ;-).*
>
> J'aurais donc dit 1 bis mais 1A.
>
> J'ai regardé la plaque d'un 19 bis et il est écrit 19b...
>
> 19B et 19 bis permettrait de clarifier un peu.
>
> Et si je reprends le 3A dans un célèbre annuaire en ligne je vois 3 A, 3
> (il ne devrait y en avoir qu'un avec-entrée directe dans un appart du 3 A
> il y en a plusieurs, des 3 A, un bât 1 3 Bis - il avait dû fumer, 3 porte
> bât B). Comme ce sont les gens qui entrent ce n'est pas évident.
>
> Les références des routes comportent des espaces et donc par exemple D 342
> bis.
>
> Maintenant comme dit Christian l'essentiel est se mettre d'accord et si
> notre moulinette cadastre dit de mettre une espace, mettons la.
>
> Jean-Yvon
> Le 25/05/2020 à 13:36, Romain MEHUT - romain.me...@mailo.com a écrit :
>
> Pour mémoire :
> https://www.mail-archive.com/talk-fr@openstreetmap.org/msg81574.html
>
> Romain
>
> Le 25/05/2020 à 12:36, Marc M. a écrit :
>
> Bonjour,
>
> Le 25.05.20 à 10:28, Yves P. a écrit :
>
> Quel format faut-il utiliser ?
> 1bis, 1 bis, 1B, 1BIS, 1 BIS…
>
> http://cadastre.openstreetmap.fr dit B,T,Q→ bis, ter, quater   A→␣A
> donc "1 bis"
> mais effectivement cela devrait se trouver sur le wiki qlq part.
>
> 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
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Ecole maternelle / primaire : amenity=school ou kindergarten

[Jérôme Seigneuret]

isced:level <https://wiki.openstreetmap.org/wiki/Key:isced:level> sert déjà
à cela

Le ven. 22 mai 2020 à 16:59, Frantz  a écrit :

> Bonjour,
>
> 22 mai 2020 12:58 "Christian Rogel"  a
> écrit:>> Le 22 mai 2020 à 10:43, Jérôme Seigneuret <
> jerome.seigneu...@gmail.com> a écrit :
> >>
> >>>
> >>
> >> ça fait pas vraiment concenssus. Le problème est français depuis cette
> années scolaire la
> >> maternelle est obligatoire par décret. N'en reste pas moins que dans
> certains pays le crèche sont
> >> privé et pour du préscolaire. Que chez nous on fait une décomposition
> linguistique qui n'existe pas
> >> forcément ailleurs. Certaines crêche on exactement les même programme
> que les maternelles ce qui
> >> pose donc des problèmes au choix des clés et à la catégorisation
> >
> > Non, l’école maternelle n’est pas obligatoire, pas plus que la
> scolaritè. C’est l’instruction qui
> > est obligatoire.
>
> En effet :
> "L'instruction est obligatoire pour tous les enfants, français et
> étrangers, à partir de 3 ans et jusqu'à l’âge de 16 ans révolus. Les
> parents peuvent choisir de scolariser leur enfant dans un établissement
> scolaire (public ou privé) ou bien d'assurer eux-mêmes cette instruction."
>
> Noter : "obligatoire" "à partir de 3 ans" et "scolariser dans un
> établissement *scolaire*".
>
> > Que l'instruction préscolaire ait été ajoutée comme obligation ne
> modifie rien au fait qu’elle
> > intervient,
> > par définition, avant la période où savoir, lire, écrire et compter est
> compté dans les acquis
> > obligatoires à partir de l’âge de 6 à 7 ans.
>
> Si tu la déclares préscolaire d'office, l'argumentation est biaisée.
>
> TLFi :
> Préscolaire : "Approprié à la formation des enfants qui n'ont pas atteint
> l'âge de la scolarité obligatoire."
> École : "[L'idée dominante est l'acquisition d'un savoir] Établissement
> dans lequel on donne un enseignement collectif"
> Et ce n'est pas une nouveauté : "Étymol. et Hist. 1. Ca 1050 escole «
> établissement où l'on donne un enseignement collectif »"
>
> > Pour être en ligne avec les autres pays, il est nécessaire de s’appuyer
> sur les descriptions
> > internationales.
>
> Parfaitement. La définition du mot école est curieusement assez proche
> dans les langues anglais/français/allemand.
> anglais : school : "An institution for educating children."
>
> Enseignement collectif, a fortiori obligatoire -> school
> et si on veut détailler :
> * niveau d'enseignement : isced:level (ou school:isced_level ?)
> * âge : min_age / max_age (ou school:age ?)
> * public particulier : school:for ?
> * spécialisation : school:speciality ?
> * dénomination locale : school:FR=maternelle/...
>
> Et comme ça tout le monde peut faire ses recherches selon le critère qui
> l'intéresse, et on rassemble le monde de l'éducation.
>
> Sinon on continue à perdre notre temps à tenter en vain de faire
> correspondre à l'univers anglo-saxons les appellations locales pour chaque
> tranche d'âge et niveau d'éducation dans... 197 pays.
> Et quand on aura fini pour kindergarten/school on attaquera
> college/university, et clinique/hôpital,...
>
> --
> Frantz
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Ecole maternelle / primaire : amenity=school ou kindergarten

[Jérôme Seigneuret]

> Non, l’école maternelle n’est pas obligatoire, pas plus que la scolaritè.
> C’est l’instruction qui est obligatoire.
>
> Que l'instruction préscolaire ait été ajoutée comme obligation ne modifie
> rien au fait qu’elle intervient,
> par définition, avant la période où savoir, lire, écrire et compter est
> compté dans les acquis obligatoires
> à partir de l’âge de 6 à 7 ans.
> Pour être en ligne avec les autres pays, il est nécessaire de s’appuyer
> sur les descriptions internationales.
>
>
On parle d'école par analogie. En effet on peut faire l'école à la maison
(ou donner une instruction scolaire pour être plus précis et en accord avec
les textes). En terme de définition, on parle d'école dans le cas d'un
enseignement collectif. L'enseignement en soit ce n'est pas que lire écrire
parler. On pourrait aussi dire que les assistantes maternelles donne un
enseignement collectif. Le savoir être et vivre en collectivité me semble
bien aussi important.


> Lea question des crèches ne pourrait-elle pas être traitée par :
>
> amenity = kindergarten
> kindergarten:for = toddlers ?
>
Oui c'est une autre possibilité  mais childcare existe déjà et nursery a
été retoqué.

*This tag is used for places where children are looked after, including a
nursery or daycare which takes care of small children who are too young
for amenity =kindergarten
 or
preschool, and after-school childcare facilities.*

*This tag can be controversial because there is an overlap in some cases
with amenity =kindergarten
, but on
the other hand there clearly is demand for such a tag. There are two
separate proposal for this same tag [1]
 [2]
 and a
related one [3]
.*

*The tag amenity
=kindergarten
 is used
differently in different countries. In some, it is only used for
preschool-like education (isced:level
=0). Other countries
include institutional supervision of primary-school children in the
afternoon. In other places, such as the United States, "childcare" is a
generic term for supervision of children in a wide range of age groups and
institutions, from schools to private service providers. It is suggested a
feature be tagged as a kindergarten when there is an overlap.*

  isced:level =0
quelque soit le tag on pourrait y intégrer la clé de classification
internationale
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Ecole maternelle / primaire : amenity=school ou kindergarten

[Jérôme Seigneuret]

 ans) et les mêmes lieux de formation (les écoles normales).
> >> Ce n’est qu’un changement sur le niveau d’admission (licence) et les
> >> droits à la retraite.
> >> Pas la peine de le mentionner.
> >>
> >> J’ai parlé de primarisation des EM, car, les programmes y ont
> >> toujours existé, mais, les compétences demandées aux petits se sont
> >> accrues et on en est venu à leur donner les premières bases de la
> >> lecture.
> >> Et très récemment, l’EM est devenu « obligatoire ».
> >>
> >> En fait, l’école n’a jamais obligatoire, mais l’instruction, oui.
> >>
> >> Chacun est libre de ne pas mettre ses enfants à l’école, pourvu qu’il
> >> soit en mesure de prouver qu’ils acquièrent les savoirs et
> >> compétences correspondants à leur âge.
> >>
> >> La seule question qui vaille est celle-ci :
> >>
> >> Si on voit écrit « école maternelle », est-ce que c’est du
> >> pré-scolaire ?
> >>
> >> Si, on répond oui, on suit la régle internationale : pre-school >
> >> kindergarten (la traduction compte peu, nous sommes dans une
> >> convention de nommage).
> >>
> >> Si, on pense que la maternelle est le début, du primaire, on répond non.
> >>
> >>
> >> Jusqu’ici, même primarisée, l’école maternelle est pré-scolaire, car,
> >> on y apprend pas réellement les pré-requis du savoir, qui élargit les
> >> compétences.
> >>
> >>
> >>
> >> Christian R.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> ___
> >> 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
>
> --
> Violaine_Do
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import de points d'eau incendie en Saône-et-Loire

[Jérôme Seigneuret]

Je ne sais pas si on peut adjoindre dans alias dans ID via Transifex. Cela
permettrait d'avoir des terminologies différentes pour les mêmes couple de
clés/ valeurs en résultat...

Le mer. 20 mai 2020 à 06:38, Antonin Delpeuch (lists) <
li...@antonin.delpeuch.eu> a écrit :

> On 19/05/2020 23:37, Yves P. wrote:
> >> Mon habitude de dire "pilier" vient probablement du fait que c'est le
> >> terme utilisé par iD en version française (pour traduire la valeur
> >> "pillar") - ça vaudrait le coup d'être corrigé. Si tu sais comment
> >> résoudre ça (et probablement d'autres problèmes de terminologie)
> >> n'hésite pas !
> > Il faut utiliser Transifex
> > : https://www.transifex.com/openstreetmap/id-editor/
> >
> > Pour plus d'infos :
> >
> https://github.com/openstreetmap/iD/blob/develop/CONTRIBUTING.md#translating
>
> Super! Je te laisse t'en occuper ? Personellement je n'ai pas de
> préférence particulière sur les termes à utiliser.
>
> Antonin
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Point d'apport volontaire, point de collecte, point de regroupement

[Jérôme Seigneuret]

https://www.mapillary.com/map/im/r3-7eaUqvjER2K6KQCbIPg
colonne enterrée à préhension par simple crochet


https://www.mapillary.com/map/im/Ml__GIf3g3bbILsmEWglsQ
  colonne aérienne à préhension par simple crochet

https://www.mapillary.com/map/im/lKjOCV-HlhHMnpFHH1tEYQ
colonne OM (j'en avait pas encore vu en aérien)  à préhension par simple
crochet

Et tous comme les camions peuvent être multi flux; les bacs de collecte et
les colonnes peuvent être multi-flux
https://www.elkoplast.fr/media/photos/catalog/item/gallery/images-218/p3091140-1024-t2.jpg

Le ven. 15 mai 2020 à 14:31, Stéphane Péneau  a
écrit :

> Le 15/05/2020 à 13:09, Yves P. a écrit :
>
>  >Des photos seraient les bienvenues pour différencier les 2 types de
> conteneurs/déchets.
>
> Comme ça ?
> https://www.mapillary.com/map/im/r3-7eaUqvjER2K6KQCbIPg
>
> https://www.mapillary.com/map/im/Ml__GIf3g3bbILsmEWglsQ
>
> https://www.mapillary.com/map/im/lKjOCV-HlhHMnpFHH1tEYQ
>
>
> Pour les types de "clés" je n'en ai aucune idée. Je n'en possède pas
> moi-même.
>
> Stf
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Point d'apport volontaire, point de collecte, point de regroupement

[Jérôme Seigneuret]

>
> Ce qui serait bien pour les contributeurs OSM, c'est de normaliser les
> fichiers de données (un peu comme les parking).
> On pourrait ainsi avoir à terme un seul fichier national sur data.gouv.fr
>  :)
>
> Pour tous le monde car on aurait enfin un standard exploitable!
Avant d'avoir un seul fichier on peut définir une trame d'import et un
outil d'import comme pour le géocodeur data.gouv.fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Point d'apport volontaire, point de collecte, point de regroupement

[Jérôme Seigneuret]

 concernait que les ordures ménagères mais maintenant peut contenir des bacs
> de tri sélectif
>
C'est tous le dilemme... Où l'on va mettre la séparation...

>
> A noter que pour l'instant nous ne souhaitions pas aller au niveau de
> détail
> de la colonne mais bien de l’emplacement des points. Si on positionne une
> station service on va pas positionner pompe par pompe avec n° de référence
> de la pompe et type d'essence distribué, l’intérêt du POI station service
> c'est qu'un utilisateur puisse savoir où sont les stations services et quel
> essence il peut y trouver. On aimerait faire la même chose pour la collecte
> en recensant tous les points de collecte avec les flux de déchets que l'on
> peut y amener. L'idée étant de maintenir ces données à jours très
> fréquemment on va rester sur le point de collecte et on ne va pas descendre
> au niveau du contenant.
>
> J'attire votre attention sur le fait que sur 8000 point environ on en bouge
> environ 10 par jour pour la maintenance ou autre. Dans ce contexte
> référencer les numéros de série me semble peu pertinent.
>
Comme dit plus haut certains gèrent au site d'autre au contenant. Les
références dans ce cas sont visible. Nous nous en servant pour définir les
anomalies et les besoins de maintenance.

-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Point d'apport volontaire, point de collecte, point de regroupement

[Jérôme Seigneuret]

Le jeu. 14 mai 2020 à 13:09,  a écrit :

> Je ne crois pas qu'il faut y voir un parti pris idéologique : recycling
> suppose qu'il y a recyclage et mettre reycling et waste ensemble forme
> un oxymore. Et oui il y a de l'écoblanchiment pour certains à parler de
> recyclage là où il n'y en a pas.
>
Ok. C'est pour cela que je parle plus de conteneur dans un process
d'enlèvement pouvant rentrer dans un process de recyclage. Je pense
particulièrement à l'Amiante qui n'est pas recyclé mais qui peut pour les
particulier être admis en centre

>
> Je ne connais pas l'équivalent de répurgation en anglais. DeepL dit
> repurgation.
>
 Je ne te suis pas sur le sujet. Peux-tu me préciser tes pensées?

end of life ? Mais changer une clé très utilisée... avec en plus le
> problème que EOL a plusieurs significations et pas spécialement
> celle-là. Alors un avertissement sur le wiki pour signaler qu'il s'agit
> de la fin de vie en général, que le produit collecté soit effectivement
> recyclé ou pas ?
>
En fait dans le cycle de traitement c'est plutôt du oui non. C'est
recyclable ou pas. On a d'autre produit qui rentre dans des processus de
retraitement. On a par exemple à certains endroit des produits plastique
avec consigne de tri étendu prenant dans les plastique souple. Par contre
c'est une politique des fois des communes sans pour autant que les centres
soit en capacité de traiter et donc ça engendre un tri supplémentaire avec
un retour à l'enfouissement ou l’incinération. Bref la consigne de tri
étendu c'est pour 2022. On verra si tous les centres se sont adaptés

>
> Si ça vous sert de savoir quel système de préhension, pourquoi ne pas
> grip=hook, sucsion ... mais il faut se mettre d'accord sur la partie
> qu'on modélise : est-ce l'outil pour appréhender ou le côté statique.
>
En fait ce crocher permet de matérialiser le mode d'enlèvement et donc on
sait d'office que l'on est sur ce que l'on appel un PAV (Point d'Apport
Volontaire) et pour l'OMR on est surement sur un abus de langage. Bref dans
tous les cas c'est pas de l'apport volontaire mais du tri volontaire pour
une évacuation forcé (sauf pour les gens atteint du syndrome de Diogène)

>
> Décrire le côté statique c'est simple (la personne le voit, ici un
> anneau) ou pas (savoir comment est récupéré ce que j'aurais appelé une
> benne et que tu appelles un caisson, ce n'est pas évident).
>
On peut définir en effet le coté statique quand au mode de récupération
c'est par l'exemple sur le wiki que l'on peut le présenter ou à renseigner
par les gestionnaire public qui en ont la charge

>
> Tu nous fais une traduction jargon / noms pour béotiens francophones
> ou/et anglophones (Yves a bien commencé) et une proposition de schéma de
> tags "à la François" ?
>
Oui vu qu'Yves a aussi bien avancer sur le sujet je vais voir avec lui pour
y faire par d'un doc que l'on proposera à la communauté pour essayer de
compléter au mieux sans pour autant tous remettre en question

>
> Pour certains cas (les défibrillateurs par exemple) on met marque et
> modèle, ça c'est peut être facile à trouver et permet de compléter les
> autres attributs techniques a priori.
>
C'est possible mais dans ce cas il faudrait peut-être faire le lien avec
les fournisseurs (catalogue sur une page d'exemple) et avoir des photos
ouvertes faites par des contributeurs sur le terrain. Même chose aussi sur
les poteaux incendies.

>
> --
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Point d'apport volontaire, point de collecte, point de regroupement

[Jérôme Seigneuret]

> Le Groupe Nicollin  a une
>> page wikipedia.
>> Qui sont les autres sur les marches du podium ?
>>
>
Veolia, Sita, Paprec, Pizzorno, Bronzo, Urbaser, Sepur, Onyx, Brangeon et
(leurs filiales) et autres opérateurs privés locaux
Reste comme je disais plus haut tous les EPCI qui souhaitent utiliser OSM
comme outils de diffusion et d'exploitation de données publique comme c'est
le cas sur Montpellier Méditerranée Métropole

Je prends aussi l'exemple des bornes incendies en exemple car il y a bien
une richesse d'information que tous le monde ne mettra pas. Les interco en
ont la gestion et les SDIS les exploitent. Quel intérêt pour le publique
aujourd'hui ? Aucun sauf pour un point de RDV? ;-)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Point d'apport volontaire, point de collecte, point de regroupement

[Jérôme Seigneuret]

Le jeu. 14 mai 2020 à 11:38, Yves P.  a écrit :

>
> A ben @yves on peut dire que tu rebondis rapidement.
>
> Je ne suis pas fan de foot, mais je fais des efforts pour m'intégrer :D
>

> Pour le moment Nicollin donc environ une 50 aines de clients dans la
> collecte des déchets des particuliers avec autant de contraintes et de
> typicités en fonction des territoires.
>
> Le Groupe Nicollin <https://fr.wikipedia.org/wiki/Groupe_Nicollin> a une
> page wikipedia.
> Qui sont les autres sur les marches du podium ?
>
Je ne parle pas pour les autres mais je pense que tout organisme publique
dont l'intérêt et de présenter son parc et qui fait de OpenData a un
intérêt. Métropole de Montpellier, Toulouse, Nice, Paris ?!

>
>
> Bref si l'on si l'on veut exploiter correctement les données sur OSM
>>
>> qui ?
>>
> Je pense pas être le seul à chercher mes données sur OSM. C'est le cas de
> plein de métropole et la complétude des données fait que l'on peut
> exploiter ou non le système correctement pour le maintenir et pas avoir 3
> bases (client, opérateur, et prestataire GPS) pour fournir ces informations
>
>
> prestataire GPS : c'est quoi cette bête là ?
>
Aujourd'hui pour cité les principaux Simpliciti, Axians-Sysoco, Sulo, pro
tracking, Sinaps, Novacom sont des sociétés proposant de la géolocalisation
avec des informations enrichies pour l'exploitation du métiers de la
collecte et du nettoiement

>
> En Suisse et probablement ailleurs, il existe des conteneurs fermés. Il
> faut un badge ou un code pour y jeter son sac.
>
ça sert à calculer la taxe.
>
  Même principe en France dans certains contrats incluant la
redevance incitative

>
> Il existe aussi des sacs taxés. ils s'achètent dans les supérettes.
> Si on jette ses déchets avec un sac normal (non taxé) on peut-être dénoncé
> ;)
>
C'est bien la suisse ça ducoup ils viennent en France vider leurs ordures!

>
> En France, il y a des pesées lors de l'enlèvement du bac (le poids est
> associé au "tag" RFID collé sur le bac).
>
Oui est non. Il y a très peu de contrat basé sur le poids à la levé. ça
marche pas bien  il faut un temps plus important à la levé il faut taré les
pesons plus régulièrement. En clair ça a le mérite d'exister car il y a eu
une demande. çà augmente le nombre de dépôt sauvage et le vrac (sac mis
hors du bac

>
> Le revers de la médaille est que les "citoyens" jettent leurs déchets dans
> le bac du voisin, dans la nature et/ou de l'autre côté de la frontière.
>
Ben voilà
pour info :
https://www.ademe.fr/sites/default/files/assets/documents/tarification-incitative-conseils-et-retours-experience-8057.pdf

>
> Est-ce qu'il y a un besoin/intérêt à saisir ça dans OSM ?
> De même que la référence du conteneur (visible sur le bac) ?
>
Mettre les bacs RFID dans OSM non car ça serait vraiment comme mettre les
compteurs d'eau dans OSM (qui plus est on est sur le l'information
individuelle donc RGPD ...)


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


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Point d'apport volontaire, point de collecte, point de regroupement

[Jérôme Seigneuret]

>
>
>
> si un pro du domaine a envie de faire une proposition pour des tags
> renseignant le type exact de conteneur, leur crochet et leur mécanisme
> d'ouverture, j'ai rien contre, mais je crois que là on dépasse
> la capacité et surtout l'envie de la majorité d'entre nous.
>
> Un pro a déjà l'information dans son SIG ?
>
Oui comme tous les EPCI et syndicat ayant la gestion de ces informations!!!
c'est d'ailleurs à cela que l'on répond aux appels d'offre pour
dimensionner les moyens humains et matériels pour faire la collecte des
déchets

>
> Quel serait l'intérêt pour un pro, une collectivité, les citoyens que les
> contributeurs OSM référencent ça ?
>
Tous simplement la gestion du parc d'une part et la diffusion des
informations au usagers sans faire une couche dans une carte Google. Faire
un contrôle terrain en cas de changement d'opérateur de collecte lors des
renouvellement. Faire des cartes d'isochrones pour définir l'accessibilité
des colonnes aux usagers de manière à les répartir uniformément sur le
territoire. Faire une symbologie sur une Umap pour observer les
volumétries, comparer ça avec les fréquences de levées fourni par les
opérateurs de collecte etc. les usages sont sans fin comme pour chaque
métiers dont l'on fait une intégration dans OSM. Bref chacun voit midi à sa
porte et arrivera à en définir les besoins comme pour les PMR et
l’accessibilité aux colonnes.
Faire du PAV c'est aussi un investissement dans le temps.Evaluer son
implantation dans des conditions où il ne risque pas de tomber en panne
tous les mois faute de pluies c'est important (surtout pour des colonnes
OMR enterré) Pour reprendre tes arguments vers le PAV @Yves. Ma réaction
est plutôt simple : la volonté c'est bien mais la faisabilité c'est autre
chose (que ce soit des contraintes économiques car le parc de bacs est en
place et neuf ou parce que les réseaux enterrés ou les éléments naturelles
empêchent simple l'implantation de tel éléments) d'où la collecte en sac
qui existe encore en centre ville (Montpellier, Nîmes, Lunel et autres),
quartier huppé dans la ville de Le Chenay

__
> Yves
>
> Quelques photos dans Wikimedia Commons :
>
>- France :
>   - Category:Waste containers in Fontenay-sous-Bois
>   
> 
>   - Category:Waste containers in Yonne
>   
>- Suisse :
>   - Category:Sorted waste containers in Switzerland
>   
> 
>- Belgique :
>   - Category:Sorted waste containers in Belgium
>   
> 
>- Canada :
>   - Category:Sorted waste containers in Canada
>   
> 
>   - Category:Dumpsters in Canada
>   
>
> Sympa. Il y a de quoi compléter
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Point d'apport volontaire, point de collecte, point de regroupement

[Jérôme Seigneuret]

t déjà défini sur nos sites de
> commandes de produits et sur les catalogues de nos fournisseurs.
>
> La plupart des contributeurs OSM ne sont pas des professionnels du
> traitement des déchets ;)
>
C'est pareil pour l'electricité et l'eau... mais je suis d'accord qu'il
faut pas empécher de décrire les choses ou tous du moins on peut aussi
améliorer le wiki pour apporter les connaissances nécessaires. Je suis pas
spécialiste en éléctricité et je vais pas mettre les puissances quand je ne
les connais pas. Ici c'est le même cas de figure

>
> les bacs se lèves avec des chaises
> les colonnes avec un crochet par levé verticale
> les caisson avec un cochet à traction horizontale
> le mode de collecte est différents mais le contenu peut être similaire.
>
>
> J'ai essayé d'e trouver des exemples de ce qui existe.
> Je m'y perd un peu entre les termes français, canadiens.
> Si je comprends bien, une colonne peut-être en surface/aérienne, semi
> enterrées/enfouies ou enterrées/enfouies.
>
> colonne (appelé contenant de surface
> <https://durabac.net/fr/urbin/type/264-contenants-chargement-grue-plastique/267-surface>
>  au
> Canada) :
>
>- plastique : Citybulle
>
> <http://www.sulo.fr/fr/conteneurs-a-dechets/colonnes-aeriennes/colonne-classique.html>
>, Hubl’O
>
> <http://www.sulo.fr/fr/conteneurs-a-dechets/colonnes-aeriennes/item/179.html>…
>3 ㎥, 4 ㎥
>- métallique (anti feu !!) : C600
>
> <http://www.sulo.fr/fr/conteneurs-a-dechets/colonnes-aeriennes/item/182.html> 
> 2 ㎥
>à 5 ㎥
>- bois : PolyTri
>
> <https://www.polytri-stcm.com/produits/colonnes-bois/colonne-polytri-bois/> 2 
> ㎥
>à 7 ㎥
>
>
> caisson :
>
>- standard
>
> <http://www.carrosseriedelafrance.com/l-entreprise/qui-sommes-nous?page_id=1642=1=235>
>  6
>x 2.3 m - 8 à 35 ㎥
>- bac Ecobac
>
> <https://www.carrosseriedelafrance.com/nos-produits/caissons-amovibles?categories=7=241>
>  5
>à 10 ㎥ (c'est une colonne ?)
>
> C'est au caisson fermé qui se lève avec un simple crochet

>
> conteneur semi enfoui (avec toujours un sac souple de levage ?) :
>
>- Totem
><https://www.totemconteneurs.com/produits/conteneurs-semi-enfouis/> 1.3 ㎥,
>3 ㎥, 5 ㎥   - Canada
>- Molok - France, Finlande, Canada
>   - MolokClassic
>   <https://www.molok.com/fr/molok-produits/molokclassic> 0.8 ㎥,
>   1.3 ㎥, 2 ㎥, 3 ㎥, 5 ㎥
>   - MolokDomino <https://www.molok.com/fr/molok-produits/molokdomino> 2 ㎥,
>   3 ㎥, 5 ㎥
>- Urbin
>
> <https://durabac.net/fr/urbin/type/264-contenants-chargement-grue-plastique/266-semi-enfouis>
>  0.8 ㎥,
>1.3 ㎥, 3 ㎥, 5 ㎥ - Canada
>
> En effet les Molok on en lève pas mal et c'est aussi ce que l'on trouve
sur les autoroute

>
> conteneur complètement enfoui :
>
>- CCE-5000
>
> <https://durabac.net/fr/urbin/fiche/312-contenants-enfouis-chargement-grue/321-contenants-enfouis/236-cce-5000-litres-enfoui>
>  5 ㎥ -
>Canada
>
>
> préhension :
>
>- crochet (un simple anneau
>
> <http://www.sulo.fr/images/stories/flexicontent/item_179_field_46/original/conteneur-plastic-omnium-colonne-aerienne-hublo-08-fr.jpg>
>  sur
>le bac)
>- Kinshofer
>
> <https://www.kinshofer.com/fr/grue-3/recyclage-des-dechets/appareils-pour-vidage-de-conteneurs?pid=4>
> : champignon
>
> <http://www.sulo.fr/images/stories/flexicontent/item_179_field_46/original/plastic-omnium-colonnes-aeriennes-hublo-produit-06.jpg>
> et double crochet
>
> <https://www.carrosseriedelafrance.com/wp-content/uploads/2018/caissons/06-BACS-ET-CONTENEURS/2-ECOBAC%2010M3.JPG>
>
> Bien vu

>
>-
>
> sonde de télérelevage
> <https://www.le-gresivaudan.fr/cms_viewFile.php?idtf=5697=06/5697_515_Prescriptions-techniques-implantation-PAV-aeriens-VF.pdf>
>  :
> système de détection du taux de remplissage des colonnes aériennes. Il
> contribue à la connaissance en temps réel du niveau de remplissage de
> chaque borne.
>
;-)

>
>
> Si l'on veut intégrer un processus métier qu'on le face mais faudrait
> arrêter d'y mettre des contraintes idéologiques à chaque fois.
>
> +1
>
> C'est qu'un exemple et c'est loin d'être complet vu les types de colonnes
> et de conteneur existant (enterré, semi-enterré ou aériens)
>
> cf. supra
>
> il existe aussi des systèmes d'apport sur Paris à aspiration pneumatique.
> Et ça c'est pas classable aujourd'hui et il n'y a pas d'enlèvement vu que
> ça marche par aspiration…
>
> On peut quand même taguer ça avec amenity=recycling +
> recycling_type=container + location=underground ?
>
En effet mais il n'y aura pas de préhension. Donc plutôt un mode de
collecte par succion

Le recyclage rentre dans un modèle économique. C'est comme si on avait mis
en clé principale que les énergie verte pour les panneaux solaire...
Pour le verre on a aussi des systèmes de consignes c'est pas pour autant
qu'on à mis les appareils de récupération en recycling=*

-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Point d'apport volontaire, point de collecte, point de regroupement

[Jérôme Seigneuret]

Le mer. 13 mai 2020 à 18:31, Yves P.  a écrit :

> amenity=recycling+recycling_type=container ne dit en aucun cas que c'est
> une colonne
>
> amenity=recycling + recycling_type=container + location=underground le dit
> ;)
>
C'est donc bien ce que je dis dans l'exemple que tu cites en exemple ce
n'est pas une colonnes en enterrée mais des bacs enterrés à
levé hydraulique qui se lève avec une BOM classique
les types c'est : bacs roulant, caisson, colonnes. Ce sont des
dénominations données à des typologies plus précises qui sont en lien avec
un mode de levage également
C'est ces données que l'on exploite dans nos référentiels.

Si l'on se base donc sur recycling il y a bien tous les flux possible dont
l'OMR (ou DIB pour les pro) en terme de flux. On est sur un problème de
connaissance et d'identification terrain faute de détails ou de
connaissance métier.

Peut-on considérer dans recycling tous les flux? La réponse est oui!
d'ailleur l'insinération des déchets rentre dans le process de recyclage
mais pas dans le recyclage circulaire comme certains peuvent l'entendre.

De toute façon un produit mis en conteneur quel qu'il soit ne veut pas dire
qu'il rentrera dans un process de recyclage. Il est enlevé avec un type de
moyen adapté au mode de conteneurisation pour aller vers un centre de
transfert, de stockage, de traitement ou d'enfouissement. Si il y a des
erreurs de tri par exemple ça repart à l'enfouissement ou l’incinération.
En soit les conteneurs ne sont la que pour définir un mode de tri et non de
recyclage en vu d'un enlèvement. D'ailleurs les professionnels doivent
maintenant faire le tri à la sources et les opérateurs de collecte s'adapte
(ou on fait du lobbing) pour aller chercher les gisement à la source.

Bref si l'on si l'on veut exploiter correctement les données sur OSM il va
falloir arrêter de vouloir faire ça avec des clés différentes pour des
gisements qui sont normalement traités et collectés avec des contenants et
du matériel qui lui est similaire. Sinon c'est que la clé principale elle
n'est plus adaptées à nos besoins.

Aujourd'hui si l'on accepte pas l'OM dans dans recycling_type=container je
vois pas à quoi sert cette clé. vaudra mieux tous mettre en
waste_disposal et dire que le type de contenant est un bac une colonne ou
un caison avec sa volumétrie en m3 ou en litres comme c'est déjà défini sur
nos sites de commandes de produits et sur les catalogues de nos
fournisseurs.

les bacs se lèves avec des chaises
les colonnes avec un crochet par levé verticale
les caisson avec un cochet à traction horizontale
le mode de collecte est différents mais le contenu peut être similaire.

Si l'on veut intégrer un processus métier qu'on le face mais faudrait
arrêter d'y mettre des contraintes idéologiques à chaque fois. Le recyclage
ça veut pas dire que c'est circulaire.


> Cf. https://wiki.openstreetmap.org/wiki/Tag:amenity=recycling#Examples
>

C'est qu'un exemple et c'est loin d'être complet vu les types de colonnes
et de conteneur existant (enterré, semi-enterré ou aériens)
il existe aussi des systèmes d'apport sur Paris à aspiration pneumatique.
Et ça c'est pas classable aujourd'hui et il n'y a pas d'enlèvement vu que
ça marche par aspiration...

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

Re: [OSM-talk-fr] Point d'apport volontaire, point de collecte, point de regroupement

[Jérôme Seigneuret]

Bonjour,

*waste_basket *c'est des cobeilles de propreté ou des anneaux avec sac
(poubelle de rue sur poteau ou en pied, ou murale)

On se retrouve avec un problème car sur les *waste_disposal *on peut aussi
avoir du recyclable ou non.
de toute façon on peut spécifier le type de produit. C'est pour moi du bac
roulant en point fixe et non de la colonne avec une préhension par crochet.
qui plus est contrairement à une colonne l'accès y est plus restreint.
(quoi qu'avec la redevance incitative et les colonnes en accès par badge
change la donne)


   - waste <https://wiki.openstreetmap.org/wiki/Key:waste>=* to specify the
   type of waste.
   - access <https://wiki.openstreetmap.org/wiki/Key:access>=* to specify
   the access. Mapping of objects unverifiable by general public is
   discouraged.
   - fee <https://wiki.openstreetmap.org/wiki/Key:fee>=* to specify if a
   fee is payable.
   - operator <https://wiki.openstreetmap.org/wiki/Key:operator>=* to
   specify the operator.
   - capacity <https://wiki.openstreetmap.org/wiki/Key:capacity>=* *to
   specify the capacity in m3 attention en France les bacs sont en litres les
   colonnes en m3*



Aujourd'hui on a donc un réel problème sur les colonnes OM au vu du
descriptif vu que cela exclut les colonnes OM
amenity=recycling+recycling_type=container. Il faut savoir qu'au USA ce
mode est inexistant pour l'OM

Je pense qu'il faut vraiment limiter l'usage ou catégoriser autrement car
une colonne en soit c'est un waste_disposal

waste_disposal c'est un moyen de stockage des déchets en vu de leur
enlèvement... qu'ils soient recyclables ou non.
si l'on veut repartir la dessus il y a donc quelque élément en plus à
prendre en compte
la préhension
type de conteneur

amenity=recycling+recycling_type=container ne dit en aucun cas que c'est
une colonne mais que c'est une commodité servant au recyclage dont le type
n'est pas un centre mais un conteneur
c'est donc clairement spécifique au type de traitement et non au fait
d'évacuer et de retraiter un flux


Le mer. 13 mai 2020 à 14:49, Yves P.  a écrit :

>
> on en avait parlé il y a peu, bin=yes me semble plus cohérent.
>
> bin=yes <https://wiki.openstreetmap.org/wiki/Key:bin> en tag secondaire
> ou amenity=waste_basket
> <https://wiki.openstreetmap.org/wiki/Tag:amenity=waste_basket> en tag
> principal, c'est la poubelle de contenance 30 l.
> ça ne correspond pas :/
>
> ça serait plutôt amenity=waste_disposal
> <https://wiki.openstreetmap.org/wiki/Tag:amenity=waste_disposal>.
>
> mais doit-on changer de tag principal parce que la poubelle est ronde,
> carrée, verte ou bleu ?
> et aussi parce que les utilisateurs mélangent leurs déchets, ne trient pas
> … ?
> ;)
>
> En pratique c'est le même camion avec la même grue qui vide ces conteneurs.
> Je me simplifie la vie : un seul tag (grosse poubelle, petite poubelle).
>
> __
> Yves
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] adresse des POI et numéro de rue - était [Ça reste ouvert] Ne pas ajouter les commerces sur les numéros de rue

[Jérôme Seigneuret]

ends "contact:*" comme des informations pour
> > communiquer, par pour de la géolocalisation: Mon entreprise à 2 locaux
> > (bureau, livraison) mais un seul point de contact (accueil, courrier,
> > téléphonique).
>
> Ça ne me choque pas
>
> > La route est longue mais la voie est libre ; m'enfin il faudrait tout
> > de même trouver un consensus :-)
>
> Une liste avec avantages/inconvénients ?
>
> cordialement
>
> leni
>
> >
> > Cyrille37.
> >
> >
> > ___
> > 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
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] France Bleu Poitou/La Rochelle cherche des contributeurs OSM

[Jérôme Seigneuret]

Bonjour, pour ma part j'ai fait une diffusion au travers des Facebook des
EPCI de mon territoire quand s'était possible.

Le mar. 31 mars 2020 à 13:27, Matthieu Godet via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

>
> > Message: 2
> > Date: Tue, 31 Mar 2020 11:31:20 +0200
> > From: Philippe Verdy 
> > To: Discussions sur OSM en français  
> > Cc: Matthieu Godet 
> > Subject: Re: [OSM-talk-fr] France Bleu Poitou/La Rochelle cherche des
> >   contributeurs OSM
> > Message-ID:
> >5no0dkauw88xs0z...@mail.gmail.com>
> > Content-Type: text/plain; charset="UTF-8"
> >
> > twit inexistant...
> Merci Pierre pour ton retour,
>
> Je te réponds ici afin que ça soit visible, la journaliste en question
> ne cherche plus de témoignage, elle a rapidement enlevé son tweet,
> réponse reçue hier soit :
> "Merci à vous, ça représente pas mal de témoignages déjà" (22:38)
>
> J'ai eu d'autres retours en privé je tiens à saluer l'ensemble des
> personnes qui ont répondu présentes.
> > Message: 4
> > Date: Tue, 31 Mar 2020 11:40:53 +0200
> > From: Jacques Lavignotte 
> > To: Matthieu Godet via Talk-fr 
> > Subject: Re: [OSM-talk-fr] France Bleu Poitou/La Rochelle cherche des
> >   contributeurs OSM
> > Message-ID: 
> > Content-Type: text/plain; charset=utf-8; format=flowed
> >
> > J'ai fait ce que j'ai pu...
> >
> > Voici la trame que je lui ai proposé :
> >
> >
> > Je partitipe au projet OpenstreetMap depuis 2013 et je vis dans la
> > région de Poitiers
> >
> > Je bénévole dans le projet Openstreetmap car c'est un dispositif
> > technique (j'ai un goût pour la technique), collaboratif et démocratique
> > qui participe à la mise en commun de données géographiques.
> >
> > Dans le cadre de l'opération de crise CARESTEEOUVERT, comme simple
> > citoyen je me renseigne sur place lors de mes rares sorties auprès de
> > commerces locaux : j'ai  commencé mercredi dernier par la pharmacie
> > voisine qui m'a indiqué ne pas avoir modifié ses horaires. Sur la carte
> > de CARESTEOUVERT comme tout client des commerces peut le faire, j'ai
> > trouvé la pastille grise de la pharmacie et j'ai renseigné les horaires
> > dans le petit formulaire qui s'ouvre : j'ai noté horaires inchangés.
> >
> > Sur mon chemin, une boulangerie dont j'ai noté les horaires qui eux
> > avaient changé.
> >
> >
> > Rentré chez moi, j'ai appelé un autre commerce au téléphone et Hop ! Sur
> > la carte CARESTEEOUVERT lui aussi.
> >
> > Là j'ai fait mon boulot de piétion cartographe citoyen, celui que tout
> > le monde peut faire, lors de ses rares sorties ou par téléphone.
> >
> >
> >
> > Ensuite, comme cartographe OpenStreetMap bien calé dans son son fauteuil
> > : j'ai intégré les trois commerces dans la base de données OSM : c'est
> > facile pour quelqu'un d'un peu expérimenté, juste un peu de technique et
> > désormai les horaires actualisés des trois commerces sont disponibles au
> > grand public.
> >
> > Un peu plus tard, j'ai contacté un pharmacien de mes amis, lui ai parlé
> > du projet. Avec moi au téléphone, il a utilisé "caresteouvert" depuis
> > son ordinateur et moins de 3 heures après un mappeur que je ne connais
> > pas a intégré la modification. Cette pharmacie est maintenant à jour.
> >
> >Le pharmacien qui a des resposabilité syndicales à l'échelon régional
> > a décidé de parler du projet à son organisation professionnelle pour les
> > inciter à participer à CA RESTEOUVERT. C'était samedi. Je vois
> > aujourd'hui que presque1500 pharmacies (1483 le 31/3 à 11:29) on mis à
> > jour leurs horaires dans le cadre du confinement COVID 19
> >
> > Depuis, à temps perdu, comme des centaines de bénévoles, toujours de mon
> > fauteuil de cartographe OpenStreetMap j'intègre les modifications
> > d'horaires créées par les simples citoyens qui participent.
> >
> > En pendant ce temps les informaticiens de l'association améliorent les
> > programmes en temps réel pour faire face à l'afflux de données et rendre
> > plus ergonomique le dispositif.
> >
>
> Merci Jacques pour ton retour très complet, je suis certain que ça
> plairait si on pouvait d'une façon ou d'une autre en parler sur les
> contributions locales et le bouche-à-oreille qui fait son effet !
>
> Je viens de recevoir fin de matinée une proposition d'interview (pour cet
> après-midi), j'aimerais y proposer a minima de saluer les contributeurs, le
> projet "ça reste ouvert" et aussi les quelques associations que j'ai à ma
> connaissance (Rochelug pour La Rochelle,  APP3L pour Poitiers, GEBULL pour
> le Nord Deux-Sèvres).
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Contribution pour ajouter les marchés ouvert, exploitations agricoles et horticoles suite à décision préfectorales, municipales

[Jérôme Seigneuret]

Bonjour,
J'ouvre ce sujet pour les marché dont voici les informations pour le Gard
et l'Hérault

Voici une liste des marchés ouvert pour la préfecture du Gard

http://www.gard.gouv.fr/Actualites/Mesures-generales-pour-faire-face-a-l-epidemie-COVID-19-dans-le-cadre-de-l-etat-d-urgence-sanitaire?fbclid=IwAR3p9ZZwDackSsLSsafVacfIw3kXmiko6b8hYbR9aXZbtHtBh04t7usikX8


J'ai pas trouvé d'info pour l'Hérault

Parcontre il y a des infos pour la filière agricole

https://herault.chambre-agriculture.fr/actualites/detail-de-lactualite/actualites/les-regles-se-precisent-pour-les-agriculteurs-des-differentes-filieres-horticulteurs-manadiers/


Je pense que l'on peut trouver les même infos pour l'ensemble des
départements

On peut regrouper les infos concernant ces sujets ici pour apporter nos
contributions.

-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Adresses uniformisation d'écriture des extensions

[Jérôme Seigneuret]

Ouai après je me base pas que sur de la données "terrain". On a des bases
pour nous données ces infos avec l'adresse 16B (dans la couche BANO)

dizaine, le coté par une unité, et "16A2G" devenait la plaque de porte
"16-00122"!
On va faire comme les russes avec une numérotation  48A k2 s1


Le lun. 30 mars 2020 à 11:47, Philippe Verdy  a écrit :

> La résidence n'est pas toujours nommée. J'ai habité dans une
> copropriété près de Paris, qui avait un même accès public au numéro
> "16" pour:
>
> - un immeuble en façade de rue avec plusieurs escaliers (16A, 16B)
> (ensuite les appartements étaient numérotés par étage et côté.Mais
> seul le "16A" était accessible directement depuis la rue, pour le 16B
> il fallait entrer au "16A" et utiliser un couloir commun.
> - deux maisons individuelles (avec étages) avec un jardin privatif
> derrière une cour commune, numérotées "16 Bis" et 16 Ter"; leur accès
> se faisait par le couloir commun aux 16A et 16B.
> - toutes les boîtes aux lettres étaient regroupées dans le couloir
> commun. L'accès commun depuis la rue était marqué "16", mais le "16A"
> aussi pour l'accès direct à un des escaliers depuis l'extérieur, les
> "16B", "16 Bis" et "16Ter" n'étaient pas visibles depuis la voie
> publique ! Pour les télécoms, il y avait des plaques en bas des portes
> indiquant une autre numérotation des logements individuels (pas la
> même pour les boites aux lettres et la poste qui eux suivaient la
> numérotation du règlement de copropriété visé aussi aux actes
> notariés)  ; la numérotation était pourtant différente également pour
> les eaux, l'électricité, puis ensuite le câble TV, chaque fournisseurs
> ayant créé la sienne sans consulter la copropriété ou parce que cela
> ne correspondait pas à leurs formats supportés dans leurs fichiers :
> ils auraient eux des numéros comme "16A2G" pour "2ème étage, porte
> gauche, escalier A de l'immeuble au 16"; France Telecom a préféré
> remplacer la lettre par un chiffre de centaines, l'étage par une
> dizaine, le coté par une unité, et "16A2G" devenait la plaque de porte
> "16-00122"!
>
>
> Le lun. 30 mars 2020 à 11:23, Jérôme Seigneuret
>
>  a écrit :
> >
> > Merci Philippe,
> > Je préciserai ça.
> > Mais en principe, comme tu le dis, il y a déjà un A et une résidence
> nommé (ou pas). A B etc. Correspond au bâtiment ou à une entrée. C'est un
> point de vigilance à signaler.
> >
> >
> > Le lun. 30 mars 2020 à 11:12, Philippe Verdy  a écrit
> :
> >>
> >> Attention aux adresses comme "2B" qui ne sont PAS des "2 Bis" (il y a
> >> des cas avec "2A", "2B", "2C" pour un groupe d'adresses d'une même
> >> résidence au "2"..., puis ensuite "2 Bis" complètement séparé du
> >> "2B").
> >> Donc attention aux corrections automatiques de numéros lettrés
> >> (surtout avec la lettre B) qui ne vérifient pas au minimum le
> >> voisinage !
> >>
> >> Le lun. 30 mars 2020 à 09:24, Jérôme Seigneuret
> >>  a écrit :
> >> >
> >> > Bonjour,
> >> >
> >> > Je vois que sur OSM il y a pas mal d'adresses importées en B T Q 5 6 7
> >> > d'autre  sont écrits en minuscules accolé au chiffre ou non
> >> >
> >> > Comment écrire proprement cette extension ?
> >> >
> >> > Personnellement je remplace ces éléments en terme complet écrit de la
> manière suivante comme on le fait aussi pour les références routières:
> >> >
> >> > 00 Xxx
> >> >
> >> > 10 Bis
> >> > 10 Ter
> >> > 10 Quater
> >> > 10 Quiquies
> >> > 10 Sexies
> >> > 10 Septies
> >> >
> >> > La suite https://fr.wikipedia.org/wiki/Adverbe_multiplicatif
> >> >
> >> >
> >> > 10B > 10 Bis
> >> > 10 bis > 10 Bis
> >> > 10Bis > 10 Bis
> >> > ...
> >> >
> >> > exemple de double écrire pour une même adresse
> >> >
> >> > http://overpass-turbo.eu/s/S4c
> >> >
> >> >
> >> >
> >> > --
> >> > Cordialement,
> >> > Jérôme Seigneuret
> >> > ___
> >> > 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
> >
> >
> >
> > --
> > Cordialement,
> > Jérôme Seigneuret
> > ___
> > 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
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Adresses uniformisation d'écriture des extensions

[Jérôme Seigneuret]

Merci Philippe,
Je préciserai ça.
Mais en principe, comme tu le dis, il y a déjà un A et une résidence nommé
(ou pas). A B etc. Correspond au bâtiment ou à une entrée. C'est un point
de vigilance à signaler.


Le lun. 30 mars 2020 à 11:12, Philippe Verdy  a écrit :

> Attention aux adresses comme "2B" qui ne sont PAS des "2 Bis" (il y a
> des cas avec "2A", "2B", "2C" pour un groupe d'adresses d'une même
> résidence au "2"..., puis ensuite "2 Bis" complètement séparé du
> "2B").
> Donc attention aux corrections automatiques de numéros lettrés
> (surtout avec la lettre B) qui ne vérifient pas au minimum le
> voisinage !
>
> Le lun. 30 mars 2020 à 09:24, Jérôme Seigneuret
>  a écrit :
> >
> > Bonjour,
> >
> > Je vois que sur OSM il y a pas mal d'adresses importées en B T Q 5 6 7
> > d'autre  sont écrits en minuscules accolé au chiffre ou non
> >
> > Comment écrire proprement cette extension ?
> >
> > Personnellement je remplace ces éléments en terme complet écrit de la
> manière suivante comme on le fait aussi pour les références routières:
> >
> > 00 Xxx
> >
> > 10 Bis
> > 10 Ter
> > 10 Quater
> > 10 Quiquies
> > 10 Sexies
> > 10 Septies
> >
> > La suite https://fr.wikipedia.org/wiki/Adverbe_multiplicatif
> >
> >
> > 10B > 10 Bis
> > 10 bis > 10 Bis
> > 10Bis > 10 Bis
> > ...
> >
> > exemple de double écrire pour une même adresse
> >
> > http://overpass-turbo.eu/s/S4c
> >
> >
> >
> > --
> > Cordialement,
> > Jérôme Seigneuret
> > ___
> > 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
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Adresses uniformisation d'écriture des extensions

[Jérôme Seigneuret]

Ok je vais mettre ça sur le wiki afin d'en définir ce que l'on souhaite
avoir en base.
Je vais ajouter la requête overpass d'Antoine pour trouver les adresses à
vérifier

Le lun. 30 mars 2020 à 10:22, Romain MEHUT  a
écrit :

> Bonjour,
>
> Un avis de Christian ici
> https://forum.openstreetmap.fr/viewtopic.php?f=2=3260=12213=bis#p12213
>
> Romain
>
> Le lun. 30 mars 2020 à 09:24, Jérôme Seigneuret <
> jerome.seigneu...@gmail.com> a écrit :
>
>> Bonjour,
>>
>> Je vois que sur OSM il y a pas mal d'adresses importées en B T Q 5 6 7
>> d'autre  sont écrits en minuscules accolé au chiffre ou non
>>
>> Comment écrire proprement cette extension ?
>>
>> Personnellement je remplace ces éléments en terme complet écrit de la
>> manière suivante comme on le fait aussi pour les références routières:
>>
>> 00 Xxx
>>
>> 10 Bis
>> 10 Ter
>> 10 Quater
>> 10 Quiquies
>> 10 Sexies
>> 10 Septies
>>
>> La suite https://fr.wikipedia.org/wiki/Adverbe_multiplicatif
>>
>>
>> 10B > 10 Bis
>> 10 bis > 10 Bis
>> 10Bis > 10 Bis
>> ...
>>
>> exemple de double écrire pour une même adresse
>>
>> http://overpass-turbo.eu/s/S4c <https://t.co/b6wN4n7L8K?amp=1>
>>
>>
>>
>> --
>> Cordialement,
>> Jérôme Seigneuret
>> ___
>> 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
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] caresteouvert problème géocodeur

[Jérôme Seigneuret]

Le voici ;-)
https://github.com/osmontrouge/caresteouvert/issues/74

Le lun. 30 mars 2020 à 10:12, PanierAvide  a écrit :

> Bonjour Jérôme,
>
> Merci de ce retour, si tu as possibilité de nous faire un ticket sur le
> dépôt GitHub ce serait top, ça facilite grandement la répartition des
> tâches pour l'équipe ;-)
>
> https://github.com/osmontrouge/caresteouvert/issues
>
> Cordialement,
>
> Adrien P.
>
> Le 30/03/2020 à 10:07, Jérôme Seigneuret a écrit :
>
> Bonjour,
>
> J'ai remarqué qu'au 4ème espace le géocodeur ne fourni plus de résultat
> sur l'auto complétion et ducoup celui-ci ne retourne rien si l'on valide
> une recherche qui n'est pas proposé. C'est possible de corriger cela?
>
> Il faudrait aussi limiter les résultats des recherches à la France vu que
> les données d'ouverture sont limitées à ce territoire.
>
> --
> Cordialement,
> Jérôme Seigneuret
>
> ___
> 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
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] caresteouvert problème géocodeur

[Jérôme Seigneuret]

Bonjour,

J'ai remarqué qu'au 4ème espace le géocodeur ne fourni plus de résultat sur
l'auto complétion et ducoup celui-ci ne retourne rien si l'on valide une
recherche qui n'est pas proposé. C'est possible de corriger cela?

Il faudrait aussi limiter les résultats des recherches à la France vu que
les données d'ouverture sont limitées à ce territoire.

-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Isodistance 1 km

[Jérôme Seigneuret]

Les mentons sont en bas de page

Jeux de donnéesLe site carte-sortie-confinement.fr utilise la cartographie
OpenStreetMap <https://www.openstreetmap.org/> et l'API Leaflet
<https://leafletjs.com/> pour la cartographie ainsi que l'API de la Base
Adresse Nationale
<https://www.data.gouv.fr/fr/datasets/base-adresse-nationale/> pour
géolocaliser les adresses.

Le lun. 30 mars 2020 à 08:21, Philippe Verdy  a écrit :

> Ici il s'agit d'une simple "capture d'écran", hébergée sur le site Le
> Bien Public directement à titre d'exemple illustratif. On est dans les
> limites du droit de citation dans la presse. Cela n'impacte pas les
> ressources serveurs et réseaux d'OSM, et la carte fixe n'a pas d'usage
> généralisé car elle n'est pas navigable et a une résolution limitée
> (et on ne peut pas zoomer dessus pour voir le détail des données).
>
> Ce qui compte alors est que cette image est totalement liée à
> l'article qui l'utilise. Et là, concernant les illustrations de
> presse, c'est l'usage de faire une mentions d'attribution sur une page
> dédiée du titre de presse et pas pour chaque illustration. Il suffit
> de voir les photos venant des agences de presse: le titre mentionne
> ses sources d'agences dans un carré d'infos légales, et sur Internet
> cela se traduit par la page de mentions légales (qui cependant devrait
> être à jour pour chaque édition! sur Internet dont le contenu change
> sans arrêt, il est effectivement plus simple de gérer ça mention par
> mention avec un petit indicateur pour chaque illustration ou dans
> l'illustration elle-même et je pense qu'ils auraient du éviter de
> couper la mention en faisant leur copie d'écran: à eux de dimensionner
> la fenêtre pour qu'elle soit conservée, ou à eux de la rajouter en cas
> de rognage)...
>
> Même chose sur https://carte-sortie-confinement.fr/ (le site cité par
> Le Bien Public ou France 3) où la première carte d'exemple est fixe.
>
> Mais si on recherche la zone, on tombe sur la vraie carte demandée, où
> il y a bien les mentions nécessaires.
>
> Il ne semble pas en revanche légalement nécessaire dans le cas des
> illustrations simples non navigables dans la presse d'ajouter un lien
> navigable vers OSM, tant qu'au moins OSM est crédité et que par
> ailleurs la page de mentions légales détaille un peu plus les sources.
> D'ailleurs la presse imprimée ne peut mettre ces liens sur chaque
> photo (a-t-on sur la page "copyright" un exemple de QRCode utilisable
> à la place du lien pour les illustrations à imprimer? Et expliquant
> que ce QRcode ne doit contenir qu'une URL vers le site officiel de
> licence et pas via un site redirecteur tiers)
>
> Le dim. 29 mars 2020 à 09:01, Dlareg  a écrit :
> >
> > Le 29/03/2020 à 08:56, Jean-Claude Repetto a écrit :
> > > Bonjour,
> > >
> > > Le géoportail IGN permet de visualiser la zone accessible à moins de 1
> > > km de chez soi. Existe-t-il un service équivalent basé sur OSM ?
> >
> > Oui il existe  https://carte-sortie-confinement.fr/
> >
> > Par contre je voudrais pas avoir l'air de chipoter mais dans les
> > mentions légales
> > il y a bien un lien vers OSM :
> > https://carte-sortie-confinement.fr/mentions-legales.php
> >
> > Par contre il n'y a pas de mention de la licence ni du crédit « © les
> > contributeurs d’OpenStreetMap ».
> >
> > J'ai interpeller Le Bien Public et France3 sur Twitter car sur leur
> > capture d'écran il n'y a pas non plus la licence :
> >
> >
> https://www.bienpublic.com/sante/2020/03/26/limite-de-1-km-du-confinement-jusqu-ou-pouvez-vous-aller-depuis-chez-vous
> >
> >
> https://france3-regions.francetvinfo.fr/bourgogne-franche-comte/carte-coronavirus-covid-19-deplacements-1-km-mon-domicile-ca-m-emmene-1806030.html
> >
> > >
> > > Jean-Claude
> > >
> > > ___
> > > Talk-fr mailing list
> > > Talk-fr@openstreetmap.org
> > > https://lists.openstreetmap.org/listinfo/talk-fr
> >
> >
> > --
> > Dlareg
> >
> > ___
> > 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
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Adresses uniformisation d'écriture des extensions

[Jérôme Seigneuret]

Bonjour,

Je vois que sur OSM il y a pas mal d'adresses importées en B T Q 5 6 7
d'autre  sont écrits en minuscules accolé au chiffre ou non

Comment écrire proprement cette extension ?

Personnellement je remplace ces éléments en terme complet écrit de la
manière suivante comme on le fait aussi pour les références routières:

00 Xxx

10 Bis
10 Ter
10 Quater
10 Quiquies
10 Sexies
10 Septies

La suite https://fr.wikipedia.org/wiki/Adverbe_multiplicatif


10B > 10 Bis
10 bis > 10 Bis
10Bis > 10 Bis
...

exemple de double écrire pour une même adresse

http://overpass-turbo.eu/s/S4c <https://t.co/b6wN4n7L8K?amp=1>



-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] zone résidentielle dans une zone résidentielle ?

[Jérôme Seigneuret]

Une relation c'est deux éléments ou plus. On a un modèle zonage pour
pourrait tout traiter a partir de limite commune ou de deux linéaire s
ayant des valeurs différentes mais permettant d'identifier des zones. En
opposition il y a les objets simples qui une fois fermés forment
naturellement un zone.

Le dim. 16 févr. 2020 à 13:10, Stéphane Péneau 
a écrit :

> Une relation pour délimiter un ensemble de 8 maisons ? Je suis le seul à
> trouver ça un peu tordu ?
>
> Stf
>
>
> Le 05/02/2020 à 21:58, osm.sanspourr...@spamgourmet.com a écrit :
>
> https://www.openstreetmap.org/relation/10060749#map=19/47.78699/-3.48688
>
> Le Prat et Les Jardins de Vitalis sont deux lotissements jointifs. Et tu
> pourrais les englober dans des place de plus haut niveau.
>
> Ils font partie du landuse=residential de la zone agglomérée du bourg de
> Guidel.
>
> On ne mélange pas l'utilisation (landuse) des dénominations (ici Le Prat
> et Les Jardins de Vitalis) qui ont leur vie propre si j'ose dire.
>
> Jean-Yvon
> Le 05/02/2020 à 21:26, Arnaud Champollion -
> arnaud.champoll...@linux-alpes.org a écrit :
>
> Le 05/02/2020 à 21:23, pepilepi...@ovh.fr a écrit :
>
> Pourquoi tu veux faire ça ? Si c'est juste pour le nommer il y a
> place=neighbourhood
> ...
>
> Bonne soirée,
>
>
> Justement je ne veux pas le faire.
>
> Je suis tombé dessus car il y a plusieurs zones mappées ainsi à Digne les
> Bains.
>
> Je me suis dit que ça n'avait pas l'air normal, mais je voulais m'en
> assurer avant de supprimer ou remplacer par un tag plus adapté.
>
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://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] Tagger correctement les panneaux entrées de villes & villages

[Jérôme Seigneuret]

Bien joué 


Le ven. 14 févr. 2020 à 19:48,  a écrit :

> Bonsoir,
>
> ça y est, nous avons fini la journée de Cartopartie à tagger les panneaux
> d'entrée et de sorties de villes du Gers.
> 966 panneaux ont été créés.
>
> Voici la requette Overpass Turbo pour consulter les données:
>
> [out:json][timeout:25];
> // Définir la zone de recherche:
> {{geocodeArea:"Gers"}}->.dept;
> ( // Prospecter pour les noeuds, chemins et relation
> node["traffic_sign:forward"="city_limit"](area.dept);
> node["traffic_sign:backward"="city_limit"](area.dept);
> node["traffic_sign"="city_limit"](area.dept);
> node["traffic_sign"="city_limit,FR:EB10"](area.dept);
> node["traffic_sign"="city_limit,FR:EB20"](area.dept);
> );
> // Afficher les résultats:
> out body;
> >;
> out skel qt;
>
>
> Je dois encore vérifier et corriger quelques petites choses pour voir s'il
> n'y a pas d'erreurs.
> Je compléterais également la doc OSM.
>
> Nous n'avons pas tant utilisés le tag traffic_sign:forward car certains
> étudiants n'étaient pas forcément à l'aise avec le sens du tracet, etc.
>
> Merci à tous ceux qui m'ont aidé à préparé et débrousailler ce travail!
>
> Bonne soirée,
>
> Onésime.
>
> --
> *De: *onesim...@free.fr
> *À: *"Discussions sur OSM en français" 
> *Envoyé: *Jeudi 13 Février 2020 23:26:01
> *Objet: *Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de
> villes & villages
>
> Bonsoir,
>
> Ok, merci pour cette précisions.
> Je vais voir comment ça se passe.
> Et si jamais c'est trop compliqué de tagger directement dans OSM, est ce
> qu'on peut transmettre le fichier shapefile avec les données, et les
> métadonnées pour que quelqu'un puisse les charger directement dans OSM? Si
> oui, comment ça se passe, il y a un lieu fait pour ça, ou c'est sur ce
> genre de liste?
> Avant, on utilisait le plugin OSM de QGis, mais maintenant il n'y ai
> plus... et l'utilisation de Josm est un peu compliquée à employer dans le
> cadre d'une cartopartie avec des personnes qui ne sont pas familières.
>
> Merci à vous,
>
> Onésime.
>
> --
> *De: *"Florimond Berthoux" 
> *À: *"Discussions sur OSM en français" 
> *Envoyé: *Mercredi 12 Février 2020 22:13:39
> *Objet: *Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de
> villes & villages
>
>
> Sur le wiki en créant une page, par exemple en anglais tu suis un des
> liens et tu appuies sur "créer"
> https://wiki.openstreetmap.org/wiki/Key:pole:sealed
> ou https://wiki.openstreetmap.org/wiki/Key:support:sealed
>
> Le mar. 11 févr. 2020 à 21:30,  a écrit :
>
>> Ok, je vais tenter avec cela.
>> Pour le documenter, comment ça se passe?
>>
>> Merci!
>>
>> --
>> *De: *"Florimond Berthoux" 
>> *À: *"Discussions sur OSM en français" 
>> *Envoyé: *Mardi 11 Février 2020 19:38:44
>> *Objet: *Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de
>> villes & villages
>>
>> Tout bien réfléchi je pense que c'est une erreur de considérer le sol ou
>> le béton comme étant le support du poteau (c'est pas faux, mais pas top non
>> plus).
>> Je verrais plutôt un tag pour préciser si le poteau est scellé ou non
>> dans du béton.
>>
>> propositions :
>> support:sealed=yes|concrete
>> ou
>> pole:sealed=yes|concrete
>>
>> (sealed ou embedded ?)
>>
>> @Onésime oui il n'y a pas de tag documenté pour différencier les poteaux
>> scellé des non scellé.
>> Dans l'absolue vaut mieux inventer inventer un nouveau tag, le
>> documenter, et s'il faut le changer un peu plus tard on pourra le faire de
>> façon presque automatique.
>>
>> Le mar. 11 févr. 2020 à 14:34, marc marc  a
>> écrit :
>>
>>> Le 11.02.20 à 14:05, Florimond Berthoux a écrit :
>>> > support=pole
>>> > support:pole:support=ground
>>> >
>>> > plutôt parce que s’il y a plusieurs support (support=pole;wall) on
>>> > pourra pas préciser le support de quel support.
>>>
>>> une photo d'un panneau supporté à la fois par un poteau et un mur ?
>>> j'ai l'impression qu'on est une fois de +  entrain de faire une usine à
>>> gaz "par défaut" pour au cas oü il y a besoin de traiter un cas plus
>>> complexe que le cas par défaut. et le contributeur lambda est largé
>>> depuis longtemps par la marche toujours plus grande à entrée...
>>>
>>> > Le mar. 11 févr. 2020 à 00:15, marc marc a écrit :
>>> >
>>> > support=pole : le panneau est porté par un poteau
>>> > support:support=ground : le poteau est directement mis dans le sol
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>
>>
>> --
>> Florimond Berthoux
>>
>> ___
>> 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
>>
>
>
> --
> Florimond 

Re: [OSM-talk-fr] FANTOIR: publication de la version de janvier 2020

[Jérôme Seigneuret]

Ok merci pour l'info

Le jeu. 13 févr. 2020 à 17:26, Vincent de Château-Thierry 
a écrit :

> Bonjour,
> presque tout est dans le titre.
>
> Suite au coup d'oeil de Deuzeffe (merci :) ) qui m'a signalé sa parution,
> j'ai chargé cette nouvelle version dans BANO avant-hier soir. On dénombre
> environ 7 nouvelles entrées (noms de voies et lieux-dits) à l'échelle
> nationale, réparties sur un peu plus de 2000 communes. Toutes ces communes
> ont fait l'objet ce matin d'une passe de rapprochement dans BANO. Ne soyez
> donc pas étonné.e.s si vous voyez apparaître aussi bien de nouveaux
> rapprochements que de nouvelles voies candidates au rapprochement.
>
> 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] Tag panneau zone vidéo surveillance ?

[Jérôme Seigneuret]

On tag l'existant pas le manque mais une umap avec un symbologie propre au
caméra les panneaux d'entrée de ville et la panneau d'information de ville
sous vidéo surveillance devrait faire ton affaire

Le mer. 12 févr. 2020 à 23:03, Victor/tuxayo  a écrit :

> On 20-02-11 16:26, Shohreh wrote:
> > tourism=information
> > information=board
> > board_type=surveillance
>
> Est-ce qu'il aurai a un moyen pour indiquer l'absence de panneau alors
> que c'est légalement requis? (caméra dans un lieu publique en France par
> exemple)
>
> Car là on peut juste indiquer la présence d'un panneau.
>
> Cas concret: Dans le cadre de contribuer à la campagne Technopolice[1] à
> Marseille, il y a pour plan de faire une cartopartie des caméras de
> surveillance.
> Et pour aller plus loin, des gens seraient intéressés par indiquer si
> une caméra viole la législation sur l'affichage. Et de les extraire sur
> une carte pour que cela serve lors de plaintes.[2] (à différents buts
> dont obtenir en open data la position des caméras de certaines villes)
>
> Donc cette discussion tombe très bien :D Est-ce que qu'un a une idée
> pour indiquer de manière propre l'absence de signalétique d'une caméra?
> Au pire écrire un truc joli dans l’attribut "description" (ou un truc
> pas joli dans "note") et homogénéiser ce qu'il y est mit à l'échelle
> d'une ville mais c'est du gros bricolage. (non)
>
> À++
>
> [1] https://technopolice.fr/
> [2]
>
> https://forum.technopolice.fr/topic/403/plainte-collective-cnil-obliger-paris-%C3%A0-publier-une-carte-de-ses-cam%C3%A9ras
>
> --
> Victor/tuxayo
>
> ___
> 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] Tag panneau zone vidéo surveillance ?

[Jérôme Seigneuret]

C'est pas chez toi donc t'es un visiteur suivi d'un consommateur

Le mer. 12 févr. 2020 à 22:06, Florimond Berthoux <
florimond.berth...@gmail.com> a écrit :

> «An *information* source for tourists, travellers and visitors.»
> Je visite rarement les supermarchés, les halls d'entreprises ou les
> piscines municipales.
> J'y vais mais je ne visite pas.
>
> Le problème c'est que les consommateurs de cette données vont
> l'interpréter comme une information touristique alors que ça ne l'est pas.
> Exemple, ça sera affiché sur CyclOSM comme n'importe qu'elle autre panneau
> d'info à valeur touristique.
>
> (Pour préciser, je ne suis contre que sur l'utilisation du tag 
> tourism=information
> pour ce cas)
>
>
> Le mer. 12 févr. 2020 à 21:07,  a
> écrit :
>
>> Si on regarde ce qui touche à la surveillance côté taginfo:
>>
>> surveillance=outdoor/public/indoor.
>> surveillance:type=camera
>> surveillance:zone=traffic/building/town/parking...
>>
>> Ça me semble possible de l'indiquer aussi ici.
>>
>> Certes ce n'est pas du tourisme mais board_type=sport ou
>> board_type=public_transport non plus.
>>
>> Simplement on a/aurait la chaîne tourism=information / information=board
>> / board_type=surveillance.
>>
>> C'est bien ce qu'a écrit Shohreh
>> 
>> sur le wiki.
>>
>> Et non ça ne me choque pas. Même si la caméra n'a pas de reconnaissance
>> faciale pour ne fliquer que les touristes^^.
>>
>> Jean-Yvon
>> Le 12/02/2020 à 20:49, Florimond Berthoux - florimond.berth...@gmail.com
>> a écrit :
>>
>> Mon avis que ce tourism=information est une erreur, il y a rien de
>> touristique dans ce panneau.
>> information=board et board_type=* se suffisent à eux même.
>>
>> Le mar. 11 févr. 2020 à 16:27, Shohreh  a écrit :
>>
>>> Ok, donc c'est parti pour
>>>
>>> tourism=information
>>> information=board
>>> board_type=surveillance
>>>
>>> Merci.
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> --
> Florimond Berthoux
> ___
> 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 et ref:FR

[Jérôme Seigneuret]

Bonjour,

Il me semble que pour les conventions de nommage on évite des accents
*ref:FR:Tisséo
*dans les balises


Le mer. 12 févr. 2020 à 00:34, marc marc  a
écrit :

> on ets en plein dogme, cfr Réseau Arc en ciel de bus en france
>
> Le 12.02.20 à 00:21, François Lacombe a écrit :
> > En corollaire à ces propositions, je pensais suggérer à l'international
> > de ne laisser sur la page ref que les références mondiales
> > J'ai déjà supprimé le peu de ref:FR qui s'y trouvaient, en laissant
> > évidemment les liens vers la page française des références nationales.
> >
> > Cela permettra de clarifier les choses entre mondial/national et
> > d'inciter les pays à créer leurs propres page et namespace
> >
> > Penser qu'il y a aussi un niveau continental, avec quelques entrées en
> > Europe par exemple
> > https://wiki.openstreetmap.org/wiki/FR:Key:ref:EU:EVSE
> > https://wiki.openstreetmap.org/wiki/Key:ref:EU:ENTSOE_EIC
> >
> > Bonne soirée
> >
> > François
> >
> > Le mar. 11 févr. 2020 à 23:47, François Lacombe
> > mailto:fl.infosrese...@gmail.com>> a écrit :
> >
> > Bonsoir à vous
> >
> > +1 avec vous, bonne idée de séparer le tableau, pourquoi pas par
> > thèmes, comme nous le faisons pour les Map Features ?
> > Sur le caractère national/local, pourquoi pas ajouter une colonne
> > dans les tables pour le préciser ?
> >
> > Globalement, tout ce qui favorise l'adoption de ref:FR:* est bon à
> > prendre.
> >
> > François
> >
> > Le mar. 11 févr. 2020 à 18:57, deuzeffe  > <mailto:opensm@deuzeffe.org>> a écrit :
> >
> > Hello,
> >
> > Le 11/02/2020 à 18:25, leni a écrit :
> > > Bonjour
> > >
> > > En attendant que nous trouvions une meilleure solution pour
> > certaines
> > > ref:FR:*** , je pense qu'il serait bien de partager le tableau
> > de la
> > > page
> > >
> >
> https://wiki.openstreetmap.org/wiki/France/Liste_des_r%C3%A9f%C3%A9rences_nationales
> >
> > > (1) en deux parties :
> > > - une première partie avec les références qui s'appliquent sur
> > > l'ensemble du territoire (ref:FR:ARCEP=* ; ...) en y ajoutant
> > celles que
> > > j'ai trouvées dans le wiki (2)
> > > - une partie pour les autres (ref:FR:CRTA=*en Aquitaine ;
> > > ref:FR:BSPP:=* ; ref:FR:RATP=*) en y ajoutant celles que
> j'ai
> > > trouvées dans le wiki (3)
> > > - Faut-il y ajouter ref:FR:TransGironde et ref:FR:CUB qui sont
> > dans osm
> > > et que je n'ai pas trouvées dans le wiki ?
> > >
> > > Qu'en pensez-vous ?
> >
> > Sur le partage, que du bien. Et peut-être "l'ordonner" voire le
> > découper
> > par thème ?
> > Il me semble que j'en avais déjà parlé, sans grand succès...
> >
> > --
> > deuzeffe - qui n'a pas oublié la page transport à toiletter.
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org <mailto: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
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tag panneau zone vidéo surveillance ?

[Jérôme Seigneuret]

penses à le décrire sur le wiki en Anglais et Français au moins

Le mar. 11 févr. 2020 à 16:27, Shohreh  a écrit :

> Ok, donc c'est parti pour
>
> tourism=information
> information=board
> board_type=surveillance
>
> Merci.
>
>
>
> --
> 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
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tag panneau zone vidéo surveillance ?

[Jérôme Seigneuret]

*tourism *est plus large que l'on peut l'entendre. les panneaux de
direction sont aussi utilisé avec cette clé

Le mar. 11 févr. 2020 à 16:20, Jérôme Seigneuret <
jerome.seigneu...@gmail.com> a écrit :

> bon ben tu t'es répondu tout seul ;-)
>
> Le mar. 11 févr. 2020 à 16:17, Shohreh  a écrit :
>
>> Shohreh wrote
>> > Quid de man_made=surveillance avec board_type=surveillance +
>> > information=board ?
>>
>> Mauvaise idée, puisque c'est pour marquer la caméra, pas un panneau pour
>> indiquer une zone :-/
>>
>>
>>
>> --
>> 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
>>
>
>
> --
> Cordialement,
> Jérôme Seigneuret
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tag panneau zone vidéo surveillance ?

[Jérôme Seigneuret]

bon ben tu t'es répondu tout seul ;-)

Le mar. 11 févr. 2020 à 16:17, Shohreh  a écrit :

> Shohreh wrote
> > Quid de man_made=surveillance avec board_type=surveillance +
> > information=board ?
>
> Mauvaise idée, puisque c'est pour marquer la caméra, pas un panneau pour
> indiquer une zone :-/
>
>
>
> --
> 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
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tag panneau zone vidéo surveillance ?

[Jérôme Seigneuret]

non information est un sous élément de tourism donc j'ai mis à chaud met
pas par hasard

Description
Clé pour décrire de façon complète les panneaux d'informations
touristiques [image:
Edit or translate this description.]
<https://wiki.openstreetmap.org/wiki/Item:Q356>
*Groupe:* Tourisme
<https://wiki.openstreetmap.org/wiki/Category:FR:Tourisme>
Utilisé pour ces éléments
<https://wiki.openstreetmap.org/wiki/FR:%C3%89l%C3%A9ments>

[image: peut être utilisé sur des nœuds]
<https://wiki.openstreetmap.org/wiki/FR:N%C5%93ud>[image: ne devrait pas
être utilisé sur des chemins]
<https://wiki.openstreetmap.org/wiki/FR:Chemin>[image: peut être utilisé
sur des zones] <https://wiki.openstreetmap.org/wiki/FR:Zone>[image: ne
devrait pas être utilisé sur des relations]
<https://wiki.openstreetmap.org/wiki/FR:Relation>
Nécessite

   - tourism <https://wiki.openstreetmap.org/wiki/FR:Key:tourism>=
   information
   <https://wiki.openstreetmap.org/wiki/FR:Tag:tourism%3Dinformation>

Combinaisons utiles

   - tourism <https://wiki.openstreetmap.org/wiki/FR:Key:tourism>=
   information
   <https://wiki.openstreetmap.org/wiki/FR:Tag:tourism%3Dinformation>


tourism=information
information=bord
bord_type=surveillance


Le mar. 11 févr. 2020 à 15:25, Rpnpif via Talk-fr 
a écrit :

> Le 11/02/2020 à 10:37, Jérôme Seigneuret a écrit :
>
>
>>
>> à chaud, j'aurais créé traffic_sign=surveillance
>> ___
>>
> Pour moi c'est pas en lien avec le traffic
>
> A chaud ;-)
> tourism=information
> information=bord
> bord_type=surveillance
>
>
> Tu veux dire :
>
> Information=board
> board_type=surveillance
>
> ;)
>
> --
> Rpnpif
>
> _______
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages

[Jérôme Seigneuret]

>
> j'ai visiblement mal formulé ma remarque :
> FAIT: quand on passe de "hors zone urbaine" à "zone urbaine" en
> croissant donc un panneau EB10 dans un sens et un panneau EB20 dans
> l'autre sens, cela se MODELISE dans osm par traffic_sign=city_limit
> QUESTION : si on modélise l'entrée sur un way bi-directionnel,
> a-t-on besoin de dire que dans le sens inverse c'est une sortie ?
>
Non sauf si tu modélise le matériel en tant que tel. Donc on peut définir :
un niveau 1 de précision en lien avec juste l'information routière et son
découpage simple
on considère que le cas par défaut c'est
traffic_sign=city_limit+ direction=forward
traffic_sign:forward=FR:EB10[agglo];traffic_sign:backward=FR:EB20[agglo]
Avec 1 noeud à la limite des zones


>
> On pourrait réserver ce niveau de précision au cas des voie en
> sens-unique puisque dans ce cas (seulement ?) le panneau entrée n'est pas

dans ce cas en effet tu as une notion de sortie
en entrée
traffic_sign:forward=FR:EB10[agglo];
en sortie
traffic_sign:backward=FR:EB20[agglo]

Dans les autres (99% ?) cas, c'est une complexification dont
> je ne vois l'information supplémentaire qu'elle apporte.
>
Toi peut être mais on me modélise pas tous pour les même chose et certains
pas pour le routing

@marc il suffirait de limiter le niveau de détail (ou d'abstraction) que
l'on souhaite c'est aussi ça une base... Mais c'est pas fait (tous du moins
pas jusqu'a un certain niveau)
On voit ça sur l'électricité ou l'on atteint le niveau de précision d'une
base métier

D'où la multiplicité des méthodes et niveaux détails sur les données.

Pour revenir au niveau des support:
Pour éviter de renter dans l'usine à gaz on prend l'objet en tant que tel.
L'objet que l'on décrit est matérialisé sous forme de point est situer où?
sur un mur ou au sol? si tu veux aller plus loin dans ce cas on va dans du
commentaire ( regrouper sur un poteau)
On doit pouvoir comme on le disait plus haut trouver certains modèles et
les décrire assez bien pour que des outils puissent exploiter les données
et que des contributeurs puissent fournir des informations.
Si l'on commence à avoir des imbrications d'un même éléments (chose que je
ne pensais pas accepté) ça va aller super loin. Et plus loin jusqu'à
présent s'était ailleurs

-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tag panneau zone vidéo surveillance ?

[Jérôme Seigneuret]

>
>
>
> à chaud, j'aurais créé traffic_sign=surveillance
> ___
>
Pour moi c'est pas en lien avec le traffic

A chaud ;-)
tourism=information
information=bord
bord_type=surveillance

Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tag panneau zone vidéo surveillance ?

[Jérôme Seigneuret]

Pas à ma connaissance
C'est un panneau informatif au même titre que ceux pour signaler le 0
phyto, ville fleuri ...

Si je ne me trompe pas c'est juste un élément qui répond à une
recommandation de la CNIL en terme de signalement au usager.



Le mar. 11 févr. 2020 à 10:10, Shohreh  a écrit :

> Bonjour,
>
> Les panneaux indiquant les zones vidéosurveillées ne semblent pas
> standardisés.
>
> Existe-t-il néammoins un tag pour tagger ces panneaux correctement ?
>
> Merci.
>
>
>
> --
> 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
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages

[Jérôme Seigneuret]

*je comprend pas ce que tu veux dire avec cette totologie.une limite
urbaine est un panneau EB20 et vice-versa.a-t-on besoin de dire que si on
suit le chemin inverse d'une entréec'est une sortie ? cela me semble lourd
pour un gain qui m’échappe.  *

Je suis d'accord sur ce sujet. Un FR:EB20 c'est égal à la valeur de sortie
du city_limit

Ducoup c'est soit l'un soit l'autre dans le cas du point sur le réseau
traffic_sign=city_limit
ou
traffic_sign=FR:EB20 pour la sortie d'une voie en sens unique
traffic_sign=FR:EB10  pour les autre cas on peut considéré que c'est le cas
implicite

Sinon c'est hors topologie avec placement au réel du panneau ce qui permet
d'identifier la présence ou absence de matériel sur le terrain.
Graphiquement. L'analyse de vitesse on s'en fou un peu puisse que le
maxspeed doit être saisie sur la voie et que la source d'information est
matérialisé.

traffic_sign=FR:EB10 et traffic_sign=FR:EB20 Prennent tous leur sens et
c'est les problème que l'on a toujours entre Montpellier Lattes et
Saint-Jean de Védas où on a de réel problème pour les vitesses
portion à 50 ou à 80 voir 90 avant l'entrée sur le rond point.

sortie 1  90
https://www.mapillary.com/map/im/ixB69C61ZJJIDtY3KLZzrw
entrée 1 50
https://www.mapillary.com/map/im/Zo3aje8wMAYuV5kjF0QLdA

sortie 2 90
https://www.mapillary.com/map/im/wst74HSo9hjkXTabdGlKxQ
entrée 2 50
https://www.mapillary.com/map/im/OoJ7Mk2eXmhsA0fy6LUD-w

sortie 3 80
https://www.mapillary.com/map/im/KSwwyWu3Pl53VKzXhj4CdQ
entrée 3 50
ici suivant d'où je viens j'ai un problème clair de vitesse

J'ai pas de photo mais au bout de la sortie 3 le l'autre coté du rond point
on a un panneau d'entrée mais pas de sortie ce qui génère un problème de
topologie. Et en base on fait quoi? et les outils traite le problème
comment?
C'est un peu comme le trou ou le chevauchement sur des limites de
frontières dont les pays sont en désaccord.

C'est pour cela que je préfère les implantations réelles puis fournir sur
le tronçon l'information de vitesse correspondantes (ou une erreur à
corriger).

Je vais pas reprendre le cours sur le traitement des vitesses du code de la
route mais on pourrait envisager de détailler ce point sur le wiki vu la
problématique.


*Si l’autorité détentrice du pouvoir de police souhaite abaisser la
vitesse, il doit en principe rappeler cette limite après chaque
intersection. Mais il dispose également de différents outils qui permettent
de ne pas rappeler la vitesse à chaque intersection (cas des panneaux de
zones)  *

Le problème c'est le suivi du développement urbain qui n'est pas forcément
réanalysé en terme de signalisation
Pour moi ces panneaux sont dans tous les cas indispensable à leur
emplacement pour bien interpréter la réalité terrain. Si on met l'info de
vitesse sur le tronçon c'est pour éviter ces cas d'interprétation par les
outils vu que c'est pas performant et que ça pause aussi des problèmes
problème de responsabilité. C'est pour cela que l'on a autant de problème à
trouver des sources fiable sur le sujet alors que les DDTM on des infos sur
les implantations de leurs panneaux. Pour les communes j'en parle pas car
vu les problèmes il est clair que l'on ne retrouvera des infos que dans 30%
des cas.

Ne pas oublier qu'un panneau 30 sous un panneau de ville transpose
l'ensemble de l'agglomération à 30km/h sauf signalisation au sol ou
vertical signalant le contraire dans l'agglomération (oui la ville peut
être limité à 30km/h sauf axes majeurs qui peuvent être élevé à une vitesse
de 70km/h
https://www.ornikar.com/code/cours/panneaux/interdiction/limitation-vitesse#les-panneaux-en-agglomeration-1


J'ai corrigé la ville de Beauvoisin  en ce sens.
https://www.openstreetmap.org/node/7121675138  Nœud simple sur le réseau
(pour le moment)
Le problème reste les chemins sur lesquels il manque les panneaux d'entrée
et sortie et qui retombent sur la départementale hors agglomération... Les
chemin sont carrossés...

Bonne journée

Le mar. 11 févr. 2020 à 00:18, marc marc  a
écrit :

> Bonsoir,
>
> Le 10.02.20 à 21:59, onesim...@free.fr a écrit :
> > Je pense qu’on va partir sur des points à proximité de la route, à
> > l’emplacement exact du panneau.
>
> je me demande s'il y un logiciel de routage qui l'utilisera
>
> > Il n’est pas possible de mettre 2 fois la même clé par ex. :
>
> si : clef=valeur1;valeur2 (exemple avec la clef cuisine
>
> > donc une alternative et une meilleure manière de le noter est la
> suivante :
> > - traffic_sign=city_limit,FR:EB20.
>
> je comprend pas ce que tu veux dire avec cette totologie.
> une limite urbaine est un panneau EB20 et vice-versa.
> a-t-on besoin de dire que si on suit le chemin inverse d'une entrée
> c'est une sortie ? cela me semble lourd pour un gain qui m’échappe.
>
> Cordialement,
> Marc
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.o

Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages

[Jérôme Seigneuret]

Soit  || mon panneau à deux faces

cas A
---> || <---
cas B
<---  || <---
cas C
 <--- || --->
Si l'on ne prend que la géométrie en bout de noeud le forward backward va
avoir un problème

sens normal de circulation -->  direction à prendre en compte pour le
vecteur du panneau   <--- ||

comment matérialiser la face arrière du panneau qui est sur le même poteau
Si l'on fait deux point très proches ce qui fera qu'entre les deux points
on aura 1 mètre hors agglomération?

Ca c'est dans le schéma où l'on matérialise le panneau sur le réseau

L'autre solution c'est de dissocié les points d'entrée du réseau pour les
mettre à leur implantation réelle. Cela ne fix pas de problème de double
faces mais traite le problème de topologie.
C'est le même problème au final que pour les panneaux de destination mais
pour les destinations de ce type il me semble que c'est mis dans une
relation

face A face B
\   \
 \ ° \
   \   \
direction pour A = 240
  direction pour B = 60

L'avantage de prendre l'angle c'est qu'on se dissocié du problème de sens
de circulation

Si l'on met ça dans une relation on se retrouve avec la possibilité de
mettre ce que l'on veut sur le point concerné et de respecter le sens
d'entrée sortie avec from via to


Le lun. 10 févr. 2020 à 15:37, Jérôme Seigneuret <
jerome.seigneu...@gmail.com> a écrit :

> e
>
> Le lun. 10 févr. 2020 à 13:38, marc marc  a
> écrit :
>
>> Le 10.02.20 à 12:30, leni a écrit :
>> > https://wiki.openstreetmap.org/wiki/Tag:traffic_sign%3Dcity_limit :
>> >
>> > direction=* should be specified. The traffic sign should be faced when
>> > you drive into the city.
>> >
>> > on ne regarde que le sens du tronçon qui va vers la commune
>>
>>
>   En effet sauf quand ton panneau sert à la fois à l'entrée de deux
> agglomérations et à la sortie de ces même agglomération. Dans ce cas il
> faut bien choisir un sens et son opposé
>
>

-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages

[Jérôme Seigneuret]

e

Le lun. 10 févr. 2020 à 13:38, marc marc  a
écrit :

> Le 10.02.20 à 12:30, leni a écrit :
> > https://wiki.openstreetmap.org/wiki/Tag:traffic_sign%3Dcity_limit :
> >
> > direction=* should be specified. The traffic sign should be faced when
> > you drive into the city.
> >
> > on ne regarde que le sens du tronçon qui va vers la commune
>
>
  En effet sauf quand ton panneau sert à la fois à l'entrée de deux
agglomérations et à la sortie de ces même agglomération. Dans ce cas il
faut bien choisir un sens et son opposé
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages

[Jérôme Seigneuret]

outes express, ou quand il
>> y a des feux dans un seul sens, ou quand la partie habitée commence d'un
>> seul côté, l'autre étant encore agricole ou forestier (et hors zone
>> constructible selon les PLU en vigueur).
>>
>> Délimiter les agglomérations peut avoir plusieurs significations:
>> * celle de l'INSEE se base sur des distances minimales entre bâtis (50
>> mètres?), et permet à l'INSEE de définir les secteurs de populations
>> urbaines ou rurales, ces frontières du découpage urbain du territoire aux
>> fins statistiques sont évolutives.
>> * celle décidée par les communes qui décident de mettre en place des
>> limitations vitesse, et accéder aux demandes des "riverains" (peu importe
>> la définition de l'INSEE, la commune peut considérer d'autres facteurs
>> comme la présence de parcs de loisirs ou terrrains de sports ou des
>> équipements publics comme un cimetière communal, ou certaines autres
>> activités de loisir ou touristiques, même si elles ne sont pas habitées, ou
>> simplement une activité commerciale ou industrielle attirant de nombreux
>> piétons): la limitation de vitesse "urbaine" n'est pas la même définition
>> que .l'INSEE.
>>
>> On n'a pas de distinction des deux types de découpage urbain (statistique
>> de l'INSEE, ou routier au sens du code de la route et de la réglementation
>> communale/préfectorale et des panneaux EB10 et EB20, qui ne sont pas
>> disposés partout sur toutes les voies résidentielles "mineures" ni sur les
>> voies privées).
>>
>>
>> Le dim. 9 févr. 2020 à 13:44, onesime31  a écrit :
>>
>>>
>>> Bonjour,
>>>
>>> Nous avons un projet avec une classe de géomaticiens en formation.
>>> On a une commande et on aimerait faire cela en utilisant OSM, faire une
>>> cartoparty dans le cadre de leur formation. La commande est de
>>> cartographier les entrées et sorties de villes et villages.
>>>
>>> Pour le panneau d'entrée de village, voici le key et le value qu'on
>>> pensait utiliser: traffic_sign=city_limit
>>> à priori, il n'y a pas possibilité de préciser si c'est le panneau
>>> d'entrée ou de sortie du village?
>>> On peut les distinguer via le code EB10 et EB20...  est ce une bonne
>>> manière de référencer comme cela:
>>> - traffic_sign=city_limit
>>> - traffic_sign=FR:EB20
>>> ?
>>>
>>> Il nous faudrait également indiquer s'ils sont zérophyto: c'est à dire
>>> que les poteaux de ces panneaux aient un dé ou une dalle béton au pied (et
>>> qu'on utilise pas de pesticide pour enlever l'herbe au pied de ceux-ci).
>>> Pour la fixation du panneau, on pensait utiliser le key "support" puis
>>> les value suivant pour les distinguer:
>>> - support= post quand le panneau est simplement planté (donc pas
>>> zerophyto)
>>> - support = pole si le panneau est scellé au sol (= zerophyto pour nous)
>>> Existe t-il une autre manière de tagger s'il y a un dé, ou une dalle
>>> béton au pied du panneau?
>>>
>>> L'idée serait de travailler sur OSM, et de faire une extraction pour
>>> répondre à la commande qui nous est faite.
>>>
>>> Si vous avez des conseils, précisions, ressources, etc. n'hésitez pas.
>>>
>>> Bonne soirée, Onésime.
>>> ___
>>> 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
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Équitation et attributs proposés

[Jérôme Seigneuret]

Pour rebondir sur le sujet et améliorer l'usage et le rendu qu'il peut en
être fait

1) Aborder les sujets et améliorer le wiki pour les tags en question et les
soumettre au processus de validation (tagging list et autres)
2) Voir avec les différents dev de fond de plan pour intégrer des rendus
génériques ou spécifiques  de manière à avoir une visibilité ou
l'améliorer (rendu général osm.org, rendu hiking)
3) Communiquer auprès des communautés si ces éléments seraient pertinents à
être exploité pour les itinéraires par exemple.
4) Si plusieurs tag sont proches ou similaires, proposer d'en supprimer un
au profit de l'autre la la mailing list qui va bien. > adapter le wiki et
présenté la solution adaptée.

Un exemple simple de choses possible et non prise en compte dans le rendu
c'est de mettre un portail comme linéaire alors que les outils et le rendu
utilise le point. Deux choses se passent dans ce cas:
- les utilisateurs voulant un rendu mais pas dégrader le détail mettent
barrier=gate sur le point d'intersection
- les utilisateurs qui considèrent que ça ne répond pas au modèle et
supprime le linéaire pour faire un point unique à l'intersection.
Par dessus ça il y a les contributeurs qui supprime les infos car osmose
émet une alerte si un portail n'est pas connecté à la voirie

Donc comme signalé précédemment, il faut dissocier le contenu, le rendu,
l'exploitation des données, l'analyse qualité. A chaque niveau des
décisions sont prise et la base évolue au rythme des contributions et des
sujets que l'on veut bien y intégrer (des fois sans validation complet du
processeur)

Bon weekend



Le sam. 8 févr. 2020 à 13:51, marc marc  a
écrit :

> Le 08.02.20 à 13:21, Arnaud Champollion a écrit :
> > beaucoup d'attributs "proposés" mais pas validés.
> >
> > Est-ce que ça veut dire que pour l'instant on ne les utilise pas ?
>
> dans osm, tout le monde est libre d'utiliser n'importe quel tags.
> un tag validé est simplement un tag qui a fait l'objet d'une discussion
> au niveau mondial et qui au moment du vote a paru être de qualité.
> c'est totalement indépendent d'être présent ou pas dans la bdd,
> être ou pas utilisé par le rendu par défaut ou par n'importe quel autre
> rendu ou par une application
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] stabilité et stat sur la disponibilité du fond OSM org

[Jérôme Seigneuret]

Je suis déjà parti sur le principe de proposer du Mapbox ou une solution
interne.

@Vincent la question de garantie n'est pas abordée. Aujourd'hui toute les
apli basé sur du Leaflet et de l'Openlayer mettent par defaut OSM en
basemaps. Esri propose la couche en Lyr et elle est exploitable et proposé
par défaut dans QGIS... Faut regarder ce qu'il se passe au réel. Maintenant
c'est pas mon objectif de saturer un service. De toutefaçon la partie tech
bloquera le service trop consommateur si c'est le cas ou me rapellera à
l'ordre.

Je me fou de la garantie et j'ai pas abordé cette partie. Ce que je cherche
c'est à comparer la disponibilité d'un service osm.org vu que c'est ce qui
est comparé aujourd'hui et non son actualisation. Je pense que les mecs ne
savent même pas comment une basemap est mise à jour. Ils consomment juste
le service pour avoir un rendu.

Si je veux une garantie je prends un fournisseur pour éviter ou limiter une
rupture de service. L'objectif c'est de péter un argument sans fondement
pour dire qu'on veut pas du modèle opensource...
Sachant que la mise à jour de l'api interne à des coupures de service bien
plus récurrente que ne peut l'avoir le fond OSM . d'où peut-être des stat
munin...


Le ven. 7 févr. 2020 à 17:22, marc marc  a
écrit :

> stable selon ta définition : je me souviens pas quand osm.org
> m'a répondu "service pas dispo" ou n'a pas répondu, donc 100% ? :)
>
J'ai déjà eu des cas où j'avais des réponses en 500 donc pas de service
mais c'est en lien avec un serveur qui était en panne ou des surcharges qui
ont été traitées car la carto avait tellement de modif que le serveur
saturé pour la mise à jour du rendu. L'actualisation du rendu n'est plus
aussi rapide aujourd'hui.

>
> disponibilité sans latence : là est le soucis avec osm.org
> c'est un choix que d'essayer de faire du rendu "temps réel"
>
Le rendu c'est pas avec de l'actualisation des éditions en temps réel. Dans
ce cas il vaut mieux traiter ça avec un rendu vectoriel que de générer de
la tuile à gogo il me semble


> au lieu de répondre avec l'ancienne tuile par défaut.
>
ça ok

> Et quand la tuile n'est pas dispo sur le serveur de rendu,
>
le cache dans ce cas?

> la latence pour l'avoir peux être énorme en journée.
> sur le rendu libre cyclo hébergé sur osm-fr, le choix inverse a été fait
> (fournir la tuile du cache, les maj se font de manière séparé)
>
Ben ma foi si c'est une solution pour avoir un fond j'en demande pas
beaucoup plus on a juste besoin d'un rendu de fond...

>
> le cache du cache d'osm.org : pq pas... pour un petit truc mini...
>
Tu entends quoi par là. Les appli sont générés sous Android. Je parle aussi
de mettre en cache sur le mobile

> mais de quelle volunme on parle ?
>
Si c'est sur le groupe ce sera entre 1000 et 4000 appareil pouvant tourner
en 3 postes

> osm.org est une vitrine et un feedback aux contributeurs,
> pas un service commercial gratuit.
> Je suis sur qu'il y a des entreprises qui font moins cher que GM
> et si tu trouves pas, je te montre la voie :-)
>
J'ai bien compris mais c'est pas ma demande initiale. Mais on peut voir en
MP pour les orientations que je pourrai donner.

Si quelqu'un a déjà mener une tel étude je suis preneur. ;-)
Il me semble qu'il y a pas mal d'interco qui ont encore "for
devlopment purpose"
Merci A+
-- 
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Demande d'intervention de tiers sur un conflit d'édition

[Jérôme Seigneuret]

Dans ton cas de toute-façon il y a une signalisation verticale...
Ca reste de la dégradation sans justification.
Après discussion propose lui déjà de faire un revert de son changeset en
mettant les liens et notre discussion mail.

Si c'est pas fait tu le fais et si des modifications reviennent sans
justification tu pourras ouvrir une demande de gestion des conflits auprès
du DWG   https://wiki.openstreetmap.org/wiki/Disputes


Le ven. 7 févr. 2020 à 21:29, Charles MILLET  a
écrit :

> Merci Florimond pour ton retour. Il y a bien une ligne de séparation qui
> est déjà bien effacée.
>
> En fait je craque avec ce contributeur, il efface très régulièrement des
> trucs juste parce que ça lui plaît pas et pas mal de piste cyclables que
> des débutants OSM prennent le temps de mapper pour les remplacer par du
> track même quand c'est même plus justifiable pour du routage.
> On 07/02/2020 20:30, Florimond Berthoux wrote:
>
> Salut,
>
> Merci pour le lien mapillary,
>
> highway=path
> bicycle=designated
> foot=designated
> seggregated=? (j'ai l'impression qu'il y a une ligne de démarcation)
>
> sur le way de la route tu peux ajouter
> bicycle=use_sidepath
>
> cycleway:right=track me semble peu pertinent ici étant donné que piétons
> et cyclistes sont mélangés sur la même chaussée.
>
> Des fois c'est peut-être plus simple d'attendre et de changer sans
> discuter.. ;)
>
>
> Le ven. 7 févr. 2020 à 16:12, Jérôme Seigneuret <
> jerome.seigneu...@gmail.com> a écrit :
>
>> https://www.mapillary.com/map/im/ZF99wjAm9RtiGhd-LmrDMw
>>
>> https://www.openstreetmap.org/way/753746024
>>
>> Après mettre highway=footway + bicycle=designated ou highway=cycleway +
>> foot=designated ... pour moi c'est du débat idéologique. Ca reste de base
>> un trottoir donc fait pour les piétons avec une obligation pour les vélos
>> d'y circuler...
>> Au niveau exploitation des données d'y voit pas de différence.
>>
>>
>>
>>
>>
>> Le ven. 7 févr. 2020 à 16:04, Jérôme Seigneuret <
>> jerome.seigneu...@gmail.com> a écrit :
>>
>>> marc il y a un lien mapilary
>>>
>>> Pour moi c'est bien un Cycleway séparé de la voie sur un trottoir avec
>>> accès piéton et ségrégation clairement affiché sur panneau.
>>> Il faut mettre une la voie routière cycleway=use_sidepath car c'est une
>>> obligation de circuler sur le trottoir
>>>
>>> Bonne journée
>>>
>>> Le ven. 7 févr. 2020 à 16:02, marc marc  a
>>> écrit :
>>>
>>>> Le 07.02.20 à 15:49, Charles MILLET a écrit :
>>>> > Pour info cette "piste cyclable" est utilisable par les piétons et
>>>> donc
>>>> > nécessite un way séparé et la précision du segregated=yes
>>>>
>>>> il y a une erreur dans l'argument ?
>>>> photo classique récente du lieu ou uniquement vue sat ?
>>>> ___
>>>> Talk-fr mailing list
>>>> Talk-fr@openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>>
>>>
>>>
>>> --
>>> Cordialement,
>>> Jérôme Seigneuret
>>>
>>
>>
>> --
>> Cordialement,
>> Jérôme Seigneuret
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> --
> Florimond Berthoux
>
> ___
> 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
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] stabilité et stat sur la disponibilité du fond OSM org

[Jérôme Seigneuret]

Stable : disponibilité du service sans rupture de continuité
Disponibilité : accès au service sans latence

Le cache c'est une des proposition que j'ai proposé pour éviter de
solliciter inutilement le serveur.
La tuile à jour oui au démarrage des outils. Ce sont des application
mobiles. Les délais de réponse c'est du classique mais quelque chose qui
permet de bosser sans latence visible.
Le prestataire nous propose du google maps car juge le service
d'OSM instable... Je cherche donc des contre arguments tangibles et des
infos sur la rupture de service... Un peu comme on a sur les serveurs avec
des taux de disponibilité. Je pense que le prestaire par du service général
osm.org. L'autre chose que j'ai proposé c'est de monter un serveur miroir
pour fournir de la disponibilité avec un load balancer. Mais là il y a une
question de coût à aborder. De toute-façon l'étude de côut GM n'est pas
évaluée car compliqué à estimer par le prestataire...


Le ven. 7 févr. 2020 à 16:07, marc marc  a
écrit :

> Le 07.02.20 à 15:44, Jérôme Seigneuret a écrit :
> > Bonjour,
> >
> > A t'on des stat sur la stabilité et la disponibilité du fond OSM merci
>
> il y a tellement de critère que cela me semble compliqué.
> c'est quoi stable ?
> c'est quoi disponible ? fournir la tuile en cache c'est disponbile ?
> ou faut fournir une tuile à jour avec les données de moins de X min ?
> répondre en moins de x ms pour les tuiles à jour ?
>
> côté osm-fr je crois qu'on a aucune stats de ce genre,
> hormis celle qu'on peux sortir du graphe munin (% de tuile servie
> périmée depuis le cache faute d'avoir pu être rendue dans un délais
> court). stats complètement déformée par la présence d'un cache frontal
> et du cache des navigateurs.
>
> osm.org a les mêmes graphes munin, avec les mêmes défauts.
> je veux bien me renseigner si les caches distribués ont un monitoring
> qualité style délais pour founir une tuile. mais j'en doute.
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Demande d'intervention de tiers sur un conflit d'édition

[Jérôme Seigneuret]

On remplace par des track quand l'accessibilité est donnée pour des
véhicules sur des voies vertes ce qui peut être déroutant.

Après pour discuter il vaut mieux en effet rester sur le changeset puis en
cas de litige voir sur la liste pour un avis plus général et une solution.
Ta pratique est donc bonne je pense qu'il ne veut pas être montré du
doigt...

Bref pas de track à mettre dans ce cas vu qu'on est sur un linéaire
dissocié...

A+

Le ven. 7 févr. 2020 à 16:16, Charles MILLET  a
écrit :

> En gros si on regarde ça
> (http://resultmaps.neis-one.org/osm-discussion-comments?uid=412560) on
> voit qu'il ne répond qu'une fois sur 2. Et qu'il a bien eu cette
> pratique de supprimer les cycleway pour les remplacer par des track.
>
> Ce changeset (https://www.openstreetmap.org/changeset/65441162) par
> exemple est truffé de piste supprimées.
>
>
> On 07/02/2020 15:49, Charles MILLET wrote:
> > Bonjour à tous
> >
> > J'ai à nouveau un problème de conflit d'édition avec l'utilisateur
> > Meersbrook. cf. https://www.openstreetmap.org/changeset/79878637
> >
> > En résumé il a supprimé l'ajout d'une piste cyclable (discutable mais
> > ce n'est pas le sujet) pour la remplacer par un track. Ce sujet a déjà
> > été discuté avec lui pour des pratique identique à Caen et je suppose
> > qu'il le fait malheureusement régulièrement. Je suis à la recherche
> > des discussions à ce sujet pour reprendre les arguments.
> >
> > Pour info cette "piste cyclable" est utilisable par les piétons et
> > donc nécessite un way séparé et la précision du segregated=yes
> >
> > Je suis à la recherche d'un peu d'arbitrage car mes échanges avec
> > Meersbrook sont insupportables et totalement non constructif à cause
> > de son ton ultra arrogant et différents reproches totalement délirant.
> >
> > Charles
> >
> >
> > ___
> > 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
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Demande d'intervention de tiers sur un conflit d'édition

[Jérôme Seigneuret]

https://www.mapillary.com/map/im/ZF99wjAm9RtiGhd-LmrDMw

https://www.openstreetmap.org/way/753746024

Après mettre highway=footway + bicycle=designated ou highway=cycleway +
foot=designated ... pour moi c'est du débat idéologique. Ca reste de base
un trottoir donc fait pour les piétons avec une obligation pour les vélos
d'y circuler...
Au niveau exploitation des données d'y voit pas de différence.





Le ven. 7 févr. 2020 à 16:04, Jérôme Seigneuret 
a écrit :

> marc il y a un lien mapilary
>
> Pour moi c'est bien un Cycleway séparé de la voie sur un trottoir avec
> accès piéton et ségrégation clairement affiché sur panneau.
> Il faut mettre une la voie routière cycleway=use_sidepath car c'est une
> obligation de circuler sur le trottoir
>
> Bonne journée
>
> Le ven. 7 févr. 2020 à 16:02, marc marc  a
> écrit :
>
>> Le 07.02.20 à 15:49, Charles MILLET a écrit :
>> > Pour info cette "piste cyclable" est utilisable par les piétons et donc
>> > nécessite un way séparé et la précision du segregated=yes
>>
>> il y a une erreur dans l'argument ?
>> photo classique récente du lieu ou uniquement vue sat ?
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> --
> Cordialement,
> Jérôme Seigneuret
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Demande d'intervention de tiers sur un conflit d'édition

[Jérôme Seigneuret]

marc il y a un lien mapilary

Pour moi c'est bien un Cycleway séparé de la voie sur un trottoir avec
accès piéton et ségrégation clairement affiché sur panneau.
Il faut mettre une la voie routière cycleway=use_sidepath car c'est une
obligation de circuler sur le trottoir

Bonne journée

Le ven. 7 févr. 2020 à 16:02, marc marc  a
écrit :

> Le 07.02.20 à 15:49, Charles MILLET a écrit :
> > Pour info cette "piste cyclable" est utilisable par les piétons et donc
> > nécessite un way séparé et la précision du segregated=yes
>
> il y a une erreur dans l'argument ?
> photo classique récente du lieu ou uniquement vue sat ?
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] stabilité et stat sur la disponibilité du fond OSM org

[Jérôme Seigneuret]

Bonjour,

A t'on des stat sur la stabilité et la disponibilité du fond OSM merci
-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] zone résidentielle dans une zone résidentielle ?

[Jérôme Seigneuret]

Je le fais en mode relation outer pour le polygone englobant et je met les
autres landaise en objet pour les résidences nommées et lotissement. Rien
d'interdit a cela il faut juste ne pas avoir de superposition

Le jeu. 6 févr. 2020 à 07:56, Arnaud Champollion <
arnaud.champoll...@linux-alpes.org> a écrit :

> Le 05/02/2020 à 21:58, osm.sanspourr...@spamgourmet.com a écrit :
>
> Les relations
> boundary 
> place
> place  neighbourhood
> (par exemple)
> 
> type  boundary
> 
>
> me semblent plus adaptées
>
>
> OK, à l'occasion je ferai les corrections nécessaires, car sur Digne les
> Bains il y a un certain nombre de quartiers mappés landuse=residential à
> l'intérieur d'un autre landuse=residential.
>
> Merci à tous, bonne journée.
> ___
> 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] Voies OSM inconnues de FANTOIR

[Jérôme Seigneuret]

Bon ben c'est bien ça ! Au moins on a la totale côté voirie

Le mar. 4 févr. 2020 à 19:04, Vincent de Château-Thierry 
a écrit :

>
> > De: "Jérôme Seigneuret" 
>
> > On a déjà fait quelques chose pour les codes Fantoir mis sur OSM mais
> > non reconnu dans la dernière version de FANTOIR? Vu que certains les
> > mettent un peu en automatique. Osmose ou autre?
>
> Ils sont visibles ici :
> http://dev.cadastre.openstreetmap.fr/fantoir/fantoir_errone.html
>
> 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] Voies OSM inconnues de FANTOIR

[Jérôme Seigneuret]

On a déjà fait quelques chose pour les codes Fantoir mis sur OSM mais non
reconnu dans la dernière version de FANTOIR? Vu que certains les mettent un
peu en automatique. Osmose ou autre?

Le mar. 4 févr. 2020 à 16:49,  a écrit :

>
> Le 04/02/2020 à 16:42, Christian Quest - cqu...@openstreetmap.fr a écrit :
> > La DGFiP ne modifie semble-t-il jamais un libellé, mais préfère
> > annuler l'ancienne entrée dans FANTOIR et en créer une nouvelle, ce
> > qui est visiblement le cas pour les deux exemples cités.
>
> Intéressante gestion de version. C'est bon à savoir ! Donc si jamais ils
> voient qu'on a noté une erreur, on va avoir un nouveau numéro FANTOIR
> qui avec un peu de chance sera reconnecté automatiquement à la bonne
> voie. Oui, je sais, les erreurs qu'on note ne sont pas
> remontées, il faudrait que Christian remonte son service Minitel pour
> qu'ils sachent y accéder^^.
>
> 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] Import massif dans OSM

[Jérôme Seigneuret]

Oui c'est faisable sous Josm et en important les données osm existante avec
overpass. Le plugin conflate est ton ami

Le sam. 1 févr. 2020 à 10:12, Cédric Frayssinet  a
écrit :

> Bonjour à tous,
>
> Les 2 associations lyonnaises Pleinlavue et RAP ont obtenu de la part de
> la Métropole de Lyon, le fichier des implantations des panneaux
> publicitaires (joliment appelé mobilier urbain), notamment JCDecaux :
> https://data.grandlyon.com/jeux-de-donnees/mobilier-urbain-metropole-lyon/donnees
>
> C'est très complet. Actuellement, nous en sommes là au niveau cartographie
> : https://openadvertmap.pavie.info/#15/45.7649/4.8400 (que nous réalisons
> avec MapContrib).
>
> Nous aimerions injecter ce fichier dans OSM pour compléter l'existant,
> tout en n'écrasant par les différents POI qui pourraient exister.
>
> Question 1 : est-ce faisable ?
>
> Question 2 : qui aurait une expertise là dessus pour nous aider ?
>
> Merci d'avance,
>
> Cédric
> --
>
> Sur Mastodon : @bristow...@framapiaf.org
> 
>
> [image: Promouvoir et soutenir le logiciel libre] 
> ___
> 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] Voies OSM inconnues de FANTOIR

[Jérôme Seigneuret]

Merci Vincent

Bonne journée

Le mar. 4 févr. 2020 à 08:42, Vincent de Château-Thierry 
a écrit :

> Bonjour,
>
> Le 04/02/2020 à 08:02, rainerU a écrit :
> >
> > J'ai constaté que dans la liste des voies inconnues dans FANTOIR on
> > trouve des rues qui sont bien dans liste brute FANTOIR. Exemples pour la
> > ville de Perpignan 66136 :
> >
> > Rue Luchino Visconti 661365195R
> > Rue Georges Claude 661361048H
>
> Pour les rapprochements je ne tiens pas compte des voies FANTOIR
> annulées. Dans tes 2 cas ce sont des voies ayant été annulées dans
> FANTOIR. Pour chacune on a des rues au nom très proche, c'est peut-être
> une raison de leur annulation pour éviter les confusions :
>
> 661363128U RUE LOUIS VISCONTI
> 661360858B AV GEORGES ET CLAUDE CAUSTIER
>
> vincent
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Trottoir traversant

[Jérôme Seigneuret]

   > si tu veux maintenant ajouter du détail pour dire en linéaire
> > > > la longueur de ce croissement pour chaque usager :
> > > > - pour la voiture, c'est un plateau traffic_calming=table
> > > > sur le way voiture.
> > > > côté voiture, je vois pas de différence entre traverser
> > > > un plateau passage piéton avec marquage (les ""anciens"" trottoir
> > > > traversants qui existent depuis des années) et un plateau
> > > > passe piéton trottoir traversant).
> > > > tout autre tag me semble donc superflu ou erroné.
> > > > est-ce qu'il y a une différence dans la loi ?
> > >
> > > Premier point, il y a différent type de trottoir traversant plus ou
> > > moins cassant pour une voiture, alors qu'un plateau traversant
> c'est
> > > bien réglementé (en France en tout cas).
> > > Second point, sur un plateau traversant il y a toujours une
> > > délimitation route/trottoir même s'ils sont censés être à niveau.
> > > Troisième point légal, en France, une voiture qui traverse un
> > > trottoir traversant traverse un trottoir (eh eh) et doit donc cédez
> > > le passage à tous à l'intersection (Article 415-9
> > >
> https://www.legifrance.gouv.fr/affichCodeArticle.do;jsessionid=6ED1C96581529BBCE4CD62E5C0D68704.tplgfr41s_3?idArticle=LEGIARTI23095968=LEGITEXT06074228=20200117
> > > )
> > >
> > > > - pour le piéton, il y a 2 incohérences dans ce que tu dis.
> > > > la clef crossing sert a décrire le passage piéton (le nœud même
> > > > si certain duplique l'info du passage 3 fois).
> > > > crossing=continuous n'est donc pas une bonne idée pour décrire
> > > > l'étendue du cheminement de voie le composant.
> > > > par ailleurs si tu considères qu'un trottoir traversant est un
> > > trottoir,
> > > > alors ce n'est pas un passage piéton, c'est highway=path
> path=sidewalk
> > > > si c'est pas tout a fait un trottoir (peut-on s'y arrêter pour
> faire
> > > > ses lacets ou discuter avec un autre pendant 5 min ? j'en doute),
> > > > alors highway=path path=continuous_sidewalk ou qlq chose du
> genre.
> > >
> > > C'est un vrai trottoir et tu peux jouer à la marelle dessus, c'est
> > > comme une entrée charretière, après personne n'a le droit
> d’empêcher
> > > l'autre de passer ;)
> > > Oui crossing ça veut vraiment dire passage pour traverser la grosse
> > > voie (route, chemin de fer, rivière...).
> > >
> > > Et le mot anglais pour intersection c'est ... junction
> > > https://wiki.openstreetmap.org/wiki/Key:junction
> > > «This key describes how a specific junction is constituted. »
> > > Perfect, aujourd'hui utilisé pour les différents rond-point (à
> > > priorité à droite ou à priorité à l'anneau par exemple) donc pour
> > > définir à la fois la forme physique et l'aspect légal.
> > > On peut imaginer :
> > > junction=continuous_sidewalk/continuous_cycleway
> > >
> > > Donc je me suis essayé à modéliser ce magnifique trottoir
> traversant
> > > que je connais bien
> > > https://www.openstreetmap.org/#map=19/48.87867/2.35428
> > >
> > > Donc deux nœuds d'intersection avec
> > > junction=continuous_sidewalk/continuous_cycleway
> > > https://www.openstreetmap.org/node/652025857
> > > https://www.openstreetmap.org/node/7140053012
> > >
> > > Un bout de rue piétonne sur trottoir :
> > > traffic_calming=continuous_sidewalk
> > > highway=pedestrian
> > > pedestrian=sidewalk (cette portion de segment est sur trottoir)
> > > kerb=no
> > > https://www.openstreetmap.org/way/25704593
> > >
> > > Une piste cyclable :
> > > cycleway=continuous
> > > highway=cycleway
> > > kerb:left=lowered
> > > kerb:right=flush
> > > https://www.openstreetmap.org/way/764269695
> > >
> > > Un chemin piéton :
> > > highway=footway
> > > footway=continuous_sidewalk
> > > kerb:left=lowered
> > > kerb:right=flush
> > > https://www.openstreetmap.org/way/764269695
> > >
> > > Avec ça on est blindé :D
> > >
> > > --
> > > Florimond Berthoux
> > >
> > >
> > >
> > > --
> > > Florimond Berthoux
> > >
> > > ___
> > > 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
>
>
>
> --
> Florimond Berthoux
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] intégration des voies sans addr : trouveur leur localisation

[Jérôme Seigneuret]

https://www.cadastre.gouv.fr/scpc/accueil.do
Et d'ailleurs on retrouve plein de choses bizarres avec des noms de voies
qui n'ont pas été changé sur certaines parcelles... l'alias n'est pas
utilisé dans le cadastre. En effet c'est très fastidieux.Si  pas de
rattachement parcellaire et que la voie est quand même connu, ça ne va pas
plus loin et ne te propose pas de planche.



Le mer. 22 janv. 2020 à 14:25, Vincent de Château-Thierry 
a écrit :

> Bonjour,
>
> > De: "marc marc" 
> >
> > existe-t-il un moyen de chercher le cadastre pour trouver
> > la localisation d'une voie sans addr ?
> > http://dev.cadastre.openstreetmap.fr/fantoir/ ne donne pas de
> > coordonées
> > Sur la couche cadastre, elles apparaissent souvent mais visualiser
> > toute l'étendue d'une commune est fastidieux.
> >
> > ou autre outil ?
>
> Si à la voie recherchée sont rattachées des parcelles, alors tu peux
> chercher le nom de voie ici :
> https://www.cadastre.gouv.fr/scpc/accueil.do
> Tu auras autant de réponses que de parcelles correspondantes (et de
> feuilles concernées) avec une visu carto.
>
> vincent
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Supermarché drive only

[Jérôme Seigneuret]

Bonjour,

Ca me fait pensez à certains points de retraits des service de colis en
extérieur sur des stations services et autres magasins

https://www.itespresso.fr/e-leclerc-ouvre-portes-casiers-intelligents-abricolis-133921.html
sauf
que dans ton cas c'est du du indoor

Peut être mettre sur la zone concernée
*indoor=room/area*
*level=0*

Bonne journée



Le lun. 20 janv. 2020 à 19:02, Cédric Frayssinet  a
écrit :

> Bonjour,
>
> Le 18/01/2020 à 23:29, marc marc a écrit :
>
> Le 18.01.20 à 20:25, Cédric Frayssinet a écrit :
>
> Le 12/01/2020 à 19:33, marc marc a écrit :
>
> Le 06/01/2020 à 22:23, Cédric Frayssinet a écrit :
>
> Avez-vous déjà tagué ce genre de magasin :https://westnordost.de/p/7258.jpg
>
> si c'était un drive only
> shop=supermarket
> drive_through=only
>
> mais à voir la photo, ce n'est pas le cas,
> tu sorts de ton véhicule et tu vas dans le magasin,
> comme n'importe quel autre magasin sauf que t'as passé
> ta commande avant au lieu de sur place.
> je n'ai pas connaissance de tag disant que le magasin
> a la possibilité de commander en ligne.
> si tu le trouve, suffit de mettre =only
>
> Du coup, j'ai pris exemple sur les lockers Amazon et j'ai mis ces tags :
>
> c'est une bonne idée. mais je ne suis pas d'accord avec qlq détails :
>
>
> vending=parcel_pickup
>
> vending c'est le produit vendu (le truc avec lequel tu repart)
> On n'y vend pas des "parcel_pickup",
> On y vend de la nourriture, boisson et autre.
>
>
> Tu seras d'accord avec moi que l'on vient récupérer des colis qui peuvent
> contenir tout produits, comme chez Amazon. Du coup, j'ai laissé
> *parcel_pickup* qui me semble le plus approprié.
>
>
> covered=yes
>
> cela n'avait pas l'air d'être couvert mais dans un bâtiment.
>
>
> Tout à fait, on m'a fait la remarque en privé, j'ai supprimé couvert et
> inside
>
> description=Consignes permettant de retirer ses courses 24h/24h
>
> virer le 24h/24 puisqu'il se trouve dans un tag (sinon on finit
> inutilement par copier tous les tags dans description)
>
>
> En effet, corrigé !
>
> Merci, Cédric
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Grosses lenteurs et panne des proxies du serveur de données OSM

[Jérôme Seigneuret]

En effet j'ai eu le même problème et c'est récurent depuis hier.

Le ven. 10 janv. 2020 à 06:17, Philippe Verdy  a écrit :

> Les échecs comme dans le message ci-dessus (erreur DNS du proxy pour
> joindre le serveur rails3 en upstream) ou des résultats
> incomplets/tronqués, concernent en gros 1 requête sur 3 à l'API
> (indépendamment de leur volume ou complexité), un des proxies est en panne,
> on tombe dessus au hasard, ou il est mal configuré dans le load-balancer.
>
> Le ven. 10 janv. 2020 à 06:05, Philippe Verdy  a
> écrit :
>
>> [image: image.png]
>>
>> Le ven. 10 janv. 2020 à 05:59, Philippe Verdy  a
>> écrit :
>>
>>> je constate depuis aujourd'hui de très grosses lenteurs du serveur OSM
>>> pour presque tout, au chargement des données dans l'éditeur (même sous iD
>>> dans une toute petite zone, nombreux échecs, ou données partiellement
>>> chargées et tronquées, sous JOSM, des listes de membres de relation
>>> incomplètes ou des chemins longs auxquels manquent de nombreux points).
>>> Lors de l'envoi, une partie des données est transmise, je passe mon
>>> temps à revérifier (donc recharger péniblement) et corriger ce qui n'est
>>> pas passé.
>>> Et sous ID j'ai un message clair: ce sont les proxies qui retournent
>>> après de longs délais des erreurs 502 donnant une raison erreur DNS:
>>> problème de connexion avec le serveur central.
>>> Cela semble être les proxies d'accès qui ont des problèmes, même si le
>>> serveur est fonctionnel.
>>> De plus les minute diffs sont anormalement en retard (plus d'1/2 heure
>>> au moins quand les modifs sont habituellement visibles en 3 ou 4 minutes)
>>>
>>> Mais maintenant c'est carrément la panne: plus moyen de faire quelque
>>> chose de fiable, même les vérifs après envoi mettent trop de temps ou se
>>> rechargent trop lentement et partiellement, jamais deux fois les mêmes
>>> résultats, d'où aussi l'apparition un peu partout de noeuds orphelins ou
>>> d'objets laissés en doublon (je pense que ça touche pas mal de monde avec
>>> les tentatives multiples de soumission à nouveau).
>>>
>>> [[
>>> Note: JOSM ne rapporte pas toutes les erreurs réseau, certaines sont
>>> encore totalement silencieuses (sauf si on a ouvert la console Java, ce qui
>>> n'est pas fait par défaut), méfiance car vous ne voyez pas forcément une
>>> boite d'alerte après une exception pourtant bien détectée durant le
>>> chargement ou l'envoi. Il est hautement recommandé de lancer JOSM avec la
>>> console ouverte.
>>>
>>> Vérifiez votre panneau de configuration Java pour activer l'option
>>> console de journalisation, même si cela a pour effet d'ouvrir une fenêtre
>>> de plus qu'il ne faut pas fermer car on ne peut pas l'ouvrir à nouveau
>>> ensuite. Malheureusement JOSM n'inclue pas lui-même sa propre fenêtre
>>> console (ou l'inscription en backup vers un fichier log externe qu'on
>>> pourrait consulter à tout moment), on n'a que la fenêtre console du lanceur
>>> (fenêtre de commande dans laquelle on le lance via un shell, ou
>>> Javawebstart.
>>>
>>> Cette option journal est bien pratique aussi pour gérer certains
>>> conflits d'édition ou erreurs lors d'un envoir et trouver les ID d'objets
>>> concernés, par fois de très grande liste qu'il faut garder en copie pour
>>> les inspecter ensuite un par un ou par lot. La console Java permet au moins
>>> de faire de copier-coller de ce qu'on veut garder.
>>>
>>> Avec l'éditeur iD, on a besoin parfois aussi de la console Javascript du
>>> navigateur pour retrouver certaines erreurs non traitées par l'UI de
>>> l'appli web et en trouver la cause ou le détail car certains messages des
>>> serveurs ou proxies ne sont pas traitées: la console Javascript doit être
>>> ouverte sinon les logs ne sont pas gardés en mémoire, mais on peut toujours
>>> effacer la console à tout moment si on manque de mémoire et qu'on n'a rien
>>> à garder.
>>> ]]
>>>
>>> Là aussi c'est indispensable en ce moment et révèle que ce n'est pas un
>>> problème de notre propre connexion internet jsqu'au front-end d'OSM, mais
>>> quelquepart entre le front-end/proxy et les serveurs, dans le réseau
>>> interne d'OSM. Et il semble que ce soit un problème de config DNS: les
>>> front-end proxies ont du mal à maintenir ou rouvrir les connexions au
>>> serveur, peut-etre une saturation mémoire ou d'un espace disque interne sur
>>> les proxies, ou une panne sur un routeur ou un switch interne, ou une panne
>>> chez Bytemark, l'hébergeur du domaine DNS osm.org.
>>>
>>> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Abus de StephaneP : adresses FANTOIR

[Jérôme Seigneuret]

Oui en effet tu as raison... Mais tu me diras la définition anglaise reste
sur un lieu orienté principalement pour les piétons. Un espace destiné à
rassembler des gens autour d'évènements avec si possible un élément
monumental en son centre.
On y parle selon les pays d'équivalent à la place public (on a plus
d’échafaud) ou de place centrale. Encore une fois c'est vraiment orienté
sur le fait d'y faire des évènements publique

Sinon le terme à l'américaine est encore plus particulier vu que c'est une
notion de trame carré (village square, garden square, town square,
washington square...) avec des ilots qui se sont remplit de commerce et de
park et autre fonctionalité. Ducoup les ilots de circulation "mode
circulation douce" sont des place=square

La place de la comédie à Montpellier répond bien à cette usage.
Au pire tu serais sur une place de marché. (Si tel est le cas)




Le mer. 8 janv. 2020 à 22:09, Stéphane Péneau 
a écrit :

> Le 08/01/2020 à 21:15, Jérôme Seigneuret a écrit :
> > Le square tel qu'il est défini est en effet ambigu. Je trouve que la
> > définition sur wikipedia est nettement plus claire et celle d'OSM
> > devrait avoir une révision...
> https://fr.wikipedia.org/wiki/Square_(lieu)
> >
> Ah ok, c'est parce que tu prends la définition française du mot
> "square". C'est une sorte de faux-ami, et c'est bien précisé sur le wifi
> français de faire attention à la confusion. La référence est la
> définition anglaise.
>
> Dans la terminologie Osm, place=square donne en français : "place"
>
> "square" en français donne leisure=park dans la terminologie Osm
>
> A+
>
> Stf
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Jérôme Seigneuret]

récupérer
> les messages qu'Orange ne parvient pas à relayer, ce qui arrive aussi
> régulièrement et fait qu'Orange sature au plan stockage et génère ensuite
> des bounces pour les autres messages entrants valides qu'il est incapable
> de vérifier et même de stocker.
>
> Les protocoles du mail sont vieux, incohérents, chaque fournisseur semble
> vouloir gérer le spam entrant un peu comme il veut et selon des méthodes
> parfois incompatibles entre elles. Que puis-je faire? pas grand chose hormi
> signaler aux divers fournisseurs, qui corrigeront (peut-être) un jour, mais
> ces signalements à Orange ne sont pas compris (leur support technique ne
> comprend rien ou prétend que tout va bien chez lui ou suggère à tord de
> changer de client mail, ou veut nous obliger à utiliser son webmail encore
> plus pourri, hyper-lent et peu pratique, bourré de bannières publicitaires
> intempestives, et dangereux car il ne filtre aucun script ou image jointe
> et lasise passer des tas de virus activés dès l'ouverture; en plus il
> laisse passer les cookies traqueurs des annonceurs, et envoie des
> "autorisations" automatiques même quand on a bloqué des cookies (Orange
> refuse/ignore les requêtes et laisse tout passer, la vie privée n'est pas
> un problème pour lui, il force le passage des annonces de ses propres
> annonceurs et de plusieurs réseaux "partenaires" sous prétexte d'enrichir
> l'expérience utilisateur.
> Jamais je n'utilise le webmail d'Orange, sauf pour récupérer certains
> mails qu'il aurait détectés comme "spam" et mis dans le dossier des
> "indésirables" (la plupart du temps à tord d'ailleurs), les seuls où les
> scripts et cookies et pixels traceurs ont désactivés par défaut).
>
> Il n'y a personne accessible chez Orange qui s'occupe réellement du
> support technique du mail, ils ne veulent supporter que leur webmail et
> rien d'autre, SMTP/POP3/IMAP sont hors support tout comme la gestion de
> leurs domaines DNS et leurs espaces IP d'adressage, et tous les serveurs ne
> sont même pas gérés par les mêmes prestataires qui font chacun la moitié du
> boulot; Orange ne recette pas correctement ses mises à jour et évolutions
> de son architecture; le mail est un truc qui ne leur rapporte pas grand
> chose et ne fait que leur couter, ils font un service minimum pour
> seulement régler ~90% des cas et laisser les ~10% qui restent dans les
> limbes; aucun moyen de créer un ticket d'incident et de toute façon Orange
> ne gère pas les tickets et renvoie seulement à un support "communautaire"
> dont il n'assume pas la responsabilité). C'est pour ça qu'Orange a été
> blacklisté souvent sur les DNSBL de plein de pays (c'est le seul cas où vu
> le volume de plaintes reçu par le support cela entraine une résolution
> relativement rapide; Orange ou ses prestataires ne comprennent pas comment
> marche les mails)
>
>
> Le mer. 8 janv. 2020 à 13:44, Vincent de Château-Thierry 
> a écrit :
>
>> Bonjour,
>>
>> Le 08/01/2020 à 13:32, marc marc a écrit :
>> > Le 08.01.20 à 08:53, ades a écrit :
>> >>
>> >> je ne compte plus les messages de « bounced" depuis 1 ou 2 mois, je
>> n’en n’avais jamais avant… et mon adresse mail est tout ce qu’il y a de
>> plus simple, 'at orange', sans aucune redirection…
>> >
>> > je sais que le sujet est complexe, mais il est important de comprendre
>> > qu'il y a 2 groupes qui coexiste pour provoquer le problème :
>> > - un groupe d'email d'expéditeur donc la config email n'est pas
>> > classique (par exemple écrire avec une email wanadoo.fr comme
>> expéditeur
>> > en utilisant un compte gmail)
>> > - un groupe d'email de destintaire donc la config email est "stricte"
>> >
>> > quand l'email d'un expéditeur en question arrive à un des destinataire
>> > en question, le serveur de celui-ci la rejette (message 550 spam detecte
>> > dans le cas de free.fr)
>> > quand le gestionnaire de la liste recoint trop de rejet, il désinscrit
>> > le(s) destintaire(s) en question, quand bien même c'est pas leur faute
>> > si l'expéditeur "pas classique" continue
>>
>> Ce message est pour Philippe Verdy, dont je peux plus lire les mails
>> depuis longtemps, mes adresses mail étant chez free.fr et laposte.net,
>> tous deux fournisseurs 'stricts'.
>>
>> Philippe, comme te l'as rappelé Marc ce matin ici :
>>
>> https://lists.openstreetmap.org/pipermail/talk-fr/2020-January/096123.html
>>
>> tu continues d'envoyer tes messages avec une adresse en wanadoo.fr.
>> Peux-tu une fois pour toutes utiliser une autre adresse, par exemple ton
>> adresse @gmail, pour poster, et sans mécanisme de renommage en adresse
>> wanadoo.fr, qui pose problème à beaucoup de monde ici pour suivre
>> normalement les discussions.
>>
>> merci
>> vincent
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Abus de StephaneP : adresses FANTOIR

[Jérôme Seigneuret]

Le square tel qu'il est défini est en effet ambigu. Je trouve que la
définition sur wikipedia est nettement plus claire et celle d'OSM devrait
avoir une révision...  https://fr.wikipedia.org/wiki/Square_(lieu)

Même si la géométrie n'est pas identique ce n'est pas adaptée à ta
situation. Historiquement les square avait un usage fonctionnel qui est
devenu un espace de détente et de rencontre d'où le fait de dire que c'est
là plus part du temps piéton. Les routes encadre le square ou le recoupe en
plusieurs carré.

Le square est vraiment un type de lieu particulier.
Voilà pourquoi j'ai proposé d'adapter ta contribution

A+
Bonne soirée

Le mer. 8 janv. 2020 à 20:39, Stéphane Péneau 
a écrit :

> Bonsoir Jérôme,
>
> Le 08/01/2020 à 12:16, Jérôme Seigneuret a écrit :
> > les place=square peut être adaptée mais en effet pas de le cas présent
> > à mon avis
> > On n'est pas sur un espace piéton et/ou il n'y a pas d'espaces verts
> >
> Je ne comprends pas. Je ne vois rien sur le wiki qui indique qu'un
> place=square doit être piéton et/ou avec des espaces verts. C'est même
> plutôt le contraire, que ce soit sur la version anglaise ou française.
> https://wiki.openstreetmap.org/wiki/Tag:place%3Dsquare
>
> > On n'est sur un parking ou et sur une place de marché
> > Le nom peut être portée sur le parking directement et le FANTOIR
> également
> >
> Comme la géométrie n'est pas identique, et que j'ai tendance à penser
> que les détails augmentent avec le temps, je trouve que ce n'est pas
> pertinent de supprimer l'un au profit de l'autre. Mais bon, ça se discute.
>
> A+
>
> Stf
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Abus de StephaneP : adresses FANTOIR

[Jérôme Seigneuret]

les place=square peut être adaptée mais en effet pas de le cas présent à
mon avis
On n'est pas sur un espace piéton et/ou il n'y a pas d'espaces verts

On n'est sur un parking ou et sur une place de marché
Le nom peut être portée sur le parking directement et le FANTOIR également

C'est bien une voie de service vue que l'on travers un parking sur une
place destiné principalement à cela les résidences derrières ne passe que
sur une voie d'accès.
Pour rappel on tag deux choses: des classes fonctionnelles et un usage de
la route. Dans le cas de figure c'est clairement pas un highway=residential

Une voie résidentielle est une voie majeur qui sert à transiter pour
accéder à d'autre résidence et dont des résidences donnent accès sur cette
voie directement. Ici on est sur un point final et les autres voies sont
des voies d'accès. Ici tu ne pourra même pas rouler à 50. Tu passes
d'ailleurs par un trottoir ... donc tu ne sera pas prioritaire à la sortie
même sans marquage.

Le FANTOIR n'est pas que sur des voies. Donc faut ce calmer sur les
questions de compréhension du code. On n'est plus à une erreur prêt de la
part de la des impôts. Le fait de matérialiser le ref:FR:FANTOIR permet de
faire la jonction sur d'autres objets qu'une voie et cela est bien normal.

Là il n'y a pas de question du terrain prime. C'est une question de simple
logique d'application et celle de Stéphane n'est pas incompatible pour
l'exploitation. La structure et l'exploitation du référentiel prime et
c'est ainsi qu'on fait une abstraction du terrain sans dénaturer ce que
l'on pourrait en comprendre et comment l'exploiter. Si la structure n'est
pas adaptée ou incomplète il suffit de la faire évoluer et c'est ainsi que
l'on dit que le terrain prime pas l'inverse. Sinon on se retrouve avec des
référentiel qui ne deviennent plus exploitable... Cela revient aussi à la
logique de "on ne tague pas pour le rendu". On adapte le rendu pour donner
une lecture des données saisie dans le référentiel on fonction de critères
exploitables.

Voilà donc mes préconisations:

On laisse les voies de service
place=plaza doit disparaître on n'est pas sur le bon usage
le parking récupère le nom et le FANTOIR ce qui est bien suffisant
Pas de relation car elle ne sert à rien
Le nom doit être mis sur le tag addr:street des adresses pour les résidences

A+ et bonne après midi





Le mer. 8 janv. 2020 à 01:11, Philippe Verdy  a écrit :

> Voir son commentaire:
> https://www.openstreetmap.org/changeset/79302148#map=19/47.08243/-1.33683
>
> Visiblement il n'a pas compris le FANTOIR et supprime les adresses et crée
> des trucs "à sa sauce".
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Adresse renseigné en import de masse...

[Jérôme Seigneuret]

Bonjour,

Bonne année!
J'ouvre un petit sujet pour faire de la qualité sur les données insérées

Je pense que le sujet est récurent mais il serait intéressant dans tes
outils de @Vincent sur la partie Fantoir de voir si les numéros renseignés
sur une rue dans OSM existe ou non dans les autres référentiels et pas
seulement sur les fonds de plans disponibles.

Je vois pas mal de cas ou l'import est fait en masse sans vérification
terrain.

https://www.openstreetmap.org/#map=20/48.82270162711555/2.1150345528297643

J'ai pas supprimé les numéros pour en discuter ici

Ici je pense que les adresses ont été supprimé suite à la création de la
déchetterie donc autant dire que ça fait plus de 10ans...
En clair c'est le 16 18 et surement 18 Bis qui n'ont plus lieu d'être sur
le terrain.

Peut-on adapté le travail que tu as fait au niveau des rue  avec un tableau
des numéros existants ou non dans chaque référentiel afin de voir ce qui
peuvent être problématique?

voie  osm | fantoir | IGN | la poste | données commune | autre  *peut
importe que la voie soit rapprochée ou non *

| addr:number |  oui | non | oui| non | non  | -  < dans le cas présent pas
de donnée impôt et postal on peut donc ce dire que le numéro n'a plus lieu
d'être. (ou date ou version de la derrière entrée connue ça peut être en
poup pour les infos complémentaire sur les casses à "oui")

Ca va offrir deux choses: l'ajout des nouveaux numéros sera visible donc la
maintenance sera plus simple pour ce qui ont déjà intégré toute leur ville
On pourra virer ou mettre en disued:addr:housenumber les numéros qui n' ont
plus d’existence terrain (cas d'accès sur une autre rue avec déplacement du
portail) rue coupée en deux et renommage partiel de la voirie sur le
prolongement de la rue adjacente... Bref plein de cas de terrain.
J'ai discuté avec déjà pas mal de responsable SIG dans les communes qui se
servent d'OSM comme source de gestion d'adresse. L'import de masse fait
mais pas de contrôle faute de temps et de moyen. proposé un moyen de
traiter les cas de divergence permettra de limiter les voies à contrôler.

Peut être que ça existe chez certains déjà (interco ou département)



-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] SPAM, Re: Problème avec ID - besoin d'aide

[Jérôme Seigneuret]

00-19:00;12:00-14:00 off" est équivalente à  "08:00- 12:00;14:00-
> 19:00"
> - "08:00-19:00;Sa-Su off" est équivalente à  "Mo-Th 08:00-19:00"
> - "Mo-Sa 08:00-19:00;Sa 18:00-19:00 off" est équivalente à  "Mo-Th
> 08:00-19:00;Sa 08:00-18:00"
> Tu peux tester, c'est comme ça que ça marche.
> Les règles séparées par ";" sont ordonnées de façon strictes, et elles
> sont TOUTES évaluées cumulativement (on ne s'arrête pas au premier "match").
> "||" ne sert strictement à rien (sauf à la compatibilité avec d'anciennes
> spécifications qui ne marchaient pas dans plein de cas) et équivaut au ";".
>
>
>
> Le mar. 31 déc. 2019 à 13:17, Philippe Verdy  a
> écrit :
>
>>
>>
>> Le mar. 31 déc. 2019 à 09:18, Jérôme Seigneuret <
>> jerome.seigneu...@gmail.com> a écrit :
>>
>>> Le ; est une règle cumulative avec écrasement des valeurs passés.
>>>
>>> Si tu met Lundi au Vendredi de 10 à 20h et que tu ajoutes Mercredi de
>>> 20h à 22h c'est pas cumulatif. Tu dis juste de remplacer les horaires de
>>> Mercredi
>>>
>>
>> C'est un non sens complet!
>>
>> L'indication: "08:00-19:00;Fr 18:00-19:00 off;Su off" indique clairement
>> l'ouverture tous les jours de 8h à 19h, sauf le vendredi où ça ferme à 19h
>> et le dimanche fermé.
>>
>>
>> https://openingh.openstreetmap.de/evaluation_tool/?EXP=Mo-Fr%2010%3A00-20%3A00%3B%20We%2020%3A00-22%3A00=48.84991979995=2.6370411=0=157773336_value=Mo-Fr%2010%3A00-20%3A00%3B%20We%2020%3A00-22%3A00
>>
>>
>> L'interprétation est bien cumulative et se fait dans l'ordre, chaque
>> règle séparée par ";" modifiant les précédentes.
>>
>>
>>

-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] SPAM, Re: Problème avec ID - besoin d'aide

[Jérôme Seigneuret]

Le ; est une règle cumulative avec écrasement des valeurs passés.

Si tu met Lundi au Vendredi de 10 à 20h et que tu ajoutes Mercredi de 20h à
22h c'est pas cumulatif. Tu dis juste de remplacer les horaires de Mercredi
Dans ce cas il faut utiliser le *|| *et non* ; *

L'évaluation se fait de gauche à droite Si on ajoute un nouveau sélecteur
celui-ci surchage les valeur précédente ou ajoute des horaires non
précédemment défini pour le jour en question.
Même si tu spécifie des plages horaire le selecteur c'est le jour complet
donc si tu ajoutes des nouveaux horaires c'est l'horaire de la journée
complète qui est réévalué.
Le double pipe à un comportement cumulatif des plages non couvertes

*voici les exemples*
Mo-Fr 10:00-20:00; We 20:00-22:00
https://openingh.openstreetmap.de/evaluation_tool/?EXP=Mo-Fr%2010%3A00-20%3A00%3B%20We%2020%3A00-22%3A00=48.84991979995=2.6370411=0=157773336_value=Mo-Fr%2010%3A00-20%3A00%3B%20We%2020%3A00-22%3A00


Mo-Fr 10:00-20:00|| We 20:00-22:00
https://openingh.openstreetmap.de/evaluation_tool/?EXP=Mo-Fr%2010%3A00-20%3A00%7C%7C%20We%2020%3A00-22%3A00=48.84991979995=2.6370411=0=157773336_value=Mo-Fr%2010%3A00-20%3A00%3B%20We%2020%3A00-22%3A00


Maintenant comme je l'ai présenté précédemment il est possible de coupler
les séparateurs ; et tu peux surement améliorer ma proposition ou corriger
la tienne en exploitant || et en testant ;-)
Bonne journée

Le mar. 31 déc. 2019 à 00:37, Philippe Verdy  a écrit :

>
>
> Le lun. 30 déc. 2019 à 21:02, Jérôme Seigneuret <
> jerome.seigneu...@gmail.com> a écrit :
>
>> Salut,
>> "Journée continue"  n'est pas nécessaire si l'on utilise le mot clé
>> "off". Attention YoHours ne prend pas en compte toute la syntaxe de
>> opening_hours
>> exemple complet pour les vacances
>>
>> https://openingh.openstreetmap.de/evaluation_tool/?EXP=SH%2010%3A00-18%3A00%3B%20SH%20Sa%2CSu%2013%3A00-15%3A00%20off=48.84991979995=2.6370411=0=1577733402192
>>
>>
>> @Philippe l'ajout d'un sélecteur écrase la valeur précédente donc tu va
>> avoir un problème sur le mercredi et sur le jeudi. Dans ton cas, jeudi ne
>> sera ouvert que de 20h à 21h et Mercredi de 11h30 à 11h45
>> Il faut aussi ajouter PH off pour une fermeture les jours fériés si c'est
>> le cas.
>>
>
> Non, chaque valeur listée vient modifier les valeurs précédentes dans les
> plages horaires indiquées; les règles sont cumulatives, et ordonnées, mais
> dans ce cas il n'y a même pas d'écrasement, une première règle indique la
> plage "standard" du lundi au vendredi, les autres pour les jours
> particuliers viennent modifier encore ce qui est défini. Quand on "parse"'
> les règles au début la règle par défaut est "off" partout, chaque règle ne
> modifie que les plages indiquées.
>
> Mais que penser de ma proposition de rendre tous les espaces facultatifs
> sauf entre 2 lettres ou entre deux chiffres dans la syntaxe existante; ce
> qui permettrait de les supprimer pour compacter encore plus (et c'est
> facile de restaurer ces espaces "implicites" entre une lettre et un
> chiffre. Je ne vois aucune règle existante où cela conduit à une ambiguïté
> quelconque.
>
> Ca peut éventuellement casser certaines analyses lexicales mais le patch
> lexical est simple à faire, on a pratiquement besoin d'aucune espace dans
> la plupart des cas (sauf par exemple "Jul-Aug off" pour indiqué "fermé en
> juillet et août" et qu'on ne peut pas compacter en "Jul-Augoff" car cette
> espace est entre deux lettres). C'est pas une révolution, mais au moins si
> ça peut aider à passer la limite des 255 caractères par valeur de tag...
>
>

-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Plusieurs relations pour la même rue...

[Jérôme Seigneuret]

la supprimer non. la mettre en voie de service ça dépend. Pour une voie de
service privé j'ai tendance à faire du cas par cas.
Si les boites aux lettres sont au niveau du portail la voie est rarement
une voie nommé sauf cas de lotissement. Le point d'adresse est
souvent unique et dans ce cas je le met sur le portail et non à l'entrée
Une partie ou la totalité de la voie peut être privée. Les service postaux
on dans ce cas un badge d'accès. Les numéros sont bien matérialisé sur les
bâtiments.

Bref on a des lieu dit complet qui sont accessible qu'en voies privé avec
des postes barrières aux entrées. L'adressage n'est pas pour autant à
l'entrée du poste barrière... Les voies sont limités à 30km/h elle sont
nommé et servent au transit (sauf accès privé).

Par défaut une voie de service n'a pas de vitesse mais pour le routing
j'irai pas y mettre plus de 20km/h et en voie privé 10 km/h sauf indication
contraire. On peut considérer que la voie de service n'est pas utilisé pour
du transit. Elle ne sert qu'à une destination finale et/ou un service
particulier (c'est un principe de routing). On évite les voies de service
pour les itinéraires rapides et équilibré sauf si c'est le seul moyen
d'arriver au POI.

Chemin : Rue des Libellules (72456629)
C'est un chemin d'accès privé
highway=service+service=driveway+access=private  ainsi pas de suppression
de l'objet en tant que tel et il faut supprimer le nom de la voie et le
sortir de la relation

portail à ajouter:
barrier=gate+access=private

Pour les deux autres ways et les points d'adresses il faut tous mettre dans
une seule relation. C'est un extension de la voie existante
La partie présente au niveau du 22 et 24 et à découper est à mettre en
portion voie d'accès privé  highway=service+service=driveway+access=private
avec le portail qui va bien ;-)

Petite remarque sur la zone:
Les voies cyclables mentionnées autour n'en sont pas. Ceux sont des
trottoirs et il n'y a aucune signalisation à ma connaissance. Les trottoirs
abaissés c'est pour les poussettes et principalement pour les PMR. Donc il
faut tous remettre comme highway=footway et ajouter les mention d'accès
wheelchair=yes sauf si la signalisation aérienne ou au sol a évolué.
Peut-être voir avec Mickey86  <https://www.openstreetmap.org/user/Mickey86> à
la base de l'édition.

Bonne journée


Le lun. 30 déc. 2019 à 23:41, marc marc  a
écrit :

> Le 30.12.19 à 22:16, deuzeffe a écrit :
> >> Chemin : Rue des Libellules (72456629)
> >
> > Ce n'est pas une rue, mais une voie privée : elle fait partie intégrante
> > de la parcelle 450. Classique dans les lotissements arrangés façon
> > Tétris. À débaptiser et passer en highway=service ?
>
> oui
>
> > Voire à supprimer ?
>
> non car un jour un autre contributeur la recréera :)
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] SPAM, Re: Centre aquatique - problèmes sur le quartier

[Jérôme Seigneuret]

Bonsoir,

Le bâtiment n'est pas l'équipement en effet.

Le mieux c'est de faire un sport_center sur le terrain englobant ton
bâtiment  et le parking du centre de sport etc si c'est le cas. En effet si
tu as des horaires d'ouverture  et un portail dans ce cas à la fermeture tu
ne pourra pas accéder au parking non plus.

et des leisure=pich pour les piscines en location=indoor ET avec level=0
level=-1 ou autre niveau. Le layer c'est que pour définir un niveau
d'affichage sur des couche qui se représente sur un même niveau

Les batiments sont de base au dessus des zones d'équipement sauf pour les
piscine sur le toit et là c'est un autre cas comme pour les parking sur les
toits

Bonne soirée



Le lun. 30 déc. 2019 à 20:08, Arnaud Champollion <
arnaud.champoll...@linux-alpes.org> a écrit :

> Le 30/12/2019 à 18:03, Brice a écrit :
> > Pour avoir une icône "nageur" associé à l'intitulé comme à Manosque ou
> > à Belleville, je suppose que c'est ce que souhaite Arnaud, il faut
> > rajouter un sport=swimming sur le bâtiment du "sports_centre"
>
> Oui c'est ce que j'ai fait et au final ça respecte la logique puisque la
> piscine est quand même l'activité principale, et que le nom de
> l'établissement est : "Centre aquatique des Eaux Chaudes".
>
>
>
> > Mais bon tout cela, ce n'est rien que du rendu ;-)
>
> Certes mais en même temps le rendu OSM-fr est plutôt bien pensé à la
> base, et justement sur d'autres exemples ça fonctionne bien, donc quand
> le visuel est inhabituel, je me dis que ça peut révéler un défaut de
> qualification des données.
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] SPAM, Re: Problème avec ID - besoin d'aide

[Jérôme Seigneuret]

ontinue%22;SH%20Sa,Su%2010:00-13:00,15:00-18:00=46.57657400418426=5.750308802675297=0=157763046>
>>>  mais
>>> ça affiche «Vacances de Noël» au lieu de «Journée continue»
>>>
>>> Mo
>>> <https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification#selector:weekday>
>>>  12:00-14:00,17:00-20:00
>>> <https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification#selector:time>
>>> ;
>>> <https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification#section:rule_separators>
>>> Tu
>>> <https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification#selector:weekday>
>>>  11:45-14:00,16:30-21:00
>>> <https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification#selector:time>
>>> ;
>>> <https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification#section:rule_separators>
>>> We
>>> <https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification#selector:weekday>
>>>  11:30-13:00,15:00-18:00
>>> <https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification#selector:time>
>>> ;
>>> <https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification#section:rule_separators>
>>> Th
>>> <https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification#selector:weekday>
>>>  11:45-14:00,16:30-20:00
>>> <https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification#selector:time>
>>> ;
>>> <https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification#section:rule_separators>
>>> Fr
>>> <https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification#selector:weekday>
>>>  11:45-14:00,17:00-20:00
>>> <https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification#selector:time>
>>> ;
>>> <https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification#section:rule_separators>
>>> SH
>>> <https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification#selector:holiday>
>>>  Mo-Fr
>>> <https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification#selector:weekday>
>>>  "Journée continue"
>>> <https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification#comment>
>>> ;
>>> <https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification#section:rule_separators>
>>> SH
>>> <https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification#selector:holiday>
>>>  Sa,Su
>>> <https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification#selector:weekday>
>>>  10:00-13:00,15:00-18:00
>>> <https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification#selector:time>
>>>
>>> —
>>> Yves
>>>
>>> PS: Cette limite de 255 caractères est une bonne illustration de « Le
>>> mieux est l’ennemi du bien » 廊
>>>
>>> ___
>>> 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
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Plusieurs relations pour la même rue...

[Jérôme Seigneuret]

Salut,
Si c'est la même rue et pas une erreur de nom tu dois affecter les numéros
d'adresse dans la relation 1 et supprimer la relation 2.

C'est la même rue donc une relation unique la relation dans ton cas est
divisée en 2

Bonne soirée

Le lun. 30 déc. 2019 à 19:21, Jacques Lavignotte  a
écrit :

> Bonjour,
>
> Osmose me crie dessus :
>
>   Plusieurs relations pour la même rue
> relation 1125815 analyse1 analyse2 josm iD edit
> name = Rue des Libellules
> type = associatedStreet
> relation 1125822 analyse1 analyse2 josm iD edit
> name = Rue des Libellules
> type = associatedStreet
>
> Que faire ?
>
> Merci,
> --
> GnuPg : 156520BBC8F5B1E3 Because privacy matters.
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] SPAM, Re: Banque de France

[Jérôme Seigneuret]

La banque de France n'ouvre un compte que si une autre banque vous rempli
une attestation de refus de d'ouverture de compte. Ça reste un
établissement bancaire

Le sam. 28 déc. 2019 à 01:33, marc marc  a
écrit :

> Le 27.12.19 à 22:46, David Crochet a écrit :
> > Bonjour
> >
> > Le 27/12/2019 à 21:41, Arnaud Champollion a écrit :
> >> En tout cas, je ne vois effectivement pas comment je peux ouvrir un
> >> compte à la Banque de France, encore moins y obtenir un chéquier, et
> >> ne connais personne dans mon entourage pour qui c'est le cas.
> >
> >
> > Recevant des chèque pour le compte d'une association, j'y retrouve bien
> > des chèque émis au nom de la Banque de France, avec une belle écriture
> > calligraphique vert  sur fond vert clair
>
> je suis bien surpris.
> l'iban de ces asso dit quoi ?
>
> > La banque de France ouvre un compte avec un attestation de refus
> > d'ouverture de compte puisque l'ouverture d'un compte est un droit
> > (article L312-1 du code monétaire et financier)
>
> mais le site de la banque de France elle-même dit qu'elle désignera
> une banque pour faire respecter ce droit.
> ___
> 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] gestion du hstore dans qgis

[Jérôme Seigneuret]

Oui c'est un truc qui t'évite de gérer le délimiteur de valeur et remplace
donc par $$ donc pas d'échappement à gérer. exemple de clé ou la valeur
contenant un simple cote ou un double cote utilisé comme paramètre de ta
requête

y compris les `` ou "

Je parlais ce ça car le mieux c'est d'uniformiser et surtout de pas avec
des caratères différent pour délimiter un champs




Le ven. 13 déc. 2019 à 12:18, Leroy Olivier  a écrit :

> Un pro de postgre te fera sûrement une réponse plus fine que moi.   Ici
> c'est une forme de quoting qui te permet "d’éviter" les autres formes de
> quoting (comme ') et \ et ne pas à avoir à les "echapper". Dans ma tête
> c'est un "super quote".
>
> Le ven. 13 déc. 2019 à 12:02, Tony Emery via Talk-fr <
> talk-fr@openstreetmap.org> a écrit :
>
>> Merci Olivier pour ta contribution.
>> Rappelle-moi ce que signifie les $$ ?
>>
>>
>>
>> -
>> 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
>>
>
>
> --
> Olivier Leroy
> Docteur Géographie et Environnement
> Post-doctorant EVS ANR Rêveries <http://reveries-project.fr/>
> 06.18.37.18.08
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Osmose : Erreur sur remplacement clés "ref" sur réseaux de transports en commun

[Jérôme Seigneuret]

De plus Streetview n'est pas autorisé pour cela! As supprimer dans les plus
bref délai

A+

Le ven. 13 déc. 2019 à 11:28, Xavier BIZOT  a
écrit :

> J'ai lu la page avec attention...
>
> Par contre je m'interroge sur cette phrase personnellement :
> *Pour certaines informations, il est vivement conseillé de se rendre sur
> le terrain ou d'utiliser StreetView (ou équivalent Mapillary). *
>
> Pour ces attributs il est uniquement conseillé de le faire de visu... Et
> la promotion de StreetView n'est pas obligatoire...
>
> C'est un avis personnel évidemment.
>
>
>
> Le ven. 13 déc. 2019 à 11:01, Quentin Salles 
> a écrit :
>
>> Bonjour,
>>
>> Je vous informe avoir modifié la page
>> https://wiki.openstreetmap.org/wiki/Toulouse/Transports_en_commun
>> afin de prendre en compte le "ref:FR:Tisséo".
>>
>> Cordialement
>>
>> Quentin SALLES
>>
>> Le mer. 11 déc. 2019 à 18:55, lenny.libre  a
>> écrit :
>>
>>> En ce qui concerne le réseau Arc-en-Ciel, quand nous avons choisi le nom
>>> de l'attribut je l'ai ajouté avec son explication dans le wiki, pour ma
>>> part, je n'ai rien fait d'autre ; quelqu'un a dû le lire pour mettre la
>>> règle dans osmose car je ne reçois pas le message que nous recevons pour
>>> Tisséo.
>>>
>>> Je te conseille de le modifier et de le signaler quand la modif sera
>>> faite, en réponse à ton message
>>>
>>> Leni
>>> Le 10/12/2019 à 15:02, Quentin Salles a écrit :
>>>
>>> Bonjour Frédéric,
>>>
>>> Si dans le Wiki OSM de "Toulouse/Transports en commun", je mets à jour
>>> la règle, alors ce sera pris en charge par Osmose ?
>>> Quelle est la procédure pour prendre en compte ce changement ?
>>>
>>>
>>>
>>> Le mar. 10 déc. 2019 à 14:53, Frédéric Rodrigo 
>>> a écrit :
>>>
>>>> Le principe des règles, c'est de corrigé les données, pas les règles.
>>>> La règle est valide et basé sur le wiki OSM.
>>>>
>>>>
>>>>
>>>> Le 10/12/2019 à 14:48, Quentin Salles a écrit :
>>>> > Bonjour,
>>>> >
>>>> > Après avoir demandé à la mail-list de Toulouse, j'ai récemment
>>>> > entrepris de mettre à jour et de remplacer la clé "ref" par
>>>> > "ref:FR:Tisséo" sur les arrêts de bus toulousains. Aujourd'hui,
>>>> Osmose
>>>> > signale tous les arrêts de bus ayant un mauvais suffixe d'attribut
>>>> sur
>>>> > la clé "ref:FR:Tisséo". Est-il possible de corriger cette règle dans
>>>> > le code d'Osmose ?
>>>> >
>>>> > Cordialement.
>>>> >
>>>> > Quentin SALLES
>>>> >
>>>> > ___
>>>> > 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
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Jérôme Seigneuret]

@Tony quelle version de Postgresql Postgis as tu? Tu as fait quelle
configuration ? Encodage de base etc.

('amenity_pnt', 'amenity IS NOT NULL’, ’amenity', ‘name', *‘*access’, 'tags
-> *"*ref:FR:FANTOIR*"*', 'dispatch_point’),

Il y a un problème ici  tu as des guillemets en mode MySQL dans la chaîne
qui ne correspondent pas à ce qu'attend Postgresql

Après -> c'est pas un Cast  hstore -> text c'est une recherche de valeur
donc plutôt  => '"tags" => *"*ref:FR:FANTOIR*"*'  ?

Après une la recherche IS NULL tu peux surement faire une recherche avec
exist(...)





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

> pyrog wrote
> > Imbriquer les guillemets simple dans des doubles (ou vice versa), ça ne
> > fonctionne pas ?
>
> J'ai tout essayé, même la danse du ventre...
>
>
>
>
> -
> 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
>


-- 
Cordialement,
Jérôme Seigneuret
___
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 Seigneuret]

C'est pas le seul dans ce cas. J'ai discuté avec le responsable SIG d'une
intercommunalité qui bascule les données en important tous les points
d'adresse sans vérification depuis l'export de Fantoir.

Pour eux OSM est La données d'entrée donc tous doit y être... La
vérification passe au deuxième plan.

L'adressage varie fortement d'année en année. fusion cadastrale avec une
adresse création de copro. Ajout de numéro ou nom de rue sur des
lotissements.

Bref le point d'entrée pertinent et à jour est difficile à trouver. On fait
des DSP (eau) et de la redevance  incitavice (déchets) et on arrive pas à
avoir des données pertinentes à jour des communes et encore moins à définir
un process pour gérer l'actualisation (problème de moyens et de temps?)

Quelqu'un a déjà défini un processus pour les mise à jour (exemple:
renommage de rue, changement de sens de circulation , création de numéro,
changement d'un adressage en mode métrique ... sur la base d 'arrêté de
voirie?


Le mer. 11 déc. 2019 à 16:29, Vincent de Château-Thierry 
a écrit :

>
> > De: "Vincent de Château-Thierry" 
> >
> > Merci Jérôme pour la veille.
> > Je viens de laisser un commentaire sur un de ses changesets :
> > https://www.openstreetmap.org/changeset/78252330
> >
> > On verra s'il répond (et quoi) pour mieux aviser la suite.
>
> Chabe01 a lu mon commentaire, y a répondu et a engagé une correction
> massive de ses derniers changesets. Une bonne chose. Mais en observant ses
> autres changesets récents je vois qu'il/elle fait de l'import trop massif
> d'adresses pour assurer une quelconque qualité d'intégration, cf.:
> https://www.openstreetmap.org/changeset/78259779
> La discussion du changeset a donc continué... j'espère que la méthode
> changera un peu aussi, au profit d'un rythme moins soutenu. A suivre.
>
> vincent
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Un peu de BANO v2

[Jérôme Seigneuret]

Pour une compréhension simplifié voici les grands principes
https://upload.wikimedia.org/wikipedia/commons/8/85/Creative_commons_license_spectrum_fr.svg


Le mer. 11 déc. 2019 à 14:51, Jérôme Seigneuret 
a écrit :

> https://icon-library.net/icon/export-to-csv-icon-13.html
>
> elle est en CCO donc public domain universel. Pas de droit réservé donc tu
> peux l'utiliser sans contrainte
>
> Merci pour le reste des explications
>
> Le mer. 11 déc. 2019 à 14:11, Vincent de Château-Thierry 
> a écrit :
>
>>
>> > De: "Xavier BIZOT" 
>> >
>> > En haut à droite de couleur verte sur écriture blanche juste à côte
>> > de communes voisines
>>
>> Merci Xavier :)
>>
>> > Le mer. 11 déc. 2019 à 13:54, Donat ROBAUX < dona...@gmail.com > a
>> > écrit :
>> >
>> > Bizarre je ne le vois pas ton bouton d'export .csv même après avoir
>> > supprimé le cache.
>>
>> L'occasion de suggérer la recherche d'un bouton explicite et plus joli et
>> visible *même pour Donat ;) * pour cette nouvelle fonction.
>> J'avais vu celui-ci :
>> https://www.drupal.org/files/styles/grid-3-2x/public/project-images/export-csv.png
>> mais je n'ai pas compris quelle licence s'appliquait, donc dans le doute je
>> n'en ai rien fait. La remarque vaut plus généralement pour le design de
>> toutes les pages Fantoir : avis à celles/ceux qui aiment jouer avec les
>> CSS.
>>
>> vincent
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> --
> Cordialement,
> Jérôme Seigneuret
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Un peu de BANO v2

[Jérôme Seigneuret]

https://icon-library.net/icon/export-to-csv-icon-13.html

elle est en CCO donc public domain universel. Pas de droit réservé donc tu
peux l'utiliser sans contrainte

Merci pour le reste des explications

Le mer. 11 déc. 2019 à 14:11, Vincent de Château-Thierry 
a écrit :

>
> > De: "Xavier BIZOT" 
> >
> > En haut à droite de couleur verte sur écriture blanche juste à côte
> > de communes voisines
>
> Merci Xavier :)
>
> > Le mer. 11 déc. 2019 à 13:54, Donat ROBAUX < dona...@gmail.com > a
> > écrit :
> >
> > Bizarre je ne le vois pas ton bouton d'export .csv même après avoir
> > supprimé le cache.
>
> L'occasion de suggérer la recherche d'un bouton explicite et plus joli et
> visible *même pour Donat ;) * pour cette nouvelle fonction.
> J'avais vu celui-ci :
> https://www.drupal.org/files/styles/grid-3-2x/public/project-images/export-csv.png
> mais je n'ai pas compris quelle licence s'appliquait, donc dans le doute je
> n'en ai rien fait. La remarque vaut plus généralement pour le design de
> toutes les pages Fantoir : avis à celles/ceux qui aiment jouer avec les
> CSS.
>
> vincent
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Un peu de BANO v2

[Jérôme Seigneuret]

Bonjour,

Quelques éléments à ajouter pour préciser les divergences

- Divergence de complétude du nom (prénom présent ou non sur le terrain
mais existant dans Fantoir - Inverse valable)
625101610F RUE GRAMME

- Nom de résidence / Lotissement incorporé au nom de voie

http://dev.cadastre.openstreetmap.fr/fantoir/#insee=62510=0

exemple
625101316L RUE E. VARLIN RES LA BREVA
625102237M RUE LOUISE MICHEL RES LE FOHEN

Parcontre la surcouche pour la carto elle est prévue? Et la synchro sur les
données OSM tu as fais sauter le bouton. La syncrho est devenue journalière?

Merci


Le ven. 15 nov. 2019 à 22:47, deuzeffe  a écrit :

> On 11/11/2019 16:34, Vincent de Château-Thierry wrote:
>
> > Bonjour,
>
> Bonsoir,
>
> > TL;DR : il y a enfin des choses à tester avec BANO v2, c'est par là :
> > https://dev.cadastre.openstreetmap.fr/fantoir/
>
> Superbe travail, plus rapide, plus fluide, plus complet (pas comme le
> cadastre, en somme, ou dans d'autres départements...). Des heures
> pluvieuses à occuper en perspective.
>
> Merci à tous les neurones qui se sont activés pour améliorer le
> terrain de jeu. Ça tombe bien, mon responsable communal de l'urbanisme
> vient de m'envoyer le dernier lot de nouvelles voiesérotation à
> saisir ^^
>
> --
> deuzeffe. Avec du vrai internet, la vie est plus belle.
>
> ___
> 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] Moulinette pour convertir codes Insee en GPS > GPX ?

[Jérôme Seigneuret]

Bonjour,

@christian sur l'api adresse on peut aussi imaginer de définir le niveau
exact où une limite à prévoir dans les types d'objets recherchés,
output=voie, lieudit,ville,commune

Jérôme






Le mer. 2 oct. 2019 à 22:56, Christian Quest  a
écrit :

> api-adresse.data.gouv.fr est fait pour géocoder des adresses, pas des
> noms de ville avec leur code INSEE, ça c'est le boulot de geo.api.gouv.fr
>
> Du coup, oui, 3190 moulins, ça peut être plein de choses...
>
>
> Le mer. 2 oct. 2019 à 19:17, Shohreh  a écrit :
>
>> Samy Mezani wrote
>> > L'API est faite pour automatiser tout ça :
>> >
>> > https://geo.api.gouv.fr/adresse (descendre à /search/csv/)
>>
>> Merci beaucoup.
>>
>> Si d'autres cherchent à faire la même chose :
>> 1. (nécessaire?) Convertir les données entrée en UTF8
>> 2. Downloader curl.exe dans le même répertoire
>> 3. curl --insecure -o output.csv -X POST -F data=@input.csv -F
>> citycode=NOMCOLONNECODEINSEE https://api-adresse.data.gouv.fr/search/csv/
>>
>> Bizarrement, il y a des villes que le serveur n'a pas réussi à géocoder
>> (lat,lon vides):
>>
>> 3190Moulins
>> 44090   La Marne
>> 77083   Champs-sur-Marne
>> 88212   Grand
>> 92072   Sèvres
>> 93039   L'Île-Saint-Denis
>> 93066   Saint-Denis
>>
>>
>>
>> --
>> 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
>>
>
>
> --
> 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

Re: [OSM-talk-fr] fin à venir du rendu osm.org pour shop=yes

[Jérôme Seigneuret]

Même requête sur taginfo fr
https://taginfo.openstreetmap.fr/api/4/key/values?key=shop=all=fr=count=asc=value=json_pretty
<https://taginfo.openstreetmap.org/api/4/key/values?key=shop=all=fr=count=asc=value=json_pretty>


Ca marche bien et évite les autres langues et les données des autres pays
mais c'est bien le but donc c'est cool!

Pour le Framapad tu penses à quoi au résultat?

A compléter avec:
Mise en parallèle des codes APE
Wiki à créer ...
Autres partie bien venu ou à ajouter au fur et à mesure de l'évolution du
document Framapad






Le ven. 23 août 2019 à 14:23, marc marc  a
écrit :

> Le 23.08.19 à 10:37, Jérôme Seigneuret a écrit :
> > Pour ceux que ça intéresse j'ai juste filtré le résultat json de Taginfo
> > (il y a 40% de cas d'erreur de saisie même avec cette requête) J'ai pris
> > des valeur avec plus de 5 entrée dans la page wiki n'existe pas
> >
> https://taginfo.openstreetmap.org/api/4/key/values?key=shop=all=fr=count=asc=value=json_pretty
> >
> > https://jsonpath.com/
> > $.data[?(@.count > 5 && @.in_wiki == false)].[value,count]
> >
> > Peut-on essayer de dégrossir tous ça en parallèle de la correction
> > apportée. Je pense que shop=yes est quand même mis souvent à défaut de
> > trouver une valeur cohérente
>
> tu peux poster le résultat par ex dans un framapad ?
> l'api de taginfo osm.fr ne va pas ?
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] usage de shop=yes sur station service

[Jérôme Seigneuret]

Bonjour,

Je bascule le sujet













*> - soit, option JB, on considère qu'une station service a aussi une
autre> activité et shop=yes est adapté (le POI apparaitra comme station>
service, on n'a pas "besoin" du point shop)Pourquoi shop=yes conviendrait ?
Il n'est pas question de rendu mais dedescription de la station service, et
shop=yes me paraît assez imprécisdans ce cas. En pratique, une
station-service, si elle a un magasinassocié, vend des produits bien
définis, en général du gaz, del'alimentation de base (gâteaux / chips) et
des produits automobiles(essuie-glaces, liquides divers).Du coup, un
shop=convenience;gas me semble plus précis et correct, ycompris s'il est
sur le même nœud que l'amenity=fuel. *

C'est une  possibilité

L'autre étant de dissocier les éléments (c'est aussi la aussi d'échelle de
saisie de données)
On a la même prblématique sur les abris bus avec la possibilité de mettre
bench=yes et waste_basket=yes
 et on peut aller aussi sur de l'indoor

Soit sur le site tu peux dissocié les deux soit les informations sont dans
un élément plus global.

*shop=convenience;gas*
Les valeurs multiples dans une même clé pose toujours des problèmes en
principe le nouveau schéma voudrais que l'on emploi une valeur principale
et que celle ci soit décliné en clé
shop=valeur
valeur:x=
valeur:y=
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] fin à venir du rendu osm.org pour shop=yes

[Jérôme Seigneuret]

@Cyrille37 on va pouvoir booster la list tagging-fr XD

Pour le choix de valeurs il y avait cette liste on peut peut être repartir
sur cette liste pour aborder ces sujets?

Pour en revenir au sujet, si l'on a plus cette clé ça ne changera pas la
face du monde pour les requêtes mais c'est un problème pour le rendu.
@MarcMarc il y a un rendu par défaut pour toute les autres valeurs
renseignés ou juste celle connu d'une liste exploité/ foisonné par osmcarto?
Sinon osmcarto va avoir du travail sauf à mettre un point si pas de figuré
spécifique

JOSM peut t'il proposer une liste un peu plus exhaustive (de base sans
avoir à charger autre chose) ou aller sur le wiki systématiquement

Le wiki peut être plus complet avec un possible parallèle avec les grands
types d'activités proposées en code APE pour simplifier la saisie. En soit
les activités commerciales/artisanales/industrielles sont presque une
couche de données isolées

Je pense qu'en regardant sur TagInfo ou peut trouver pas mal de valeurs
sans description sur le wiki

A l'heure actuelle c'est plus de 174000 valeurs à reprendre dont d'autre en
langue locale et une partie avec des problèmes de case des caractères
(c'est pas limité à la France)

Exemple :

Pour ceux que ça intéresse j'ai juste filtré le résultat json de Taginfo
(il y a 40% de cas d'erreur de saisie même avec cette requête) J'ai pris
des valeur avec plus de 5 entrée dans la page wiki n'existe pas
https://taginfo.openstreetmap.org/api/4/key/values?key=shop=all=fr=count=asc=value=json_pretty

https://jsonpath.com/
$.data[?(@.count > 5 && @.in_wiki == false)].[value,count]

Peut-on essayer de dégrossir tous ça en parallèle de la correction
apportée. Je pense que shop=yes est quand même mis souvent à défaut de
trouver une valeur cohérente

Le ven. 23 août 2019 à 10:29,  a écrit :

> De deux choses l'une :
> - soit, option JB, on considère qu'une station service a aussi une autre
> activité et shop=yes est adapté (le POI apparaitra comme station service,
> on n'a pas "besoin" du point shop)
> - soit, option marc_marc, on considère qu'il s'agit de deux activités
> différentes et alors un shop=convenience ou car_parts voir gas est sans
> doute adapté. Mais dans ce cas on mettra plutôt deux POI avec le risque que
> le POI shop soit affiché au dépendant du POI station service. Alors qu'en
> premier lieu une station service sert du combustible liquide pour la
> propulsion automobile.
>
> Les deux peuvent être adaptés suivant le cas.
> Le 23/08/2019 à 08:25, JB - jb...@mailoo.org a écrit :
>
> Le 22/08/2019 à 22:44, marc marc a écrit :
>
> Le 22.08.19 à 21:18, Jacques Lavignotte a écrit :
>
> J'en ai 2 qui sont des stations-service (essence/gas-oil) qui ont  une «
> boutique » Dans ce cas shop=yes n'est-il pas de bon aloi ?
>
> l'idéal c'est 2 objets, surtout qu'ils ont souvent des horaires
> d'ouverture, des moyens de payement et une position différente "dehors"
> <> dans un batiment
>
> Avec quel tags pour la boutique ? shop=yes en complément d'une station
> service, ça me semblait bien défini :
> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dfuel#Additional_services
>
>
> ___
> 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
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] fin à venir du rendu osm.org pour shop=yes

[Jérôme Seigneuret]

Bonjour, pour faire le point en Occitanie

Arriège : 8 points, 2 polygones
https://overpass-turbo.eu/s/LKw

Aude : 2 points, 5 polygones
https://overpass-turbo.eu/s/LKx

Aveyron: 9 points
https://overpass-turbo.eu/s/LKy

Gard : 2 points, 3 polygones
https://overpass-turbo.eu/s/LKv

Gers : 13 points, 2 polygones
https://overpass-turbo.eu/s/LKB

Haute Garonne : 53 points, 18 polygones
https://overpass-turbo.eu/s/LKA

Hérault : 78 points, 18 polygones dont une partie de mes contributions (par
flemme de trouver la bon type)
https://overpass-turbo.eu/s/LKu

Lot: 6 points, 5 polygones
https://overpass-turbo.eu/s/LKC

Lozère : 3 points 2 polygones
https://overpass-turbo.eu/s/LKD

Hautes-Pyrénées: 1 point 2 polygones
https://overpass-turbo.eu/s/LKE

Pyrénées-Orientales 14 points, 6 polygones
https://overpass-turbo.eu/s/LKF

Tarn; 5 points, 1 polygone
https://overpass-turbo.eu/s/LKG

Tarn-et-Garonne: 3 points, 5 Polygones
https://overpass-turbo.eu/s/LKI

On peut faire une page wiki de suivi? par département je pense que c'est
suffisant.

Le ven. 23 août 2019 à 08:26, JB  a écrit :

> Le 22/08/2019 à 22:44, marc marc a écrit :
> > Le 22.08.19 à 21:18, Jacques Lavignotte a écrit :
> >> J'en ai 2 qui sont des stations-service (essence/gas-oil) qui ont  une «
> >> boutique » Dans ce cas shop=yes n'est-il pas de bon aloi ?
> > l'idéal c'est 2 objets, surtout qu'ils ont souvent des horaires
> > d'ouverture, des moyens de payement et une position différente "dehors"
> > <> dans un batiment
> Avec quel tags pour la boutique ? shop=yes en complément d'une station
> service, ça me semblait bien défini :
> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dfuel#Additional_services
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Importations traces GR30

[Jérôme Seigneuret]

mouhahah!


Le mer. 21 août 2019 à 21:55, pepilepi...@ovh.fr  a
écrit :

> Le 21/08/2019 à 21:34, Adrien Grellier via Talk-fr a écrit :
>
> Le 21/08/2019 à 20:26, Jérôme Seigneuret a écrit :
>
>
> A vous de trouver un moyen que le circuit ne soit un GR sinon ça devra
> être enlevé simplement. Si certains veulent à tous pris mettre ça en base
> ce sera donc au SOTM de trancher avec les personnes amener à définir les
> conditions de nettoyage. Si la proposition d'itinéraire est faite avant
> celle de la FFR dans ce cas on pourra aussi attaquer en tant que copie si
> le droit de cité n'est pas respecter vu que l'on est pas dans une oeuvre
> interdisant la copie.
>
> Au risque de me répéter, il y a des sentiers en OpenData, par exemple les
> GR, GRP et PR de Loire Atlantique. Il n'y a aucune raison d'enlever ces
> sentiers. Pour les GR qui ne sont pas en OpenData, OSM peut tous les
> supprimer, mais à mon avis c'est vraiment stupide.
>
> 
>
> On pourrait pas les appeler "Sentier dont on ne peut pas dire le nom" ?
>
> 
>
> (OK, je vais me coucher !)
>
> Avec une telle action, sans aucune injonction de la FFRP, au moins le
> message sera clair : OSM ne sera jamais fait pour la rando en France, ce
> qui est bien dommage vu l'offre logiciel disponible (notamment OSMand)
>
> Adrien
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
> --
> --
>
> Si ma réponse n'a pas résolu ton problème, c'est que tu n'as pas posé la
> bonne question
>
> _______
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Importations traces GR30

[Jérôme Seigneuret]

Bonjour,
OSM n'est pas là pour reprendre des données existantes tous comme on ne
reprend pas la base IGN

Il y a bien des outils qui permettent de faire des itinéraires sans pour
autant reprendre ce des GR GRP et PR.

Comme mentionné précédemment: S'il n'y a qu'un chemin et que celui-ci sert
à parcourir la cote ou aller d'un point A à B c'est ce que peut faire un
moteur d'itinéraire.

Des itinéraires il y en a pleins et en plus on choisi pas forcément de
faire toutes les étapes.

Visio Rando est un outil destiné à faire de l'itinéraire sur la base de
trace GPX qui plus est enrichi avec des messages contextuelle et pas
seulement tournée à droite...

En soit les étapes d'une trace qui ne sont pas parfaitement le GR ne pose
pas de problème. Le problème c'est d'avoir un contributeur qui voit la
trace, y trouve la référence au GR, et répercute la relation dans la base.

Tracer un chemin physique n'est pas un souci. La route existe en tant que
tel. C'est la relation de type itinéraire qui est un problème.

Maintenant vous voulez la référence au GR vous faites ça en Umap Privé ou
vous listez les points d'étapes pour les mettre dans OSMand ou autre outil
de routing et on en parle plus...




Le mer. 21 août 2019 à 21:35, Adrien Grellier via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Le 21/08/2019 à 20:26, Jérôme Seigneuret a écrit :
>
>
> A vous de trouver un moyen que le circuit ne soit un GR sinon ça devra
> être enlevé simplement. Si certains veulent à tous pris mettre ça en base
> ce sera donc au SOTM de trancher avec les personnes amener à définir les
> conditions de nettoyage. Si la proposition d'itinéraire est faite avant
> celle de la FFR dans ce cas on pourra aussi attaquer en tant que copie si
> le droit de cité n'est pas respecter vu que l'on est pas dans une oeuvre
> interdisant la copie.
>
> Au risque de me répéter, il y a des sentiers en OpenData, par exemple les
> GR, GRP et PR de Loire Atlantique. Il n'y a aucune raison d'enlever ces
> sentiers. Pour les GR qui ne sont pas en OpenData, OSM peut tous les
> supprimer, mais à mon avis c'est vraiment stupide.
>
> Avec une telle action, sans aucune injonction de la FFRP, au moins le
> message sera clair : OSM ne sera jamais fait pour la rando en France, ce
> qui est bien dommage vu l'offre logiciel disponible (notamment OSMand)
>
> Adrien
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Importations traces GR30

[Jérôme Seigneuret]

Bonjour,

*J’avais un peu le béguin pour « Du Mont-Saint-Michel à Saint-Nazaire » qui
était plus informatif pour les consommateurs.  *

C'est un peu comme si l'on fait pour les itinéraires de Bus et de Train.
Maintenant c'est itinétaires sont contraints ce qui n'est pas le cas d'un
itinéraire piétons. Sauf matérialisation public et non GR il n'y a pas
d'itinéraire ou il y en en autant que de destination. (Sauf affichage
public et accord de celui qui le diffuse avec droit de cité)

Dans tous les cas
Il faut trouver des termes qui n'utilise pas GR ... Mais le fait de ne pas
mentionner le nom n'en change pas le fait que l'on copie et diffuse un
itinéraire... Donc c'est tout aussi attaquable...

Tu copie le linéaire IGN et tu changes le nom ou la dénomination ça
changera pas le fait que c'est des données IGN à la base.

Bref. Il faut reprendre des sentiers avec des niveaux locaux les agréger
pour en faire des départementaux ou des régionaux voir plus sans qu'il n'y
ai de similitude parfaite sauf accord de propriétaire initiale.

Nous pouvons donc proposer des itinéraires dont les tracés ne sont pas
semblable à ceux des GR que le chemin physique existe ou non. La où il n'y
aura pas d'ouvre de l'esprit c'est si c'est le seul chemin possible pour
aller d'un point A à un point B ou si des moteurs cartographique sont
câbles de générer ces itinéraires. En clair les GR propose aussi de voir
des points de vues, des bâtiments ETC

A vous de trouver un moyen que le circuit ne soit un GR sinon ça devra être
enlevé simplement. Si certains veulent à tous pris mettre ça en base ce
sera donc au SOTM de trancher avec les personnes amener à définir les
conditions de nettoyage. Si la proposition d'itinéraire est faite avant
celle de la FFR dans ce cas on pourra aussi attaquer en tant que copie si
le droit de cité n'est pas respecter vu que l'on est pas dans une oeuvre
interdisant la copie.

On a Michelin qui à créer des Atlas sur base OSM il me semble.

Bref même les communes qui ne veulent pas que l'on saisisse leurs
itinéraires (ex: car il font un commerce autour de pub avec l'itinéraire
fourni en office de tourisme) pourraient attaquer pour non respect de la
propriété intellectuelle.



Le mer. 21 août 2019 à 19:52, Christian Rogel <
christian.ro...@club-internet.fr> a écrit :

>
>
> Le 21 août 2019 à 19:35, osm.sanspourr...@spamgourmet.com a écrit :
>
>
>
> -quelle dénomination donner au linéaire en question, du coup ? Est-ce
> ‘GR30’ ? Sinon quoi mettre ?
>
> Rien. Tout simplement rien.
>
> "highway=path", point final. Peut-être trail_visibility=*, surface=*, mais
> pas de name=*, ref=*
>
>
>
> KISS
>
> Sentier littoral serait une dénomination qui sentirait un peu le
> bureaucrate amoureux des termes « techniques ». (disclaimer : j’ai fait des
> études de géographie).
>
> Dés que je vois un GR 34, que ce soit dans le Finistère ou sur les rives
> du Golfe du Morbihan, je le tagge « Sentier Côtier », car c’est assez
> souvent ainsi  que les panneaux directionnels (de toute tailles) le
> désignent.
> Je garde la faute typographique (capitale à un adjectif), car c’est ce que
> je vois sur le terrain.
> « Sentier littoral » est apparu plus récemment, probablement sous
> l’influence du Conservatoire du Littoral.
>
> Je renvoie à un post précédent sur le nom qui vient d’être donné à la
> relation, « Chemin des douaniers », car, on le trouve peu et concurremment
> avec « Sentier des douaniers ».
> J’avais un peu le béguin pour « Du Mont-Saint-Michel à Saint-Nazaire » qui
> était plus informatif pour les consommateurs.
>
>
> Christian R.
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Vacances scolaires dans opening_hours

[Jérôme Seigneuret]

@Yves si il est ouvert quelque soit la zone ça sert à rien de le mentionner
vu qu'il est ouvert de base

Le mar. 20 août 2019 à 15:07, Yves P.  a écrit :

>
>
> Le mar. 20 août 2019 à 14:12, Jérôme Seigneuret <
> jerome.seigneu...@gmail.com> a écrit :
>
>>
>> La partie SH se suffit à elle même c'est comme quand on parle des jours
>> férié.
>>
> ??
>
>
>> Concernant les commerces je vais juste une question qui me trotte.
>> As-t-on des commerces/services qui seraient ouverts ou fermés mais sur la
>> zone d'une autre académie?
>>
> Au moins un, le musée cité dans mes 2 premiers messages.
> Il est ouvert quelque soit la zone.
>
> --
> Yves
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Sur rendez-vous

[Jérôme Seigneuret]

Bonjour,
On est sur de la réservation pendant les horaires d'ouvertures. Pourquoi
voudrais-tu utiliser une autre clé? En soit c'est la bonne clé.
Si on veut gérer des horaires globaux d'ouvertures on le met avec un
contexte
*09:00-12:00 open "*reservation only*", 14:00-19:00 open "public room"*


booking c'est forcément de la réservation hors c'est pas le cas pour les
médecins. On parle pas là d'horaire pendant lesquels on peut appeler pour
réserver. De plus certains médecins ne prennent même plus le temps de
répondre au téléphone pour les réservations. C'est un répondeur qui demande
d'utiliser une plateforme de réservation en ligne.

et encore on pourrait utiliser  *09:00-11:00 "call us for reservation"*

Jérôme

Le mar. 20 août 2019 à 12:39, Topographe Fou  a
écrit :

> Bonjour,
>
> Il vaut mieux à mon sens éviter d'utiliser le champ opening_hours pour
> cela, sinon on en arrive à mélanger la maintenance des horaires avec celle
> des multiples possibilités de réservation (téléphone mais aussi Internet,
> sur place...). En plus le standard n'a pas forcément les mêmes horaires que
> les consultations. Idem pour Internet (24/7). La proposition de Marc est
> préférable à mes yeux : mettre la réservation sur un tag dédié (voir aussi
> la direction qui avait eu lieu en juin je crois sur la réservation
> hôtelière avec le débat booking=*) et laisser les horaires d'ouverture pour
> les horaires d'ouverture.
>
> C'est bien différent d'un magasin qui n'ouvrirait que sur rendez-vous
> (sens de l'usage dans opening_hours).
>
> Cordialement,
>
> LeTopographeFou
>
>
>   Message original
>
>
>
> De: marc_marc_...@hotmail.com
> Envoyé: 20 août 2019 9:41 AM
> À: talk-fr@openstreetmap.org
> Répondre à: talk-fr@openstreetmap.org
> Objet: Re: [OSM-talk-fr] Sur rendez-vous
>
>
> Bonjour
>
> Le 19.08.19 à 18:52, David Crochet a écrit :
> > Le 19/08/2019 à 18:39, Jacques Lavignotte a écrit :
> >> je ne sais pas indiquer que voir la dentiste est uniquement « sur
> >> rendez-vous »
> >
> > *opening_hours=xx:xx* |"||reservation by phone"|
> >
> > en remplacant xx:xx par les jours/horaires d'ouverture
>
> il y aussi reservation=required
> https://wiki.openstreetmap.org/wiki/FR%3AKey%3Areservation
>
> 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
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Vacances scolaires dans opening_hours

[Jérôme Seigneuret]

relations *boundary educational.*
>> > *
>> > *
>> > Et/ou aussi étendre la syntaxe *SH* en spécifiant une zone ?
>> > SH A,C // vacances scolaires zone A et C
>> >
>> > J'ai un musée qui à des horaires d'ouvertures spécifiques pour les
>> > vacances scolaires quelque soit la zone :
>> > https://www.atelierdessavoirfaire.fr/
>> >
>> > En attendant, peut-on définir des vacances comme "Vacances xxx zone
>> Y" ?
>> >
>> > Exemple : Vacances d'hiver zone A
>> > https://www.education.gouv.fr/pid25058/le-calendrier-scolaire.html
>> >
>> > Fin des cours :
>> > samedi 22 février 2020
>> > Reprise des cours :
>> > lundi 9 mars 202
>> >
>> >SH:
>> >  - name: Vacances d'hiver zone A
>> >'2020': [2, 23, 3, 8]
>> >
>> > Fichier pour l'Allemagne (contient des définitions pour les vacances
>> > scolaires)
>> >
>> https://github.com/opening-hours/opening_hours.js/blob/master/holidays/de.yaml
>> >
>> > __
>> > Yves
>> > **
>> >
>> >
>> > ___
>> > Talk-fr mailing list
>> > Talk-fr@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-fr
>> >
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> --
> Christian Quest - OpenStreetMap France
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] OpenInfraMap - suggestion

[Jérôme Seigneuret]

Salut,
On est partout ;-)
Nous plus sérieusement c'est Russ Garrett qu'il faut voir pour cette partie
 https://russ.garrett.co.uk/

Pour le contacter
https://russ.garrett.co.uk/contact/


Le lun. 12 août 2019 à 16:31, David Crochet  a
écrit :

> Bonjour
>
> Je ne sais pas si les contributeur a OpenInfraMap sont également sur
> cette liste, mais Il serait intéressant de modulé l'opacité des données,
> car les données "Oil & Gaz" étant d'une couleur très clair, il est pas
> facile de les visualiser.
>
> Cordialement
>
> --
> David Crochet
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr