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: [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*

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

[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

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

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

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

[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: [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] 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

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

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] 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*")

[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] 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] 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] 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] 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] 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*")

[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] 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] 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] 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] 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: [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]

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] 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] 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] 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: [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] 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] 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] 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: [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] 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: [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

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

[Talk-at] Adressen übernehmen mit Adresshelper

[Walter Krammer]

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. Und da bin ich auf 
eine grundlegende Diskrepanz gestossen. Der Adresshelper verwendet die 
Ortschaftsnamen, wie sie im Statistikzentralamt verlautbart sind, in der 
OSM-Datenbank sind aber die openGeoDB:name massgebend. Hier werden die 
Namen mit "Sankt ." bezeichnet, in den Hausadressen aus dem 
adresshelper als "St. .". Dadurch zeigt aber der OSM.Inspector 
Fehler an, weil der Eintrag addr:place in der Hausadresse nicht mit dem 
Namen im name- Tag der Ortschaft übereinstimmt. Am leichtesten wäre es, 
den Namen der Ortschaft an die Schreibweise der Hausadresse anzupassen. 
In einem Fall habe ich das so gemacht  und es hat funktioniert, aber ich 
weiß nicht, ob das erlaubt ist, da es ja die openGeoDB - Tags gibt, aber 
auch einen "name"-tag, der gleich lautet.

Meine Frage ist: Wie soll ich richtig vorgehen?

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

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

[eest9]

Hi,
ob St. oder Sankt angegeben wird unterscheidet sich grundsätzlich danach ob
sich diese Gemeinden irgendwann in St. umbenannt haben. Meine eigene
Gemeinde St. Georgen an der Leys hat sich zB umbenannt. Andere Ortsnamen im
Adresshelper sind durchaus auch noch mit Sankt angegeben.
Diese Diskrepanz war auch schon ein Thema als der Adresshelper programmiert
wurde und wenn ich mich richtig erinnere sind wir zum Schluss gekommen,
dass wir die korrekten Namen (wie beim Statistikzentralamt) übernehmen
wollen.
lg eest9

Am 27. September 2017 um 11:22 schrieb Walter Krammer <
walter.kramm...@utanet.at>:

> 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. Und da bin ich auf eine
> grundlegende Diskrepanz gestossen. Der Adresshelper verwendet die
> Ortschaftsnamen, wie sie im Statistikzentralamt verlautbart sind, in der
> OSM-Datenbank sind aber die openGeoDB:name massgebend. Hier werden die
> Namen mit "Sankt ." bezeichnet, in den Hausadressen aus dem
> adresshelper als "St. .". Dadurch zeigt aber der OSM.Inspector Fehler
> an, weil der Eintrag addr:place in der Hausadresse nicht mit dem Namen im
> name- Tag der Ortschaft übereinstimmt. Am leichtesten wäre es, den Namen
> der Ortschaft an die Schreibweise der Hausadresse anzupassen. In einem Fall
> habe ich das so gemacht  und es hat funktioniert, aber ich weiß nicht, ob
> das erlaubt ist, da es ja die openGeoDB - Tags gibt, aber auch einen
> "name"-tag, der gleich lautet.
> Meine Frage ist: Wie soll ich richtig vorgehen?
>
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
>
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-it] Aiuto su conditional restrictions

[Marcello]

Grazie Damjan, mi mancava soprattutto il PH -1 day, non lo conoscevo.
Grazie anche per il link al tool, veramente comodo.

Il 26/09/2017 20:14, Damjan Gerl ha scritto:
> 26.09.2017 - 19:46 - Marcello:
>> Salve,
>>
>> i comuni certo non facilitano la vita ai mappatori e non amano la
>> semplificazione, ad esempio volevo inserire le restrizioni di accesso
>> secondo la segnaletica della foto [1].
>>
>> Al momento ho inserito:
>> access=private
>> disabled=yes
>> emergency=yes
>> foot=yes
>> goods=delivery
>>
>> Vorrei aggiungere anche access:conditional=yes in base agli orari,
>> giorni della settimana e mesi, ma sono talmente tante le condizioni che
>> mi sto intrecciando sempre più e non ne esco. Qualcuno ha dei
>> suggerimenti?
>>
>> Grazie a tutti
>>
>> [1] https://www.dropbox.com/s/a26h145wdkw7nn6/20170920_102002.jpg?dl=0
>>
>
> Ecco la stringa per gli orari (supponendo che l'ultima riga con la
> croce valga come quella prima - domenica e festivi):
>
> Apr 14-Oct 29: Mo-Th 10:00-24:00, Fr-Sa,PH -1 day 19:00-01:00, Su,PH
> 14:00-01:00, Oct 30-Apr 13: Fr,Sa,PH -1 day 19:30-01:00, Su,PH
> 14:00-01:00
>
>
> Damjan
>
> PS: per la verifica della sintassi degli orari/opening_hours consiglio
> l'uso del tool http://openingh.openstreetmap.de/evaluation_tool/
>
>

-- 
Ciao
Marcello


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

Re: [Talk-it] Aiuto su conditional restrictions

[Elena ``of Valhalla'']

On 2017-09-26 at 22:24:37 +0200, Martin Koppenhoefer wrote:
> le collezioni di cartelli del genere sono veramente assurdi, chi fa questo
> ha sbagliato professione e dovrebbe scrivere libri invece di fare cartelli.
> L'unico modo e fermarsi davanti con la macchina, leggersi tutto il testo,
> chiamare il numero telefonico indicato e farsi spiegare cosa intendono ;-).
> Ogni giorno.

beh, in quel caso mi pare che almeno ci sia sopra un cartello luminoso
che — suppongo — dia l'indicazione di accesso o meno in quel momento, e
il cartello serve solo se qualcuno deve pianificare un accesso futuro

a meno che il cartello luminoso non sia sbagliato, ovviamente...

-- 
Elena ``of Valhalla''

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

[Talk-it] Calanchi

[demon.box]

ciao, vorrei mappare bene una zona costituita da calanchi che sul wiki
vengono definiti così:

https://it.wikipedia.org/wiki/Calanco

non trovo però l'esatto tag perciò secondo voi si avvicina di più a
natural=scree

https://wiki.openstreetmap.org/wiki/IT:Tag:natural%3Dscree

oppure a natural=shingle  ?

https://wiki.openstreetmap.org/wiki/Tag%3Anatural%3Dshingle

grazie

--enrico





--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

Re: [Talk-it] Aiuto su conditional restrictions

[Lorenzo "Beba" Beltrami]

Il giorno 27 settembre 2017 10:27, Elena ``of Valhalla'' <
elena.valha...@gmail.com> ha scritto:

> beh, in quel caso mi pare che almeno ci sia sopra un cartello luminoso
> che — suppongo — dia l'indicazione di accesso o meno in quel momento, e
> il cartello serve solo se qualcuno deve pianificare un accesso futuro
>
> a meno che il cartello luminoso non sia sbagliato, ovviamente...
>

...o spento...
E comunque anche il cartello luminoso non basta. Se indica che il varco non
è attivo allora "liberi tutti", ma se indica che è attivo poi ci sono
comunque le eccezioni contenute nel penultimo cartello in basso (che tra
l'altro riporta lo stesso numero telefonico del cartello più in basso di
tutti, ma più in piccolo).
E se ne vedono un sacco di cartelli così!

Sono pienamente d'accordo con Martin. :)

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

Re: [Talk-it] Calanchi

[Paolo F]

Se riguarda una formazione litologica il tag piu' adatto dovrebbe essere:

https://wiki.openstreetmap.org/wiki/Tag%3Anatural%3Dbare_rock

Ciao, Paolo

On Wed, Sep 27, 2017 at 10:49 AM, demon.box  wrote:

> ciao, vorrei mappare bene una zona costituita da calanchi che sul wiki
> vengono definiti così:
>
> https://it.wikipedia.org/wiki/Calanco
>
> non trovo però l'esatto tag perciò secondo voi si avvicina di più a
> natural=scree
>
> https://wiki.openstreetmap.org/wiki/IT:Tag:natural%3Dscree
>
> oppure a natural=shingle  ?
>
> https://wiki.openstreetmap.org/wiki/Tag%3Anatural%3Dshingle
>
> grazie
>
> --enrico
>
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Calanchi

[Paolo Platania]

Non trovo nulla di specifico, quelli che si avvicinano di piu' sono il tuo

https://wiki.openstreetmap.org/wiki/IT:Tag:natural%3Dscree

oppure

https://wiki.openstreetmap.org/wiki/Tag%3Ageological%3Doutcrop


-Original Message-
From: demon.box [mailto:e.rossin...@alice.it] 
Sent: mercoledì 27 settembre 2017 10:50
To: talk-it@openstreetmap.org
Subject: [Talk-it] Calanchi

ciao, vorrei mappare bene una zona costituita da calanchi che sul wiki vengono 
definiti così:

https://it.wikipedia.org/wiki/Calanco

non trovo però l'esatto tag perciò secondo voi si avvicina di più a 
natural=scree

https://wiki.openstreetmap.org/wiki/IT:Tag:natural%3Dscree

oppure a natural=shingle  ?

https://wiki.openstreetmap.org/wiki/Tag%3Anatural%3Dshingle

grazie

--enrico





--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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


.

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

Re: [Talk-it] Calanchi

[Volker Schmidt]

Prima una domanda: vuoi mappare una calanca o un calanco? Sono cose diverse.
Entrambi sono superficie create da erosione (quello che è rimasto da
erosione)

Non ho una risposta per il tagging. Posso solo dire:
Non va bene né shingle né scree (materiali creati e portati via di erosione.
Non è nemmeno bare rock, perché calanche e calanchi sono materiali
compositi.

Domanda forse da prtare alla lista tagging


On 27 September 2017 at 10:49, demon.box  wrote:

> ciao, vorrei mappare bene una zona costituita da calanchi che sul wiki
> vengono definiti così:
>
> https://it.wikipedia.org/wiki/Calanco
>
> non trovo però l'esatto tag perciò secondo voi si avvicina di più a
> natural=scree
>
> https://wiki.openstreetmap.org/wiki/IT:Tag:natural%3Dscree
>
> oppure a natural=shingle  ?
>
> https://wiki.openstreetmap.org/wiki/Tag%3Anatural%3Dshingle
>
> grazie
>
> --enrico
>
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Calanchi

[Alessandro]

Il 27/09/2017 11:03, Paolo F ha scritto:

Se riguarda una formazione litologica il tag piu' adatto dovrebbe essere:

https://wiki.openstreetmap.org/wiki/Tag%3Anatural%3Dbare_rock



In alcuni punti potrebbe essere applicabile anche natural=cliff

Alessandro Ale_Zena_IT

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

Re: [Talk-it] Calanchi

[demon.box]

voschix wrote
> Prima una domanda: vuoi mappare una calanca o un calanco? 


ciao, vorrei mappare una calanca...

--enrico



--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

Re: [Talk-it] Domanda da nuovo arrivato!

[Gian Luca Gaiba]

Grazie infinite

ora e’ tutto molto chiaro

scusa se ti ho fatto ripetere alcune cose
ma sono veramente nuovo dell’argomento…

ne approfitto per chiedere anche un’altra delucidazione

quando si esplicitano i campi per il csv
trovo 2 tipi di “dichiarazioni

::id precedute dai ::
e
“name” tra apici…

che diffeneza c’e’?
se io ad esempio volessi avere nel csv la tipologia di nodo
(bus_station o halt o train_station)
cosa dovrei usare?

grazie ancora infinite!!!
ciauu

> On 26 Sep 2017, at 10:41, Cascafico Giovanni  wrote:
> 
> Il 26 settembre 2017 09:33, Gian Luca Gaiba
>  ha scritto:
> 
> 
>> 1) se volessi includere (o fare altra query) per le fermate degli autobus 
>> che tags dovrei usare?
> 
> Guarda questa query [1] per le fermate di Udine
> 
>> 2) Se volessi avere i dati direttamente in csv e’ possibile?
> 
> Ti avevo già mandato il link per produrre direttamente un csv. In ogni
> caso questo comando [2], derivato direttamente dalla query [1], ti
> produce i dati; cerca e sostituisci "Udine" con altra città e riprova
> a dare il comando...
> 
>> 3) Se replicassi questi dati in un mio database ogni quanto mi consigliate 
>> di aggiornare/sincronizzare le tabelle?
> 
> Dipende dallo stato della mappa, dall'attività dei mappatori, dalle
> variazione dell'azienda dei trasporti. Per Udine, dubito ci saranno
> attività prossimamente, in quanto un utente ha già mappato tutto in
> dettaglio. Nessuno ti vieta di mettere in crontab il comando [2] a tuo
> piacimento :-)
> 
> 
> 
> [1] http://overpass-turbo.eu/s/rYt
> [2] 
> http://overpass-api.de/api/interpreter?data=%5Bout%3Acsv%28%3A%3Aid%2C%22name%22%2C%3A%3Alat%2C%3A%3Alon%3Btrue%3B%22%2C%22%29%5D%3Barea%5B%22name%22%3D%22Udine%22%5D%2D%3E%2Ea%3B%28node%28area%2Ea%29%5B%22highway%22%3D%22bus%5Fstop%22%5D%3B%29%3Bout%3B%0A
> 
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it


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

Re: [Talk-it] Domanda da nuovo arrivato!

[Cascafico Giovanni]

> quando si esplicitano i campi per il csv
> trovo 2 tipi di “dichiarazioni:
> ::id precedute dai :: e “name” tra apici…
> che diffeneza c’e’?

Considera la query:

[out:csv(::id,"name",::lat,::lon;true;",")];
  area[name="Udine"]->.a;
  ( node(area.a)[highway=bus_stop];
 );
  out;


la prima linea definisce cosa estrarre in csv... con i "::" accedi a
dei tag predefiniti (non assegnati dal mappatore, in questo caso ID
unico del nodo, latitudine e longitudine), mentre tra doppi apici
accedi ai tag assegnati dal mappatore (in questo caso name); nella
parte finale delle prima linea, "true" definisce che si userà un
separatore di campo, poi tra doppi apici quale separatore (in questo
caso virgola, ma poteva essere "\t" tabulazione, oppure "|" ecc).


> se io ad esempio volessi avere nel csv la tipologia di nodo
> (bus_station o halt o train_station)
> cosa dovrei usare?

Sostituisci nella terza linea la coppia k=v (chiave=valore) che ti
interessa. Per fare ciò devi riferirti alla relativa wiki, per esempi
un buon punto di partenza per i treni è la stazione [1], in ogni senso
:-)

Puoi inserire più di un criterio di ricerca tra parentesi quadre: per
esempio se ti interessano i Defibrillatori di Cecina che non sono
stati mappati dal Progetto Cecina Cuore, compilerai questa query [1]

[out:csv(::id,"name",::lat,::lon;true;",")];
  area[name="Cecina"]->.a;
  ( node(area.a)[emergency=defibrillator][source!="Progetto Cecina Cuore"];
 );
  out;

[1] http://wiki.openstreetmap.org/wiki/Tag:railway%3Dstation
[2] http://overpass-turbo.eu/s/s00

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

Re: [Talk-it] Calanchi

[Lorenzo "Beba" Beltrami]

Il giorno 27 settembre 2017 11:13, Volker Schmidt  ha
scritto:

> Prima una domanda: vuoi mappare una calanca o un calanco? Sono cose
> diverse.
> Entrambi sono superficie create da erosione (quello che è rimasto da
> erosione)
>

Molto interessante. Nella mia zona ci sono diversi tipi di "calanchi" e
tutti quanti vengono chiamati "calanchi" indistintamente.
Ci sono questi:
https://commons.wikimedia.org/wiki/Image:Badlands_-_Canossa,_Reggio_Emilia,_Italy_-_December_21,_2014_02.jpg
che in inglese trovo tradotti come "Badlands", che sono delle 'collinette'
che pian piano vengono erose dai ruscelli quando piove.
E poi ci sono questi:
https://commons.wikimedia.org/wiki/File:Calanchi_vezzano.jpg
che in inglese trovo tradotti come "Calanques" che però sono delle vere e
proprie pareti di roccia, seppur friabile, lasciate dall'erosione.

Per il tag ora sta prendendo piede anche geological=*[1], ma non ho capito
se c'è una vera e propria logica per secgliere tra quello e natural=*...

Lorenzo

[1] https://wiki.openstreetmap.org/wiki/Key:geological
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Calanchi

[Volker Schmidt]

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

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

[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: [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] Label language on the Default stylesheet

[Oleksiy Muzalyev]

On 26.09.17 23:00, Martin Koppenhoefer wrote:
for the record: using Latin would be the completely wrong message we 
could send out IMHO. It would make us look like an elitist circle [1] 
and would make many people feel rejected, or at least make them turn 
away as soon as they get to know about it.


Cheers,
Martin


[1] sometimes you already can get this impression about OSM, although 
it is a different bunch of elitists (computer science) than those 
typically studying Latin.


I do not argue with it. It is not an ideal solution.

However, there is a saying "A language is a dialect with an army and 
navy" [1]. So giving a global preference to one language, no matter 
which, also sends a certain message.


The Latin language is unique in this respect. It is well developed in 
the field of science, including geography. And it is not associated with 
any political entity for which exists a living memory. And it will be 
used only for additional labels to the main labels in local non-Latin 
alphabets.


In any case, it is doable, and, perhaps, there could be other ideas, not 
only the obvious ones.


[1] 
https://en.wikipedia.org/wiki/A_language_is_a_dialect_with_an_army_and_navy


Best regards,

Oleksiy



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

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

[Safwat Halaby]

Thanks for the info, mmd!

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

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

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

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

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

[Jo]

Deleting data on OpenStreetMap and replacing it by imported data is
obviously never the acceptable approach.

What I don't understand is why you don't create something that compares the
latest version of all the bus stops in OSM with the latest version of the
GTFS data from upstream.

Why compare with an inbetween version?

What I think is needed is a (web) service that stands between the operator
data, be it GTFS or DB dumps and OpenStreetMap where comparison is made and
which can be used by mappers to either improve OSM, or to send feedback to
the operators that there are issues with the data they provide. Or where
the operators can request flagged stops in bulk.

The same goes for the lines (route_master) and the various itineraries
(route relations).

Polyglot

2017-09-27 7:42 GMT+02:00 Safwat Halaby :

> Hi John Whelan,
>
> As implied in the forum thread, not wanting to destroy user data is
> exactly why I'm building a relatively complex script. The naive
> approach is to destroy all-bus stops are re-import, everytime a GTFS
> update is released. But I don't want that.
>
> Instead of doing that, the script preserves all user-submitted data
> such as shelter, wheelchair, and GPS coordinate fixes and provides
> incremental updates rather than the destruction of all bus stops per
> import. The incremental updates do not destroy user changes. In order
> to achieve that, the older and the newer GTFS database need to be
> compared per update.
>
> Yesterday I didn't have the database which was used in the old 2012
> import, so I couldn't locally test-run my script. which is what lead to
> my original question in this thread. But now I managed to reverse-build
> the old GTFS database from version 3 of the bus stops in Israel by
> downloading the bus stops through the relevant changesets.
>
> Here's some of the discussion:
>
> >Here's a merging idea.
> >
> >Problem: Dealing with conflicts between mapper
> edits and gtfs data.
> >Solution: "The most recent version is the correct
> version" philosophy.
> >
> >- The first gtfs update would update everything.
> Conflicts are
> >  resolved by prioritizing the gtfs file's version. This
> is a
> >  "necessary evil" but is >only needed once.  (edit: I might be
> >
> able to mitigate this by tracing bus stop OSM history).
> >- Some time
> passes, and users update some of the bus stops.
> >- The ministry of
> transportation updates some bus stops in
> >  its database and publishes a
> new gtfs file.
> >- The next gtfs update would inspect the difference
> between
> >  the new gtfs file and the older gtfs file. Only bus stops
> >
> that have had their data (in >the gtfs file) changed since the
> >  last
> file are updated. So, conflicts are resolved by prioritizing
> >  the gtfs
> file version, but only for the bus stops that were changed
> >  by the
> ministry since the last update. The rest of the bus stops
> >  are left
> intact.
>
> (source: https://forum.openstreetmap.org/viewtopic.php?id=16738=3)
>
> Also, we know the data can be used in OSM.
>
> https://forum.openstreetmap.org/viewtopic.php?pid=244096#p244096
>
> ___
> 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*

[PanierAvide]

Hello,

Thank you for this query, which will be very useful for detecting these 
issues. I'm not sure if this is possible in the current state of 
Wikidata, but can't we retrieve all shop chains brands, and then query 
OSM to find object having wikidata tag pointing to one of the brands ? 
If data is structured enough on Wikidata side, we would have a better 
way to retrieve more of the OSM issues.


Regards,

Adrien.


Le 27/09/2017 à 00:47, Yuri Astrakhan a écrit :
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.


http://tinyurl.com/y72afjpy

BTW, this type of queries might be good for maproulette challenges 
once they can work more like osmose.


--
PanierAvide
Géomaticien & développeur


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

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

[Jo]

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

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

[Safwat Halaby]

On Wed, 2017-09-27 at 09:12 +0200, Jo wrote:
> Deleting data on OpenStreetMap and replacing it by imported data is
> obviously never the acceptable approach.
> 
> What I don't understand is why you don't create something that
> compares the
> latest version of all the bus stops in OSM with the latest version of
> the
> GTFS data from upstream.
> 
> Why compare with an inbetween version?

I'm taking a "Newer is better" approach for conflict resolution.

Let's say a user made a 2015 edit for a coordinate (We'll call this
version X). And your 2017 database has a different coordinate (We'll
call this version Y). How do you determine which coordinate to keep?

If you had a 2012 database that would be easy.

Case 1:
2012 database: Y
2015 user edit: X
2017 database: Y

This means the Y has not been updated since 2012. Newer is better, so
trust the user edit and set the coordinates to X.

Case 2:
2012 database: T
2015 user edit: X
2017 database: Y

This means Y is the newest value, and we should override the user edit.

Without two database, we'd have to guess or resort to manual user
intervention via fancy web services.


> What I think is needed is a (web) service that stands between the
> operator
> data, be it GTFS or DB dumps and OpenStreetMap where comparison is
> made and
> which can be used by mappers to either improve OSM, or to send
> feedback to
> the operators that there are issues with the data they provide. Or
> where
> the operators can request flagged stops in bulk.
> 

I am a huge advocate of simplicity. In my humble opinion, web services
and SQL databases are overkill for what I'm trying to do. Your project
spans dozens of files while mine is a single .js file for the JOSM
scripting plugin, which reads two textual stops.txt files from the old
and the newer GTFS databases.

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

Re: [OSM-talk] The real face of MAPS.ME edits and notes - a short analysis

[Safwat Halaby]

Note: I'm replying to an old mail. If you don't have it. You can find
it here:
https://lists.openstreetmap.org/pipermail/talk/2017-June/078181.html
"The real face of MAPS.ME edits and notes - a short analysis"

>The price to reproduce all the on-the-ground mappers'
> contributions
we have is
> likely to be somewhere between 4 million and 150 million
euros: 

Hello,

These monetary considerations could be valid so long as the MAPS.ME bad
edits do not exceed a certain threshold. Past that threshold,
maintainers can no longer keep up with the noise and the value of the
map essentially drops to zero. Take a look at the Middle East, the map
was filled with POIs such as "my house", "my uncle's house". For a map
consumer, it would be a poor choice to use OpenStreetMap in these
regions, because it's junk. They'd prefer Google Maps or Bing Maps. And
so, OpenStreetMap becomes valueless, regardless of much money would
have been invested in surveying, etc.

I've deleted thousands of personal bookmarks in that area but I can no
longer keep up and have no desire to continue doing so. The "my house"
style tags will probably re-accumulate with time, reducing the value of
the map.

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

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

[Jo]

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.

Jo

2017-09-27 10:46 GMT+02:00 Safwat Halaby :

> On Wed, 2017-09-27 at 09:12 +0200, Jo wrote:
> > Deleting data on OpenStreetMap and replacing it by imported data is
> > obviously never the acceptable approach.
> >
> > What I don't understand is why you don't create something that
> > compares the
> > latest version of all the bus stops in OSM with the latest version of
> > the
> > GTFS data from upstream.
> >
> > Why compare with an inbetween version?
>
> I'm taking a "Newer is better" approach for conflict resolution.
>
> Let's say a user made a 2015 edit for a coordinate (We'll call this
> version X). And your 2017 database has a different coordinate (We'll
> call this version Y). How do you determine which coordinate to keep?
>
> If you had a 2012 database that would be easy.
>
> Case 1:
> 2012 database: Y
> 2015 user edit: X
> 2017 database: Y
>
> This means the Y has not been updated since 2012. Newer is better, so
> trust the user edit and set the coordinates to X.
>
> Case 2:
> 2012 database: T
> 2015 user edit: X
> 2017 database: Y
>
> This means Y is the newest value, and we should override the user edit.
>
> Without two database, we'd have to guess or resort to manual user
> intervention via fancy web services.
>
>
> > What I think is needed is a (web) service that stands between the
> > operator
> > data, be it GTFS or DB dumps and OpenStreetMap where comparison is
> > made and
> > which can be used by mappers to either improve OSM, or to send
> > feedback to
> > the operators that there are issues with the data they provide. Or
> > where
> > the operators can request flagged stops in bulk.
> >
>
> I am a huge advocate of simplicity. In my humble opinion, web services
> and SQL databases are overkill for what I'm trying to do. Your project
> spans dozens of files while mine is a single .js file for the JOSM
> scripting plugin, which reads two textual stops.txt files from the old
> and the newer GTFS databases.
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Simon Poole]

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?
Particularly given that object type + brand(s) should essentially always
be unique, anybody that wants to look up WD keys could do so via a
simple external table.

