Bundestraßen und deren Routen

Ich meine den Abschnitt zwischen Bad Vilbel und der A 661, und da müsste ein Kraaftfahrstraßen-Schild stehen. Zumindest meine ich, das dort gesehen zu haben.

Du meinst zwischen BV-Fertighausausstellung und Unfallkrankenhaus? Das ist nach meiner Erinnerung keine Kraftfahrstraße (hier sind aber die Fußgänger/Radfahrer-Verboten-Schilder vorhanden; zumindest bis vor einem guten Jahr); die B3 ist zwischen Bad Vilbel und Preungesheimer Dreieck hingegen schon eine Kraftfahrstraße :wink:

Nein, da steht keines. Wer die Tags foot/bicycle=no dort angebracht hat, weiß ich nicht, es gibt aber einen guten Grund dafür: Direkt neben der Straße ist ein sehr gut ausgebauter Radweg der es praktisch unmöglich macht, einen Grund zu finden, auf der Straße fahren zu dürfen.

Nein, keine vorhanden. Ich würde sogar sagen, die standen noch nie da.

Mmhh, bin mir ziemlich sicher, dass bei der Brücke über die A661 die Schilder vorhanden sind/waren; habe aber gerade gesehen, dass das schon nicht mehr die B521 (sondern die B3) ist :wink: werde wohl kommende Woche mal wieder in der Ecke vorbeikommen und dann die Augen offenhalten :wink:

Ich habe mal die B312 (Stuttgart - Memmingen) bearbeitet (aus route=TMC jeweils route=road), um mit TMC Erfahrungen zu sammeln.

Vorläufiges Ergebnis: Der Import von TMC-Daten in 2010 per Bot umfasste bei weitem nicht alle Daten, die man bräuchte, um TMC-Meldungen interpretieren zu können. Die TMC-Relationen umfassen längere Abschnitte der Bundesstraße, die TMC-Punkte im Abstand von wenigen km fehlen größtenteils. An den Enden der Relationen war einmal ein TMC-Punkt als OSM-node, mehrere “Punkte” waren Relationen mit Kreuzungsobjekten, an einigen Enden waren gar keine TMC-Punkt-Daten vorhanden. Ich habe zur Info die TMC-Endpunkte (aus http://osm-tmc.infoware.de/tmc/) per Tag tmc:from/to der Relation hinzugefügt. Die Einmündung B 312 / B 300 fehlt aber auch dort.

Das Ganze habe ich in die (vorhandene) Super-Relation “Bundesstraße B 312” eingebaut (hin und zurück), die TMC-Relationen und ein paar Ways entfernt, ebenso das Zwischenstück über die B 27. Der JOSM-Validator meckert die Rollen an, aber route=TMC kannte er auch nicht.

Die TMC-Relationen waren nur stückweise zusammenhängend, teilweise fehlten die forward/backward-Rollen, gelegentlich fehlten ein paar km und einmal ging es durch den Kreisverkehr in falscher Richtung. Mit erheblicher Nacharbeit ist also zu rechnen.

Die Aufteilung der Gesamtstrecke per TMC-Relationen scheint mir ziemlich willkürlich, ich würde Segmente zwischen Bundesstraßeneinmündungen/-kreuzungen bevorzugen.

Im Infoware-Tool ist zu sehen, dass sporadisch die TMC-Information entsprechend dem Proposal an die Straßen als Tag tmc=* angehängt ist. Da sind dann alle Zwischenpunkte vorhanden (aus tmc=DE:xxxxx/yyyyy).

[edit] Letztes Hochladen fehlgeschlagen, aber auch früher hochgeladene Teilergebnisse sind verschwunden …

Hi, der TMC-Thread ist eigentlich “nebenan”: http://forum.openstreetmap.org/viewtopic.php?id=23754

Wenn du dich damit rumschlagen willst, …

Gruss
walter

Hi, hier mal meine aktuell Auswertung der Bundestraßen “ohne TMC”: http://wiki.openstreetmap.org/wiki/User:Wambacher#Bundestra.C3.9Fen

Es sind mindestens 4 “saubere” Rels dazugekommen, also geht es langsam aber sicher voran.

Kleiner Tip: Die Rels, die sehr wenige Members haben < 5-6 sind wohl Master-Relationen. Da könnte man loslegen.

Zum Thema “Verwaltung”: Ich bin ja kein Freund von irgendwelchen im Wiki manuell gepflegten Listen - z.B. “Liste aller Bundesstraßen, die in OSM drin sein sollten” oder eine “Bearbeitungsstatus der BS-Relationen”.

für beide Probleme sehen ich Lösungsansätze und wollte mal eure Meinung hören:
a) externe Referenz (was sollte in OSM drin sein?): Da könnte ich die Location-Liste von TMC nehmen, da dort ja vom Bast alle BS gepflegt werden.
b) Status der Bearbeitung: mir schwebt da ein tag in der Rel vor. Etwa last_checked=1.4.2014 by wambacher. Irgend welche Ideen?

