Re: [OSM-talk] 2 Great Lakes missing

[James]

someone probably broke them again... happens quite often sadly...

On Thu., Aug. 9, 2018, 9:05 p.m. Daniel Koć,  wrote:

> Hi,
>
> Is anybody aware what happened to Lake Superior and Lake Huron?
>
> https://www.openstreetmap.org/relation/4039486
>
> https://www.openstreetmap.org/relation/1205151
>
>
> They were changed 20 and 3 days ago, respectively, and they stopped
> being rendered both on default and on humanitarian map.
>
>
> --
> "My method is uncertain/ It's a mess but it's working" [F. Apple]
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-it] Nomi di strade/piazze

[Martin Koppenhoefer]

sent from a phone

> On 2. Aug 2018, at 14:32, Alessandro Palmas  
> wrote:
> 
> Anche questo potrebbe essere visto come un'attività non strategica per un 
> local chapter che potrebbe tranquillamente ribaltare il discorso dicendo che 
> se ne dovrebbe occupare OSMF o qualcun altro. Sarebbe però un buon tramite 
> col quale i diversi capitoli rimarrebbero in contatto.


per noi potrebbe essere strategico perché Nominatim funziona particolarmente 
male in Italia (e qualche altro paese come la Spagna e la Francia)


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

[OSM-talk] 2 Great Lakes missing

[Daniel Koć]

Hi,

Is anybody aware what happened to Lake Superior and Lake Huron?

https://www.openstreetmap.org/relation/4039486

https://www.openstreetmap.org/relation/1205151


They were changed 20 and 3 days ago, respectively, and they stopped
being rendered both on default and on humanitarian map.


-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]



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

Re: [Talk-de] access tag / was möglich oder erlaubt ist Was: Wege des WSV an den Kanälen / tagging

[Martin Koppenhoefer]

sent from a phone

> On 9. Aug 2018, at 22:15, Florian Lohoff  wrote:
> 
> Er sagt das ist rechtlich einwandfrei solange da nicht ein Verbot
> für Fahrzeuge steht bzw das als reiner Fuß-/Radweg ausgezeichnet ist.
> Ansonsten ist das wie eine reine "Breitenbeschränkung".


ich schrieb daher ja, wenn man den Poller umfahren muss (nicht drumherum, 
sondern darüber, deutsch ist hier mal untypisch mehrdeutig). Bei einem Poller 
auf der _Straße_ ohne Schild kann man weiterfahren wenn man durchpasst (wo es 
mehrdeutig wäre sind daher normalerweise Schilder).


> 
> Und das ich Treppen nicht mit dem Rad runter darf - Dafür hätte ich mal
> gerne eine Rechtsgrundlage. Ich denke das wenn was passiert ist der
> Radfahrer dran weil er auf der Treppe sein Fahrzeug nicht sauber unter
> Kontrolle hat - Aber Schlechterdings verboten - das glaube ich nicht.


Treppen sind Fußwege, an Gehwegen steht auch nicht überall ein Schild, trotzdem 
darf man die nicht befahren. Treppen sind keine _Fahr_bahnen.
par.2 StVO https://www.gesetze-im-internet.de/stvo_2013/__2.html


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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[john whelan]

Think about what you have just said.  If I have an internet connection
available and I'm running JOSM how would I find them if Nominatim  wasn't
available.

Cheerio John

On Thu, 9 Aug 2018, 6:28 pm Yves,  wrote:

> If those codes can be encoded and decoded offline, it should be dealt with
> offline by the client, not a server-side application like Nominatim.
> Yves
>
> Le 10 août 2018 00:04:56 GMT+02:00, Vao Matua  a
> écrit :
>>
>> I use Plus Codes with OSMand offline and it works well. If we are worried
>> about the number of tags we should remove all tags and convince everyone to
>> just use lat/long.
>> The ability to verbally tell someone a location like 47RP+XG
>> Dar-es-Salaam is much easier than -6.85748/39.28613
>> Suspend disbelief, sometimes new things are better.
>>
>> On Thu, Aug 9, 2018 at 2:57 PM, john whelan 
>> wrote:
>>
>>> So if OSMand or some such could handle them in a search off line that
>>> would be acceptable?  They are generated from long and lat after all.
>>>
>>> My feeling is adding them to Nominatim is not a perfect solution as it
>>> implies OpenStreetMap supports them rather than something else but from a
>>> practical point of view it would solve a lot of problems.  Not least the
>>> idea that tags get added to every building with some sort of address code.
>>> How many different codes for buildings are we going to see?
>>>
>>> Currently locally addr: has number, postcode and street name so its
>>> difficult to logically say its one rule for one country and another for a
>>> different one.
>>>
>>> Cheerio John
>>>
>>> On 9 August 2018 at 17:40, Vao Matua  wrote:
>>>
 It is a good idea for the unconnected part of the world. If you have
 access to a website you might as well use three-silly-words.
 If you have a stand-alone app with the Plus Codes on the buildings then
 someone can easily communicate that information.
 Internet connectivity is not world wide.

 On Thu, Aug 9, 2018 at 2:27 PM, Frederik Ramm 
 wrote:

> Hi,
>
> On 08/09/2018 10:48 PM, Vao Matua wrote:
> > The Tanzania Development trust has calculated the Plus Code addresses
> > for 17 million building points in Tanzania and have added a sample
> > village (1800 points) as a test.
>
> This is not a good idea. Please don't do it. It does not make sense! If
> someone searches for a plus code on a web site, the site can compute
> the
> lat/lon and take you there, WITHOUT having to add billions of plus code
> points all over the word.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09"
> E008°23'33"
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>


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


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

Re: [Talk-es] Proyecto de mapeado de info sobre bicicletas

[Miguel Sevilla-Callejo]

Hola Patricio,

Disculpa no te haya contestado antes (es lo que tienen las vacaciones), en
Zaragoza tenemos una "línea" de acción sobre el tema que planteas que
llamamos #zizlabilidad y del que puedes ver algo en la web del grupo de
Mapeado Colaborativo: http://mapcolabora.org/project/ziclabilidad/

Así mismo, hace un año y pico presentamos una comunicación que despues
publicaron sobre el tema en un congreso sobre la bicicleta que se
desarrolló en Zaragoza:
https://github.com/mapcolabora/mapcolabora_material/tree/master/articulos

No se si es lo que estas buscando exactamente pero quizá te pueda interesar
nuestra experiencia.

Ah! por último contarte que andamos por promover un "fotomapeado a nivel de
calle" de la infraestructura ciclista con colectivos de la ciudad... pero
esto va un poco lento.

Ya nos dirás

Un saludo

--
*Miguel Sevilla-Callejo*
Doctor en Geografía


On Mon, 23 Jul 2018 at 19:24, Patricio Soriano  wrote:

> Buenas tardes,
>
> En la pasada reunión de geoinquietos Córdoba, se no pidió colaboración
> para realizar una actividad dentro de la Semana de la Movilidad
>  que se desarrollará en Septiembre.
>
> En un principio nos propusieron unos paseo en bici para documentar los
> nuevos carriles que se están construyendo, pero desde el grupo lo vimos
> poco operativo y con poco recorrido. Una segunda opción, que parece que es
> la que va a prosperar, es hacer que durante la semana de la actividad y
> con  la etiqueta #mapeomovilidad
>  se vayan
> identificando los elementos vinculados con el tema bici (carriles, señales
> de tráfico, aparcamientos, tiendas...) y al final se realice un taller para
> meter esa información, en el caso que no esté, en OSM.
>
> Todavía está todo un poco en el aire, pero me gustaría saber si conocéis
> experiencias parecidas, otras aspectos vinculados con la bici que se puedan
> documentar, herramientas que podamos usar (ej. estoy investigando un script
> en Python para recuperar los tuis). Hace cuatro años organizamos algo
> parecido y contamos con una base (
> https://wiki.osgeo.org/wiki/Opencyclecordoba
> http://slides.com/patriciosorianocastro/taller-osm-del-i-opencyclecordoba) 
> pero
> cualquier ayuda nos vendría genial.
>
> Muchas gracias de antemano
> --
> Patricio J. Soriano Castro
> *Geógrafo :: Tecnologías de Información Geográfica*
> www.sigdeletras.com :: @SIGdeletras  ::
> Linkedin 
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [OSM-talk-fr] Artefact ou erreur de données ?

[Philippe Verdy]

J'ai un peu "tittillé" le passage à niveau en le recréant sur un nouveau
nœud et supprimant l'ancien nœud, ça règle le problème du chemin parasite
(les mises à jour de rendu sont en cours pour les niveaux de zoom plus
bas). Au passage j'ai un peu amélioré la précision de placement de la ligne
de chemin de fer.

Le 9 août 2018 à 23:28, Philippe Verdy  a écrit :

> La modif n'a pas d'effet sur le chemin parasite, il semble que le rendu
> curieux soit lié au fait que le serveur de rendu a bien deux chemins mais
> il n'en trouve qu'un correctement tagué dans sa base mais avec une
> géométrie incomplète, et l'autre vient de la géométrie qu'il voit mais pas
> tagué correctement. Un changeset est visiblement passé sur ce serveur, mais
> visiblement pas au complet, il était peut-être tronqué quand il a été
> chargé, et cela a laissé ces parasites avec des modifs incomplètement
> chargées sur sa base esclave.
> Je reste persuadé que c'est un problème de remise en route des serveurs
> migré de Londres à Amsterdam: suite à l'arrêt il a du manquer certains
> diffs ou des diffs incomplets ou un problème d'espace disque ou d'espace
> temporaire saturé (suite aux scripts de migration) ou de connectivité
> temporaire (erreurs de caches DNS par exemple) a pu causer ce bogue. On
> voit ces bogues à divers endroits, tous autour des modifications effectuées
> durant une seule heure environ.
>
> La désynchronisation des "diffs" semble bien la bonne piste. Cela est déjà
> arrivé aussi sur les serveurs de rendu d'OSM France et chaque fois il a
> fallu repartir en chargeant un dump complet postérieur aux problèmes de
> diffs constatés puis rechargeant les autres nouveaux diffs émis depuis ce
> dump.
>
> En terme de tags je ne vois pas de problème, et les rendus d'OSM France ou
> Allemagne ou Mapquest ne sont pas impactés ici (mais eux n'ont pas changé
> d'hébergement et de config réseau pendant ce temps). De toute façon comme
> le bogue est connu et signalé, OSM.org trouvera bien une solution (quitte à
> arrêter deux de ses 4 serveurs de rendu et avoir un peu plus de "lag"
> pendant ce temps là, le temps de recharger leur base).
>
> En tout cas une chose est sure, cela ne vient pas des caches de tuiles
> (sur les 21 sites du CDN d'OSM.org) : ils sont bien à jour et pas en retard.
>
>
> Le 9 août 2018 à 22:46,  a écrit :
>
>> Le 09/08/2018 à 19:09, marc marc - marc_marc_...@hotmail.com a écrit :
>>
>> si tu regardes le point qui a visuelement un 
>> problèmehttps://www.openstreetmap.org/node/252291030
>> il ne fait plus partie que d'un rail. donc problèe entre temps résolu
>> et lag dans la maj du rendu (il y a un bug majeur sur 2 serveur de rendu 
>> osm.org)
>>
>> Ça fait 9 mois que baleineaux
>>  l'a mis comme
>> level_crossing d'un seul éléments ferré et d'un non ferré.
>> Et 12 jours qu'il a mis à jour la liaison https://www.openstreetmap.org/
>> way/262550757#map=12/47.5247/-3.0738=H
>>
>> Je vois que Philippe a titillé le chemin en lui mettant sa référence (et
>> en supposant une vitesse de 80 km/h).
>> La référence est bien affichée mais au niveau 18 on a un curieux rendu :
>> https://www.openstreetmap.org/query?lat=47.67901=-3.0216
>> 7#map=18/47.67904/-3.02191
>>
>> https://a.tile.openstreetmap.org/18/128871/91473.png
>> [image: https://a.tile.openstreetmap.org/18/128871/91473.png]
>> Sachant que le railway va de part et d'autre du PAN...
>>
>> N.B. : le décalage horaire ne me semble pas une bonne piste.
>> Jean-Yvon
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Yves]

If those codes can be encoded and decoded offline, it should be dealt with 
offline by the client, not a server-side application like Nominatim.
Yves 

Le 10 août 2018 00:04:56 GMT+02:00, Vao Matua  a écrit :
>I use Plus Codes with OSMand offline and it works well. If we are
>worried
>about the number of tags we should remove all tags and convince
>everyone to
>just use lat/long.
>The ability to verbally tell someone a location like 47RP+XG
>Dar-es-Salaam
>is much easier than -6.85748/39.28613
>Suspend disbelief, sometimes new things are better.
>
>On Thu, Aug 9, 2018 at 2:57 PM, john whelan 
>wrote:
>
>> So if OSMand or some such could handle them in a search off line that
>> would be acceptable?  They are generated from long and lat after all.
>>
>> My feeling is adding them to Nominatim is not a perfect solution as
>it
>> implies OpenStreetMap supports them rather than something else but
>from a
>> practical point of view it would solve a lot of problems.  Not least
>the
>> idea that tags get added to every building with some sort of address
>code.
>> How many different codes for buildings are we going to see?
>>
>> Currently locally addr: has number, postcode and street name so its
>> difficult to logically say its one rule for one country and another
>for a
>> different one.
>>
>> Cheerio John
>>
>> On 9 August 2018 at 17:40, Vao Matua  wrote:
>>
>>> It is a good idea for the unconnected part of the world. If you have
>>> access to a website you might as well use three-silly-words.
>>> If you have a stand-alone app with the Plus Codes on the buildings
>then
>>> someone can easily communicate that information.
>>> Internet connectivity is not world wide.
>>>
>>> On Thu, Aug 9, 2018 at 2:27 PM, Frederik Ramm 
>>> wrote:
>>>
 Hi,

 On 08/09/2018 10:48 PM, Vao Matua wrote:
 > The Tanzania Development trust has calculated the Plus Code
>addresses
 > for 17 million building points in Tanzania and have added a
>sample
 > village (1800 points) as a test.

 This is not a good idea. Please don't do it. It does not make
>sense! If
 someone searches for a plus code on a web site, the site can
>compute the
 lat/lon and take you there, WITHOUT having to add billions of plus
>code
 points all over the word.

 Bye
 Frederik

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

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

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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Frederik Ramm]

Hi,

On 08/10/2018 12:04 AM, Vao Matua wrote:
> I use Plus Codes with OSMand offline and it works well. If we are
> worried about the number of tags we should remove all tags and convince
> everyone to just use lat/long.

There's absolutely nothing to be said against OSMand using plus codes,
indeed, this proves that plus codes can be used perfectly well without
adding them to the OSM database.

I'm not sure I understand what you mean by "remove all tags and convince
everyone to just use lat/long". Our tags describe not *where* something
is, but *what* something is, a feature certainly as useful in Tanzania
as elsewhere. The description of *where* something is does indeed happen
by latitude and longitude in OSM.

In some countries we add street addresses, but only because there's no
mathematical way to derive a lat/long from the address. If it were
possible to apply a formula to an address and arrive at a lat/long, or
apply a formula to a lat/long and arrive at a street address, nobody
would be mapping them.

Just as nobody should be mapping plus codes. Put the formula in the
device (e.g. OSMand) and you have plus code support for the whole
planet. No need to import billions of address points. It's faster,
cleaner, and less likely to break.

Bye
Frederik

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

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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Vao Matua]

I use Plus Codes with OSMand offline and it works well. If we are worried
about the number of tags we should remove all tags and convince everyone to
just use lat/long.
The ability to verbally tell someone a location like 47RP+XG Dar-es-Salaam
is much easier than -6.85748/39.28613
Suspend disbelief, sometimes new things are better.

On Thu, Aug 9, 2018 at 2:57 PM, john whelan  wrote:

> So if OSMand or some such could handle them in a search off line that
> would be acceptable?  They are generated from long and lat after all.
>
> My feeling is adding them to Nominatim is not a perfect solution as it
> implies OpenStreetMap supports them rather than something else but from a
> practical point of view it would solve a lot of problems.  Not least the
> idea that tags get added to every building with some sort of address code.
> How many different codes for buildings are we going to see?
>
> Currently locally addr: has number, postcode and street name so its
> difficult to logically say its one rule for one country and another for a
> different one.
>
> Cheerio John
>
> On 9 August 2018 at 17:40, Vao Matua  wrote:
>
>> It is a good idea for the unconnected part of the world. If you have
>> access to a website you might as well use three-silly-words.
>> If you have a stand-alone app with the Plus Codes on the buildings then
>> someone can easily communicate that information.
>> Internet connectivity is not world wide.
>>
>> On Thu, Aug 9, 2018 at 2:27 PM, Frederik Ramm 
>> wrote:
>>
>>> Hi,
>>>
>>> On 08/09/2018 10:48 PM, Vao Matua wrote:
>>> > The Tanzania Development trust has calculated the Plus Code addresses
>>> > for 17 million building points in Tanzania and have added a sample
>>> > village (1800 points) as a test.
>>>
>>> This is not a good idea. Please don't do it. It does not make sense! If
>>> someone searches for a plus code on a web site, the site can compute the
>>> lat/lon and take you there, WITHOUT having to add billions of plus code
>>> points all over the word.
>>>
>>> Bye
>>> Frederik
>>>
>>> --
>>> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>>>
>>> ___
>>> talk mailing list
>>> talk@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk
>>>
>>
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
>>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Martin Koppenhoefer]

sent from a phone

> On 9. Aug 2018, at 23:57, john whelan  wrote:
> 
> My feeling is adding them to Nominatim is not a perfect solution as it 
> implies OpenStreetMap supports them rather than something else


on the other hand we are supporting proprietary, copyrighted systems like 
postcodes. If a location coding system is freely and openly available and has 
gained some traction, I feel we should try to support it.


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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Martin Koppenhoefer]

sent from a phone

> On 9. Aug 2018, at 23:40, Vao Matua  wrote:
> 
> Internet connectivity is not world wide.


it is available everywhere, but you have to be able and willing to afford it 
(it might cost several orders of magnitude more than cellphone internet in 
europe).

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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[john whelan]

So if OSMand or some such could handle them in a search off line that would
be acceptable?  They are generated from long and lat after all.

My feeling is adding them to Nominatim is not a perfect solution as it
implies OpenStreetMap supports them rather than something else but from a
practical point of view it would solve a lot of problems.  Not least the
idea that tags get added to every building with some sort of address code.
How many different codes for buildings are we going to see?

Currently locally addr: has number, postcode and street name so its
difficult to logically say its one rule for one country and another for a
different one.

Cheerio John

On 9 August 2018 at 17:40, Vao Matua  wrote:

