Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-16 Diskussionsfäden marcus.wolschon


Ich habe mal 
http://wiki.openstreetmap.org/wiki/TMC/TMC_Import_Germany#WORK_TO_BE_DONE
etwas aufgeräumt, so dass man da mit der Arbeit des eigentlichen Imports
demnächst anfangen könnte.

Müssen wir uns nur vorher noch einigen ob wir an dem Tagging-Schema noch
Änderungen vornehmen wollen.

Ich würde dann dieses oder eines der kommenden Wocheenden mal OSM-Exporte
der diversen LCL-Elemente machen und online stellen sowie den Inhalt
der Wiki-Tabellen generieren.

Marcus

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-16 Diskussionsfäden André Riedel
Am 16. September 2009 07:18 schrieb Marcus Wolschon mar...@wolschon.biz:
 On 2009-09-15, André Riedel riedel.an...@gmail.com wrote:
 Ich bin der Meinung, dass wir nicht die LCL in den OSM-Daten abbilden
 müssen, sondern nur diese Teile, dass man eindeutig ein Punkt oder
 Segment bestimmen kann. Andere in den LCL-Daten enhaltene
 Informationen gibt es vielfach schon in OSM und müssen so nicht extra
 an das Element gehängt werden.

 Welche Informationen meinst du?

Ich meine die Informationen, dass wir nicht in die OSM-Daten schreiben
müssen, dass Punkt 11181 in der Gemeinde Lichtenau in
Sachsen/Deutschland ist.

 Außer den OSM-Objekten welche einem Ort entsprechen
 braucht man die verkettete Liste der LCL-Elemenet um eine Nachricht
 auswerten zu können (Nachricht sagt: Von LocationCode 3 bis
 2 Schritte nach vorne.)

Es wird also nur ein Node angegeben und dann wieviel Nodes auf dem
selben Segment durchlaufen werden müssen? Gibt es noch mehr
Verständliche Beispiele dieser TMC-Nachrichten, damit man das System
besser verstehen kann.

 Erster Vorschlag auf Basis meines bisherigen TMC-Verständnis:

 So wie ich das jetzt gesehen, habe gehören zur Beschreibung eines
 Objektes mit einem Location Code auf jeden Fall der Ländercode (CID)
 und Tabellennummer (TABCD) dazu. Da man bisher davon ausgeht, dass
 folgende LCL-Versionen (Location Code List) zu älteren
 Navigationsgeräten kompatibel sein sollten, kann man die Version
 vielleicht vernachlässigen. Sie sollte aber auf jeden Fall bei der
 Eingabe im Changeset erscheinen.

 Bisher gibt es folgende Version zur Abbildung der Raststätte
 Auerswalder Blick:
 TMC:cid_81:tabcd_1:LocationCode = 11181

 Für ein Programm ist es wahrscheinlich egal, ob die eindeutig
 Bestimmung durch den OSM-Key, den OSM-Value oder durch beide möglich

 nicht wirklich. Mit dem jetzigen Schhema kann man gegeben
 die empfangenen CID und Tabcd -Paare in einem simplen Index
 nach dem key suchen und erhält genau die OSM-Elemente welche
 man braucht.

Das geht andersrum auch. Such einfach nach allen Elementen mit dem
Schlüssel TMC:LocationCode , welche den Wert 81:1:11181 haben.

 Da man eine Autobahn mit nur einer Linie und die beidseitige
 Raststätte mit nur einem Punkt auf der Linie abbildet, diese in den
 OSM-Daten aber aus einer Linie pro Fahrtrichtung und zwei Nodes
 besteht, bieten sich für fast alle Varianten Relationen an. Nur
 einmalig vorhandene OSM-Elemente, wie Parkplätze, Seen,
 Gemeindegrenzen usw., können jedoch dirket mit den TMC-Daten ergänzt
 werden.

 Vorsicht: Das sind je nach Richtung (Richtung in der verketteten Liste
 der LCL-Elemente) 2 verschiedene Strassen/Rastplätze.
 Es wird immer gesendet ob die Richtung vorwärts oder rückwärts
 gemeint ist.

Gut dann muss diese Information noch angehängt werden. Aber welches
OSM-Objekt würdest du als Rastplatz taggen. Siehe dazu das Beispiel:
http://osm.org/go/0MIeIXDw

 Für mich stellt sich jetzt die Frage, wie mit den Linien-Abschnitten
 (Segments) verfahren werden soll. Im Moment bevorzuge ich die
 Variante, dass man pro Segment (von einem Location Code-Punkt zum
 nächsten) eine Relation erstellt und alle eingeschlossenen Wege als
 Kind hinzufügt.

 Das wird sehr, sehr viel manuelles Relationen-Anlegen.
 Grundsätzlich gerne aber es macht es nicht leichter.

 Aber wie benennen, denn oft haben diese Segmente keine
 eigene ID und werden nur durch den Vorgänger und Nachfolger bestimmt.

 ist ein Problem.

Gerade für solche Abschnitte empfiehlt sich doch eine Relation. Da es
zwischen zwei TMC-Punkte (bspw. Kreuzungen) mehrere Wege gibt, muss
man den korrekten Weg irgendwie beschreiben. Also entweder an alle ein
tmc:cid:tabcd:segment = start-end oder alle Wege in die Relation. Auf
Grund der Sortiermöglichkeiten seit API 0.6 kann man damit sogar die
TMC-Richtung abbilden.

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-16 Diskussionsfäden Marcus Wolschon
2009/9/16 André Riedel riedel.an...@gmail.com:
 Am 16. September 2009 07:18 schrieb Marcus Wolschon mar...@wolschon.biz:
 Außer den OSM-Objekten welche einem Ort entsprechen
 braucht man die verkettete Liste der LCL-Elemenet um eine Nachricht
 auswerten zu können (Nachricht sagt: Von LocationCode 3 bis
 2 Schritte nach vorne.)

 Es wird also nur ein Node angegeben und dann wieviel Nodes auf dem
 selben Segment durchlaufen werden müssen? Gibt es noch mehr
 Verständliche Beispiele dieser TMC-Nachrichten, damit man das System
 besser verstehen kann.

Lass und bie der richtigen Terminologie bleiben um OSM und LCL -Entitäten
nicht durcheinander zu bringen.

Eine Nachricht kann sagen, Stau an dem Objekt 1234 bis 3 Schritte zurück.
Dann heißt dass 1234, sein Vorgänger, dessen
Vorgänger, ... .
1234 kann dabei ein Point sein, ein Segment oder eine Road.
(All diese Entitäten haben Vorgänger und Nachfolger.)

Jeder dieser Points in der LCL kann durchaus mehere Nodes und Ways
in OSM sein und es kann auch für vorwärts eine andere Menge von Ways
als für Rückwärts sein.
Einfaches Beispiel wäre ein Point mitten auf
freier Strecke auf einer Autobahn = 2 Nodes, eine rpro Richtung.
Oder ein Autobahnkreuz  = je 2 Auf/Abfahrten pro Richtung
Oder ein Kreizverkehr in einer Bundesstrasse = 1 Way aber der gleiche
vorwärte wie rückwärts.

Bei Kreuzungen gibt es noch Intersections.
d.H. eine als Ring verkettere Folge von Points.
Alle haben die gleiche Koordinate aber jede gehört zu
einem anderen Segment einer anderen Road.
 Für ein Programm ist es wahrscheinlich egal, ob die eindeutig
 Bestimmung durch den OSM-Key, den OSM-Value oder durch beide möglich

 nicht wirklich. Mit dem jetzigen Schhema kann man gegeben
 die empfangenen CID und Tabcd -Paare in einem simplen Index
 nach dem key suchen und erhält genau die OSM-Elemente welche
 man braucht.

 Das geht andersrum auch. Such einfach nach allen Elementen mit dem
 Schlüssel TMC:LocationCode , welche den Wert 81:1:11181 haben.

