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"!

Servus DATATPROTECT,

und willkommen bei OSM.

Drei kleine Fehler/Probleme möchte ich hier anmerken:

#1: die Firma DATAPROTECT scheint in der 2. Etage zu sein, das Gebäude (way/87406577) (#44) hat aber wohl 6 Stockwerke. Daraus schließe ich, dass in dem Gebäude noch andere Parteien sind.
In OSM werden Firmen in solchen Fällen nicht an das Gebäude gemapped, sonder als eigenständigen Punkt (Punkt 13618121884), was bereits geschehen ist. Womit, Problem #2, "DATAPROTECT" im Gebäude #44 zwei mal existiert.

Vorschlag #3: office=it statt office=company.

'company' ist ein allgemeiner Sammelbegriff für den Fall, dass nicht ganz klar ist, in welche Kategorie die Firma bei OSM fällt.

VG
Toni

Hier scheint office=it aber wohl sehr gut zu passen.

Gerne!

Mir fiel noch ein, dass Navis unterschiedliche Update-Intervalle haben. OsmAnd zum Beispiel läd OSM-Daten immer am 1. eines Monats runter, bearbeitet sie und stellt die dann den (normalen, nicht-Abo) Benutzern ein paar Tage später zur Verfügung. Andere landen Daten einmal in der Woche, ...

Von daher war es hier gut, schon einmal mit access:conditional vor dem 1. März zu arbeiten, bevor highway=construction dann am 2. März aktiviert wird / werden könnte.

Die Standardkarte zeigt Veränderungen ja im Prinzip innerhalb weniger Minuten, das gilt leider nicht für alle Karten-Stile und Navis.

Beim MVV habe ich noch nicht herausfinden können, welche Strecke denn der 361er fahren wird. Die GTFS-Fahrplandaten des MVV enthalten nur die Haltestellen und Abfahrzeiten, nicht aber die Strecke (außer für München-Stadt, da gibt es GTFS von der MVG). Außer!? Ich werde mal einen Verbindungssuche auf der MVV-Webseite für Dienstag machen.

Marc, ça marche aussi avec JOSM, mais peut-être tu as essayė de trouver l'erreur quand l'erreur était déjà corrigée ?
Toni

Oops, und dann werden wir (ich) uns wohl noch um den 361er Bus kümmern müssen. Mal schauen, was der MVV hierzu in den März-Fahrplandaten (GTFS) rausspuckt.

changeset/179080656#map=18/47.875469/11.706925&layers=T

https://ptna.openstreetmap.de/results/DE/BY/DE-BY-MVV-Analysis.html#bus_361

Ich werde opening_date mal in end_date = 2026-11-01 (im ISO-Format) ändern und start_date = 2026-03-02 hinzufügen.

Servus und Danke für den Eintrag.

Das 'landuse' ist auf der Karte ganz 'nett' anzuschauen, hat aber auf "Navis" keine Auswirkungen.

Da die Baustelle recht langzeitig ist, ist die allgemeine Vorgehensweise, die Straße "B 13" auf highway=construction zu setzen und zusätzlich construction=primary (der derzeitige Wert von highway) zu verwenden. Das wird von Navis verstanden und auf den Karten auch entsprechend angezeigt.

Eine kurzzeitige Sperrung wird mit einem 'conditional' gemapped, das verstehen viele Navis mittlerweile auch.

access:conditional = no @ (2026 Mar 30-2026 Apr 13) auf kurzen Stücken der Straßen um die Kriege-Kreuzung herum.

Bei weiteren Fragen bitte einfach melden

Viele Grüße
Toni aus Ottobrunn

Ähm, das war Bus 451.

Oops: fence%20type=*?uselang=en#Values

Servus,

meinst du mit 'wire_mesh' eventuell 'chain_link'?

fence%20type=*?uselang=en#Values

Gruß,
Toni

Servus,

Google Earth und Google Maps sind für OSm tabu, das sind keine legalen Quellen für uns.

Bitte den Changeset rückgängig machen.

Gruß
Toni

Yep, zumal im Park Fahrräder noch nicht einmal schieben darf.

Hello Ismael David,

the 'check_date' value should be specified in ISO 8601 format: YYYY-MM-DD.

See also https://ptna.openstreetmap.de/results/BO/C/BO-C-Cochabamba-Analysis.html

Best regards,
Toni

Hallo,

hier, in diesem CS, hast du in der relation/2513344

- Bus N22: Alt-Lübars => Tegelort (2513344)

alle Stops, Platforms und Ways gelöscht. Die Relation hat keine 'member', was prinzipiell bei einer Relation nicht vorkommen darf

Kannst Du bitte die 301 'member' der Version 124 dieser Relation relation/2513344/history/124 wieder einfügen, die Relation in den Stand "124 " versetzen. Ein kompletter "revert" dieses CS wäre mit "Kanonen auf Spatzen schießen"

JOSM hat wohl ein "revert CS" Plugin, damit habe ich aber bisher nur komplette CS revertiert.

"CS" = ChangeSet"

Gruß
Toni

Fertig.