Re: [OSM-talk] Adding Wikidata tags to 70k items automatically

[Eugene Alvin Villar]

On Mon, Sep 1, 2014 at 5:22 AM, Lester Caine  wrote:

> But where do you stop. Wikipedia and wikidata are not the only sources
> so if they get 'special treatment' then why not some of the other
> similar archives? Now if every other archive simply included an OSM tag
> ... problem solved. But why should we get special treatment the other
> way around? We just need a reliable way of identifying POI's that we can
> all agree on and then lookup all data with filtering relevant to the
> intended use.
>

1. We already link to Wikipedia using the wikipedia=* tag. I really can't
see how wikidata=* is any different. Linking to Wikidata actually provides
more value than merely linking to Wikipedia as it provides additional data,
*including* links to all language Wikipedias where the object has an
article.

2. Wikidata is certainly special. There is no other freely-licensed and
general-purpose database project out there that is maintained by an open
community. Freebase comes close but it is owned and operated by Google.

3. You fear that linking to Wikidata opens up the floodgates for linking
from OSM to other databases (such as national registries and the like). But
actually, it makes much more sense to link from Wikidata, being a database
about data, to those other databases instead of from OSM. In fact, Wikidata
already has many of properties (like keys in OSM) that provide links to
other databases[1][2]. We can leverage that in OSM by linking to Wikidata.

[1]
https://www.wikidata.org/wiki/Wikidata:List_of_properties/Generic#Authority_control
[2]
https://www.wikidata.org/wiki/Wikidata:List_of_properties/Geographical_feature#Administrative_territorial_entity_identifier
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Adding Wikidata tags to 70k items automatically

[Lester Caine]

On 31/08/14 20:59, Clifford Snow wrote:
> I say let's figure out how to do this import in a quality manner and
> make it easy for mappers to add the link from iD and JSOM. 

But where do you stop. Wikipedia and wikidata are not the only sources
so if they get 'special treatment' then why not some of the other
similar archives? Now if every other archive simply included an OSM tag
... problem solved. But why should we get special treatment the other
way around? We just need a reliable way of identifying POI's that we can
all agree on and then lookup all data with filtering relevant to the
intended use.

-- 
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 70k items automatically

[Edward Betts]

Archer  wrote:
> I've found some more examples for villages in the Czech Republic (I've
> looked only randomly) if you need some more please let me know. In your
> mismatch list there seem to be many german municipalities:
> http://edwardbetts.com/osm-wikidata/mismatches.html

The mismatch list includes lots of German villages beacause somebody has
already added wikidata tags to them.

Matching of villages might improve significantly when the latest version of
the matcher finishes running tomorrow.

-- 
Edward.

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

Re: [OSM-talk] Adding Wikidata tags to 70k items automatically

[Archer]

sorry, the right match for Q1639627 would be
http://www.openstreetmap.org/relation/433042

I've found some more examples for villages in the Czech Republic (I've
looked only randomly) if you need some more please let me know. In your
mismatch list there seem to be many german municipalities:
http://edwardbetts.com/osm-wikidata/mismatches.html

In my opinion this import is to early. Wikidata needs much consolidation
atm (many instance of missing, etc). We shouldn't rely on Wikipedia
categories for the import of Wikidata IDs. Those categories seem to be
problematic as they mix up for example villages and municipalities. There
may also be problems when the Wikipedia article describes two or more
objects (for example one article for the islands Langlütjen as I mentioned
before).


2014-08-31 21:33 GMT+02:00 Archer :

> For the category "Villages" there seems to be also a matching problem. For
> example https://www.wikidata.org/wiki/Q1639627 is a municipality
> according to Wikidata but the match is place=village:
> http://www.openstreetmap.org/node/897680195 and not the administrative
> relation for the municipality:
> http://www.openstreetmap.org/relation/437755
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Adding Wikidata tags to 70k items automatically

[Clifford Snow]

There seems to be two threads to this conversation. 1) Will the
import/mechanical edit be of high quality and 2) do we want a link to
Wikidata.

Skipping the technical aspects of connecting OSM with Wikidata I like to
focus on do we want to link to Wikidata. From the number of wikidata links
in taginfo, it would certainly seem that people want the datasets linked.
Taginfo has 630 people contributing wikidata tags. That is a significant
number. Most of the tag looks to be in Germany although they seem to be
widespread.

Since taginfo does not explain why people are adding the tag I'm going to
just express my views. Being able to click on a map to get more information
is a very desirable feature. Some day, OSM will undoubtedly have that
feature. OSM is a great place to tag features like location, addresses,
acceptability and possibly contact information. Being able to pull
information from another database would really be a great enhancement. Just
click on a feature and have a pop up with more information. The wikidata
link eliminates the need to collect duplicate data. And gives OSM a feature
that would help draw more people into contributing.

