<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2014-08-31 20:19 GMT+02:00 Edward Betts <span dir="ltr"><<a href="mailto:edward@4angle.com" target="_blank">edward@4angle.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">Archer <<a href="mailto:arch3r@gulli.com">arch3r@gulli.com</a>> wrote:<br>
> Please don’t understand me wrong. I’m a big fan of Wikidata but I'm against<br>
> an automated import. The mismatches list gives good examples that your<br>
> matching algorithm doesn't work very well:<br>
> <a href="http://edwardbetts.com/osm-wikidata/mismatches.html" target="_blank">http://edwardbetts.com/osm-wikidata/mismatches.html</a><br>
><br>
> Some examples:<br>
><br>
</div>> 1. Isar Nuclear Power Plant <<a href="http://wikidata.org/wiki/Q569510" target="_blank">http://wikidata.org/wiki/Q569510</a>>: your<br>
<div class="">> algorithm matches only one reactor of the power plant: Isar 2<br>
</div>> <<a href="http://www.openstreetmap.org/way/32918120" target="_blank">http://www.openstreetmap.org/way/32918120</a>> but the right matching<br>
> would be Kernkraftwerke<br>
> Isar <<a href="http://www.openstreetmap.org/way/23802422" target="_blank">http://www.openstreetmap.org/way/23802422</a>><br>
<br>
Q569510 is matching Isar 2 (Way 32918120) because Isar 2 is in the list of<br>
German aliases in the Wikidata object:<br>
<br>
[ "KKW Isar", "AKW Isar", "Isar 2", "Kernkraftwerk Isar I", "Isar 1",<br>
  "Atomkraftwerk Isar" ]<br>
<br>
The German label on the Wikidata item is "Kernkraftwerke Isar", notice the<br>
extra 'e' on the end of the first word.<br>
<br>
I could add Levenshtein distance calculations to my matching, we could say if<br>
there is a single character difference the names match. With this change both<br>
OSM objects would match and my code would skip the wikidata item.<br>
<br>
The problem with this change is that hill and hall would match.<br>
<br></blockquote><div>Ok, but the Wikidata object describes the whole power plant and not only one reactor. <br><br>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.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> 2. Heligoland <<a href="http://wikidata.org/wiki/Q3038" target="_blank">http://wikidata.org/wiki/Q3038</a>>: you’ve matched the island<br>
> Heligoland <<a href="http://www.openstreetmap.org/relation/3787052" target="_blank">http://www.openstreetmap.org/relation/3787052</a>> but the right<br>
<div class="">> match would be the municipality Heligoland<br>
</div>> <<a href="http://www.openstreetmap.org/relation/1157962" target="_blank">http://www.openstreetmap.org/relation/1157962</a>> (for the island there<br>
<div class="">> exists a different object in Wikidata)<br>
<br>
</div>I can't find the Wikidata item that represents the island.<br></blockquote><div><br><br></div><div>island: <a href="https://www.wikidata.org/wiki/Q3129772">https://www.wikidata.org/wiki/Q3129772</a><br></div><div>
municipality: <a href="https://www.wikidata.org/wiki/Q3038">https://www.wikidata.org/wiki/Q3038</a><br></div><div>archipelago: <a href="https://www.wikidata.org/wiki/Q17515918">https://www.wikidata.org/wiki/Q17515918</a><br>
</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">
> I also don’t understand why you prefer nodes instead of ways or relations.<br>
> Ways and relations provide more information (e.g. extent of an area) than<br>
> nodes. The Matching algorithm should first look for relations, when there’s<br>
> no relation it should search for ways. Nodes should come last.<br>
<br>
</div>The matching algorithm is only considering objects within 400m, so the nodes<br>
happen to be close, but the centre of the relation is more than 400m from the<br>
location in Wikidata.<br>
<br>
I've modified my matching algorithm to use much large distances for some types<br>
of object, it is running now. My hope is that when it is finished the code<br>
will detect the presence of the node and relation and skip the Wikidata item.<br>
Most of these node vs relation mismatches should disappear.<br></blockquote><div><br></div><div>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.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=""><br>
> What does your matching algorithm when a Wikidata object describes<br>
> different objects and therefore should be split?<br>
><br>
> A good example for this is the Wikidata object for Thasos<br>
</div>> <<a href="https://www.wikidata.org/wiki/Q204096" target="_blank">https://www.wikidata.org/wiki/Q204096</a>> (currently it describes the island<br>
<div class="">> and the municipality “Thasos”) but the object has to be split into two<br>
> Wikidata objects so that you can say “the island Thasos lies in the<br>
> administrative division Thasos”. There are also other examples like mixed<br>
> up nature reserves, lakes and administrative divisions in Wikidata which<br>
> you have to solve before you can import the IDs into OSM.<br>
<br>
</div>My code doesn't do anything special with a wikidata item that represents<br>
multiple things like islands and municipalities. If Wikidata/Wikipedia claim a<br>
thing is an island, and in OSM there is a thing tagged with place=island and<br>
the same name they will match.<br>
<br>
OSM objects can be tagged as both an island and a municipality.</blockquote><div>I'd propose to drop Wikidata objects which have the following property combinations:<br></div><div>"is a" island and at the same time administrative division<br>
</div><div>"is a" nature reserve and administrative division<br>"is a" lake and administrative division</div><div>"is a" forest  and administrative division</div><div>These are the combinations where I've encountered problems in Wikidata yet.<br>
</div><div><br></div><div>Another problem here: municipality Langeneß: <a href="https://www.wikidata.org/wiki/Q29931">https://www.wikidata.org/wiki/Q29931</a> the algorithm matches the island which is also called "Langeneß". But the island has its own WD-object: <a href="https://www.wikidata.org/wiki/Q13747872">https://www.wikidata.org/wiki/Q13747872</a> OSM Tags und Wikidata Propertys (P39) should be compared and only if the attributes match there should be a match.<br>
<br></div><div>Or Mawson Peak: <a href="http://www.openstreetmap.org/node/2774722248">http://www.openstreetmap.org/node/2774722248</a> the match of the algorithm was Big Ben (volcanoe) <a href="https://www.wikidata.org/wiki/Q858516">https://www.wikidata.org/wiki/Q858516</a> but it should be Mawson Peak: <a href="https://www.wikidata.org/wiki/Q2114101">https://www.wikidata.org/wiki/Q2114101</a> (Mawson Peak is the highest point of the volcanoe "Big Ben". It seems that the algorithm focuses to much on aliases in Wikidata.<br>
</div></div></div></div>