Re: [OSM-talk-fr] Source = livre sous copyright

[Vincent Bergeot]

Bonjour,


Le 14/12/2018 à 08:12, Jean-Claude Repetto a écrit :

Bonjour,

Je viens de tomber sur cette zone:
https://www.openstreetmap.org/#map=17/43.71058/6.87575
dans laquelle un contributeur a ajouté de nombreuses cabanes, avec 
"source=Promenades Archéologiques et Pastorales dans le pays de 
Saint-Vallier"
C'est un ouvrage de 1988, donc il n'est probablement pas dans le 
domaine public.


De plus, il a mis des noms tels que "Cabane double - 9" ou "Borie - 
4". Je suppose que les numéros correspondent à ceux du livre, ils ne 
sont certainement pas écrits sur place !


Que faire ? Prendre contact avec l'auteur, bien que sa contribution 
date de plus de 3 ans, tout enlever, ou autre action ?



prendre contact avec le contributeur oui, d'autant qu'il y a 7 mois, il 
contribuait toujours.


à minima, et voir :)

à plus






Jean-Claude

___
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-fr] Source = livre sous copyright

[Jean-Claude Repetto]

Bonjour,

Je viens de tomber sur cette zone:
https://www.openstreetmap.org/#map=17/43.71058/6.87575
dans laquelle un contributeur a ajouté de nombreuses cabanes, avec 
"source=Promenades Archéologiques et Pastorales dans le pays de 
Saint-Vallier"
C'est un ouvrage de 1988, donc il n'est probablement pas dans le domaine 
public.


De plus, il a mis des noms tels que "Cabane double - 9" ou "Borie - 4". 
Je suppose que les numéros correspondent à ceux du livre, ils ne sont 
certainement pas écrits sur place !


Que faire ? Prendre contact avec l'auteur, bien que sa contribution date 
de plus de 3 ans, tout enlever, ou autre action ?


Jean-Claude

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

Re: [Talk-cz] Fwd: Copyright OSM map

[Jachym Cepicky]

Případ "Freytag  & Berndt" komentovat neumím, vypadá to na "přeprodej"
ještě 3tí strany, přijde mi, že to je na diskusi na úrovni OSM-Global

Případ chytré mapy a závaznosti. Ná na openstreetmap.org/copyright, čtu

For a browsable electronic map, the credit should appear in the corner
of the map.

Včetně příkladu.

Někde v českém překladu jsem to viděl taky.


J



ne 9. 12. 2018 v 0:30 odesílatel Pavel Machek  napsal:
>
> On Fri 2018-12-07 15:42:59, Jachym Cepicky wrote:
> > Mariáne,
> >
> > v pořádku to není. http://www.openstreetmap.org/copyright jasně píše a
> > ukazuje, jak to má vypadat.
>
> Je to zavazne?
>
> Protoze openstreetmap je treba na
>
> https://zpravy.idnes.cz/christiania-kodan-dansko-zeme-nezeme-serial-nezavislost-ped-/zahranicni.aspx?c=A180925_212735_zahranicni_kha
>
> Tam kde by clovek cekal "Copyright Openstreetmap" je reklama na
> "Phonemaps" a pod tim je text "Mapy poskytuje freytag & berndt
> vydavatel nejrozsáhlejšího obrazového vlastivědného průvodce o naší
> zemi Český atlas."...
>
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz



-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/pgp/JachymCepicky.pgp

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

Re: [Talk-hr] Renderiranje je zapelo?

[Matija Nalis]

Hm, zavrsavas u Amsterdamu.

Svi ti spori (5-6 sekundi) tile server requesti javljaju da su na
Trogdoru (novi tile cache server u Amsterdamu):
"x-cache-lookup: HIT from trogdor.openstreetmap.org:3128"

Oni koji zavrse na Viserionu (u HR) su relativno OK (brze od 1.1 sec)

A trogdor izgleda je problematican (jedini kaska u reportiranju):
https://hardware.openstreetmap.org/

simurgh Hosted by Delta Telecom in Baku, Azerbaijan munin   
03:45
stormfly-02 Hosted by OSUOSL in Corvallis, Oregon   munin   
03:32
trogdor Hosted by Blix Solutions in Amsterdam, Netherlands  munin   
12 December
viserionHosted by CARNet in Pula, Croatia   munin   
03:26

a i ljudi se zale na druge probleme s njim:
https://help.openstreetmap.org/questions/67154/trogdor-err_socket_failure?

Dakle dva su problema:

- trogdor (tile server cache na kojem zavrsavas) je izgleda problematican zbog 
opterecenja diskova pa je zbog toga sporo. 
  
https://munin.openstreetmap.org/openstreetmap.org/trogdor.openstreetmap.org/diskstats_utilization/index.html
  Prijavio sam sada na operati...@osmfoundation.org (ne znam da li hbogner ima 
bolji kontakt) pa ce valjda rijesiti.

- drugo pitanje je zasto uopce zavrsavas na Amsterdamu (a ja npr. ne)? 
  Koliko vidim Trogdor ne bi trebao niti pokrivati HR? 
https://dns.openstreetmap.org/tile.openstreetmap.org.html
  Dakle iz nekog razloga vjerojatno se krivo detektira odakle si...
  To bi isto bilo dobro rijesiti, jer ce ti udaljeniji serveri uvijek biti 
sporiji (ne ovako ekstremno kao kad su potrgani, naravno)


Pitanja (u vezi tog drugog problema sto uopce zavrsavas na Trogdoru u 
Amsterdamu):

1) Da li mozda koristis neki javni DNS koji nije od tvog ISPa ? (npr. 1.1.1.1 
ili 8.8.8.8?)
   Ili mozda VPN? To bi moglo dovesti do upucivanja na udaljeniji server

2) mozes li otici na npr. https://check-host.net/ pa kliknuti na IP
   na vrhu stranice lijevo? Pa ti pokaze 3 baze gdje detektira na razlicite 
   nacine gdje si kako bi te poslao najblizem serveru. Sto ti javlja?

Matija

P.S. Tnx na trudu za prijavu problemu i sudjelovanju u rjesavanju istog!


On Thu, Dec 13, 2018 at 01:48:18PM +, Ivan Delac wrote:
> hbogner napisa:
> > I ja sam uočio probleme sa sporijim učitavanjem, te sam skužio da s 
> > mreža zakucava na 100mega, prijavio sam to i limit na serveru je 
> > promjenjen tako da se sad manje država spaja na njega, te je nakon toga 
> > učitavanje sa 5 sekundi palo na ispod 1 sekunde.
> 
> Onda je najvjerojatnije do toga. Prije jedno mjesec dana je bilo
> neizdrživo, sad je donekle prihvatljivo iako nije baš bajno. Povlači mi
> tajlove ne brže od 1 Mbit/s. Upravo sada isprobavam i dosta varira brzina,
> unutar 5 minuta jednom učita stranicu za 2 sekunde da bi za par minuta bilo
> 5 ili čak do 19 sekundi.
> 
> Evo taj HAR file, ali mislim da nije problem do mene jer samo Mapnik šteka.
> Humanitarian i cycle map rade savršeno.
> https://www.dropbox.com/s/ypvv50mirc8fj7i/har%20osm.zip?dl=0
> 
> 
> ___
> Talk-hr mailing list
> Talk-hr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-hr

-- 
Opinions above are GNU-copylefted.

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

Re: [Talk-cz] Mapy.cz - spoluprace

[Jachym Cepicky]

rád bych připomněl, že seznam má v topgisu podíl, takže otázka
uvolnění leteckých snímků není úplně mimo mísu

J
út 11. 12. 2018 v 21:44 odesílatel Jan Macura  napsal:
>
> Ahoj,
>
> On Tue, 11 Dec 2018 at 16:00, Petr Vozdecký  wrote:
>>
>> asi by slo o pilotni projekt synchronizace dat "treti stranou" v CR, ktery 
>> by byl postaveny tak, ze vznikla spolecna data by mela referencni zakladnu v 
>> OSM databazi (alespon pokud je mi znamo).
>
>
> super nápad, udělat z toho (pro nás) pilotní projekt v koordinaci mezi NGO, 
> GOV a Biz, tj. v tomto případě OSM ČR (+ WM ČR) + ŘSD + Seznam.
> Zásadní by ale bylo mít toho "project leadera", někoho, kdo si takový projekt 
> vezme na starost.
>
>
>>
>> (...) myslim, ze do stejne kategorie pak patri i SOS body (Body zachrany) v 
>> lesich a turistickych lokalitach. A to uz by chtelo pokus o hromadne ziskani 
>> techto dat od provozovatelu (zpravidla kraje).
>
>
> Body záchrany patří do stejné kategorie z pohledu OSM, ale z hlediska 
> poskytovatele dat jsme jinde. Teď bych to nemíchal.
>
> H.
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz



-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/pgp/JachymCepicky.pgp

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

Re: [Talk-it] utilizzo di noexit=yes

[Sergio Manzi]

Trovata, qui: https://wiki.openstreetmap.org/wiki/Tag%3Anoexit%3Dno ed è 
deprecata, a favore di fixme=continue

Peccato, la hic_sunt_leones mi piaceva...

Ciao!


On 2018-12-14 00:34, Sergio Manzi wrote:
>
> Tra l'altro, nella pagina wiki per noexit [1] (/che dovrebbe essere 
> autoritativa per quella tag/), non si fa nessuna menzione dell'uso 
> esoterico/iniziatico di "noexit=no" ad indicare una way di cui... non si sa 
> dove vada a finire.
>
> Nell'orma della migliore tradizione cartografica, potremmo proporre una nuova 
> chiave here_be_dragons=yes [2] oppure hic_sunt_leones=yes [3] come valida 
> alternativa per quelle situazioni...   :-))
>
> Ciao!
>
> [1] https://wiki.openstreetmap.org/wiki/Key:noexit
> [2] https://en.wikipedia.org/wiki/Here_be_dragons
> [3] https://it.wikipedia.org/wiki/Hic_sunt_leones
>
>
> On 2018-12-13 23:58, Sergio Manzi wrote:
>>
>> La mia perplessità, nella frase che hai citato, era relativa al fatto che si 
>> è preferito usare una logica del tipo "(*è vero*) (che questa strada *non 
>> ha* uscita)" rispetto all'altra possibilità, equivalente, "(*non è vero*) 
>> (che questa strada *ha* una uscita)".
>>
>> Per il resto, penso sarebbe preferibile un fixme=*
>>
>> E' vero che in https://wiki.openstreetmap.org/wiki/Key:fixme si dice che si 
>> può (deve???) mappare "/noexit=no — For tagging incomplete ways (not 
>> completely surveyed) as such/", ma trovo la cosa assolutamente priva di 
>> senso: nexit=no, se la logica non è un'opinione, vuol dire che la strada ha 
>> una uscita.
>>
>> Ciao!
>>
>>
>> On 2018-12-13 23:44, Martin Koppenhoefer wrote:
>>>
>>>
>>> sent from a phone
>>>
>>> On 13. Dec 2018, at 20:46, Sergio Manzi mailto:s...@smz.it>> 
>>> wrote:
>>>
 Inoltre non riesco a capire perché a qualcuno sia venuto in mente di 
 ragionare in logica negata: noexit=yes === exit=no, che mi sembrerebbe di 
 più chiara ed immediata comprensione (/ma comunque inutile/).
>>>
>>>
>>> è un flag: Strada senza uscita -> si
>>>
>>> Non è del tutto inutile in quanto si tratta di un tag per altri mappatori: 
>>> lì è verificato che non ci sia altra uscita (vuol dire mappatura completa, 
>>> perché in OSM non sai mai se non c’è strada oppure non è mappata.) Nella 
>>> prassi, la situazione potrebbe essere cambiata, quindi che fai, non 
>>> verifichi comunque ;-)
>>>
>>>
>>> Ciao, Martin 
>>>
>>>
>>>
>>> ___
>>> Talk-it mailing list
>>> Talk-it@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-it


smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] utilizzo di noexit=yes

[Sergio Manzi]

Tra l'altro, nella pagina wiki per noexit [1] (/che dovrebbe essere 
autoritativa per quella tag/), non si fa nessuna menzione dell'uso 
esoterico/iniziatico di "noexit=no" ad indicare una way di cui... non si sa 
dove vada a finire.

Nell'orma della migliore tradizione cartografica, potremmo proporre una nuova 
chiave here_be_dragons=yes [2] oppure hic_sunt_leones=yes [3] come valida 
alternativa per quelle situazioni...   :-))

Ciao!

[1] https://wiki.openstreetmap.org/wiki/Key:noexit
[2] https://en.wikipedia.org/wiki/Here_be_dragons
[3] https://it.wikipedia.org/wiki/Hic_sunt_leones


On 2018-12-13 23:58, Sergio Manzi wrote:
>
> La mia perplessità, nella frase che hai citato, era relativa al fatto che si 
> è preferito usare una logica del tipo "(*è vero*) (che questa strada *non ha* 
> uscita)" rispetto all'altra possibilità, equivalente, "(*non è vero*) (che 
> questa strada *ha* una uscita)".
>
> Per il resto, penso sarebbe preferibile un fixme=*
>
> E' vero che in https://wiki.openstreetmap.org/wiki/Key:fixme si dice che si 
> può (deve???) mappare "/noexit=no — For tagging incomplete ways (not 
> completely surveyed) as such/", ma trovo la cosa assolutamente priva di 
> senso: nexit=no, se la logica non è un'opinione, vuol dire che la strada ha 
> una uscita.
>
> Ciao!
>
>
> On 2018-12-13 23:44, Martin Koppenhoefer wrote:
>>
>>
>> sent from a phone
>>
>> On 13. Dec 2018, at 20:46, Sergio Manzi mailto:s...@smz.it>> 
>> wrote:
>>
>>> Inoltre non riesco a capire perché a qualcuno sia venuto in mente di 
>>> ragionare in logica negata: noexit=yes === exit=no, che mi sembrerebbe di 
>>> più chiara ed immediata comprensione (/ma comunque inutile/).
>>
>>
>> è un flag: Strada senza uscita -> si
>>
>> Non è del tutto inutile in quanto si tratta di un tag per altri mappatori: 
>> lì è verificato che non ci sia altra uscita (vuol dire mappatura completa, 
>> perché in OSM non sai mai se non c’è strada oppure non è mappata.) Nella 
>> prassi, la situazione potrebbe essere cambiata, quindi che fai, non 
>> verifichi comunque ;-)
>>
>>
>> Ciao, Martin 
>>
>>
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it


smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] utilizzo di noexit=yes

[Sergio Manzi]

La mia perplessità, nella frase che hai citato, era relativa al fatto che si è 
preferito usare una logica del tipo "(*è vero*) (che questa strada *non ha* 
uscita)" rispetto all'altra possibilità, equivalente, "(*non è vero*) (che 
questa strada *ha* una uscita)".

Per il resto, penso sarebbe preferibile un fixme=*

E' vero che in https://wiki.openstreetmap.org/wiki/Key:fixme si dice che si può 
(deve???) mappare "/noexit=no — For tagging incomplete ways (not completely 
surveyed) as such/", ma trovo la cosa assolutamente priva di senso: nexit=no, 
se la logica non è un'opinione, vuol dire che la strada ha una uscita.

Ciao!


On 2018-12-13 23:44, Martin Koppenhoefer wrote:
>
>
> sent from a phone
>
> On 13. Dec 2018, at 20:46, Sergio Manzi mailto:s...@smz.it>> 
> wrote:
>
>> Inoltre non riesco a capire perché a qualcuno sia venuto in mente di 
>> ragionare in logica negata: noexit=yes === exit=no, che mi sembrerebbe di 
>> più chiara ed immediata comprensione (/ma comunque inutile/).
>
>
> è un flag: Strada senza uscita -> si
>
> Non è del tutto inutile in quanto si tratta di un tag per altri mappatori: lì 
> è verificato che non ci sia altra uscita (vuol dire mappatura completa, 
> perché in OSM non sai mai se non c’è strada oppure non è mappata.) Nella 
> prassi, la situazione potrebbe essere cambiata, quindi che fai, non verifichi 
> comunque ;-)
>
>
> Ciao, Martin 
>
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it


smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] utilizzo di noexit=yes

[Martin Koppenhoefer]

sent from a phone

> On 13. Dec 2018, at 20:46, Sergio Manzi  wrote:
> 
> Inoltre non riesco a capire perché a qualcuno sia venuto in mente di 
> ragionare in logica negata: noexit=yes === exit=no, che mi sembrerebbe di più 
> chiara ed immediata comprensione (ma comunque inutile).


