Re: [Talk-it] Parlano di noi su Repubblica :-)

[Luca Delucchi]

On 27 September 2017 at 15:34, Matteo Zaffonato  wrote:
> http://www.repubblica.it/cronaca/2017/09/27/news/dai_beni_confiscati_alla_street_art_tutti_pazzi_per_crowd_mapping-176618750/
>

Qualcuno ha il contatto dell'autrice del pezzo?

> Ciao
> Matteo
>


-- 
ciao
Luca

www.lucadelu.org

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

Re: [OSM-talk-fr] Présentation

[Jean-Christophe Becquet]

Le 27/09/2017 21:01, Cédric Frayssinet a écrit :
> Merci pour ta remarque. Du coup, cela a fait évolué notre site puisque
> nous venons d'y installer un plugin SPIP qui permet à chaque auteur de
> choisir sa licence, pratique.
> 
> Il est donc passé en CC BY-SA.

Super !

Merci Cédric, je me réjouis de pouvoir partager ton article librement.
https://dane.ac-lyon.fr/spip/OpenStreetMap-la-cartographie

Tu pourrais sans doute le référencer sur le wiki, par exemple ici
http://wiki.openstreetmap.org/wiki/FR:WikiProject_education

Bonne journée

Sincèrement

JC
-- 
Les logiciels libres de gestion de bibliothèques (SIGB)
http://www.apitux.org/index.php?2006/01/18/133-les-logiciels-libres-de-gestion-de-bibliotheques

==APITUX : le choix du logiciel libre==

APITUX - Jean-Christophe Becquet
BP 32 - 04001 Digne-les-Bains Cedex
06 25 86 07 92 - j...@apitux.com - http://www.apitux.com
SIRET : 452 887 441 00031 - APE : 6202A

===



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

Re: [OSM-co] Abreviaturas

[Andres Gomez Casanova]

Buenas noches,

Con respecto a la nomenclatura de las calles, se deben seguir los estándares de 
OSM de no mapear para el render, sino que el render se ajuste a los datos, como 
se explica en este artículo: 
http://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer 
 y que se 
considera como una buena práctica 
http://wiki.openstreetmap.org/wiki/Good_practice 


Teniendo en cuenta lo anterior, poner abreviaturas no es estándar y esto 
implica ajustarse al render. Por este motivo se debe escribir el nombre 
completo, ya sea calle, carrera, diagonal, transversal, etc.
Con respecto a eso, al uso de letras y posibles combinaciones de direcciones 
existe el siguiente artículo para Colombia: 
http://wiki.openstreetmap.org/wiki/ES:Nomenclatura_para_calles_en_Colombia 

Si bien, hay una discusión 
(http://wiki.openstreetmap.org/wiki/ES_talk:Nomenclatura_para_calles_en_Colombia
 
)
 en la que se debe definir si el punto cardinal debe comenzar en mayúsculas, y 
de manera similar el “bis”. Para poder concluir dicha discusión, aprovecho esta 
oportunidad para que todos ustedes den sus puntos de vista en la discusión y 
terminemos de definir concretamente cómo vamos a escribir los nombres.

Con respecto a múltiples nombres, no lo considero apropiado, ya que cualquier 
render medianamente inteligente puede convertir Carrera en Kr; por lo que veo 
innecesario esos múltiples nombres en punto y coma.
También aprovecho para indicar que no se debe poner el nombre oficial dentro 
del name separado por ;
Para esto es mejor usar los múltiples tags de name: 
http://wiki.openstreetmap.org/wiki/Names 
 donde yo apoyaría usar el tag 
official_name. 
Por ejemplo en Bogotá: 
name=Carrera 30 
official_name=Avenida Quito 
alt_name=Avenida NQS

Cordialmente,


Andres Gomez Casanova
AngocA

> On Sep 27, 2017, at 9:35 PM, Fredy Rivera  wrote:
> 
> 
> 
> 2017-09-27 17:55 GMT-05:00 Jorge Aguirre  >:
> Buenas tardes amigos OSM!
> Hola 
> 
> Esta semana pasada visitamos Bogotá para agregar nombres faltantes en las 
> calles.  Nos encontramos con que, aunque hay muchas variantes en la forma 
> escrita de los nombres que se encuentran físicamente en las calles, la 
> constante parecieran ser las abreviatras en los nombres - KR, CA, DG, AC, etc.
> Una de las reglas generales que tenemos en OSM es la de no usar abreviaturas, 
> ya que entre otras razones dificulta la traducción y comprensión en otros 
> idiomas, no obstante existe la posibilidad de usar etiquetas de valor 
> multiple para los caso que los refiera estos valores se pueden separa por 
> "punto y coma" algo como  name= Carrera 7 ; Kr 7 aun que no lo consideraría 
> una buena práctica.
> 
> las directrices para mapear direcciones las puedes encontrar en 
> http://wiki.openstreetmap.org/wiki/Addresses 
> 
> 
> 
> 
> 
> 
> Quiero proponerles, por este medio, que sea cambiado esto a manera que 
> coincida con la forma abreviada que se encuentra escrita en los rótulos sobre 
> las calles de manera que sea más fácil de ingresar los nombres, para luego 
> encontrarlos al estar en las mismas calles físicamente.
> 
> Quisiera saber qué les parece esta propuesta ya que son ustedes los que han 
> creado las "reglas a seguir", pero me parece que este cambio pudiera ser 
> bueno luego de visitar y conducir por toda la ciudad con "ojos frescos".
> 
> Quedo a la espera de sus comentarios.
> Muchas gracias por ciomunicarte.
> 
> Salu2
> Humano. 
> 
> Atentamente,
> 
> Jorge Aguirre
> Geographer
> Kaart Group, LLC
> jo...@kaartgroup.com 
> +(502) 4191 1999 
> www.kaartgroup.com 
> 
> 
> “Let's make our planet great again.”
> 
> - Emmanuel Macron
>   President of France
> 
> 
> 
> ___
> Talk-co mailing list
> Talk-co@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-co 
> 
> 
> 
> 
> 
> -- 
> ##
>  |___|__\___
>  | _ |   |_ |  }  
>  "(_)""  ""(_)"
> 
> Twitter: @fredy_rivera
> Titán Caracol en Técnología y Conectividad
> Coordinador Unidad de Mapeo Humanitario #UMH
> Presidente Fundación OSM Colombia
> Phone: 3044886255
> ___
> Talk-co mailing list
> Talk-co@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-co 
> 
___
Talk-co mailing list

[Talk-us] Mappy Hour / Many Mappy Minutes

[Martijn van Exel]

Hi all,

We had our first virtual mappy hour tonight and it was a lot of fun to chat
with fellow mappers. I wrote a short diary post about it, also announcing
the next edition on November 1:
https://www.openstreetmap.org/user/mvexel/diary/42393

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

Re: [OSM-co] Abreviaturas

[Fredy Rivera]

2017-09-27 17:55 GMT-05:00 Jorge Aguirre :

> Buenas tardes amigos OSM!
>
Hola

>
> Esta semana pasada visitamos Bogotá para agregar nombres faltantes en las
> calles.  Nos encontramos con que, aunque hay muchas variantes en la forma
> escrita de los nombres que se encuentran físicamente en las calles, la
> constante parecieran ser las abreviatras en los nombres - KR, CA, DG, AC,
> etc.
>
Una de las reglas generales que tenemos en OSM es la de no usar
abreviaturas, ya que entre otras razones dificulta la traducción y
comprensión en otros idiomas, no obstante existe la posibilidad de usar
etiquetas de valor multiple para los caso que los refiera estos valores se
pueden separa por "punto y coma" algo como  name= Carrera 7 ; Kr 7 aun que
no lo consideraría una buena práctica.

las directrices para mapear direcciones las puedes encontrar en
http://wiki.openstreetmap.org/wiki/Addresses





> Quiero proponerles, por este medio, que sea cambiado esto a manera que
> coincida con la forma abreviada que se encuentra escrita en los rótulos
> sobre las calles de manera que sea más fácil de ingresar los nombres, para
> luego encontrarlos al estar en las mismas calles físicamente.
>
> Quisiera saber qué les parece esta propuesta ya que son ustedes los que
> han creado las "reglas a seguir", pero me parece que este cambio pudiera
> ser bueno luego de visitar y conducir por toda la ciudad con "ojos frescos".
>
> Quedo a la espera de sus comentarios.
>
Muchas gracias por ciomunicarte.

Salu2
Humano.

>
> Atentamente,
>
> Jorge Aguirre
> Geographer
> Kaart Group, LLC
> jo...@kaartgroup.com
> +(502) 4191 1999 
> www.kaartgroup.com
>
>
>
> *“Let's make our planet great again.”*
> - Emmanuel Macron
>   President of France
>
>
>
> ___
> Talk-co mailing list
> Talk-co@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-co
>
>


-- 
##
 |___|__\___
 | _ |   |_ |  }
 "(_)""  ""(_)"

Twitter: @fredy_rivera
Titán Caracol en Técnología y Conectividad
Coordinador Unidad de Mapeo Humanitario #UMH
Presidente Fundación OSM Colombia
Phone: 3044886255
___
Talk-co mailing list
Talk-co@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-co

Re: [Talk-ca] OSM Canada & State of the Map US: Oct 20-22

[Stewart C. Russell]

On 2017-09-27 05:49 PM, Matthew Darwin wrote:
> Hi,
> 
> Are any Canadian folks going to State of the Map US October 20-22
> https://2017.stateofthemap.us/

Nope. Wish I could afford it.

> During the conference, I would like to have a discussion about turning
> the informal https://www.osmcanada.ca/ into a not-for-profit Canadian
> corporation.

I'd be opposed. Who are osmcanada? They don't represent me. Last I heard
it was an informal group of mappers in Ottawa. What would the non-profit
do? How would it justify its status? Would it be attempting to be an
OSMF Chapter?

 Stewart

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

Re: [Talk-ca] Stats Canada building project

[Stewart C. Russell]

On 2017-09-27 07:00 PM, john whelan wrote:
> No we need to persuade the municipalities to move to the new standard
> license in the TB kit

Is this initiative published anywhere, John? I virtually attended the
conference it was supposed to be announced at, and all there is is
Jean-Noé's announcement:
http://open.canada.ca/en/blog/coming-soon-do-it-yourself-open-data-toolkit

I also don't remember any consultation on what it was going to look like.

 Stewart

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

Re: [Talk-pe] Poder sumar a la Conferencia Estadística de las Américas

[Javier Carranza]

Hola Omar,

Seguimos trabajando en esto para el Censo ofreciendo nuestra ayuda a Anibal
Sanchez , el Dire de INEI.

Ya les dimos apoyo haciendo un app para levantar datos en terreno pero
todavía no conocemos los resultados. Tambien preparamos una declaración
para la próxima CEA y de hecho hemos planeado un osm geo week para
acompañar ese próximo evento en México. De todos modos estaremos en el
State of the Map con esta presentación:
https://2017.stateofthemap.us/program/mosh-pit-style-openstreetmap.html

Quizás también podamos presentarlo en Lima, aunque en el Hot Summit no le
vieron merito a la propuesta. Estamos buscando apoyo aún para ir al SoTM
Latam.



[image: geocensos]
*Javier Carranza** Tresoldi** CEO*

*, GeoCensos@geocensos*Skype: javiercarranza
https://www.youtube.com/watch?v=9cfdYdQHZVY
Colombia Mobile:(57) 314-3244540
Panama Mobile: (507) 688 - 04892
www.geocensos.com
*Lets map together a better world*
 [image: Twitter]
 [image: LinkedIn]


"La información aquí contenida es para uso exclusivo de la persona o
entidad de destino. Está estrictamente prohibida su utilización, copia,
descarga, distribución, modificación y/o reproducción total o parcial, sin
el permiso expreso del representante legal de Fundación Geocensos, pues su
contenido puede ser de carácter confidencial y/o contener material
privilegiado. Si usted recibió esta información por error, por favor
contacte en forma inmediata a quien la envió y borre este material de su
computador. La Fundación GeoCensos no es responsable por la información
contenida en esta comunicación, el directo responsable es quien la firma o
el autor de la misma."

2017-09-27 16:49 GMT-05:00 Omar Vega Ramos :

> El 18/11/15 a las 08:58, Javier Carranza escribió:
> > Hola , muy honrados e inspirados por vuestro apoyo.
> >
> > Te cuento que la declaración se presentó y tuvimos una intervención en
> > la sesión sobre  data revolution ayer. Lo estuvimos tuiteando por
> @geocensos
> >
> > Agregaremos y avisaremos a la comision su adhesión en forma post
> > scriptum.El texto final que presentamos esta en ingles primero y en
> > español despues en https://t.co/RmZxXLq9eR
> >
> > No perdamos el contacto, para ver si podemos trabajar juntos a INEI.
> > Por de pronto, nosotros nos vamos a intentar reunir con el subdirector
> > Anibal Sanchez que esta por estos dìas aca, Hay que insistir.
> >
> > Avísame si se te ocurre una idea que presentarle.
> >
>
> ¿Alguien sabe en que quedó esto? Lo pregunto porque próximamente será el
> censo del 2017.
>
> --
> Omar Vega Ramos
> GPG ID: 9825028B
>
> ___
> Talk-pe mailing list
> Talk-pe@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-pe
>
___
Talk-pe mailing list
Talk-pe@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-pe

Re: [OSM-talk] Adding wikidata tags to the remaining objects with only wikipedia tag

[Andy Townsend]

On 26/09/2017 18:08, Yuri Astrakhan wrote:



  When data consumers want to get a link to corresponding wikipedia
article, doing that with wikipedia[:xx] tags is straightforward. Doing
the same with wikidata requires additional pointless and time
consuming abrakadabra.


no, you clearly haven't worked with any data consumers recently. Data 
consumers want Wikidata, much more than wikipedia tags - please talk 
to them.


That would be me in a former job, I think.

One of the things that I used to spend a lot of time doing was finding 
ways to encode data so that knowledge could be shared by e.g. field 
engineers, and then analysing those results so that you can find out 
what was related to what, what caused what, and how much store you can 
set by a particular result or prediction.  There are a couple of points 
worth sharing from that experience:


1) The first point to make about human-contributed data is that it's 
variable.  Some people will say something is probably an X, some people 
probably a Y.  The reality is that they're actually both right some of 
the time.  You might think (in the context of e.g. shop brands) "hang on 
- surely a shop can be only one brand?  It must be _either_ X or Y!" but 
you'd be wrong.  There are _always_ exceptions, and there will always be 
"errors" - you just don't know which way is right and which wrong.


2) The second point that's relevant here is that codes such as CODE1, 
CODE2 etc. are to be avoided at all costs since they don't enable any 
natural visualisation of what's been captured.  You have already said 
"but surely every system that displays data can look up the description" 
but anyone familar with the real world knows that that simply won't 
happen.  This means that there's no way for an ordinary mapper to verify 
whether the magic code on an OSM item is correct or not.  Verifiability 
is one of the key concepts of OSM (see 
https://wiki.openstreetmap.org/wiki/Verifiability et al) and anything 
that moves away from it means that data isn't going to be maintained, 
because people simply won't understand what it means.  I suspect that a 
key part of the success of OSM was the reliance on natural 
language-based keys and values, and a loose tagging scheme that allowed 
easy expansion.


3) The third point is that a database that has been "cleaned" so that 
there are no "errors" in it is worth far less than one that hasn't, when 
you're trying to understand the complex relationships between objects.  
This goes against most normal data processing instincts because 
obviously normally you'd try and ensure that data has full referential 
integrity - but where there are edge cases (and as per (1) above there 
are always edge cases) different consumers will very likely want to 
treat those edge cases differently, which they can't do if someone has 
"helpfully" merged all the edge cases into more popular categories.



To be blunt, if I was trying to process OSM data and had a need to get 
into the wikidata/wikipedia world based on it (for example because I 
wanted the municipal coat of arms - something not in OSM) I'd take a 
wikipedia link over a wikidata one every time because all mappers will 
have been able to see the text of the wikipedia link rather than just 
something like Q123456.  You've made the point that things change in 
wikipedia regularly (articles get renamed etc.), but it's important to 
remember that things change in the real world all the time as well - and 
a link that's suddenly pointing at something different in wikipedia is 
immediately apparent, in the same way that if Q123456 was no longer 
relevant (because the real world thing has changed) it wouldn't be.


All that said, I don't see wikidata as a key component (or even a very 
useful component) of OSM - but we all map things that are of interest to 
us - some people map in great detail the style of British telephone 
boxes or the "Royal Cipher" on postboxes which I see absolutely no point 
in, but if it's verifiable, why not - I'm sure I'm mapping stuff that is 
irrelevent to them.  A problem with wikidata (as noted above) is that 
I'm not sure that it _is_ verifiable data - I suspect it'll get stale 
after adding and never be maintained, simply because people will never 
notice that it's wrong.


(and on an unrelated comment in the same message)



Sure, it can be via dump parsing, but it is a much more complicated 
than querying.  Would you rather use Overpass turbo to do a quick 
search for some weird thing that you noticed, or download and parse 
the dump?  Most people would rather do the former.


It depends - if you want to do a "quick search for something" then an 
equivalent to overpass turbo might be an option, but in the real world 
what you'd _actually_ want to do is a local database query. 
Unfortunately that side of things seems to be completely missing (or at 
least very well-hidden) - wikidata seems to be quite immature in that 
respect.   Where's 

