Einbinden von RC in eigenes Programm

[willie68]

Hallo,

ich versuche gerade RC in mein eigenes Programm (http://wkla.dyndns.org/mcslog/) für meinen Hardwarelogger (http://wkla.dyndns.org/ArduinoWiki/doku....uino:oseam) einzubinden.
Bei den Vorüberlegungen sind ein paar aufgetaucht, die ich gerne hier stellen möchte.

Vorab: Die Konvertierung der Loggerdaten ist fertig. Nun können die Datendateien doch recht umfangreich sein. Es können tatsächlich Routen von bis zu 21 Tagen dauer auftreten. Das sind dann mehrer GB an Daten. (ca. 100MB pro Stunde)

1. Ist es sinnvoll die Daten zuerst zu filtern, damit man nicht pro Sekunde einen Punkt hat? Ich denke da so an 10 Sekunden oder evt. auch im Minutenbereich. (Das ganze könnte ich in meiner Konfiguration einstellbar machen.)
2. Wie sollte eine sinnvolle Einbindung aussehen? Ich habe Testweise mir mal die HTML Geschichte angeschaut. Das wäre zwar der einfachste Weg, aber dort liegen die Daten quasi in der HTML Seite. Gibt es da eine Größenbeschränkung?
3. Kann ich außer Google noch andere Services verwenden? OpenStreetMap? Wenn ja, wie? Für mich natürlich extrem interessant wäre OpenSeaMap. Damit ich dort auch die Tiefendaten angezeigt bekomme.

---

4. Ich habe eine Einbindung mittels

Code:

String[] args = { nmeaFile.getCanonicalPath(), "WebPageFormat", htmlFile.getCanonicalPath() };      
slash.navigation.converter.cmdline.RouteConverterCmdLine.main(args);

Leider scheint sich der RouteConverterCmdLine mittels System.exit zu verabschieden. Gibt's 'ne andere Möglichkeit? (Außer externen Prozess)

PS.: Punkt 4 hat sich erledigt. Hab mir einfach die Quellen angeschaut und die convert übernommen.

[routeconverter]

1. Ist es sinnvoll die Daten zuerst zu filtern, damit man nicht pro Sekunde einen Punkt hat? Ich denke da so an 10 Sekunden oder evt. auch im Minutenbereich. (Das ganze könnte ich in meiner Konfiguration einstellbar machen.)

Ja, für die Darstellung mache ich eine solche Filterung per Douglas-Peucker-Algorithmus, um den Internet Explorer nicht zum Abstürzen zu bringen. Ich habe eine ganze Menge an RouteConverter optimiert, so daß es seit Version 2.10 mit 750000 Positionen klarkommt. Bei Deinem Datenvolumen dürftest Du deutlich oberhalb liegen und es könnte passieren, daß der Speicher nicht reicht und daß die UI nicht zügig genug reagiert.

2. Wie sollte eine sinnvolle Einbindung aussehen? Ich habe Testweise mir mal die HTML Geschichte angeschaut. Das wäre zwar der einfachste Weg, aber dort liegen die Daten quasi in der HTML Seite. Gibt es da eine Größenbeschränkung?

Wenn Du damit meinst, das NMEA-Log ins Webpage (*.html) Format zu wandeln, so hat die RouteConverter-Kommandozeilenversion keine Beschränkungen. Sehr wohl jedoch die Google Maps API und der Browser, der das anzeigt.

3. Kann ich außer Google noch andere Services verwenden? OpenStreetMap?

Ja

Wenn ja, wie? Für mich natürlich extrem interessant wäre OpenSeaMap. Damit ich dort auch die Tiefendaten angezeigt bekomme.

Das ist analog zu den Beispielen, die bereits in die .html Datei geschrieben werden.

4. Ich habe eine Einbindung mittels

Code:

String[] args = { nmeaFile.getCanonicalPath(), "WebPageFormat", htmlFile.getCanonicalPath() };      
slash.navigation.converter.cmdline.RouteConverterCmdLine.main(args);

Leider scheint sich der RouteConverterCmdLine mittels System.exit zu verabschieden. Gibt's 'ne andere Möglichkeit? (Außer externen Prozess)

Du könntest Dir RouteConverterCmdLine#convert() anschauen und das in Dein Programm einbauen.

PS.: Punkt 4 hat sich erledigt. Hab mir einfach die Quellen angeschaut und die convert übernommen.

Ok, ich hätte erst alles durchlesen sollen ;-)

[willie68]

Ja, für die Darstellung mache ich eine solche Filterung per Douglas-Peucker-Algorithmus, um den Internet Explorer nicht zum Abstürzen zu bringen. Ich habe eine ganze Menge an RouteConverter optimiert, so daß es seit Version 2.10 mit 750000 Positionen klarkommt. Bei Deinem Datenvolumen dürftest Du deutlich oberhalb liegen und es könnte passieren, daß der Speicher nicht reicht und daß die UI nicht zügig genug reagiert.

OK, dann werd ich mal schauen, wie ich die Datenmengen sinnvollreduzieren kann.

Wenn Du damit meinst, das NMEA-Log ins Webpage (*.html) Format zu wandeln, so hat die RouteConverter-Kommandozeilenversion keine Beschränkungen. Sehr wohl jedoch die Google Maps API und der Browser, der das anzeigt.

Kennst du da die Größen?

Das ist analog zu den Beispielen, die bereits in die .html Datei geschrieben werden.

OK, und wie krieg ich die da rein? Gibt's irgendwo ein Template zur Generierung der html Datei? Kann ich das per Kommandozeile mit angeben oder muss ich die jar patchen?

[routeconverter]

Bei Deinem Datenvolumen dürftest Du deutlich oberhalb liegen und es könnte passieren, daß der Speicher nicht reicht und daß die UI nicht zügig genug reagiert.

OK, dann werd ich mal schauen, wie ich die Datenmengen sinnvollreduzieren kann.

Ich habe 3 Algorithmen bereits implementiert. Schau Dir mal Positionsliste/Entferne doppelte Positionen an.

Wenn Du damit meinst, das NMEA-Log ins Webpage (*.html) Format zu wandeln, so hat die RouteConverter-Kommandozeilenversion keine Beschränkungen. Sehr wohl jedoch die Google Maps API und der Browser, der das anzeigt.

Kennst du da die Größen?

Der Internet Explorer stürzt gerne jenseits von 1000 Polylines ab, das sind etwa 2000 Positionen. Die Google Maps API zickte bei mir unter WebKit jenseits von 5000 Polylines.

Polylines werden für Tracks verwandt. Die Wegpunktlisten und Routen habe die Limits deutlich früher bei 750 Markern für Wegpunkte und 300 Routingabschnitten.

Ohne Tricks und Hirnschmalz kannst Du Dein 10 Millionen Datenpunkte nicht auf eine HTML-Seite bringen.

OK, und wie krieg ich die da rein? Gibt's irgendwo ein Template zur Generierung der html Datei?

Ja, es heißt webpage.html

Kann ich das per Kommandozeile mit angeben oder muss ich die jar patchen?

Clone das Repository und patche es in den Code. Für die OSM Cyclemap sieht das bspw. so aus:

map.mapTypes.set(CYCLE_MAPTYPE_ID, new google.maps.ImageMapType({
getTileUrl: function(coordinates, zoom) {
return "http://" + getOpenStreetMapServerIndex() + ".tile.opencyclemap.org/cycle/" + zoom + "/" + coordinates.x + "/" + coordinates.y + ".png";
},
tileSize: DEFAULT_TILE_SIZE,
maxZoom: 18,
alt: "OpenCycleMap rendering of OpenStreetMap data",
name: CYCLE_MAPTYPE_ID
}));

Analog geht es wahrscheinlich für die OpenSeaMap

[willie68]

Ich habe 3 Algorithmen bereits implementiert. Schau Dir mal Positionsliste/Entferne doppelte Positionen an.

Werd ich machen.

Der Internet Explorer stürzt gerne jenseits von 1000 Polylines ab, das sind etwa 2000 Positionen. Die Google Maps API zickte bei mir unter WebKit jenseits von 5000 Polylines.

Polylines werden für Tracks verwandt. Die Wegpunktlisten und Routen habe die Limits deutlich früher bei 750 Markern für Wegpunkte und 300 Routingabschnitten.

Na das ist ja nicht gerade viel...

Ohne Tricks und Hirnschmalz kannst Du Dein 10 Millionen Datenpunkte nicht auf eine HTML-Seite bringen.

Hab ich mir schon fast gedacht...

Clone das Repository und patche es in den Code. Für die OSM Cyclemap sieht das bspw. so aus:

map.mapTypes.set(CYCLE_MAPTYPE_ID, new google.maps.ImageMapType({
getTileUrl: function(coordinates, zoom) {
return "http://" + getOpenStreetMapServerIndex() + ".tile.opencyclemap.org/cycle/" + zoom + "/" + coordinates.x + "/" + coordinates.y + ".png";
},
tileSize: DEFAULT_TILE_SIZE,
maxZoom: 18,
alt: "OpenCycleMap rendering of OpenStreetMap data",
name: CYCLE_MAPTYPE_ID
}));

Analog geht es wahrscheinlich für die OpenSeaMap

So, geclont, dann schau ich mal, ob ich das ganze auch gebuildet kriege...

[EddiVonDerAlm]

Wie Christian schon geschrieben hat, werden die Tracks im Routeconverter in einzelne Polylines verpackt.

Wenn Du vorhast die Daten auf eine Webseite zu bringen kannst Du es evtl. auch mit einer encoded Polyline abbilden. Das Maximum an Punkten habe ich nicht gefunden, aber hier http://facstaff.unca.edu/mcmcclur/Google...mples.html gibt es ein Beispiel mit knapp 400.000 Punkten.

Aber damit das Flüssig läuft wirst Du dich auch mit Douglas-Peuker o.ä. beschäftigen müssen.

[willie68]

Vielleicht sollte ich erst mal beschreiben, welche Voraussetzungen es gibt und was ich vorhabe.
Der Logger logt GPS und Echolot-Daten. Zus. werden auch noch Beschleunigungs und Neigungsdaten protokolliert. Im schlimmsten Fall über 3-4 Wochen. Dabei werden die Daten schon vom Logger in Häppchen von einer Dauer von ca. 1 Stunde geschnibbelt. (Ca. 100MB) Die Daten stammen sowohl von Privatleuten, die am Croudsourcing Projekt der OpenSeaMap teilnehmen, wie auch von dort beteiligten Vercharterern.
Ich möchte neben dem reinen Upload der Daten auf den OSeaM Server zur Berechnung der Wassertiefen etwas Mehrwert für die Users des Logger bieten.
Einerseits natürlich die Darstellung der Route auf einer Karte, wie auch die gesammelten Tiefendaten. (Ähnlich der Höhenanzeige im RC Programm)
Für die Vercharterer wäre noch ein schöner Nebeneffekt, wenn man auch die Beschleunigungsdaten über den gesamten Turnzeitraum sehen könnte. Und dann per Ausschnittbildung den dazugehörigen Routenteil sehen könnte. (Ich denke da z.B. an Kollisionen mit Bojen, anderen Schiffen usw...)
Die Anzeige könnte auch ähnlich der Höhenanzeige im RC erfolgen.
Da ich ein strikter Gegener von Doppelentwicklungen bin, fände ich es sehr spannnend das in den RC mit zu integrieren. Denn Christian hat sich ja die ganze Arbeit schon mal gemacht, ich würde mich dann eher auf die loggerspezifichen Teile (Also Darstellung der Wassertiefen, und der Lage und Beschleunigungsdaten) innerhalb vom RC konzentrieren. Wäre eine solche Zusammenarbeit für dich/euch interessant?

[routeconverter]

Da ich ein strikter Gegener von Doppelentwicklungen bin, fände ich es sehr spannnend das in den RC mit zu integrieren. Denn Christian hat sich ja die ganze Arbeit schon mal gemacht, ich würde mich dann eher auf die loggerspezifichen Teile (Also Darstellung der Wassertiefen, und der Lage und Beschleunigungsdaten) innerhalb vom RC konzentrieren. Wäre eine solche Zusammenarbeit für dich/euch interessant?

Klar ist das interessant - ein Open Source-Projekt lebt von den Nutzern und ihren Beiträgen. So hat @EddiVonDerAlm viele Beiträge gebracht, wie z.B. den Douglas-Peucker-Algorithmus und einige fieste Binärformate, die vielen Nutzern zu Gute kommen.

Im Detail müssen wir herausfinden, wo Du hinwillst und was für Dich interessant ist und was für alle anderen Nutzer. Von einer weiteren Optimierung, um Millionen Positionen lesen und bearbeiten zu können, profitieren sicher alle Nutzer und im schlimmsten Fall merkt man es nicht, wenn man nur 50 Positionen in einer Route hat. Anderseits kann man natürlich für einen Anwendungsfall nicht das gesamte UI umbauen. Je nachdem, wie weit Du da abweichen möchtest und wieviel Arbeit Du investieren möchtest, könntest Du auch eine Variante mit abweichendem UI (und eigenem Namen) bauen und verteilen. Die GPL erlaubt das. Oder Du bleibst näher an meinem Master-Branch und wir überlegen, wie wir Deine Ideen ins UI bekommen. Zum Beispiel könnte man einen kleinen Dialog bauen, der die Häppchen von einer Stunde auf 1 Klick zugreifbar macht - dann müßte man nicht Gigabytes laden. Oder man komprimiert die Häppchen im voraus, um sie im Bedarfsfall schnell laden zu können. Oder oder oder.

[willie68]

Klar ist das interessant - ein Open Source-Projekt lebt von den Nutzern und ihren Beiträgen. So hat @EddiVonDerAlm viele Beiträge gebracht, wie z.B. den Douglas-Peucker-Algorithmus und einige fieste Binärformate, die vielen Nutzern zu Gute kommen.

Im Detail müssen wir herausfinden, wo Du hinwillst und was für Dich interessant ist und was für alle anderen Nutzer. Von einer weiteren Optimierung, um Millionen Positionen lesen und bearbeiten zu können, profitieren sicher alle Nutzer und im schlimmsten Fall merkt man es nicht, wenn man nur 50 Positionen in einer Route hat. Anderseits kann man natürlich für einen Anwendungsfall nicht das gesamte UI umbauen. Je nachdem, wie weit Du da abweichen möchtest und wieviel Arbeit Du investieren möchtest, könntest Du auch eine Variante mit abweichendem UI (und eigenem Namen) bauen und verteilen. Die GPL erlaubt das. Oder Du bleibst näher an meinem Master-Branch und wir überlegen, wie wir Deine Ideen ins UI bekommen. Zum Beispiel könnte man einen kleinen Dialog bauen, der die Häppchen von einer Stunde auf 1 Klick zugreifbar macht - dann müßte man nicht Gigabytes laden. Oder man komprimiert die Häppchen im voraus, um sie im Bedarfsfall schnell laden zu können. Oder oder oder.

Was ich mir vorstelle, ist das ich den RC per Kommandozeile mit einer oder mehreren Dateien starte.
Am UI möchte ich eigentlich gar nichts ändern.
Wenn Tiefendaten vom Echolot vorhanden sind, wird neben dem Höhenfenster auch ein Tiefenfenster angezeigt. (Evt. einfach nur in einer anderen Farbe mit in das Fenster eingezeichnet. z.B. in rot mit dem Y-Massstab auf der rechten Seite.)
Wenn ACC und Gyro Daten vorhanden sind, dann gibt es quasi eine 2. Höhenanzeige. Dort werden dann alle 6 Kurven dargestellt. Per Kontextmenü kann man dann einzelne Kurven an/abschalten.
Wenn ich in den beiden Fenstern einen BEreich markiere, kann ich darin zoomen und nur das Stück der Route wird oben in der Karte dargestellt. Bei der Darstellung der Teifen und Gyrowerte dürfen bei der gleitenden Mittelwertbildung die Maxima und Minima nicht verwischt werden. D.h. man muss selbst wenn nur ein Messpunkt total rausreißt diesen direkt sehen können. (z.B. Kollision mit dem Untergrund, oder einem anderen Boot)
D.h. im RC müßte nur marginal etwas geändert werden.
zus. Parsen der Echolotdaten. (Um die Konvertierung der Seatalk Daten nach NMEA würde ich mich dann im Loggerverwaltungsprogramm kümmern.) zus. Parsen der Acc/Gyro Daten und wenn vorhanden dann zus. Fenster zur Darstellung.
Klar könnte ich aus dem Repo meinen eigenen RC builden und den modifizieren. Aber genau das will ich ja nicht. Schnell ist man von der Hauptentwicklung abgehängt. (Ich bin ja selber Softwarearchitekt.)

[routeconverter]

Wenn Tiefendaten vom Echolot vorhanden sind, wird neben dem Höhenfenster auch ein Tiefenfenster angezeigt. (Evt. einfach nur in einer anderen Farbe mit in das Fenster eingezeichnet. z.B. in rot mit dem Y-Massstab auf der rechten Seite.)
Wenn ACC und Gyro Daten vorhanden sind, dann gibt es quasi eine 2. Höhenanzeige. Dort werden dann alle 6 Kurven dargestellt. Per Kontextmenü kann man dann einzelne Kurven an/abschalten.

Dann schau Dir mal ProfileView und ProfileMode an: das müßtest Du erweitern.

Wenn ich in den beiden Fenstern einen BEreich markiere, kann ich darin zoomen und nur das Stück der Route wird oben in der Karte dargestellt.

Das klappt im Moment nicht.

Bei der Darstellung der Teifen und Gyrowerte dürfen bei der gleitenden Mittelwertbildung die Maxima und Minima nicht verwischt werden. D.h. man muss selbst wenn nur ein Messpunkt total rausreißt diesen direkt sehen können.

Erfüllt: es gibt keine gleitenden Mittelwerte bei RouteConverter.

D.h. im RC müßte nur marginal etwas geändert werden.
zus. Parsen der Echolotdaten. (Um die Konvertierung der Seatalk Daten nach NMEA würde ich mich dann im Loggerverwaltungsprogramm kümmern.) zus. Parsen der Acc/Gyro Daten und wenn vorhanden dann zus. Fenster zur Darstellung.

Bei einem weiteren NMEA-ähnlichen Format könnte ich Dir helfen - das geht mit meiner Erfahrung bestimmt schneller, wenn Du sagst, welche Daten relevant sind.

Klar könnte ich aus dem Repo meinen eigenen RC builden und den modifizieren. Aber genau das will ich ja nicht. Schnell ist man von der Hauptentwicklung abgehängt. (Ich bin ja selber Softwarearchitekt.)

Kennst Du git und github?