es geht mir nicht um die Gebäude sondern um die Tankstelle, zuvor war die als Fläche abgebildet und jetzt als node. Das ist jetzt nicht super dramatisch, aber wohl auch keine Verbesserung
@ dieterdreist
Es gab da vor nicht allzu langer Zeit eine Diskussion über die Frage, ob die Attribute einer amenity, die ein ganzes Gebäude belegt (also z.B. Supermarkt), besser an das building getaggt werden oder besser an einen node, den man dort hinein setzt. Wenn ich mich richtig erinnere, waren viele Teilnehmer der Meinung, das letztere wäre die bessere Lösung (mich eingeschlossen), da building und amenity zwei unterschiedliche Objekte sind. Das gilt natürlich umso mehr, wenn sichin einem Gebäude mehr als eine amenity befinden, wie im Falle der hier bearbeiteten Tankstelle.
Von daher halte ich die von PT-53 jetzt realisierte Lösung durchaus für eine Verbesserung. Alternativ könnte man natürlich auch das gesamte Gelände als area mit amenity=fuel erfassen, aber einen Mehrwert kann ich darin nicht direkt erkennen. Wird im Wiki so auch nicht favorisiert. Oder hab ich da was übersehen?
es geht hier nicht mit dem Mischen von Gebäude und amenity weil es 2 Gebäude sind
Ok, verstehe ich das richtig, dass es Dir darum geht, dass man bei den beiden Gebäuden (1xbuilding=yes, 1x building=roof) jetzt an den tags nicht mehr erkennen kann, dass sie beide zu der Tankstelle gehören …?
genau, vorher wusste man dass beide Gebäude Teil der Tankstelle sind und jetzt weiß man nur noch dass es dort eine Tankstelle gibt.
Wie es zuvor war fand ich allerdings auch nicht gut, nicht dass ein falscher Eindruck entsteht 
Hmm, wenn man beide Gebäude der Tanke fix zuordnen will, wäre ein Multipolygon sachlich schon korrekt, oder …??.. eine site relation käme auf jeden Fall nach der Beschreibung im Wiki definitiv nicht in Frage.
Was wäre Deine Alternative? Beide Gebäude separat mappen (1xyes, 1xroof) und dann das ganze Gelände der Tankstelle als area erfassen und mit amenity=fuel taggen? Also analog der Erfassung von z.B. Schulgeländen mit mehreren Gebäuden drauf?
genau, s. #2
Tankstellengebäude sind sicherlich ein eigener Gebäudetyp, anstatt “yes” könnte man z.B. gas_station oder petrol_station verwenden, beides zwar noch gering genutzt, aber das liegt auch an den 80,6% yes.
Die letzten Beiträge haben nichts mehr mit dem Thread-Thema zu tun. Bitte diskutiert das in einem eigenen Thread.
Hallo PT-53, ich wollte Deinen Thread nicht missbrauchen, war der Meinung, dass meine Frage(n) an dieterdreist durchauch mit der von Dir eingang gestellten Frage
Tankstelle → MP entfernen → Daten auf Node übertragen oder eventuell site relation ?
in Zusammenhang stehen. Werde das hier nicht weiter vertiefen.
Mir ist übrigens aufgefallen, dass das Dach über den Zapfsäulen gemäß Luftbild eher nicht am Gebäude angesetzt ist, sondern frei steht und die Gebäudekante überdeckt (man kann deutlich den Schattenwurf auf dem Gebäudedach sehen) … nur zur Info.
+1
Ein MP ist immer eine Fläche und braucht nie ein area=yes!
+1, als Fläche. Ein MP bracht es dafür aber nicht.
Mmh, das “Ladengebäude” ist wohl eher retail. Was jetzt mögliche Werkstatt oder Waschanlagengebäude angeht, bin ich mir unsicher aber gas_station oder petrol_station sind die auch nicht. operator wäre noch ein möglicher Tag um die Zusammengehörigkeit zu verdeutlichen.
Eine Relation, die nur zwei Gebäude als Mitglieder hat, ist eigentlich nur formal eine Multipolygonrelation [*1], weil die beiden Gebäude halt Polygone sind. Genaugenommen ist es aber egal, ob die Relation Gebäude oder amenity-pois oder hw=service als Mitglieder hat, im Grunde ist dies nur eine Sammelrelation (gewesen): alles was zur Tanke gehört.
Und Sammelrelationen sind bäh! Die einfachste und sauberste Lösung ist in #2 beschrieben. Dafür brauchts keine Relation. Ich weine der gelöschten Relation keine Träne nach, ich hätte sie auch gelöscht.
*1 echte Multipolygonrelationen sind (abgesehen von denen mit Loch [*2]) doch die, wo mehrere lineare Objekte zusammengesetzt werden und erst durch das Zusammensetzen in einer Relation ein geschlossenes outer bilden und erst durch die Eigenschaften an der Relation zur Fläche werden.
*2 Da hatte ich doch letztens auch so eine Tankstellen-Relation, wo das outer eine hw=service-MP-Relation war, und die Gebäude als inner aus der Fläche ausgestanzt waren, damit die im carto-Rendering nicht von der hw=service-Fläche überdeckt werden brrrr!
Sorry, wenn Du mich so kurz und aus dem Zusammenhang gerissen zitierst, wird jede Antwort problematisch. Andere und auch ich haben doch schon geschrieben, dass wir hier keine Relation brauchen.
Die Beispiele und falschen Anwendungen ändern doch nichts daran: Eine Relation mit type=multipolygon ist eine Fläche. Punkt
Habe hier z.B. einen Sportplatz als “Käfig” mit einem geschlossenen Zaun exakt als Abgrenzung und nur einem Tor als Eingang. Für mich ist das dann ein barrier=fence als geschlossene Linie und ein MP leisure=pitch mit dem Zaun als einziges Mitglieder (outer).
Bei Deiner Tankstelle mit dem hw=service sollte die “outer” Linie die Tankstelle darstellen und das MP den hw=service, wobei ich bezweifel, dass die Umrisse hier exakt identisch sind und dass das Dach nicht in Teilen auch über den hw=service ragt.
Und? Ich habe nichts anderes behauptet.
Auch diesbezüglich habe ich nichts anderes behauptet. Allerdings ändert falsche Anwendung durchaus etwas dran. Ich wette, es war nicht Intention des Mappers, mit der Relation aus beiden Gebäuden die Fläche der Tankstelle zu definieren. Und wäre die Waschanlage und der Shop in die Relation aufgenommen worden, wäre es klar kein MP und klar eine Sammelrelation gewesen.
Auch das könnte man ganz ohne Relation lösen.
Nein, das MP ist nur durch das Ausstanzen der inner entstanden. Sowohl am outer als auch das MP selbst waren jeweils (sozusagen doppelt) mit hw=service getaggt. Sonst waren da keine Werte in Bezug auf die Tankstelle dran. Die Fläche sollte einfach die gepflasterte, befahrbare Fläche definieren. Ich kann mich nicht mehr genau erinnern, ob sogar bei diesem oder bei anderen ähnlichen Konstrukten sogar unnötigerweise am MP ein area=yes dranhing - auch da sind wir uns völlig einig, dass es da keins brauch.
Genau das war offensichtlich das Problem! In Realität ist das Dach über der hw=service - Fläche, in OSM-Carto ist die hw=service - Fläche über dem Dach. Damit man das Dach sieht macht man ein inner und damit ein MP und machts besonders falsch, weil dann in den Daten unterm Dach keine hw=service-Fläche mehr existiert.
im konkreten Fall habe ich die Tankstelle schon als Fläche eingezeichnet, allerdings hatte ich die Waschstraße als Teil davon gesehen, das wurde hier ja anders gesehen. Ganz in der Ecke stand noch ein Druckluftgerät, das ist jetzt auch mit drin, ob das zur Waschstraße gehört könnte man vor Ort auskundschaften
Warum auch einfach, wenns auch kompliziert geht ? 
Edit:
amenity=fuell wird weltweit aktuell an rd. 287000x Nodes verwendet und nur rd. 18100x auf Flächen.
weil sonst weder die Ausdehnung der Tankstelle klar wäre, noch z.B. die Zuordnung der Druckluft. Mit nodes für große Features verpasst man einen der Hauptvorteile einer Geodatenbank, nämlich die Struktur was innerhalb von was ist, und wie groß die Dinge sind, abzubilden. Das wird zwar akzeptiert als erste Näherung, aber der Rückschritt von bereits gemappter Fläche zu Punkt mit dem damit einhergehenden Datenverlust nicht
Ja das ist natürlich ein ganz enormer Datenverlust. Wenn ich jetzt nur wüßte, wer diese Flächen-Daten überhaupts braucht.
Edit:
Braucht es dafür wirklich ein MP ?
https://www.openstreetmap.org/relation/13875198/history
Gut, dass nicht jeder nach dieser Logik alles löscht, was er nicht versteht.
Das ist - leider - auch keine Antwort auf meine Frage.
andere Länder andere Sitten. Das könnte man auch durch gestapelte ways abbilden, aber die sind so schwer zu bearbeiten dass die Mapper hier Multipolygone bevorzugen.
Was man nicht machen sollte ist den Zaun mit demselben Objekt repräsentieren wie den Park.
Es gibt noch einen weiteren Grund. warum gestapelte ways teilweise Probleme machen, wenn auch AFAIK nicht beim Bearbeiten mit JOSM: wenn man nachträglich in solche Konstrukte weitere nodes einfügt werden die bei manchen Editoren nur in einen der ways eingefügt und man muss die dann ggf. danach noch weiterverbinden, was aber einige Mapper nicht machen. Im Ergebnis hat man dann ein paar der gates als Teil des fence (wo sie hingehören) und andere als Teil des Parks.