Re: [OSM-talk] Overlapping brands (was "Fixing wiki* -> brand:wiki*")

[Andy Townsend]

On 27/09/2017 19:47, Marc Gemis wrote:


Is "the same geographical area" relevant ? Why should a data consumer
use a separate datebase to identify the brand of an item ?


Simply because some people had suggested that "brand:wikidata" was 
unnecessary because you could always work out what brand a name was by 
location, and some people had suggested that it was necessary because 
you couldn't - it was just an attempt to find a concrete example; not an 
attempt to prove a point either way.


Of course this is unrelated to whether or not wikidata/wikipedia/any 
other foreign key belongs in OSM (as discussed at length elsewhere).


Best Regards,

Andy


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

[Talk-de] Raiffeisen

[Martin Koppenhoefer]

Angestoßen durch eine Diskussion auf tagging über Händler von „Agrarbedarf“ 
habe ich mir ein paar Raiffeisen in Deutschland angesehen und leider 
festgestellt, dass das kaum bedeutungsvoll getaggt ist. Meistens sind nur der 
Name und landuse tags (wahlweise industrial, retail, farmyard oder commercial, 
m.E. nichts davon (evtl. industrial doch) zutreffend und insbesondere nichts 
davon aussagekräftig) vorhanden. Eigentlich bräuchte man einen landuse tag 
wholesale ;-)

Es gibt dazu im Wiki einen tag:
https://wiki.openstreetmap.org/wiki/Tag:shop%3Dagrarian

was haltet ihr davon, bzw. gibt es Alternativen? 

Wem der tag zusagt bzw. falls es keine verbreiteten Alternativen gibt, dann 
seid ihr hiermit aufgerufen, in eurer Nähe die örtliche Raiffeisen stelle damit 
zu versehen, sofern der tag zutrifft.

Gruß,
Martin 

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

Re: [Talk-ca] Stats Canada building project

[James]

municipalities will follow what the federal is doing. ideally everything
would be public domain, but that would be a utopian world. forget them
switching to ODbL, most people have no idea about it and is very
restrictive when you want to change licenses in the future.

On Sep 27, 2017 7:01 PM, "john whelan"  wrote:

> No we need to persuade the municipalities to move to the new standard
> license in the TB kit and I think Stats will have better success that we
> will in the first instance also Open-Ouvert could probably let us know
> which municipalities have expressed an interest  in the new license.
>
> Cheerio John
>
> On 27 September 2017 at 18:52, Alan Richards  wrote:
>
>> It's still a different license for each city, province, or organisation,
>> and the current opinion is that each different license needs to go through
>> the same multi-month review to be approved for OSM.
>>
>> On Wed, Sep 27, 2017 at 3:48 PM, john whelan 
>> wrote:
>>
>>> T.B. have what they call a Municipal Open Data kit which basically has
>>> the same license as the city of Ottawa uses plus how to use it.
>>>
>>> Cheerio John
>>>
>>> On 27 September 2017 at 18:40, Stewart Russell  wrote:
>>>
 But they can't use OGL-CA v2 cos municipalities aren't federal. And
 anything but the actual few already approved licences need a multi-month
 review.

  Stewart

 On Sep 27, 2017 18:28, "James"  wrote:

> other then have them change their license from say ogl-ca v1 to
> ogl-cav2
>
> theres not much we can do from a legal stand point. ogl-ca v1 puts too
> many restrictions
>
> On Sep 27, 2017 6:21 PM, "Matthew Darwin"  wrote:
>
>> How do we want to move this discussion forward?  Do we need to set up
>> a time to talk on the phone? I am willing to help coordinate logistics.
>>
>> On 2017-09-17 10:55 AM, Stewart C. Russell wrote:
>>
>>> On 2017-09-17 10:40 AM, john whelan wrote:
>>>
 They'd like to extend it across Canada so now might be the time to
 think
 about the project.

>>> That sounds good. Despite some prodding, the Licence Working Group
>>> (LWG)
>>> hasn't got back to me with any updates on how they want to handle the
>>> Toronto or Ontario licences. I first contacted them in March, so if
>>> it
>>> takes them six months or more to look at the licence, then this
>>> import
>>> is a multi year (if not multi-decade) project. Remember, LWG has
>>> decided
>>> that *every* Canadian licence variant needs their sign-off.
>>>
>>> Denis Carr (open data lead) from Toronto has been on board since the
>>> spring, and I hope hasn't forgotten us.
>>>
>>> Toronto has nice building outlines (embedded in the 3D Massing data
>>> set,
>>> so we can pull out base elevation and height). We also have address
>>> points already in the middle of buildings.
>>>
>>> It also is of great help that the Esri Community Imagery includes
>>> some
>>> very nice municipal air photos for verification.
>>>
>>>   Stewart
>>>
>>> ___
>>> Talk-ca mailing list
>>> Talk-ca@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-ca
>>>
>>
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>
 ___
 Talk-ca mailing list
 Talk-ca@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-ca


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

Re: [Talk-se] Ändra linknummer på E-vägar

[Andreas Vilén]

Att nvdb blivit öppen data är förstås inget skäl till att plocka bort data från 
osm, utan snarare tvärtom att tillföra mer data. Dessutom är osm-databasen 
öppen för tillägg vilket imdb inte är.

/Andreas

Skickat från min iPhone

> 25 sep. 2017 kl. 09:54 skrev Mats Elfström :
> 
> Hej!
> För all vägrelaterad information rekommenderas ett studium av trafikverkets 
> nationella vägdatabas, NVDB, som är öppna data.
> Den finns både som nedladdningsbar geodata, eller som wms-tjänst.
> Och man får anse den som den bästa offentligt tillgängliga väginformationen 
> som finns, eftersom den underhålls kontinuerligt. Därmed sagt att den som 
> kopierar data därifrån till OSM, även åtar sig att hålla den rimligt 
> uppdaterad. Och, eftersom pålitlig vägdata numera är öppen, behöver den 
> finnas i OSM? Vägnummer och gatunamn kan behövas, men knappast mer tänker jag.
> 
> Hälsning / Regards
> Mats.E
> 
> Skickat från min / Sent from my iPad, Ursäkta att jag är kortfattad / Excuse 
> my brevity. 
> 
>> 25 sep. 2017 kl. 09:35 skrev talk-se-requ...@openstreetmap.org:
>> 
>> Ändra linknummer på E-vägar
> 
> ___
> Talk-se mailing list
> Talk-se@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-se

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

Re: [Talk-se] Ändra linknummer på E-vägar

[Andreas Vilén]

Fast de vägar som är länkvägar är väl inte skyltade E4 osv med ifyllda ramar 
utan streckade? Då dessa vägsträckor inte är en del av själva e-vägen utan har 
ett internt nummer bör dessa nog inte skyltas med huvudnumret.

Jag tror att skälet till att dessa nummer, liksom de sekundära länsvägarna, 
börjat användas mer i media är för att de renderas på osm och även här och där 
på eniro och andra kartor. Det vore då i min mening synd att åter dölja dessa. 
Men det är egentligen helt rätt att de passar bättre i official_ref eller 
unsigned_ref.

/Andreas

Skickat från min iPhone

> 25 sep. 2017 kl. 09:35 skrev David Olsson :
> 
> Lekmanna-miss av mig. Jag syftar såklart på vägnumret och vad som finns i 
> ref-taggen. Och förstår jag allt rätt så ska "ref" vara i princip det som 
> står på skylten. (E4 i detta fall). 
> Så ändra ref : E 4.26 till enbart ref: E 4 och sedan lägga till en 
> "official_ref : E 4.26" tycks vara den bästa lösningen, likt 1ec5 nämnde i 
> kommentaren på github.
> 
> Ber om ursäkt för missen, jag som tyckte E4 är namnet på vägen när det 
> egentligen är numret. 
> 
> /David
> 
>> On 24 Sep 2017 20:12, "Andreas Vilén"  wrote:
>> Skilj på namn och nummer. De här vägarna har dessa som officiella nummer. De 
>> skyltas vad jag vet inte men används mer och mer i media. Däremot har de 
>> ofta helt andra namn eller inga namn alls. Namnen kan också ändras medan 
>> numret är detsamma.
>> 
>> /Andreas
>> 
>> Skickat från min iPhone
>> 
>>> 24 sep. 2017 kl. 19:00 skrev Martin Norbäck Olivers :
>>> 
>>> Ofta märks väl dessa ut med streckad ram runt numret (E4 i det här fallet)?
>>> 
>>> Vet inte hur man ska tagga det, men official_ref för E 4.26 låter väl bra 
>>> iaf
>>> 
 sön 24 sep. 2017 kl. 18:52 skrev David Olsson :
 Finns många E-vägar som har linknummer (som t.ex E 4.26) 
 http://www.openstreetmap.org/way/76169023
 
 Det blir ett problem med osrm. Minh nämnde att det var bra att börja i 
 mailinglistan. 
 https://github.com/mapbox/mapbox-navigation-ios/issues/637#issuecomment-331589408
 
 Undernumret är det riktiga namnet på vägen hos nvdb/trafikverket och det 
 tycks aldrig vara använt. Någon som vet fall där det används på skyltar? 
 
 Annars låter det som ett korrekt projekt att tagga om så linknummer inte 
 ligger med "ref" iom det inte används (se github-länken). Eller har andra 
 några andra synpunkter kring det?
 
 /david
 ___
 Talk-se mailing list
 Talk-se@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-se
>>> 
>>> -- 
>>> Martin Norbäck Olivers
>>> IT-konsult, Masara AB
>>> Telefon: +46 703 22 70 12
>>> E-post: mar...@norpan.org
>>> Kärrhöksvägen 4
>>> 656 72 Skattkärr
>>> ___
>>> Talk-se mailing list
>>> Talk-se@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-se
>> 
>> ___
>> Talk-se mailing list
>> Talk-se@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-se
>> 
> ___
> Talk-se mailing list
> Talk-se@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-se
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [Talk-ca] Stats Canada building project

[john whelan]

No we need to persuade the municipalities to move to the new standard
license in the TB kit and I think Stats will have better success that we
will in the first instance also Open-Ouvert could probably let us know
which municipalities have expressed an interest  in the new license.

Cheerio John

On 27 September 2017 at 18:52, Alan Richards  wrote:

> It's still a different license for each city, province, or organisation,
> and the current opinion is that each different license needs to go through
> the same multi-month review to be approved for OSM.
>
> On Wed, Sep 27, 2017 at 3:48 PM, john whelan 
> wrote:
>
>> T.B. have what they call a Municipal Open Data kit which basically has
>> the same license as the city of Ottawa uses plus how to use it.
>>
>> Cheerio John
>>
>> On 27 September 2017 at 18:40, Stewart Russell  wrote:
>>
>>> But they can't use OGL-CA v2 cos municipalities aren't federal. And
>>> anything but the actual few already approved licences need a multi-month
>>> review.
>>>
>>>  Stewart
>>>
>>> On Sep 27, 2017 18:28, "James"  wrote:
>>>
 other then have them change their license from say ogl-ca v1 to ogl-cav2

 theres not much we can do from a legal stand point. ogl-ca v1 puts too
 many restrictions

 On Sep 27, 2017 6:21 PM, "Matthew Darwin"  wrote:

> How do we want to move this discussion forward?  Do we need to set up
> a time to talk on the phone? I am willing to help coordinate logistics.
>
> On 2017-09-17 10:55 AM, Stewart C. Russell wrote:
>
>> On 2017-09-17 10:40 AM, john whelan wrote:
>>
>>> They'd like to extend it across Canada so now might be the time to
>>> think
>>> about the project.
>>>
>> That sounds good. Despite some prodding, the Licence Working Group
>> (LWG)
>> hasn't got back to me with any updates on how they want to handle the
>> Toronto or Ontario licences. I first contacted them in March, so if it
>> takes them six months or more to look at the licence, then this import
>> is a multi year (if not multi-decade) project. Remember, LWG has
>> decided
>> that *every* Canadian licence variant needs their sign-off.
>>
>> Denis Carr (open data lead) from Toronto has been on board since the
>> spring, and I hope hasn't forgotten us.
>>
>> Toronto has nice building outlines (embedded in the 3D Massing data
>> set,
>> so we can pull out base elevation and height). We also have address
>> points already in the middle of buildings.
>>
>> It also is of great help that the Esri Community Imagery includes some
>> very nice municipal air photos for verification.
>>
>>   Stewart
>>
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>

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


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

[OSM-co] Abreviaturas

[Jorge Aguirre]

Buenas tardes amigos OSM!

Esta semana pasada visitamos Bogotá para agregar nombres faltantes en las
calles.  Nos encontramos con que, aunque hay muchas variantes en la forma
escrita de los nombres que se encuentran físicamente en las calles, la
constante parecieran ser las abreviatras en los nombres - KR, CA, DG, AC,
etc.

Quiero proponerles, por este medio, que sea cambiado esto a manera que
coincida con la forma abreviada que se encuentra escrita en los rótulos
sobre las calles de manera que sea más fácil de ingresar los nombres, para
luego encontrarlos al estar en las mismas calles físicamente.

Quisiera saber qué les parece esta propuesta ya que son ustedes los que han
creado las "reglas a seguir", pero me parece que este cambio pudiera ser
bueno luego de visitar y conducir por toda la ciudad con "ojos frescos".

Quedo a la espera de sus comentarios.

Atentamente,

Jorge Aguirre
Geographer
Kaart Group, LLC
jo...@kaartgroup.com
+(502) 4191 1999 
www.kaartgroup.com



*“Let's make our planet great again.”*
- Emmanuel Macron
  President of France
___
Talk-co mailing list
Talk-co@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-co

Re: [Talk-ca] Stats Canada building project

[Alan Richards]

It's still a different license for each city, province, or organisation,
and the current opinion is that each different license needs to go through
the same multi-month review to be approved for OSM.

On Wed, Sep 27, 2017 at 3:48 PM, john whelan  wrote:

> T.B. have what they call a Municipal Open Data kit which basically has the
> same license as the city of Ottawa uses plus how to use it.
>
> Cheerio John
>
> On 27 September 2017 at 18:40, Stewart Russell  wrote:
>
>> But they can't use OGL-CA v2 cos municipalities aren't federal. And
>> anything but the actual few already approved licences need a multi-month
>> review.
>>
>>  Stewart
>>
>> On Sep 27, 2017 18:28, "James"  wrote:
>>
>>> other then have them change their license from say ogl-ca v1 to ogl-cav2
>>>
>>> theres not much we can do from a legal stand point. ogl-ca v1 puts too
>>> many restrictions
>>>
>>> On Sep 27, 2017 6:21 PM, "Matthew Darwin"  wrote:
>>>
 How do we want to move this discussion forward?  Do we need to set up a
 time to talk on the phone? I am willing to help coordinate logistics.

 On 2017-09-17 10:55 AM, Stewart C. Russell wrote:

> On 2017-09-17 10:40 AM, john whelan wrote:
>
>> They'd like to extend it across Canada so now might be the time to
>> think
>> about the project.
>>
> That sounds good. Despite some prodding, the Licence Working Group
> (LWG)
> hasn't got back to me with any updates on how they want to handle the
> Toronto or Ontario licences. I first contacted them in March, so if it
> takes them six months or more to look at the licence, then this import
> is a multi year (if not multi-decade) project. Remember, LWG has
> decided
> that *every* Canadian licence variant needs their sign-off.
>
> Denis Carr (open data lead) from Toronto has been on board since the
> spring, and I hope hasn't forgotten us.
>
> Toronto has nice building outlines (embedded in the 3D Massing data
> set,
> so we can pull out base elevation and height). We also have address
> points already in the middle of buildings.
>
> It also is of great help that the Esri Community Imagery includes some
> very nice municipal air photos for verification.
>
>   Stewart
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>

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

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

Re: [Talk-ca] Stats Canada building project

[john whelan]

T.B. have what they call a Municipal Open Data kit which basically has the
same license as the city of Ottawa uses plus how to use it.

Cheerio John

On 27 September 2017 at 18:40, Stewart Russell  wrote:

> But they can't use OGL-CA v2 cos municipalities aren't federal. And
> anything but the actual few already approved licences need a multi-month
> review.
>
>  Stewart
>
> On Sep 27, 2017 18:28, "James"  wrote:
>
>> other then have them change their license from say ogl-ca v1 to ogl-cav2
>>
>> theres not much we can do from a legal stand point. ogl-ca v1 puts too
>> many restrictions
>>
>> On Sep 27, 2017 6:21 PM, "Matthew Darwin"  wrote:
>>
>>> How do we want to move this discussion forward?  Do we need to set up a
>>> time to talk on the phone? I am willing to help coordinate logistics.
>>>
>>> On 2017-09-17 10:55 AM, Stewart C. Russell wrote:
>>>
 On 2017-09-17 10:40 AM, john whelan wrote:

> They'd like to extend it across Canada so now might be the time to
> think
> about the project.
>
 That sounds good. Despite some prodding, the Licence Working Group (LWG)
 hasn't got back to me with any updates on how they want to handle the
 Toronto or Ontario licences. I first contacted them in March, so if it
 takes them six months or more to look at the licence, then this import
 is a multi year (if not multi-decade) project. Remember, LWG has decided
 that *every* Canadian licence variant needs their sign-off.

 Denis Carr (open data lead) from Toronto has been on board since the
 spring, and I hope hasn't forgotten us.

 Toronto has nice building outlines (embedded in the 3D Massing data set,
 so we can pull out base elevation and height). We also have address
 points already in the middle of buildings.

 It also is of great help that the Esri Community Imagery includes some
 very nice municipal air photos for verification.

   Stewart

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

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

