Kleine Fragen 2017

Oh, ich sehe schon, Diskussion losgetreten.

Also ich konnte das Problem gut lösen, indem ich den Weg so gemappt habe, wie es
a) die Gesetzeslage und die Beschilderung vor Ort vorsieht - als Fußweg mit highway=footway und
b) hier steht auch, wie der Weg interpretiert wird.

Auch die Bezeichnung “designated” ist eindeutig bezüglich Nutzungspflich als “ggf.” im Wiki beschrieben. Lediglich der Eintrag, dass auch highway=path mit foot=designated für Zeichen 239 verwendet werden kann, war schlicht unvollständig. Zeichen 239 mit highway=path sollte dann, wenn man das hier berücksichtigt, dann noch mit motor_vehicle oder bicycle=no versehen werden. Sonst würde mir der Radrouter ja über den Weg schicken.

Es erscheint mir also höchst umständlich, einen Fußweg mit Zeichen 239 mit path zu kennzeichnen, wenn es doch für diesen ohnehin ein anderes Tag gibt.

Die Bedenken zur Nutzung in den Niederlanden werden durch die dort anderen Access Restrictions in highway=cycleway abgebildet und die genannten Ausnahmen müssen nicht separat angegeben werden.

Hoffe, ich habs richtig verstanden :wink:

Letzter Beitrag von mir zu dem Thema, dann kommt was anderes :wink:

Eben diese Widmung besagt ja schon, dass dort dann erstmal nur die spezielle Nutzungsgruppe drauf darf: https://de.wikipedia.org/wiki/Stra%C3%9Fenwidmung

und

Für das Wiki mag das vieleicht stimmen, aber in der Praxis begegnet mir sowas so gut wie nie.

Generell habe ich manchmal das Gefühl, dass wir uns es hier schwerer machen, als eigentlcih notwendig :slight_smile:

So,

==Themawechsel==

Ein Kiosk, der ÖPNV-Tickets verkauft, bekommt der ein vending=public_transport_tickets?

Ein User schreibt inzwischen an solche Verkaufsstellen vending:VRS=tickets. Das finde ich sehr unschön, da das allerhöchstens lokal ausgewertet werden kann. Außerdem ist tickets zu ungenau. Daher hätte ich gerne was besseres, was ich vorschlagen kann, bin aber nicht fündig geworden.

vending=public_transport_tickets gibt es ja auch schon bei Automaten, das liegt daher nahe, allerdings ist das Tag vending=* bei Kiosken bisher nicht wirklich gebräuchlich…

Nebenbei: Entsprechend würde ich dann auch die anderen Tags umschreiben in public_transport_tickets:network=VRS und public_transport_tickets:operator=KVB. Der Kiosk ist ja nicht direkt Mitglied im VRS.

Eure Meinung?

Grüße

Edit: Der User war doch meines Wissens nicht von der KVB, da hab ich was durcheinander geworfen.

shop=public_transport_tickets

hatten wir vor kurzen bei Eintrittskarten:
https://taginfo.openstreetmap.org/search?q=admission_tickets#values

nope, bleibt immer noch im Wesentloichen ein shop=kiosk. Ist also nicht möglich.
Dazu fehlt da auch noch ein lotto=yes und dann ist das ganze auch noch ein DHL-Shop…

shop=kiosk
cash point=public_transport_tickets (oder public_transport_tickets=yes)
lotto=yes
amenity=post_office
post_office=DHL
post_office:type=post_partner

EDIT: nur ob es genutzt wird?

https://taginfo.openstreetmap.org/search?q=cash_point
0 Ergebnisse für cash_point…
dann doch vending=public_transport_tickets?