I say let's figure out how to do this import in a quality manner and make
it easy for mappers to add the link from iD and JSOM.

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

Re: [OSM-talk] Adding Wikidata tags to 70k items automatically

[Archer]

> I'm not looking at P37 (instance of) because many of the wikidata items
> don't
> include it. I depend on the the article categories from English Wikipedia.


Ok, I'm not familiar with article categories in the english Wikipedia. This
may cause problems as Wikidata contains more objects than Wikipedia and
Wikipedia often describes two or more objects in one article.

For example the Wikipedia article about the islands Langlütjen describes
two different islands: https://en.wikipedia.org/wiki/Langl%C3%BCtjen In
Wikidata each island has its own object:
https://www.wikidata.org/wiki/Q17130505 and
https://www.wikidata.org/wiki/Q17130568

The algorithm matched https://www.wikidata.org/wiki/Q458905 and
http://www.openstreetmap.org/way/286346464

Adding "instance of" to Wikidata would be a perfect challenge for
https://tools.wmflabs.org/wikidata-game/#
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Adding Wikidata tags to 70k items automatically

[Edward Betts]

Archer  wrote:
> 2014-08-31 20:19 GMT+02:00 Edward Betts :
> 
> > Archer  wrote:
> > > Please don’t understand me wrong. I’m a big fan of Wikidata but I'm
> > against
> > > an automated import. The mismatches list gives good examples that your
> > > matching algorithm doesn't work very well:
> > > http://edwardbetts.com/osm-wikidata/mismatches.html
> > >
> > > Some examples:
> > >
> > > 1. Isar Nuclear Power Plant : your
> > > algorithm matches only one reactor of the power plant: Isar 2
> > >  but the right matching
> > > would be Kernkraftwerke
> > > Isar 
> >
> > Q569510 is matching Isar 2 (Way 32918120) because Isar 2 is in the list of
> > German aliases in the Wikidata object:
> >
> > [ "KKW Isar", "AKW Isar", "Isar 2", "Kernkraftwerk Isar I", "Isar 1",
> >   "Atomkraftwerk Isar" ]
> >
> > The German label on the Wikidata item is "Kernkraftwerke Isar", notice the
> > extra 'e' on the end of the first word.
> >
> > I could add Levenshtein distance calculations to my matching, we could say
> > if
> > there is a single character difference the names match. With this change
> > both
> > OSM objects would match and my code would skip the wikidata item.
> >
> > The problem with this change is that hill and hall would match.
> >
> > Ok, but the Wikidata object describes the whole power plant and not only
> one reactor.
> 
> I'd propose to take "is a" (WD-Property: P37) into account. For example in
> Wikidata Q569510 is classified as a nuclear power plant (Q134447) the match
> algorithm should find the matching OSM tags. For example for power plants
> the right tag would be power=plant. Otherwise there should be no match.

Thanks, that's the solution, my matching criteria included the
power=generator tag, I'll remove it, the only matches for a power station
are power=station and power=plant.

I'm not looking at P37 (instance of) because many of the wikidata items don't
include it. I depend on the the article categories from English Wikipedia.

> > > 2. Heligoland : you’ve matched the
> > island
> > > Heligoland  but the right
> > > match would be the municipality Heligoland
> > >  (for the island there
> > > exists a different object in Wikidata)
> >
> > I can't find the Wikidata item that represents the island.
> >
> 
> 
> island: https://www.wikidata.org/wiki/Q3129772
> municipality: https://www.wikidata.org/wiki/Q3038
> archipelago: https://www.wikidata.org/wiki/Q17515918

Thanks.

> 
> 
> > > I also don’t understand why you prefer nodes instead of ways or
> > relations.
> > > Ways and relations provide more information (e.g. extent of an area) than
> > > nodes. The Matching algorithm should first look for relations, when
> > there’s
> > > no relation it should search for ways. Nodes should come last.
> >
> > The matching algorithm is only considering objects within 400m, so the
> > nodes
> > happen to be close, but the centre of the relation is more than 400m from
> > the
> > location in Wikidata.
> >
> > I've modified my matching algorithm to use much large distances for some
> > types
> > of object, it is running now. My hope is that when it is finished the code
> > will detect the presence of the node and relation and skip the Wikidata
> > item.
> > Most of these node vs relation mismatches should disappear.
> >
> 
> The radius for natural and administrative features should be much bigger.
> For example if you want to find the island Hispaniola you'll need a radius
> of  93 km. There are also big glaciers, lakes, etc.
> 
> 
> >
> > > What does your matching algorithm when a Wikidata object describes
> > > different objects and therefore should be split?
> > >
> > > A good example for this is the Wikidata object for Thasos
> > >  (currently it describes the
> > island
> > > and the municipality “Thasos”) but the object has to be split into two
> > > Wikidata objects so that you can say “the island Thasos lies in the
> > > administrative division Thasos”. There are also other examples like mixed
> > > up nature reserves, lakes and administrative divisions in Wikidata which
> > > you have to solve before you can import the IDs into OSM.
> >
> > My code doesn't do anything special with a wikidata item that represents
> > multiple things like islands and municipalities. If Wikidata/Wikipedia
> > claim a
> > thing is an island, and in OSM there is a thing tagged with place=island
> > and
> > the same name they will match.
> >
> > OSM objects can be tagged as both an island and a municipality.
> 
> I'd propose to drop Wikidata objects which have the following property
> combinations:
> "is a" island and at the same time administrative division
> "is a" nature reserve and administrative division
> "is a" lake and administrative di