Gruß
Walter

ps: ich hab nix gegen die TMC-Daten, nur in OSM möchte ich die nicht mehr sehen.

Wie wäre es mit check_date?

Das wäre übrigens auch für andere Relationen wie postal_code hilfreich.

Welche Information erhofft ihr Euch von diesem Tag? Wer das Datum ändert kann man in der history sehen wenn man möchte.
Aber die Frage ob das Datum seinen zweck erfüllt ist auch fraglich. Denn Die relation bekommt keine neue Version wenn Teilnehmer geändert werden, sondern nur wenn sie hinzugefügt oder gelöscht werden. Daraus folgte das für einen Intigritäscheck jedes mal die Version der Relation geändert würde nur weil das Datum aktualisiert wird.
Aber die Idee das die Information so dicht wie möglich bei den Daten ist halte ich ebenfalls für sinnvoll. Vielleicht kann man ja zukünftig Vererbungen in der API einbauen. So das Tags der relationen auch an Kindern leicht sichtbar sind bzw. Änderungen an Kindern auch einfacher in Relationen sichtbar werden. Vielleicht ist das aber auch nur eine Frage des Editors.

Frage zur Relationsbereinigung

Die B 115 hat an der Relation die Tags:

type=route
route=road
ref=B 115
operator=Bundesrepublik Deutschland
TMC:cid_58:tabcd_1:Class=Road
TMC:cid_58:tabcd_1:LCLversion=8.00
TMC:cid_58:tabcd_1:LocationCode=50202

Was passiert mit den letzten drei Tags? Erst mal ignorieren?

Nachtrag: laut aktueller Liste hat die B115 den LocationCode 50202. Die B 115 gliedert sich in zwei Anschnitte: Görlitz-Forst (LocationCode 8474) und Lübben-Jüterbog (LocationCode 8475).

fragt Sven

Genauer formuliert: Erfahrung mit dem Umsetzen von TMC- zu normalen route-Relationen. Von daher gehört es hier herein.
Ich werde aber ebenfalls einen Hinweis im TMC-Thread setzen.
Mir kam es vor allem auch darauf an, ob dieses Schema Master-Segment bei Auswertungen Probleme macht. Daher diese Pilot-Umsetzung.

Die B 312 ist jetzt in der OSM-DB drin (Master und Segmente). Ich habe die alte Master als “Bundesstraße B 312 (TMC)” zur Info noch drin gelassen, muss natürlich als Duplikat bald weg.

Zum Umstellaufwand: Er ist zwar beträchtlich, aber beim völligen Neubeginn müssten hier etwa 500 Straßenstücke in Relationen einsortiert werden, das ist ein Vielfaches mehr - bei den TMC-Relationen kann man wenigstens etliche größere Portionen übernehmen.

Die TMC-Referenzen sind nur informell drin (für den, den es interessiert - die anderen dürfen sie ignorieren).

War nu so ne Idee. Ich verstehe das als Gütesiegel: “Am YYYY-MM-DDTHH:mmZ als korrekt befunden”. Das muss ja keine vorherige Änderungen bedeuten, sondern das bis dahin z.B. nichts zerstört wurde.
Wer die Relationen als “Experte” anfasst oder repariert, könnte das Datum aktualisieren. Das könnte theoretisch auch ein QS-Bot machen.
Wenn Relationsteilnehmer (von Nicht-Experten) geändert werden, sollte deren Changeset einen anderen/späteren Timestamp haben. Somit ist der Check dann veraltet.

Die TMC-Tags können für die route-Relation wegfallen, da sie keine wesentliche Information enthalten. Den Location-Code kann ich nicht nachvollziehen, er ist in der Infoware-Karte (Stand 3.12.2013) in der Gegend nicht zu finden.

Den hab ich aus der aktuellen Liste des BaSt und hab ihn zum anderen so an der Relation vorgefunden.
Das ist der für die gesammte B 115, die Abschnitte banen ihren eigenen. (s.oben)
Sven

OK, ich habe nur bei den Location-Codes für die TMC-Points nachgesehen. Nur die werden im vereinfachten Schema für TMC berücksichtigt, weil die in den TMC-Meldungen vorkommen, so weit ich das entnehmen konnte. Eine Meldung für die gesamte B 115 macht wohl keinen Sinn.

Man könnte das höchstens als quasi offizielle Parallel-Nomenklatur ähnlich den RGS und AGS bei den Verwaltungsgrenzen sehen.

Nee, nicht automatisch. das macht die OSM-Api ja so recht und schlecht von selbst. Ich meinte, daß der Mapper - zumindest für dieses Projekt- das selber reinschreibt.

