HUHU
Welches Anzeigeproblem in Osmand? Online sowie in der App alles gut!
http://osmand.net/go?lat=50.822056&lon=6.984279&z=19
Schöne Grüße
Meik
Sorry, laut dem Wiki gehört dort kein building-tag hin, weder auf der Parking-Seite noch auf der building-Seite steht etwas dazu. id, also der Editor von openstreetmap.org setzt ebenfalls kein building. Abgesehen davon zeigt die Slippy Map, also die „offizielle“ Karte von OSM, die Parkhäuser nur richtig gelb an, wenn kein building-Tag gesetzt ist. Wegen dieser ganzen Fakten ist es für mich ganz klar, dass der building-Tag falsch ist. Sollte das nicht so sein, müsste man es erstens im Wiki ändern, zweitens müsste es damit auf der offiziellen Slippy Map richtig dargestellt werden und der OSM-Editor müsste ihn auch setzen. Ich kann keinen Hinweis darauf erkennen, dass der building-tag dort richtig ist, sondern das Gegenteil. Daher meine Korrekur.
Würdest du dann bei tourism=hotel auch das building=hotel entfernen?
PS: Ähm, ich habe mir gerade mal das von Nakaner bezogene Changeset angesehen und frage mich eher was anderes: Also wenn es ein Gebäude ist, müsste dann der Rheinparkweg nicht “gecovered” sein? Wäre es eventuell nicht sinniger amenity=parking_entrance zu setzen?
…mit tunnel=building_passage 
und die history weist aus: der Weg war bereits mal tunnel=yes vor Jahren
Ein Gebäude, ist ein Gebäude, ist ein Gebäude, ist ein Gebäude…
Du blendest mit deiner Sichtweise** das Objekt** in Zusammenhang mit der Nutzung aus. Egal wie die Nutzung ist, es ist schlicht und ergreifend erst mal ein Gebäude, das sagt auch die Bezeichnung schon: ParkHAUS… Lediglich die Nutzung ist das Parken…
Hier das Parkhaus an der Merzedes-Benz-Arena in Berlin. Solange es steht, fahre ich mit dem Zug dran vorbei und empfand es immer als Gebäude:
… oder willst du etwa behaupten, daß die kein Gebäude ist: http://www.openstreetmap.org/#map=19/52.50725/13.44170&layers=N
Das Bild dazu, im Internet gefunden: http://www.fugensysteme.com/wp-content/uploads/2015/07/GBPHMBA_02.jpg
Sven
amenity=parking gibt allgemein an, dass da geparkt werden kann. Das kann wie z.B. bei amenity=school ein größeres Gelände mit mehreren Objekten sein. Am Umriss steht dann natürlich kein building-Tag.
Wenn es aber nur ein Gebäude als Einrichtung ist, steht sowohl amenity als auch building am Umriss (auch bei der Schule).
Ob ein Renderer oder ein Editor da eine Farbe setzt, ist keine Rechtfertigung für unzutreffendes Tagging.
Sowohl OSM-Carto (“slippy map”) als auch iD sind nur eine Möglichkeit unter mehreren und nicht die offizielle.
Vor allem iD wird von manchen kritisch gesehen, weil er Anfänger zu fehlerhaftem Tagging verführen kann.
Ich blende gar nichts aus. Auf der Slippy Map auf http://www.openstreetmap.org/ wurden Parkhäuser nicht als farbige Fläche wie im Wiki beschrieben angezeigt: Tagging: ein Node zeigt ein P-Schild an. Area wird als farbige Fläche mit einem P-Schild dargestellt. Da Mapnik die Slippy Map OHNE building=* die Parkhäuser farbig rendert, und nirgends steht, dass Parkhäuser mit building=* getaggt werden und ID keinen building-Tag setzt, habe ich den Tag entfernt. Dass etwas falsch getaggt wird, kommt ja oft vor, z.B. access=permissive auf Kundenparkplätzen von z.B. Edeka oder es werden Altglascontainer durchgehend mit recycling:glass anstatt recycling:glass_bottles getaggt.
OSM ist ein globales Projekt, wenn jeder so einträgt, wie er will, wird das nicht gut funktionieren. Die Tags müssen konsistent sein. Sich einfach überlegen, dass man etwas anders einträgt als andere, wird nur dazu führen, dass es nicht funktioniert. In diesem Fall dazu, dass Parkhäuser nicht so dargestellt werden wie vorgesehen und dass man sie dadurch schlecht auf der Slippy Map (und vielleicht anderen) erkennen kann.
Und genauso wie building=* area=yes impliziert, kann parking=multi-storey auch building=yes implizieren.
Im Wiki fehlt unter http://wiki.openstreetmap.org/wiki/DE:Tag:amenity%3Dparking die eindeutige Aussage, daß Parkhaus-Gebäude auch den Tag building bekommen sollten. Mir war das bei office=government damals auch nicht klar. Siehe https://forum.openstreetmap.org/viewtopic.php?id=53987 Ich halte eine entspr. Ergänzung bei amenity=parking für sinnvoll.
Grüße aus Oberschwaben
Peter
+1
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
https://de.wikipedia.org/wiki/Gebäude
https://de.wikipedia.org/wiki/Parkhaus
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.
Danke
geow
Das ist dann ja eine Sache der Renderer. OsmAnd~ für Android und iOS zeigt ein Symbol an, an dem man erkennen kann, dass es ein Parkhaus ist.
Hallo,
Nachdem Graf Westerholt aufgehört hat, building=* zu entfernen, habe ich meinen Sperrantrag zurückgezogen.
Viele Grüße
Michael
Hmm, und genau deswegen verstehe ich dich und deinen eigenen Widerspruch nicht, das dich dazu bewegt building zu entfernen…
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.
+1
Die von ihm bearbeiteten Buildings, die jetzt keine mehr sind, wurden übrigens von ihm nicht zurückgesetzt.
@nakaner: magst du einen revert machen? Mir fehlt momentan die zeit dazu.
Gruss
walter
Hallo Graf Westerholt, hallo Rest,
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.
Viele Grüße
Michael
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.
Allerdings ist der Weg dorthin fragwuerdig.
Das wär’ dann das beliebte tagging for rendering
Eine vernünftige OSM-App findet die Tennishalle anhand der Attribute, unabhängig davon wie das nun auf osm-carto dargestellt wird.
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:
http://wiki.openstreetmap.org/wiki/DE:Taggen_für_den_Renderer
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