POI -- ein paar Unklarheiten

Ich bin zur Zeit in zwei Industriegebieten unterwegs, um dort nicht nur die Gebäude, sondern auch deren Inhalt zu erfassen. Da tun sich dann gleich ein paar Fragen auf.

Zu folgendem habe ich mich bereits entschlossen:

  • Gebäude zeichne ich als Building-Polygone.

  • Eingänge (oft mehrere an einem Gebäude) erfasse ich als Nodes mit building=entrance.

  • Jeder Entrance-Node bekommt eine Hausnummer via addr:housenumber.

  • Für jede Straße gibt es eine Relation vom Typ associatedStreet. Mitglieder sind die Straße (Rolle street) und die Entrance-Nodes (Rolle house). Die Relation steuert die anderen addr:* Attribute bei.

Soweit, so gut.

Doch wie füge ich hier nun die in den Gebäuden ansässigen Unternehmen ein? Ein Unternehmen hat ja i.d.R. mehrere Attribute: Name, Webpräsenz, Telefon, Fax, …

Da die Unternehmensdaten eine explizite Verbindung zu den Adressdaten haben sollten, kommt dafür eigentlich nur der Entrance-Node in Frage. Der Unternehmensname wird via name=, die Webpräsenz mit website= und der Rest der Kontaktdaten mit contact:= eingefügt. Das geht aber schief, wenn mehrere Unternehmen mit einer Hausnummer verbunden sind. Was dann? Streng genommen fehlt hier noch eine Relation, die POI mit einer Adresse verknüpft.

Also könnte man auf die Idee kommen, für jedes Unternehmen einen Node irgendwo im Inneren des Gebäude-Polygons zu plazieren, der die Unternehmensattribute trägt. Damit erkennt man die Beziehung zum Gebäude aber nur noch an der geometrischen Lage. Die explizite Verbindung zum Entrance-Node und weiter zur ganzen Adresse fehlt. Die Adressdaten komplett und redundant an jedem POI zu erfassen, lehne ich vom Datenmodell her so stark ab, daß ich es nicht machen werde :slight_smile: Also bliebe mir hier höchstens, solche POI ohne Adressbezug zu erzeugen… Da wir schon bei POI sind: es gibt amenities, offices, shops und crafts. Doch alles das will in den Industriegebieten nicht passen. Hier fehlt mir noch mindestens ein Schlüssel, oder gibt es da schon was? Oder entfällt so ein Schlüssel hier aus besonderem Grund?

Dann stellt sich da auch die Frage nach der Darstellung in Karten. Ja, ich weiß, wir… Trotzdem: Wenn ein Unternehmen in einem Gebäude sitzt, macht es Sinn, diesen Namen in der Karte darzustellen. Bei mehreren Unternehmen in einem Gebäude macht es keinen Sinn mehr, da die Namenszüge sich oft so sehr überlappen, daß man nichts mehr lesen kann. Hier wäre es durchaus sinnvoll, sich auf einen Namen zu beschränken. Manchmal gibt es vielleicht ein besonderes Unternehmen, das man auszeichnen könnte[1]. Es gibt aber auch viele Fälle, in denen das Gebäude einen eigenen Namen hat, z.B. XYZ Business Center o.ä. Hier könnte man vielleicht den Namen des Business Centers in der Karte darstellen und würde den aller Unternehmen unterdrücken. Gibt es dazu ein erprobtes Vorgehen?

[1] Beispiel: Ein Unternehmen hat seinen Namen in riesen großen Lettern oben am oder auf dem Gebäude so angebracht, daß man ihn (und eben nur ihn) schon von weitem sieht. Nachts ist er sogar erleuchtet. Genau diesen Namen aus einer Menge von zehn oder zwanzig Unternehmem im Gebäude auszuzeichnen macht durchaus Sinn, da es die Orientierung erleichtern kann. Dazu bräuchte ein Renderer aber einen Hinweis.

Du hast ja schon viele Möglichkeiten durch diskutiert.

Ich habe davon gehört, das für Sendemasten schonmal mehrere Nodes auf der gleichen Stelle gelegt werden, um mehrere operatoren abzubilden. Beim ersten überlegen, fand ich das eine interessante Art “MultiValues” abzubilden.
Beim Zweiten mal kam es mir nicht mehr ganz so komisch vor.

Damit könntest du auf einen Entrance mehrere Unternehmen legen.

Das Rendering Problem löst das nicht, aber “Wir Mappen ja nicht…”

