Danke, ich schaue mit das morgen mal an.

Hi,

bitte hier das service=emergency_access dran lassen. Das ist wichtiger als emergency=*

Wobei emergency=emergency_access falsch ist, da der Wert audf Straßen und Wegen nur 'yes', 'designated', 'no', ... sein kann aber nicht 'emergency_access'.

osm.wiki/DE:Key:emergency

osm.wiki/DE:Key:service

Gruß
Toni

Servus,

hier hast Du den neuen Way parallel, fast schon über die existierenden Wege gemapped. Das ist nicht korrekt.

Bitte die vorhandenen Zufahrten und sich anschließenden Fußwege mit "emergency=designated" kennzeichnen und dann gegebenenfalls das letzte, kurze Stück als highway=service + service=emergency_access mappen und wieder: ohne 'name' = 'DLKZufahrt'

Die hauptsächlich Nutzung des, von der Straße her gesehenen, ersten Stück ist highway=service ohne service=emergency_access aber emergency_designated. Die sich anschließenden Fußwege sind hauptsächlich Fußwege mit möglicher Nutzung durch Feuerwehr. Daher bleibt hier highway=footway ohne service=* amer mit gegebenenfalls emergency=designated.

HTH
Toni

Servus MaxPower089,

Willkommen bei OSM.

"DLAK Zufahrt" sehe ich hier nicht als offiziellen Namen der Feuerwehrzufahrt, das ist wohl eher eine Beschreibung ("was es ist, nicht wie es heißt")

Daher ist 'name' = 'DLAK Zufahrt' nicht korrekt, gemäß dem Mantra: "name is the name only".

BTW: was heißt "DLAK" eigentlich?
"vollautomatische Drehleiter (Korb)"? Dann gehört das definitiv nicht in 'name', eher nach 'description'.

Gruß
Toni

nicht "highway=bicycle"

Servus,

type=route ist hier falsch, oder zumindest fehlt hier route=pipeline

route=pipeline

Es sieht mir aber nach einer Sammelrelation aus, die es (anders als bei Wikipedia die "Category") nicht gibt.

"Alle Hauptwasserleitungen Münchens" lassen sich als Overpass-API query mit ref~'$HW' && man_made=pipeline && substance=water && osm.wiki/Tag:operator=... && ... ermitteln.

Die Pflege von Sammelrelationen hat sich im Übrigen als fehleranfällig herausgestellt, solche Relationen sind fast immer unvollständig.

Up-to-you.

Gruß
Toni

Oops, schlecht formuliert:

> Der Weg wird an den Hauswänden geteilt. <strike>, der Teil, d</strike> Der durch das Haus führende Teil bekommt

Hallo, ich schon wieder.

Ein kleiner Tipp zum korrekten Mappen von Hausdurchgängen (solche ohne Haustür).

Schau die bitte mal den Weg durch Hausnummer 13b an, wie das nach meinen Änderungen aussieht.

Der Weg wird an den Hauswänden geteilt, der Teil, der durch das Haus führende Teil bekommt ein tunnel=building_passage (ohne layer=-1). Das gilt nur für solche Wege, wo ich keine Haustür aufsperren muss (das wäre dann ja ein Flur und kein Durchgang). Sollte dort ein abschließbares Tor sein, so gilt für die dahinter liegenden Teile access=private.

Viele Grüße
Toni

... Bahnhofplatz 4: ...

Servus, danke und: "alles gut".

Bzgl. "SWMH GmbH":

Für den Fall, dass jemand im Auftrag einer Firma bei OSM tätig ist bitten wir als Community um die Beachtung einiger Regeln:

- Organisiertes Mappen
osm.wiki/DE:Organised_Editing_Guidelines

- Automatisiertes Mappen
osm.wiki/DE:Automated_Edits_code_of_conduct

- Import von Daten aus anderen Quellen osm.wiki/Import/Guidelines

Und natürlich immer wieder: die Lizenz der genutzten Daten beachten osm.wiki/DE:Import/Guidelines#Schritt_3_-_Lizenz_absichern

Z.B. sind "Google" und andere kommerzielle Quelle und sogar der "Bayern-Atlas" als Quelle tabu.

Viel Spas noch. Liebe Grüße
Toni

Hallo,

Du hast hier die Baustelle "Sauerlacher Straße" in Deisenhofen wieder als highway=residential (statt construction) und auch die Straßenbegleitenden Fußwege als nutzbar hinterlassen. Die sind alle bis Ende November 2026 gesperrt (mit Ausnahmen: Anlieger, ...).

Das würde ich gerne wieder in den vorherigen Zustand versetzen.

BTW: "swmhlea", steht "swm" für "Stadtwerke München"?

Gruß,
Toni aus Ottobrunn

war am Donnerstag erst wieder vor Ort und hatte auch diesbezüglich Kontakt zur Gemeinde Oberhaching.

Sorry, ist Linie 212

Eher umgekehrt. 'higway=bus_stop' ist genau genommen nur für OSM Nodes definiert. 'local_ref' wird auf der Transport Karte nur gerendert, wenn es an einem node hängt.
Die südliche Haltestelle "5" ist wie du beschreibst, quasi eine eigene Infrastruktur.
Grüße
Toni

Servus,

die "description" ist redundant. Ich hatte das getagged, was auf dem Schild steht.

Anderes Thema: die 4 Haltestellen hier haben in OSM eine highway=platform area.
Das ist bei allen 4 aber eigentlich nur ein ganz normaler Bürgersteig (mit Busbucht: bus_bay) hat also keine dedizierte Platform-Infrastruktur, rechtfertigt mMn kein soclhes Mapping. Sieht also so aus wie die SEV-Haltestelle (Richtung Ebersberg) im Südosten der Platzes.

Ich überlege, die 4 areas hier zu löschen, deren Tags auf die 4 highway=bus_stop nodes zu übertragen, die Relationen anzupassen.

Etwas anders sieht sieht es bei der Haltestelle '5' aus, hier auf der anderen Straßenseite.

Was ist deine Meinung?

Gruß
Toni

Um 10:30 läuft eine neue, von mir "beantragte" Analyse.

https://ptna.openstreetmap.de/results/queue.php

Das kannst du übrigens auch. Im Analyse-Report gibt es am Anfang bei "Datum der Daten" einen Knopf. Alle 15 wird geschaut, ob irgendwo ein Knopf gedrückt wurde.
Gruß
Toni

"Aller Anfang ist schwer" heißt es ja so schön.

In er Regel tut sich im Laufe der Zeit recht wenig an den Relationen. Häufigste Fehlerquelle ist ein Edit in iD, wenn man eine Straße wegen unterschiedlichem Belag, Tempolimit, ... aufspalten muss und deren Reihenfolge in der Relation nicht mehr stimmt. Un dann natürlich noch Fahrplanwechsel, Baustellen (siehe 361er auf Miesbacher Straße in Holzkirchen oder 222, 222V, X203, X320, 371 auf Sauerlacher Straße in Deisenhofen).

Aber ja, je mehr Details, desto größer der Wartungsaufwand.

PTNA läuft jede Nacht zwischen 2-4 Uhr Ortszeit der betreffenden Gegend: DE, US, AU, ...

Für den WBB gibt es leider keine GTFS (General Transit Feed Specification) Daten des MVV oder so. Mit diesen Fahrplandaten kann man die Routen zusätzlich vergleichen: https://ptna.openstreetmap.de/results/DE/BY/DE-BY-MVV-Analysis.html#bus_361 oben rechts das komische Icon neben dem "GTFS", ... und wenn der Overpass-API Server gnädig ist und Daten liefert: https://ptna.openstreetmap.de/gtfs/compare-routes.php?feed=DE-BY-MVV&release_date=&route_id=mvv-12-361-1&relation=15862268 und https://ptna.openstreetmap.de/gtfs/compare-trips.php?feed=DE-BY-MVV&release_date=&trip_id=mvv-12-361-1-3-22-R-23-TuWe%235-90-36&relation=15862692

Aber vielleicht könnte man ja ... ich "spinne" mal rum: für den WBB auch GTFS-Daten erzeugen. Ach nee, selbst bei nur einer Linie ist das manuell doch sehr aufwändig. Der MVV erstellt GTFS aus seinen internen Datenbanken heraus , quasi als "Abfallprodukt" aus den Fahrplandaten.

Gruß
Toni

Servus Bert,

PTNA akzeptiert derzeit noch beide 'network'-Werte.

Könntest du noch 'ref'='WBB' setzten, denn PTv2 ('public_transport:version' = '2') braucht das. Bei PTv2 ist vieles optional, 'ref' aber nicht.

osm.wiki/w/index.php?title=Proposed_features/Public_Transport&oldid=625726

VG
Toni

Servus sid6point7,

Ich habe den "Waakirchner Bürgerbus" mal in die Übersicht und Analyse der ÖPNV-Verbindungen im Großraum München aufgenommen.

- 'network' = 'Waakirchner Bürgerbus' wäre passender?

https://www.waakirchen.de/de/leben/mobilitaet/buergerbus

Du hast die Route hier als 'public_transport:version' = '2' getagged.

Die Reihenfolge 'member' ist hierbei definiert als: "stop1, platform1, stop2, platform2, ... letzter_stop, letzte_platform, Straße1, Straße2, ..." in der Reihenfolge wie sie vom Bus angesteuert/benutzt werden.
Die Sortierung müsste also noch angepasst werden.

Aber das wird PTNA https://ptna.openstreetmap.de/ für den MVV_bereich https://ptna.openstreetmap.de/results/DE/BY/DE-BY-MVV-Analysis.htm , Ortsbusse https://ptna.openstreetmap.de/results/DE/BY/DE-BY-MVV-Analysis.html#A3.1.4 morgen dann entsprechend melden.

Viele Grüße,
Toni aus Ottobrunn

Gut, dann ändere ich das mal.

Servus,

ich würde das hier eher als historic=memorial sehen.

Gruß
Toni

Schön, dich hier mal wieder zu "sehen"!