You are not logged in.

#51 2014-01-06 12:20:49

streckenkundler
Member
From: Lübben (Spreewald)
Registered: 2012-08-09
Posts: 4,952
Website

Re: Überarbeitung von TMC / TPEG

Zu der Erläuterung:

MHohmann wrote:

LOCATIONCODE - eindeutige Codenummer dieses Punktes in der Tabelle

TYPE, SUBTYPE - Objekttyp, z.B. Autobahnkreuz, Kreisverkehr, Parkplatz, Rastplatz...

ROADNUMBER - ref der zugehörigen Straße

FIRST_NAME - Name des Objektes

AREA_REFERENCE - Location Code des Verwaltungsgebietes

LINEAR_REFERENCE - Location Code der zugehörigen Straße oder Straßensegments

NEGATIVE_OFFSET, POSITIVE_OFFSET - Location Codes der benachbarten Punkte entlang dieser Straße

X_KOORD, Y_KOORD - WGS84-Koordinaten

sollte noch mit gelistet werden, was ich hier geschrieben hatte:

streckenkundler wrote:

Was anscheinend keiner so richtig mitbekommen hat: in der LCL-Tabelle des BaSt ist zugleich eine Netzknotenliste (mit Koodinaten !!!) enthalten. Netzknoten ist zwar nichts, was man direkt in OSM braucht oder da hineingehört, Wichtig ist die Liste dennoch, weil man so anhand der Netzknoten sie auch ändernden Straßenabschnitte identifizieren kann. Leider ist die nicht vollständig: Hessen, Thüringen, Saarland und Schleswig-Holstein fehlen.  Nomenklatur des Netzknotens ist recht einfach: die ersten vier Ziffern bezeichnen die Meßtischblattnummer. Dann schließt sich eine laufende Nummer pro Meßtischblatt an. Es ist zwar keine vollständige Netzknotenliste, aber alle, die Landesstraßen, Bundtesstraßen und Autobahnen identifizierenden Nummern sollten enthalten sein.

Sven

Offline

#52 2014-01-06 13:07:44

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 16,736
Website

Re: Überarbeitung von TMC / TPEG

Hi, obwohl TMC nicht -mehr- mein Ding ist, möchte ich doch auf eine sehr gute PostGIS-Erweiterung hinweisen:

Das aktuelle PostGIS (schlage 2.0 oder höher vor) unterstützt Topologien.

Topologien bestehen aus Knoten, Kanten und Flächen (Nodes, Edges und Areas) und werden von Postgis als eigene Datentypen/Objekte verwendet. Das wartet geradezu auf TMS.

Die Doku ist ein wenig dürftig, aber wer sich wirklich dafür interessiert (z.B. Routing), wird da schon was finden können.

http://trac.osgeo.org/postgis/wiki/User … isTopology
http://postgis.net/docs/Topology.html

ach ja: Ich hab nichts gegen TMS, ich kenne inzwischen einigermaßen die Daten und deren Struktur, schaue da gerne nach und verwende die auch als Referenz - ich will die nur nicht mehr in OSM drin haben.

Gruß
walter

ps2: Zum Thema "eindeutige ID" schlage ich die Verwendung von UUIDs vor. Die sind aber bei osm-Talk mehrfach abgeblockt worden, ohne daß die Ablehner eine Alternative angeboten hätten

Offline

#53 2014-01-06 17:41:37

Gehrke
Member
From: Bremen, DE
Registered: 2013-10-19
Posts: 1,894
Website

Re: Überarbeitung von TMC / TPEG

Aus dem Route-Schwester-Thread:

DoDoMR wrote:

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.

"type=TMC" gefällt mir auch gar nicht. Entweder es ist ein Node oder eine Relation für Gebiete (type=boundary|multipolygon) oder Abschnitte (type=route).
Dann könnte z.B. "boundary|route=tmc" sein. Letztlich benötigt wird aber nur die TMC-ID, egal ob die nun direkt in OSM ist oder extern mit der passenden OSM-Relation verknüpft wird.

Kann die betreuende Firma das für den BR nicht schnell umstellen? Das ist ja nur eine kleine, einfache SQL-Abfrage.

Offline

#54 2014-01-06 18:45:06

MHohmann
Member
From: Tartu, Estonia
Registered: 2009-06-07
Posts: 1,600
Website

Re: Überarbeitung von TMC / TPEG

wambacher wrote:

ach ja: Ich hab nichts gegen TMS, ich kenne inzwischen einigermaßen die Daten und deren Struktur, schaue da gerne nach und verwende die auch als Referenz - ich will die nur nicht mehr in OSM drin haben.

Das aktuelle TMC-Tagging will wohl auf die Dauer niemand hier in OSM drin haben, es wird nur eben noch genutzt. Deshalb ist ja auch völlig unstrittig, dass wir es rauswerfen, sobald wir etwas besseres haben (und das stattdessen genutzt werden kann). Genau darum geht es doch. Klar dass man dafür die Struktur verstehen muss, gerade deshalb versuche ich ja sie zu dokumentieren, damit auch andere außer uns beiden und den aktiven Postern hier sie verstehen und wir ein besseres Tagging bekommen wink Das geht nur nicht von heute auf morgen.

Worin genau besteht denn nun der Nutzen von PostGIS-Topologien im Zusammenhang mit TMC?


SotM Baltics, 3.-4. August 2013, Tartu, Estonia: amenity=university, mappers=yes

Offline

#55 2014-01-06 19:47:46

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 16,736
Website

Re: Überarbeitung von TMC / TPEG

MHohmann wrote:

Worin genau besteht denn nun der Nutzen von PostGIS-Topologien im Zusammenhang mit TMC?

Ganz "einfach": TMC-Daten bestehen aus Points, Lines und Areas und Topologieen bestehen aus Nodes, Edges und Areas - andere Worte für die gleichen Begriffe.

Ein Datensatz aus der Location-Liste ist genau ein Topologie-Element, ohne auch nur irgendwas zusammensuchen zu müssen.

In PostGIS kann man ja geometrische Operationen mit den GIS-Objekten machen (Welche Linien schneiden sich wo? Welche Fläche ist die grösste?, ...)  Und mit der Topology-Extension geht das auch mit Topologischen Objekten - und die Location-Liste von TMC besteht zu 100% aus topologischen Objekten.
Geht so in Richtung Graphen, Routing. Da wird sowas gebraucht. Und TMC ist auch nicht anderes.

Ist für dich allerdings wohl nur theoretisch interessant, da die Einarbeitung relativ mühsam ist. Und ich bin auch noch nicht sehr vertraut damit.

Gruß
walter

Offline

#56 2014-01-06 20:27:13

MHohmann
Member
From: Tartu, Estonia
Registered: 2009-06-07
Posts: 1,600
Website

Re: Überarbeitung von TMC / TPEG

wambacher wrote:

Ganz "einfach": TMC-Daten bestehen aus Points, Lines und Areas und Topologieen bestehen aus Nodes, Edges und Areas - andere Worte für die gleichen Begriffe.

Na gut, so weit war ich noch mitgekommen, aber ich hatte bis eben gedacht, solche Objekte wären ohnehin schon in PostGIS vorhanden und nicht erst durch eine "Topologie-Erweiterung". IMHO werden doch auch OSM-Objekte schon seit längerem in PostGIS abgebildet, und die sind doch auch nichts anderes, oder? Wobei:

In PostGIS kann man ja geometrische Operationen mit den GIS-Objekten machen (Welche Linien schneiden sich wo? Welche Fläche ist die grösste?, ...)  Und mit der Topology-Extension geht das auch mit Topologischen Objekten - und die Location-Liste von TMC besteht zu 100% aus topologischen Objekten.
Geht so in Richtung Graphen, Routing. Da wird sowas gebraucht. Und TMC ist auch nicht anderes.

...und ein GIS-Objekt ist kein topologisches Objekt (oder umgekehrt) - d.h. das ist nicht das gleiche?

Ist für dich allerdings wohl nur theoretisch interessant, da die Einarbeitung relativ mühsam ist. Und ich bin auch noch nicht sehr vertraut damit.

Ja, das fürchte ich auch wink Mit PostGIS hatte ich bisher noch nichts zu tun. Aber man weiß ja nie, was man nicht noch irgendwann mal brauchen wird...


SotM Baltics, 3.-4. August 2013, Tartu, Estonia: amenity=university, mappers=yes

Offline

#57 2014-01-06 21:33:40

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 16,736
Website

Re: Überarbeitung von TMC / TPEG

MHohmann wrote:

ich hatte bis eben gedacht, solche Objekte wären ohnehin schon in PostGIS vorhanden und nicht erst durch eine "Topologie-Erweiterung". IMHO werden doch auch OSM-Objekte schon seit längerem in PostGIS abgebildet, und die sind doch auch nichts anderes, oder? ..

Nö, die sind wirklich was anderes. egal.

Gruss
walter

Offline

#58 2014-01-06 22:36:39

mueschel
Member
Registered: 2012-06-11
Posts: 1,152
Website

Re: Überarbeitung von TMC / TPEG

Ich habe hier einen Vorschlag zum Thema mapping von Punkt-Lokationen (meistens Kreuzungen). Hier ist eine Kreuzung, die zwei TMC Koordinaten hat:
http://www.openstreetmap.org/node/32906938

Dieser Knoten sowie der zweite Zentrale Kreuzungsknoten dieser Kreuzung sind Teil von zwei Relationen, die jeweils alle Infos zu diesem TMC-Punkt enthalten.
Leider zeigt osm.org/browse nicht den Typ der Relation an, aber das kann sich ja noch ändern.

Damit sind zwei zentrale Kritikpunkte hoffentlich behoben: Tag-Chaos an Punkten und Wegen sowie der Problemfall mehrerer überlagernder Punkte.
Was haltet ihr von dieser möglichen Lösung?

Die einzelnen Routen-Teilstücke werde ich in den nächsten Tagen hinzufügen. Das genaue Tagging innerhalb der Relation steht jetzt (noch) nicht zur Diskussion, das ist das alte Schema.

Offline

#59 2014-01-06 23:18:37

sennewald63
Member
Registered: 2013-09-20
Posts: 272

Re: Überarbeitung von TMC / TPEG

Hallo ins Forum,

grundsätzlich bin ich ja interessiert, dass Daten ala TMC ins Gerät kommen.
Ich benutze aber seit diesem Jahr kein Navi mehr, sondern alles geht über ein 7 Zoll Tablet mit OSMAND oder Mapfactor Navigator als Navi-Software.
Mein Gedankengang war dabei von teuren Kartenupdates der reinen Navi's weck zu kommen.

Hier wurde auch schon kräftig über TMC über Internet diskutiert http://www.car-pc.info/phpBB2/viewtopic … sc&start=0
und eine Anwendung auch benannt die Navi-Software verschiedenen Betriebssyteme erweitert.
Man würde also nicht bei 0 Anfangen müssen, ob allerdings die TMC-Tags von OSM dabei genutzt werden weiss ich nicht.

Ich kling mich jetzt für ein paar Tage aus.

MfG

Senni

Offline

#60 2014-01-07 15:08:52

woodpeck
Member
Registered: 2009-12-02
Posts: 1,188

Re: Überarbeitung von TMC / TPEG

Gehrke wrote:
woodpeck wrote:

Wenn man sich bei der Software Muehe gibt, kann man meiner Ansicht nach ueber 95% der TMC-Segmente vollautomatisch aus OSM herleiten (nach dem Motto: Ich weiss aus der BASt-Tabelle, dass das Segment X von ungefaehr hier bis ungefaehr dort geht und A5 heisst, nun such ich mir mit einem Routing-Algorithmus in OSM die Strassenstuecke, die damit am wahrscheinlichsten gemeint sind).

Da klingen meine Alarmglocken. Ist es wirklich besser, das TMC/OSM-Mapping zu "raten" als es explizit aufzuschreiben? Kann ich kaum glauben.

Sagen wir es mal so. Aus Nutzersicht waere es natuerlich toll, wenn ich jederzeit aktuelle Strassendaten mit durchgaengigen, korrekten TMC-Informationen bekommen koennte - so dass ich ohne komplizierte Logik eine Anfrage wie "ich hab hier eine Staumeldung fuer Segmente A,B,C, welche OSM-Ways sind betroffen" stellen kann und richtige und vollstaendige Antworten bekomme. Das waere fuer mich als Nutzer das beste.

(Selbst in dieser perfekten Welt waere vieles nicht trivial - wenn zum Beispiel ein Meldungstyp "Fahrbahnverengung" den TMC-Code eines Rastplatzes betrifft, dann sind damit *andere* Asphaltflaechen gemeint als wenn fuer den identischen TMC-Code ein "Rastplatz gesperrt"-Meldungstyp rausgeht - der gleiche TMC-Code betrifft mal die Autobahn, die am Rastplatz vorbeifuehrt, und mal die highway=services-Flaeche, die neben der Autobahn liegt. Aber das nur am Rande!)

Aber diese aus Nutzersicht tolle Welt werden wir nie hinkriegen, wir werden auch mit manueller Instandhaltung nie 100% erreichen, und es wird auch immer wieder passieren, dass irgendwas bei uns nicht fehlt, sondern schlicht falsch ist - weil ein Weg gesplittet und eine Relation nicht kopiert wurde, was auch immer, die meisten hier kennen das ja zur Genuege.

Selbst wenn bei uns alles ok ist, so kaemen doch neue Listen von der BASt, an die wir unsere Daten regelmaessig anpassen muessten (und das, obwohl sich in der realen Welt gar nichts aendert - auch komisch, oder).

Das heisst, dass ernsthafte Nutzer sich *eh* nie 100% auf OSM verlassen koennen, sondern die OSM-Infos mit geeigneten Routing-Algorithmen ueberpruefen muessen.

Wir koennten also maximal etwas liefern, was *ein bisschen* besser ist als das, was man sich selber ausrechnen kann. Im Unterschied zu dem, was man sich selber ausrechnen kann, wuerde unseres aber staendig mit Arbeitszeit "nachgefuettert" werden muessen. Und es wuerde die Arbeit unbeteiligter Mapper an anderen Dingen beeintraechtigen (weil die sich damit auseinandersetzen muessten, was das seltsame TMC-Tag da jetzt soll).

Unterm Strich, wenn man den moeglichen Nutzen auf die eine Waagschale legt und den Aufwand und die stoerenden Seiten auf die andere, scheinen mir die negativen Seiten zu ueberwiegen.

Bye
Frederik

Offline

#61 2014-01-07 15:30:46

viw
Member
Registered: 2010-05-15
Posts: 2,623

Re: Überarbeitung von TMC / TPEG

woodpeck wrote:

Aber diese aus Nutzersicht tolle Welt werden wir nie hinkriegen, wir werden auch mit manueller Instandhaltung nie 100% erreichen, und es wird auch immer wieder passieren, dass irgendwas bei uns nicht fehlt, sondern schlicht falsch ist - weil ein Weg gesplittet und eine Relation nicht kopiert wurde, was auch immer, die meisten hier kennen das ja zur Genuege.

Selbst wenn bei uns alles ok ist, so kaemen doch neue Listen von der BASt, an die wir unsere Daten regelmaessig anpassen muessten (und das, obwohl sich in der realen Welt gar nichts aendert - auch komisch, oder).

Wo ist OSM denn je zu 100% fertig/aktuell? Es wird immer etwas geben was wir zwar erfassen können aber nicht vollständig erfasst ist bzw. nicht mehr aktuell ist.

Man braucht sich nur einmal die Postleitzahlen anschauen. Diese erfüllen dann auch den Tatbestand der Änderung ohne das sich etwas in der realen Welt ändert.


woodpeck wrote:

Das heisst, dass ernsthafte Nutzer sich *eh* nie 100% auf OSM verlassen koennen, sondern die OSM-Infos mit geeigneten Routing-Algorithmen ueberpruefen muessen.

Wir koennten also maximal etwas liefern, was *ein bisschen* besser ist als das, was man sich selber ausrechnen kann. Im Unterschied zu dem, was man sich selber ausrechnen kann, wuerde unseres aber staendig mit Arbeitszeit "nachgefuettert" werden muessen. Und es wuerde die Arbeit unbeteiligter Mapper an anderen Dingen beeintraechtigen (weil die sich damit auseinandersetzen muessten, was das seltsame TMC-Tag da jetzt soll).

Dies würde ziemlich vieles in OSM in Frage stellen. Sei es bei Adressen die angabe des landes der Plz oder ähnliches.

Ähnliches gilt für die Routen des ÖPNV. Auch Relationen von Straßen könnte man sich sparen, da diese ebenfalls aus externen Quellen mehr oder weniger genau über unser Netz gelegt werden können.

Die Frage ob man andere Nutzer damit behindert möchte ich grundsätzlich anzweifeln. Aber man läuft natürlich Gefahr, dass Nutzer die das nicht verstehen es weder pflegen noch darauf Rücksicht nehmen. Aber das gilt bei allen Datenstrukturen in OSM. Warum sonst gehen Grenzen und Küstenlinien immer wieder mal auseinander? Bestimmt nicht weil jemand da böse absichten hat.

Last edited by viw (2014-01-07 15:31:31)

Offline

#62 2014-01-07 16:01:34

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 16,736
Website

Re: Überarbeitung von TMC / TPEG

woodpeck wrote:

Unterm Strich, wenn man den moeglichen Nutzen auf die eine Waagschale legt und den Aufwand und die stoerenden Seiten auf die andere, scheinen mir die negativen Seiten zu ueberwiegen.

Und das bestätigt meine Ansicht, daß wir uns mit TMC-Daten in OSM nicht rumärgern beschäftigen sollten.

tl;dr:  Werden nicht gebraucht, sind permanent zu pflegen, "stören" -> weg damit.

als Referenz "wie hängt das alles zusammen? Welche Straßen ... gibt es?" allerdings prima zu verwenden.

Gruss
walter

Last edited by wambacher (2014-01-07 16:02:52)

Offline

#63 2014-01-07 16:10:15

MHohmann
Member
From: Tartu, Estonia
Registered: 2009-06-07
Posts: 1,600
Website

Re: Überarbeitung von TMC / TPEG

woodpeck wrote:

Aber diese aus Nutzersicht tolle Welt werden wir nie hinkriegen, wir werden auch mit manueller Instandhaltung nie 100% erreichen, und es wird auch immer wieder passieren, dass irgendwas bei uns nicht fehlt, sondern schlicht falsch ist - weil ein Weg gesplittet und eine Relation nicht kopiert wurde, was auch immer, die meisten hier kennen das ja zur Genuege.

Natürlich erwartet (hoffentlich) niemand, dass die Daten, die in OSM vorhanden sind, zu 100% perfekt wären. Wenn wir wirklich ein perfektes Mapping, oder meinetwegen auch nur ein perfektes Straßenrouting, als Ziel anstreben würden, könnten wir gleich sämtliche Straßendaten in die Tonne hauen, mit dem Argument, dass diese immer Fehler enthalten, weil sie manuell gemappt sind. Natürlich enthalten OSM-Daten Fehler, so wie jede andere Karte auch, aber es ist doch gerade die Stärke von OSM, dass diese Fehler von einer Community behoben werden können, sobald sie jemand entdeckt oder meldet, im Gegensatz zu kommerziellen Karten, wo der Nutzer auf ein Update hoffen und dafür bezahlen müsste.

Selbst wenn bei uns alles ok ist, so kaemen doch neue Listen von der BASt, an die wir unsere Daten regelmaessig anpassen muessten (und das, obwohl sich in der realen Welt gar nichts aendert - auch komisch, oder).

So weit ich das bisher sehen kann, ändern sich bei einem solchen Update nicht auf einen Schlag alle Location Codes, sondern es gibt graduelle Änderungen. Die meisten Codes wären von einem Update also gar nicht betroffen. Man könnte genau so argumentieren, dass Verwaltungsgrenzen nicht in OSM gehören, weil es ja ständig Gemeindereformen gibt - und man da die Daten ändern muss, obwohl man in der realen Welt keinen Unterschied sieht.

Das heisst, dass ernsthafte Nutzer sich *eh* nie 100% auf OSM verlassen koennen, sondern die OSM-Infos mit geeigneten Routing-Algorithmen ueberpruefen muessen.

Es geht ja auch gar nicht darum, sich zu 100% auf die Daten zu verlassen. Natürlich müssen die Daten überprüft werden. Es ist aber wesentlich einfacher, vorhandene Daten auf ihre Konsistenz und Richtigkeit hin zu überprüfen, als sie komplett auszurechnen.

Wir koennten also maximal etwas liefern, was *ein bisschen* besser ist als das, was man sich selber ausrechnen kann. Im Unterschied zu dem, was man sich selber ausrechnen kann, wuerde unseres aber staendig mit Arbeitszeit "nachgefuettert" werden muessen. Und es wuerde die Arbeit unbeteiligter Mapper an anderen Dingen beeintraechtigen (weil die sich damit auseinandersetzen muessten, was das seltsame TMC-Tag da jetzt soll).

Das ist doch aber genau das gleiche Problem wie z.B. bei Busrouten, wobei die sogar noch in größerer Zahl vorhanden sein dürften und sich dynamischer ändern. Natürlich kann ein Nutzer sich diese auch selbst von den ÖPNV-Unternehmen holen statt aus OSM und man würde so das Risiko vermeiden, dass ein Mapper eine Busroutenrelation zerschießt. Das hätte man aber auch keine OSM-ÖPNV-Karten. Deshalb sollte es natürlich das Ziel eines wie auch immer gestalteten Tagging sein, es so einfach wie nur möglich zu halten, damit auch Nutzer, die sich mit TMC nicht auskennen, damit keine Probleme bekommen.

Dazu kommt noch das IMHO beste Argument von viw: Wenn wir es schaffen sollten, TMC-Rohdaten von anderen Ländern zu erwerben mit der Möglichkeit sie "in nicht mehr roher Form" einzupflegen (meinetwegen über eine Spende oder was auch immer), könnten wir die aufgearbeiteten Daten als Teil der OSM-Karte auch FOSS-Routing-Projekten anbieten, die sich die Rohdaten selbst nicht leisten können. Als wenn das kein signifikanter Nutzen wäre...


SotM Baltics, 3.-4. August 2013, Tartu, Estonia: amenity=university, mappers=yes

Offline

#64 2014-01-07 16:26:08

mueschel
Member
Registered: 2012-06-11
Posts: 1,152
Website

Re: Überarbeitung von TMC / TPEG

woodpeck wrote:

Selbst wenn bei uns alles ok ist, so kaemen doch neue Listen von der BASt, an die wir unsere Daten regelmaessig anpassen muessten (und das, obwohl sich in der realen Welt gar nichts aendert - auch komisch, oder).

Das Update lässt sich hervorragend automatisieren - >95% aller Punkte ändern sich nicht, die anderen Änderungen sind klein (neue Segmente, neue Punkte) und lassen sich in eine einfache ToDo-Liste umsetzen. Buslinien sind um Größenordnungen schwerer instandzuhalten, und da beschwert sich niemand, dass die nicht in OSM gehören würden!

woodpeck wrote:

Und es wuerde die Arbeit unbeteiligter Mapper an anderen Dingen beeintraechtigen (weil die sich damit auseinandersetzen muessten, was das seltsame TMC-Tag da jetzt soll).

Das trifft auf jedes beliebige andere Tag auch zu. Wie steht es mit den 3D-Attributen für Gebäude? Das ist ein noch viel größeres Gemenge an unterschiedlichen Dingen, und viele haben Werte die man ohne Nachschlagen nicht interpretieren kann.

MHohmann wrote:

So weit ich das bisher sehen kann, ändern sich bei einem solchen Update nicht auf einen Schlag alle Location Codes, sondern es gibt graduelle Änderungen.

Ja, insbesondere: Ein einmal vergebener Code wird auf keinen Fall neu an anderer Stelle vergeben! Alte Daten sind also höchstens ungenau, aber in keinem Fall komplett falsch.

Offline

#65 2014-01-07 17:45:51

MHohmann
Member
From: Tartu, Estonia
Registered: 2009-06-07
Posts: 1,600
Website

Re: Überarbeitung von TMC / TPEG

mueschel wrote:

Ich habe hier einen Vorschlag zum Thema mapping von Punkt-Lokationen (meistens Kreuzungen). Hier ist eine Kreuzung, die zwei TMC Koordinaten hat:
http://www.openstreetmap.org/node/32906938

Dieser Knoten sowie der zweite Zentrale Kreuzungsknoten dieser Kreuzung sind Teil von zwei Relationen, die jeweils alle Infos zu diesem TMC-Punkt enthalten.
Leider zeigt osm.org/browse nicht den Typ der Relation an, aber das kann sich ja noch ändern.

Damit sind zwei zentrale Kritikpunkte hoffentlich behoben: Tag-Chaos an Punkten und Wegen sowie der Problemfall mehrerer überlagernder Punkte.
Was haltet ihr von dieser möglichen Lösung?

Grundsätzlich gefällt mir, dass man auf diese Weise TMC-Locations in Form von OSM-Objekten abbilden kann, in diesem Fall also als eine Relation. Allerdings sehe ich das Schema etwas problematisch im Hinblick auf zukünftige Bearbeitungen an dieser Kreuzung. Angenommen, jemand teilt die B 521 und L 3209 gemäß einer baulichen Trennung in je zwei Wege auf*. Dann kommen zwei weitere Kreuzungspunkte hinzu. Jemand, der das TMC-Tagging nicht kennt, wird die aber nicht zur TMC-Relation hinzufügen, wie es eigentlich dem korrekten Tagging entsprechen würde.  Vielleicht löscht er auch Punkte oder ersetzt sie. Damit würde so ein (ziemlich wahrscheinlicher) Edit das TMC-Tagging aus der Bahn werfen, z.B. weil man die TMC-Punkte dann nur noch auf einer von zwei Richtungsfahrbahnen findet und es so aussieht, als würde man sie in der anderen Richtung gar nicht passieren. So ein Fehler dürfte auch schwer automatisiert zu finden sein, denn wenn man nur prüft, ob eine TMC-Relation an der richtigen Stelle vorhanden ist, findet man ja eine solche - sie ist aber nicht vollständig.

*Nehmen wir mal hypothetisch an, die Kreuzung würde genau so umgebaut werden.


SotM Baltics, 3.-4. August 2013, Tartu, Estonia: amenity=university, mappers=yes

Offline

#66 2014-01-07 18:32:04

viw
Member
Registered: 2010-05-15
Posts: 2,623

Re: Überarbeitung von TMC / TPEG

MHohmann wrote:

Grundsätzlich gefällt mir, dass man auf diese Weise TMC-Locations in Form von OSM-Objekten abbilden kann, in diesem Fall also als eine Relation. Allerdings sehe ich das Schema etwas problematisch im Hinblick auf zukünftige Bearbeitungen an dieser Kreuzung. Angenommen, jemand teilt die B 521 und L 3209 gemäß einer baulichen Trennung in je zwei Wege auf*. Dann kommen zwei weitere Kreuzungspunkte hinzu. Jemand, der das TMC-Tagging nicht kennt, wird die aber nicht zur TMC-Relation hinzufügen, wie es eigentlich dem korrekten Tagging entsprechen würde.  Vielleicht löscht er auch Punkte oder ersetzt sie. Damit würde so ein (ziemlich wahrscheinlicher) Edit das TMC-Tagging aus der Bahn werfen, z.B. weil man die TMC-Punkte dann nur noch auf einer von zwei Richtungsfahrbahnen findet und es so aussieht, als würde man sie in der anderen Richtung gar nicht passieren. So ein Fehler dürfte auch schwer automatisiert zu finden sein, denn wenn man nur prüft, ob eine TMC-Relation an der richtigen Stelle vorhanden ist, findet man ja eine solche - sie ist aber nicht vollständig.

Also ich würde sagen so ein Locationcode ist keine einmalige Sache. Denn sonst würde man in Berlin beispielsweise ein Problem bekommen. http://www.openstreetmap.org/#map=18/52.56736/13.47575
Der Locationcode teilt die B2 in Höhe der Brücke und eigentlich auch gleichzeitig die Darßerstraße. Das kann aber kein gemeinsamer Punkt auf beiden Straßen sein.

Dann muss es in jede Richtung ein TMC Segment geben. Dies kann man sehrwohl automatisch validieren, indem man schaut ob die relation vom richtigen Start- zum Endpunkt geht und geschlossen ist.

Oder habe ich da etwas falsch verstanden?

Offline

#67 2014-01-07 19:16:37

MHohmann
Member
From: Tartu, Estonia
Registered: 2009-06-07
Posts: 1,600
Website

Re: Überarbeitung von TMC / TPEG

viw wrote:

Also ich würde sagen so ein Locationcode ist keine einmalige Sache. Denn sonst würde man in Berlin beispielsweise ein Problem bekommen. http://www.openstreetmap.org/#map=18/52.56736/13.47575
Der Locationcode teilt die B2 in Höhe der Brücke und eigentlich auch gleichzeitig die Darßerstraße. Das kann aber kein gemeinsamer Punkt auf beiden Straßen sein.

Ja, völlig richtig. Genau deshalb hat diese Kreuzung / Straßenverbindung zwei TMC-Locations, einmal 21558 entlang der B 2 und einmal 26858 entlang der L 1193 / Darßer Straße. Jedem TMC-Punkt ist eindeutig eine Straße bzw. ein Straßensegment zugeordnet, und wenn sich zwei Straßen kreuzen, die beide TMC-Codes haben, dann hat deren Kreuzung (mindestens) zwei Location Codes. So auch im Beispiel von mueschel (wobei es dort ja sogar gemeinsame Punkte auf beiden Straßen gibt).

Dann muss es in jede Richtung ein TMC Segment geben. Dies kann man sehrwohl automatisch validieren, indem man schaut ob die relation vom richtigen Start- zum Endpunkt geht und geschlossen ist.

Ja, das sollte im Prinzip gehen. Das wäre ja letztlich das gleiche Vorgehen wie bei einer Busroute, einmal in Vorwärtsrichtung und einmal in Rückwärtsrichtung.

Apropos, in den TMC-LCLs hat jeder Punkt außerdem eine Information darüber, ob man die zugehörige Straße an dieser Stelle in positiver bzw. negativer Richtung befahren bzw. verlassen kann. Das kann man also durchaus auch validieren - führt eine Straße dorthin bzw. weg, die eine Verbindung zum nächsten Knoten darstellt?

Damit ziehe ich meinen Einwand aus dem letzten Post zurück, was eine automatische Validierung angeht. Allerdings würde ich das Tagging ein wenig modifizieren. Ich würde es so machen, dass beim kompletten Durchfahren einer TMC-Route jeder TMC-Punkt, der zu dieser Route gehört, genau einmal in Form eines Nodes auf der Strecke durchfahren wird. Beim Beispiel von mueschel werden beim Durchfahren der B 521 von Westen nach Norden aber zwei Nodes durchfahren, die Mitglied der gleichen TMC-Relation sind, wobei diese Relation Teil der TMC-Route auf der B 521 ist. Stattdessen würde ich lieber nur einen Node (in diesem Fall http://www.openstreetmap.org/node/32906938) aufnehmen, da dieser immer durchfahren wird, egal in welcher Richtung. Wenn es an einer Kreuzung getrennte Richtungfahrbahnen gibt, braucht es dann genau zwei Nodes, einen pro Richtung, meinetwegen mit Rollen forward und backward o.ä. in der Relation, ähnlich wie z.B. bei Bushaltestellen.


SotM Baltics, 3.-4. August 2013, Tartu, Estonia: amenity=university, mappers=yes

Offline

#68 2014-01-07 19:28:15

viw
Member
Registered: 2010-05-15
Posts: 2,623

Re: Überarbeitung von TMC / TPEG

MHohmann wrote:

Damit ziehe ich meinen Einwand aus dem letzten Post zurück, was eine automatische Validierung angeht. Allerdings würde ich das Tagging ein wenig modifizieren. Ich würde es so machen, dass beim kompletten Durchfahren einer TMC-Route jeder TMC-Punkt, der zu dieser Route gehört, genau einmal in Form eines Nodes auf der Strecke durchfahren wird. Beim Beispiel von mueschel werden beim Durchfahren der B 521 von Westen nach Norden aber zwei Nodes durchfahren, die Mitglied der gleichen TMC-Relation sind, wobei diese Relation Teil der TMC-Route auf der B 521 ist. Stattdessen würde ich lieber nur einen Node (in diesem Fall http://www.openstreetmap.org/node/32906938) aufnehmen, da dieser immer durchfahren wird, egal in welcher Richtung. Wenn es an einer Kreuzung getrennte Richtungfahrbahnen gibt, braucht es dann genau zwei Nodes, einen pro Richtung, meinetwegen mit Rollen forward und backward o.ä. in der Relation, ähnlich wie z.B. bei Bushaltestellen.

Das ganze verstehe ich noch nicht. Was machst du denn bei einer richtungsgetrennten Fahrbahn welche von einer Landstraße ohne Trennung der Richtung gekreutz wird? Dann hast du auch zwei Knoten wegen der getrennten Straße. Aber durchfährst entweder zwei Punkte bei der nicht getrennten Straße oder es bleibt ein Stück frei.
Und was machst du wenn sich zwei Straßen mit getrennten Fahrbahnen treffen? Vielleicht sollte man das mal grafisch im Wiki verewigen.
Aber es sollte doch eigentlich über ein neues tagging nachgedacht werden statt das alte zu modifizieren?
Ich finde es schade das die Nutzer sich bisher nicht gemeldet haben. Insbesondere BR und SWR wären von Vorteil.

Offline

#69 2014-01-07 20:27:10

MHohmann
Member
From: Tartu, Estonia
Registered: 2009-06-07
Posts: 1,600
Website

Re: Überarbeitung von TMC / TPEG

viw wrote:

Das ganze verstehe ich noch nicht. Was machst du denn bei einer richtungsgetrennten Fahrbahn welche von einer Landstraße ohne Trennung der Richtung gekreutz wird? Dann hast du auch zwei Knoten wegen der getrennten Straße. Aber durchfährst entweder zwei Punkte bei der nicht getrennten Straße oder es bleibt ein Stück frei.

Also, wie oben beschrieben gehört zu einer TMC-Punkt-Location immer eindeutig eine TMC-Route. Nehmen wir an, in diesem Beispiel sind beide kreuzenden Straßen A (getrennt) und B (nicht getrennt) TMC-Routen. Dann hat die Kreuzung zwei verschiedene Location Codes, 1 mit Referenz auf A und 2 mit Referenz auf B.

In diesem Fall würde ich es dann so machen, dass ich 1 auf die beiden Kreuzungsnodes tagge. Wenn ich nun entlang von Straße A fahre, durchfahre ich immer genau einen dieser beiden Knoten. Was beim Durchfahren von Straße B und diesen beiden Nodes passiert, ist egal, da 1 nicht zu B gehört. Dagegen würde ich 2 auf einem Node in der Mitte der Kreuzung taggen, zwischen den beiden Kreuzungsnodes. Dieser Node wird dann genau einmal durchfahren, wenn man Straße B entlang fährt. Auch hier ist wieder egal, was beim Durchfahren von Straße A passiert, weil 2 nicht zu A gehört.

Auf diese Weise kann man die beiden Fahrbahnen von A jeweils so in zwei Teilstücke unterteilen, dass jeweils eines davon auf jeder Seite von Location 1 liegt. Ebenso kann man Straße B nun an Location 2 in zwei Teile aufteilen.

Und was machst du wenn sich zwei Straßen mit getrennten Fahrbahnen treffen?

In dem Fall würde ich die Nodes immer genau zwischen zwei Kreuzungsnodes setzen. Location 1 wäre also an Nodes auf den beiden Richtungsfahrbahnen von A, die zwischen den beiden Richtungsfahrbahnen von B liegen.

Vielleicht sollte man das mal grafisch im Wiki verewigen.

Ja, gute Idee, ich werde das mal versuchen zu zeichnen.

Aber es sollte doch eigentlich über ein neues tagging nachgedacht werden statt das alte zu modifizieren?

Das denke ich auch. Das war auch nur eine Überlegung, mit welchen OSM-Objekten man generell eine TMC-Location assoziieren könnte. Ob man das nun besser als Relation taggt oder mittels eines TMC-Schlüssel an diesen Punkten wie im Proposal im Wiki ist eine andere Frage, da bin ich mir selbst noch nicht ganz sicher. Aber auf jeden Fall sollten die Tags, egal ob an Relation oder Node, einfacher sein als dieses cid_X:tabcd_Y-Gewirr, das kein Mensch versteht. tmc:point=*, tmc:road=*, tms:segment=* würde ich eher im Sinn haben.

Ich finde es schade das die Nutzer sich bisher nicht gemeldet haben. Insbesondere BR und SWR wären von Vorteil.

Sehe ich auch so, gerade von denen wäre es doch gut zu wissen, was gewünscht ist. Insofern kann ich zumindest als Navit-Entwickler und damit hoffentlich zukünftiger Nutzer ein wenig die Perspektive der Router einbringen.


SotM Baltics, 3.-4. August 2013, Tartu, Estonia: amenity=university, mappers=yes

Offline

#70 2014-01-07 21:47:41

streckenkundler
Member
From: Lübben (Spreewald)
Registered: 2012-08-09
Posts: 4,952
Website

Re: Überarbeitung von TMC / TPEG

Von der Sache her dürfte es abfragetechnisch (für Anwendungen, die TMC-Daten aus OSM verarbeiten) für TMC egal sein, ob die Relation type=road oder type=TMC ist. Da so oder so beides ausgewertet werden muß.

Ist die Master-Relation type=road und die Slave-Relation type=TMC wird entweder erst "type=road" ausgewertet um auf das das "type=TMC" - Segment zu kommen, oder beides wird eh gleichzeitig ausgewertet. Die für die Auswertung relevante Information hier steckt in dem Tag des LCL-Codes, der für den betreffenden Straßenabschitt in einer Relation mit type=TMC steckt.

Betrachtet man eine Master-Reation "type=road" mit den Slave-Relationen "type=TMC" so steckt der für die TMC-Meldung auszuwertende LCL-Code in der Slave-Relation type=TMC. Im LCL-Code in der Master-Relation steckt nur die gesamte betreffende Straße drin. Bei TMC-Master-Slave-Relationen hat man immer mehrere LCL-Codes: der erste für die gesamte Straße, der zweite für das jeweilige Segment. Hinzu kommen die LCK-Codes der Knotenpunkte.
Beachten muß man dabei auch, daß nicht zwingend eine Straße immer in Segmenten geteilt ist. In der o.g. Liste sind eine Reihe von Straßen drin, die nicht segmentiert sind, also nur einen LCL-Code haben (dann zuzüglich zweier Punkte: Start und Ende).

In der Auswertung braucht sowieso lediglich nur der LCL-Code abgefragt zu werden. Je nachdem, welche Nummer man hat, landet man am Startpunkt der Straße, am Code des Gesamtverlaufes der Straße, an einem ihrer Abschnitte oder einem ihrer Zwischenpunkte oder sonstwo...

Ich betrachte daher die saubere Trennung zwischen Straßen- und TMC- Relationen als unproblematisch, im Gegenteil, die dann entstehenden TMC-Relationen erfahren eine Überarbeitung, zu mindestens in Hinblick der Vollständigkeit der Elemente.

Sven

Offline

#71 2014-01-07 23:04:50

mueschel
Member
Registered: 2012-06-11
Posts: 1,152
Website

Re: Überarbeitung von TMC / TPEG

MHohmann wrote:

Ich würde es so machen, dass beim kompletten Durchfahren einer TMC-Route jeder TMC-Punkt, der zu dieser Route gehört, genau einmal in Form eines Nodes auf der Strecke durchfahren wird. Beim Beispiel von mueschel werden beim Durchfahren der B 521 von Westen nach Norden aber zwei Nodes durchfahren, die Mitglied der gleichen TMC-Relation sind, wobei diese Relation Teil der TMC-Route auf der B 521 ist. Stattdessen würde ich lieber nur einen Node (in diesem Fall http://www.openstreetmap.org/node/32906938) aufnehmen, da dieser immer durchfahren wird, egal in welcher Richtung

Überlegt hatte ich das, aber in komplexen Situationen sehe ich das als nicht ganz so brauchbar an. Ich denke aber, dass es kein Problem ist Knoten an einer komplexen Kreuzung "großzügig" mit in die TMC-Relation aufzunehmen, auch wenn dann mehrere Knoten befahren werden. TMC-Abschnitte von einem Knoten zum anderen sollten dann immer von letzten erreichten Knoten bei A zum ersten erreichten Knoten bei B gehen. Man sollte allerdings wohl noch den Übergang von einem Segment auf ein kreuzendes im Auge behalten - dafür müsste auch ein Knoten der Abbiegespur an "meiner" Kreuzung noch mit aufgenommen werden.

Offline

#72 2014-01-08 00:06:02

MHohmann
Member
From: Tartu, Estonia
Registered: 2009-06-07
Posts: 1,600
Website

Re: Überarbeitung von TMC / TPEG

Das

mueschel wrote:

Überlegt hatte ich das, aber in komplexen Situationen sehe ich das als nicht ganz so brauchbar an. Ich denke aber, dass es kein Problem ist Knoten an einer komplexen Kreuzung "großzügig" mit in die TMC-Relation aufzunehmen, auch wenn dann mehrere Knoten befahren werden. TMC-Abschnitte von einem Knoten zum anderen sollten dann immer von letzten erreichten Knoten bei A zum ersten erreichten Knoten bei B gehen. Man sollte allerdings wohl noch den Übergang von einem Segment auf ein kreuzendes im Auge behalten - dafür müsste auch ein Knoten der Abbiegespur an "meiner" Kreuzung noch mit aufgenommen werden.

Das kann man durchaus machen, die Auswertung sollte auf jeden Fall kein Problem sein. Die Problematik sehe ich eher darin, so ein Tagging zu validieren, wenn jemand die Kreuzung bearbeitet hat. Woran erkennt man, dass alle aufzunehmenden Nodes in der Relation enthalten sind? Wenn es immer genau einen bzw. einen pro Richtung gibt, ist das eindeutig.

Aber du hast Recht, bei komplexeren Kreuzungen stellt sich natürlich die Frage, wo denn dieser eine Knoten sein soll. Genau so bei Autobahnausfahrten - bei der Ausfahrt, der Einfahrt oder dazwischen?


SotM Baltics, 3.-4. August 2013, Tartu, Estonia: amenity=university, mappers=yes

Offline

#73 2014-01-08 11:26:03

AtLa
Member
Registered: 2014-01-08
Posts: 1

Re: Überarbeitung von TMC / TPEG

Schina02 wrote:

Ich kenne mich damit nicht aus. Aber ich denke es ist wichtig, dass das System auch abwärtskompatibel ist. Und am besten wird es natürlich auch sein, je mehr Systeme unterstützt werden. So wie es scheint ist TMC rein passiv und funktioniert durch UKW. Funktioniert das dann auch wenn man ein TPEG-fähiges Gerät hat bzw. funktioniert TPEG auch wenn TMC nicht mehr in OSM ist auf einem alten Gerät?

TPEG ist nur ein Container, es kommt darauf an was man hineinpackt. In TPEG kann man auch TMC Loc-Referenzierungen angeben. Das tut man auch gerne weil diese schön kurz sind und alle Navis TMC verstehen. Siehe TPEG-TEC
Im übrigen steht im TPEG exakt das drinn was auch in TMC drinn steht, was sonst?

Was ich gerade sehe: TPEG soll auch für den öffentlichen Personenverkehr gemacht werden/sein. Heißt das, dass dies eine Art Fahrplanauskunft ist und ÖPNV-Routing ohne weitere Daten ermöglicht?

Nein. TPEG ist ein Container wo man im Header sagen kann was kommt. So hat man für die ÖPNV ein Container gemacht, der allerdings gefüllt werden soll. Ganze Fahrpläne zu broadcasten wäre hirnrissig, es reicht die Verspätungen und aktuelle An- und Abfahrten in 20-30 Minuten Umkreis. Idee dabei war die Locationlisten zu verbinden - also Parkhaus zu Bahnsteig, und so den Reisenden durchzunavigieren.

Offline

#74 2014-01-10 00:11:42

MHohmann
Member
From: Tartu, Estonia
Registered: 2009-06-07
Posts: 1,600
Website

Re: Überarbeitung von TMC / TPEG

Ich habe mal die frei verfügbaren Location Code Tabellen von Deutschland, Italien, Schweden und Norwegen in eine Datenbank geladen und ein paar Abfragen dazu erstellt. Das ganze ist sicher weder perfekt noch komplett, aber zumindest die Straßen werden schon einmal auf Wunsch angezeigt, zusammen mit den dazugehörigen Wegpunkten. Hier ist die Startseite:

http://manuelhohmann.dyndns.org/osm/TMC.html

Die Daten gibt es als einfache Kartenansicht oder auch gleich zum Download als GPX. Wenn jemand einen Fehler finden sollte oder etwas nicht funktioniert, oder sich jemand ein Feature wünscht, einfach bei mir melden, dann schaue ich, was ich machen kann.


SotM Baltics, 3.-4. August 2013, Tartu, Estonia: amenity=university, mappers=yes

Offline

#75 2014-01-10 11:31:05

viw
Member
Registered: 2010-05-15
Posts: 2,623

Re: Überarbeitung von TMC / TPEG

MHohmann wrote:

Ich habe mal die frei verfügbaren Location Code Tabellen von Deutschland, Italien, Schweden und Norwegen in eine Datenbank geladen und ein paar Abfragen dazu erstellt. Das ganze ist sicher weder perfekt noch komplett, aber zumindest die Straßen werden schon einmal auf Wunsch angezeigt, zusammen mit den dazugehörigen Wegpunkten. Hier ist die Startseite:

http://manuelhohmann.dyndns.org/osm/TMC.html

Die Daten gibt es als einfache Kartenansicht oder auch gleich zum Download als GPX. Wenn jemand einen Fehler finden sollte oder etwas nicht funktioniert, oder sich jemand ein Feature wünscht, einfach bei mir melden, dann schaue ich, was ich machen kann.

Na dann wollen wir mal Wünsche wünschen. Wie wäre es das ganze als WMS zur Einbindung in JOSM?

Also ich könnte mir vorstellen in meinem Bereich wenigstens die Locationcodes anzulegen. Dann sollten wir aber noch darüber sprechen nach welchem Schema das am besten geschehen sollte.

Offline

Board footer

Powered by FluxBB