Re: [OSM-talk] Overlapping brands (was "Fixing wiki* -> brand:wiki*")

[Martin Koppenhoefer]

sent from a phone

> On 27. Sep 2017, at 23:09, Yuri Astrakhan  wrote:
> 
> Martin, that specific Wikidata item may have some, possibly incomplete data, 
> that can be easily fixed, but that's irrelevant. As I keep saying - the 
> wikidata and wikipedia tags are no different - both point to the same article 
> in Wikipedia.


I think there’s a fundamental difference: when I link a wikipedia article I 
will take a look at the specific article in the specific language and then link 
it. When I link a wikidata item I will look at the properties of this item and 
then link it. I will not read all linked wikipedia articles in all languages, 
and from my experience (looking only at 3 languages) the wikipedia articles in 
different languages differ _a lot_. There are much more often than you‘d 
probably expect articles dealing with different things interlinked. And 
articles dealing with somehow the same subject still differ a lot, in all 
regards, what they cover, what is included (and what is in a different 
article), etc.

Yes, most wikipedia articles point to wikidata objects and most WD obj point to 
WP articles, but this doesn’t mean you can blindly assume they are telling the 
same story/containing the same content.

The stability issues exist in Wikidata as they do in Wikipedia, just on a 
different level: wikipedia articles might get merged, renamed or deleted (and 
you can mostly see this because your link will be dead), but wikidata objects 
change as well (classes (instance of) change, new properties get added, others 
are removed or their meaning changes, etc.)

Yes, it might be possible to fix (sync) everything, but there aren’t enough 
people actually doing it, and it is much easier to create hard to detect new 
problems by changing existing items „with a click“. And because everything is 
linked, it is also impossible to overlook the incredible complexity (unlike 
wikipedia, where an article can be modified a lot but still will tell a similar 
story or the edit will typically get reverted, or it was wrong before).

Maybe it’s really and mostly just an issue of too few people verifying and 
editing Wikidata (e.g. if more properties and other information would be added 
to a WD object, people could easier recognize when the link of the WP article 
in their language is pointing to the wrong object, but it just doesn’t seem to 
happen in reality: WD said for years that human settlements were administrative 
territorial entities, and it was only corrected after it was mentioned here.
It still says a human settlement is a subclass of a geographical point, looking 
at the geographical point object I learnt this is: „point or an area on the 
Earth's surface or elsewhere“ (btw: it’s also a „part of“ (object of which the 
subject is a part.) Earth’s surface, which seems inconsistent as „elsewhere“ is 
not part of Earth‘s surface). Now the settlement is at the same time („all 
instances of these items are instances of those items“) also a subclass of a 
„geographic region“, but the region is „different from“ („item that is 
different from another item, but they are often confused
is notnot to be confused withdistinct fromnot the same asnotisn'tdistinguished 
fromdifferent thansee alsodisambiguated fromnot same as“) a geographical point.

Which contradictions can be ignored and which should be fixed?

cheers,
Martin 



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

Re: [Talk-ca] Stats Canada building project

[James]

Stewart i meant a license based on v2. As toronto is based on v1

On Sep 27, 2017 6:40 PM, "Stewart Russell"  wrote:

> But they can't use OGL-CA v2 cos municipalities aren't federal. And
> anything but the actual few already approved licences need a multi-month
> review.
>
>  Stewart
>
> On Sep 27, 2017 18:28, "James"  wrote:
>
>> other then have them change their license from say ogl-ca v1 to ogl-cav2
>>
>> theres not much we can do from a legal stand point. ogl-ca v1 puts too
>> many restrictions
>>
>> On Sep 27, 2017 6:21 PM, "Matthew Darwin"  wrote:
>>
>>> How do we want to move this discussion forward?  Do we need to set up a
>>> time to talk on the phone? I am willing to help coordinate logistics.
>>>
>>> On 2017-09-17 10:55 AM, Stewart C. Russell wrote:
>>>
 On 2017-09-17 10:40 AM, john whelan wrote:

> They'd like to extend it across Canada so now might be the time to
> think
> about the project.
>
 That sounds good. Despite some prodding, the Licence Working Group (LWG)
 hasn't got back to me with any updates on how they want to handle the
 Toronto or Ontario licences. I first contacted them in March, so if it
 takes them six months or more to look at the licence, then this import
 is a multi year (if not multi-decade) project. Remember, LWG has decided
 that *every* Canadian licence variant needs their sign-off.

 Denis Carr (open data lead) from Toronto has been on board since the
 spring, and I hope hasn't forgotten us.

 Toronto has nice building outlines (embedded in the 3D Massing data set,
 so we can pull out base elevation and height). We also have address
 points already in the middle of buildings.

 It also is of great help that the Esri Community Imagery includes some
 very nice municipal air photos for verification.

   Stewart

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

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

Re: [Talk-ca] Stats Canada building project

[Stewart Russell]

But they can't use OGL-CA v2 cos municipalities aren't federal. And
anything but the actual few already approved licences need a multi-month
review.

 Stewart

On Sep 27, 2017 18:28, "James"  wrote:

> other then have them change their license from say ogl-ca v1 to ogl-cav2
>
> theres not much we can do from a legal stand point. ogl-ca v1 puts too
> many restrictions
>
> On Sep 27, 2017 6:21 PM, "Matthew Darwin"  wrote:
>
>> How do we want to move this discussion forward?  Do we need to set up a
>> time to talk on the phone? I am willing to help coordinate logistics.
>>
>> On 2017-09-17 10:55 AM, Stewart C. Russell wrote:
>>
>>> On 2017-09-17 10:40 AM, john whelan wrote:
>>>
 They'd like to extend it across Canada so now might be the time to think
 about the project.

>>> That sounds good. Despite some prodding, the Licence Working Group (LWG)
>>> hasn't got back to me with any updates on how they want to handle the
>>> Toronto or Ontario licences. I first contacted them in March, so if it
>>> takes them six months or more to look at the licence, then this import
>>> is a multi year (if not multi-decade) project. Remember, LWG has decided
>>> that *every* Canadian licence variant needs their sign-off.
>>>
>>> Denis Carr (open data lead) from Toronto has been on board since the
>>> spring, and I hope hasn't forgotten us.
>>>
>>> Toronto has nice building outlines (embedded in the 3D Massing data set,
>>> so we can pull out base elevation and height). We also have address
>>> points already in the middle of buildings.
>>>
>>> It also is of great help that the Esri Community Imagery includes some
>>> very nice municipal air photos for verification.
>>>
>>>   Stewart
>>>
>>> ___
>>> Talk-ca mailing list
>>> Talk-ca@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-ca
>>>
>>
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Stats Canada building project

[john whelan]

>How do we want to move this discussion forward?  Do we need to set up a
time to talk on the phone? I am willing to help coordinate logistics.

I think we need a contact at Stats and since Bjenk has left I'm not sure
who is doing what.  Alessandro is more management overview than a working
contact although I've cced him so he can identify a point person.

The first step is make sure the municipal license is in alignment with the
TB 2.0 open data license.

So question to Kent/Open-Ouvert how is the municipal Open Data package
coming along?

Thanks John

On 27 September 2017 at 18:20, Matthew Darwin  wrote:

> How do we want to move this discussion forward?  Do we need to set up a
> time to talk on the phone? I am willing to help coordinate logistics.
>
>
> On 2017-09-17 10:55 AM, Stewart C. Russell wrote:
>
>> On 2017-09-17 10:40 AM, john whelan wrote:
>>
>>> They'd like to extend it across Canada so now might be the time to think
>>> about the project.
>>>
>> That sounds good. Despite some prodding, the Licence Working Group (LWG)
>> hasn't got back to me with any updates on how they want to handle the
>> Toronto or Ontario licences. I first contacted them in March, so if it
>> takes them six months or more to look at the licence, then this import
>> is a multi year (if not multi-decade) project. Remember, LWG has decided
>> that *every* Canadian licence variant needs their sign-off.
>>
>> Denis Carr (open data lead) from Toronto has been on board since the
>> spring, and I hope hasn't forgotten us.
>>
>> Toronto has nice building outlines (embedded in the 3D Massing data set,
>> so we can pull out base elevation and height). We also have address
>> points already in the middle of buildings.
>>
>> It also is of great help that the Esri Community Imagery includes some
>> very nice municipal air photos for verification.
>>
>>   Stewart
>>
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Stats Canada building project

[James]

other then have them change their license from say ogl-ca v1 to ogl-cav2

theres not much we can do from a legal stand point. ogl-ca v1 puts too many
restrictions

On Sep 27, 2017 6:21 PM, "Matthew Darwin"  wrote:

> How do we want to move this discussion forward?  Do we need to set up a
> time to talk on the phone? I am willing to help coordinate logistics.
>
> On 2017-09-17 10:55 AM, Stewart C. Russell wrote:
>
>> On 2017-09-17 10:40 AM, john whelan wrote:
>>
>>> They'd like to extend it across Canada so now might be the time to think
>>> about the project.
>>>
>> That sounds good. Despite some prodding, the Licence Working Group (LWG)
>> hasn't got back to me with any updates on how they want to handle the
>> Toronto or Ontario licences. I first contacted them in March, so if it
>> takes them six months or more to look at the licence, then this import
>> is a multi year (if not multi-decade) project. Remember, LWG has decided
>> that *every* Canadian licence variant needs their sign-off.
>>
>> Denis Carr (open data lead) from Toronto has been on board since the
>> spring, and I hope hasn't forgotten us.
>>
>> Toronto has nice building outlines (embedded in the 3D Massing data set,
>> so we can pull out base elevation and height). We also have address
>> points already in the middle of buildings.
>>
>> It also is of great help that the Esri Community Imagery includes some
>> very nice municipal air photos for verification.
>>
>>   Stewart
>>
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [OSM-talk] Adding wikidata tags to the remaining objects with only wikipedia tag

[Yuri Astrakhan]

I have been fixing nodes that have wikipedia but no wikidata tags [1], and
even the first two randomly picked nodes had identical problem - article
was renamed (twice!) without leaving redirects  - node 1136510320

Try it yourself - run the query and see what the it points to.
[1]
https://wiki.openstreetmap.org/wiki/Wikipedia_Link_Improvement_Project#Missing_Wikidata_tags

Imre, I think at this point it might be better to have both, just as a
safety check. But I can already see that they get misaligned - articles
keep getting renamed, so we will be stuck mindlessly updating wikipedia
tag. Feels a bit like a busywork for the sake of work, but might be needed
for a bit.

On Wed, Sep 27, 2017 at 6:00 PM, Imre Samu  wrote:

> > I hope everyone realizes that there are Wikidata items for which there
> > is no Wikipedia article.
> > So you cannot always find it via Wikipedia  tags.
> >  And at least JOSM shows a human readable name of a Wikidata item
> > besides the Q-number. I think iD does this as well.
> > m. (who manually adds Wikidata references for Flemish churches after
> creating the Wikidata items).
>
> imho:
> probably you have a local and domain knowledge on the topic of "Flemish
> churches"
> but for me:  wikidata without wikipedia page - is  extremely suspicious
>
> because:
>
> #1.  Sometimes the " nearby" search for geolocated articles/wikidataids is
> not enough
> for example:
> * at least ~28000 churches exist in the wikidata without coordinates:
> http://tinyurl.com/y8nyk9zw
>
> And probably we will also find wikidata cities without coordinates.
>
> #2. And we should aware of the current "Parallel geo worlds" problem in
> the wikidata[1]
> for example:
> Arad ( major City in Romania ) has 3 wikidata, and we should prefer id
> with wikipedia pages.
> * https://www.wikidata.org/wiki/Q173591 ( with wikipedia pages, linked to
> OSM )
> * https://www.wikidata.org/wiki/Q31886684 (  created by Cebuano import
> [1] ~1 month ago) * https://www.wikidata.org/wiki/Q16898082
>
> [1] wikidata cebuano import problem:
> * https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/
> 2017/08#Dealing_with_our_second_planet * https://www.wikidata.org/wiki/
> Wikidata:Project_chat/Archive/2017/08#Nonsense_imported_from_Geonames
>
>
> Imre
>
>
>
>
>
>
> 2017-09-27 5:03 GMT+02:00 Marc Gemis :
>
>> On Wed, Sep 27, 2017 at 1:17 AM, Andy Townsend  wrote:
>> > That's simply rubbish.  Tags on an OSM object describe it in the real
>> world.
>> > They should be verifiable.  Whether an OSM object has a wikidata tag on
>> it
>> > is essentially irrelevant as far as OSM is concerned - it's just a
>> primary
>> > key into an external database.  External data consumers might find the
>> data
>> > in that database useful, but they can also get to it via wikipedia tags
>> > (which, being human-readable, are more likely to be maintained), so it's
>> > really not a big deal.
>>
>>
>> I hope everyone realizes that there are Wikidata items for which there
>> is no Wikipedia article. So you cannot always find it via Wikipedia
>> tags.
>>
>> And at least JOSM shows a human readable name of a Wikidata item
>> besides the Q-number. I think iD does this as well.
>>
>> m. (who manually adds Wikidata references for Flemish churches after
>> creating the Wikidata items).
>>
>> ___
>> 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-ca] Stats Canada building project

[Matthew Darwin]

How do we want to move this discussion forward?  Do we need to set up 
a time to talk on the phone? I am willing to help coordinate logistics.


On 2017-09-17 10:55 AM, Stewart C. Russell wrote:

On 2017-09-17 10:40 AM, john whelan wrote:

They'd like to extend it across Canada so now might be the time to think
about the project.

That sounds good. Despite some prodding, the Licence Working Group (LWG)
hasn't got back to me with any updates on how they want to handle the
Toronto or Ontario licences. I first contacted them in March, so if it
takes them six months or more to look at the licence, then this import
is a multi year (if not multi-decade) project. Remember, LWG has decided
that *every* Canadian licence variant needs their sign-off.

Denis Carr (open data lead) from Toronto has been on board since the
spring, and I hope hasn't forgotten us.

Toronto has nice building outlines (embedded in the 3D Massing data set,
so we can pull out base elevation and height). We also have address
points already in the middle of buildings.

It also is of great help that the Esri Community Imagery includes some
very nice municipal air photos for verification.

  Stewart

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


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

Re: [OSM-talk] Adding wikidata tags to the remaining objects with only wikipedia tag

[Imre Samu]

> I hope everyone realizes that there are Wikidata items for which there
> is no Wikipedia article.
> So you cannot always find it via Wikipedia  tags.
>  And at least JOSM shows a human readable name of a Wikidata item
> besides the Q-number. I think iD does this as well.
> m. (who manually adds Wikidata references for Flemish churches after
creating the Wikidata items).

imho:
probably you have a local and domain knowledge on the topic of "Flemish
churches"
but for me:  wikidata without wikipedia page - is  extremely suspicious

because:

#1.  Sometimes the " nearby" search for geolocated articles/wikidataids is
not enough
for example:
* at least ~28000 churches exist in the wikidata without coordinates:
http://tinyurl.com/y8nyk9zw

And probably we will also find wikidata cities without coordinates.

#2. And we should aware of the current "Parallel geo worlds" problem in the
wikidata[1]
for example:
Arad ( major City in Romania ) has 3 wikidata, and we should prefer id with
wikipedia pages.
* https://www.wikidata.org/wiki/Q173591 ( with wikipedia pages, linked to
OSM )
* https://www.wikidata.org/wiki/Q31886684 (  created by Cebuano import [1]
   ~1 month ago) * https://www.wikidata.org/wiki/Q16898082

[1] wikidata cebuano import problem:
* https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/
2017/08#Dealing_with_our_second_planet * https://www.wikidata.org/wiki/
Wikidata:Project_chat/Archive/2017/08#Nonsense_imported_from_Geonames


Imre






2017-09-27 5:03 GMT+02:00 Marc Gemis :

> On Wed, Sep 27, 2017 at 1:17 AM, Andy Townsend  wrote:
> > That's simply rubbish.  Tags on an OSM object describe it in the real
> world.
> > They should be verifiable.  Whether an OSM object has a wikidata tag on
> it
> > is essentially irrelevant as far as OSM is concerned - it's just a
> primary
> > key into an external database.  External data consumers might find the
> data
> > in that database useful, but they can also get to it via wikipedia tags
> > (which, being human-readable, are more likely to be maintained), so it's
> > really not a big deal.
>
>
> I hope everyone realizes that there are Wikidata items for which there
> is no Wikipedia article. So you cannot always find it via Wikipedia
> tags.
>
> And at least JOSM shows a human readable name of a Wikidata item
> besides the Q-number. I think iD does this as well.
>
> m. (who manually adds Wikidata references for Flemish churches after
> creating the Wikidata items).
>
> ___
> 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-westmidlands] Next meeting

[Rob Nickerson]

With two people saying no to Thursday (3 if you include me) this month, we
might as well go for Wednesday 4th October.

For pubs those in Birmingham may know better but here are some ideas. I
suggest the first on the list unless anyone knows a reason to rule it out.