> It is a good idea for the unconnected part of the world. If you have
> access to a website you might as well use three-silly-words.
> If you have a stand-alone app with the Plus Codes on the buildings then
> someone can easily communicate that information.
> Internet connectivity is not world wide.
>
> On Thu, Aug 9, 2018 at 2:27 PM, Frederik Ramm  wrote:
>
>> Hi,
>>
>> On 08/09/2018 10:48 PM, Vao Matua wrote:
>> > The Tanzania Development trust has calculated the Plus Code addresses
>> > for 17 million building points in Tanzania and have added a sample
>> > village (1800 points) as a test.
>>
>> This is not a good idea. Please don't do it. It does not make sense! If
>> someone searches for a plus code on a web site, the site can compute the
>> lat/lon and take you there, WITHOUT having to add billions of plus code
>> points all over the word.
>>
>> Bye
>> Frederik
>>
>> --
>> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-it] Cammino del beato Enrico, tag network.

[Martin Koppenhoefer]

sent from a phone

> On 9. Aug 2018, at 19:12, Volker Schmidt  wrote:
> 
> Conosco pezzi di percorsi anche a lunga percorrenza (per bici) che portano 
> sul campo  anche cinque segnaletiche diverse, perché fanno parte di così 
> tanti percorsi. 


+1, non vedo nessun problema nel avere più percorsi segnati sullo stesso 
tratto, in Germania è quasi la regola, non l’eccezione. Ci sono vari simboli 
(per esempio rombo giallo, quadrato rosso, due linee blu, ecc., oppure simboli 
come un castello, un ape, una conchiglia, ...) e basta seguire il “suo” segno. 
L’unica cosa da stare attenti è di usare simboli difficilmente confondibili 
(certo, se tutti usano rosso bianco rosso, e sullo stesso tratto c’è 111 e 11, 
e dopo un po’ un 111 diventa un 11 per erosione, saremmo nei guai).

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

[OSM-talk-fr] Lieux d'accueil enfants-parents

[deuzeffe]

Bonsoir,

Les LAEP (ou parfois LAPE) sont des structures (~ 1500 ) officiellement 
reconnues et soutenues par la CAF (cf 
http://www.caf.fr/allocataires/vies-de-famille/futur-parent/garde-d-enfant/les-lieux-d-accueil-enfants-parents 
; il y a même une base en LO/OL),


C'est donc dans le thème enfance. Mais quel(s) tag(s) ? Ce ne sont pas 
des kinderkarten, même si ça peut s'en rapprocher. Quel tag pourrait-on 
utiliser voire créer ?


Merci pour vos réponses, quelles qu'elles soient.
--
deuzeffe

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

Re: [Talk-it] Cammino del beato Enrico, tag network.

[Martin Koppenhoefer]

sent from a phone

> On 9. Aug 2018, at 19:12, Volker Schmidt  wrote:
> 
> Come misura provvisoria propongo cambiare le due relazione da "con 
> segnaletica", cioè da reazaione route normale a "percorso proposto", cioè 
> aggiungerei "state=proposed" alla relazione.


io lo vedo dal punto di vista della verificabilità. Se nessuno si ha impegnato 
a segnalare il percorso sul terreno, non è da inserire. I libri sono coperti da 
copyright, come anche gli itinerari in generale. Poi ci sono infiniti percorsi 
suggeriti nelle guide turistiche.

Oggetti del tipo proposed non si inseriscono generalmente, solo in via 
eccezionale, ma qui non vedo i presupposti.


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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Vao Matua]

It is a good idea for the unconnected part of the world. If you have access
to a website you might as well use three-silly-words.
If you have a stand-alone app with the Plus Codes on the buildings then
someone can easily communicate that information.
Internet connectivity is not world wide.

On Thu, Aug 9, 2018 at 2:27 PM, Frederik Ramm  wrote:

> Hi,
>
> On 08/09/2018 10:48 PM, Vao Matua wrote:
> > The Tanzania Development trust has calculated the Plus Code addresses
> > for 17 million building points in Tanzania and have added a sample
> > village (1800 points) as a test.
>
> This is not a good idea. Please don't do it. It does not make sense! If
> someone searches for a plus code on a web site, the site can compute the
> lat/lon and take you there, WITHOUT having to add billions of plus code
> points all over the word.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-it] Aggiornamento mappe su OsmAnd+ e MAPS:ME

[Martin Koppenhoefer]

sent from a phone

> On 8. Aug 2018, at 22:13, Alessandro Vitali  wrote:
> 
> Sbaglio qualcosa o hanno frequenze di aggiornamento differenti?


su maps.me gli aggiornamenti non sono stati molto frequenti in passato. Si va 
(ios) in basso a destra (icona con 3 righe), poi mappe, poi aggiornamento 




> Oppure centra qualcosa il fatto dello spostamento dei server OSM?


no, non credo 


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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Frederik Ramm]

Hi,

On 08/09/2018 10:48 PM, Vao Matua wrote:
> The Tanzania Development trust has calculated the Plus Code addresses
> for 17 million building points in Tanzania and have added a sample
> village (1800 points) as a test.

This is not a good idea. Please don't do it. It does not make sense! If
someone searches for a plus code on a web site, the site can compute the
lat/lon and take you there, WITHOUT having to add billions of plus code
points all over the word.

Bye
Frederik

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

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

Re: [OSM-talk-fr] Artefact ou erreur de données ?

[Philippe Verdy]

La modif n'a pas d'effet sur le chemin parasite, il semble que le rendu
curieux soit lié au fait que le serveur de rendu a bien deux chemins mais
il n'en trouve qu'un correctement tagué dans sa base mais avec une
géométrie incomplète, et l'autre vient de la géométrie qu'il voit mais pas
tagué correctement. Un changeset est visiblement passé sur ce serveur, mais
visiblement pas au complet, il était peut-être tronqué quand il a été
chargé, et cela a laissé ces parasites avec des modifs incomplètement
chargées sur sa base esclave.
Je reste persuadé que c'est un problème de remise en route des serveurs
migré de Londres à Amsterdam: suite à l'arrêt il a du manquer certains
diffs ou des diffs incomplets ou un problème d'espace disque ou d'espace
temporaire saturé (suite aux scripts de migration) ou de connectivité
temporaire (erreurs de caches DNS par exemple) a pu causer ce bogue. On
voit ces bogues à divers endroits, tous autour des modifications effectuées
durant une seule heure environ.

La désynchronisation des "diffs" semble bien la bonne piste. Cela est déjà
arrivé aussi sur les serveurs de rendu d'OSM France et chaque fois il a
fallu repartir en chargeant un dump complet postérieur aux problèmes de
diffs constatés puis rechargeant les autres nouveaux diffs émis depuis ce
dump.

En terme de tags je ne vois pas de problème, et les rendus d'OSM France ou
Allemagne ou Mapquest ne sont pas impactés ici (mais eux n'ont pas changé
d'hébergement et de config réseau pendant ce temps). De toute façon comme
le bogue est connu et signalé, OSM.org trouvera bien une solution (quitte à
arrêter deux de ses 4 serveurs de rendu et avoir un peu plus de "lag"
pendant ce temps là, le temps de recharger leur base).

En tout cas une chose est sure, cela ne vient pas des caches de tuiles (sur
les 21 sites du CDN d'OSM.org) : ils sont bien à jour et pas en retard.


Le 9 août 2018 à 22:46,  a écrit :

> Le 09/08/2018 à 19:09, marc marc - marc_marc_...@hotmail.com a écrit :
>
> si tu regardes le point qui a visuelement un 
> problèmehttps://www.openstreetmap.org/node/252291030
> il ne fait plus partie que d'un rail. donc problèe entre temps résolu
> et lag dans la maj du rendu (il y a un bug majeur sur 2 serveur de rendu 
> osm.org)
>
> Ça fait 9 mois que baleineaux
>  l'a mis comme
> level_crossing d'un seul éléments ferré et d'un non ferré.
> Et 12 jours qu'il a mis à jour la liaison https://www.openstreetmap.org/
> way/262550757#map=12/47.5247/-3.0738=H
>
> Je vois que Philippe a titillé le chemin en lui mettant sa référence (et
> en supposant une vitesse de 80 km/h).
> La référence est bien affichée mais au niveau 18 on a un curieux rendu :
> https://www.openstreetmap.org/query?lat=47.67901=-3.
> 02167#map=18/47.67904/-3.02191
>
> https://a.tile.openstreetmap.org/18/128871/91473.png
> [image: https://a.tile.openstreetmap.org/18/128871/91473.png]
> Sachant que le railway va de part et d'autre du PAN...
>
> N.B. : le décalage horaire ne me semble pas une bonne piste.
> Jean-Yvon
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Blake Girardot HOT/OSM]

On Thu, Aug 9, 2018 at 4:48 PM, Vao Matua  wrote:
> The Tanzania Development trust has calculated the Plus Code addresses for 17
> million building points in Tanzania and have added a sample village (1800
> points) as a test.
> https://www.openstreetmap.org/changeset/59213224
>
> The Python code on Github works great to calculate Plus Codes.
>
> We did used these tags:
> addr:pluscode:full  (the 8+2 digit full Plus Code)
> addr:pluscode:area (the first 4 digits of the full Plus Code which is a 1
> degree by 1 degree lat long area)
> addr:pluscode:local (the second 4 digits + last 2 digits which used with a
> local name becomes the local address)
>

This is really cool to hear!

I am a big fan of OLC / Pluse Codes

I passed this thread on to the folks at Google Zurich who created it
originally, not sure if they still work there or not, we last chatted
in 2016, but I am sure they will be glad to stop in and answer
questions if I can raise them.

Cheers
blake

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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Vao Matua]

The Tanzania Development trust has calculated the Plus Code addresses for
17 million building points in Tanzania and have added a sample village
(1800 points) as a test.
https://www.openstreetmap.org/changeset/59213224

The Python code on Github works great to calculate Plus Codes.

We did used these tags:
addr:pluscode:full  (the 8+2 digit full Plus Code)
addr:pluscode:area (the first 4 digits of the full Plus Code which is a 1
degree by 1 degree lat long area)
addr:pluscode:local (the second 4 digits + last 2 digits which used with a
local name becomes the local address)

On Thu, Aug 9, 2018 at 6:48 AM, Stefano  wrote:

> Hi,
> there's already a pull request
> https://github.com/openstreetmap/openstreetmap-website/pull/1818
>
> Stefano
>
> Il giorno gio 9 ago 2018 alle ore 15:45 Yuri Astrakhan <
> yuriastrak...@gmail.com> ha scritto:
>
>> I'm a big fan of plus codes, and even have a pending implementation of it
>> in the Elasticsearch (as an aggregation hashing function).  I doubt there
>> are any legal restrictions on using this - the code is licensed under
>> Apache 2, and Google states "Plus codes are free. There are no licensing
>> fees or other costs. The technology is open-sourced." at
>> https://plus.codes/
>> Not sure about the implementation complexities.
>>
>> On Thu, Aug 9, 2018 at 4:35 PM oleksiy.muzal...@bluewin.ch <
>> oleksiy.muzal...@bluewin.ch> wrote:
>>
>>> Open Location Codes are also referred to as "plus codes".  Since August
>>> 2015, Google Maps supports plus codes in their search engine. The algorithm
>>> is Open Source, licensed under the Apache License 2.0. and available on
>>> GitHub [1].
>>>
>>> A plus code, can be generated at: https://plus.codes/ . It can be
>>> entered at the Google Maps search input box to find a location. A plus sign
>>> "+" is inserted in the code for recognition.
>>>
>>> It would be nice to have an interoperability. For example, a customer
>>> uses Google Map, but a dispatcher in a Call Center the OpenStreetMap. The
>>> OLC has got some interesting features:
>>>
>>> "Open Location Codes are derived from latitude and longitude
>>> coordinates, so they already exist everywhere. They are similar in length
>>> to a telephone number -- 849VCWC8+R9, for example -- but can often be
>>> shortened to only four or six digits when combined with a locality
>>> (CWC8+R9, Mountain View). Locations close to each other have similar codes.
>>> They can be encoded or decoded offline. The character set avoids similar
>>> looking characters, to reduce confusion and errors, and avoids vowels to
>>> make it unlikely that a code spells existing words.The Open Location Code
>>> is not case-sensitive, and can therefore be easily exchanged over the
>>> phone." [1]
>>>
>>> [1] https://en.wikipedia.org/wiki/Open_Location_Code
>>>
>>> Best regards,
>>> Oleksiy
>>>
>>> ___
>>> talk mailing list
>>> talk@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk
>>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Artefact ou erreur de données ?

[osm . sanspourriel]

Le 09/08/2018 à 19:09, marc marc - marc_marc_...@hotmail.com a écrit :


si tu regardes le point qui a visuelement un problème
https://www.openstreetmap.org/node/252291030
il ne fait plus partie que d'un rail. donc problèe entre temps résolu
et lag dans la maj du rendu (il y a un bug majeur sur 2 serveur de rendu
osm.org)
Ça fait 9 mois que baleineaux 
 l'a mis comme 
level_crossing d'un seul éléments ferré et d'un non ferré.
Et 12 jours qu'il a mis à jour la liaison 
https://www.openstreetmap.org/way/262550757#map=12/47.5247/-3.0738=H


Je vois que Philippe a titillé le chemin en lui mettant sa référence (et 
en supposant une vitesse de 80 km/h).
La référence est bien affichée mais au niveau 18 on a un curieux rendu : 
https://www.openstreetmap.org/query?lat=47.67901=-3.02167#map=18/47.67904/-3.02191


https://a.tile.openstreetmap.org/18/128871/91473.png
https://a.tile.openstreetmap.org/18/128871/91473.png
Sachant que le railway va de part et d'autre du PAN...

N.B. : le décalage horaire ne me semble pas une bonne piste.
Jean-Yvon
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Cammino del beato Enrico, tag network.

[Cascafico Giovanni]

Il 9 ago 2018 7:13 PM, "Volker Schmidt"  ha scritto:


.
La problematica delle sovvraposizione di percorsi è reale, e serve una
soluzione sia per la segnaletica, sia per la sucessiva mappatura in OSM.
Conosco pezzi di percorsi anche a lunga percorrenza (per bici) che portano
sul campo  anche cinque segnaletiche diverse, perché fanno parte di così
tanti percorsi.


Io non vedo grandi problemi per questo, rendering a parte (non si mappa per
il). Parafrasando
un pelato del passato: molti percorsi, molto onore!

IMHO i problemi ci sono quando esistono piu versioni dell stesso percorso.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-de] access tag / was möglich oder erlaubt ist Was: Wege des WSV an den Kanälen / tagging

[Florian Lohoff]

On Thu, Aug 09, 2018 at 05:31:41PM +0200, Martin Koppenhoefer wrote:
> > Da kommen wir aber wieder dahin was die access tags meinen. Sind access
> > tags das was erlaubt ist, oder das was möglich ist.

> eine physische Barriere hat auch rechtliche Auswirkungen. Wenn Du
> einen Poller umfährst um dahinter weiterzufahren ist das nicht nur
> Sachbeschädigung am Poller sondern auch ein Verkehrsdelikt. Du darfst
> z.B. auch keine Treppen mit dem Moto-cross rad befahren, auch wenn da
> kein Schild ist, und du darfst als Fußgänger überall frei in der
> offenen Landschaft gehen (in Deutschland), auch auf Privatgrund,
> sofern Du nicht die Frucht beschädigst (z.B. gemähte Wiese) und:
> sofern es nicht umfriedet ist. Wenn ein Zaun drumrum ist darfst du
> nicht rein.

Das sehe ich anders - Ein Mapper und Polizist hier in der Gegend
ist immer mit seinem Elektrofahrzeug unterwegs. Das ist ein
CityEL - Der ist so schmal das der zwischen den Pollern typischweise
durchpasst. 

Er sagt das ist rechtlich einwandfrei solange da nicht ein Verbot
für Fahrzeuge steht bzw das als reiner Fuß-/Radweg ausgezeichnet ist.
Ansonsten ist das wie eine reine "Breitenbeschränkung".

Und das ich Treppen nicht mit dem Rad runter darf - Dafür hätte ich mal
gerne eine Rechtsgrundlage. Ich denke das wenn was passiert ist der
Radfahrer dran weil er auf der Treppe sein Fahrzeug nicht sauber unter
Kontrolle hat - Aber Schlechterdings verboten - das glaube ich nicht.

Deshalb tagge ich auch access tags nur wo es explizit beschildert ist.
Nur weil da jemand poller aufstellt oder ein drängelgitter heisst
das nüscht - ja - Das Drängelgitter oder der Poller ist vielleicht
typischerweise nur zu Fuß und mit dem Rad passierbar - Dann tagge
ich das so (Auf der barrier) - Aber die Wege dürfen ja ggfs wenn
du drauf kommst trotzdem anders benutzt werden.

Flo
-- 
Florian Lohoff f...@zz.de
 UTF-8 Test: The  ran after a , but the  ran away


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

Re: [OSM-talk-fr] Artefact ou erreur de données ?

[Philippe Verdy]

les rendus des tuiles ne sont pourtant pas en retard. Et les données dans
leurs base non plus.

Je pense plutôt à un problème avec certains changesets en erreur qui n'ont
pas été envoyés/reçus ou ont été écrasés dans le flux (sans doute un
problème de mises à jours des dates sur certains serveurs transférés de
Londres à Amsterdam, par exemple une config de fuseau horaire incorrecte si
le serveur de temps a été changé et les serveurs n'avaient pas une horloge
réglée en UTC mais en heure locale; dans ce cas il y a pu y avoir un
décalage d'1 heure avant que le problème soit réglé, mais au moment du
changement le recul d'1 heure de l'horloge a pu provoquer des écrasements
ou un défaut de configuration des espaces de stockage réseau).

Bizarrement cela n'affecte que les serveurs de rendus d'OSM.org pas les
autres, ni la base de données maître. Ce serait donc un problème de mise à
jour de la base esclave (copiée/synchronisée sur le serveur de rendu) lié à
une reconfiguration incorrecte. Et pas du temps un "lag" (retard). A moins
de recharger cette base esclave (ou rejouer les diffs oubliés) je ne vois
pas comment le serveur de rendu peut corriger ses tuiles s'il a encore un
way qui aurait du être supprimé mais dont un noeud au moins a été gardé (le
noeud du passage à niveau).

On peut toujours essayer de fixer ça manuellement en découpant les 4
chemins connectés autour du passage à niveau pour former un trou, puis les
reconnecter à un nouveau noeud commun tagué en passage à niveau, puis
réunir les ways tronçonnés, et envoyer le tout: les 2 ways seront
préservés, seul le noeud du chemin de fer aura disparu, et le way parasite
qui l'utilisait devrait aussi être éliminé et plus tracé du tout. Mais il
est possible que cela ne marche pas non plus sur la base esclave, si ce
nouveau changeset ne passe pas car il supprimera l'ancien nœud de passage à
niveau "encore utilisé" par le way parasite (qui n'est déjà plus dans la
base maître).

De plus cette anomalie d'1 heure peut avoir eu des effets dans divers
autres endroits du monde sur la carte où il y aurait eu des écrasements
intempestifs par une désynchro des diffs.



Le 9 août 2018 à 19:09, marc marc  a écrit :