ich vergass “… für die Renderer”

Wäre das Gebäude mit einer Hausnummer getaggt, würde ich diese Variante befürworten: POI liegt innerhalb des Gebäudeumrisses und braucht selbst nicht mehr notwendigerweise eine Kopie der Adressinformation. Die Beziehung über die geometrische Lage ist in einer Geodatenbank m.E. nämlich völlig ausreichend. Die Semantik, dass eine Hausnummer an einem Gebäude sich an alle Eingänge und enthaltenen POI überträgt, die nicht selbst eine Hausnummer haben, halte ich für klar nachvollziehbar.

Bei Gebäuden mit mehreren Hausnummern (in meinen Augen der einzige Fall, in dem es nötig ist, eine Hausnummer an einzelne Eingänge zu taggen) ist das natürlich nicht mehr so einfach. Da bleibt wohl wenig anderes übrig, als die einzelnen Eingänge und POI noch mal mit Hausnummerninformation zu versehen.

Von anderen Konstrukten - etwa davon, POI auf den Eingang zu legen - halte ich wenig. Die Einschränkungen dadurch mögen bei deinem konkreten Beispiel nicht offensichtlich sein. Wenn man sich aber z.B. ein öffentlich zugängliches Einkaufszentrum vorstellt, wären in der Vollausbaustufe eigentlich auch noch level-Tags oder sogar Polygone für die POI interessant, um Stockwerkspläne erstellen zu können. Mit der Lösung, POI ins Innere des Gebäudeumrisses zu setzen, ist das absolut kompatibel, mit Ideen wie “MultiValues” hingegen nicht.

Da gibt es auch andere Meinungen. Lulu-Ann http://wiki.openstreetmap.org/w/images/f/f8/Housenumbers.pdf verstehe ich so, daß sie an jedem Building-Polygon ein Entrance-Node möchte. Vielleicht ist das für Blinde besser. Vielleicht verstehe ich sie aber auch falsch.

Manche Gebäude im Industriegebiet sind auch so groß, daß mir so ein Entrance-Node durchaus sinnvoll erscheint, auch wenn das Gebäude nur einen (hausnummerntragenden) Eingang hat. – Jedenfalls viel sinnvoller als so manch andere Dinge, die in OSM erfaßt werden.

Alle POI mit redundanten Informationen zu versehen halte ich für schlecht (das werde ich auch nicht machen, eher lasse ich sie weg). Was spricht dagegen, hier eine Relation (associatedPOI) zu verwenden, die den Entrance-Node (Rolle entrance) mit den zugeordneten POI (Rolle poi) verbindet? Die Relation würde dann addr:housenumber tragen. Man würde diese Relation auch nur dann verwenden, wenn es notwendig ist. Wahrscheinlich sollte diese Relation dann Teil der Relation associatedStreet sein – wegen der Plazierung des Attributes addr:housenumber. Wahlweise könnte man dieses Attribut auch am Entrance-Node belassen. Dann wäre nur dieser Teil der associatedStreet.

Ich auch.

Ihre Meinung ist mir bekannt, ich habe mit ihr auch schon mehrfach über das Thema diskutiert (z.B. hier im Wiki). Leider hat sie sich dann aus der Diskussion zurückgezogen und ihre unveränderte Meinung in Form der obigen Folien veröffentlicht. Ich nehme ihr ehrlich gesagt ein wenig krumm, dass sie die Vortragsfolien zwar im Wesentlichen aus sinngemäßen Ausschnitten der im Rahmen unserer Diskussion entstandenen Tabelle erstellt hat, aber die dritte Spalte nicht berücksichtigt hat. So vergleicht sie nur die beiden Extrempositionen, nämlich “Adressen immer am Gebäude” oder “Adressen immer am Eingang”, und ignoriert die von mir bevorzugte Variante: “Adresse am Gebäude, wenn sie in der Realität für das ganze Gebäude gilt; Adresse am Eingang, wenn die Eingänge in der Realität ihre eigenen Adressen haben”.

Zur Klarstellung: Auch ich möchte idealerweise an jedem Building-Polygon einen Entrance-Node (building=entrance, platziert im Gebäudeumriss). Ich finde eben nur nicht, dass die Adresse des Gebäudes zwangsläufig immer an diesen Node gehört.

Blinde (und nicht nur die) wollen zum Eingang geroutet werden. Soweit stimmt das völlig, und deshalb bin ich auch für die Erfassung von Hauseingängen.

Aber: Nur weil bei der Eingabe der Hausnummern zum Eingang geroutet werden soll, muss noch lange nicht die Adresse am Eingang getaggt werden. Ein klitzekleines bisschen Intelligenz in der Software würde völlig ausreichen, um auch bei Adressen, die an einem Gebäudeumriss stehen, zum Eingang zu routen. Da ein Node im Gebäudeumriss (anders als einer im Gebäudeinneren) sogar direkt referenziert wird, ist das wirklich keine große Herausforderung.

Ganz einfach: Wenn es nicht notwendig ist, eine Relation zu verwenden, ist es notwendig, keine Relation zu verwenden. :wink:

Man kann über diese Lösung durchaus nachdenken, wenn es mehrere Eingänge gibt und bestimmte POI nur über bestimmte Eingänge zu erreichen sind - dann aber auch ganz unabhängig vom Thema Adressen.

Schade, da nicht im korrekten Zusammenhang zitiert. Der erste Satz meines Abschnitts fehlt, und der sagt genau, daß ich eine Relation associatedPOI auch nur für den Fall in Erwägung gezogen habe, in dem sie notwendig ist. Das wird auch danach noch einmal wiederholt.

Dann habe ich den Satz falsch interpretiert: “Alle POI mit redundanten Informationen versehen” könnte man ja z.B. auch, indem man die einzige Adresse des Hauses an alle POI und Eingänge kopiert. In diesem Fall nämlich halte ich weder von mehreren Kopien der Tags, noch von Relationen etwas. Aber jetzt weiß ich ja, wie es gemeint war.

Ich selbst würde hinsichtlich der Adresse aber wohl meist zu “redundantem” Tagging greifen, wenn ich die Adresse nicht gebäudeweit vergeben kann. Anders als bei Adressen für komplette Häuser existiert bei einer gemeinsamen Adresse für eine Teilmenge der POI und Eingänge nicht schon ein Gesamtobjekt, an das man die Adressinformation sinnvoll hängen könnte. Eine Relation, die keinem anderen Zweck als der Aufnahme der Adressinformation dient, würde ich nicht anlegen.
Da du associatedStreet-Relationen verwenden willst (und angesichts deines Eingangsposts), scheinst du das aber anders zu sehen, denn auch bei associatedStreet wird ja Redundanz mit einer extra für diesen Zweck angelegten Relation bekämpft. Ich hingegen sehe kein grundsätzliches Problem in “Redundanz”, d.h. dem Setzen eines Attributs für jedes Objekt, auf das es zutrifft. Wohl aber sehe ich eine Gefahr im übermäßigen Gebrauch von Relationen.

Eine Relation für die von einem Eingang erreichbaren Objekte im Gebäudeinneren fände ich ganz allgemein allerdings brauchbar. Den Namen “associatedPOI” halte ich spontan nicht für ideal, da etwa der Begriff “POI” im OSM-Tagging eigentlich bisher nicht verwendet wird (und wegen der Einschränkung auf Punkte auch irreführend ist).

Hat eigentlich schon einmal jemand darüber nachgedacht, wie man die Vorschläge hier umsetzt, wenn man z.B. ein Einkaufszentrum mit Eingängen von mehreren Straßen und zig Shops auf mehreren Ebenen hat, wozu dann noch ein Mitarbeiter-Zugang oder ein Zugang zu der Verwaltung kommt. Anlieferung und Entsorgung machen die Sache noch komplizierter. Und wenn wir dann noch die verschiedenen möglichen Beziehungen zu den Shops usw. in Relationen packen…

Große Bahnhöfe stellen ein ähnliches Problem dar.

Ich fürchte, wenn wir das alles abbilden wollen, müssen wir uns zuerst mindestens Gedanken machen, wie wir building=entrance als Schema weiterentwickeln.

Du hast voll uns ganz recht!

Nur in OSM wird die Meinung vertreten das man nicht für die Nutzer mapt (Standartanwort: Wir mappen nicht für die Renderer).

Nur (und das freut mich ein wenig) kommen die Mapper selbst langsam in die Region wo sie selbst nicht mehr wissen was sie eigentlich wie und wo richtig reinstopfen sollen - für jeden furz ein neuen tag…
Wenn man sich hier die Diskussionen anschaut ist die Hälfte nur über dieses Problem.

Man sollte sie doch mal ein klares Konzept überlegen wie Strucktur der gemappen Infos aussehen sollte und diese dann auch durchgehent so halten…

quasilotte

  1. Danke für die Blumen :slight_smile:
  2. Meine Überlegungen zielten (noch) nicht auf’s rendern. Mir ging’s um datentechnisch umsetzbare Ansätze und die Grenzen unserer Möglichkeiten
  3. Wie so viele Diskussionen wird auch diese irgendwann im Sande verlaufen, ohne dass etwas verwertbares herauskommt. Die Grenzen des sinnvoll machbaren sind an einigen Stellen schon überschritten (Bäume im Wald…). Aber wie taggt man einen Furz? :slight_smile:
  4. Danke, dass auch du ein klares Konzept wünscht. dann fühle ich mich nicht mehr so allein zwischen all den “Hier kann-jeder-machen-was-er will”-Denkern. :roll_eyes:

Und jetzt macht mal weiter mit eurer Diskussion über die POI-Unklarheiten…
…den ich will diesen thread nicht kapern :stuck_out_tongue:

+7

Mit dem Vorschlag im Wiki, addr:housenumber “möglichst hoch” zu erfassen kann ich mich anfreunden.

Bleibt die Relation für Fälle in denen man sie braucht. Wenn ich Dich richtig verstanden habe, sollte diese Relation selbst keine Attribute (außer dem notwendigen type=associatedXYZ) tragen. addr:housenumber wäre in diesem Falle immer an einem Entrance-Node (in anderen Fällen wäre die Relation ja nicht notwendig).

Bleibt nur, einen Namen für das Kind zu finden. Mir fällt nichts besseres als associatedPOI ein. Es sollte ja schließlich ein Oberbegriff von shop, craft, office und amenity sein. Wenn jemand einen passenderen Namen findet, wäre das ok.

Wie würde es dann weitergehen? Sollte das dann irgendwo aufgeschrieben werden, z.B. als Ergänzung in der oben zitierten Diskussion? Ich würde es dann gleich verwenden, denn wo ich aktuell unterweg bin, gibt es Bedarf dafür.

Hallo zusammen,

finde diese Diskussion auch sehr interessant und wichtig. Habe in meinem Bekanntenkreis auch einen "nicht Sehenden ". Und daher merke ich das sie wirklich drauf angeswiesen sind sich zu den Eingängen der Gebäude navigieren zu lassen.

Eben anders als bei uns Sehenden Menschen.

Die ganzen Endgültigen Vorschläge müssten dann in ihrem Ergebnis als eine Art Anleitung zusammengefasst aufgelistet sein. Am besten so das sie jeder Neuling ( allerdings auch Erfahrene ) sofort anwenden kann.
Je eher je besser, weil man dann bei aktuellen Einträgen diese schon anwenden kann.

Wahnsinn, wenn ich bedenke wie sich unsere Karte täglich weiterentwickelt.
Ein großes Lob an alle die mitmachen. Mir machts Spaß.

Lieben Gruß Jürgen

Ist doch ganz einfach: man muß die Beziehung nur rumdrehen (analog zu associatedStreet) und die Relation associatedEntrance nennen. Eine Relation mit type=associatedEntrance hätte dann einen Node (building=entrance) als Mitglied in der Rolle entrance und andere Mitglieder. Die Rolle der anderen Mitglieder ist eigentlich egal, sofern nur verschieden von entrance. Man könnte hier also sogar mit mehreren Rollen arbeiten, wenn man Objekte in unterschiedlichen Rollen zu einem Eingang in Beziehung setzen will. Sofern keine weitere Unterscheidung für die anderen Mitglieder notwendig ist, würde eine Rolle object auch reichen. Ansonsten könnte man auch – als feinste Variante – für die anderen Mitglieder je nach Fall als Rolle shop, amenity, office, craft etc. verwenden. Das würde das Auswerten vermutlich etwas erleichtern. Ich tendiere eher zu der feinen Variante.

ist das mit den Rollen nicht eigentlich “doppelt gemoppelt”?
Was die einzelnen Objekte (hier POIs) sind, ist doch bereits beim Objekt getaggt.

Ich bin für den geradezu profanen Ansatz:
Eine Relation hat Member der verschiedensten Klassen (andernfalls wäre es ja eine verpönte Sammelrelation), die normalerweise keine Rolle benötigen.
Nur bei einigen Ausnahmen (z.B. Grenzen, Landuse, …) müssen Rollen verwendet werden, um deren Funktion innerhalb der Relation anzugeben.
(hier: alle Member sind ways, davon viele “outer” und einige “inner”)

Nochmal in anderen Worten: Eine Rolle sagt nicht, was das Objekt IST sondern was das Objekt DARSTELLT.

Gruss
Walter

Das Problem ist ein klarer Fall für eine Relation und die Passende gibt es auch schon längst:
http://wiki.openstreetmap.org/wiki/Relations/Proposed/Buildings

… und für die Leute die klare Regelungen haben wollen: Die lösen die technischen Probleme bei der Objektdarstellung auch nicht und sind damit überflüssiger Verwaltungsmehraufwand.
Die Leute die klare Regelungen haben wollen, sollen lieber versuchen eine möglichst gute Umsetzung ihrer Taggingprobleme zu finden und dann mit Begründung und sonstigen Erwägungen im Wiki dokumentieren. Man kann Leute auch mit Fakten vom Besseren überzeugen…
Für existierende technische Probleme siehe z.B. http://wiki.openstreetmap.org/wiki/API_v0.7#Way_to_get_orphaned_relations_and_represent_tree_style_information_more_properly

Ja, so herum finde ich es sinnvoller.

Ich bin jetzt nicht so davon überzeugt, die Keys der Mitglieder noch mal in die Rolle zu kopieren. Ich dachte, du magst keine Redundanz? :wink:

Diese Mitglieder würde ich einfach ohne Rolle hinzufügen.

Welches Problem? Das Problem, dass manche Objekte in einem Gebäude nur von manchen Eingängen des Gebäudes zugänglich sind, lässt sich nicht lösen, indem man alle Objekte und Eingänge in einem Gebäude in dieselbe Relation steckt.

Ich würde sogar noch weiter gehen: Building-Relationen sind immer überflüssig, da sich jede einzelne der Informationen, die diese Relation enthalten soll, schon aus dem Gebäudeumriss ergibt. Außer “label” - aber das ist ein Rendering-Hint und damit hier wirklich off-topic. Interessant sind die Fälle, in denen nicht alle Objekte in einem Gebäudeumriss über einen Kamm geschoren werden können - aber da bringt wie gesagt die Building-Relation nichts.

Ich kannte das bisher nicht, aber damit würde die Lösung des bevorstehenden Problems – bestimmte POI mit bestimmten Eingängen zu verbinden – etwas aufwändiger. Dafür ist die Lösung mächtiger. Man kann halt nicht alles haben, Ausdrucksstärke und Einfachheit…

Im vorstehenden Fall müßte man demnach für jeden Eingang zunächst eine Relation mit einem Mitglied in der Rolle entrance sowie Mitgliedern in der Rolle contains (für die POI) erzeugen. Dann müßte man diese Relationen zu einer weiteren Relation vom type=building zusammenfassen. Deren Mitglieder hätten dann (bis auf eine) ebenfalls die Rolle contains. Dazu käme in dieser Relation noch ein Mitglied in der Rolle outline. So verstehe ich den Text jedenfalls.

Relationen vom type=building gibt es auch schon 539 mal. Wow! :slight_smile:

Mir war nicht klar, daß eine Relation auch Mitglieder ohne Rolle haben darf. Wenn das erlaubt ist, dann kann man diese Mitglieder in der Tat ohne Rolle hinzufügen.

Ich denke doch, auf die von mir oben beschriebene Art und Weise, als Relationen in einer Relation. Man kann beides aber auch leicht verheiraten. Das führt zwar wieder mehr Möglichkeiten ein, dafür aber auch mehr Freiheiten.

Man verbinde Eingänge mit POI durch eine Relation vom type=associatedEntrance. Wenn man dann unbedingt noch eine Relation vom type=building will, kann man diese auch anlegen. Sie hätte dann z.B. ein Mitglied in der Rolle outline und mehrere Relationen vom type=associatedEntrance in der Rolle contains als Mitglieder.

Der Vorteil der weiteren Relation vom type=associatedEntrance wäre, daß man auf die Relation vom type=building verzichten kann. In diesem Fall wäre das Gebäude als Polygon mit Attribut building=* zu erfassen. Man hat aber auch die Möglichkeit, das Gebäude als Relation darzustellen. Der Vorschlag Gebäuderelation ist damit vereinbar. Zudem macht die weitere Relation vom type=associatedEntrance die Verwendung der Relation vom type=building nicht komplizierter, sondern klarer.