In the original version of the node (node/8006275399/history/1), I linked to a file on Wikimedia Commons (https://commons.wikimedia.org/wiki/File:B%C3%A4r-Some_like_it_hot.jpg - that was taken somewhere else though, and not by me) - when the sculpture was still standing here, it did look a bit different though, seems like it was painted differently. I also have a low quality, night-time photo from when I initially noticed it, but now that it's gone, that's not so useful anymore ;).

Super, danke für die Anpassung!

Hallo Lirum Larum, tut mir leid, dass ich das falsch getaggt habe, da hat sich wohl meine lokale Quelle etwas vertan und ich hab das leider auch nicht vor Ort geprüft. Allerdings bin ich auch nicht sicher, ob das Tagging als `amenity=bar` wirklich passend ist, mind. aufgrund der Selbstdarstellung auf der Website, in sog. sozialen Medien sowie einem Zeitungsartikel würde ich das mittlerweile tatsächlich eher als `tourism=gallery` kombiniert mit `bar=yes` taggen. Aber wenn du genauere 'on-the-ground'-Infos hast, gehen die natürlich vor.

Hallo sk94,
um das Haus herum zeichnen geht vermutlich nicht in jedem Fall, daher ist das wohl schwierig. Grundstuecke einzeln erfassen haette sicher einen gewissen Zusatznutzen, aber hat halt auch das Problem, dass nicht unbedingt das ganze Grundstueck ein Garten ist - dies als Multipolygon zu erfassen und z.B. das Haus und Parkplaetze/Wege ausnehmen waere technisch zwar wohl korrekt (oder zumindest nicht ganz falsch), resultiert aber in sehr vielen Multipolygonen, was sicher auch nicht ideal ist - das muss ja alles auch noch irgendwie gepflegt werden koennen und so 'gruen' wie z.B. Frauenfeld ist, ergaebe das wohl fast ein Multipolygon pro Wohngebaeude, also eine ganze Menge. D.h. ja, es ist nicht ganz einfach zu entscheiden, wie man das erfassen will ;).
Dass diese Gaerten in Genf schon ziemlich umfassend erfasst wurden, wusste ich nicht - scheint mir aber in der Schweiz schon eher die Ausnahme zu sein, aufgefallen war mir das sonst noch nicht. Wenn man sie erfassen will, wuerde ich zumindest noch dazu tendieren, `garden:type=residential`- und `access=private`-Tags zu setzen (osm.wiki/DE:Key:garden:type), so lassen sie sich z.B. von oeffentlichen Gaerten unterscheiden.
Fuer einen Dialog in groesserer Runde kannst du ja vielleicht auch mal ein Mail an die talk-ch-Liste schicken (https://lists.openstreetmap.ch/mailman/listinfo/talk-ch).

Gruss
mstock

Hallo sk94,

mir ist aufgefallen, dass in diesem und ein paar nachfolgenden Aenderungssaetzen einige Flaechen als `leisure=garden` getaggt werden. Ich weiss noch nicht, ob ich das gut oder schlecht finde, wuerde es selbst aber ziemlich sicher nicht oder nicht so machen, weil es doch auch noch einige andere Dinge, die kein Garten sind, wie z.B. Parkplaetze oder Zufahrtswege/-flaechen, in diesen Gebieten hat. Mindestens in der englischen Version der Beschreibung des Tags im Wiki (leisure=garden) steht auch "Areas should not include features (for example residential houses) which are not part of the garden itself.", das wuerde durch diese Flaechen verletzt. Im Detail gibt es auch noch ein paar Stellen, wo die neuen Flaechen Trottoirs oder Fusswege schneiden, die ausserhalb der Gebiete liegen.

Gruss
mstock

Habe das soeben entsprechend angepasst, siehe Changeset #103293975 (changeset/103293975).
Bezueglich Normierung: Das ganze Schild sieht ohnehin lustig aus, das eigentliche Parkplatz-Schild ist sehr stark verwittert, der Zusatz mit der Beschraenkung sieht hingegen ziemlich neu aus, das soll also vermutlich ein neueres Problem 'loesen', und ich hoffe schon sehr, dass das zumindest in dieser Schreibweise nicht Teil einer Norm ist ;).

Hallo,
aus meiner Sicht ist im Wiki zumindest nichts entsprechendes dokumentiert - auf dem Schild steht woertlich "Dauer Parkieren verboten", mehr leider nicht. Basierend auf dem maxstay=unlimited aus dem Wiki (bei maxstay=*#Maxstay=0) koennte man vielleicht maxstay=limited draus machen (maxstay=yes war ja mein erster Versuch, der gefiel JOSM schon nicht ;)), das wurde laut taginfo immerhin schon einmal benuetzt (maxstay=yes schon rund 40 mal, limited faende ich aber irgendwie verstaendlicher). Was meinst du? Gluecklich bin ich ueber 'mein' neues Tag ja nicht, war halt der einfachste Weg, diesen Sachverhalt zu dokumentieren ;).

Hi,
the meaning of this is that I made a mistake ;). Should be fixed in changeset #95178339.

