Mehrere Arztpraxen in einem Gebäude - wie am sinnvollsten erfassen?

Hallo,
aktuell gibt es in meiner Gegend einiges an Änderungen bzgl. Arztpraxen und medizinischen Versorgungsmöglichkeiten durch Umstrukturierungen. Diese Daten möchte ich gerne aktuell halten, habe dazu aber eine Frage:

Wie sollte man es am sinnvollsten erfassen wenn es in einem Gebäude mehrere Arztpraxen (auf unterschiedlichen Stockwerken) sowie Apotheke, Sanitätshaus und weiteres gibt ?

Bei der Apotheke und dem Sanitätshaus ist das recht einfach, da diese jeweils eigene Eingänge haben. Dort einfach einen Punkt setzen und entsprechend kennzeichnen. Aber wie sollte man das bei den Arztpraxen umsetzen, die alle durch einen Eingang erreicht werden ? Alle Ärzte einzeln aufführen ? Es gibt dort unterschiedliche Fachrichtungen.

Zudem ist das ganze zwar ein Gebäude, hat aber mehrere Hausnummern für die jeweiligen Bereiche. Eine allgemeine offizielle Bezeichnung wie Ärztehaus etc. gibt es für das Gebäude nicht.

Jede Arztpreis einzeln als Node. Das Stockwerk mit level=0/1/2... angeben.

Der Haupteingang bekommt im Gebäudeumriss einen Node mit eintrance=main.

Jeder Bereich (die einzelnen Nodes) bekommen dann ihre addr:housenumber.

building=civic würde ich verwenden.

6 Likes

Moin!

Ich würde da tatsächlich mindestens jede Arztpraxis einzeln erfassen, jeweils mit level=* für das Stockwerk. Je nach Komplexität nutze ich auch manchmal Healthcare 2.0 und mappe jeden Arzt einzeln. Dazu erfasse ich in beiden Fällen pro Arzt/pro Praxis einen Node im Gebäude.

Was Hausnummern angeht, kann man diese am Eingang selbst erfassen, falls keine Hausnummer auf das gesamte Gebäude zutrifft. Zusätzlich dann an den POIs der Arztpraxen Straße und Hausnummer erfassen, weil die ja nicht aus dem umliegenden Gebäude abgeleitet werden kann. Meines Wissens geht es nicht besser, auch wenn ich mir oft wünsche, dass es eine einfache Möglichkeit gäbe, POI und Eingang zu verknüpfen.

4 Likes

Danke für die Tipps. Dann werde ich die einzelnen Praxen einfügen, so wie sie auch auf dem Infoschild am Eingang aufgeführt sind.

Einen Haupteingang gibt es dort so nicht. Es gibt drei Eingänge (1x Apotheke, 1x Sanitätshaus, und einen Eingang zu den Arztpraxen). Dazu kommt: Apotheke und Ärzte haben die identische Hausnummer, nur eben auf zwei Eingänge verteilt. Die einzelnen Eingänge werde ich ebenfalls hinzufügen, da aktuell nicht vorhanden.

Bei den Eingängen kannst Du mit description noch eine kurze Info hinzufügen wie z.B. “Eingang Arztpraxen”, “Eingang Apotheke" usw.

Wie ich gestern erst gesehen habe, gibt es auch ein nicht approvetes, aber trotzdem benutztes, Relationsschema porovides_feature, mit dem man Eingänge, Ausgänge und Parkplätze einem oder mehreren POIs zuweisen kann. Wird sicher von niemandem unterstützt, aber die Idee ist nicht schlecht für POIs die als Node erfasst sind. Gibt dann nur Probleme mit dem Parkplatz, wenn die POIs in unterschiedlichen Gebäuden sich denselben Parkplatz teilen, aber nicht dieselbe Eingangstür. Dann braucht man mehrere Relationen :roll_eyes:
Update: und fast alle Verwendungen sind in Brüssel. Oha.

Apotheke und Sanitätshaus könnte man auch vereinfacht direkt auf dem EingangPOI erfassen. Lässt sich drüber Diskutieren, aber dafür weis man sofort, welcher Eingang dafür da ist bzw. wo man hinmuss für die.

EDIT: OSM_RogerWilco hat recht mit dem, was er schreibt. Wobei ich selbst ‘Entfernung vom Eingang’ für irrelevant halt - wenn der Eingang NUR für diesen speziellen POI ist. Aber wie gesagt, lieber zwei unterschiedliche Objekte mappen :slight_smile:

1 Like

Das halte ich für keine gute Lösung. Wenn sich Eingang und POI auf untetschiedlichen Stockwerken befinden, der POI Ort weit vom Eingang entfernt ist oder es mehrere Eingänge für ein POI gibt, dann funktioniert das schon nicht mehr.

Außerdem sind POI und Eingang zwei unterschiedliche Objekte, die auch als zwei Objekte in OSM dargestellt werden sollten.

8 Likes

Hallo
+1

Gruß
Danfost

Ist nicht ganz klar ob sich @OSM_RogerWilco direkt darauf bezog, aber Apotheke und Sanitätshaus haben eigene Eingänge und ich verstehe es so, dass diese sich auch im Erdgeschoss befinden. Also nichts mit “unterschiedlichen Stockwerken”, “weit weg vom Eingang” oder “mehrere Eingänge für ein POI”, sondern eineindeutig zuordenbar: ein Objekt = ein Eingang = ein POI
Insofern halte ich den Vorschlag von @Negreheb für zulässig, nicht allgemein, sondern für den hier diskutierten speziellen Fall Apotheke und Sanitätshaus. Dann kann der Router auch direkt zum richtigen Eingang schicken, und zwar KISS.
Für die Arztpraxen, die offensichtlich in den Etagen über Apotheke und Sanitätshaus liegen und über einen dritten Eingang erreichbar sind, gilt dies natürlich nicht.

2 Likes

Nein, allgemein. Ich persönlich würde grundsätzlich diese Erfassungsmethode aus o.g. Gründen nicht anwenden.

Dito. Ich finde, dass POI-Daten komplett getrennt von allen anderen Daten abgelegt werden sollten. POI und Gebäude sich denselben Weg teilen lassen würde ich genauso wenig machen, wie POI und Eingang auf denselben Node legen. Ich weiß, dass es da viele unterschiedliche Meinungen gibt, aber für mich sind Gebäude, Eingang und POI getrennte Dinge und sollten getrennt abgelegt werden.

4 Likes

ich halte nichts davon, die Daten des Eingangs mit denen des POIs zu vermischen, das sind unterschiedliche Objekte und sie haben unterschiedliche Eigenschaften, von der Adresse abgesehen. Mir würde es reichen, wenn der POI diesselbe Adresse wie seine Eingänge hat (ggf. also auch mehrere, das entscheidet der POI, kommt hierzulande jedenfalls oft vor, dass mehrere Hausnummern für einen POI angegeben sind), dann kann man an den weiteren Daten sehen, ob es sich um einen Eingang handelt (Navigationsziel) oder eine POI-Adresse. Eingang kann auch barrier=gate bedeuten, bzw. barrier=entrance.

Nun, wie ist dann aufzulösen, wenn es mehrere Eingänge mit der gleichen Adresse gibt, aber nur einer der Eingänge zu dem Poi mit ebenfalls der gleichen Adresse führt?

das provides_feature ist zwar nett, aber nicht KISS.

Genausowenig, wie wenn es mehrere Eingänge zum selben POI gibt: Vor Ort Augen aufmachen, oder alle POIs als Flächen mappen und Indoor-Tagging. Oder eben doch mit Relationen arbeiten.

1 Like

Nun, wie ist dann aufzulösen, wenn es mehrere Eingänge mit der gleichen Adresse gibt, aber nur einer der Eingänge zu dem Poi mit ebenfalls der gleichen Adresse führt?

das habe ich noch nie erlebt. Wie machen sie es denn ohne OpenStreetMap?

Ein Gebäude, eine Hausnummer, mehrere POIs im Gebäude alle mit eigenem Eingang. Alle POIs haben die selbe Adresse. Ist jetzt nicht so ungewöhnlich.

Beispiel: Way: 201641118 | OpenStreetMap

(Allerdings ohne gemappte Eingänge).

Bleibt die Frage, wie man POIs sinnvoll einem Eingang zuordnet. So wie ich das sehe, gibt es mehrere Probleme und Ansätze. Zum einen mappen wir POIs in der Regel am ehesten dort, wo sie sind, nicht wo man sie betritt. Von dieser Norm kann man aber abweichen, wenn es sich z.B. um ein Geschäft mit einem einzelnen, separaten Eingang für selbiges handelt. In diesem Fall ziehe ich gerne den POI nahe an den Eingang heran. Wenn jemand auf die Karte schaut, wird er oder sie die Zuordnung wohl machen können:

Die Königslösung wäre in diesem Fall allerdings, die POIs als Fläche zu erfassen, denn dadurch läge der Eingang an der Kante der Fläche und der Zusammenhang wäre eindeutig. So wie hier (linkes der drei Geschäfte steht leer):

Leider ist es gerade in Innenstädten nicht immer möglich, die Ausdehnung eines Geschäftes zu erahnen, aber mit Mut zur Lücke wäre das für die meisten Geschäfte im Erdgeschoss machbar. Nachteil des Erfassens als Fläche ist, dass man den POI schlecht „umziehen“ kann, wenn das Geschäft umzieht. Vorteil ist, dass das Nachfolgegeschäft sofort schon eine Flächengeometrie hat. Auch funktioniert dieser Ansatz gut für Kaufhäuser mit mehreren Ein- und Ausgängen, weil sie eindeutig dem Geschäft zugeordnet werden können.

Das ganze Konzept funktioniert nicht mehr identisch, sobald man es mit einer Tür zu einem Treppenhaus zu tun hat, was gerade in Arztpraxen häufig vorkommt, weil man dann korrekterweise Indoor-Tagging bräuchte, um die Verbindung des Gebäudeeingangs zur Wohnung/zum Geschäft herzustellen. Ein Beispiel für unvollständiges Tagging dieser Art:

Es sind zwei Arztpraxen (links Zahnarzt, rechts Hausarzt) nebeneinander jeweils als Fläche erfasst, ich habe den Zahnarzt mal rot umrandet. Die Pfeile zeigen jeweils auf Eingänge. Der Eingang zum Gebäude hat eine explizit erfasste Hausnummer, weil sich das Gebäude nicht aufteilen lässt (auch nicht nach Rückfrage mit dem Bauträger, das ist eigentlich durchgehend). Was fehlt, wäre also eine Verbindung vom Gebäudeeingang zum Praxiseingang. Da es sich allerdings um ein 4+2-stöckiges Haus handelt, und ich das Indoor-Tagging als extrem fiddlig und ungenau empfinde, habe ich das bisher nicht getan.

Wenn ich mich recht entsinne, ist der letzte Fall genau das, was vom TO geschildert wurde. Mittlerweile tendiere ich dazu, zu sagen: Relationen zu erstellen, die Eingang, Parkplatz und POI verbinden ist für den Ottonormalmapper weitaus einfacher, als ein Treppenhaus mit Indoormapping zu erfassen. Vor allem, weil es dann auch ohne Betreten des Gebäudes oder gar der Geschäftsräume geht. Und dann noch erfassen zu können, welcher Parkplatz (oder auch welche Parkplätze) zu einem Geschäft gehören, ist eigentlich auch praktisch, weil sich dann auch klärt, was access=customer bedeutet.

Ich möchte diese (leider sehr lange) Antwort übrigens wirklich als Antwort auf die ursprüngliche Frage verstanden wissen: am sinnvollsten ist es, die einzelnen Praxen als Fläche, jeweils mit level=* zu erfassen und über Indoor-Tagging dann die Eingänge der Praxen mit dem, oder den Gebäudeeingängen zu verbinden. Die eigentliche Frage ist also, ob es eine akzeptierte „Abkürzung gibt“

Wie seht Ihr das: sollte man so eine Relationslösung vielleicht ein wenig mehr pushen und das ursprüngliche Proposal aufhübschen, oder befürchtet Ihr, dass dann bald jedes Geschäft eine eigene Relation bekommt, bzw. haltet Ihr grundsätzlich von so einer Lösung, bzw. „Abkürzung“ nichts?

1 Like

Ich finde eine Relation auch einfacher als ein vollständiges Indoor-Mapping. Sowohl in der Erfassung als auch bei der Auswertung, wenn es darum geht die richtigen Eingänge zu einem POI zu finden.

Was genau meinst Du mit “Abkürzung”?

Die Lösung mit den Relationen oder das Indoormapping bilden die Sache wohl genauer ab.
Ich sehe da aber das Problem der Wartung. Hier in der Gegend gibt es ein großes Einkaufszentrum mit U-Bahnstation, mehrstöckigem Parkhaus, Läden und vielen Ärzten. Das alles befindet sich auf 6 oder mehr Ebenen und es gibt auch einige Korridore.
Ich habe meine OSM-Aktivitäten damit begonnen, fehlende Läden als POI zu ergänzen, Öffnungszeiten einzutragen usw.
(Derzeit grübele ich darüber, wo in dem Komplex Layer / Level 0 ist…)

Wenn ich da auf ein System mit Relationen oä. gestoßen wäre, dann hätte ich sicher größere Verheerungen angerichtet - oder gleich wieder mit dem Mappen aufgehört.

1 Like