Danke, gute Idee. 👍

Genau für diesen Scheinvorteil habe ich noch kein Beispiel gesehen, wo das umgesetzt ist und stattdessen nur ein Link erscheint. Kennst du da bitte ein Beispiel, das du mir zeigen könntest? Im Wiki konnte ich keines finden.

Über die Langform müsste man genauso gut per Hotlink ein Bild bekommen können, nur ohne das man den Vorteil einer echten URL verliert. Der Vorteil der URL/Langversion wäre, dass man bei Webseiten, die kein Bild anzeigen/hotlinken, einen klickbaren Link angezeigt bekommt statt einer unverlinkten Zeichenkette, die auch noch mit dem file://-Protokoll verwechselt werden kann. Bei der Langform ist es auch klar, dass das Bild von Wiki Commons kommen soll und nicht aus einem anderen Wiki. Gerade in dem allgemeinem image-Tag, wo sonst nur URLs stehen, ist das komisch, wenn da nur "File:…" steht.
Vor allem wenn es doch den speziellen wikimedia_commons-Tag gibt. Das wird auf der image-Tag-OSM-Wikiseite auch so formuliert: "Bilder, die auf wikimedia und mapillary verfügbar sind, können mit den speziellen Tags wikimedia_commons=* und mapillary=* getaggt werden. " Das ist doch viel besser?

Ich kann dir mit diesem Hotlink nicht ganz folgen. Was verstehst du darunter? Wie würde das funktionieren? Könntest du mir ein Beispiel zeigen?

Auf der Wikiseite, die du verlinkst, steht: "obwohl dies gemeinhin als wikimedia_commons=* getaggt wird". Der wikimedia_commons ist der speziellere Tag. Daher würde ich den vor image bevorzugen und image die vollständige URL vorhalten. So kann ich als OSM-Nutzer, direkt einen Link klicken.
Das wikimedia_commons kann man nun nutzen, um dieses "File:..." einzutragen. Ich habe das mal mit CS changeset/129949951 gemacht.

Ich musste nochmal nachschauen, was Hotlink genau meint. Das wäre ein Link direkt auf die Bilddatei, also hier im Beispiel wäre das ein Hotlink: https://upload.wikimedia.org/wikipedia/commons/thumb/b/b4/Luetow_dolmen_2010-08-06_006.JPG/320px-Luetow_dolmen_2010-08-06_006.JPG

Die Erklärung dazu habe ich bei Commons gefunden:
https://commons.wikimedia.org/wiki/Commons:Reusing_content_outside_Wikimedia/technical#Hotlinking

Hallo ChillyDL,

in dem image-Tag war kein Link vorhanden. Das sieht man ganz gut in der Versionsansicht, wenn man Version #3 und #4 vergleicht: way/607988992/history

Das image-Tag enthielt den Wert "File:Luetow_dolmen_2010-08-06_006.JPG" und damit keinen Link, weshalb ich diese Info genutzt habe, um daraus die URL "https://commons.wikimedia.org/wiki/File:Luetow_dolmen_2010-08-06_006.JPG" zu machen. Dies wird dann oft automatisch verlinkt und damit anklickbar.

Der image-Tag enthält normalerweise URLs, die mit http starten. Der Wert, der vor meiner Bearbeitung im image-Tag drin stand, würde ich eher in dem Key "wikimedia_commons" sehen, siehe auch das Wiki:
wikimedia_commons=*

Meintest du das? Sollten wir den wikimedia_commons-Tag hier hinzufügen?

Viele Grüße

Ich danke dir. Das schaut gut aus.

Hallo,
ja das wäre auch mein Verständnis zu Name. Man soll wohl erst disused:name machen und später old_name. Aber bisher habe ich den Zwischenschritt mit disused:name übersprungen. Da denke ich später nicht mehr dran, den wiederzuverwenden.

Wenn der Name noch groß am Gebäude steht, lass ich ihn auch gerne am Objekt bestehen als "name", weil man sich anhand dessen noch orientieren kann. Wenn das hier der Fall ist, hast du das gut gemacht, das so zu lassen.

Viele Grüße
Sven

Hi soerface, hier würde ich es ähnlich handhaben und alle veralteten Tags vom Objekt entfernen, die nun nicht mehr gültig sind (Websites, cuisine, diet, …). Den Name-Key könnte man umbenennen in "disused:name" oder "old_name".

Siehe dazu auch das Wiki old_name=*
osm.wiki/Lifecycle_prefix

Hallo soerface,
deinen Beitrag im Forum habe ich gerade gelesen. Daher hier ein kurzes Feedback zu dieser Bearbeitung.
Man könnte außer dem amenity=pharmacy noch diejenigen Tags vom Gebäude entfernen, die nur für die Apotheke gelten. Die gehören ja auch nicht mehr an das Gebäude.

Viele Grüße
Sven

siehe https://praxis-etn.de/

Hi Fred, wolltest du den neben dem Way way/277521936 liegenden Pfad mit access=no versehen oder wirklich diese Linie ohne weitere Eigenschaften?

hier das gleiche Problem wie beim Cafe. Der Slash gehört zur URL dazu

Ich habe das mal zurückgeändert wie es korrekt war

Hi Müllers, du hast hier die Website so verändert, dass sie auf einen 404 Fehler führt. Sie muss mit Slash enden.

Also nicht https://www.stadt-barth.de/details/stamm/show/cafe-am-markt-1 sondern https://www.stadt-barth.de/details/stamm/show/cafe-am-markt-1/

Hi Karsten,
dass in diesem Änderungssatz nur die Namen hingefügt worden sind und nicht die Art des POIs lag an einem Bug in StreetComplete. Ab der Version 49.2 sollte das nicht mehr vorkommen. Das Update für StreetComplete konnte ich heute schon herunterladen.

Ich habe diese beiden Nodes von dieser Änderung hier wieder entfernt. Snack mit Pep ist auch schon eingezeichnet, aber in Haus Nr.1 und nicht Nr. 2.
Ich hoffe, die POIs in der Nr. 1 sind richtig und sie sind nicht in Nr. 2?

Viele Grüße
Sven

Und worin unterscheiden sich der Landmarkt Burow in node/7702087774 und dein neuer Punkt Burow Landhandel in node/10183973848?

Wurde das erstere Geschäft nur umbenannt oder existiert dort beides?

Hallo Karsten, danke für deinen Beitrag. Um was für eine Art shop handelt es sich jeweils bei diesen beiden neuen Objekten?

source=local knowledge;survey;aerial imagery

Hallo zusammen, danke für die Diskussion. Ich gehe da auch mit, dass wir nicht für DIE Karte (oder irgendeine andere) mappen. Das würde der Wikiseite osm.wiki/DE:Taggen_f%C3%BCr_den_Renderer entsprechen und wäre nicht in OSM gewünscht.
Aber wenn es das Objekt Echarding so zweimal gibt, einmal als stat. Bezirk und als Wohngegend und man die unterscheiden kann, kann ich gut damit leben das noch als Node zu haben.

Wenn es mal ein Problem gibt, dass ein Objekt, obwohl es korrekt kartiert ist, nicht gescheit in der Karte aussieht, sollte ein Ticket beim Renderer aufgemacht werden, sodass das auch überall gefixt wird und nicht nur an der einen Stelle, wo man die Daten hinbiegt.

Viele Grüße

Hi lberges,
Echarding gibt es bereits als Relation: relation/5428611

Ist ein zusätzlicher Node hier noch nötig?

Viele Grüße