Re: [OSM-talk] Adding Wikidata tags to 70k items automatically

[Archer]

For the category "Villages" there seems to be also a matching problem. For
example https://www.wikidata.org/wiki/Q1639627 is a municipality according
to Wikidata but the match is place=village:
http://www.openstreetmap.org/node/897680195 and not the administrative
relation for the municipality: http://www.openstreetmap.org/relation/437755
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Adding Wikidata tags to 70k items automatically

[Archer]

2014-08-31 20:19 GMT+02:00 Edward Betts :

> Archer  wrote:
> > Please don’t understand me wrong. I’m a big fan of Wikidata but I'm
> against
> > an automated import. The mismatches list gives good examples that your
> > matching algorithm doesn't work very well:
> > http://edwardbetts.com/osm-wikidata/mismatches.html
> >
> > Some examples:
> >
> > 1. Isar Nuclear Power Plant : your
> > algorithm matches only one reactor of the power plant: Isar 2
> >  but the right matching
> > would be Kernkraftwerke
> > Isar 
>
> Q569510 is matching Isar 2 (Way 32918120) because Isar 2 is in the list of
> German aliases in the Wikidata object:
>
> [ "KKW Isar", "AKW Isar", "Isar 2", "Kernkraftwerk Isar I", "Isar 1",
>   "Atomkraftwerk Isar" ]
>
> The German label on the Wikidata item is "Kernkraftwerke Isar", notice the
> extra 'e' on the end of the first word.
>
> I could add Levenshtein distance calculations to my matching, we could say
> if
> there is a single character difference the names match. With this change
> both
> OSM objects would match and my code would skip the wikidata item.
>
> The problem with this change is that hill and hall would match.
>
> Ok, but the Wikidata object describes the whole power plant and not only
one reactor.

I'd propose to take "is a" (WD-Property: P37) into account. For example in
Wikidata Q569510 is classified as a nuclear power plant (Q134447) the match
algorithm should find the matching OSM tags. For example for power plants
the right tag would be power=plant. Otherwise there should be no match.


> > 2. Heligoland : you’ve matched the
> island
> > Heligoland  but the right
> > match would be the municipality Heligoland
> >  (for the island there
> > exists a different object in Wikidata)
>
> I can't find the Wikidata item that represents the island.
>


island: https://www.wikidata.org/wiki/Q3129772
municipality: https://www.wikidata.org/wiki/Q3038
archipelago: https://www.wikidata.org/wiki/Q17515918


> > I also don’t understand why you prefer nodes instead of ways or
> relations.
> > Ways and relations provide more information (e.g. extent of an area) than
> > nodes. The Matching algorithm should first look for relations, when
> there’s
> > no relation it should search for ways. Nodes should come last.
>
> The matching algorithm is only considering objects within 400m, so the
> nodes
> happen to be close, but the centre of the relation is more than 400m from
> the
> location in Wikidata.
>
> I've modified my matching algorithm to use much large distances for some
> types
> of object, it is running now. My hope is that when it is finished the code
> will detect the presence of the node and relation and skip the Wikidata
> item.
> Most of these node vs relation mismatches should disappear.
>

The radius for natural and administrative features should be much bigger.
For example if you want to find the island Hispaniola you'll need a radius
of  93 km. There are also big glaciers, lakes, etc.


>
> > What does your matching algorithm when a Wikidata object describes
> > different objects and therefore should be split?
> >
> > A good example for this is the Wikidata object for Thasos
> >  (currently it describes the
> island
> > and the municipality “Thasos”) but the object has to be split into two
> > Wikidata objects so that you can say “the island Thasos lies in the
> > administrative division Thasos”. There are also other examples like mixed
> > up nature reserves, lakes and administrative divisions in Wikidata which
> > you have to solve before you can import the IDs into OSM.
>
> My code doesn't do anything special with a wikidata item that represents
> multiple things like islands and municipalities. If Wikidata/Wikipedia
> claim a
> thing is an island, and in OSM there is a thing tagged with place=island
> and
> the same name they will match.
>
> OSM objects can be tagged as both an island and a municipality.

