Hi,
hier http://www.openstreetmap.org/?lat=51.59685&lon=7.2462&zoom=15 werden zwei Parkplätze mit jeweils einer site-Relation erfasst.
Laut wiki soll die site Objekte zusammenfassen, die nicht innerhalb einer gemappten Fläche liegen.
IMHO ist die site hier überflüssig, da alle Objekte jeweils innerhalb einer amenity=parking-Fläche liegen.
BTW, wenn schon site, gehören dann die Wege nicht dazu?
Laut site-Relation ( http://wiki.openstreetmap.org/wiki/Relations/Proposed/Site ) sollte es so aber richtig sein.
Moin,
bereits der erste Satz sagt genau das Gegenteil: which belong together but not within a single area - wie Radeln bereits schrieb und wie sich die Situation in diesem Fall darstellt.
Allerdings ist der Bezug zwischen dem Parkplatz und seinen Einzelelemente so halt einfacher gegeben und damit wie bei einer Sammelrelation eben auch ohne GIS-Funktionen oder Overpass (“liefere mir alle parking_space innerhalb der parking Fläche” => Anzahl der Plätze) auszuwerten.
Dieser Bedarf scheint ja wohl zu oft zu bestehen - ob nun nur vermeintlich oder eben auch tatsächlich.
Gruß
Georg
Irgendwie ist mir der Sinn dieser site-Relationen noch nicht ganz klar. Für mich wäre das ein Multiploygon wie im Beispiel [1]. Mir ist bisher kein Fall bekannt, wo man eine site-Relation nicht durch eine Multiploygon-Relation ersetzen könnte.
Christian
P.S. Noch mal “site” angesehen, da andere Rollen als beim MP. Aber diese werden hier im Beispiel nicht benötigt.
[1] http://wiki.openstreetmap.org/wiki/Relation:multipolygon#Two_disjunct_outer_rings
Hi,
zum Hintergrund siehe:
http://forum.openstreetmap.org/viewtopic.php?id=19070
Ich hatte die 50 Parkplätze zu parking_space umgewandelt und aus Kompatibilitätsgründen
den Gesamtparkplatz jeweils mit in die site=parking Relation hinzugefügt.
Chris
Also mit MPs hat die site-Relation nichts am Hut und den Fall “Auf dem Parkplatz sind diese Stellplätze” kann man auch nicht mit einem MP abbilden. Der Parkplatz hat ja keine Lücke da, wo die Stellplätze sind.
Das man für den Fall eine site-Relation nutzen soll sagt: http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking_space. Die site gruppiert dabei die einzelnen Parkplätze. Die Fläche des Parkplatzes im Ganzen ist nur die Hülle.
Btw: Der erste Satz auf der Wiki-Seite der site-Relation wiederspricht irgendwie dem Rest der Seite. Wie soll man etwas in perimeter angeben, wenn es nicht in einer Fläche liegt oder anders gesagt: Was soll eine single area sein? Ich kann um beliebige Objekte immer eine Hülle zeichnen…
Wenn man ein Objekt als Fläche zeichnen kann und alle Elemente innerhalb dieser Fläche zum Objekt gehören, dann ist site eigentlich überflüssig. Denn dann genügt die Fläche mit den entsprechenden Tags für das Gesamtobjekt und die implizite Zuordnung über die Lage.
Es gibt Fälle, wo das nicht funktioniert, gerade wenn man in drei Dimensionen geht. Beim Thema Parkplätze sind das z.B. Tiefgaragen, über denen Dinge stehen, die nicht zum Parkplatz gehören. Da hat dann die Relation ihren großen Auftritt. Eine Fläche mit entsprechendem Layer kann man trotzdem angeben, das wäre auch gleichzeitig ein guter Kandidat für die perimeter-Rolle.
Und dann gibt es natürlich noch den Fall, dass jemand eine site-Relation einsetzt, obwohl sie gar nicht unbedingt nötig wäre - etwa bei den meisten oberirdischen Parkplätzen. Der Autor von amenity=parking_space gehört bekanntlich zu dieser Fraktion. 
Da freuen sich die Auswerter, wenn sie die Richtigen Objekte zusammen zu suchen dürfen. Ohne entsprechende Datenbank oder fette Workstation kann man dann nämlich nahezu einpacken. Ich denke, das ist nicht wirklich im Sinne von OSM.
Gehört wirklich alles, was innerhalb eines Parkplatzes steht zum Parkplatz. Triviales Beispiel wäre wohl ein Blumenkübel oder die Einkaufswagensammelstelle. Der Parkscheinautomat gehört wahrscheinlich dazu, die Würstchenbude aber eher weniger usw. Im Fall des Parkplatzes gibt es eine Relation zwischen den Stellplätzen und dem Parkplatz.
Gehörst Du auch zu denen, die sich berührende Gebäude oder auch Flächen per MP zusammmenfassen und damit jede Menge intersections produzieren (OSMI)?
Dann werden in Zukunft z.B. alle Schulgebäude, die sich innerhalb einer Fläche befinden, per site erfasst.
OSM ist eine Geodatenbank. Der Wunsch, anspruchsvolle Auswertungen auf OSM-Basis erstellen zu können, ohne dabei geographische Zusammenhänge zu berücksichtigen, wird sich nicht so leicht erfüllen lassen.
Man bedenke, dass das anderswo ebenso wenig geht: Wenn ich eine Liste aller Parkplätze in Hamburg möchte, dann kann ich nicht auf eine Relation mit allen Objekten zurückgreifen, die zu Hamburg gehören, sondern muss eben schauen, was so alles in den Grenzen von Hamburg liegt.
Wie immer bei solchen fast schon philosophischen Fragen: Was “dazu gehört” ist Definitionssache und verschiedene Mapper und Auswerter werden das unterschiedlich beantworten. Ich sehe beispielsweise die Zufahrtswege zwischen den Stellplätzen als Teil des Parkplatzes. Allerdings scheinen diese oft nicht in der site-Relation als Mitglieder erfasst zu werden. Inwiefern hilft jetzt also die Relation bei der Beantwortung der Frage, was zum Parkplatz gehört?
Für den naheliegenden Anwendungsfall, die zu einem Parkplatz gehörenden Stellplätze zu ermitteln, spielt diese Abgrenzung aber ohnehin keine Rolle.
Bei landuse=* haben wir die weise Definition der “Überwiegend”-Nutzung, damit nicht jeder Kleinkram per MP ausgenommen werden muss. Sollte man hier auch so sehen 
Wie würdet ihr das z.B. in diesem [1*] Fall sehen:
Die Uni hat mehrere Parkplätze, mit einigen wenigen Frauen-/Behindertenparkplätzen darin. Leider sind diese Plätze so gut wie nicht (mehr) beschildert und ich möchte ihre Position klar machen. Das Ganze ist folgendermaßen verschachtelt: Die Behindertenparkplätze [2] sind Teil der Parkfläche [3], die einen Teil des Parkplatzes “Parkspange” [4] darstellt, die zu den Parkplätzen [5] der Uni [6] gehört.
Um dies abzubilden, habe ich für [4], [5] und [6] die site-Relation benutzt. Würdet ihr da etwa Multipolygone nehmen?
Seoman
[1*] http://www.openstreetmap.org/?lat=51.42966&lon=6.80296&zoom=17&layers=M
[2] http://www.openstreetmap.org/browse/way/130655725
[3] http://www.openstreetmap.org/browse/way/130655728
[4] http://www.openstreetmap.org/browse/relation/1758919
[5] http://www.openstreetmap.org/browse/relation/1862665
[6] http://www.openstreetmap.org/browse/relation/2189267 {Anm.: Die anderen Campi muss ich noch aufnehmen.}
Dann können wir ja auch auf MP verzichten. Kann doch jeder selber bei Bedarf innen liegende Flächen von umgebenen Flächen abziehen oder große Polygone aus vielen Wegen zusammenbasteln.
Die gesamte Geodatenbank würde auch ohne Relationen auskommen. Man könnte alles irgendwie auch über ways und nodes darstellen und dann der Auswertung sagen mach mal. Wenn man aber die Geodatenbank nicht mehr sinnvoll auswerten kann, dann ist die Geodatenbank nicht viel wert. Dann kann ich auch für Google mappen. Ob die Daten nicht nutzen kann oder nicht nutzen darf kommt letztlich aufs selbe raus.
Das ist ein komplett anderer Fall. In vorliegenden Fall geht es um einen Parkplatz, der diverse Bestandteile hat.
Ich habe schon Site-Rels gesehen für z.B. Haltestellen: da sind verschiedene Objekte wie Halteschilder, Stop-Positionen, Plattformen, Automaten, Shelter u.s.w, ohne dass es einen Perimeter aka Landuse/Amenity dafür gibt.
Die ÖPNV-Karte hat dann eine Hüllkurve drum rumgelegt und alle waren happy.
So würde ich das für alle Plätze, also auch Parkplätze sehen. Und wenn der Platz wirklich durch etwas physikalisch abgegrenzt wird, kommt es halt als Perimeter dazu rein.
In anderen Worten: der Zusammenhalt kommt durch die Relation und nicht unbedingt durch Landuse/Amenity.
gruss
walter
p.s. Speziallösungen für bestimmte Plätze (hier Parkplätze) halte ich eh für Blödsinn.
Das grundlegende Problem dabei wäre ja auch nicht der Test, ob eine Fläche in einer anderen liegt, sondern das fehlende Wissen, welche Flächen ein Loch darstellen und welche zusätzlich zur äußeren Fläche gelten.
Bei der Zuordnung von Stellplätzen zu Parkplätzen gibt es kein derartiges Definitionsproblem: Sofern nicht durch eine Relation anders angegeben, gehört jeder Stellplatz auf der Fläche eines Parkplatzes zu diesem dazu. Ich sehe das als klare und intuitiv verständliche Lösung.
Wie das Weglassen der amenity=parking-Fläche die Auswertung verbessert, musst du mir aber auch erst mal erklären.
Im Gegensatz zur Relation, für die überzeugende Auswertungen noch auf sich warten lassen, werden amenity=parking-Flächen nämlich bereits in unzähligen Anwendungen genutzt.
IMHO solll die site doch solche Objekte zusammen fassen, deren Zusammengehörigkeit nicht ersichtlich ist. Für Schulgebäude auf einer Fläche, die als Schule getaggt ist, oder einzelne Parkplätze auf einer Parkplatzfläche ist die Zuordnung doch eindeutig. Was soll hier dann eine site?
War das vielleicht eher eine stop_area als eine site?
joo, da magst du recht haben. ist schon 2 Jahre her.
Gruss
walter
Narf. Und wieder muss mein Parkplatz dran glauben… Ich tue mal so als hätte ich den Thread nicht gesehen…