Vorschlag : Pilotprojekt für eine übertragbare Modellierung von Klinik- und Campusgeländen
Die Arbeitsgruppe (aus Interessierten innerhalb wie ausserhalb des OSM Forums) entwickelt eine nachvollziehbare und möglichst übertragbare Vorgehensweise zur Abbildung der Uniklinik Tübingen in OpenStreetMap. Dabei sollen insbesondere die Beziehungen zwischen Campus, Gebäuden, Gebäudeteilen, Ebenen, Einrichtungen, Abteilungen und Stationen klar beschrieben werden.
Die derzeitige Dokumentation reicht für diese komplexen Strukturen nur teilweise aus. Dadurch entstehen unterschiedliche Interpretationen und uneinheitliche Erfassungen. Zusammengehörige Objekte und Hierarchien sind für Menschen oft nur schwer nachvollziehbar und für Maschinen nicht zuverlässig auswertbar.
Ziel ist deshalb eine abgestimmte, strukturierte und maschinenlesbare Modellierung. Die Arbeitsgruppe soll offene Fragen sammeln, verschiedene Ansätze vergleichen, konkrete Beispiele an der Uniklinik Tübingen untersuchen und daraus dokumentierte Empfehlungen entwickeln. Diese Empfehlungen sollen nach Möglichkeit auch auf andere Klinik- und Campusgelände übertragbar sein.
Ich finde es bemerkenswert, dass die bisherigen Rückmeldungen sich nicht etwa mit dem Inhalt beschäftigen (habe das mit der Arbeitsgruppe präzisiert), sondern mehr mit dem Profilnamen bzw -bild (oder “Grußformeln”). Seit 2021 hat sich scheinbar nicht viel getan zu dem Thema, wurde aber immerhin “wiedererweckt” Krankenhaus: Abteilungen als Punkt oder als Fläche? - #8 by seichter
In einem Beitrag von 2021 wurde ein Teilaspekt “Krankenhaus: Abteilungen als Punkt oder als Fläche ?” angefragt, dort gibt es inzwischen auch eine Meinung zu "die Strukturen sollten wir m.E. durchaus grob abbilden können, also dass es Unis gibt […], die Campusse haben die zur selben Uni gehören, Institute, Fachbereiche, Kliniken (o.ä.), Mensen, Verwaltung, Bibliotheken, Wäschereien, Kraftwerke, Rechenzentren, Hörsäle, Labors Krankenhaus: Abteilungen als Punkt oder als Fläche? - #7 by dieterdreist
Anmerkung : für die Nutzung der Daten kann es viele Anlässe geben und so ein Campus/Krankenhausgelände ist oft recht gross. Für die Uniklinik Tübingen könnte man sich zur Übersicht an den Abteilungen orientieren (nicht 1:1 die Struktur übernehmen) https://medizin-uni-tuebingen.catchup-apps.com. Dann stellt sich die Frage, ob und wie die in Site-Relationen integriert werden (wie viele “Schachtelungs-Ebenen”). Zu berücksichtigen wäre evtl. noch, was “micro-mapper” indoor dazu beitragen (zumindest Stockwerke) Simple Indoor Tagging - OpenStreetMap Wiki. Die Uni selbst listet sogar Wasserspender
Nichts für ungut, aber bevor wir uns mit dem Inhalt auseinandersetzen, wäre eine kurze aber eindeutige Antwort (Ja/Nein) auf die bisher ignorierte Frage
durchaus angebracht.
Es deutet nämlich erstaunlich viel genau darauf hin.
ob site-Relationen verwendet werden oder Nodes, Polygone oder Multipolygone, richtet sich m.E. danach, welche Geometrietypen eingebunden werden sollen, und ob alles innerhalb eines Polygons dazugehört oder nicht. Die einfachste Abbildung sollte jeweils bevorzugt werden.
Absolut. Aber wie viele “Schichten” ? In TÜ wäre schon mal Uni, darunter 2 (Klinik-) campus, darunter zum Teil Gebäudekomplexe als relation (innerhalb des campus). Eine weitere Ebene fände ich zu viel, zumindest zum “manuellen mappen” (in ID oder einer app). Sofern die Ebenen in einem anderen editor besser dargestellt werden, wären “Gelegenheits-mapper” relativ ausgeschlossen*. Ausser natürlich jemand baut extra eine app dafür in der Art Beitragen mit dem Smartphone — OpenStreetMap Deutschland.
Soll heissen : ich fände eine Gebäude- oder campus- interne Abbildung über “gehört zu”=XY besser. Das bekommt jeder hin und eine app kann das interpretieren. Stockwerk, Fachrichtung dazu angeben und fertig ? (“Chirurgie” oder “Kardiologie” könnte auch über mehrere Flächen verteilt sein, insofern eine “Geometrie”. Aber hätte eine Relation da einen Nutzwert ?)
(*) Bsp. eine Unterabteilung zieht um und ein Mitarbeiter möchte das Aktualisieren, ist aber mit relationen nicht vertraut. Eine Fläche oder einen Punkt bekommt er hin und den (zu definierenden) tag, wozu das gehört.
Also unterhalb eines Gebäudekomplexes parent_id=(welchen unique identifier, department-id ?)
Hospital campus
└── Site / campus
├── Building
│ ├── Floor
│ │ ├── Zone
│ │ │ ├── Department
│ │ │ │ ├── Unit
│ │ │ │ └── Room
│ │ │ └── Service area
│ │ └── Circulation area
│ └── Entrance
├── External department building
├── Helipad
└── Parking area
So etwas wie “gehört.zu”, nämlich is_in hat es für hierarchisch gegliederte Objekte in anderem Zusammenhang schon mal gegeben. Das hat sich nicht bewährt und ist inzwischen deprecated.
Eine Zusammengehörigkeit aus Tags zusammenzusuchen ist viel mühsamer als auf die Mitglieder einer Relation zuzugreifen.
Eine Zuordnung per Tags ist auch nicht ganz trivial, am Beispiel des Medizin-Campus in Tübingen auf dem Schnarrenberg: Es gibt da die Crona-Kliniken, die Universitätsklinik, die Medizinische Klinik, die Radioonkologie, die Radiologische Universitätsklinik, das Zentrum für Gesundheitsfachberufe, die Blutspendezentrale, das Hertie-Institut für klinische Hirnforschung, das Gästehaus und vieles mehr. So ein Sammelsurium dürfte auch an anderen Stellen nicht außergewöhnlich sein.
so kompliziert ist es nicht, auf dem Schnarrenberg gibt es einen Teil des Universitätsklinikums, und der besteht aus CRONA und Medizinischer Klinik. Für Gästehäuser haben wir tags, für Forschungsinstitute auch. Dazu kommen die Kliniken im Tal. Das ist alles Teil der Uni. Wenn es Standorte gibt wie hier, mit Namen und klaren Grenzen, dann braucht man eigentlich nur einen tag “Unistandort” der nicht gleich eine komplette Uni bedeutet, und damit könnte man ein Polygon um den Bereich taggen, ist auch im Prinzip schon so umgesetzt gewesen als ich das letzte mal draufgesehen habe, nur waren die tags nicht ganz klar.
Innerhalb der Standorte (oder auch unabhängig, z.B. alte Aula) kann man Teile davon taggen, Hautklinik, Augenklinik, Frauenklinik, HNO, etc.
und innerhalb dessen kann man ggf. und nach Bedarf weitere Unterteilungen machen. Dafür gibt es noch nicht so klare tags glaube ich.
Die Frage, wenn man es so implizit über Polygone machen will, ist, was man mit Dingen macht die drin liegen aber nicht dazugehören. Kann man die dann ausschließen? Angenommenen sie sind in 2 von 4 Stockwerken, dann geht Multipolygon eher nicht, oder kann man damit einzelne Stockwerke ausschneiden? Was bedeutet “level” auf inner members, gar nichts?