I'd propose to drop Wikidata objects which have the following property
combinations:
"is a" island and at the same time administrative division
"is a" nature reserve and administrative division
"is a" lake and administrative division
"is a" forest and administrative division
These are the combinations where I've encountered problems in Wikidata yet.

Another problem here: municipality Langeneß:
https://www.wikidata.org/wiki/Q29931 the algorithm matches the island which
is also called "Langeneß". But the island has its own WD-object:
https://www.wikidata.org/wiki/Q13747872 OSM Tags und Wikidata Propertys
(P39) should be compared and only if the attributes match there should be a
match.

Or Mawson Peak: http://www.openstreetmap.org/node/2774722248 the match of
the algorithm was Big Ben (vo

Re: [OSM-talk] Adding Wikidata tags to 70k items automatically

[Edward Betts]

Archer  wrote:
> Please don’t understand me wrong. I’m a big fan of Wikidata but I'm against
> an automated import. The mismatches list gives good examples that your
> matching algorithm doesn't work very well:
> http://edwardbetts.com/osm-wikidata/mismatches.html
> 
> Some examples:
> 
> 1. Isar Nuclear Power Plant : your
> algorithm matches only one reactor of the power plant: Isar 2
>  but the right matching
> would be Kernkraftwerke
> Isar 

Q569510 is matching Isar 2 (Way 32918120) because Isar 2 is in the list of
German aliases in the Wikidata object:

[ "KKW Isar", "AKW Isar", "Isar 2", "Kernkraftwerk Isar I", "Isar 1",
  "Atomkraftwerk Isar" ]

The German label on the Wikidata item is "Kernkraftwerke Isar", notice the
extra 'e' on the end of the first word.

I could add Levenshtein distance calculations to my matching, we could say if
there is a single character difference the names match. With this change both
OSM objects would match and my code would skip the wikidata item.

The problem with this change is that hill and hall would match.

> 2. Heligoland : you’ve matched the island
> Heligoland  but the right
> match would be the municipality Heligoland
>  (for the island there
> exists a different object in Wikidata)

I can't find the Wikidata item that represents the island.

> 3. Puerto Rico : the Wikidata objects says
> „is a unincorporated area of the United states“ – the right match therefore
> would be the administrative relation: Puerto Rico
>  but your algorithm matches
> the island: Island of Puerto Rico
> 

The English Wikipedia article Puerto Rico is in the 'Islands of Puerto Rico'
category, so my code considers Q1183 to represent an island. Node 357271412 is
tagged as place=island, so it is perfect match.

We could argue that the node doesn't have much purpose in OSM, the tags could
be merged into Relation 306157.

> I also don’t understand why you prefer nodes instead of ways or relations.
> Ways and relations provide more information (e.g. extent of an area) than
> nodes. The Matching algorithm should first look for relations, when there’s
> no relation it should search for ways. Nodes should come last.

The matching algorithm is only considering objects within 400m, so the nodes
happen to be close, but the centre of the relation is more than 400m from the
location in Wikidata.

I've modified my matching algorithm to use much large distances for some types
of object, it is running now. My hope is that when it is finished the code
will detect the presence of the node and relation and skip the Wikidata item.
Most of these node vs relation mismatches should disappear.

> What does your matching algorithm when a Wikidata object describes
> different objects and therefore should be split?
> 
> A good example for this is the Wikidata object for Thasos
>  (currently it describes the island
> and the municipality “Thasos”) but the object has to be split into two
> Wikidata objects so that you can say “the island Thasos lies in the
> administrative division Thasos”. There are also other examples like mixed
> up nature reserves, lakes and administrative divisions in Wikidata which
> you have to solve before you can import the IDs into OSM.

My code doesn't do anything special with a wikidata item that represents
multiple things like islands and municipalities. If Wikidata/Wikipedia claim a
thing is an island, and in OSM there is a thing tagged with place=island and
the same name they will match.

OSM objects can be tagged as both an island and a municipality.

-- 
Edward.

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

Re: [OSM-talk] Own wikipage for every single speed limit??

[colliar]

Am 28.08.2014 15:07, schrieb Andreas Goss:>> The problem behind this is
that there is no way to mark the reason why
>> there is
>> a redirect.
>
> Well, there is a little trick ;)
>
>
http://wiki.openstreetmap.org/w/index.php?title=Tag:amenity%3Dalm&action=edit
>
>
> http://taginfo.openstreetmap.org/tags/amenity=alm#wiki

