Lieber Graf Westerholt,
ein Parkhaus ist ein Gebäude im Sinne der Länderbauordnungen und sollte schon deshalb als building=yes erfasst werden. Zu den Definitionen im Einzelnen siehe
Auch im englischen OSM-Wiki besteht mit parking=multi-storey ->“Two or more levels of parking decks in a building structure.” eindeutig ein Bezug zu Gebäuden.
Sowohl in der Standardkarte (OSM-carto) als auch in OSMAnd wird ein P auf dem Gebäude gerendert, so dass es als Parkhaus erkennbar ist, z.B. http://www.openstreetmap.org/way/28128281
Damit ist klar, dass es sich nicht um einen offenen Parkplatz, sondern um eine Parkmöglichkeit innerhalb eines Gebäudes handelt. Bei deinen Tagging könnte man dies nicht mehr unterscheiden, da Parkhäuser und offene Parkflächen identisch gerendert werden.
Wir würden uns daher sehr freuen, wenn du angesichts der genannten Argumente deine Änderungen rückgängig machen würdest.
Dass es in OSM Inkonsistenzen und Unlogisches gibt, ist bekannt und bei einem globalen Community-Projekt wohl unvermeidlich.
Dass man anstreben sollte, das zu verringern, dürfte auch Konsens sein.
Das kann aber nicht im Alleingang geschehen, da es sehr wohl auch abweichende und begründete Meinungen geben kann (wie hier zu sehen).
Implizites Tagging sollte auf ein absolutes Minimum beschränkt werden, da das in allen abhängigen Anwendungen von Hand programmiert werden muss.
Da ist ein ggf. Nachjustieren der Darstellung beim Map-Renderer mMn das weitaus kleinere Übel.
Ja, ich kann den Revert machen. Da es sich in meinen Augen um einen Revert mit geringer Konfliktneigung handelt, du dich einsichtig gezeigt hast und die anderen Beiträge wertvolle, nicht automatische Korrekturen enthalten, möchte ich dir, Graf Westerholt, die Gelegenheit einräumen, Stopp zu rufen, falls ich doch zu viel revertieren sollte.
Anhand der Änderungssatzkommentare habe ich folgende Änderungssätze als diejenigen identifiziert, die ich zu revertieren gedenke:
45696511
45801140
45801162
45801754 bis 45802317
45802370 bis 45802561
45821412
45821781 bis 45821905
45821953 bis 45822095
45822178 bis 45822430
45824656
45825202
45830018 bis 45830430
Ich habe mir die Änderungssatzkommentar der letzten sieben Tage angesehen. Die Inhalte habe ich mir nur in Einzelfällen angesehen. Die Änderungssätze, die von Kommentar her nicht nach einer Entfernung building=* aussahen, aber zeitlich nahe an einem solchen lagen, habe ich stichprobenweise geprüft. Die Erkenntnis war, dass deine Änderungssatzkommentare stets aussagekräftig und korrekt waren. Vielen Dank! Da könnte sich manch anderer Mapper mal ein Vorbild nehmen.
Hm, auch mich ärgert es ganz massiv, das building=yes bei den allermeisten Renderen die wichtigere andere Information unterdrueckt. Typisches Beispiel von solchen Ärgernissen sind fuer mich neben den Parkhäusern auch Sporthallen wie Reit- oder Tennishallen (oder auch Multihallen) in denen korrekt die Spielfelder in dem Gebäudeteil in dem sie sich befinden gemappt wurden.
Den Grund, warum dann building=yes entfernt wird kann ich also mehr als gut nachvollziehen.
Das Ergebniss ist auch aus Nutzersicht sicherlich wuenschenswert - Gebäude gibt es ja viele und niemand fährt durch die Stadt um ein Gebäude zu suchen, sondern z.B. die Tennishalle.
Wie ich schon geschrieben habe, habe ich das buiding=* entfernt, weil alles (Wiki, Editor ID, Slippy Map) darauf hindeutete, dass es falsch ist. Wenn ein POI nicht richtig eingetragen ist, kann er vom Renderer möglicherweise nicht richtig eingetragen werden. Korrekte Eintragungen sind kein Fehler und „taggen für den Renderer“ ist etwas anderes als etwas korrekt einzutragen:
Natürlich muss man in dem Sinne für den Renderer taggen, dass man etwas korrekt einträgt, nur korrekte Einträge können korrekt dargestellt werden. Wenn jemanden einen Knoten mit amenity=parking und shop=supermarket und tourism=hotel einträgt, wird das schlecht darzustellen sein. Die Knoten aufzuteilen ist ja auch nicht „taggen für den Renderer“.
Genauso wie ich access=customers zu Kundenparkplätzen hinzufüge, auch damit es ggf. richtig von Mapnik gerendert wird, ist ja auch nicht falsch und auch nicht „taggen für den Renderer“. Und genauso wurden die Parkhäuser nicht parkplatzgelb angezeigt.
Und der Sinn einer Karte ist ja auch, dass man auf ihr wichtige Sachen sehen kann, deshalb werden Parkplätze ja auch Parkplatzgelb dargestellt. Wenn man immer mit einer Suchfunktion etwas anzeigen lassen müsste, ist das auch benutzerunfreundlich. Und dann wird ggf. eine andere Karte verwendet, wie in diesem Beitrag erwähnt: https://forum.openstreetmap.org/viewtopic.php?pid=630202#p630202
Die Karte auf openstreetmap.org ist nur eine von vielen Darstellungsmöglichkeiten des Datenbestandes. Sie kann nur einen Bruchteil der Informationen anzeigen und muss möglichst universell sein. Parkpkatzgelb sind nur die oberirdischen Parkplätze, wo sonst nichts ist. Bei Tiefgaragen wird auch nur ein leicht übersehbares P dargestellt, während z.B. der Park obendrauf in allen Details angezeigt wird. Karten mit einem Schwerpunkt für Autofahrer können natürlich alle Parkplätze deutlicher darstellen. Leider wurde parking.openstreetmap.de wohl eingestellt.
Apps, welche die Bildschirmanzeige und Routinginformationen aus Vektordaten berechnen, hätten da mehr Möglichkeiten. Daher wäre es wichtig, dass bei Tiefgaragen und Parkhäusern auch die Einfahrten korrekt getaggt sind, wenngleich sie auf der normalen Karte nicht angezeigt werden.
Noch eine Idee für einen möglichst schonenden Revert: Alle parking=multi-storey mit fehlendem Building-Tag selektieren, bei denen Graf Westerholt der letzte Bearbeiter war und das Building-Tag wieder setzen.
Da sind wir uns wohl alle einig. Aber jetzt machst du einen eigenartigen gedanklichen Sprung! Ich würde als nächsten logischen Schritt erwarten, dass ParkHÄUSER korrekterweise als Gebäude getaggt werden, einfach weil es welche sind. Du argumentierst, dass das Tagging aus dem Grund nicht richtig sein kann, dass sie dann nicht wie von dir erwartet dargestellt werden:
Du erwartest vom Renderer, alle Parkmöglichkeiten einschließlich Parkhäuser gelb darzustellen. Das ist weder richtig noch falsch, es ist eine Erwartung. Wenn der Renderer das aber derzeit bei Parkhäusern nicht macht (und ich stimme durchaus zu, dass „hier kann man parken“ eine interessantere Information ist als „hier steht ein Gebäude“), dann muss doch der Renderer angepasst werden, nicht das Tagging! Denn da steht eindeutig ein Gebäude, deshalb kann building=yes nicht falsch sein.
Ich lese die Karte übrigens anders als du. „Gelb“ heißt für mich nicht „Parkmöglichkeit allgemein“, sondern „ebenerdige Parkfläche, ansonsten unbebaut, hier steht nix“. Insofern führt mich dein Tagging ganz schön in die Irre, ich würde bei deinen Parkhäusern laut Karte eine beparkbare Baulücke erwarten.
Genauso geht es mir auch. Wenn ich eine gelbe Parkfläche sehe und dann feststelle, dass es sich vielmehr um ein Parkhaus handelt, ärgere ich mich und empfinde das als schlampig gemappt.
Genau.
P+gelbe Fläche = ParkPLATZ
P+Gebäudefarbe = ParkHAUS
Sieht durchaus absichtlich und sinnnig aus.
Bei einem ParkPLATZ wüsste man ohne farbige Fläche nämlich gar nicht, wie groß der ist.
Bei einem Parkhaus sieht man die Größe schon am Gebäude - und weiß auch gleich, das ist ein Haus.
Nicht die Tags oder das Rendern sind falsch, sondern die Erwartung.
Seit heute enthält das Wiki (de, en) auch klare Hinweise auf entsprechende building=* tags sowie eine nach heutigem Stand richtige Beschreibung, was der Standard-Layer daraus gerade zu machen beliebt.
Das wär’ dann das beliebte tagging for rendering