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

[Guillaume Rischard]

On 9 Nov 2019, at 22:30, thevenon.jul...@free.fr 
 wrote:
> 
> De: Guillaume Rischard
> Objet: Re: [OSM-talk-fr] Élections au board de la Fondation OSM
> 
>> J’ai évité l’hiver dernier une tentative d’entrisme de la Fondation par 100 
>> employés de la société GlobalLogic. Ceux qui ont lu le rapport du MWG que 
>> j’ai co-écrit avec Steve Friedl 
>> (https://openstreetmap.lu/MWGGlobalLogicReport20181226.pdf) savent que le 
>> risque est réel, et à quel point le problème me tient à cœur. La communauté 
>> française a involontairement joué un rôle crucial dans l’enquête.
> 
> Ah oui j avais lu le rapport. sacre travail d analyse et de reporting, c 
> etait passionnant a lire.
> Merci pour les différentes précisions, javais vu HOT dans ta bio mais il n 
> etait pas précisé simple contributeur ou membre
> 
> Bon week end
> Julien

Merci beaucoup! J’ai mis à jour ma bio sur le wiki du coup.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-ie] New Bing aerial imagery

[Colm Moore]

Hi,

There is new Bing aerial imagery available, certainly in the Dublin area. It 
seems to be from 2019.

Colm

---
Never doubt that a small group of thoughtful, committed citizens can change the 
world. Indeed, it is the only thing that ever has. Margaret Mead
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

Re: [Talk-se] Hjälp med naturreservaten

[Christian Asker]

Hej. Här är ett exempel: https://www.openstreetmap.org/way/723565425

Jag har taggat efter vad jag kunde läsa mig till i wikin. Mapnik renderar nog 
inte detta, men däremot OsmAnd.

Mvh Christian




pangoSE  skrev: (9 november 2019 22:31:09 CET)
>Hej Christian
>
>On 2019-11-09 16:28, Christian Asker wrote:
>> Hej. Bra uppmärksammat!
>> 
>> Naturreservaten finns ju som öppna data i shapeformat hos 
>> Naturvårdsverket. Jag har för mig att den shapefilen släpar efter 
>> verkligheten lite dessutom. Sen vill man ju helst få med stigar, 
>> fikabord, informationsskyltar också, men det kräver ju ett fysiskt
>besök.
>> 
>> Jag försöker hålla naturreservaten uppdaterade i "mitt kvarter".
>
>Toppen
>
>> 
>> En relaterad grej är områden som är "biotopskydd". Dessa kan karteras
>i 
>> OSM också.
>
>Vilka taggar använder du till dem?
>
>/pangoSE
>
>> Den 2019-11-09 kl. 15:53, skrev pangoSE:
>>> Hej
>>>
>>> Jag började jobba igen med naturreservaten i dag efter ett års paus.
>>>
>>> Status är som följer:
>>> - OSM ligger efter: Det har tillkommit många nya.
>>> - OSM är fel: vissa NR är fel geometri i OSM jämfört med den öppna
>data
>>> - 286 av våra boundary=protected_area saknar protect_class=* och
>syns 
>>> därför inte på osm.org, se https://overpass-turbo.eu/s/NXn
>>>
>>> Se 
>>>
>https://wiki.openstreetmap.org/wiki/WikiProject_Sweden/naturvardsverket_import#Naturreservat
>
>>>
>>>
>>> Välkommen att bidra till att få ordning på reservaten.
>>>
>>> Mvh
>>> pangoSE
>>> ps se även https://www.openstreetmap.org/user/pangoSE/diary/391178
>där 
>>> jag beskriver hur jag sammanfogar mellan NR-lagret och osm-lagret.
>>>
>>> ___
>>> Talk-se mailing list
>>> Talk-se@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-se
>> 
>> ___
>> Talk-se mailing list
>> Talk-se@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-se

-- 
Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [Talk-at] Radknotenpunktnetz Murtal

[Robert Grübler]

Hi Gottfried,
Danke, freut mich sehr.
Die IG Map-Nimm's-Radl ist damit gegründet
:-)

LG Robert (robhubi)

-Ursprüngliche Nachricht-
Von: Gottfried [mailto:volvo10...@gmail.com] 
Gesendet: Samstag, 9. November 2019 23:02
An: talk-at@openstreetmap.org
Betreff: Re: [Talk-at] Radknotenpunktnetz Murtal

Hallo Robert,

Ich würde bei dem Projekt Nimm‘s Radl mitmachen.

Lg Gottfried



--
Sent from: http://osm-talk-at.1116557.n5.nabble.com/

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


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

Re: [Talk-at] Radknotenpunktnetz Murtal

[Gottfried]

Hallo Robert,

Ich würde bei dem Projekt Nimm‘s Radl mitmachen.

Lg Gottfried



--
Sent from: http://osm-talk-at.1116557.n5.nabble.com/

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

Re: [Talk-se] Hjälp med naturreservaten

[pangoSE]

För den intresserade skrev jag just en guide till konvertering av 
shapefiler för att förbättra upplevelse i JOSM


https://wiki.openstreetmap.org/wiki/QGIS#Using_QGIS_to_filter_data_from_government_sources_and_convert_it_to_KML

Jag har börjat filtrera på "Gällande" eftersom det inte ger så mycket 
mening att lägga in dem som inte är i effekt.



On 2019-11-09 15:53, pangoSE wrote:

Hej

Jag började jobba igen med naturreservaten i dag efter ett års paus.

Status är som följer:
- OSM ligger efter: Det har tillkommit många nya.
- OSM är fel: vissa NR är fel geometri i OSM jämfört med den öppna data
- 286 av våra boundary=protected_area saknar protect_class=* och syns 
därför inte på osm.org, se https://overpass-turbo.eu/s/NXn


Se 
https://wiki.openstreetmap.org/wiki/WikiProject_Sweden/naturvardsverket_import#Naturreservat 



Välkommen att bidra till att få ordning på reservaten.

Mvh
pangoSE
ps se även https://www.openstreetmap.org/user/pangoSE/diary/391178 där 
jag beskriver hur jag sammanfogar mellan NR-lagret och osm-lagret.


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



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

Re: [Talk-se] Hjälp med naturreservaten

[pangoSE]

Hej Christian

On 2019-11-09 16:28, Christian Asker wrote:

Hej. Bra uppmärksammat!

Naturreservaten finns ju som öppna data i shapeformat hos 
Naturvårdsverket. Jag har för mig att den shapefilen släpar efter 
verkligheten lite dessutom. Sen vill man ju helst få med stigar, 
fikabord, informationsskyltar också, men det kräver ju ett fysiskt besök.


Jag försöker hålla naturreservaten uppdaterade i "mitt kvarter".


Toppen



En relaterad grej är områden som är "biotopskydd". Dessa kan karteras i 
OSM också.


Vilka taggar använder du till dem?

/pangoSE


Den 2019-11-09 kl. 15:53, skrev pangoSE:

Hej

Jag började jobba igen med naturreservaten i dag efter ett års paus.

Status är som följer:
- OSM ligger efter: Det har tillkommit många nya.
- OSM är fel: vissa NR är fel geometri i OSM jämfört med den öppna data
- 286 av våra boundary=protected_area saknar protect_class=* och syns 
därför inte på osm.org, se https://overpass-turbo.eu/s/NXn


Se 
https://wiki.openstreetmap.org/wiki/WikiProject_Sweden/naturvardsverket_import#Naturreservat 



Välkommen att bidra till att få ordning på reservaten.

Mvh
pangoSE
ps se även https://www.openstreetmap.org/user/pangoSE/diary/391178 där 
jag beskriver hur jag sammanfogar mellan NR-lagret och osm-lagret.


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


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



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

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

[thevenon . julien]

De: Guillaume Rischard
Objet: Re: [OSM-talk-fr] Élections au board de la Fondation OSM

> J’ai évité l’hiver dernier une tentative d’entrisme de la Fondation par 100 
> employés de la société GlobalLogic. Ceux qui ont lu le rapport du MWG que 
> j’ai co-écrit avec Steve Friedl 
> (https://openstreetmap.lu/MWGGlobalLogicReport20181226.pdf) savent que le 
> risque est réel, et à quel point le problème me tient à cœur. La communauté 
> française a involontairement joué un rôle crucial dans l’enquête.

Ah oui j avais lu le rapport. sacre travail d analyse et de reporting, c etait 
passionnant a lire.
Merci pour les différentes précisions, javais vu HOT dans ta bio mais il n 
etait pas précisé simple contributeur ou membre

Bon week end
Julien

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

[Talk-et] Community in Ethiopia

[Sören Reinecke via Talk-ET]

Hello there,

is in Ethiopia an active OSM Community to map infrastructure?

Cheers

Sören Reinecke alias Valor Naram

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

Re: [OSM-talk-be] Overdreven gedetailleerde mapping ? Exaggerated detailed mapping?

[Marc Gemis]

> And to be honest: I don't think OSM will really surpass commercial maps for 
> car navigation, because up to date traffic information is part of that.
> I don't see how volunteers can arrange that quickly.

In some countries (including Belgium) traffic information from the
government is open data. Some OSM based apps, such as Magic Earth or
MapsFactor Navigator use this information. I have driven to Austria
this year with Magic Earth and the GPS in my car. There was not a lot
of difference in accuracy regarding traffic information.
The traffic slow down on the R0 I went through today was also
announced via Magic Earth.

Waze is also an app that uses volunteers to gather traffic
information. The beta version of Magic Earth that I'm testing now
allows people to send information about road works, traffic jams etc.
to the central servers. Just like Waze.

Some car manufacturers (e.g. BMW) use statistics from the cars of that
brand to gather up-to-date traffic information. Magic Earth does this
as well from their installed base.

So it depends more on the features of your OSM based navigation app
than anything else.
If you are not satisfied with OsmAnd for car navigation, I really
recommend you to try out Magic Earth.

regards

m.

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

Re: [OSM-talk-fr] maquette iD-consensuel : passage en "production" ou c'est bon ainsi ?

[Yves P.]

> de Marc
> d’où ma question : certains ont envie de basculer ?
> ou on reste sur une démonstration théorique en attendant un miracle ?
En ce moment, j’utilise exclusivement JOSM.
Mais oui tant qu’à utiliser iD, j’utiliserais la version consensuelle 

Je me demande naïvement pourquoi on ne peut pas débrancher les dev ou cette 
version d’iD du site OSM ?
Ma réponse, si j’ai bien compris : on ne peut pas car c'est la foundation 
elle-même qui les as mis là.

Donc le problème, est-ce ces développeurs ou est-ce la fondation ?

En attendant, utiliser la version consensuelle mise e ligne par Fred serait un 
moyen de « manifester » notre mécontentement ??

—
Yves

PS: et merci pour le liens vers l’article de woodpeck (Frederik Ramm) ___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] maquette iD-consensuel : passage en "production" ou c'est bon ainsi ?

[marc marc]

Le 09.11.19 à 19:10, ades a écrit :
> iD c’est qui ?

c'est l'éditeur par défaut actuel sur osm.org
donc le plus utilisé (en nombre de contributeur)

> J’ai cru comprendre (plusieurs fils sur cette liste) qu’ils n’ont rien à 
> foutre du wiki, de la liste ou du forum (au sujet des tags).

je nuancerais un peu.
il y a parfois des incohérences sur le wiki.
Bryan (le dev principal d'iD) a voulu "modifier en masse" le wiki,
et il s'est fait allumé.
du coup il considère que le wiki a faux quand il n'a pas le même avis :)

> qui est derrière iD ?

un (Bryan) puis depuis peu un 2ieme employé de Mapbox affecté/payé
pour cette tâche grâce au don de la Knight Foundation,
don fait dans le but explicite d'améliorer l'infra osm.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-at] Radknotenpunktnetz Murtal

[Robert Grübler]

Liebe Mapper,

im Murtal gibt es eine in Österreich einzigartige Radinfrastruktur – das
Radknotenpunktnetzwerk „Nimm’s Radl“. Das Netz mit 101 Knotenpunkte auf 350
km wurde im April 2016 eröffnet. Heute – 3 ½ Jahre später – ist davon in OSM
noch immer keine Spur zu sehen. 

 

Das kann’s nicht sein, das soll sich ändern. Mitwirkende gesucht!

 

Ziel ist, gemeinsam die Art der Erfassung festzulegen und mit Spaß an der
Sache umzusetzen. Grad und Intensität der Mitarbeit ist selbstverständlich
frei. Auch interessierte Anteilnahme ist willkommen.

 

Der Zeitpunkt ist optimal: im Winter planen und im Frühjahr ins Feld ;-)

Wer hat Interesse an dem Thema?

 

Liebe Grüße Robert (robhubi)

 

 

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

Re: [OSM-talk-fr] maquette iD-consensuel : passage en "production" ou c'est bon ainsi ?

[ades]

e ne comprends pas tout (comme toujours ;-) )

iD c’est qui ? tout ce que je sais d’eux c’est que les (enfin, certains) 
contributeurs qui utilisent produisent n’importe quoi ;-), géométries fausse 
(le gros doigt sur la tablette) ; pour les tags, n’en parlons pas… 

J’ai cru comprendre (plusieurs fils sur cette liste) qu’ils n’ont rien à foutre 
du wiki, de la liste ou du forum (au sujet des tags).

Donc dans le genre théorie du complot :  qui est derrière iD ? (J’ai cru 
comprendre qu’il y avait un(e) des[salarié(e)(s)], qui c’est qui paye ?) en 
plus fesse de bouc… c’est un peu édifiant.

Retour à la question de base : id c’est qui ? 

> Le 9 nov. 2019 à 17:49, Vincent Bergeot  a écrit :
> 
> 


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

Re: [OSM-talk-fr] maquette iD-consensuel : passage en "production" ou c'est bon ainsi ?

[marc marc]

Bhousel a écrit (traduit) :> C'est un projet Open Source
en plus de la différence culturelle (une critique correcte
pour un européen passerait pour cinglante pour un américain),
il se dit que Bryan n'est tout simplement pas formé
à ce qu'implique un projet opensource et communautaire.
ceci explique peut-être pourquoi il est si souvent irrité.
A sa décharge, son employeur aurait du le laisser faire
du dev et nommer quelqu'un peu rodé à cet univers
au moins pour la partie communication externe
> je ne vous dois rien."

la vrai réponse serrait de dire qu'il "nous" doit son boulot actuel :)
sans osm, pas de don de la fondation qui paye sa place.
Pas sur qu'il soie capable de l'entendre de la part d'un simple 
contributeur.

Le 09.11.19 à 17:49, Vincent Bergeot a écrit :
> C'est un peu rude de lire cela concernant la porte d'entrée  
> principale à la contribution dans OSM.

c'est le grand reproche qu'on peux faire à la fondation à ce sujet :
cela a brûlé mais il n'y a personne au numéro demandé.

d’où ma question : certains ont envie de basculer ?
ou on reste sur une démonstration théorique en attendant un miracle ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] L’enfer est pavé de bonnes intentions (clef mapillary id<>url)

[osm . sanspourriel]

tu m'as mal compris.
le problème n'est PAS le lieu (talk-fr, wiki, github)
le problème n'est PAS l'idée (le lien utile ou pas)
donc aller manifester à X pour dire "c'est utile"
ne résout pas le problème dont parle TomH dans
sa réponse "cela va faire de la maintenance »

Je comprenais plutôt qu’il ne voulait pas faire un précédent pour
gérer des liens sur des identifiants extérieurs


+1

C'est woodpeck qui avait peur de la maintenance


Il me semblait vraiment que c’était de la pure mauvaise fois (cf. PR
plus bas)

Pas forcément pure mais aussi.