Das hieße alle Elemente deiner Karte welche inen
TMC:LocationCode haben aus der Datenbank/Datei zu laden
um 99.99% davon im Vergleich des Wertes wegzuwerfen.
Das wären die Strassennetze ganzer Kontinente von denen
wir reden.

 Vorsicht: Das sind je nach Richtung (Richtung in der verketteten Liste
 der LCL-Elemente) 2 verschiedene Strassen/Rastplätze.
 Es wird immer gesendet ob die Richtung vorwärts oder rückwärts
 gemeint ist.

 Gut dann muss diese Information noch angehängt werden. Aber welches
 OSM-Objekt würdest du als Rastplatz taggen. Siehe dazu das Beispiel:
 http://osm.org/go/0MIeIXDw

Ich würde für Vorwärts und für Rückwärte jeweils alle Service-Roads
der jeweiligen Seite so taggen. Da alle von einem Ereigniss z.B. Sperrung
der Rastanlage wegen Feuer betroffen wären und nicht nur ein Punkt auf einer
dieser Strassen.
Besser etwas zu viel als zu wenig.  So dass der Bereich bei einem Event auc
tatsächlich gemieden wird.

 Gerade für solche Abschnitte empfiehlt sich doch eine Relation. Da es
 zwischen zwei TMC-Punkte (bspw. Kreuzungen) mehrere Wege gibt, muss
 man den korrekten Weg irgendwie beschreiben. Also entweder an alle ein
 tmc:cid:tabcd:segment = start-end oder alle Wege in die Relation. Auf
 Grund der Sortiermöglichkeiten seit API 0.6 kann man damit sogar die
 TMC-Richtung abbilden.

Ich würde pro Richtung eine Relation machen.
So bleibt das robuster.

Für simple Fälle z.B. Point ist nur ein Node oder ein Way eines
Kreisverkehres aber direkt das Objekt taggen.
Sonst wird man bei den ganzen simpel gelageten Bundestrassen
und wichtigen Landstrassen mechugge.

Marcus

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-16 Diskussionsfäden Mirko Küster
 Ich habe mal
 http://wiki.openstreetmap.org/wiki/TMC/TMC_Import_Germany#WORK_TO_BE_DONE
 etwas aufgeräumt, so dass man da mit der Arbeit des eigentlichen Imports
 demnächst anfangen könnte.

Nochmal, das ganze bitte auch verständlich in Deutsch. Schön wenn das 
Insider usw. verstehen. Nur kannst du dir einen Import sparen, wenn die Keys 
nach und nach mangels Hintergrundinfos wieder gelöscht werden. Ich glaube 
nicht das sich die Key Erdenker dann ums fixen kümmen, das bleibt auf dem 
lokalen Mappern hängen.

Wäre ja schön wenn sowas nach einmal importieren sitzen würde. Nur sieht die 
tägliche Praxis beim Mappen ein klein wenig anders aus. Das ist nunmal ein 
Jedemann Projekt und da muss man mit sowas rechnen. Ganz verhindern lassen 
sich Fehler natürlich nicht, mit vernünftiger Doku aber veringern. Das hält 
die Arbeit vor Ort in Grenzen. Es macht ansonsten keinen Spaß mehr sich um 
die Pflege solch komplexer Dinge zu kümmern, wenn das ständig kaputt geht. 
Bei den Straßenrelationen habe ich es z.B. schon aufgegeben. Die werden 
nahezu wöchentlich zerkloppt, fixen aussichtslos. Wenn das gleiche mit TMC 
losgeht dann gute Nacht.

Gruß
Mirko 


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-16 Diskussionsfäden Marcus Wolschon
2009/9/16 Mirko Küster webmas...@ts-eastrail.de:
 Ich habe mal
 http://wiki.openstreetmap.org/wiki/TMC/TMC_Import_Germany#WORK_TO_BE_DONE
 etwas aufgeräumt, so dass man da mit der Arbeit des eigentlichen Imports
 demnächst anfangen könnte.

 Nochmal, das ganze bitte auch verständlich in DeutschIch
...
 Wäre ja schön wenn sowas nach einmal importieren sitzen würde. Nur sieht die
 tägliche Praxis beim Mappen ein klein wenig anders aus. Das ist nunmal ein
 Jedemann Projekt und da muss man mit sowas rechnen. Ganz verhindern lassen
 sich Fehler natürlich nicht, mit vernünftiger Doku aber veringern.

Die Links für mehr Doku sind ja schon da. Erstmal wollte ich warten
ob hier noch Voschläge bzgl- eines besseren Taging-Schemas kommen.

Marcus

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-15 Diskussionsfäden marcus.wolschon
On Mon, 14 Sep 2009 09:37:08 +0200, André Riedel riedel.an...@gmail.com
wrote:
 Was kann getan werden? Wäre es möglich einen WMS-Layer von den TMC-
 oder OpenLR-Linien zu erstellen, um so die nötigen Informationen an
 die Straßen in OSM anzufügen.

Ein Export-Werkzeug der TMC-LCL eines Landes Export als OSM-Daten gibt
es schon. Zum Arbeiten macht es mehr sinn das als 2ten Layer in JOSM
zu laden. Hab ich testweise schon für kleine Gebiete gemacht und geht
ganz gut.


 (navi:tmc = 12345, navi:openlr =
 f2332f4) Dann könnte man das ganze in DE:Aktionen einbinden und es
 wäre innerhalb von einer Woche komplett.
 
 Das anhängen an die OSM-Daten hätte den Nachteil, dass es jederzeit
 durch Fehler gefälscht werden könnte,

In der Praxis vernachlässigbar.

 So nun noch einmal die Frage: Welche Hilfe wird benötigt und was kann
 der OSM-Michel dazu beitragen?

Aufteilen der Daten in Arbeitspakete, Sammeln von Freiwilligen,
Tracken wer sich welches Paket schnappt, wer welches Paket validiert
und welche schon erledigt sind.
Schreiben einer besser verständlichen Anleitung für die Freiwilligen.
Automatischer Import und manuelle Verifikation der Autobahn-Stücke
(Bundesstrassen, Punkte, wichtige Landesstrassen, Gebiete und
Autobahnkreuze/Abfahrten müssen aufgrund des Detailgrades in OSM
manuell gemacht werden.)

Marcus

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-15 Diskussionsfäden Ulf Lamping
Marcus Wolschon schrieb:
 Schau mal im Wiki.

Hab ich gemacht.

Ich hab dann gleich ein paar Kleinigkeiten korrigiert (Tippfehler, ein 
paar Sätze umgestellt, ... :-)

(übrigens: name:loc - loc_name und ref:loc - loc_ref)

Sollte man den sehr länglichen Absatz automatic import nicht besser 
auf eine eigene Seite verbannen, oder ist das für den Anwender wichtig?

 Die Codes kannst du dir bei der Bafin maschinenlesbar abholen.
 Die Rohform online stellen ist nicht zulässig.
 Der Code um deren Format in was für uns brauchbares zu
 transformieren existiert schon seid ewig.

Und nu?

Ich hab mir die gesamte Seite durchgelesen und schlicht nicht verstanden 
was jetzt zu tun wäre.

Meine aktuelle grobe Vorstellung:

a) LCL Codes von der Bafin holen
b) Mit deinem Tool LCL nach .osm Format konvertieren
c) In JOSM laden und mit den bestehenden OSM Daten vergleichen
d) TMC:xy Tags in den OSM Daten setzen und nach OSM hochladen

Sehe ich das so erstmal richtig?

Um ein paar Leute zu motivieren das auch zu tun, was wollen wir dann mit 
den Tags später mal anstellen? :-)

Gruß, ULFL

[1] http://wiki.openstreetmap.org/wiki/TMC/TMC_Import_Germany#The_import

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-15 Diskussionsfäden André Riedel
Am 15. September 2009 07:29 schrieb Marcus Wolschon mar...@wolschon.biz:
 Ich sagte schon daß die Vorbereitungen schon gemacht sind.
 Tagging-Schema und da Ausarbeiten wie die Abbildung auf OSM
 geht sind schon seid Monaten gemacht.
 Werkzeuge existieren auch schon.
 Sogar ein Navi was die nach dem Tagging-Schema auswertet existiert.

Das Tagging-Schema würde ich gerne noch einmal diskutieren. Warum
genügt der LocationCode in den OSM-Daten allein nicht? Die anderen
Daten können doch aus der seperaten LCL-Liste gelesen werden. Bei
Segmenten sollte man überlegen, ob man die beinhalteten Straßen in
eine Relation packt.

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-15 Diskussionsfäden Tobias Wendorff
Am Di, 15.09.2009, 10:48 schrieb Ulf Lamping:

 Um ein paar Leute zu motivieren das auch zu tun, was wollen wir dann mit
 den Tags später mal anstellen? :-)

TCM-Decoder für UKW/FM gibt es bei eBay, Software im Netz.

Schon kann man unterwegs mit dem Netbook Staus (etc.) erkennen und ggf.
umfahren.


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-15 Diskussionsfäden Mirko Küster
 Schau mal im Wiki.

Seit gestern kenne ich die Seite, leider ausführlich in Englisch.

Das brauchts kompakter und für Mapper verständlich am besten noch in 
deutsch. Dann eine Aktion daraus gemacht und in einer Woche ist das 
umgesetzt. Im Moment verstehe ich da nur Bahnhof Bratkartoffreln.

 Die Codes kannst du dir bei der Bafin maschinenlesbar abholen.

Das hatte ich auch gesehen. Nur bevor ich da irgendwelche Daten bei der 
Bafin angeben wollte, wollte ich erstmal wissen wie und was. Wenn das kommt 
kannst du Teile von Thüringen, Sachsen und Sachsen-Anhalt schon als abgehakt 
betrachten.

Gruß
Mirko 


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-15 Diskussionsfäden Tobias Wendorff
Am Di, 15.09.2009, 12:54 schrieb Mirko Küster:
 Wenn das
 kommt
 kannst du Teile von Thüringen, Sachsen und Sachsen-Anhalt schon als
 abgehakt
 betrachten.

Ich melde mich für die fehlenden Teile in NRW sowie Datenkontrolle in
anderen Bundesländern .


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-15 Diskussionsfäden marcus.wolschon
On Tue, 15 Sep 2009 10:48:41 +0200, Ulf Lamping
ulf.lamp...@googlemail.com
wrote:
 Marcus Wolschon schrieb:
 Schau mal im Wiki.
 
 Hab ich gemacht.
 
 Ich hab dann gleich ein paar Kleinigkeiten korrigiert (Tippfehler, ein 
 paar Sätze umgestellt, ... :-)

Danke :)

 Ich hab mir die gesamte Seite durchgelesen und schlicht nicht verstanden 
 was jetzt zu tun wäre.
 Meine aktuelle grobe Vorstellung:
 
 a) LCL Codes von der Bafin holen

Hab ich hier liegen und kann ich geben.
Kann man nur nicht einfach so auf eine Webseite stellen.
(Aber die Codes an Objekte in OSM anhängen ist erlaubt.)

 b) Mit deinem Tool LCL nach .osm Format konvertieren
 c) In JOSM laden und mit den bestehenden OSM Daten vergleichen
 d) TMC:xy Tags in den OSM Daten setzen und nach OSM hochladen

So sieht es aus.
Man könnte eine Liste der enthaltenen Roads machen und dass sich
zu jeder zuerst einer Einträge der sie gerade in OSM einbaut
(damit sich keine 2 Leute über den Haufen rennen) und danach
optional einer der das nochmal prüft.

Ich kann die Code für die Autobahnen in ein paar Stunden an
unsere Autobahn-Relationen anhängen. Ebenso für die geographischen,
politischen und metereologischen Gebiete.
Dann bleiben nur ein riesen Haufen Punkte (Meist Kreuzungen),
Bundes- und wichtige Landstrassen sowie Autobahn-Segmente.

Ich kann zur Prüfung etwas schreiben, was z.b. eine lokale .osm -Datei
nimmt und die korrekt getaggten TMC-Segmente rendert sowie auf einfach
zu findende Fehler schaut. (Löcher in Wegen, Nächter/Letzter
Reihenfolgen,
fehlende Sachen, Schreibfehler)

 Sehe ich das so erstmal richtig?
 
 Um ein paar Leute zu motivieren das auch zu tun, was wollen wir dann mit 
 den Tags später mal anstellen? :-)

Jedes Navi was TMC-Daten (welche man im NMEA-Datenstrom von guten GPS-
empfängern bekommt) parsen kann, kann damit z.B. grundsätzlich Staus
umfahren.
In Traveling Salesman hab ich das schon eingebaut und es funktioniert in
Tests
wunderbar.
Weiterhin haben wir durch den Import eine Möglichkeit unser Strassennetz
auf
Vollständigkeit zu prüfen, da jede benannte Strasse, Kreuzung, Punkt oder
Gebiet ja auch existieren muss.

Marcus

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-15 Diskussionsfäden Florian Lohoff
On Mon, Sep 14, 2009 at 09:37:08AM +0200, André Riedel wrote:
 Vielleicht hilft keiner, weil er das Thema nicht genau verstanden hat
 und weiß was er machen kann.
 Was kann getan werden? Wäre es möglich einen WMS-Layer von den TMC-
 oder OpenLR-Linien zu erstellen, um so die nötigen Informationen an
 die Straßen in OSM anzufügen. (navi:tmc = 12345, navi:openlr =
 f2332f4) Dann könnte man das ganze in DE:Aktionen einbinden und es
 wäre innerhalb von einer Woche komplett.

http://wiki.openstreetmap.org/wiki/TMC/TMC_Import_Germany

navi:tmc ist zu wenig - die LCL ist nicht Globally Unique.

Flo
-- 
Florian Lohoff f...@rfc822.org
Es ist ein grobes Missverständnis und eine Fehlwahrnehmung, dem Staat
im Internet Zensur- und Überwachungsabsichten zu unterstellen.
- - Bundesminister Dr. Wolfgang Schäuble -- 10. Juli in Berlin 


signature.asc
Description: Digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-15 Diskussionsfäden Tobias Wendorff
Am Di, 15.09.2009, 15:06 schrieb Florian Lohoff:

 navi:tmc ist zu wenig - die LCL ist nicht Globally Unique.


Setzen wir halt ein :DE dahinter.

Bei der Aktion
sollten wir aber auch OpenLR gleich mitnehmen.

Wäre doch genial für eine Pressemitteilung und unsere PR.


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-15 Diskussionsfäden Florian Lohoff
On Tue, Sep 15, 2009 at 03:21:23PM +0200, Tobias Wendorff wrote:
 Am Di, 15.09.2009, 15:06 schrieb Florian Lohoff:
 
  navi:tmc ist zu wenig - die LCL ist nicht Globally Unique.
 
 
 Setzen wir halt ein :DE dahinter.

Not enough - In DE gibt es alleine 2 LCLs (TMC und TMCPro) die sich
nummerisch ueberschneiden. Und wenn man an Laender wie Rußland oder
China denkt wird eine LCL bzw table dort nicht ausreichen sondern die werden
pro Provinz mindestens eine LCL table haben.

SO weit ich weiss (man moege mich korrigieren) benutzt TMCPro einen 
anderen Country Identifier ...

Dazu kommt das es moeglich ist mehrere tables zu benutzen (TMC Location Code 
ist 16 bit,
also fuer China und Rußland moeglicherweise zu wenig) -also ist 
es wichtig zu welcher table diese LCL gerade gehoert.

Also tmc:cid:tableid=lcl code

Flo
-- 
Florian Lohoff f...@rfc822.org
Es ist ein grobes Missverständnis und eine Fehlwahrnehmung, dem Staat
im Internet Zensur- und Überwachungsabsichten zu unterstellen.
- - Bundesminister Dr. Wolfgang Schäuble -- 10. Juli in Berlin 


signature.asc
Description: Digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-15 Diskussionsfäden marcus.wolschon
On Tue, 15 Sep 2009 12:29:25 +0200, André Riedel riedel.an...@gmail.com
wrote:
 Am 15. September 2009 07:29 schrieb Marcus Wolschon
mar...@wolschon.biz:
 Ich sagte schon daß die Vorbereitungen schon gemacht sind.
 Tagging-Schema und da Ausarbeiten wie die Abbildung auf OSM
 geht sind schon seid Monaten gemacht.
 Werkzeuge existieren auch schon.
 Sogar ein Navi was die nach dem Tagging-Schema auswertet existiert.
 
 Das Tagging-Schema würde ich gerne noch einmal diskutieren. Warum
 genügt der LocationCode in den OSM-Daten allein nicht?

Weil es mehrere Länder mit TMC gibt und mehrere Anbieter pro Land
sowie mehrere Versionen jeder LCL. (typischerweise aber kompatibel.)

Mit gefällt die Länge der Tags auch nicht so recht aber sie sollten
schon wie alles andere auch sich auf den ersten Blick erschliessen.
Optimal sind die Tags nicht.

 Die anderen
 Daten können doch aus der seperaten LCL-Liste gelesen werden.

Der Zweck ist ja gerade ganz ohne die LCL auszukommen, nur mit
der OSM-Karte und einem Empfänger. Oder registrierst du dich auf
irgendwelchen Webseiten bevor du rüber nach Italien fährst um
dort was von einer Behörde auf Italienisch runterzuladen?
(Mitliefern bei jedem Navi in Rohform geht ja wieder nicht und bei
 OpenSource kann man wenig verstecken wie in kommerzieller Software.)

 Bei
 Segmenten sollte man überlegen, ob man die beinhalteten Straßen in
 eine Relation packt.

Wäre eine Überlegung wert.

Schlag was vor! :)
(Endlich mal Konstruktives)

Marcus

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-15 Diskussionsfäden Tobias Wendorff
Am Di, 15.09.2009, 15:29 schrieb Florian Lohoff:

 SO weit ich weiss (man moege mich korrigieren) benutzt TMCPro einen
 anderen Country Identifier ...

Löst OpenLR ein solches Problem?

 Dazu kommt das es moeglich ist mehrere tables zu benutzen (TMC Location
 Code ist 16 bit,
 also fuer China und Rußland moeglicherweise zu wenig) -also ist
 es wichtig zu welcher table diese LCL gerade gehoert.

Vielleicht eine Dictionary-/Translation-Datenbank? OSM-Nodes und die
passenden TCM und -Pro-IDs?



___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-15 Diskussionsfäden Florian Lohoff
On Tue, Sep 15, 2009 at 03:41:24PM +0200, Tobias Wendorff wrote:
 Am Di, 15.09.2009, 15:29 schrieb Florian Lohoff:
 
  SO weit ich weiss (man moege mich korrigieren) benutzt TMCPro einen
  anderen Country Identifier ...
 
 Löst OpenLR ein solches Problem?

Welches Problem? Und was soll es loesen?

  Dazu kommt das es moeglich ist mehrere tables zu benutzen (TMC Location
  Code ist 16 bit,
  also fuer China und Rußland moeglicherweise zu wenig) -also ist
  es wichtig zu welcher table diese LCL gerade gehoert.
 
 Vielleicht eine Dictionary-/Translation-Datenbank? OSM-Nodes und die
 passenden TCM und -Pro-IDs?

Koennte man machen wenn OSM IDs stabil waeren - sind sie aber nicht.

Das die OpenStreetRouting leute ja TMC machen wuerde mich interessieren 
wie die die TMC liste da reinbekommen automatisiert ...

Flo
-- 
Florian Lohoff f...@rfc822.org
Es ist ein grobes Missverständnis und eine Fehlwahrnehmung, dem Staat
im Internet Zensur- und Überwachungsabsichten zu unterstellen.
- - Bundesminister Dr. Wolfgang Schäuble -- 10. Juli in Berlin 


signature.asc
Description: Digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-15 Diskussionsfäden Tobias Wendorff
Florian Lohoff schrieb:
 SO weit ich weiss (man moege mich korrigieren) benutzt TMCPro einen
 anderen Country Identifier ...
 Löst OpenLR ein solches Problem?
 
 Welches Problem? Und was soll es loesen?

Problem: TMC hat keine global unique IDs.
Lösung: Ein System mit global unique IDs.

 Koennte man machen wenn OSM IDs stabil waeren - sind sie aber nicht.

Die Kreuzungen sind zu 99% stabil, nur die Lage nicht. Die Lage ist
aber für ein solches System total egal.

 Das die OpenStreetRouting leute ja TMC machen wuerde mich interessieren 
 wie die die TMC liste da reinbekommen automatisiert ...

TMC-Empfangen und auswerten ist ja nicht das große Problem, AFAIK
hat sich auch Jan-Benedict schon damit beschäftigt.

Da in den Tags irgendwie nichts auftaucht, denk ich mal, dass die
auch eine Art Zweittabelle haben oder die TMC-Informationen einfach
grober auflösen?

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-15 Diskussionsfäden Florian Lohoff
On Tue, Sep 15, 2009 at 05:05:45PM +0200, Tobias Wendorff wrote:
 Florian Lohoff schrieb:
 SO weit ich weiss (man moege mich korrigieren) benutzt TMCPro einen
 anderen Country Identifier ...
 Löst OpenLR ein solches Problem?

 Welches Problem? Und was soll es loesen?

 Problem: TMC hat keine global unique IDs.
 Lösung: Ein System mit global unique IDs.

Sie ist nur dann global unique wenn man country id und table id dazu nimmt.

Das eben beinhaltet auch der tagging vorschlag im Wiki ... Wer lesen kann
ist klar im vorteil...

 Das die OpenStreetRouting leute ja TMC machen wuerde mich interessieren 
 wie die die TMC liste da reinbekommen automatisiert ...

 TMC-Empfangen und auswerten ist ja nicht das große Problem, AFAIK
 hat sich auch Jan-Benedict schon damit beschäftigt.

 Da in den Tags irgendwie nichts auftaucht, denk ich mal, dass die
 auch eine Art Zweittabelle haben oder die TMC-Informationen einfach
 grober auflösen?

Nein - Es geht drum wie die die LCL auf die OSM Daten matchen - Das empfaengen
habe im ueberigen ich geschrieben nicht Jan Benedict - der hat an meinen
krams nur das decoden einzelner messages drangeklebt.

Ich habe das empfangen via DVB gemacht weil man dann ueber EINEN transponder
alle ARD Stationen bekommt und damit die TMC Messages fuer das ganze 
Bundesgebiet
und eben nicht nur das was man ueber den regionalen UKW Sender bekommt.

Der code ist soweit hier:

git clone git://hydra.gt.owl.de/rdsdump.git

Flo
-- 
Florian Lohoff f...@rfc822.org
Es ist ein grobes Missverständnis und eine Fehlwahrnehmung, dem Staat
im Internet Zensur- und Überwachungsabsichten zu unterstellen.
- - Bundesminister Dr. Wolfgang Schäuble -- 10. Juli in Berlin 


signature.asc
Description: Digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-15 Diskussionsfäden Tobias Wendorff
Florian Lohoff schrieb:
 Sie ist nur dann global unique wenn man country id und table id dazu nimmt.

Du hast nicht gelesen, was ich gefragt habe, oder?
Es ging mir darum, ob OpenLR weltweit einzigartige IDs hat, also
von der chinesischen Provinz Anhui bis zum Zypern.

 Nein - Es geht drum wie die die LCL auf die OSM Daten matchen - Das empfaengen
 habe im ueberigen ich geschrieben nicht Jan Benedict - der hat an meinen
 krams nur das decoden einzelner messages drangeklebt.

Ich habe bislang noch keine Nodes gefunden ... aber wir hatten ja
den NRW-Import vom BaSt. Vielleicht irgendwie überlagert?

 Ich habe das empfangen via DVB gemacht weil man dann ueber EINEN transponder
 alle ARD Stationen bekommt und damit die TMC Messages fuer das ganze 
 Bundesgebiet
 und eben nicht nur das was man ueber den regionalen UKW Sender bekommt.

Ist die Verbreitung eigentlich an den Rundfunkstaatsvertrag gekoppelt
oder wieso tun die es?

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-15 Diskussionsfäden André Riedel
Ich bin der Meinung, dass wir nicht die LCL in den OSM-Daten abbilden
müssen, sondern nur diese Teile, dass man eindeutig ein Punkt oder
Segment bestimmen kann. Andere in den LCL-Daten enhaltene
Informationen gibt es vielfach schon in OSM und müssen so nicht extra
an das Element gehängt werden.

Erster Vorschlag auf Basis meines bisherigen TMC-Verständnis:

So wie ich das jetzt gesehen, habe gehören zur Beschreibung eines
Objektes mit einem Location Code auf jeden Fall der Ländercode (CID)
und Tabellennummer (TABCD) dazu. Da man bisher davon ausgeht, dass
folgende LCL-Versionen (Location Code List) zu älteren
Navigationsgeräten kompatibel sein sollten, kann man die Version
vielleicht vernachlässigen. Sie sollte aber auf jeden Fall bei der
Eingabe im Changeset erscheinen.

Bisher gibt es folgende Version zur Abbildung der Raststätte
Auerswalder Blick:
TMC:cid_81:tabcd_1:LocationCode = 11181

Für ein Programm ist es wahrscheinlich egal, ob die eindeutig
Bestimmung durch den OSM-Key, den OSM-Value oder durch beide möglich
wird, aber ein OSM-Oldi geht wahrscheinlich davon aus das links die
Eigenschaft steht und rechts der Wert. Also warum nicht in folgendes
ändern. Es wird dadurch nicht lesbarer, aber für leichter zuordbar da
es ein Telefonnummer ähnelt.
TMC:LocationCode=81:1:11181 (nach dem Schema CID:TABCD:LCD)

Das ganze kann man eventl. auch noch mit dem LCL-Datum oder der
LCL-Version verbinden. Um zu meinem ersten Vorschlag zurückzukommen
kann es auch wie folgt benannt werden.
navi:tmc=81:1:11181

Da man eine Autobahn mit nur einer Linie und die beidseitige
Raststätte mit nur einem Punkt auf der Linie abbildet, diese in den
OSM-Daten aber aus einer Linie pro Fahrtrichtung und zwei Nodes
besteht, bieten sich für fast alle Varianten Relationen an. Nur
einmalig vorhandene OSM-Elemente, wie Parkplätze, Seen,
Gemeindegrenzen usw., können jedoch dirket mit den TMC-Daten ergänzt
werden.

Für mich stellt sich jetzt die Frage, wie mit den Linien-Abschnitten
(Segments) verfahren werden soll. Im Moment bevorzuge ich die
Variante, dass man pro Segment (von einem Location Code-Punkt zum
nächsten) eine Relation erstellt und alle eingeschlossenen Wege als
Kind hinzufügt. Aber wie benennen, denn oft haben diese Segmente keine
eigene ID und werden nur durch den Vorgänger und Nachfolger bestimmt.
Sollten diese Information mit in den Key/Value-Bereich
(navi:tmc:segment=81:1:11181-81:1:11184) oder via Kind mit einer Rolle
(from und to bei einem Way pro Richtung und between für in zwei
Richtungen befahrene Ways + key/value navi:tmc=segment) hinzugefügt
werden.

Soweit mein Draft-Alpha-Vorschlag. Besonders für den letzten Abschnitt
muss ich mir noch einmal Zeit nehmen, den Vorschlag zu abzuwägen und
das Optimum zu finden.
Ciao André

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-15 Diskussionsfäden André Riedel
 a) LCL Codes von der Bafin holen

 Hab ich hier liegen und kann ich geben.
 Kann man nur nicht einfach so auf eine Webseite stellen.
 (Aber die Codes an Objekte in OSM anhängen ist erlaubt.)

Kann man das LCL2OSM-Ergebnis veröffentlichen?

 Ich kann zur Prüfung etwas schreiben, was z.b. eine lokale .osm -Datei
 nimmt und die korrekt getaggten TMC-Segmente rendert sowie auf einfach
 zu findende Fehler schaut. (Löcher in Wegen, Nächter/Letzter
 Reihenfolgen,
 fehlende Sachen, Schreibfehler)

Online-Prüftool ist für den gemeinen OSM-Benutzer einfacher. Löcher in
Wegen lassen sich bei Nutzung von Relations auch mit vorhandenen
Relation-Tests prüfen.

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-15 Diskussionsfäden Bernd Wurst
Hallo.

Am Dienstag, 15. September 2009 schrieb André Riedel:
 TMC:cid_81:tabcd_1:LocationCode = 11181

 Für ein Programm ist es wahrscheinlich egal, ob die eindeutig
 Bestimmung durch den OSM-Key, den OSM-Value oder durch beide möglich
 wird, aber ein OSM-Oldi geht wahrscheinlich davon aus das links die
 Eigenschaft steht und rechts der Wert. Also warum nicht in folgendes
 ändern. Es wird dadurch nicht lesbarer, aber für leichter zuordbar da
 es ein Telefonnummer ähnelt.
 TMC:LocationCode=81:1:11181 (nach dem Schema CID:TABCD:LCD)

 Das ganze kann man eventl. auch noch mit dem LCL-Datum oder der
 LCL-Version verbinden. Um zu meinem ersten Vorschlag zurückzukommen
 kann es auch wie folgt benannt werden.
 navi:tmc=81:1:11181

Autsch, Problem:
Wenn wir nicht nur nach Land sondern auch nach Code-Liste unterscheiden 
müssen, muss es möglich sein, ein Objekt / einen Abschnitt in mehreren 
Tabellen abzubilden.

Da jeder Key nur einmal vorkommen darf, muss die Unterscheidung der 
verschiedenen Code-Listen im Key passieren.

Alternativvorschlag:
Wir taggen alle benötigten Objekte (Punkte, Abschnitte) in OSM irgendwie 
eindeutig und erzeugen eine Konversions-Tabelle z.B. von TMC nach 
OSM-Identifier (nicht Way-/Node-ID) und eine von TMCpro nach OSM-Irgendwas.

Wäre nur die Frage ob es ein nicht-numerisches System geben kann, was die 
Daten korrekt abbildet. Numerische Systeme ohne Bezugssystem sind immer so 
demotivierend für den Mapper, weil man so abstrakt arbeiten muss. ;-)

Gruß, Bernd

-- 
for i in /bin/*; do man $(basename $i); done


signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-15 Diskussionsfäden Tobias Wendorff
Hallo,

Bernd Wurst schrieb:
 Alternativvorschlag:
 Wir taggen alle benötigten Objekte (Punkte, Abschnitte) in OSM irgendwie 
 eindeutig und erzeugen eine Konversions-Tabelle z.B. von TMC nach 
 OSM-Identifier (nicht Way-/Node-ID) und eine von TMCpro nach OSM-Irgendwas.

Ähnliche Idee hatte ich mit festen Way-/Nodes:
http://www.mail-archive.com/talk-de@openstreetmap.org/msg53764.html

Natürlich kann man auch irgendein anderen Tag nehmen, der vielleicht
besser drankleben bleibt:

tmc:OSM = id

 Wäre nur die Frage ob es ein nicht-numerisches System geben kann, was die 
 Daten korrekt abbildet. Numerische Systeme ohne Bezugssystem sind immer so 
 demotivierend für den Mapper, weil man so abstrakt arbeiten muss. ;-)

Was meinst Du mit nicht-numerisch?

Was kreuzt mit was?
tmc:OSM = Kassel;Ketteler Straße;Badstraße
Aber dann werden die Tags unendlich lang :-/

Grüße
Tobias

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-15 Diskussionsfäden Bernd Wurst
Hallo.

Am Dienstag, 15. September 2009 schrieb Tobias Wendorff:
 Ähnliche Idee hatte ich mit festen Way-/Nodes:
 http://www.mail-archive.com/talk-de@openstreetmap.org/msg53764.html
 Natürlich kann man auch irgendein anderen Tag nehmen, der vielleicht
 besser drankleben bleibt:
 tmc:OSM = id

Der Punkt mit den Way-IDs ist, dass man Ways immer mal wieder aufspalten muss 
(für Geschwindigkeitsbeschränkungen oder ähnliches). Dann deckt die ID etwas 
anderes ab als zuvor.

Ein Tag kann der Benutzer sehen (er wird also kurz nachdenken ob das an beide 
neuen Wege dran muss oder nicht) und der Editor kann es auch intelligent 
handhaben. Bei den IDs der Objekte geht das nicht.



  Wäre nur die Frage ob es ein nicht-numerisches System geben kann, was die
  Daten korrekt abbildet. Numerische Systeme ohne Bezugssystem sind immer
  so demotivierend für den Mapper, weil man so abstrakt arbeiten muss. ;-)
 Was meinst Du mit nicht-numerisch?

 Was kreuzt mit was?
 tmc:OSM = Kassel;Ketteler Straße;Badstraße
 Aber dann werden die Tags unendlich lang :-/

Das ist genau das Problem. :(

Als einfacher Mapper ist es halt einigermaßen unschön, wenn ich dann ein Tag a 
la tmc=1675123 habe und ich kann nicht *ganz einfach* herausfinden, was 
diese Zahl zu sagen hat. 
Zudem müsste jemand diese IDs global vergeben, das ist auch etwas unschön.

Dann vielleicht doch lieber
  tmc:81:1=123123

Gruß, Bernd

-- 
Joey: Also gut Ross hör zu. Du fühlst dich momentan hundeelend, du
bist sehr wütend, und gekränkt. Soll ich dir mal 'nen guten Rat
geben?
Ross: Ah.
Joey: Geh in ein Striplokal.
  -  Friends (am. Sitcom)


signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-15 Diskussionsfäden Tobias Wendorff
Hallo Bernd,

Bernd Wurst schrieb:
 Der Punkt mit den Way-IDs ist, dass man Ways immer mal wieder aufspalten muss 
 (für Geschwindigkeitsbeschränkungen oder ähnliches). Dann deckt die ID etwas 
 anderes ab als zuvor.

Das mit den Way-IDs sehen ich ein. War ja nur eine schnelle Idee.

 Zudem müsste jemand diese IDs global vergeben, das ist auch etwas unschön.

Nunja, die Globalität könnte man anhand der Relationen und einer
räumlichen Abfrage lösen.

Wenn die ID xy in Deutschland ist, dann gilt auch das deutsche TMC
System.

Grüße
Tobias

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-15 Diskussionsfäden Bernd Wurst
Hallo.

Am Dienstag, 15. September 2009 schrieb Tobias Wendorff:
 Wenn die ID xy in Deutschland ist, dann gilt auch das deutsche TMC
 System.

Ist das wirklich so?

Ich hätte jetzt vermutet, dass Straßen in Grenznähe in mehreren 
TMC-Location-Code-Listen erscheinen um auch Staus z.B. auf parallel 
verlaufenden Ausweichstrecken unkompliziert abbilden zu können. 

In Baden ist es so, dass in Frankreich eine Autobahn parallel zur deutschen A5 
läuft. Wenn die deutsche Autobahn zu ist, wird im Verkehrsfunk die 
französische Autobahn als Ausweichstrecke vorgeschlagen. Wenn jetzt die auch 
mal Stau hat, sollte man das im selben Atemzug mit senden können. Daher würde 
ich (unbelegt!) vermuten, dass wir hier nicht an den Ländergrenzen hart 
abschneiden können.

Alternative:
TMC:DE=12123

:)

Gruß, Bernd

-- 
Gebildet ist, wer weiß wo er findet, was er nicht weiß


signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-15 Diskussionsfäden Tobias Wendorff
Hallo,

Bernd Wurst schrieb:
 Ist das wirklich so?

Weiß ich nicht, können die Beteiligten sicher besser beantworten.

Wenn ein Konzept stehen würde, würde ich gerne beim Eintragen
helfen.

Grüße
Tobias

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-15 Diskussionsfäden Florian Lohoff
On Tue, Sep 15, 2009 at 05:54:42PM +0200, Tobias Wendorff wrote:
 Florian Lohoff schrieb:
 Sie ist nur dann global unique wenn man country id und table id dazu nimmt.

 Du hast nicht gelesen, was ich gefragt habe, oder?
 Es ging mir darum, ob OpenLR weltweit einzigartige IDs hat, also
 von der chinesischen Provinz Anhui bis zum Zypern.

OpenLR ist mir so lange egal wie es nicht irgendeinen anwendungsfall dafuer
gibt. Neue Protokolle oder XML Schema kann ich jeden tag schreiben - aber
interessiert das irgendwen?

Ist ja schon das wir einen neuen Standard haben - Nur leider
keinen Content ...

 Nein - Es geht drum wie die die LCL auf die OSM Daten matchen - Das 
 empfaengen
 habe im ueberigen ich geschrieben nicht Jan Benedict - der hat an meinen
 krams nur das decoden einzelner messages drangeklebt.

 Ich habe bislang noch keine Nodes gefunden ... aber wir hatten ja
 den NRW-Import vom BaSt. Vielleicht irgendwie überlagert?

Du redest ziemlich an allem vorbei was ich oben schrieb. Es gab
keinen BaSt Import sondern nur den Plan und dieser muss erst auch
nochmal diskutiert werden - und im moment ging es drum das eben manuell
zu machen und nicht automatisiert ...

Flo
-- 
Florian Lohoff f...@rfc822.org
Es ist ein grobes Missverständnis und eine Fehlwahrnehmung, dem Staat
im Internet Zensur- und Überwachungsabsichten zu unterstellen.
- - Bundesminister Dr. Wolfgang Schäuble -- 10. Juli in Berlin 


signature.asc
Description: Digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-15 Diskussionsfäden André Riedel
Am 15. September 2009 18:20 schrieb Bernd Wurst be...@bwurst.org:
 Autsch, Problem:
 Wenn wir nicht nur nach Land sondern auch nach Code-Liste unterscheiden
 müssen, muss es möglich sein, ein Objekt / einen Abschnitt in mehreren
 Tabellen abzubilden.

 Da jeder Key nur einmal vorkommen darf, muss die Unterscheidung der
 verschiedenen Code-Listen im Key passieren.

Wenn wir das ganze in Relations abbilden, lässt sich das Problem
umgehen. Da die Segmente pro System unterschiedlich ausfallen, werden
die Relations auch unterschiedlich ausfallen.

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-15 Diskussionsfäden Mirko Küster
 Wenn wir das ganze in Relations abbilden, lässt sich das Problem
 umgehen. Da die Segmente pro System unterschiedlich ausfallen, werden
 die Relations auch unterschiedlich ausfallen.

Und wer meldet sich freiwillig das ganze auch zukünftig im Auge zu behalten 
und ständig zu fixen? Wenn ich sehe was hier tagtäglich so alles schief 
gehen kann, spare ich mir das einpflegen bei einer Lösung per Ralation 
lieber. Sowas komplexes wie diese Codes zu pflegen wird da zum Alptraum. Und 
TMC ginge ja noch, deckt es nur die wichtigsten Straßen ab. Dieses LR soll 
ja noch tiefer gehen.

Da werden Relationen verpfuscht, durcheinender geschmissen, verkehrt 
zugeordnet, Member vergessen und manche verschwindet auch ohne das einer 
etwas gemacht hat komplett. Daran ist oft nichtmal aktiv ein Unwissender 
Mapper Schuld. Da reicht schon einfaches editieren mit Potlatch. Dieser 
Editor warnt bei einigen fatalen Aktionen bis heute nicht bei Auswirkungen 
auf die Relationen und sortieren kann er gleich garnicht.

Das Konstrukt Relation ist derzeit für sowas komplexes einfach viel zu 
anfällig. Das ginge genauso in die Hose, wie Codes an eine ID binden die 
morgen schon ins Nirvana editiert sein kann.

Gruß
Mirko 


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-15 Diskussionsfäden Marcus Wolschon
On 2009-09-15, André Riedel riedel.an...@gmail.com wrote:
 Ich bin der Meinung, dass wir nicht die LCL in den OSM-Daten abbilden
 müssen, sondern nur diese Teile, dass man eindeutig ein Punkt oder
 Segment bestimmen kann. Andere in den LCL-Daten enhaltene
 Informationen gibt es vielfach schon in OSM und müssen so nicht extra
 an das Element gehängt werden.

Welche Informationen meinst du?
Außer den OSM-Objekten welche einem Ort entsprechen
braucht man die verkettete Liste der LCL-Elemenet um eine Nachricht
auswerten zu können (Nachricht sagt: Von LocationCode 3 bis
2 Schritte nach vorne.)

 Erster Vorschlag auf Basis meines bisherigen TMC-Verständnis:

 So wie ich das jetzt gesehen, habe gehören zur Beschreibung eines
 Objektes mit einem Location Code auf jeden Fall der Ländercode (CID)
 und Tabellennummer (TABCD) dazu. Da man bisher davon ausgeht, dass
 folgende LCL-Versionen (Location Code List) zu älteren
 Navigationsgeräten kompatibel sein sollten, kann man die Version
 vielleicht vernachlässigen. Sie sollte aber auf jeden Fall bei der
 Eingabe im Changeset erscheinen.

 Bisher gibt es folgende Version zur Abbildung der Raststätte
 Auerswalder Blick:
 TMC:cid_81:tabcd_1:LocationCode = 11181

 Für ein Programm ist es wahrscheinlich egal, ob die eindeutig
 Bestimmung durch den OSM-Key, den OSM-Value oder durch beide möglich

nicht wirklich. Mit dem jetzigen Schhema kann man gegeben
die empfangenen CID und Tabcd -Paare in einem simplen Index
nach dem key suchen und erhält genau die OSM-Elemente welche
man braucht.

 wird, aber ein OSM-Oldi geht wahrscheinlich davon aus das links die
 Eigenschaft steht und rechts der Wert.

Tut sie. Der LocationCode dieses Objektes nach 81:1 lautet 11181.

 Also warum nicht in folgendes
 ändern. Es wird dadurch nicht lesbarer, aber für leichter zuordbar da
 es ein Telefonnummer ähnelt.
 TMC:LocationCode=81:1:11181 (nach dem Schema CID:TABCD:LCD)

Das funktioniert nicht, da ein Objekt in mehreren Ländern in deren
jeweiliger LCL steht.

 Da man eine Autobahn mit nur einer Linie und die beidseitige
 Raststätte mit nur einem Punkt auf der Linie abbildet, diese in den
 OSM-Daten aber aus einer Linie pro Fahrtrichtung und zwei Nodes
 besteht, bieten sich für fast alle Varianten Relationen an. Nur
 einmalig vorhandene OSM-Elemente, wie Parkplätze, Seen,
 Gemeindegrenzen usw., können jedoch dirket mit den TMC-Daten ergänzt
 werden.

Vorsicht: Das sind je nach Richtung (Richtung in der verketteten Liste
der LCL-Elemente) 2 verschiedene Strassen/Rastplätze.
Es wird immer gesendet ob die Richtung vorwärts oder rückwärts
gemeint ist.

 Für mich stellt sich jetzt die Frage, wie mit den Linien-Abschnitten
 (Segments) verfahren werden soll. Im Moment bevorzuge ich die
 Variante, dass man pro Segment (von einem Location Code-Punkt zum
 nächsten) eine Relation erstellt und alle eingeschlossenen Wege als
 Kind hinzufügt.

Das wird sehr, sehr viel manuelles Relationen-Anlegen.
Grundsätzlich gerne aber es macht es nicht leichter.

 Aber wie benennen, denn oft haben diese Segmente keine
 eigene ID und werden nur durch den Vorgänger und Nachfolger bestimmt.

ist ein Problem.


Marcus

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-15 Diskussionsfäden Marcus Wolschon
On 2009-09-15, Tobias Wendorff tobias.wendo...@uni-dortmund.de wrote:
 Zudem müsste jemand diese IDs global vergeben, das ist auch etwas unschön.

 Nunja, die Globalität könnte man anhand der Relationen und einer
 räumlichen Abfrage lösen.

Vorsicht.
Räumliche Abfragen sind sehr, sehr teure Operationen
und Navis die auch mal auf Handys laufen haben nur
extrem begrenzte Ressourcen.
Suchen nach einem exakten Key ist nach dem Suchen nach
einer Objekt-Id schon das teuerste was wir benötigen sollten.

Ich bin für das Taggen an den Objekten selbst für Points
und Segments soweit sinnvoll. Lasse mich da aber gerne
umstimmen.

 Wenn die ID xy in Deutschland ist, dann gilt auch das deutsche TMC
 System.

Nein. Auch die anliegenen Staaten haben deutsche Strassen und Orte
in ihren Codes. Für weiter entfernte gibt es dann erweiterte Nachrichten
mit denen man Orte aus anderen LCLs angeben kann.
Schau mal im verlinkten ISO-Dokument auf der TMC-Seite im TS-Wiki
nach European Inter Road oder sowas.

Marcus

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-15 Diskussionsfäden Marcus Wolschon
On 2009-09-15, André Riedel riedel.an...@gmail.com wrote:
 a) LCL Codes von der Bafin holen

 Hab ich hier liegen und kann ich geben.
 Kann man nur nicht einfach so auf eine Webseite stellen.
 (Aber die Codes an Objekte in OSM anhängen ist erlaubt.)

 Kann man das LCL2OSM-Ergebnis veröffentlichen?

Sicher doch.
Das wäre gar keine so schlechte Idee
die zum Abarbeiten auf die Seite zu stellen.

Marcus

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-15 Diskussionsfäden Marcus Wolschon
On 2009-09-15, Florian Lohoff f...@rfc822.org wrote:

 Das die OpenStreetRouting leute ja TMC machen wuerde mich interessieren
 wie die die TMC liste da reinbekommen automatisiert ...


Mit einer sehr groben und fehleranfälligen Heuristik über Lat+Lon.
Hab ich schon erfragt.

Marcus

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-14 Diskussionsfäden André Riedel
Am 14. September 2009 07:35 schrieb Marcus Wolschon mar...@wolschon.biz:
 Wird eh nix.
Killerphrase.

 Was meinst du wie oft ich nach Unterstützung bei den TMC-LocationCodes
 gefragt habe?
 Läuft in OSM-Navis, wir haben die Codes, dürfen sie importieren,
 Vorbereitungen sind gemacht
 aber keiner will helfen das wirklich zu machen.

Vielleicht hilft keiner, weil er das Thema nicht genau verstanden hat
und weiß was er machen kann.
Was kann getan werden? Wäre es möglich einen WMS-Layer von den TMC-
oder OpenLR-Linien zu erstellen, um so die nötigen Informationen an
die Straßen in OSM anzufügen. (navi:tmc = 12345, navi:openlr =
f2332f4) Dann könnte man das ganze in DE:Aktionen einbinden und es
wäre innerhalb von einer Woche komplett.

Das anhängen an die OSM-Daten hätte den Nachteil, dass es jederzeit
durch Fehler gefälscht werden könnte, jedoch wäre es auch möglich
einen wöchentlichen Check laufen zu lassen, ob die gewünschten
Teilstücke wirklich in dem von den TMC- oder OpenLR-Listen gegebenen
Gebiet zu finden sind.

So nun noch einmal die Frage: Welche Hilfe wird benötigt und was kann
der OSM-Michel dazu beitragen?

Ciao André

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-14 Diskussionsfäden Mirko Küster
 Wird eh nix.
 Was meinst du wie oft ich nach Unterstützung bei den TMC-LocationCodes
 gefragt habe?
 Läuft in OSM-Navis, wir haben die Codes, dürfen sie importieren,
 Vorbereitungen sind gemacht
 aber keiner will helfen das wirklich zu machen.

Diese Codes sind doch sicherlich auf genaue Abschnitte zu geschnitten? In 
dem Fall würde mich es nicht wundern das man vor einem automatischen Import 
ein bisschen Angst hat. Wir haben hier nun nicht gerade einen vergleichbaren 
Standard wo das immer genau passt. Unserer Straßen sind etweder zerstückelt 
und nicht immer deckungsgleich und lagegenau oder in dünnen Gebieten lang 
durchgehend. Da kann auch das beste Tool nur verlieren.

Stell die Codes doch einfach mal online. Dann kann das jeder in seiner Ecke 
kontrolliert nachtragen.

Gruß
Mirko 


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-14 Diskussionsfäden Tobias Wendorff
Marcus Wolschon schrieb:
 Läuft in OSM-Navis, wir haben die Codes, dürfen sie importieren,
 Vorbereitungen sind gemacht
 aber keiner will helfen das wirklich zu machen.

Was genau ist zu tun? Die Aktionen, die hier oft gestartet
werden, sind sehr erfolgreich.

Schonmal über das Forum  Co. probiert?

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-14 Diskussionsfäden André Riedel
Mehr zum Thema TMC in OSM:

Link zur vorherigen Diskussion:
http://article.gmane.org/gmane.comp.gis.openstreetmap.region.de/40580

Wiki: (en)
http://wiki.openstreetmap.org/wiki/TMC/TMC_Import_Germany

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-14 Diskussionsfäden Marcus Wolschon
On 2009-09-14, Mirko Küster webmas...@ts-eastrail.de wrote:
 Wird eh nix.
 Was meinst du wie oft ich nach Unterstützung bei den TMC-LocationCodes
 gefragt habe?
 Läuft in OSM-Navis, wir haben die Codes, dürfen sie importieren,
 Vorbereitungen sind gemacht
 aber keiner will helfen das wirklich zu machen.

 Diese Codes sind doch sicherlich auf genaue Abschnitte zu geschnitten? In
 dem Fall würde mich es nicht wundern das man vor einem automatischen Import
 ein bisschen Angst hat. Wir haben hier nun nicht gerade einen vergleichbaren
 Standard wo das immer genau passt. Unserer Straßen sind etweder zerstückelt
 und nicht immer deckungsgleich und lagegenau oder in dünnen Gebieten lang
 durchgehend. Da kann auch das beste Tool nur verlieren.

Ich sagte schon daß die Vorbereitungen schon gemacht sind.
Tagging-Schema und da Ausarbeiten wie die Abbildung auf OSM
geht sind schon seid Monaten gemacht.
Werkzeuge existieren auch schon.
Sogar ein Navi was die nach dem Tagging-Schema auswertet existiert.

Was fehlt sind Leute die Wissen wie man die manuelle Arbeit sinnvoll
auf Leute verteilen, verifizieren und als erledigt markieren kann.
Mails an diese Liste, die internationale Talk-Liste und die
imports-Lists haben nichts gebracht. Wiki-Seite (wurde hier schon genannt)
existiert auch seid ewig.

 Stell die Codes doch einfach mal online. Dann kann das jeder in seiner Ecke
 kontrolliert nachtragen.

Schau mal im Wiki.
Die Codes kannst du dir bei der Bafin maschinenlesbar abholen.
Die Rohform online stellen ist nicht zulässig.
Der Code um deren Format in was für uns brauchbares zu
transformieren existiert schon seid ewig.

Marcus

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Taskforce: Integration von OpenLR

2009-09-13 Diskussionsfäden Marcus Wolschon
Wird eh nix.
Was meinst du wie oft ich nach Unterstützung bei den TMC-LocationCodes
gefragt habe?
Läuft in OSM-Navis, wir haben die Codes, dürfen sie importieren,
Vorbereitungen sind gemacht
aber keiner will helfen das wirklich zu machen.

On 2009-09-10, Tobias Wendorff tobias.wendo...@uni-dortmund.de wrote:
 Hallo Community,

 nun, nach diesem Ausspruch von TomTom [1] müssen wir ja aktiv werden.

 Schaden kann's nicht, wenn Dritte irgendwann einmal Verkehrsinfos auf
 unseren Daten abbilden können. HD Traffic ist bereits kompatibel zu
 OpenLR ... kostet 10 EUR im Monat. Für Vielfahrer ist es sicherlich
 interessant.

 Besteht Interesse, dieses Konzept in OpenStreetMap zu integrieren?
 Falls ja, könnten wir ja eine Art Taskforce bilden, um die Integration
 voranzutreiben: Vorgehensweise erarbeiten, Tutorials schreiben etc.

 Es müssen ja auch die Anwendungen mitspielen: die Router müssen die
 neuen Informationen verarbeiten können. Ich denke, das ist vielleicht
 gar nicht zu falsch, da mitzuspielen. Wenn dann Nokia/NAVTEQ in zwei
 Wochen auch einen eigenen Standard rausbringt, bewegt sich der
 Markt wenigstens mal wieder ;-)

 Viele Grüße
 Tobias

 [1] Mit OpenLR verfolgen wir das Ziel, der Open Source-Community zu
 helfen, den Nutzern standortbezogene Services anbieten zu können,
 so Mark Gretton, Director of Product Engineering bei TomTom.
 Quelle: winfuture.de

 ___
 Talk-de mailing list
 Talk-de@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-de


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de