bcn2
commented
4 years ago Dirk,
hat es irgendeine Reaktion gegeben? Kontakte?
Hubert
Open Dirk-- opened 4 years ago
bcn2
commented
4 years ago Dirk,
hat es irgendeine Reaktion gegeben? Kontakte?
Hubert
wellenvogel
commented
4 years ago Wir hatten auf der Messe den Kontakt mit Navionics, sie haben mir jetzt geschrieben, das sie es intern an die Entwicklung weitergeleitet haben. Ich werde dranbleiben und nochmal nachhaken, wenn in absehbarer Zeit nichts kommt.
Gruß Andreas
Am 2. Februar 2020 09:34:58 MEZ schrieb bcn2 notifications@github.com:
Dirk,
hat es irgendeine Reaktion gegeben? Kontakte?
Hubert
-- You are receiving this because you were assigned. Reply to this email directly or view it on GitHub: https://github.com/open-boat-projects-org/call-for-papers/issues/1#issuecomment-581111797
Dirk--
commented
4 years ago Auf meine Email habe ich bisher keine brauchbaren Rueckmeldungen erhalten. Lediglich Empfangsbestaetigungen oder die Notiz, die Mail sei weitergeleitet worden ....
afischerdev
commented
4 years ago Wie wäre es denn, wenn man z.B. im Falle Navionics ein Projekt ohne Keys veröffentlich und damit Nutzer zwingt, sich selbst einen Key zu besorgen? Und einen neuen Bundle Identifier. Muss ja nicht immer alles Out-of-the-Box sein. Navionics hat ein eigenes Git-Projekt, in dem auch ihr Key drin enthalten ist.
Viele Grüße Axel
wellenvogel
commented
4 years ago Hmm. Aber wie soll das gehen? Vermutlich wird ja Navionics nicht jedem Endnutzer einen key geben wollen. Und am Ende braucht man ja alles offline, i.e. muss es 'runterladen.
afischerdev
commented
4 years ago Ja, ist schon richtig, ich dachte auch eher an Entwickler. Ich musste mein Projekt vorstellen und es dauerte etwas über eine Woche bevor es genehmigt wurde und ich eigene Keys generieren konnte. Habe nochmal das Git Beispiel kontrolliert, es wird zwar der Key mitgegeben, aber die Libs fehlen.
free-x
commented
4 years ago moin, sorry dass ich so hier reinplatze ;-) Um welchen Art von Karten geht's denn? Vector? Raster? Für welche Anwendungen wird es benötigt? ich nehme an: OpenCPN, AvNav, AFTrack SE, SignalK (freeboard-sk, tuk-tuk)
OpenCPN Vector: S-57/SENC, cm93v2 Raster: BSB3, MBTiles Da jetzt "oernc" verfügbar sollte man vielleicht kontakt zu NV und DK herstellen. Beim letzteren war Gerhard Kley( g.kley@delius-klasing.de ) für Karten zuständig. Ich denke nach dem "desaster" mit "Yacht Navigator" und absprung von Fugawi, andere Vertriebskanäle für DK-Karten wären für DK von Vorteil
Webbasierte Anwendungen Ich fasse die alle (AvNav, SignalK, AFtrack) zusammmen: sind vor allem für die Arbeit mit Tiles ausgelegt. Die dann in Form MBTiles, GEMF, OSMDroid konsumieren bzw als Input für konverter benutzt werden Kleine Ausnahme: AFTrack kann auch native NV ( respekt @afischerdev ) und BSB
Was stellt ihr euch vor? In welcher Form werden von Kartenherstellern erwartet? Die werden bestimmt "not amused" wenn die Ergebnisse kein DRM haben. Also wie sollen die Schutzmechanismen aussehen.
Wer soll das übernehmen? @bcn2 hast du Lust unter dem Dach von o-charts das unterzubringen?
Gruß free-x
bcn2
commented
4 years ago Aus der o-charts/OpenCPN Perspektive:
Wir hatten auf der METS Kontakt mit NV und warten darauf, dass sie sich melden. Ich will auch nicht drängeln, weil wir nicht über Langeweile klagen können. Mit G.Kley gab es im Vorjahr Gespräche, aber er hat sich auf meine letzte Anfrage im Herbst nicht mehr gemeldet.
Es ist sonnenklar, dass alle Kartenhäuser auf einem DRM bestehen. Inklusive einer beschränkten Anzahl von Kopien, die nachzuweisen und nachverfolgbar sein müssen.
Andreas AvNav hat einige Ideen, die OpenCPN plug-ins zu nutzen. Da ist noch ein wenig Nachdenken von uns auf der OpenCPN Seite gefragt. mbTiles Encrypted haben wir auch schon einmal debattiert und ist eine machbare Option.
Unter dem Dach von o-charts: das geht, nur sollte man sich immer vor Augen halten, dass die Entwicklung und Anpassung an OpenCPN, Produktion, Updates, Lizensierung, Reporting plus eine Horde von Finanzbehörden einen beträchtlichen Rattenschwanz an Arbeit nach sich ziehen. Das braucht eine feste Struktur und ist auch nicht nur mit guten Vorsätzen durchzuhalten. Als Hausnummer schätzen wir, dass z. Zt. etwa 5.000 Mannstunden im Jahr aufgebracht werden.
Rasterkarten sind im Allgemeinen aufwändiger als Vektormaterial. Hängt aber davon ab, wie die Karten angeliefert werden und welche händischen Arbeitsschritte anfallen. Auf der anderen Seite gibt es seltener Updates als bei Vektor ENCs.
Das nächste Thema in diesem Zusammenhang ist der Support. Wir machen das für OpenCPN, aber wenn weitere Programme oder Apps dazu kämen, müssen wir an dieser Front streiken. Da fehlt dann einfach das nötige Know-how. (Dass ein Benutzer trotzdem bei o-charts anklopft ist unvermeidbar...)
Wir hatten und haben Kontakt zu den "Grossen Drei" Garmin/Navionics, Navico/C-Map und Wärtsila/Transas. Ob und wann da etwas spruchreif wird, werden wir sehen.
Navionics verwies uns das letzte Mal auf unsere Kartenquelle Chartworld und die Navionicskarten im S-63 Format. Es gibt Benutzer für diese Karten, aber der Preis ist nicht für Arme. Was aus Transas unter der Wärtsilafahne wird, ist eine andere spannende Frage. Bei diesen Herstellern fällt sicherlich das Thema Lizensierung und Distribution weg, aber Support bleibt. Über die Frage, was es den Herren (und Damen) wert ist, dass wir ihnen Kunden anschleppen, kann man sich auch trefflich streiten. Für lau würden wir das nicht machen. Zu welchem Preis es die Lizenzen gäbe, App-level oder Plotter-level, bereitet diesen Partnern ebenfalls heftiges Kopfzerbrechen.
Wir sind zu allen Schandtaten bereit - im Rahmen unser Kapazitäten.
Hubert
wellenvogel
commented
4 years ago Wie Hubert schon geschrieben hat, haben wir ja ein wenig überlegt... Mein Favorit wäre eine Lösung, die es ermöglicht, für möglichst viele Dinge eine gemeinsame Infrastruktur zu haben. Und damit den Aufwand möglichst gering zu halten. Da dort OpenCPN schon weit ist, wäre es m.E. eine gute Option, das nachzunutzen. Hätte ggf. auch den Charme, das man auf dem gleichen System dann auch je nach Anwendungsfall OpenCPN oder eben z.B. AvNav nutzen könnte - mit den gleichen für dieses System lizensierten Karten. Support ist definitiv ein Thema - ich würde da für AvNav natürlich selbst bereit stehen, aber ich vermute, das wir dann noch mehr Freiwillige brauchen, um das halbwegs lückenlos abdecken zu können. Definitiv ist das DRM Thema nicht ganz klein. Hier wäre es natürlich auch gut, wenn sich alle Anstrengungen unter dem Dach von o-charts bündeln lassen. Ich könnte mir vorstellen, das es ggf. auch weitere Entwickler geben könnte, die bereit wären da mit Manpower beizutragen.
afischerdev
commented
4 years ago Hier noch mein Senf aus Android Sicht:
Für Navionics sehe ich keinen Handlungsbedarf. Ich versuche gerade eine Anpassung für AFTrack, aber das ist für niemand sonst interessant. Navionics bietet ja schon eine API.
Ich könnte mir aber ein Open Source Plugin für o-charts vorstellen:
Bei BRouter kann man sich z.B. die Idee eines solchen Interfaces ansehen, es besteht aus einer Interface-Beschreibung (aidl) und einer dazu passenend ServiceConnection Klasse. Die müssen dann in ein anderes Projekt eingebunden werden.
Ich habe einige Plugins für AFTrack so realisiert, um dem Grundprogramm nicht zuviel Extrawünsche aufzubürden. Auch ein RNC Plugin mit Karten aus einer Datenbank war dabei - für einen Kartenhandler. Die Ids für die Kacheln waren dabei kryptisch und eine Funktion getTile(x,y,z) musste mit dem Schlüssel des Benutzers umgerechnen werden auf die Id der Kachel. Ist aber nichts draus geworden, es kamen nicht genug Kartenlieferanten zusammen.
Die Initialisierung würde ich machen, brauche aber Unterstützung für das Zusammenspiel mit o-charts - da hatte ich bisher keinen Kontakt. Auch eine Beispielkarte wäre schön, ich hatte mal eine australische Karte mit Testschlüssel, das war sehr hilfreich. Im Moment denke ich an RNC, stelle ich mir einfacher vor. Aber auch Vektorkarten könnten ähnlich behandelt werden.
Axel
wellenvogel
commented
4 years ago Ziemlich gute Idee das mit einem universellen Plugin. Die Herausforderung am Ende ist vermutlich, genügend Sicherheit gegen unerwünschtes Kopieren der Karten dort einzubauen. Ich wäre jedenfalls dabei...
bcn2
commented
4 years ago Ich sehe drei Software Baustellen und eine juristische/administrative:
1 - Einbau der oeSENC und oeRNC Plug-ins in andere Apps oder Programme. Wie kommt die entschlüsselte und gerenderte Kartenansicht in die Applikation. Das schliesst das generelle OpenCPN plug-in framework ein. Letzteres ist gerade in Überarbeitung, um in Zukunft leichter installieren und ausrollen zu können. Auf dem Bauplan steht auch ein Verschmelzen der beiden "oeXXX" plug-ins in eines. Was einschliesst, die Konzepte, bei denen wir dazu gelernt haben und bei oeRNC implementiert sind, auch auf oeSENC anzuwenden. Und klar, das Thema Sicherheit bei einem vertretbaren Aufwand steht immer an der Wand. Freie Software und DRM sorgt in der Regel für hochgezogene Augenbrauen und eine gehörige Portion Misstrauen auf Seiten der Lizenzgeber. Fehler sollten wir uns also nicht leisten.
2 - Settings und Verwalten von Einstellungen in der Zielapp.
3 - Implementierung der Shop-API. Um sich da eine Idee zu machen, kann man sich zu den Funktionalitäten einfach die kleinen Handbücher zum Installieren von Karten anschauen. oeSENC z.B.: https://manuals.o-charts.org/oesenc_en_US.html . Es gibt auch ein YouTube Filmchen. Wie üblich bei GUIs ist das Abfangen und Behandeln von Fehlern ein ewiger Quell von neuen Überrraschungen. Aber das kennt ja jeder... Die Funktionen zur Identifizierung eine Systems und der Verwaltung von Kopien soll einerseits online im Hintergrung ablaufen - das ist der Normalfall - aber auch eine Offlineanforderung von Karten muss möglich sein.
Administrativ: Alle Lizenvereinbarungen enthalten Aussagen zum Zielsystem oder Zielprodukt. Zu klären wäre hier, ob ein OpenCPN oeXXX plug-in als "Zielsystem" akzeptiert wird, unabhängig von der konkreten App oder ob alle Verträge jedesmal angefasst werden müssen. Für Alternative A) würde sprechen, dass das Kartenprodukt dasselbe ist.
afischerdev
commented
4 years ago Einheitlichkeit hört sich gut an. Sicherheit für die Kartenanbieter wird im OpenCPN Pluign durch die geschlossenen Bibliotheken gewährleistet. Das wäre hier auch so. Libs müssten allerdings for zur Verfügung gestellt werden. Rendering: Für SENC hätte ich da noch keine Idee, aber für RNC stelle ich mir die Übergabe eines Tiles vor.
Die Zielapp erhält vom Plugin Informationen von die verfügbaren Karten über Kartenname, Copyright, Ausdehnung, Zoomstufen, usw. - angedacht Json Format. Und sie muss dann beim Plugin die gewünschten Kacheln für eine Karte anfordern. Es gibt ein Beispiel dazu für die Einbindung.
Den Shopzugriff sehe ich über den Webauftritt bis zum Download. Auf dem Device wird dann die Karte über das Plugin auf dem Filesystem referenziert. So kann man die Karte auch auf einer SD-Karte speichern.
Das Ganze geht nur - aus meiner Sicht - wenn das Plugin als Zielsystem akzeptiert ist, auch wenn es von verschiedenen Apps genutzt werden kann.
Update Struktur
afischerdev
commented
4 years ago @bcn2
Ich würde gern hierauf nochmal zurückkommen:
Administrativ: Alle Lizenvereinbarungen enthalten Aussagen zum Zielsystem oder Zielprodukt. Zu klären wäre hier, ob ein OpenCPN oeXXX plug-in als "Zielsystem" akzeptiert wird, unabhängig von der konkreten App oder ob alle Verträge jedesmal angefasst werden müssen. Für Alternative A) würde sprechen, dass das Kartenprodukt dasselbe ist.
Wie sind denn die Aussichten, dass so eine Plugin-Konstruktion akzeptiert wird?
Meine Navionics-Einbindung neigt sich dem Ende zu und da gäbe es wieder zeitliche Räume, um etwas an der Idee zu arbeiten. Aber es sollte auch Sinn machen.
bcn2
commented
4 years ago Axel...
@wellenvogel hat in den letzten Tagen ebenfalls angefangen, sich über Machbarkeit und Code Gedanken zu machen. Ihr solltet Euch vielleicht mal kurzschliessen. Und uns dabei einbeziehen.
Wenn das Kartenprodukt oeSENC oder oeRNC von o-charts ist, können wir mit der Hypothese arbeiten, dass die Lizenzverträge das aushalten. Bis der nächste Rechtsgelehrte was anderes entdeckt.
EULA müsste man sich anschauen, wenn wir was spruchreifes haben.
Hubert
wellenvogel
commented
4 years ago Ich bin dabei. Ich mache jetzt erst mal ein proof of concept, wie die Performance aussieht. Fokus erst mal raspberry. Aber Android könnte der nächste Schritt sein.
afischerdev
commented
4 years ago Gut, ich bereite etwas vor für Android,, so wie ich es im Moment im Kopf habe und lege dann ein Git-Projekt an. Dann haben wir erwas zum Diskutieren. Dauert einen Moment.
Dirk--
commented
4 years ago free-x
commented
4 years ago ja...es waren schon spannend die vergangenen 2 Monate das Zeug zu testen ;-)
afischerdev
commented
4 years ago Ja, sieht gut aus, finde ich auch. Erinnert mich leider daran, dass ich auch etwas vorbereiten wollte. Da bin ich in Verzug, habe mich im ersten Anlauf etwas verbastelt und dann erstmal liegenlassen. Nach dem Urlaub mache ich weiter.
wellenvogel
commented
4 years ago Leider ist android noch ein weiter Weg... WxWidgets gibts ja nicht so wirklich. Hat Dave selber gebaut so wie ich das sehe. Aber ich schaue mir das mal an. Vielleicht finden wir dann einen Weg für multiple Nutzung...
bcn2
commented
4 years ago Erstmal finden wir es toll, dass Andreas das gebacken bekommen hat. Einfach war es sicherlich nicht. Und wir haben da nicht viel helfen können.
WxWidgets für Android ist ein heisses Thema - Sean hat da auch einiges beigetragen. Und Dave kann mehr als eine Geschichte erzählen, wenn wieder eine neue Android Version rauskommt. "Multiple Nutzung" - ja bitte.
afischerdev
commented
4 years ago Warum sollen unbedingt wxWidgets genutzt werden?
Mein Vorschlag beruht auf Standard Java. Eine Schnittstelle zwischen App und Plugin und eine Schnittstelle zwischen Plugin und Server. Die Ui ist dabei sehr rudimentär. Knöpfe zum Generieren von device-key, Einladen von Downloads, Hilfestellung, Shopaufruf, eine Liste der Kartensets. So was eben.
Die App erhält vom Plugin die Liste der vorhandenen Karten bzw. der Kartensets (hatte ich erstmal in json gemacht, weil ich nicht wußte, ob es vielleicht zum Kartendownload eine Liste der enthalten Einzelkarten mitkommt, XML wäre genau so denkbar). Und die App kann für Koordinaten und Größe ein Bitmap anfragen (als Byte Array).
Das Plugin fragt das Array beim Server ab und erhält eine entschlüsselten Kartenausschnitt zurück. Diese Schnittstelle ist Java zu native.
Ich gehe davon aus, wir können den Server des OpenCPN-Plugins für o-charts mitnutzen.
Leider stand der Server für das Android System noch nicht zur Verfügung. Ich vermute allerdings, dass Dave ihn in seinem Plugin für Android bereits nutzt. Darauf beruht überhaupt die Möglichkeit, ein Open Source Project mit verschlüsselten Karten zu machen.
wellenvogel
commented
4 years ago Ich würde auch sehr gerne auf WxWidgets verzichten. Aber die Karten sind Vektor-Karten- wir brauchen also einen Renderer. Ich wollte von der Arbeit bei OpenCPN profitieren und nehme deren Plugin. Das nutzt leider WxWidgets. Aber so ist es auch lizenztechnisch einfach. Die Karten kommen dann gerendert als Kacheln. Meine UIs sind komplett in Js. Ein Weg wäre, den server, den ich dafür gebaut habe ( und der das plugin lädt) auch auf Android an den Start zu bringen. Das sollte prinzipiell gehen - es gibt ja OpenCPN und das plugin schon für Android. Api dann http ( ggf. noch was in Java + jni dazu). Da gibt es dann auch schon einen Ansatz, wie wir Sicherheit gegen unerlaubte Nutzung bekommen ( verschlüsselte URLs mit jeweils einem Zertifikat pro App). Ausserdem auch caching und eine UI für die Konfiguration (einfach im WebView...). Alternative wäre ein neuer/anderer Renderer....
afischerdev
commented
4 years ago Gut, ich war bisher davon ausgegangen, für das Rendering ist die anfragende App zuständig.
Aber dies wäre eine Variante, die für sehr viele tile-verarbeitende Apps geeignet wäre. Easy going für die Plugin Nutzer, aber heavy stuff für das Plugin.
In der Verbindung App zu Plugin hatte ich schon eine Funktion getTile(x,y,z) vorgesehen, da bräuchte es nicht mal einen Webserver.
open letter to Transas, FlyToMap, Navionics, NV-Verkag, Vaarkaart Nederland, Eniro, ...:
[...] Dear Sir or Madam,
I am part of the team, promoting openSource and openHardware @ boot_2020 in Duesseldorf: https://open-boat-projects.org
You might find some (translated) feedback here: https://translate.google.com/translate?hl=de&sl=de&tl=en&u=https%3A%2F%2Fwww.segeln-forum.de%2Fboard194-boot-technik%2Fboard35-elektrik-und-elektronik%2F73796-diy-gemeinschaftsstand-auf-der-boot-2020%2Findex5.html%23post2113347
Besides interest in openData, there is a great demand in reliable charts for recreational boating from developer and user side. We would like to encourage you and your company to provide licensed sets of charts for our favorite openSource chart plotters: https://wiki.opennauticalchart.org/index.php?title=Category:Applications
Feel free to bundle efforts with o-charts.org [...]