kann das Wiki eigentlich dynamisch die Overpass verwenden?

Gruss
walter

ich hab den Tag mal “checked” genannt und gebe den in der Liste auch mit aus. Kann man aber jederzeit ändern oder rausschmeißen.

Ich bin mir auch nicht ganz sicher. Bei den Rels, wo es sich um eine Kopie oder ein Duplikat handelt, sollte man die wohl rausschmeissen. Und wo es keine TMC-Version gibt, eventuell den Location-Code drin lassen, damit die Info nicht verschütt geht? Am liebsten wäre ich die komplett los.

Gruss
walter

alles klar. Ich taste mich auch an die Machbarkeit ran.

Ich mache eine Kopie der TMC, bereinige die von unnötigen Tags und beginne dann im josm eine “Deuschlandreise”. Dazu lade ich mir in einer leeren Ebene mit Datei/Objekt herunterladen nur die Relation, dann im Relation-Editor Elemente herunterladen, Bing dazu und schon kann es losgehen.

Gruss
walter

Das Rausschmeissen der ersten beiden TMC-Tags ist bestimmt zu verschmerzen. Wir wissen, dass die Version veraltet ist, und wir wissen (durch type/route), dass es ein TMC-Object der Klasse Road sein muss.

Die LocationCode-Info bliebe auch mit “tmc=DE:50202” erhalten (vgl. proposed new schema). Aber das ist wohl strittig. Inzwischen ist der Diskussionstand eher bei “TMC ganz rausschmeissen und ggf. neu und besser aufbauen”.

Stimmt (natürlich) :wink:

Wer ne Postgresql-DB hat, hier die Befehle zum Laden:


-- LOCATIONCODE, TYPE, SUBTYPE, ROADNUMBER, ROADNAME, FIRST_NAME, SECOND_NAME, AREA_REFERENCE, LINEAR_REFERENCE, NEGATIVE_OFFSET, POSITIVE_OFFSET, 
--   URBAN, INTERSECTIONCODE, INTERRUPTS_ROAD, IN_POSITIVE, OUT_POSITIVE, IN_NEGATIVE, OUT_NEGATIVE, 
--   PRESENT_POSITIVE, PRESENT_NEGATIVE, EXIT_NUMBER, DIVERSION_POSITIVE, DIVERSION_NEGATIVE, 
--   VERÄNDERT, TERN, NETZKNOTEN_NR, NETZKNOTEN2_NR, STATION, X_KOORD, Y_KOORD, POLDIR, ADMIN_County, ACTUALITY, ACTIVATED, 
--   TESTED, SPECIAL1, SPECIAL2, SPECIAL3, SPECIAL4, SPECIAL5, SPECIAL6, SPECIAL7, SPECIAL8, SPECIAL9, SPECIAL10

drop table lcl;

create table lcl (locationcode int,
		  type text,
                  SUBTYPE int,
                  ROADNUMBER text,
                  ROADNAME text,
                  FIRST_NAME text,
                  SECOND_NAME text,
                  AREA_REFERENCE text,
                  LINEAR_REFERENCE int,
                  NEGATIVE_OFFSET int, 
                  POSITIVE_OFFSET int,
                  URBAN text,
                  INTERSECTIONCODE text,
                  INTERRUPTS_ROAD text,
                  IN_POSITIVE text,
                  OUT_POSITIVE text,
                  IN_NEGATIVE text,
                  OUT_NEGATIVE text,
                  PRESENT_POSITIVE text,
                  PRESENT_NEGATIVE text,
                  EXIT_NUMBER text, -- int,
                  DIVERSION_POSITIVWen ne "rcihtige" DB hat, hier die Befehle zum Laden:E text, 
                  DIVERSION_NEGATIVE text,
                  VERÄNDERT text,
                  TERN text,
                  NETZKNOTEN_NR int,
                  NETZKNOTEN2_NR int,
                  STATION text,
                  X_KOORD bigint,
                  Y_KOORD bigint,
                  POLDIR text,
                  ADMIN_County text,
                  ACTUALITY text,
                  ACTIVATED text,
                  TESTED text,
                  SPECIAL1 text,
                  SPECIAL2 text,
                  SPECIAL3 text,
                  SPECIAL4 text,
                  SPECIAL5 text,
                  SPECIAL6 text,
                  SPECIAL7 text,
                  SPECIAL8 text,
                  SPECIAL9 text,
                  SPECIAL10 text
 ); 

copy lcl from '/home/walter/osm/db/misc/landstrassen/bast/LCL12.0.D-121202.csv'
         with (format csv, delimiter ';', header, encoding 'Windows-1252');

Dann kann man mal schnell nachschauen.

Gruß
Walter