Moin!
Laterne mit Mülleimer dran:
amenity=waste_basket
highway=street_lamp
bin=yes
highway=street_lamp
?
Öfter in Benutzung ist die Kombination mit amenity=waste_basket, aber fühlt sich irgendwie falsch an. Oder gibt es einen besseren Ansatz? Ach ja, Osmose jammert bei amenity=*+ highway=* auch, aber das wäre mir egal, wenn das alle als korrekt ansehen.
Ich bin da seit einiger Zeit dazu übergegangen, einfach zwei Nodes an der gleichen Stelle zu machen. Über kurz oder lang wird das Mischen von Dingen an einem OSM-Objekt immer nervig oder problematisch und da kann man ganz einfach vorgreifen.
Ja, JOSM jammert dann, daß da zwei Nodes an der gleichen Stelle sind. Aber da sind dann halt eine Straßenlaterne und ein Mülleimer (und ein Wegweiser und ein Hydrantenschild, …) an der gleichen Stelle.
Ich selber tagge solche Objekte mit bin=yes (auch Sitzbänke z.B.), weil ich 2 (oder mehr) aufeinanderliegende Nodes nicht für eine besonders elegante Lösung halte. Aber korrekterweise muss man schon sagen, dass der Eimer und die Laterne 2 unterschiedliche Objekte sind, die auch separat gemappt werden können.
Die datentechnisch ideale Darstellung ist m.E. ein Node mit highway=street_lamp und ein zweiter Node ein paar cm daneben mit amenity=waste_basket + support=street_lamp.
Resultat in OSM2World:
…ist mein Favorit.
…und wenn du einen Wegweiser hast (=ein vertikaler Pfahl=Rohr), der:
…alles zugleich?
Ich hab Bilder, die drei der vier Kriterien erfüllen… Es kann sein, daß ich auch eines mit mehr oder anderen Kriterien habe… Willst du dann für alles einen eigenen Punkt setzen? Das gibt Chaos Pur! Das geht datentechnisch besser…!
Sven
Um beide Objekte sauber zu erfassen setzte ich immer zwei Nodes.
Analog zu Bushaltestellen, beschreibt ein bin/shelter/bench=yes nicht das entsprechende Objekt, sondern ist nur ein Hinweis darauf, dass es diese Objekte dort gibt. Mehr nicht.
Geschmacksache. Nur die Lösung mit 2 Nodes an identischer Stelle gefällt mir nicht.
Wie einige schon geschrieben haben: Zwei Nodes, da zwei Objekte mit total unterschiedlichen Eigenschaften. Den Mülleimer verschiebe ich immer ein kleines Stück in die Richtung, in die er von der Laterne aus schaut. Siehe Antwort von @Tordanik: mit support=street_lamp am Mülleimer wird die Verbundenheit deutlich und darstellbar.
Wichtig ist das, da Eigenschaften wie Höhe, Farbe, operator etc. unterschiedlich sind (und es für viele Auswertungen generell einfacher ist, wenn jedes Objekt durch eine eigene Geometrie repräsentiert wird).
Verschiedene QA progs werden Klagen ueber uebereinander liegende nodes ohne verbindung.
edit:typo
Die datentechnisch ideale Darstellung ist m.E. ein Node mit
highway=street_lampund ein zweiter Node ein paar cm daneben mitamenity=waste_basket + support=street_lamp
es gibt auch die node-Relation wo man den waste_basket als Relation taggen würde mit „attached“ Rolle an der Streetlamp
Ich habe nichts davon geschrieben die Punkte übereinander zu legen. Der Mülleimer befindet sich auch leicht versetzt. Aber selbst wenn: Die Warnungen von QA-Tools sind auch nur Hinweise. Wir mappen nicht für irgendwelche QA-Tools.
Gerade in dem von Sven geschilderten Fall, wenn sich sogar drei bis vier unterschiedliche Objekte an einem Pfosten befinden, halte ich das Erfassen in getrennten Punkten für übersicherlicher und leichter auszuwerten als bei dem Erfassen in einem Punkt.
Wenn alles in einem Punkt erfasst wird, halte ich es für schwierig, bei den einzelnen Attributen nachvollziehen, zu welchem der Objekte es gehört.
Die Punkte würde ich aber auch nicht direkt übereinander sondern nur sehr nah nebeneinander erfassen.
Ich weiß, dass es momentan nicht anders geht, aber das Erfassen eines Wegweisers mit 4-5 Schildern als 4-5 „ganz nah beieinanderliegenden Punkten“ ist doch nun wirklich nicht besser, als sie aufeinander zu legen. In beiden Fällen kann es sein, dass man die Existenz schier übersieht.
Da wäre die Node-Relation durchaus eleganter und wartbarer. Ist nur die Frage, ob damit überhaupt ein Auswerter umgehen kann oder will. Aber eine nette Idee ist es 
Näh… das mache nicht, das kann ich mit meinem Gewissen, auch von datensparendem Arbeiten nicht vereinbaren. Es ist ein Punkt = Pfostenrohr, der sich mir in der Landschaft repräsentiert, mit mehreren Funktionen.
ref:hiking → Nummerierung für Wanderwegsbeschilderung
ref:bicycle → Nummerierung für Radwegsbeschilderung
ref:emergency → wäre der sinnvolle Platz für die Rettungspunktnummer…
Es ist ein Punkt = Pfostenrohr, der sich mir in der Landschaft repräsentiert, mit mehreren Funktionen.
als ob wir Pfosten mappen würden. Wenn unter einem Briefkasten ein Mülleimer mit Aschenbecher am selben Pfosten hängt dann ist das für dich ein Objekt?
Ja, Ein Pfosten, ein Objekt…
anderenfalls wäre sowas, die der Knotenpunkt 2 mindestens 4, eigentlich 5 Punkte:
Der Widersproch der sich dann ergeben würde: Karte und Radwegbeschilderung stehen in einem direkten Zusammenhang und sind voneinander inhaltlich abhängig.
5 Punke!!! Das ist übersichtlicher? Näh… nicht mit mir… Entschuldigung, aber da kann ich nicht aus meiner Haut!
Die Tagging-Möglichkeiten geben es her, daß alles an einem Punkt zu erfassen, dann mach ich es auch…
Ja, Ein Pfosten, ein Objekt…
für mich ist das keine tragfähige Interpretation, wenn man den Pfosten überhaupt erwähnen will dann sähe ich 3 Objekte: Mülleimer, Briefkasten, Pfosten.
Dass an einem Pfosten mehrere Dinge hängen können halte ich für unzweifelhaft. Genauso wie an einer Garderobe mehrere Kleidungsstücke hängen können und die dann nicht zum selben einzigen Kleidungsstück werden weil sie an derselben Garderobe hängen
Momentan ist es so erfasst:
bicycle=yes
emergency=access_point
highway=emergency_access_point
hiking=yes
information=guidepost
operator=Landkreis Oberspreewald-Lausitz
ref=D3
tourism=information
Ich halte Relationen in Fällen wie diesen für die einfachere Lösung, wenn ich die ganzen Wegweiser erfassen wollte. Für jeden Wegweiser eine destination_sign-Relation, und ob man jetzt highway=emergency_access_point und information=guidepost an denselben Knoten, n 2 Knoten, oder in eine Node-Relation packt, hängt ein wenig von der Situation ab.
Warum? Worauf bezieht sich ref=D3, auf den Sammelpunkt oder den Guidepost? Und bicycle=yes heißt was? Sammelpunkt für Fahrradfahrer? Guidepost für Radwege? Finde ich nicht eindeutig, ich müsste da jetzt erstmal im Wiki nachschauen. Wären es Objekte, die ich als Weg erfasse, würde ich auch entweder 2 separate Wege mit den jeweiligen Tags erfassne, oder eben mit einer Relation. Alles an einen Punkt erscheint mir doch nicht so sauber wie anfangs. Aber bei mir gings ja nur um Mülleimer an Laterne, das ist ein sehr häufiger Fall.
…ja! Schau mal in die Historie…
https://www.openstreetmap.org/node/2792915415/history
die für mich ideale Variante war ref:access_point=D3, eben dann als Unterscheidung zu eventuell anderen auftretenden refs.
highway=emergency_access_point war und ist für mich genereller Nonsens…
emergency=access_point reicht! Wenn alleinstehend mit ref, wenn als Sekundäreigenschaft wie hier mit ref:access_point. Aber @DD1GJ sah das damals anders…
Wenn ich in die History schauen muss, worauf sich das ref=* bezieht, ist doch was im Argen 
Ja, man könnte ref:access_point=D3 machen, oder eben gleich zwei getrennte Objekte - ob als Nodes oder Relation. Und dann wohl guidepost:bicycle=yes? Oder eher information:bicycle=yes? Ach ja, hiking=yes ist ja auch da. Also wäre das finale tagging in etwa so:
access_point:ref=D3
emergency=access_point
guidepost:bicycle=yes
guidepost:hiking=yes
information=guidepost
operator=Landkreis Oberspreewald-Lausitz
tourism=information
Und den Operator vermutlich auch prefixen. Worauf ich hinaus will: auswerten wird das keiner, es ist ja auch nirgendwo definiert, wie jeweils zu prefixen ist. Na ja, jeder mappt anders und jeder wertet anders aus. Ich persönlich finde, hier sind zu viele Dinge vermischt, die man besser sauber trennen sollte.