è un flag: Strada senza uscita -> si

Non è del tutto inutile in quanto si tratta di un tag per altri mappatori: lì è 
verificato che non ci sia altra uscita (vuol dire mappatura completa, perché in 
OSM non sai mai se non c’è strada oppure non è mappata.) Nella prassi, la 
situazione potrebbe essere cambiata, quindi che fai, non verifichi comunque ;-)


Ciao, Martin 


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

Re: [Talk-GB] OS Boundary-Line - Manchester political wards and related boundaries, dealing with inconsistent data

[Warin]

I have faced formal learning things by using tool A at first because it 
'is easy', then the next year learning tool B because 'we' needed to do 
more complex things, then the next year learning tool C because 'we' 
needed to do the most complex things...

on numerous subjects... taught in formal subjects.
Having to learn tools A and B were a waste of my time .. give the choice 
if I think I'm going to be around to need the more complex tools I go 
straight for tool C.

I have never bothered with ID .. I went straight for tool JOSM.

On 13/12/18 23:00, Edward Bainton wrote:
As a new mapper around just long enough to know that I've made some 
crass newbie mistakes already [point in case, just replied without 
editing the subject line... apologies!], I agree with Andy. The iD 
editor is the the go-to editor for newbies, myself included, and the 
snap feature is so apparent in the UX that I have regularly taken its 
steer and made new objects follow old nodes.


Presumably it would be possible to have some 'sticky' features that 
aren't so easily modified - these boundaries would seem to be a good 
candidate; so would roads when they've been rigorously established 
from multiple data sources.


And/or perhaps a warning in iD that flags the pros and cons of 
snapping to existing nodes, and/or gives the option of a 
bulk-undo/bulk-disconnect if you've done that and thought better of it.






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

Re: [Talk-ar] Retos de MapRoulette en Argentina

[Andrew Wiseman]

Hola Hernan,

Es posible que alguien lo haya arreglado, pero también es posible que haya una 
pequeña esquina incorrecta, por ejemplo como esta en Colombia: 
https://www.openstreetmap.org/#map=18/4.81916/-74.56129

Y buena idea en el comentario del changeset, puedo cambiarlo.

Muchas gracias,

Andrew


Andrew Wiseman |  Maps | andrew_wise...@apple.com 




> On Dec 13, 2018, at 7:33 AM, Hernán Javier López  
> wrote:
> 
> Andrew! Muy buena la herramienta que estan usando. Estoy probando las tareas 
> de los caminos en angulo y encontré solo una marcada hasta ahora que no vi el 
> error, no se si por falta de avisar que fue solucionado o alguien lo arreglo 
> entre que lo detectaron y publicaron la tarea. 
> El único comentario para hacer, es si pudiesen programar que el comentario 
> del changeset sea algo mas que #maproulette que tenga un agregado de la tarea 
> especifica, en este caso, agregarle el mismo titulo 
> #maproulette Sharp Angle Roads / Carreteras de Ángulo Agudo en Argentina
> Saludos
> Hernan
> 
> El mié., 12 dic. 2018 a las 20:46, Andrew Wiseman ( >) escribió:
> Hola OSM Argentina,
> 
> Esto es Andrew del equipo de mapas de Apple. Llevamos algún tiempo trabajando 
> en el red vial (https://github.com/osmlab/appledata/issues/34 
> ) y recientemente usado 
> nuestro herramienta Atlas para análisis de datos 
> (https://github.com/osmlab/atlas ) para 
> buscar algunos tipos de posibles problemas, como carreteras con ángulos 
> agudos, intersecciones de edificios y carreteras, y lugares donde la 
> clasificación de “highway_link” no coincide con la clasificación más alta de 
> las carreteras. Pongo los resultados de los retos en MapRoulette, un 
> herramienta que te permite pasar los problemas uno por uno y corregirlos o 
> marcar que no son un problema. Quería hacerles saber que estaban disponibles 
> en caso de que alguien quisiera intentar arreglarlos. Yo también arreglaré 
> algunos.
> 
> En MapRoulette escoges un problema random o haz clic en un problema 
> especifico. Si desea ver tareas en un lugar determinado, como en un lugar con 
> el que está familiarizado, puede hacer clic en "más opciones" y luego en 
> “load tasks by proximity” (cargar tareas por proximidad.)
> 
> Por favor, hágamelo saber si tiene alguna pregunta o comentario.
> 
> Los retos son:
> 
> Intersecciones de edificios y carreteras en Argentina: 
> https://maproulette.org/mr3/browse/challenges/3394/ 
> 
> Carreteras de ángulo agudo en Argentina: 
> https://maproulette.org/mr3/browse/challenges/3392/ 
> 
> Carreteras de enlaces en Argentina: 
> https://maproulette.org/mr3/browse/challenges/3393/ 
> 
> 
> Saludos,
> 
> Andrew
> 
> 
> Andrew Wiseman |  Maps | andrew_wise...@apple.com 
> 
> 
> ___
> Talk-ar mailing list
> Talk-ar@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-ar 
> 
> ___
> Talk-ar mailing list
> Talk-ar@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ar

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

Re: [Talk-de] Deutsche Zusammenfassungen der Wahlprogramme und Antworten

[Michael Reichert]

Hallo,

Am 10.12.18 um 23:46 schrieb Michael Reichert:
> ich habe im deutschen OSM-Blog am Sonntag eine deutschsprachige
> Zusammenfassung der Wahlprogramme der Kandidaten und ihrer Antworten auf
> den Fragenkatalog veröffentlicht. Zu beachten ist, dass nur fristgerecht
> eingegangene Einreichungen berücksichtigt worden sind.
> 
> https://blog.openstreetmap.de/blog/2018/12/wahlen-zum-vorstand-der-openstreetmap-foundation-2018-die-wahlprogramme-und-der-fragenkatalog/
> 
> Eine knappere Fassung, die die Kandidaten im Kontext ihres bisherigen
> Wirkens und der OSM(F)-Politik betrachten wird, ist gerade noch in Arbeit.

Diese habe ich soeben veröffentlicht. Redaktionsschluss ist vor etwa
zwei bis drei Tagen gewesen, sodass die neusten Entwicklungen zur
Krim-Frage und dem Umgang mit der On-the-Ground-Regel nicht
berücksichtigt worden sind.

https://blog.openstreetmap.de/blog/2018/12/wahlen-zum-vorstand-der-openstreetmap-foundation-2018-einordnung-der-kandidaten/

Wer eine Wahlempfehlung sucht, wird nicht fündig werden, kann aber
direkt zur Überschrift "Tobias Knerr" springen, ab da wird es spannend.

Viele Grüße

Michael

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Talk-it] Your experience with Wikimedia Italia being a local OSMF chapter

[Maurizio Napolitano]

Hi Micheal
to what was said in the other answers I add some considerations:
- if the supporters of OpenStreetMap decide to be recognized by the
Wikimedia chapter, then they must also be active inside the chapter,
otherwise the results will be poor
- the Wikimedia chapters are very focused on the Wikimedia Foundation
products (wikipedia, wikidata, commons ...) so the energies should be
divided into measures proportional to the various objectives (and OSM
must be one of these)
- it is very difficult to focus activities effectively if you do not
have the support of an active community
- it is very important to create actions of dissemination and
contamination among the members so as to know all the products that
the association promotes

I was one of the promoters of the approach of the Italian OSM
community in Wikimedia Italia.
The association has always shown itself to support the initiative.
However, I think it is crucial that openstreetmap activists feel they
are an integral part of the association in order to achieve tangible
results.

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

Re: [Talk-it] Your experience with Wikimedia Italia being a local OSMF chapter

[Marco Minghini]

Hi Michał,
just some additional information.

WMI organized the 2017 State of The Map conference in Milan.
>

Clearly it was 2018 :)
At the time of the conference I was working at Politecnico di Milano (that
co-organized and hosted the conference) and I can say that this was a
successful joint result, achieved after an already stable collaboration we
had with Wikimedia Italia. Among others, we organized mapping events and
also wrote research projects together - and Wikimedia Italia is doing this
kind of OSM-related work also with other research institutions in Italy.

In addition, since 2017 Wikimedia Italia has partnered with GFOSS.it and
ArcheoFOSS in the organization of FOSS4G-IT, the annual conference that
merges together the previous "geospatial" conferences of the 3
associations, including OSMit. After two editions (Genova
 and Rome
) we can say that this model works, since
it brings together communities with (partially) different roots but with a
lot to share. Next edition  will be in
Padova in February and the high number of submissions received is again a
clear measure of the interest.

In additions, I joined the last itWikiCon conference
 and there was an
explicit request by Wikimedia to the OSM community to represent OSM at the
event by submitting talk and proposals :)


> While at the beginning we discussed about level of independence between
> the two "area of interest", by the end of the day both Wiki* and OSM are
> well interconnected and it's quite common to mix the topics when presenting
> the projects to the wide audience.
>

Definitely!

>
> IMHO, having been one of the original proposer of WMI as OSM Chapter, the
> coexistence is natural and as far as there isn't attrition between the
> groups, will be a successfull integration in Poland as well.
>
> Regarding the other questions you are asking, I'm hopeful that someone
from Wikimedia Italia can directly reply :)

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

[OSM-talk-fr] Après la carte en breton : voici les cartes en occitan et en basque

[Maël REBOUX]

OpenStreetMap e Brezhoneg


Après la carte en breton : voici les cartes en occitan et en basque

Depuis septembre 2017 une carte en langue bretonne utilisant les données de 
OpenStreetMap (la base de données géographique, mondiale, libre et 
contributive) est visible sur notre site www.openstreetmap.bzh 
.
Cette carte nous permet de valoriser notre langue, notre culture et de fédérer 
les diverses contributions autour d’un objet commun afin que le breton est 
toute sa place dans les outils numériques du XXIe siècle. En 2 ans et demi, les 
bretons ont multiplié par 2,5 le nombre d’objets portant un nom en breton dans 
OpenStreetMap. Nous venons de dépasser les 40 000 avec une belle progression :



Bravo à tous les contributeurs et merci au soutien de l’Office Publique de la 
Langue Bretonne .

Au printemps 2018 s’est déroulée Ar Redadeg , une 
course de relais sans interruption de 1 800 km dont le but est de récolter des 
fonds pour des projets éducatifs pour la langue bretonne. Notre partenariat 
avec Ar Redadeg a permis de dégoogliser leur site de vente de kilomètres tout 
en mettant en avant la carte, notre projet et OpenStreetMap dans son ensemble. 
Le partenariat vient d’être reconduit pour l’édition 2020.
En juin le State Of The Map France 2018  a 
été pour nous l’occasion de parler du projet et de notre démarche à la 
communauté. Les échanges avec la communauté dans son ensemble, les basques et 
les occitans ont été riches.


Depuis octobre 2018 le service de carte a été techniquement amélioré et 
stabilisé au point de le considérer “bon pour le service actif”… et pouvant 
accepter une reproductibilité.
C’est donc avec plaisir que nous vous annonçons la disponibilité des services 
de cartes de 2 langues minoritaires de France : l’occitan et le basque











Derrière les noms de lieu officiels, il y a les langues de la France, certaines 
plus anciennes que le français et toujours utilisées et enseignées. Par sa 
souplesse et son adaptabilité, l’écosystème OpenStreetMap permet de contribuer 
et de visualiser toutes les versions linguistiques. Voir donc une carte de 
Bretagne, d’Occitanie ou du Pays basque avec des mentions en langue originale 
est possible grâce au service de carte mis en place par OpenStreetMap e 
brezhoneg.
Les noms de lieu sont peu à peu ajoutés par les cartographes volontaires qui 
s’appuient sur les organismes de collecte et de normalisation (offices 
linguistiques, associations spécialisées).

Les url des services de tuiles (au format TMS) sont les suivants :
breton (br) : https://tile.openstreetmap.bzh/br/{z}/{x}/{y}.png
occitan (oc) : https://tile.openstreetmap.bzh/oc/{z}/{x}/{y}.png
basque (eu) : https://tile.openstreetmap.bzh/eu/{z}/{x}/{y}.png

Pour le moment nous ne disposons pas du même système de mise à jour des tuiles 
que pour le rendu FR. Les tuiles se mettent à jour entre 1 jour minimum et 7 
jours maximum. Une contribution se verra donc sur la carte entre 1 et 7 jours.

OpenStreetMap e Brezhoneg dispose d’une application cartographique pour 
exploiter le service de tuiles en breton. Elle est visible à cette adresse : 
https://kartenn.openstreetmap.bzh  Nous 
nous tenons à la disposition des différents organismes travaillant sur les 
langues régionales pour les aider à mettre en place des applications 
cartographiques similaires.

Afin de disposer d’outils à minima pour aider à suivre la saisie dans 
OpenStreetMap, nous avons mis en place 2 dispositifs.

Le premier consiste en une couche de “contrôle” de la présence des tags 
spécifique de langue sur les objets portant une toponymie (voie et lieux-dits). 
C’est simple : en vert c’est ok en rouge : au boulot ! Cela permet visuellement 
de motiver des contributeurs et de voir où sont les manques.



Les url des services de tuiles de contrôle (au format TMS) sont les suivants :
breton (br) : https://tile.openstreetmap.bzh/br_control/{z}/{x}/{y}.png
occitan (oc) : https://tile.openstreetmap.bzh/oc_control/{z}/{x}/{y}.png
basque (eu) : https://tile.openstreetmap.bzh/eu_control/{z}/{x}/{y}.png

Le deuxième est un suivi statistique de la présence des tags dans 16 langues 
minoritaires 

 sur les objets dans OpenStreetMap.

Concrètement : un fichier CSV est mis à jour tous les 2 de chaque mois :
https://github.com/osm-bzh/osm-bzh-data/blob/master/stats/stats_locale_names.csv
 

 

Extrait des statistiques des saisies au 2 décembre 2018 :
Breton  41 324
Basque  23 400
Occitan 11 826 (avec 2 000 saisies en novembre !)


Merci à OpenStreetMap France pour son accueil et son soutien technique. Tout 
cela est possible par la mise à disposition d’un serveur dédié à ce projet. 

Re: [Talk-it] utilizzo di noexit=yes

[Sergio Manzi]

... manata in fronte! Ovvio, hai ragione!

Ma certo che bisogna essere un po' perversi, però...   :-)


On 2018-12-13 21:22, Andrea Albani wrote:
>
>
> Il giorno gio 13 dic 2018 alle ore 20:46 Sergio Manzi  > ha scritto:
>
>
> Inoltre non riesco a capire perché a qualcuno sia venuto in mente di 
> ragionare in logica negata: noexit=yes === exit=no, che mi sembrerebbe di più 
> chiara ed immediata comprensione (/ma comunque inutile/).
>
> Penso derivi dal fatto che in inglese un cartello di strada chiusa è un "no 
> exit" sign
>  
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it


smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] utilizzo di noexit=yes

[Andrea Albani]

Il giorno gio 13 dic 2018 alle ore 20:46 Sergio Manzi  ha
scritto:

>
> Inoltre non riesco a capire perché a qualcuno sia venuto in mente di
> ragionare in logica negata: noexit=yes === exit=no, che mi sembrerebbe di
> più chiara ed immediata comprensione (*ma comunque inutile*).
>
Penso derivi dal fatto che in inglese un cartello di strada chiusa è un "no
exit" sign
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] utilizzo di noexit=yes

[Andrea Albani]

Il giorno gio 13 dic 2018 alle ore 16:59 Max1234Ita 
ha scritto:

>
> Non è solo mappare per il rendering, è anche un'informazione utile che dai
> anche all'utente ed al routing, ad esempio nel caso in cui la strada
> termina
> ma a poca distanza ce n'è un'altra percorribile, ad esempio una via che è
> tagliata alla fine da un fosso ma oltre il fosso corre la Strada
> Provinciale: poco importa se con un salto un pedone un po' agile può
> riuscire a passare dall'altra parte...
>

Sull'utilità per l'utente potremmo essere d'accordo fermo restando che
bisognerebbe trovare una mappa che si fila questo tag (Transport Karte per
Garmin ?)

Da un motore di routing mi aspetterei però che non mi faccia saltare da una
strada ad un'altra che non risultano connesse oppure che risultano "poco"
distanti.
Ti fideresti del percorso calcolato da un engine che non valuta in modo
rigoroso i dati cartografici ?
Comunque se vale questo principio la presenza o meno di noexit è
ininfluente.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] utilizzo di noexit=yes

[Sergio Manzi]

Ciao a tutti/e,

Sinceramente noexit=yes mi sembra un tagging assurdo: la topologia non è 
un'opinione e se una strada abbia o meno una uscita (/e per quali mezzi di 
trasporto!/) lo si desume tranquillamente dalle relazioni con le altre ways.

