Changeset: 52744495
Adding wikidata entries
Closed by rmikke
Tags
created_by | JOSM/1.5 (12921 pl) |
---|---|
source | Wikipedia plugin |
Discussion
-
Comment from Spiegel0
Hi rmikke,
thank you for your contribution. I quickly browsed through some modifications in the vast amount of changes and they look very similar to changeset [1]. In particular they are showing the same flaws as described in the discussion section of [1]. I don't want to hinder the usage of Wikidata tags in general but I would be glad if such corner cases are properly handled. I therefore kindly ask you to fix the cases where in-site links and list ("Liste") articles are involved or to completely revert your edit. From my point of view, one possible fix would be to (at least) delete all spurious Wikidata entries on "list" nodes. Consequently, a node without Wikidata entry would indicate the need of manual intervention. Thank you in advance.
Best regards,
Michael -
Comment from rmikke
Hi,
I've read discussion in [1]and I'm not quite sure what is the problem here.But if you mean that some wikidata IDs point to a wikipedia list article then the answer is: Yes, they do, because articles in wikipedia=* tag were list articles. The same goes for disambiguation pages. I don't know what you mean by "in-site" links?
Now, please note that the user nyuriks (the author of [1]) created a tool for correcting wikipedia/wikidata entries that are lists or disambigs and this tool uses wikidata heavily. This meanss that one can find and correct such cases if they have wikidata entries, so adding wikidata entries makes it easier to find and correct such cases. Which is one of the main reasons i try to add wikidata ID to every object that has a wikipedia=* tag.
You can see the tool here: https://www.mediawiki.org/wiki/User:Yurik/OSM_wiki_tag_problems . While I have used the disambig part of tool throughout the world (everywhere I could read the names of OSM objects i.e. everywhere they use latin or cyrillic alphabet), I am not able to decice what to do with lists where I don't really understand the language (which limits it to English, Polish, Russian and maybe some othe Slavic languages).Therefore I think the best solution would be to drop the tool in some German forum and find someone willing and able to solve the cases manually.
As for "in-site links" please clarify what you mean and what is the problem with them. My guess was that you mean wikipedia links pointing to some section of wikipedia article, but as far as I know the method I use does nothing with such wikipedia links (as is the case fo any wikipedia=* value that does not translate directly to a wikidata item).
-
Comment from rmikke
Also, if someone speaking German would be willing to use nyuriks' tool, I offer to answer any question I can. I am also sure that nyuriks would be happy to help, as he helped me when I was starting using his tool.
-
Comment from Spiegel0
Hi!
First of all, thank you for your quick reply! I'm sorry for the confusion regarding "in-site links". I mean those links which do not point to a whole Wikipedia article but a section thereof. I.e. links following the scheme "de:foo#bar" (Sorry, I don't know the exact term for those links which point to a subsection.) From my point of view, these links are not ideal but correct. They point to the concept which is described in the section. For instance node ID 935343113 and 326086904 (see [1]) have a Wikipedia Tag which points to exactly one section in an article. That article just lists several objects and one section describes the item from OSM. By following the Wikipedia link, exactly that item is addressed and not the entire list of objects.
Unfortunately, for these kind of links no Wikidata object was created yet. Hence, there is only one Wikidata ID for the entire list. Adding the Wikidata ID of the entire list obviously creates a spurious entry in OSM. I don't know why the importing tool failed to handle the list article but I'm quite sure that it is not handled correctly.
I agree with you that someone who is speaking German should better check and adjust the Wikidata entries. There may be other corner cases which arn't addressed so far. Since there are so many items in the changeset, I'll have no time to verify a significant amount of them. But just for the sake of curiosity, I will probably have a look at the import tool.
I hope I was able to explain my issues with section ("in-site") links and ask you again to take appropriate action on them. Thank you very much in advance.Best regards,
Michael -
Comment from rmikke
1. The tool I have linked is not an import tool. It's a QA tool, that addresses exactly the problems you mention and more. You can use it e.g. to identify all the disambiguation articles in wikidata=* tags (shown on map), then go and correct whatever you can.
2. Oooops, I can see the problem with links to sections and I'm not quite sure how to deal with it. @matkoniecz is working on tool comparing wikipedia=* and wikidata=* tags (i.e. whether they point to the same article), maybe that will help to identify such cases. -
Comment from Spiegel0
Hi rmikke!
Ad 1) I looked at the tool (Wikipedia Plugin + SPARQL service) in slightly more detail and it looks quire powerful and impressive. You are right, it's surely not a tool which can only be used for imports. I also see several new opportunities in linking OSM and Wikidata. In order to get useful results on querying OSM+Wikidata, I strongly believe its very important to keep the quality of Wikidata entries as high as possible. Especially linking to wrong Wikidata concepts (e.g. to a list instead of an entry or to a person instead of a museum) may drastically decrease the value of the service.
Ad 2.) I've also tries to further asses the quality of your changeset via Overpass and to be honest - I'm not really satisfied with the way how section links on Wikipedia are handled. You may want to run the query below on http://overpass-turbo.eu/ to get an impression on how many entries were affected by your edit in Austria. If I'm not mistaken, there are for instance 2546 nodes with a section link in your changeset. Please revert or fix those entries. Thank you in advance.Best regards,
Michael--------------------------------------
[out:json];
// fetch area “Austria” to search in
{{geocodeArea:Austria}}->.searchArea;
// gather results
(
// query part for: “wikipedia="*#*"”
node["wikipedia"~".*#.*"](area.searchArea)(user:rmikke);
way["wikipedia"~".*#.*"](area.searchArea)(user:rmikke);
relation["wikipedia"~".*#.*"](area.searchArea)(user:rmikke);
);
// print results
out body;
>;
out skel qt; -
Comment from rmikke
I intend to remove wikidata entries where wikipedia link points to a section of Wikipedia article and exclude such cases from query in future, see [1]. However, it seems strange that there are so many cases - AFAIR that's about the number of all changes I have made in Austria...
[1] https://lists.openstreetmap.org/pipermail/talk/2017-October/079138.html
-
Comment from Spiegel0
Thank you very much for taking action! It sounds indeed strange that the number of section link items is that high. AFAIR, there was quite some Wikipedia/Wikidata-related activity some time ago but I can hardly believe that nearly all changes in the changeset were section links. Maybe I've made a mistake with the Overpass query. I'll double check it in the next few days and let you know whether I've found an explanation.
Best regards, Michael -
Comment from Spiegel0
I double checked the query and it seems to be correct. However, I was first confused by the high number of nodes which was displayed by overpass. It turned out that the number of nodes which is displayed at overpass-turbo.eu includes all nodes of every returned object. Not only those nodes with a Wikipedia section-link tag. If for instance a street with 20 nodes is tagged by a Wikipedia tag, 20 nodes are added to the total number of nodes.
I counted the number of affected Wikipedia/Wikidata tags and there were only 224 cases which still need to be considered. Thats about 3.3% of the changes in your changeset, which sounds plausible to me. I hope my investigations are helpful for fixing the invalid cases which were introduced by the changeset.Best regards,
Michael
- Barichgasse (4789258), v19
- Wildbichler-Bundesstraße (4814772), v15
- Unterinntalbahn (4824179), v18
- Riesgasse (5889589), v10
- Jaurèsgasse (5889617), v11
- Ziehrerplatz (9654905), v10
- Pfarrkirche Maria Schnee (26292991), v13
- Verbindungsbahn (26302388), v13
- Pottendorfer Linie (26351227), v12
- Laaber Kaiserzipfwiese (26390535), v8
- Zu den vier heiligen Evangelisten (26583483), v4
- Stefaniewarte (26586105), v10
- Paulinenturm (26591674), v8
- Verbindungsbahn (26686001), v31
- Drautalbahn (26725527), v18
- Donauländebahn (26740464), v19
- Landecker Tunnel (26803745), v27
- Kronprinz Rudolf-Bahn (26831822), v17
- Kronprinz Rudolf-Bahn (26831827), v11
- Kronprinz Rudolf-Bahn (26831831), v12
- Hl. Martin (1559381309), v8
- Pestsäule (2446694168), v5
- Sina-Warte (387433282), v5
- Kriegerdenkmal 1. Weltkrieg (935343113), v10
- Meilenstein (1151313782), v10
- Georgistollen (1369430055), v8
- 1504940375, v6
- 1504940381, v6
- 1504940394, v6
- Kriegerdenkmal (1770459859), v5
- Erzstollen (1854518307), v8
- Pietà-Pfeiler (2056484804), v6
- Grenzstein (2265840002), v8
- Kriegerdenkmal (2417463432), v6
- Bildbaum (2441125110), v5
- Sebastianpfeiler (2449593526), v8
- Mariensäule (2449609356), v5
- Olramkreuz (2450079395), v7
- Hl. Johannes Nepomuk (3121575004), v5
- Sparkassenbrunnen (5135814499), v2
Welcome to OpenStreetMap!
OpenStreetMap is a map of the world, created by people like you and free to use under an open license.
Hosting is supported by Fastly, OSMF corporate members, and other partners.
https://openstreetmap.org/copyright | https://openstreetmap.org |
Copyright OpenStreetMap and contributors, under an open license |