Bitte entschuldigt die späte Antwort. Ja, ich denke auch, dass der Name etwas zu lang ist. Die Information an sich (inklusive Datum) halte ich aber für spannend und sollte daher unbedingt im description-Key erhalten bleiben. Die beiden Vorschläge von Andreas gefallen mir sehr gut, wobei man, denke ich, ruhig "ehemalige Skisprungschanze Kasgraben" schreiben kann, um etwaigen Verwirrungen vorzubeugen.
Bezüglich ruins=yes fehlt mir, ehrlich gesagt die Erfahrung. So wie ich das Wiki verstehe passt es nicht 100%-ig, aber ich lese auch nichts heraus, was ruins=yes ausschließen würde. Mir wäre diesbezüglich also beides recht.

LG Michael

Hallo PaulGomes,

danke für das Einzeichnen der alten Skisprungschanzen! (Hier und am Himmelhof) Ich fand es sehr spannend die Geschichte zu diesen doch recht markanten Punkten zu erfahren. Ich denke nur, dass der Text besser in den description= Key passt, als in den name= Key. Immerhin handelt es sich um eine Beschreibung der Abhänge. Spricht irgendetwas dagegen, die Infromation dorthin zu verschieben?

LG
Michael

Hi! Actually, I'm not from Mapbox, I just use their tool to state that a particular changeset has been positively reviewed. (I also don't use their tool for reviews because the satellite imagery is sometimes outdated) Since your changeset covers a large area and (at least for me) the correctness was not instantly obvious, I wanted to indicate that I have double checked the changes. By submitting a review, I intend to avoid duplicate work. Would it be fine if I directly post a comment when I review one of your changesets next time?
Regarding the linked changeset review I cannot say much because I don't know the area well. Sorry!
Best regards, Michael

Hello!
I reviewed your changeset on OSMCha and it looks great!
Thank you very much for your contributions to OpenStreetMap!
#REVIEWED_GOOD #OSMCHA
Published using OSMCha: https://osmcha.mapbox.com/changesets/55668289

Hello!
I reviewed your changeset on OSMCha and it looks great!
Thank you very much for your contributions to OpenStreetMap!
#REVIEWED_GOOD #OSMCHA
Published using OSMCha: https://osmcha.mapbox.com/changesets/55659216

In principle, I agree with zimba that a more meaningful changeset comment may be nice and I think that the west part of the old building at Hütteldorf has been changed and could be refined, but I'm also very grateful that someone is maintaining the building structure in that area. Thank you, _!Y!_, for your effort! If you don't want to refine the ÖBB building yourself, I can have a look at it on the ground and refine it afterwards.
Have you figured out how and why the huge building outline at Gurkgasse was created? It is now visible on the map, so we shouldn't wait too long before acting.

Best regards
Michael

Hi _!Y!_ !

According to Achavi [1], Changeset Analyzer [2] and OSM itself [3] there is a huge spurious (?) building introduced which covers several blocks at Gurkgasse. At least for me, the building is not rendered in OSM but it is sill listed in the changeset. Was the line [3] introduced on purpose? (Or do I misinterpret the output of OSM?) Thank you in advance for your reply!

Best regards
Michael

[1] https://nrenner.github.io/achavi/?changeset=55572069
[2] https://osmcha.mapbox.com/changesets/55572069
[3] way/554210460

Hi Yktan,

no problem, to be honest, I havn't put too many toughs into the orography of street names and I'm always glad to learn something new. Thank you for your patient explanations!
I did a quick search and I was not able to find any official list of suburb names except the document you posted. Nevertheless, any source I found (e.g. [2]), including a book on Hietzing [1] uses the version with spaces. Since the document from Nomenklaturkommission is the most official source I see, keeping the suburb names with hyphens is probably the best option. (If someone else finds other reasons why to use spaces, we may have to repeat the discussion.) I also think that using the alt_name for the other version is an excellent idea. On using that tag, people will hopefully still be able to find the suburbs, even if they use the version with spaces. I'll soon add the additional tag.
According to the "don't use abbreviations" rule [3], the names should be indeed spelled with "Sankt", but I think that would even add more confusion. Especially, given that the official name abbreviates it and the abbreviation is not yet implemented in OpenStreetMap.