- The gunmakers arms. Just round the corner from the bull. (seems to have
it's own micro brewery)
- Queen's Arms, Newhall St
- The Shakespeare, Summer Row
- The Wellington (no event on Wednesday / live folk music on
Thursday). Bennetts
Hill
- The Lost and Found. Bennetts Hill

See you soon,


*Rob*

On 27 September 2017 at 10:16, Andy Robinson  wrote:

> I’m easy, though in Cheshire more and more.
>
>
>
> Cheers
>
> Andy
>
>
>
> *From:* Brian Prangle [mailto:bpran...@gmail.com]
> *Sent:* 27 September 2017 08:15
> *To:* Rob Nickerson
> *Cc:* talk-gb-westmidlands
> *Subject:* Re: [Talk-gb-westmidlands] Next meeting
>
>
>
> Hi Rob
>
> No progress on alternative venue and I definitely can't make Thurs 5th
>
> Regards
>
> Brian
>
>
>
> On 26 September 2017 at 23:59, Rob Nickerson 
> wrote:
>
> Hi all,
>
> Are we back in Birmingham for Octobers meeting? I seem to recall some
> discussion about trying a new venue. Where did we get to on that one?
>
> Also I've screwed up my calendar so Thursday 5th October isn't looking
> that great for me :-( I might have to skip it but throwing the idea of a
> one off Wednesday meeting out there if that works for others. If not the go
> ahead without me on Thursday.
>
> *Rob*
>
>
> ___
> Talk-gb-westmidlands mailing list
> Talk-gb-westmidlands@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
>
>
>
___
Talk-gb-westmidlands mailing list
Talk-gb-westmidlands@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands

[Talk-ca] OSM Canada & State of the Map US: Oct 20-22

[Matthew Darwin]

Hi,

Are any Canadian folks going to State of the Map US October 20-22 
https://2017.stateofthemap.us/


During the conference, I would like to have a discussion about turning 
the informal https://www.osmcanada.ca/ into a not-for-profit Canadian 
corporation.  I'm looking for other folks who think this might be a 
good idea (or maybe have a contrary opinion) and want to talk about it.


Of course comments are accepted here or directly to me 
(matt...@mdarwin.ca).


Thanks!

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

Re: [Talk-pe] Poder sumar a la Conferencia Estadística de las Américas

[Omar Vega Ramos]

El 18/11/15 a las 08:58, Javier Carranza escribió:
> Hola , muy honrados e inspirados por vuestro apoyo.
> 
> Te cuento que la declaración se presentó y tuvimos una intervención en
> la sesión sobre  data revolution ayer. Lo estuvimos tuiteando por @geocensos
> 
> Agregaremos y avisaremos a la comision su adhesión en forma post
> scriptum.El texto final que presentamos esta en ingles primero y en
> español despues en https://t.co/RmZxXLq9eR
> 
> No perdamos el contacto, para ver si podemos trabajar juntos a INEI. 
> Por de pronto, nosotros nos vamos a intentar reunir con el subdirector
> Anibal Sanchez que esta por estos dìas aca, Hay que insistir.
> 
> Avísame si se te ocurre una idea que presentarle.
> 

¿Alguien sabe en que quedó esto? Lo pregunto porque próximamente será el
censo del 2017.

-- 
Omar Vega Ramos
GPG ID: 9825028B

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

Re: [OSM-talk] Fixing wiki* -> brand:wiki*

[Dave F]

Unlikely, I'm sure, but you could have two brands with the same name on 
the same high street. Being antipodean doesn't define their differences.


DaveF.


On 27/09/2017 15:35, John F. Eldredge wrote:
The spatial information will tell you where each business location is; 
it is not sufficient to tell you whether these are multiple locations 
of the same brand, or two unrelated brands that share the same name 
and category of business.



On September 27, 2017 6:51:32 AM Richard Fairhurst 
 wrote:



Andy Mabbett wrote:

in different parts of the world


IIRC OSM stores spatial information. I might be wrong.

Richard



--
Sent from: 
http://gis.19327.n8.nabble.com/General-Discussion-f5171242.html


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




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



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


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

Re: [OSM-talk-fr] Importation des hauteurs de bâtiments sur Nice

[Philippe Verdy]

Un problème entre Cantaron et Falicon, le MNT ne semble pas correct (plat
là où il y a des montagnes) du coup, on a des tas de "tours":

http://demo.f4map.com/#lat=43.7604708=7.3021714=16=27.399


Le 27 septembre 2017 à 18:01, Vincent Frison  a
écrit :

> Hello,
>
> L'import a été fait: 52310 bâtiments ont été mis à jour avec leur hauteur.
>
> Plus de détails sur cette page Wiki
> 
> .
>
> ++ Vincent.
>
> Le 18 septembre 2017 à 17:57, Vincent Frison  a
> écrit :
>
>> Hello,
>>
>> Je projette d'importer dans OSM la hauteur des bâtiments de la ville de
>> Nice, un peu comme je l'avais fait il y a 2 ans pour Paris:
>> http://wiki.openstreetmap.org/wiki/Paris,_France/Buildings_Heights_Import
>>
>> Ici les données viennent du MNT (modèle numérique de terrain) et MNS
>> (modèle numérique de surface) disponible sur le portail Open Data de la
>> métropole Nice Côte d'Azur: http://opendata.niceco
>> tedazur.org/data/dataset/modele-numerique-de-terrain-de-nice-cote-d-azur
>>
>> En fait j'ai déjà lancé un sujet sur le forum: http://forum.openstreet
>> map.fr/viewtopic.php?f=5=6373
>>
>> Mais comme je n'ai pas trop eu de retour je poste ici car il y a
>> visiblement bien plus de trafic (dommage c'est sympa un forum).
>>
>> De ce que j'ai pu voir mes hauteurs calculées sont suffisamment précises
>> mais je ne suis pas contre un petit retour avant de faire l'import (2
>> fichiers d'exemple sont attachés dans mon dernier message du forum). Sinon
>> je compte je faire l'import dès que j'aurai un peu de temps...
>>
>> Merci, Vincent.
>>
>>
>>
>
> ___
> 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] Overlapping brands (was "Fixing wiki* -> brand:wiki*")

[Yuri Astrakhan]

>
> > Specifying Q125054 is the same as specifying "Aldi". If needed/wanted,
> it could be replaced with the more specific wikidata entry like Aldi Nord.
>
> no, it’s not the same, because this wikidata object suggests that there is
> one company, Aldi GmbH & Co. KG, with 2 seats, and one logo.
> Specifying operator:wikipedia=en:Aldi would be similar to specifying
> operator=Aldi and it would be much more precise, because it tells you
> there’s 2 chains of this name, and they are not “supermarkets” but discount
> supermarkets which is very different.
>

Martin, that specific Wikidata item may have some, possibly incomplete
data, that can be easily fixed, but that's irrelevant. As I keep saying -
the wikidata and wikipedia tags are no different - both point to the same
article in Wikipedia. if you want, think of Wikidata as the redirect system
with stable IDs. We don't mind storing "website" with arbitrary URL, why
not store wikipedia with a stable URL?  operator:wikipedia=en:Aldi is bad
simply because it "en:Aldi" is frequently renamed. The wikidata tag can
easily be shown as text by all the tools (some already do). I feel like we
are going the 2nd or 3rd circle by now.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Overlapping brands (was "Fixing wiki* -> brand:wiki*")

[Martin Koppenhoefer]

sent from a phone

> On 27. Sep 2017, at 22:04, Yuri Astrakhan  wrote:
> 
> Martin, you cannot make a general claim based on a single value. 


I didn’t make a general claim based on this, I said it’s another example. 



> Specifying Q125054 is the same as specifying "Aldi". If needed/wanted, it 
> could be replaced with the more specific wikidata entry like Aldi Nord.


no, it’s not the same, because this wikidata object suggests that there is one 
company, Aldi GmbH & Co. KG, with 2 seats, and one logo. 
Specifying operator:wikipedia=en:Aldi would be similar to specifying 
operator=Aldi and it would be much more precise, because it tells you there’s 2 
chains of this name, and they are not “supermarkets” but discount supermarkets 
which is very different.


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

Re: [OSM-talk] Overlapping brands (was "Fixing wiki* -> brand:wiki*")

[Martin Koppenhoefer]

sent from a phone

On 27. Sep 2017, at 21:58, Andy Mabbett  wrote:

>>> the only wikidata example I can
>>> find is https://www.openstreetmap.org/way/25716765
> 
>> which btw. is another good example of misleading and wrong information via
>> wikidata.
> 
> No, it's an example of wrong data in OSM. Albeit on a single object:
> way/25716765


really? So how could we fix it without modifying wikidata?

cheers,
Martin


PS: Ironically, someone using a Pink Floyd related nick just has created an 
item “Aldi brew” (Sud)


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

Re: [OSM-talk] Fixing wiki* -> brand:wiki*

[Lester Caine]

On 27/09/17 20:56, Yuri Astrakhan wrote:
> That formed no part of the early discussions on how wikidata should
> work? I bowed out when the discussions were going down a path I did not
> find to be at all useful. The current offering is certainly a lot more
> 'organised' than those original discussions.
> 
> Getting the initial points across is always a process. Hard to get it
> right from the start :)  I hope we can progress in a more organized and
> beneficial way.

I've been working with data involving addresses and other material for
over 25 years using relation databases, and I don't find many of the
'modern' approaches add anything to managing that data.

> I WOULD still like to see a
> storage model that allows third party lists to be managed and cross
> referenced, but that does not fit the wikidata model. It is why I think
> 
> 'another' cross-reference tool may be more appropriate with OSM and
> wikipedia/wikidata simply being sources.
> 
> I am not exactly sure what you mean here. What goals do you have in mind
> that cannot be stored with the current system?

I'm not sure that every third party source will want their data included
in either OSM or wikidata. I have a large volume of data that I can't
provide access to. I can currently access OSM via coordinates, but I
would like to tie every National Street Gazetteer entry to the matching
objects in OSM. wikidata should probably have an entry for every street
in the UK, but since the NSG data is not currently public domain using
this source is not CURRENTLY possible. Other data sources are linked
using NSG references so mapping those to OSM objects allows that data to
be used where it's licence does allow. Other countries have this same
mix of open data and private stuff which is nowadays a manageable
minefield from which the public domain content can be accessed.

> THAT requires OSM to have a
> 'unique id' one can use to cross reference though :(
> 
>  If a third party list has a list of OSM objects, any time a new object
> is added or existing one is changed, that 3rd party list needs to be
> updated.  Generally you don't want that. Also, it would require a
> substantial fundamental change to OSM data structure and social dynamics
> - the "ID" would have to be placed above all else, like it is done in
> Wikidata.  The ID meaning should never change, and merging two IDs
> should leave a redirect from one to the other.  I doubt that can be
> easily achievable. 

The whole point here is that any change should be easy to pick up. If a
new bus stop is added to that database, a bot monitoring this will pick
up the change and make the change available to other users. Similarly
when a record is updated, and changes that affect the monitoring bot's
target can be flagged. More and more sources are being made open access
and using suitable data to improve OSM's quality should be something
that is easy to manage.

YES the current OSM data structure has a problem when adding this layer
of management. A database like wikidata might be an option to provide
higher level lists of objects, which can then be linked to bot's which
manage primary data such as the NSG's update reports adding new streets
and changes to location hierarchy. But I should prefer that this layer
is part of OSM rather than a third party service.

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

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

[Talk-it] Task incompleto, da me bloccato.

[liste DOT girarsi AT posteo DOT eu]

Si tratta del tasking al seguente indirizzo:

http://osmit-tm.wmflabs.org/project/26

Siccome ho dovuto lasciare il lavoro incompleto per allontanarmi dal pc,
scrivo qui per chi se ne vuole occupare, visto per sbaglio ho cliccato
sul pulsante sbagliato, cioè ho messo come completato, di fatto
autobloccando il task in oggetto a me... :)

Quindi chiedo a chi vuole andare a finirlo, manca ancora qualche building.

Questo il link diretto al task:

http://osmit-tm.wmflabs.org/project/26#task/148



grazie e scusate.


-- 
Simone Girardelli
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|

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

Re: [OSM-talk] Overlapping brands (was "Fixing wiki* -> brand:wiki*")

[Yuri Astrakhan]

That's exactly what we are trying to do.  Add another tag --
brand:wikidata=Q550258

On Wed, Sep 27, 2017 at 4:10 PM, yvecai  wrote:

> Excuse me, but what does wikidata do in this discussion ?
> If brand=wendy is different tham brand=wendy, and if somebody has a
> problem with is it, why not change the key, values or add another tag,
> document it and voila ?
> Yves
>
>
> ___
> 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] Overlapping brands (was "Fixing wiki* -> brand:wiki*")

[yvecai]

Excuse me, but what does wikidata do in this discussion ?
If brand=wendy is different tham brand=wendy, and if somebody has a 
problem with is it, why not change the key, values or add another tag, 
document it and voila ?

Yves

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

Re: [OSM-talk] Overlapping brands (was "Fixing wiki* -> brand:wiki*")

[Yuri Astrakhan]

Martin, you cannot make a general claim based on a single value.  Users can
enter "Aldi", or "Aldi Nord" or "Aldi Sud". With different capitalization
and dashes, and with or without dots, and god knows what other creative
ways to misspell it. Specifying Q125054 is the same as specifying "Aldi".
If needed/wanted, it could be replaced with the more specific wikidata
entry like Aldi Nord.

On Wed, Sep 27, 2017 at 3:50 PM, Martin Koppenhoefer  wrote:

>
>
> sent from a phone
>
> On 27. Sep 2017, at 17:57, Andy Townsend  wrote:
>
> In Germany both Aldi Nord and Aldi Sud operate, but these tend to be
> tagged in OSM as operator rather than brand, and the only wikidata example
> I can find is https://www.openstreetmap.org/way/25716765
>
>
>
>
> which btw. is another good example of misleading and wrong information via
> wikidata. There’s no indication that there are 2 groups of companies (Aldi
> nord and süd) each of which consisting of many companies, instead it seems
> Aldi is one single company “GmbH & Co. KG” (property legal form). There’s
> not even the full name, nor a vatin. It also suggests that the aldi nord
> logo is the logo for this aldi süd instance.
>
>
> If you tag operator=Aldi Süd there’s no problem, but if you tag
> operator:wikidata=
> Q125054
> you introduce errors and uncertainties.
>
>
> cheers,
> Martin
>
> ___
> 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] Overlapping brands (was "Fixing wiki* -> brand:wiki*")

[Andy Mabbett]

On 27 September 2017 at 20:50, Martin Koppenhoefer
 wrote:

> On 27. Sep 2017, at 17:57, Andy Townsend  wrote:

>> the only wikidata example I can
>> find is https://www.openstreetmap.org/way/25716765

> which btw. is another good example of misleading and wrong information via
> wikidata.

No, it's an example of wrong data in OSM. Albeit on a single object:
way/25716765

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [OSM-talk] Fixing wiki* -> brand:wiki*

[Yuri Astrakhan]

>
> That formed no part of the early discussions on how wikidata should
> work? I bowed out when the discussions were going down a path I did not
> find to be at all useful. The current offering is certainly a lot more
> 'organised' than those original discussions.

Getting the initial points across is always a process. Hard to get it right
from the start :)  I hope we can progress in a more organized and
beneficial way.


> I WOULD still like to see a
> storage model that allows third party lists to be managed and cross
> referenced, but that does not fit the wikidata model. It is why I think

'another' cross-reference tool may be more appropriate with OSM and
> wikipedia/wikidata simply being sources.

I am not exactly sure what you mean here. What goals do you have in mind
that cannot be stored with the current system?


> THAT requires OSM to have a
> 'unique id' one can use to cross reference though :(

 If a third party list has a list of OSM objects, any time a new object is
added or existing one is changed, that 3rd party list needs to be updated.
Generally you don't want that. Also, it would require a substantial
fundamental change to OSM data structure and social dynamics - the "ID"
would have to be placed above all else, like it is done in Wikidata.  The
ID meaning should never change, and merging two IDs should leave a redirect
from one to the other.  I doubt that can be easily achievable.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Overlapping brands (was "Fixing wiki* -> brand:wiki*")

[Martin Koppenhoefer]

sent from a phone

> On 27. Sep 2017, at 17:57, Andy Townsend  wrote:
> 
> In Germany both Aldi Nord and Aldi Sud operate, but these tend to be tagged 
> in OSM as operator rather than brand, and the only wikidata example I can 
> find is https://www.openstreetmap.org/way/25716765



which btw. is another good example of misleading and wrong information via 
wikidata. There’s no indication that there are 2 groups of companies (Aldi nord 
and süd) each of which consisting of many companies, instead it seems Aldi is 
one single company “GmbH & Co. KG” (property legal form). There’s not even the 
full name, nor a vatin. It also suggests that the aldi nord logo is the logo 
for this aldi süd instance.


If you tag operator=Aldi Süd there’s no problem, but if you tag 
operator:wikidata=
Q125054
you introduce errors and uncertainties.


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

Re: [OSM-talk] Redacting 75, 000 street names contributed by user chdr

[Martijn van Exel]

Hi Frederik,

That is helpful. Let us know when you have re-executed the analysis and
posted the results.

A list of IDs per county would be helpful. We can work together as US
community to identify viable sources for re-assessing the correct names, as
well as organizing mapping efforts for surveying. We can encourage people
to use StreetComplete as well, which already has a missing names
'challenge', if I remember correctly.

On the topic of StreetComplete, does anyone know how often their challenges
are refreshed? I will add Tobias to the thread, perhaps he can shed some
light on this.

Thanks,
Martijn


On Wed, Sep 27, 2017 at 6:27 AM, Frederik Ramm  wrote:

> Hi,
>
> On 27.09.2017 06:43, Martijn van Exel wrote:
> > In your email from Aug 28 you proposed to wait a while as a first step
> > to gather some feedback on your assessment. Did you receive any? When do
> > you think you want to proceed with the redaction? Anything we can do to
> > help?
>
> I haven't received any feedback other than what came over the lists.
> I'll re-do my analysis and try to take into account changes that people
> have made after chdr and where they mentioned a particular source.
>
> > I can assist with preparing the MapRoulette challenge to re-tag the
> > redacted roads.
>
> > We can take steps to ensure that people use legit
> > sources: run a separate challenge for each region and point to specific
> > sources that can be used for that region, for example.
>
> Frankly, in those regions where we've just a couple 100 affected roads,
> maybe we don't have to do anything at all - the roads will show up on
> generic "name missing" debug views like in OSMI, and will be fixed
> sooner or later. If we concentrate on countries losing 500 names or
> more, that'd be ~ 15 country-wide challenges which should be manageable?
> I could make a list of way IDs per country.
>
> I was hoping to get things over with this month which is going to get a
> bit tight but I'm still planning that. Unless there's a reason to wait?
>
> 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] Fixing wiki* -> brand:wiki*

[Lester Caine]

On 27/09/17 19:46, Yuri Astrakhan wrote:
> Lester, first and foremost, Wikidata is a system to connect the same
> Wikipedia articles in different languages. The "read this article in
> another language" links on the left side comes from Wikidata.  Wikidata
> has developed beyond this initial goal, but it remains the only way to
> identify Wikipedia articles in a language-neutral way, even if a
> specific Wikipedia article is renamed or deleted.

That formed no part of the early discussions on how wikidata should
work? I bowed out when the discussions were going down a path I did not
find to be at all useful. The current offering is certainly a lot more
'organised' than those original discussions. I WOULD still like to see a
storage model that allows third party lists to be managed and cross
referenced, but that does not fit the wikidata model. It is why I think
'another' cross-reference tool may be more appropriate with OSM and
wikipedia/wikidata simply being sources. THAT requires OSM to have a
'unique id' one can use to cross reference though :(

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

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

Re: [OSM-talk] Overlapping brands (was "Fixing wiki* -> brand:wiki*")

[Yuri Astrakhan]

Marc, I think you are confusing the goal and the means to get there.  I
agree - the goal is to be able to globally find all Wendy's, so that when I
travel, I still can search for familiar brands.  So the same brand should
have the same ID everywhere.  That ID can be either textual or numeric.
Both approaches have pros & cons.  The ID can be defined inside OSM - in
which case we must have a globally-coordinated effort to standardize and
document them - e.g. on a wiki, or we can use external IDs.  We already use
some external IDs like ISO-defined "USA" or "TX", but Wikidata is clearly a
much less standard, user-contributable system. I am not sure OSM community
should duplicate the effort of Wikipedia community to redefine concepts.
Look at "denomination" tag - OSM has a long list of values for it, but most
of them are links to Wikipedia.

Lastly, lets not confuse what we *store* (DB) and how we enter/display (UI)
a value.  Data consumers would value cross-referencable IDs much more. The
users on the other hand should see proper text, preferably with additional
things like company's logo.  Wikidata would allow you to show that logo,
and a company description in a dropdown. Text wouldn't.

P.S. Snackbar Wendy's should be in OSM, and judging by media and legal
attention, it should also be in Wikipedia, or at least in Wikidata (which
has much lower barrier of entry).  The searching for it is tricky
- https://en.wikipedia.org/wiki/Goes#Fast_food

P.P.S. I applaud local Wendy's. I am not a big fan of having identical food
brands in every corner of the globe, but that's a personal taste preference

On Wed, Sep 27, 2017 at 2:47 PM, Marc Gemis  wrote:

> >
> > Can anyone think of an example where two unrelated brands share the same
> > name and category of business in the same geographical area?
>
> Is "the same geographical area" relevant ? Why should a data consumer
> use a separate datebase to identify the brand of an item ?
>
> Suppose I want to find all "Wendy's". Why do I need to know that the
> one in The Netherlands does not  belong to the brand found in the US ?
> [1] Shouldn't this be part of the OSM data in some way ?
>
> regards
>
> m
>
> [1] https://www.businessinsider.nl/een-zeeuw-noemde-zn-
> snackbar-wendys-naar-zn-dochter-en-weerstaat-de-gelijknamige-amerikaanse-
> fastfoodgigant/
>
> ___
> 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] Overlapping brands (was "Fixing wiki* -> brand:wiki*")

[Simon Poole]

Am 27.09.2017 um 20:47 schrieb Marc Gemis:
>> Can anyone think of an example where two unrelated brands share the same
>> name and category of business in the same geographical area?
> Is "the same geographical area" relevant ? Why should a data consumer
> use a separate datebase to identify the brand of an item ?
>
> Suppose I want to find all "Wendy's". Why do I need to know that the
> one in The Netherlands does not  belong to the brand found in the US ?
> [1] Shouldn't this be part of the OSM data in some way ?
No?

Both this example and (particularly) the ones given by Mark Wagner,
simply show that there in no way we can expect a "normal" mapper to
choose the right wikidata tag in the first place. It is more correct to
simply record that there is an establishment doing X using brand Y,
because -that- statement of fact isn't wrong.

And yes that probably means that the person querying for "Wendy's" needs
to know that he has to exclude NL, who else?

Simon

PS: particularly brand:wikipedia is rather low use and mainly points to
McDonald's 
> regards
>
> m
>
> [1] 
> https://www.businessinsider.nl/een-zeeuw-noemde-zn-snackbar-wendys-naar-zn-dochter-en-weerstaat-de-gelijknamige-amerikaanse-fastfoodgigant/
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk




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

Re: [OSM-talk-fr] Présentation

[Cédric Frayssinet]

Le 27/09/2017 à 10:47, Jean-Christophe Becquet a écrit :
> Le 26/09/2017 18:25, Cédric Frayssinet a écrit :
>> Je vous informe également que je viens de rédiger un article sur notre
>> site à la Délégation Académique au Numérique Éducatif de Lyon :
>> https://dane.ac-lyon.fr/spip/OpenStreetMap-la-cartographie
>> Cet article se veut accessible, et il est plutôt à destination des
>> enseignants afin qu'il donne envie d'utiliser OpenStreetMap dans leurs
>> séquences pédagogiques ; j'ai mis à la fin quelques exemples de scenarii.
> Merci Cédric, cet article est intéressant.
>
> Accepterais-tu de le partager sous une licence moins restrictive que
> Creative Commons BY-NC-SA, par exemple Creative Commons BY-SA ?
>
> Tu trouveras un argumentaire pour l'abandon de la clause NC sur le site
> de l'April : Libérez vos oeuvres : appel à publier sous licence libre
> http://www.april.org/liberez-vos-oeuvres-appel-publier-sous-licence-libre
>
> ou sur le Framablog : Dis papa, c'est quoi une « œuvre culturelle libre » ?
> http://www.framablog.org/index.php/post/2009/12/08/oeuvre-culturelle-libre
>
> Bonne journée
>
> Librement
>
> JC


Merci pour ta remarque. Du coup, cela a fait évolué notre site puisque
nous venons d'y installer un plugin SPIP qui permet à chaque auteur de
choisir sa licence, pratique.

Il est donc passé en CC BY-SA.

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

Re: [OSM-talk] Adding wikidata tags to the remaining objects with only wikipedia tag

[Marc Gemis]

So you do not agree with the Automated Edits code of conduct ?
If an automated edit takes place in a country, why do you expect that
that community follows the talk mailing list or even speak English ?
People has the right to know that some stranger starts making changes
in their area without being forced to read a mailing list (which is an
outdated medium for the younger) or understand English.

An import has to be discussed with the local community, so why would
an automated edit be different ?

regards

m.

On Wed, Sep 27, 2017 at 5:38 PM, Martin Koppenhoefer
 wrote:
>
>
> 2017-09-27 16:56 GMT+02:00 Andy Mabbett :
>>
>> On 26 September 2017 at 21:39, Martin Koppenhoefer
>>  wrote:
>>
>> >> This might also mean that
>> >> you have to discuss it via Telegram, Facebook, email, IRC, etc.
>> >> depending on where that local community is.
>> >>
>> >> The talk mailing list is not sufficient.
>>
>> > I think this is problematic. If the local community uses a paid service
>> > for
>> > communication you'd have to pay in order to speak to your fellow
>> > mappers?
>>
>> The mapping community in the West Midlands of England communicates
>> most often face-to-face, meeting in a a pub.
>>
>> Perhaps we could mandate that anyone wanting to make an automated edit
>> in the region has to buy the beer?
>
>
>
> you don't only pay with money, e.g. in Facebook you only pay money if you
> are a client of theirs (buying visibility for your advertizing), the
> ordinary users (merchandise) pay with data and their privacy.
>
> Cheers,
> Martin
>
> ___
> 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] Fixing wiki* -> brand:wiki*

[Yuri Astrakhan]

Yves, see above - I listed 3 problems that I would like to solve. Do you
agree with them?
-- Dr. Yuri :)

On Wed, Sep 27, 2017 at 2:44 PM, Yves  wrote:

> I add a look at http://wiki.openstreetmap.org/wiki/Key:brand:wikidata
> Wow.
> So, this tag is about adding an external reference that explains what the
> tag is? Really? This is not a joke?
>
> OSM is sick, please somebody call a doctor.
> Yves
>
>
On Wed, Sep 27, 2017 at 12:14 PM, Yuri Astrakhan 
 wrote:

> I think we should re-start with the definition of the problems we are
> (hopefully) trying to solve, or else we might end up too far in the
> existential realm, which is fun to discuss, but should be left for another
> thread.
>
> * Problem #1:  In my analysis of OSM data, wikipedia tags quickly go stale
> because they use Wikipedia page titles, and titles are constantly renamed,
> deleted, and what's worse - old names are reused for new meanings.  This is
> a fundamental problem with all Wikipedia tags, such as wikipedia,
> brand:wikipedia, operator:wikipedia, etc, that needs solving. The solution
> does not need to be perfect, it just needs to be better than what we have.
>
> * Problem #2: the *meaning* of the "wikipedia" tag is ambiguous, and
> therefor cannot be processed easily. The top three meanings I have seen are:
>   a) This WP article is about this OSM feature (a so called 1:1 match,
> e.g. city, famous building, ...)
>   b) This WP article is about some aspect of this OSM feature, like its
> brand, tree species, or subject of the sculpture
>   c) Only a part of this WP article is about this OSM feature, e.g. a WP
> list of museums in the area contains description of this museum.
>
> * Problem #3: data consumers need cleaner, more machine-processable data.
> The text label is much more error prone than an ID:  McDonalds vs mcdonalds
> vs McDonald's vs ..., so having "brand=mcdonalds" results in many errors.
> Note that just because OSM default map skin may handle some of them
> correctly, each data consumer has to re-implement that logic, so the more
> ambiguous something is, the more likely it will result in errors and data
> omissions.
>
> The brand:wikidata discussion is about #1, #2b, and #3.
>
> Are we in agreement that these are problems, or do you think none of them
> need solving?
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Overlapping brands (was "Fixing wiki* -> brand:wiki*")

[Marc Gemis]

>
> Can anyone think of an example where two unrelated brands share the same
> name and category of business in the same geographical area?

Is "the same geographical area" relevant ? Why should a data consumer
use a separate datebase to identify the brand of an item ?

Suppose I want to find all "Wendy's". Why do I need to know that the
one in The Netherlands does not  belong to the brand found in the US ?
[1] Shouldn't this be part of the OSM data in some way ?

regards

m

[1] 
https://www.businessinsider.nl/een-zeeuw-noemde-zn-snackbar-wendys-naar-zn-dochter-en-weerstaat-de-gelijknamige-amerikaanse-fastfoodgigant/

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

Re: [OSM-talk] Fixing wiki* -> brand:wiki*

[Yuri Astrakhan]

Lester, first and foremost, Wikidata is a system to connect the same
Wikipedia articles in different languages. The "read this article in
another language" links on the left side comes from Wikidata.  Wikidata has
developed beyond this initial goal, but it remains the only way to identify
Wikipedia articles in a language-neutral way, even if a specific Wikipedia
article is renamed or deleted.

On Wed, Sep 27, 2017 at 2:13 PM, Lester Caine  wrote:

> On 27/09/17 17:40, Andy Mabbett wrote:
> >> Not on a number of articles I've recently been looking at while checking
> >> out the CURRENT wikidata offering. I've not found wikidata id's on the
> >> wikipedia articles I looked at ... but wikidata does seem something I
> >> should perhaps reassess.
> > You not having found them does not mean that they are not there.
> >
> > teh only Wikipedia articles with no Wikidata ID are those that are
> > newly created.
> >
> > Otherwise, you will find the "Wikidata item" link in the left-hand
> > navigation pane (using the default desktop view)
>
> AH - so it's stripped when you grab a printed copy of the article :(
> There may be a link to Wikimedia Commons material, but not to wikidata
> material in external links ... that is where I expected to find it ;)
>
> --
> Lester Caine - G8HFL
> -
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk
> Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
>
> ___
> 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] Fixing wiki* -> brand:wiki*

[Yves]

I add a look at http://wiki.openstreetmap.org/wiki/Key:brand:wikidata
Wow. 
So, this tag is about adding an external reference that explains what the tag 
is? Really? This is not a joke? 

OSM is sick, please somebody call a doctor. 
Yves 

Le 27 septembre 2017 19:14:53 GMT+02:00, Mark Wagner  a 
écrit :
>On Wed, 27 Sep 2017 06:49:40 -0500 (CDT)
>Richard Fairhurst  wrote:
>
>> Andy Mabbett wrote:
>> > in different parts of the world  
>> 
>> IIRC OSM stores spatial information. I might be wrong.
>> 
>
>Two examples that can't be resolved by a spatial query:
>
>1) There is a business near me named "Maxwell House".  It is entirely
>unrelated to the coffee brand of that name, despite both companies
>operating in the same country.
>
>2) Until recently, there was a burger joint in town called "Sonic's"
>that was entirely unrelated to the chain of drive-in eateries.  (When
>the national chain opened up a location in town, they paid the existing
>restaurant to re-brand.)
>
>-- 
>Mark
>
>___
>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-ie] overpass-turbo.openstreetmap.ie

[Colm Moore]

Hi,


Thanks for your efforts guys.


Colm


---
Never doubt that a small group of thoughtful, committed citizens can change the 
world. Indeed, it is the only thing that ever has. Margaret Mead

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

Re: [OSM-talk-ie] Email privacy

[Colm Moore]

Hi,


It's not about privacy as such, more about the spam risk (I'm getting a fair 
bit of phishing at the moment).


Pages like that would be ripe for harvesting email addresses.


Colm


---
Never doubt that a small group of thoughtful, committed citizens can change the 
world. Indeed, it is the only thing that ever has. Margaret Mead


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

Re: [OSM-talk] Fixing wiki* -> brand:wiki*

[Lester Caine]

On 27/09/17 17:40, Andy Mabbett wrote:
>> Not on a number of articles I've recently been looking at while checking
>> out the CURRENT wikidata offering. I've not found wikidata id's on the
>> wikipedia articles I looked at ... but wikidata does seem something I
>> should perhaps reassess.
> You not having found them does not mean that they are not there.
> 
> teh only Wikipedia articles with no Wikidata ID are those that are
> newly created.
> 
> Otherwise, you will find the "Wikidata item" link in the left-hand
> navigation pane (using the default desktop view)

AH - so it's stripped when you grab a printed copy of the article :(
There may be a link to Wikimedia Commons material, but not to wikidata
material in external links ... that is where I expected to find it ;)

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

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

Re: [Talk-at] Adressen übernehmen mit Adresshelper

[Andreas]

Am 2017-09-27 um 17:32 schrieb Friedrich Volkmann:
> On 27.09.2017 11:22, Walter Krammer wrote:
>> Ich trage jetzt seit einigen Tagen mit der JOSM-Erweiterung
>> adresshelper in einigen Kärntner Gemeinden die Hausnummern ein. Dann
>> kontrolliere ich mit dem OSM.Inspector von Geofabrik die Einträge.
>
> Bitte nicht! Wenn du für so was einen Validator verwendest, und OSMI
> ist einer der schlimmsten, dann kommt nur Blödsinn heraus. Es gibt
> unzählige Möglichkeiten, Adressen zu mappen - ein ewiges Streitthema!
> Das betrifft nicht nur St./Sankt, sondern auch
> addr:place/hamlet/street und addr:housenumber/conscriptionnumber,
> weiters die Platzierung (Adressnode/Eingang/Gebäude/Grundstück), von
> Identadressen ganz zu schweigen. Wenn in einer Ortschaft schon viele
> Adressen gemappt sind, dann lass sie daher möglichst so wie sie sind,
> denn derjenige, der sie so gemappt hat, wird sich etwas dabei gedacht
> haben. Im Zweifelsfall schreib ihn an und mach dir das weitere
> Vorgehen mit ihm aus.
? Wie ich Hr. Krammer verstanden habe, trägt er nur Hausnummern ein, die
noch nicht existieren und führt keine Korrektur von bestehenden Adressen
durch. Er überprüft nur seine Eintragungen mit den Validatoren.
>
> Und die OpenGeoDB vergiss genauso wie die Validatoren, denn die
> OpenGeoDB enthält viele Fehler, und die Verknüpfung der OpenGeoDB mit
> OSM ist ein längst aufgegebenes Projekt.
>
>> Meine Frage ist: Wie soll ich richtig vorgehen?
>
> Wiki lesen, die schon gemappten Adressen anschauen, dich mit den
> lokalen Mappern verständigen und vor allem selber denken.
>
Ich finde eine berechtigte Frage und schau ins Wiki, wenn die Lage nicht
so eindeutig ist, denke ich nicht, dass eine große Hilfe ist. Vor allem
wenn man sich mit Adressen beschäftigt, hat man sich sicherlich schon
mit dem Wiki über das Thema vertraut gemacht. Es stellt sich die Frage,
ob man die Adressen nun so machen will wie es offiziell vom BEV
vorgegeben wird oder sich eben an die OpenGeoDB halten soll?

Hm, ich habe mich in meiner Ortschaft auch eine zeitlang mit den
Adressen beschäftigt und habs dann aufgegeben, weil es dafür keine
vernünftige Vorgabe gibt nach der man sich richten kann. Mein Problem
damit ist vielleicht, dass ich aus meinem beruflichen Alltag gewohnt
bin, dass ich vorgegebene Schemata habe, nach denen man dann auch die
Daten validieren kann. Finde es interessant, dass Routing-SW überhaupt
mit OSM funktioniert, wenn es bei Adressen keine einheitliche Norm gibt.

Andreas alias Geologist



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

Re: [OSM-talk] Fixing wiki* -> brand:wiki*

[Mark Wagner]

On Wed, 27 Sep 2017 06:49:40 -0500 (CDT)
Richard Fairhurst  wrote:

> Andy Mabbett wrote:
> > in different parts of the world  
> 
> IIRC OSM stores spatial information. I might be wrong.
> 

Two examples that can't be resolved by a spatial query:

1) There is a business near me named "Maxwell House".  It is entirely
unrelated to the coffee brand of that name, despite both companies
operating in the same country.

2) Until recently, there was a burger joint in town called "Sonic's"
that was entirely unrelated to the chain of drive-in eateries.  (When
the national chain opened up a location in town, they paid the existing
restaurant to re-brand.)

-- 
Mark

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

Re: [Talk-us] Missing imagery in JOSM

[Mark Wagner]

On Wed, 27 Sep 2017 12:14:03 -0400
"Mark Bradley"  wrote:

> What happened to the USGS topographic map imagery that was available
> in JOSM until a few days ago?

Still there for me, though something's changed: when you zoom out, it
no longer switches away from the 1:24000 maps, but instead displays
them scaled down.

-- 
Mark

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

Re: [OSM-talk] Fixing wiki* -> brand:wiki*

[Andy Mabbett]

On 27 September 2017 at 17:31, Lester Caine  wrote:
> On 27/09/17 16:48, Andy Mabbett wrote:
>> On 27 September 2017 at 16:06, Lester Caine  wrote:

>>> critically I'd prefer to see the wikipedia pages containing a link to
>>> the wikidata entry!
>>
>> They do.
>
> Not on a number of articles I've recently been looking at while checking
> out the CURRENT wikidata offering. I've not found wikidata id's on the
> wikipedia articles I looked at ... but wikidata does seem something I
> should perhaps reassess.

You not having found them does not mean that they are not there.

teh only Wikipedia articles with no Wikidata ID are those that are
newly created.

Otherwise, you will find the "Wikidata item" link in the left-hand
navigation pane (using the default desktop view)

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [OSM-talk] Fixing wiki* -> brand:wiki*

[Lester Caine]

On 27/09/17 16:48, Andy Mabbett wrote:
> On 27 September 2017 at 16:06, Lester Caine  wrote:
> 
>>> While it is not yet complete, in what way is Wikdiata failing to be
>>> sufficiently reliable?
>>
>> Much of the work I did on wikipedia was stripped for all sorts of
>> reasons.
> 
> My question was about Wikidata's reliability, not yours ;-)

My experience of 'wikipedia' is bad and so that colours my thinking
about using wikidata! I know many of us who used to be contributors are
in the same boat ...

>> critically I'd prefer to see the wikipedia pages containing a link to
>> the wikidata entry!
> 
> They do.

Not on a number of articles I've recently been looking at while checking
out the CURRENT wikidata offering. I've not found wikidata id's on the
wikipedia articles I looked at ... but wikidata does seem something I
should perhaps reassess.

>>> That is exactly what Wikidata is for.
>>
>> But has yet to be formally adopted by OSM ... at which point the
>> wikidata id becomes the OSM unique reference?
> 
> I've not seen anyone advocate that.

Personally I'd prefer to see an OSM id I can use as an alternative to
wikidata ... with a few links to other datasources without relying on
wikidata.

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

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

Re: [OSM-talk] Fixing wiki* -> brand:wiki*

[Yuri Astrakhan]

I think we should re-start with the definition of the problems we are
(hopefully) trying to solve, or else we might end up too far in the
existential realm, which is fun to discuss, but should be left for another
thread.

* Problem #1:  In my analysis of OSM data, wikipedia tags quickly go stale
because they use Wikipedia page titles, and titles are constantly renamed,
deleted, and what's worse - old names are reused for new meanings.  This is
a fundamental problem with all Wikipedia tags, such as wikipedia,
brand:wikipedia, operator:wikipedia, etc, that needs solving. The solution
does not need to be perfect, it just needs to be better than what we have.

* Problem #2: the *meaning* of the "wikipedia" tag is ambiguous, and
therefor cannot be processed easily. The top three meanings I have seen are:
  a) This WP article is about this OSM feature (a so called 1:1 match, e.g.
city, famous building, ...)
  b) This WP article is about some aspect of this OSM feature, like its
brand, tree species, or subject of the sculpture
  c) Only a part of this WP article is about this OSM feature, e.g. a WP
list of museums in the area contains description of this museum.

* Problem #3: data consumers need cleaner, more machine-processable data.
The text label is much more error prone than an ID:  McDonalds vs mcdonalds
vs McDonald's vs ..., so having "brand=mcdonalds" results in many errors.
Note that just because OSM default map skin may handle some of them
correctly, each data consumer has to re-implement that logic, so the more
ambiguous something is, the more likely it will result in errors and data
omissions.

The brand:wikidata discussion is about #1, #2b, and #3.

Are we in agreement that these are problems, or do you think none of them
need solving?
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-us] Missing imagery in JOSM

[Mark Bradley]

What happened to the USGS topographic map imagery that was available in JOSM
until a few days ago?

 

Mark

 

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

Re: [OSM-talk-fr] Importation des hauteurs de bâtiments sur Nice

[Vincent Frison]

Hello,

L'import a été fait: 52310 bâtiments ont été mis à jour avec leur hauteur.

Plus de détails sur cette page Wiki
.

++ Vincent.

Le 18 septembre 2017 à 17:57, Vincent Frison  a
écrit :

> Hello,
>
> Je projette d'importer dans OSM la hauteur des bâtiments de la ville de
> Nice, un peu comme je l'avais fait il y a 2 ans pour Paris:
> http://wiki.openstreetmap.org/wiki/Paris,_France/Buildings_Heights_Import
>
> Ici les données viennent du MNT (modèle numérique de terrain) et MNS
> (modèle numérique de surface) disponible sur le portail Open Data de la
> métropole Nice Côte d'Azur: http://opendata.nicecotedazur.org/data/
> dataset/modele-numerique-de-terrain-de-nice-cote-d-azur
>
> En fait j'ai déjà lancé un sujet sur le forum: http://forum.
> openstreetmap.fr/viewtopic.php?f=5=6373
>
> Mais comme je n'ai pas trop eu de retour je poste ici car il y a
> visiblement bien plus de trafic (dommage c'est sympa un forum).
>
> De ce que j'ai pu voir mes hauteurs calculées sont suffisamment précises
> mais je ne suis pas contre un petit retour avant de faire l'import (2
> fichiers d'exemple sont attachés dans mon dernier message du forum). Sinon
> je compte je faire l'import dès que j'aurai un peu de temps...
>
> Merci, Vincent.
>
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk] Overlapping brands (was "Fixing wiki* -> brand:wiki*")

[Andy Townsend]

On 27/09/2017 15:35, John F. Eldredge wrote:
The spatial information will tell you where each business location is; 
it is not sufficient to tell you whether these are multiple locations 
of the same brand, or two unrelated brands that share the same name 
and category of business.


Can anyone think of an example where two unrelated brands share the same 
name and category of business in the same geographical area?


The nearest I can think of in the UK is "Wilco Motorsave" and "Wilko" 
(some overlap of what they sell, but different spelling, and typically a 
different "shop" tag in OSM).  In Germany both Aldi Nord and Aldi Sud 
operate, but these tend to be tagged in OSM as operator rather than 
brand, and the only wikidata example I can find is 
https://www.openstreetmap.org/way/25716765 (via 
http://overpass-turbo.eu/s/s10 , http://overpass-turbo.eu/s/s0Z didn't 
return anything).


Best Regards,

Andy


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

Re: [OSM-talk] Fixing wiki* -> brand:wiki*

[Martin Koppenhoefer]

2017-09-27 17:45 GMT+02:00 Andy Mabbett :

> On 27 September 2017 at 16:00, Christoph Hormann  wrote:
> > On Wednesday 27 September 2017, Frederik Ramm wrote:
>   means that by
> >> extension I also have to welcome "amenity:wikidata=Q123456" on
> >> something that is, say, an ice cream parlour because Q123456 is the
> >> generic Wikidata category for ice cream parlours, then I think I'd
> >> rather not have any Wikidata links in OSM at all.
> >
> > I am inclined to concur.
>
> So that's at least three of you tilting at the same windmill.
>


3+1
to say _what_ something is, we should not need wikidata, we should use our
tags and improve our system if it is not sufficient to distinguish what we
want to distinguish. I'm fine with linking osm objects to wikidata items,
where the item is an instance of something (is representing a particular
thing that is the same or very close to thing of the thing in OSM).

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

Re: [OSM-talk] Fixing wiki* -> brand:wiki*

[Andy Mabbett]

On 27 September 2017 at 16:06, Lester Caine  wrote:

>> While it is not yet complete, in what way is Wikdiata failing to be
>> sufficiently reliable?
>
> Much of the work I did on wikipedia was stripped for all sorts of
> reasons.

My question was about Wikidata's reliability, not yours ;-)

> critically I'd prefer to see the wikipedia pages containing a link to
> the wikidata entry!

They do.

>> That is exactly what Wikidata is for.
>
> But has yet to be formally adopted by OSM ... at which point the
> wikidata id becomes the OSM unique reference?

I've not seen anyone advocate that.

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [OSM-talk] Fixing wiki* -> brand:wiki*

[Andy Mabbett]

On 27 September 2017 at 16:00, Christoph Hormann  wrote:
> On Wednesday 27 September 2017, Frederik Ramm wrote:
>>
>> In theory, almost everything we map could be expressed by a Wikidata
>> ID. If welcoming a Wikidata link on a city place node means that by
>> extension I also have to welcome "amenity:wikidata=Q123456" on
>> something that is, say, an ice cream parlour because Q123456 is the
>> generic Wikidata category for ice cream parlours, then I think I'd
>> rather not have any Wikidata links in OSM at all.
>
> I am inclined to concur.

So that's at least three of you tilting at the same windmill.

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [Talk-it] Calanchi

[Martin Koppenhoefer]

2017-09-27 10:49 GMT+02:00 demon.box :

> ciao, vorrei mappare bene una zona costituita da calanchi che sul wiki
> vengono definiti così:
>
> https://it.wikipedia.org/wiki/Calanco



già che hai linkato wikipedia per descrivere l'oggetto, siamo sicuri che
quel articolo della wikipedia italiana tratta della stessa identica cosa
che gli articoli in inglese, tedesco e francese? Quest'ultimi trattano
tutti di "badlands", termine credo abbastanza specifico.

Per esempio esiste anche questo articolo in francese:
https://fr.wikipedia.org/wiki/Calanque


Quello che descrive l'articolo "Calanco" in italiano mi sembra di trattare
di un tipo di paesaggio, cosa in OSM non possiamo mappare.
Mappiamo soltanto i singoli elementi del paesaggio, non le tipologie
generalizzate o geologiche.

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

Re: [Talk-us] I 85 Express Lane (Atlanta, Georgia)

[Jack Burke]

> On Sep 24, 2017, at 5:22 PM, Minh Nguyen 
wrote:

>
> I might be inclined to map the lane as a separate way, but only because I
don't know of any routers that currently
> recognize the change:lanes tag. [1] Either way, it makes sense to treat
HOV and toll lanes similarly.
>
> [1] https://wiki.openstreetmap.org/wiki/Key:change
>


As to treating the two types the same, I concur.  The specific type of lane
is immaterial; that they have different access restrictions than normal
lanes is what is important.  As to mapping them separately, I'm...still
strugging with that (mentally, not in terms of making the edits).  We
already map some types of access restrictions without drawing separate
ways; e.g., hgv:lanes=no|yes|yes for sections of highway where big rigs are
not supposed to use the far-left lane.  On the other hand, we do it that
way because there isn't any legal restriction on vehicles moving between
lanes, like there is with the double-solid-stripe separated HOV/toll
lanes.  Using hov:lanes=blah|blah|blah is actually documented, whereas
toll:lanes= is not, yet as far as I know, not a single router supports HOV
tags in any form, which is a problem in Atlanta, because we have some
HOV-only freeway entrance and exit ramps.  I guess that's why some wiki
pages suggest doing access=no and hov=yes for such link roads.


On Sun, Sep 24, 2017 at 8:47 PM, Tod Fitch  wrote:

> I strongly recommend mapping them as one way with the hov:lanes=* and
change:lanes=* showing the restrictions and
> where you can transition between the lanes. That is the best tagging I
know of to accurately reflect the actual configuration.

> The reason I feel strongly about it is that many miles of HOV lanes in my
are were mapped as separate lanes (done
> before I moved to the area). And now CalTrans is repainting those to
allow entry and exit at anyplace (change from
> a variety of old paint styles to broad dashed white striping). If the HOV
lanes had been tagged as a single way with
> change:lanes showing the restrictions on moving to and from the non-HOV
lanes it would have been trivial to change
> the mapping to conform to the current paint. Mapped as separate ways you
have to go back and remove the separate ways
> then the paint changes which is a pain.

I understand your point; I'm just not sure if "difficulty in making changes
to match what the DOT does later" is reason enough to draw it more simply.


> When there is a solid line (I’ve seen white, yellow and a variety of
parallel white/yellow versions of the “don’t change
> lanes here striping), there are generally designated areas for
transitioning between HOV and non-HOV lanes. If you map
> the HOV as a separate way then you need to add any number of virtual
cross over ways.

OR merge the HOV lane into the main road for the length of the transition
area, and start a new separated road where the transition section ends,
which is what I was considering doing if I try to draw them separately,
because as you point out, the crossover ways become a problem.


> I wondered why OsmAnd and Maps.me
> were always telling me to do slight rights or slight lefts in those areas
until I looked at the mapping and saw the
> separate HOV lanes with virtual link ways connecting it to the non-HOV
lanes. In essence putting in separate HOV ways
> where they don’t actually exist doesn’t always help the router.

I agree that it can be confusing when a router gives seemingly spurrious
and unnecessary directions like that; it seems to be the proximity of the
separate way to the main road that is the problem, from what I can tell.
Although OsmAnd seems to use the smoothness (or lack thereof) in road bends
to make its slight left/right direction statements; I know of some roads
where there are no turns, side roads, exits, or anything else to leave the
main road where it still says slight left/right, simply because the angle
of the way as it crosses a node appears to be over some configured number
of degrees.


Let me throw an additional scenario into the discussion.  On the Veterans
Expressway toll road in Tampa, they are adding some new separated express
lanes to the road.  The "barrier" is both a double-solid-stripe *and* some
orange plastic vertical bollards:

https://www.mapillary.com/map/im/i98UEIXDDgAfhhqzMxD1IA

Because there is an actual physical barrier, albeit a "soft" one that cars
can easily drive through, I think this one _has to_ be mapped separately.
But I'm open to discussion on it.


> FWIW, the JOSM plug-in that deals with change:lanes shows things nicely.
And I suspect that routers like OsmAnd
> will be supporting it soon (if not already) as they support turn:lanes
pretty well.

change:lanes is one of the most confusing tagging schemes I've seen yet.
 *sigh*  I guess this means I actually have to start trying to figure it
out.


> Extending this somewhat: I’ve traditionally mapped on and off ramps with
the link leaving/joining the 

Re: [OSM-talk] Adding wikidata tags to the remaining objects with only wikipedia tag

[Martin Koppenhoefer]

2017-09-27 16:56 GMT+02:00 Andy Mabbett :

> On 26 September 2017 at 21:39, Martin Koppenhoefer
>  wrote:
>
> >> This might also mean that
> >> you have to discuss it via Telegram, Facebook, email, IRC, etc.
> >> depending on where that local community is.
> >>
> >> The talk mailing list is not sufficient.
>
> > I think this is problematic. If the local community uses a paid service
> for
> > communication you'd have to pay in order to speak to your fellow mappers?
>
> The mapping community in the West Midlands of England communicates
> most often face-to-face, meeting in a a pub.
>
> Perhaps we could mandate that anyone wanting to make an automated edit
> in the region has to buy the beer?
>


you don't only pay with money, e.g. in Facebook you only pay money if you
are a client of theirs (buying visibility for your advertizing), the
ordinary users (merchandise) pay with data and their privacy.

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

Re: [Talk-at] Adressen übernehmen mit Adresshelper

[Friedrich Volkmann]

On 27.09.2017 11:22, Walter Krammer wrote:
Ich trage jetzt seit einigen Tagen mit der JOSM-Erweiterung adresshelper in 
einigen Kärntner Gemeinden die Hausnummern ein. Dann kontrolliere ich mit 
dem OSM.Inspector von Geofabrik die Einträge.


Bitte nicht! Wenn du für so was einen Validator verwendest, und OSMI ist 
einer der schlimmsten, dann kommt nur Blödsinn heraus. Es gibt unzählige 
Möglichkeiten, Adressen zu mappen - ein ewiges Streitthema! Das betrifft 
nicht nur St./Sankt, sondern auch addr:place/hamlet/street und 
addr:housenumber/conscriptionnumber, weiters die Platzierung 
(Adressnode/Eingang/Gebäude/Grundstück), von Identadressen ganz zu 
schweigen. Wenn in einer Ortschaft schon viele Adressen gemappt sind, dann 
lass sie daher möglichst so wie sie sind, denn derjenige, der sie so gemappt 
hat, wird sich etwas dabei gedacht haben. Im Zweifelsfall schreib ihn an und 
mach dir das weitere Vorgehen mit ihm aus.


Und die OpenGeoDB vergiss genauso wie die Validatoren, denn die OpenGeoDB 
enthält viele Fehler, und die Verknüpfung der OpenGeoDB mit OSM ist ein 
längst aufgegebenes Projekt.



Meine Frage ist: Wie soll ich richtig vorgehen?


Wiki lesen, die schon gemappten Adressen anschauen, dich mit den lokalen 
Mappern verständigen und vor allem selber denken.


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

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

[OSM-talk-fr] Disparition des Grands Lacs canadiens et autres...

[Pilon, Michel (SSC/SPC)]

Bonjour à tous,

Je suis en train de monter un serveur OpenStreetMap localement et j'ai un 
problème récurrent avec la disparition des Lacs qui sont très grands suite aux 
mise-a-jour des données OSM.

Pour télécharger initialement la planète, la commande que j'utilise est la 
suivante

osm2pgsql --create --slim --flat-nodes /data/osm/pgload/flat_nodes.bin \
 -C 27000 --number-processes 8 --hstore --keep-coastlines \
 --style /data/osm/openstreetmap-carto-3.2.0/openstreetmap-carto.style \
--multi-geometry /data/osm/new_planet-latest.osm.pbf

A ce moment là, lorsque je regarde le slippymap, je tous les grands lacs sont 
bien présents. Par exemple au Canada, dans la région de Toronto, nous avons les 
Grands Lacs suivants :

·Ontario

·Michigan

·Supérieur

·Huron

·Érié

J'utilise alors osmosis pour effectuer les mises a jour quotidiennes. Une fois 
complété, tout est beau à l'exception que je n'ai plus les Lacs Michigan, 
Supérier et Huron. Ontario et Érié sont encore présent (pour l'instant) mais je 
sais qu'à terme ils disparaitront aussi. Quand je dis disparaitre, je veux dire 
que je ne vois plus la couleur bleue pour l'eau dans le slippymap.

La disparition de ces Lacs est notée sur TOUS les niveaux de zoom.

Le même problème se produit également pour les Lacs Ladoga et Onega en Russie 
et probablement pour d'autres grands lacs dans le monde.

Je suis à court d'idée et il est impératif pour mon organisation d'avoir un 
serveur OSM local fonctionnel.

Est-ce que quelqu'un aurait une idée?   Je dois avouer que je commence tout 
juste à me familiariser avec OSM.

A part ca, tout fonctionne bien, incluant les mise a jour mais je dois 
ABSOLUMENT résoudre ce problème de grands lacs qui disparaissent apres une mise 
a jour des données OSM.

Merci encore pour votre aide bien appréciée :)

Michel

Québec, Canada.






--
Michel Pilon
Conseiller technique / Technical Advisor
Courriel | Email : michel.pi...@canada.ca
Téléphone | Telephone :  (819) 564-5600 ext. 227
Télécopieur | Fax:  (819) 564-5698
50 Place de la Cité, suite 212, C.P. 162, Sherbrooke (Québec) J1H 4G9
Échange de données, solutions d'E/S E-Science | E-Science Input/Output 
Solutions Data
Superinformatique | Super Computing
Gestion des services et centres de données | Service Management and Data Centres
Services partagés Canada | Shared Services Canada
Gouvernement du Canada | Government of Canada


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

Re: [OSM-talk] Fixing wiki* -> brand:wiki*

[Lester Caine]

On 27/09/17 14:40, Andy Mabbett wrote:
> On 27 September 2017 at 14:28, Lester Caine  wrote:
> 
>> wikidata provides a section which documents a range of LINKS which
>> identify the same object on other databases. It would be nice if there
>> was a stable identity on OSM that would populate an entry in THAT list.
> 
> Indeed so, but OSM does not, nor is it likely to in the foreseeable future.

The current 'risk' is that the wikidata identifier becomes the defacto
'standard' for defining OSM objects, and then we have to create wikidata
entries for new objects. In the past I did write wikipedia articles to
fill gaps in the past, but when entries get tidied up by other editors,
titles can be changed and we get broken links. At least wikidata id's
are static ... hopefully.

>> At some point it might be nice to eliminate all of the unnecessary links
>> like this in OSM if wikidata or somenewopesourcedata become a more
>> reliable source of such data.
> 
> While it is not yet complete, in what way is Wikdiata failing to be
> sufficiently reliable?

Much of the work I did on wikipedia was stripped for all sorts of
reasons. HOPEFULLY facts that exist will not be subject to the same
arbitrary treatment in wikidata, but I don't have much confidence still
to spend time contributing these days. I did not like the way wikidata
was structured originally but it does look like the problems have been
eliminated. We still need a lot more stubs replacing with real data? And
critically I'd prefer to see the wikipedia pages containing a link to
the wikidata entry!

>> Just a single link to a substantial set of additional data.
> 
> That is exactly what Wikidata is for.

But has yet to be formally adopted by OSM ... at which point the
wikidata id becomes the OSM unique reference?

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

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

Re: [OSM-talk] Fixing wiki* -> brand:wiki*

[Christoph Hormann]

On Wednesday 27 September 2017, Frederik Ramm wrote:
>
> In theory, almost everything we map could be expressed by a Wikidata
> ID. If welcoming a Wikidata link on a city place node means that by
> extension I also have to welcome "amenity:wikidata=Q123456" on
> something that is, say, an ice cream parlour because Q123456 is the
> generic Wikidata category for ice cream parlours, then I think I'd
> rather not have any Wikidata links in OSM at all.

I am inclined to concur.

The basis of accepting wikidata IDs in OSM originally was that it is 
difficult to reference a specific feature from our database from the 
outside and that wikidata provides stable IDs for real world objects 
and that it can be of significant use for OSM data users to be able to 
directly reference features in the OSM database describing the same 
real world objects through this ID.  There are a number of 
prerequisites for this however all of which have been put into question 
in recent discussion:

* There would need to be a 1:1 relationship between OSM features and the 
tagged wikidata ID (which apparently is often not the case for example 
for populated places, island countries etc.).
* The wikidata ID would need to be stable (recent statements that the 
wikidata IDs in the OSM database require constant maintenance to not 
become stale indicate otherwise).
* The wikidata ID would need to be verifiable - a local mapper with 
knowledge of the real world object represented by a certain OSM feature 
would need to be able to falsify the wikidata ID based on information 
readily available from wikidata (which does not always seem to be the 
case either).
* The wikidata IDs are at least for the most part manually added and 
verified by mappers with lokal knowledge - just like any other data in 
OSM (which clearly does not seem to be the case any more - i have no 
solid numbers here but certainly the majority of wikidata tags have 
been added without individual verification by mappers with local 
knowledge).

Everyone remember there is a big cultural difference between OSM and 
wikipedia (and i assume wikidata can be included there).  OSM is 
founded on local knowledge and original research while wikipedia 
rejects original research and values secondary sources of information.  
This fundamental difference also translates into differences in data 
models and different approaches to solving problems.  It is a good idea 
not to try pretending these differences do not exist and that you can 
intermix the two worlds without problems.

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

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

Re: [OSM-talk] Adding wikidata tags to the remaining objects with only wikipedia tag

[Andy Mabbett]

On 26 September 2017 at 21:39, Martin Koppenhoefer
 wrote:

>> This might also mean that
>> you have to discuss it via Telegram, Facebook, email, IRC, etc.
>> depending on where that local community is.
>>
>> The talk mailing list is not sufficient.

> I think this is problematic. If the local community uses a paid service for
> communication you'd have to pay in order to speak to your fellow mappers?

The mapping community in the West Midlands of England communicates
most often face-to-face, meeting in a a pub.

Perhaps we could mandate that anyone wanting to make an automated edit
in the region has to buy the beer?

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [OSM-talk] Fixing wiki* -> brand:wiki*

[John F. Eldredge]

The spatial information will tell you where each business location is; it 
is not sufficient to tell you whether these are multiple locations of the 
same brand, or two unrelated brands that share the same name and category 
of business.



On September 27, 2017 6:51:32 AM Richard Fairhurst  
wrote:



Andy Mabbett wrote:

in different parts of the world


IIRC OSM stores spatial information. I might be wrong.

Richard



--
Sent from: http://gis.19327.n8.nabble.com/General-Discussion-f5171242.html

___
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] Fixing wiki* -> brand:wiki*

[Jean-Marc Liotier]

On Wed, 27 Sep 2017 15:59:34 +0200
Frederik Ramm  wrote:
>
> "amenity:wikidata=Q123456" on something that is, say, an ice cream
> parlour because Q123456 is the generic Wikidata category for ice
> cream parlours

I thought wikidata tags were for unique objets, which usage I believe
is welcome... If they are applied to categories then it is something
else entirely.

I would agree that the matching of a generic Openstreetmap tag to a
Wikidata identifier is Wikidata's business... But then maybe a
Wikidata-centric view of the model will consider it is Openstreetmap's
business...

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

Re: [OSM-talk] Fixing wiki* -> brand:wiki*

[Andy Mabbett]

On 27 September 2017 at 14:59, Frederik Ramm  wrote:

> We generally discourage foreign keys

We do? Citation please.

> If welcoming a Wikidata link on a city place node means that by
> extension I also have to welcome "amenity:wikidata=Q123456" on something
> that is, say, an ice cream parlour because Q123456 is the generic
> Wikidata category for ice cream parlours, then I think I'd rather not
> have any Wikidata links in OSM at all.

This is a slippery-slope fallacy. Such equivalence should be entered
one, on the applicable key= or tag= page of the OSM wiki, like this:

   
https://wiki.openstreetmap.org/w/index.php?title=Tag:amenity%3Dice_cream=1510821=1424407

just as it it should be recorded once in Wikidata, on the
corresponding item, using the "OpenStreetMap tag or key" property,
P1282, like this:

   https://www.wikidata.org/wiki/Q1311064#P1282

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [OSM-talk] Fixing wiki* -> brand:wiki*

[Marc Gemis]

I fail to understand how an external database can link to an OSM
location in case we do not allow foreign keys.
I know there is some vague "find something with a name similar to X in
some area Y" kind of strategy, but did somebody ever implemented such
a thing ?
I doubt that "area Y" is always known.

Suppose a tourist agency has some additional information an an hotel.
How can they link that information to the OSM object ? Do they have to
store the coordinates, then do a query for hotel with name X around
that location ? Is that the best method ?

Just curious.

m.

On Wed, Sep 27, 2017 at 3:59 PM, Frederik Ramm  wrote:
> Hi,
>
> On 27.09.2017 15:37, Simon Poole wrote:
>> My take is that it adds a nearly impossible to maintain (consider your
>> own Woolworth's example), non-speaking, foreign key
>
> We generally discourage foreign keys (that are only usable together with
> a different data set and that are not signposted locally).
>
> When Wikidata keys were first added to OSM, I thought this was something
> limited to place names of a certain importance and I didn't object.
>
> Seeing that this now leads to the automatic assumption that Wikidata IDs
> are practically admissible *everywhere* where Wikidata has defined an
> ID, I am having second thoughts about the whole issue.
>
> In theory, almost everything we map could be expressed by a Wikidata ID.
> If welcoming a Wikidata link on a city place node means that by
> extension I also have to welcome "amenity:wikidata=Q123456" on something
> that is, say, an ice cream parlour because Q123456 is the generic
> Wikidata category for ice cream parlours, then I think I'd rather not
> have any Wikidata links in OSM at all.
>
> 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: [OSM-talk] Fixing wiki* -> brand:wiki*

[Stefano]

2017-09-27 15:59 GMT+02:00 Frederik Ramm :

> Hi,
>
> On 27.09.2017 15:37, Simon Poole wrote:
> > My take is that it adds a nearly impossible to maintain (consider your
> > own Woolworth's example), non-speaking, foreign key
>
> We generally discourage foreign keys (that are only usable together with
> a different data set and that are not signposted locally).
>
> When Wikidata keys were first added to OSM, I thought this was something
> limited to place names of a certain importance and I didn't object.
>
> Seeing that this now leads to the automatic assumption that Wikidata IDs
> are practically admissible *everywhere* where Wikidata has defined an
> ID, I am having second thoughts about the whole issue.
>
> In theory, almost everything we map could be expressed by a Wikidata ID.
> If welcoming a Wikidata link on a city place node means that by
> extension I also have to welcome "amenity:wikidata=Q123456" on something
> that is, say, an ice cream parlour because Q123456 is the generic
> Wikidata category for ice cream parlours,


This is wrong also for me. The "translation" between tagging systems should
be kept externally.


> then I think I'd rather not have any Wikidata links in OSM at all.
>


> 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: [OSM-talk] Fixing wiki* -> brand:wiki*

[Andy Mabbett]

On 27 September 2017 at 14:37, Simon Poole  wrote:

> Am 27.09.2017 um 15:00 schrieb Andy Mabbett:

>> Tim Berners Lee coined the "Five Stars of Open Data"
>>
>> http://5stardata.info/en/

> You are assuming
> a) that an arbitrary best practice definition is relevant for OSM

It's not "arbitrary". You can find TBL's credentials here:

   https://en.wikipedia.org/wiki/Tim_Berners-Lee

> b) that we get any real life brownie points for this outside of academia

I don't give a fig about (and most certainly did not refer to) "brownie points".

>> and that's what including Wikidata iDs in cases such as the above does.
>>
>> In fact, since that makes OSM more useful and thus more attractive to
>> re-users, it *does* matter to OSM.

> You still haven't given any specific real world use case in which
> brand:wikidata would actually be helpful and somebody would -really-
> want to consume it.

You didn't ask for one. But since you now do:

* A data consumer wants to render a map with logos of shops and restaurants

* A data consumer wants to link to Wikipedia articles about same, in
the local language

* A data consumer wants to calculate and compare the distances between
(or density of) the outlets of a particular brand, in different
countries, regardless of the script in which the plaintext name of the
brand has been entered.

> Outside of than that it would obviously be good for
> wikidata and for people going to linked data conferences.

That's the second time you've mentioned a supposed benefit to
Wikidata; any such benefit is minimal, and certainly not my - nor, I'm
sure, Yuri's - reason for wanting to fix the issues outlined in the
OP.

The conference comment is pure snark.

> My take is that it adds a nearly impossible to maintain (consider your
> own Woolworth's example), non-speaking, foreign key for additional
> information that is already  that is already quite adequately provided
> by the brand key.

Your take is mistaken, as shown previously.

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [OSM-talk] Fixing wiki* -> brand:wiki*

[Frederik Ramm]

Hi,

On 27.09.2017 15:37, Simon Poole wrote:
> My take is that it adds a nearly impossible to maintain (consider your
> own Woolworth's example), non-speaking, foreign key

We generally discourage foreign keys (that are only usable together with
a different data set and that are not signposted locally).

When Wikidata keys were first added to OSM, I thought this was something
limited to place names of a certain importance and I didn't object.

Seeing that this now leads to the automatic assumption that Wikidata IDs
are practically admissible *everywhere* where Wikidata has defined an
ID, I am having second thoughts about the whole issue.

In theory, almost everything we map could be expressed by a Wikidata ID.
If welcoming a Wikidata link on a city place node means that by
extension I also have to welcome "amenity:wikidata=Q123456" on something
that is, say, an ice cream parlour because Q123456 is the generic
Wikidata category for ice cream parlours, then I think I'd rather not
have any Wikidata links in OSM at all.

Bye
Frederik

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



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

Re: [Talk-it] Calanchi

[Dino Michelini]

  calanchi famosi sono quelli di Civita di
Bagnoreggio
https://it.m.wikipedia.org/wiki/File:Valle_dei_Calanchi.jpg
[7]

Il 27.09.2017 15:27 Cascafico Giovanni ha scritto: 

> Calanque? 
>

> https://commons.wikimedia.org/wiki/File:Rilke_2.jpg [5] 
> 
> Il
27/set/2017 12:26, "Volker Schmidt" ha scritto:
> 
>>> ciao, vorrei
mappare una calanca...
>> 
>> ... cioè qulacosa come: 
>>
https://fr.wikipedia.org/wiki/Calanque [1] 
>> (no c'è una versione
italiana dell'articolo) 
>> e non quello che hai citato tu inizialmente:

>> https://it.wikipedia.org/wiki/Calanco [2] 
>> 
>> Mi sembra che ci
sia una differenza, leggendo questi due articoli. 
>> La calanca sarebbe
una specie di fjord con pareti erosi, invece calanco una collina o un
monte con fiianchi erosi. 
>> O sbaglio? 
>>
___
>> Talk-it mailing
list
>> Talk-it@openstreetmap.org [3]
>>
https://lists.openstreetmap.org/listinfo/talk-it [4]
 



Con Mobile Open 7 GB a 9 euro/4 sett navighi veloce con 7 GB di Internet e hai 
200 minuti ed SMS a 15 cent. Passa a Tiscali Mobile! http://tisca.li/Open7GB0617

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

Re: [OSM-talk] Fixing wiki* -> brand:wiki*

[Andy Mabbett]

On 27 September 2017 at 14:28, Lester Caine  wrote:

> wikidata provides a section which documents a range of LINKS which
> identify the same object on other databases. It would be nice if there
> was a stable identity on OSM that would populate an entry in THAT list.

Indeed so, but OSM does not, nor is it likely to in the foreseeable future.

> At some point it might be nice to eliminate all of the unnecessary links
> like this in OSM if wikidata or somenewopesourcedata become a more
> reliable source of such data.

While it is not yet complete, in what way is Wikdiata failing to be
sufficiently reliable?

> Just a single link to a substantial set of additional data.

That is exactly what Wikidata is for.

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [OSM-talk] Fixing wiki* -> brand:wiki*

[Simon Poole]

Am 27.09.2017 um 15:00 schrieb Andy Mabbett:
> ...
>> Why would that matter to OSM?
> It may not, It certainly matters to OSM's users.
>
> Tim Berners Lee coined the "Five Stars of Open Data"
>
> http://5stardata.info/en/
>
> defining best practice in publishing open data. OSM already meets the
> first four, well. The fifth is:
>
>  *  link your data to other data to provide context
You are assuming
a) that an arbitrary best practice definition is relevant for OSM
b) that we get any real life brownie points for this outside of academia

>
> and that's what including Wikidata iDs in cases such as the above does.
>
> In fact, since that makes OSM more useful and thus more attractive to
> re-users, it *does* matter to OSM.
You still haven't given any specific real world use case in which
brand:wikidata would actually be helpful and somebody would -really-
want to consume it. Outside of than that it would obviously be good for
wikidata and for people going to linked data conferences.

My take is that it adds a nearly impossible to maintain (consider your
own Woolworth's example), non-speaking, foreign key for additional
information that is already  that is already quite adequately provided
by the brand key.
 
Simon









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

[Talk-it] Parlano di noi su Repubblica :-)

[Matteo Zaffonato]

http://www.repubblica.it/cronaca/2017/09/27/news/dai_beni_confiscati_alla_street_art_tutti_pazzi_per_crowd_mapping-176618750/

Ciao
Matteo


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

Re: [OSM-talk] Fixing wiki* -> brand:wiki*

[Lester Caine]

( Thought I hit 'reply list' :) )

On 26/09/17 23:47, Yuri Astrakhan wrote:
> Here is a query that finds all wikidata IDs frequently used in
> "brand:wikidata", and shows OSM objects whose "wikidata" points to the
> same. I would like to replace all such wikidata/wikipedia tags with the
> corresponding brand:wikidata/brand:wikipedia.  Most of them are in
> India, but there are some in Europe and other places.  This query can be
> used directly from JOSM as well.

wikidata provides a section which documents a range of LINKS which
identify the same object on other databases. It would be nice if there
was a stable identity on OSM that would populate an entry in THAT list.
This would then allow cross checking of any link.

At some point it might be nice to eliminate all of the unnecessary links
like this in OSM if wikidata or somenewopesourcedata become a more
reliable source of such data. Just a single link to a substantial set of
additional data.

So ... where does 'brand:' come from? Should this not simply be 'link:'?

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

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

Re: [Talk-it] Calanchi

[Cascafico Giovanni]

Calanque?

https://commons.wikimedia.org/wiki/File:Rilke_2.jpg

Il 27/set/2017 12:26, "Volker Schmidt"  ha scritto:

>
>
> ciao, vorrei mappare una calanca...
>>
>
> ... cioè qulacosa come:
> https://fr.wikipedia.org/wiki/Calanque
> (no c'è una versione italiana dell'articolo)
>
> e non quello che hai citato tu inizialmente:
> https://it.wikipedia.org/wiki/Calanco
>
> 
> Mi sembra che ci sia una differenza, leggendo questi due articoli.
> La calanca sarebbe una specie di fjord con pareti erosi, invece calanco
> una collina o un monte con fiianchi erosi.
>
> O sbaglio?
>
>
>
> ___
> 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] Downloading Version 3 of all bus stops in a country

[Safwat Halaby]

On Wed, 2017-09-27 at 09:18 +0200, Jo wrote:
> 2017-09-27 8:30 GMT+02:00 Safwat Halaby :
> 
> > On Tue, 2017-09-26 at 11:46 +0200, Jo wrote:
> > 
> > > Then load that in PostGIS and create scripts to read GTFS into
> > > PostGIS.
> > > 
> > > Then compare the data in the DB and produce output and ideally a
> > > UI.
> > > 
> > > I started doing something like that here:
> > > 
> > > https://github.com/osmbe/public_transport
> > > 
> > > Let me know if you see ways of working on that or another way to
> > > tackle the
> > > problem together.
> > > 
> > > Jo
> > 
> > I will check the project out. Thanks for the link. Would you mind
> > explaining what it is capable of? The readme is not so descriptive.
> > 
> 
> For the time being not so much yet. Before the summer I made some
> progress
> migrating scripts I had created for an import of Belgian bus stops
> and
> lines, but during the summer I got a bit 'distracted' by mentoring
> the
> PT_Assistant plugin.
> 
> The basic idea is to take operator data, either GTFS or a dump of
> their
> internal DB.
> 
> Then compare all the stops regarding tags and position. For the stops
> the
> other tables routes, trips and segments, can be used to calculate
> route_ref.
> 
> Then create OSM route relations based on their data and compare to
> what is
> present in OSM.
> 
> This is where it becomes trickier to keep track of their versions and
> ours,
> especially if the intent is to both give feedback to the operators
> and have
> a platform showing mappers which stops, routes and route_masters are
> in
> need of attention.
> 
> Polyglot

That's very interesting. My script is far less ambitious (no routes,
only plain stops).

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

Re: [OSM-talk] Fixing wiki* -> brand:wiki*

[Andy Mabbett]

On 27 September 2017 at 12:49, Richard Fairhurst  wrote:

> Andy Mabbett wrote:

>> in different parts of the world
>
> IIRC OSM stores spatial information. I might be wrong.

For some reason I can't determine, you quote me out-of-context; the
context was that we were discussing the assertion that "object type +
brand(s) should essentially always be unique".

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [OSM-talk] Fixing wiki* -> brand:wiki*

[Andy Mabbett]

On 27 September 2017 at 12:57, Simon Poole  wrote:

>> For example, until the UK version went titsup a few years back, there
>> were chains of stores in the UK and in Australia, each called
>> "Woolworths". Though they had common roots, they were not the same.

> Why would that matter to OSM?

It may not, It certainly matters to OSM's users.

Tim Berners Lee coined the "Five Stars of Open Data"

http://5stardata.info/en/

defining best practice in publishing open data. OSM already meets the
first four, well. The fifth is:

 *  link your data to other data to provide context

and that's what including Wikidata iDs in cases such as the above does.

In fact, since that makes OSM more useful and thus more attractive to
re-users, it *does* matter to OSM.

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

Re: [Talk-it] SMAU Milano 2017 - le Community a SMAU-ICT

[Luca Delucchi]

2017-09-27 13:56 GMT+02:00 Alessandro Palmas :
>
> A parte Volker non ho avuto nessun altro feedback. Vorrà dire che domattina
> telefono all'organizzazione per dire che non interessa.
>

Peccato che nessun altro sia disponibile... si perde una grande
opportunità di visibilità

> Alessandro
>


-- 
ciao
Luca

www.lucadelu.org

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

Re: [OSM-talk] Downloading Version 3 of all bus stops in a country

[Safwat Halaby]

I think my last two replies never got through and were sent privately
instead. Here's a rephrasing. (which is possibly better anyways).
__

On Wed, 2017-09-27 at 10:53 +0200, Marc Gemis wrote:
> isn't it possible that the 2017 contains data from e.g. 2014, which
> has not been reviewed in the meantime ?
> Which would then mean that the 2015 edit is more recent.
> 
> Or is there a review date in the "database" ?

There is no internal review date, and what you describe could happen.
This is the only drawback I can think of. The first run would be
imperfect in that regard, but the government publishes new GTFS dumps
on a daily basis, so after the first run this wouldn't be an issue at
all, and the "review date" would be "yesterday" or at worst "during the
last few weeks".

This is still better than any practically possible manual work
considering our mapper density and the amount of stops. No one has been
able to manually review or edit all those stops and it's been 5 years
and the stops are horribly stale.

Note that:

1. extra tags (shelter, wheelchair) will be preserved despite the
drawback
2. the new database is considered pretty good quality, so issues will
likely be negligible or nonexistent.

__

On Wed, 2017-09-27 at 11:07 +0200, Jo wrote:
> If there is a conflict regarding position or tags, they should be
> resolved
> by a human mapper. If I were to apply the newer is better approach,
> we
> would constantly be reverting back to the positions the operators
> think
> their stops are at.
> 
> It's important to respect the mappers work, because without mappers
> OSM
> quickly dies off.
> 
> It might be complex to put such a solution in place, but it should be
> obvious that if data flows in 2 directions, too much simplification
> doesn't
> work.

The script will not "constantly revert".

1. Government publishes database with bad edit X: script adds it
2. user fixes it with fix Y
3. Goverment publishes database which still has bad edit X:

The script ignores 3, because "newer is better" and the user edit is
newer. No constant reverts are involved.

However, in the following scenario, the script would indeed introduce a
bad edit to OSM:

1. Government publishes database with bad edit X: script adds it
2. user fixes it with fix Y
3. Goverment publishes database with a NEW BAD EDIT Z.

So the script rests on the assumption that whenever a government
updates a bus stop, it's because the bus stop has actually changed or
because a newer better measurement was made, so Z is always expected to
be better than X (and usually better than Y because it's newer in time)
and this scenario shouldn't exist. Z is always assumed better.

If a provider is unreliable such that it makes random edits in its new
database that are LESS accurate than its older database, then this
script is not suitable for dealing with such a provider and the
complexity of your project is needed. This does not seem to be the case
in Israel. To quote anonymous_gushdan_mapper from the forums:

> Israel has something like 30,000 bus stops,
> and they change daily all across the country.
> There's no way human mappers could ever verify
> the accuracy of all of them, unless you have
> someone working full-time on
> this. However, the data is considered extremely
> accurate, and inaccuracies are quite rare.
> We do have a system that announces the name
> of the next stop, which uses this data.

> I think people from other countries don't realize that this
> is not a single, private operator data, nor it's a single
> city data - it's government generated data that controls
> the entire public transportation network in the country.
> If a bus stop is not in this dataset, it doesn't exist.
> There will never be anything more accurate for bus stops
> in Israel than this dataset.

> If accuracy is important to us, we *must* implement this
> importing script, otherwise the data on OSM will get
> stale quickly - just like the current data is stale
> and shows a lot of bus stops that have been
> since then moved or canceled.

source: 
https://forum.openstreetmap.org/viewtopic.php?pid=665570#p665570

So, I could probably naively always trust the GTFS and it'll still be
mostly fine. But I still want to give mappers the ability to fix
coordinates and such, without overriding their edits the next run
(unless they've been updated by the government to newer values during
that time). 

Lastly, I'd like to point out that no local mappers are complaining
about this and the feedback is so far positive.

Thanks.

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

Re: [OSM-talk] Redacting 75, 000 street names contributed by user chdr

[Frederik Ramm]

Hi,

On 27.09.2017 06:43, Martijn van Exel wrote:
> In your email from Aug 28 you proposed to wait a while as a first step
> to gather some feedback on your assessment. Did you receive any? When do
> you think you want to proceed with the redaction? Anything we can do to
> help?

I haven't received any feedback other than what came over the lists.
I'll re-do my analysis and try to take into account changes that people
have made after chdr and where they mentioned a particular source.

> I can assist with preparing the MapRoulette challenge to re-tag the
> redacted roads. 

> We can take steps to ensure that people use legit
> sources: run a separate challenge for each region and point to specific
> sources that can be used for that region, for example.

Frankly, in those regions where we've just a couple 100 affected roads,
maybe we don't have to do anything at all - the roads will show up on
generic "name missing" debug views like in OSMI, and will be fixed
sooner or later. If we concentrate on countries losing 500 names or
more, that'd be ~ 15 country-wide challenges which should be manageable?
I could make a list of way IDs per country.

I was hoping to get things over with this month which is going to get a
bit tight but I'm still planning that. Unless there's a reason to wait?

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] Fixing wiki* -> brand:wiki*

[Simon Poole]

Am 27.09.2017 um 13:30 schrieb Andy Mabbett:
>
> For example, until the UK version went titsup a few years back, there
> were chains of stores in the UK and in Australia, each called
> "Woolworths". Though they had common roots, they were not the same.
>
>
Why would that matter to OSM?

Given that they are already disambiguated by geography?

And that if you are looking for a "Woolworths" in Australia you don't
really care if there is/was a chain of the same name in the UK?

PS: in OSM  such brands tend end up in the name tag in any case



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

Re: [Talk-it] SMAU Milano 2017 - le Community a SMAU-ICT

[Alessandro Palmas]

Il 20/09/2017 16:53, Alessandro Palmas ha scritto:

Salve lista,
mi è arrivata la proposta per la partecipazione di OSM allo SMAU 
nell'area community.
Come potete leggere sotto non è obbligatorio presidiare tutti i tre 
giorni e le singole persone potrebbero partecipare anche un solo giorno.
Datemi qualche feedback entro qualche giorno (diciamo per martedì 
prossimo 26 settembre) per capire se ne vale la pena. Per cortesia però, 
solo persone motivate. Indicate quale o quali giorni sareste disponibili 
e se avete qualche conoscenza specifica.


CIT.: "... L'area community è pensata per creare un momento di 
networking tra community, user group e associazioni inerenti all'ambito 
ICT.
Il format è un'area con tavoli e sedie dove ciascuna community avrà la 
propria postazione e potrà così interagire con le altre.
Ciascuna associazione può decidere se presidiare l'area tutti e tre i 
giorni o nei giorni in cui è disponibile ed è a titolo gratuito.
Inoltre, ogni giorno la community cambierà di posto così da favorire il 
networking con più community possibili."


Grazie
   Alessandro Ale_Zena_IT




A parte Volker non ho avuto nessun altro feedback. Vorrà dire che 
domattina telefono all'organizzazione per dire che non interessa.


Alessandro

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

Re: [OSM-talk] Fixing wiki* -> brand:wiki*

[Richard Fairhurst]

Andy Mabbett wrote:
> in different parts of the world

IIRC OSM stores spatial information. I might be wrong.

Richard



--
Sent from: http://gis.19327.n8.nabble.com/General-Discussion-f5171242.html

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

Re: [OSM-talk] Fixing wiki* -> brand:wiki*

[Andy Mabbett]

On 27 September 2017 at 10:07, Simon Poole  wrote:

> While I can understand adding WP and WD tags to objects of note, why on
> earth would we want to add all this redundancy to OSM objects at all?

The question incudes the false premise that this is redundancy: It is
not, it adds disambiguation.

> Particularly given that object type + brand(s) should essentially always be
> unique

You're prepared to guarantee that there are not two different chains,
in the same business, in different parts of the world, with the same
name? I'm not.

For example, until the UK version went titsup a few years back, there
were chains of stores in the UK and in Australia, each called
"Woolworths". Though they had common roots, they were not the same.

> anybody that wants to look up WD keys could do so via a simple external table.

Please can you tell us where to find these tables?

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [OSM-talk] Fixing wiki* -> brand:wiki*

[Andy Mabbett]

On 26 September 2017 at 23:47, Yuri Astrakhan  wrote:

> Here is a query that finds all wikidata IDs frequently used in
> "brand:wikidata", and shows OSM objects whose "wikidata" points to the same.
> I would like to replace all such wikidata/wikipedia tags with the
> corresponding brand:wikidata/brand:wikipedia.

Thank you. I support this proposal.

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [Talk-br] Como ser um nó de banco de dados do OSM?

[Nelson A. de Oliveira]

2017-09-26 15:28 GMT-03:00 Rodrigo M. Mariano :
> Isto é realmente possível? Se sim, alguém poderia me passar, por favor,
>
> as instruções de como podermos ser um nó de BD do OSM?

Vocês querem que tipo de serviço exatamente?
Apenas o banco de dados, um servidor de tiles ou outra coisa?

Esse servidor seria para uso interno de vocês ou seria disponibilizado
para o público também?

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