This does not work for example for all uuid:* pages which are redirects
to the proposal page and have 0 uses.

See https://wiki.openstreetmap.org/wiki/Proposed_Features/UUID#UUID_Tagging

Could some wiki admin please delete these pages and fix the links. Thanks

Cheers colliar



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

Re: [OSM-talk] Adding Wikidata tags to 70k items automatically

[Archer]

Please don’t understand me wrong. I’m a big fan of Wikidata but I'm against
an automated import. The mismatches list gives good examples that your
matching algorithm doesn't work very well:
http://edwardbetts.com/osm-wikidata/mismatches.html

Some examples:

1. Isar Nuclear Power Plant : your
algorithm matches only one reactor of the power plant: Isar 2
 but the right matching
would be Kernkraftwerke
Isar 

2. Heligoland : you’ve matched the island
Heligoland  but the right
match would be the municipality Heligoland
 (for the island there
exists a different object in Wikidata)

3. Puerto Rico : the Wikidata objects says
„is a unincorporated area of the United states“ – the right match therefore
would be the administrative relation: Puerto Rico
 but your algorithm matches
the island: Island of Puerto Rico




I also don’t understand why you prefer nodes instead of ways or relations.
Ways and relations provide more information (e.g. extent of an area) than
nodes. The Matching algorithm should first look for relations, when there’s
no relation it should search for ways. Nodes should come last.



What does your matching algorithm when a Wikidata object describes
different objects and therefore should be split?

A good example for this is the Wikidata object for Thasos
 (currently it describes the island
and the municipality “Thasos”) but the object has to be split into two
Wikidata objects so that you can say “the island Thasos lies in the
administrative division Thasos”. There are also other examples like mixed
up nature reserves, lakes and administrative divisions in Wikidata which
you have to solve before you can import the IDs into OSM.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Adding Wikidata tags to 70k items automatically

[Peter Wendorff]

Hi Janko,
something like that was proposed on the wikidata side already if I
remember right.
The idea was to store some kind of query on wikidata, e.g. the
Overpass-Permanent-ID [1], which would be used exactly as you say:
it can fetch the arbitrary object(s) that match and should match;
independent of changing OSM object ids, splits or other stuff like that.

I don't find the right page where that happend, probably my memory is
corrupted ;)

regards
Peter

[1] http://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID

Am 31.08.2014 um 16:46 schrieb Janko Mihelić:
> Hi Frederik, great post.
> 
> I always thought wikidata tags would be a first step to a new database that
> OSM needs, and which would be something like Wikidata is to Wikipedia. A
> database that classifies and categorizes elements in OSM. In my opinion a
> slightly modified version of Wikibase could be enough. It would have
> combinations of tags and areas where that category applies.
> 
> If we had a database item in our potential OSM-wikibase that said "all
> primary highways with ref 55 in the UK" and then offload the proprietary
> identifiers there, I think no one would mind.
> 
> Another problem this potential database solves is the often quoted
> "relations aren't categories". We could make an item "HSBC ATM machines"
> and add a few tags that define an element as a HSBC ATM machine
> (amenity=atm + operator=HSBC, or amenity=atm + ref:HSBC=34 or whatever)
> 
> Even wikidata tags that we are discussing could be deprecated if we had
> such a database. We would have our own identifiers (O3489 instead of
> Q23489) and those identifiers would link to wikidata as well as to other
> databases.
> 
> If we don't make our own database that categorizes our tags and elements,
> someone else will do it. In this case, it's Wikidata, which is better then
> the rest because it is crowdsourced, it has an open license for it's data,
> and it has opensource software for it's database and user interface. So if
> I'm not mistaken, we could fork their project if that was needed. But if I
> could choose, we would have our own.
> 
> Janko Mihelić
> 
> 2014-08-30 23:40 GMT+02:00 Frederik Ramm :
> 
>> Hi,
>>
>> On 08/29/2014 08:10 PM, Rob Nickerson wrote:
>>> Lets just step back and reflect on this for a minute.
>>
>> My overarching concern is that if this import is done, future imports
>> will use the "but we also have Wikidata links" argument for justification.
>>
>> What we have here is a third-party database whose object identifiers we
>> add to OSM as tags in order to make linking things easier.
>>
>> This is something that has often been requested by people but never been
>> granted on a large scale because we always said that it would be an
>> abuse of our database and our mapper's patience to offload everyone's
>> and their dog's linking requirements onto us.
>>
>> Imagine every single stretch of road being tagged with three different
>> proprietary (or at least competing) identifiers of traffic information
>> providers, or similar payload tacked onto OSM.
>>
>> I'm not saying no to a Wikidata import but I would like the proponents
>> to state clearly what makes this import special - why this and not, for
>> example, Ordnance Survey TOIDs or IDs of Mapillary photos?
>>
>> I would like to define high hurdles for such an import. The import costs
>> us a lot (in terms of mappers having to spend time to understand the
>> tags and know how to handle them when they edit an object, more quality
>> checks, etc.), and it must be proven - or at least expected - to offset
>> that cost by making itself useful. It's ok of this particular import
>> clears the hurdles but at least I can then use the hurdles if the next
>> guy in line comes along and wants to import his keys too.
>>
>> Also, I note that Rob wrote:
>>
>> "We have our own restrictions (verifiable on the ground, not changing to
>> frequently) in OSM. A link to wikidata allows us to continue with these
>> restrictions but still allow people to get at interesting non-geographic
>> data."
>>
>> And Andrew said:
>>
>> "A few more points: This isn’t a deletionists’ charter and we shouldn’t
>> rush to unload any tagging onto Wikidata without discussing the removal
>> very carefully."
>>
>> I am personally very much in favour of "unloading" non-geo-database
>> tagging elsewhere. We started with marking restaurants (useful) and
>> recording their names (also useful), classing them into fast-food or
>> "proper" restaurants, then tagging what cuisine they have and how to
>> contact them for booking a table, and meanwhile we're recording whether
>> they have vegan food and what their opening times are and whetehr you
>> can pay with bitcoin. We don't currently have anywhere to "offload" that
>> information which is all useful for certain use cases, but once we have
>> a working integration, I should very much hope that stuff like the menu
>> and the opening times will be recorded either in OSM or in Wikidata but
>