Hi, ich habe ein Problem mit dem Seepark in Berlin-Karlshorst. (http://www.openstreetmap.org/#map=18/52.48158/13.51405)

Ich bin nicht sicher, wie man den am besten mappt.

Es ist ein Park, der ringsum von einigermaßen dichter Bewaldung begrenzt ist. In der Mitte ist eine Grasfläche, auf der wiederum ein Spielplatz ist. Im “Wald” gibt es zudem 2 Sportflächen.

Ich habe den Wald als multipolygon gemappt und da die Grasfläche und die Sportplätze ausgestanzt. Aus der Grasfläche wieder habe ich den Spielplatz gestanzt (ist ja kein Gras mehr, sondern Sand), sodass die Grasfläche Teil von zwei Multipolygonen ist, also Grass (outer) und forest (inner). Allerdings fehlt nun die Information für den park. Also habe ich das Multipolygon mit Attribut “park” versehen, das eigentliche outer-Shape mit forest. Nun meckert JOSM, dass man landuse-Tags nicht ans outer-Shape packt, sondern als attribut des Multipolygons. Das ist aber schon der Park.

Nun habe ich versucht, einfach das Wald-Polygon zu lassen und habe ein deckungsgleiches Shape als Park drüber gesetzt. Das gefällt mir aber irgendwie nicht, da man das nur sehr schlecht wieder bearbeiten kann. Außerdem scheint der Renderer nun den Wald zu ignorieren (jaja, wir mappen nicht für den Renderer, aber wenn ich mir bspw. den Park Babelsberg anschaue, geht ja Wald in Park, ich muss also einen Fehler gemacht haben).

Ich könnte auch dem Multipolygon beide Attribute geben, aber auch das ist nicht so richtig sinnvoll, oder?

Wie geht mal also damit um, wenn Waldgrenze = Parkgrenze…

Vielen Dank für die Antworten.

Ist es Park oder Wald - ich vermute Park.
Außerdem kann das Gras den Spielplatz ausgrenzen - so ist dort schon keine inner-Relation erforderlich - dann sind gras, playground, 2x leisure nur inner im outer der MP-Relation leisure=park.

Warum darf ein Park keinen Wald enthalten, also beides sein? Gibt Doch genügend Gegenbeispiele…

Wir haben natural=wood, was ein naturbelassener Wald sein soll und landuse = forest, für forstwirtschaftliche Nutzung. Ein Park mit Bäumen ist keines davon. Dafür gibt es landcover = trees, ein mit Bäumen bedecktes irgendwas, das durch andere Tags als Park oder Spielplatz oder was auch immer bestimmt wird.

Ah, landcover kannte ich noch nicht. Aber ab wann wird denn trees zu forest?

Und das führt letztlich nur wieder zum Ursprungsproblem: Wie gebe ich einer Fläche das Attribut Park und ein landcover-Multipolygon?

@geri-oc: Was meinst du mit ausgrenzen?

Dafür gibt’s allerdings wohl noch kein deutsches Wiki?

Also, was mir auffällt:
Das äußerste outer ist mit leisure=forest getaggt, das gibt es so nicht, besser landuse=forest (wenn forstwirtschaftlich genutzt).
Das zugehörige inner mit der Wiese ist nicht als landuse=grass getaggt, sondern gar nicht.

Das outer mit der Wiese ist als leisure=grass getaggt, was es so auch nicht gibt, besser landuse=grass.

Das landuse=gras entfernen, da “Park ja Rasen- und Baumflächen beinhaltet”.

Warum willst du in einem Park Baumflächen und Rasenflächen trennen?
(Natürlich kann man es zerpflücken und mit mehreren outer - die auch wieder MP-Relationen sind - zum Park bauen. Aber warum so kompliziert? Ganz einfach den Park als Fläche und die “innenliegenden” als POI-Node geben alle Informationen.)

Und zur MP-Relation siehe auch Geofreund1 - erst einmal ordnen …

Danke für den Hinweis, da ist wohl etwas durcheinander geraten.

Zu dem Warum: Ich finde es schon relevant zu wissen, wo in einem Park eine freie Wiese ist und wo es eher schattig ist. Größere Parks, wie Sanssouci oder den Tiergarten differenziert man ja auch. Hat am Ende ja auch Orientierungsgründe.

http://wiki.openstreetmap.org/wiki/Landcover ist ein guter Hinweis. Ich werde daraufhin tatsächlich einige Parks, in denen ich gemapt habe, überarbeiten müssen.
leisure=park + landcover=grass und leisure=park + landcover=trees

Jetzt müsste nur noch jemand die Zuständigen für die OSM-Standard-Karte oder z.B. die Humanitarian bitten, Landcover zu rendern. Ich habe bei einem Park versuchsweise landuse=forest durch lancover=trees ersetzt mit dem Erfolg, dass dort jetzt nichts mehr zu sehen ist außer der allgemein für Parks stehenden hellgrünen Fläche: https://www.openstreetmap.org/way/519718134
Ich nutze ja z.B. gerne die OSM-Standardkarte zur Online-Orientierung und dafür ist es - wie S-Man42 geschrieben hat - schon wichtig zu sehen, welche Flächen in einem Park dicht mit Bäumen bestanden sind und wo offene Grasflächen sind.

Wo liegt eigentlich das Problem dabei, es einfach zu halten und über die Parkfläche eine Forestfläche zu legen? landuse=forest heißt doch “bewirtschafteter Wald”. Bewirtschaften heißt doch nicht nur “ernten”. Natürlich werden Bäume in Parks bewirtschaftet, nämlich erhalten als Schutz- und Erholungsraum, gepflegt usw.

Der Wunsch ist beim Carto Team schon bekannt, landcover gibts ja auch schon seit 2010.

https://github.com/gravitystorm/openstreetmap-carto/issues/2548

Sehe ich auch so.