Btw, mehrere Elemente Auswählen geht klassich mit Strg + linke Maustaste. Oder einfach nen Rahmen ziehen.
Wenn mehrere Elemente übereinander liegen, kannste mittels Alt + linke Maustaste zwischen den Elementen wechseln.
Wenn du level=* benutzt kannst du die Ebenen sogar in JOSM auswählen und einzeln bearbeiten. Lade dir das Gebäude einmal und schaue es an.
https://wiki.openstreetmap.org/wiki/DE:Key:level
Müsste auch für deine Altbauten passen.
Eindeutig ein Bedienfehler. Die Tasten S(elect) und A(dd) sind deine besten Freunde, von denen sich meine linke Hand beim Mappen nur sehr ungern trennt 
Gönn dir die Einarbeitung in JOSM. Es lohnt sich.
–ks
Sehr interessante Disskusion!
Ich würde da gerne auch meine 2 cents dazugeben.
Der Eingang eines Gebäudes kann ein Punkt des Gebäude-Ways sein, der entsprechend getaggt wird. Das ist eigentlich so üblich. Für POIs wäre das eher unpraktikabel ab einer bestimmten Menge an POIs, die sich alle neben dem Eingang reihen würden. Manchmal will man ja auch eine simple Art von Indoor-Mapping machen und die POIs entsprechend ihrer ungefähren Position im Gebäude setzen (z.B. in einem Einkaufszentrum).
Die Lösung per Relation finde ich persönlich sehr gut, schließlich besteht ja zwischen Gebäude und Geschäft eine “Beziehung” (Relation). Allerdings, soweit ich das bisher mitbekommen/gelesen habe, werden Relations versucht zu vermeiden, da man das ganze Datenmodell einfach halten möchte. Aber vom Prinzip wäre eine Relation wohl angemessen, um die Zuordnung für den User durch Vermeidung von Geocoding einfach zu halten.
Ich denke, da OSM ein Datenbank-Projekt ist, sollten auch die grundlegenden Datenbank-Regeln gelten, also Redundanz zu vermeiden. Redundanz bringt beim Bearbeiten (Edit) fast immer einen Aufwand mit sich, der höher ist als der Aufwand für’s Auslesen (Read). Für beides kann man Software nutzen, die den Aufwand verringert, aber Redundanz kann am Ende auch zu inhaltlichen Fehlern führen. Z.B. wenn ein POI mit Adresse verschoben wird, weil das Geschäft nach nebenan umgezogen ist und man vergisst die Adresse im POI zu ändern. Als einfaches Beispiel.
Redundanz hat imho nur selten eine Berechtigung in Datenbanken. Meistens geht es dann um Performance und führt zum Caching von Daten. Hier könnte man jetzt sagen, dass das Geocoding aufwändig ist. Nicht unbedingt für die Maschine, aber für den Menschen/User der nicht über die entsprechenden Kenntnisse oder Software verfügt. Da wäre die Lösung dann aber eine zweite Datenbank, wo ein Geocoding-Algorithmus die redundanten Daten erstellt und in die zweite Datenbank schreibt. Dann könnte man diese erweiterte Datenbank bequem nutzen und könnte sich sicher sein, dass z.B. bei der Adresszuteilung keine menschlichen Fehler im Spiel sind.
Eine andere Möglichkeit um eine einfache Zuordnung zu gewährleisten hat ja schon @NTGhost erwähnt, indem man Relations nutzt.
Ist ja das gleiche Redundanz-Thema nur eine Ebene höher. Allerdings sehe ich das hier ähnlich wie @R0bst3r, da Straßennamen, Postleitzzahlen oder Ortsnamen sich eher selten ändern im Gegensatz zu POIs, wo es im Grunde eine permanente Fluktuation gibt. Somit ist da auch die Gefahr von Fehlern sehr viel geringer.
Ich dachte, es soll nicht für den Renderer, das Navi oder ähnliches gemappt werden? Müsste das dann nicht auch für Unternehmen gelten?
Letztendlich geht es wohl nur um “Redundanzfrei + Geocoding” vs. “Redundant + Bequem”. Ich tendiere da auf jeden Fall zum ersteren, ist einfach sauberer und erheblich weniger fehleranfällig.
Hmm, ist jetzt doch mehr geworden, als beabsichtigt, aber egal. Ist ja schließlich ein echt interessantes Thema.
Sonniges Wochenende!
Offtopic:
Naja, ganz so einfach ist es nicht. Google crawlt die Seiten, bewertet sie mit einem Algorithmus und speichert lediglich die Meta-Daten. Außerdem ist die Datenbank von Google eine graphenbasierte Datenbank. Die funktioniert etwas anders. Google-Cache ist nochmal was anderes und hat mit der Suchdatenbank wenig zu tun.
Ja, deshalb muss ich regelmäßig bei Wikipedia zusätzlich oder gleich direkt die englische Version lesen, da dort meist mehr Informationen zu finden sind. 
Ich bin jetzt nicht so sehr mit Wikipedia vertraut, aber ich glaube den Ansatz gibt es bereits mit Wikidata als gemeinsame, sprachenübergreifende, maschinenlesbare Datenquelle. In den USA werden mittlerweile der Großteil der textlichen Sportnachrichten von Maschinen erstellt, da es oft nur um die Wiedergabe von statistischen Daten geht, die in nette Worte gehüllt werden. Wikipedia ist da in vielen Bereichen vergleichbar und ich sehe da auch die Richtung wo es hingeht. Eine Datenbasis und eine KI, die das in einen netten Text verpackt. Soll ja kein Bestseller-Roman werden. 
Ich sehe in Unternehmen einen Datennutzer (und im günstigen Fall einen Mapper). Und mir persönlich ist (aktuelle) Redundanz lieber als komplizierte (unaktuelle) Daten, die keiner nutzen/ändern will/kann. Nicht jeder Ferienhausanbieter oder Restaurantbetreiber oder Geschäftsinhaber will/kann sich erst in Relationen und Geocoding einarbeiten. Bei mir gibt es einige, denen das Ändern der Daten eines POI’s durch Nachricht oder Notes setzen lieber ist.
Wenn es zu kompliziert wird gehe ich zur Konkurrenz.
Ja natürlich, da gebe ich dir recht. Aber die Konkurrenz lässt ihre Kunden auch nicht an den Rohdaten “rumpfuschen”, sondern bietet Interfaces an, die es einem ermöglichen die notwendigen Informationen einzugeben, ohne das Datenmodell dahinter zu kennen. Den Ansatz gibt es ja mit iD, wenn man das mit JOSM vergleicht. Das Ziel sollte dann doch sein, die Bearbeitungssoftware zu verbessern und nicht das Datenmodell “aufzuweichen”.
Bei Google läuft sowas dann z.B. hiermit: https://support.google.com/business/answer/2911778?hl=de
Wenn ich also in diesem Fall Unternehmen dazu verleiten möchte ihr Geschäft einzutragen, sollte ich auch entsprechende Tools dafür anbieten. Das muss ja nichts aufwendiges sein. Da reicht im Grunde eine Formularseite, dessen Daten von einem Backend entsprechend der OSM-Richtlinien verarbeitet werden, ohne dass der Unternehmer etwas von diesen Richtlinien mitbekommt. Für den zählt nur das Ergebnis beim Renderer.
Ja, interessantes Thema.
Könntest Du mir mal ein bis zwei Smartphone-Apps (und auch weitere generelle OSM-Software) nennen , die Deine präferierte Variante “Redundanzfrei + Geocoding” bereits umsetzen und danach auswerten?
Danke & schöne Grüsse
Ganz spontan fällt mir da Nominatim ein. Macht im Prinzip nur das: Geocoding mit dem Ziel Bequemlichkeit.
OsmAnd. Bei POIs ohne Adressdaten wird die Adresse des umgebenden Gebäudes angezeigt.
Funktioniert aber nur, wenn man sehr einfache Verhältnisse unterstellt.
Hier hat das Gebäude (Mercado) fünf Adressen: https://www.openstreetmap.org/#map=18/49.46956/11.10190
Der CityPoint hat midestens vier: https://www.openstreetmap.org/#map=19/49.44959/11.07717
Und in Italien versagt der Ansatz komplett… (OSM iat ein weltweites Projekt).
Beim vorschlagenen Datenmodell mit Relationen: Beim POI verschieben merken die meisten gar nicht, dass man da auch noch den POI aus der “Adressrelation” herauslösen müsste und in eine andere einpflegen. Das fürht zu Fehlern. Nicht die Redundanz.
Nicht ohne Grund ist der Ansatz mit https://wiki.openstreetmap.org/wiki/DE:Relation:associatedStreet praktisch gescheitert.
Ich habe diese Thema ja angestoßen um ein besseres Verständnis der Problematik zu bekommen und muss sagen: Jup das hat geholfen. Gerade in Bezug auf Harburg stehe ich nämlich diesbezüglich vor so einigen Problemen
Nach einigem hinundher und selber mal mit relationen arbeiten muss ich sagen…sorry, aber Geocoding it is.
Der Aufwand relationen zu erstellen/ändern und wieder zu lösen steht in keinem Verhältnis zum nutzen zumal es mit besagtem Geocoding bereits eine automatisierte Lösung dafür gibt.
Für Routen ist das erstellen von Relationen leider zwingend und auch wenn ich das System verstanden habe muss ich sagen “das geht einfacher” JSOM und wahrscheinlich viele andere Programme machen es einem dort unnötig schwer. Eine einfache Route zu erstellen und per drag und drop zu justieren und das dann als “Wanderroute St Jacobi” abzuspeichern wäre die bessere Lösung.
Redunanz:
Gerade bei Gebäuden wie der Haspa am “Sand 1” ist die scheinbare Redundanz “Sand 1” notwendig um die automatische Assoziation “Schloßmühlendamm 9”, die geographisch richtig wäre, gar nicht erst aufkommen zu lassen bzw. zu unterdrücken.
Und es gibt von solchen Auswüchsen WEIT mehr als man annehmen mag. Gerade der einwurf von pyram mit “Italien” und Adress mapping lässt mich grinsen…Rom…2000 Jahre bautechnischer F*** ** unzählige Kriege und ein Bauwildwuchs…Harburg ist mit seiner wirklich “winzigen” Altstadt und max 400 Jahren gar nichts im Verhältnis zu diesen Monster der Antike. und selbst hier hab ich noch Monate an Arbeit vor mir wenn ich auch “nur” die Geschäftsadressen alle eintragen will die ich aus dem “Kopf” kenne. Und um mal so eine Hausnummer zu haben wovon ich hier rede: in Harburg sind geschätzt nur 40% aller Geschäftsadressen überhaupt eingetragen.
Man kann hier also sehr schön sehen wie Relationen TROTZ “Richtigkeit” von der praktikabeleren Lösung “Geocoding+ein wenig redunanz” evolutionär verdrängt wird. Unterstützt durch immer höhere Rechnleistung der Computer verliert das Argument “Benötigt höhere Rechenleistung” immer mehr an Gewicht. Wie auch bei anderen Fällen der Informatik. Thema Assembler und Hochsprachen/Bibliotheken. Die immer weiter wachsende Rechenleistung macht eine “richtige” Herangehensweise immer ineffizienter und langsamer und damit leider obsolet.
Ich finde es witzig wie man an diesem Thema, das eigentlich gar nichts mit Evolution zu tun hat, sieht, wie diese funktioniert.
Die “richtige” Methode wird durch die “einfache” aber ebenso funktionierende ersetzt. Natur ist halt faul.
Ich für meinen Teil werde deswegen anfangen Gebäude mit Straße und Hausnummer zu versehen um keine Fragen aufkommen zu lassen.
Die POIs werden dann von mir im Gebäude plaziert, mit Webseite. Ohne Adresse. Relationen werde ich nur anwenden wenn zwingend notwendig um die Daten für zukünftige mapper einfacher zu halten, so das wenn wer die Sachen aktualisieren will, sich nicht auch noch mit Relationen herumgeschlagen muss. Von der bereits erwähnten geringeren Fehleranfälligkeit mal ganz zu schweigen.
Die Idee dahinter ist einfach:
Was Physikalisch fixiert ist bekommt die volle Ladung daten. Was beweglich ist nur das notwendigste.
Das heißt Häuser bekommen von mir eine volle Adresse. Ebenso werde ich versuchen diese Häuser als Gebäudeflächen in ihrer form akkurat abzubilden, ich habe festgestellt das dies nicht zwingend mit den Bildmaterial übereinstimmen muss. Viele der Luftaufnahmen sind in einem ziemlichen Winkel aufgenommen worden.
POIs werden dann ohne Adresse in der Nähe ihres jeweiligen eingangs platziert sollte im Gebäude kein Durchgang zu einem anderen Eingang existieren wird das von mir durch Linien in der Gebäudefläche selber kenntlich gemacht.
Damit sollte auch den Nutzer der Daten klar sein das man dort hin nicht durchkommt und er einmal außen drumherum laufen muss.
Ich hätte nicht gedacht das ich mal meine Meinung komplett ändern würde aber war ich vorher noch auf der Seite “Relationen” muss ich nach einigen arbeiten sagen das Geocoding tatsächlich die praktikablere Lösung ist. Wenn man sich hier an ein paar Grundregeln hält ist eine weit besseres und fehlerfreies Ergebnis die Folge. Das mag zwar nicht schlanker und damit “schöner” sein, ist aber für den menschlichen Anwender besser zu verstehen und leichter zu handhaben.
Und da du vor Ort bist - level=* - an den POI’s nicht vergessen. dann kann man auch schon sehen bis in welche Etage man “laufen” muss.
https://wiki.openstreetmap.org/wiki/Key:level
(Wogegen ich noch dafür plädiere, die POI’s mit Adresse zu versehen, dann lassen sie sich auch “ganz einfach” auswerten. Eine Angabe des Node und alles ist enthalten. Es gab einmal eine OpenPoiMap, die war für viele Keinstnutzer ideal. Ich nutze für solche Kleinstanwendungen uMap.)
Natürlich kann auch die Redundanz zu Fehlern führen, wie ich ja im von dir zitierten Beispiel erklärt habe. Am Ende führt aber beides zu Fehlern, wenn vergessen wird, die “Verbindung” (Relation oder redundante Adresse) zu editieren.
+1
Klar “level” ist selbstverständlich. wer einmal mit einer Palette in einem Einkaufszentrum rumirrte um festzustellen das der Laden wo er hin will 2 Stockwerke über ihm ist, der weiß das Stockwerksangaben nicht nur ein nettes Feature sind.
Bei “Adressen in POIs” war ich anfangs auch dafür, aber die Fehleranfälligkeit wenn wer vergiss das zu ändern beim Umzug ist eben auch gegeben. Deswegen “+ein wenig Redunanz” Adressen im Gebäude müssen reichen der Rest muss das Geocoding erledigen.
Ich werd übrigens die Save Funktion von JSOM ausgiebig nutzen und ein CS Upload in der mailing liste ankündigen. Nicht das mir die Hamburger mapper geschockt aufs Dach steigen wenn da aus dem Nichts CS mit 100+ Einträgen aufschlagen ^^
Dann ist es ein Fehler beim “Umzug” durch den Mapper. Man sollte beim Umzug alle Daten des POI’s überprüfen: Öffnungszeiten, Website, Telefon, Stockwerk, …
In der Theorie richtig…in der Theorie soll man auch blinken beim Spurwechsel…und letzteres ist weit gefährlicher wenn man es nicht tut…hält sich aber auch keiner dran.
Also besser von vornherein mit der Dummheit und Faulheit anderer Rechnen und so arbeiten das solche Fehler komplett vermieden wird.
Nun mal etwas anderes:
Ein POI ohne Adresse nach deiner Meinung, wird “ausversehen” ins Nachbargebäude mit Adresse verschoben. Also hat der POI eine neue Adresse. Hätte er eine richtige Adresse, würde der Fehler auffallen, entweder er wurde falsch verschoben oder die Adressfehler würden auffallen.
Du kannst solche Fehler nicht komplett vermeiden.
Hmmmm sehr gutes argument…damit…
man kann es aber versuchen zu minimieren. die Frage ist nur wo zieht man die linie?
Was anders, hab bisher nix dazu finden können: Wie stelle ich Gebäudeüberhänge dar?
Geht konkret um das hier:
Was für Schlüssel nehm ich für die aussenwände des Erdgeschosses?
—>