Re: [Talk-de] Gebäude, Grundstücke und Institutionen
On 29.09.2013 16:25, Eckhart Wörner wrote: Am Mittwoch, 11. September 2013, 18:53:39 schrieb Stephan Wolff: Das Institute und Fachkliniken in die OSM-Datenbank gehören, wird hoffentlich nicht bezweifelt. Ähm, doch? Was kommt als nächstes? Firmenstruktur der Deutschen Bank in OSM? Soweit die Firmenstruktur sich in getrennten Gebäuden niederschlägt, möchte ich doch sehr hoffen, dass sie in OSM wiedergegeben ist. Wenn ich eine Filiale der Deutschen Bank suche, wo ich z.B. ein Girokonto eröffnen kann, lege ich nämlich Wert darauf, dass ich sie von der Konzernzentrale oder irgendeiner Außenstelle der Innenrevision unterscheiden kann. Gruß, Mark ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude, Grundstücke und Institutionen
Am Mittwoch, 11. September 2013, 18:53:39 schrieb Stephan Wolff: > Das Institute und Fachkliniken in die OSM-Datenbank gehören, wird > hoffentlich nicht bezweifelt. Ähm, doch? Was kommt als nächstes? Firmenstruktur der Deutschen Bank in OSM? Eckhart ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude, Grundstücke und Institutionen
Am 11.09.2013 13:07, schrieb Martin Koppenhoefer: Am 11. September 2013 13:01 schrieb Stephan Wolff : Ich würde alle Teile nur der Universität zuordnen. Das passt zumindest zur deutschen Rechtslage, in der die Universität als ganzes eine rechtsfähige, juristische Person (meist eine Körperschaft des öffentlichen Rechts) ist. Die Untergliederungen würde ich nur als Punkt erfassen. ich finde, mindestens die Fachbereiche und evtl. auch die Institute können wir schon hinbekommen, und das sind auch eher stabilere und für die Orientierung äusserst wichtige Informationen, [] Ähnlich verhält es sich übrigens oft auch mit Krankenhäusern, insbesondere Unikliniken. In beiden Fällen sind für sinnvolles Routing genauere Informationen als nur: da ist das Universitätsklinikum XY nötig, vor allem, wenn es mehrere Standorte gibt. Eine Universität oder ein Uniklinikum lassen sich meist gut als Fläche definieren. Die einzelnen Institute und Fachkliniken sind aber oft so kleinteilig untereinander und mit Gemeinschaftsräumen vermischt, dass eine Flächenerfassung kaum möglich ist. Zudem gibt es oft mehrstöckige Gebäude mit unterschiedlicher Nutzung auf jeder Ebene. Das Institute und Fachkliniken in die OSM-Datenbank gehören, wird hoffentlich nicht bezweifelt. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude, Grundstücke und Institutionen
Am 11. September 2013 13:54 schrieb Martin Koppenhoefer < dieterdre...@gmail.com>: > Auf Institutsebene weiß ich von den Wirtschaftswissenschaften und der >> BWL, dass die deutlich verteilt sind über mehrere Gebäude. >> > > > -> site relation, evtl. muss man vielleicht doch auf Lehrstuhlebene gehen? > sorry, "Fachgebiet" wäre da wohl die nächste Stufe. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude, Grundstücke und Institutionen
Am 11. September 2013 13:44 schrieb Peter Wendorff < wendo...@uni-paderborn.de>: > Am 11.09.2013 13:07, schrieb Martin Koppenhoefer: > > ich finde, mindestens die Fachbereiche und evtl. auch die Institute > können > > wir schon hinbekommen, und das sind auch eher stabilere und für die > > Orientierung äusserst wichtige Informationen, Lehrstühle sind dagegen > > wirklich schon sehr detailiertes Micromapping. > Aber ist das geografisch eindeutig? > Beispiel hier in Paderborn: > Fakultäten: > - Kulturwissenschaften: Verteilt über den Hauptcampus auf mehrere > nicht-zusammenhängende Gebäude, dazu die Aussenstelle in Detmold > - Wirtschaftswissenschaften: Verteilt auf dem Campus, und Teile der > Wirtschaftsinformatik am Standort Fürstenallee > - Naturwissenschaften: verteilt auf dem Campus und Sportgelände > - Maschinenbau: das dürfte mit die kompakteste Fakultät sein > - E-technik, Informatik, Mathematik: Campus (weitgehend zusammenhängend) > + Fürstenallee > zugegeben, (mittlerweile) gibt es eher wenige und allgemeine Fakultäten, daher wäre Institutsebene wohl angebracht. > Auf Institutsebene weiß ich von den Wirtschaftswissenschaften und der > BWL, dass die deutlich verteilt sind über mehrere Gebäude. > -> site relation, evtl. muss man vielleicht doch auf Lehrstuhlebene gehen? > > Ähnlich verhält es sich übrigens oft auch mit Krankenhäusern, > insbesondere > > Unikliniken. In beiden Fällen sind für sinnvolles Routing genauere > > Informationen als nur: da ist das Universitätsklinikum XY nötig, vor > allem, > > wenn es mehrere Standorte gibt. > Oft reicht aber eben auch nicht "Fakultät Informatik", sondern "Büro von > Prof. Meier, Fakultät für Informatik, Uni Buxtehude". > ja klar, wenn man ein bestimmtes Anliegen hat, dann braucht man normalerweise neben dem Gebäude auch eine Zimmernummer, der Gedanke war, dass man mit OSM wenigstens in die Nähe kommt, wo man dann den richtigen Pförtner fragen kann, wo man genau hin muss. Wenn das aber auch so nicht (in allen Fällen) funktioniert, dann ist bei Universitäten vielleicht noch am ehesten eine Chance (aufgrund unserer Mapper-Struktur), dass man die Informationen detailliert und aktuell anbieten kann. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude, Grundstücke und Institutionen
Am 11.09.2013 13:07, schrieb Martin Koppenhoefer: > ich finde, mindestens die Fachbereiche und evtl. auch die Institute können > wir schon hinbekommen, und das sind auch eher stabilere und für die > Orientierung äusserst wichtige Informationen, Lehrstühle sind dagegen > wirklich schon sehr detailiertes Micromapping. Aber ist das geografisch eindeutig? Beispiel hier in Paderborn: Fakultäten: - Kulturwissenschaften: Verteilt über den Hauptcampus auf mehrere nicht-zusammenhängende Gebäude, dazu die Aussenstelle in Detmold - Wirtschaftswissenschaften: Verteilt auf dem Campus, und Teile der Wirtschaftsinformatik am Standort Fürstenallee - Naturwissenschaften: verteilt auf dem Campus und Sportgelände - Maschinenbau: das dürfte mit die kompakteste Fakultät sein - E-technik, Informatik, Mathematik: Campus (weitgehend zusammenhängend) + Fürstenallee Auf Institutsebene weiß ich von den Wirtschaftswissenschaften und der BWL, dass die deutlich verteilt sind über mehrere Gebäude. > Ähnlich verhält es sich übrigens oft auch mit Krankenhäusern, insbesondere > Unikliniken. In beiden Fällen sind für sinnvolles Routing genauere > Informationen als nur: da ist das Universitätsklinikum XY nötig, vor allem, > wenn es mehrere Standorte gibt. Oft reicht aber eben auch nicht "Fakultät Informatik", sondern "Büro von Prof. Meier, Fakultät für Informatik, Uni Buxtehude". Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude, Grundstücke und Institutionen
Am 11. September 2013 13:01 schrieb Stephan Wolff : > Am 10.09.2013 11:35, schrieb Wolfgang Hinsch: > > > Es ging darum, nicht nur die Uni zu erfassen, sondern auch die einzelnen >> Bestandteile der Uni den Fachbereichen etc. zuzuordnen. Spätestens dann >> wird das Multipolygon gewöhnungsbedürftig, da hier ein Haufen >> Multpolygone übereinander gelegt werden muss. >> > > Eine Universität mit den Unterteilungen in Fakultäten, Fachbereiche, > Institute und Lehrstühle sowie zentralen Einrichtungen, die oft sehr > verschachtelt sind, ist eine der kompliziertesten Institutionen. Wir können > sie sicherlich nicht vollständig in OSM abbilden. > Ich würde alle Teile nur der Universität zuordnen. Das passt zumindest zur > deutschen Rechtslage, in der die Universität als ganzes eine rechtsfähige, > juristische Person (meist eine Körperschaft des öffentlichen Rechts) ist. > Die Untergliederungen würde ich nur als Punkt erfassen. > ich finde, mindestens die Fachbereiche und evtl. auch die Institute können wir schon hinbekommen, und das sind auch eher stabilere und für die Orientierung äusserst wichtige Informationen, Lehrstühle sind dagegen wirklich schon sehr detailiertes Micromapping. Ähnlich verhält es sich übrigens oft auch mit Krankenhäusern, insbesondere Unikliniken. In beiden Fällen sind für sinnvolles Routing genauere Informationen als nur: da ist das Universitätsklinikum XY nötig, vor allem, wenn es mehrere Standorte gibt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude, Grundstücke und Institutionen
Am 10.09.2013 11:35, schrieb Wolfgang Hinsch: Es ging darum, nicht nur die Uni zu erfassen, sondern auch die einzelnen Bestandteile der Uni den Fachbereichen etc. zuzuordnen. Spätestens dann wird das Multipolygon gewöhnungsbedürftig, da hier ein Haufen Multpolygone übereinander gelegt werden muss. Eine Universität mit den Unterteilungen in Fakultäten, Fachbereiche, Institute und Lehrstühle sowie zentralen Einrichtungen, die oft sehr verschachtelt sind, ist eine der kompliziertesten Institutionen. Wir können sie sicherlich nicht vollständig in OSM abbilden. Ich würde alle Teile nur der Universität zuordnen. Das passt zumindest zur deutschen Rechtslage, in der die Universität als ganzes eine rechtsfähige, juristische Person (meist eine Körperschaft des öffentlichen Rechts) ist. Die Untergliederungen würde ich nur als Punkt erfassen. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude, Grundstücke und Institutionen
Am 10. September 2013 11:42 schrieb Martin Koppenhoefer < dieterdre...@gmail.com>: was ist es denn nun, eine öffentliche Straße oder Teil des Campus? Eben dieses Problem aufzuzeigen war mein Anliegen. > Evtl. > ist ja auch der Campus "öffentlich"? > Hast Du mal ein Beispiel mit zugehörigem Katasterplan und > Liegenschaftsregisterauszug? Vielleicht ist eine Dienstbarkeit eingetragen? > Wenn man das richtig aufdröseln will, wird es sicher komplizierter als nur > amenity=university, name=foo, unabhängig davon, ob man eine site-Relation > oder ein Polygon zur Repräsentation verwendet (die site-Relation entbindet > einen ja nicht davon, dass man die Grenzen kennen und zeichnen muss). > Jain. Für eine site-Relation brauche ich nicht zwingend eine Grenze. Ich kann auch einfach zugehörige Objekte sammeln. Wie dies sich räumlich anordnen ist der Relation erst mal egal. > > Gewässer sind wie Straßen normalerweise öffentlich, d.h. sie liegen in > Deutschland nicht auf einer Parzelle sondern im unparzellierten Bereich > (glaube ich, ganz sicher bin ich mir nicht, ob das eine Grundregel ist, > oder nur meistens der Fall). Ggf. müsste man die auch aus dem Campus > ausnehmen, muss man sich vermutlich im Einzelfall ansehen. > Mein Punkt war: eben dadurch, dass es viele Flächen gibt, die nicht unbedingt dem eigentlichen Objekt zuzuordnen sind ist der Anwendungsfall der geschlossenen Fläche als Grenze eines Objekts durchaus nicht immer der passenste. Gruß, Chaos ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude, Grundstücke und Institutionen
Am 10. September 2013 11:12 schrieb Ronnie Soak < chaoschaos0...@googlemail.com>: > Hier wird es in Zukunft sicher massiv Streitereien geben, was denn > "zugehörig" meint. > Ist eine Bushaltestelle auf dem Campus jetzt dem Campus zugehörig (ist auf > dem Geände, trägt dessen Namen, wird von Studenten benutzt) > oder nicht (weder owner noch operator haben was mit der Uni zu tun)? > Das ist meines Erachtens nach das gröere Problem, ehe es um die technische > Umsetzung geht. > Will man denn überhaupt, dass alles innerhalb der Campusgrenzen zum Campus > gehört? (Stromleitungen? öffentl. Straßen? Gewässer?) > was ist es denn nun, eine öffentliche Straße oder Teil des Campus? Evtl. ist ja auch der Campus "öffentlich"? Hast Du mal ein Beispiel mit zugehörigem Katasterplan und Liegenschaftsregisterauszug? Vielleicht ist eine Dienstbarkeit eingetragen? Wenn man das richtig aufdröseln will, wird es sicher komplizierter als nur amenity=university, name=foo, unabhängig davon, ob man eine site-Relation oder ein Polygon zur Repräsentation verwendet (die site-Relation entbindet einen ja nicht davon, dass man die Grenzen kennen und zeichnen muss). Gewässer sind wie Straßen normalerweise öffentlich, d.h. sie liegen in Deutschland nicht auf einer Parzelle sondern im unparzellierten Bereich (glaube ich, ganz sicher bin ich mir nicht, ob das eine Grundregel ist, oder nur meistens der Fall). Ggf. müsste man die auch aus dem Campus ausnehmen, muss man sich vermutlich im Einzelfall ansehen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude, Grundstücke und Institutionen
Am Dienstag, den 10.09.2013, 01:28 +0200 schrieb Martin Koppenhoefer: > Am 10. September 2013 00:57 schrieb Gerhard Hermanns < > gerhard.herma...@uni-due.de>: > > > Ein schönes Beispiel sind meiner Meinung nach Universitäten mit mehr als > > einem Campus. Alles folgt einer verschachtelten Logik, die ich mit der > > site-Relation abbilden kann: Die Uni besteht aus mehreren Campi, ein > > Campus hat mehrere Gebäude und Parkplätze, die Parkplätze haben Frauen- > > und Behindertenplätze, mehrere Gebäude haben einen gemeinsamen, > > übergeordneten Namen, in den Gebäuden sitzen Institute oder die Mensa usw. > > Hier kann ich dann auch einzelne Nodes für die Einrichtungen verwenden, > > wenn ich nichts anderes habe. Dadurch, dass ich sie in die Relation > > packen kann, werden sie in einer Auswertung trotzdem als zur Uni gehörig > > erkannt. > > > > > für das allermeiste braucht man da allerdings keine site-Relation, das sind > Fälle die man weitgehend mit Polygonen lösen kann: pro Campus eines, der > Rest sind dann weitere unabhängige Objekte, räumlich innerhalb des Campus' > und daher automatisch zugehörig. Das einzige, was man dann mit einer site- > (oder auch multipolygon-) Relation als zusammengehörig modellieren muss > sind die einzelnen Campi. Einen node mit entrance=yes/main kann man z.B. > auch ohne Relation setzen. > > Wenn man anfängt, jeden Parkplatz (und schließlich jeden Papierkorb und > jede Parkbank) in die Site-Relationen einzutragen, obwohl er auch schon > räumlich auf dem Campus-Gelände liegt, dann wird man über kurz oder lang > ein paar Dinge vergessen, d.h. es wird unübersichtlich und fehlerträchtig, > und man kann sich letzten Endes doch nicht auf die Relation verlassen. > > Man kann sicherlich für alles eine site-Relation anlegen und tolle Rollen > etc. vergeben, aber solange es auch ohne geht sollte man das unbedingt so > machen, weil Relationen zusätzliche Komplexität einführen und tendenziell > schnell mal kaputt gehen bzw. nicht erweitert werden (Beispiel: ein Mapper > fügt etwas zur Karte hinzu, übersieht aber die site-Relation und nimmt das > daher nicht mir rein), um so mehr, als nicht jeder mit JOSM arbeitet ;-) > -1 Es ging darum, nicht nur die Uni zu erfassen, sondern auch die einzelnen Bestandteile der Uni den Fachbereichen etc. zuzuordnen. Spätestens dann wird das Multipolygon gewöhnungsbedürftig, da hier ein Haufen Multpolygone übereinander gelegt werden muss. Im Übrigen ist auch ein Multipolygon nichts anderes als eine Relation. Multipolygone sollten hauptsächlich benutzt werden, um räumliche Gegebenheiten darzustellen. Für die Darstellung organisatorischer Konstrukte ist die Site dem Multipolygon überlegen, weil sie alle Arten von Objekten einbinden kann, Hierarchien relativ einfach und logisch abgebildet werden können und beim Rendern weniger fehleranfällig sind. Ein Multipolygon kann vom Renderer leichter missverstanden werden. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude, Grundstücke und Institutionen
Am 10. September 2013 01:28 schrieb Martin Koppenhoefer < dieterdre...@gmail.com>: > > > für das allermeiste braucht man da allerdings keine site-Relation, das sind > Fälle die man weitgehend mit Polygonen lösen kann: pro Campus eines, der > Rest sind dann weitere unabhängige Objekte, räumlich innerhalb des Campus' > und daher automatisch zugehörig. Das einzige, was man dann mit einer site- > (oder auch multipolygon-) Relation als zusammengehörig modellieren muss > sind die einzelnen Campi. Einen node mit entrance=yes/main kann man z.B. > auch ohne Relation setzen. > Hier wird es in Zukunft sicher massiv Streitereien geben, was denn "zugehörig" meint. Ist eine Bushaltestelle auf dem Campus jetzt dem Campus zugehörig (ist auf dem Geände, trägt dessen Namen, wird von Studenten benutzt) oder nicht (weder owner noch operator haben was mit der Uni zu tun)? Das ist meines Erachtens nach das gröere Problem, ehe es um die technische Umsetzung geht. Will man denn überhaupt, dass alles innerhalb der Campusgrenzen zum Campus gehört? (Stromleitungen? öffentl. Straßen? Gewässer?) > > Wenn man anfängt, jeden Parkplatz (und schließlich jeden Papierkorb und > jede Parkbank) in die Site-Relationen einzutragen, obwohl er auch schon > räumlich auf dem Campus-Gelände liegt, dann wird man über kurz oder lang > ein paar Dinge vergessen, d.h. es wird unübersichtlich und fehlerträchtig, > und man kann sich letzten Endes doch nicht auf die Relation verlassen. > Siehe oben, kann man sich anderweitig auch nicht. > > Man kann sicherlich für alles eine site-Relation anlegen und tolle Rollen > etc. vergeben, aber solange es auch ohne geht sollte man das unbedingt so > machen, weil Relationen zusätzliche Komplexität einführen und tendenziell > schnell mal kaputt gehen bzw. nicht erweitert werden (Beispiel: ein Mapper > fügt etwas zur Karte hinzu, übersieht aber die site-Relation und nimmt das > daher nicht mir rein), um so mehr, als nicht jeder mit JOSM arbeitet ;-) > Das ist genau das Argument, gegen das ich mich wehre. Es gibt auch Nutzer, die editieren per PIO-App vom Handy. Wollen wir deswegen keine ways benutzen? Nicht jeder Nutzer und jedes Tool muss alles können. Dafür gibt es Freaks und Profi-tools. Eine genügend große Anzahl an Nutzern nutzt JOSM, kann mit Relationen umgehen und hat (scheinbar) genug Motivation sie auch zu betreuen. (Und ich habe sogar Hoffnung, das auch ID irgendwann vernünftig damit umgehen kann.) Dann mappt der Potlatch-Gelegenheitsnutzer halt nur als node. Egal. 4 Wochen später findet es ein Poweruser und packt es in die Relation. Wenn man nur Daten in die DB lässt, die Otto-Normal-Verbraucher mit dem einfachsten Tool eintragen kann, rennen wir demnächst (eigentlich: gestern) vor eine engültige Komplexitätswand. Wenn wir weiter wachsen wollen und die Komplexität weiter beherrschen, müssen wir nicht nur auf gute Tools, sondern auch auf Aufgabenteilung unter den Nutzern setzen. my 2 cents Chaos ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude, Grundstücke und Institutionen
Hallo zusammen,
Am 05.09.2013 20:59, schrieb Ronnie Soak:
> Also mein Apell: Weniger Angst vor (site-)Relationen!
+1
Ich würde mich selbst als "Casual-Mapper" bezeichnen und ich komme
inzwischen - nach ein wenig Rumprobieren - recht gut mit der
site-Relation klar.
Ein schönes Beispiel sind meiner Meinung nach Universitäten mit mehr als
einem Campus. Alles folgt einer verschachtelten Logik, die ich mit der
site-Relation abbilden kann: Die Uni besteht aus mehreren Campi, ein
Campus hat mehrere Gebäude und Parkplätze, die Parkplätze haben Frauen-
und Behindertenplätze, mehrere Gebäude haben einen gemeinsamen,
übergeordneten Namen, in den Gebäuden sitzen Institute oder die Mensa usw.
Hier kann ich dann auch einzelne Nodes für die Einrichtungen verwenden,
wenn ich nichts anderes habe. Dadurch, dass ich sie in die Relation
packen kann, werden sie in einer Auswertung trotzdem als zur Uni gehörig
erkannt.
Ein Beispiel, an dem ich gearbeitet habe, sind die Duisburger Campi der
Universität Duisburg-Essen (die Essener muss ich noch hinzufügen, die
haben derzeit ein anderes Schema):
http://www.openstreetmap.org/browse/relation/2189267
In einem Punkt muss ich Martin übrigens widersprechen: In diesem Fall
ist der Flächenmittelpunkt für die Kartenbeschriftung zwar noch
automatisch ermittelbar, aber nicht mehr sinnvoll: Bei einer Uni mit
zwei Campi, die 2 Kilometer auseinander liegen, würde dann der Name der
Uni im "Niemandsland" zwischen den Campi gerendert.
Meine Lösung für diesen Fall: Der Name der Uni (an der site-Relation und
am Label-Knoten eingetragen) wird gar nicht gerendert, was in diesem
Fall auch sinnvoll ist. Es gibt ja keinen Ort, der dafür geeignet wäre.
Stattdessen habe ich im obigen Beispiel zusätzlich je einen Way in der
Rolle "perimeter" um die Hauptcampi ("L+M-Bereich" und "B-Bereich")
gezogen, deren Namen dann gerendert werden. Statt der Perimeter hätte
ich lieber einen Knoten mit der Rolle "label" verwendet, aber das wird
von den Renderern offenbar nicht unterstützt.
Gerhard
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude, Grundstücke und Institutionen
Am 10. September 2013 00:57 schrieb Gerhard Hermanns < gerhard.herma...@uni-due.de>: > Ein schönes Beispiel sind meiner Meinung nach Universitäten mit mehr als > einem Campus. Alles folgt einer verschachtelten Logik, die ich mit der > site-Relation abbilden kann: Die Uni besteht aus mehreren Campi, ein > Campus hat mehrere Gebäude und Parkplätze, die Parkplätze haben Frauen- > und Behindertenplätze, mehrere Gebäude haben einen gemeinsamen, > übergeordneten Namen, in den Gebäuden sitzen Institute oder die Mensa usw. > Hier kann ich dann auch einzelne Nodes für die Einrichtungen verwenden, > wenn ich nichts anderes habe. Dadurch, dass ich sie in die Relation > packen kann, werden sie in einer Auswertung trotzdem als zur Uni gehörig > erkannt. > für das allermeiste braucht man da allerdings keine site-Relation, das sind Fälle die man weitgehend mit Polygonen lösen kann: pro Campus eines, der Rest sind dann weitere unabhängige Objekte, räumlich innerhalb des Campus' und daher automatisch zugehörig. Das einzige, was man dann mit einer site- (oder auch multipolygon-) Relation als zusammengehörig modellieren muss sind die einzelnen Campi. Einen node mit entrance=yes/main kann man z.B. auch ohne Relation setzen. Wenn man anfängt, jeden Parkplatz (und schließlich jeden Papierkorb und jede Parkbank) in die Site-Relationen einzutragen, obwohl er auch schon räumlich auf dem Campus-Gelände liegt, dann wird man über kurz oder lang ein paar Dinge vergessen, d.h. es wird unübersichtlich und fehlerträchtig, und man kann sich letzten Endes doch nicht auf die Relation verlassen. Man kann sicherlich für alles eine site-Relation anlegen und tolle Rollen etc. vergeben, aber solange es auch ohne geht sollte man das unbedingt so machen, weil Relationen zusätzliche Komplexität einführen und tendenziell schnell mal kaputt gehen bzw. nicht erweitert werden (Beispiel: ein Mapper fügt etwas zur Karte hinzu, übersieht aber die site-Relation und nimmt das daher nicht mir rein), um so mehr, als nicht jeder mit JOSM arbeitet ;-) In einem Punkt muss ich Martin übrigens widersprechen: In diesem Fall > ist der Flächenmittelpunkt für die Kartenbeschriftung zwar noch > automatisch ermittelbar, aber nicht mehr sinnvoll: Bei einer Uni mit > zwei Campi, die 2 Kilometer auseinander liegen, würde dann der Name der > Uni im "Niemandsland" zwischen den Campi gerendert. > ja, ganz so einfach ist es zugegebenermaßen nicht, man kann das aber durchaus automatisch lösen und z.B. vorgeben, dass die Beschriftung sich innerhalb des Objekts befinden muss. Die ÖPNV-Karte macht z.B. vor, wie man mehrere (gleichnamige) einzelne Bushaltestellen in geeigneten Zoomleveln als zusammengehöriges Ganzes darstellen kann, analog könnte man auch andere Beschriftungsprobleme durch komplexere Regeln und automatische Vorverarbeitung angehen. Problem einer vom Mapper vorgegebenen Label-Position ist, dass man als Mapper ja weder den Maßstab der gerenderten Karte kennt, noch weiss, was in welcher Größe und Schriftart bzw. Umbruch, etc. beschriftet wird. Von daher ist das m.E. Mappen für (den einen Haupt-)Renderer. Ist aber auch nicht so schlimm, weil man es beim Rendern ja problemlos ignorieren kann, und evtl. hilft es ja, sich die Vorverarbeitung zu sparen (die beim Rendern von sich potenziell permanent ändernden Daten ein grundsätzliches Problem darstellt). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude, Grundstücke und Institutionen
Ich stimme Martin bei fast allen Punkten zu. Lediglich >> Brauchen wir für große Institutionen Relationen, die die Gesamtfläche, >> Gebäude, Parkplätze und den Hauptzugang miteinander verknüpfen? > ja, aber eher in wenigen Fällen, meist sollte ein Polygon ausreichen, man > braucht sie z.B. wenn der Parkplatz räumlich getrennt ist (z.B. andere > Straßenseite), oder wenn man andere Beziehungen darstellen will (z.B. hier > ist das Ticketoffice für diesen POI). Sehe ich etwas differenzierter. Relationen sind allgemein als schwer editierbar und schwer auswertbar verschrien. Ich kann das nach all der Zeit nun wirklich nicht mehr nachvollziehen. Sie sind als logisches Konstrukt intuitiv und einfach zu verstehen und zumindest in einigen Editoren kinderleicht zu bearbeiten. Vor allem wenn sie auf kleine Raum daherkommen (also nicht mit unhandlichen Grenzrelationen zu vergleichen.) Zur Auswertung kann ich nichts sagen. Für die Beschreibung von räumlich getrennten Einzelobjekten als ein zusammengehöriges Ganzes sind sie ideal. Durch die Rollen ergibt sich sogar ein zusätzlicher, sonst nicht abbildbarer Informationsgewinn. Ich würde Relationen daher weit weniger als Ausnahme als die Regel betrachten. Die Ausnahme ist das Polygon, wenn alle Einzelobjekte räumlich umschlossen werden können. Sobald Objekte mehreren Institutionen zugeordnet werden können (Parkplätze? Toiletten?), würden sich überschneidende Polygone ergeben, die nun wirklich auch nicht mehr einfacher zu handhaben sind als Relationen. Schon erwähnt wurde die räumliche Trennung (Nebengebäude auf der anderen Straßenseite.) Auch das ausschliessen von Objekten (Bushaltestelle im Messegelände? Nodes von POIs auf anderen Stockwerken) klappt nicht mit Polygonen, sondern nur mit Relationen. Also mein Apell: Weniger Angst vor (site-)Relationen! Durch die Rollen ergeben sich auch noch neue Möglichkeiten, z.B. kann man Eingänge nach Haupt- und Neben- gruppieren, auch wenn es aus Gebäudesicht vielleicht alles Haupteingänge sind, etc... Schönen Abend noch, Chaos ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude, Grundstücke und Institutionen
Am 5. September 2013 20:17 schrieb Stephan Wolff : > Moin! > Ich frage mich oftmals, wie man Institutionen am besten erfasst. > Als Institution verstehe ich hier Geschäfte, Industrieunternehmen, > Handwerksbetriebe, Vereine, Institute, Behörden, Ärzte, Anwälte, etc. > je nachdem, siehe mapfeatures ;-) > In unser Datenbank sind viele Institutionen nur als "name"-Tag am Gebäude > erfasst. Für einen menschlichen Nutzer mit ausreichendem Sprachverständnis > und Vorwissen ist meist erkennbar, was gemeint ist, > für fremdsprachige Nutzer und automatische Auswertungen nicht. > ja, das ist leider nicht so gut, es gibt halt für viele Dinge nach wie vor noch keinen allgemein anerkannten / verbreiteten tag, und viele Mapper haben weder Lust, einen Tag vorzuschlagen, noch fühlen sie sich berufen, adhoc was zu erfinden. > Beim Einzelhandel und einigen anderen Objekten ist neben "building" und > "name" zumindest ein weiteres Tag wie "shop", "office" etc. üblich. > building hat damit nichts zu tun, das ist ein Gebäude ;-) > Dabei bleibt undefiniert, ob "name" und andere tags zum Gebäude oder zum > Gebäudenutzer gehören. Meist passt nicht einmal die Gebäudeaußenlinie als > Grenze der Institution, da entweder ein Grundstück dazu gehört oder das > Gebäude weitere Nutzer hat. > ja, das kommt daher, dass allerorten empfohlen wird, alles entweder ans Gebäude oder an die Straße zu hängen ;-) > Einige Gebäude sind nach dem Hauptmieter benannt, während kleinere > (rechtlich selbstständige) Mieter als Punkt innerhalb des Gebäudes liegen. > Große Institutionen werden oft als mehrere Gebäude mit gleichem Namen > (Mehrdeutigkeit bei der Suche, falsche Ergebnisse bei Zählungen) oder als > "landuse" mit Namen der Institution (Mehrdeutigkeit der tag-Zuordnung) > erfasst. > Für das Kartenbild mag das Tagging akzeptabel sein, aber eine sinnvolle > Analyse der Geodaten ist damit kaum möglich. > Ein POI innerhalb eines Gebäudes ist unproblematisch, aber eine > Unterscheidung nach der Größe ist nicht möglich. > Die Lösung sind eigene Objekte für die Nutzer / Institutionen, das können entweder Punkte sein (mit dem geschilderten Nachteil, dass man über die Ausdehnung keine Angaben hat) oder eigene Polygone, ggf. (wenn z.B. Gebäudegrundfläche und Nutzung übereinstimmen) auch Multipolygone. Vermeiden sollte man, das Gebäude mit der Nutzung in ein Objekt zu quetschen, weil dadurch nicht mehr klar wird, welcher tag wohin gehört. > Mir fallen folgende Kriterien ein, die ein Datenobjekt für Institutionen > im Idealfall erfüllen sollte: > > - genau ein OSM-Objekt pro Institution (Datenbankauswertung, Routingziele) > - mindestens ein Tag zur Klassifizierung der Institution (shop, club, > office, craft, etc.) > - eindeutige Zuordnung der OSM-Tags zum Gebäude oder zur Institution > - eindeutige Zuordnung von Gebäuden / Parkplätzen zur Institution > ggf. site relation > - Haupteingang statt Flächenmitte als Routingziel > entrance=main > - Flächenmittelpunkt für Kartenbeschriftung > automatisch ermittelbar > - Abschätzung der Wichtigkeit einer Institution, um bei Kollisionen des > Kartentextes die wichtigere Institution darzustellen und bei einer Suche > diese als erstes aufzulisten > das ist m.E. die Aufgabe des Auswerters > - evtl. sogar Besucher-/Kundenparkplatz als Routingziel für PKW > -> Auswerter, es sollte halt klar sein, was wozu gehört Wollen wir eher Grundstücke, Gebäude oder einfach den Zugangspunkt als Institution erfassen? s.o., wenn alles "klar" sein soll, kann man wohl kaum alles zusammenwürfeln Brauchen wir für große Institutionen Relationen, die die Gesamtfläche, Gebäude, Parkplätze und den Hauptzugang miteinander verknüpfen? ja, aber eher in wenigen Fällen, meist sollte ein Polygon ausreichen, man braucht sie z.B. wenn der Parkplatz räumlich getrennt ist (z.B. andere Straßenseite), oder wenn man andere Beziehungen darstellen will (z.B. hier ist das Ticketoffice für diesen POI). Wollen wir für Gebäude und Institutionen grundsätzlich verschiedene OSM-Objekt nehmen oder die Tags durch einen Prefix eindeutig machen (z.B. "building:name", "shop:name")? m.E. verschiedene Objekte, weil das "einfach und natürlich" ist. Wie kann man die Bedeutung einer Institution aus unseren Daten erkennen? Hilft die Grundstücks- bzw. Gebäudefläche oder brauchen wir manuell gepflegte Daten (z.B. "importance=1" bis "importance=5")? die tags helfen sicher dabei genauso wie die Fläche, aber "importance", wo man wieder alles zusammenwürfelt und subjektive Kriterien anlegt, brauchen wir m.E. nicht. Ich tendiere dazu, Institutionen mit eigenem Grundstück als Fläche zu erfassen (ohne diese gleichzeitig als "landuse" zu verwenden), kleinere als Punkt innerhalb eines Gebäudes. Was meint ihr dazu? ja, mache ich auch so, nur dass ich die Flächen auch gleich für den landuse verwende, wieso auch nicht? Ggf. kann man auch (Teil-)Flächen in Gebäuden andeuten. Gruß Martin _
[Talk-de] Gebäude, Grundstücke und Institutionen
Moin! Ich frage mich oftmals, wie man Institutionen am besten erfasst. Als Institution verstehe ich hier Geschäfte, Industrieunternehmen, Handwerksbetriebe, Vereine, Institute, Behörden, Ärzte, Anwälte, etc. Diese kommen in sehr unterschiedlichen Größen und Bauformen vor. Einige typische Beispiele: - großes Industrieunternehmen (Gelände mit mehreren Gebäuden, ein Haupttor und mehrere Nebentore) - mittelgroßes Gewerbe / Handel (ein Grundstück, ein Gebäude, ein Eingang) - Gewerbehof / Supermarkt (mehreren Institutionen nebeneinander in einem Gebäude, gemeinsame Nutzung des Grundstücks / Parkplatzes) - mehrstöckiges Geschäftshaus (Ladenlokal, Büros, Praxis übereinander) In unser Datenbank sind viele Institutionen nur als "name"-Tag am Gebäude erfasst. Für einen menschlichen Nutzer mit ausreichendem Sprachverständnis und Vorwissen ist meist erkennbar, was gemeint ist, für fremdsprachige Nutzer und automatische Auswertungen nicht. Beim Einzelhandel und einigen anderen Objekten ist neben "building" und "name" zumindest ein weiteres Tag wie "shop", "office" etc. üblich. Dabei bleibt undefiniert, ob "name" und andere tags zum Gebäude oder zum Gebäudenutzer gehören. Meist passt nicht einmal die Gebäudeaußenlinie als Grenze der Institution, da entweder ein Grundstück dazu gehört oder das Gebäude weitere Nutzer hat. Einige Gebäude sind nach dem Hauptmieter benannt, während kleinere (rechtlich selbstständige) Mieter als Punkt innerhalb des Gebäudes liegen. Große Institutionen werden oft als mehrere Gebäude mit gleichem Namen (Mehrdeutigkeit bei der Suche, falsche Ergebnisse bei Zählungen) oder als "landuse" mit Namen der Institution (Mehrdeutigkeit der tag-Zuordnung) erfasst. Für das Kartenbild mag das Tagging akzeptabel sein, aber eine sinnvolle Analyse der Geodaten ist damit kaum möglich. Ein POI innerhalb eines Gebäudes ist unproblematisch, aber eine Unterscheidung nach der Größe ist nicht möglich. Mir fallen folgende Kriterien ein, die ein Datenobjekt für Institutionen im Idealfall erfüllen sollte: - genau ein OSM-Objekt pro Institution (Datenbankauswertung, Routingziele) - mindestens ein Tag zur Klassifizierung der Institution (shop, club, office, craft, etc.) - eindeutige Zuordnung der OSM-Tags zum Gebäude oder zur Institution - eindeutige Zuordnung von Gebäuden / Parkplätzen zur Institution - Haupteingang statt Flächenmitte als Routingziel - Flächenmittelpunkt für Kartenbeschriftung - Abschätzung der Wichtigkeit einer Institution, um bei Kollisionen des Kartentextes die wichtigere Institution darzustellen und bei einer Suche diese als erstes aufzulisten - evtl. sogar Besucher-/Kundenparkplatz als Routingziel für PKW - alles möglichst einfach und selbsterklärend ;-) Leider ist alles zugleich kaum möglich. Wollen wir eher Grundstücke, Gebäude oder einfach den Zugangspunkt als Institution erfassen? Brauchen wir für große Institutionen Relationen, die die Gesamtfläche, Gebäude, Parkplätze und den Hauptzugang miteinander verknüpfen? Wollen wir für Gebäude und Institutionen grundsätzlich verschiedene OSM-Objekt nehmen oder die Tags durch einen Prefix eindeutig machen (z.B. "building:name", "shop:name")? Wie kann man die Bedeutung einer Institution aus unseren Daten erkennen? Hilft die Grundstücks- bzw. Gebäudefläche oder brauchen wir manuell gepflegte Daten (z.B. "importance=1" bis "importance=5")? Ich tendiere dazu, Institutionen mit eigenem Grundstück als Fläche zu erfassen (ohne diese gleichzeitig als "landuse" zu verwenden), kleinere als Punkt innerhalb eines Gebäudes. Was meint ihr dazu? Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