Le retour c’est que c’est dans un projet externe qu’OSM ne maitrise
pas (l'API peut changer, qui édite les données ?…)
Mauvaise foi ou réelle question ?


J'ai eu l'occasion de dire qu'au pire le cache ne serait plus mis à jour.

Donc ce ne serait pas complètement cassé.


Il y a quelqu’un qui en a fait une, mais ça ne bouge pas !!


url ?

Display a link for wikimedia_commons keys #2277


Le ticket d’incident ne datait que du 25 juin 2019, mais comme le
rappel Bibi59 , la PR datait du 15 Nov 2014.

56 pas 59^^.

Ça a finalement bougé, mais l’accouchement s’est fait aux forceps et
sans péridurale.


À la décharge de TomH il dit être passé à côté de ce PR.

Là j'ai du mal à comprendre la gestion du projet, au bout d'un temps
fini on regarde les PR ouverts non ?

Peut-être qu'il est de bonne foi, disons que la lecture des différentes
réactions n'incitent pas à cette lecture.

Quand il parle de non-sense sur les demandes d'Yves avoir des liens
quand les valeurs sont des références (ici vers une image), j'avoue que
les bras m'en tombent.

J'ai dit et je maintiens que le gros du boulot c'était de savoir passer
d'une référence à un lien et ça c'est ce que fait la requête d'Yves.

Que Tom ne souhaite pas faire ce bout de code est parfaitement entendable.
Mais quand on voit un PR qui reste trainer 5 ans et qui fini par passer
parce que 3 personnes au moins (l'auteur, Yves et moi) poussons il faut
bien mesurer les conséquences.

Et une conséquence c'est la moindre envie des quidams d'essayer de
proposer des PR.

Jean-Yvon

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

Re: [OSM-talk-fr] maquette iD-consensuel : passage en "production" ou c'est bon ainsi ?

[Vincent Bergeot]

Le 09/11/2019 à 13:44, marc marc a écrit :

Bonjour,

vous avez tous lu l'email de freed à propos de la maquette iD-consensuel
mis en place voici quelques mois.
vous avez peut-être lu osmweekly le moi passé montrant
l'absence de solution au niveau du board osmf.
la question qui se pose c'est : et maintenant ?
niveau utilisateur, certains-ont ils envie de passer
sur la version consensuelle ?
niveau "détecteur de non consensus", certains ont-ils envie
de faire avancer la liste publiée sur le wiki ?
niveau "soutient du projet", certains ont-ils envie d'aider ?

Dernier accro en date : iD pioche maintenant chez facebook
pour les logos, ce qui fait que éditer via osm.org conduit
à nourrir l'ogre.
https://www.openstreetmap.org/user/woodpeck/diary/391175


merci pour ce lien, très intéressant.

En allant sur le problème d'iD qui pioche chez Facebook (anglais : 
https://github.com/openstreetmap/iD/issues/7028) un des points qui a le 
plus retenu mon attention est la remarque de bhousel (un des deux 
développeurs, salarié de MapBox) qui dit :


Anglais :  I don't have the energy to debate you all on whether it makes 
sense to fetch logos from Facebook [...] This is an Open Source project 
and I don't owe you anything.


Qui pourrait se traduire selon DeepL par

"Je n'ai pas l'énergie nécessaire pour débattre de la question de savoir 
s'il est judicieux d'aller chercher des logos sur Facebook.[...] C'est 
un projet Open Source et je ne vous dois rien."


C'est un peu rude de lire cela concernant la porte d'entrée principale à 
la contribution dans OSM.


Je me suis retenu de demander si c'était une blague, car je ne suis pas 
sur que cela soit la meilleure réaction !


merci marcmarc pour ta veille

--
Vincent Bergeot


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

[Talk-de] Tile cache mit asynchronem Update und Bereichsbegrenzung

[Manuel Reimer]

Hallo,

Da eventuell auch andere daran Interesse haben könnten habe ich meinen 
Tile-Cache-Proxy unter einer Open-Source-Lizenz veröffentlicht (GNU 
Affero GPL).


https://github.com/M-Reimer/tilecache.cgi

Hintergrund war unter anderem die Unabhängigkeit vom offiziellen 
Tileserver für den Fall, dass dieser aufgrund von Störungen offline ist. 
In dem Fall würden die Tiles dann ohne Verzögerung aus meinem eigenen 
Cache kommen.


Weiterhin muss ich mir für meine Karte dann keine Gedanken mehr über die 
DSGVO machen, denn ab jetzt kommen alle Daten von meinem eigenen Server 
und es fließen keine Daten mehr nach extern ab.


Was mich auch sehr gestört hat am offiziellen Tile-Server ist, dass ein 
Referrer gesendet werden muss. Ich habe für unseren Server die 
Referrer-Policy so gesetzt, dass der Browser keinen Referrer nach extern 
senden wird. Das wäre mit dem offiziellen Tile-Server eigentlich verboten.


Für Feedback wäre ich dankbar.

Gruß

Manuel


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

Re: [Talk-se] Naturvårdsverkets nya Nationella MarktäckeData

[Snusmumriken]

On Fri, 2019-11-08 at 17:46 +0100, pangoSE wrote:
> Hej
> 
> Håller helt med Essin. Se min kommentar här 
> https://www.openstreetmap.org/changeset/70936570
> 
> Jag förslår att vi sätter stop för import tills att vi sett att nån 
> tagit åt sig den enorma uppgift att städa upp det som redan
> importerats.
> 
> Tills dess får vi leva med en "vit" karta i några områden.
> 
> Nån emot?

Utan att ha kollat på detaljerna i det här fallet så vill jag bara
instämma med att importer ska hållas till en mycket hög standard.


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

Re: [Talk-se] Hjälp med naturreservaten

[Christian Asker]

Hej. Bra uppmärksammat!

Naturreservaten finns ju som öppna data i shapeformat hos 
Naturvårdsverket. Jag har för mig att den shapefilen släpar efter 
verkligheten lite dessutom. Sen vill man ju helst få med stigar, 
fikabord, informationsskyltar också, men det kräver ju ett fysiskt besök.


Jag försöker hålla naturreservaten uppdaterade i "mitt kvarter".

En relaterad grej är områden som är "biotopskydd". Dessa kan karteras i 
OSM också.



Mvh Christian


Den 2019-11-09 kl. 15:53, skrev pangoSE:

Hej

Jag började jobba igen med naturreservaten i dag efter ett års paus.

Status är som följer:
- OSM ligger efter: Det har tillkommit många nya.
- OSM är fel: vissa NR är fel geometri i OSM jämfört med den öppna data
- 286 av våra boundary=protected_area saknar protect_class=* och syns 
därför inte på osm.org, se https://overpass-turbo.eu/s/NXn


Se 
https://wiki.openstreetmap.org/wiki/WikiProject_Sweden/naturvardsverket_import#Naturreservat


Välkommen att bidra till att få ordning på reservaten.

Mvh
pangoSE
ps se även https://www.openstreetmap.org/user/pangoSE/diary/391178 där 
jag beskriver hur jag sammanfogar mellan NR-lagret och osm-lagret.


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


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

Re: [Talk-at] Mappen von Schneekettenpflicht

[Patrick Strasser-Mikhail]

Am 09.11.2019 um 13:53 schrieb Friedrich Volkmann:


Mit der Zusatztafel liegt allerdings nahe, dass das Schild das ganze 
Jahr über dort steht, 


Ja, ist weder mit Vorkehrungen zum Wegklappen noch zum Abhängen oder 
Überdecken ausgestattet. Der Weg dahinter ist auch wirklich sehr steil.


und dann ist ein Tagging wie motor_vehicle:conditional="no@snow AND 
snow_chains=no" technisch möglich. Aber dann sollte es wahrscheinlich 
auch ein gleichlautendes standalone-Tag geben, und als solches wär 
snow_chains=yes/no weniger zweckmäßig. Vielleicht besser sowas wie 
tyres=any/winter/spikes/snow_chains? Keine Ahnung.


Es ist ein Gebot, deshalb auch blau. Effektiv ist es ein Verbot des 
Fahrens ohne Ketten, daher würde dein erster Vorschlag für mich schon 
sinn ergeben, bis auf Weiters.


Mit taginfo
    https://taginfo.openstreetmap.org/search?q=snow_chain
finde ich heiße 13 Einträge, davon:

 * 10 snow_chains = no -> Bedingungsloses Kettenverbot in Cincinatty
   auf der I 471
 * 2 snow_chains:snow = mandatory -> Kettenpflicht bei Schneefall.
   Genau was ich will, aber die formulierung ist nicht praktikabel mit
   der Bedingung im Key. Übrigens in der gleiche Gemeinde wo ich die
   Tafel gefunden habe, nämlich Stattegg.
 * 1 snow_chains:conditional = yes @ (Nov 15-Mar 31)

"snow_chains" als key erlaubt die Modifizierung mit ":conditional" wie 
bekannt, yes/no würde bedingungsl Pflicht und Verbot ermöglichen. Würde 
gleich funktionieren wie eine Geschwindigkeitsbeschränkung oder 
Überholverbot (z.B. bei Regen).


"tyres" als Key find ich nicht passend, weil es nicht um die Reifen 
geht, sondern um eine variable Zusatzausrüstung, die angelegt werden 
kann. Es wären auch Sommerreifen mit Ketten möglich. Spikes wären 
natürlich etwas für "tyres".


Ich finde es bemerkenswert dass das nicht öfters vorkommt, weil es das 
zumindest in Österreich und Deutschland ein offizielles Verkehrszeichen 
(in DE Nr. 268) ist, und dann gar nicht _so_ selten, auf wichtigen 
Pässen sogar sehr relevant, teilweise fast das ganze Jahr.


Muss man sich überlegen, wenn man ein entsprechendes Proposal 
schreibt. Zu geben scheint es noch keins, also Bahn frei für dich, 
wenn du Lust hast. :-)


Noch nie gemacht.

Ich hab schon einige abgelehnte oder kommatöse Proposals gesehen. Wenn 
ich das mache, dann soll das auch die Zeit wert sein. Wie bereiteich das 
gut vor? Wer hat Erfahrung damit?


Patrick/trapicki

--
Cheap - good - fast: choose any two
Patrick Strasser-Mikhail
patr...@wirklich.priv.at
OSM: trapicki

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

[Talk-se] Hjälp med naturreservaten

[pangoSE]

Hej

Jag började jobba igen med naturreservaten i dag efter ett års paus.

Status är som följer:
- OSM ligger efter: Det har tillkommit många nya.
- OSM är fel: vissa NR är fel geometri i OSM jämfört med den öppna data
- 286 av våra boundary=protected_area saknar protect_class=* och syns 
därför inte på osm.org, se https://overpass-turbo.eu/s/NXn


Se 
https://wiki.openstreetmap.org/wiki/WikiProject_Sweden/naturvardsverket_import#Naturreservat


Välkommen att bidra till att få ordning på reservaten.

Mvh
pangoSE
ps se även https://www.openstreetmap.org/user/pangoSE/diary/391178 där 
jag beskriver hur jag sammanfogar mellan NR-lagret och osm-lagret.


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

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

[Guillaume Rischard]

Bonjour tous,

Merci Marc. Je n’ai en effet jamais fait partie de HOT. J’ai contribué 
occasionellement à des tâches HOT il y a quelques années, par exemple au Mali, 
mais c’est tout.

Désolé Christian, je ne suis pas membre du CA, même si j’ai déjà été candidat. 
Je fais partie du Data Working Group et du Membership Working Group.

Julien a raison, il est important que les idées de la communauté francophone 
soit connues dans le CA. Les succès des collaborations avec le secteur public 
et autour de l’Open Data gagneraient à être reproduits au niveau international.

J’ai évité l’hiver dernier une tentative d’entrisme de la Fondation par 100 
employés de la société GlobalLogic. Ceux qui ont lu le rapport du MWG que j’ai 
co-écrit avec Steve Friedl 
(https://openstreetmap.lu/MWGGlobalLogicReport20181226.pdf) savent que le 
risque est réel, et à quel point le problème me tient à cœur. La communauté 
française a involontairement joué un rôle crucial dans l’enquête.

Je papote sur le chat IRC #osm-fr, garde mon beau t-shirt de la SotM de Paris 
d’avril 2014, et ai adhéré à OpenStreetMap France en 2018. Mais si je suis élu, 
je ne représenterai pas un groupe ou une communauté, mais tous les 
contributeurs, et travaillerai à éviter que n’importe quel groupe ou intérêt 
spécial n’exercent trop d’influence sur la Fondation. Je resterai entièrement 
indépendant des différentes sociétés et ONG actives dans l’univers OSM.

Bon weekend

Guillaume - http://hdyc.neis-one.org/?Stereo 


> On 9 Nov 2019, at 14:35, marc marc  wrote:
> 
> Le 08.11.19 à 22:58, thevenon.jul...@free.fr a écrit :
>> Pour HOT: Mikel Maron, Guillaume Rischard
> 
> sauf modif récente que Guillaume confirmera ou infirmera,
> Guillaume ne fait pas partie de HOT.
> c'est à mes yeux un bon candidat soucieux de la communauté
> et sans conflit d'intérêt ou dépendance envers une entreprise.
> cfr ses réponses à la précédente élection.
> reste qu'il faut plus qu'un élu.
> ___
> 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-at] name:suffix & name:prefix (de)

[Robert Kaiser]

andreas wecer schrieb:


Am Sa., 9. Nov. 2019 um 03:39 Uhr schrieb Robert Kaiser :


IMHO ist diese Relation sowieso falsch (und ev. alle Statutarstädte).
Der Bezirk heißt "Steyr-Stadt", die Gemeinde heißt "Steyr".


  Laut Wikipedia ist der Name "Steyr". Bei manchen Statutarstädten wie St.
Pölten und Wiener Neustadt gibt es nicht einmal (mehr) die Unterscheidung
mit "-Land/Umgebung", d.h. ohne die Präzisierung mit "Bezirk" oder anderen
Zusatzinformationen bzw. Abweichung vom offiziellen Namen sind die nicht
einmal unterscheidbar.


Der Name der Stadt und der Gemeinde ist "Steyr", das stimmt. Der Name 
des Bezirkes ist allerdings "Steyr-Stadt" (hauptsächlich, weil es 
daneben noch "Steyr-Land" gibt). Und auch wenn sie flächenmäßig 
deckungsgleich und veraltungsmäßig großteils vereinheitlicht sind, 
handelt es sich um zwei verschiedene Dinge bei Gemeinde/Stadt und Bezirk.


KaiRo


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

[Talk-at] Fahrverbot für LKW mit Anhänger

[Patrick Strasser-Mikhail]

Hallo!

Bin heute über ein kniffliges Verkehrszeichen gestolpert:

Fahrverbot für LKW mit Anhänger, STVO §52 Lit. a Z. 7b

Ich hab das gemappt als:

hgv:conditional=no@(trailer=yes)

Passt das so? Wenn ja dann würd ich das in's Wiki eintgragen.

LG Patrick/trapicki

--
Cheap - good - fast: choose any two
Patrick Strasser-Mikhail
patr...@wirklich.priv.at


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

Re: [OSM-talk-fr] L’enfer est pavé de bonnes intentions (clef mapillary id<>url)

[Yves P.]

> tu m'as mal compris.
> le problème n'est PAS le lieu (talk-fr, wiki, github)
> le problème n'est PAS l'idée (le lien utile ou pas)
> donc aller manifester à X pour dire "c'est utile"
> ne résout pas le problème dont parle TomH dans
> sa réponse "cela va faire de la maintenance »
Je comprenais plutôt qu’il ne voulait pas faire un précédent pour gérer des 
liens sur des identifiants extérieurs
Est-ce un problème de traduction, un point de vue biaisé (de ma part)… ?

Il me semblait vraiment que c’était de la pure mauvaise fois (cf. PR plus bas)

> sous entendu : TomH ne veux pas s'en occuper et il est bénévole.
Je pensais qu’il était salarié de la fondation OSM.

> c'est cela qu'il faut résoudre pour avancer.
Je veux bien écrire des snipets, des bibliothèques de code, recenser 
l’existant, écrire des PR…
Mais il y a la question de la (sa) mauvaise foi (cf. plus bas).

>> Tu parles de créer un tableau dans le wiki qui permettrait 
>> (automatiquement ou manuellement) aux dev de créer ces liens dans le 
>> site web d’OSM ?
> 
> la (ta?) requête remplace utilement la page wiki qui listerait
> tous les liens.
C’est bien « ma » requête 

Avec l’aide de Bibi56, on en a parlé à Tom et al. sur GitHub : possible 
solution mentioned in #2405 

Le retour c’est que c’est dans un projet externe qu’OSM ne maitrise pas (l'API 
peut changer, qui édite les données ?…)
Mauvaise foi ou réelle question ?

> ce qui manque c'est le "sans maintenance" : un script qui produit
> le code "osm.org" nécessaire pour faire ces liens.
> ainsi quelqu'un exécute le script, fait un PR quand il y a une modif,
> et le problème de "cela va faire trop de maintenance" est résolu.
> ou un bout de code qui sait lire le résultat de la requête.
On est bien d’accord et ce n’est pas trop difficile à écrire 

L’intérêt que je vois à faire ça dans wikidata c’est qu’on peut « documenter » 
chaque propriété.
Le projet est mûr, carré, facilement lisible par une machine et par un humain.
Pas besoin non plus de maitriser GitHub et la « dialecte » wiki.

Mais effectivement un simple fichier JSON ou CSV peut faire l’affaire.
Et les administrateurs OSM pourront garder le contrôle si c’est hébergé dans le 
compte GitHub de la foundation.

>> Il y a quelqu’un qui en a fait une, mais ça ne bouge pas !!
> 
> url ?
Display a link for wikimedia_commons keys #2277 

Le ticket d’incident ne datait que du 25 juin 2019, mais comme le rappel Bibi59 
, la PR datait du 15 Nov 2014.
Ça a finalement bougé, mais l’accouchement s’est fait aux forceps et sans 
péridurale.

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

Re: [OSM-ja] Google Mapsと一致するPOI

[241 bizen]

コメントへの返信を待ってみようと思います。
ありがとうございました。

2019年11月9日(土) 20:08 Miura Hiroshi :
>
> この方、ながらく 仙台を拠点として、 ApndroidのMAPS.MEによる編集をされていますね
> 岡山での大規模な編集をAndroid のMAPS.MEで編集されているのは
> たしかに、不思議なかんじがします。
>
> ご本人に気づいてもらって、返信してもらえるのが一番ですが、きづいてもらえないですかね。
>
> 三浦
>
> 2019年11月8日(金) 20:30 241 bizen :
> >
> > はじめまして。
> > 岡山のbizen241といいます。
> >
> > Google Mapsからの転記と思われる編集への対応に困り、投稿しました。
> >
> > ---
> >
> > 先日OSMChaを見てみると、多数の店舗のノードが追加されていました。
> > https://www.openstreetmap.org/changeset/76681052
> >
> > そのうちの複数のPOIが既存のものと重複していたため、前後の編集も含めて確認しました。
> > https://www.openstreetmap.org/changeset/76572954
> >
> > 編集が広範囲に渡っていることなどから不思議に思い、Google Mapsと照合しました。
> > すると、nameタグの内容の多くがGoogle Mapsの表記の全部または一部と一致していました。
> ___
> Talk-ja mailing list
> Talk-ja@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ja
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

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

[marc marc]

Le 08.11.19 à 22:58, thevenon.jul...@free.fr a écrit :
> Pour HOT: Mikel Maron, Guillaume Rischard

sauf modif récente que Guillaume confirmera ou infirmera,
Guillaume ne fait pas partie de HOT.
c'est à mes yeux un bon candidat soucieux de la communauté
et sans conflit d'intérêt ou dépendance envers une entreprise.
cfr ses réponses à la précédente élection.
reste qu'il faut plus qu'un élu.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-at] Mappen von Schneekettenpflicht

[Friedrich Volkmann]

On 09.11.19 12:14, Patrick Strasser-Mikhail wrote:
Ich bin über eine Straße mit den Verkehrstafel gestoßen: "Schneeketten 
vorgeschrieben" (STVO §52 Abs a Z.22) mit Zusatztafel "Schneestern" also 
"Diese Zusatztafel weist darauf hin, dass das Straßenverkehrszeichen bei 
Schneelage oder Eisbildung auf der Fahrbahn zu beachten ist." STVO §54 Abs. 
5 Lit f


Ich habe ausgiebig danach gesucht, keine Idee gefunden, wie das zu mappen 
ist.


Viele dieser Schilder werden nur dann aufgestellt (oder hervorgedreht), wenn 
die Jahreszeit bzw. Witterung entsprechend ist. Solche temporären 
Beschränkungen zu mappen hat wenig Sinn. Noch dazu gilt nicht der 
Umkehrschluss, dass man ohne dieses Zeichen die Straße ohne Schneeketten 
befahren kann. Bei winterlichen Verhältnissen ist Hirn gefragt, nicht Routing.


Mit der Zusatztafel liegt allerdings nahe, dass das Schild das ganze Jahr 
über dort steht, und dann ist ein Tagging wie 
motor_vehicle:conditional="no@snow AND snow_chains=no" technisch möglich. 
Aber dann sollte es wahrscheinlich auch ein gleichlautendes standalone-Tag 
geben, und als solches wär snow_chains=yes/no weniger zweckmäßig. Vielleicht 
besser sowas wie tyres=any/winter/spikes/snow_chains? Keine Ahnung. Muss man 
sich überlegen, wenn man ein entsprechendes Proposal schreibt. Zu geben 
scheint es noch keins, also Bahn frei für dich, wenn du Lust hast. :-)


