Kleine Fragen 2019

Nein, da track nicht für Straßen innerhalb bebauter Flächen verwendet werden soll - dort sind sie residential.
Aber natürlich sollte die Einteilung nicht unbedingt den Gegebenheiten der Vergangenheit folgen, sondern sich am Jetzt-Zustand orientieren (was historische Bedeutsamkeit ja nicht ausschließt).

Alternativ könnte man über highway=unclassified nachdenken, falls der Weg asphaltiert ist.
Doch die Freigabe für Forstwirtschaft ist ein starkes Argument für track.

Das “highway=” (track, service, residential, unclassified) Tagging von Strassen/Wegen folgt der Nutzung bzw. Widmung und keinesfalls und niemals der Wegbeschaffenheit! :wink:

Fuer die Wegbeschaffenheit gibt es eigene Tags: surface, smoothness, width, …

Ich würde den Waldweg zwischen der Straße “Am Neuwirtshaus” und dem einzelstehenden Haus von highway=track in highway=service oder Highway=unclassified ändern, da dieses Wegstück nach Deiner Beobachtung als Zufahrt zu diesem Haus genutzt wird (Was von den beiden Möglichkeiten, darüber streiten sich meiner Beobachtung nach die Gelehrten). Den Weg “Alter Kahler Weg” dann aber im weiteren Verlauf bis zur Siedlung als track belassen (Schranke, nur Forstwirtschaftl. Verkehr)

Da das als Zufahrt zu dem einzelnen Haus genutzte Weg sicherlich wie ein üblicher Waldweg lediglich eine geschotterte Oberlfäche hat, kommt natürlich noch surface=compacted drann.

Und natürlich gibt es Waldwege, die einen Namen haben. Bei mir um die Ecke gibt es z.B. einen Waldkurpark, da hat jeder Waldweg ein schönes Straßenschild aus Holz: Häherweg, Bussardweg, Meisenweg… Das sind aber trotzdem reine Forst- und Spazierwege. Und nein, dass sind keine Wandwegsbezeichnungen für irgendwelche Rund- oder Streckenwanderwege. Bei letzteren habe ich hier in der Gegend schon reihenweise name=Hermannsweg oder name=Lönspfad etc. in ref=Hermannsweg etc. umbenannt.

Nur rein interessehalber: Sprichst du da von “durchgehenden” Wanderwegen? Wären Relationen da nicht besser gewesen?

Ja, genau, niemals. Ganz eindeutig, immer. Wie in allen Wikis beschrieben. :smiley:

Wenn am Wegesanfang schon die fortwirtschaftliche Nutzung beschildert ist, stellt sich doch die Frage eigentlich nicht.
(Ist das Haus vielleicht sogar ein Forsthaus?)
Zum Haus kommt man doch nur mit forstwirschaftlichen Belangen, also kann das nur in zweiter Linie Zufahrtsweg sein.
Außer man bezieht den nichtmotorisierten Verkehr und den Eselskarren mit ein, da dieser Verkehr sogar überwiegen könnte, wäre dann etwas anderes möglich.
Also von der Nutzung her spricht doch alles für track.

Und vom Erscheinungsbild her? Ein typischer Waldweg - wieder track.

Der Zweck könnte zwar auch die Zufahrt (service) sein, aber da der Weg einen wie auch immer gearteten historischen Namen hat und wohl weiter als nur zu dem Haus führt, müsste man den Weg unterteilen, wie Galbinus vorschlägt.
Ob eine Teilung allerdings sinnvoll ist (ich gehe davon aus, dass der Weg vor und hinter dem Haus sich nicht wesentlich unterscheiden), ist eine andere Frage und bietet je nach Betrachtung Futter für die Gelehrten.
Oh, halt, das wäre ja wieder über die Beschaffenheit definiert… :wink:

Landuse Konzept
Kann mir jemand das landuse Konzept von osm erklären?
Ich verstehe es so: z.b. landuse=residential legt ein Wohngebiet fest.
Darin befinden sich Gebäude, die aber Teil des Wohngebietes sind und daher nicht den landuse “aufbrechen” (kein eigener landuse und auch nicht per MP ausgenommen)
Auf hohen Zoomstufen werden die Gebäude so klein, dass sie nicht mehr sinnvoll angezeigt werden können, daher wird stattdessen nur der landuse (residential / commercial / … ) angezeigt (graue / rote Fläche etc.). So weit so gut.

Warum wird dann aber mit z.b. landuse=grass Elementen der landuse “aufgebrochen”?
Eine Wiese in einem Wohngebiet (oder der Garten eines Hauses) sind ja trotzdem inhaltlich residential.
Auf hohen Zoomstufen sieht ein Wohngebeit dann sehr zerstückelt von Grünflächen aus:
https://www.openstreetmap.org/way/572510749#map=13/48.1206/11.6812

