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

2020-05-13 Par sujet 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] Evolution des règles pour les plages et la ligne de côte (zones et traits)

2020-05-13 Par sujet Thomas Petillon 
>
> C'est à dire que c'est la moyenne des vives-eaux (95) et non la moyenne
> des vives-eaux d'équinoxes (100).


Oui, je t'ai dit 100 l'autre jour, mais j'ai réanalysé la question et suis
tombé sur 95. (La définition officielle qu'on retrouve un peu partout n'est
pas de la plus grande limpidité.) La différence n'est pas énorme, mais
c'est mieux si on est tous d'accord !

Comme en Allemagne, *les limites des communes sont à la pleine mer de 120
> et le trait de côte à 95*.
>

+1

Je serais pour ne pas découper plus que nécessaire en strates horizontales
> pour ne garder que des iso-lignes ou des isobathes : limites des communes,
> trait de côte, sans doute 0 des cartes terrestres et en plus 0 des cartes
> marines. Mais le wiki parle de BMVE et non du 0 des cartes marines.
>

Pourquoi pas, mais il n'y a pas de tag établi pour la ligne de mi-marée,
pour autant que je sache.

Pour les beach, on les met du DPM à quoi ? BMVE serait logique dans OSM,
> car on utilise PMVE.
>

D'accord aussi. (Avoir une source fiable pour le tracer est un autre
problème.)

Blague à part, *vus les profils des plages ça revient à positionner les
> plages en mer* ! Donc les arrêter à la ligne de mi-marée ne serait pas
> déconnant (c'est aussi la partie de la plage la plus utilisée).
>

Je penche pour quelque-chose comme ça aussi.

Et on évite ces hérésies de tidalflat et de tidal=yes : natural=sand, mud,
> gravel d'un côté et des traits de côtes y compris de basses côtes
>

Le tag tidal=yes permet d'éviter à avoir à faire des opérations de clipping
pour obtenir les surfaces de l'estran. Mais par contre il oblige à découper
en deux certaines features, comme les plages, ce qui est pas top non plus.

Là où c'est peut-être utile de se mettre d'accord c'est de savoir si la
> limite sable/roche on la met plutôt en hiver ou en été. J'aurais tendance à
> dire en été car il y a plus de monde à fréquenter le littoral en été. Des
> objections ?
>

 À moins que la différence soit grande, dans la pratique, ça risque plutôt
d'être calé sur ce qui est disponible comme imagerie. (Mais elles ne sont
pas faites en hiver, donc ça répond involontairement à la question.)

Thomas.

On Wed, 13 May 2020 at 22:19,  wrote:

> Bonjour,
>
> résumé : on a un carroyage plus qu'un code barre, mais pour donner une
> image il faut dessiner les lignes et pas les carreaux.
>
> *on a verticalement des natures de sol *(vase, sable, gravier,  galets,
> blocs, roche).
>
> avec potentiellement des couvertures (landcover ?) pour les dunes
> . Je connaissais les dunes blanches,
> grises, il faut ajouter les dunes vertes, les noires et les brunes.
>
> Typiquement on ne trouvera pas les dunes vertes dans OSM (trop mobiles :
> c'est le bas de dune comportant juste quelques plantes pionnières et le
> sable reste bien visible).
>
> *Et horizontalement du plus haut au plus bas des traits plus ou moins de
> côte* (DPM, PMVE, 0 cartes terrestres, BMVE, 0 cartes marines, ligne de
> base) :
>
> - la limite théorique haute (pleine mer "maximale" de coefficient de 120)
> correspond en théorie à la limite du domaine public maritime (DPM pour les
> intimes) et des communes. En théorie car des polders peuvent avoir changé
> la donne et placé - ou pas - des zones asséchées en zones terrestres,
> - la limite de trait de côté OSM (pleine mer de vive-eau moyenne de
> coefficient de 95) - PMVE,
> - la mi-marée (correspond au 0 des cartes terrestres même s'il est mesuré
> à partir de la mi-marée à Marseille) - MM,
> - la limite de basse mer de vive-eau moyenne (de coefficient de 95) -
> BMVE, c'est traditionnellement le 0 des cartes marines britanniques) !
> - la limite théorique basse (basse mer "maximale" dite astronomique, de
> coefficient de 120) correspond en zone rocheuse saillante à la ligne de
> base - ligne servant à la délimitation des zones en mer, ligne qui se tague
> boundary=administrative + boundary:type=baseline. C'est le 0 des cartes
> électroniques marines et actuellement aussi le 0 des cartes du SHOM et de
> ses équivalents britanniques et allemands.
>
> Ouf ;-).
>
> Les références sont toujours par pression atmosphérique normale et pour
> les cours d'eau avec un débit d'eau douce moyen. Et les coefficients
> calculés à partir du port de Brest. Oui une définition franco-française
> mais homogène avec les définitions internationales.
>
> 95 ou 100 ? il n'y a guère de différence pratique, selon Wikipédia on
> devrait prendre 95 comme indiqué sur le wiki :
> *C = 95*, définit une vive-eau moyenne *C = 100*, définit une vive-eau
> équinoxiale moyenne
>
> Je serais pour ne pas découper plus que nécessaire en strates horizontales
> pour ne garder que des iso-lignes ou des isobathes : limites des communes,
> trait de côte, sans doute 0 des cartes terrestres et en plus 0 des cartes
> marines. Mais le wiki parle de BMVE et non du 0 des cartes marines.
>
> Pour les beach (plages ou grèves - la distinction est importante puisque
> les plages sont

Re: [OSM-talk-fr] Evolution des règles pour les plages et la ligne de côte

2020-05-13 Par sujet Thomas Petillon 
>
> J'irais jusqu'à dire qu'il y a eu regression dans le rendu des côtes.


Tout à fait d'accord, il y a eu pas mal de perte d'informations et c'est
dommage. Il y a eu un certain nombre de changements liés dans le code de
rendu. Mais de ce que j'en comprends, le code a évolué de sorte à ce que ça
soit possible d'obtenir de meilleurs rendus à l'avenir. (Mais il reste
encore du boulot, comme
https://github.com/gravitystorm/openstreetmap-carto/issues/3854)

Bon, certains diront que j'ai triché car j'ai utilisé la transparence nomal
> du tidalflat pour recouvrir les rochers/sand qui normalement n'auraient pas
> dû etre visible (je peux expliquer) mais avouez que c'est une carte tres
> correcte, juste et exploitable.
>

Ce qui est le plus long, c'est de créer les géométries, après les tags ça
peut se changer facilement. Donc de mon point de vue, comme ça va
clairement dans la bonne direction, je trouve ça super tous les tidalflats
que tu as fait. :)


> Sauf que je trouve le natural=wetland justifié et qu'un wetland=tidal en
> secondaire serait parfait à la place d'un wetland=tidalflat vu qu'il existe
> déjà des natural=mud pour la vase (plutot bien cartographié en france grace
> aux landcover)
>

Effectivement, wetland pour tout l'estran a du sens. Mais pour garder la
distinction vase/rochers/etc., il faudrait plutôt utiliser des tags
spécifiques pour chaque type, genre wetland=tidal_rocks, etc. (Vu qu'on
peut pas utiliser natural=bare_rock en plus de natural=wetland.) C'est pas
forcément déconnant, mais j'ai l'impression que ça serait plus difficile à
faire adopter qu'ajouter tidal=yes sur des tags habituels. (Voire juste
utiliser l'information que le polygone est au large du trait de côte.)

Pour les limites mer/fleuve, c'est plus compliqué effectivement et la
> reponse est peut etre à etudier mais j'ai peur que la solution ne soit que
> franco francaise vu que la limite cartographié de salinité officielle (par
> exemple mais c'est la même chose pour les autres) n'existe qu'ici.
>

Les sources que j'ai cité permettent d'avoir des informations intéressantes
quand on mappe en France. Mais les critères doivent être les mêmes partout,
oui. Toute la difficulté est de trouver ces critères.

Thomas.

On Wed, 13 May 2020 at 15:34, Djo_man via Talk-fr 
wrote:

> Bonjour,
>
> Oui, c'est aussi mon point de vue pour les plages, les rochers et le
> tidalflat.
>
> Sauf que je trouve le natural=wetland justifié et qu'un wetland=tidal en
> secondaire serait parfait à la place d'un wetland=tidalflat vu qu'il existe
> déjà des natural=mud pour la vase (plutot bien cartographié en france grace
> aux landcover)
>
> Pour les limites mer/fleuve, c'est plus compliqué effectivement et la
> reponse est peut etre à etudier mais j'ai peur que la solution ne soit que
> franco francaise vu que la limite cartographié de salinité officielle (par
> exemple mais c'est la même chose pour les autres) n'existe qu'ici.
>
> Djo man
>
> Envoyé depuis mon smartphone Xperia de Sony
>
>
>  Thomas Petillon a écrit 
>
> Bonsoir,
>
> Super boulot Djo man ! :)
>
> Quelques remarques et ajouts :
>
> Plages
> Je pense que les polygones natural=beach devraient couvrir l'intégralité
> des places, à savoir au-dessus et en-dessous du trait de côte. Il y a des
> difficultés techniques à rendre ça correctement dans openstreetmap-carto
> , mais maintenant
> que le rendu des mers à été changé, ça ne devrait pas être insurmontable.
>
> Tidalflats
> Ce tag est effectivement utilisé à quelques endroits pour représenter
> l'intégralité de l'estran (https://osm.org/go/erkO8n5D--,
> https://osm.org/go/eq0l5im8-). Je pense que ça vient du fait qu'il
> apparait sur le rendu. Mais sémantiquement je dirais qu'il n'est à utiliser
> que pour les zones de vase ou sable. Si c'est des rochers, il n'y a pas de
> raison qu'on ne puisse pas taguer ça en rocher, juste parce que c'est
> recouvert par la marée. Avec qu'un seul tag, on perd beaucoup
> d'informations.
>
> Placement du trait de côte
> Pour la marée basse, Géolittoral est pratique, mais pour la marée haute
> c'est plus compliqué. Le trait de côte Histolitt monte trop haut
> (coefficient 120). Sinon, ça n'est pas extrêmement précis, car ce sont des
> images satellites et non aériennes, mais lorsque j'ai un doute j'utilise
> les images de Sentinel à partir d'ici :
> https://apps.sentinel-hub.com/eo-browser/. En remontant dans les
> archives, on tombe forcément sur des photos où il fait à la fois beau et où
> la marée est haute.
> On peut aussi regarder les photos d'archive de l'IGN (
> https://remonterletemps.ign.fr/), à condition que la zone n'ai pas changé
> depuis.
>
> Pour regarder rapidement et simplement le trait de côte version OSM,
> j'utilise http://tools.geofabrik.de/osmi/?view=coastline.
>
> Limites mer/rivières
> Il serait intéressant d'ajouter une slide ou deux au document pour parler
> des embouchures. Ici la difficulté principale est de savoir où

Re: [OSM-talk-fr] Evolution des règles pour les plages et la ligne de côte (zones et traits)

2020-05-13 Par sujet osm . sanspourriel 

Bonjour,

résumé : on a un carroyage plus qu'un code barre, mais pour donner une
image il faut dessiner les lignes et pas les carreaux.

/on a verticalement des natures de sol /(vase, sable, gravier,  galets,
blocs, roche).

avec potentiellement des couvertures (landcover ?) pour les dunes
. Je connaissais les dunes blanches,
grises, il faut ajouter les dunes vertes, les noires et les brunes.

Typiquement on ne trouvera pas les dunes vertes dans OSM (trop mobiles :
c'est le bas de dune comportant juste quelques plantes pionnières et le
sable reste bien visible).

/Et horizontalement du plus haut au plus bas des traits plus ou moins de
côte/ (DPM, PMVE, 0 cartes terrestres, BMVE, 0 cartes marines, ligne de
base) :

- la limite théorique haute (pleine mer "maximale" de coefficient de
120) correspond en théorie à la limite du domaine public maritime (DPM
pour les intimes) et des communes. En théorie car des polders peuvent
avoir changé la donne et placé - ou pas - des zones asséchées en zones
terrestres,
- la limite de trait de côté OSM (pleine mer de vive-eau moyenne de
coefficient de 95) - PMVE,
- la mi-marée (correspond au 0 des cartes terrestres même s'il est
mesuré à partir de la mi-marée à Marseille) - MM,
- la limite de basse mer de vive-eau moyenne (de coefficient de 95) -
BMVE, c'est traditionnellement le 0 des cartes marines britanniques) !
- la limite théorique basse (basse mer "maximale" dite astronomique, de
coefficient de 120) correspond en zone rocheuse saillante à la ligne de
base - ligne servant à la délimitation des zones en mer, ligne qui se
tague boundary=administrative + boundary:type=baseline. C'est le 0 des
cartes électroniques marines et actuellement aussi le 0 des cartes du
SHOM et de ses équivalents britanniques et allemands.

Ouf ;-).

Les références sont toujours par pression atmosphérique normale et pour
les cours d'eau avec un débit d'eau douce moyen. Et les coefficients
calculés à partir du port de Brest. Oui une définition franco-française
mais homogène avec les définitions internationales.

95 ou 100 ? il n'y a guère de différence pratique, selon Wikipédia on
devrait prendre 95 comme indiqué sur le wiki :

   *C = 95*, définit une vive-eau moyenne
   *C = 100*, définit une vive-eau équinoxiale moyenne

Je serais pour ne pas découper plus que nécessaire en strates
horizontales pour ne garder que des iso-lignes ou des isobathes :
limites des communes, trait de côte, sans doute 0 des cartes terrestres
et en plus 0 des cartes marines. Mais le wiki parle de BMVE et non du 0
des cartes marines.

Pour les beach (plages ou grèves - la distinction est importante puisque
les plages sont interdites par défaut et les grèves pas sauf si elles
servent d'accès à la mer(*)), on les met du DPM à quoi ? BMVE serait
logique dans OSM, car on utilise PMVE. Et si quelqu'un veut mettre son
rond de serviette, heu sa serviette, au niveau 0 absolu, il risque de ne
le mettre qu'une fois tous les 20 ans sur un sable détrempé.

Djo man, c'est bien le BMVE et non le BMME.

Blague à part, *vus les profils des plages ça revient à positionner les
plages en mer* ! Donc les arrêter à la ligne de mi-marée ne serait pas
déconnant (c'est aussi la partie de la plage la plus utilisée). Je dis
plages mais je pense beach : les grèves sont incluses. Mais peut-être
qu'on peut laisser le moteur de rendu repositionner le nom dans les terres.

De plus (mais c'est une mauvaise raison) l'imagerie est souvent coupée
avant.

Pourquoi le 0 des cartes terrestres ? C'est intéressant pour avoir une
idée du profil de marée / de la plage. Pas prévu par OSM, sauf à faire
des way avec ele=0.

Trait absolu de basse mer : idem et de plus utile pour le calcul des
lignes de base. Et comme dit par Thomas on a ce qu'il faut pour le faire
en France.

Et comme ça, pour faire un rendu propre, on ajoute un dégradé
transparent bleuté entre ces lignes.

Et on évite ces hérésies de tidalflat et de tidal=yes : natural=sand,
mud, gravel d'un côté et des traits de côtes y compris de basses côtes
(désolé pour les végans^^).

Je dis hérésie c'est pourtant cette horreur qui est décrite dans le wiki
anglais  :

/Mean low water springs
//is the position of
the lowest tide. There is currently no agreed way of tagging this line
in OSM. One way of tagging it is to tag the area between mean low water
springs and OSM coastline as //natural
=wetland
//+//wetland
=tidalflat
//. /

Si on arrive à nous mettre d'accord, on pourra envisager une proposition
au niveau international.

Le 13/05/2020 à 14:36, Denis Bigorgne - denis.bigor...@gmail.com a écrit :

en clair que la position de la coastline change

Re: [OSM-talk-fr] covid19 : horaires post confinement

2020-05-13 Par sujet Frantz 
Bonjour,

13 mai 2020 19:43 osm.sanspourr...@spamgourmet.com a écrit:

> Bonjour,
> 
> dans cette phase de déconfinement, les horaires parfois ne sont ni ceux
> d'avant le confinement ni ceux du confinement.
> 
> Doit-on les mettre en opening_hours ou en opening_hours:covid19 ?
> 
> Je suppose que nous devons conserver l'usage des :covid19 tant qu'il y a
> des restrictions liées au covid-19.

Il faut mettre à jour les :covid19, opening_hours garde les horaires ordinaires 
que l'on retrouvera un jour ;)

-- 
Frantz

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

Re: [OSM-talk-fr] covid19 : horaires post confinement

2020-05-13 Par sujet PanierAvide 

Bonjour,

Ça me paraît judicieux de conserver l'usage du opening_hours:covid19 
tant que nous ne serons pas revenus à une situation "normale" (le 
déconfinement commence, nous sommes toujours en état d'urgence 
sanitaire, toujours des restrictions...). L'interprétation à donner au 
suffixe ":covid19" est "durant la crise sanitaire".


Cordialement,

Adrien P.

Le 13/05/2020 à 19:43, osm.sanspourr...@spamgourmet.com a écrit :

Bonjour,

dans cette phase de déconfinement, les horaires parfois ne sont ni ceux
d'avant le confinement ni ceux du confinement.

Doit-on les mettre en opening_hours ou en opening_hours:covid19 ?

Je suppose que nous devons conserver l'usage des :covid19 tant qu'il y a
des restrictions liées au covid-19.

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

[OSM-talk-fr] covid19 : horaires post confinement

2020-05-13 Par sujet osm . sanspourriel 

Bonjour,

dans cette phase de déconfinement, les horaires parfois ne sont ni ceux
d'avant le confinement ni ceux du confinement.

Doit-on les mettre en opening_hours ou en opening_hours:covid19 ?

Je suppose que nous devons conserver l'usage des :covid19 tant qu'il y a
des restrictions liées au covid-19.

Jean-Yvon



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

Re: [OSM-talk-fr] Nouvel outil : od2osm

2020-05-13 Par sujet PanierAvide 

Bonjour Nicolas,

À noter que tu peux t'amuser avec JOSM à envoyer des points sur le 
serveur de dév OSM. La procédure :


- Télécharger sur le serveur prod OSM les données d'une zone
- Enregistrer en OSM XML
- Modifier avec un éditeur texte les identifiants de tous les objets 
pour les passer en négatif (avec une regex)

- Ouvrir avec JOSM le fichier édité et le pousser sur le serveur de dev

Ça permet de simuler avec un peu plus de données que ce qu'il peut y 
avoir à défaut.


Cordialement,

Adrien P.

Le 13/05/2020 à 19:00, Nicolas Bétheuil a écrit :

Bonjour,

Comme je vous l'avais annoncé, j'ai réalisé un nouvel outil : 
OpenData2OpenStreetMap aka od2osm.


Vous pouvez aller jouer avec à l'adresse https://od2osm.cleverapps.io

Il faut être authentifié sur l'environnement de dev OSM 
https://master.apis.dev.openstreetmap.org en attendant vos 
commentaires acerbes et votre jugement implacable pour le mettre sur 
le vrai "OSM".


Vous pouvez en quelques clics ajouter de la données à OSM à partir 
d'un jeu de données de test : les commerces parisiens qui livrent 
pendant le confinement (oui c'est un peu parigo centré et peut être un 
peu dépassé, mais c'est pour jouer aussi).


Ces données sont comparées avec l'environnement de dev d'OSM qui est 
plutôt vide et incohérent avec le fond de carte, vous allez donc faire 
beaucoup de création.
Rien n’empêche de faire plusieurs fois une création par l'outil, 
charge au contributeur de vérifier si un point existe déjà, l'outil 
aide à retrouver les éventuels points dèjà existant.
J'en ai moi même déjà ajouté pour tester et que vous puissiez voir 
comment se passe une comparaison (même si du coup les tags vont être 
identique).


J'attends vos commentaires, avec une certaine impatience, ici ou en 
issue sur le repo github https://github.com/wadouk/od2osm/issues.


Je cherche déjà à valider l'usage contributeur (ajout communautaire et 
collaboratif) avant d'ajouté d'autres jeu de données.


D'avance merci pour votre aide et vos critiques aiguisées.

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

[OSM-talk-fr] Nouvel outil : od2osm

2020-05-13 Par sujet Nicolas Bétheuil 
Bonjour,

Comme je vous l'avais annoncé, j'ai réalisé un nouvel outil :
OpenData2OpenStreetMap aka od2osm.

Vous pouvez aller jouer avec à l'adresse https://od2osm.cleverapps.io

Il faut être authentifié sur l'environnement de dev OSM
https://master.apis.dev.openstreetmap.org en attendant vos commentaires
acerbes et votre jugement implacable pour le mettre sur le vrai "OSM".

Vous pouvez en quelques clics ajouter de la données à OSM à partir d'un jeu
de données de test : les commerces parisiens qui livrent pendant le
confinement (oui c'est un peu parigo centré et peut être un peu dépassé,
mais c'est pour jouer aussi).

Ces données sont comparées avec l'environnement de dev d'OSM qui est plutôt
vide et incohérent avec le fond de carte, vous allez donc faire beaucoup de
création.
Rien n’empêche de faire plusieurs fois une création par l'outil, charge au
contributeur de vérifier si un point existe déjà, l'outil aide à retrouver
les éventuels points dèjà existant.
J'en ai moi même déjà ajouté pour tester et que vous puissiez voir comment
se passe une comparaison (même si du coup les tags vont être identique).

J'attends vos commentaires, avec une certaine impatience, ici ou en issue
sur le repo github https://github.com/wadouk/od2osm/issues.

Je cherche déjà à valider l'usage contributeur (ajout communautaire et
collaboratif) avant d'ajouté d'autres jeu de données.

D'avance merci pour votre aide et vos critiques aiguisées.
___
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

2020-05-13 Par sujet Yves P. 
> amenity=recycling+recycling_type=container ne dit en aucun cas que c'est une 
> colonne
amenity=recycling + recycling_type=container + location=underground le dit ;)

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


> 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
Je cite Georges ;)

"Donc si c'est bon pour une déchetterie, pourquoi le refuser pour un point de 
collecte ?"

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

Re: [OSM-talk-fr] cadastre - commune inexistante

2020-05-13 Par sujet Frantz 
Bonjour,13 mai 2020 17:13 "Georges Dutreix via Talk-fr" 
 a écrit:> Bonjour,
> 
> Je tombe sur une commune avec aucune maison dans OSM :
> https://www.openstreetmap.org/#map=17/47.75787/5.31887
> 
> Impossible de trouver les communes de Percey-le-Pautel ou Longeau (52) sur
> http://cadastre.openstreetmap.fr/
> Et sur https://cadastre.damsy.net/#11/47.7666/5.3160, c'est "non dispo", tout 
> noir.
> 
> C'est sans espoir ?

"Longeau Percey" est dispo sur cadastre.gouv.fr... mais pas en vectoriel.

-- 
Frantz

___
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

2020-05-13 Par sujet Georges Dutreix via Talk-fr 


Le 13/05/2020 à 13:36, Vincent Bergeot a écrit :
On est donc à mi-chemin entre le container simple (amenity=recycling 
+ recycling_type=container) et la déchetterie (amenity=recycling + 
recycling_type=centre). Je vois sur Taginfo "recycling_type=station" 
(13 usages dans le monde), ça me semblerait bien décrire cette 
situation ?



couci-couça car cela parle "recycling", ce qui dans le cas des ordures 
ménagères ne fonctionnent pas !
Une déchetterie (amenity=recycling + recycling_type=centre) accepte 
aussi bien du recyclable, de l'incinérable que des gravas à enterrer. 
Donc si c'est bon pour une déchetterie, pourquoi le refuser pour un 
point de collecte ?


Le terme recycling devrait sans doute être remplacé par waste, que ce 
soit recyclable ou non, mais là, ce serait une autre histoire ;-)
___
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

2020-05-13 Par sujet François Lacombe 
Salut,

Merci pour le relais.
J'ai eu l'occasion de tremper dans cette sombre affaire.

Le convertisseur est utilisé pour alimenter OSRM, mais c'est surtout le
réciproque de osm2pgsql.
Il produit un fichier xml osm à partir d'une base postgis.

Cela ayant pour avantage de bénéficier de la force de postgis et de données
tierces pour utiliser des logiciels qui n'acceptent que du xml en entrée.
La valeur ajoutée résident dans le code SQL de création de la topologie
avec les bonnes connections plus que dans l'écriture du XML qui devrait
être revue prochainement.

A dispo pour plus d'explications

François

Le mer. 13 mai 2020 à 16:25,  a écrit :

> DCbrain rend public un convertisseur de données, sur son compte Github. Il
> s'agit d'un convertisseur de données géographiques postgresql en format
> openstreetmap
> Apparemment c est en rapport avec OSRM
>
> Source:
> https://www.programmez.com/actualites/dcbrain-rend-publique-une-partie-de-son-code-en-open-source-30553
>
> Julien
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] cadastre - commune inexistante

2020-05-13 Par sujet Georges Dutreix via Talk-fr 

Bonjour,

Je tombe sur une commune avec aucune maison dans OSM : 
https://www.openstreetmap.org/#map=17/47.75787/5.31887


Impossible de trouver les communes de Percey-le-Pautel ou Longeau (52) 
sur http://cadastre.openstreetmap.fr/
Et sur https://cadastre.damsy.net/#11/47.7666/5.3160, c'est "non dispo", 
tout noir.


C'est sans espoir ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2020-05-13 Par sujet thevenon . julien 
DCbrain rend public un convertisseur de données, sur son compte Github. Il 
s'agit d'un convertisseur de données géographiques postgresql en format 
openstreetmap
Apparemment c est en rapport avec OSRM

Source: 
https://www.programmez.com/actualites/dcbrain-rend-publique-une-partie-de-son-code-en-open-source-30553

Julien

___
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

2020-05-13 Par sujet 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 =* to specify the
   type of waste.
   - access =* to specify
   the access. Mapping of objects unverifiable by general public is
   discouraged.
   - fee =* to specify if a
   fee is payable.
   - operator =* to
   specify the operator.
   - 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  en tag secondaire
> ou 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
> .
>
> 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] Evolution des règles pour les plages et la ligne de côte

2020-05-13 Par sujet Djo_man via Talk-fr 
Bonjour, 

Oui, c'est aussi mon point de vue pour les plages, les rochers et le tidalflat. 

Sauf que je trouve le natural=wetland justifié et qu'un wetland=tidal en 
secondaire serait parfait à la place d'un wetland=tidalflat vu qu'il existe 
déjà des natural=mud pour la vase (plutot bien cartographié en france grace aux 
landcover) 

Pour les limites mer/fleuve, c'est plus compliqué effectivement et la reponse 
est peut etre à etudier mais j'ai peur que la solution ne soit que franco 
francaise vu que la limite cartographié de salinité officielle (par exemple 
mais c'est la même chose pour les autres) n'existe qu'ici. 

Djo man 

Envoyé depuis mon smartphone Xperia de Sony

 Thomas Petillon a écrit 

>Bonsoir,
>
>Super boulot Djo man ! :)
>
>Quelques remarques et ajouts :
>
>Plages
>Je pense que les polygones natural=beach devraient couvrir l'intégralité
>des places, à savoir au-dessus et en-dessous du trait de côte. Il y a des
>difficultés techniques à rendre ça correctement dans openstreetmap-carto
>, mais maintenant que
>le rendu des mers à été changé, ça ne devrait pas être insurmontable.
>
>Tidalflats
>Ce tag est effectivement utilisé à quelques endroits pour représenter
>l'intégralité de l'estran (https://osm.org/go/erkO8n5D--,
>https://osm.org/go/eq0l5im8-). Je pense que ça vient du fait qu'il apparait
>sur le rendu. Mais sémantiquement je dirais qu'il n'est à utiliser que pour
>les zones de vase ou sable. Si c'est des rochers, il n'y a pas de raison
>qu'on ne puisse pas taguer ça en rocher, juste parce que c'est recouvert
>par la marée. Avec qu'un seul tag, on perd beaucoup d'informations.
>
>Placement du trait de côte
>Pour la marée basse, Géolittoral est pratique, mais pour la marée haute
>c'est plus compliqué. Le trait de côte Histolitt monte trop haut
>(coefficient 120). Sinon, ça n'est pas extrêmement précis, car ce sont des
>images satellites et non aériennes, mais lorsque j'ai un doute j'utilise
>les images de Sentinel à partir d'ici :
>https://apps.sentinel-hub.com/eo-browser/. En remontant dans les archives,
>on tombe forcément sur des photos où il fait à la fois beau et où la marée
>est haute.
>On peut aussi regarder les photos d'archive de l'IGN (
>https://remonterletemps.ign.fr/), à condition que la zone n'ai pas changé
>depuis.
>
>Pour regarder rapidement et simplement le trait de côte version OSM,
>j'utilise http://tools.geofabrik.de/osmi/?view=coastline.
>
>Limites mer/rivières
>Il serait intéressant d'ajouter une slide ou deux au document pour parler
>des embouchures. Ici la difficulté principale est de savoir où placer la
>limite entre la rivière et la mer. Il n'y a pas de consensus clair dans
>OSM, et la raison la plus probable à ça est que c'est compliqué et un peu
>arbitraire. C'est comme si chaque acteur avait son propre critère, alors
>pas facile pour OSM d'adopter une stratégie claire. Je pense que ça devrait
>être quelque-chose comme « la limite amont à laquelle l'eau de mer est
>dominante à marée haute », ce qui reste vague. Dans la pratique j'ai
>utilisé l'orthophoto Géolittoral pour voir quelle partie de l'estuaire se
>vidait à marée basse, mais c'est plutôt « I know when I see it ». Et ça ne
>fonctionne pas pour les gros fleuves. (Comme la Loire, qui mériterait
>d'être améliorée.)
>
>D'autant plus qu'entre une petite rivière bretonne de fond de ria et un
>énorme fleuve Sud-Américain, ça n'a rien à voir ! (Quelques explications
>ici :
>http://modb.oce.ulg.ac.be/mediawiki/upload/Aida/OCEA0011/3_ESTUARiES.pdf)
>
>Quelques sources :
>
>   - Histolitt, mais il remonte trop haut :
>   https://www.geoportail.gouv.fr/donnees/trait-de-cote-histolitt
>   - Géolittoral, pour voir quelle partie de l'estuaire se vide à marée
>   basse.
>   - Limite de salure des eaux, du SHOM :
>   
> https://data.shom.fr/donnees#001=eyJjIjpbLTQxMzMxMC4yNDYxNjA1MDQ3Niw2MDQxMzI3Ljk1NTcwMzI2Nl0sInoiOjgsInIiOjAsImwiOlt7InR5cGUiOiJJTlRFUk5BTF9MQVlFUiIsImlkZW50aWZpZXIiOiJMSU1JVEVTX1NBTFVSRV9FQVVYX1dNVFMiLCJvcGFjaXR5IjoxLCJ2aXNpYmlsaXR5Ijp0cnVlfSx7InR5cGUiOiJJTlRFUk5BTF9MQVlFUiIsImlkZW50aWZpZXIiOiJGRENfR0VCQ09fUFlSLVBOR18zODU3X1dNVFMiLCJvcGFjaXR5IjowLjUsInZpc2liaWxpdHkiOnRydWV9XX0=
>   - Liste des commune littorales :
>   https://fr.wikipedia.org/wiki/Liste_des_communes_littorales_de_France
>
>(Merci à Jean-Yvon pour les deux dernières ! :) )
>
>La question de jusqu'où faire aller le way de la rivière se pose aussi.
>
>Et le cas des barrages comme celui de la Rance est encore différent. Je
>trouverais logique que le trait de côte s'arrête au barrage. Mais dans ce
>cas, on met quoi derrière ? (natural=water, water=reservoir, salt=yes ?)
>
>J'essayerai de faire une image pour résumer ça.
>
>Limites administratives
>Comme indiqué dans le document, les limites administratives et le trait de
>côte mènent des vies séparées. Ils sont confondus jusqu'à présent
>principalement par simplicité. La distinction a été faite en
>Grande-Bretagne par exemple

Re: [OSM-talk-fr] Evolution des règles pour les plages et la ligne de côte

2020-05-13 Par sujet Djo_man via Talk-fr 
Bonjour, 

En fait non, j'habite pas le coin, même si je l'apprécie vraiment. Là où c'est 
pas un hazard c'est que je l'ai choisi car je n'y avais pas touché... 

Là ou je sevis c'est le 44. Et je sais que certains pourraient avoir à redire 
sur mon utilisation extensive du tidalflat à la place du tidal=yes. 

J'entends déjà les clairons du " tag pour le rendu" . Mais j' ai une defense:
- c'est pas un tag pour un autre, à mon avis, car tidal=yes n'est pas un tag 
pleinement opérationnel du fait qu'il intervient en ajout secondaire sur un 
autre tag et reclame de diviser des surfaces existantes de rocher/mud/beach 
selon une ligne imaginaire qui, en plus, n'est pas en reflet d'une réalité sur 
le terrain: la coastline. Mais je peux comprendre qu'un tag principal n'est pas 
forcément le top car la mer recouvre plusieurs types d'espaces naturels. 
- mais là où on peut dire qu'il sagit d'un tag naturel quand même c'est que 
l'écosystème mer (avec poissons, etc) vient recouvrir l'écosystème rochers. 
Donc natural=wetland est assez judicieux et permet d'ajuster avec des tag 
secondaires en surcouche. 
-  quand on sait que le modele de tag est conçu en réponse à un probleme de 
rendu du bleu de la mer, il devient logique d'utiliser le seul rendu comme 
méthode de visibilité de l'avancement du travail. 
- la cartographie complete de l'estran du 44 est fait de wetland= tidalflat si 
un jour il faut migrer ça sera facile. 
- et pour finir. Le modèle de tag et le rendu sont à la traine mais on avance 
quand même. 

J'irais jusqu'à dire qu'il y a eu regression dans le rendu des côtes. Regardez 
le rendu de geofabric standard qui est en ce moment l'image du rendu osm.org de 
l'année dernière comparé à celle d'aujourd'hui :  
http://tools.geofabrik.de/mc/#15/47.4402/-2.4886=4=mapnik=geofabrik=mapnik-german=here-map

Bon, certains diront que j'ai triché car j'ai utilisé la transparence nomal du 
tidalflat pour recouvrir les rochers/sand qui normalement n'auraient pas dû 
etre visible (je peux expliquer) mais avouez que c'est une carte tres correcte, 
juste et exploitable. 

Djo man 


Envoyé depuis mon smartphone Xperia de Sony

 Jean-Yvon Landrac a écrit 

>Bonjour voisin (je suppose que le lieu pris n'est pas par hasard),
>
>j'ai à redire (à la marge, c'est déjà très bien).
>Je te passerai en MP, ce soir sans doute, tu en feras ce que tu veux
>(une v2 ?).
>
>J'ai dit à Yves d'attendre si ce n'est pas trop tard. Et ce n'était pas
>trop tard.
>
>De plus j'ai signalé le fil de discussion à Thomas Pétillon qui doit
>être dans la région de Quimper/Bénodet et qui a lui aussi remonté du
>trait de côte. Il a trouvé la discussion intéressante et devrait y
>participer.
>
>Tiens :
>
>https://www.ouest-france.fr/bretagne/lorient-56100/quelques-jours-encore-avant-de-se-mettre-la-plage-de-guidel-larmor-plage-6832671
>
>/Dans le cadre de la loi d’État d’urgence sanitaire, le gouvernement
>doit promulguer le décret qui prévoit l’interdiction d’accès aux plages.
>Charge ensuite au préfet d’accorder des dérogations aux communes./
>
>Donc en absence de décret, c'est autorisé !
>
>Jean-Yvon, Guidelois comme tu t'en doutes
>
>Le 11/05/2020 à 22:15, Djo_man via Talk-fr - talk-fr@openstreetmap.org a
>écrit :
>>
>> Bonsoir,
>>
>> Bien sur, il faut diffuser si personne n'y voit à redire.
>>
>> Djo man
>>
>>
>>
>>
>>  Yves P. a écrit 
>>
>>
>>> J'ai eu un peu de temps ce week-end pour préciser à la fois l'état du
>>> tagging
>>> pour les côtes et décrire les problématiques que cela soulève en
>>> terme de rendu de carte.
>>> Il s'agit d'un PDF avec des photos aériennes commentées de JOSM et
>>> modifiées sur photoshop.
>>>
>>> http://pc.cd/ssGrtalK
>>
>> Un grand merci pour ce travail de "dingue" :)
>>
>> Il m'a permis (entre-autres) de comprendre la différence entre BDOrtho
>> IGN et Géolittoral.
>>>
>>> ça ne résoudra pas la question du manque de vote pour cette dernière
>>> modif de wiki
>>> mais permettra de comprendre ce qui est en jeu pour OSM voire pour
>>> OPENSEAMAP.
>>>
>> Je peux transmettre le lien à Malcolm Herring (OpenSeaMap) ?
>> Il ne parle pas le français, mais devrait suivre les illustrations :)
>>>
>>> Le Mont Saint-Michel nous remerciera peut être...
>>>
>> Le rendu standard montre l'estran :) mais comme une zone marcageuse :/
>> Pas le carte basque : c'est marrée haute ;D
>>
>> Encore merci, Djo man :)
>>
>> __
>> 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] Point d'apport volontaire, point de collecte, point de regroupement

2020-05-13 Par sujet Yves P. 

> on en avait parlé il y a peu, bin=yes me semble plus cohérent.
bin=yes  en tag secondaire ou 
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 
.

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

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

2020-05-13 Par sujet Marc M. 
Le 13.05.20 à 14:27, Vincent Bergeot a écrit :
> recycling:waste=yes -> General waste container (black bags) (don't use
> this if the waste is not recycled

est-ce que cela existe encore ?
cela fait longtemps que je n'ai pas vu un poubelle "déchets recycblabe
non trié"
soit c'est non trié->incinérateur ou décharge
soit c'est trié -> recyclé (ouais enfin, sous-cyclé mais c'est
un autre débat)

on en avait parlé il y a peu, bin=yes me semble plus cohérent.

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

Re: [OSM-talk-fr] Evolution des règles pour les plages et la ligne de côte

2020-05-13 Par sujet Denis Bigorgne 
nouvelles et pleines lunes = vives eaux = deux marées par mois.
Le coef  70 n'est qu'une approximation du marnage en marée moyenne, pour
les marées de vives eaux moyenne on utilisera le coef 95
.
Pour en savoir plus, avec sureté : Transparents Journées Refmar Shom 2013

Pour les vives eaux : transparent 4
Pour les coefficients : transparent 36, 37, 38