Inoltre non riesco a capire perché a qualcuno sia venuto in mente di ragionare 
in logica negata: noexit=yes === exit=no, che mi sembrerebbe di più chiara ed 
immediata comprensione (/ma comunque inutile/).

Per quanto riguarda sentieri/piste a tratti invisibili, sono totalmente 
d'accordo con Volker: vanno mappati ed indicati con trail_visibility=no, perché 
in caso contrario si interromperebbe un utilissimo e validissimo "routing" 
(/sia che sia automatizzato o "ad occhio"/).

Sergio


On 2018-12-13 16:59, Max1234Ita wrote:
> Andrea Albani wrote
>> noexit è un tag che, pur avendolo usato qualche volta, mi ha sempe
>> lasciato
>> freddo e per me non è così scontato che si debba per forza mettere quando
>> una strada termina.
>>
>> E' un dato di fatto che una strada finisce sull'ultimo nodo non connesso
>> della way che la rappresenta, e questo i motori di routing immagino lo
>> sappiano bene.
>>
>> Ci rimane il fattore rendering, ovvero comunicare visivamente ad un utente
>> questo dead-end. Quindi nel caso di questo tag posso mappare per il
>> rendering ?
> Non è solo mappare per il rendering, è anche un'informazione utile che dai
> anche all'utente ed al routing, ad esempio nel caso in cui la strada termina
> ma a poca distanza ce n'è un'altra percorribile, ad esempio una via che è
> tagliata alla fine da un fosso ma oltre il fosso corre la Strada
> Provinciale: poco importa se con un salto un pedone un po' agile può
> riuscire a passare dall'altra parte...
> In questo caso noexit indica espressamente che non c'è via d'uscita e non si
> tratta di un problema di scarsa/nulla mappatura...
>
> Per i casi "liquidi", invece, di solito preferisco tracciare il sentiero fin
> dove lo si può vedere, e po lasciarlo aperto, a finire "nel nulla"... come
> in effetti è.
>
> Ciao,
> Max
>
>
>
>
> --
> 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


smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-us] Whole-US Garmin Map update - 2018-12-11

[Dave Hansen]

These are based off of Lambertus's work here:

http://garmin.openstreetmap.nl

If you have questions or comments about these maps, please feel
free to ask.  However, please do not send me private mail.  The
odds are, someone else will have the same questions, and by
asking on the talk-us@ list, others can benefit.

Downloads:

http://daveh.dev.openstreetmap.org/garmin/Lambertus/2018-12-11

Map to visualize what each file contains:


http://daveh.dev.openstreetmap.org/garmin/Lambertus/2018-12-11/kml/kml.html


FAQ



Why did you do this?

I wrote scripts to joined them myself to lessen the impact
of doing a large join on Lambertus's server.  I've also
cut them in large longitude swaths that should fit conveniently
on removable media.  

http://daveh.dev.openstreetmap.org/garmin/Lambertus/2018-12-11

Can or should I seed the torrents?

Yes!!  If you use the .torrent files, please seed.  That web
server is in the UK, and it helps to have some peers on this
side of the Atlantic.

Why is my map missing small rectangular areas?

There have been some missing tiles from Lambertus's map (the
red rectangles),  I don't see any at the moment, so you may
want to update if you had issues with the last set.

Why can I not copy the large files to my new SD card?

If you buy a new card (especially SDHC), some are FAT16 from
the factory.  I had to reformat it to let me create a >2GB
file.

Does your map cover Mexico/Canada?

Yes!!  I have, for the purposes of this map, annexed Ontario
in to the USA.  Some areas of North America that are close
to the US also just happen to get pulled in to these maps.
This might not happen forever, and if you would like your
non-US area to get included, let me know. 

-- Dave


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

Re: [Talk-it] Parchimetri a Perugia

[Sergio Manzi]

Ciao!

Direi che usare nuove chiavi come parcometro=* e settore=* è _senza dubbio_ da 
evitare: sarebbe preferibile fossero approvate dalla comunità, dopo adeguata 
proposta e votazione e devono essere in Inglese Britannico.

network=* mi sembra dedicato ad altri scopi [1]

Mi sembra bene il ref=10-135

Sergio


[1] https://wiki.openstreetmap.org/wiki/Key:network

On 2018-12-13 17:27, claudio62PG wrote:
> Varie proposte
>
> Parcometro=135
> amenity=vending_machine
> settore=10
> vending=parking_tickets
>
>
> amenity=vending_machine
> vending=parking_tickets
> ref=10-135
>
>
> amenity=vending_machine
> vending=parking_tickets
> ref=135
> network=10
>
>
> Opinioni ?
> ciao 
> Claudio
>
>
>
> --
> 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


smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-it] Caricamento JOSM in ambiente MAc

[francocalistri]

Buonasera a tutti

scusate ma sono un neofita. Dopo aver usato JOSM su un portatile in ambiente 
Windows sto provando a caricarlo sul fisso che un Mac non molto giovane è un 
OSX Lion 10.7.5. Quando avvio JOSM in fase di caricamento del programma JOSm 
alla stringa "caricamento preferenze immagini aeree " si blocca ed il programma 
si chiude. 

Qualcuno che usa Mac ha idea di come risolvere il problema.

Grazie

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

[Talk-it-trentino] Una strada verso l'assessorato...?

[Alessandro Vitali]

Ciao ragazzi!
E' da un po' che non scrivo ma sono stato preso dal lavoro.

In questi poco più di due anni di lavoro mi sono inserito bene nel sistema
118 trentino ed ho iniziato a portare la discussione cartografia a livelli
un po' più alti. Parlando con la mia "responsabile del personale no
dirigenziale U.O. Trentino Emergenza 118" Roberta Levato, si è ipotizzata
la possibilità di inviare una lettera al nuovo assessore di competenza.
L'obbiettivo sarebbe quello di informarlo sulle difficoltà che il sistema
di emergenza deve affrontare ogni giorno a causa di una cartografia obsoleta,
incompleta ed insufficiente... ovviamente con "tatto" politichese.
A questo poi si apre un mondo di possibilità...
- si potrebbe introdurre lo strumento OSM prendendo come riferimento
l'esperienza emiliana di condivisione dei numeri civici
- si potrebbe fare richieste di modifiche normative per favorire gli open
data cartografici
- ecc...

Ora, io sono e rimango un novizio in merito, però se voi (e Napo!)
valutaste la cosa e mi deste una mano per redigere una relazione utile allo
scopo ne sarei ben felice!!
Potremmo dividerci gli argomenti da redigere... tipo:
- OSM
- Segnalazioni di Rischio Clinico pervenute per il sistema 118 in merito
alle difficoltà di raggiungere il target
- Database idranti
- Competenza della gestione dei civici in trentino
- Open data (esempio emiliano)
- ecc...

Se ritenete che sia meglio potrei condividere questa richiesta anche su
talk-it IT.

Grazie!!!
...a giusto... buone feste!!

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

Re: [Talk-cz] Znaceni uzavirek vs offline navigace

[majka]

Na mobilech: neumí to ani OsmAnd.
On Thu, 13 Dec 2018 at 18:02, Jozef Matejička  wrote:

> Brouter nepodporuje conditional routing. Takže neexistuje ani stránka.
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-it] Parchimetri a Perugia

[Cascafico Giovanni]

Direi che la 10-135 sia più semplice e lo identifica univocamente.

Il gio 13 dic 2018, 17:27 claudio62PG  ha scritto:

> Varie proposte
>
> Parcometro=135
> amenity=vending_machine
> settore=10
> vending=parking_tickets
>
>
> amenity=vending_machine
> vending=parking_tickets
> ref=10-135
>
>
> amenity=vending_machine
> vending=parking_tickets
> ref=135
> network=10
>
>
> Opinioni ?
> ciao
> Claudio
>
>
>
> --
> 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
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-cz] Znaceni uzavirek vs offline navigace

[Jozef Matejička]

Brouter nepodporuje conditional routing. Takže neexistuje ani stránka.

Dne čt 13. 12. 2018 17:29 uživatel mahdi1234  napsal:

> Pro doplneni reakce od ME vyvojaru:
>
> -
>
> It seems that there was a tagging problem with the first example that you
> shared with us, but someone made changes on the OpenStreetMap website one
> day ago. We will check this particular case with the next map set and make
> sure that everything works as expected.
>
> As for the routing engine that we are using in Magic Earth, we developed
> the code ourselves, so we do not use either of the two routing engines that
> you mentioned, we use our own routing algorithm.
>
> -
>
> Takze uvidis, no. Zkousel sem to v Budapesti
> https://www.openstreetmap.org/directions?engine=graphhopper_car=47.52098%2C19.03688%3B47.51688%2C19.03662#map=17/47.51873/19.03773
> pro https://www.openstreetmap.org/way/424538540 ktera ma
>
> oneway:conditional yes @ (06:00-20:00)
>
> ale ani ME, ani GraphHopper ani OSRM ani brouter po 20h neprehodi
> routovani.
>
> Nevite nekdo o strance, kde se da otestovat bez ohledu na denni/rocni dobu
> tzn zadat, kdy chcu routovat, pro overeni techto veci?
>
> mahdi
>
>
> majka wrote on 12/11/2018 05:48 PM:
>
> Ne, tahle je to špatně. V iD je třeba "sjet" až do části "Všechny
> vlastnosti" a upravit to tam, tedy ručně vepsat. Pro jistotu jsem to
> zkontrolovala v JOSM, ale naprosto stejně jsem to zadala do iD.
>
> Mimochodem, je tam blbě o kousek dál ten průjezd Benzinou. Ta cesta skrz
> namá být indoor, opravím to také.
>
> On Tue, 11 Dec 2018 at 17:18, marek  wrote:
>
>> Tak jsem to upravil, je to správně?  conditional = yes @  forward  ( nov
>> - mar )
>>
>>
>>
>> Marek Polák
>>
>>
>>
>> __
>> > Od: "mahdi1234" 
>> > Komu: "OpenStreetMap Czech Republic" 
>> > Datum: 10.12.2018 16:24
>> > Předmět: Re: [Talk-cz] Znaceni uzavirek vs offline navigace
>> >
>> mahdi1234 wrote on 12/09/2018 10:21 PM:
>>
>> marek wrote on 12/09/2018 07:37 PM:
>>
>> Já to píšu proto, že asi před rokem jsem sem dával omezení a magic Earth
>> s ním zatím nepracuje, pokud to mám dobře.
>> https://www.openstreetmap.org/way/653782922
>>
>>
>>
>> Marek Polák
>>
>>
>>
>> Jeste k te jednosmerce, vypada, ze nemas tag podle spec viz
>> https://wiki.openstreetmap.org/wiki/Conditional_restrictions kde je
>> pouzit oneway :
>> conditional =yes @
>> Su
>>
>> Podle tag info je pouzit jen 4x jak mas ty -
>> https://taginfo.openstreetmap.org/keys/?key=oneway#values ... podle te
>> wiki stranky to je pouzito 975x
>> https://taginfo.openstreetmap.org/keys/?key=oneway:conditional
>>
>>
>> --
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>> https://openstreetmap.cz/talkcz
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>> https://openstreetmap.cz/talkcz
>>
>
>
> ___
> Talk-cz mailing 
> listTalk-cz@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-czhttps://openstreetmap.cz/talkcz
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-cz] Znaceni uzavirek vs offline navigace

[mahdi1234]

Pro doplneni reakce od ME vyvojaru:

-

It seems that there was a tagging problem with the first example that
you shared with us, but someone made changes on the OpenStreetMap
website one day ago. We will check this particular case with the next
map set and make sure that everything works as expected.

As for the routing engine that we are using in Magic Earth, we developed
the code ourselves, so we do not use either of the two routing engines
that you mentioned, we use our own routing algorithm.

-

Takze uvidis, no. Zkousel sem to v Budapesti
https://www.openstreetmap.org/directions?engine=graphhopper_car=47.52098%2C19.03688%3B47.51688%2C19.03662#map=17/47.51873/19.03773
pro https://www.openstreetmap.org/way/424538540 ktera ma

oneway:conditional     yes @ (06:00-20:00)

ale ani ME, ani GraphHopper ani OSRM ani brouter po 20h neprehodi routovani.

Nevite nekdo o strance, kde se da otestovat bez ohledu na denni/rocni
dobu tzn zadat, kdy chcu routovat, pro overeni techto veci?

mahdi

majka wrote on 12/11/2018 05:48 PM:
> Ne, tahle je to špatně. V iD je třeba "sjet" až do části "Všechny
> vlastnosti" a upravit to tam, tedy ručně vepsat. Pro jistotu jsem to
> zkontrolovala v JOSM, ale naprosto stejně jsem to zadala do iD.
>
> Mimochodem, je tam blbě o kousek dál ten průjezd Benzinou. Ta cesta
> skrz namá být indoor, opravím to také.
>
> On Tue, 11 Dec 2018 at 17:18, marek  > wrote:
>
> Tak jsem to upravil, je to správně?  conditional = yes @  forward 
> ( nov - mar )
>
>  
>
> Marek Polák
>
>  
>
> __
> > Od: "mahdi1234" mailto:mahdi1...@centrum.cz>>
> > Komu: "OpenStreetMap Czech Republic"  >
> > Datum: 10.12.2018 16:24
> > Předmět: Re: [Talk-cz] Znaceni uzavirek vs offline navigace
> >
>
> mahdi1234 wrote on 12/09/2018 10:21 PM:
>
> marek wrote on 12/09/2018 07:37 PM:
>
> Já to píšu proto, že asi před rokem jsem sem dával omezení
> a magic Earth s ním zatím nepracuje, pokud to mám dobře.
> https://www.openstreetmap.org/way/653782922
>
>  
>
> Marek Polák
>
>  
>
> Jeste k te jednosmerce, vypada, ze nemas tag podle spec viz
> https://wiki.openstreetmap.org/wiki/Conditional_restrictions kde
> je pouzit oneway
> :conditional
> =yes @ Su
>
> Podle tag info je pouzit jen 4x jak mas ty -
> https://taginfo.openstreetmap.org/keys/?key=oneway#values ...
> podle te wiki stranky to je pouzito 975x
> https://taginfo.openstreetmap.org/keys/?key=oneway:conditional
>
>
> --
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz

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

Re: [Talk-it] Parchimetri a Perugia

[claudio62PG]

Varie proposte

Parcometro=135
amenity=vending_machine
settore=10
vending=parking_tickets


amenity=vending_machine
vending=parking_tickets
ref=10-135


amenity=vending_machine
vending=parking_tickets
ref=135
network=10


Opinioni ?
ciao 
Claudio



--
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: [OSM-talk-fr] Gmaps strikes again...

[Cédric Frayssinet]

Le 13/12/2018 à 15:18, Pierre Jarnet a écrit :
> Le 13/12/2018 à 11:19, Jacques Lavignotte a écrit :
>> Euh,
>>
>> http://www.zones-activites.net/plan-1386-Zone-d-activites-de-Beaubaton.html
>>
>> Non, rien.
> And again
>
> https://passeport.ants.gouv.fr/Services-associes/Ou-faire-ma-demande-de-passeport-CNI?displayMap=1%5Blati%5D=48.021%5Blong%5D=-3.2606631299735%5Bzoom%5D=9
>

Je pense que la liste est longue comme le bras :( , je préfère à présent
relever ceux qui ont fait un switch réussi, comme la mairie de
Villeurbanne :

https://villeurbanne.plan-interactif.com/fr/

Cédric




-- 
Dégooglisé !  - Sociétaire Enercoop
, l'énergie militante

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

Promouvoir et soutenir le logiciel libre 

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

Re: [OSM-talk-fr] Opencyclemap : absence des relations network= icn

[Richard Fairhurst]

Mathias Vadot a écrit:
> Après plusieurs test, je me rends compte que le fond de carte 
> OCM n’affiche pas les itinéraires internationaux, relations 
> taguées de cette manière : network = icn. 

https://cycle.travel/map

:)

Richard



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

Wochennotiz Nr. 437 27.11.2018–03.12.2018

[Wochennotizteam]

Hallo,

die Wochennotiz Nr. 437 mit vielen wichtigen Neuigkeiten aus der 
OpenStreetMap-Welt ist da:

http://blog.openstreetmap.de/blog/2018/12/wochennotiz-nr-437/

Viel Spaß beim Lesen!
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-it] utilizzo di noexit=yes

[Max1234Ita]

