OpenStreetMap logo OpenStreetMap

Changeset When Comment
179356154

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.

179080656

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.

179068990

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

179080656

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

179080656

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

179080656

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

178692371

Ähm, das war Bus 451.

178194518

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

178194518

Servus,

meinst du mit 'wire_mesh' eventuell 'chain_link'?

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

Gruß,
Toni

177740919

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

177754949

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

177615286

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

177232957

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

177072891

Fertig.

177072891

> So wie ich es sehe müssten also die 10 relevanten Relationen von way/1126917034 nach relation/20067580 verschoben werden,

Im Prinzip ja. In der OSM-Struktur ist der Way way/1126917034 derzeit Mitglied ('member') der 10 Relationen und müsste aus der Liste er Mitglieder der 10 Relationen herausgenommen werden und (!) an der selben Stelle der Mitgliederliste durch die Relation relation/20067580 ersetzt werden - und hier patzt iD.

Der bessere Editor ist JOSM (josm.openstreetmap.de), gerade für Relationen sehr zu empfehlen. Das ist ein JAVA-basiertes Programm, das auf dem PC läuft. Hat leider eine gewisse Lernkurve, auf Dauer aber das deutlich bessere Werkzeug.

Da ich nun weiß, was geändert wurde, warum und dass es notwendig war, ... kann ich die 10 Änderungen machen - in JOSM

Gruß
Toni

177072891

Hallo maxi_,

bei dem Edit sind am Bahnsteig Way way/1126917034 leider alle Informationen verloren gegangen, vergleiche bitte die vorangegangene Version way/1126917034/history/21

Dadurch kommt es zu Problemen mit S-Bahn-Routen-Relationen, z.B. S 1 Leuchtenbergring => Flughafen München https://ptna.openstreetmap.de/results/DE/BY/DE-BY-MVV-Analysis.html#train_S1

Sind die Infos komplette verschwunden, oder was ist dort passiert?

Könntest Du bitte die betroffenen S-Bahn-Routen-Relationen S1, S2, S3, S4, S5, S6, S8reparieren oder die Infos am Bahnsteig wieder herstellen oder sagen, wohin die Informationen "gewandert" sind?

N.B. achte beim Reparieren der S-Bahn-Routen-Relationen bitte auf die korrekte Reihenfolge der Relationsmitglieder: "iD", der Editor im Browser ist da manchmal eigenwillig, für solche Relationen eigentlich nicht geeignet.

Viele Grüße
Toni

176872204

sorry, typos:

... life-cycle prefixes zu nutzen. Die Route verschwindet ...

176872204

Servus,

es wäre günstiger, statt "delete" in 'name' die sogenannten life-cacle prefixes zu nutzen. Die Route verschwindert dadurch von den Karten, taucht aber in PTNA noch im entsprechenden Abschnitt auf - man kann sie also einfach finden.

https://ptna.openstreetmap.de/results/DE/BY/DE-BY-MVV-Analysis.html#life-cycle-prefix

Hier bietet sich der Präfix 'suspended' an.

Gruß
Toni

174123015

Hi,

Wenn die Bahnsteigkante oder die Bushaltestelle 'member' einer PTv2-Relation ist, ist 'public_transport' = 'platform' oder = 'stop_position' gefordert.

Eigentlich müsste man den gesamten Changeset rückgängig machen.

Gruß
Toni

175715622

Servus und willkommen bei OSM

Ein kleiner Tipp:
In OSM werden alle Namen ausgeschrieben, keine Abkürzungen:

addr:street=Kirchenstr

sollte

addr:street=Kirchenstraße

sein

Gruß
Toni