Kind regards,
Michael

[1] "Wien 13. Bezirk, Hietzing in alten Fotografien", Carola Leitner and Kurt Hamtil, Ueberreuter, 2006
[2] http://www.hietzing.at/Bezirk/bezirk_liste.php?tags=Ober_St_dot__Veit&menu=3
[3] osm.wiki/Naming_conventions

Hi Yktan Eszett!

I just saw that you reverted most of your edits regarding the hyphens in Unter St. Veit and Ober St. Veit. Thank you very much for that!
Currently, the place=suburb node names are still written with hyphens. Is this intentional or were these nodes just not properly reverted?

Best regards,
Michael

See changeset/53436834 for a discussion on that topic.

See changeset/53436834 for a discussion on that topic.

Hi Yktan Eszett!

First of all welcome to OpenStreetMap and thank you for your contribution! Unfortunately, I think Ober St. Veit and Unter St. Veit is better spelled without hyphens ('-'). AFAIK, there is a policy in OpenStreetMap that thinks are usually spelled as seen on the ground (e.g. [1]). Especially if there is a general rule on how to spell street names and a street is signposted in a different way, the spelling on the streetsigns should be applied. Have you seen some signs or something similar spelled with hyphens? As far as I remember all labels on the underground stations are spelled with spaces and in a Book on Hietzing, the names were also spelled with spaces.
If you do not have any strong indicators that the spelling with hyphens is actually used on the ground, please revert your changes regarding Unter St. Veit and Ober St. Veit. Thank you very much in advance!
If you have issues with reverting your changes or if you have any questions regarding OpenStreetMap, don't hesitate in dropping a line.

Best regards
Michael

[1] osm.wiki/Naming_conventions

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

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

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;

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

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

[1] changeset/52339653

Hi nyuriks,
thank you for the reply and taking action. Currently, I'm not sure at which point these issues should be tackled. Maybe it is also an option to create new Wikidata entities for those list items and items which are only described in sub-pages. This may simplify data evaluation and may also provide additional benefit for Wikidata. In any way, I think it should be possible to automatically identify those problematic tags because nearly almost all other Wikipedia tag now also have a Wikidata tag. Thank you for your contribution on that.
Best regards,
Michael

Hi!

I've quickly browsed trough some of your changes and most of the Wikidata references seem to match perfectly with the Wikipedia article. However, anchors in wikipedia sites (en:foo#bar) do not seem to be handled correctly. See [1] or [2] for instance. The Wikipedia link points to the correct entry in a list but the Wikidata ID just points to the entire list. Hence, some spurious Wikidata ID is added to OSM. I would be glad if you could double check entries with anchors during cleanup.

Best regards,
Michael

[1] node/935343113
[2] node/326086904

Zu allererst: Herzlich willkommen bei Openstreetmap und Danke für Ihren Beitrag!
Es ist zwar nur eine Kleinigkeit, aber das Namensfeld wird üblicherweise dazu verwendet den Namen eines Objekts einzutragen, also z.B. "Huber-Wirt". Damit die Daten bestmöglich verwertet und dargestellt werden können, gibt es eigene Adressfelder. Diese können z.B. in ID im Bereich links über "Feld hinzufügen/Adresse" eingegeben werden. Ich bitte Sie daher den Namen zu löschen (leer lassen) und stattdessen die Adressfelder zu verwenden. Vielen Dank im Voraus!
Zusätzliche Informationen zum Eintragen von Adressinformation finden Sie im Wiki [1,2]. Sollten die Wiki-Seiten noch etwas unklar sein, kann ich den "Beginners Guide" [3] empfehlen. Außerdem stehe ich Ihnen gerne für Fragen zur Verfügung.

Schöne Grüße und viel Spaß beim Mappen
Michael

[1] osm.wiki/DE:Key:name
[2] osm.wiki/DE:Key:addr
[3] osm.wiki/DE:Beginners%27_guide