> Le 09. 08. 18 à 14:48, osm.sanspourr...@spamgourmet.com a écrit :
> > Je vois que sur OSM.org
> > 
> > ou OSM.fr
> > , la
> > ligne Auray-Quiberon (le Tire-Bouchon) est affublée d'une ligne directe
> > s'affranchissant des obstacles naturels. Je ne savais qu'avait été créée
> > une ligne TGV d'Auray à Quiberon ;-).
>
> si tu regardes le point qui a visuelement un problème
> https://www.openstreetmap.org/node/252291030
> il ne fait plus partie que d'un rail. donc problèe entre temps résolu
> et lag dans la maj du rendu (il y a un bug majeur sur 2 serveur de rendu
> osm.org)
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Cammino del beato Enrico, tag network.

[Volker Schmidt]

On 9 August 2018 at 18:02, Martin Koppenhoefer 
wrote:

> se non c’è segnaletica non lo mappiamo.
>

Io non sarei  così categorico. O meglio, ho cominciato vedere meglio le
varie faccie delle relazioni route.

Come misura provvisoria propongo cambiare le due relazione da "con
segnaletica", cioè da reazaione route normale a "percorso proposto", cioè
aggiungerei "state=proposed" alla relazione.


Non solo in questo caso ma anche in generale mi rendo conto che c'è un
aspetto che ho sottovalutato (anche nel "mio" settore delle ciclovie).
Una soluzione lungo termine non la vedo al momento.
La problematica delle sovvraposizione di percorsi è reale, e serve una
soluzione sia per la segnaletica, sia per la sucessiva mappatura in OSM.
Conosco pezzi di percorsi anche a lunga percorrenza (per bici) che portano
sul campo  anche cinque segnaletiche diverse, perché fanno parte di così
tanti percorsi.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Artefact ou erreur de données ?

[marc marc]

Le 09. 08. 18 à 14:48, osm.sanspourr...@spamgourmet.com a écrit :
> Je vois que sur OSM.org 
>  
> ou OSM.fr 
> , la 
> ligne Auray-Quiberon (le Tire-Bouchon) est affublée d'une ligne directe 
> s'affranchissant des obstacles naturels. Je ne savais qu'avait été créée 
> une ligne TGV d'Auray à Quiberon ;-).

si tu regardes le point qui a visuelement un problème
https://www.openstreetmap.org/node/252291030
il ne fait plus partie que d'un rail. donc problèe entre temps résolu
et lag dans la maj du rendu (il y a un bug majeur sur 2 serveur de rendu 
osm.org)

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

Re: [OSM-talk-fr] Modifier un pont erroné avec une dizaine de relations imbriquées au moins.

[Philippe Verdy]

Les tags sur les ways sont de toute façon indicatifs uniquement quand le
way entre dans une relation : la relation prime de toute façon en cas de
conflit éventuel.

Aussi bien les frontières que les cours d'eau devraient être modélisés dans
une relation contenant les way. Mais on a des tas de rues et de petits
cours d'eau sans relation du tout.

Ces tags sur le way quand il y a une relation sont plus des "rappels"
informant de la présence (éventuelle) d'une relation: s'il y a une
relation, c'est elle qui donne le nom a priori, mais pour les cours d'eau
c'est un peu plus compliqué car si l'ensemble du cours a un nom, il peut
changer localement le long du cours (notamment les cours d'eau sur
plusieurs pays ayant des langues officielles différentes, mais aussi dans
les estuaires (comme la Gironde et d'autres fleuves ouverts sur la remontée
d'eau marine jusqu'au dernier barrage, ou équipement comme une barrière
anti-sel, mais aussi les sections canalisées de fleuves et rivières qui
localement prennent le nom du canal, par exemple sur l'Ille à Rennes)
Le "name" alors sur le tracé est le nom local (ce serait un cas pour
utiliser "loc_name" plutôt que "name" réservé au cours d'eau naturel).
On a aussi des cas de noms encore plus locaux comme les noms d'écluses (là
on a décidé d'utiliser "lock_name" pour ne pas rompre la continuité des
noms des canaux et rivières canalisées).
Même chose avec les noms locaux de ponts et tunnels sur une rue/route.
D'une façon générale les frontières n'ont pas de nom bien défini sur leur
way, ces noms dérivent des relations qui les utilisent: les noms de
rivières et routes priment dans "'name".

Les autres attributs ne souffrent pas d'ambiguité/conflits en général entre
frontière et cours d'eau ou entre frontière et rue/route.

Mais il y a des conflits de valeurs sur "admin_level=*" (on a opté pour
utiliser sur le way la plus petite valeur), et sur "admin_type=*" ou
"boundary=*" : là on choisit en général de prendre la valeur d'"admin_type"
correspondant à l'admin_level le plus faible pour les frontières
"boundary=administrative", qui est aussi prioritaire sur les autres types
comme "boundary=political" sans "admin_level" (cas particulier: les
frontières religieuses qui ont aussi malheureusement un "admin_level" à ne
pas prendre en compte dans les priorités, cela aurait du être
"religion_level", mais on a des conflits "administratifs" dans des pays
multiconfessionnels qu'on ne peut pas régler sur les ways, uniquement sur
les relations) les valeurs données sont là aussi indicatives mais on les
choisit par degré d'importance administrative avant le reste.

Si on met encore des tags sur les ways au lieu des relations parentes,
c'est souvent par compatibilité avec plein d'outils et rendus qui eux ne
cherchent pas les relations parentes, qui elles aussi ne sont pas encore
obligatoires partout : ils sont aussi une aide utile pour les contributeurs
car ces tags permettent de distinguer facilement les chemins dans des
listes techniques d'objets qui ne sont pas pratiques à repérer avec juste
leur ID numérique. Mais des améliorations des éditeurs pourraient aller
chercher les relations parentes pour obtenir ces informations et les
afficher sans qu'on ait à les renseigner aussi sur les ways (hormi cas
spécial des noms locaux préférés aux noms globaux de l'objet dans leur
relation parente)

Le 3 août 2018 à 23:39, marc marc  a écrit :

> Le 03. 08. 18 à 11:27, Rpnpif a écrit :
> > Oui bien sûr, mais le problème n'est pas là. Le problème est la
> > superposition-fusion au mm près des tracés ou carrément le tagage type
> > squat dans les attributs du flux.
>
> l'idéal est d'avoir un way pour la rivière avec uniquement les tags de
> la rivière et utiliser ce way dans la relation boundary avec uniquement
> les tags qui concerne le boundary.
> mixer les 2 sur un way n'est pas top mais certains outils se servent
> encore des tags boundary sur les relations... hélas...
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] [HOT] Learning to Use Machine Learning - A learn along for folks who want to be using ML in their work.

[john whelan]

Of course the really nice thing to do would be to compare the new scanned
buildings with the
existing o
nes
then tag all the ones with an overlap where the old was shall we say twice
the size of the new.

It really could make a tremendous differ
ence to data quality especially if HOT ran a few clean up projects in the
worst areas.


Cheerio John

On 9 Aug 2018 11:32 am, "Dale Kunce"  wrote:

@Blake Girardot  Fantastic Job pulling together
all these resources for folks.

I'm really am excited for all the possibilities and time savings and better
data the machines will give us. However, with emphasis, I'm also excited by
the work that HOT is doing and has been doing to prepare for the machines.
To answer a lot of the questions will inevitably come up. For instance: How
will humans verify the results? What will a mapathon look like in 2 years?
Do we still need to trace X features? How do machines fit in with OSM
culture?

I believe firmly that OSM is best when a human is the one that makes the
final edit. I do see many workflows happening that will allow us to take
advantage of the great work that our corporate partners and community are
coming up with.

Looking forward to learning and working on these issues together.



On Thu, Aug 9, 2018 at 6:02 AM john whelan  wrote:

> One does hope that a manual check will be part of the process?
>
> Thanks John
>
> On 9 August 2018 at 08:10, Blake Girardot  wrote:
>
>> Dear Friends,
>>
>> In case you missed it, Dale Kunce tweeted this out yesterday:
>>
>> The day of Machine Learning and OSM/Humanitarian mapping reckoning is
>> getting closer. Very excited for the possibilities these new methods
>> have for @hotosm @RedCross. Next frontier is making HOT and
>> @TheMissingMaps more valuable than just a training dataset for the
>> machines.
>>
>> https://twitter.com/calimapnerd/status/1027275305440829440
>>
>> Toward that end, I have been watching and in some cases working with
>> various ML tool chains over the past 2 years and really, not having a
>> lot of luck with my level of skill and knowledge. I am a pretty
>> advanced sysadmin, comfortable on the command line, but understanding
>> the terminology and installations has been a bit beyond me.
>>
>> So if anyone is like me and sees all of these great tool chains and
>> would like to learn how to use them with your peers learning along
>> with you and hopefully some experts as well, I created a dedicated
>> #mlearning-basic channel on the OSM-US slack (
>> https://osmus-slack.herokuapp.com/ )
>>
>> OSM-US runs a lovely, informative, lively, international slack with
>> many channels and everyone is welcome!
>>
>> The #mlearning-basic channel is for the absolute beginner basics, how
>> to install and use the existing and emerging tools chains and OSM/OAM
>> data to generate usable vector data from Machine Learning quickly.
>>
>> You are all invited to join, but it is very basic. Hopefully some of
>> the ML experts from the projects below will be in there to hand hold
>> us newbies through actually making use of what we are seeing more and
>> more everyday. Excellent tool chains exist, world changing tool
>> chains, now we just need to get them into the hands of the people who
>> need and want to use them everyday :)
>>
>> Everyone is welcome and encouraged to join, it is intended to be kind
>> of a "learn-a-long". Our first project, my first project, is building
>> on the Anthropocene Labs work and doing the same area using MapBoxes
>> RobotSat tool chain using Danial's and Maning's posts as a guide.
>>
>> For reference please see this incredible work the community has shared
>> in the past months, much like humanitarian mapping in general, the
>> projects you see below will start changing the world over the next 12
>> months. Apologies if I missed any other OSM ML public projects, please
>> reply and let us all know!
>>
>> =
>>
>> Anthropocene Labs @anthropoco
>>
>> #Humanitarian #drone imgs of #Rohingya refugee camps + pretrained
>> model finetuned w @hotosm data. Not perfect maps but fast, small data
>> need, works w diff imgs. Thx @UNmigration @OpenAerialMap @geonanayi
>> @WeRobotics 4 #opendata & ideas! #cloudnative #geospatial
>> #deeplearning
>> https://twitter.com/anthropoco/status/1027268421442883584
>>
>> =
>>
>> This post follows Daniel’s guide for detecting buildings in drone
>> imagery in the Philippines. The goal of this exercise is for me to
>> understand the basics of the pipeline and find ways to use the tool in
>> identifying remote settlements from high resolution imagery (i.e
>> drones). I’m not aiming for pixel-perfect detection (i.e precise
>> geometry of the building). My main question is whether it can help
>> direct a human mapper focus on specific areas in the imagery to map in
>> OpenStreetMap.
>>
>> https://www.openstreetmap.org/user/maning/diary/44462
>>
>> ===
>>
>> Recently at Mapbox we open sourced 

Re: [OSRM-talk] Updating a map

[Sayer, Bryan]

When I had that problem it was due to lack of memory. For the United States, I 
had to have 64 GB of memory prepare, though I was doing it through a Stata 
interface, not directly.


From: Didier Doumerc 
Sent: Thursday, August 9, 2018 11:53:39 AM
To: osrm-talk@openstreetmap.org
Subject: [OSRM-talk] Updating a map

Hi,

I need help for updating the map file. Here is what I get when I run 
osrm-prepare france-latest.osrm. It stops at 90%

[info] Input file: france-latest.osrm
[info] Profile: profile.lua
[info] Threads: 8
[info] Loading edge-expanded graph representation
[info] Opening france-latest.osrm.ebg
[info] Reading 25874228 edges from the edge based graph
[info] Done reading edges
[STXXL-MSG] STXXL v1.4.1 (prerelease/Release)
[STXXL-ERRMSG] Warning: no config file found.
[STXXL-ERRMSG] Using default disk configuration.
[STXXL-MSG] Disk '/var/tmp/stxxl' is allocated, space: 1000 MiB, I/O 
implementation: syscall autogrow delete_on_exit queue=0 devid=0
merged 51783408 edges out of 103496912
contractor finished initalization
initializing elimination PQ ...ok
preprocessing 13952773 nodes  10% . 20% . 30% . 40% . 50% . 60% . [flush 
9336408 nodes]  70% . 80% . 90% .



Before, I run osrm-extract france-latest/osm.pbf


[info] Input file: france-latest.osm.pbf
[info] Profile: profile.lua
[info] Threads: 8
[info] Using script profile.lua
[STXXL-MSG] STXXL v1.4.1 (prerelease/Release)
[STXXL-ERRMSG] Warning: no config file found.
[STXXL-ERRMSG] Using default disk configuration.
[STXXL-MSG] Disk '/var/tmp/stxxl' is allocated, space: 1000 MiB, I/O 
implementation: syscall autogrow delete_on_exit queue=0 devid=0
[info] Parsing in progress..
[info] input file generated by osmium/1.8.0
[info] timestamp: 2018-08-05T20:00:03Z
[info] Using turn restrictions
[info] Found 3 exceptions to turn restrictions:
[info]   motorcar
[info]   motor_vehicle
[info]   vehicle
[info] Parsing finished after 914.304 seconds
[info] Raw input contains 387758183 nodes, 57191546 ways, and 521319 relations, 
and 0 unknown entities
[extractor] Sorting used nodes... ok, after 8.97724s
[extractor] Erasing duplicate nodes   ... ok, after 5.16838s
[extractor] Sorting all nodes ... ok, after 270.95s
[extractor] Building node id map  ... ok, after 146.325s
[extractor] setting number of nodes   ... ok
[extractor] Confirming/Writing used nodes ... ok, after 84.6342s
[info] Processed 36442184 nodes
[extractor] Sorting edges by start... ok, after 46.7546s
[extractor] Setting start coords  ... ok, after 188.624s
[extractor] Sorting edges by target   ... ok, after 47.2029s
[extractor] Computing edge weights... ok, after 201.467s
[extractor] Sorting edges by renumbered start ... ok, after 47.6069s
[extractor] Writing used egdes   ... ok, after 33.4863s
[extractor] setting number of edges   ... ok
[info] Processed 37971544 edges
[extractor] Sorting used ways ... ok, after 3.42604s
[extractor] Sorting 34351 restriction. by from... ok, after 0.078667s
[extractor] Fixing restriction starts ... ok, after 1.32651s
[extractor] Sorting restrictions. by to  ... ok, after 0.048604s
[extractor] Fixing restriction ends   ... ok, after 1.28459s
[info] usable restrictions: 31935
[extractor] writing street name index ... ok, after 0.159635s
[info] extraction finished after 2046.13s
[info] Generating edge-expanded graph representation
[info]  - 31935 restrictions.
[info] Importing n = 36442184 nodes
[info]  - 17000 bollard nodes, 41647 traffic lights
[info]  and 37971544 edges
[info] Graph loaded ok and has 37971544 edges
. 10% . 20% . 30% . 40% . 50% . 60% . 70% . 80% . 90% . 100%
[info] Node compression ratio: 0.166043
[info] Edge compression ratio: 0.19941
. 10% . 20% . 30% . 40% . 50% . 60% . 70% . 80% . 90% . 100%
[info] Generated 37961020 nodes in edge-expanded graph
[info] generating edge-expanded edges
. 10% . 20% . 30% . 40% . 50% . 60% . 70% . 80% . 90% . 100%
[info] Generated 37961020 edge based nodes
[info] Node-based graph contains 13952773 edges
[info] Edge-expanded graph ...
[info]   contains 25874228 edges
[info]   skips 26910 turns, defined by 31859 restrictions
[info]   skips 11264858 U turns
[info]   skips 18504 turns over barriers
[info] Timing statistics for edge-expanded graph:
[info] Renumbering edges: 0.239598s
[info] Generating nodes: 10.5262s
[info] Generating edges: 44.5756s
[info] building r-tree ...
[info] large component [6711]=13836854
[info] SCC run took: 1.89227s
[info] constructing r-tree of 37961020 edge elements build on-top of 36442184 
coordinates
[info] finished r-tree construction in 23.796 seconds
[info] writing node map ...
[extractor] Writing edge-based-graph egdes   ... ok, after 3.98042s
[info] Processed 25874228 edges
[info] Expansion  : 274152 nodes/sec and 104966 edges/sec
[info] To prepare the data for routing, run: ./osrm-prepare france-latest.osrm

[STXXL-ERRMSG] Removing disk file: /var/tmp/stxxl
logout
Saving session...

Re: [Talk-it] Cammino del beato Enrico, tag network.

[Martin Koppenhoefer]

se non c’è segnaletica non lo mappiamo.


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

[OSRM-talk] Updating a map

[Didier Doumerc]

Hi,

I need help for updating the map file. Here is what I get when I run 
osrm-prepare france-latest.osrm. It stops at 90%

[info] Input file: france-latest.osrm
[info] Profile: profile.lua
[info] Threads: 8
[info] Loading edge-expanded graph representation
[info] Opening france-latest.osrm.ebg
[info] Reading 25874228 edges from the edge based graph
[info] Done reading edges
[STXXL-MSG] STXXL v1.4.1 (prerelease/Release)
[STXXL-ERRMSG] Warning: no config file found.
[STXXL-ERRMSG] Using default disk configuration.
[STXXL-MSG] Disk '/var/tmp/stxxl' is allocated, space: 1000 MiB, I/O 
implementation: syscall autogrow delete_on_exit queue=0 devid=0
merged 51783408 edges out of 103496912
contractor finished initalization
initializing elimination PQ ...ok
preprocessing 13952773 nodes  10% . 20% . 30% . 40% . 50% . 60% . [flush 
9336408 nodes]  70% . 80% . 90% .



Before, I run osrm-extract france-latest/osm.pbf