Re: [OSM-talk] Adding Wikidata tags to 70k items automatically

[Janko Mihelić]

Hi Frederik, great post.

I always thought wikidata tags would be a first step to a new database that
OSM needs, and which would be something like Wikidata is to Wikipedia. A
database that classifies and categorizes elements in OSM. In my opinion a
slightly modified version of Wikibase could be enough. It would have
combinations of tags and areas where that category applies.

If we had a database item in our potential OSM-wikibase that said "all
primary highways with ref 55 in the UK" and then offload the proprietary
identifiers there, I think no one would mind.

Another problem this potential database solves is the often quoted
"relations aren't categories". We could make an item "HSBC ATM machines"
and add a few tags that define an element as a HSBC ATM machine
(amenity=atm + operator=HSBC, or amenity=atm + ref:HSBC=34 or whatever)

Even wikidata tags that we are discussing could be deprecated if we had
such a database. We would have our own identifiers (O3489 instead of
Q23489) and those identifiers would link to wikidata as well as to other
databases.

If we don't make our own database that categorizes our tags and elements,
someone else will do it. In this case, it's Wikidata, which is better then
the rest because it is crowdsourced, it has an open license for it's data,
and it has opensource software for it's database and user interface. So if
I'm not mistaken, we could fork their project if that was needed. But if I
could choose, we would have our own.

Janko Mihelić

2014-08-30 23:40 GMT+02:00 Frederik Ramm :

> Hi,
>
> On 08/29/2014 08:10 PM, Rob Nickerson wrote:
> > Lets just step back and reflect on this for a minute.
>
> My overarching concern is that if this import is done, future imports
> will use the "but we also have Wikidata links" argument for justification.
>
> What we have here is a third-party database whose object identifiers we
> add to OSM as tags in order to make linking things easier.
>
> This is something that has often been requested by people but never been
> granted on a large scale because we always said that it would be an
> abuse of our database and our mapper's patience to offload everyone's
> and their dog's linking requirements onto us.
>
> Imagine every single stretch of road being tagged with three different
> proprietary (or at least competing) identifiers of traffic information
> providers, or similar payload tacked onto OSM.
>
> I'm not saying no to a Wikidata import but I would like the proponents
> to state clearly what makes this import special - why this and not, for
> example, Ordnance Survey TOIDs or IDs of Mapillary photos?
>
> I would like to define high hurdles for such an import. The import costs
> us a lot (in terms of mappers having to spend time to understand the
> tags and know how to handle them when they edit an object, more quality
> checks, etc.), and it must be proven - or at least expected - to offset
> that cost by making itself useful. It's ok of this particular import
> clears the hurdles but at least I can then use the hurdles if the next
> guy in line comes along and wants to import his keys too.
>
> Also, I note that Rob wrote:
>
> "We have our own restrictions (verifiable on the ground, not changing to
> frequently) in OSM. A link to wikidata allows us to continue with these
> restrictions but still allow people to get at interesting non-geographic
> data."
>
> And Andrew said:
>
> "A few more points: This isn’t a deletionists’ charter and we shouldn’t
> rush to unload any tagging onto Wikidata without discussing the removal
> very carefully."
>
> I am personally very much in favour of "unloading" non-geo-database
> tagging elsewhere. We started with marking restaurants (useful) and
> recording their names (also useful), classing them into fast-food or
> "proper" restaurants, then tagging what cuisine they have and how to
> contact them for booking a table, and meanwhile we're recording whether
> they have vegan food and what their opening times are and whetehr you
> can pay with bitcoin. We don't currently have anywhere to "offload" that
> information which is all useful for certain use cases, but once we have
> a working integration, I should very much hope that stuff like the menu
> and the opening times will be recorded either in OSM or in Wikidata but
> not both.
>
> Allow me one question in that matter as a Wikidata ignorant though: Are
> there any notability rules in Wikidata? For example, if we should one
> day decide that restaurant opening times should not be recorded in OSM
> but on Wikidata, can it then happen that someone records a restaurant's
> opening times on Wikidata only to have that information kicked out by
> someone else again for lack of relevance?
>
> Because if that were the case, then Wikidata would be relatively useless
> as a general offloading point for non-geodata.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> _