Andrea Albani wrote
> noexit è un tag che, pur avendolo usato qualche volta, mi ha sempe
> lasciato
> freddo e per me non è così scontato che si debba per forza mettere quando
> una strada termina.
> 
> E' un dato di fatto che una strada finisce sull'ultimo nodo non connesso
> della way che la rappresenta, e questo i motori di routing immagino lo
> sappiano bene.
> 
> Ci rimane il fattore rendering, ovvero comunicare visivamente ad un utente
> questo dead-end. Quindi nel caso di questo tag posso mappare per il
> rendering ?

Non è solo mappare per il rendering, è anche un'informazione utile che dai
anche all'utente ed al routing, ad esempio nel caso in cui la strada termina
ma a poca distanza ce n'è un'altra percorribile, ad esempio una via che è
tagliata alla fine da un fosso ma oltre il fosso corre la Strada
Provinciale: poco importa se con un salto un pedone un po' agile può
riuscire a passare dall'altra parte...
In questo caso noexit indica espressamente che non c'è via d'uscita e non si
tratta di un problema di scarsa/nulla mappatura...

Per i casi "liquidi", invece, di solito preferisco tracciare il sentiero fin
dove lo si può vedere, e po lasciarlo aperto, a finire "nel nulla"... come
in effetti è.

Ciao,
Max




--
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: [OSM-talk-fr] Opencyclemap : absence des relations network= icn

[Phyks]

Bonjour,

Je ne saurais répondre particulièrement sur la question des network = 
icn, mais OpenCycleMap n'est pas libre (contrairement à ce que son nom 
pourrait laisser penser). Ce n'est donc pas possible de contribuer. En 
revanche, il y a un suivi de tickets ici 
https://trac.openstreetmap.org/query?component=opencyclemap. L'autre 
solution est de contacter directement l'auteur par 
http://thunderforest.com/contact/.


En rapport, il était question hier sur le canal IRC osm-fr d'essayer 
d'avoir un vrai rendu cyclable collaboratif et libre. OpenCycleMap a un 
certain nombre de problèmes/limitations, dont certains qui ne seront 
peut être jamais corrigés (comme ça, je vois notamment la question des 
parkings partagés motos / vélos qui sont ignorés ou l'absence de rendu 
de zone pour les zones commerciales, qui offrent souvent des points 
d'eau / toilettes même s'ils ne sont pas explicitement renseignés dans 
OSM). Plusieurs personnes étaient intéressées, je profite de ce message 
pour relayer l'info, si d'autres personnes pourraient également être 
intéressées / vouloir participer.


Bonne journée,
--
Phyks

Le 2018-12-13 16:21, Mathias Vadot a écrit :

Bonjour à tous,

Après plusieurs test, je me rends compte que le fond de carte OCM
n’affiche pas les itinéraires internationaux, relations taguées de
cette manière : network = icn. [1] Je m’en suis rendu compte pour
les relations que je connais en France [2], mais c’est finalement un
problème globale. Les relations bien visibles en rouge [3] sont
tagué comme étant des relations nationale, network = ncn [4].

Dans la légende [5], les icn n’ont en effet pas l’air d’avoir
leurs places, ce qui parait aberrant.  Est-ce un problème qui a
déjà été relevé ? Je n’ai pas trouvé le github de ce projet.

Mathias

 [6]
Garanti sans virus. www.avast.com [6]



Links:
--
[1] https://wiki.openstreetmap.org/wiki/Tag:network%3Dicn
[2]
https://www.openstreetmap.org/relation/5448020#map=15/50.2451/4.0115layers=C
[3]
https://www.openstreetmap.org/relation/5445857#map=9/49.4360/-1.0547layers=C
[4] https://wiki.openstreetmap.org/wiki/Tag:network%3Dncn
[5] http://www.opencyclemap.org/docs/
[6]
https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


--
Phyks

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

Re: [Talk-it] Parchimetri a Perugia

[claudio62PG]

quindi sarò il primo che mappa i settori? 
ciao
Claudio



--
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: [OSM-talk] [HOT] Quality (was: The point on the OSM Response to the DR Congo Nord Kivu Ebola outbreak)

[Pierre Béland]

Yes, Quality should be be integrated at all levels, from Documentation, Editing 
tools, Projects monitoring particularly in the context of Mapathons to catch 
problems rapidly and correct. And  yes validation is the last step, the last 
barrier to catch Quality problems and correct. 

After the experience with Mapathons in the last few years, we are surely at 
this point where we need to revise our global process and suggest where 
improvements would contribute to this Quality Quest.
Bjoern, in a HOT discussion about the Ebola Response  in Butembo, gave us a 
link to some Documentation used in the context of Mapathons.  It is  important 
to propose such documentation specific to 
Mapathons.https://lists.openstreetmap.org/pipermail/hot/2018-December/014667.html
Documentation easily accessible in iD with the ? shortcut is also a good point. 
Such easy access to documentatin should be part of the various OSM editors. But 
it should also focus on specific skills like Trace a building, Correct 
irregular geometry, Adjust the offset of imagery, Classify roads. Links to 
short videos would also greatly help the beginners.
There are projects more complex with aspects such as the density of urban 
areas, imagery quality and offset and it is important to restrict access based 
on OSM experience for more complex projects and this is now possible for the 
various Tasking Manager projects. Taking this step for the Butembo Ebola 
response this week dramatically improved the quality of the data produced. But 
still, I often observed that some occasionnal contributors to Mapathons 
continue to produce some Fantasy buildings more then a year after they started 
editing.
This is indication of how it is important not only to provide good 
documentation and tools to beginners, to restrict more complex jobs, but also 
to better accompany and motivate the OSM beginners. Let's be a community. Let's 
go back to our roots! We should stop to have thousand of one day contributors 
that produce inadequate data that often is not corrected afterward.

Irregular geometries in the OSM database are probably more then 90% of the time 
an indication of incorrect mapping. Highlighting Irregular geometries and 
overlaps in editors such as iD and JOSM would faciliate revision by beginners.  
It could be integrated in the JOSM validation process.  iD could also have such 
a validation process.   

Monitoring of Quality and OSM edits need tools to quickly identify such 
problems. The Overpass and JOSM could provide the possibility to query for 
irregular geometries and overlaps.  Such addition in Overpass would offer to 
the Mapathons the possibility to visually monitor Quality of editing with the 
participants using for example a list of OSM user id's.  This could also be 
used for edition in JOSM.  And imagine the Mapathon participants that view the 
progress on a «Live Quality Map» plus «Quality statistics». This would be both 
motivating and pedagogic.

There were some regression with the Tasking Manager updates for the possibility 
to monitor the users. For example, the Activity and Stats section do not let 
see on the map the squares mapped by a particular contributor. It is then 
uneasy to revise the edits of a specific contributor that do not map 
appropriately. On the other hand, it is now possible to restrict the access to 
Validation.
.
 
regard
 
Pierre 
  ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-it] utilizzo di noexit=yes

[Andrea Musuruane]

On Thu, Dec 13, 2018 at 3:38 PM Andrea Musuruane  wrote:

>
>
> On Thu, Dec 13, 2018 at 3:32 PM Andrea Albani  wrote:
>
>> Il giorno gio 13 dic 2018 alle ore 10:47 demon_box <
>> e.rossini7...@gmail.com> ha scritto:
>>
>>> ciao, finchè si utilizza il tag noexit=yes, diciamo in ambito urbano
>>> sicuramente problemi non ce ne sono.
>>>
>>> esempio semplice semplice:
>>>
>>> strada asfaltata che poi finisce, se non c'è modo di proseguire nemmeno a
>>> piedi utilizzo noexit=yes e sono a posto.
>>>
>>>
>> noexit è un tag che, pur avendolo usato qualche volta, mi ha sempe
>> lasciato freddo e per me non è così scontato che si debba per forza mettere
>> quando una strada termina.
>>
>> E' un dato di fatto che una strada finisce sull'ultimo nodo non connesso
>> della way che la rappresenta, e questo i motori di routing immagino lo
>> sappiano bene.
>>
>> Ci rimane il fattore rendering, ovvero comunicare visivamente ad un
>> utente questo dead-end. Quindi nel caso di questo tag posso mappare per il
>> rendering ?
>>
>
> Mah... io ho sempre usato noexit=yes solo per indicare strade che sono
> senza uscita ma in prossimità di altre. Per il resto credo che sia inutile.
> I software di navigazione riescono a capire se la strada è senza uscita
> senza aver bisogno di questo tag.
>

BTW, la wiki è sempre amica:
https://wiki.openstreetmap.org/wiki/Key:noexit

"This tag should not be used when the way is only a dead-end for one
transport mode, but where other modes can continue"

Ciao,

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

Re: [Talk-it] utilizzo di noexit=yes

[Martin Koppenhoefer]

anch’io non uso questo tag, ma ricordo da discussioni precedenti che dovrebbe 
indicare la situazione per macchine (è stato inventato perché ci sono cartelli 
di questo contenuto, probabilmente non pensando che nel nostro contesto è quasi 
superfluo perché mappiamo l’intera rete, e quindi sappiamo tutti i percorsi 
senza uscita, quelli con il tag e quelli senza).
Per esempio quando c’è il cartello ma a piedi si continua, il tag “va messo” lo 
stesso.

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

[OSM-talk-fr] Opencyclemap : absence des relations network= icn

[Mathias Vadot]

Bonjour à tous,

Après plusieurs test, je me rends compte que le fond de carte OCM 
n’affiche pas les itinéraires internationaux, relations taguées de cette 
manière : network = icn. 
 Je m’en suis 
rendu compte pour les relations que je connais en France 
, 
mais c’est finalement un problème globale. Les relations bien visibles 
en rouge 
 
sont tagué comme étant des relations nationale,network = ncn 
.


Dans la légende , les icn n’ont en 
effet pas l’air d’avoir leurs places, ce qui parait aberrant. Est-ce un 
problème qui a déjà été relevé ? Je n’ai pas trouvé le github de ce projet.


Mathias



---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-cz] Bylo: WeeklyOSM CZ 437 - bazény

[Jan Macura]

Ahoj,

On Thu, 13 Dec 2018 at 14:23, majka  wrote:

> Inzerát:
> Nabízíme práci na několik příštích desetiletí. Cestování po celé ČR,
> náklady nejsou hrazené, odměna žádná. Pracovní náplň: Zkontrolovat "on the
> ground" stav a příslušně tomu změnit značení u malých bazénků. Zájemci se
> mohou hlásit na talk-cz@openstreetmap.org. Značka: dohoda jistá.
>

+1.

Jinak souhlasím s Daliborem. Je tu 90 % šance na porušení podmínek OSM pro
přispívání, což by se mělo řešit v prvé řadě.

H.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-it] utilizzo di noexit=yes

[Andrea Musuruane]

On Thu, Dec 13, 2018 at 3:32 PM Andrea Albani  wrote:

> Il giorno gio 13 dic 2018 alle ore 10:47 demon_box <
> e.rossini7...@gmail.com> ha scritto:
>
>> ciao, finchè si utilizza il tag noexit=yes, diciamo in ambito urbano
>> sicuramente problemi non ce ne sono.
>>
>> esempio semplice semplice:
>>
>> strada asfaltata che poi finisce, se non c'è modo di proseguire nemmeno a
>> piedi utilizzo noexit=yes e sono a posto.
>>
>>
> noexit è un tag che, pur avendolo usato qualche volta, mi ha sempe
> lasciato freddo e per me non è così scontato che si debba per forza mettere
> quando una strada termina.
>
> E' un dato di fatto che una strada finisce sull'ultimo nodo non connesso
> della way che la rappresenta, e questo i motori di routing immagino lo
> sappiano bene.
>
> Ci rimane il fattore rendering, ovvero comunicare visivamente ad un utente
> questo dead-end. Quindi nel caso di questo tag posso mappare per il
> rendering ?
>

Mah... io ho sempre usato noexit=yes solo per indicare strade che sono
senza uscita ma in prossimità di altre. Per il resto credo che sia inutile.
I software di navigazione riescono a capire se la strada è senza uscita
senza aver bisogno di questo tag.

Ciao,

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

Re: [Talk-it] utilizzo di noexit=yes

[Andrea Albani]

Il giorno gio 13 dic 2018 alle ore 10:47 demon_box 
ha scritto:

> ciao, finchè si utilizza il tag noexit=yes, diciamo in ambito urbano
> sicuramente problemi non ce ne sono.
>
> esempio semplice semplice:
>
> strada asfaltata che poi finisce, se non c'è modo di proseguire nemmeno a
> piedi utilizzo noexit=yes e sono a posto.
>
>
noexit è un tag che, pur avendolo usato qualche volta, mi ha sempe lasciato
freddo e per me non è così scontato che si debba per forza mettere quando
una strada termina.

E' un dato di fatto che una strada finisce sull'ultimo nodo non connesso
della way che la rappresenta, e questo i motori di routing immagino lo
sappiano bene.

Ci rimane il fattore rendering, ovvero comunicare visivamente ad un utente
questo dead-end. Quindi nel caso di questo tag posso mappare per il
rendering ?
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Gmaps strikes again...

[Pierre Jarnet]

Le 13/12/2018 à 11:19, Jacques Lavignotte a écrit :
> Euh,
> 
> http://www.zones-activites.net/plan-1386-Zone-d-activites-de-Beaubaton.html
> 
> Non, rien.

And again

https://passeport.ants.gouv.fr/Services-associes/Ou-faire-ma-demande-de-passeport-CNI?displayMap=1%5Blati%5D=48.021%5Blong%5D=-3.2606631299735%5Bzoom%5D=9



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

Re: [OSM-talk] [Osmf-talk] Candidate's views? Re: Board decision on Crimea complaint

[Martin Koppenhoefer]

sent from a phone

> On 13. Dec 2018, at 13:53, Andy Townsend  wrote:
> 
> Given that there will be effectively a "new board" after Saturday I think 
> that it's only fair to let them get their feet under the table first, but 
> there clearly will be pressure from the community once they have done that to 
> release the more comprehensive statement that was promised in 
> https://lists.openstreetmap.org/pipermail/talk/2018-December/081781.html .


given that the decision was taken by the current board it seems logical that 
the current board explains the reasoning behind it. What would the „new“ board 
know about it (ok, most of the new board will be the old board anyway).


Cheers, Martin 





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

Re: [Talk-hr] Renderiranje je zapelo?

[Ivan Delac]

hbogner napisa:
> I ja sam uočio probleme sa sporijim učitavanjem, te sam skužio da s 
> mreža zakucava na 100mega, prijavio sam to i limit na serveru je 
> promjenjen tako da se sad manje država spaja na njega, te je nakon toga 
> učitavanje sa 5 sekundi palo na ispod 1 sekunde.

Onda je najvjerojatnije do toga. Prije jedno mjesec dana je bilo
neizdrživo, sad je donekle prihvatljivo iako nije baš bajno. Povlači mi
tajlove ne brže od 1 Mbit/s. Upravo sada isprobavam i dosta varira brzina,
unutar 5 minuta jednom učita stranicu za 2 sekunde da bi za par minuta bilo
5 ili čak do 19 sekundi.

Evo taj HAR file, ali mislim da nije problem do mene jer samo Mapnik šteka.
Humanitarian i cycle map rade savršeno.
https://www.dropbox.com/s/ypvv50mirc8fj7i/har%20osm.zip?dl=0


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

Re: [Talk-cz] Bylo: WeeklyOSM CZ 437 - bazény

[Dalibor Jelínek]

Ahoj,

jestli jsem správně pochopil problém, tak hlavní je,

že to fell mapoval podle nelegálního zdroje.

U toho bych diskusi ukončil a prostě to smazal.

Bazény od ostatních bych asi nechal, jak jsou.

 

Dalibor

 

From: majka [mailto:majka.zem+t...@gmail.com] 
Sent: Thursday, December 13, 2018 2:23 PM
To: talk-cz@openstreetmap.org
Subject: Re: [Talk-cz] Bylo: WeeklyOSM CZ 437 - bazény

 

 

On Thu, 13 Dec 2018 at 11:46, Petr Vozdecký mailto:v...@seznam.cz> > wrote:


-- Původní e-mail --
Od: majka mailto:majka.zem%2bt...@gmail.com> >

Otázka je proč mu to zarazili - ne proto, že ty bazény neexistují (ať jsou 
jakékoliv), ale proto, že mapoval zcela zřejmě z nelegálních zdrojů. Tam je 
potřeba začít u jakýchkoliv úvah o zachování či nezachování dat. Pokud ta data 
jsou reálná (a byla-li by legální), pak spíše zachovat, ale příslušně otagovat.

Inzerát:

Nabízíme práci na několik příštích desetiletí. Cestování po celé ČR, náklady 
nejsou hrazené, odměna žádná. Pracovní náplň: Zkontrolovat "on the ground" stav 
a příslušně tomu změnit značení u malých bazénků. Zájemci se mohou hlásit na 
talk-cz@openstreetmap.org  . Značka: dohoda 
jistá.

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

[OSM-talk-fr] Formation Linux

[Tony Emery]

Bonjour à tous,

Notre collectivité cherche un organisme de formation dont voici les critères :

- objet de la formation : initiation à Linux, administration et configuration
système, tâches planifiées, (programme à détailler)
- Environnement actuel : Ubuntu Server 16.04 LTS
- Nombre de personnes à former : 3 (à mutualiser peut-être avec d'autres
collectivités)
- Lieu : Orange (Vaucluse) ou pas trop loin
- Obligation : le prestataire doit être reconnu organisme de formation

Si vous êtes intéressé ou si vous connaissez un organisme qui peut répondre à
ces critères, merci de diffuser largement cette demande et de me contacter à
t.em...@ccpro.fr

Merci à tous
Tony EMERY

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

Re: [Talk-cz] Bylo: WeeklyOSM CZ 437 - bazény

[majka]

On Thu, 13 Dec 2018 at 11:46, Petr Vozdecký  wrote:

>
> -- Původní e-mail --
> Od: majka 
>
> Otázka je proč mu to zarazili - ne proto, že ty bazény neexistují (ať jsou
> jakékoliv), ale proto, že mapoval zcela zřejmě z nelegálních zdrojů. Tam je
> potřeba začít u jakýchkoliv úvah o zachování či nezachování dat. Pokud ta
> data jsou reálná (a byla-li by legální), pak spíše zachovat, ale příslušně
> otagovat.
>
> Inzerát:
Nabízíme práci na několik příštích desetiletí. Cestování po celé ČR,
náklady nejsou hrazené, odměna žádná. Pracovní náplň: Zkontrolovat "on the
ground" stav a příslušně tomu změnit značení u malých bazénků. Zájemci se
mohou hlásit na talk-cz@openstreetmap.org. Značka: dohoda jistá.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-cz] Bylo: WeeklyOSM CZ 437 - bazény

[Jan Dudík]

Pokud to není fixní bazén, může příští rok stát o nějaký ten metr jinde. A
u bazénu bych předpokládal, že v zimě aspoň spadnu do prázdné jímky. COž u
přenosných bazénů nehrozí.

Zřejmě neznám ty správné lidi, protože vím jen o dvou z mých známých, co
mají na zahradě pevný bazén, a ten už má nějakých 20 m v obvodu. Zbylé
bazény se prostě na zimu uklidí.
A takové by se medle mapovat neměly - to je podobný případ jako se
stanovými tábory, ty se také nemapují.

JAnD
---

čt 13. 12. 2018 v 11:46 odesílatel Petr Vozdecký  napsal:

>
> -- Původní e-mail --
> Od: majka 
>
>
> On Thu, 13 Dec 2018 at 10:59, Miroslav Suchy  wrote:
>
> Tohle by se dalo rict o dost velkem poctu prvku v OSM. Z moji vlastni
> zkusenosti - pokud ma nekdo na zahrade bazen ktery
> je viditelny z orto-fota, tak tam je pristi rok znovu. A dost velka cast
> je fixni a je tam i pres zimu.
>
> Tohle je nesmysl. Bavíme se o malých bazénech, a pokud se podívám, kde mi
> to ten dotaz našel, je tam až na výjimky jen ten fell3. Kam nepřišel (nebo
> kde ho včas zarazili), není nic takového.
>
>
> Otázka je proč mu to zarazili - ne proto, že ty bazény neexistují (ať jsou
> jakékoliv), ale proto, že mapoval zcela zřejmě z nelegálních zdrojů. Tam je
> potřeba začít u jakýchkoliv úvah o zachování či nezachování dat. Pokud ta
> data jsou reálná (a byla-li by legální), pak spíše zachovat, ale příslušně
> otagovat.
>
> Stejně mě zajímá, proč to dělá, nějaká motivace tam musí být, možná je to
> na nějakou komerční objednávku pro nějakou další analýzu - takovou práci s
> takovým konkrétním tématem bez zjevného širokého užitku a navzdory odporu
> komunity si přece normální člověk dát nemůže...
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-GB] OS Boundary-Line --- Sharing nodes

[ael]

On Thu, Dec 13, 2018 at 12:16:34PM -, Andy Robinson wrote:
> If you are using JOSM you can use the "Unglue Ways" from the Tools menu. This 
> will duplicate the nodes to make the two overlapping ways independent. Don't 
> know if this functionality is available in other editors.
 
I use josm and use the "Unglue ways" as my primary tool when encountering
these problems. But, as I said originally, it is still a huge pain :-)

I hit this sort of thing when updating rivers and streams which are
usually very poorly mapped. I find a boundary running along the
waterway, with some external source tag. It is quite likely the the
boundary is defined as following the stream/river, but how do I know?
And how should I update the source tag on the boundary if I have moved
it? It is a great time sink and makes me think that there are better
things to do.

Another frequent problem is where hedges and fields share nodes with
roads. Again, something that is just plain wrong when one has reasonably
accurate survey data. And very painful to correct.

Likewise for wooded areas that others have mentioned. 

Maybe editors should by default never share nodes, and require explicit
actions surrounded with warnings, to allow coincident ways to share
nodes -  apart from the obvious exceptions like junctions ?

ael

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

Re: [OSM-talk] [Osmf-talk] Candidate's views? Re: Board decision on Crimea complaint

[Andy Townsend]

On 11/12/2018 13:45, Manfred A. Reiter wrote:


[...]

The decision of the DWG was absolutely correct according to the rules 
that OSM imposed on itself.


I think the board here is opening Pandora's box. It will certainly be 
interesting to see how all the controversial areas will be judged from 
now on.




Given that there will be effectively a "new board" after Saturday I 
think that it's only fair to let them get their feet under the table 
first, but there clearly will be pressure from the community once they 
have done that to release the more comprehensive statement that was 
promised in 
https://lists.openstreetmap.org/pipermail/talk/2018-December/081781.html .


Without knowing on what basis this board decision to create an exception 
to the OSM norm was reached it's difficult to generalise from it and 
understand how it might apply in other edge cases.


Best Regards,

Andy (a member of the DWG, but sending this in a personal capacity)


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

Re: [OSM-talk] [HOT] Quality (was: The point on the OSM Response to the DR Congo Nord Kivu Ebola outbreak)

[Nate Smith]

This is a good discussion. Chiming in here to share some additional
thoughts and work we’ve been doing on the Tasking Manager this fall.

I agree with what people have said. Quality isn’t just a “let’s improve how
we validate” problem. This also isn’t only an editor problem — through many
of the mapathons, the Tasking Manager is an entry point for new mappers and
can be a source of both the problems and the solution. It’s a
multi-factored problem and we're trying to work on the Tasking Manager side
to help out here. TM developers are definitely aware of the fact that many
new mapathon mappers start using an OSM editor through the TM and so there
is a chance to greatly support quality improvements here.

As Steve mentioned at the HOT Summit we started to dig into some of these
problems through a couple workshops.  Notes from the two workshop sessions
are here if anyone is interested:
  - Data quality improvements workshop:
https://github.com/hotosm/hot-summit-2018/wiki/Design-Workshop-:-Data-Quality-Validation-Improvements-with-TM-iD-Editor
  - AI & ML workshop:
https://github.com/hotosm/hot-summit-2018/wiki/Design-Workshop-:-AI-&-Machine-Learning---Integrating-into-HOT-Tools

As we’ve been working on Tasking Manager this fall and preparing for some
additional development this spring, we’ve been digging into a couple items
related to quality:

  1. Onboarding. Onboarding not only starts with good training at mapathons
but can happen in app as well. We’ve only just started to dig into many
ideas on ways that we can improve the training aspect of what people need
to know before they start mapping. Some notes from a recent design convo we
had:
https://github.com/hotosm/tasking-manager/wiki/Onboarding-Idea-Generation-Session-Notes

  2. New mapper mapping experience. In relation to onboarding and training,
the type of mapping or the way data is exposed to new mappers is vastly
different from a well-trained, experienced mapper. The Tasking Manager
workflow currently tries to meet both mapper needs in the middle - which
might be part of the problem at the moment. In January we’re going to be
taking a look at the entire experience to dig into where and how things
should change to improve on this front.

  3. Testing ML as a quality support tool. Machine learning outputs can be
a huge support here and that hasn’t been well tested. As we’ve been working
on the first part of the ML strategy HOT outlined this fall, giving
real-time feedback to a mapper will be extremely helpful in improving the
data quality:
https://www.hotosm.org/updates/integrating-machine-learning-into-the-tasking-manager/.
What the exactly looks like is yet to be determined, but we’re hoping to
have a prototype in January about how ML can be used to integrate a
complexity measure into a task grid square and ultimately can help set
mapping expectations.

Along with volunteering opportunities to work on technology projects with
HOT, we do have a job opening that will include working on the Tasking
Manager: https://www.hotosm.org/jobs/technical-project-manager/.



On Thu, Dec 13, 2018 at 7:50 AM Stephen Penson 
wrote:

> To build on Jean- Marc's point, one thing I raised at the HOT Summit and
> also recently to the London Missing Maps team is the need to tackle the
> errors at the source. Having validators is vital, but I believe we can
> improve the initial mapping through a few tweaks in the way new mappers are
> trained.
>
> Personally, what I believe would be really powerful is the creation of a
> way for new mappers to understand the importance of high quality mapping.
>
> For instance, if it were possible within ID Editor to not only highlight
> overlapping buildings but ALSO explain why overlapping buildings have an
> impact, then people would be able to relate and therefore change their
> behaviours.
>
> For example, the tool could highlight that overlapping buildings can
> result in inaccurate population density calculations which can have an
> impact on humanitarian response (see previous messages from Pierre
> Belland's HOT mailing list post on the DRC as a case study). If we can
> explain this to people in a compelling way, I believe the quality of the
> mapping would improve.
>
> If something could be built within the current tool set (e.g. embedded
> text/video within ID validation) this should hopefully ensure consistency.
>
> Combining such tweaks with real-time monitoring tools, such as Bjoern
> suggests, should improve quality at mapathons.
>
> Essentially, people attend Missing Maps mapathons to contribute to a
> worthy cause. People wish to map the best they can, so if more (and
> consistent) support is offered, the quality will improve.
>
> Thanks
>
> Steve
> --
> *From:* Jean-Marc Liotier 
> *Sent:* 12 December 2018 22:30
> *To:* talk@openstreetmap.org; h...@openstreetmap.org
> *Subject:* Re: [HOT] Quality (was: The point on the OSM Response to the
> DR Congo Nord Kivu Ebola outbreak)
>
> On 

Re: [Talk-ar] Retos de MapRoulette en Argentina

[Hernán Javier López]

Andrew! Muy buena la herramienta que estan usando. Estoy probando las
tareas de los caminos en angulo y encontré solo una marcada hasta ahora que
no vi el error, no se si por falta de avisar que fue solucionado o alguien
lo arreglo entre que lo detectaron y publicaron la tarea.
El único comentario para hacer, es si pudiesen programar que el comentario
del changeset sea algo mas que #maproulette que tenga un agregado de la
tarea especifica, en este caso, agregarle el mismo titulo
#maproulette Sharp Angle Roads / Carreteras de Ángulo Agudo en Argentina
Saludos
Hernan

El mié., 12 dic. 2018 a las 20:46, Andrew Wiseman ()
escribió:

> Hola OSM Argentina,
>
> Esto es Andrew del equipo de mapas de Apple. Llevamos algún tiempo
> trabajando en el red vial (https://github.com/osmlab/appledata/issues/34)
> y recientemente usado nuestro herramienta Atlas para análisis de datos (
> https://github.com/osmlab/atlas) para buscar algunos tipos de posibles
> problemas, como carreteras con ángulos agudos, intersecciones de edificios
> y carreteras, y lugares donde la clasificación de “highway_link” no
> coincide con la clasificación más alta de las carreteras. Pongo los
> resultados de los retos en MapRoulette, un herramienta que te permite pasar
> los problemas uno por uno y corregirlos o marcar que no son un problema.
> Quería hacerles saber que estaban disponibles en caso de que alguien
> quisiera intentar arreglarlos. Yo también arreglaré algunos.
>
> En MapRoulette escoges un problema random o haz clic en un problema
> especifico. Si desea ver tareas en un lugar determinado, como en un lugar
> con el que está familiarizado, puede hacer clic en "más opciones" y
> luego en “load tasks by proximity” (cargar tareas por proximidad.)
>
> Por favor, hágamelo saber si tiene alguna pregunta o comentario.
>
> Los retos son:
>
> Intersecciones de edificios y carreteras en Argentina:
> https://maproulette.org/mr3/browse/challenges/3394/
> Carreteras de ángulo agudo en Argentina:
> https://maproulette.org/mr3/browse/challenges/3392/
> Carreteras de enlaces en Argentina:
> https://maproulette.org/mr3/browse/challenges/3393/
>
> Saludos,
>
> Andrew
>
>
> Andrew Wiseman |  Maps | andrew_wise...@apple.com
>
> ___
> Talk-ar mailing list
> Talk-ar@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ar
>
___
Talk-ar mailing list
Talk-ar@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ar

Re: [Talk-GB] Talk-GB Digest, Vol 147, Issue 6

[Nick Allen]

Hi All,
When using iD you can stop it 'snapping' to a nearby feature by holding
down the 'Alt' key whilst drawing the feature. 
This wiki list may help with some of the other shortcuts - possibly D
will help with shared nodes (not sure on that one, I've never used it):
 https://wiki.openstreetmap.org/wiki/ID/Shortcuts
Regards
Nick (Tallguy)
On Thu, 2018-12-13 at 11:55 +, Edward Bainton wrote:
> As a new mapper around just long enough to know that I've made some
> crass newbie mistakes already, I agree with Andy. The iD editor is
> the the go-to editor for newbies, myself included, and the snap
> feature is so apparent in the UX that I have regularly taken its
> steer and made new objects follow old nodes.
> Presumably it would be possible to have some 'sticky' features that
> aren't so easily modified - these boundaries would seem to be a good
> candidate; so would roads when they've been rigorously established
> from multiple data sources.
> 
> And/or perhaps a warning in iD that flags the pros and cons of
> snapping to existing nodes, and/or gives the option of a bulk-
> undo/bulk-disconnect if you've done that and thought better of it.
> 
> On Thu, 13 Dec 2018 at 11:39, 
> wrote:
> > Send Talk-GB mailing list submissions to
> > 
> > talk-gb@openstreetmap.org
> > 
> > 
> > 
> > To subscribe or unsubscribe via the World Wide Web, visit
> > 
> > https://lists.openstreetmap.org/listinfo/talk-gb
> > 
> > or, via email, send a message with subject or body 'help' to
> > 
> > talk-gb-requ...@openstreetmap.org
> > 
> > 
> > 
> > You can reach the person managing the list at
> > 
> > talk-gb-ow...@openstreetmap.org
> > 
> > 
> > 
> > When replying, please edit your Subject line so it is more specific
> > 
> > than "Re: Contents of Talk-GB digest..."
> > 
> > Today's Topics:
> > 
> > 
> > 
> >1. OS Boundary-Line - Manchester political wards and related
> > 
> >   boundaries, dealing with inconsistent data (Rick Bowlby)
> > 
> >2. Re: OS Boundary-Line - Manchester political wards and related
> > 
> >   boundaries, dealing with inconsistent data (Colin Smale)
> > 
> >3. Re: OS Boundary-Line - Manchester political wards and related
> > 
> >   boundaries, dealing with inconsistent data (ael)
> > 
> >4. Re: OS Boundary-Line - Manchester political wards and related
> > 
> >   boundaries, dealing with inconsistent data (Mark Goodge)
> > 
> >5. Re: OS Boundary-Line - Manchester political wards and   
> >  related
> > 
> >   boundaries, dealing with inconsistent data (Andy G Wood)
> > 
> > 
> > 
> > 
> > -- Forwarded message --
> > From: Rick Bowlby 
> > To: talk-gb@openstreetmap.org
> > Cc: 
> > Bcc: 
> > Date: Wed, 12 Dec 2018 18:10:24 +
> > Subject: [Talk-GB] OS Boundary-Line - Manchester political wards
> > and related boundaries, dealing with inconsistent data
> > Hello, I quite recently imported Ordnance Survey Boundary-Line data
> > (October 2018, OGL v3) for recently changed electoral wards in
> > Manchester (changeset 65101926). I hope this isn't controversial -
> > these boundaries are useful to me and potentially others as well,
> > and I understand that the OGL is compatible with OSM.
> > 
> > But I've now noticed that the 
> > outer boundary of the wards is not coincident with the current
> > administrative boundary for Manchester City Council in OSM
> > (relation 146656) - as far as I can see, the discrepancies are up
> > to about 5m or so. However it is consistent with the city boundary
> > in the same OS dataset. The sources for the existing OSM data seem
> > to be mixed - there are references to Ordnance Survey sources
> > (without dates), in some places the boundary ways are rivers, there
> > are also references to the "historic course" of a river and so on.
> > 
> > So I'm a bit out of my depth here. As things stand in the OSM data,
> > there are slivers of land all around the periphery which are in
> > Manchester but not in any ward in Manchester, or vice versa, which
> > can't be right. Plus there are data in OSM which are labeled as
> > sourced from OS Boundary-Line but which are not consistent with the
> > latest data from that source. The problem is that there are
> > numerous boundary relations sharing nodes (neighbouring
> > authorities, counties, "historic counties" etc) and cleaning all
> > this up - even if I was confident about where or whether the latest
> > OS data has priority - would be quite tricky, not to say time
> > consuming.
> > 
> > So would it be best to leave things as they are, inconsistencies
> > and all?
> > 
> > Thanks
> > 
> > 
> > 
> > 
> > -- Forwarded message --
> > From: Colin Smale 
> > To: talk-gb@openstreetmap.org
> > Cc: 
> > Bcc: 
> > Date: Wed, 12 Dec 2018 22:05:51 +0100
> > Subject: Re: [Talk-GB] OS Boundary-Line - Manchester political
> > wards and related boundaries, dealing with inconsistent data
> > 
> > Hi Rick,
> > As you can probably guess the 

Re: [Talk-GB] OS Boundary-Line - Manchester political wards and related boundaries, dealing with inconsistent data

[Paul Berry]

I've been mapping for 5 years and I still use iD 95% of the time—because it
just gets stuff done quickly and visually—so it's not just for newbies!
Snapping to nodes isn't a problem per se but the implications of doing so
can be. I've lost count of the times I've encountered roads with adjoining
landuse boundaries that go right up to the centre line of the way rather
than stopping at the kerb/pavement edge. Unpicking all those nodes is
doable in iD but it's a slow and thankless task, and that's with clear and
unambiguous boundaries, never mind administrative or other invisible ones.

(It'd be nice if there were an intermediate OSM editor sitting somewhere on
the skill/complexity curve between iD and JOSM.)

Regards,
*Paul*

On Thu, 13 Dec 2018 at 12:08, Edward Bainton  wrote:

> As a new mapper around just long enough to know that I've made some crass
> newbie mistakes already [point in case, just replied without editing the
> subject line... apologies!], I agree with Andy. The iD editor is the the
> go-to editor for newbies, myself included, and the snap feature is so
> apparent in the UX that I have regularly taken its steer and made new
> objects follow old nodes.
>
> Presumably it would be possible to have some 'sticky' features that aren't
> so easily modified - these boundaries would seem to be a good candidate; so
> would roads when they've been rigorously established from multiple data
> sources.
>
> And/or perhaps a warning in iD that flags the pros and cons of snapping to
> existing nodes, and/or gives the option of a bulk-undo/bulk-disconnect if
> you've done that and thought better of it.
>
> E
>
> On Thu, 13 Dec 2018 at 11:39,  wrote:
>
>> Send Talk-GB mailing list submissions to
>> talk-gb@openstreetmap.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://lists.openstreetmap.org/listinfo/talk-gb
>> or, via email, send a message with subject or body 'help' to
>> talk-gb-requ...@openstreetmap.org
>>
>> You can reach the person managing the list at
>> talk-gb-ow...@openstreetmap.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Talk-GB digest..."
>> Today's Topics:
>>
>>1. OS Boundary-Line - Manchester political wards and related
>>   boundaries, dealing with inconsistent data (Rick Bowlby)
>>2. Re: OS Boundary-Line - Manchester political wards and related
>>   boundaries, dealing with inconsistent data (Colin Smale)
>>3. Re: OS Boundary-Line - Manchester political wards and related
>>   boundaries, dealing with inconsistent data (ael)
>>4. Re: OS Boundary-Line - Manchester political wards and related
>>   boundaries, dealing with inconsistent data (Mark Goodge)
>>5. Re: OS Boundary-Line - Manchester political wards and related
>>   boundaries, dealing with inconsistent data (Andy G Wood)
>>
>>
>>
>> -- Forwarded message --
>> From: Rick Bowlby 
>> To: talk-gb@openstreetmap.org
>> Cc:
>> Bcc:
>> Date: Wed, 12 Dec 2018 18:10:24 +
>> Subject: [Talk-GB] OS Boundary-Line - Manchester political wards and
>> related boundaries, dealing with inconsistent data
>> Hello, I quite recently imported Ordnance Survey Boundary-Line data
>> (October 2018, OGL v3) for recently changed electoral wards in Manchester 
>> (changeset
>> 65101926 ). I hope
>> this isn't controversial - these boundaries are useful to me and
>> potentially others as well, and I understand that the OGL is compatible
>> with OSM.
>>
>> But I've now noticed that the outer boundary of the wards is not
>> coincident with the current administrative boundary for Manchester City
>> Council in OSM (relation 146656
>> ) - as far as I can see,
>> the discrepancies are up to about 5m or so. However it is consistent with
>> the city boundary in the same OS dataset. The sources for the existing OSM
>> data seem to be mixed - there are references to Ordnance Survey sources
>> (without dates), in some places the boundary ways are rivers, there are
>> also references to the "historic course" of a river and so on.
>>
>> So I'm a bit out of my depth here. As things stand in the OSM data, there
>> are slivers of land all around the periphery which are in Manchester but
>> not in any ward in Manchester, or vice versa, which can't be right. Plus
>> there are data in OSM which are labeled as sourced from OS Boundary-Line
>> but which are not consistent with the latest data from that source. The
>> problem is that there are numerous boundary relations sharing nodes
>> (neighbouring authorities, counties, "historic counties" etc) and cleaning
>> all this up - even if I was confident about where or whether the latest OS
>> data has priority - would be quite tricky, not to say time consuming.
>>
>> So would it be best to leave things as they are, inconsistencies and all?
>>
>> Thanks
>>
>>
>>
>> 

Re: [OSM-talk] [HOT] Quality (was: The point on the OSM Response to the DR Congo Nord Kivu Ebola outbreak)

[Stephen Penson]

To build on Jean- Marc's point, one thing I raised at the HOT Summit and also 
recently to the London Missing Maps team is the need to tackle the errors at 
the source. Having validators is vital, but I believe we can improve the 
initial mapping through a few tweaks in the way new mappers are trained.

Personally, what I believe would be really powerful is the creation of a way 
for new mappers to understand the importance of high quality mapping.

For instance, if it were possible within ID Editor to not only highlight 
overlapping buildings but ALSO explain why overlapping buildings have an 
impact, then people would be able to relate and therefore change their 
behaviours.

For example, the tool could highlight that overlapping buildings can result in 
inaccurate population density calculations which can have an impact on 
humanitarian response (see previous messages from Pierre Belland's HOT mailing 
list post on the DRC as a case study). If we can explain this to people in a 
compelling way, I believe the quality of the mapping would improve.

If something could be built within the current tool set (e.g. embedded 
text/video within ID validation) this should hopefully ensure consistency.

Combining such tweaks with real-time monitoring tools, such as Bjoern suggests, 
should improve quality at mapathons.

Essentially, people attend Missing Maps mapathons to contribute to a worthy 
cause. People wish to map the best they can, so if more (and consistent) 
support is offered, the quality will improve.

Thanks

Steve

From: Jean-Marc Liotier 
Sent: 12 December 2018 22:30
To: talk@openstreetmap.org; h...@openstreetmap.org
Subject: Re: [HOT] Quality (was: The point on the OSM Response to the DR Congo 
Nord Kivu Ebola outbreak)

On 12/12/18 2:16 AM, Ralph Aytoun wrote:

I am also concerned about the quality of the mapping that is tying up projects 
because it takes up so much validation time. [..]

This perception is (don't take it personally - I answer your message but I'm 
not singling you out) a symptom of a widespread problem: quality perceived as a 
separate activity, an extra cost tacked on the actual productive work.

Considering the quality assurance process as a distinct set of activities has 
the very unfortunate effect of creating an unnecessary conflict with production.

So:
- Start with a clearly defined objective quality goal, just adequate for the 
planned purpose of the data
- Teach contributors that not meeting this goal is worse than doing nothing: 
negative value
- Monitor contributions in real time, to catch deviations before they 
snowball... I love Bjoern's idea, though OSMCHA works for me
- Reiterate !

Quality is the essence of the whole activity, not a distinct step.

Yes, it spoils the fun for new contributors thrilled to start mapping away and 
see their gamified metrics take off spectacularly in a rain of digital 
achievement awards. But it also helps them make sense of what they are doing 
instead of launching them on an open ended trip with a hazy purpose - and what 
is better than to find meaning in a task ?

Normative leadership may feel incompatible with a flat collaborative forum such 
as Openstreetmap, but it makes sense within a directed project with a declared 
purpose, to which contributors voluntarily participate. If they trust the 
project leadership enough to join as contributors, they may expect the 
normative guidance and even be disappointed not to feel it from the leadership.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Academic Track at State of the Map 2019 - Call for applications for the Leading Team

[Marco Minghini]

 Dear colleagues,

Following the successful initiation of the *Academic Track* at State of the
Map 2018 in Milan [1], this Track will be included again in the program of
State of the Map 2019, to be held in Heidelberg on September 21-23, 2019.
The main purpose of the Academic Track is to bring together and foster
interactions between the OpenStreetMap community at large (contributors,
developers, users, etc.) and the academic/scientific community of
researchers from all over the world.

A designated Leading Team would be in charge on the organization of the
Academic Track, co-chaired by Marco Minghini (on behalf of the OSMF State
of the Map Working Group) and Yair Grinberger (on behalf of the Heidelberg
local team). We hereby issue a call for applications, inviting all
interested individuals to apply to join the Leading Team. This team will be
in charge of:

   - writing and publishing the call for abstracts/papers for State of the
   Map 2019
   - designing and managing the review process of the submitted abstracts,
   deciding which ones to accept for oral presentation or poster presentation
   - defining the Academic Track schedule at State of the Map 2019, by
   working in close contact with the Programme Selection Committee
   - planning and managing possible publication outputs, e.g. conference
   proceedings or a Special Issue in a scientific journal

In agreement with the OSMF State of the Map Working Group and the local
team, it was decided that the Academic Track Leading Team will be composed
by Marco and Yair plus 3 additional people that would be selected through
this open call.

Thus, we invite applications for *researchers or academics* to be part of
the Academic Track Leading Team. The call is open to everyone
interested. *Applications
shall be made exclusively by sending an e-mail to the OSM science mailing
list scie...@openstreetmap.org * (this requires
registering for the list at https://lists.openstreetmap.org/listinfo/science
),
and filling the following template:

*Name and Surname*
*Please enter your name and surname.*

*Affiliation*
*Please enter your (current) full affiliation.*

*Academic experience, in particular on OpenStreetMap*
*Please enter a short description of your main academic interests and
contributions, especially related to OpenStreetMap. A full list of
OpenStreetMap-related publications (or a link to it) is appreciated.*

*Editorial experience*
*Please enter a short description of your editorial experience, e.g. as a
Member of the Editorial Board of scientific journals, Guest-Editors of
Special Issues, reviewer for scientific journals. Place the focus on
OpenStreetMap, when relevant.*

*Participation in State of the Map 2019*
*Despite it is not required that you are attending State of the Map 2019,
please inform us whether you plan to attend (if selected as a member of the
Academic Track Leading Team).*

Only applications submitted according to this procedure and only
self-nominations will be considered.

The deadline for applications is *January 3, 2019*.

Applications will be assessed by the OSMF State of the Map Working Group
and the Heidelberg local team. The three available seats of the Academic
Track Leading Team will be assigned based on the candidate’s personal merit
and according to the overall goal of forming a diverse and
interdisciplinary Team. In absence of candidates who are meeting the
expectations, the OSMF State of the Map Working Group and the Heidelberg
local team reserve the right to select less than three people, or nominate
additional persons by invitation.

Best regards,

Yair and Marco - on behalf of the OSMF State of the Map Working Group and
the State of the Map 2019 Heidelberg local team


[1] See the call for abstracts for 2018 (
https://2018.stateofthemap.org/academictrack) and the program of the
Academic Track on Sunday, 29 July, room S1.3 (
https://2018.stateofthemap.org/program)
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] [Osmf-talk] Board decision on Crimea complaint

[Manfred A. Reiter]

"When in doubt, also consider the "on the ground rule": map the world as it
can be observed by someone physically there."

source: https://wiki.openstreetmap.org/wiki/How_We_Map

- no further comment -

## Manfred Reiter - mobile -
## please excuse typos and brevity


Am Mo., 10. Dez. 2018, 11:58 hat Martijn van Exel  geschrieben:

> Hi all,
>
> On November 17, the OSMF Board of Directors received a request to review
> the Nov 14, 2018 Data Working Group decision regarding Crimea.
>
> The Board decided that this decision is to be reversed and the previous
> situation, as laid out in the May 5, 2014 Data Working Group minutes, is to
> further remain in effect.
>
> The board highly values the Data Working Group’s work and appreciates the
> difficulty and complexity of the cases they are asked to review on an
> ongoing basis.
>
> A more comprehensive statement will follow in the next weeks.
>
> Best regards,
> Martijn van Exel
> Secretary, OpenStreetMap Foundation
> ___
> osmf-talk mailing list
> osmf-t...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osmf-talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] [Osmf-talk] Candidate's views? Re: Board decision on Crimea complaint

[Manfred A. Reiter]

Am Di., 11. Dez. 2018 um 11:52 Uhr schrieb Guillaume Rischard <
openstreet...@stereo.lu>:

> Hi Rory and fellow members,
>
> I am a candidate in the board election, and have underlined in my
> manifesto how important it is that decisions like this are taken
> transparently. The detailed reasoning behind this decision must be
> published without delay.
>

+1

[...]


> However, the on-the-ground rule is one of the very core values that we
> have built OSM and the OSMF on.
>

+1


> https://wiki.osmfoundation.org/wiki/Mission_Statement says that OSM
> favours objective ‘Ground Truth’ over all other sources. The ‘Scope of the
> OSMF’ section says that it does not decide what to map or how to map.


[...]

The decision of the DWG was absolutely correct according to the rules that
OSM imposed on itself.

I think the board here is opening Pandora's box. It will certainly be
interesting to see how all the controversial areas will be judged from now
on.

cheers
-- 
## Manfred Reiter
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] [Osmf-talk] Candidate's views? Re: Board decision on Crimea complaint

[Jaak Laineste]

Hi,

There are map services (TomTom I believe) which have a parameter, something 
like "politics" with possible values China, India and Pakistan, and of course 
google does same for end-users. As far as I can think of more or less every 
single country has some details what they feel to be mapped differently from 
some others, probably all the neighbours of the same country connected with 
Crimea have this challenge. Nothing new here, that's reality and implementing 
"international map politics" that would be an obvious minimal feature of any 
international map app. So far only the biggest ones do it, but none of 
OSM-based AFAIK. OSM itself is a database, not app, so we can only enable it 
with tagging, and maybe in the 'preview' web tiles. 

Jaak

> On 11 Dec 2018, at 17:39, Eugene Alvin Villar  wrote:
> 
> On Tue, Dec 11, 2018 at 10:02 PM Imre Samu  > wrote:
> TLDR:  We need focusing for the customizable vector tiles for the next year!  
>   (  Less community fighting - more working on the real problems!  )
> 
> Vector tiles and customizable styling is not enough. AFAIK, we never use 
> 3rd-party data (except for the public domain Natural Earth data for the lower 
> zoom levels, IIRC) when rendering the default tile layer on the OSM. So we 
> still need to represent the various viewpoints on disputed borders and 
> territories within the OSM database itself if you want that level of 
> flexibility on the default tile layer(s). There are already a couple or so 
> threads on the Tagging mailing list discussing various tagging solutions for 
> representing these viewpoints and disputes.
> 
> ~Eugene
> ___
> osmf-talk mailing list
> osmf-t...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osmf-talk

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

[Talk-GB] OS Boundary-Line - Manchester political wards and related boundaries, dealing with inconsistent data

[Edward Bainton]

As a new mapper around just long enough to know that I've made some crass
newbie mistakes already [point in case, just replied without editing the
subject line... apologies!], I agree with Andy. The iD editor is the the
go-to editor for newbies, myself included, and the snap feature is so
apparent in the UX that I have regularly taken its steer and made new
objects follow old nodes.

Presumably it would be possible to have some 'sticky' features that aren't
so easily modified - these boundaries would seem to be a good candidate; so
would roads when they've been rigorously established from multiple data
sources.

And/or perhaps a warning in iD that flags the pros and cons of snapping to
existing nodes, and/or gives the option of a bulk-undo/bulk-disconnect if
you've done that and thought better of it.

E

On Thu, 13 Dec 2018 at 11:39,  wrote:

> Send Talk-GB mailing list submissions to
> talk-gb@openstreetmap.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.openstreetmap.org/listinfo/talk-gb
> or, via email, send a message with subject or body 'help' to
> talk-gb-requ...@openstreetmap.org
>
> You can reach the person managing the list at
> talk-gb-ow...@openstreetmap.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Talk-GB digest..."
> Today's Topics:
>
>1. OS Boundary-Line - Manchester political wards and related
>   boundaries, dealing with inconsistent data (Rick Bowlby)
>2. Re: OS Boundary-Line - Manchester political wards and related
>   boundaries, dealing with inconsistent data (Colin Smale)
>3. Re: OS Boundary-Line - Manchester political wards and related
>   boundaries, dealing with inconsistent data (ael)
>4. Re: OS Boundary-Line - Manchester political wards and related
>   boundaries, dealing with inconsistent data (Mark Goodge)
>5. Re: OS Boundary-Line - Manchester political wards and related
>   boundaries, dealing with inconsistent data (Andy G Wood)
>
>
>
> -- Forwarded message --
> From: Rick Bowlby 
> To: talk-gb@openstreetmap.org
> Cc:
> Bcc:
> Date: Wed, 12 Dec 2018 18:10:24 +
> Subject: [Talk-GB] OS Boundary-Line - Manchester political wards and
> related boundaries, dealing with inconsistent data
> Hello, I quite recently imported Ordnance Survey Boundary-Line data
> (October 2018, OGL v3) for recently changed electoral wards in Manchester 
> (changeset
> 65101926 ). I hope this
> isn't controversial - these boundaries are useful to me and potentially
> others as well, and I understand that the OGL is compatible with OSM.
>
> But I've now noticed that the outer boundary of the wards is not
> coincident with the current administrative boundary for Manchester City
> Council in OSM (relation 146656
> ) - as far as I can see,
> the discrepancies are up to about 5m or so. However it is consistent with
> the city boundary in the same OS dataset. The sources for the existing OSM
> data seem to be mixed - there are references to Ordnance Survey sources
> (without dates), in some places the boundary ways are rivers, there are
> also references to the "historic course" of a river and so on.
>
> So I'm a bit out of my depth here. As things stand in the OSM data, there
> are slivers of land all around the periphery which are in Manchester but
> not in any ward in Manchester, or vice versa, which can't be right. Plus
> there are data in OSM which are labeled as sourced from OS Boundary-Line
> but which are not consistent with the latest data from that source. The
> problem is that there are numerous boundary relations sharing nodes
> (neighbouring authorities, counties, "historic counties" etc) and cleaning
> all this up - even if I was confident about where or whether the latest OS
> data has priority - would be quite tricky, not to say time consuming.
>
> So would it be best to leave things as they are, inconsistencies and all?
>
> Thanks
>
>
>
> -- Forwarded message --
> From: Colin Smale 
> To: talk-gb@openstreetmap.org
> Cc:
> Bcc:
> Date: Wed, 12 Dec 2018 22:05:51 +0100
> Subject: Re: [Talk-GB] OS Boundary-Line - Manchester political wards and
> related boundaries, dealing with inconsistent data
>
> Hi Rick,
>
> As you can probably guess the whole of the country is divided into wards,
> which are subdivisions of council areas for electoral (and not
> administrative) purposes. The slivers are not correct of course - they are
> artefacts of the fact that the different boundaries have been created from
> different data sets, or at different times, using different levels of
> generalisation, or using different transformations. The latter is important
> as the data published by the OS uses the National Grid as its datum, and
> has to be converted to the latitude/longitude format used by OSM. This
> conversion 

Re: [Talk-GB] Talk-GB Digest, Vol 147, Issue 6

[Edward Bainton]

As a new mapper around just long enough to know that I've made some crass
newbie mistakes already, I agree with Andy. The iD editor is the the go-to
editor for newbies, myself included, and the snap feature is so apparent in
the UX that I have regularly taken its steer and made new objects follow
old nodes.

Presumably it would be possible to have some 'sticky' features that aren't
so easily modified - these boundaries would seem to be a good candidate; so
would roads when they've been rigorously established from multiple data
sources.

And/or perhaps a warning in iD that flags the pros and cons of snapping to
existing nodes, and/or gives the option of a bulk-undo/bulk-disconnect if
you've done that and thought better of it.

On Thu, 13 Dec 2018 at 11:39,  wrote:

> Send Talk-GB mailing list submissions to
> talk-gb@openstreetmap.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.openstreetmap.org/listinfo/talk-gb
> or, via email, send a message with subject or body 'help' to
> talk-gb-requ...@openstreetmap.org
>
> You can reach the person managing the list at
> talk-gb-ow...@openstreetmap.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Talk-GB digest..."
> Today's Topics:
>
>1. OS Boundary-Line - Manchester political wards and related
>   boundaries, dealing with inconsistent data (Rick Bowlby)
>2. Re: OS Boundary-Line - Manchester political wards and related
>   boundaries, dealing with inconsistent data (Colin Smale)
>3. Re: OS Boundary-Line - Manchester political wards and related
>   boundaries, dealing with inconsistent data (ael)
>4. Re: OS Boundary-Line - Manchester political wards and related
>   boundaries, dealing with inconsistent data (Mark Goodge)
>5. Re: OS Boundary-Line - Manchester political wards and related
>   boundaries, dealing with inconsistent data (Andy G Wood)
>
>
>
> -- Forwarded message --
> From: Rick Bowlby 
> To: talk-gb@openstreetmap.org
> Cc:
> Bcc:
> Date: Wed, 12 Dec 2018 18:10:24 +
> Subject: [Talk-GB] OS Boundary-Line - Manchester political wards and
> related boundaries, dealing with inconsistent data
> Hello, I quite recently imported Ordnance Survey Boundary-Line data
> (October 2018, OGL v3) for recently changed electoral wards in Manchester 
> (changeset
> 65101926 ). I hope this
> isn't controversial - these boundaries are useful to me and potentially
> others as well, and I understand that the OGL is compatible with OSM.
>
> But I've now noticed that the outer boundary of the wards is not
> coincident with the current administrative boundary for Manchester City
> Council in OSM (relation 146656
> ) - as far as I can see,
> the discrepancies are up to about 5m or so. However it is consistent with
> the city boundary in the same OS dataset. The sources for the existing OSM
> data seem to be mixed - there are references to Ordnance Survey sources
> (without dates), in some places the boundary ways are rivers, there are
> also references to the "historic course" of a river and so on.
>
> So I'm a bit out of my depth here. As things stand in the OSM data, there
> are slivers of land all around the periphery which are in Manchester but
> not in any ward in Manchester, or vice versa, which can't be right. Plus
> there are data in OSM which are labeled as sourced from OS Boundary-Line
> but which are not consistent with the latest data from that source. The
> problem is that there are numerous boundary relations sharing nodes
> (neighbouring authorities, counties, "historic counties" etc) and cleaning
> all this up - even if I was confident about where or whether the latest OS
> data has priority - would be quite tricky, not to say time consuming.
>
> So would it be best to leave things as they are, inconsistencies and all?
>
> Thanks
>
>
>
> -- Forwarded message --
> From: Colin Smale 
> To: talk-gb@openstreetmap.org
> Cc:
> Bcc:
> Date: Wed, 12 Dec 2018 22:05:51 +0100
> Subject: Re: [Talk-GB] OS Boundary-Line - Manchester political wards and
> related boundaries, dealing with inconsistent data
>
> Hi Rick,
>
> As you can probably guess the whole of the country is divided into wards,
> which are subdivisions of council areas for electoral (and not
> administrative) purposes. The slivers are not correct of course - they are
> artefacts of the fact that the different boundaries have been created from
> different data sets, or at different times, using different levels of
> generalisation, or using different transformations. The latter is important
> as the data published by the OS uses the National Grid as its datum, and
> has to be converted to the latitude/longitude format used by OSM. This
> conversion is actually rather complicated, and different implementations
> can give 

Re: [Talk-lt] RC naujiena

[Tomas Straupis]

Sveiki

  Džiugu, kad bent kažkas vyksta į tą pusę Registrų centre.

  Deja, kol kas konkrečiai mums nėra gerų žinių. Paklausiau dėl mums
rūpimų adresų ir administracinių ribų registro ir dalyvavimo
konsultacijose. Gavau tokį atsakymą (išėmiau mandagumus, dėkojimus ir
pan.)

„
Atsakydamas į Jūsų klausimus, noriu informuoti, kad adresų ir
administracinių ribų duomenų rinkiniai nėra įtraukti iki 2019 m.
planuojamų atverti duomenų rinkinių planą. Bet matydami Jūsų interesą,
rimtai svarstysime tai padaryti vėliau ateityje.

Jūsų asociacija be jokios abejonės gali dalyvauti konsultacijose dėl
Registrų centro planuojamų atverti duomenų. Šiuo metu kaip tik yra
rengiama galutinė konsultacijų su visuomene ir suinteresuotomis
šalimis tvarka. Labiausiai tikėtina, kad bandysime suinteresuotas
šalis pasikviesti pas save. Bet kuriuo atveju, sekite mūsų naujienas,
būtinai informuosime apie eigą ir planuojamus susitikimus.
“

-- 
Tomas

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

Re: [Talk-GB] OS Boundary-Line - Manchester political wards and related boundaries, dealing with inconsistent data

[Gareth L]

If only it could “snap” to points, but not join, where the way is an 
administrative boundary.

> On 13 Dec 2018, at 11:39, Andy G Wood  wrote:
> 
>> On Thursday, 13 December 2018 11:22:58 GMT Mark Goodge wrote:
>>> On 12/12/2018 23:11, ael wrote:
>>> This is perhaps slightly off topic, but this habit of some of sharing
>>> nodes causes me many problems. When I am updating roads and other
>>> features from fairly accurate gps surveys, I often find the I have all
>>> these tangled boundaries about which I know little. It is a huge pain
>>> to duplicate nodes to separate ways before I can adjust just the feature
>>> that I have surveyed. I confess that my patience often runs out, and I
>>> just drag the other stuff along with my updates, thinking that the
>>> mappers who shared the nodes in the first place get what they deserve
>>> 
>>> :-).
>> 
>> I agree. [...]
> 
> I also wholeheartedly agree.
> However I think this problem is not helped by the fact that the iD editor, by 
> default, will snap to nearest points.  You may be able to change this (?), 
> but 
> I have kept with the defaults, so this will be a "feature" that many mappers 
> just go with as the accepted norm.
> 
> Andy.
> 
> 
> 
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] OS Boundary-Line - Manchester political wards and related boundaries, dealing with inconsistent data

[Andy G Wood]

On Thursday, 13 December 2018 11:22:58 GMT Mark Goodge wrote:
> On 12/12/2018 23:11, ael wrote:
> > This is perhaps slightly off topic, but this habit of some of sharing
> > nodes causes me many problems. When I am updating roads and other
> > features from fairly accurate gps surveys, I often find the I have all
> > these tangled boundaries about which I know little. It is a huge pain
> > to duplicate nodes to separate ways before I can adjust just the feature
> > that I have surveyed. I confess that my patience often runs out, and I
> > just drag the other stuff along with my updates, thinking that the
> > mappers who shared the nodes in the first place get what they deserve
> > 
> > :-).
> 
> I agree. [...]

I also wholeheartedly agree.
However I think this problem is not helped by the fact that the iD editor, by 
default, will snap to nearest points.  You may be able to change this (?), but 
I have kept with the defaults, so this will be a "feature" that many mappers 
just go with as the accepted norm.

Andy.




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

Re: [OSM-talk] Ground truth for non-physical objects

[Martin Koppenhoefer]

sent from a phone

> On 13. Dec 2018, at 11:40, Tomas Straupis  wrote:
> 
> 
>  I was never for indiscriminate, automated imports without manual
> checks. Accepting documents as source does not necessary mean allowing
> such imports. When doing manual checks you can find (and we DO find)
> errors in official documents. Then OpenStreetMap gets correct data,
> not official version.
> 
>  I'm also not saying to remove the ground truth rule as such. I'm
> only saying that the term "ground truth" in the context of
> non-physical objects must be clarified because currently it is being
> interpreted in a lot of different ways.


I would not exclude documents as source for mapping, e.g. you could copy 
information from a company website, but I would value ground truth higher if 
there are contradictions. You shouldn’t probably change some existing 
information based solely on remote research. We even have established specific 
tags for these, e.g. „official_name“ for a legal name vs. name for the most 
suitable/common name.


Recently we have been discussing an import of housenumbers in Italy and some 
people were advocating the removal of housenumbers that the city has suspended, 
while I was advocating to do this only after a ground survey and having 
confirmed that the sign has been physically removed (=almost never). Imagine 
someone standing in front of a housenumber telling her position on the phone, 
it doesn’t matter if the city thinks it is a valid address, it still serves its 
purpose, and the person seeing the number will not be able to see whether that 
number is „valid“ or not.

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

Re: [Talk-GB] OS Boundary-Line - Manchester political wards and related boundaries, dealing with inconsistent data

[Mark Goodge]

On 12/12/2018 23:11, ael wrote:


This is perhaps slightly off topic, but this habit of some of sharing
nodes causes me many problems. When I am updating roads and other
features from fairly accurate gps surveys, I often find the I have all
these tangled boundaries about which I know little. It is a huge pain
to duplicate nodes to separate ways before I can adjust just the feature
that I have surveyed. I confess that my patience often runs out, and I
just drag the other stuff along with my updates, thinking that the
mappers who shared the nodes in the first place get what they deserve
:-).


I agree. I tried to fix the outline of a park that's just down the road 
from me. It's clearly incorrect when viewed on the satellite view in the 
editor, and I thought it would be a relatively simple task of dragging 
the nodes to match reality. But it turns out that the nodes down one 
side are shared with a river that's adjacent to the park, and down 
another side with a road that is almost, but not quite, directly 
adjacent to the park. Sharing nodes with that road makes the park look 
bigger than it actually is, and, more importantly, makes a building 
that, in reality, is on the boundary of the park appear to be wholly 
within it. I thought I could simply drag the nodes to the correct 
position, but I can't without also moving the road, which would be 
equally incorrect.


It would make far more sense if the boundaries of the park were a single 
set of nodes and ways not shared with any other object. When I've got 
considerably more tuits to spare I may just do that - delete the park 
completely and then recreate it from scratch as a new object with its 
own nodes and ways. But, at the moment, I don't really have the time. So 
I've left it, and it continues to irritate me every time I look at it on 
the map :-)


Mark

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

Re: [Talk-it] utilizzo di noexit=yes

[Volker Schmidt]

On Thu, 13 Dec 2018 at 11:18, Edoardo Yossef Marascalchi <
e.marascal...@gmail.com> wrote:

>
> Secondo me (ma non ho esperienza di mappatura di sentieri) il sentiero va
> mappato dove è discernibile. Dove non lo è non va mappato.
>

Non è veramente così. Ci sono sentieri (nel senso d percorso hiking) che
contengono pezzi dove il sentiero (nel senso fisico) non è discernibile sul
terreno, ma è percorribile (non c'è un impedimento fisico). Per questo tipo
di situazione si utilizza highway=path con trail_visibility
=no.


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

Re: [Talk-lt] RC naujiena

[Mantas]

Dalyvavau susitikime su žmogumi, kuris bus atsakingas už RC atvirus
duomenis. Po susitikimo iki galo nesupratau ar duomenys bus atverti ar ne.
Kaip suprantu, jei valstybė kompensuos RC prarastas pajamas, tada duomenys
bus atverti.

2018-12-13, kt 12:52, Ramas  rašė:

> Sveiki,
> čia RC paskelbė[1] tokią naujieną:
>
> > "Atviri duomenys turi būti lengvai prieinami, patogiai naudojami, kad
> teiktų didžiausią įmanomą naudą gyventojams, verslui ir valstybei. Matydami
> atvirų duomenų potencialą ir galimybes, pirmą kartą imame inicijuoti
> diskusijas su suinteresuotomis šalimis bei visuomene dėl Registrų centro
> tvarkomų duomenų atvėrimo. Šis procesas padės geriau suprasti visuomenės
> poreikį, leis aiškiai nusistatyti prioritetus, kokie duomenys turėtų būti
> atverti pirmiausiai", - sako Registrų centro direktorius Saulius
> Urbanavičius.
>
> Gal kas nors žino daugiau? Ar dalyvaus kas nors iš OSM prijaučiančių?
>
> [1]
> http://www.registrucentras.lt/naujienos/index.php?mod=news=view=37815
> ___
> Talk-lt mailing list
> Talk-lt@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-lt
>
___
Talk-lt mailing list
Talk-lt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-lt

[Talk-lt] RC naujiena

[Ramas]

Sveiki,
čia RC paskelbė[1] tokią naujieną:

> "Atviri duomenys turi būti lengvai prieinami, patogiai naudojami, kad
teiktų didžiausią įmanomą naudą gyventojams, verslui ir valstybei. Matydami
atvirų duomenų potencialą ir galimybes, pirmą kartą imame inicijuoti
diskusijas su suinteresuotomis šalimis bei visuomene dėl Registrų centro
tvarkomų duomenų atvėrimo. Šis procesas padės geriau suprasti visuomenės
poreikį, leis aiškiai nusistatyti prioritetus, kokie duomenys turėtų būti
atverti pirmiausiai", - sako Registrų centro direktorius Saulius
Urbanavičius.

Gal kas nors žino daugiau? Ar dalyvaus kas nors iš OSM prijaučiančių?

[1]
http://www.registrucentras.lt/naujienos/index.php?mod=news=view=37815
___
Talk-lt mailing list
Talk-lt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-lt

Re: [Talk-cz] Bylo: WeeklyOSM CZ 437 - bazény

[Petr Vozdecký]

-- Původní e-mail --
Od: majka 
"



On Thu, 13 Dec 2018 at 10:59, Miroslav Suchy mailto:miros...@suchy.cz)> wrote:

"Tohle by se dalo rict o dost velkem poctu prvku v OSM. Z moji vlastni
zkusenosti - pokud ma nekdo na zahrade bazen ktery
je viditelny z orto-fota, tak tam je pristi rok znovu. A dost velka cast je
fixni a je tam i pres zimu.
"
Tohle je nesmysl. Bavíme se o malých bazénech, a pokud se podívám, kde mi to
ten dotaz našel, je tam až na výjimky jen ten fell3. Kam nepřišel (nebo kde
ho včas zarazili), není nic takového. 


"



Otázka je proč mu to zarazili - ne proto, že ty bazény neexistují (ať jsou
jakékoliv), ale proto, že mapoval zcela zřejmě z nelegálních zdrojů. Tam je
potřeba začít u jakýchkoliv úvah o zachování či nezachování dat. Pokud ta
data jsou reálná (a byla-li by legální), pak spíše zachovat, ale příslušně
otagovat.




Stejně mě zajímá, proč to dělá, nějaká motivace tam musí být, možná je to na
nějakou komerční objednávku pro nějakou další analýzu - takovou práci s
takovým konkrétním tématem bez zjevného širokého užitku a navzdory odporu
komunity si přece normální člověk dát nemůže...
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [OSM-talk] Ground truth for non-physical objects

[Tomas Straupis]

2018-12-12, tr, 15:47 Andy Townsend rašė:
> If you're looking for a project that essentially mirrors "official" data
> without actually checking that its valid then OpenStreetMap might not be
> the project for you.

  I was never for indiscriminate, automated imports without manual
checks. Accepting documents as source does not necessary mean allowing
such imports. When doing manual checks you can find (and we DO find)
errors in official documents. Then OpenStreetMap gets correct data,
not official version.

  I'm also not saying to remove the ground truth rule as such. I'm
only saying that the term "ground truth" in the context of
non-physical objects must be clarified because currently it is being
interpreted in a lot of different ways.

  What is "ground" in this term for non physical objects:
  1. Physical place which could have some traces of an actual object.
  2. Ground where non-physical objects actually live - documents.

> the general view, which I think we can see from the balance of the posts
> in this thread, is that most people back the "on the ground" principle -
> if there's a housename that looks like looks like a house name, it's a
> house name, even if it's not in an "official" list.

  Balance of posts could mean one of these:
  1. You're right and majority is against usage of documents as
sources for non-physical objects.
  2. People just do not see it possible to change your interpretation
or do not see the point in this discussion at all and simply continue
doing what they have been doing.

  But even if we would be able to vote, count, elect here in talk
mailing list, what authority would that have? In my opinion - close to
none. As in most open source/data projects people "vote" with their
actions. In this case by creating data in the OpenStreetMap database.
And most non-physical data today does not come from physical
observation.

-- 
Tomas

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

Re: [Talk-it] utilizzo di noexit=yes

[angelo mornata]

Uso noexit quando effettivamente è  così,  tipo : tratturo che finisce in un 
lettamaio , o sentiero che finisce su un bel vedere, (Se vai oltre finisci 
spiaccicato 400 metri sotto).
Ciao
Angelo


Inviato da smartphone Samsung Galaxy.

 Messaggio originale 
Da: Edoardo Yossef Marascalchi 
Data: 13/12/18 11:17 (GMT+01:00)
A: openstreetmap list - italiano 
Oggetto: Re: [Talk-it] utilizzo di noexit=yes

IMHO noexit è pensato esclusivamente per strade, non per sentieri.
Il livello di densità della vegetazione, poi, non è costante.
Secondo me (ma non ho esperienza di mappatura di sentieri) il sentiero va 
mappato dove è discernibile. Dove non lo è non va mappato.

Edo


On Thu, Dec 13, 2018 at 11:47 AM demon_box 
mailto:e.rossini7...@gmail.com>> wrote:
ciao, finchè si utilizza il tag noexit=yes, diciamo in ambito urbano
sicuramente problemi non ce ne sono.

esempio semplice semplice:

strada asfaltata che poi finisce, se non c'è modo di proseguire nemmeno a
piedi utilizzo noexit=yes e sono a posto.

ma se ci spostiamo in ambito extraurbano o addirittura montano la situazione
si fa molto più liquida.

al solito vi pongo alcuni esempi per chiedervi cosa ne pensate:

1) sentiero che da ben visibile termina di colpo dove comincia un prato ma
volendo potrei proseguire a piedi in mezzo al prato senza traccia segnalata,
quindi non metto nulla?
2) sentiero che da ben visibile poi diventa impossibile da seguire a causa
della vegetazione faccio noexit=yes + obstacle=vegetation
3) situazione quasi identica alla prima: sentiero che da ben visibile
termina di colpo e si perde nel sottobosco non fitto quindi volendo potrei
proseguire [ armato di bussola ;-) ] che faccio?
4) sentiero diciamo di "servizio" che porta ad una casetta isolata di
montagna, a meno che traccio questo sentiero fino a connettermi alla porta
di casa, come mi comporto? in questo caso ci sta noexit=yes laddove il
sentiero in questione "finisce" pochi metri prima della casetta stessa?


concludendo in relazione all'utilizzo di noexit=yes non sempre (o quasi mai
in montagna) dove il sentiero ben segnato termina ci si trova di fronte ad
un muro!! quindi come ci comportiamo?

grazie

--enrico




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


--
Edoardo Yossef Marascalchi
skype: asca_edom
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[OSM-talk-fr] Gmaps strikes again...

[Jacques Lavignotte]

Euh,

http://www.zones-activites.net/plan-1386-Zone-d-activites-de-Beaubaton.html

Non, rien.
--
GnuPg : C8F5B1E3 Because privacy matters.


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

Re: [Talk-it] utilizzo di noexit=yes

[Edoardo Yossef Marascalchi]

IMHO noexit è pensato esclusivamente per strade, non per sentieri.
Il livello di densità della vegetazione, poi, non è costante.
Secondo me (ma non ho esperienza di mappatura di sentieri) il sentiero va
mappato dove è discernibile. Dove non lo è non va mappato.

Edo


On Thu, Dec 13, 2018 at 11:47 AM demon_box  wrote:

> ciao, finchè si utilizza il tag noexit=yes, diciamo in ambito urbano
> sicuramente problemi non ce ne sono.
>
> esempio semplice semplice:
>
> strada asfaltata che poi finisce, se non c'è modo di proseguire nemmeno a
> piedi utilizzo noexit=yes e sono a posto.
>
> ma se ci spostiamo in ambito extraurbano o addirittura montano la
> situazione
> si fa molto più liquida.
>
> al solito vi pongo alcuni esempi per chiedervi cosa ne pensate:
>
> 1) sentiero che da ben visibile termina di colpo dove comincia un prato ma
> volendo potrei proseguire a piedi in mezzo al prato senza traccia
> segnalata,
> quindi non metto nulla?
> 2) sentiero che da ben visibile poi diventa impossibile da seguire a causa
> della vegetazione faccio noexit=yes + obstacle=vegetation
> 3) situazione quasi identica alla prima: sentiero che da ben visibile
> termina di colpo e si perde nel sottobosco non fitto quindi volendo potrei
> proseguire [ armato di bussola ;-) ] che faccio?
> 4) sentiero diciamo di "servizio" che porta ad una casetta isolata di
> montagna, a meno che traccio questo sentiero fino a connettermi alla porta
> di casa, come mi comporto? in questo caso ci sta noexit=yes laddove il
> sentiero in questione "finisce" pochi metri prima della casetta stessa?
>
>
> concludendo in relazione all'utilizzo di noexit=yes non sempre (o quasi mai
> in montagna) dove il sentiero ben segnato termina ci si trova di fronte ad
> un muro!! quindi come ci comportiamo?
>
> grazie
>
> --enrico
>
>
>
>
> --
> 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
>


-- 
Edoardo Yossef Marascalchi
skype: asca_edom
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-cz] Bylo: WeeklyOSM CZ 437 - bazény

[majka]

On Thu, 13 Dec 2018 at 10:59, Miroslav Suchy  wrote:

> Tohle by se dalo rict o dost velkem poctu prvku v OSM. Z moji vlastni
> zkusenosti - pokud ma nekdo na zahrade bazen ktery
> je viditelny z orto-fota, tak tam je pristi rok znovu. A dost velka cast
> je fixni a je tam i pres zimu.
>
Tohle je nesmysl. Bavíme se o malých bazénech, a pokud se podívám, kde mi
to ten dotaz našel, je tam až na výjimky jen ten fell3. Kam nepřišel (nebo
kde ho včas zarazili), není nic takového.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-cz] Bylo: WeeklyOSM CZ 437 - bazény

[Miroslav Suchy]

Dne 12. 12. 18 v 16:32 r00t napsal(a):
> Cokoliv mensiho nez nejakych 10x5m co mapoval fell3 bych proste smazal.
> Protoze jina alternativa je ze by to musel nekdo udrzovat aktualni, pochybuju
> ze vetsina bazenu tam opet bude az bude k dispozici nova ortofotomapa.

Tohle by se dalo rict o dost velkem poctu prvku v OSM. Z moji vlastni 
zkusenosti - pokud ma nekdo na zahrade bazen ktery
je viditelny z orto-fota, tak tam je pristi rok znovu. A dost velka cast je 
fixni a je tam i pres zimu.

Osobne me prijde zajimave mapovat zahradni bazeny, protoze se z toho 
potencionalne daji delat zajimave vodohospodarske
statistiky: ocekavana spotrebava vody apod.

Mirek

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

Re: [OSM-talk] Ground truth for non-physical objects

[Martin Koppenhoefer]

Am Mi., 12. Dez. 2018 um 16:36 Uhr schrieb Florian Lohoff :

>  I know that because i have caused ~100 residents to
> get new id cards because they all had a wrong street name in their ID.



This would merit a diary entry ;-)

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

Re: [Talk-it] Parchimetri a Perugia

[Martin Koppenhoefer]

Am Mi., 12. Dez. 2018 um 13:26 Uhr schrieb claudio62PG :

> Ho guardato Roma ma non ho trovato i settori



credo ci siano i settori, ma non li abbiamo mappati. ;-)

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

[Talk-it] utilizzo di noexit=yes

[demon_box]

ciao, finchè si utilizza il tag noexit=yes, diciamo in ambito urbano
sicuramente problemi non ce ne sono.

esempio semplice semplice:

strada asfaltata che poi finisce, se non c'è modo di proseguire nemmeno a
piedi utilizzo noexit=yes e sono a posto.

ma se ci spostiamo in ambito extraurbano o addirittura montano la situazione
si fa molto più liquida.

al solito vi pongo alcuni esempi per chiedervi cosa ne pensate:

1) sentiero che da ben visibile termina di colpo dove comincia un prato ma
volendo potrei proseguire a piedi in mezzo al prato senza traccia segnalata,
quindi non metto nulla?
2) sentiero che da ben visibile poi diventa impossibile da seguire a causa
della vegetazione faccio noexit=yes + obstacle=vegetation
3) situazione quasi identica alla prima: sentiero che da ben visibile
termina di colpo e si perde nel sottobosco non fitto quindi volendo potrei
proseguire [ armato di bussola ;-) ] che faccio?
4) sentiero diciamo di "servizio" che porta ad una casetta isolata di
montagna, a meno che traccio questo sentiero fino a connettermi alla porta
di casa, come mi comporto? in questo caso ci sta noexit=yes laddove il
sentiero in questione "finisce" pochi metri prima della casetta stessa?


concludendo in relazione all'utilizzo di noexit=yes non sempre (o quasi mai
in montagna) dove il sentiero ben segnato termina ci si trova di fronte ad
un muro!! quindi come ci comportiamo?

grazie

--enrico




--
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-de] Rein unterirdische Gebäude?

[Martin Koppenhoefer]

Am Mi., 12. Dez. 2018 um 13:12 Uhr schrieb Tom Pfeifer <
t.pfei...@computer.org>:

> Unsere Mapperkollegen im Geoportal/ALKIS/Berlin unterscheiden jedenfalls
> "Gebäude" und "Bauwerke",
> die ich in unterschiedlichen ALKIS-Layern aufrufen kann. In "Gebäude"
> finde ich sichtbare Häuser,
> während "Bauwerke" mir Tunnel, Brücken, flach überdeckte Tiefgaragen und
> bauliche Straßenanlagen
> liefert.



"bauliche Anlage" ist die Obermenge in der LBO wenn es um Gebäude geht,
aber das betrifft nicht Anlagen des öffentlichen Verkehrs, die sind anders
geregelt.
§2  z.B. http://www.bauordnungen.de/Berlin.pdf
(1) ... Bauliche Anlagen sind mit dem Erdboden verbundene, aus Bauprodukten
hergestellte Anlagen; eine Verbindung mit dem Boden besteht auch dann, wenn
die Anlage
durch eigene Schwere auf dem Boden ruht oder auf ortsfesten Bahnen begrenzt
beweglich
ist oder wenn die Anlage nach ihrem Verwendungszweck dazu bestimmt ist,
überwiegend
ortsfest benutzt zu werden.
Bauliche Anlagen sind auch
1. Aufschüttungen und Abgrabungen,
2. Lagerplätze, Abstellplätze und Ausstellungsplätze,
3. Sport- und Spielflächen,
4. Campingplätze, Wochenendplätze und Zeltplätze,
5. Freizeit- und Vergnügungsparks,
6. Stellplätze für Kraftfahrzeuge,
7. Gerüste,
8. Hilfseinrichtungen zur statischen Sicherung von Bauzuständen.

In der Honorarordnung der Planer wird unterschieden zwischen Gebäuden,
Ingenieurbauwerken, Verkehrsanlagen, Tragwerken und Anlagen der Technischen
Ausrüstung.

Im BGB kommt der Begriff Bauwerk vor, habe aber keine Definition gefunden,
auch Gebäude kommt vor ohne dass festgelegt wird, was damit gemeint ist
bzw. ob es was anderes ist: https://www.gesetze-im-internet.de/bgb/__94.html
und §95.

Tiefgaragen die nur dem Parken dienen sind wohl Ingenieursbauwerke, sie
könnten ggf. unter den Begriff Gebäude fallen, wenn auch Lagermöglichkeiten
vorhanden sind. Selbst wenn ein Haus auf einer Tiefgarage steht wird das
unter Umständen als 2 getrennte Objekte gesehen, s.z.B. hier
https://www.baunetz.de/recht/Tiefgarage_als_eigenstaendiges_Ingenieurbauwerk__44794.html

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