[info] Input file: france-latest.osm.pbf
[info] Profile: profile.lua
[info] Threads: 8
[info] Using script profile.lua
[STXXL-MSG] STXXL v1.4.1 (prerelease/Release)
[STXXL-ERRMSG] Warning: no config file found.
[STXXL-ERRMSG] Using default disk configuration.
[STXXL-MSG] Disk '/var/tmp/stxxl' is allocated, space: 1000 MiB, I/O 
implementation: syscall autogrow delete_on_exit queue=0 devid=0
[info] Parsing in progress..
[info] input file generated by osmium/1.8.0
[info] timestamp: 2018-08-05T20:00:03Z
[info] Using turn restrictions
[info] Found 3 exceptions to turn restrictions:
[info]   motorcar
[info]   motor_vehicle
[info]   vehicle
[info] Parsing finished after 914.304 seconds
[info] Raw input contains 387758183 nodes, 57191546 ways, and 521319 relations, 
and 0 unknown entities
[extractor] Sorting used nodes... ok, after 8.97724s
[extractor] Erasing duplicate nodes   ... ok, after 5.16838s
[extractor] Sorting all nodes ... ok, after 270.95s
[extractor] Building node id map  ... ok, after 146.325s
[extractor] setting number of nodes   ... ok
[extractor] Confirming/Writing used nodes ... ok, after 84.6342s
[info] Processed 36442184 nodes
[extractor] Sorting edges by start... ok, after 46.7546s
[extractor] Setting start coords  ... ok, after 188.624s
[extractor] Sorting edges by target   ... ok, after 47.2029s
[extractor] Computing edge weights... ok, after 201.467s
[extractor] Sorting edges by renumbered start ... ok, after 47.6069s
[extractor] Writing used egdes   ... ok, after 33.4863s
[extractor] setting number of edges   ... ok
[info] Processed 37971544 edges
[extractor] Sorting used ways ... ok, after 3.42604s
[extractor] Sorting 34351 restriction. by from... ok, after 0.078667s
[extractor] Fixing restriction starts ... ok, after 1.32651s
[extractor] Sorting restrictions. by to  ... ok, after 0.048604s
[extractor] Fixing restriction ends   ... ok, after 1.28459s
[info] usable restrictions: 31935
[extractor] writing street name index ... ok, after 0.159635s
[info] extraction finished after 2046.13s
[info] Generating edge-expanded graph representation
[info]  - 31935 restrictions.
[info] Importing n = 36442184 nodes 
[info]  - 17000 bollard nodes, 41647 traffic lights
[info]  and 37971544 edges 
[info] Graph loaded ok and has 37971544 edges
. 10% . 20% . 30% . 40% . 50% . 60% . 70% . 80% . 90% . 100%
[info] Node compression ratio: 0.166043
[info] Edge compression ratio: 0.19941
. 10% . 20% . 30% . 40% . 50% . 60% . 70% . 80% . 90% . 100%
[info] Generated 37961020 nodes in edge-expanded graph
[info] generating edge-expanded edges
. 10% . 20% . 30% . 40% . 50% . 60% . 70% . 80% . 90% . 100%
[info] Generated 37961020 edge based nodes
[info] Node-based graph contains 13952773 edges
[info] Edge-expanded graph ...
[info]   contains 25874228 edges
[info]   skips 26910 turns, defined by 31859 restrictions
[info]   skips 11264858 U turns
[info]   skips 18504 turns over barriers
[info] Timing statistics for edge-expanded graph:
[info] Renumbering edges: 0.239598s
[info] Generating nodes: 10.5262s
[info] Generating edges: 44.5756s
[info] building r-tree ...
[info] large component [6711]=13836854
[info] SCC run took: 1.89227s
[info] constructing r-tree of 37961020 edge elements build on-top of 36442184 
coordinates
[info] finished r-tree construction in 23.796 seconds
[info] writing node map ...
[extractor] Writing edge-based-graph egdes   ... ok, after 3.98042s
[info] Processed 25874228 edges
[info] Expansion  : 274152 nodes/sec and 104966 edges/sec
[info] To prepare the data for routing, run: ./osrm-prepare france-latest.osrm

[STXXL-ERRMSG] Removing disk file: /var/tmp/stxxl
logout
Saving session...
...copying shared history...
...saving history...truncating history files...
...completed.


Thanks for your help.

Kind regards.

Didier___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [Talk-de] Wege des WSV an den Kanälen / tagging

[Martin Koppenhoefer]

sent from a phone

> On 9. Aug 2018, at 15:37, Christoph Hormann  wrote:
> 
> In der praktischen Verwendung bezieht sich das Kriterium der primären 
> Nutzung bei highway=track auf die Nutzung durch zweispurige Fahrzeuge.


m.E. auch auf den „Grund“, warum der Weg da ist. Wobei solche tracks z.T. sehr 
alt sind und früher vielleicht mal „echte Straßen“ waren.

Sofern es ein Schild gibt, erübrigt sich die Unterscheidung von unclassified 
und track anhand der Nutzung, in Deutschland ist einfach alles track, was eine 
gesperrt, land- undforstwirtschaftlicher  Verkehr frei“ beschilderung hat (oder 
gilt das nur in Baden-württemberg?) und die nirgendwo hinführen. Außerhalb sind 
tracks im Prinzip alle die, die nirgends hinführen, oder wo es Alternativen 
gibt, und der Weg für land- und forstw. Verkehr da ist (Fischerei gehört da 
auch dazu).

Die Abgrenzung track zu service: letzteres ist es dann, wenn es keiner höheren 
Klasse angehört und wo hinführt, sonst track. 

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

Re: [Talk-de] access tag / was möglich oder erlaubt ist Was: Wege des WSV an den Kanälen / tagging

[Martin Koppenhoefer]

sent from a phone

On 9. Aug 2018, at 15:21, Florian Lohoff  wrote:

>> dann ist private schon ok, physische Barrieren haben denselben Effekt
>> wie Schilder im Kontext der Zugänglichkeit 
> 
> Da kommen wir aber wieder dahin was die access tags meinen. Sind access
> tags das was erlaubt ist, oder das was möglich ist.


eine physische Barriere hat auch rechtliche Auswirkungen. Wenn Du einen Poller 
umfährst um dahinter weiterzufahren ist das nicht nur Sachbeschädigung am 
Poller sondern auch ein Verkehrsdelikt. Du darfst z.B. auch keine Treppen mit 
dem Moto-cross rad befahren, auch wenn da kein Schild ist, und du darfst als 
Fußgänger überall frei in der offenen Landschaft gehen (in Deutschland), auch 
auf Privatgrund, sofern Du nicht die Frucht beschädigst (z.B. gemähte Wiese) 
und: sofern es nicht umfriedet ist. Wenn ein Zaun drumrum ist darfst du nicht 
rein.

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

Re: [Talk-de] Wege des WSV an den Kanälen / tagging

[Martin Koppenhoefer]

sent from a phone

> On 9. Aug 2018, at 15:16, Florian Lohoff  wrote:
> 
> Das ist ein service way der Wasserstraße.
> Straßenunterhaltungspflichtig
> ist die WSV. Räder und Fußgänger sind nur geduldet. Deshalb auch mein
> Vorschlag zu dem permissive.


wenn das vor allem („tausendmal mehr“) als Fahrradweg genutzt ist, könnte man 
in OSM das auch als cycleway sehen, ich gehe aber mit dir mit, der Grund für 
den Weg ist die Zufahrt zur Wasserstraße, service passt daher für mich. Ich 
würde die Zufahrt zu einer Wasserstraße (Verkehrsbau) eher nicht mit der 
Erschließung von Wald und Flur gleichsetzen.


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

Re: [OSM-talk-fr] Artefact ou erreur de données ?

[osm . sanspourriel]

Le 09/08/2018 à 16:36, David Crochet - david.croc...@free.fr a écrit :


Bonjour

Le 09/08/2018 à 15:49, osm.sanspourr...@spamgourmet.com a écrit :
Ou tu cherches ailleurs ? Je suis d'accord si tu cherches sur la 
ligne fantôme (loin des extrémités) OSM ne trouve rien.


Non, je définit bien la recherche aux environs des nœuds (et non sur 
le parcours du chemin sans nœud aux environs


et en effectuant une requête entre le noeud 2393687377 
 et le noeud 2393687378 
, il ne trouve rien


En téléchargeant la zone dans JOSM, il ne trouve pas de telle ligne 
non plus.
En fait on est peut-être d'accord : en cherchant comme tu dis 
https://www.openstreetmap.org/query?lat=47.48469=-3.11789
Il trouve bien la relation Ligne d'Auray à Quiberon 


Pas la relation voyageurs (je ne sais pourquoi).

Si tu penses à une liaison comportant uniquement les points gare de 
Quiberon - PAN de Botulen, je ne pense pas qu'elle existe.
Et  pourtant https://b.tile.openstreetmap.org/19/257743/182946.png 
comporte toujours ce zombie.

C'est ce qui me fait penser à un problème d'affichage mais ça m'étonne.

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

Re: [Talk-it] BRouter Suspect Scanner

[Andrea Albani]

Il giorno gio 9 ago 2018 alle ore 13:45 Cascafico Giovanni <
cascaf...@gmail.com> ha scritto:

>
> se ho risolto il punto [1], come faccio a marcarlo fixed?
>
>
A clicchi su "Open in BRouter-Web". Un'indicatore blu ti dice dov'è il
potenziale problema P
B clicca l'indicatore e questo sparisce
C clicca in un punto di una strada che in qualche modo passa dal punto P
(in questo modo setti il punto di partenza)
D clicca in un altro punto oltre il punto P per settare il punto di arrivo
E viene calcolato il percorso: in questo modo puoi vedere se dal punto P è
possibile passare
F back sul browser

ora puoi cliccare nell'ordine "mark as a confirmed issue" e quindi "mark as
fixed" altrimenti ti esce il messaggio di errore

"*marking confirmed requires at least 2 recent nearby waypoints from
BRouter-Web, found: 0* "

Se invece era un falso problema, prima di poter cliccare "mark false
positive (=not an issue)", devi ripetere per 5 volte i punti da C ad E.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk] Learning to Use Machine Learning - A learn along for folks who want to be using ML in their work.

[Blake Girardot HOT/OSM]

Hi Christoph,

Thank you very much adding that notice, I was sure someone would :)

There are also a tremendous about of use cases for these tools that do
not involve putting data in OSM.

But rest assure, myself and everyone I interact with know about the
guidelines and no one suggests ever not following them.

These are really the early efforts to "operationalize" or create
workflows for different use cases.

Those guidelines will always be the core of any workflow that puts
data in OSM I am quite sure.

Thank you for doing the responsible thing and reminding us all.

Cheers
Blake

On Thu, Aug 9, 2018 at 9:54 AM, Christoph Hormann  wrote:
>
> As a quick reminder to any mapper who wants to use algorithmically
> generated data as a source for mapping work:
>
> If you upload such data without manually verifying the individual
> features against local knowledge or suitable primary data you are doing
> a mechanical edit or import and must follow the rules we have for
> those:
>
> https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
> https://wiki.openstreetmap.org/wiki/Import/Guidelines
>
> Practically this would for example be the case if - when being asked
> about the validity of your mapping by a fellow mapper - you'd be
> inclined to answer "I don't know, that's what the algorithm generated".
> You would then be in the mechanical edit/import domain.
>
> This is not a new topic, we have had this kind of problem in the past on
> several occasions, for example with use of automated tracing tools like
> scanaerial - which can be used both productively and responsibly for
> manual mapping as well as for doing bad quality mechanical
> edits/imports.  And in particular with algorithms advertised with the
> terms 'learning' and 'intelligence' implying human like capability and
> thereby a lack of need for human control and verification this is
> important to keep in mind.
>
> If you are not controlling the algorithm yourself but are being given
> pre-generated data by others for the purpose of uploading it to OSM -
> with or without manual verification - you are always doing an import
> and need to follow the guidelines.
>
> Side note:  It would be a responsible thing to include a reminder like
> what i wrote above with a message like the one i reply to here or in
> the welcome messages/FAQs etc. of dedicated communication channels.
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk



-- 

Blake Girardot
Humanitarian OpenStreetMap Team

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

Re: [OSM-talk] Learning to Use Machine Learning - A learn along for folks who want to be using ML in their work.

[Martin Koppenhoefer]

sent from a phone

> On 9. Aug 2018, at 15:54, Christoph Hormann  wrote:
> 
> If you are not controlling the algorithm yourself but are being given 
> pre-generated data by others for the purpose of uploading it to OSM - 
> with or without manual verification - you are always doing an import 
> and need to follow the guidelines.


+1
Also if you are controlling the algorithm yourself but are not manually and 
individually verifying its outcome, you are performing an import.


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

Re: [OSM-talk-fr] Artefact ou erreur de données ?

[David Crochet]

Bonjour


Le 09/08/2018 à 15:49, osm.sanspourr...@spamgourmet.com a écrit :
Ou tu cherches ailleurs ? Je suis d'accord si tu cherches sur la ligne 
fantôme (loin des extrémités) OSM ne trouve rien.


Non, je définit bien la recherche aux environs des nœuds (et non sur le 
parcours du chemin sans nœud aux environs


et en effectuant une requête entre le noeud 2393687377 
 et le noeud 2393687378 
, il ne trouve rien


En téléchargeant la zone dans JOSM, il ne trouve pas de telle ligne non 
plus.


Cordialement

--
David Crochet

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

Re: [Talk-GB] 'historic' county boundaries added to the database

[Lester Caine]

On 08/08/18 17:03, Nick Whitelegg wrote:


I think these things are at least partly a product of what generation 
you belong to.


I think one can include 'Middlesex' in that package? Just when will it 
cease to exist ;)


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [OSM-talk-fr] Artefact ou erreur de données ?

[David Crochet]

Bonjour


Le 09/08/2018 à 15:49, osm.sanspourr...@spamgourmet.com a écrit :


Curiosité : je vois qu'il y a une ligne vue en tant que transporteur 
de voyageurs  et une 
autre  en tant 
qu'infrastructure mais la première ne s'appuie pas sur la seconde. 
Est-ce normal ? Logique ?


A priori je trouve cela logique, l'un décrit la voie de circulation 
(référence provenant du réseau ferré) et ne définit que la voie de 
circulation l'autre indique la circulation possible (référence provenant 
du transporteur) avec les arrêts qu'il utilise pour définir ce trajet de 
transport.


Cordialement

--
David Crochet

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

Re: [Talk-it] Piazzola atterraggio elisoccorso notturno

[Martin Koppenhoefer]

sent from a phone

> On 9. Aug 2018, at 09:49, Damjan Gerl  wrote:
> 
> Si, però per il description conviene mettere description:it=...


+1

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

Re: [OSM-talk] Learning to Use Machine Learning - A learn along for folks who want to be using ML in their work.

[Christoph Hormann]

As a quick reminder to any mapper who wants to use algorithmically 
generated data as a source for mapping work:

If you upload such data without manually verifying the individual 
features against local knowledge or suitable primary data you are doing 
a mechanical edit or import and must follow the rules we have for 
those:

https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
https://wiki.openstreetmap.org/wiki/Import/Guidelines

Practically this would for example be the case if - when being asked 
about the validity of your mapping by a fellow mapper - you'd be 
inclined to answer "I don't know, that's what the algorithm generated". 
You would then be in the mechanical edit/import domain.  

This is not a new topic, we have had this kind of problem in the past on 
several occasions, for example with use of automated tracing tools like 
scanaerial - which can be used both productively and responsibly for 
manual mapping as well as for doing bad quality mechanical 
edits/imports.  And in particular with algorithms advertised with the 
terms 'learning' and 'intelligence' implying human like capability and 
thereby a lack of need for human control and verification this is 
important to keep in mind.

If you are not controlling the algorithm yourself but are being given 
pre-generated data by others for the purpose of uploading it to OSM - 
with or without manual verification - you are always doing an import 
and need to follow the guidelines.

Side note:  It would be a responsible thing to include a reminder like 
what i wrote above with a message like the one i reply to here or in 
the welcome messages/FAQs etc. of dedicated communication channels.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Talk-br] Towards Vandalism Detection in OpenStreetMap Through a Data Driven Approach

[Paulo Carvalho]

Não sei se o Pandas pode ler diretamente de uma base PostgreSQL, mas nada
impede de exportar os dados para um formato que o Pandas reconheça e daí
para os algoritmos de machine learning.

Em 9 de agosto de 2018 10:08, Peter Krauss  escreveu:

> Oi Paulo, boas dicas de clusterização, comunidade Python realmente criou
> ferramentas poderosas ...
> Quando ao OSM, bom lembrar que o XML é só um formato de troca de dados, as
> representações geométricas do OSM usualmente são feitas em PostGIS.
> Aqui vai um exemplo meio caduco, um dos poucos que clientes permitiram eu
> doar para o mundo, 6 anos atrás..
>
>https://gist.github.com/ppKrauss/3810651
>
> Faz justamente a detecção de "quadras mais pra quadriláteras" via
> operações espaciais (ex. buffer) onde o PostGIS é eficaz.
> Usei para destacar em espaço urbano os locais onde precisávamos conferir
> se as calçadas eram bem traçadas, e os erros mais usuais seram
> nas quadras fora do "padrao quadradinho".
>
>
>
>
> On Thu, Aug 9, 2018 at 8:32 AM Paulo Carvalho <
> paulo.r.m.carva...@gmail.com> wrote:
>
>> O módulo scikit-learn do Python tem excelentes algoritmos de
>> clusterização que poderiam ser usados para esse tipo de análise em larga
>> escala.  Bastaria pegar o XML de um mapa (pode ser o do mundo), abrí-lo com
>> o pandas e fazer a visualização dos grupos com, por exemplo, um
>> dendrograma.  Objetos vandalizados tendem a formar grupos pequenos ou de um
>> só elemento, tal como dito no artigo, daí é fácil detectar tais
>> situações.   Mas a dificuldade é definir que métricas usar para obter tal
>> separação.  E é aí que entra a ciência de dados.
>>
>> Seria interessante que houvesse um servidor onde pudéssemos instalar a
>> base do OSM global (ou só do BR) e o Anaconda (pacote com Python +
>> bibliotecas de visualização, análise e computação científica) onde as
>> pessoas pudessem fazer suas análises através de Jupyter Notebooks.
>>
>> Para quem é programador, existe a biblioteca TensorFlow que também tem
>> algoritmos de clusterização para big data.
>>
>> Em 8 de agosto de 2018 20:46, Gerald Weber  escreveu:
>>
>>> Oi Pessoal
>>>
>>> artigo sobre deteção de vandalismo no OSM:
>>>
>>> http://drops.dagstuhl.de/opus/volltexte/2018/9389/pdf/
>>> LIPIcs-GISCIENCE-2018-61.pdf
>>>
>>> fico imaginando se a gente conseguiria implementar algo assim em grande
>>> escala
>>>
>>> abraço
>>>
>>> Gerald
>>>
>>> ___
>>> Talk-br mailing list
>>> Talk-br@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-br
>>>
>>>
>> ___
>> Talk-br mailing list
>> Talk-br@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-br
>>
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-it] Cammino del beato Enrico, tag network.

[Giulio]

Salve a tutti,
Scusate il ritardo in questa risposta, ma grazie a Volker, che ci ha mandato 
il link di questa discussione e ci ha invitato a rispondere, ora siamo a
disposizione.

Da Bolzano a Treviso
https://www.openstreetmap.org/relation/6032965#map=9/46.0865/11.5135

Da Treviso a Venezia
https://www.openstreetmap.org/relation/6158367


Per quanto riguarda la mappatura ho cercato di farla utilizzando le
relazioni in quanto la maggior parte del cammino passa per tratti dove già
altri cammini sono stati tracciati.
Alcuni pezzi di collegamento invece sono stati aggiunti a mano.
Sono d'accordo con mettere lo status proposed, in quanto come leggerete
dalla risposta sotto dell'autore della guida, si stanno informando per
fornire la segnaletica.

Vi chiederei gentilmente se è possibile, di non cancellare il lavoro che ha
richiesto più di qualche giorno di mappatura e un lungo cammino per
accertarsi che il sentiero fosse percorribile e quali tratti coincidevano
con altri cammini.

Di seguito la risposta dell'autore:

Il cammino come mi pare hai sottolineato tu è analiticamente documentato
nella guida che ho pubblicato nel 2017
Guida Presentata in occasioni ufficiali a Bolzano Treviso e in due versi
altri centri Ubicati lungo il cammino
Lo stesso è stato già percorso da molti pellegrini in
Ambedue i sensi di marcia
La questione della segnaletica è alla nostra attenzione ( compagnia di
Santiago e del Beato Enrico) e non abbiamo ancora deciso per diverse ragioni
tra le quali la principale  :
Trattandosi di un itinerario che comprende per alcuni tratti altri itinerari
( es via romea di Stade, via Claudia augusta altinate, sentiero degli
Ezzelini etc)
Si rischia di avere una sovrapposizione di segnaletiche che può creare
confusione invece che orientare il Pellegrino 
Abbiamo quindi deciso per ora di citare nella ns guida la segnaletica già
esistente per i tratti comuni e di rendere disponibile sul nostro sito
compagniasantiagobeatoenrico.org il tracciato Gpx
Dopo verifiche con diocesi ed enti interessati decideremo definitivamente
sulla segnaletica 
Cordiali saluti
Paolo




--
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-it] Cammino del beato Enrico, tag network.

[Giulio]

Salve a tutti,
Scusate il ritardo in questa risposta, ma grazie a Volker, che ci ha mandato 
il link di questa discussione e ci ha invitato a rispondere, ora siamo a
disposizione.

Da Bolzano a Treviso
https://www.openstreetmap.org/relation/6032965#map=9/46.0865/11.5135

Da Treviso a Venezia
https://www.openstreetmap.org/relation/6158367


Per quanto riguarda la mappatura ho cercato di farla utilizzando le
relazioni in quanto la maggior parte del cammino passa per tratti dove già
altri cammini sono stati tracciati.
Alcuni pezzi di collegamento invece sono stati aggiunti a mano.
Sono d'accordo con mettere lo status proposed, in quanto come leggerete
dalla risposta sotto dell'autore della guida, si stanno informando per
fornire la segnaletica.

Vi chiederei gentilmente se è possibile, di non cancellare il lavoro che ha
richiesto più di qualche giorno di mappatura e un lungo cammino per
accertarsi che il sentiero fosse percorribile e quali tratti coincidevano
con altri cammini.

Di seguito la risposta dell'autore:

Il cammino come mi pare hai sottolineato tu è analiticamente documentato
nella guida che ho pubblicato nel 2017
Guida Presentata in occasioni ufficiali a Bolzano Treviso e in due versi
altri centri Ubicati lungo il cammino
Lo stesso è stato già percorso da molti pellegrini in
Ambedue i sensi di marcia
La questione della segnaletica è alla nostra attenzione ( compagnia di
Santiago e del Beato Enrico) e non abbiamo ancora deciso per diverse ragioni
tra le quali la principale  :
Trattandosi di un itinerario che comprende per alcuni tratti altri itinerari
( es via romea di Stade, via Claudia augusta altinate, sentiero degli
Ezzelini etc)
Si rischia di avere una sovrapposizione di segnaletiche che può creare
confusione invece che orientare il Pellegrino 
Abbiamo quindi deciso per ora di citare nella ns guida la segnaletica già
esistente per i tratti comuni e di rendere disponibile sul nostro sito
compagniasantiagobeatoenrico.org il tracciato Gpx
Dopo verifiche con diocesi ed enti interessati decideremo definitivamente
sulla segnaletica 
Cordiali saluti
Paolo




--
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] Artefact ou erreur de données ?

[osm . sanspourriel]

> Le rendu cyclable et le rendu transport sont mis à jour avec des 
temps plus longs (7 à 15 jours environ)
Ça correspond bien à la dernière modif (10 jours). On verra dans 
quelques temps.


Le 09/08/2018 à 14:54, David Crochet - david.croc...@free.fr a écrit :
OSM.org ne trouve pas cette ligne lorsque je lui demande de "trouver 
autour" que ce soit d'une extrémité ou de l'autre. Je pense que 
l'erreur est déjà corrigé.

Si :
https://www.openstreetmap.org/query?lat=47.48470=-3.11792
Ou près du PAN :
https://www.openstreetmap.org/query?lat=47.6790=-3.0220#map=14/47.5606/-3.0749

Ou tu cherches ailleurs ? Je suis d'accord si tu cherches sur la ligne 
fantôme (loin des extrémités) OSM ne trouve rien.


Curiosité : je vois qu'il y a une ligne vue en tant que transporteur de 
voyageurs  et une autre 
 en tant 
qu'infrastructure mais la première ne s'appuie pas sur la seconde. 
Est-ce normal ? Logique ?


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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Stefano]

Hi,
there's already a pull request
https://github.com/openstreetmap/openstreetmap-website/pull/1818

Stefano

Il giorno gio 9 ago 2018 alle ore 15:45 Yuri Astrakhan <
yuriastrak...@gmail.com> ha scritto:

> I'm a big fan of plus codes, and even have a pending implementation of it
> in the Elasticsearch (as an aggregation hashing function).  I doubt there
> are any legal restrictions on using this - the code is licensed under
> Apache 2, and Google states "Plus codes are free. There are no licensing
> fees or other costs. The technology is open-sourced." at
> https://plus.codes/
> Not sure about the implementation complexities.
>
> On Thu, Aug 9, 2018 at 4:35 PM oleksiy.muzal...@bluewin.ch <
> oleksiy.muzal...@bluewin.ch> wrote:
>
>> Open Location Codes are also referred to as "plus codes".  Since August
>> 2015, Google Maps supports plus codes in their search engine. The algorithm
>> is Open Source, licensed under the Apache License 2.0. and available on
>> GitHub [1].
>>
>> A plus code, can be generated at: https://plus.codes/ . It can be
>> entered at the Google Maps search input box to find a location. A plus sign
>> "+" is inserted in the code for recognition.
>>
>> It would be nice to have an interoperability. For example, a customer
>> uses Google Map, but a dispatcher in a Call Center the OpenStreetMap. The
>> OLC has got some interesting features:
>>
>> "Open Location Codes are derived from latitude and longitude coordinates,
>> so they already exist everywhere. They are similar in length to a telephone
>> number -- 849VCWC8+R9, for example -- but can often be shortened to only
>> four or six digits when combined with a locality (CWC8+R9, Mountain View).
>> Locations close to each other have similar codes. They can be encoded or
>> decoded offline. The character set avoids similar looking characters, to
>> reduce confusion and errors, and avoids vowels to make it unlikely that a
>> code spells existing words.The Open Location Code is not case-sensitive,
>> and can therefore be easily exchanged over the phone." [1]
>>
>> [1] https://en.wikipedia.org/wiki/Open_Location_Code
>>
>> Best regards,
>> Oleksiy
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Yuri Astrakhan]

I'm a big fan of plus codes, and even have a pending implementation of it
in the Elasticsearch (as an aggregation hashing function).  I doubt there
are any legal restrictions on using this - the code is licensed under
Apache 2, and Google states "Plus codes are free. There are no licensing
fees or other costs. The technology is open-sourced." at https://plus.codes/

Not sure about the implementation complexities.

On Thu, Aug 9, 2018 at 4:35 PM oleksiy.muzal...@bluewin.ch <
oleksiy.muzal...@bluewin.ch> wrote:

> Open Location Codes are also referred to as "plus codes".  Since August
> 2015, Google Maps supports plus codes in their search engine. The algorithm
> is Open Source, licensed under the Apache License 2.0. and available on
> GitHub [1].
>
> A plus code, can be generated at: https://plus.codes/ . It can be entered
> at the Google Maps search input box to find a location. A plus sign "+" is
> inserted in the code for recognition.
>
> It would be nice to have an interoperability. For example, a customer uses
> Google Map, but a dispatcher in a Call Center the OpenStreetMap. The OLC
> has got some interesting features:
>
> "Open Location Codes are derived from latitude and longitude coordinates,
> so they already exist everywhere. They are similar in length to a telephone
> number -- 849VCWC8+R9, for example -- but can often be shortened to only
> four or six digits when combined with a locality (CWC8+R9, Mountain View).
> Locations close to each other have similar codes. They can be encoded or
> decoded offline. The character set avoids similar looking characters, to
> reduce confusion and errors, and avoids vowels to make it unlikely that a
> code spells existing words.The Open Location Code is not case-sensitive,
> and can therefore be easily exchanged over the phone." [1]
>
> [1] https://en.wikipedia.org/wiki/Open_Location_Code
>
> Best regards,
> Oleksiy
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[john whelan]

So you are talking about an enhancement to Nominatim I assume?

There is a process to request enhancements.

Cheerio John

On Thu, 9 Aug 2018, 9:35 am oleksiy.muzal...@bluewin.ch, <
oleksiy.muzal...@bluewin.ch> wrote:

> Open Location Codes are also referred to as "plus codes".  Since August
> 2015, Google Maps supports plus codes in their search engine. The algorithm
> is Open Source, licensed under the Apache License 2.0. and available on
> GitHub [1].
>
> A plus code, can be generated at: https://plus.codes/ . It can be entered
> at the Google Maps search input box to find a location. A plus sign "+" is
> inserted in the code for recognition.
>
> It would be nice to have an interoperability. For example, a customer uses
> Google Map, but a dispatcher in a Call Center the OpenStreetMap. The OLC
> has got some interesting features:
>
> "Open Location Codes are derived from latitude and longitude coordinates,
> so they already exist everywhere. They are similar in length to a telephone
> number -- 849VCWC8+R9, for example -- but can often be shortened to only
> four or six digits when combined with a locality (CWC8+R9, Mountain View).
> Locations close to each other have similar codes. They can be encoded or
> decoded offline. The character set avoids similar looking characters, to
> reduce confusion and errors, and avoids vowels to make it unlikely that a
> code spells existing words.The Open Location Code is not case-sensitive,
> and can therefore be easily exchanged over the phone." [1]
>
> [1] https://en.wikipedia.org/wiki/Open_Location_Code
>
> Best regards,
> Oleksiy
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-de] Wege des WSV an den Kanälen / tagging

[Christoph Hormann]

On Thursday 09 August 2018, Florian Lohoff wrote:
> > Bei highway=track ist die land- und forstwirtschaftliche Nutzung
> > übrigens keine abschließende Aufzählung von möglichen Nutzungen, im
> > Englischen steht da ein 'etc.' dran.  Hier kann man die
>
> https://wiki.openstreetmap.org/wiki/Tag:highway=track
> "This tag represents roads for mostly agricultural use, forest tracks
> etc.; "
>
> "mostly" ist hier das ausschlaggebende Argument - Wenn etwas
> überwiegend für diesen Zweck ist. Das ist hier definitiv nicht der
> fall. Selbst wenn der Landwirt da 10 mal im Jahr mit dem Schwader auf
> die Wiese fährt kommen da faktor 1000 mal mehr Fahrräder durch.

Mit dem selben Argument dürftest Du einen großen Teil der Forstwege hier 
im Schwarzwald auch nicht als highway=track taggen, da die Fahrrad- und 
Wanderer-Nutzung die forstwirtschaftliche Nutzung bei weitem überwiegt.

Wird aber offensichtlich und auch sinnvollerweise trotzdem als 
highway=track getaggt.

In der praktischen Verwendung bezieht sich das Kriterium der primären 
Nutzung bei highway=track auf die Nutzung durch zweispurige Fahrzeuge.

> Räder und Fußgänger sind
> nur geduldet. Deshalb auch mein Vorschlag zu dem permissive.

Das kannst Du genauso an highway=track taggen.

-- 
Christoph Hormann
http://www.imagico.de/

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

[OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[oleksiy.muzal...@bluewin.ch]

Open Location Codes are also referred to as "plus codes".  Since August 2015, 
Google Maps supports plus codes in their search engine. The algorithm is Open 
Source, licensed under the Apache License 2.0. and available on GitHub [1]. 
A plus code, can be generated at: https://plus.codes/ . It can be entered at 
the Google Maps search input box to find a location. A plus sign "+" is 
inserted in the code for recognition.
It would be nice to have an interoperability. For example, a customer uses 
Google Map, but a dispatcher in a Call Center the OpenStreetMap. The OLC has 
got some interesting features:
"Open Location Codes are derived from latitude and longitude coordinates, so 
they already exist everywhere. They are similar in length to a telephone number 
-- 849VCWC8+R9, for example -- but can often be shortened to only four or six 
digits when combined with a locality (CWC8+R9, Mountain View). Locations close 
to each other have similar codes. They can be encoded or decoded offline. The 
character set avoids similar looking characters, to reduce confusion and 
errors, and avoids vowels to make it unlikely that a code spells existing 
words.The Open Location Code is not case-sensitive, and can therefore be easily 
exchanged over the phone." [1]
[1] https://en.wikipedia.org/wiki/Open_Location_Code
Best regards,
Oleksiy
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-de] access tag / was möglich oder erlaubt ist Was: Wege des WSV an den Kanälen / tagging

[Florian Lohoff]

On Thu, Aug 09, 2018 at 09:24:41AM +0200, Martin Koppenhoefer wrote:
> > Wobei ich das mit dem motor_vehicle=private auch doof finde. Das steht
> > nirgends, es ist bloss überall durch Poller oder Schranken dafür gesorgt
> > das die öffentlichkeit eben mit einem Auto da nicht drauf kommt. 
> 
> dann ist private schon ok, physische Barrieren haben denselben Effekt
> wie Schilder im Kontext der Zugänglichkeit 

Da kommen wir aber wieder dahin was die access tags meinen. Sind access
tags das was erlaubt ist, oder das was möglich ist.

Eigentlich haben wir das was möglich ist in den highway types definiert
(und ggfs surface, width, height etc) und das was erlaubt ist ist im
access. Aber da kann ich auch auf dem Holzweg sein.

Flo
-- 
Florian Lohoff f...@zz.de
 UTF-8 Test: The  ran after a , but the  ran away


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

Re: [Talk-de] Wege des WSV an den Kanälen / tagging

[Florian Lohoff]

On Thu, Aug 09, 2018 at 02:20:29PM +0200, Markus wrote:
> Hi Christoph,
> Service für: Zufahrt zu Wehr, Schleuse, Kraftwerk, Gebäude, Hafen, Kran,
> Slipway (Feuerwehr, Wasserrettung, Polizei)
> 
> Fahrradweg für: (Fern-)Radwege
> 
> Rest: track:grade für Land- und Wasserwirtschaft

Der Weg entlang des Kanals ist für die WSV der Zufahrt und Kontrollweg
für den Kanal - Straßenunterhaltungspflichtig ist hier wie beim Kanal
auch die WSV. Fußgänger und Räder sind nur geduldet. Daher kann das
IMHO einfach kein cycleway sein. Dann hätte der
Straßenunterhaltungspflichtige ja einen Radweg beschildert - hat er aber
nicht.

Quasi alle wege sind bestandteil des einen oder anderen Fernradweges.
Zufahrt zu Feldern/Agrarwirtschaft ist mir in keinem Fall aufgefallen.

Flo
-- 
Florian Lohoff f...@zz.de
 UTF-8 Test: The  ran after a , but the  ran away


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

Re: [Talk-de] Wege des WSV an den Kanälen / tagging

[Florian Lohoff]

On Thu, Aug 09, 2018 at 09:57:12AM +0200, Christoph Hormann wrote:
> Bei highway=track ist die land- und forstwirtschaftliche Nutzung 
> übrigens keine abschließende Aufzählung von möglichen Nutzungen, im 
> Englischen steht da ein 'etc.' dran.  Hier kann man die 

https://wiki.openstreetmap.org/wiki/Tag:highway=track
"This tag represents roads for mostly agricultural use, forest tracks
etc.; "

"mostly" ist hier das ausschlaggebende Argument - Wenn etwas überwiegend
für diesen Zweck ist. Das ist hier definitiv nicht der fall. Selbst
wenn der Landwirt da 10 mal im Jahr mit dem Schwader auf die Wiese fährt
kommen da faktor 1000 mal mehr Fahrräder durch.

> wasserwirtschaftliche Nutzung in Analogie durchaus mit einbeziehen, 
> denn da sind ja erhebliche Ähnlichkeiten.  Wie der Feldweg primär zum 
> generellen Zugang zu den angrenzenden Feldern dient, dient der 
> wasserwirtschaftliche Weg zum Zugang zum angrenzenden Gewässer in der 
> Strecke.

Ich habe nicht einen Trecker aber 1000 Fahrräder gesehen. Ich denke von
überwiegend Landwirtschaftlicher Nutzung lässt sich hier nicht reden.

> Kurz:  Meiner Meinung nach ist die Ähnlichkeit eines solchen Weges zu 
> einem Feld- oder Waldweg deutlich höher als zu einem Zufahrtsweg zu 
> einem Objekt.  Gibt natürlich Ausnahmen wie eine Ufer-parallele Zufahrt 
> zu einem konkreten Objekt wie einem Wehr oder so.

Das ist ein service way der Wasserstraße. Straßenunterhaltungspflichtig
ist die WSV. Räder und Fußgänger sind nur geduldet. Deshalb auch mein
Vorschlag zu dem permissive.

Flo
-- 
Florian Lohoff f...@zz.de
 UTF-8 Test: The  ran after a , but the  ran away


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

Re: [Talk-br] Towards Vandalism Detection in OpenStreetMap Through a Data Driven Approach

[Peter Krauss]

Oi Paulo, boas dicas de clusterização, comunidade Python realmente criou
ferramentas poderosas ...
Quando ao OSM, bom lembrar que o XML é só um formato de troca de dados, as
representações geométricas do OSM usualmente são feitas em PostGIS.
Aqui vai um exemplo meio caduco, um dos poucos que clientes permitiram eu
doar para o mundo, 6 anos atrás..

   https://gist.github.com/ppKrauss/3810651

Faz justamente a detecção de "quadras mais pra quadriláteras" via operações
espaciais (ex. buffer) onde o PostGIS é eficaz.
Usei para destacar em espaço urbano os locais onde precisávamos conferir se
as calçadas eram bem traçadas, e os erros mais usuais seram
nas quadras fora do "padrao quadradinho".




On Thu, Aug 9, 2018 at 8:32 AM Paulo Carvalho 
wrote:

> O módulo scikit-learn do Python tem excelentes algoritmos de clusterização
> que poderiam ser usados para esse tipo de análise em larga escala.
> Bastaria pegar o XML de um mapa (pode ser o do mundo), abrí-lo com o pandas
> e fazer a visualização dos grupos com, por exemplo, um dendrograma.
> Objetos vandalizados tendem a formar grupos pequenos ou de um só elemento,
> tal como dito no artigo, daí é fácil detectar tais situações.   Mas a
> dificuldade é definir que métricas usar para obter tal separação.  E é aí
> que entra a ciência de dados.
>
> Seria interessante que houvesse um servidor onde pudéssemos instalar a
> base do OSM global (ou só do BR) e o Anaconda (pacote com Python +
> bibliotecas de visualização, análise e computação científica) onde as
> pessoas pudessem fazer suas análises através de Jupyter Notebooks.
>
> Para quem é programador, existe a biblioteca TensorFlow que também tem
> algoritmos de clusterização para big data.
>
> Em 8 de agosto de 2018 20:46, Gerald Weber  escreveu:
>
>> Oi Pessoal
>>
>> artigo sobre deteção de vandalismo no OSM:
>>
>>
>> http://drops.dagstuhl.de/opus/volltexte/2018/9389/pdf/LIPIcs-GISCIENCE-2018-61.pdf
>>
>> fico imaginando se a gente conseguiria implementar algo assim em grande
>> escala
>>
>> abraço
>>
>> Gerald
>>
>> ___
>> Talk-br mailing list
>> Talk-br@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-br
>>
>>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [OSM-talk-fr] Artefact ou erreur de données ?

[David Crochet]

Bonjour


Le 09/08/2018 à 14:48, osm.sanspourr...@spamgourmet.com a écrit :
Je vois que sur OSM.org 
 
ou OSM.fr 
, la 
ligne Auray-Quiberon (le Tire-Bouchon) est affublée d'une ligne 
directe s'affranchissant des obstacles naturels. Je ne savais qu'avait 
été créée une ligne TGV d'Auray à Quiberon ;-).


OSM.org ne trouve pas cette ligne lorsque je lui demande de "trouver 
autour" que ce soit d'une extrémité ou de l'autre. Je pense que l'erreur 
est déjà corrigé.


Donc "wait and see"

Cordialement

--
David Crochet

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

Re: [OSM-talk-fr] Artefact ou erreur de données ?

[David Crochet]

Bonjour


Le 09/08/2018 à 14:48, osm.sanspourr...@spamgourmet.com a écrit :
Comme les deux systèmes affichent la même chose ainsi que le rendu HOT 
mais que la carte cyclable 
 
est bonne comme la carte transports je me demande s'il n'y a pas un 
bogue dans l'affichage cartoCSS/Mapnik


Le rendu cyclable et le rendu transport sont mis à jour avec des temps 
plus longs (7 à 15 jours environ)


cordialement

--
David Crochet

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

[OSM-talk-fr] Artefact ou erreur de données ?

[osm . sanspourriel]

Je vois que sur OSM.org 
 
ou OSM.fr 
, la 
ligne Auray-Quiberon (le Tire-Bouchon) est affublée d'une ligne directe 
s'affranchissant des obstacles naturels. Je ne savais qu'avait été créée 
une ligne TGV d'Auray à Quiberon ;-).


Comme les deux systèmes affichent la même chose ainsi que le rendu HOT 
mais que la carte cyclable 
 
est bonne comme la carte transports je me demande s'il n'y a pas un 
bogue dans l'affichage cartoCSS/Mapnik.


Je n'ai pas trouvé d'erreur, en particulier au point d'arrivée 
https://www.openstreetmap.org/node/252291030


Quelqu'un de plus doué pour trouver l'origine de l'erreur ?

De plus un local de l'étape peut confimrer que c'est le segment 
https://www.openstreetmap.org/way/23305663#map=17/47.68052/-3.00281 qui 
manque à la relation côté Auray ?


https://www.openstreetmap.org/way/262550757#map=17/47.48634/-3.11656

http://tile.openstreetmap.fr/?zoom=17=47.48634=-3.11656

http://overpass-turbo.eu/s/AV2

[out:xml][timeout:250];
{{geocodeArea:Morbihan}}->.searchArea;
(
  node["name"="Ligne d'Auray à Quiberon"](area.searchArea);
  way["name"="Ligne d'Auray à Quiberon"](area.searchArea);
  relation["name"="Ligne d'Auray à Quiberon"](area.searchArea);
);
(._;>;);
out meta;

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

Re: [Talk-de] Wege des WSV an den Kanälen / tagging

[Markus]

Hi Christoph,

> Meiner Meinung nach ist die Ähnlichkeit eines solchen Weges zu 
> einem Feld- oder Waldweg deutlich höher als zu einem Zufahrtsweg zu 
> einem Objekt.  Gibt natürlich Ausnahmen wie eine Ufer-parallele Zufahrt 
> zu einem konkreten Objekt wie einem Wehr oder so.

+1

Service für: Zufahrt zu Wehr, Schleuse, Kraftwerk, Gebäude, Hafen, Kran,
Slipway (Feuerwehr, Wasserrettung, Polizei)

Fahrradweg für: (Fern-)Radwege

Rest: track:grade für Land- und Wasserwirtschaft

Gruss, Markus

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

Re: [OSM-talk-fr] Lit-et-Mixe

[Philippe Verdy]

Pour les communes associées dans une fusion-association, ou pour les
communes déléguées dans les communes nouvelles, ou pour les arrondissements
municipaux (de Lille, Paris et Marseille), c'est le niveau 9 qui est
utilisé avec admin_type:FR=* qui précise leur type respectif. La commune
fusionnée de droit est de niveau 8, et peut avoir aussi un
"admin_type:FR=*" pour la distinguer d'une commune simple (par défaut).
En règle générale place=* est indépendant de l'entité adminsitrative (on
devrait même se passer de "place=*" pour les relations, il est plus lié aux
nodes).
De même les chiffres de population devraient être sur la relation (quand il
en existe une) et non sur le noeud. Le noeud peut être l'admin_centre de
plusieurs relations adminsitratives, ou parfois un des "admin_centre" d'une
même relation dans certains cas pour certaines entités: 'de jure' contre
'de facto'; 'capitale politique' contre 'capitale administrative' ou
'judiciaire'; 'capitale royale' contre 'capitale nationale'). Et très
souvent ce noeud n'a pas le même nom que l'entité administrative où il est
situé. Ce noeud donne plutôt une vision de géographie urbaine et non
politique.

Les statuts de "ville", "village", "borough" (admin_type=* sur les
relations administratives ou politiques ou autres) ne vont pas bien avec
les valeurs données à "place=*" pour les noeuds "admin_centre". Et nombre
de ces lieux (village ou hameaux ou communautés rurales locales) n'ont
aucun statut administratif et ne sont pas clairement délimités au sein de
l'entité administrative.

Assez souvent aussi un noeud "place=*" donne son nom à une entité qui est
plus large que l'entité administrative (notamment dans les grandes
métropoles, mais parfois aussi des villes plus petites, pour inclure une
partie de leur périphérie): les "place" correspondent mieux en France à ce
que l'INSEE désigne dans sa géographie urbaine (indépendante de la
géographie administrative) qui évolue tout le temps et plus vite que la
géographie administrative.

Et pour moi "place=suburb" est donc inadapté en France, sauf pour les
noeuds ajoutés en "admin_centre" des arrondissements municipaux des 3
grandes villes: là c'est "admin_type:FR=arrondissement municipal" qui va
prend le pas

Le "place=suburb" est plus pour la compatibilité des rendus génériques
internationaux: c'est une approximation permettant juste des comparaisons
et d'améliorer le rendu final (pour sélectionner l'icone du noeud ou juste
le style/la taille du libellé , il n'a pas de valeur en tant que donnée
administrative, et sinon pour donner une priorité estimée de "l'importance"
du lieu dans les recherches puisque une carte ne peut pas tous les afficher
: ce "place=*" est juste un des critères possibles permettant de filtrer
les éléments à afficher en priorité).


Le 9 août 2018 à 11:20, djakk djakk  a écrit :

> Oui tout à fait c’est le même problème avec les communes fusionnées. Je
> n’aime pas l’utilisation du place=suburb pour les communes associées ... je
> préférerai qu’on garde place=village ou place=town et que le détail
> administratif se fasse avec les admin_level= ...
> Car quand on se balade on ne ressent pas la ville ou le village par son
> côté administratif mais par son urbanisme et sa densité commerciale et sa
> densité de services.
>
> djakk
>
>
> Le mar. 7 août 2018 à 19:00, Rpnpif  a écrit :
>
>> Le  4 août 2018, Stéphane Péneau a écrit :
>>
>> > Si le panneau d'entrée du bourg principal indique lit-et-mixe, c'est un
>> > peu délicat.
>> >
>> > En revanche, town pour un bourg d'un peu plus de 1000 habitants, je ne
>> > suis pas trop d'accord. place=village est mieux adapté
>> >
>>
>> Bonjour,
>>
>> En complément de la réserve de Stéphane, c'est le même problème avec la
>> fusion récente de communes.
>> Il faudrait aussi adapter le niveau administratif 8, 9 ou autre.
>> https://wiki.openstreetmap.org/wiki/Key:admin%20level?uselang=fr
>>
>> --
>> Alain Rpnpif
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] BRouter Suspect Scanner

[Andrea Musuruane]

Ciao,

Il gio 9 ago 2018, 13:45 Cascafico Giovanni  ha
scritto:

> Inviterei chi opera a marcare le issue come fixed o false positive perchè
>>> ne ho trovate diverse per le quali la situazione su OSM era stata sanata da
>>> qualche ora, ma nella lista risultavano ancora da trattare.
>>>
>>
> se ho risolto il punto [1], come faccio a marcarlo fixed?
>

Prima lo segni "confirmed" e dopo puoi segnarlo "fixed".

Ciao,

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

[OSM-talk] Learning to Use Machine Learning - A learn along for folks who want to be using ML in their work.

[Blake Girardot HOT/OSM]

Dear Friends,

In case you missed it, Dale Kunce tweeted this out yesterday:

The day of Machine Learning and OSM/Humanitarian mapping reckoning is
getting closer. Very excited for the possibilities these new methods
have for @hotosm @RedCross. Next frontier is making HOT and
@TheMissingMaps more valuable than just a training dataset for the
machines.

https://twitter.com/calimapnerd/status/1027275305440829440

Toward that end, I have been watching and in some cases working with
various ML tool chains over the past 2 years and really, not having a
lot of luck with my level of skill and knowledge. I am a pretty
advanced sysadmin, comfortable on the command line, but understanding
the terminology and installations has been a bit beyond me.

So if anyone is like me and sees all of these great tool chains and
would like to learn how to use them with your peers learning along
with you and hopefully some experts as well, I created a dedicated
#mlearning-basic channel on the OSM-US slack (
https://osmus-slack.herokuapp.com/ )

OSM-US runs a lovely, informative, lively, international slack with
many channels and everyone is welcome!

The #mlearning-basic channel is for the absolute beginner basics, how
to install and use the existing and emerging tools chains and OSM/OAM
data to generate usable vector data from Machine Learning quickly.

You are all invited to join, but it is very basic. Hopefully some of
the ML experts from the projects below will be in there to hand hold
us newbies through actually making use of what we are seeing more and
more everyday. Excellent tool chains exist, world changing tool
chains, now we just need to get them into the hands of the people who
need and want to use them everyday :)

Everyone is welcome and encouraged to join, it is intended to be kind
of a "learn-a-long". Our first project, my first project, is building
on the Anthropocene Labs work and doing the same area using MapBoxes
RobotSat tool chain using Danial's and Maning's posts as a guide.

For reference please see this incredible work the community has shared
in the past months, much like humanitarian mapping in general, the
projects you see below will start changing the world over the next 12
months. Apologies if I missed any other OSM ML public projects, please
reply and let us all know!

=

Anthropocene Labs @anthropoco

#Humanitarian #drone imgs of #Rohingya refugee camps + pretrained
model finetuned w @hotosm data. Not perfect maps but fast, small data
need, works w diff imgs. Thx @UNmigration @OpenAerialMap @geonanayi
@WeRobotics 4 #opendata & ideas! #cloudnative #geospatial
#deeplearning
https://twitter.com/anthropoco/status/1027268421442883584

=

This post follows Daniel’s guide for detecting buildings in drone
imagery in the Philippines. The goal of this exercise is for me to
understand the basics of the pipeline and find ways to use the tool in
identifying remote settlements from high resolution imagery (i.e
drones). I’m not aiming for pixel-perfect detection (i.e precise
geometry of the building). My main question is whether it can help
direct a human mapper focus on specific areas in the imagery to map in
OpenStreetMap.

https://www.openstreetmap.org/user/maning/diary/44462

===

Recently at Mapbox we open sourced RoboSat our end-to-end pipeline for
feature extraction from aerial and satellite imagery. In the following
I will show you how to run the full RoboSat pipeline on your own
imagery using drone imagery from the OpenAerialMap project in the area
of Tanzania as an example.

https://www.openstreetmap.org/user/daniel-j-h/diary/44321

=

Skynet is our machine learning platform. It quickly scans vast
archives of satellite and drone imagery and delivers usable insights
to decisionmakers. Our partners use Skynet to reliably extract roads
and buildings from images that NASA, ESA, and private satellites and
drones record daily. The tool is remarkably versatile. We are
experimenting with using Skynet to detect electricity infrastructure,
locate schools, and evaluate crop performance.

https://developmentseed.org/projects/skynet/

=

Deep learning techniques, esp. Convolutional Neural Networks (CNNs),
are now widely studied for predictive analytics with remote sensing
images, which can be further applied in different domains for ground
object detection, population mapping, etc. These methods usually train
predicting models with the supervision of a large set of training
examples.

https://www.geog.uni-heidelberg.de/gis/deepvgi_en.html

===

OSMDeepOD - OpenStreetMap (OSM) and Machine Learning (Deep Learning)
based Object Detection from Aerial Imagery (Formerly also known as
"OSM-Crosswalk-Detection"). http://www.hsr.ch/geometalab

https://github.com/geometalab/OSMDeepOD


==

Re: [Talk-it] BRouter Suspect Scanner

[Cascafico Giovanni]

>
> Inviterei chi opera a marcare le issue come fixed o false positive perchè
>> ne ho trovate diverse per le quali la situazione su OSM era stata sanata da
>> qualche ora, ma nella lista risultavano ancora da trattare.
>>
>
se ho risolto il punto [1], come faccio a marcarlo fixed?


[1] http://brouter.de:443/brouter/suspects/italy/834046253461330815
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[OSM-talk] Learning to Use Machine Learning - A learn along for folks who want to be using ML in their work.

[Blake Girardot]

Dear Friends,

In case you missed it, Dale Kunce tweeted this out yesterday:

The day of Machine Learning and OSM/Humanitarian mapping reckoning is
getting closer. Very excited for the possibilities these new methods
have for @hotosm @RedCross. Next frontier is making HOT and
@TheMissingMaps more valuable than just a training dataset for the
machines.

https://twitter.com/calimapnerd/status/1027275305440829440

Toward that end, I have been watching and in some cases working with
various ML tool chains over the past 2 years and really, not having a
lot of luck with my level of skill and knowledge. I am a pretty
advanced sysadmin, comfortable on the command line, but understanding
the terminology and installations has been a bit beyond me.

So if anyone is like me and sees all of these great tool chains and
would like to learn how to use them with your peers learning along
with you and hopefully some experts as well, I created a dedicated
#mlearning-basic channel on the OSM-US slack (
https://osmus-slack.herokuapp.com/ )

OSM-US runs a lovely, informative, lively, international slack with
many channels and everyone is welcome!

The #mlearning-basic channel is for the absolute beginner basics, how
to install and use the existing and emerging tools chains and OSM/OAM
data to generate usable vector data from Machine Learning quickly.

You are all invited to join, but it is very basic. Hopefully some of
the ML experts from the projects below will be in there to hand hold
us newbies through actually making use of what we are seeing more and
more everyday. Excellent tool chains exist, world changing tool
chains, now we just need to get them into the hands of the people who
need and want to use them everyday :)

Everyone is welcome and encouraged to join, it is intended to be kind
of a "learn-a-long". Our first project, my first project, is building
on the Anthropocene Labs work and doing the same area using MapBoxes
RobotSat tool chain using Danial's and Maning's posts as a guide.

For reference please see this incredible work the community has shared
in the past months, much like humanitarian mapping in general, the
projects you see below will start changing the world over the next 12
months. Apologies if I missed any other OSM ML public projects, please
reply and let us all know!

=

Anthropocene Labs @anthropoco

#Humanitarian #drone imgs of #Rohingya refugee camps + pretrained
model finetuned w @hotosm data. Not perfect maps but fast, small data
need, works w diff imgs. Thx @UNmigration @OpenAerialMap @geonanayi
@WeRobotics 4 #opendata & ideas! #cloudnative #geospatial
#deeplearning
https://twitter.com/anthropoco/status/1027268421442883584

=

This post follows Daniel’s guide for detecting buildings in drone
imagery in the Philippines. The goal of this exercise is for me to
understand the basics of the pipeline and find ways to use the tool in
identifying remote settlements from high resolution imagery (i.e
drones). I’m not aiming for pixel-perfect detection (i.e precise
geometry of the building). My main question is whether it can help
direct a human mapper focus on specific areas in the imagery to map in
OpenStreetMap.

https://www.openstreetmap.org/user/maning/diary/44462

===

Recently at Mapbox we open sourced RoboSat our end-to-end pipeline for
feature extraction from aerial and satellite imagery. In the following
I will show you how to run the full RoboSat pipeline on your own
imagery using drone imagery from the OpenAerialMap project in the area
of Tanzania as an example.

https://www.openstreetmap.org/user/daniel-j-h/diary/44321

=

Skynet is our machine learning platform. It quickly scans vast
archives of satellite and drone imagery and delivers usable insights
to decisionmakers. Our partners use Skynet to reliably extract roads
and buildings from images that NASA, ESA, and private satellites and
drones record daily. The tool is remarkably versatile. We are
experimenting with using Skynet to detect electricity infrastructure,
locate schools, and evaluate crop performance.

https://developmentseed.org/projects/skynet/

=

Deep learning techniques, esp. Convolutional Neural Networks (CNNs),
are now widely studied for predictive analytics with remote sensing
images, which can be further applied in different domains for ground
object detection, population mapping, etc. These methods usually train
predicting models with the supervision of a large set of training
examples.

https://www.geog.uni-heidelberg.de/gis/deepvgi_en.html

===

OSMDeepOD - OpenStreetMap (OSM) and Machine Learning (Deep Learning)
based Object Detection from Aerial Imagery (Formerly also known as
"OSM-Crosswalk-Detection"). http://www.hsr.ch/geometalab

https://github.com/geometalab/OSMDeepOD


==

Re: [Talk-br] Towards Vandalism Detection in OpenStreetMap Through a Data Driven Approach

[Paulo Carvalho]

O módulo scikit-learn do Python tem excelentes algoritmos de clusterização
que poderiam ser usados para esse tipo de análise em larga escala.
Bastaria pegar o XML de um mapa (pode ser o do mundo), abrí-lo com o pandas
e fazer a visualização dos grupos com, por exemplo, um dendrograma.
Objetos vandalizados tendem a formar grupos pequenos ou de um só elemento,
tal como dito no artigo, daí é fácil detectar tais situações.   Mas a
dificuldade é definir que métricas usar para obter tal separação.  E é aí
que entra a ciência de dados.

Seria interessante que houvesse um servidor onde pudéssemos instalar a base
do OSM global (ou só do BR) e o Anaconda (pacote com Python + bibliotecas
de visualização, análise e computação científica) onde as pessoas pudessem
fazer suas análises através de Jupyter Notebooks.