Re: [OSM-talk] need advice for clever query or script

[Richard Z.]

On Sat, Aug 30, 2014 at 02:09:34AM +0200, Imre Samu wrote:
> > I have got one problem, some of the queries with most bridges do
> > not load into JOSM. Josm says "contacting the server" and thats all.
> 
> strange ... :(
> maybe timeout when generate JOSM data?

my impression was that the problem was on the overpass website as it also
generated a very strange "shorturl" for sharing.

> 
> *#2. You can split the   big query-s - to smaller ones ..*

yes, thats what I was doing. Is actually nicer to edit in smaller batches
and the problem is triggered only for the 3 or 4 most frequent contributors.

> *Other solution - >   Filter in JOSM*
> 
> *  JOSM  "File" / "Open location"  :
> http://www.overpass-api.de/api/xapi_meta?way[bridge=swing]
> *   and after open the Filter menu (   Windows→Filter from the menu, or
> Alt+Shift+F from the keyboard)
> 
> https://wiki.openstreetmap.org/wiki/JOSM/Search_function
> 
> https://www.mapbox.com/blog/2012-08-15-using-filters-josm/
> 
> * and copy the query  ( without the "global"  keyword ( ..maybe... )   )
> 
> but I am not perfect in JOSM ...   so if you find th correct JOSM filtering
> please share with me ...  :)

yes that also works, I actually use the "Download from Overpass API" 
with 
  [timeout:600];way[bridge=swing];(._;>;);out meta;
and in JOSM use the plain search to select the subset that I want.
  bridge=swing  and ( id:50483896 or id:51513287 or id:51831532 or id:52209220 
or id:59430361 or id:88300946 or id:88863770 or id:99211716 )

Never looked at filters yet, it might be that they would hide the nodes?


Richard

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

Re: [OSM-talk] Adding Wikidata tags to 70k items automatically

[yvecai]

Edward,

This is a great work but ... If you are able to add wikidata ID to OSM 
objects, why not building an API to do so instead of just adding tags to 
OSM objects ?


An API would allow QA tools to help complete data in both WMF projects 
and OSM, for instance, among other unexpected interesting services.


Whence the import is done, your work seems useless, while your code can 
help build a more powerful tool.


Yves
(I could do with wikidata tags in OSM, but in that case I'm pretty sure 
we miss something.)



On 27.08.2014 18:47, Edward Betts wrote:

I've written some code to match items in Wikidata with items in OSM. Currently
I have found 70,849 unique matches, where there is a one-to-one mapping
between OSM and Wikidata objects.

I'd like to annotate these 70k objects in OSM with a Wikidata tag
automatically.

For example:

Way: Piper's Orchard (43246411)
http://www.openstreetmap.org/way/43246411

And on Wikidata: https://www.wikidata.org/wiki/Q7197307

I would like to add wikidata=Q7197307 to "Piper's Orchard".

The code to find the matches is here:

https://github.com/edwardbetts/osm-wikidata

Matching criteria:

https://github.com/EdwardBetts/osm-wikidata/blob/master/entity_types.json

The results are here:

http://edwardbetts.com/osm-wikidata/

The best approach is probably to update 100 items with wikidata tags, then
we can check them to make sure the edit looks good. If everything is fine I
can go ahead and load the other 70k.

Does anybody have a strong preference that the edits are split up by region,
or loaded in batches?

Any objections?

I've read https://wiki.openstreetmap.org/wiki/Mechanical_Edit_Policy - if
there are no major objections I'll go ahead and create
https://wiki.openstreetmap.org/wiki/Mechanical_Edits/edward