Et je ne peux que recommander la consultation de ce document très bien fait
pour tous ceux qui veulent comprendre le phénomène des marées.

On pourrait théoriquement calculer ces hauteurs moyennes en utilisant les
calculateurs de marées et pas mal d'approximations de localisation. On ne
serait pas bien avancé car ces hauteurs se réfèrent à un zéro des cartes
marines qui n'est pas relié aux altitudes géodésiques...

La proposition de se baser sur les laisses de haute mer, pour une marée de
95 (vives eaux moyenne), un jour sans vent, avec une pression atmosphérique
de 1013 hPa me semble la plus sûre. En ce qui concerne les plages, on ne se
cassera pas plus la tête. Tous ceux qui fréquentent les plages océaniques
savent que les plages s'engraissent ou se dégraissent suivant les
conditions météorologiques, en clair que la position de la coastline change
chaque année !!!

Et à mon humble avis, (hors sujet) OSM se porterait mieux avec une
coastline définie comme le trait de côte français, la limite entre le
bistre et le vert des cartes du SHOM.

Le mar. 12 mai 2020 à 15:09, GarenKreiz  a écrit :

> Si on lit attentivement les définitions de MHWS, il faut calculer la
> moyenne des marées successives de plus haute amplitude au moment des
> nouvelles et pleines lunes soit 4 marées en gérnéral par mois et non pas
> pour toutes les marées de vives eaux (coefficent supérieur à 70). Etant
> donné les variations introduites par la pression atmosphérique et l'effet
> du vent, je ne suis pas sûr que cela fasse beaucoup de différence entre les
> deux moyennes et on peut sans doute utiliser la définition la plus simple!
>
>
>
> On Tue, 12 May 2020 at 12:41, Denis Bigorgne 
> wrote:
>
>> Bonjour,
>>
>> Juste un point de détail à corriger dans la page 8 :
>>
>> "La ligne de côte pour OSM doit etre placée sur le «mean high water
>> springs», «pleine Mer Moyenne de vives-eaux» : hauteur moyenne des*
>> hautes mer de marée de printemps*."
>> devrai être remplacée par
>> "La ligne de côte pour OSM doit etre placée sur le «mean high water
>> springs», «pleine Mer Moyenne de vives-eaux» :  hauteur moyenne des *hautes
>> mer de vives eaux*"
>>
>> ("spring tides" en anglais ne désigne pas les marées de printemps - voir
>> ""
>> https://tidesandcurrents.noaa.gov/glossary.html#springtidesortidalcurrents;
>> : Tides of increased range [...] occurring semimonthly as the result of the
>> Moon being new or full. )
>>
>>
>> Le lun. 11 mai 2020 à 22:15, Djo_man via Talk-fr <
>> talk-fr@openstreetmap.org> a écrit :
>>
>>> Bonsoir,
>>>
>>> Bien sur, il faut diffuser si personne n'y voit à redire.
>>>
>>> Djo man
>>>
>>>
>>>
>>>  Yves P. a écrit 
>>>
>>>
>>> J'ai eu un peu de temps ce week-end pour préciser à la fois l'état du
>>> tagging
>>> pour les côtes et décrire les problématiques que cela soulève en terme
>>> de rendu de carte.
>>> Il s'agit d'un PDF avec des photos aériennes commentées de JOSM et
>>> modifiées sur photoshop.
>>>
>>> http://pc.cd/ssGrtalK
>>>
>>>
>>> Un grand merci pour ce travail de "dingue" :)
>>>
>>> Il m'a permis (entre-autres) de comprendre la différence entre BDOrtho
>>> IGN et Géolittoral.
>>>
>>> ça ne résoudra pas la question du manque de vote pour cette dernière
>>> modif de wiki
>>> mais permettra de comprendre ce qui est en jeu pour OSM voire pour
>>> OPENSEAMAP.
>>>
>>> Je peux transmettre le lien à Malcolm Herring (OpenSeaMap) ?
>>> Il ne parle pas le français, mais devrait suivre les illustrations :)
>>>
>>> Le Mont Saint-Michel nous remerciera peut être...
>>>
>>> Le rendu standard montre l'estran :) mais comme une zone marcageuse :/
>>> Pas le carte basque : c'est marrée haute ;D
>>>
>>> Encore merci, Djo man :)
>>>
>>> __
>>> 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
>>
> ___
> 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] Point d'apport volontaire, point de collecte, point de regroupement

2020-05-13 Par sujet Yves P. 
> oui mais 
> 
> recycling:waste=yes -> General waste container (black bags) (don't use this 
> if the waste is not recycled, use a tag like amenity=waste_disposal or 
> amenity=waste_basket instead) 
> 
ça c'est la théorie du wiki ;)
c'est probablement vrai dans d'autres pays.

Ici (dans le Jura) les conteneurs sont les "mêmes" (jaunes, bleus, noirs) pour 
des déchets recyclables ou pas. Sont-ils réellement recyclés, c'est une vaste 
question :D

Pour le verre et parfois les papiers, il y a des conteneurs différents (verts 
ou bleus).
J'oubliais, il y a aussi les bac à déchets verts/compostes et les bacs à 
vêtements.

En résumé, des conteneurs pour "déchets" : un seul et même tag principal :)
Sinon, on ne va pas s'en sortir.
> ce qui se traduit sur le wiki fr par "Autres déchets (non recyclables)"
> 
> ce qui me semble pas vraiment cohérent :)
> 
C'est effectivement incohérent du point de vue du recyclage, mais très cohérent 
du point de vue du conteneur :)
Et oui,  l'être humain est plein de contradictions :D

__
Yves

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

Re: [OSM-talk-fr] Evolution des règles pour les plages et la ligne de côte

2020-05-13 Par sujet Djo_man via Talk-fr 
Bonjour, 

Oui, c'est exact. Je modifie pour la v2.

 J'ai voulu faire du littéral simpliste (à l'anglaise) aidant à la 
comprehension mais ce n'est pas precis. La majorité des marées en question 
(servant au calcul de cette moyenne) sont bien de printemps en general. 
D'ailleurs cette année c'était une 119 dans le week-end du 8 mai mais personne 
n'a eu le droit de la voir

Djo man 

Envoyé depuis mon smartphone Xperia de Sony

 Denis Bigorgne a écrit 

>Bonjour,
>
>Juste un point de détail à corriger dans la page 8 :
>
>"La ligne de côte pour OSM doit etre placée sur le «mean high water
>springs», «pleine Mer Moyenne de vives-eaux» : hauteur moyenne des* hautes
>mer de marée de printemps*."
>devrai être remplacée par
>"La ligne de côte pour OSM doit etre placée sur le «mean high water
>springs», «pleine Mer Moyenne de vives-eaux» :  hauteur moyenne des *hautes
>mer de vives eaux*"
>
>("spring tides" en anglais ne désigne pas les marées de printemps - voir ""
>https://tidesandcurrents.noaa.gov/glossary.html#springtidesortidalcurrents;
>: Tides of increased range [...] occurring semimonthly as the result of the
>Moon being new or full. )
>
>
>Le lun. 11 mai 2020 à 22:15, Djo_man via Talk-fr 
>a écrit :
>
>> Bonsoir,
>>
>> Bien sur, il faut diffuser si personne n'y voit à redire.
>>
>> Djo man
>>
>>
>>
>>  Yves P. a écrit 
>>
>>
>> J'ai eu un peu de temps ce week-end pour préciser à la fois l'état du
>> tagging
>> pour les côtes et décrire les problématiques que cela soulève en terme de
>> rendu de carte.
>> Il s'agit d'un PDF avec des photos aériennes commentées de JOSM et
>> modifiées sur photoshop.
>>
>> http://pc.cd/ssGrtalK
>>
>>
>> Un grand merci pour ce travail de "dingue" :)
>>
>> Il m'a permis (entre-autres) de comprendre la différence entre BDOrtho IGN
>> et Géolittoral.
>>
>> ça ne résoudra pas la question du manque de vote pour cette dernière modif
>> de wiki
>> mais permettra de comprendre ce qui est en jeu pour OSM voire pour
>> OPENSEAMAP.
>>
>> Je peux transmettre le lien à Malcolm Herring (OpenSeaMap) ?
>> Il ne parle pas le français, mais devrait suivre les illustrations :)
>>
>> Le Mont Saint-Michel nous remerciera peut être...
>>
>> Le rendu standard montre l'estran :) mais comme une zone marcageuse :/
>> Pas le carte basque : c'est marrée haute ;D
>>
>> Encore merci, Djo man :)
>>
>> __
>> 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] Point d'apport volontaire, point de collecte, point de regroupement

2020-05-13 Par sujet Vincent Bergeot 

Le 13/05/2020 à 14:02, Yves P. a écrit :
On est donc à mi-chemin entre le container simple (amenity=recycling 
+ recycling_type=container) 
couci-couça car cela parle "recycling", ce qui dans le cas des 
ordures ménagères ne fonctionnent pas !
J'utilise ces tags. Pour les ordures ménagères le preset JOSM propose 
l'option "détritus" : recycling:waste=yes ;)



oui mais

recycling:waste=yes -> General waste container (black bags) (don't use 
this if the waste is not recycled, use a tag like amenity=waste_disposal 
or amenity=waste_basket instead)


ce qui se traduit sur le wiki fr par "Autres déchets (non recyclables)"

ce qui me semble pas vraiment cohérent :)







__
Yves

PS: les couleurs doivent être normalisées en France. Est-ce que vous 
les saisissez ?





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



--
Vincent Bergeot

___
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

2020-05-13 Par sujet Yves P. 
>> On est donc à mi-chemin entre le container simple (amenity=recycling + 
>> recycling_type=container) 
> couci-couça car cela parle "recycling", ce qui dans le cas des ordures 
> ménagères ne fonctionnent pas !
J'utilise ces tags. Pour les ordures ménagères le preset JOSM propose l'option 
"détritus" : recycling:waste=yes ;)

__
Yves

PS: les couleurs doivent être normalisées en France. Est-ce que vous les 
saisissez ?



___
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

2020-05-13 Par sujet Vincent Bergeot 

Le 13/05/2020 à 10:01, PanierAvide a écrit :

Bonjour Vincent,

Les zones dont tu parles ont bien cette allure là ?

https://www.vitry-aux-loges.fr/images/gmapfp/755__sam_0923.jpg

https://coat-meal.fr/images/albums/pose-containers-enterres/NYL_8613.JPG

On est donc à mi-chemin entre le container simple (amenity=recycling + 
recycling_type=container) et la déchetterie (amenity=recycling + 
recycling_type=centre). Je vois sur Taginfo "recycling_type=station" 
(13 usages dans le monde), ça me semblerait bien décrire cette 
situation ?



couci-couça car cela parle "recycling", ce qui dans le cas des ordures 
ménagères ne fonctionnent pas !


disons que "recycling_type=station" va regrouper tous les conteneurs de 
tri, mais pas les ordures ménagères (sans doute le conteneur rond sur 
ton premier exemple : amenity=waste_disposal)


(PS  : Merci je ne connaissais pas ce recycling_type=station, qui peut 
avoir son usage aussi)





Cordialement,

Adrien P.

Le 13/05/2020 à 09:14, Vincent Bergeot a écrit :

Bonjour,

depuis plusieurs années, en ville et en campagne fleurissent de plus 
en plus de "zone de collecte", "point d'apport volontaire", "point de 
regroupement", qui regroupent souvent des containers de recyclages et 
des conteneurs pour les ordures ménagères.


Selon mon expérience et mes échanges avec des syndicats de gestion 
des déchets, ces zones sont beaucoup plus stables dans le temps que 
les types de "matériaux" que l'on peut y apporter (même si cela 
semble peu à peu se stabiliser).


Aujourd'hui on peut détailler chaque conteneur, poubelle, ... que 
cela soit amenity=waste_disposal pour les déchets type ordure 
ménagères, amenity=recycling pour ce qui va être trié.


Mais je n'ai pas trouvé comment cartographier ces zones "génériques" 
qui, de plus en plus fréquemment, ont un nom affiché et une référence 
géographiquement stable dans le temps.


Avez vous quelques pistes, idées !

Bonne journée



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



--
Vincent Bergeot


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

Re: [OSM-talk-fr] attributions

2020-05-13 Par sujet blef 

Bonjour,

La rédaction de Sud-Ouest a semble t il une meilleure image d'OSM:
/"les cartographies participatives Open Street Map, plus vertueuses que 
celles de leur concurrent, Google"/

https://www.sudouest.fr/2020/05/12/dax-prof-et-eleves-creent-une-application-pour-mesurer-les-100-kilometres-de-perimetre-7478984-3350.php/
/




Le 03/05/2020 à 00:44, Donat ROBAUX a écrit :

Tu ne crois pas si bien dire Jean-Yvon!

Dans un article de l'Est Républicain
https://www.estrepublicain.fr/societe/2020/05/01/une-appli-pour-manifester-depuis-son-canape




"Nous sommes là..." le site Manif.app vous permet de participer à une
manifestation virtuelle en plaçant votre avatar et votre slogan sur une
carte Google. Créé en avril dernier, il suscite la créativité des
internautes. Un vent de fraîcheur et d'humour en cette période de
confinement.

Voilà ma réponse sur Twitter:
/@lestrepublicain
A propos de cet article
https://estrepublicain.fr/societe/2020/05/01/une-appli-pour-manifester-depuis-son-canape
Il ne s'agit pas d'une carte Google, mais #OpenStreetMap comme l'indiquent
les mentions en bas.

Quand commence la désintoxication aux cartes Google de votre rédaction?/



--
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



___
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

2020-05-13 Par sujet PanierAvide 

Bonjour Vincent,

Les zones dont tu parles ont bien cette allure là ?

https://www.vitry-aux-loges.fr/images/gmapfp/755__sam_0923.jpg

https://coat-meal.fr/images/albums/pose-containers-enterres/NYL_8613.JPG

On est donc à mi-chemin entre le container simple (amenity=recycling + 
recycling_type=container) et la déchetterie (amenity=recycling + 
recycling_type=centre). Je vois sur Taginfo "recycling_type=station" (13 
usages dans le monde), ça me semblerait bien décrire cette situation ?


Cordialement,

Adrien P.

Le 13/05/2020 à 09:14, Vincent Bergeot a écrit :

Bonjour,

depuis plusieurs années, en ville et en campagne fleurissent de plus 
en plus de "zone de collecte", "point d'apport volontaire", "point de 
regroupement", qui regroupent souvent des containers de recyclages et 
des conteneurs pour les ordures ménagères.


Selon mon expérience et mes échanges avec des syndicats de gestion des 
déchets, ces zones sont beaucoup plus stables dans le temps que les 
types de "matériaux" que l'on peut y apporter (même si cela semble peu 
à peu se stabiliser).


Aujourd'hui on peut détailler chaque conteneur, poubelle, ... que cela 
soit amenity=waste_disposal pour les déchets type ordure ménagères, 
amenity=recycling pour ce qui va être trié.


Mais je n'ai pas trouvé comment cartographier ces zones "génériques" 
qui, de plus en plus fréquemment, ont un nom affiché et une référence 
géographiquement stable dans le temps.


Avez vous quelques pistes, idées !

Bonne journée



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

Re: [OSM-talk-fr] Robert Keller, Laurent Matheron et Pierre Guillou : Hitler sur table d'écoute

2020-05-13 Par sujet Yves P. 
Bonjour,

> Il y a aussi un central téléphonique qui porte le nom de Robert Keller, 
> correspondant au bureau de poste dans le 15eme arrondissement Parisien
> https://www.openstreetmap.org/node/2062421762#map=19/48.84801/2.28139 
> 
> (Il manque ref ptt dessus 75115RKE)
J'avais vu le noeud dans JOSM en mettant la plaque commémorative 
 au n°6 de la "Rue de 
l'Ingénieur Robert Keller" :)

> Est ce qu'on sait où se trouve la plaque commémorative à Lyon Sevigné?
Il doit y en avoir 2 :
une  commémorant le renommage du 
centre. Elle est dans le passage pour rejoindre la cour intérieure.
l'autre  dans la cour, près de 
l'entrée du bâtiment C (positionnée au pif).

> J'y ai passé 3 mois il y a quelques années, peut etre l'ai je en photo
Je suis preneur, Wikimedia Commons aussi :)

Merci d'avance aux éventuels photographes.
__
Yves

PS: En cherchant des infos sur le centre PTT Lyon Sévigné, j'ai trouvé 
l'article sur Le Réseau Téléphonique de Sécurité 
 qui mentionne l'incendie du 
centre le 9 novembre 1981.
Le RTS est (était) un réseau téléphonique propre à EDF pour la supervision du 
réseau électrique français. Basé dés les années 50 sur des courants porteurs en 
lignes et/ou radio et maintenant sur des fibres optiques.
On y trouve pleins d'illustrations et photos des matériels…
Un article "amusant" sur Les difficultés pour téléphoner dans les années 1960 
 (liens vers le sketch de 
Fernand Reynaud "Le 22 à Asnières" et celui d'Yves Montand sur le "Télégramme").

> Lyon
> plaque commémorative est apposée une plaque dans l'enceinte du centre 
> Lyon-Sévigné de Orange, situé dans le 3e arrondissement de Lyon
> Centre d'amplification des LSGD de Lyon-Tassin a été nommé Centre 
> Laurent-Matheron
Pour info, LSGD est le sigle de Lignes souterraines à grande distance 
.

Le site de la FNARH (Fédération Nationale des Associations de personnel de la 
Poste et d'Orange pour la Recherche Historique) regorge d'articles sur 
l'histoire des télécoms .___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2020-05-13 Par sujet Vincent Bergeot 

Bonjour,

depuis plusieurs années, en ville et en campagne fleurissent de plus en 
plus de "zone de collecte", "point d'apport volontaire", "point de 
regroupement", qui regroupent souvent des containers de recyclages et 
des conteneurs pour les ordures ménagères.


Selon mon expérience et mes échanges avec des syndicats de gestion des 
déchets, ces zones sont beaucoup plus stables dans le temps que les 
types de "matériaux" que l'on peut y apporter (même si cela semble peu à 
peu se stabiliser).


Aujourd'hui on peut détailler chaque conteneur, poubelle, ... que cela 
soit amenity=waste_disposal pour les déchets type ordure ménagères, 
amenity=recycling pour ce qui va être trié.


Mais je n'ai pas trouvé comment cartographier ces zones "génériques" 
qui, de plus en plus fréquemment, ont un nom affiché et une référence 
géographiquement stable dans le temps.


Avez vous quelques pistes, idées !

Bonne journée

--
Vincent Bergeot


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