Thanks for notifying me :)!

Hi Martin,

thank you for the notification, I've just removed the cycleway tag for now, currently, there's only a sidewalk that is publicly usable since some construction work is going on, so the cycleway tag clearly was wrong.

Greetings
Manfred

Hallo xraysalami,

mir ist aufgefallen, dass du in diesem Aenderungssatz beim Hof 'Waldegg' wahrscheinlich versehentlich den Namen auf 'WaldeggBei Fahrtantritt habe er sich „wie nach einer Auseinandersetzung mit Klitschko“ gefühlt.' gesetzt hast. Das hat unterdessen jemand anderes repariert, aber ich habe gerade noch zwei weitere, ganz aehnliche Fehler von dir korrigiert [1,2] (wo's nicht im 'name'-Tag und daher etwas subtiler war). Ich weiss nicht, wie dir das passiert ist, ich vermute, es war eine Art Copy-Paste-Fehler, Drei Instanzen dieses Fehlers sind mittlerweile korrigiert, da musst du also nichts mehr machen, aber in Zukunft vielleicht etwas besser aufpassen, schliesslich koennten da auch mal Informationen dabei sein, die du nicht im Internet veroeffentlichen willst ;).

Gruss
mstock

[1] changeset/42444967
[2] changeset/42445345

Hallo Christian,
super, danke fuer die Korrekturen :).
Gruss
mstock

Hallo wunderhorn,
mir ist aufgefallen, dass du in diesem Changeset bei vielen Elementen addr:city, addr:country und addr:postcode hinzugefuegt hast (http://overpass-api.de/achavi/?changeset=38161768). Da diese Information aus den Grenzen hergeleitet werden kann (hier z.B. aus relation/1684520), finde ich das zwar nicht sehr sinnvoll, solange es korrekt ist, stoert es mich aber auch nicht. Allerdings ist zumindest addr:city auch an ein paar Hecken, Baechen, Parkplaetzen, Bahngleisen und Bahnsteigen gelandet, was vermutlich keine Absicht war ;). Falls doch, wuerde mich der Nutzen davon dann schon noch interessieren. Zudem ist beim das Restaurant Frohsinn umschliessenden Weg (way/197836993), vermutlich ebenfalls aus Versehen, building=yes verloren gegangen.

Gruss & Happy Mapping
mstock

Hallo osmma,

mir ist aufgefallen, dass du in diesem Changeset den Building-Part mit dem Bettenturm des Kantonsspitals Frauenfeld geloescht hast, leider ohne Changeset-Kommentar, wo man solche Aenderungen begruenden koennte. Soweit ich weiss, steht er momentan ja noch, und wird erst in den naechsten Jahren abgerissen. Wenn es dir nichts ausmacht, wuerde ich daher diese Aenderung fuer den Moment mal noch rueckgaengig machen, damit die 3d-Darstellung des Spitals bei z.B. der f4map-Demo (http://demo.f4map.com/) wieder korrekter aussieht.

Gruss
mstock

Just to be on the safe side, I visited the "Müllheim end" of this power line today, and it definitely still exists.

Hallo butl,

ok :). Ich hab's jetzt in Changeset #33890961 repariert. Damit sind die Luecken weg, und der Relation Analyzer [1] ist auch wieder zufrieden. Die Trottoirs habe ich jetzt einfach mittels 'sidewalk'-Tags an den Strassen erfasst, das ist nicht ganz so genau, aber wahrscheinlich auch nicht falsch. Vielleicht frage ich am Stammtisch mal ein paar andere Mapper, wie sie solche Situationen erfassen (wuerden).
Bei iD wuesste ich uebrigens auch nicht, wie man Relationen bearbeitet, allerdings verwende ich den auch fast nie. Bei JOSM hat's aber auch recht lange gedauert, bis ich die erste Relation bewusst angefasst habe ;).

Gruss
mstock

[1] http://ra.osmsurround.org/analyzeRelation?relationId=4084314&noCache=true&_noCache=on

Hallo butl,

ja, das waere fuer mich grundsaetzlich durchaus ok, da die Relation momentan wirklich Luecken hat, was ich stoerender finde als die fehlenden Details an diesen drei "Kreuzungen". Reparierst du das, oder soll ich mich drum kuemmern? Dabei waere es sicher sinnvoll, wenigstens noch die 'sidewalk'-Tags [1] an den betroffenen Wegstuecken anzubringen, da diese sonst ebenfalls Luecken aufweisen, weil die angrenzenden Strassen mind. der Inline-Strecke entlang welche haben.
Trotzdem noch ein paar Worte zum Thema Detaillierungsgrad und die Gruende, wieso ich das so erfasst hatte:
* Auf [2] hat es Infos zur Erfassung von Inline-Routen in der Schweiz, und da steht sinngemaess, dass es noetig sein kann, dass man fuer die korrekte Modellierung Trottoirs zur Relation hinzufuegt. Daher habe ich das hier mal begonnen.
* Je mehr Details bei Strassen und Wegen erfasst sind, desto bessere/genauere Routen lassen sich errechnen. Fuer Autos und durchschnittliche Fussgaenger sind unsere Daten sicher meist schon recht gut, wobei man bei Fussgaengern das Routing meiner Meinung nach schon noch spuerbar verbessern kann, wenn auch Trottoirs, Fussgaengerstreifen, etc. erfasst sind - so koennte man z.B. vermeiden, dass man sie einer Hauptstrasse ohne Trottoir entlang schickt, nur weil sie der kuerzeste Weg ist. Abgesehen davon koennen die Daten natuerlich auch fuer das Routing von sehbehinderten oder blinden Fussgaengern oder von Rollstuhlfahrern verwendet werden - beide duerften durchaus von vielen Details profitieren, erstere z.B. von Informationen zum Vorhandensein taktiler Belaege [3], letztere z.B. auch von Informationen zur Beschaffenheit der Bordsteinkante [4].
* Ueber den richtigen Detaillierungsgrad herrscht sicher noch keine Einigkeit ;). Ich (und auch andere [5]) finde Trottoirs und so z.B. durchaus sinnvoll, und zwar fuer's Routing. Gerendert werden muessen sie deswegen nicht, das bringt dann wirklich nicht soo viel (meiner Meinung nach ;)). Bei den (momentan) ~474'002 Baeumen, die in der Schweiz erfasst sind, sehe ich den Nutzen auch nicht so, kann jetzt aber nicht behaupten, noch nie einen erfasst zu haben, und loeschen wuerde ich sie deswegen auch nicht ;). Beim Loeschen halte ich es grundsaetzlich so, dass ich nur Objekte loesche, die falsch oder ueberholt sind, d.h. die in der Realitaet nicht oder nicht mehr existieren. Falls ich auf etwas stossen sollte, das ich wirklich komisch oder problematisch finde, wuerde ich zuerst den Erfasser kontaktieren, und je nachdem auf der Mailingliste oder am Stammtisch das Thema mal ansprechen, um zu sehen, was andere davon halten.