Para quem é programador, existe a biblioteca TensorFlow que também tem
algoritmos de clusterização para big data.

Em 8 de agosto de 2018 20:46, Gerald Weber  escreveu:

> Oi Pessoal
>
> artigo sobre deteção de vandalismo no OSM:
>
> http://drops.dagstuhl.de/opus/volltexte/2018/9389/pdf/
> LIPIcs-GISCIENCE-2018-61.pdf
>
> fico imaginando se a gente conseguiria implementar algo assim em grande
> escala
>
> abraço
>
> Gerald
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] The social construction of technological stasis: The stagnating data structure in OpenStreetMap

[Peter Krauss]

Oi gente, concordo com o Gerard,
e vejo uma certa inércia (nossa resistência natural quando pensamos "mais
seguro continuar como está")
ou até resistência (alguns são mesmo radicais) no "core" do OSM... Que tem
seus motivos.
De leve o artigo faz uma certa critica ao excesso de centralização do poder
na infraestrutura e decisões técnicas do OSM.

Cabe a nós, comunidade OSM-Brasil, fazermos nosso "lobby" junto à
comunidade OSM-geral e a OSMF...
Como não existe *mecanismo de voto*, uma opção interessante de participar é
"votando" no https://HELP.openstreetmap.org nas questões pertinentes
(o escopo do fórum HELP é suporte técnico - mas por vezes aceitam tópicos
mais genéricos exemplo

)

- - -

O artigo fala das aplicações de utilidade publica que só se tornariam
realidade depois de mudanças de arquitetura/compromisso no OSM...

Pensando em aplicações mais imediatas e com solução simples (que não
requerem mudar a arquitetura do OSM),
acho que a mais importante e "bola da vez" é o Permanent_ID,
  https://wiki.openstreetmap.org/wiki/Permanent_ID
Tentando resumir: sem Permanent_ID não há como ter investimento de longo
prazo num simples link...
*não existe hoje* endereço (*URL*) para por exemplo *um simples mapa do
Brasil*.
Tudo se perde, ninguém na OSMF ou na infraestrutura-OSM dá garantia de
persistência, coisa que tem solução tecnológica já fazem uns 20 anos, como
o PURL .
Se publicamos um PDF com link para o OSM o link vai se perder, é
investimento perdido... Por isso o Permanent_ID é tão importante.

As prefeituras e a maior parte das iniciativas de utilidade pública demanda
isso. Geocodificação idem, aguarda Permanent_ID para ser algo mais sério.
Os meandros da solução do problema são um pouco mais discutidos em
https://wiki.openstreetmap.org/wiki/Persistent_Place_Identifier
Tem solução simples, passa pelo uso da Wikidata (P402)
 em regime recíproco da
tag-Wikidata *.*



On Wed, Aug 8, 2018 at 8:43 PM Gerald Weber  wrote:

> Oi Paulo
>
> na verdade a estagnação não é somente tecnológica, mas também social ;)
>
> Certamente, o modelo de "todo mundo pode mexer à vontade"  foi importante
> há uns 10 anos quando o mapa era um grande vazio e era necessário criar
> volume. Mas com a complexidade que temos hoje a lógica já precisava ser
> outra. Hoje é preciso criar confiabilidade, e é difícil fazer isto no
> modelo atual.
>
> abraço
>
> Gerald
>
> 2018-08-05 19:28 GMT-03:00 Paulo Carvalho :
>
>> Como diz o paper, mudar os mais de 50 softwares baseados na atual
>> estrutura é inviável.  Seria necessário a OSMF criar um OSM 2 e fazer o *code
>> freeze* do OSM atual.  Seria complicado, mas necessário, pois o modelo
>> Wiki (no qual o OSM atual se baseia) tem dois sérios defeitos, a saber:
>> 1) A revisão é a posteriori.  Deveria ser como em software livre: rever
>> antes, publicar depois.  Contribuições ruins podem ser detectadas muito
>> tempo depois, levando a um comprometimento sério de partes do mapa
>> expandidas a partir delas.
>> 2) Não tem um modelo de privilégios crescentes como no Stack Overflow e
>> Wikimapia, o que diminui o impacto de edições negligentes ou
>> mal-intencionadas.
>>
>> att,
>>
>> PC
>>
>>
>> Em 5 de agosto de 2018 11:30, Gerald Weber  escreveu:
>>
>>> Oi Pessoal
>>>
>>> artigo fazendo uma análise interessante sobre o OSM e o que o autor
>>> chama de estagnação tecnológica:
>>>
>>> http://journals.sagepub.com/doi/pdf/10.1177/2053951718790591
>>>
>>> abraço
>>>
>>> Gerald
>>>
>>> ___
>>> Talk-br mailing list
>>> Talk-br@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-br
>>>
>>>
>>
>> ___
>> Talk-br mailing list
>> Talk-br@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-br
>>
>>
>
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-africa] Intention to be included in mailing list:

[Joel Umeuduji]

My name is Prof. J. E. Umeuduji, a Geomorphologist based at the University
of Port Harcourt, Nigeria. I am a map enthusiast. I like contributing to
Tasks in OSM and I am also interested in mentoring students in VGI. I will
like to learn more from you and share my experiences with you as well.
Thank you.
Prof. J. E. Umeuduji.
___
Talk-africa mailing list
Talk-africa@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-africa

Re: [OSM-talk-fr] édition mécanique : nettoyage is_in:continent

[deuzeffe]

Je ne suis pas contre ;p

On 08/08/2018 01:40, marc marc wrote:

Bonsoir,

une discussion a lieu ces derniers jours à propos des continents.
ceux-ci, hormis l’antarctique, sont pour le moment représenté par un
nœud car l'étendue de ceux-ci sont imprécis et parfois conflictuel
(parle-t-on d’Europe donc d'un continent politique ? si oui quel est
sa limite vers l'est ou de plaque tectonique et donc d’Eurasie ?)
bref le débat est en cours... et j'ai pas la prétention d'apporter
quelques choses à celui-ci tant les positions sont éloignées.

par contre, pour contourner ce manque d'étendue géographique,
il existe le tag is_in:continent.
cela permet de renseigner qu'un pays ou une partie de celui-ci
est dans tel continent
cependant ce tag pour une raison inconnue se retrouve un peu n'importe
où, il y a par exemple environ 350x ce tag en France continentale
alors qu'il est suffisant d'en avoir un seul sur la relation.

Mon message a donc pour but d'informer mon intention de procéder
un nettoyage en France continentale et donc de discuter de celui-ci
avant de le faire comme il se doit :)

PS: c'est quasi toute la variété des is_in qui faudrait nettoyer.
Mais pour d'autre tag, ce serra moins trivial, alors je préfère
y aller par petite étape rapide à discuter et à faire.

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



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

Re: [Talk-br] Towards Vandalism Detection in OpenStreetMap Through a Data Driven Approach

[Peter Krauss]

Oi Gerald e Wille, tambem achei interessante o artigo, que passa a receita
e faz a prova de conceito. Bom achado.

Aí entre a prova de conceito e produto tem um longo caminho... mas tudo
indica que o OSMCha seria
justamente uma ótima "casca" para abrigar o algoritmo da detecção de
prédios (algo como um módulo opcional),
aproveitando que o resto já se encontra implementado.

O OSMCha é muito bom e foi apresentado em Milão... Tem reconhecimento
internacional e selo de "made in Brasil", by Wille!

Fica a pergunta pro Wille: se fosse incorporar esse módulo de detecção de
prédios,
no que nós (comunidade aqui) podemos ajudar? Testadores? Discussão de
pontos cabeludos do artigo? Discussão do custo/beneficio do módulo?



On Thu, Aug 9, 2018 at 6:10 AM Wille Marcel  wrote:

> Dei uma olhada rápida, parece interessante as fórmulas de detecção de
> prédios, mas vi que não mencionaram o OSMCha e que lá temos sim um registro
> de changesets com problemas e com possibilidade de filtrar os que foram
> classificados como uma má edição intencional.
>
> http://osmcha.mapbox.com/
> 
> On Ago 9 2018, at 1:46 am, Gerald Weber  wrote:
>
>
> Oi Pessoal
>
> artigo sobre deteção de vandalismo no OSM:
>
>
> http://drops.dagstuhl.de/opus/volltexte/2018/9389/pdf/LIPIcs-GISCIENCE-2018-61.pdf
> 
>
> fico imaginando se a gente conseguiria implementar algo assim em grande
> escala
>
> abraço
>
> Gerald
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
> [image: Open Tracking]___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-it] BRouter Suspect Scanner

[Andrea Albani]

Il giorno gio 9 ago 2018 alle ore 10:00 Andrea Musuruane 
ha scritto:

> Ciao,
> per quanto riguarda il workflow da seguire, Arndt mi ha scritto::
>
> *The suspect list shows only suspects that were detected in the last scan.
> However,*
> *if you investigated a suspect you should always change the state either
> to:*
>
> *- false positive (if there is no real issue)*
> *- confirmed->fixed*
>
> *You can also leave it as "confirmed" to indicate that yes, you saw*
> *there is an issue, but want to fix it later or have someone else to fix
> it.*
>
> Ciao,
>
> Andrea
>
>
ok, ma comunque prima bisogna fare qualche test di routing con brouter-web
altrimenti lo stato in fixed o false positive non si riesce proprio a
cambiarlo.

Inviterei chi opera a marcare le issue come fixed o false positive perchè
ne ho trovate diverse per le quali la situazione su OSM era stata sanata da
qualche ora, ma nella lista risultavano ancora da trattare.

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

Re: [Talk-de] Tag: line=rail in relation-route

[Scholtes, Martin]

Hallo Nick,

Was ich so von unterwegs feststellen konnte hast du die RB und KBS 
zusammengefasst, was grundsätzlich getrennt werden sollte. Ebenso arbeitest du 
nicht vollständig nach ptv2.
Wenn du magst schau ich mir das gleich am PC an.

Gruß Martin

 Originalnachricht 
Betreff: [Talk-de] Tag: line=rail in relation-route
Von: goegeo 
An: talk-de@openstreetmap.org
Cc:


Hallo ÖPNV-(Relations-)experten,

Vor geraumer Zeit viel mir auf, dass bei einer von mir  bearbeiteten 
Routenrelation (Bahn) beim Aufruf der ÖPNV-Karte die in der 
Relation-Route erfassten Haltestellen, doppelt gerendert werden.

Es handelt sich um die Relation "SH-Regionalbahnlinie RB 64;KBS 135 
Husum - Bad St Peter-Ording". Habt Ihr einen Erklärungs- und womöglich 
auch Lösungsansatz? Denke, dass der Fehler in einer mangelhaften 
Erfassung meinerseits liegt. Ich selber habe mich zuletzt gefragt, ob 
eventuell  der Tag line=rail in der Route_Relation dafür verantwortlich 
sein könnte. Im Wiki auf der Seite zur ÖPNV-Karte ist dieser nämlich 
nicht mit angegeben. Mag sich jemand das mal mit anschauen?

Beste Grüße und Danke für Eure Hilfe.

Grüße, Nico

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

Re: [OSM-talk-fr] Lit-et-Mixe

[djakk djakk]

Oui tout à fait c’est le même problème avec les communes fusionnées. Je
n’aime pas l’utilisation du place=suburb pour les communes associées ... je
préférerai qu’on garde place=village ou place=town et que le détail
administratif se fasse avec les admin_level= ...
Car quand on se balade on ne ressent pas la ville ou le village par son
côté administratif mais par son urbanisme et sa densité commerciale et sa
densité de services.

djakk


Le mar. 7 août 2018 à 19:00, Rpnpif  a écrit :

> Le  4 août 2018, Stéphane Péneau a écrit :
>
> > Si le panneau d'entrée du bourg principal indique lit-et-mixe, c'est un
> > peu délicat.
> >
> > En revanche, town pour un bourg d'un peu plus de 1000 habitants, je ne
> > suis pas trop d'accord. place=village est mieux adapté
> >
>
> Bonjour,
>
> En complément de la réserve de Stéphane, c'est le même problème avec la
> fusion récente de communes.
> Il faudrait aussi adapter le niveau administratif 8, 9 ou autre.
> https://wiki.openstreetmap.org/wiki/Key:admin%20level?uselang=fr
>
> --
> Alain Rpnpif
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-de] Tag: line=rail in relation-route

[goegeo]

Hallo ÖPNV-(Relations-)experten,

Vor geraumer Zeit viel mir auf, dass bei einer von mir  bearbeiteten 
Routenrelation (Bahn) beim Aufruf der ÖPNV-Karte die in der 
Relation-Route erfassten Haltestellen, doppelt gerendert werden.


Es handelt sich um die Relation "SH-Regionalbahnlinie RB 64;KBS 135 
Husum - Bad St Peter-Ording". Habt Ihr einen Erklärungs- und womöglich 
auch Lösungsansatz? Denke, dass der Fehler in einer mangelhaften 
Erfassung meinerseits liegt. Ich selber habe mich zuletzt gefragt, ob 
eventuell  der Tag line=rail in der Route_Relation dafür verantwortlich 
sein könnte. Im Wiki auf der Seite zur ÖPNV-Karte ist dieser nämlich 
nicht mit angegeben. Mag sich jemand das mal mit anschauen?


Beste Grüße und Danke für Eure Hilfe.

Grüße, Nico

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

Re: [Talk-br] Towards Vandalism Detection in OpenStreetMap Through a Data Driven Approach

[Wille Marcel]

Dei uma olhada rápida, parece interessante as fórmulas de detecção de prédios, 
mas vi que não mencionaram o OSMCha e que lá temos sim um registro de 
changesets com problemas e com possibilidade de filtrar os que foram 
classificados como uma má edição intencional.

