Ist das landuse=construction noch Baugebiet oder bereits (in Teilen) fertig gestellt? Die Bilder sind relativ alt. Das Gebiet wurde im Mai 2010 nach den Aerowest-Bildern erfasst und im September 2011 zum letzten Mal angepasst.
Edbert (EvanE)
Das mit einer site-Realtion zu lösen ist sehr unglücklich. Das Objekt ist als eigenstäniger Parkplatz eingetragen und nur über seine Mitgliedschaft in einer Relation ändert sich diese Eigenschaft komplett. Von der Logik her wären das am ehesten noch Multipolygone.
Allgemein würde ich mir wünschen, wenn du schon auf diesem Detaillevel mit viel Mühe editierst, dass du etwas sorgfältiger mappen würdest. Es gab auf dem von dir verlinkten Parkplatz viele Nodes die unerbunden waren bzw. ebenfalls als Stellplatz gekennzeichnet waren. Weiterhin gibt es überdeckungen mit den Recycling-Behältern und Gebäuden. Auch würde ich davon ausgehen, dass die Stellplätze rechteckig sind.
Wiki: Benutze eine Relation mit den Tags type=site und site=parking um die einzelnen Stellflächen bzw. Ein- und Ausfahrten zu einem logischen Parkplatz zusammenzufassen.
Ist doch der Super-Gau, jeden einzelnen Stellplatz zu mappen. Wenn schon, dann nur Plätze für Behinderte und Eltern-Kind.
Ich hab nichts gesagt, dass es nicht im wiki steht, nur das es mehr als unglücklich ist, wenn man viele Flächen mit amenity=parking taggt und dann die über eine site-Relation zu einem Parkplatz verbindet.
Die sollte man als Stellplätze taggen und die ganze Fläche mit den Stellplätzen dann eben als Parkplatz. http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking_space finde ich da von dem etablierten Sachen besser als z.B. die site-Relation.
Das ergibt aber zumindest auf der Standard-Karte auch nicht unbedingt ein optimales Ergebnis: http://www.openstreetmap.org/?lat=52.434004&lon=10.798294&zoom=18&layers=M
Ich habs wie gesagt nach einen Proposal gemapped von dem das Voting auch schon abgeschloßen ist, und in dem Proposal wird nunmal gesagt, das man die gesamten einzelnen Parkplätze hinterher in einer Site Relation zusammen fügt.
Hier is übrigens das Proposal nach dem ich gamapped habe: http://wiki.openstreetmap.org/wiki/Proposed_features/parking
Danke für den Hinweis, das is mir dann bei den zig tausend nodes nicht aufgefallen, da es eh schon sehr kompliziert und Zeitaufwändig ist, so ein Detailgrad zu erreichen.
Das mit dem Recycling Containern is übrigens Absicht, schließlich könnte man auf die Plätze dann noch nen Smart oder nen Motorrad abstellen, außerdem sind solche Container ja auch nicht Fest installiert und können rein theoretisch von heute auf morgen verschwinden.
Aneinander grenzende landuse solltest Du verbinden und doppelte/gemeinsame nodes zusammenfassen.
Das ist ein MischMasch aus beiden Schemen. Bei Verwendung von parking_spaces soll der Gesamtparkplatz per
Relation gebildet werden und nicht zusätzlich als amenity=parking gemappt werden.
Edit: Hab mal gerade ne Mail an flamio geschickt, ob das “erlaubt” ist. Vorteil dieser Lösung wäre ja die Abwärtskompatibilität.
Sorry, keine Ahnung, bin nur über den OSMI-Multipolygon Fehler auf den Parkplatz gestoßen.
Vollkommen richtig. Genauso war mein Proposal gedacht. Der Satz “Therefore I wrote this proposal as an addition, not as an replacement, to the current mapping scheme for parking spaces.” besagt eigentlich, dass das Mapping-Schema mit amenity=parking als solches nicht obsolet ist. Die Gründe wieso man das Alte noch verwenden kann/soll stehen im Proposal. Es heißt aber nicht, dass man ein und den selben Parkplatz zweimal erfassen soll. Kann sein, dass das bei meiner englischen Formulierung nicht klar rübergekommen ist.
Zum Thema Relationen: Das wurde auch in der RFC-Phase heiß diskutiert. Surface-Stellflächen könnten theoretisch in den meisten Fällen auf beide Arten gemappt werden, die Relation erweist sich aber als robuster gegenüber Spezialfällen, wo die physischen Stellflächen exotisch verteilt sind. Ausserdem darf man nicht vergessen, dass das Schema auch zum Mappen von Tiefgaragen und Parkhäusern gedacht ist, wo man nur die Eingänge erfasst, weil sich diese vielleicht über mehrere Blöcke verteilen und die physischen Ausmaße der Tiefgarage vermutlich gar nicht bekannt sind. Der Einfachheit halber habe ich es daher bei der Relation belassen und auf die zusätzliche Aufnahme des alten amenity=parking als Zusammenfassende Fläche verzichtet. Das neue Public-Transport-Schema macht es ja genauso und fasst alle Haltestellenelemente in einer Relation zusammen, anstatt ein highway=bus_stop als Fläche drüberzuziehen.
Ich habe dem Proposal zu parking_space zustimmen können, weil es ausdrücklich Hinweise wie “Therefore I wrote this proposal as an addition, not as an replacement, to the current mapping scheme for parking spaces” und “This new tagging scheme is not meant to replace amenity=parking.” enthielt.
Dass diese Formulierung so gedeutet werden kann, dass das Proposal Flächen mit amenity=parking für alle detailliert erfassten Parkplätze eben doch abschafft, war ganz und gar nicht klar.
Ob das so gedacht war, sehe ich als zweitrangig, wenn es aus dem Proposal zum Abstimmungszeitpunkt nicht hervorging.
Ich halte eine Fläche mit amenity=parking zusätzlich zu den einzelnen Stellplätzen für die sinnvollste Art des Mappings. Zum einen aus Kompatibilitätsgründen, aber auch konzeptionell: Eine Fläche für den Gesamtparkplatz, auf der zusätzlich einzelne Stellplätze eingetragen sind, betrachte ich eben nicht als “doppelt” gemappt - genausowenig wie ein Park, in dem einzelne Bäume eingezeichnet sind, oder ein Gebäude, in dem Räume mit Raumnummern eingetragen sind, doppelt gemappt sind.
Wenn man die Information zur Ausdehnung nicht hat, kann man sie natürlich auch nicht eintragen. Das ist aber kein Grund, sie auch dort wegzulassen, wo man sie hat - wie eben bei praktisch allen oberirdischen Parkplätzen und sicher auch manchen Tiefgaragen.
@Tordanik: +1
Wenn ich mich recht erinnere war das auch in den Diskussionen hier der Tenor, dass Stellplatzmapping immer zusätzlich erfolgt. Ähnlich wie riverbank immer zusätzlich zu einem river gemappt wird.
Kein Problem. Ich hatte das Baugebiet 2010 nach den Aerowest-Bildern erst-erfasst. Etliche Straßen sind in der Zwischenzeit dazu gekommen. Von daher hat mich die Frage interessiert. Sie war auch mehr an die Allgemeinheit, insbesondere die Dortmunder Mapper, gerichtet.
Edbert (EvanE)
Dann hast du meiner Meinung nach falsch interpretiert und hättest beim RFC diese Unklarheit erwähnen sollen. Bei der detailierten Bechreibung von amenity=parking_space und später der Relation steht nichts davon, dass als alternative auch amenity=parking verwendet werden kann. Hätte ich es vorgesehen, hätte ich ein Beispiel dazu hingeschrieben. Hätte ich gewollt, dass man beides gleichzeitig verwendet hätte ich vermutlich den Satz in etwa so formuliert: “You can use amenity=parking_space in combination with amenity=parking to map a parking lot”.
Es spricht mehr für Relationen als dagegen. Z.B. lassen sich mit Flächen nämlich auch keine Hierarchien abbilden wie zB bei großen Flughafen- oder Shoppingmall-Parkplätzen die verschiedene Sektionen haben.
Ich hab jetzt aber ehrlich gesagt keine Lust das ganze Thema wieder aufzuwärmen, was zur genüge im Zuge der RFC-Phase durchgekaut wurde. Wer will kann sich die Kommentare auf der Wikiseite oder der Mailinglist durchlesen und ggf ein Änderungsproposal starten wenn er der Meinung ist, dass das jetzige Schema komplett falsch ist.
Aber damit wäre schonmal geklärt das wir die Site Relation endlich auch mal beim Rendering und in der Auswertung brauchen. Weil ich wirklich davon ausgehe, das bald mehr Parkplätze detailierter mappen werden, als es jetzt der Fall ist, weil die Luftbilder einfach besser werden.
Außerdem ist es Realistischer wenn man die Realen Stellflächen hat, als wenn man riesen Luftlöcher bedingt durch die Fläche in der amenity=parking fläche hat, die eigentlich gar kein Parkplatz sind, sondern zur Zufahrt gehören, die dort eben etwas breiter ist.
Ich denke mal in naher zukunft werden auch einige die Flächen für Flächen Berechnungen benutzen wollen und da is sowas nun einmal essentinal das die Daten auch korrekt sind.
Welche Unklarheit? Es war mir “klar”, dass amenity=parking wie bisher weiter genutzt werden kann - auch bei detailliert gemappten Parkplätzen -, nachdem du das Tagging auf amenity=parking_space umgestellt hattest. Ich meine, rückblickend ist offensichtlich, dass wir da aneinander vorbeigeredet haben. Aber wenn man das Proposal mit meiner Interpretation im Kopf liest, wird man gar nicht auf deine Lesart kommen.
Vielleicht können wir auch unabhängig von der Frage, ob das Proposal damals eindeutig formuliert war oder nicht, noch darüber reden, was du eigentlich gegen ein ergänzendes amenity=parking hast. Es erscheint mir als absolut pragmatische Lösung: Wer sich nicht für einzelne Stellplätze interessiert, kann weiterhin das grobe amenity=parking auswerten und muss keinen Unterschied machen zwischen Parkplätzen mit Stellplatzmapping und Parkplätzen ohne Stellplatzmapping (die auf lange Zeit die Mehrheit sein werden). Zusätzlich zu den Dutzenden Stellplatzflächen noch 1 weitere Fläche für den Parkplatz insgesamt zu zeichnen, erscheint mir nicht als nennenswerter Mehraufwand. Sogar in deine site-Relation lässt es sich die parking-Fläche recht elegant als perimeter-Member einbinden.
Also, was ist eigentlich der entscheidende Grund dafür, hier überhaupt über einen Bruch mit dem bisherigen Tagging nachzudenken?
Ich zumindest schlage ja auch nicht vor, die realen Stellflächen nicht zu mappen. Ich schlage vor, die Stellflächen und die Gesamtanlage (inklusive Service-Ways und sonstiges “Zubehör”) mit jeweils passenden Tags zu mappen. Beides sind, je nach Anwendungsfall, sinnvolle Sichten auf ein und denselben Parkplatz.
+1
Ein solches umschließendes Polygon ist sogar bei der site-Relation vorgesehen, was bisher bei den Parkplätzen gefehlt hat. Also im Prinzip die Fläche, die den Parkplatz bildet. Dann hätte man zumindest als Auswerter eine Chance, den Parkplatz in der groben Version zu zeichnen/nutzen.