Würde man stattdessen natural=grass* verwenden, wäre der landuse nicht “aufgebrochen” und der mapper könnte die eine einheitliche zusammanhängende Fläche des Wohn/Gewerbe/etc. -gebietes anzeigen.
Das tut der standart-mapper zwar derzeit wohl auch bei der Verwendung von natural=* nicht, aber er könnte es recht einfach machen. (und ich glaube die “Humanitarian” Ansicht von osm tut bereits genau das)

  • Dass es einen kleinen aber signifikanten Unterschied in der Bedeutung von landuse=grass und natural=grassland für die Beschaffenheit der Grünfläche gibt, ist mir bekannt.
    Das ließe sich aber mit einem natural=grassXYZ tag, das die gleiche Bedeutung wie landuse=grass bekommt recht einfach lösen und man hätte wieder sinnvoll zusammenhängende landuse Bereiche.

Das ist aber keine kleine Frage. :wink: Das gibt eine Riesendiskussion …

Daher erst mal nur zu einem Punkt:

Hm, natural=grass* wäre auch etwas suboptimal, weil es eine „natürliche“ Grasfläche beschreibt, und die meisten Grasflächen in Wohnorten sind alles andere als natürlich. Es gibt aber genau für das von Dir angesprochene Problem schon lange den Vorschlag, landcover=* zu verwenden, im Beispiel also landcover=grass. Das würde das Problem elegant lösen. :slight_smile: Warum setzt sich landcover=* dann nicht durch? Keine Ahnung … u.a. aber wohl, weil „man“ nicht gerne Tags verwendet, die nicht gerendert werden.

für ein Wohngebiet würde ich place verwenden, entweder neighbourhood, oder falls es neighbourhoods innerhalb gibt, quarter. landuse beschreibt eine Fläche die überwiegend dem Wohnen dient (d.h. Gärten auf den Grundstücken wären drin, Kleingärten und öffentliche Grünflächen wie Parks nicht, Straßen auch nicht)

Frage: Kann ich highway=bus_stop an neben der Strecke platzierten Haltestellen bedenkenlos löschen, wenn dafür public_transport=platform (als node oder node innerhalb einer Strecke/area) eingetragen ist?
Ich habe hier viele verwaiste Haltestellen, die nicht Teil von route-Relationen sind (aber existieren).

Und wie sieht das aus, wenn zwar bereits nach Schema 2 getagte stop-Position auf der Straße notiert ist, die zugehörige Haltestelle aber als area (public_transport=platform) mit einem enthaltenen node mit highway=bus_stop gekennzeichnet ist? Was spricht gegen das Löschen?

Auf welche Fallstricke müsste ich bei Überführung von Schema 1 nach Schema 2 achten?

Doku:

Ach du liebes Bisschen.
Als Bug Report seit 2014.
Zum Schämen.

Also immer zusätzlich highway=bus_stop an die platform.
Bloß kein Taggen fürs Rendern. :rage:

Dass es da einen Unterschied gibt, hatte ich oben ja schon geschrieben.
Das Problem ist, dass landuse=grass ja auch falsch ist, da kein landuse.
Man hat quasi die Wahl zwischen 2 Varianten die beide falsch sind. (oder die 3. die nicht gemapt wird …)

Gerade bin ich beim Suchen auf das hier gestoßen: https://wiki.openstreetmap.org/wiki/Key:managed
Würde das nicht zu natural=grass passen?

Die landcover tags werden auch deshalb nicht gerendert, weil die mapper als Fallback fast immer noch einen tag zusätzlich dranmachen, der gerendert wird, landuse=forest oder natural=wood, landuse=meadow oder gras, etc.
Es schmerzt daher nicht, wenn man den tag ignoriert, und solange er nicht gerendert wird, wird sich das auch nicht ändern.

Die Routen sind ganz anders. Bei den Haltestellen ist es einfacher:

Man muss bei den alten PTv1-Haltestellen nichts überführen. Wenn man mit einem highway=bus_stop-Node für eine Haltestelle zufrieden ist, dann reicht das völlig. highway=bus_stop kann aber nur an Nodes. Dieser Node muss in allen PTv1/2-Relationen angegeben werden.

highway=bus_stop neben der Straße ist eine Platform in PTv2. Wenn man da zusätzlich public_transport=platform dranschreibt, dann ändert sich dadurch nichts … aber der JOSM nimmt dann automatisch die richtige Rolle “platform” in den Relationen und man muss es nicht selbst dranschreiben. Macht man da aber zusätzlich noch eine Platform (Linie oder Fläche) hin, dann sind das zwei Platforms in PTv2 und damit falsch.

highway=bus_stop auf der Straße ist eine Stop-Position in PTv2. Wenn man da zusätzlich public_transport=stop_position dranschreibt, dann ändert sich dadurch nichts … aber der JOSM nimmt dann automatisch die richtige Rolle “stop” in den Relationen und man muss es nicht selbst dranschreiben.

Zum Rendern:
In PTv2 darf man die Objekte für einmaliges Anhalten des Fahrzeugs auf drei Arten mappen:
1.: ein Stop und keine Platform mappen (Der Stop kommt in die Relation)
2.: kein Stop und eine Platform mappen (Die Platform kommt in die Relation)
3.: sowohl Stop als auch Platform mappen (Dann müssen immer beide in die Relation)
Jetzt stehen die Renderer auf dem Schlauch: Nur die Stops anzeigen reicht nicht wegen “2.”. Nur die Platforms anzeigen reicht auch nicht wegen “1.”. Beide anzeigen überfüllt die Karte. Da nach PTv1 aber einer der beiden und nie zwei ein highway=bus_stop haben, nimmt man den highway=bus_stop-Node für die Anzeige.

Danke.
highway=bus_stop an die Haltestelle neben der Straße zu setzen, macht schon Sinn, da sie an einigen Stellen nicht nur einfach auf der gegenüber liegenden Straßenseite sind.
Oder weil es tatsächlich für beide Richtungen nur eine Haltestelle gibt und der Bus eine Schleife fährt.
Die Stop-Positionen auf der Straße (v2) selbst lege ich dann zusammen, wenn die Haltestellen nicht sehr weit auseinander liegen.
Nicht sehr weit heißt für mich, nicht viel weiter als eine Buslänge, wobei ich die Halteposition vorne beim Fahrer tagge.
Die Straße weiter zu fragmentieren, macht für mich nicht sonderlich viel Sinn. Zwar könnte man beispielsweise angeben, welche lane benutzt wird, aber dann müsste man konsequenterweise auch Haltebuchten als zusätzliche Spur eintragen und mit Restriktionen versehen.
Das halte ich (derzeit und in meiner Region) aber für overkill. Bei schön ausgemappten Gebieten kann das wieder anders aussehen.

In JOSM hat die PTv1 Notation den Vorteil gegenüber PTv2, mit dem blauen Symbol in der Anzeige deutlich leichter erkennbar zu sein, als das braune platform-Symbol.
Besonders unschön wird es, wenn man ein separates amenity=shelter mit shelter=public_transport daneben setzt (schwer unterscheidbar). Ich mache das gelegentlich, weil die Bushäuschen beispielsweise auf der Radfahrerkarte angezeigt werden und diese Info bei einsetzendem Regen ganz nützlich ist.

Dafür gibt es als zusätzliches Tag am “highway”: bus_bay=left|right|both (gibt es noch =yes für Einbahnstraßen?).

Was wieder eine Segmentierung des ways nach sich zieht, aber eine zusätzliche Spur für die “nicht baulich getrennte” (!) Haltebucht vermeidet.

Das kommt darauf an, wie man “an die Haltestelle” versteht:

Es ist völlig in Ordnung, an das Objekt mit public_transport=platform zusätzlich highway=bus_stop zu schreiben. (Was man aber nur darf wenn es ein Node ist.)

Wenn man aber zusätzlich zu einem Objekt mit public_transport=platform ein anderes Objekt mit highway=bus_stop hat, dann ist das falsch. Man hat dann nach PTv2 zwei Platforms. Jede Platform und jeder Stop muss aber immer in der Routenrelation angegeben werden. Man kann aber in PTv2-Routen keine zwei Platforms zu einer Haltestelle angeben. Die Folge dieser Verletzung der PTv2-Regeln ist, dass jetzt auch kein einfaches Nachschlagen der an diesem Objekt haltenden Busse mehr möglich ist.

Moin,

ich brauch mal wieder einen Flyer - und der sollte an die aktuelle Situation angepasst sein:

Die Flyer auf https://wiki.openstreetmap.org/wiki/Flyers_and_posters/Flyers sind mMn etwas veraltet. Es gibt keinen Hinweis auf die Nutzung von Smartphones als Logger und dass man damit georeferenzierte Bilder machen kann, sollte auch drin stehen. Nur Luftbilder und GPS ist nicht mehr zeitgemäß.

Kennt jemand noch andere Quellen?

Evtl bastel ich mir einen eigenen Flyer, da ich auch ein Feld mit den Kontaktdaten des Mappers haben will. Aber eine möglichst moderne Vorlage wäre nicht schlecht.

Gruss
walter

Das hier ist historisch ein zusammenhängendes Haus, hat aber in real zwei getrennte Eingänge und Hausnummern:

https://www.openstreetmap.org/way/129751887
https://www.openstreetmap.org/way/684918603

Was tun?

Adressen an die Eingänge und Haus mit (3D-) Informationen.