Re: [OSM-talk-be] Patlatch (was Weggetje verdwenen, hoe terug ?)

[Marc Gemis]

Karel,

Ik dacht dat de ontwikkelaar van Potlatch bezig was met een
stand-alone versie. dwz dat je het niet meer in de browser kan
gebruiken, maar dat je nog wel met je vertrouwde editor verder kan.

mvg

m.

On Wed, May 13, 2020 at 10:57 AM Karel Adams  wrote:
>
> :) ikke, want Potlatch is het enige dat ik ken en voor mijn beperkte gebruik 
> voldoet dat prima; veel beter dan ID in alle geval.
>
> Maar het ziet ernaar uit dat Flash ten dode is opgeschreven dus ik zal wel 
> moeten overstappen :(
>
> KA
>
> On 2020-05-13 08:22, wannes wrote:
>
> Jaahaa, dat is met Flash, wie heeft dat nu nog ? :-)
>
> On Tue, May 12, 2020 at 3:03 PM Jo  wrote:
>>
>> Er is nog een 'truuk' om verwijderde ways terug te halen. (werkt enkel voor 
>> ways).
>>
>> Start editeersessie met Potlatch2.
>>
>> Je wilt eigenlijk de vorige versie van Potlatch gebruiken, haal daarom de 2 
>> weg uit de url in de adresbalk...
>>
>> De originele versie van Potlatch maakt gebruik van een niet gedocumenteerde 
>> 'feature' in de API.
>>
>> Er is een knop om deleted ways te zien.
>>
>> Jo
>>
>> On Tue, May 12, 2020 at 1:07 PM Tim Couwelier  
>> wrote:
>>>
>>> Bijlage bleeft hangen wegens groter dan 80kb, maar hierbij even ter 
>>> illustratie hoe je ze kan traceren met de 'skyview' laag.  Is een soort 
>>> hoogtemodelweergave op grondniveau, de bomen zie je dus niet.. en het pad 
>>> wordt zichtbaar.
>>>
>>> https://framapic.org/r01ExtbzPorU/Z1Zri8oU24QM.jpg
>>>
>>> (ik had al even afzonderlijk gemaild naar de betrokken persoon, maar 
>>> mogelijks zijn er nog mensen waarvoor dit een meerwaarde kan betekenen.)
>>>
>>>
>>> Op di 12 mei 2020 om 10:57 schreef Wannes Soenen :

 Ok, dan lijkt me het het “handigste” dat ik een GPX neem en het pad terug 
 teken (want het zit onder de bomen)
 Die relaties, en GR enz toevoegen/verleggen, zal ik eerst eens moeten 
 bestuderen, want dat heb ik nog nooit gedaan.

 Op 12 mei 2020, om 10:53 heeft Sander Deryckere  het 
 volgende geschreven:

 Hallo,

 Het hangt er van af hoe lang de wijziging geleden is.
 Als het vrij recent is (enkele dagen), kan je de geschiedenis van een 
 gebied opvragen (de geschiedenis knop op de hoofdpagina).
 Maar deze wijziging lijkt langer geleden te zijn, dus valt dit moeilijk te 
 bespeuren.

 Wat je wel kan is bekijken welke objecten waarschijnlijk ook gewijzigd 
 zijn bij die aanpassing (zoals het fietspad dat nu gebruikt wordt).

 

 Als je dat fietspad selecteert, en de geschiedenis opvraagt, dan kom je 
 hier terecht: https://www.openstreetmap.org/way/24520913/history

 Er is dus in de laatste maanden tamelijk wat aangepast aan het pad.  In 
 het bijzonder zie ik een wijziging van 4 maand geleden met het commentaar 
 "cycleroute 03-04 update: broken (again), now due to missing segments". 
 Wat er op wijst dat iemand er voor die regio heeft aangepast, zonder 
 rekening te houden met de relaties.

 Het is dus waarschijnlijk niet 1 iemand die de relatie verlegd heeft, maar 
 iemand heeft dat pad verwijderd, en iemand anders heeft de relatie opnieuw 
 verbonden met de bestaande paden...

 Mvg,
 Sander

 Op di 12 mei 2020 om 10:18 schreef Wannes Soenen :
>
> Hoi,
>
> Ik zie dat er zeer lokaal, een wegje verdwenen is op de kaart.
> Ik kan dat er zelf terug op gaan zetten, maar dan is de kans groot dat 
> diegene die de edit gedaan heeft het weer wist.
>
> Hoe kan ik 1) zien wie de edit deed, of er een comment bij was? 2) 
> rollback doen
>
> Het betreft een pad net ten zuiden van het Ringfietspad op 
> https://www.openstreetmap.org/edit#map=18/51.20462/4.44275
> De plaatselijke merkkringen van het GR-pad (en van op de GR site) loopt 
> wel degelijk over dat pad, niet over het fietspad.
> Dus, de huidige gemaakte situatie is fout, want 1) pad is niet meer 
> gemapt 2) GR loopt over het fietspad.
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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


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

Re: [Talk-us] admin_level and COGs, MPOs, SPDs, Home Rule

[Martin Machyna]

I just edited a OSMwiki page and apparently that hurt him so much that
immediately started heated discussion claiming his rules to be OSM
community rules. And as an act of retaliation he went on and changed my
data and data of other users to his liking. I don't know how to correctly
name this.
I just wanted to bring up that this is not OK. This is a toxic behavior.


> Mateusz Konieczny matkoniecz at tutanota.com
>  Tue May 12 21:06:40 UTC 2020
>  Note that vandalism in OSM and similar project is considered as something
> that is not only damaging but also malicious and intended to be damaging.
> In cases where you consider other mapper as mistaken and wrong, but not
> malicious - consider using other terms.  See
> https://wiki.openstreetmap.org/wiki/Vandalism  (it is not unique to OSM,
> see for example  https://en.wikipedia.org/wiki/Wikipedia:Vandalism )
> May 12, 2020, 05:28 by machyna at gmail.com:  > I am just going to paste
> here what I wrote on Slack and I as well consider removal of counties from
> admin_level=6 as vandalism. >
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk] Proposed mechanical edit - remove tracking parameters

[Martin Koppenhoefer]

sent from a phone

> On 13. May 2020, at 13:44, Mateusz Konieczny via talk 
>  wrote:
> 
> It means that it is beneficial to turn tag
> website=http://paris.intersquat.org/les-lieux/le-satellite/?fbclid=de58e340d6aa79a584552a2055042d004b9b19454bc0d7a6046fc81fc90f51
> into
> website=http://paris.intersquat.org/les-lieux/le-satellite/
> 
> This urls can be often fixed using an automated script, allowing to
> use human time on something more productive.


I agree with removing tracking information. In the example above it seems that 
“url” would be a better key than “website”.

Cheers Martin ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-it] Village / Town

[Martin Koppenhoefer]

sent from a phone

> On 13. May 2020, at 12:42, Fra00  wrote:
> 
> Per quanto riguarda invece i centri del Molise, di cui non si è parlato nella
> discussione, San Martino in Pensilis e Campomarino perché sono stati taggati
> come "town"? Mi sembra che tra Larino, Termoli e Guglionesi che sono molto
> vicini non ci sia una loro prevalenza o importanza geografica nella zona.


Premetto che non conosco Guglionesi, e di Larino e Termoli ho solo sentito 
parlare, ma leggendo su wikipedia e guardando la mappa, per Guglionesi mi 
sembra village ci starebbe bene. Termoli mi sembra la più importante di tutti e 
tre luoghi, ma Larino potrebbe essere comunque cittadina. 

Ciao Martin 
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[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

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

[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: [Talk-GB] Rights of way mapping - making it easy for newcomers to OSM (perhaps!)

[Rob Nickerson]

Hi Nick,

I like your idea. Breaking the tasks down in to chunks makes sense. One
group of beginners contribute data (a gps trace all coordinated via a
simple app) whilst another group make the edits in OSM.

P.S. On mapthepaths.org.uk (the website) can you make it such that when I
click a local authority line it highlights the full line. I would like to
see the start and end point of the line so that I can properly add the
reference to OSM. Currently I have to click along the path several times to
see where the reference changes.

Thank you,
*Rob*
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

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

[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

[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

[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

[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

Re: [Talk-GB] Rights of way mapping - making it easy for newcomers to OSM (perhaps!)

[Nick Whitelegg]

Oops... sorry one or two editing errors in the last paragraph.

I meant to say:

"They [the non-expert user] select ROW type and path surface via a nice 
interface, and then a tagged GPX trace is generated, *with trksegs tagged with 
ROW designation and surface* (which was done by the first version of the app 
anyway). This is then uploaded to the MapThePaths server, and volunteer expert 
users *are alerted*. Said expert user then downloads the GPX trace and, *using 
the tags in the trksegs of the GPX* then edits in JOSM, perhaps via a JOSM 
plugin - or even directly in the MapThePaths web app. (I am possibly thinking 
of adding way creation into the MapThePaths web app anyway, time depending)."

Nick


From: Nick Whitelegg
Sent: 13 May 2020 18:08
To: talk-gb@openstreetmap.org 
Subject: Rights of way mapping - making it easy for newcomers to OSM (perhaps!)

Hi,

Just to continue with the theme of rights of way mapping, I've been noticing 
that there are still large tracts of England and Wales away from the 'honeypot' 
areas with little or now ROW mapping at all meaning there's still quite a big 
job to be done.

As you may remember I have been developing a companion app to MapThePaths. In 
the first version of this (around two years ago) I experimented with 
auto-converting GPX traces to OSM ways. However I was dissatisfied with the 
results, the ways generated were really rather nasty and I ended up having to 
prettify them significantly in JOSM afterwards, rendering the auto-creation 
facility a little pointless. Consequently later versions of the app have 
focused on merely presenting the council and OSM data overlaid (like the 
website),  with only limited editing facilities, to change the designation of a 
path.

However (and I may have mentioned this before, it's been a while) I am 
wondering about a 'two-user' approach in which a new user merely does the GPX 
survey, using an easy to use UI (a refined version of the MapThePaths app with 
the UI re-designed by someone more versed in UX than myself).

They select ROW type and path surface via a nice interface, and then a tagged 
GPX trace is generated (which was done by the first version of the app anyway). 
This is then uploaded to the MapThePaths server, and volunteer expert users. 
Said expert user then downloads the GPX trace and then edits in JOSM, perhaps 
via a JOSM plugin - or even directly in the MapThePaths web app. (I am possibly 
thinking of adding way creation into the MapThePaths web app anyway, time 
depending).

Any thoughts?

Thanks,
Nick

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

[Talk-GB] Rights of way mapping - making it easy for newcomers to OSM (perhaps!)

[Nick Whitelegg]

Hi,

Just to continue with the theme of rights of way mapping, I've been noticing 
that there are still large tracts of England and Wales away from the 'honeypot' 
areas with little or now ROW mapping at all meaning there's still quite a big 
job to be done.

As you may remember I have been developing a companion app to MapThePaths. In 
the first version of this (around two years ago) I experimented with 
auto-converting GPX traces to OSM ways. However I was dissatisfied with the 
results, the ways generated were really rather nasty and I ended up having to 
prettify them significantly in JOSM afterwards, rendering the auto-creation 
facility a little pointless. Consequently later versions of the app have 
focused on merely presenting the council and OSM data overlaid (like the 
website),  with only limited editing facilities, to change the designation of a 
path.

However (and I may have mentioned this before, it's been a while) I am 
wondering about a 'two-user' approach in which a new user merely does the GPX 
survey, using an easy to use UI (a refined version of the MapThePaths app with 
the UI re-designed by someone more versed in UX than myself).

They select ROW type and path surface via a nice interface, and then a tagged 
GPX trace is generated (which was done by the first version of the app anyway). 
This is then uploaded to the MapThePaths server, and volunteer expert users. 
Said expert user then downloads the GPX trace and then edits in JOSM, perhaps 
via a JOSM plugin - or even directly in the MapThePaths web app. (I am possibly 
thinking of adding way creation into the MapThePaths web app anyway, time 
depending).

Any thoughts?

Thanks,
Nick

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

[OSM-talk-fr] Nouvel outil : od2osm

[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: [Talk-GB] Lancashire prow_ref format (Was: Public Rights of Way - legal vs reality)

[Adam Snape]

Hi,

I'm so glad the information is being used and progress is being made.
However, I do have to agree with Rob about the Council's online map.

Re:OS copyright they are really highly protective about what they perceive
to be derived data. I think it would be difficult to add rights of way
whilst consulting the Council's OS-based map, yet completely avoid using
any geographic information in it at any point to clarify, adjust or update
the routes or surrounding features.

But, in any case, we definitely do not have the Council's permission to use
the data in the online map, which does differ slightly from the dataset
they supplied in response to my foi/ rpsi request in 2018. It may seem
trivial but we need explicit permission when using data for OSM, so I
really do suggest we avoid this source.

Please keep up the good work though,

Adam
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

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

[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] Proposed mechanical edit - remove tracking parameters

[Mateusz Konieczny via talk]

May 13, 2020, 17:31 by doerr.step...@gmail.com:

> On 13/05/2020 12:40, Mateusz Konieczny via talk wrote:
>
>> Proposed bot edit would remove links where all used parameters are tracking
>> users and may be removed.
>>
>
> Sounds good. Will you limit individual changesets to fairly small 
> geographical units?
>
Yes. 

Splitting changeset into reasonable areas will be
done by my osm_bot_abstraction_layer.generic_bot_retagging
library (run_simple_retagging_task function),
that is why it is not appearing anywhere in my code.

Code of changeset splitting is at
https://github.com/matkoniecz/osm_bot_abstraction_layer/blob/master/osm_bot_abstraction_layer/split_into_packages.py
and will be done with limits of
max elements in a changeset: 500
max changeset size in degrees (latitude): 0.3
max changeset size in degrees (longitude): 0.3

See https://www.openstreetmap.org/user/Mateusz Konieczny - bot account/history
for how it works in practice (note that many recent edits had low number of 
elements, you may
need to go back in history)
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[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

[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] Proposed mechanical edit - remove tracking parameters

[Steve Doerr]

On 13/05/2020 12:40, Mateusz Konieczny via talk wrote:

Proposed bot edit would remove links where all used parameters are 
tracking

users and may be removed.


Sounds good. Will you limit individual changesets to fairly small 
geographical units?


--
Steve

--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

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

[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

Re: [Talk-africa] [Trufi Association] Translation of bus route mapping documentation

[Enock Seth Nyamador]

Thanks Sören for sharing here, and JML for the comments, this post was
initially shared on t.me/osmafrica where we have somehow diverse language
representation and I recommended for it be posted here too, Looping in
Talk-ML, CI and TG as well.

Cordialement,

Am Mi., 13. Mai 2020 um 15:02 Uhr schrieb Jean-Marc Liotier :

> On 5/12/20 10:40 PM, Sören Reinecke via Talk-africa wrote:
> > I am Sören Reinecke from Trufi Association. We help communities in
> developing countries to organize their public transport (pt) e.g. we work
> with the community from Accra, Ghana. Aside from providing the pt
> navigation app and the infrastructure behind it (e.g. OTP server etc.) we
> also show mappers how to add bus routes to OpenStreetMap (
> https://mapping-bus-routes.readthedocs.io/en/master/ ).
> >
> > My question is: Does your community need a translation into French? If
> yes, I would set up the translation infrastructure and invite the onces
> wanting to do the translation work.
>
> Hello Sören. talk-africa@openstreetmap.org is English language only but,
> in French-speaking West Africa, the Openstreetmap contributors use
> French almost exclusively in their Openstreetmap practice. French
> translation proves valuable in including them.
>
> cc: Nathalie Sidibe, from Openstreetmap Mali, who is fluent in English
> but very aware of how much French translations are required in her local
> community - she can give you the local perspective.
>
>
>
> ___
> Talk-africa mailing list
> Talk-africa@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-africa
>


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

[OSM-talk-fr] cadastre - commune inexistante

[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

Re: [OSM-talk] Quality and the Openstreetmap value chain

[Jean-Marc Liotier]

On 5/12/20 3:50 PM, Colin Smale wrote:
The role I expect of the data consumers is to articulate how they 
would like to view the data (including what attributes they are 
expecting), and not to dictate how that data is stored/represented 
internally. Cartography, geography, statistics etc are very different 
skills to data modelling and database design.


Indeed, technical implementations take functional requirements into 
account but have many other inputs and a different class of actors. 
Consumers, tell us what you want - not how to do it ! Same as any 
software project...



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

Re: [Talk-africa] [Trufi Association] Translation of bus route mapping documentation

[Jean-Marc Liotier]

On 5/12/20 10:40 PM, Sören Reinecke via Talk-africa wrote:

I am Sören Reinecke from Trufi Association. We help communities in developing 
countries to organize their public transport (pt) e.g. we work with the 
community from Accra, Ghana. Aside from providing the pt navigation app and the 
infrastructure behind it (e.g. OTP server etc.) we also show mappers how to add 
bus routes to OpenStreetMap ( 
https://mapping-bus-routes.readthedocs.io/en/master/ ).

My question is: Does your community need a translation into French? If yes, I 
would set up the translation infrastructure and invite the onces wanting to do 
the translation work.


Hello Sören. talk-africa@openstreetmap.org is English language only but, 
in French-speaking West Africa, the Openstreetmap contributors use 
French almost exclusively in their Openstreetmap practice. French 
translation proves valuable in including them.


cc: Nathalie Sidibe, from Openstreetmap Mali, who is fluent in English 
but very aware of how much French translations are required in her local 
community - she can give you the local perspective.




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

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

[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

[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-ie] Estimate of number of building=* in Ireland

[Donie Kelly]

Don’t buildings have tags? Did I see a residential tag? Is it used in all cases?

> On 13 May 2020, at 13:24, Colm Moore  wrote:
> 
> Hi,
> 
> Inspired by seeing the estimate in the Microgrant application of 5.5 million 
> buildings on the island of Ireland, I did some number crunching.
> 
> I downloaded the populations of Kilkenny townlands (1,500+) from the CSO and 
> analysed the population against the number of buildings per civil parish 
> (100+) for County Kilkenny. This is assuming Kilkenny has all or nearly all 
> buildings mapped. Based on my inspections, this is largely true.
> 
> The CSO data is somewhat distorted for the Kilkenny city area (100+ 
> townlands), due to the way the CSO have arranged the townlands and civil 
> parishes. I could look at this in more detail, but there would be a few hours 
> of effort (unless someone has a simple way of calculating number of buildings 
> per area, for a large number of areas).
> 
> I calculated the 'number of buildings per civil parish' using the Overpass 
> Turbo query [building=* in "civilparishname, Kilkenny"]. Overpass Turbo gives 
> a summary of the data in the bottom right corner of the screen, e.g. 
> 
> Loaded – nodes: 4261, ways: 867, relations: 2
> Displayed – pois: 0, lines: 0, polygons: 866
> 
> I took the number of polygons to mean the number of buildings (this might not 
> be perfect - I don't know how those numbers add up). Additionally, some 
> polygons, e.g. building=terrace represent several buildings, while in other 
> cases buildings may have been crudely split or joined-up.
> 
> Depending on the civil parish, we're looking at 0.32-2.29 polygons per capita 
> (0.44-3.15 people per building). Rural areas ten to have more polygons per 
> capita, especially due to farm outbuildings, while urban areas have fewer 
> polygons per capita, due to apartments buildings and semi-detached buildings 
> (e.g. two square houses joined together might have only six nodes).
> 
> I also calculated 4.40-5.83 nodes per polygon. This means some civil parishes 
> have predominantly rectangular polygons / buildings, whereas others have many 
> L-shaped or other-shaped polygons / buildings.
> 
> As I wasn't able to immediately get some 'number of buildings per civil 
> parish' numbers (Overpass Turbo had problems returning them, possibly due to 
> duplicate names and variations in name spellings), I had to calculate them 
> from their component townlands, using the Overpass Turbo query [building=* in 
> "townlandname, civilparishname, Kilkenny"].
> 
> Depending on the townland, we're looking at 0.23-8.00 polygons per capita 
> (0.13-4.37 people per building) and 3.91-6.45 nodes per polygon (i.e. some 
> townlands have large numbers of semi-detached or terraced buildings, whereas 
> others have a high number of complicated-shape polygons / buildings or 
> buildings with too many mapped nodes). It is usual to see more extreme 
> spreads when looking at smaller areas.
> 
> I'm coming up with about 5.4 million (close enough!) buildings for the whole 
> island, assuming the pattern is the same everywhere. However, as shown by 
> analysing the smaller areas, there is variation and the 'final' number will 
> vary from that. Of course, given that OSM is an ongoing project, there will 
> never be a final number.
> 
> Colm
> VictorIE
> ___
> Talk-ie mailing list
> Talk-ie@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ie

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

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

[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

[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] Let's talk Attribution

[Frederik Ramm]

Hi,

On 13.05.20 14:33, Simon Poole wrote:
> as obvious from this thread, it
> does confuse people as to what the actual facts are.

I know it is tedious, but this thread could certainly benefit from
someone providing a recap of the facts, i.e. the core points of the
proposed attribution guideline.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Let's talk Attribution

[Mateusz Konieczny via talk]

Hidden button is explicitly allowed on mobile devices by the draft:

"In addition, mobile devices may have attribution after one interaction. 
Examples of one interaction include “one click,” such as an icon or 
link that opens a pop-up or new webpage, or a swipe, drag, pinch, etc."

from 
https://wiki.openstreetmap.org/wiki/Draft_Attribution_Guideline#Mobile_devices

That would misleadingly claim that hidden button (used by Mapbox and
FB and others on mobile devices) is acceptable and fulfills ODBL requirements.

See 
https://raw.githubusercontent.com/matkoniecz/illegal-use-of-OpenStreetMap/master/Mapbox/Mapbox_attributes_itself_2019-12-30.png
for an example in map with hidden button that would fulfill
"mobile devices may have attribution after one interaction".

This specific screenshot from mobile device (low budget smartphone)
also demonstrates that there for full-screen maps there is enough space
for a real attribution.

Though something smaller than logo and "Mapbox" repeated three times
would be also enough.

To repeat: normal user will NOT click on weir "i" button. This is effectively
not displaying attribution.



More info about that specific case at
https://github.com/matkoniecz/illegal-use-of-OpenStreetMap/blob/master/Mapbox/Mapbox.md#mapbox-is-using-openstreetmap-data-illegally
(yes Mapbox was notified, yes Mapbox ignored it).

May 13, 2020, 14:33 by si...@poole.ch:

>
> Am 13.05.2020 um 13:46 schrieb Mateusz Konieczny via talk:
> ...
>
>> And, no, a typical user will not click on a hidden button or check
>> deeply in settings.
>>
> ...
>
> Nobody ever even remotely indicated that attribution via a "hidden
> button" or deep in any settings was sufficient, in fact the draft
> guideline contained the opposite. Now I do realize the value of
> exaggeration as a rhetoric device, but, as obvious from this thread, it
> does confuse people as to what the actual facts are.
>
> Simon
>

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

Re: [OSM-talk] Proposed mechanical edit - remove tracking parameters

[Mateusz Konieczny via talk]

I expanded 
https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny_-_bot_account/remove_tracking_parameters#How

Thanks for a feedback!

Let me know if it is clear or whatever it should be improved.

May 13, 2020, 14:09 by marc_marc_...@hotmail.com:

> Hello,
>
> I agree the idea and thank you for doing the operation,
> can you highlight on the wiki the key and the logic ? it seem to be
> key : website url source (but not 
> contact:website heritage:website brand:website 
> source:website operator:website was:website ?)
> target : "fbclid", "gclid", "campaign_ref", "mc_id", "utm_source",
> "utm_medium", "utm_term", "utm_content", "utm_campaign"
>
> someone who doesn't read the code, must still be able
> to easily understand the criteria of the operation.
>
> Regards,
> Marc
>
> Le 13.05.20 à 13:40, Mateusz Konieczny via talk a écrit :
>
>> URL often have unnecessary parts, typically added for tracking purposes.
>> This tracking parameters sshould never appear in any osm tags.
>>
>> FB, Google and other add tracking links for various purposes.
>>
>> It means that it is beneficial to turn tag
>> website=http://paris.intersquat.org/les-lieux/le-satellite/?fbclid=de58e340d6aa79a584552a2055042d004b9b19454bc0d7a6046fc81fc90f51
>> into
>> website=http://paris.intersquat.org/les-lieux/le-satellite/
>>
>> This urls can be often fixed using an automated script, allowing to
>> use human time on something more productive.
>>
>> Human-made edit will also result in changing "last edited by"
>> (while not allowing to filter out such edits unlike marked bot edit),
>> there are better ways to spot areas requiring fixes and we are not lacking
>> places with QA indicators that manual review is needed.
>>
>> Usually tracking links are added by clueless people who just searched for
>> a website and copied it from FB/Google.
>>
>> There are rare cases of links created to specifically track OSM users
>> see for example
>> * https://www.openstreetmap.org/way/754704241/history
>> ** https://www.cronauerlaw.com/?utm_source=openstreetmap
>> * https://www.openstreetmap.org/node/1063808111/history
>> **
>> http://www.travelerscoffee.ru?utm_campaign=geo_source=openstreetmap_medium=link
>> * https://www.openstreetmap.org/node/6817678019/history
>> **
>> https://www.resotainer.fr/agence-bonneuil-sur-marne?utm_source=open-street-map_medium=recherche-locale_content=openstreetmap_campaign=open-street-map-garde-meubles-bonneuil-sur-marne
>> * https://www.openstreetmap.org/node/1684317522
>> **
>> http://www.travelerscoffee.ru?utm_campaign=geo_source=openstreetmap_medium=link
>>
>> In general I have not noticed correlation between presence of tracking links
>> and additional issues that would not be detected automatically.
>>
>> Therefore automatic removal of tracking parameters is not causing loss of
>> useful indicators of areas that should be reviewed.
>> Osmose and JOSM validators and StreetComplete are offering better
>> indicators.
>>
>> Automatic removal would allow me to spend time on something more useful,
>> than reviewing all cases where this links are present and confirming
>> them one by one.
>>
>> Proposed bot edit would remove links where all used parameters are tracking
>> users and may be removed. Other links will be reviewed manually to catch
>> also currently unknown tracking parameters.
>>
>> Anchors (#section) will be preserved.
>>
>> Parameters for removal across OSM: fbclid, gclid, campaign_ref, mc_id,
>> utm_source, utm_medium, utm_term, utm_content, utm_campaign
>>
>> Code is tested, I am currently using it in a manual review mode.
>> Sole difference in but run will be disabling of manual confirmation.
>>
>> I have experience with automated edits, see
>> https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny_-_bot_account
>>
>> Yes, editing element will cause it to be edited and change "last edited"
>> date.
>> Effect will be exactly the same in case of using bot and manual edit
>> (which I will do anyway in case of rejecting this automated edit proposal).
>> Note that in case of bot edits you may filter out bot edits marked as
>> automatic.
>>
>> Documentation page:
>> https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny_-_bot_account/remove_tracking_parameters
>>
>> Edits that would be made by bot, based on currently present tracking
>> parameters:
>> https://gist.github.com/matkoniecz/6710d066fea6596533f5013040eb5dc1
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>

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

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

[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

[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

[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

[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] Let's talk Attribution

[Simon Poole]

Am 13.05.2020 um 13:46 schrieb Mateusz Konieczny via talk:
...
> And, no, a typical user will not click on a hidden button or check
> deeply in settings.
>
...

Nobody ever even remotely indicated that attribution via a "hidden
button" or deep in any settings was sufficient, in fact the draft
guideline contained the opposite. Now I do realize the value of
exaggeration as a rhetoric device, but, as obvious from this thread, it
does confuse people as to what the actual facts are.

Simon




signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[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

[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

[OSM-talk-ie] Estimate of number of building=* in Ireland

[Colm Moore]

Hi,

Inspired by seeing the estimate in the Microgrant application of 5.5 million 
buildings on the island of Ireland, I did some number crunching.

I downloaded the populations of Kilkenny townlands (1,500+) from the CSO and 
analysed the population against the number of buildings per civil parish (100+) 
for County Kilkenny. This is assuming Kilkenny has all or nearly all buildings 
mapped. Based on my inspections, this is largely true.

The CSO data is somewhat distorted for the Kilkenny city area (100+ townlands), 
due to the way the CSO have arranged the townlands and civil parishes. I could 
look at this in more detail, but there would be a few hours of effort (unless 
someone has a simple way of calculating number of buildings per area, for a 
large number of areas).

I calculated the 'number of buildings per civil parish' using the Overpass 
Turbo query [building=* in "civilparishname, Kilkenny"]. Overpass Turbo gives a 
summary of the data in the bottom right corner of the screen, e.g. 

Loaded – nodes: 4261, ways: 867, relations: 2
Displayed – pois: 0, lines: 0, polygons: 866

I took the number of polygons to mean the number of buildings (this might not 
be perfect - I don't know how those numbers add up). Additionally, some 
polygons, e.g. building=terrace represent several buildings, while in other 
cases buildings may have been crudely split or joined-up.

Depending on the civil parish, we're looking at 0.32-2.29 polygons per capita 
(0.44-3.15 people per building). Rural areas ten to have more polygons per 
capita, especially due to farm outbuildings, while urban areas have fewer 
polygons per capita, due to apartments buildings and semi-detached buildings 
(e.g. two square houses joined together might have only six nodes).

I also calculated 4.40-5.83 nodes per polygon. This means some civil parishes 
have predominantly rectangular polygons / buildings, whereas others have many 
L-shaped or other-shaped polygons / buildings.

As I wasn't able to immediately get some 'number of buildings per civil parish' 
numbers (Overpass Turbo had problems returning them, possibly due to duplicate 
names and variations in name spellings), I had to calculate them from their 
component townlands, using the Overpass Turbo query [building=* in 
"townlandname, civilparishname, Kilkenny"].

Depending on the townland, we're looking at 0.23-8.00 polygons per capita 
(0.13-4.37 people per building) and 3.91-6.45 nodes per polygon (i.e. some 
townlands have large numbers of semi-detached or terraced buildings, whereas 
others have a high number of complicated-shape polygons / buildings or 
buildings with too many mapped nodes). It is usual to see more extreme spreads 
when looking at smaller areas.

I'm coming up with about 5.4 million (close enough!) buildings for the whole 
island, assuming the pattern is the same everywhere. However, as shown by 
analysing the smaller areas, there is variation and the 'final' number will 
vary from that. Of course, given that OSM is an ongoing project, there will 
never be a final number.

Colm
VictorIE
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

Re: [OSM-talk] Proposed mechanical edit - remove tracking parameters

[Marc M.]

Hello,

I agree the idea and thank you for doing the operation,
can you highlight on the wiki the key and the logic ? it seem to be
key : website url source (but not   
contact:website heritage:website brand:website  
source:website operator:website was:website ?)
target : "fbclid", "gclid", "campaign_ref", "mc_id", "utm_source",
"utm_medium", "utm_term", "utm_content", "utm_campaign"

someone who doesn't read the code, must still be able
to easily understand the criteria of the operation.

Regards,
Marc

Le 13.05.20 à 13:40, Mateusz Konieczny via talk a écrit :
> URL often have unnecessary parts, typically added for tracking purposes.
> This tracking parameters sshould never appear in any osm tags.
> 
> FB, Google and other add tracking links for various purposes.
> 
> It means that it is beneficial to turn tag
> website=http://paris.intersquat.org/les-lieux/le-satellite/?fbclid=de58e340d6aa79a584552a2055042d004b9b19454bc0d7a6046fc81fc90f51
> into
> website=http://paris.intersquat.org/les-lieux/le-satellite/
> 
> This urls can be often fixed using an automated script, allowing to
> use human time on something more productive.
> 
> Human-made edit will also result in changing "last edited by"
> (while not allowing to filter out such edits unlike marked bot edit),
> there are better ways to spot areas requiring fixes and we are not lacking
> places with QA indicators that manual review is needed.
> 
> Usually tracking links are added by clueless people who just searched for
> a website and copied it from FB/Google.
> 
> There are rare cases of links created to specifically track OSM users
> see for example
> * https://www.openstreetmap.org/way/754704241/history
> ** https://www.cronauerlaw.com/?utm_source=openstreetmap
> * https://www.openstreetmap.org/node/1063808111/history
> **
> http://www.travelerscoffee.ru?utm_campaign=geo_source=openstreetmap_medium=link
> * https://www.openstreetmap.org/node/6817678019/history
> **
> https://www.resotainer.fr/agence-bonneuil-sur-marne?utm_source=open-street-map_medium=recherche-locale_content=openstreetmap_campaign=open-street-map-garde-meubles-bonneuil-sur-marne
> * https://www.openstreetmap.org/node/1684317522
> **
> http://www.travelerscoffee.ru?utm_campaign=geo_source=openstreetmap_medium=link
> 
> In general I have not noticed correlation between presence of tracking links
> and additional issues that would not be detected automatically.
> 
> Therefore automatic removal of tracking parameters is not causing loss of
> useful indicators of areas that should be reviewed.
> Osmose and JOSM validators and StreetComplete are offering better
> indicators.
> 
> Automatic removal would allow me to spend time on something more useful,
> than reviewing all cases where this links are present and confirming
> them one by one.
> 
> Proposed bot edit would remove links where all used parameters are tracking
> users and may be removed. Other links will be reviewed manually to catch
> also currently unknown tracking parameters.
> 
> Anchors (#section) will be preserved.
> 
> Parameters for removal across OSM: fbclid, gclid, campaign_ref, mc_id,
> utm_source, utm_medium, utm_term, utm_content, utm_campaign
> 
> Code is tested, I am currently using it in a manual review mode.
> Sole difference in but run will be disabling of manual confirmation.
> 
> I have experience with automated edits, see
> https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny_-_bot_account
> 
> Yes, editing element will cause it to be edited and change "last edited"
> date.
> Effect will be exactly the same in case of using bot and manual edit
> (which I will do anyway in case of rejecting this automated edit proposal).
> Note that in case of bot edits you may filter out bot edits marked as
> automatic.
> 
> Documentation page:
> https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny_-_bot_account/remove_tracking_parameters
> 
> Edits that would be made by bot, based on currently present tracking
> parameters:
> https://gist.github.com/matkoniecz/6710d066fea6596533f5013040eb5dc1
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
> 


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

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

[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] Let's talk Attribution

[Mateusz Konieczny via talk]

May 13, 2020, 12:39 by si...@poole.ch:

>
>
>
> Am 12.05.2020 um 23:03 schrieb Mateusz  Konieczny via talk:
>
>>
>>
>>
>> May 12, 2020, 05:48 by >> rockyt...@gmail.com>> :
>>


>>> As Joseph said:
>>>
 The attribution goes on the map.
 This is not a difficult requirement to meet.

>>>
>>>
 The most recent version of the guidelines
 drafted by the LWG is almost there, but has drawncommunity 
 criticism
 about being too generous especially w.r.t. initiallyhidden 
 attribution.

>>>
>>> Is there anywhere I can share my two cents about the  guidelines?
>>>
>> I commented on
>> https://wiki.openstreetmap.org/wiki/Talk:Draft_Attribution_Guideline
>> but I am unsure is it a good place because I got no reply.
>>
>
> Expecting a reply is unreasonable, taking the comments in to  account not 
> (which we did).
>
>
Allowing to hide attribution on mobile remained present in this proposal and 
AFAIK
it was one of primary reasons why Draft Attribution Guideline is staying as a 
draft for now
rather than being adopted.

(though I was participating in just some meetings on Mumble).

And it deserves an explanation why not showing attribution
is considered as ODBL compatible that requires to ensure that user is aware of 
data source
and license.

And, no, a typical user will not click on a hidden button or check deeply in 
settings.


>> One may also join online meeting of a Legal Working Group
>> and talk there.
>>
>> https://wiki.osmfoundation.org/wiki/Licensing_Working_Group
>> "The group now meets every 2nd Thursday of the month, at20:00 UTC, 
>> on >> Mumble >> , unless 
>> rescheduled."
>>
>
> As you know the LWG has handed the subject back to the board  months ago, 
> not to mention that we provided ample time and venues  to provide input 
> on the matter and that is long closed. Just  because somebody wasn't 
> paying attention doesn't mean that you  restart a process when they turn 
> up and feel they have a right to  their opinion being heard*.
>
>
> Simon
>
>
> * that was one of the main reasons the OSM licence change was  such a 
> traumatic experience. 
>
>
Well, in that case comments may be useful for next improved version or for a 
board.

There may be a better place to post them, but I am not aware about anything 
better.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Proposed mechanical edit - remove tracking parameters

[Mateusz Konieczny via talk]

URL often have unnecessary parts, typically added for tracking purposes.
This tracking parameters sshould never appear in any osm tags.

FB, Google and other add tracking links for various purposes.

It means that it is beneficial to turn tag
website=http://paris.intersquat.org/les-lieux/le-satellite/?fbclid=de58e340d6aa79a584552a2055042d004b9b19454bc0d7a6046fc81fc90f51
into
website=http://paris.intersquat.org/les-lieux/le-satellite/

This urls can be often fixed using an automated script, allowing to
use human time on something more productive.

Human-made edit will also result in changing "last edited by"
(while not allowing to filter out such edits unlike marked bot edit),
there are better ways to spot areas requiring fixes and we are not lacking
places with QA indicators that manual review is needed.

Usually tracking links are added by clueless people who just searched for
a website and copied it from FB/Google.

There are rare cases of links created to specifically track OSM users
see for example
* https://www.openstreetmap.org/way/754704241/history
** https://www.cronauerlaw.com/?utm_source=openstreetmap
* https://www.openstreetmap.org/node/1063808111/history
** 
http://www.travelerscoffee.ru?utm_campaign=geo_source=openstreetmap_medium=link
* https://www.openstreetmap.org/node/6817678019/history
** 
https://www.resotainer.fr/agence-bonneuil-sur-marne?utm_source=open-street-map_medium=recherche-locale_content=openstreetmap_campaign=open-street-map-garde-meubles-bonneuil-sur-marne
* https://www.openstreetmap.org/node/1684317522
** 
http://www.travelerscoffee.ru?utm_campaign=geo_source=openstreetmap_medium=link

In general I have not noticed correlation between presence of tracking links
and additional issues that would not be detected automatically.

Therefore automatic removal of tracking parameters is not causing loss of
useful indicators of areas that should be reviewed.
Osmose and JOSM validators and StreetComplete are offering better indicators.

Automatic removal would allow me to spend time on something more useful,
than reviewing all cases where this links are present and confirming them one 
by one.

Proposed bot edit would remove links where all used parameters are tracking
users and may be removed. Other links will be reviewed manually to catch
also currently unknown tracking parameters.

Anchors (#section) will be preserved.

Parameters for removal across OSM: fbclid, gclid, campaign_ref, mc_id,
utm_source, utm_medium, utm_term, utm_content, utm_campaign

Code is tested, I am currently using it in a manual review mode.
Sole difference in but run will be disabling of manual confirmation.

I have experience with automated edits, see
https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny_-_bot_account

Yes, editing element will cause it to be edited and change "last edited" date.
Effect will be exactly the same in case of using bot and manual edit
(which I will do anyway in case of rejecting this automated edit proposal).
Note that in case of bot edits you may filter out bot edits marked as automatic.

Documentation page: 
https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny_-_bot_account/remove_tracking_parameters

Edits that would be made by bot, based on currently present tracking parameters:
https://gist.github.com/matkoniecz/6710d066fea6596533f5013040eb5dc1
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-GB] Tagging showgrounds

[Jez Nicholson]

By all means create a UK-specific page to document discussions, show
differences to the rest of the world, and/or state how we do things round
these parts. The naming convention is "[Primary subject] in the United
Kingdom", as in "Showgrounds in the United Kingdom".

On Wed, May 13, 2020 at 12:30 PM Paul Berry  wrote:

> Not sure about the tagging/proposal politics but since there are a small
> number of showgrounds, is there anything to stop a UK-specific page being
> set up on the Wiki for visibility? Then if anyone wants to harmonise the
> tags they can use that as a guide to do so.
>
> There's nothing to say we can't tag in any way we want—and again for this
> small collection of entities which are clearly all the same fundamental
> object—it's only if we want people to be consistent, or to adopt our tags,
> that we would need to go through the process of proposed tag adoption.
>
> Regards,
> *Paul*
>
> On Wed, 13 May 2020 at 10:10, nathan case  wrote:
>
>> Hi all,
>>
>> Just to drag this back up - I encountered an unmapped showground
>> (Chipping, Lancashire) whilst adding PROWs and don't know the best way to
>> tag. It appears to hold a several large shows each year (well presumably
>> not this year!) but doesn't appear to be a recreational site.
>>
>> I found this abandoned proposal for amenity=show_grounds:
>> https://wiki.openstreetmap.org/wiki/Proposed_features/show_grounds It's
>> a shame it never got traction as it might enable us to come to some
>> consensus on these sites. Can an abandoned proposal be re-opened or does it
>> have to be re-proposed?
>>
>> Cheers.
>>
>>
>>
>> -Original Message-
>> From: Andy Townsend 
>> Sent: 25 February 2020 00:23
>> To: talk-gb@openstreetmap.org
>> Subject: Re: [Talk-GB] Tagging showgrounds
>>
>> Since I was going through these anyway to see what ought to be rendered
>> at map.atownsend.org.uk, I thought I might as well list them here too.
>> These are things "tagged a bit like showgrounds, excluding bus stops and
>> car parks", sorted by one of the main tags.
>>
>> I suspect that the ones tagged just "place", "landuse=grass" or
>> "tourism=attraction" only probably need some other tag to say "this is a
>> showground".   "events_venue" might be a misunderstanding of what that tag
>> was for.  "recreation_ground" may be correct in some cases but I suspect
>> isn't in many others. "park" I'd be similarly surprised if it was often
>> correct.  In most or all cases it probably needs a local to make the call,
>> though...
>>
>> place:
>>
>>
>> https://www.openstreetmap.org/node/2382298440
>> name Mannsfield Showground
>> place locality
>> source OS OpenData StreetView
>>
>> https://www.openstreetmap.org/node/3416147963
>> name Great Harwood Showground
>> place neighbourhood
>>
>> https://www.openstreetmap.org/node/4347790541
>> addr:postcode BS37 8QZ
>> addr:street Westerleigh Road
>> name The Windmill Fisheries Showground place locality
>>
>>
>> events_venue only:
>>
>> https://www.openstreetmap.org/node/5849512782
>> alt_name Royal Cornwall Event Centre amenity events_venue name
>> Royal Cornwall Showground
>>
>> https://www.openstreetmap.org/node/6938439833
>> amenity events_venue
>> name Hertfordshire County Showground operator Hertfordshire
>> Country Council
>>
>>
>> tourism=attraction only:
>>
>> https://www.openstreetmap.org/way/283445694
>> name Devon County Showground
>> tourism attraction
>>
>> https://www.openstreetmap.org/way/91401877
>> name Kent Showground
>> source Bing
>> tourism attraction
>>
>> https://www.openstreetmap.org/way/40942963
>> barrier fence
>> name Norfolk Showground
>> tourism attraction
>>
>> https://www.openstreetmap.org/node/316706558
>> name Great Yorkshire Showground
>> tourism attraction
>>
>> https://www.openstreetmap.org/way/104155888
>> barrier fence
>> name Royal Bath and West of England Showground tourism attraction
>>
>> https://www.openstreetmap.org/way/239487854
>> name Hennock Showground
>> tourism attraction
>>
>> https://www.openstreetmap.org/way/178396540
>> addr:city Newark
>> addr:postcode NG24 2NY
>> addr:street Lincoln Road
>> alt_name Newark Show Ground
>> name Newark Showground
>> operator Newark & Nottinghamshire Agricultural Society phone +44
>> 1636 705796 tourism attraction website
>> http://www.newarkshowground.com/ wikidata Q15262122
>>
>> https://www.openstreetmap.org/way/274093728
>> name Lincolnshire Showground
>> tourism attraction
>>
>>
>> recreation_ground only:
>>
>> https://www.openstreetmap.org/way/603746353
>> alt_name Briscwm Fields
>> description Normally farmland,  Used to hold events such as the
>> Cardigan County Agricultural Show.
>> landuse recreation_ground
>> name Cardigan County Showground
>> note Located from information on Coflein.
>> phone +44 1545 570501
>> recreation_ground 

Re: [Talk-br] Digest Talk-br, volume 140, assunto 11

[Lívia Degrossi]

Olá, Raphael.

Em nome do projeto, eu agradeço a sua colaboração e dos demais membros da
comunidade. Caso precise de alguma coisa, você entrar em contato comigo.

At.te,
Lívia
-
*Dr. Lívia Castro Degrossi*
Postdoctoral researcher | National Centre for Disaster Monitoring and
Early-Warning (Cemaden)




On Tue, May 12, 2020 at 10:30 PM Ao Vivo  wrote:

> Boa Noite Livia e todos envolvidos no Projeto de Mapeamento de Rio Branco
> e São Paulo.
>
> Obrigado por convidar outros usuários do OpenstreetMap, gostaria de
> participar desse multirão ajudando no mapeamento e validação também, no dia
> do multirão estarei na tarefa mapeando e Ajudando esse Projeto.
>
> boa noite a todos.
>
> Raphael de Assis.
> Membro da Fundação do OpenstreetMap. (FOSM).
> Membro do Coletivo União dos Mapeadores Brasileiros do Openstreetmap.
> UMBRAOSM.
> Recife/PE.
>
>
> 
>  Livre
> de vírus. www.avast.com
> .
> <#m_-9028933538134083337_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> Em ter., 12 de mai. de 2020 às 15:28, 
> escreveu:
>
>> Enviar submissões para a lista de discussão Talk-br para
>> talk-br@openstreetmap.org
>>
>> Para se cadastrar ou descadastrar via WWW, visite o endereço
>> https://lists.openstreetmap.org/listinfo/talk-br
>> ou, via email, envie uma mensagem com a palavra 'help' no assunto ou
>> corpo da mensagem para
>> talk-br-requ...@openstreetmap.org
>>
>> Você poderá entrar em contato com a pessoa que gerencia a lista pelo
>> endereço
>> talk-br-ow...@openstreetmap.org
>>
>> Quando responder, por favor edite sua linha Assunto assim ela será
>> mais específica que "Re: Contents of Talk-br digest..."
>>
>>
>> Tópicos de Hoje:
>>
>>1. Re: Mapatona "Mapeando Rio Branco com o OpenStreetMap"
>>   (Lívia Degrossi)
>>
>>
>> --
>>
>> Message: 1
>> Date: Tue, 12 May 2020 15:28:27 -0300
>> From: Lívia Degrossi 
>> To: Sérgio V. 
>> Cc: OpenStreetMap no Brasil 
>> Subject: Re: [Talk-br] Mapatona "Mapeando Rio Branco com o
>> OpenStreetMap"
>> Message-ID:
>> > nlfoqudhd-84...@mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Olá, Sérgio.
>>
>> Muito obrigada pela dica. Iremos anexar o tutorial à Wiki.
>>
>> At.te,
>> Lívia
>> -
>> *Dr. Lívia Castro Degrossi*
>> Postdoctoral researcher | National Centre for Disaster Monitoring and
>> Early-Warning (Cemaden)
>>
>>
>>
>>
>> On Tue, May 12, 2020 at 10:37 AM Sérgio V.  wrote:
>>
>> > Bom dia Lívia, achei que ficou muito bacana o tutorial e bem completo.
>> > Se vocês desejarem podem também fazer upload do PDF à wiki e colar na
>> > página do projeto.
>> > Boa mapatona!
>> >
>> >
>> > - - - - - - - - - - - - - - - -
>> >
>> > Sérgio - http://www.openstreetmap.org/user/smaprs
>> >
>> > --
>> > *De:* Lívia Degrossi 
>> > *Enviado:* segunda-feira, 11 de maio de 2020 09:24
>> > *Para:* Sérgio V. 
>> > *Cc:* OpenStreetMap no Brasil 
>> > *Assunto:* Re: [Talk-br] Mapatona "Mapeando Rio Branco com o
>> > OpenStreetMap"
>> >
>> > Esqueci de anexar o tutorial.
>> >
>> > -
>> > *Dr. Lívia Castro Degrossi*
>> > Postdoctoral researcher | National Centre for Disaster Monitoring and
>> > Early-Warning (Cemaden)
>> >
>> >
>> >
>> >
>> > On Mon, May 11, 2020 at 9:23 AM Lívia Degrossi > >
>> > wrote:
>> >
>> > Olá, pessoal.
>> >
>> > Eu faço parte de um projeto internacional chamado Dados à Prova D'água e
>> > amanhã (terça-feira, dia 12/05) realizaremos uma capacitação sobre
>> > mapeamento usando OpenStreetMap, como parte da chamada "Mapeando Rio
>> Branco
>> > com o OpenStreetMap"  (
>> > https://twitter.com/waterproof_data/status/1255963265244553216).  Para
>> a
>> > capacitação, os organizadores do evento elaboraram um tutorial sobre o
>> > OpenStreetMap, o qual eu compartilho em anexo.
>> >
>> > Nas três terças-feiras subsequentes, isto é, dias 19/05, 26/05 e 02/06,
>> > nós realizaremos mutirões de mapeamento da cidade de Rio Branco. Como
>> > integrante da organização, eu gostaria de convidar a comunidade OSM
>> Brasil
>> > a nos ajudar na validação do mapeamento realizado. Infelizmente, nós
>> > contamos com poucos mapeadores experientes para realizar essa tarefa.
>> >
>> > Seguindo a orientação do Sérgio, vocês poderão encontrar todas as
>> > informações sobre o mapeamento nos seguintes links:
>> >
>> >
>> https://wiki.openstreetmap.org/wiki/Organised_Editing/Activities/Rio_Branco
>> >
>> >
>> > https://tasks.hotosm.org/projects/6124
>> >
>> > Muito obrigada.
>> > Lívia
>> > 
>> > -
>> > *Dr. Lívia Castro Degrossi*
>> > 

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

[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: [Talk-GB] Tagging showgrounds

[Paul Berry]

Not sure about the tagging/proposal politics but since there are a small
number of showgrounds, is there anything to stop a UK-specific page being
set up on the Wiki for visibility? Then if anyone wants to harmonise the
tags they can use that as a guide to do so.

There's nothing to say we can't tag in any way we want—and again for this
small collection of entities which are clearly all the same fundamental
object—it's only if we want people to be consistent, or to adopt our tags,
that we would need to go through the process of proposed tag adoption.

Regards,
*Paul*

On Wed, 13 May 2020 at 10:10, nathan case  wrote:

> Hi all,
>
> Just to drag this back up - I encountered an unmapped showground
> (Chipping, Lancashire) whilst adding PROWs and don't know the best way to
> tag. It appears to hold a several large shows each year (well presumably
> not this year!) but doesn't appear to be a recreational site.
>
> I found this abandoned proposal for amenity=show_grounds:
> https://wiki.openstreetmap.org/wiki/Proposed_features/show_grounds It's a
> shame it never got traction as it might enable us to come to some consensus
> on these sites. Can an abandoned proposal be re-opened or does it have to
> be re-proposed?
>
> Cheers.
>
>
>
> -Original Message-
> From: Andy Townsend 
> Sent: 25 February 2020 00:23
> To: talk-gb@openstreetmap.org
> Subject: Re: [Talk-GB] Tagging showgrounds
>
> Since I was going through these anyway to see what ought to be rendered at
> map.atownsend.org.uk, I thought I might as well list them here too. These
> are things "tagged a bit like showgrounds, excluding bus stops and car
> parks", sorted by one of the main tags.
>
> I suspect that the ones tagged just "place", "landuse=grass" or
> "tourism=attraction" only probably need some other tag to say "this is a
> showground".   "events_venue" might be a misunderstanding of what that tag
> was for.  "recreation_ground" may be correct in some cases but I suspect
> isn't in many others. "park" I'd be similarly surprised if it was often
> correct.  In most or all cases it probably needs a local to make the call,
> though...
>
> place:
>
>
> https://www.openstreetmap.org/node/2382298440
> name Mannsfield Showground
> place locality
> source OS OpenData StreetView
>
> https://www.openstreetmap.org/node/3416147963
> name Great Harwood Showground
> place neighbourhood
>
> https://www.openstreetmap.org/node/4347790541
> addr:postcode BS37 8QZ
> addr:street Westerleigh Road
> name The Windmill Fisheries Showground place locality
>
>
> events_venue only:
>
> https://www.openstreetmap.org/node/5849512782
> alt_name Royal Cornwall Event Centre amenity events_venue name
> Royal Cornwall Showground
>
> https://www.openstreetmap.org/node/6938439833
> amenity events_venue
> name Hertfordshire County Showground operator Hertfordshire
> Country Council
>
>
> tourism=attraction only:
>
> https://www.openstreetmap.org/way/283445694
> name Devon County Showground
> tourism attraction
>
> https://www.openstreetmap.org/way/91401877
> name Kent Showground
> source Bing
> tourism attraction
>
> https://www.openstreetmap.org/way/40942963
> barrier fence
> name Norfolk Showground
> tourism attraction
>
> https://www.openstreetmap.org/node/316706558
> name Great Yorkshire Showground
> tourism attraction
>
> https://www.openstreetmap.org/way/104155888
> barrier fence
> name Royal Bath and West of England Showground tourism attraction
>
> https://www.openstreetmap.org/way/239487854
> name Hennock Showground
> tourism attraction
>
> https://www.openstreetmap.org/way/178396540
> addr:city Newark
> addr:postcode NG24 2NY
> addr:street Lincoln Road
> alt_name Newark Show Ground
> name Newark Showground
> operator Newark & Nottinghamshire Agricultural Society phone +44
> 1636 705796 tourism attraction website
> http://www.newarkshowground.com/ wikidata Q15262122
>
> https://www.openstreetmap.org/way/274093728
> name Lincolnshire Showground
> tourism attraction
>
>
> recreation_ground only:
>
> https://www.openstreetmap.org/way/603746353
> alt_name Briscwm Fields
> description Normally farmland,  Used to hold events such as the
> Cardigan County Agricultural Show.
> landuse recreation_ground
> name Cardigan County Showground
> note Located from information on Coflein.
> phone +44 1545 570501
> recreation_ground showground
> website https://cardigancountyshow.org.uk/
>
> https://www.openstreetmap.org/way/34993687
> landuse recreation_ground
> name Mirfield Showground
>
> https://www.openstreetmap.org/way/89151502
> addr:city Peterborough
> addr:housename Peterborough Arena
> addr:postcode PE2 6XE
> addr:street East of England Showground landuse recreation_ground
> name East of England Showground phone +44 1733 363500 website
> 

Re: [OSM-talk] Let's talk Attribution

[Simon Poole]

Am 12.05.2020 um 23:03 schrieb Mateusz Konieczny via talk:
>
>
>
> May 12, 2020, 05:48 by rockyt...@gmail.com:
>
>
> As Joseph said:
>
> The attribution goes on the map.
> This is not a difficult requirement to meet.
>
>
> The most recent version of the guidelines
> drafted by the LWG is almost there, but has drawn community
> criticism
> about being too generous especially w.r.t. initially hidden
> attribution.
>
>
> Is there anywhere I can share my two cents about the guidelines?
>
> I commented on
> https://wiki.openstreetmap.org/wiki/Talk:Draft_Attribution_Guideline
> but I am unsure is it a good place because I got no reply.

Expecting a reply is unreasonable, taking the comments in to account not
(which we did).

>
> One may also join online meeting of a Legal Working Group
> and talk there.
>
> https://wiki.osmfoundation.org/wiki/Licensing_Working_Group
> "The group now meets every 2nd Thursday of the month, at 20:00 UTC, on
> Mumble , unless rescheduled."
>
As you know the LWG has handed the subject back to the board months ago,
not to mention that we provided ample time and venues to provide input
on the matter and that is long closed. Just because somebody wasn't
paying attention doesn't mean that you restart a process when they turn
up and feel they have a right to their opinion being heard*.

Simon

* that was one of the main reasons the OSM licence change was such a
traumatic experience.



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


signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-it] Village / Town

[Fra00]

Per quanto riguarda invece i centri del Molise, di cui non si è parlato nella
discussione, San Martino in Pensilis e Campomarino perché sono stati taggati
come "town"? Mi sembra che tra Larino, Termoli e Guglionesi che sono molto
vicini non ci sia una loro prevalenza o importanza geografica nella zona.



--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

Re: [Talk-GB] Tagging showgrounds

[nathan case]

Hi all,

Just to drag this back up - I encountered an unmapped showground (Chipping, 
Lancashire) whilst adding PROWs and don't know the best way to tag. It appears 
to hold a several large shows each year (well presumably not this year!) but 
doesn't appear to be a recreational site.

I found this abandoned proposal for amenity=show_grounds: 
https://wiki.openstreetmap.org/wiki/Proposed_features/show_grounds It's a shame 
it never got traction as it might enable us to come to some consensus on these 
sites. Can an abandoned proposal be re-opened or does it have to be re-proposed?

Cheers.



-Original Message-
From: Andy Townsend  
Sent: 25 February 2020 00:23
To: talk-gb@openstreetmap.org
Subject: Re: [Talk-GB] Tagging showgrounds

Since I was going through these anyway to see what ought to be rendered at 
map.atownsend.org.uk, I thought I might as well list them here too. These are 
things "tagged a bit like showgrounds, excluding bus stops and car parks", 
sorted by one of the main tags.

I suspect that the ones tagged just "place", "landuse=grass" or 
"tourism=attraction" only probably need some other tag to say "this is a 
showground".   "events_venue" might be a misunderstanding of what that tag was 
for.  "recreation_ground" may be correct in some cases but I suspect isn't in 
many others. "park" I'd be similarly surprised if it was often correct.  In 
most or all cases it probably needs a local to make the call, though...

place:


https://www.openstreetmap.org/node/2382298440
name     Mannsfield Showground
place     locality
source     OS OpenData StreetView

https://www.openstreetmap.org/node/3416147963
name     Great Harwood Showground
place     neighbourhood

https://www.openstreetmap.org/node/4347790541
addr:postcode     BS37 8QZ
addr:street     Westerleigh Road
name     The Windmill Fisheries Showground place     locality


events_venue only:

https://www.openstreetmap.org/node/5849512782
alt_name     Royal Cornwall Event Centre amenity     events_venue name     
Royal Cornwall Showground

https://www.openstreetmap.org/node/6938439833
amenity     events_venue
name     Hertfordshire County Showground operator     Hertfordshire Country 
Council


tourism=attraction only:

https://www.openstreetmap.org/way/283445694
name     Devon County Showground
tourism     attraction

https://www.openstreetmap.org/way/91401877
name     Kent Showground
source     Bing
tourism     attraction

https://www.openstreetmap.org/way/40942963
barrier     fence
name     Norfolk Showground
tourism     attraction

https://www.openstreetmap.org/node/316706558
name     Great Yorkshire Showground
tourism     attraction

https://www.openstreetmap.org/way/104155888
barrier     fence
name     Royal Bath and West of England Showground tourism     attraction

https://www.openstreetmap.org/way/239487854
name     Hennock Showground
tourism     attraction

https://www.openstreetmap.org/way/178396540
addr:city     Newark
addr:postcode     NG24 2NY
addr:street     Lincoln Road
alt_name     Newark Show Ground
name     Newark Showground
operator     Newark & Nottinghamshire Agricultural Society phone     +44 1636 
705796 tourism     attraction website     http://www.newarkshowground.com/ 
wikidata     Q15262122

https://www.openstreetmap.org/way/274093728
name     Lincolnshire Showground
tourism     attraction


recreation_ground only:

https://www.openstreetmap.org/way/603746353
alt_name     Briscwm Fields
description     Normally farmland,  Used to hold events such as the Cardigan 
County Agricultural Show.
landuse     recreation_ground
name     Cardigan County Showground
note     Located from information on Coflein.
phone     +44 1545 570501
recreation_ground     showground
website     https://cardigancountyshow.org.uk/

https://www.openstreetmap.org/way/34993687
landuse     recreation_ground
name     Mirfield Showground

https://www.openstreetmap.org/way/89151502
addr:city     Peterborough
addr:housename     Peterborough Arena
addr:postcode     PE2 6XE
addr:street     East of England Showground landuse     recreation_ground name   
  East of England Showground phone     +44 1733 363500 website     
http://www.peterborougharena.com wheelchair     yes

https://www.openstreetmap.org/way/415636494
leisure     recreation_ground
name     Christow Playing Fields and Showground

https://www.openstreetmap.org/way/4587165
leisure     recreation_ground
name     Essex Showground
source     approximate

https://www.openstreetmap.org/node/30813084
leisure     recreation_ground
name     North Somerset Showground
tourism     attraction

https://www.openstreetmap.org/way/547075306
addr:postcode     LE15 7TW
addr:street     Burley Park Way
landuse     recreation_ground
name     Rutland Showground
note     The new county showground site.
source     EsriWorldImagery
website     https://www.rutlandshowground.com/

https://www.openstreetmap.org/way/588128321
leisure     recreation_ground
name     Strithians Showground

Re: [OSM-talk-be] Weggetje verdwenen, hoe terug ?

[Karel Adams]

:) ikke, want Potlatch is het enige dat ik ken en voor mijn beperkte 
gebruik voldoet dat prima; veel beter dan ID in alle geval.


Maar het ziet ernaar uit dat Flash ten dode is opgeschreven dus ik zal 
wel moeten overstappen :(


KA

On 2020-05-13 08:22, wannes wrote:

Jaahaa, dat is met Flash, wie heeft dat nu nog ? :-)

On Tue, May 12, 2020 at 3:03 PM Jo > wrote:


Er is nog een 'truuk' om verwijderde ways terug te halen. (werkt
enkel voor ways).

Start editeersessie met Potlatch2.

Je wilt eigenlijk de vorige versie van Potlatch gebruiken, haal
daarom de 2 weg uit de url in de adresbalk...

De originele versie van Potlatch maakt gebruik van een niet
gedocumenteerde 'feature' in de API.

Er is een knop om deleted ways te zien.

Jo

On Tue, May 12, 2020 at 1:07 PM Tim Couwelier
mailto:tim.couwel...@gmail.com>> wrote:

Bijlage bleeft hangen wegens groter dan 80kb, maar hierbij
even ter illustratie hoe je ze kan traceren met de 'skyview'
laag.  Is een soort hoogtemodelweergave op grondniveau, de
bomen zie je dus niet.. en het pad wordt zichtbaar.

https://framapic.org/r01ExtbzPorU/Z1Zri8oU24QM.jpg

(ik had al even afzonderlijk gemaild naar de betrokken
persoon, maar mogelijks zijn er nog mensen waarvoor dit een
meerwaarde kan betekenen.)


Op di 12 mei 2020 om 10:57 schreef Wannes Soenen
mailto:wanne...@gmail.com>>:

Ok, dan lijkt me het het “handigste” dat ik een GPX neem
en het pad terug teken (want het zit onder de bomen)
Die relaties, en GR enz toevoegen/verleggen, zal ik eerst
eens moeten bestuderen, want dat heb ik nog nooit gedaan.


Op 12 mei 2020, om 10:53 heeft Sander Deryckere
mailto:sander...@gmail.com>> het
volgende geschreven:

Hallo,

Het hangt er van af hoe lang de wijziging geleden is.
Als het vrij recent is (enkele dagen), kan je de
geschiedenis van een gebied opvragen (de geschiedenis
knop op de hoofdpagina).
Maar deze wijziging lijkt langer geleden te zijn, dus
valt dit moeilijk te bespeuren.

Wat je wel kan is bekijken welke objecten waarschijnlijk
ook gewijzigd zijn bij die aanpassing (zoals het fietspad
dat nu gebruikt wordt).



Als je dat fietspad selecteert, en de geschiedenis
opvraagt, dan kom je hier terecht:
https://www.openstreetmap.org/way/24520913/history

Er is dus in de laatste maanden tamelijk wat aangepast
aan het pad. In het bijzonder zie ik een wijziging van 4
maand geleden met het commentaar "cycleroute 03-04
update: broken (again), now due to missing segments". Wat
er op wijst dat iemand er voor die regio heeft aangepast,
zonder rekening te houden met de relaties.

Het is dus waarschijnlijk niet 1 iemand die de relatie
verlegd heeft, maar iemand heeft dat pad verwijderd, en
iemand anders heeft de relatie opnieuw verbonden met de
bestaande paden...

Mvg,
Sander

Op di 12 mei 2020 om 10:18 schreef Wannes Soenen
mailto:wanne...@gmail.com>>:

Hoi,

Ik zie dat er zeer lokaal, een wegje verdwenen is op
de kaart.
Ik kan dat er zelf terug op gaan zetten, maar dan is
de kans groot dat diegene die de edit gedaan heeft
het weer wist.

Hoe kan ik 1) zien wie de edit deed, of er een
comment bij was? 2) rollback doen

Het betreft een pad net ten zuiden van het
Ringfietspad op
https://www.openstreetmap.org/edit#map=18/51.20462/4.44275
De plaatselijke merkkringen van het GR-pad (en van op
de GR site) loopt wel degelijk over dat pad, niet
over het fietspad.
Dus, de huidige gemaakte situatie is fout, want 1)
pad is niet meer gemapt 2) GR loopt over het fietspad.
___
Talk-be mailing list
Talk-be@openstreetmap.org

https://lists.openstreetmap.org/listinfo/talk-be

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


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

   

Re: [OSM-talk-fr] attributions

[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-be] Weggetje verdwenen, hoe terug ?

[wannes]

Jaahaa, dat is met Flash, wie heeft dat nu nog ? :-)

On Tue, May 12, 2020 at 3:03 PM Jo  wrote:

> Er is nog een 'truuk' om verwijderde ways terug te halen. (werkt enkel
> voor ways).
>
> Start editeersessie met Potlatch2.
>
> Je wilt eigenlijk de vorige versie van Potlatch gebruiken, haal daarom de
> 2 weg uit de url in de adresbalk...
>
> De originele versie van Potlatch maakt gebruik van een niet
> gedocumenteerde 'feature' in de API.
>
> Er is een knop om deleted ways te zien.
>
> Jo
>
> On Tue, May 12, 2020 at 1:07 PM Tim Couwelier 
> wrote:
>
>> Bijlage bleeft hangen wegens groter dan 80kb, maar hierbij even ter
>> illustratie hoe je ze kan traceren met de 'skyview' laag.  Is een soort
>> hoogtemodelweergave op grondniveau, de bomen zie je dus niet.. en het pad
>> wordt zichtbaar.
>>
>> https://framapic.org/r01ExtbzPorU/Z1Zri8oU24QM.jpg
>>
>> (ik had al even afzonderlijk gemaild naar de betrokken persoon, maar
>> mogelijks zijn er nog mensen waarvoor dit een meerwaarde kan betekenen.)
>>
>>
>> Op di 12 mei 2020 om 10:57 schreef Wannes Soenen :
>>
>>> Ok, dan lijkt me het het “handigste” dat ik een GPX neem en het pad
>>> terug teken (want het zit onder de bomen)
>>> Die relaties, en GR enz toevoegen/verleggen, zal ik eerst eens moeten
>>> bestuderen, want dat heb ik nog nooit gedaan.
>>>
>>> Op 12 mei 2020, om 10:53 heeft Sander Deryckere 
>>> het volgende geschreven:
>>>
>>> Hallo,
>>>
>>> Het hangt er van af hoe lang de wijziging geleden is.
>>> Als het vrij recent is (enkele dagen), kan je de geschiedenis van een
>>> gebied opvragen (de geschiedenis knop op de hoofdpagina).
>>> Maar deze wijziging lijkt langer geleden te zijn, dus valt dit moeilijk
>>> te bespeuren.
>>>
>>> Wat je wel kan is bekijken welke objecten waarschijnlijk ook gewijzigd
>>> zijn bij die aanpassing (zoals het fietspad dat nu gebruikt wordt).
>>>
>>> 
>>>
>>> Als je dat fietspad selecteert, en de geschiedenis opvraagt, dan kom je
>>> hier terecht: https://www.openstreetmap.org/way/24520913/history
>>>
>>> Er is dus in de laatste maanden tamelijk wat aangepast aan het pad.  In
>>> het bijzonder zie ik een wijziging van 4 maand geleden met het commentaar 
>>> "cycleroute
>>> 03-04 update: broken (again), now due to missing segments". Wat er op
>>> wijst dat iemand er voor die regio heeft aangepast, zonder rekening te
>>> houden met de relaties.
>>>
>>> Het is dus waarschijnlijk niet 1 iemand die de relatie verlegd heeft,
>>> maar iemand heeft dat pad verwijderd, en iemand anders heeft de relatie
>>> opnieuw verbonden met de bestaande paden...
>>>
>>> Mvg,
>>> Sander
>>>
>>> Op di 12 mei 2020 om 10:18 schreef Wannes Soenen :
>>>
 Hoi,

 Ik zie dat er zeer lokaal, een wegje verdwenen is op de kaart.
 Ik kan dat er zelf terug op gaan zetten, maar dan is de kans groot dat
 diegene die de edit gedaan heeft het weer wist.

 Hoe kan ik 1) zien wie de edit deed, of er een comment bij was? 2)
 rollback doen

 Het betreft een pad net ten zuiden van het Ringfietspad op
 https://www.openstreetmap.org/edit#map=18/51.20462/4.44275
 De plaatselijke merkkringen van het GR-pad (en van op de GR site) loopt
 wel degelijk over dat pad, niet over het fietspad.
 Dus, de huidige gemaakte situatie is fout, want 1) pad is niet meer
 gemapt 2) GR loopt over het fietspad.
 ___
 Talk-be mailing list
 Talk-be@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-be

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


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

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

[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-be] Changing default maxspeed for Brussels in 2021

[joost schouppe]

Hi Yves,

Sounds good. We'll need to update at least these pages:

https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Maxspeed#Belgium
https://wiki.openstreetmap.org/wiki/Key:source:maxspeed#Belgium

Have you given it any thought how we might organize the update efficiently?
I thought perhaps the ways now tagged with source:maxspeed=[something
urban] could be bulk-edited after the change, but it looks like many of
those roads might actually change to explicitly signed 50 during the
transition. So I'm thinking we need to review ALL the roads with a maxspeed
again after the change. To do that, maybe we could take a dump before the
change and use that for some sort of mapping challenge, or add a tag to
indicate that the maxpseed should be reviewed (the risk being that people
might correct the maxpseed and not remove the tag).

Best
Joost

Op zo 10 mei 2020 om 22:25 schreef Yves bxl-forever <
bxl-fore...@linuxmail.org>:

> Hello, folks,
>
> As of January 2021, Brussels will change the default maxspeed on urban
> roads to become an all-30-kph city.  This goes for the entire
> Brussels-Capital Region (161 km²).
> Basically, the idea is the following:
> * no speed roadsign will mean 30-kph
> * on the main roads there will be C43 signs with a 50-kph limit (or
> possibly 70-kph on the biggest ones); those signs are to be repeated after
> every intersection.
> * living streets (20-kph) or pedestrian areas are left untouched
> * motorways are left untouched
>
> The good point is that it will be much easier than now—for drivers and for
> mappers alike—to know whether 50 or 30-kph applies somewhere.
> I will no longer use BE:urban because it’s not the same in every Region.
>
> May I suggest the following tagging scheme
> * maxspeed=30 + source:maxspeed=BE-BXL:urban
> * maxspeed=50 (or 70) + source:maxspeed=sign
>
> What do you think?
>
> Cheers.
> Yves
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>


-- 
Joost Schouppe
OpenStreetMap  |
Twitter  | LinkedIn
 | Meetup

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

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

[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

[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