…
Dein Problem hat wenig bis nichts mit Multipolygonen (MP) zu tun (außer das ein Gebäude an sich ein MP erfordert). Es ist auch keine gute Idee, etwas bestehendes einfach umzudeuten. Das erschwert Auswertern das Leben ungemein.
Eine Relation vom Typ building ist genau das was du brauchst. Die ordnet einem Gebäude darin liegende Geschäfte und Eingänge zu. Ob deine Navi-Software solche Relationen auswertet, ist natürlich eine andere Frage. Mit zur Zeit ca. 4700 Verwendungen ist dieser Relationstyp noch nicht sehr verbreitet, insbesondere, da die auch noch in zwei verschiedenen Zusammenhängen (mit unterschiedlichen Rollen) verwendet wird.
Dennoch ist das der richtige Ansatz, wenn man Geschäfte und Eingänge (als Knoten) mit dem Gebäudeumriss in Beziehung setzen will. Dass JOSM noch keine Vorlage dafür hat solltest du dabei nicht überbewerten. Steigen erst mal die Verwendungen, werden die Auswerte-Programme (JOSM ist auch nur ein Programm, das die OSM-Daten interpretiert) schon nachziehen.
Wann Navi- / Such-Programme dann die Adress-Informationen vom Umriss oder einem Eingang auf die enthaltenen Geschäfte übertragen ist eine andere Frage, die wiederum von der Zahl der Verwendung beeinflusst wird.
Edbert (EvanE)
…
bin nur eingeschränkt online aber schau einmal unter Lübeck (Der Stadt) und dort unter dem Eintrag Hausnummern.
Jan
Multipolygone beschreiben bei OSM Flächen (inner) innerhalb anderer Flächen (outer). Wege, die keine Ringe bilden, haben darin nichts zu suchen. Punkte sollen nur mit der Rolle label oder admin_centre verwendet werden, auf keinen Fall mit einer Rolle inner.
Du willst mit deinen vorgeschlagenen Änderungen MP-Relationen in Richtung building-Relation erweitern. So eine massive Änderung wäre problematisch, da sich alle Auswerte-Programme daran anpassen müssten. Das ginge nur nach ausführlicher internationaler Diskussion.
Probiere mal die Adresse am Hausumriss zu belassen. Die Beziehung POI zu Adresse ist dann einerseits durch die building-Relation gegeben und andererseits durch die räumliche Anordnung (POI im Umriss). Die räumliche Anordnung ist bei Auswerte-Programmen eine bekannte Situation, von daher sollten das viele beherrschen.
Warum Nominatim deine Konstruktion nicht erkennt, kann viele Ursachen haben. Eine davon kann sein, dass eine building-Relation für Adressen nicht ausgewertet wird. Wie bereits geschrieben, lasse mal die Adresse am Gebäude-Umriss. Die Chance, dass Nominatim diese Konstruktion unabhängig von einer building-Relation (er)kennt und richtig auswertet ist mMn recht groß.
Edbert (EvanE)
Nur leider beherrscht Nominatim sie bis heute nicht, was ja auch oft genug kritisiert wurde. Deshalb klebe auch ich die Adresse zusätzlich an den POI, sonst steht im Suchresultat die falsche Adresse und das halte ich für noch schlimmer als doppelt sichtbare Hausnummern.
Vielleicht sollten wir besser mal anfangen, Patches an Nominatim zu schicken, anstatt mit Relationen zu arbeiten, die ein guter Auswerter gar nicht bräuchte. Vielleicht finde ich am Wochenende ja mal etwas Zeit, mir das Ding anzuschauen, bin allerdings kein Freund von Java :-\
Hallo zusammen,
darf ich hier nochmal einsteigen, da der Thread ein Problem betrachtet, das ich gerade auch sehe? Ich fange gerade an bei uns im Ort zu mappen mit dem ersten Ziel POIS und Hausnummern zu aktualisieren/vervollständigen.
Zur Zeit gibt’s hier ein Gemisch an Adressen, die als Punkt im Gebäude erfasst sind, oder direkt am Gebäude (teilweise auch mit den Daten des POI). Allerdings hakt mein Verständnis hier etwas. Für mich wäre es am logischsten dem Gebäude die Adresse zu verpassen, den POI als Punkt im Gebäude, der allerdings seine Adressdaten via Relation vom Gebäude bezieht.
Geht so was?
Gruß
Stephan
POIs in Gebäudeumrissen sind allgemeine Praxis.
Eigentlich könnte für diese die Adressinformation (ohne eine Relation oder Ahnliches) aus ihrer Lage im Gebäude berechnet werden.
Da allerdings viele Tools dies nicht machen (können), wird oftmals die Adressinfo nochmal an den POI geheftet.
Von der Verwendung einer Relation für diesen Zweck halte ich nichts!
Wenn ich nach einem Arzt (POI) suche, dann möchte ich dort die erforderlichen Informationen finden - die sollten Bestandteil der Daten sein.
Bei einer Suche nach einer Adresse sollte mir auch angezeigt werden, das unter dieser Adresse ein Wohnhaus mit Eingang, einem Geschäft und einem Arzt zu erreichen ist, wo ich wieder entscheiden kann.
Wenn nur nach “dem” Arzt gesucht wird , wird auch nur eine Adresse angezeigt.
Das mit Relationen usw. ist zwar für “Erfahrene” möglich - aber denkt doch an die “vielen” Interessenten, die nur ihr Geschäft eintragen möchten …
Relationen wären zwar der datentechnisch eleganteste Weg (redundanzfrei), stellen aber mMn für den Gelegenheitsmapper/-nutzer eine zu große Hemmschwelle dar.
Die Redundanz in POI und Gebäudeumriss sind dann das kleinere Übel.
POIs ohne Adressinformation können problematisch sein, da die einzige logische Verbindung “ist im Gebäude” durch Verschieben verloren gehen kann. Ich bin nicht selten auf POIs in verwinkelten Innenstädten gestoßen, die nach einer kleinen Gebäudekorrektur durch z.B. genauere Geometrie-Daten im Nachbarhaus oder auf der Straße zu liegen kamen.
Da ist man schon froh, wenn wenigstens Straße und Hausnummer im POI zu finden sind.
Eine Lösung, die den Relationen schon nahe kommt, ist, den POI auf den Hauseingang zu legen. Der ist dann auch automatisch mit dem Umriss verbunden. Bei Häusern mit mehreren Eingängen ist das fast Pflicht.
Das Dumme ist nur: Die Eingänge sind auf Luftbildern und Lageplänen oft nicht zu identifizieren und mit dem Mappen direkt vor Ort hapert es ein bisschen.
OK, danke für die Antworten. Das mit den Relationen erschien mir logisch (nachdem ich gerade meine erste Blitze mit relationen erfasst habe (püh)) … aber da hängt mein Herz nicht dran.
Ich kam sowieso nur auf das Thema, weil ich die doppelten Einträge beim Housenr. Validator dann als “Duplikat” sehe …
Aber wenn das so allgemein akzeptiert ist … irgorier ich das einfach mal 
Gruß
Stephan
Bitte nicht ignorieren → Fehlalarm melden, wenn es zutreffend ist. Dann wird es auch dort wieder “übersichtlicher”
ok – dann sag ich dem Validator daß er zwar doppelt sieht, aber alles gut ist …
Danke
Generell zu POIs: Wie füge ich denn zusätzliche Informationen hinzu? z.B.
Max Mustermann, Facharzt für Straßenheilkunde
name=“Max Mustermann”
note=“Facharzt für Straßenheilkunde” oder description=“Facharzt für Straßenheilkunde” oder ???
das gleiche bei Anwälten, Versicherungsvertretern usw. also
name=“Max Mustermann”
note=“Beste-Versicherung der Welt” oder description=“Beste-Versicherung der Welt” oder ???
Oder sollte man das gane als name machen
name=“Max Mustermann; Beste-Versicherung der Welt”
Danke
Benjilein
Alles, was sich erfassen lässt, erfasse ich so gut es geht. Im ersten Deiner Beispiele dann eben mit Healthcare 2.0, auch wenn manche damit nicht viel anfangen können. Alles, was ich nicht erfassen kann, packe ich an eine note=, wie z.B. note=“Blumenbeet zum Selberpflücken, bisher kein Tag gefunden”. note= wird nur Mappern angezeigt, description=* wird auch für Endbenutzer ausgewertet. “Beste Versicherung der Welt” hat in keinem der Tags etwas verloren, “note=Anwalt für Familienrecht” schon eher.
Ich wollte keinen Namen verwenden, daher habe ich statt einem “bekannten” Namen die Versicherung als “Beste Versicherung der Welt” bezeichnet, soll aber der Name der Versicherung darstellen, für welchen die Person arbeitet. 
D.h. es wäre dann geschickter genauere Bezeichnungen mit “description=” zu taggen, dass der Enduser dann, wenn er einen Anwalt/Arzt/Versicherungsmenschen sucht, auch weiß, dass es derjenige von dem Fachgebiet/o.ä. ist, was er sucht?
Bei Ärzten kann man Healthcare 2.0 taggen, bei Anwälten oder Versicherungs"menschen" würde ich das mit note=* oder descr=* machen, genau 
note=* → Die Notiz ist vor allem für Mapper und anderer Bearbeiter gedacht. Normale Karten zeigen die Notiz nicht an.
description=* → … eine ausführlichere Beschreibung für das Element (um dies z.B.) in einem Popup anzuzeigen. Der Text sollte kurz gehalten werden: einige wenige Wörter, oder ein bis maximal drei Sätze. Längere Informationen sollten per Referenz zu einer Webseite oder Wikipedia bereitgestellt werden.