Re: [OSM-talk] Local language help

[Jo]

The whole country has 3 official languages. In the north nl is the official
language, in the south fr. And a small area in the east is de. Brussels is
officially bilingual. Hence all names there will be a combination of fr -
nl.

Normally I would expect Belgium to not have default_language set. You may
have to keep a list of countries where it only makes sense to look at the
next smaller geographic regions.

I expect the same goes for Switzerland (whole country 3-4 official
languages, but at the next geographic level it is clear which language is
spoken/official for which region).

I think in most multilingual countries the regions are not so clearly
defined.

Jo

2018-05-09 2:37 GMT+02:00 Yuri Astrakhan :

> Polyglot, thanks!  I just ran the list of names for Belgium -
> http://overpass-turbo.eu/s/yEj (takes a few minutes and 20MB download).
> It seems that most of the names are single language.  Even cities tend to
> be a single language strings, with a few exceptions (e.g. Brussels itself,
> and the country name).
>
> So on one hand, we could set default_language to "nl / fr / de" to match
> the country name format, or to two languages that match "Bruxelles -
> Brussel"  ("fr - nl" ?). But in reality, the most helpful value is just a
> single "nl" or "fr" (?), because for almost all "name" tags, there is just
> a single language. The country name is a very rare exception, but it has
> many other name:xx defined anyway, so it is not a problem - if user
> requests "fr" or "nl", there is a name:fr and name:nl. And if user requests
> something that's not defined, at the end it will still fall back to name
> tag.
>
> What do you think?
>
> On Wed, May 9, 2018 at 2:39 AM Jo  wrote:
>
>> Since there is not 1 language for Belgium and nl;fr;de is not allowed, it
>> won't be possible to set this tag for Belgium. I did set it on the
>> regions/communities.
>>
>> Polyglot
>>
>> 2018-05-08 22:31 GMT+02:00 Yuri Astrakhan :
>>
>>> Daniel, I agree - it seems most of the low-zoom Moroccan names are in a
>>> triple-form,  and many local names are in a wild mix of french only and
>>> multi-lingual ones:   https://overpass-turbo.eu/s/yE5 (thx trigpoint &
>>> FredrikLindseth on IRC!)  Do you want to change it, or should I?
>>>
>>> Also, there are still about 60 countries without a tag:
>>> http://tinyurl.com/y9382ewv
>>>
>>>
>>> On Tue, May 8, 2018 at 10:59 PM Daniel Koć  wrote:
>>>
 W dniu 08.05.2018 o 21:31, Yuri Astrakhan pisze:

 > This query shows a list of regions that have the new default_language
 > tag (you can multisort column with shift or control clicking the
 > headers).  http://tinyurl.com/yd6bx6s3

 What about places like Morocco? Shouldn't it be rather similar to
 Belgium - "fr ber ar" (because the name is "Maroc ⵍⵎⵖⵔⵉⴱ المغرب") than
 just "ar"?

 --
 "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
>>>
>>>
>>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-us] Maximum number of tasks on US tasker

[Paul Johnson]

Right, we're only counting striped lanes.

On Tue, May 8, 2018 at 7:43 PM, Jack Burke  wrote:

> But they *are* lanes. They just aren't striped.
>
> -jack
> --
> Typos courtesy of fancy auto spell technology
>
>
> On May 8, 2018 3:24:08 PM EDT, Paul Johnson  wrote:
>>
>> The tag you're looking for is width, not lanes.
>>
>> On Tue, May 8, 2018, 13:29 Tod Fitch  wrote:
>>
>>> Most residential roads in my area are unstriped but are definitely built
>>> for two lanes of traffic (one in each direction). It seems perfectly
>>> reasonable to me to tag them with lanes=2 as they are designed to take two
>>> lanes of traffic.
>>>
>>> In fact, as part of some traffic calming measures a number of
>>> residential roads are having the lane striping removed. They claim that
>>> people tend to drive slower if there is no marking showing the boundary for
>>> oncoming traffic. I certainly will not be removing lanes=2 from those roads.
>>>
>>>
>>> > On May 8, 2018, at 11:20 AM, Mike N  wrote:
>>> >
>>> > On 5/8/2018 11:55 AM, Paul Johnson wrote:
>>> >> Then with residential streets where there are no lanes, often lanes=2
>>> would get tagged anyway despite nothing on the ground suggesting that was
>>> actually the case.
>>> >
>>> >  I hadn't considered that unstriped roads shouldn't have lane tagging,
>>> but at least this doesn't cause bad effects for map data users.
>>> >
>>> > ___
>>> > Talk-us mailing list
>>> > Talk-us@openstreetmap.org
>>> > https://lists.openstreetmap.org/listinfo/talk-us
>>>
>>>
>>> ___
>>> Talk-us mailing list
>>> Talk-us@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-us
>>>
>>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Maximum number of tasks on US tasker

[Jack Burke]

But they *are* lanes. They just aren't striped.

-jack
-- 
Typos courtesy of fancy auto spell technology

On May 8, 2018 3:24:08 PM EDT, Paul Johnson  wrote:
>The tag you're looking for is width, not lanes.
>
>On Tue, May 8, 2018, 13:29 Tod Fitch  wrote:
>
>> Most residential roads in my area are unstriped but are definitely
>built
>> for two lanes of traffic (one in each direction). It seems perfectly
>> reasonable to me to tag them with lanes=2 as they are designed to
>take two
>> lanes of traffic.
>>
>> In fact, as part of some traffic calming measures a number of
>residential
>> roads are having the lane striping removed. They claim that people
>tend to
>> drive slower if there is no marking showing the boundary for oncoming
>> traffic. I certainly will not be removing lanes=2 from those roads.
>>
>>
>> > On May 8, 2018, at 11:20 AM, Mike N  wrote:
>> >
>> > On 5/8/2018 11:55 AM, Paul Johnson wrote:
>> >> Then with residential streets where there are no lanes, often
>lanes=2
>> would get tagged anyway despite nothing on the ground suggesting that
>was
>> actually the case.
>> >
>> >  I hadn't considered that unstriped roads shouldn't have lane
>tagging,
>> but at least this doesn't cause bad effects for map data users.
>> >
>> > ___
>> > Talk-us mailing list
>> > Talk-us@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-us
>>
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk] Local language help

[Yuri Astrakhan]

Polyglot, thanks!  I just ran the list of names for Belgium -
http://overpass-turbo.eu/s/yEj (takes a few minutes and 20MB download).  It
seems that most of the names are single language.  Even cities tend to be a
single language strings, with a few exceptions (e.g. Brussels itself, and
the country name).

So on one hand, we could set default_language to "nl / fr / de" to match
the country name format, or to two languages that match "Bruxelles -
Brussel"  ("fr - nl" ?). But in reality, the most helpful value is just a
single "nl" or "fr" (?), because for almost all "name" tags, there is just
a single language. The country name is a very rare exception, but it has
many other name:xx defined anyway, so it is not a problem - if user
requests "fr" or "nl", there is a name:fr and name:nl. And if user requests
something that's not defined, at the end it will still fall back to name
tag.

What do you think?

On Wed, May 9, 2018 at 2:39 AM Jo  wrote:

> Since there is not 1 language for Belgium and nl;fr;de is not allowed, it
> won't be possible to set this tag for Belgium. I did set it on the
> regions/communities.
>
> Polyglot
>
> 2018-05-08 22:31 GMT+02:00 Yuri Astrakhan :
>
>> Daniel, I agree - it seems most of the low-zoom Moroccan names are in a
>> triple-form,  and many local names are in a wild mix of french only and
>> multi-lingual ones:   https://overpass-turbo.eu/s/yE5 (thx trigpoint &
>> FredrikLindseth on IRC!)  Do you want to change it, or should I?
>>
>> Also, there are still about 60 countries without a tag:
>> http://tinyurl.com/y9382ewv
>>
>>
>> On Tue, May 8, 2018 at 10:59 PM Daniel Koć  wrote:
>>
>>> W dniu 08.05.2018 o 21:31, Yuri Astrakhan pisze:
>>>
>>> > This query shows a list of regions that have the new default_language
>>> > tag (you can multisort column with shift or control clicking the
>>> > headers).  http://tinyurl.com/yd6bx6s3
>>>
>>> What about places like Morocco? Shouldn't it be rather similar to
>>> Belgium - "fr ber ar" (because the name is "Maroc ⵍⵎⵖⵔⵉⴱ المغرب") than
>>> just "ar"?
>>>
>>> --
>>> "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
>>
>>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Local language help

[Jo]

Since there is not 1 language for Belgium and nl;fr;de is not allowed, it
won't be possible to set this tag for Belgium. I did set it on the
regions/communities.

Polyglot

2018-05-08 22:31 GMT+02:00 Yuri Astrakhan :

> Daniel, I agree - it seems most of the low-zoom Moroccan names are in a
> triple-form,  and many local names are in a wild mix of french only and
> multi-lingual ones:   https://overpass-turbo.eu/s/yE5 (thx trigpoint &
> FredrikLindseth on IRC!)  Do you want to change it, or should I?
>
> Also, there are still about 60 countries without a tag:
> http://tinyurl.com/y9382ewv
>
>
> On Tue, May 8, 2018 at 10:59 PM Daniel Koć  wrote:
>
>> W dniu 08.05.2018 o 21:31, Yuri Astrakhan pisze:
>>
>> > This query shows a list of regions that have the new default_language
>> > tag (you can multisort column with shift or control clicking the
>> > headers).  http://tinyurl.com/yd6bx6s3
>>
>> What about places like Morocco? Shouldn't it be rather similar to
>> Belgium - "fr ber ar" (because the name is "Maroc ⵍⵎⵖⵔⵉⴱ المغرب") than
>> just "ar"?
>>
>> --
>> "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
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-ja] 高速道路の定義について

[tomoya muramoto]

 Ras and Road 様

整理いただいてありがとうございます。

今回の議論の範囲外ではありますが、#15のバス専用道路がserviceではない理由を教えていただけませんでしょうか。
私はserviceでよいのではないかと思うのですが。

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

[OSM-talk-fr] Priorité au terrain et plaques ou panneaux bilingues

[Christian Rogel]

Les lecteurs de cette liste ne peuvent ignorer combien j’ai pu, avec l’équipe « 
OpenStreetMap e brezhoneg », m’impiquer dans le multilinguisme des cartes OSM. 
Le site et le blog qui acccompagnent « la carte en breton » contient de 
nombreuses observations utiles. http://www.openstreetmap.bzh/fr/

Il faut bien marquer la différence entre toponyme relevé sur le terrain et 
toponyme traduit ou restitué .
L’usage réel, dans le second cas, est extrêmement variable et il s’agit parfois 
d’un usage postulé et à venir.
Il est donc important que les toponymes affichés en doublet linguistiques 
(couple nom officiel/second nom) soient clairement distingués par « 
source:name:ISO639 = survey ».

Même si cela semble étrange,  il faut traiter de cette manière les noms uniques 
qui sont conformes à l’orthographe moderne de la langue minorisée.
Ex : « name = Hent an Heizez » que l’on accompagne d’un « name:br = Hent an 
Heizez » et d’un « source:name:br = survey », mais, il peut être plus conforme 
de tagger : « source:name:br = copied from name ».

Pour les « restitutions », c’est « source:name:ISO639 = proper translation » 
qui est préconisé, car cela avertit qu’il s’agit d'une initiative individuelle 
soumise à révision.

« Hent » pouvant signifier « Rue », on rencontre sur le cadastre des « RUE HENT 
… «  pour lesquels seule une vérification sur le terrain permet de comprendre 
s’il y a  du bilinguisme ou une fantaisie administrative.
Si l’on regarde les masses de données en jeu, on voit que les cas d’affichage 
officiels bilingues ou « revivalistes » sont peu nombreux par rapport aux 
toponymes ordinaires, même en Bretagne, et cela ne pourra changer avant 
longtemps.

Le problème est de capter la totalité des noms visibles sur le terrain, car il 
se pratique un « renaming en fauteuil » qui contredit quelquefois la réalité, 
particulièrement quand le second nom est un ancien nom qui a été supplanté par 
un autre.
J’en viens au motif principal de ce post: si vous voyez avec vos yeux une 
discordance, rectifiez et mettez « survey » comme source, quitte à effacer le 
nom d’un organisme, si respectable soit-il.


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

Re: [Talk-pt] Zona Militar dos Açores - Dúvida

[Topo Lusitania Lusitania]

Olá

Em Portugal Continental estão relativamente bem mapeados os seguintes locais, 
quer nos mapas que editávamos para os Garmin, quer no OSM

Campo de Tiro de AlcocheteCampo Militar de Santa Margarida
Aeródromo Militar de Tancos e unidades adjacentes (Engenharia, Tropas 
Paraquedistas)
Paióis de Tancos
Zona de Manobras do Regimento de Artilharia de Vendas Novas e paiol
Base Naval do Alfeite
Base Aérea do Montijo
Base Aérea de Monte Real

A única queixa que recebemos de uma entidade militar foi do SCE (Serviço 
Cartográfico do Exercito , à altura) porque nas nossas páginas fizémos 
publicidade a um site espanhol com tinha as cartas M888 modificadas para uso 
directo nos GPS Garmin (formato JNX)
As cartas M888 indicam todas as instalações militares e não são reservadas. Por 
menos de 10 euros podes ter todas as cartas M888 num android... 

Cumprimentos
TopoLusitania 

On Tuesday, May 8, 2018, 6:22:08 PM GMT+1, Emanuel Silva 
 wrote:  
 
 Olá a tod@s,Que vos parece a introdução de algumas áreas, correspondentes à 
Zona Militar dos Açores? A ideia seria recorrer às tags landuse=military e 
outras para edifícios/ árvores etc. Existem instalações no Faial, Terceira, São 
Miguel e Santa Maria. Acham que é permitido do ponto de vista legal a 
introdução destes dados?
Silva1989-- 

Emanuel Silva 
___
Talk-pt mailing list
Talk-pt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-pt
  ___
Talk-pt mailing list
Talk-pt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-pt

Re: [OSM-talk] Local language help

[Yuri Astrakhan]

Daniel, I agree - it seems most of the low-zoom Moroccan names are in a
triple-form,  and many local names are in a wild mix of french only and
multi-lingual ones:   https://overpass-turbo.eu/s/yE5 (thx trigpoint &
FredrikLindseth on IRC!)  Do you want to change it, or should I?

Also, there are still about 60 countries without a tag:
http://tinyurl.com/y9382ewv


On Tue, May 8, 2018 at 10:59 PM Daniel Koć  wrote:

> W dniu 08.05.2018 o 21:31, Yuri Astrakhan pisze:
>
> > This query shows a list of regions that have the new default_language
> > tag (you can multisort column with shift or control clicking the
> > headers).  http://tinyurl.com/yd6bx6s3
>
> What about places like Morocco? Shouldn't it be rather similar to
> Belgium - "fr ber ar" (because the name is "Maroc ⵍⵎⵖⵔⵉⴱ المغرب") than
> just "ar"?
>
> --
> "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

[Talk-it] lingua di default

[Martin Koppenhoefer]

Segnalo questo nuovo tag che indica la lingua del tag name e può essere 
applicato sia a nazioni che a regioni più piccole:

https://wiki.openstreetmap.org/wiki/Key:default_language


Ciao, Martin 


sent from a phone___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk] Local language help

[Daniel Koć]

W dniu 08.05.2018 o 21:31, Yuri Astrakhan pisze:

> This query shows a list of regions that have the new default_language
> tag (you can multisort column with shift or control clicking the
> headers).  http://tinyurl.com/yd6bx6s3

What about places like Morocco? Shouldn't it be rather similar to
Belgium - "fr ber ar" (because the name is "Maroc ⵍⵎⵖⵔⵉⴱ المغرب") than
just "ar"?

-- 
"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-es] Complemento JOSM para Servicios Web de Catastro

[Javier Sánchez Portero]

Me alegro de que de resultados. Espero que pronto este disponible en la
versión estable de Josm.

El mar., 8 may. 2018 19:15, Roberto geb  escribió:

> Gracias Javier, resulta muy útil.
>
> El 12 de abril de 2018, 9:47, Javier Sánchez Portero  > escribió:
>
>> Buenos días
>>
>> He localizado un complemento que hace justo lo que comentaba en el correo
>> anterior pero para República Chéca [1]. Lo he bifurcado en nuestro
>> repositorio [2] y con unas pequeñas modificaciones ya funciona para ver las
>> fotos de fachada de Catastro. Los cambios ya están combinados en el
>> original, pasarán dentro de poco a la versión de desarrollo de JOSM y más
>> adelante aparecerá en la versión estable. Cuando eso pase, se podrá
>> seleccionar e instalar desde el programa. Mientras tanto, he subido al
>> repositorio de Catastro una copia complilada para que lo pueda probar quien
>> quiera instalándolo manualmente.
>>
>> Para instalarlo, descargar este archivo
>>
>>
>> https://github.com/OSM-es/catastro-import/blob/master/pointinfo/pointInfo.jar
>>
>> Copiarlo en la carpeta 'plugins' de JOSM. La localización depende del
>> sistema operativo:
>>
>> https://josm.openstreetmap.de/wiki/Help/Preferences#Defaultlocation
>>
>> En JOSM, en preferencias, complementos, seleccionar pointInfo. Aparecerá
>> una nueva pestaña en el panel de preferencias, con el icono de una
>> interrogación, seleccionar en ella el módulo 'Catastro'.
>>
>> Para usarlo, con una capa de datos activa, en el menú 'Más herramientas'
>> seleccionar la opción 'Información del punto' (tecla rápida Ctrl-Mayús-X).
>> Hacer clic en una posición de la pantalla. Aparecerá una ventana con la
>> referencia catastral, la dirección postal y un enlace a la foto de fachada.
>>
>> Javier
>>
>> [1] https://github.com/mkyral/josm-pointInfo
>> [2] https://github.com/OSM-es/josm-pointInfo
>>
>>
>> El 4 de abril de 2018, 15:05, Javier Sánchez Portero <
>> javiers...@gmail.com> escribió:
>>
>>> Hola
>>>
>>> Llevo tiempo dándole vueltas a alguna forma de hacer accesibles a todo
>>> el mundo las fotos de fachada que proporciona Catastro y tenemos
>>> autorización para usar [1]. Las fotos son un complemento a la observación
>>> sobre el terreno útil para recoger números de portal, estado y tipo de
>>> edificios, comprobar su número de plantas, si tiene balcones, forma del
>>> techo, si aloja comercios o recursos de interés, ocasionalmente el nombre
>>> de la calle, etc, etc.
>>>
>>> Para acceder a una foto hace falta la referencia catastral de la parcela
>>> donde está el edificio. Ahora mismo se puede hacer a través de un fichero
>>> que genera el programa CatAtom2Osm [2], pero me gustaría que se pudiera
>>> acceder más fácilmente desde JOSM.
>>>
>>> Catastro proporciona unos servicios web públicos descritos en [3]. El
>>> que necesitamos es la Consulta_RCCOOR [4], que devuelve la referencia
>>> catastral a partir de las coordenadas. Este es un ejemplo de llamada al
>>> servicio [5] y el enlace a la foto de fachada correspondiente [6].
>>>
>>> El caso de uso sería que en JOSM, haciendo clic con el botón derecho en
>>> el mapa, una opción del menú contextual permitiría obtener los datos de la
>>> parcela (referencia catastral y dirección postal) y mostrar un enlace para
>>> acceder a la foto.
>>>
>>> Creo que no debe ser muy difícil de programar, aunque no tengo
>>> experiencia con complementos de JOSM y me llevará un tiempo documentarme.
>>> Si alguien quiere participar en el desarrollo que se ponga en contacto
>>> conmigo.
>>>
>>> Saludos, Javier.
>>>
>>> [1]
>>> https://wiki.openstreetmap.org/wiki/ES:Fuentes_de_datos_potenciales_de_España#Fotos_de_fachada
>>> [2] https://wiki.openstreetmap.org/wiki/ES:Catastro español/Importación
>>> de edificios/Conversión de datos/Programa#Acceso_a_fotos_de_fachada
>>> [3] http://www.catastro.meh.es/ws/Webservices_Libres.pdf
>>> [4]
>>> https://ovc.catastro.meh.es/ovcservweb/OVCSWLocalizacionRC/OVCCoordenadas.asmx?op=Consulta_RCCOOR
>>> [5]
>>> https://ovc.catastro.meh.es/ovcservweb/OVCSWLocalizacionRC/OVCCoordenadas.asmx/Consulta_RCCOOR?SRS=EPSG:4326_X=-16.3071274_Y=28.4273586
>>> [6]
>>> http://ovc.catastro.meh.es/OVCServWeb/OVCWcfLibres/OVCFotoFachada.svc/RecuperarFotoFachadaGet?ReferenciaCatastral=2251824CS7425S
>>>
>>
>>
>> ___
>> Talk-es mailing list
>> Talk-es@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-es
>>
>>
>
>
> --
> Saludos,
>
>  Roberto
> ___
> 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] Local language help

[Yuri Astrakhan]

Thanks to many people who have helped with this effort!

This query shows a list of regions that have the new default_language tag
(you can multisort column with shift or control clicking the headers).
http://tinyurl.com/yd6bx6s3

This query has also been added to the key:default_language wiki page at the
bottom.

P.S. same query, but with the last editing user included:
http://tinyurl.com/yatfd9sr

On Tue, May 8, 2018 at 12:02 AM Yuri Astrakhan 
wrote:

> Hi, most countries now have a default_language [1] tag, specifying the
> most likely language of the "name" tag in that region.  Here's a list of
> 60+ countries that have multiple official languages.  If you have local
> knowledge, or can research it, could you add the proper default_language
> tag to these relations?  Also, if most of the country uses one language,
> but some region uses a different default language, please set first
> language on the whole country, and the second language on the smaller admin
> region.  Do not set multiple languages, e.g.  "en;fr".  See
> Key:default_language wiki page.
>
> This query generates a list of admin boundary relations that have no
> default_language tag. It also shows country's the official languages per
> Wikidata.http://tinyurl.com/y9382ewv
>
> Wiki page:
> [1] https://wiki.openstreetmap.org/wiki/Key:default_language
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-us] Maximum number of tasks on US tasker

[Paul Johnson]

The tag you're looking for is width, not lanes.

On Tue, May 8, 2018, 13:29 Tod Fitch  wrote:

> Most residential roads in my area are unstriped but are definitely built
> for two lanes of traffic (one in each direction). It seems perfectly
> reasonable to me to tag them with lanes=2 as they are designed to take two
> lanes of traffic.
>
> In fact, as part of some traffic calming measures a number of residential
> roads are having the lane striping removed. They claim that people tend to
> drive slower if there is no marking showing the boundary for oncoming
> traffic. I certainly will not be removing lanes=2 from those roads.
>
>
> > On May 8, 2018, at 11:20 AM, Mike N  wrote:
> >
> > On 5/8/2018 11:55 AM, Paul Johnson wrote:
> >> Then with residential streets where there are no lanes, often lanes=2
> would get tagged anyway despite nothing on the ground suggesting that was
> actually the case.
> >
> >  I hadn't considered that unstriped roads shouldn't have lane tagging,
> but at least this doesn't cause bad effects for map data users.
> >
> > ___
> > Talk-us mailing list
> > Talk-us@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-us
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Maximum number of tasks on US tasker

[Mark Wagner]

What I've observed is that MapRoulette works well with tasks that
are highly localized and don't require much thinking.  "A road crosses a
railroad here: should it be a crossing, or a bridge?" is a good
MapRoulette task, because unusual situations are rare, and the user
doesn't need to consider anything outside the focus point. "This road
segment hasn't been touched in ten years. See if there's anything wrong
with it, and if so, fix it." is bad: the road segment might be a
twenty-mile-long composite of a logging road, a rural highway, and a
driveway, badly aligned, with half the logging end of the road having
been abandoned in the 1970s. The average MapRoulette user is only going
to spot one or two of the problems, and in fixing them, could well
introduce more problems.

-- 
Mark

On Mon, 07 May 2018 22:25:30 -0600
Martijn van Exel  wrote:

> I'd like to learn more about that massive mess and how we can prevent
> that in the future, Paul.To my mind, most TIGER clean up consists of
> atomic tasks, which is where MapRoulette would typically come in
> really handy. (Remember the 70,000 connectivity errors we fixed in
> 2013/4, and the 100,000+ missing railroad crossings which were also
> attributable to TIGER .) But perhaps you have something different in
> mind. I'd like to think MapRoulette can help, also because not
> everybody prefers the same style of working on large projects.--
>   Martijn van Exel
>   m...@rtijn.org
> 
> 
> 
> On Mon, May 7, 2018, at 21:12, Paul Johnson wrote:
> > MapRoulette really made a massive mess of the lanes situation that a
> > more systematic and big-picture effort is starting to get a handle
> > on in Oklahoma.  I think MapRoulette works well for smaller-picture
> > stuff, and is more complimentary to StreetComplete and not terribly
> > great at directing more complicated projects.> 
> > I've restarted my efforts at a county level to avoid having a huge
> > number of tasks that fall largely in Texas, since it seems that the
> > tasking manager is ultimately only capable of dealing with
> > rectangular project areas even if you feed it a more complicated
> > polygon via JSON.> On Mon, May 7, 2018 at 9:32 PM, Martijn van Exel
> >  wrote:>> I’d like to see how TM and MapRoulette could
> > be complementary in this  
> >> effort. I know Clifford has set up a TIGER related challenge on
> >> MapRoulette, and I have done this in the past as well.>> 
> >>  I feel that TM can be good for a general ask like ‘check all TIGER
> >>  residential roads in rural areas in this cell, demote to track /
> >>  unclassified or delete as needed’ whereas MapRoulette may be
> >> useful for more specific TIGER cleanup related tasks?>> 
> >>  Thoughts?
> >> 
> >>  Martijn
> >>   
> >> > On May 5, 2018, at 12:49 PM, Paul Johnson   
> >> > wrote:>>  >   
> >>  > I think it's somewhere between 2000 and 2100.  I'm working on
> >>  > eventually handling the entire state of Oklahoma on a TIGER
> >>  > cleanup and enrichment.  Ideally, I'd like to do the whole state
> >>  > at once (just for variety's sake and for even coverage), but
> >>  > county by county works, too.  If there's a limit for the number
> >>  > of times an area can be split, this could really use some work,
> >>  > too, since 3 (based on tasks2 limit) is not enough.  A 4000 or
> >>  > 5000 task limit should be sufficient for a single county (though
> >>  > definitely won't start off with that many tasks, and almost
> >>  > certainly won't hit that many tasks over the life of a project)
> >>  > if the split limit is increased (like, at least 5, possibly
> >>  > higher just to be on the safe side).>>  > 
> >>  > The idea is to basically keep it in that 75-100 item range per
> >>  > task just to keep it manageable (item count based on the
> >>  > resulting selection when using JOSM search to replace selection
> >>  > and searching for highway=* type:way).>>  > 
> >>  > On Sat, May 5, 2018 at 12:57 PM, Ian Dees   
> >>  > wrote:>>  > I don't know. Do you see a limit somewhere? I'm
> >>  > happy to increase it.>>  > 
> >>  > On Sat, May 5, 2018, 12:35 Paul Johnson   
> >>  > wrote:>>  > What is the maximum number of tasks possible on the
> >>  > US tasker, and is it possible to change that?>>  >
> >>  > ___ Talk-us mailing
> >>  > list Talk-us@openstreetmap.org
> >>  > https://lists.openstreetmap.org/listinfo/talk-us
> >>  > 
> >>  > ___
> >>  > Talk-us mailing list
> >>  > Talk-us@openstreetmap.org
> >>  > https://lists.openstreetmap.org/listinfo/talk-us  
> >>   
> 


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

Re: [Talk-us] Maximum number of tasks on US tasker

[Paul Johnson]

It's basically the opposite problem of overlooking bike, bus and HOV lanes.
Instead of your lane guidance being off by however lanes were omitted,
you're getting lane advice where it's not applicable.

On Tue, May 8, 2018, 13:21 Mike N  wrote:

> On 5/8/2018 11:55 AM, Paul Johnson wrote:
> > Then with residential streets where there are no lanes, often lanes=2
> > would get tagged anyway despite nothing on the ground suggesting that
> > was actually the case.
>
>I hadn't considered that unstriped roads shouldn't have lane tagging,
> but at least this doesn't cause bad effects for map data users.
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-GB] Toys R Us

[Neil Matthews]

previous_name isn't documented -- and seems a bad idea. It's unlikely to
be searchable with Nominatim, and won't be rendered.

This is the scheme some of us are using in Bristol
https://wiki.openstreetmap.org/w/index.php?title=Bristol#Lifecycle.



In an ideal world (!) I'd say use something like disused:name /
proposed:name.

  * disused:name / proposed:name would be searchable.
  * proposed:name and disused:name would both be rendered (at lower
priority to name) and "faintly"
  * validation support

No idea how such a Utopia might be achieved though.

Neil


On 07/05/2018 20:27, Brian Prangle wrote:
> The answer to the question I posed originally seems to be either 
> "never" or "immediately". Maplin I understand waiting some more time
> for the liquidation process to complete. For clarity the mechanical
> edit would be shop=vacant and previous_name=  whichever variant of the
> Toys R us name is present; which preserves the shop amenity  with a
> change of use and preserves the "landmark" data, which I hope answers
> some of the concerns raised so far. Maintaining map data surely has to
> be a mix of automation and hand-crafted, not a zealot position of one
> to the exclusion of the other. If we know data to be inaccurate and
> there is an easy fix surely we're bounden to users of our map to make
> it the best we can. If we adopt Frederick's position(which I see,
> rightly or wrongly, as a quest for ideological purity) we put
> community  before users, when I see it has to be a balance between the
> two. What's the point of  building a map if we don't make it as
> accurate and complete as possible,/*as soon as possible*/? Otherwise
> it's in danger of becoming purely a thing of beauty hand-crafted by
> dedicated hobbyists, with  no thought for all those who have decided
> to use our map.
>
> How long should we wait for a mapper to verify something that's
> changed? Lloyds and TSB  banks demerged 5 years ago - yet we still
> have 180 branches with the old name. Likewise the Territorial Army
> changed name 6 years ago and we still have 27 instances of the old
> name. So how about  volunteers for a campaign to contact local mappers
> and gently encourage them to update the map?
>
> Regards
>
> Brian
>
>
> On 5 May 2018 at 11:57, Rob Nickerson  > wrote:
>
> And for the balance: I disagree with Frederik on this one.
>
> If we know the map is wrong we should fix it. We should not leave
> it just because it may encourage others to fix it and then go on
> to do other local edits.
>
> Frederik's view is that a crap map encourages more people to edit.
> I'm not convinced. A crap map could also put people off - "why
> bother, OSM is so far behind, I'll contribute to/just use Google
> maps instead"
>
> I agree that a *blank* map encourages new mappers, but that was 10
> years ago! Less convinced that an out of date map does. At least
> not with our current homepage or if we do get a new mapper its
> most likely to be a single edit (maybe with MapsMe) rather than a
> new prolific mapper. 
>
> So I'm happy with this mechanical edit (full removal preferred,
> but addition of disussed ok too).
>
> Rob
>
> P.s. Do we still have cases of Lloyds TSB in OSM?
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-gb
> 
>
>
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb

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

Re: [Talk-cz] Pozor JOSM 13710 se asi zblaznil

[jzvc]

Dne 7.5.2018 v 17:01 Marián Kyral napsal(a):

Dne 7.5.2018 v 16:15 Janda Martin napsal(a):

Myslim ze potkat se to nemusi.

2 obdelniky - dotykaji se pouze jednim vrcholem.


To je docela velký extrém který se moc nevidí. V naprosté většině 
případů mají budovy společné dva a více uzlů.

- opravi se jeden, druhy se rozhodi.
- to by ten algoritmus musel uvazovat vsechny mozne prave uhly najednou.


Tady mám empirickou zkušenost, kdy střídavě na daných budovách mačkám 
Q tak dlouho, až se to přestane měnit :-D


Cus, tak je oznac vsechny a mackej Q naraz na vsech ... ;D,  tohle 
funguje uz hodne dlouho, kdyz oznacis vic napojenych objektu a chces je 
zpravouhlit vsechny, tak se k tomu chova jako k jednomu = nejak to lehce 
pootoci, posune a je to pravouhly cely. Skoda ze to neumi i jiny nez 
pravy uhly.




Ale i tak by se vlastne scitala chyba zpusobena opravou. Prikladem 
mohou byt radovky kterych je napr. 5 u sebe. Pokud by se uhly 
opravily u prvni tak posledni muze byt posunuta o docela velky kus.




No a od toho jsi tady ty, abys tyhle posuny korigoval. Buď tak, že 
všechny budovy trochu pootočíš, aby to sedělo, nebo změnu vrátíš 
zpátky a nastavíš, že se má chyba ignorovat.
Osobně tato varování zatím neřeším. Počkám, až to za mně někdo odladí 
( ;-) ) a pak se na to možná znova podívám.


Marián



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



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

Re: [Talk-us] Maximum number of tasks on US tasker

[Tod Fitch]

Most residential roads in my area are unstriped but are definitely built for 
two lanes of traffic (one in each direction). It seems perfectly reasonable to 
me to tag them with lanes=2 as they are designed to take two lanes of traffic.

In fact, as part of some traffic calming measures a number of residential roads 
are having the lane striping removed. They claim that people tend to drive 
slower if there is no marking showing the boundary for oncoming traffic. I 
certainly will not be removing lanes=2 from those roads.


> On May 8, 2018, at 11:20 AM, Mike N  wrote:
> 
> On 5/8/2018 11:55 AM, Paul Johnson wrote:
>> Then with residential streets where there are no lanes, often lanes=2 would 
>> get tagged anyway despite nothing on the ground suggesting that was actually 
>> the case.
> 
>  I hadn't considered that unstriped roads shouldn't have lane tagging, but at 
> least this doesn't cause bad effects for map data users.
> 
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us


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

Re: [Talk-cz] LPIS tracer a multipolygony

[Marián Kyral]

Dne 8.5.2018 v 12:33 Jan Macura napsal(a):
> Pěkný sváteční den,
>
> začal jsem v poslední době používat pLPIS tracer. Proč velká část mých
> snah o jeho použití končí hláškou:
> /"Přetrasování tohoto typu multipolygonu není v současné době
> podporováno"/?
> Mám pocit, že se to týká úplně všech multipolygonů...

Viz:
https://www.superlectures.com/openalt2017/tracer-lpis-aktualizace-natrasovanych-poli-a-jak-se-vyhnout-problemum

Důvodů může být více. Ve zkratce:

* Změna z multipolygonu na normální polygon
* V multipolygonu se nachází otagovaný vnitřní polygon (natural=wood,
natural=scrub...)
* Přetrasovávaný mutipolygon pole je jako inner v nějakém jiném
multipolygonu (třeba landuse=residental)
* Outer cesta se skládá z více segmentů
* ...

 Bohužel aktuálně na to nemám prostor. Navíc moc nerozumím tomu kódu,
který dělal Martin Švec a to je přesně to co je potřeba upravit :-(

Marián

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

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

Re: [Talk-us] Maximum number of tasks on US tasker

[Mike N]

On 5/8/2018 11:55 AM, Paul Johnson wrote:
Then with residential streets where there are no lanes, often lanes=2 
would get tagged anyway despite nothing on the ground suggesting that 
was actually the case.


  I hadn't considered that unstriped roads shouldn't have lane tagging, 
but at least this doesn't cause bad effects for map data users.


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

Re: [Talk-es] Complemento JOSM para Servicios Web de Catastro

[Roberto geb]

Gracias Javier, resulta muy útil.

El 12 de abril de 2018, 9:47, Javier Sánchez Portero 
escribió:

> Buenos días
>
> He localizado un complemento que hace justo lo que comentaba en el correo
> anterior pero para República Chéca [1]. Lo he bifurcado en nuestro
> repositorio [2] y con unas pequeñas modificaciones ya funciona para ver las
> fotos de fachada de Catastro. Los cambios ya están combinados en el
> original, pasarán dentro de poco a la versión de desarrollo de JOSM y más
> adelante aparecerá en la versión estable. Cuando eso pase, se podrá
> seleccionar e instalar desde el programa. Mientras tanto, he subido al
> repositorio de Catastro una copia complilada para que lo pueda probar quien
> quiera instalándolo manualmente.
>
> Para instalarlo, descargar este archivo
>
> https://github.com/OSM-es/catastro-import/blob/master/
> pointinfo/pointInfo.jar
>
> Copiarlo en la carpeta 'plugins' de JOSM. La localización depende del
> sistema operativo:
>
> https://josm.openstreetmap.de/wiki/Help/Preferences#Defaultlocation
>
> En JOSM, en preferencias, complementos, seleccionar pointInfo. Aparecerá
> una nueva pestaña en el panel de preferencias, con el icono de una
> interrogación, seleccionar en ella el módulo 'Catastro'.
>
> Para usarlo, con una capa de datos activa, en el menú 'Más herramientas'
> seleccionar la opción 'Información del punto' (tecla rápida Ctrl-Mayús-X).
> Hacer clic en una posición de la pantalla. Aparecerá una ventana con la
> referencia catastral, la dirección postal y un enlace a la foto de fachada.
>
> Javier
>
> [1] https://github.com/mkyral/josm-pointInfo
> [2] https://github.com/OSM-es/josm-pointInfo
>
>
> El 4 de abril de 2018, 15:05, Javier Sánchez Portero  > escribió:
>
>> Hola
>>
>> Llevo tiempo dándole vueltas a alguna forma de hacer accesibles a todo el
>> mundo las fotos de fachada que proporciona Catastro y tenemos autorización
>> para usar [1]. Las fotos son un complemento a la observación sobre el
>> terreno útil para recoger números de portal, estado y tipo de edificios,
>> comprobar su número de plantas, si tiene balcones, forma del techo, si
>> aloja comercios o recursos de interés, ocasionalmente el nombre de la
>> calle, etc, etc.
>>
>> Para acceder a una foto hace falta la referencia catastral de la parcela
>> donde está el edificio. Ahora mismo se puede hacer a través de un fichero
>> que genera el programa CatAtom2Osm [2], pero me gustaría que se pudiera
>> acceder más fácilmente desde JOSM.
>>
>> Catastro proporciona unos servicios web públicos descritos en [3]. El que
>> necesitamos es la Consulta_RCCOOR [4], que devuelve la referencia catastral
>> a partir de las coordenadas. Este es un ejemplo de llamada al servicio [5]
>> y el enlace a la foto de fachada correspondiente [6].
>>
>> El caso de uso sería que en JOSM, haciendo clic con el botón derecho en
>> el mapa, una opción del menú contextual permitiría obtener los datos de la
>> parcela (referencia catastral y dirección postal) y mostrar un enlace para
>> acceder a la foto.
>>
>> Creo que no debe ser muy difícil de programar, aunque no tengo
>> experiencia con complementos de JOSM y me llevará un tiempo documentarme.
>> Si alguien quiere participar en el desarrollo que se ponga en contacto
>> conmigo.
>>
>> Saludos, Javier.
>>
>> [1] https://wiki.openstreetmap.org/wiki/ES:Fuentes_de_datos_pote
>> nciales_de_España#Fotos_de_fachada
>> [2] https://wiki.openstreetmap.org/wiki/ES:Catastro español/Importación
>> de edificios/Conversión de datos/Programa#Acceso_a_fotos_de_fachada
>> [3] http://www.catastro.meh.es/ws/Webservices_Libres.pdf
>> [4] https://ovc.catastro.meh.es/ovcservweb/OVCSWLocalizacionRC/O
>> VCCoordenadas.asmx?op=Consulta_RCCOOR
>> [5] https://ovc.catastro.meh.es/ovcservweb/OVCSWLocalizacionRC/O
>> VCCoordenadas.asmx/Consulta_RCCOOR?SRS=EPSG:4326_
>> X=-16.3071274_Y=28.4273586
>> [6] http://ovc.catastro.meh.es/OVCServWeb/OVCWcfLibres/OVCFotoFa
>> chada.svc/RecuperarFotoFachadaGet?ReferenciaCatastral=2251824CS7425S
>>
>
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
>


-- 
Saludos,

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

Re: [Talk-us] Maximum number of tasks on US tasker

[Clifford Snow]

Martijn,
When I looked at the problem of un-reviewed roads in Washington State, I
considered two approaches. First, use a Tasking Manager to break the state
into smaller chunks. Looking at the map of the US, Washington State doesn't
seem all that large. But when you get into breaking the state into 1 mile
squares, you'd need over 70,000 tiles to check. The second approach, one
one I ended up using is to use Maproulette to check just TIGER roads
imported that haven't been touched since. There was still 30,000 ways in
the second group. Note - I didn't look at tiger:reviewed=no since most
people, including me, often forget to either change it to yes or just
delete the tag. I think we should just delete the tag like JOSM currently
does.

The clean up effort is still ongoing.

I have personally cleaned up a handful of counties which seems quicker but
that approach doesn't have any backup measures. Backup measures like,
keeping roads in the database until someone checks that they have fixed it
or it wasn't a problem. I like the systematic approach that Maproulette
offers.

MR3 has a feature that I really like. One of regularly editors in Eastern
Washington wanted to look at just roads around him. MR3 as I understand,
can do that.

Now if some company with large amounts of gpx traces were to give us a
point cloud of gpx points, we could quickly start cleaning up these rural
roads. Hint - Hint - Telenav.

As a interesting bit of information, only one way is left untouched in King
County from the original import - and it looks good.

Martijn - I'm not sure I really answered your query. Let me know if you
need more.


Best,
Clifford


-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-GB] Toys R Us

[Dave F]

Is there a tag being used to add these to OSM?

On 08/05/2018 13:14, David Woolley wrote:

On 08/05/18 13:10, Dave F wrote:
I've changed over to using disused:shop=* as it keeps the use of the 
shop in the tag. Due to shop classifications they often reopen with 
businesses of a similar nature. (food, clothes etc)


That reflects the planning classification (which are actually more 
fine grained than the OSM landuses). 

Re: [Talk-us] Maximum number of tasks on US tasker

[Paul Johnson]

I get that, for the most part, MapRoulette does have a overwhelmingly
positive benefit, the lanes challenge seemed quite underbaked.  The end
result was the majority of ways in Oklahoma that had lane tagging added by
way of MR users were not split where the number of lanes changes, two way
roads were counted like they were one-way roads, and restricted lanes (turn
lanes, bike lanes, bus lanes, etc) either weren't counted or didn't get
lane access tagging.  Then with residential streets where there are no
lanes, often lanes=2 would get tagged anyway despite nothing on the ground
suggesting that was actually the case.  It was a very underwhelming result.

On Mon, May 7, 2018, 23:25 Martijn van Exel  wrote:

> I'd like to learn more about that massive mess and how we can prevent that
> in the future, Paul.
> To my mind, most TIGER clean up consists of atomic tasks, which is where
> MapRoulette would typically come in really handy. (Remember the 70,000
> connectivity errors we fixed in 2013/4, and the 100,000+ missing railroad
> crossings which were also attributable to TIGER .) But perhaps you have
> something different in mind. I'd like to think MapRoulette can help, also
> because not everybody prefers the same style of working on large projects.
> --
>   Martijn van Exel
>   m...@rtijn.org
>
>
>
> On Mon, May 7, 2018, at 21:12, Paul Johnson wrote:
>
> MapRoulette really made a massive mess of the lanes situation that a more
> systematic and big-picture effort is starting to get a handle on in
> Oklahoma.  I think MapRoulette works well for smaller-picture stuff, and is
> more complimentary to StreetComplete and not terribly great at directing
> more complicated projects.
>
> I've restarted my efforts at a county level to avoid having a huge number
> of tasks that fall largely in Texas, since it seems that the tasking
> manager is ultimately only capable of dealing with rectangular project
> areas even if you feed it a more complicated polygon via JSON.
>
> On Mon, May 7, 2018 at 9:32 PM, Martijn van Exel  wrote:
>
> I’d like to see how TM and MapRoulette could be complementary in this
> effort. I know Clifford has set up a TIGER related challenge on
> MapRoulette, and I have done this in the past as well.
>
> I feel that TM can be good for a general ask like ‘check all TIGER
> residential roads in rural areas in this cell, demote to track /
> unclassified or delete as needed’ whereas MapRoulette may be useful for
> more specific TIGER cleanup related tasks?
>
> Thoughts?
>
> Martijn
>
> > On May 5, 2018, at 12:49 PM, Paul Johnson  wrote:
> >
> > I think it's somewhere between 2000 and 2100.  I'm working on eventually
> handling the entire state of Oklahoma on a TIGER cleanup and enrichment.
> Ideally, I'd like to do the whole state at once (just for variety's sake
> and for even coverage), but county by county works, too.  If there's a
> limit for the number of times an area can be split, this could really use
> some work, too, since 3 (based on tasks2 limit) is not enough.  A 4000 or
> 5000 task limit should be sufficient for a single county (though definitely
> won't start off with that many tasks, and almost certainly won't hit that
> many tasks over the life of a project) if the split limit is increased
> (like, at least 5, possibly higher just to be on the safe side).
> >
> > The idea is to basically keep it in that 75-100 item range per task just
> to keep it manageable (item count based on the resulting selection when
> using JOSM search to replace selection and searching for highway=*
> type:way).
> >
> > On Sat, May 5, 2018 at 12:57 PM, Ian Dees  wrote:
> > I don't know. Do you see a limit somewhere? I'm happy to increase it.
> >
> > On Sat, May 5, 2018, 12:35 Paul Johnson  wrote:
> > What is the maximum number of tasks possible on the US tasker, and is it
> possible to change that?
> > ___
> > Talk-us mailing list
> > Talk-us@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-us
> >
> > ___
> > Talk-us mailing list
> > Talk-us@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-us
>
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-GB] Toys R Us

[David Woolley]

On 08/05/18 13:10, Dave F wrote:
I've changed over to using disused:shop=* as it keeps the use of the 
shop in the tag. Due to shop classifications they often reopen with 
businesses of a similar nature. (food, clothes etc)


That reflects the planning classification (which are actually more fine 
grained than the OSM landuses). 

Re: [Talk-GB] Toys R Us

[Dave F]

On 07/05/2018 20:27, Brian Prangle wrote:
The answer to the question I posed originally seems to be either  
"never" or "immediately". Maplin I understand waiting some more time 
for the liquidation process to complete. For clarity the mechanical 
edit would be shop=vacant and previous_name=


I've changed over to using disused:shop=* as it keeps the use of the 
shop in the tag. Due to shop classifications they often reopen with 
businesses of a similar nature. (food, clothes etc)


DaveF

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

[Talk-cz] LPIS tracer a multipolygony

[Jan Macura]

Pěkný sváteční den,

začal jsem v poslední době používat pLPIS tracer. Proč velká část mých snah
o jeho použití končí hláškou:
*"Přetrasování tohoto typu multipolygonu není v současné době podporováno"*?
Mám pocit, že se to týká úplně všech multipolygonů...

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

Re: [Talk-in] Extracting rivers as multipolygons

[Arun Ganesh]

On Tue, May 8, 2018 at 2:40 AM, Aruna S  wrote:

> Hey Arun,
>
> > Find all water polygon/relations that intersect with the buffered
> centerlines
> This is the part I was missing. What tags would I be looking for here? I
> see that for https://www.openstreetmap.org/edit#map=16/24.4812/79.8781,
> the tags are
> natural=water
> type=multipolygon
> water=river
>
> Should this suffice for all river-cases?
>
>
You should look for both ways and multipolygons with any of these tags:

   - natural=water
   - waterway=riverbank
   - landuse=reservoir

http://overpass-turbo.eu/s/yCQ
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

[OSM-talk-fr] Parterres et bâtiments particuliers en ville ?

[Cédric Frayssinet]

Bonjour à tous,

En ville, il y a beaucoup de parterres, plus ou moins fleuris. On les
trouve aussi dans des bacs mais aussi entre des routes.

Comment taguez-vous cela ?

En outre, dans les jardins privés de résidence, on trouve de nombreux
'bâtiments' extracteur de fumées des garages ou descente d'escalier vers
les garages. Est-ce qu'il y a un tag particulier pour ce type de bâtiments ?

Merci d'avance,

Cédric


-- 
En cure de désintoxication  de
Google ! Client d'Enercoop
, l'énergie militante

Également sur Mastodon : @bristow...@framapiaf.org


Promouvoir et soutenir le logiciel libre 

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

[Talk-de] Kartennutzung in online-Angeboten des Landes Berlin

[Susanne Jäger]

Hi,

etwas OT, aber vielleicht für den Einen oder die Andere interessant. 
Antwort auf eine kleine Anfrage aus dem Abgeordnetenhaus Berlin.


Titel: Kartenmaterial in Online-Angeboten des Landes Berlin
Abgeordneter: Ziller, Stefan (GRÜNE)
Link: 
http://pardok.parlament-berlin.de/starweb/adis/citat/VT/18/SchrAnfr/S18-13961.pdf


Gruß
Susanne

--
http://sujag.de - Webentwicklung und -beratung
susjae...@sujag.de
Christinenstr. 36, 10119 Berlin, Tel: 030 - 443 241 73

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

[OSM-talk] Fw: FOSS4G Europe 2018 Academic Track

[Suchith Anand]

Fyi. Academic track submission details now available. Details below.


Best wishes,


Suchith



From: OpenGeoscience  on behalf of 
Luí­s Moreira de Sousa 
Sent: 08 May 2018 08:31
To: eur...@lists.osgeo.org; opengeoscie...@lists.osgeo.org
Subject: [OpenGeoscience] FOSS4G-Europe partners with the FOSS4G Academic Track 
system

Dear all,

the Local Organisation Committee of the FOSS4G-Europe conference is happy to 
announce a partnership with the FOSS4G Academic Track 
system to publish and archive its 
academic proceedings. This system has heretofore hosted the proceedings of the 
international FOSS4G conference, and starts this year hosting regional 
conferences.

The LOC further informs that outstanding contributions to the FOSS4G-Europe 
2018 academic track shall be invited to submit an extended article to later 
feature in a special issue of the Data 
journal.

The FOSS4G-Europe 2018 conference takes place in Guimarães, Portugal, from the 
17th to the 19th of July. Please visit the conference web 
page for all the details.

The Local Organisation Committee






This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please contact the sender and delete the email and
attachment. 

Any views or opinions expressed by the author of this email do not
necessarily reflect the views of the University of Nottingham. Email
communications with the University of Nottingham may be monitored 
where permitted by law.




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

Re: [OSM-talk] Using Wikipedia to add names in other languages

[Stefano]

Dear all,
on this point I wanted to link a new discussion that has been started about
the 'licensing' issues of Wikidata elements.

https://phabricator.wikimedia.org/T193728
https://www.wikidata.org/wiki/Wikidata:Project_chat#Importing_datasets_under_incompatible_licenses

Ciao,
Stefano

Il giorno lun 7 mag 2018 alle ore 10:50 Simon Poole  ha
scritto:

>
>
> Am 05.05.2018 um 15:58 schrieb Christoph Hormann:
> > Arguing about licenses and their compatibility does not really help in
> > this context since having formally compatible license (or the related
> > argument that Wikidata is CC0 and therefore by definition the license
> > is a non-issue) would not help.  We have just seen in
> 
> As has been pointed out many many many times an entity providing content
> on CC0 terms does not make any representations that there are no third
> party rights in the material, just that the entity in question does not
> claim any rights (see the text
> https://creativecommons.org/publicdomain/zero/1.0/legalcode).
>
> If the content was originally created by the entity in its entirety,CC0
> is a useful licence, otherwise .
>
> ___
> 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-GB] Toys R Us

[Andrew Hain]

And some with an apostrophe: 
http://taginfo.openstreetmap.org.uk/search?q=Lloyd+TSB#values

--
Andrew

From: Rob Nickerson 
Sent: 08 May 2018 00:19:36
To: Brian Prangle
Cc: Talk-GB
Subject: Re: [Talk-GB] Toys R Us

>Lloyds and TSB  banks demerged 5 years ago - yet we still have 180 branches 
>with the old name.

We also have 7 mapped as "LLoyds TSB", 5 as "Lloyds TSB Bank", 4 as "Lloyds TSB 
Scotland" 3 as (dubious) "Lloyds/TSB", 1 as "LLoyds TSB Bank", 1 as "Lloyds  
TSB" (double space), 1 as "Lloyd's TSB", 1 as "Lloyds TSB Bank Plc", 1 as 
"Lloyds TSB Bank PLC" and 1 as "Lloyds-TSB".

But on the plus side... um, no, that's lost on me!

Sigh.

Rob


On Mon, 7 May 2018 at 20:27, Brian Prangle 
> wrote:
The answer to the question I posed originally seems to be either  "never" or 
"immediately". Maplin I understand waiting some more time for the liquidation 
process to complete. For clarity the mechanical edit would be shop=vacant and 
previous_name=  whichever variant of the Toys R us name is present; which 
preserves the shop amenity  with a change of use and preserves the "landmark" 
data, which I hope answers some of the concerns raised so far. Maintaining map 
data surely has to be a mix of automation and hand-crafted, not a zealot 
position of one to the exclusion of the other. If we know data to be inaccurate 
and there is an easy fix surely we're bounden to users of our map to make it 
the best we can. If we adopt Frederick's position(which I see, rightly or 
wrongly, as a quest for ideological purity) we put community  before users, 
when I see it has to be a balance between the two. What's the point of  
building a map if we don't make it as accurate and complete as possible, as 
soon as possible? Otherwise it's in danger of becoming purely a thing of beauty 
hand-crafted by dedicated hobbyists, with  no thought for all those who have 
decided to use our map.

How long should we wait for a mapper to verify something that's changed? Lloyds 
and TSB  banks demerged 5 years ago - yet we still have 180 branches with the 
old name. Likewise the Territorial Army changed name 6 years ago and we still 
have 27 instances of the old name. So how about  volunteers for a campaign to 
contact local mappers and gently encourage them to update the map?

Regards

Brian


On 5 May 2018 at 11:57, Rob Nickerson 
> wrote:
And for the balance: I disagree with Frederik on this one.

If we know the map is wrong we should fix it. We should not leave it just 
because it may encourage others to fix it and then go on to do other local 
edits.

Frederik's view is that a crap map encourages more people to edit. I'm not 
convinced. A crap map could also put people off - "why bother, OSM is so far 
behind, I'll contribute to/just use Google maps instead"

I agree that a blank map encourages new mappers, but that was 10 years ago! 
Less convinced that an out of date map does. At least not with our current 
homepage or if we do get a new mapper its most likely to be a single edit 
(maybe with MapsMe) rather than a new prolific mapper.

So I'm happy with this mechanical edit (full removal preferred, but addition of 
disussed ok too).

Rob

P.s. Do we still have cases of Lloyds TSB in OSM?

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


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