Gruss
mstock

[1] osm.wiki/DE:Key:sidewalk
[2] osm.wiki/Switzerland/InlineNetwork#Inline_Skating_in_Switzerland
[3] tactile_paving=*
[4] kerb=*
[5] osm.wiki/Sidewalks

Hallo butl,
in diesem Changeset [1] sowie dem vorhergehenden [2] und einem spaeteren [3] Changeset hast du ein paar Wege geloescht. Mag sein, dass ich es dort mit dem Detailgrad etwas uebertrieben hatte, allerdings waren sie einerseits zusammen mit den Trottoirs und den Fussgaengerstreifen so gemacht, dass man Fussgaenger meiner Meinung nach korrekt routen kann, und andererseits waren sie zumindest teilweise Teil der Country-Skate-Relation [4], welche jetzt an drei Stellen kaputt ist, d.h. Luecken aufweist. Wenn moeglich waere ich daher froh, wenn du die Wege wiederherstellen und/oder zumindest die Relation korrekt reparieren koenntest.
Wie ich dem Changeset entnehme, hast du dafuer iD als Editor benuetzt - das ist ok, allerdings hat(te?) iD in Bezug auf Relationen gewisse Defizite - JOSM (ein anderer Editor) warnt jedenfalls, wenn man ein Mitglied einer Relation loeschen will, spaetestens dann sollte man es sich also nochmals ueberlegen, ob man das Objekt wirklich entfernen moechte ;) - ich weiss aber nicht, ob iD das auch macht, falls nicht, ist es sicher sinnvoll, dort sehr vorsichtig zu sein, wenn man etwas loescht.
Ganz abgesehen davon sind auch Changeset-Kommentare beim Abspeichern von Aenderungen noch gern gesehen, dort koennte man dann z.B. auch begruenden, wieso man etwas geloescht hat.

Gruss
mstock

[1] #33439503, http://overpass-api.de/achavi/?changeset=33439503
[2] #33430646, http://overpass-api.de/achavi/?changeset=33430646
[3] #33481709, http://overpass-api.de/achavi/?changeset=33481709
[4] relation/4084314

Ich weiss noch nicht, was ich von einem `name`-Tag bei Hydranten halten soll - einerseits koennte man den in diesem Changeset vergebenen Wert aus den anderen Tags automatisch eindeutig herleiten, andererseits sehe ich den Nutzen noch nicht. Da ich selbst auch schon ein paar Hydranten erfasst habe (vermutlich sind einige, die seit diesem Changeset ein `name`-Tag haben, urspruenglich von mir, inklusive den mittlerweile wohl eher veralteten `amenity=fire_hydrant`-Tags ;)), wuerde mich der Grund, wieso du `name`-Tags hinzufuegst, schon noch interessieren.