Simon

Note I'm talking about the usefulness for OSM here, that it would be
useful for WD is clear.


Am 27.09.2017 um 00:47 schrieb Yuri Astrakhan:
> 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.
>
> http://tinyurl.com/y72afjpy
>
> BTW, this type of queries might be good for maproulette challenges
> once they can work more like osmose.
>
>
>
> ___
> 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] Label language on the Default stylesheet

[Max]

+1
Until there is a (vector) map that allows you to change the preferred 
language dynamically or match against a priority list of languages from 
the user, the current principle of local language = display language is 
simply the best option.




On 2017년 09월 26일 23:00, Martin Koppenhoefer wrote:
for the record: using Latin would be the completely wrong message we 
could send out IMHO. It would make us look like an elitist circle [1] 
and would make many people feel rejected, or at least make them turn 
away as soon as they get to know about it.


Cheers,
Martin


[1] sometimes you already can get this impression about OSM, although it 
is a different bunch of elitists (computer science) than those typically 
studying Latin.



___
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 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: [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*

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

[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: [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] 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] 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: [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] 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*

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

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*

[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: [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*

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

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

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

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

[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] 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*

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

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

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: [Talk-br] Como ser um nó de banco de dados do OSM?

[Sérgio V .]

Bom  dia Rodrigo,

parece muito interessante a proposta.


Não entendo muito da parte de informática,

mas talvez você possa encontrar mais informações sobre o que deseja nestes 
links sobre a base de dados do OSM:

https://wiki.openstreetmap.org/wiki/Category:OSM_API

https://wiki.openstreetmap.org/wiki/Databases_and_data_access_APIs

https://wiki.openstreetmap.org/wiki/Planet.osm

https://wiki.openstreetmap.org/wiki/Frameworks

Imagino que deve ter mais dados que outros possam lhe informar.
E que para ser um servidor oficial necessitaria algum contato com a 
"OpenStreetMap Foundation"

http://wiki.osmfoundation.org/wiki/Main_Page

https://wiki.openstreetmap.org/wiki/Open_Database_License


Seria importante você criar uma página na wiki em português para documentar sua 
proposta, para ficar registrado e a comunidade poder acompanhar:

https://wiki.openstreetmap.org/wiki/Main_Page


De minha parte, acho ótima proposta.


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs



De: Rodrigo M. Mariano 
Enviado: terça-feira, 26 de setembro de 2017 15:28
Para: talk-br@openstreetmap.org
Assunto: [Talk-br] Como ser um nó de banco de dados do OSM?


Olá a todos, boa tarde,



Eu tinha lido em algum lugar, sobre instituições poderem criar um nó de

banco de dados do OSM, mas não estou encontrando mais sobre isso.



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?



Nós aqui do INPE estamos pensando em criar um servidor que seja nó do OSM, que

terão os dados de um projeto nosso, por isso gostaria de avaliar a 
possibilidade.



Atenciosamente,

--


Rodrigo M. Mariano

Departamento de Tecnologia da Informação do Laboratório Associado de Computação 
e Matemática Aplicada - LAC
Instituto Nacional de Pesquisas Espaciais - INPE
Av. dos Astronautas, 1.758 - Jardim da Granja
CEP: 12227-010 - São José dos Campos/SP.
Tel.: (12) 3208-6544
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

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

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