See also:

http://wiki.openstreetmap.org/wiki/Proposed_features/Wikidata
http://wiki.openstreetmap.org/wiki/Wikidata
http://wiki.openstreetmap.org/wiki/Key:wikidata

Edward.

___
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 70k items automatically

[Eugene Alvin Villar]

On Aug 31, 2014 4:53 PM, "Fabio Alessandro Locati" 
wrote:
> Also, I would add that Wikidata is different from many (or all) other
databases since:
> 1. it can give REAL value to OSM users (while most dbs don't)
> 2. It's philosophically close to OSM (while most dbs aren't)

+1. We already link to Wikipedia using the wikipedia=* tag. I really can't
see how wikidata=* is any different.

Linking to Wikidata actually provides more value than merely linking to
Wikipedia as it provides additional data, *including* links to all language
Wikipedias where the object has an article.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Adding Wikidata tags to 70k items automatically

[Eugene Alvin Villar]

On Aug 31, 2014 5:14 PM, "Simon Poole"  wrote:
> Nipping this in the bud: the OSMF and WMF are working together on
> exactly 0 (in words: zero) projects.
>
> Note: this is simply a statement of fact and not an opinion on if the
> OSMF should or should not collaborate more (less not being possible)
> with the WMF.

This is true.

But there are certainly plenty of instances where OSM and Wikimedia
organizations and groups (not OSMF and WMF) have collaborated together.
There's a joint project between Wikimedia Indonesia and HOT Indonesia to
map and create Wikipedia articles in Kalimantan. Wikimedia Italia organized
OSMit 2013, the annual OSM conference for the Italian OSM community.
Wikimedia Suomi (Finland) is collaborating with the OpenHistoricalMap
community. Wikimedia Deutschland has sponsored the multilingual OSM map
project developed by Jochen Topf.

In addition, WMF is certainly using OSM extensively. In fact, WMF currently
has a job opening for a map engineer and one of the requirements is OSM
experience. And OSM is inspired by Wikipedia and uses Wikimedia resources
such as MediaWiki for the OSM Wiki. And we link to Wikipedia and use photos
from Wikimedia Commons as well.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Adding Wikidata tags to 70k items automatically

[Lester Caine]

On 31/08/14 09:50, Fabio Alessandro Locati wrote:
> Also, I would add that Wikidata is different from many (or all) other
> databases since:
> 1. it can give REAL value to OSM users (while most dbs don't)
> 2. It's philosophically close to OSM (while most dbs aren't)
> 3. WMF and OSM Foundations are working toghether on many projects, and
> this could be an awesome new piece to add to this collaboration

Sorry - but I don't accept that ...
Wikimedia is not 'philosophically' close to OSM although it does seem to
be learning. I'd rather that third party services simply referenced OSM
rather than downloading yet another layer of data into the core database.

That OSM does not have a reliable id for POI's may be the problem here,
but adding tags for every other database in OSM is not the solution to
that?

-- 
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 70k items automatically

[Simon Poole]

Am 31.08.2014 10:50, schrieb Fabio Alessandro Locati:
...
> 3. WMF and OSM Foundations are working toghether on many projects, and
> this could be an awesome new piece to add to this collaboration

Nipping this in the bud: the OSMF and WMF are working together on
exactly 0 (in words: zero) projects.

Note: this is simply a statement of fact and not an opinion on if the
OSMF should or should not collaborate more (less not being possible)
with the WMF.

Simon

-- 
OpenStreetMap Foundation
132 Maney Hill Road
Sutton Coldfield
B72 1JU
United Kingdom
A company limited by guarantee, registered in England and Wales.
Registration No. 05912761.



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

Re: [OSM-talk] Adding Wikidata tags to 70k items automatically

[Fabio Alessandro Locati]

Hi,
I've waited long to respond to this thread, but I've followed it since the
begin.

I think we should proceed with the bulk importation and set up a
maproultette (or similar) system to do QA on Wikidata tags.

Also, I would add that Wikidata is different from many (or all) other
databases since:
1. it can give REAL value to OSM users (while most dbs don't)
2. It's philosophically close to OSM (while most dbs aren't)
3. WMF and OSM Foundations are working toghether on many projects, and this
could be an awesome new piece to add to this collaboration

These are my 2 cc,
Fabio A Locati
-- 
Fabio Alessandro Locati

Home: Segrate, Milan, Italy (CET/CEST)
Phone: +39 348 2668873
MSN/Jabber/E-Mail: fabioloc...@gmail.com

PGP Fingerprint: B1CD 2318 532D 57D6 56FA  E409 64DE 5B09 C09A 145F

Involved in: KDE, OpenStreetMap, Ubuntu, Wikimedia
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk