Bundestraßen und deren Routen

Genau so mache ich das auch: An Kreuzungen sieht man gut welche Strasse jeweils grösser ist, und Durchgangsstrassen bekommen mindestens unclassified.
Aber eigentlich gehört das ja in einen anderen Thread.

Ja, wir sind in Deutschland, wo denkst du denn hin??? :sunglasses: Die Netzknoten markieren Kreuzungspunkte der Straßenachsen. Von und von zu bestimmten Punkten beginnen und Enden Straßen und deren Baulasten. An Punkten, wo verschiedene Baulastträger augeinandertreffen ist auch (sicher) geregelt, wer ab wo mit der Straßenwartung beginnt…

Hier widersprichst du dich:

Aber gut, im vorliegenden Fall kann ich mit Leben, daß an an Autobahnauffahrten (u.ä.) die höherwertige Straße beide Auffahrten umfasst.

Für mich ist das hier erledigt, da OT werdend. :slight_smile:

Sven

Nur eine schnelle Verständnisfrage zum Vorgehen: Sofern eine Relation vorhanden ist, in der auch TMC-Informationen in den Tags verschlüsselt sind, kopiert ihr diese Relation und macht aus der Kopie (?) eine reine route-Relation ohne die TMC-Informationen (d.h. type = route; route=road; ref=B 4711; operator=Bundesrepublik Deutschland → die zugehörigen ways dann ohne role entsprechend prüfen und ggf. korrigieren; zusätzlich das tag checked… setzen, damit klar ist, dass die Relation geprüft/korrigiert wurde ?!) Korrekt ?!

Die ursprüngliche Relation, in der dann die TMC-Informationen verblieben sind mit type=TMC ggf. ändern und die restlichen Tags (operator=; route= [sofern vorhanden] - ref=* drin lassen) rausnehmen?!

Ist das allgemeiner Konsens ?!

Im wesentlichen mache ich es so.
Unterschiede gibt es darin, ob man Hin- und Rückrichtung getrennt erfasst. Das lohnt nur, wenn häufiger baulich getrennte Fahrbahnen, Einbahnstraßenabschnitte, Kreisverkehre u.ä. vorkommen. Ich mache mir die Arbeit, weil ich dann im Relationseditor jedesmal eine durchgehende Linie zumindest in den Segmenten von Kreuzung bis Kreuzung bekomme.
Ich mache schon deshalb Segmente, weil Relationen mit mehr als 2-300 Mitgliedern unangenehm in der Handhabung werden, aber da sind die Ansichten verschieden.

Wenn man die Richtungstrennung nicht macht (Beispiel B 260), bekommt man eine Richtung am Stück und danach den Lumpensammler aus den Fragmenten, in denen die Gegenrichtung abweicht (plus primary und trunk links).

Beim checked warte ich noch ab, worauf man sich einigt. Bei Richtungstrennung ist der Bedarf nicht so hoch, da man nach Herunterladen der Mitglieder und ggf. Sortieren sofort sieht, ob beide Linien noch durchgehen.

absolut korrekt so.

nicht ganz: das einzige, was ich mit offensichtlichen TMC-Daten mache: es gibt welche mit type=route und route=road, … Diese setzte ich zur Zeit auf type=TMC und lasse sonst alles drin wie es ist.
Bei der Auswertung beschränke ich mich dann auf type=route, route=road und das sind dann die “sauberen”.

Gruß
walter

meinst du den Key (checked) oder den Inhalt? Den Key kann man immer noch anpassen.

Wenn ich mit eine Route “vorknöpfe” mach ich übrigens als Allererstes ein checked=ongoing rein und lade die hoch, in der Hoffnung, daß ihr das bemerkt und dann mich erstmal in Ruhe schaffen laßt. So sollte es eigentlich keine Konflikte geben. Bisher ging das ganz gut.

Gruß
Walter

OK, das macht Sinn.

Ist zwar ein Inhalt, bei dem ich absolut nicht unterwegs bin, aber was haltet ihr davon ein Datum zum “ongoing” dazu zu geben, damit man irrtümlich belassene ongoing erkennen kann ohne die History zu durchwühlen?

Bei den ersten Bundesstraßen, die ich fertig habe, hat die Relation type=TMC einen neuen ID bekommen, aus der vorhandenen hab ich dann die TMC-Geschichte rausgenommen.
Das hat für mich den Vorteil, daß die im Wiki dokumentierten Informationen zur Bundesstraße nicht geändert werden müssen.

Das waren aber bisher nur welche ohne Tochter-Ralationen. Bei zwei großen (B 87 und B 96) habe ich erst mal die vorhandene vervollständigt.

Sven

Das setzt allerdings voraus, dass nicht die Anwendungen, die TMC-Daten aus OSM verwenden (BR), nicht auch die OSM-ID nutzen.
Abgesehen davon ist die Verwendung der OSM-IDs immer eine wackelige Geschichte, aber wohl nicht immer zu vermeiden.

Naja, mir geht es in der Hauptsache nur darum, daß die Bundesstraßen-Doku im Wiki nicht zerschossen wird. Wenn man es andersherum macht (Straßen-Relation neu anlegen) kann gleich im Anschluß die Bundesstraßen-Doku im Wiki ins Datennirvana geschickt werden, was eigentlich unschön wäre. Mir wären die TMC-freien Straßenrelationen wichtiger, darum möglichst deren Relationsnummer behalten. Das mandiese natürlich nicht zu spezielleren Auswertegeschichten verwenden sollte, ist klar.

Sven

ich bin mehr für den “Minimal-inversiven Eingriff” und ändere so wenig wie möglich an der TMS-Relation. Wenn du unbedingt das Wiki verwenden willst, ändere dort halt die OSM-Id. Mir reicht derzeit mein OSM-Report, der die reale Datensituation darstellt.

Kann das Wiki eigentlich Overpass-Abfragen machen?

Gruss
walter

Das würde mich auch interessieren.

Nun… ich kann das auch andersrum machen… Die paar Bundesstraßen waren noch nicht so kompliziert…

Sven

Bei den meisten Bundesstraßen sind die TMC-Routen ja identisch zu absolut identisch zum Straßenverlauf. Warum müssen wir dann zwei getrennte Relationen haben? Das ist eindeutig doppeltes mapping, was an allen anderen Stellen abgelehnt wird. Da wir lange Bundesstraßen ohnehin segmentieren wollen, können wir diese Segmente auch gleich an den TMC-Teilstücken orientieren und mit der jeweiligen Nummer versehen.
Ich kann die strikte Ablehnung von TMC-Daten von manchen nicht verstehen - ja, natürlich sieht es nach Datenwust aus, aber beim Mappen in den letzten Tagen habe ich explizit darauf geachtet - bei mehreren Dutzend gemappten Punkten ist mir kein falscher untergekommen. So schlecht können die vorhandenen Daten also gar nicht sein.

Ich habe das Gefühl, dass die Ablehnung von TMC-tags auch an den kryptischen TMC-Keys liegt, die die Relationsdaten optisch verschmutzen.

Das Hauptproblem ist aus meiner Sicht, dass die TMC-Relationen type=TMC enthalten, wodurch der für Straßen-Relationen notwendige type=route ausgeschlossen ist. Insofern muss es, sofern für TMC-Anwendungen der type=TMC unabdingbar ist, zwangsläufig zwei Relationen (TMC- und route-Relationen) geben. Ob es tatsächlich für TMC bei Relationen bleibt, oder ob ggf. andere Informationen in OSM (oder wo auch immer) gespeichert, wird im Rahmen des anderen Thread geklärt.

Nicht nur “auch”, sondern in der Hauptsache :wink: Mit einem klaren und wartbaren Tagging sähe die Sache ganz anders aus. Aber daran arbeiten wir ja an anderer Baustelle…

Zum Thema dieses Threads: Das derzeitige Vorgehen, die TMC-Informationen aus den Bundesstraßen-Routen-Relationen rauszunehmen und (temporär, so lange diese Tags noch genutzt werden) in eine neue Relation zu packen, halte ich ebenfalls für sinnvoll. Auf die Weise bleibt auch die History der Bundesstraßen erhalten. Ich vermute (!) außerdem, dass es für die TMC-Auswerter keine Rolle spielt, an welcher OSM-ID die TMC-Daten getaggt sind. Wenn der Auswerter direkt nach den IDs gehen würde, bräuchte er ja nicht erst nach TMC-Tags suchen.

Die Zuordnung von Straßen zu TMC-Relationen muss 2010 per Bot geschehen sein. Wenn da eine Straße inzwischen genauer gemappt wurde, hat das die Relation automatisch geerbt. Ich musste aber einige Male fehlende Stücke ergänzen (typischer Kollateralschaden beim Splitten von Ways) und nach Umbau von Kreuzungen waren da z.T. abenteuerliche Verläufe. Die Relationen erstrecken sich übrigens über viele TMC-“Points” hinweg, die Endpunkte der Relationen sind für mich ziemlich willkürlich gewählt (wenige km von der nächsten größeren Kreuzung entfernt). Da würde ich die type=route-Relationen gerne umverteilen.

Solange nicht klar ist, wo und wie die TMC-Relationen noch verwendet werden, würde ich sie lassen, wie sie sind (höchstens umkopieren), aber auch keinen Aufwand zur Wartung reinstecken.

HI,

ich hab mal heute meine DB und Qgis “gequält” und dabei ist das hier rausgekommen:

groß: http://osm.wno-edv-service.de:8080/DataServer/osm/forum/blk/bundesstrassen-1.png

Stand: heute ca 19:00 Uhr.

Es fehlen noch die Master/Slave-Relationen wie z.B. die B3. Und ein vernünftiges Landflächen-Polygon von Deutschland werde ich wohl auch noch brauchen.

Ich hoffe, das motiviert ein wenig. Updates auf meiner Wiki-Seite.

Gruß
Walter

Ja, das Motiviert… Man sieht schön die südbrandenburgische Ecke die so eine tolle grüne Landschaft ist… :slight_smile:

Jetzt fehlen einige lange Bundesstraßen noch, wie die B 87. Das ist solche mit Kind-Relationen und wäre für einen Rat dankbar: neue Relation mit type=route und allen Elementen oder wieder unterteilen?? ich wäre für ersteres…

Sven