--
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Talk-se] SCBs öppna geodata är CC-BY :(

[Sebastian Johansson]

Hittade den här mallen liggandes på bloggen, men den är på engelska.
Borde gå att översätta.

Värt att notera är att SCB inte har CC-BY rakt av, då de har tillägget
"Om du själv har bearbetat data från SCB ska du inte ange källa."

https://blog.openstreetmap.org/2017/03/17/use-of-cc-by-data/
https://drive.google.com/file/d/0B3PN5zfbzThqeTdWR1l3SzJVcTg/view

On Fri, Nov 8, 2019 at 8:20 PM pangoSE  wrote:
>
> Hej
>
> Jag skulle vilja rita in polygonen för Sundsvall men den är CC-BY.
>
> Hur gör vi?
>
> Är det nån här som jobbar på SCB eller som är van att förklara för
> myndighetspersoner varför CC-BY inte funkar för oss? Alternativt är det
> nån som har en brevmall liggande jag kan skicka ifall ingen annan vill
> dra i detta?
>
> https://www.scb.se/vara-tjanster/oppna-data/
>
> Mvh
>
> pangoSE
>
>
>
> ___
> Talk-se mailing list
> Talk-se@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-se

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

[OSM-talk-fr] maquette iD-consensuel : passage en "production" ou c'est bon ainsi ?

[marc marc]

Bonjour,

vous avez tous lu l'email de freed à propos de la maquette iD-consensuel 
mis en place voici quelques mois.
vous avez peut-être lu osmweekly le moi passé montrant
l'absence de solution au niveau du board osmf.
la question qui se pose c'est : et maintenant ?
niveau utilisateur, certains-ont ils envie de passer
sur la version consensuelle ?
niveau "détecteur de non consensus", certains ont-ils envie
de faire avancer la liste publiée sur le wiki ?
niveau "soutient du projet", certains ont-ils envie d'aider ?

Dernier accro en date : iD pioche maintenant chez facebook
pour les logos, ce qui fait que éditer via osm.org conduit
à nourrir l'ogre.
https://www.openstreetmap.org/user/woodpeck/diary/391175

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

Re: [OSM-talk-fr] L’enfer est pavé de bonnes intentions (clef mapillary id<>url)

[marc marc]

Le 07.11.19 à 14:03, Yves P. a écrit :
>> je sais pas s'il est nécessaire d'aller remplir des lignes sur le wiki.
> Si *tous* les *lecteurs* de cette liste (et *tous* les *contributeurs* 
> d’OSM) maitrise GitHub, ça ne sert à rien

tu m'as mal compris.
le problème n'est PAS le lieu (talk-fr, wiki, github)
le problème n'est PAS l'idée (le lien utile ou pas)
donc aller manifester à X pour dire "c'est utile"
ne résout pas le problème dont parle TomH dans
sa réponse "cela va faire de la maintenance"
sous entendu : TomH ne veux pas s'en occuper et il est bénévole.
c'est cela qu'il faut résoudre pour avancer.

>> à cause de la maintenance
>> (rajouter et/ou modifier la table de correspondance id <> url).
>> surtout que chaque id est à ajouter dans osm.org  josm etc
> Je ne suis pas sûr de comprendre ?
> 
> Tu parles de créer un tableau dans le wiki qui permettrait 
> (automatiquement ou manuellement) aux dev de créer ces liens dans le 
> site web d’OSM ?

la (ta?) requête remplace utilement la page wiki qui listerait
tous les liens.
ce qui manque c'est le "sans maintenance" : un script qui produit
le code "osm.org" nécessaire pour faire ces liens.
ainsi quelqu'un exécute le script, fait un PR quand il y a une modif,
et le problème de "cela va faire trop de maintenance" est résolu.
ou un bout de code qui sait lire le résultat de la requête.

>> le plus utile est d'en discuter, de faire un PR
> Sur cette liste ?

le lieux importe peu. si quelqu'un poste la solution ici parce
qu'il n'a pas de compte github, copier/coller la solution sur github 
n'est pas rébarbatif :)

> Il y a quelqu’un qui en a fait une, mais ça ne bouge pas !!

url ?

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

Re: [Talk-bd] Discussion: Issues with name localization for Bangladesh

[Fazle Rabbi]

Dear Mr Aftabuzzaman,


Thank you for participating in the discussion. We really appreciate it.


> I respectfully disagree that we should use default/primary "name" tag in
English instead of Bangla. If i understand correctly, OSM policy/general
community guideline is that default/primary "name" tag should be in
whatever language is used locally (for Bangladesh it is Bangla). (
https://wiki.openstreetmap.org/wiki/Names#Localization
https://wiki.openstreetmap.org/wiki/Multilingual_names ) It is common
practice and it is followed by most countries e.g Japan, China, Russia, all
arabic, cyrillic speaking countries etc countries.

Disagreement is part of discussion and always welcomed. You have said that
as per your understating the OSM policy/general community guideline says
`name` tag should be in local language and you refer to 2 OSM wiki links.
The first link is about `name` tag localization not about what should be
on a `name` tag. The first line of that section says, "By now the majority
of rendering systems can deal with Unicode characters, so you can use the
local script for the default name tag. There is no need to use the Latin
script.". If I understand it correctly it says we can use local script
assumed it works in most system but for us it is not working. The second
link is about one place having multiple name in multiple language. If you
check the Issue section (
https://wiki.openstreetmap.org/wiki/Multilingual_names#Issues), it says in
the first point "if not disputed" `name` should have local name. I agree to
disagree. We have dispute in local name. Multilingual name is not same as
localization. For example, 'United States' has 'মার্কিন যুক্তরাষ্ট্র' as
Bengali as Multilingual name but in the context of our country we call it
'America'. Please don't mix them up. You have also referenced that Japan,
China, Russia usages it but spiked about India which has similar font to
Bangladesh than any of those countries. India has a different page (
https://wiki.openstreetmap.org/wiki/India#Naming_in_different_scripts_and_languages)
for it where the community after much discussion decided to keep English in
`name` tag. Emphasis on 'after much discussion'. Let's see if we have
anything of the same kind, shall we? We see that we do have a Bangladesh
section (https://wiki.openstreetmap.org/wiki/Multilingual_names#Bangladesh)
that says that `name` should be Bengali and `name:en= should be in English.
But if we see the version history (
https://wiki.openstreetmap.org/w/index.php?title=Multilingual_names=history)
for that page that this edit was made by you(
https://wiki.openstreetmap.org/wiki/User:Aftab) on 19:55, 28 May 2019‎. The
first ever edit made by you on OSM was on 04 Jul 2018 17:53:57. Nobody in
the community knows about the page or the change. This looks very
convenient, isn't it? This is very heart-breaking to see that you edited
the wiki page without community consent to justify your work.


> We should use English because some software doesn't render Bangla
correctly isn't acceptable reason. It's may be true but By now the majority
of rendering systems/software can deal with unicode characters, supports
Bangla characters. Just because some software/site doesn't support Bangla
so we should use English, is like you have headache so cut the head like
solution.

Let's focus on the problem, shall we? The problem is putting Bengali in
`name` tag is causing problem and how we should solve it. For you, UX
problem caused by software that can't render Bengali is not an 'acceptable
reason' to replace Bengali names with `name:bn` tag even if it makes the
work of disaster response challenging, and we should ask the dev to fix
them. Fair enough. What we need to remember that this is an open source
ecosystem and people work as volunteer so it is tough to put a deadline on
a problem like this. So what should we do in the meantime? If it doesn't
work, shouldn't we use the Latin script instead of making a horrible user
experience and waiting for the devs to fix the problem?

I think, in your rush to reply you didn't read the email completely or
understand it. For example, forgot about the second point for adopting
English name in `name` tag which was the problem faced by humanitarian aid
agencies like UN, MSF, Red Crescent and WFP who were unable to the data for
Bangladesh. You said that "It is not true that in order to fix Bangla
rendering problem, developer needs to learn Bangla.". Unfortunately, I
didn't say that on my mail. What I said that if we keep default names to
Bengali, people from other country who wants to use the map of Bangladesh
in OSM needs to learn because how else they will use that map with Bengali
name?


> It is also not true that English names were deleted altogether, i can see
it just moved to "name:en" field (e.g "name = Road 1" became "name = সড়ক ১"
& "name:en = Road 1"). If any software/site doesn't want to show local
language but english, they easily fallback to name:en.

At the past 

[Talk-at] Mappen von Schneekettenpflicht

[Patrick Strasser-Mikhail]

Hallo!

Ich bin über eine Straße mit den Verkehrstafel gestoßen: "Schneeketten 
vorgeschrieben" (STVO §52 Abs a Z.22) mit Zusatztafel "Schneestern" also 
"Diese Zusatztafel weist darauf hin, dass das Straßenverkehrszeichen bei 
Schneelage oder Eisbildung auf der Fahrbahn zu beachten ist." STVO §54 
Abs. 5 Lit f


Ich habe ausgiebig danach gesucht, keine Idee gefunden, wie das zu 
mappen ist. Ist ja in Österreich gar nicht so selten.


Gibt es das schon gemappt?

LG Patrick

--
Cheap - good - fast: choose any two
Patrick Strasser-Mikhail
patr...@wirklich.priv.at


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

Re: [OSM-talk-be] Overdreven gedetailleerde mapping ? Exaggerated detailed mapping?

[marc marc]

If it'sn't a place=locality, but only a cadastral name with known 
boundary, a boundary=cadastral + name is better
the problem is that it is often places said that the elders used
without precise limits and it is then taken up by the land registry
and notaries, for example to locate a famrland

Le 09.11.19 à 11:45, Karel Adams a écrit :
> Mij lijkt dit enkel een kwestie van "minder-dan-perfecte" tagging: in 
> plaats van "name=HoutchiPloutch" hoort het voor mij te zijn 
> "name:land_register=..." of iets dergelijks.De tag "place=locality" 
> lijkt mij trouwens ook aanvechtbaar.
> 
> A mon avis, il suffit d'appliquer un tag plus correcte ou plus 
> approprié, p.e. "name:land_register" au lieu de "name:". Je ne suis pas 
> trop heureux avec le "place=locality" non plus.
> 
> KA
> 
> On 11/8/19 9:59 PM, EeBie wrote:
>> I have a problem with a kind of exaggerated detailed mapping that 
>> makes the map difficult to read and use.
>> That is by giving fields and meadows their cadastral name by mapping 
>> them as place=locality and name=*.
>> You can find this in some parts of Wallonie as 
>> https://www.openstreetmap.org/#map=16/50.5175/5.4718
>> When using an OSM map, these fields look similar to villages. It 
>> happened that I couldn't find the name of a village between a lot of 
>> such names of  fields and meadows.
>> Unfortunately it is even more used in France: try to find the villages 
>> in this: https://www.openstreetmap.org/#map=13/49.2093/5.3281=C
>> I hope that it will not end like this in Wallonie nor Flandres. I 
>> guess nobody is waiting to see all the cadastral names on an OSM maps. 
>> That is for dedicated cadastral maps.
>>
>> Eebie
>>
>>
>>
>> Op 5/11/19 om 09:26 schreef Lionel Giard:
>>> @Marc These parking along street are indeed often not 
>>> "amenity=parking" but probably more related to parking:lane tag 
>>>  (tagged on the 
>>> highway itself). Technically it is suggested to only map these kind 
>>> of roadside parking with the parking:lane tag on the street.
>>> But yes, it could be mapped with amenity=parking_space (without 
>>> amenity=parking around it). and we could maybe use the 
>>> "type=site"+"site=parking" relation to group them (as it is suggested 
>>> for complex parking lot already) and allow people to understand that 
>>> it is linked to the road (including the street line in the relation) 
>>> and that it is roadside parking. But it is undocumented to use it 
>>> that way. ^^
>>>
>>> Le mar. 5 nov. 2019 à 08:42, Marc Gemis >> > a écrit :
>>>
>>> Ik map soms ook parkeerplaatsen in een straat met enkel
>>> amenity=parking_space, omdat er geen parking (in de betekenis van
>>> parkeerterrein) is.
>>> Ik vind niet dat elke groep van een paar parkeerplaatsen in een
>>> straat
>>> parkings zijn. En het wordt gerenderd, dus kan je je afvragen of de
>>> wiki niet moet aangepast worden voor zulke gevallen ?
>>>
>>> m.
>>>
>>> On Mon, Nov 4, 2019 at 4:33 PM Stijn Rombauts via Talk-be
>>> mailto:talk-be@openstreetmap.org>> wrote:
>>> >
>>> > Even terug naar de aanpassingen van Jakka en ook wat
>>> aansluitend op onderstaande opmerking van Marc. En ook omdat ik
>>> in alle stilte al wel wat werk van Jakka heb verbeterd (en dan
>>> bedoel ik effectief: fouten corrigeren):
>>> > - parkeerplaatsen: Jakka heeft daar de individuele
>>> parkeerplaatsen gemapt; op zich OK. Maar waarom een aantal wel en
>>> de andere niet? En vergeet dan niet de amenity=parking
>>> (toegevoegd door Anakil): m.a.w. zorg er op z'n minst voor dan
>>> eerst de grote lijnen in orde zijn, voeg pas daarna de details
>>> toe (wiki: Mapping parking spaces is an addition, not a
>>> replacement, to mapping a whole parking lot with
>>> amenity=parking.) Jakka had trouwens een paar parkeerplaatsen
>>> foutief gemapt met amenity= parking. Daarna heeft ene philippec
>>> binnen de amenity=parking van Anakil nog eens 2 keer een amenity
>>> =parking toegevoegd (zoals deze
>>> https://www.openstreetmap.org/way/741861188)...? Waarom?
>>> > - nog parkeerplaatsen: daar
>>> (https://www.openstreetmap.org/way/731154048) 3 brede
>>> parkeerplaatsen getekend terwijl het er 5 smalle zijn...
>>> > - https://www.openstreetmap.org/way/118797990: lanes=2 -->
>>> lanes=1, maar turn:lanes=none|merge_to_left vergeten te
>>> verwijderen en ook cycleway:right=lane vergeten te verwijderen
>>> > - het gebruik van traffic_calming=island (volgens wiki: A
>>> structure separating at least two lanes of a highway from each
>>> other for a short distance.). Dan lijkt dat daar (aan het stukje
>>> Zemstbaan dat aansluit op de Brusselsesteenweg) heel veel
>>> verkeerd gebruikt. Alleen al omdat die 'dingen' daar niks met
>>> traffic calming te maken hebben, volgens mij.
>>> > - een aantal fietspaden zijn apart 

Re: [OSM-ja] Google Mapsと一致するPOI

[Miura Hiroshi]

この方、ながらく 仙台を拠点として、 ApndroidのMAPS.MEによる編集をされていますね
岡山での大規模な編集をAndroid のMAPS.MEで編集されているのは
たしかに、不思議なかんじがします。

ご本人に気づいてもらって、返信してもらえるのが一番ですが、きづいてもらえないですかね。

三浦

2019年11月8日(金) 20:30 241 bizen :
>
> はじめまして。
> 岡山のbizen241といいます。
>
> Google Mapsからの転記と思われる編集への対応に困り、投稿しました。
>
> ---
>
> 先日OSMChaを見てみると、多数の店舗のノードが追加されていました。
> https://www.openstreetmap.org/changeset/76681052
>
> そのうちの複数のPOIが既存のものと重複していたため、前後の編集も含めて確認しました。
> https://www.openstreetmap.org/changeset/76572954
>
> 編集が広範囲に渡っていることなどから不思議に思い、Google Mapsと照合しました。
> すると、nameタグの内容の多くがGoogle Mapsの表記の全部または一部と一致していました。
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-ja] 報告：バグ？

[Miura Hiroshi]

おそらくバグ、不具合なのだろうとおもいます。
いずれにせよ、台風での被害に対し、マッピングで遠地の英国から支援いただけることに
感謝します。

三浦

2019年11月5日(火) 0:27 :
>
> 長野の台風19号対応プロジェクト（#6980 - Typhoon Hagibis, 2019 Building Mapping. Nagano
> >> city, Nagano,
> >> Japan）のvalidationをしています。スクエア一つを終了し、完了のバーを押そうとしたところ画面がフリーズ、なぜか右隣のマッピングだけが済んでいるスクエアが「完了」となり、更に画面が飛んで韓国北部（北緯38度線の下）が表示されました。
>
> 私の現在地はイギリスで、どうしてこういうことになるのかさっぱりわかりません。
>
> 作業中もデータ処理が遅く、動かしたマウスカーソルが全然違う場所に出現したりすることも何度かありました。
>
> 妙な意図を持つハッキングでなければいいのですが。
>
> とりあえずログアウトを済ませ、ご報告しておきます。
>
> Meg_W
>
> ___
> Talk-ja mailing list
> Talk-ja@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ja
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-talk-be] Overdreven gedetailleerde mapping ? Exaggerated detailed mapping?

[Karel Adams]

Mij lijkt dit enkel een kwestie van "minder-dan-perfecte" tagging: in 
plaats van "name=HoutchiPloutch" hoort het voor mij te zijn 
"name:land_register=..." of iets dergelijks.De tag "place=locality" 
lijkt mij trouwens ook aanvechtbaar.


A mon avis, il suffit d'appliquer un tag plus correcte ou plus 
approprié, p.e. "name:land_register" au lieu de "name:". Je ne suis pas 
trop heureux avec le "place=locality" non plus.


KA

On 11/8/19 9:59 PM, EeBie wrote:
I have a problem with a kind of exaggerated detailed mapping that 
makes the map difficult to read and use.
That is by giving fields and meadows their cadastral name by mapping 
them as place=locality and name=*.
You can find this in some parts of Wallonie as 
https://www.openstreetmap.org/#map=16/50.5175/5.4718
When using an OSM map, these fields look similar to villages. It 
happened that I couldn't find the name of a village between a lot of 
such names of  fields and meadows.
Unfortunately it is even more used in France: try to find the villages 
in this: https://www.openstreetmap.org/#map=13/49.2093/5.3281=C
I hope that it will not end like this in Wallonie nor Flandres. I 
guess nobody is waiting to see all the cadastral names on an OSM maps. 
That is for dedicated cadastral maps.


Eebie



Op 5/11/19 om 09:26 schreef Lionel Giard:
@Marc These parking along street are indeed often not 
"amenity=parking" but probably more related to parking:lane tag 
 (tagged on the 
highway itself). Technically it is suggested to only map these kind 
of roadside parking with the parking:lane tag on the street.
But yes, it could be mapped with amenity=parking_space (without 
amenity=parking around it). and we could maybe use the 
"type=site"+"site=parking" relation to group them (as it is suggested 
for complex parking lot already) and allow people to understand that 
it is linked to the road (including the street line in the relation) 
and that it is roadside parking. But it is undocumented to use it 
that way. ^^


Le mar. 5 nov. 2019 à 08:42, Marc Gemis > a écrit :


Ik map soms ook parkeerplaatsen in een straat met enkel
amenity=parking_space, omdat er geen parking (in de betekenis van
parkeerterrein) is.
Ik vind niet dat elke groep van een paar parkeerplaatsen in een
straat
parkings zijn. En het wordt gerenderd, dus kan je je afvragen of de
wiki niet moet aangepast worden voor zulke gevallen ?

m.

On Mon, Nov 4, 2019 at 4:33 PM Stijn Rombauts via Talk-be
mailto:talk-be@openstreetmap.org>> wrote:
>
> Even terug naar de aanpassingen van Jakka en ook wat
aansluitend op onderstaande opmerking van Marc. En ook omdat ik
in alle stilte al wel wat werk van Jakka heb verbeterd (en dan
bedoel ik effectief: fouten corrigeren):
> - parkeerplaatsen: Jakka heeft daar de individuele
parkeerplaatsen gemapt; op zich OK. Maar waarom een aantal wel en
de andere niet? En vergeet dan niet de amenity=parking
(toegevoegd door Anakil): m.a.w. zorg er op z'n minst voor dan
eerst de grote lijnen in orde zijn, voeg pas daarna de details
toe (wiki: Mapping parking spaces is an addition, not a
replacement, to mapping a whole parking lot with
amenity=parking.) Jakka had trouwens een paar parkeerplaatsen
foutief gemapt met amenity= parking. Daarna heeft ene philippec
binnen de amenity=parking van Anakil nog eens 2 keer een amenity
=parking toegevoegd (zoals deze
https://www.openstreetmap.org/way/741861188)...? Waarom?
> - nog parkeerplaatsen: daar
(https://www.openstreetmap.org/way/731154048) 3 brede
parkeerplaatsen getekend terwijl het er 5 smalle zijn...
> - https://www.openstreetmap.org/way/118797990: lanes=2 -->
lanes=1, maar turn:lanes=none|merge_to_left vergeten te
verwijderen en ook cycleway:right=lane vergeten te verwijderen
> - het gebruik van traffic_calming=island (volgens wiki: A
structure separating at least two lanes of a highway from each
other for a short distance.). Dan lijkt dat daar (aan het stukje
Zemstbaan dat aansluit op de Brusselsesteenweg) heel veel
verkeerd gebruikt. Alleen al omdat die 'dingen' daar niks met
traffic calming te maken hebben, volgens mij.
> - een aantal fietspaden zijn apart bijgetekend (OK), maar
waarom niet het stukje langs de Zemstbaan van Zemstsesteenweg
naar Brusselsesteenweg? De oneway-tag lijkt mij ook een aantal
keer te ontbreken. En ook de bicycle=use_sidepath op de highways
is niet toegevoegd...
>
> Dat dingen in osm van jaren oud verbeterd, verfijnd of
geüpdatet moeten worden, is logisch. Maar dat recente
veranderingen nog hopen extra werk vragen omdat ze zeer
onvolledig of ronduit fout zijn, vind ik behoorlijk frustrerend.
En met zo'n aanpassingen wordt de databank er ook echt niet
bruikbaarder op. Soit, 't is ook mijn eigen schuld omdat ik er

[OSM-talk] FOSDEM 2020: Call for Papers

[Ilya Zverev]

Hi folks,

You might be familiar with FOSDEM, the biggest European open source conference. 
It is an event not to miss: dozens of simultaneous tracks, thousands of 
developers, no corporate distractions, absolutely free and open, like it should 
be. And this year it will again feature a Geospatial track.

I invite you to submit a talk proposal for the track. Share what you did in the 
past year: with OSM, with open source, with technology. Anything would do — 
even if it does not include programming, like writing docs, mapping or 
organising a community.

Submit your talk here:
https://penta.fosdem.org/submission/FOSDEM20 
 

See more info in the official announcement of the Geospatial track:
https://lists.osgeo.org/pipermail/dutch/2019-October/001773.html 
 

The deadline is Sunday, 1st of December 23:59 (CET, I suppose). You need no 
registration to attend the conference (on 1-2 February). Please come: I would 
be happy to meet you there.

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

Re: [OSM-talk-be] Overdreven gedetailleerde mapping ? Exaggerated detailed mapping?

[Chris Van Bael]

Hi Eebie,

you have a point that indeed those maps are confusing the way OSM renders
them at the site.
But with mapping: there is a difference between what is in the database and
what is displayed.
If what you see is not clear, then perhaps the renderer should be adapted.

As I said in an earlier post: the first line on the OSM wiki states it
wants user to use maps "using them in creative, productive, or unexpected
ways"
If you only put in data for foot/bike/car navigation, you are excluding a
whole range of create and unexpected usages.
So it all boils down to what exactly OSM wants to be.

And to be honest: I don't think OSM will really surpass commercial maps for
car navigation, because up to date traffic information is part of that.
I don't see how volunteers can arrange that quickly.

So I would say: let's provide sufficient data to allow other uses of OSM.
If that includes cadaster data, why not?  It's not like all cadaster are
free or easy to use.
If local people are willing to put the effort into inserting correct data,
why not allow them?
It is their map also.

On Fri, 8 Nov 2019 at 23:00, EeBie  wrote:

> I have a problem with a kind of exaggerated detailed mapping that makes
> the map difficult to read and use.
> That is by giving fields and meadows their cadastral name by mapping them
> as place=locality and name=*.
> You can find this in some parts of Wallonie as
> https://www.openstreetmap.org/#map=16/50.5175/5.4718
> When using an OSM map, these fields look similar to villages. It happened
> that I couldn't find the name of a village between a lot of such names of
> fields and meadows.
> Unfortunately it is even more used in France: try to find the villages in
> this: https://www.openstreetmap.org/#map=13/49.2093/5.3281=C
> I hope that it will not end like this in Wallonie nor Flandres. I guess
> nobody is waiting to see all the cadastral names on an OSM maps. That is
> for dedicated cadastral maps.
>
> Eebie
>
>
>
> Op 5/11/19 om 09:26 schreef Lionel Giard:
>
> @Marc These parking along street are indeed often not "amenity=parking"
> but probably more related to parking:lane tag
>  (tagged on the
> highway itself). Technically it is suggested to only map these kind of
> roadside parking with the parking:lane tag on the street.
> But yes, it could be mapped with amenity=parking_space (without
> amenity=parking around it). and we could maybe use the
> "type=site"+"site=parking" relation to group them (as it is suggested for
> complex parking lot already) and allow people to understand that it is
> linked to the road (including the street line in the relation) and that it
> is roadside parking. But it is undocumented to use it that way. ^^
>
> Le mar. 5 nov. 2019 à 08:42, Marc Gemis  a écrit :
>
>> Ik map soms ook parkeerplaatsen in een straat met enkel
>> amenity=parking_space, omdat er geen parking (in de betekenis van
>> parkeerterrein) is.
>> Ik vind niet dat elke groep van een paar parkeerplaatsen in een straat
>> parkings zijn. En het wordt gerenderd, dus kan je je afvragen of de
>> wiki niet moet aangepast worden voor zulke gevallen ?
>>
>> m.
>>
>> On Mon, Nov 4, 2019 at 4:33 PM Stijn Rombauts via Talk-be
>>  wrote:
>> >
>> > Even terug naar de aanpassingen van Jakka en ook wat aansluitend op
>> onderstaande opmerking van Marc. En ook omdat ik in alle stilte al wel wat
>> werk van Jakka heb verbeterd (en dan bedoel ik effectief: fouten
>> corrigeren):
>> > - parkeerplaatsen: Jakka heeft daar de individuele parkeerplaatsen
>> gemapt; op zich OK. Maar waarom een aantal wel en de andere niet? En
>> vergeet dan niet de amenity=parking (toegevoegd door Anakil): m.a.w. zorg
>> er op z'n minst voor dan eerst de grote lijnen in orde zijn, voeg pas
>> daarna de details toe (wiki: Mapping parking spaces is an addition, not a
>> replacement, to mapping a whole parking lot with amenity=parking.) Jakka
>> had trouwens een paar parkeerplaatsen foutief gemapt met amenity= parking.
>> Daarna heeft ene philippec binnen de amenity=parking van Anakil nog eens 2
>> keer een amenity =parking toegevoegd (zoals deze
>> https://www.openstreetmap.org/way/741861188)...? Waarom?
>> > - nog parkeerplaatsen: daar (
>> https://www.openstreetmap.org/way/731154048) 3 brede parkeerplaatsen
>> getekend terwijl het er 5 smalle zijn...
>> > - https://www.openstreetmap.org/way/118797990: lanes=2 --> lanes=1,
>> maar turn:lanes=none|merge_to_left vergeten te verwijderen en ook
>> cycleway:right=lane vergeten te verwijderen
>> > - het gebruik van traffic_calming=island (volgens wiki: A structure
>> separating at least two lanes of a highway from each other for a short
>> distance.). Dan lijkt dat daar (aan het stukje Zemstbaan dat aansluit op de
>> Brusselsesteenweg) heel veel verkeerd gebruikt. Alleen al omdat die
>> 'dingen' daar niks met traffic calming te maken hebben, volgens mij.
>> > - een aantal fietspaden zijn apart bijgetekend (OK), maar waarom niet
>> het