http://osmcha.mapbox.com/ 
(https://link.getmailspring.com/link/1533805329.local-d1363ee1-8bed-v1.3.0-fd741...@getmailspring.com/0?redirect=http%3A%2F%2Fosmcha.mapbox.com%2F=dGFsay1ickBvcGVuc3RyZWV0bWFwLm9yZw%3D%3D)
On Ago 9 2018, at 1:46 am, Gerald Weber  wrote:
>
> Oi Pessoal
>
> artigo sobre deteção de vandalismo no OSM:
> http://drops.dagstuhl.de/opus/volltexte/2018/9389/pdf/LIPIcs-GISCIENCE-2018-61.pdf
>  
> (https://link.getmailspring.com/link/1533805329.local-d1363ee1-8bed-v1.3.0-fd741...@getmailspring.com/1?redirect=http%3A%2F%2Fdrops.dagstuhl.de%2Fopus%2Fvolltexte%2F2018%2F9389%2Fpdf%2FLIPIcs-GISCIENCE-2018-61.pdf=dGFsay1ickBvcGVuc3RyZWV0bWFwLm9yZw%3D%3D)
> fico imaginando se a gente conseguiria implementar algo assim em grande escala
>
> abraço
>
> Gerald
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>

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

Re: [OSM-talk-fr] édition mécanique : nettoyage is_in:continent

[Philippe Verdy]

On pourrait ajouter "is_in:country" qui ne devrait plus servir à rien
maintenant qu'on a les frontières des pays (et qu'il a été décidé de
délimiter les zones contestées ou revendiquées par plusieurs pays dans des
relations séparées hors des revendications de chaque pays, avec un tag
spécifique).
La plupart des "is_in" était pour palier le manque provisoire de relations
de délimitation des frontières en indiquant cela sur des noeuds. Il reste
encore des "is_in:region=*" ou similaire pour des entités infra-nationales
non encore délimitées, notamment pas mal au niveau des municipalités ou
subdivisions nationales de 2e niveau (la plupart des délimitations de
premier niveau sont déjà dans la base, et notamment les "is_in:state=*"
pour les pays fédérés sont maintenant aussi inutiles.

Personnellement je considère les "is_in" un peu comme des "notes"
informatives à traiter comme des éléments "à faire". Ce ne sont pas
réellement des données exploitables (et encore moins le "is_in=*" qui
accepte une liste, que les "is_in:type=*" qui peuvent encore avoir une
utilité).

Pour l'Europe et l'Amérique du Nord au moins, la quasi totalité des
"is_in=*" ou "is_in:type=*" est maintenant inutile puisque les relations
nécessaires sont là.

De plus les tags "is_in[:type]=*" sont dépréciés plutôt en faveur des
membres de rôle "subarea" dans les relations :je sais certains n'aiment pas
les subarea, mais les requêtes spatiales sont lourdes et pas forcément
appropriées pour trouver les subdivisions correctes dans les cas connus où
la structure hiérarchique des niveaux n'est pas aussi stricte qu'on le
pense, et les "subarea" lèvent ces ambiguités et ont un coût négligeable
puisque c'est un seul membre ajouté par relation dans la relation parente
appropriée et n'implique aucun ajoute de relation supplémentaire, et sont
simples à gérer et vérifier de façon exhaustive et permettent aussi de
relever les cas de revendications territoriales multiples/contestées,
telles que les revendications chinoises contre celles de ses voisins, et
cela permet d'adapter les rendus carto selon les pays demandeurs et peut
permettre de lever des conflits d'édition en donnant la place à chaque
point de vue).

Bien souvent en plus on peut aussi utiliser les subarea pour créer et
référencer des relations incomplètes, dans lesquelles les membres
n'auraient encore que des noeuds (un "admin_centre", parfois 2 ou 3 pour
certaines entités comme l'Afrique du Sud qui a 3 capitales, et
éventuellement et encore d'autres pour les villes non encore tracées): ces
relations incomplètes sont faciles à trouver et on peut aussi y mettre un
tag "note" ou "fixme" pour bien indiquer ce qui reste à y faire pour les
délimiter ou ajouter des notes sur les difficultés ou contestations de
revendications. Il est simple de créer une liste exhaustive de relations
même incomplètes et continuer ensuite : au lieu des "is_in" dispersés, on
centralise l'info les sur la relation parente (même incomplète) avec ses
membres "subarea".

Les requêtes à la base de données sont largement simplifiées et beaucoup
plus rapide (avec beaucoup moins de données à scanner), et le modèle des
subarea est très résistant aux cas des relations brisées (dont certains
ways membre ont été scindés), et facilitent la réparation. Certains ont cru
à tord que les "subarea" étaient un conflit entre "modèle de surface" et
"modèle de frontière", ce n'est pas le cas car cela a toujours été les deux
en même temps: les subarea c'est autre chose et traduit seulement la
reconnaissance d'une sous-entité territoriale/administrative comme partie
d'une entité territoriale maître (voire plusieurs en cas de conflit de
revendications): les "subarea" gèrent très bien ces conflits et sont très
résistants. Il sont très peu coûteux, solides et efficaces, très faciles à
gérer et donnent un excellent rapport de complétude. Cela se construit très
vite avec peu de modifications à la base; même dans les éditeurs il devient
facile de naviguer entre niveaux. Et ils sont une méthode bien plus
efficace pour construire sans erreur (ou beaucoup moins d'erreurs) les
frontières ou pour ensuite les modifier (réformes adminstratives) sans
oubli : on sait facilement où en en est, on évite aussi des doublons
d'objets.

Les membres de rôle "subarea" ne sont pas non plus limités aux seuls
frontières administratives; on a dans la base d'autres objets comme les
limites fiscales, judiciaires, postales, militaires... En France aussi on a
les "local_authority" assez compliqués pour les EPCI (il n'y a pas que les
seuls ECPI à fiscalité propre, et même on a des cas où des ECPI ont leurs
propres subdivisions comme les métropoles de Paris ou Nantes), et qui
bougent régulièrement: il est là aussi facile de mettre dans la relation de
l'EPCI la listes des communes membres: la construction et vérification des
frontières en est facilité pour ensuite y mettre ou maintenir les ways
membres en rôle "outer"/"inner".

Certaines entités ont plusieurs types de découpages en 

Re: [OSM-talk] [Osmf-talk] Draft Terms of use for the OSM website, API and other services

[Heather Leson]

Dear all,

how about a brief companion FAQ? I am happy to help with this (as mentioned
in Milan)

Michael, would you like to collaborate on this with us?

heather

Heather Leson
heatherle...@gmail.com
Twitter/skype: HeatherLeson
Blog: textontechs.com

On Thu, Aug 9, 2018 at 10:45 AM, Simon Poole  wrote:

>
>
> Am 08.08.2018 um 19:14 schrieb Michael Reichert:
> > ..
> > I read the draft and I think that is far too long. It does not invited
> > to be read by the users. This can lead to following issues:
> Just to be clear, we (the LWG) would prefer that it be shorter too, it
> is just the amount of territory that needs to be covered that makes it
> long and complicated (I'm fairly sure that it is actually shorter than
> the WP ToU that it is derived from).
>
> > - Users don't read it because it is too boring, too long and too
> > difficult to understand (especially for the majority being not native
> > English speakers or understanding no English at all). They would be
> > surprised by the important parts later.
> > - Already active members of the community refuse to accept the terms
> > because they don't understand the needs and the content.
> >
> > If we need all that rules written down there, we should add a summary of
> > the points which are most important from our point of view at the
> > beginning. It could look like this:
> >
> > - You have access to personal data (OSM metadata). Please handle it
> > appropriate.
> > - Your contributions must not violate copyright.
> > - You must be 16 years or older to join OSM.
> > - We don't guarantee anything. [insert better wording here]
>
> We'll be discussing both the concept of a human readable summary and
> translations at a our meeting today (both ideas were floated at SOTM).
> I wouldn't put too much hope in it though, in the end we need users to
> agree to the terms themselves and not to a summary, adding one just
> means there is even more text that needs to be read (have a look at
> https://foundation.wikimedia.org/wiki/Terms_of_Use/en for the WP ToU).
> Translations are mainly an issue of cost (both initial and maintenance).
>
> > The OSMF has already a block policy ruling when users get blocked
> > permanently and how. If we add terms to the website, we should integrate
> > the block policy into the terms. This has the advantage that user
> > actively agree the block policy which makes it a lot easier to use it in
> > court (I am not talking about a fictional case here).
> >
> > Best regards
> >
> > Michael
> You were just complaining about the ToU being too long, adding the
> kitchen sink is definitely not going to make them shorter :-).
>
> Simon
>
>
>
>
> ___
> 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: [Talk-it] Ponte chiuso per lavori

[Volker Schmidt]

prova con "OR" al posto del "AND" !

2018-08-09 10:28 GMT+02:00 Andrea Albani :

> Il giorno gio 9 ago 2018 alle ore 09:42 Giuliano Zamboni <
> giuli...@zamboni.pro> ha scritto:
>
>> Ho provato ad inserirlo così ma JOSM mi segnalava un errore.
>> Così invece è stato preso:
>> vehicle:conditional=no @ (2018 Aug 08 07:00-00:00 AND 2018 Aug 09-10 AND
>> 2018 Aug 11 00:00-18:00)
>>
>
> Diciamo che il validatore di JOSM è un po' pignoletto perchè vuole vedere
> tutti i range orari esplicitati. Per soddisfarlo puoi inserire quanto
> segue:
>
> vehicle:conditional= no @ (2018 Aug 08 07:00-24:00; 2018 Aug 09
> 00:00-24:00; 2018 Aug 10 00:00-24:00; 2018 Aug 11 00:00-18:00)
>
> Gli AND al posto degli ; indicano che tutte le condizioni devono
> verificarsi in contemporanea, cosa ovviamente impossibile (l'8 agosto non
> può essere contemporaneamente anche 9, 10 e 11). Si usa quando metti
> condizioni su aspetti differenti come ad esempio tempo e peso (es. vietato
> l'acceso ai mezzi con peso superiore a x tonnellate dalle  alle yyy).
>
> Ciao
>
>
> ___
> 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: [OSM-talk] [Osmf-talk] Draft Terms of use for the OSM website, API and other services

[Simon Poole]

Am 08.08.2018 um 19:14 schrieb Michael Reichert:
> ..
> I read the draft and I think that is far too long. It does not invited
> to be read by the users. This can lead to following issues:
Just to be clear, we (the LWG) would prefer that it be shorter too, it
is just the amount of territory that needs to be covered that makes it
long and complicated (I'm fairly sure that it is actually shorter than
the WP ToU that it is derived from).

> - Users don't read it because it is too boring, too long and too
> difficult to understand (especially for the majority being not native
> English speakers or understanding no English at all). They would be
> surprised by the important parts later.
> - Already active members of the community refuse to accept the terms
> because they don't understand the needs and the content.
>
> If we need all that rules written down there, we should add a summary of
> the points which are most important from our point of view at the
> beginning. It could look like this:
>
> - You have access to personal data (OSM metadata). Please handle it
> appropriate.
> - Your contributions must not violate copyright.
> - You must be 16 years or older to join OSM.
> - We don't guarantee anything. [insert better wording here]

We'll be discussing both the concept of a human readable summary and
translations at a our meeting today (both ideas were floated at SOTM). 
I wouldn't put too much hope in it though, in the end we need users to
agree to the terms themselves and not to a summary, adding one just
means there is even more text that needs to be read (have a look at
https://foundation.wikimedia.org/wiki/Terms_of_Use/en for the WP ToU).
Translations are mainly an issue of cost (both initial and maintenance).

> The OSMF has already a block policy ruling when users get blocked
> permanently and how. If we add terms to the website, we should integrate
> the block policy into the terms. This has the advantage that user
> actively agree the block policy which makes it a lot easier to use it in
> court (I am not talking about a fictional case here).
>
> Best regards
>
> Michael
You were just complaining about the ToU being too long, adding the
kitchen sink is definitely not going to make them shorter :-).

Simon





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

Re: [Talk-it] Ponte chiuso per lavori

[Andrea Albani]

Il giorno gio 9 ago 2018 alle ore 09:42 Giuliano Zamboni <
giuli...@zamboni.pro> ha scritto:

> Ho provato ad inserirlo così ma JOSM mi segnalava un errore.
> Così invece è stato preso:
> vehicle:conditional=no @ (2018 Aug 08 07:00-00:00 AND 2018 Aug 09-10 AND
> 2018 Aug 11 00:00-18:00)
>

Diciamo che il validatore di JOSM è un po' pignoletto perchè vuole vedere
tutti i range orari esplicitati. Per soddisfarlo puoi inserire quanto
segue:

vehicle:conditional= no @ (2018 Aug 08 07:00-24:00; 2018 Aug 09
00:00-24:00; 2018 Aug 10 00:00-24:00; 2018 Aug 11 00:00-18:00)

Gli AND al posto degli ; indicano che tutte le condizioni devono
verificarsi in contemporanea, cosa ovviamente impossibile (l'8 agosto non
può essere contemporaneamente anche 9, 10 e 11). Si usa quando metti
condizioni su aspetti differenti come ad esempio tempo e peso (es. vietato
l'acceso ai mezzi con peso superiore a x tonnellate dalle  alle yyy).

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

Re: [Talk-it] BRouter Suspect Scanner

[Andrea Musuruane]

Ciao,
per quanto riguarda il workflow da seguire, Arndt mi ha scritto::

*The suspect list shows only suspects that were detected in the last scan.
However,*
*if you investigated a suspect you should always change the state either
to:*

*- false positive (if there is no real issue)*
*- confirmed->fixed*

*You can also leave it as "confirmed" to indicate that yes, you saw*
*there is an issue, but want to fix it later or have someone else to fix
it.*

Ciao,

Andrea


2018-08-08 21:48 GMT+02:00 Andrea Albani :

> Il giorno mer 8 ago 2018 alle ore 21:32 Andrea Albani 
> ha scritto:
>
>> C'è ancora una cosa che non torna sul tool.
>>
>>
> Mi rispondo da solo.
>
> Prima di marcare come "confirmed issue" bisogna aprire il link di
> brouter-web, fare 1 simulazione di routing (5 nel caso di falsi positivi) e
> a questo punto è possibile procedere.
>
>
> ___
> 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-de] Wege des WSV an den Kanälen / tagging

[Christoph Hormann]

On Wednesday 08 August 2018, Florian Lohoff wrote:
>
> - track
>   Ich halte track für falsch da es sich nicht um überwiegend Land-/
>   oder Forstwirtschaftlich genutzte Wege handelt.
>   Ähnlich der Deichverteidigungswege an der Nordsee.
>
> - cycleway
>   Halte ich ebenfalls für falsch - Das ist ja kein ausgewiesener
> Radweg sondern ein "Support weg" des Kanals der für Fußgänger und
> Radfahrer freigegeben ist.

In der Gegend hier ist die Situation, dass die meisten dieser Wege - so 
sie denn für zweispurige Fahrzeuge geeignet sind, von solchen primär 
nicht als Zufahrtsweg zu irgendeinem Objekt genutzt werden (das wäre 
highway=service), sondern zu landwirtschaftlichen Zwecken (Schäfer, der 
seine Schafe auf den Deichen grasen lässt) oder zur Landschaftspflege 
(Mähen des Grases).

Bei highway=track ist die land- und forstwirtschaftliche Nutzung 
übrigens keine abschließende Aufzählung von möglichen Nutzungen, im 
Englischen steht da ein 'etc.' dran.  Hier kann man die 
wasserwirtschaftliche Nutzung in Analogie durchaus mit einbeziehen, 
denn da sind ja erhebliche Ähnlichkeiten.  Wie der Feldweg primär zum 
generellen Zugang zu den angrenzenden Feldern dient, dient der 
wasserwirtschaftliche Weg zum Zugang zum angrenzenden Gewässer in der 
Strecke.

Kurz:  Meiner Meinung nach ist die Ähnlichkeit eines solchen Weges zu 
einem Feld- oder Waldweg deutlich höher als zu einem Zufahrtsweg zu 
einem Objekt.  Gibt natürlich Ausnahmen wie eine Ufer-parallele Zufahrt 
zu einem konkreten Objekt wie einem Wehr oder so.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Talk-it] Piazzola atterraggio elisoccorso notturno

[Damjan Gerl]

Dne, 09. avgust 2018 09:39:28 GMT+02:00, Gianluca Boero 
 sporoča:
>Esatto...ad esempio nell'ospedale più vicino, Pinerolo, c'è una
>piazzola 
>(diurna) ad uso esclusivo per gli elicotteri...e questa l'avevo taggata
>
>già a suo tempo con aeroway=heliport
>
>
>Il 09/08/2018 09:33, Martin Koppenhoefer ha scritto:
>>
>> sent from a phone
>>
>>> On 9. Aug 2018, at 09:25, Andrea Musuruane 
>wrote:
>>>
>>> Ho notato inoltre che è sufficiente inserire emergency=landing_site
>(senza aeroway=heliport).
>>
>> +1, aeroway=heliport sarebbe una cosa diversa, un “aeroporto per
>elicotteri”, cosa un campo da calcio “attrezzato” probabilmente non è.
>>
>> Ciao, Martin
>> ___
>> 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

Si, però per il description conviene mettere description:it=... 

Damjan
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Ponte chiuso per lavori

[Giuliano Zamboni]

  
  
Grazie per i suggerimenti!

Il 09/08/2018 07:07, Andrea Albani ha
  scritto:


  
  

  
  
Il gio 9 ago 2018, 01:34 Martin Koppenhoefer
   ha
  scritto:

  
  +1, questo metodo mi sembra sostenibile e adatto al breve
  periodo di chiusura (normalmente per pochi giorni non
  farei niente),
  

  

La chiusura totale è per pochi giorni, ma poi ci sarà il senso unico
alternato per alcune settimane, che aggiungerò in seguito.


  

  
 manca
  l’anno 2018 però, così com’è vorrebbe dire l’ 8-11 agosto
  di ogni anno.

  



Dimenticanza. Quindi diventa:


vehicle:conditional=no
@ (2018 Aug 08 07:00-00:00; 2018 Aug 09-10; 2018 Aug 11
00:00-18:00)

  

Ho provato ad inserirlo così ma JOSM mi segnalava un errore.
Così invece è stato preso:
vehicle:conditional=no
@ (2018 Aug 08 07:00-00:00 AND 2018 Aug 09-10 AND 2018 Aug 11
00:00-18:00)

Ciao
Giuliano (bellazambo)



  

  


  

  
  
  
  
  ___
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-it] Piazzola atterraggio elisoccorso notturno

[Gianluca Boero]

Esatto...ad esempio nell'ospedale più vicino, Pinerolo, c'è una piazzola 
(diurna) ad uso esclusivo per gli elicotteri...e questa l'avevo taggata 
già a suo tempo con aeroway=heliport



Il 09/08/2018 09:33, Martin Koppenhoefer ha scritto:


sent from a phone


On 9. Aug 2018, at 09:25, Andrea Musuruane  wrote:

Ho notato inoltre che è sufficiente inserire emergency=landing_site (senza 
aeroway=heliport).


+1, aeroway=heliport sarebbe una cosa diversa, un “aeroporto per elicotteri”, 
cosa un campo da calcio “attrezzato” probabilmente non è.

Ciao, Martin
___
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-it] Piazzola atterraggio elisoccorso notturno

[Martin Koppenhoefer]

sent from a phone

> On 9. Aug 2018, at 09:25, Andrea Musuruane  wrote:
> 
> Ho notato inoltre che è sufficiente inserire emergency=landing_site (senza 
> aeroway=heliport).


+1, aeroway=heliport sarebbe una cosa diversa, un “aeroporto per elicotteri”, 
cosa un campo da calcio “attrezzato” probabilmente non è.

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

Re: [Talk-it] Piazzola atterraggio elisoccorso notturno

[Gianluca Boero]

ok..opterei anche io per il solo tag emergency e poi si...sono d'accordo 
per il tag description


A breve provvedo...devo ancora taggare le luci artificiali del 
campo...che a questo punto sono essenziali.


Ciao...

Gianluca

Il 09/08/2018 09:25, Andrea Musuruane ha scritto:

Ciao,

Il mer 8 ago 2018, 18:52 Martin Koppenhoefer > ha scritto:


se si tratta del campo di calcio, perché aggiungere un ulteriore
nodo? Potresti aggiungere i tags al leisure=pitch


Pensavo perché l'area di atterraggio non è tutto il campo ma 
corrisponde grossomodo con il centrocampo.


Comunque non sono sfavorevole ad aggiunge i tag al campo stesso.

Ho notato inoltre che è sufficiente inserire emergency=landing_site 
(senza aeroway=heliport).


In Trentino qualcuno ha anche aggiunto description=Area indicata per 
l'atterraggio elicottero 118.


Ciao

Andrea



___
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-it] Piazzola atterraggio elisoccorso notturno

[Andrea Musuruane]

Ciao,

Il mer 8 ago 2018, 18:52 Martin Koppenhoefer  ha
scritto:

> se si tratta del campo di calcio, perché aggiungere un ulteriore nodo?
> Potresti aggiungere i tags al leisure=pitch
>

Pensavo perché l'area di atterraggio non è tutto il campo ma corrisponde
grossomodo con il centrocampo.

Comunque non sono sfavorevole ad aggiunge i tag al campo stesso.

Ho notato inoltre che è sufficiente inserire emergency=landing_site (senza
aeroway=heliport).

In Trentino qualcuno ha anche aggiunto description=Area indicata per
l'atterraggio elicottero 118.

Ciao

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

Re: [Talk-de] Wege des WSV an den Kanälen / tagging

[Martin Koppenhoefer]

sent from a phone

> On 8. Aug 2018, at 18:16, Florian Lohoff  wrote:
> 
> Daher würde ich so ein tagging passender finden:
> 
>highway=service
>surface=compacted
>bicycle=permissive
>foot=permissive
>motor_vehicle=private


+1 für service und motor vehicle private, permissive finde ich ein bisschen 
wenig, wenn das Fernradwege sind werden sie wohl auch freigegeben bleiben?



> 
> Wobei ich das mit dem motor_vehicle=private auch doof finde. Das steht
> nirgends, es ist bloss überall durch Poller oder Schranken dafür gesorgt
> das die öffentlichkeit eben mit einem Auto da nicht drauf kommt. 


dann ist private schon ok, physische Barrieren haben denselben Effekt wie 
Schilder im Kontext der Zugänglichkeit 


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

Re: [OSM-talk] highway=* + area=yes vs area:highway=*

[Martin Koppenhoefer]

sent from a phone

> On 8. Aug 2018, at 18:17, Tobias Knerr  wrote:
> 
> Linear roads/paths are mapped as highway=* ways, optionally with an
> additional area:highway=* polygon.
> 
> Plazas/squares are mapped as highway=* + area=yes polygons.


+1
it isn’t clear though, whether area:highway can be applied to the second type 
(square) as well (I would think it can).

cheers,

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

Re: [OSM-talk] highway=* + area=yes vs area:highway=*

[Komяpa]

area:highway= to highway= is what waterway=riverbank to waterway=river.

The first is area used to understand the curvature of the edge, the second
is a routable way. They denote different things and aren't interchangeable.

As with rivers, it's expected that lines are mapped first, and on top of
those detailed polygons are overlaid later.


ср, 8 авг. 2018 г. в 20:11, djakk djakk :

> A linear road is also a surface, the surface is useless at zoom=8 but
> useful at zoom=16.
> Like waterways, both can coexist.
>
> djakk
>
>
>
> Le mer. 8 août 2018 à 18:19, Tobias Knerr  a écrit :
>
>> On 08.08.2018 12:49, Tomasz Wójcik wrote:
>> > Due to our rules, that we shouldn't have 2 active tagging
>> > schemes for the same feature
>>
>> These tagging schemes are for 2 different real-world features:
>> * roads/paths (i.e. linear features with a direction)
>> * plazas/squares (i.e. open areas where people will walk across in all
>> directions)
>>
>> Linear roads/paths are mapped as highway=* ways, optionally with an
>> additional area:highway=* polygon.
>>
>> Plazas/squares are mapped as highway=* + area=yes polygons.
>>
>> So the area:highway key is never an alternative to highway polygons with
>> area=yes! In any given situation, only one or the other will be correct.
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
-- 
Darafei Praliaskouski
Support me: http://patreon.com/komzpa
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk