Kleine Fragen 2018

Mit diesem Changeset wurde dieser Abschnitt der B 271 kerzengerade gemacht. Kann man das noch sinnvoll reverten oder sollte man die Straße einfach löschen und von neu einzeichnen?

Erledigt!

https://www.openstreetmap.org/changeset/59494658

Edit: Link

https://www.openstreetmap.org/#map=19/54.47337/9.83444

Der von mir gemappte Kundenparkplatz wird nicht gerendert. Habe ich etwas falsch gemacht?

Kein Angst, der kommt schon. Vorhin war schon die Hälte da. Dauert heute etwas lange mit dem Rendern :frowning:

Gruss
walter

ps: wenn du das so angibts, ist es er leichter zu finden: https://www.openstreetmap.org/way/594140901#map=19/54.47333/9.83449

dürfen da wirklich Nicht-Kunden nicht drüberlaufen? (access=customers) oder bezieht sich das nur auf Fahrzeuge (vehicle bzw motor_vehicle=customers). Der darübergehende Fussweg ist ja nicht beschränkt.

Ich war davon ausgegangen dass der access tag bei Parkplätzen ansagt, wer dort parken darf. Wenn das nicht der Fall ist, muss ich das noch korrigieren

Das ist auch richtig und der Hinweis des Kollegen deshalb völlig falsch. access= bei Parkplätzen bedeutet etwas anderes als access= bei Wegen. Deshalb ist auch vehicle= bzw. motor_vehicle= auf Parkplatzflächen völlig falsch.

Naja, bei access access steht

Es stimmt also nicht, dass access nur für Wege gilt. Access gilt für Punkte, Wege und Flächen, einschliesslich “amenities”. Wer sich den Blödsinn ausgedacht hat und nur bei einer Tag/Value Kombination einen Tag umzudeuten, gehört geteert und gefedert.

Ist aber üblich. service= bedeutet bei highway=service etwas anderes als bei shop=car.

Bei Parkplätzen wird nur access= verwendet, denn das meint dort wer auf diesem Parkplatz parken darf, nicht wer den Parkplatz betreten darf (das gehört nämlich an den Weg der über den Parkplatz führt). Und da braucht man eben nur access=, weil es separate Tags amenity=bicycle_parking für Fahrräder und amenity=motorcycle_parking für Motorräder gibt.

Was würde dann access=customers bei amenity=motorcycle_parking bedeuten? Man darf als Nicht-Kunde ruhig drüber laufen, weil es analog zu amenity=parking nur für Fahrzeuge gilt oder darf man als Nicht-Kunde da nicht lang, weil für amenity != parking die normalen Access Tag gelten?

Das service Beispiel wiederpricht sicht mMn nicht. Die access Tag bei parking schon.

Ich stimme schon zu, dass es ungünstig ist, dass der Access-Tag hier anders verwendet wird als sonst. Dabei geht es ja auch nicht um einen mehrdeutigen Begriff. “Access” bedeutet “Zugang”, um den geht es hier eigentlich nicht, denn es können auch Fahrzeuge einen Zugang zu einem Parkplatz haben, auf dem sie nicht parken dürfen (um dort z.B. zu wenden). Man müsste eigentlich einen Tag wie “Parking:designated = public/private/customers” oder so ähnlich erfinden.

Richtig, wenn man es schafft, irgendwie über parkende Motorräder zu laufen. Das ist dann aber ein rein praktisches Problem.

Also die abweichende Bedeutung von access bei amenity=parking ist dokumeniert. Wenn Du sie auch auf amenity=motorcycle_parking anwendest, bewegst Du Dich entgegen dem, was im Wiki steht…wobei ich natürlich verstehe, warum Du so denkst. Und genau deswegen ist ein “Überladen” eines Tags blöd. Es ist nicht logisch und wo jetzt die Grenzen der Ausnahme sind, ist auch nicht klar.

Wörtlich mag es das bedeuten, in der OSM-Welt bedeutet es eher „Nutzungsrecht“. Was bei Eingängen aufs selbe hinausläuft (wer einen Eingang benutzen darf, hat Zugang), auf highways bedeutet es nicht nur Zu-, sondern auch Durchgang/-fahrt, und an amenities heißt es schlicht Nutzungserlaubnis. Wer über einen Parkplatz geht, benutzt nicht den Parkplatz, sondern nur den darüberlaufenden Weg. Erst wer parkt, benutzt den Parkplatz.

Wenn man nicht alle keys trockenbeerenausscheidend wörtlich nimmt, löst sich manch Logikwiderspruch auf :slight_smile:

–ks

Und eine kurze Frage von mir:
Wie taggt man einen Spielplatz der einen Zaun rundherum hat?
Klar den Zaun kann man einzeln taggen aber ich halte das für ein nützliches Suchinstrument weil Spielplätze ohne Zaun auch gern mal von Hunden besucht werden. Also gibt es ein Objekt das den Spielplatz UND den Zaun erfasst?

Man kann die Spielplatzfläche gleichzeitig mit leisure=playground und barrier=fence taggen, falls der Zaun die gesamte Fläche rundherum einschließt. Es gibt noch fenced=yes, das Tag ist aber veraltet und soll nicht mehr verwendet werden.

-snip- Prince war 10 sec schneller.

Aber den Eingang nicht vergessen …

Was allerdings semantisch unschön ist, weil dasselbe OSM-Objekt dann die Linie rundum sowie die eingefasste Fläche bezeichnet, also zwei unterschiedliche reale Objekte. Zusätzliche Tags wie name=* oder height=* oder material=* sind dann nicht eindeutig zuordbar.

Einfache Lösung: Zwei kongruente Ways zeichnen, einen für den Zaun, einen für den Spielplatz, dann ist das ebenso separat. Kann man machen, finde ich nicht schlimm.

Am saubersten (wenn auch komplexer) finde ich es, mit dem Way nur den Zaun zu erfassen und den Spielplatz als Multipolygon zu mappen, mit dem Zaun-Way als einzigem outer. Die Spielplatz-Tags kommen dann an die Relation. Das ist semantisch absolut sauber: der Zaun definiert die Außengrenze des Spielplatzes.

–ks

Ist der Zaun wirklich komplett drumrum, oder hat er ein mehrere Meter breites Tor / zaunloses Stück zum Eingang? Das haben die Spielplätze hier meist, da muss man dann eh separat mappen.

Ich hab bei tatsächlich völlig umzäunten Spielplätzen auch schon leisure=playground, barrier=fence gesetzt, denn das sind für mich keine 2 Objekte, sondern ein eingezäunter Spielplatz. Und aus dem Adjektiv ergibt sich dann die Nachrangigkeit.