https://wiki.openseamap.org/api.php?action=feedcontributions&user=MartinOver&feedformat=atomOpenSeaMap-dev - Benutzerbeiträge [de]2024-03-28T14:59:02ZBenutzerbeiträgeMediaWiki 1.31.10https://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:Entwicklerwochenende_2015-04/Bericht_en&diff=3494OpenSeaMap-dev:Entwicklerwochenende 2015-04/Bericht en2015-05-05T10:42:09Z<p>MartinOver: /* Organisation */</p>
<hr />
<div>[[Category:Meetings]]<br />
<br />
= Protocol =<br />
The meeting took place in Nürnberg from 2015-04-24 - 2015-04-26<br />
<br />
== Organisation ==<br />
There have been some intense discssions about the openess of the openseamap activities. Markus argued that there are discussions with parties that require to be in private since they don't like to be publicly associated to openseamap for political reasons.<br />
The people present at the meeting understood that need but claimed that some developers left or feel demotivated since key information is held by a central person. Communication with such parties is sensitive and should be done by people<br />
that have valuable contributions and insight. We found that even if we setup a group instead of a person the legitimation for that group is pretty difficult since we have no legal background which can regulate who is able to vote or not.<br />
Markus pointed out that some communication resembles characteristics of first level support and it is efficient to not bother developers which such an information. Attendees felt that this decision is to be made by developers themselves.<br />
After some discussion and weighing out the pros and cons of such changes, Martin offered to summarize the discussion which will be communicated shortly - first for to attendees and then to the public.<br />
<br />
== Depth Processing ==<br />
=== Postprocessing ===<br />
We have the basic processing chain setup and evaluate the performance in real world data sets.<br />
Inshore data renders fine but large offshore data has to be improved as some queries are a little bit slow.<br />
When performance has been improved we need to focus on data quality. Key quality contributors are the ocean tide, gauges and manual data corrections.<br />
Ocean tide calculation is already included and gauges will be the next step to be included.<br />
Andreas is an expert in filtering techniques and data analysis and would like to view at portions of the data to get an insight how a good filter might look like.<br />
As the sources are not yet online it is quite difficoult to get the system up and running in his environment.<br />
==== Format decoding ====<br />
Herbert has written a tool that is capable detecting patterns in file formats to decode them. <br />
He is currently working on AT5 which is a chart format by Lowrance. Since we have several unknown formats<br />
which were uploaded to the depth webpage he will try to analyze some of the formats to see if we can decode them in the near future<br />
=== Web Backend ===<br />
Editing of errors and gauges need to be addressed.<br><br />
[http://depth.openseamap.org:8080/org.osm.depth.upload.stage/api2/| Backend API]<br><br />
[https://depth.openseamap.org:8443/org.osm.depth.upload.stage/api2/| Backend API Secure]<br><br />
<br />
=== Website ===<br />
The manual corrections involves more work and Martin will make a proposal how to integrate the editing from the gis web viewpoint.<br />
Axel is a new contributor to the web page and contributed some valuable fixes.<br><br />
[https://depth.openseamap.org| Depth Website]<br><br />
[https://github.com/OpenSeaMap/depth_webfrontend| Sources Webfrontend]<br />
<br />
== Rendering ==<br />
=== Paper Chart Rendering === <br />
[http://www.abenteuerland.at/smrender/| SMRender]<br />
Bernhard is actively contributing to the paper based renderer and is capable of rendering various difficult scenarios.<br />
However he - like so many others - eagerly awaits free depth contours from OpenSeaMap to become available.<br />
<br />
=== Software Rendering ===<br />
==== OSM Renderer ====<br />
Malcolm is administrating the old renderer while working on the new one. The new renderer may be found at<br />
http://svn.openstreetmap.org/applications/editors/josm/plugins/seachart/<br />
Progress has been slow recently.<br />
=== Application Rendering ===<br />
==== OSMAnd ====<br />
This Android based application is rendering charts from offline data pretty fast. However it lacks support for rendering seamarks. Markus Bärlöcher contacted the OSMAnd developer and he is open<br />
to contributions that are capable of rendering seamarks and other sea items. Interested parties are welcome to show themselves to [mailto:openseamap-devel@openseamap.org| OpenSeaMap Developer Mailing List]<br />
<br />
==== OpenCPN ====<br />
S57 is a widely supported format. It would be nice to have a S57 writer so that software such as OpenCPN could use OpenSeaMap data. This should be easy task since all seamarks are already encoded as S57<br />
within the osm database. KAP is a raster format that is supported. >> What is the status of these KAP files ??? <<<br />
==== Orux Maps & Locus ====<br />
Based on MapsForge. Alexej is looking into how we can integrate into that portal . Is that correct ?<br />
<br />
<br />
== Vector Charts ==<br />
=== AT5 Generation ===<br />
Someone ? is working on activating software that can generate at5 files. The process is very cpu time consuming<br />
and we have a hardware provider and location at hand that can take over the generation process. Everything needs to be setup though.<br />
=== Garmin ADM ===<br />
As of January garmin charts stopped working due to a firmware update. Investigation is underway.<br />
The chart updates are currenlty not being handled so they are very outdated. If someone likes to<br />
reenable the process, raise your hand.<br />
=== Raymarine ===<br />
There are some ideas floating around but nothing else at the moment. Contact Markus Bärlöcher to get some details.<br />
Raster Charts<br />
<br />
== Raster Charts ==<br />
Alexej Kulmbach is working on providing zip files of predefined regions. As the amount of data is fairly large - estimated to several TB of data - he is searching for<br />
ways to intelligently select necessary tiles and compressions. <br />
<br />
== State of the Loggers ==<br />
=== OpenSeaMap Data Logger ===<br />
==== NMEA0183 Seatalk ====<br />
Since there has been a bug on the firmware the produced loggers must be flashed with<br />
a new firmware. The recently sold loggers all had the new firmware but we are running low on patched loggers<br />
and we need to flash the unpatched loggers in stock. Andreas Merz and Wolfgang will contact Winfried Schäfer on the instructions<br />
how to flash the logger to speed up the process.<br />
==== NMEA 2000 ==== <br />
There is some interest to build such a logger and provide it at a cheat rate. Interested parties are welcome to show themselves to openseamap-devel@openseamap.org<br />
=== Plotters from vendors ===<br />
There are some plotter models listed on<br />
http://wiki.openstreetmap.org/wiki/AT5-OpenSeaMap-Chart_for_Lowrance_Simrad_B%26G<br />
http://wiki.openstreetmap.org/wiki/Garmin#Sea-Chart-Plotter<br />
It is desirable to complete that list. Anyone having information and willing to actively find out which plotters are supported, present yourself at openseamap-devel@openseamap.org<br />
=== Software Data Logger ===<br />
Since the upload API change the current logger no longer supports uploading files directly<br />
to depth.openseamap.org. There is a bug that needs to be fixed and Jens Kübler will look after it in order to get this working again.<br />
<br />
== Social Media ==<br />
Markus Bärlöcher tried to consolidate the accounts and found out some social media accounts are held by other people. We are figuring out ways integrate that appearance.<br />
Cornelia did some valuable work for our presense. Discussions are under way to improve rendering for mobile devices. The main web page needs some updates to the underlying typo3 system.<br />
Wolfgang offered some help with the updates.</div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:Structure&diff=3476OpenSeaMap-dev:Structure2015-05-03T13:45:44Z<p>MartinOver: Die Seite wurde neu angelegt: „tbd“</p>
<hr />
<div>tbd</div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:Portal&diff=3475OpenSeaMap-dev:Portal2015-05-03T13:45:18Z<p>MartinOver: /* OSeaM-Wiki Dev-Portal */</p>
<hr />
<div>{|<br />
| <br />
{| class="wikitable"<br />
| Liebe Entwickler,<br />
<br />
Willkommen auf dem OpenSeaMap-Entwicklerportal !<br />
<br />
Auf eine tolle Zusammenarbeit freuen sich <br><br />
Markus und Olaf <br />
|}<br />
| &nbsp; &nbsp; &nbsp; <br />
|<br />
{| class="wikitable"<br />
| Dear Developpers, <br />
<br />
Welcome to the OpenSeaMap Developer Portal !<br />
<br />
Looking forward to great cooperation, <br><br />
Markus und Olaf <br />
|}<br />
|}<br />
<br />
<br />
__TOC__<br />
<br />
== Organisationsplattformen ==<br />
{{de:organisation}}<br />
<br />
== OSeaM-Wiki Dev-Portal ==<br />
: [[OpenSeaMap-dev:Portal|Dev-Portal]]<br />
: [[de:Develop|Dev-Hauptseite]]<br />
: [[OpenSeaMap-dev:Guidelines|Dev-Guidelines]]<br />
: [[OpenSeaMap-dev:Structure|Dev-Structure]]<br />
: [[OpenSeaMap-dev:Projekte|Our Projects]]<br />
:: [[OpenSeaMap-dev:Watersport-Wiki|Watersport-Wiki]]<br />
<br />
:: [[OpenSeaMap-dev:Renderer|Renderer]]<br />
<br />
:: Shallow Water <br />
::: [[OpenSeaMap-dev:User_login|User-Login]]<br />
::: [[Depth_Data|Depth data]]<br />
::: [[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|Crowd Sourced Depth Data]]<br />
::: [[OpenSeaMap-dev:De:Depth_raw_data|De:Depth raw data]]<br />
::: [[OpenSeaMap-dev:De:Depth_meta_data|De:Depth meta data]]<br />
::: [[OpenSeaMap-dev:De:Depth_data_processing|De:Depth data processing]]<br />
::: [[Shipnetwork|Collecting data from the ship's network]]<br />
::: [[OpenSeaMap-dev:HW-logger/specification|HW-Logger]]<br />
::: [http://seesea.sourceforge.net/datalogger/index.html SW-Logger]<br />
<br />
:: Editors<br />
::: [[OpenSeaMap-dev:Online-Editor|Online-Editor]] <br />
::: [[de:Online-Editor|Online-Editor HowTo]] - [[Online-Editor|(englisch)]]<br />
::: [[OpenSeaMap-dev:SMED-2|JOSM plugin SMED2]]<br />
<br />
:: [[OpenSeaMap-dev:Harbour|Harbour]]<br />
::: [[OpenSeaMap-dev:Harbour-DB|Harbour-DB]]<br />
::: [[OpenSeaMap-dev:Hafen-DB|Hafen-DB alt]]<br />
::: [[OpenSeaMap-dev:Hafen-Editor|Harbour-Editor]]<br />
<br />
:: Dev-ToDo's<br />
::: [[de:OpenSeaMap_in_Website|OpenSeaMap in Website einbinden]]<br />
::: [[OpenSeaMap-dev:Online-Editor|Online-Editor-dev]]<br />
::: [[OpenSeaMap-dev:Renderer|Renderer-dev]]<br />
::: [[OpenSeaMap_in_Website|How to include OpenSeaMap in your website]]<br />
::: [[Server|Server]]<br />
<br />
== OSM-Wiki ==<br />
<br />
; Projekte<br />
: [http://wiki.openstreetmap.org/wiki/DE:Seekarte Ursprüngliche Projektseite "Seekarte"]<br />
: [http://wiki.openstreetmap.org/wiki/DE:Seekarte Projektseite "für Segler"] - [http://wiki.openstreetmap.org/wiki/Marine_Mapping (english)]<br />
: [http://wiki.openstreetmap.org/wiki/DE:Meeresprofil Bathimetrie] - [http://wiki.openstreetmap.org/wiki/Bathimetry (english)]<br />
: [http://wiki.openstreetmap.org/wiki/DE:Water_Depth Wassertiefe]<br />
: [http://wiki.openstreetmap.org/wiki/DE:AIS AIS] - [http://wiki.openstreetmap.org/wiki/AIS (english)]<br />
: [http://wiki.openstreetmap.org/wiki/DE:Seamap-Editor Projektseite "SeaMap-Editor"] - [http://wiki.openstreetmap.org/wiki/DE:Seamap-Editor (english)]<br />
: [http://wiki.openstreetmap.org/wiki/Openseamap/DE:Seamap_database Meta-DB] - [http://wiki.openstreetmap.org/wiki/Openseamap/Seamap_database (english)]<br />
<br />
; Grundlagen<br />
: [http://wiki.openstreetmap.org/wiki/DE:Lowest_Astronomical_Tide LAT] - [http://wiki.openstreetmap.org/wiki/Lowest_Astronomical_Tide (english)]<br />
: [http://wiki.openstreetmap.org/wiki/DE:Genauigkeit_von_Koordinaten Genauigkeit von Koordinaten]<br />
: [http://wiki.openstreetmap.org/wiki/DE:Genauigkeit_von_GPS-Daten Genauigkeit von GPS-Daten]<br />
: [http://wiki.openstreetmap.org/wiki/Zoom_levels Zoomlevel]<br />
: [http://wiki.openstreetmap.org/wiki/DE:Altitude Höhe] - [http://wiki.openstreetmap.org/wiki/Altitude (englisch)]<br />
<br />
; Daten<br />
: [http://wiki.openstreetmap.org/wiki/OpenSeaMap/Seamark_Tag_Values Seamark Tag Values]<br />
: [http://wiki.openstreetmap.org/wiki/OpenSeaMap/Seamark_Objects Seamark Objects]<br />
: [http://wiki.openstreetmap.org/wiki/OpenSeaMap/Seamark_Attributes Seamark Attributes]<br />
: [http://wiki.openstreetmap.org/wiki/OpenSeaMap/INT-1_Cross_Reference INT-1 Cross Reference]<br />
: and Sub-Pages.<br />
<br />
: [http://wiki.openstreetmap.org/wiki/de:Beacon Boye] - [http://wiki.openstreetmap.org/wiki/Buoy (english)]<br />
: [http://wiki.openstreetmap.org/wiki/de:Beacon Bake] - [http://wiki.openstreetmap.org/wiki/Beacon (english)]<br />
: [http://wiki.openstreetmap.org/wiki/de:Leuchtfeuer Leuchtfeuer] - [http://wiki.openstreetmap.org/wiki/Lighthouse (english)]<br />
: [http://wiki.openstreetmap.org/wiki/DE:Hafen Hafen] - [http://wiki.openstreetmap.org/wiki/Harbour (english)]<br />
: [http://wiki.openstreetmap.org/wiki/OpenSeaMap/Buoy_Data_Model Datenmodell Boye]<br />
: [http://wiki.openstreetmap.org/wiki/OpenSeaMap/Beacon_Data_Model Datenmodell Bake]<br />
: [http://wiki.openstreetmap.org/wiki/OpenSeaMap/Lights_Data_Model Datenmodell Leuchtfeuer]<br />
<br />
== Qualitätsmanagement ==<br />
: [http://seamark.bplaced.net/lights/ Leuchtfeuer mit falscher Position]<br />
: [http://seamark.bplaced.net/harbours/ doppelte Häfen und Marinas]<br />
: [[OpenSeaMap-dev:Harbour-Duplicates|Harbour Duplicates]]<br />
<br />
==Mailingliste==<br />
[https://lists.sourceforge.net/lists/listinfo/openseamap-develop openseamap-develop]{{English}} - [http://sourceforge.net/mailarchive/forum.php?forum_name=openseamap-develop Archiv]<br />
<br />
== Forum ==<br />
[http://forum.openseamap.org/ OpenSeaMap-forum]<br />
<br />
very old: [http://sourceforge.net/projects/openseamap/forums/forum/992659 openseamap-develop-de]<br />
<br />
==Fehler berichten==<br />
Bitte verwende den [http://sourceforge.net/tracker/?group_id=273418&atid=1162128 SourceForge Tracker] {{English}} für Problemberichte.<br />
<br />
== Wikipedia ==<br />
Viele hervorragende Artikel zu nautischen Themen sind in Wikipedia zu finden. Einige wurden von uns geschrieben. Gute Informationen findet man auch in der [[wikipedia:en:Main_Page|englischen Wikipedia]] (im deutschen Artikel links in der Menüleiste auf "english" klicken). Es macht Sinn, möglichst viel nautisches Wissen für alle Menschen direkt in Wikipedia verfügbar zu machen. Bitte schreibe also zu allgemein interessierenden Themen, auch wenn es wissenschaftlich ist, möglichst direkt in Wikipedia. Zu fast jedem nautischen Begriff gibt es bereits einen Artikel, den man vertiefen und erweitern kann.<br />
<br />
Wikipedia-Artikel können direkt im OSM- oder OSeaM-Wiki verlinkt werden:<br />
<pre><br />
[[wikipedia:de:Artikelname|anzuzeigender Text]] (deutsch)<br />
[[wikipedia:en:Artikelname|anzuzeigender Text]] (englisch)<br />
</pre><br />
<br />
: [[wikipedia:de:OpenSeaMap|OpenSeaMap]]<br />
: [[wikipedia:de:Pegel_(Wasserstandsmessung)|Pegel]]<br />
: [[wikipedia:de:Normalhöhennull|Normalhöhennull]]<br />
: [[wikipedia:de:Höhe (Geodäsie)|Höhe]]<br />
: [[wikipedia:de:Seekartennull|Seekartennull]]<br />
: [[wikipedia:de:World Geodetic System 1984|WGS-84]]<br />
: [[wikipedia:de:Automatic_Identification_System|Automatic Identification System (AIS)]]<br />
: [[wikipedia:de:Mann über Bord|Mann über Bord]]<br />
<br />
== OSeaM-Wiki ==<br />
[http://wiki.openstreetmap.org/wiki/DE:OpenSeaMap Bitte alle Beiträge zu allgemeinen Themen, oder solchen die auch andere OSMer interessieren direkt ins OSM-Wiki schreiben]. <br />
<br />
Dieses Wiki ist nur für '''Hilfetexte''' und '''HowTo'''. <br><br />
Bitte alle Beiträge in '''Deutsch''' und '''Englisch''' verfassen.<br />
<br />
: [[de:Hauptseite|Hauptseite]] - [[Hauptseite|(english)]]<br />
:: [[de:Editor|Editor]] - [[Editor|(english)]]<br />
::: [[de:Online-Editor|Online-Editor]] - [[Online-Editor|(english)]]<br />
:::: [[de:Online-Editor/Window|Fenster und Funktionen]] - [[Online-Editor/Window|(english)]]<br />
:::: [[de:Online-Editor/edit|Editieren (neu, ändern, verschieben, löschen)]] - [[Online-Editor/edit|(english)]]<br />
:::: [[de:Online-Editor/Seamark|Seezeichen eingeben]] - [[Online-Editor/Seamark|(english)]]<br />
:::: [[de:Online-Editor/Harbour|Häfen eingeben]] - [[Online-Editor/Harbour|(english)]]<br />
::: [[de:JOSM_and_Plugin|JOSM und Plugin]] - [[JOSM_and_Plugin|(english)]]<br />
:::: [[de:JOSM_and_Plugin/Window|Fenster]] - [[JOSM_and_Plugin/Window|(english)]]<br />
:::: [[de:JOSM_and_Plugin/edit|Editieren]] - [[JOSM_and_Plugin/edit|english]]<br />
:::: [[de:JOSM_and_Plugin/Seamark|Plugin]] - [[JOSM_and_Plugin/Seamark|(english)]]<br />
:::: [[de:JOSM_and_Plugin/Harbour|Hafen]] - [[JOSM_and_Plugin/Harbour|(english)]]<br />
:: [[de:NMEA-Daten_hochladen|Wassertiefen]] - [[NMEA-Daten_hochladen|(english)]]<br />
::: [[de:Software_logger|Software-Logger]] - [[Software_logger|(english)]]<br />
::: [[de:Hardware_logger|Hardware-Logger]] - [[Hardware_logger|(english)]]<br />
:: [[de:OruxMaps|Android-App]] - [[OruxMaps|(english)]]<br />
:: [[de:OpenSeaMap_in_Website|OpenSeaMap in Website]] - [[OpenSeaMap_in_Website|(english)]]<br />
:: [http://git.bezono.org/?p=openseamap/dfa/docs_rendering.git;a=blob_plain;f=openstreetmap/install_de.txt;hb=HEAD Tile-Server installing HowTo]<br />
<br />
<br />
<br />
[[Kategorie:Develop]]</div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:Portal&diff=3474OpenSeaMap-dev:Portal2015-05-03T13:44:49Z<p>MartinOver: /* OSeaM-Wiki Dev-Portal */</p>
<hr />
<div>{|<br />
| <br />
{| class="wikitable"<br />
| Liebe Entwickler,<br />
<br />
Willkommen auf dem OpenSeaMap-Entwicklerportal !<br />
<br />
Auf eine tolle Zusammenarbeit freuen sich <br><br />
Markus und Olaf <br />
|}<br />
| &nbsp; &nbsp; &nbsp; <br />
|<br />
{| class="wikitable"<br />
| Dear Developpers, <br />
<br />
Welcome to the OpenSeaMap Developer Portal !<br />
<br />
Looking forward to great cooperation, <br><br />
Markus und Olaf <br />
|}<br />
|}<br />
<br />
<br />
__TOC__<br />
<br />
== Organisationsplattformen ==<br />
{{de:organisation}}<br />
<br />
== OSeaM-Wiki Dev-Portal ==<br />
: [[OpenSeaMap-dev:Portal|Dev-Portal]]<br />
: [[de:Develop|Dev-Hauptseite]]<br />
: [[OpenSeaMap-dev:Guidelines|Dev-Guidelines]]<br />
: [[OpenSeaMap-dev:Guidelines|Dev-Structure]]<br />
: [[OpenSeaMap-dev:Projekte|Our Projects]]<br />
:: [[OpenSeaMap-dev:Watersport-Wiki|Watersport-Wiki]]<br />
<br />
:: [[OpenSeaMap-dev:Renderer|Renderer]]<br />
<br />
:: Shallow Water <br />
::: [[OpenSeaMap-dev:User_login|User-Login]]<br />
::: [[Depth_Data|Depth data]]<br />
::: [[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|Crowd Sourced Depth Data]]<br />
::: [[OpenSeaMap-dev:De:Depth_raw_data|De:Depth raw data]]<br />
::: [[OpenSeaMap-dev:De:Depth_meta_data|De:Depth meta data]]<br />
::: [[OpenSeaMap-dev:De:Depth_data_processing|De:Depth data processing]]<br />
::: [[Shipnetwork|Collecting data from the ship's network]]<br />
::: [[OpenSeaMap-dev:HW-logger/specification|HW-Logger]]<br />
::: [http://seesea.sourceforge.net/datalogger/index.html SW-Logger]<br />
<br />
:: Editors<br />
::: [[OpenSeaMap-dev:Online-Editor|Online-Editor]] <br />
::: [[de:Online-Editor|Online-Editor HowTo]] - [[Online-Editor|(englisch)]]<br />
::: [[OpenSeaMap-dev:SMED-2|JOSM plugin SMED2]]<br />
<br />
:: [[OpenSeaMap-dev:Harbour|Harbour]]<br />
::: [[OpenSeaMap-dev:Harbour-DB|Harbour-DB]]<br />
::: [[OpenSeaMap-dev:Hafen-DB|Hafen-DB alt]]<br />
::: [[OpenSeaMap-dev:Hafen-Editor|Harbour-Editor]]<br />
<br />
:: Dev-ToDo's<br />
::: [[de:OpenSeaMap_in_Website|OpenSeaMap in Website einbinden]]<br />
::: [[OpenSeaMap-dev:Online-Editor|Online-Editor-dev]]<br />
::: [[OpenSeaMap-dev:Renderer|Renderer-dev]]<br />
::: [[OpenSeaMap_in_Website|How to include OpenSeaMap in your website]]<br />
::: [[Server|Server]]<br />
<br />
== OSM-Wiki ==<br />
<br />
; Projekte<br />
: [http://wiki.openstreetmap.org/wiki/DE:Seekarte Ursprüngliche Projektseite "Seekarte"]<br />
: [http://wiki.openstreetmap.org/wiki/DE:Seekarte Projektseite "für Segler"] - [http://wiki.openstreetmap.org/wiki/Marine_Mapping (english)]<br />
: [http://wiki.openstreetmap.org/wiki/DE:Meeresprofil Bathimetrie] - [http://wiki.openstreetmap.org/wiki/Bathimetry (english)]<br />
: [http://wiki.openstreetmap.org/wiki/DE:Water_Depth Wassertiefe]<br />
: [http://wiki.openstreetmap.org/wiki/DE:AIS AIS] - [http://wiki.openstreetmap.org/wiki/AIS (english)]<br />
: [http://wiki.openstreetmap.org/wiki/DE:Seamap-Editor Projektseite "SeaMap-Editor"] - [http://wiki.openstreetmap.org/wiki/DE:Seamap-Editor (english)]<br />
: [http://wiki.openstreetmap.org/wiki/Openseamap/DE:Seamap_database Meta-DB] - [http://wiki.openstreetmap.org/wiki/Openseamap/Seamap_database (english)]<br />
<br />
; Grundlagen<br />
: [http://wiki.openstreetmap.org/wiki/DE:Lowest_Astronomical_Tide LAT] - [http://wiki.openstreetmap.org/wiki/Lowest_Astronomical_Tide (english)]<br />
: [http://wiki.openstreetmap.org/wiki/DE:Genauigkeit_von_Koordinaten Genauigkeit von Koordinaten]<br />
: [http://wiki.openstreetmap.org/wiki/DE:Genauigkeit_von_GPS-Daten Genauigkeit von GPS-Daten]<br />
: [http://wiki.openstreetmap.org/wiki/Zoom_levels Zoomlevel]<br />
: [http://wiki.openstreetmap.org/wiki/DE:Altitude Höhe] - [http://wiki.openstreetmap.org/wiki/Altitude (englisch)]<br />
<br />
; Daten<br />
: [http://wiki.openstreetmap.org/wiki/OpenSeaMap/Seamark_Tag_Values Seamark Tag Values]<br />
: [http://wiki.openstreetmap.org/wiki/OpenSeaMap/Seamark_Objects Seamark Objects]<br />
: [http://wiki.openstreetmap.org/wiki/OpenSeaMap/Seamark_Attributes Seamark Attributes]<br />
: [http://wiki.openstreetmap.org/wiki/OpenSeaMap/INT-1_Cross_Reference INT-1 Cross Reference]<br />
: and Sub-Pages.<br />
<br />
: [http://wiki.openstreetmap.org/wiki/de:Beacon Boye] - [http://wiki.openstreetmap.org/wiki/Buoy (english)]<br />
: [http://wiki.openstreetmap.org/wiki/de:Beacon Bake] - [http://wiki.openstreetmap.org/wiki/Beacon (english)]<br />
: [http://wiki.openstreetmap.org/wiki/de:Leuchtfeuer Leuchtfeuer] - [http://wiki.openstreetmap.org/wiki/Lighthouse (english)]<br />
: [http://wiki.openstreetmap.org/wiki/DE:Hafen Hafen] - [http://wiki.openstreetmap.org/wiki/Harbour (english)]<br />
: [http://wiki.openstreetmap.org/wiki/OpenSeaMap/Buoy_Data_Model Datenmodell Boye]<br />
: [http://wiki.openstreetmap.org/wiki/OpenSeaMap/Beacon_Data_Model Datenmodell Bake]<br />
: [http://wiki.openstreetmap.org/wiki/OpenSeaMap/Lights_Data_Model Datenmodell Leuchtfeuer]<br />
<br />
== Qualitätsmanagement ==<br />
: [http://seamark.bplaced.net/lights/ Leuchtfeuer mit falscher Position]<br />
: [http://seamark.bplaced.net/harbours/ doppelte Häfen und Marinas]<br />
: [[OpenSeaMap-dev:Harbour-Duplicates|Harbour Duplicates]]<br />
<br />
==Mailingliste==<br />
[https://lists.sourceforge.net/lists/listinfo/openseamap-develop openseamap-develop]{{English}} - [http://sourceforge.net/mailarchive/forum.php?forum_name=openseamap-develop Archiv]<br />
<br />
== Forum ==<br />
[http://forum.openseamap.org/ OpenSeaMap-forum]<br />
<br />
very old: [http://sourceforge.net/projects/openseamap/forums/forum/992659 openseamap-develop-de]<br />
<br />
==Fehler berichten==<br />
Bitte verwende den [http://sourceforge.net/tracker/?group_id=273418&atid=1162128 SourceForge Tracker] {{English}} für Problemberichte.<br />
<br />
== Wikipedia ==<br />
Viele hervorragende Artikel zu nautischen Themen sind in Wikipedia zu finden. Einige wurden von uns geschrieben. Gute Informationen findet man auch in der [[wikipedia:en:Main_Page|englischen Wikipedia]] (im deutschen Artikel links in der Menüleiste auf "english" klicken). Es macht Sinn, möglichst viel nautisches Wissen für alle Menschen direkt in Wikipedia verfügbar zu machen. Bitte schreibe also zu allgemein interessierenden Themen, auch wenn es wissenschaftlich ist, möglichst direkt in Wikipedia. Zu fast jedem nautischen Begriff gibt es bereits einen Artikel, den man vertiefen und erweitern kann.<br />
<br />
Wikipedia-Artikel können direkt im OSM- oder OSeaM-Wiki verlinkt werden:<br />
<pre><br />
[[wikipedia:de:Artikelname|anzuzeigender Text]] (deutsch)<br />
[[wikipedia:en:Artikelname|anzuzeigender Text]] (englisch)<br />
</pre><br />
<br />
: [[wikipedia:de:OpenSeaMap|OpenSeaMap]]<br />
: [[wikipedia:de:Pegel_(Wasserstandsmessung)|Pegel]]<br />
: [[wikipedia:de:Normalhöhennull|Normalhöhennull]]<br />
: [[wikipedia:de:Höhe (Geodäsie)|Höhe]]<br />
: [[wikipedia:de:Seekartennull|Seekartennull]]<br />
: [[wikipedia:de:World Geodetic System 1984|WGS-84]]<br />
: [[wikipedia:de:Automatic_Identification_System|Automatic Identification System (AIS)]]<br />
: [[wikipedia:de:Mann über Bord|Mann über Bord]]<br />
<br />
== OSeaM-Wiki ==<br />
[http://wiki.openstreetmap.org/wiki/DE:OpenSeaMap Bitte alle Beiträge zu allgemeinen Themen, oder solchen die auch andere OSMer interessieren direkt ins OSM-Wiki schreiben]. <br />
<br />
Dieses Wiki ist nur für '''Hilfetexte''' und '''HowTo'''. <br><br />
Bitte alle Beiträge in '''Deutsch''' und '''Englisch''' verfassen.<br />
<br />
: [[de:Hauptseite|Hauptseite]] - [[Hauptseite|(english)]]<br />
:: [[de:Editor|Editor]] - [[Editor|(english)]]<br />
::: [[de:Online-Editor|Online-Editor]] - [[Online-Editor|(english)]]<br />
:::: [[de:Online-Editor/Window|Fenster und Funktionen]] - [[Online-Editor/Window|(english)]]<br />
:::: [[de:Online-Editor/edit|Editieren (neu, ändern, verschieben, löschen)]] - [[Online-Editor/edit|(english)]]<br />
:::: [[de:Online-Editor/Seamark|Seezeichen eingeben]] - [[Online-Editor/Seamark|(english)]]<br />
:::: [[de:Online-Editor/Harbour|Häfen eingeben]] - [[Online-Editor/Harbour|(english)]]<br />
::: [[de:JOSM_and_Plugin|JOSM und Plugin]] - [[JOSM_and_Plugin|(english)]]<br />
:::: [[de:JOSM_and_Plugin/Window|Fenster]] - [[JOSM_and_Plugin/Window|(english)]]<br />
:::: [[de:JOSM_and_Plugin/edit|Editieren]] - [[JOSM_and_Plugin/edit|english]]<br />
:::: [[de:JOSM_and_Plugin/Seamark|Plugin]] - [[JOSM_and_Plugin/Seamark|(english)]]<br />
:::: [[de:JOSM_and_Plugin/Harbour|Hafen]] - [[JOSM_and_Plugin/Harbour|(english)]]<br />
:: [[de:NMEA-Daten_hochladen|Wassertiefen]] - [[NMEA-Daten_hochladen|(english)]]<br />
::: [[de:Software_logger|Software-Logger]] - [[Software_logger|(english)]]<br />
::: [[de:Hardware_logger|Hardware-Logger]] - [[Hardware_logger|(english)]]<br />
:: [[de:OruxMaps|Android-App]] - [[OruxMaps|(english)]]<br />
:: [[de:OpenSeaMap_in_Website|OpenSeaMap in Website]] - [[OpenSeaMap_in_Website|(english)]]<br />
:: [http://git.bezono.org/?p=openseamap/dfa/docs_rendering.git;a=blob_plain;f=openstreetmap/install_de.txt;hb=HEAD Tile-Server installing HowTo]<br />
<br />
<br />
<br />
[[Kategorie:Develop]]</div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:Guidelines&diff=3473OpenSeaMap-dev:Guidelines2015-05-03T13:15:21Z<p>MartinOver: Die Seite wurde neu angelegt: „tbd“</p>
<hr />
<div>tbd</div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:Portal&diff=3472OpenSeaMap-dev:Portal2015-05-03T13:15:10Z<p>MartinOver: /* OSeaM-Wiki Dev-Portal */</p>
<hr />
<div>{|<br />
| <br />
{| class="wikitable"<br />
| Liebe Entwickler,<br />
<br />
Willkommen auf dem OpenSeaMap-Entwicklerportal !<br />
<br />
Auf eine tolle Zusammenarbeit freuen sich <br><br />
Markus und Olaf <br />
|}<br />
| &nbsp; &nbsp; &nbsp; <br />
|<br />
{| class="wikitable"<br />
| Dear Developpers, <br />
<br />
Welcome to the OpenSeaMap Developer Portal !<br />
<br />
Looking forward to great cooperation, <br><br />
Markus und Olaf <br />
|}<br />
|}<br />
<br />
<br />
__TOC__<br />
<br />
== Organisationsplattformen ==<br />
{{de:organisation}}<br />
<br />
== OSeaM-Wiki Dev-Portal ==<br />
: [[OpenSeaMap-dev:Portal|Dev-Portal]]<br />
: [[de:Develop|Dev-Hauptseite]]<br />
: [[OpenSeaMap-dev:Guidelines|Dev-Guidelines]]<br />
: [[OpenSeaMap-dev:Projekte|Our Projects]]<br />
:: [[OpenSeaMap-dev:Watersport-Wiki|Watersport-Wiki]]<br />
<br />
:: [[OpenSeaMap-dev:Renderer|Renderer]]<br />
<br />
:: Shallow Water <br />
::: [[OpenSeaMap-dev:User_login|User-Login]]<br />
::: [[Depth_Data|Depth data]]<br />
::: [[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|Crowd Sourced Depth Data]]<br />
::: [[OpenSeaMap-dev:De:Depth_raw_data|De:Depth raw data]]<br />
::: [[OpenSeaMap-dev:De:Depth_meta_data|De:Depth meta data]]<br />
::: [[OpenSeaMap-dev:De:Depth_data_processing|De:Depth data processing]]<br />
::: [[Shipnetwork|Collecting data from the ship's network]]<br />
::: [[OpenSeaMap-dev:HW-logger/specification|HW-Logger]]<br />
::: [http://seesea.sourceforge.net/datalogger/index.html SW-Logger]<br />
<br />
:: Editors<br />
::: [[OpenSeaMap-dev:Online-Editor|Online-Editor]] <br />
::: [[de:Online-Editor|Online-Editor HowTo]] - [[Online-Editor|(englisch)]]<br />
::: [[OpenSeaMap-dev:SMED-2|JOSM plugin SMED2]]<br />
<br />
:: [[OpenSeaMap-dev:Harbour|Harbour]]<br />
::: [[OpenSeaMap-dev:Harbour-DB|Harbour-DB]]<br />
::: [[OpenSeaMap-dev:Hafen-DB|Hafen-DB alt]]<br />
::: [[OpenSeaMap-dev:Hafen-Editor|Harbour-Editor]]<br />
<br />
:: Dev-ToDo's<br />
::: [[de:OpenSeaMap_in_Website|OpenSeaMap in Website einbinden]]<br />
::: [[OpenSeaMap-dev:Online-Editor|Online-Editor-dev]]<br />
::: [[OpenSeaMap-dev:Renderer|Renderer-dev]]<br />
::: [[OpenSeaMap_in_Website|How to include OpenSeaMap in your website]]<br />
::: [[Server|Server]]<br />
<br />
== OSM-Wiki ==<br />
<br />
; Projekte<br />
: [http://wiki.openstreetmap.org/wiki/DE:Seekarte Ursprüngliche Projektseite "Seekarte"]<br />
: [http://wiki.openstreetmap.org/wiki/DE:Seekarte Projektseite "für Segler"] - [http://wiki.openstreetmap.org/wiki/Marine_Mapping (english)]<br />
: [http://wiki.openstreetmap.org/wiki/DE:Meeresprofil Bathimetrie] - [http://wiki.openstreetmap.org/wiki/Bathimetry (english)]<br />
: [http://wiki.openstreetmap.org/wiki/DE:Water_Depth Wassertiefe]<br />
: [http://wiki.openstreetmap.org/wiki/DE:AIS AIS] - [http://wiki.openstreetmap.org/wiki/AIS (english)]<br />
: [http://wiki.openstreetmap.org/wiki/DE:Seamap-Editor Projektseite "SeaMap-Editor"] - [http://wiki.openstreetmap.org/wiki/DE:Seamap-Editor (english)]<br />
: [http://wiki.openstreetmap.org/wiki/Openseamap/DE:Seamap_database Meta-DB] - [http://wiki.openstreetmap.org/wiki/Openseamap/Seamap_database (english)]<br />
<br />
; Grundlagen<br />
: [http://wiki.openstreetmap.org/wiki/DE:Lowest_Astronomical_Tide LAT] - [http://wiki.openstreetmap.org/wiki/Lowest_Astronomical_Tide (english)]<br />
: [http://wiki.openstreetmap.org/wiki/DE:Genauigkeit_von_Koordinaten Genauigkeit von Koordinaten]<br />
: [http://wiki.openstreetmap.org/wiki/DE:Genauigkeit_von_GPS-Daten Genauigkeit von GPS-Daten]<br />
: [http://wiki.openstreetmap.org/wiki/Zoom_levels Zoomlevel]<br />
: [http://wiki.openstreetmap.org/wiki/DE:Altitude Höhe] - [http://wiki.openstreetmap.org/wiki/Altitude (englisch)]<br />
<br />
; Daten<br />
: [http://wiki.openstreetmap.org/wiki/OpenSeaMap/Seamark_Tag_Values Seamark Tag Values]<br />
: [http://wiki.openstreetmap.org/wiki/OpenSeaMap/Seamark_Objects Seamark Objects]<br />
: [http://wiki.openstreetmap.org/wiki/OpenSeaMap/Seamark_Attributes Seamark Attributes]<br />
: [http://wiki.openstreetmap.org/wiki/OpenSeaMap/INT-1_Cross_Reference INT-1 Cross Reference]<br />
: and Sub-Pages.<br />
<br />
: [http://wiki.openstreetmap.org/wiki/de:Beacon Boye] - [http://wiki.openstreetmap.org/wiki/Buoy (english)]<br />
: [http://wiki.openstreetmap.org/wiki/de:Beacon Bake] - [http://wiki.openstreetmap.org/wiki/Beacon (english)]<br />
: [http://wiki.openstreetmap.org/wiki/de:Leuchtfeuer Leuchtfeuer] - [http://wiki.openstreetmap.org/wiki/Lighthouse (english)]<br />
: [http://wiki.openstreetmap.org/wiki/DE:Hafen Hafen] - [http://wiki.openstreetmap.org/wiki/Harbour (english)]<br />
: [http://wiki.openstreetmap.org/wiki/OpenSeaMap/Buoy_Data_Model Datenmodell Boye]<br />
: [http://wiki.openstreetmap.org/wiki/OpenSeaMap/Beacon_Data_Model Datenmodell Bake]<br />
: [http://wiki.openstreetmap.org/wiki/OpenSeaMap/Lights_Data_Model Datenmodell Leuchtfeuer]<br />
<br />
== Qualitätsmanagement ==<br />
: [http://seamark.bplaced.net/lights/ Leuchtfeuer mit falscher Position]<br />
: [http://seamark.bplaced.net/harbours/ doppelte Häfen und Marinas]<br />
: [[OpenSeaMap-dev:Harbour-Duplicates|Harbour Duplicates]]<br />
<br />
==Mailingliste==<br />
[https://lists.sourceforge.net/lists/listinfo/openseamap-develop openseamap-develop]{{English}} - [http://sourceforge.net/mailarchive/forum.php?forum_name=openseamap-develop Archiv]<br />
<br />
== Forum ==<br />
[http://forum.openseamap.org/ OpenSeaMap-forum]<br />
<br />
very old: [http://sourceforge.net/projects/openseamap/forums/forum/992659 openseamap-develop-de]<br />
<br />
==Fehler berichten==<br />
Bitte verwende den [http://sourceforge.net/tracker/?group_id=273418&atid=1162128 SourceForge Tracker] {{English}} für Problemberichte.<br />
<br />
== Wikipedia ==<br />
Viele hervorragende Artikel zu nautischen Themen sind in Wikipedia zu finden. Einige wurden von uns geschrieben. Gute Informationen findet man auch in der [[wikipedia:en:Main_Page|englischen Wikipedia]] (im deutschen Artikel links in der Menüleiste auf "english" klicken). Es macht Sinn, möglichst viel nautisches Wissen für alle Menschen direkt in Wikipedia verfügbar zu machen. Bitte schreibe also zu allgemein interessierenden Themen, auch wenn es wissenschaftlich ist, möglichst direkt in Wikipedia. Zu fast jedem nautischen Begriff gibt es bereits einen Artikel, den man vertiefen und erweitern kann.<br />
<br />
Wikipedia-Artikel können direkt im OSM- oder OSeaM-Wiki verlinkt werden:<br />
<pre><br />
[[wikipedia:de:Artikelname|anzuzeigender Text]] (deutsch)<br />
[[wikipedia:en:Artikelname|anzuzeigender Text]] (englisch)<br />
</pre><br />
<br />
: [[wikipedia:de:OpenSeaMap|OpenSeaMap]]<br />
: [[wikipedia:de:Pegel_(Wasserstandsmessung)|Pegel]]<br />
: [[wikipedia:de:Normalhöhennull|Normalhöhennull]]<br />
: [[wikipedia:de:Höhe (Geodäsie)|Höhe]]<br />
: [[wikipedia:de:Seekartennull|Seekartennull]]<br />
: [[wikipedia:de:World Geodetic System 1984|WGS-84]]<br />
: [[wikipedia:de:Automatic_Identification_System|Automatic Identification System (AIS)]]<br />
: [[wikipedia:de:Mann über Bord|Mann über Bord]]<br />
<br />
== OSeaM-Wiki ==<br />
[http://wiki.openstreetmap.org/wiki/DE:OpenSeaMap Bitte alle Beiträge zu allgemeinen Themen, oder solchen die auch andere OSMer interessieren direkt ins OSM-Wiki schreiben]. <br />
<br />
Dieses Wiki ist nur für '''Hilfetexte''' und '''HowTo'''. <br><br />
Bitte alle Beiträge in '''Deutsch''' und '''Englisch''' verfassen.<br />
<br />
: [[de:Hauptseite|Hauptseite]] - [[Hauptseite|(english)]]<br />
:: [[de:Editor|Editor]] - [[Editor|(english)]]<br />
::: [[de:Online-Editor|Online-Editor]] - [[Online-Editor|(english)]]<br />
:::: [[de:Online-Editor/Window|Fenster und Funktionen]] - [[Online-Editor/Window|(english)]]<br />
:::: [[de:Online-Editor/edit|Editieren (neu, ändern, verschieben, löschen)]] - [[Online-Editor/edit|(english)]]<br />
:::: [[de:Online-Editor/Seamark|Seezeichen eingeben]] - [[Online-Editor/Seamark|(english)]]<br />
:::: [[de:Online-Editor/Harbour|Häfen eingeben]] - [[Online-Editor/Harbour|(english)]]<br />
::: [[de:JOSM_and_Plugin|JOSM und Plugin]] - [[JOSM_and_Plugin|(english)]]<br />
:::: [[de:JOSM_and_Plugin/Window|Fenster]] - [[JOSM_and_Plugin/Window|(english)]]<br />
:::: [[de:JOSM_and_Plugin/edit|Editieren]] - [[JOSM_and_Plugin/edit|english]]<br />
:::: [[de:JOSM_and_Plugin/Seamark|Plugin]] - [[JOSM_and_Plugin/Seamark|(english)]]<br />
:::: [[de:JOSM_and_Plugin/Harbour|Hafen]] - [[JOSM_and_Plugin/Harbour|(english)]]<br />
:: [[de:NMEA-Daten_hochladen|Wassertiefen]] - [[NMEA-Daten_hochladen|(english)]]<br />
::: [[de:Software_logger|Software-Logger]] - [[Software_logger|(english)]]<br />
::: [[de:Hardware_logger|Hardware-Logger]] - [[Hardware_logger|(english)]]<br />
:: [[de:OruxMaps|Android-App]] - [[OruxMaps|(english)]]<br />
:: [[de:OpenSeaMap_in_Website|OpenSeaMap in Website]] - [[OpenSeaMap_in_Website|(english)]]<br />
:: [http://git.bezono.org/?p=openseamap/dfa/docs_rendering.git;a=blob_plain;f=openstreetmap/install_de.txt;hb=HEAD Tile-Server installing HowTo]<br />
<br />
<br />
<br />
[[Kategorie:Develop]]</div>MartinOverhttps://wiki.openseamap.org/index.php?title=Guidelines&diff=3471Guidelines2015-05-03T13:13:43Z<p>MartinOver: Die Seite wurde neu angelegt: „tbd“</p>
<hr />
<div>tbd</div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:Entwicklerwochenende_2015-04&diff=3445OpenSeaMap-dev:Entwicklerwochenende 2015-042015-04-12T19:25:20Z<p>MartinOver: /* Themenvorschläge */</p>
<hr />
<div>[[Datei:Konzept OpenSeaMap.jpg|thumb|Konzept von OpenSeaMap]]<br />
<br />
Planung zum 10. Entwicklerwochenende am '''24.-26. 4. 2015'''<br />
<br />
<br />
== Anmeldung ==<br />
[mailto:liste12A45q7@gmx.de?subject=9.%20Entwicklerwochenende%20-%20Anmeldung Anmeldung bitte per Mail] <br>oder besser: gleich hier in der Liste:<br />
{| class="wikitable sortable"<br />
! Nr || Do || Fr || Sa || So || Mo || wer || von wo || Übernachtung || class="unsortable" | Bemerkungen<br />
|-<br />
| 1 || 19:00 || x || x || x || 16:00 || [[Benutzer:Markus|Markus]] || - || - || Orga<br />
|-<br />
| 2 || 19:00 || x || x || x || 07:00 || Cornelia || - || - || Tutorials, Artikel, Website, Support<br />
|-<br />
| 3 || || x ||x || x || || Alexej Humbach|| Aachen (DE) || bei Markus || Karten, Tiden, Wassertiefen<br />
|-<br />
| 4 || || || || || || Joachim Bobrich || Frankfurt/Main (DE) || || Echo, Logger, Anwendungen<br />
|-<br />
| 5 || || || x 9:00|| x || || Martin Over || Köln (DE) || Landgasthof || Wassertiefen<br />
|-<br />
| 6 || || 19:00 || x || x || || Wolfgang Schildbach || Nürnberg (DE) || - || Daten-Kompression<br />
|-<br />
| 7 || || || || || || Wolfgang Sommers || Erkelenz (DE) || || AT5-Karten<br />
|-<br />
| 8 || || || 10:00 || 19:00 || || Marek Skleciak || Erlangen (DE) || - || DEM (Doktorandenstelle), 3D<br />
|-<br />
| 9 || || || || || || Andreas Merz || Erlangen (DE) || - || Wassertiefen, ...<br />
|-<br />
| 10 || || || || || || Herbert Oppmann || Nürnberg (DE) || - || AT5<br />
|-<br />
| 11 || || || || || || ? || ? || || <br />
<!-- |-<br />
| 5 || || || || || || Jens Kübler || Karlsruhe (DE) || || Wassertiefen<br />
|-<br />
| 6 || 19:00 || x || x || x || || Werner König || Velbert (DE) ||bei Markus || WinNav<br />
|-<br />
| 7 || || 19:00 || || || || Hans-Jürgen Beie || Nürnberg (DE) || - || KNF, Typo3<br />
|-<br />
| 8 || || || x || || || Reiner Schmalzl || Nürnberg (DE) || - || Datenschutz, Typo3<br />
|-<br />
| 10 || || 12:00 || x || || || Victor Klein || Essen (DE) || bei Lang || offline Karten Android<br />
|-<br />
| 11 || || || x || || || Thorsten Baur || Bamberg (DE) || || Website, Stategie<br />
|-<br />
| 12 || || || x || || || Thomas Waldecker || München (DE) || bei Markus || Whitewater, Offline chart<br />
|-<br />
| 14 || || 23:00 || x || x || || Niko Ehrenfeuchter || Freiburg (DE) || bei Markus || Server, GitHub<br />
|<br />
| 4 || || || || || || Hakan Tandogan || München (DE) || || <br />
|-<br />
| 5 || || || x || || || Inger Holndonner || Nürnberg (DE) || nein || Tauchen <br />
|-<br />
| 9 || || || || || || Werner ? || || || <br />
|-<br />
| 10 || || || || || || Claas Kähler || Münster (DE) || || <br />
--><br />
|-<br />
| .. || || || || || || || || || <br />
|}<br />
<br />
== Programm ==<br />
Das Programm werden wir je nach anwesenden Personen, Interessen und Prioritäten gestalten <br>und möglichst hier vorher gemeinsam planen. <br />
<br />
Hacking: Gut fände ich, wenn wir wie letztes Mal wieder Zeit für Coding, Scripting, Hacking verwenden.<br />
<br />
Schwerpunkt wird sein:<br />
* Workflow im Entwickler-Team <br>wie können wir unterstützend, effizient, lustvoll, produktiv zusammenarbeiten <br>wie gestalten wir Planung, Doku, Kommunikation<br />
* Servers<br />
* Water depths<br />
* Charts for Android, iOS, Garmin, Lowrance, B&G, Simrad. <br />
* Vector chart (AT5, OsmAnd, S-57)<br />
* ...<br />
<br />
Und natürlich werden wir auch für alle anderen wichtigen Themen Zeit haben: <br>Visionen, Ideen, Pläne zu Apps, Community, Qualität, Server, Tidenrechner, Hafendatenbank, Wassersportwiki, Bericht von "boot", etc, etc.<br />
<br />
; Struktur<br />
: Die Idee ist, dass jeder "Maintainer" bzw. jedes Team eines Projektes ein Zeitfenster hat, <br>um die zentralen Fragen mit allen anderen Entwicklern zu diskutieren und Lösungen bzw Lösungswege zu finden.<br />
: Ergebnis soll jeweils eine ToDo-Liste sein.<br />
: Bewährt hat sich beim letzten Mal, das Treffen auch als Hack-Weekend zu gestalten.<br />
: Und natürlich wie immer Zeit für's Kennenlernen und Fachsimpeln!<br />
<br />
{| class="wikitable"<br />
! Zeit || Thema || Wer || Bemerkungen<br />
|-<br />
| Do || Core-Dev-Meeting || || open for everybody<br />
|-<br />
| Fr || Pre-Dev-Meeting || || open for everybody<br />
|-<br />
| Fr 19:00 || <small>Abendessen</small> || <small>bei Markus</small> || (bitte anmelden)<br />
|-<br />
| Sa 08:00 || <small>Frühstück</small> || <small>Gäste von Markus</small> || wer mag kann gern dazukommen (bitte anmelden)<br />
|-<br />
| '''Sa 09:00''' || Intro || Markus || Rückblick, Ausblick<br />
|-<br />
| Sa 09:30 || Vorstellungsrunde || alle || vermutlich beginnen wir gleich mit der Arbeit, da die Meisten bereits Do/Fr kommen <br />
|-<br />
| Sa 12:00 || || || <br />
|-<br />
| Sa 14:00 || <small>Mittagspause</small> || || "kaltes Buffet"<br />
|-<br />
| Sa 15:00 || || || <br />
|-<br />
| Sa 17:00 || || || <br />
|-<br />
| Sa 19:00 || <small>Abendessen</small> || || Landgasthof<br />
|-<br />
| Sa 20:00 || || || <br />
|-<br />
| So 08:00 || <small>Frühstück</small> || <small>Gäste von Markus</small> || wer mag kann gern dazukommen (bitte anmelden)<br />
|-<br />
| '''So 09:00''' || || || <br />
|-<br />
| So 12:00 || || || <br />
|-<br />
| So 14:00 || || || <br />
|-<br />
| '''So 16:00''' || Ende des Hauptteils || || <br />
|-<br />
| So 18:00 || || || <br />
|-<br />
| So 20:00 || || || <br />
|-<br />
| So 22:00 || || || <br />
|-<br />
| Mo 08:00 || Arbeits-Frühstück || || Rückblick, Planung<br />
|-<br />
| Mo 10:00 || || || Umsetzung? (je nachdem wer noch da ist)<br />
|}<br />
<br />
== Themenvorschläge ==<br />
{| class="wikitable"<br />
! Thema || Prio || wer || Zeit || wer wird gewünscht || Bemerkungen<br />
|-<br />
| Standortbestimmung OpenSeaMap || 1 || Markus || Sa || alle || <br />
|-<br />
| Quo Vadis OpenSeaMap || 1 || Markus || Sa || alle || <br />
|-<br />
| Kooperation, Kommunikation, Doku || 1 || Markus || Sa || alle || wie Martin? Das wäre ja identisch mit "Entscheidungsstrukturen & Kommunikation". Ich könnte einen kurze Einführung in das Thema Strukturen von "Offenen Projekten" geben. Um eine zu allgemeine Diskussion zu vermeiden, würde ich dann gerne anhand eines konkreten "Sub-Projektes" durchspielen wollen wie wir uns den Workflow wünschen würden. <br />
|-<br />
| Visualisierung von Wassertiefen || || Martin || Sa/bis So Mittag || || <br />
|-<br />
| Entscheidungsstrukturen & Kommunikation || || Martin || Sa/bis So Mittag || || <br />
|-<br />
| Serverstruktur optimieren || || Niko? || || Alexej, Jens, Matthias, KNF || <br />
|-<br />
<!--<br />
| Redaktionsplan Facebook, Website-Gestaltung, Marketing-Konzept || || Cornelia, Thorsten || Sa 9-14 || Markus für Rückfragen || <br />
|-<br />
| Verpflichtung auf Datenschutz BDSG §5, für alle Admins || || Reiner || Sa 15' || alle Admins || <br />
|-<br />
| Serverstruktur aufzeichnen || || Markus || 15' || Alexej, Jens, Matthias, Niko || <br />
|-<br />
| Logger-Vertrieb: 100€ statt 35€, 100 v. 500 verkauft <br>Ziel: Strategie entwickeln || 1 || Markus || 30' || Hans-Jürgen, Wolfgang, Alexej || <br />
|-<br />
| Video/Screencast-Tutorial JOSM || || Cornelia || || Wolfgang || <br />
|-<br />
| WPI-Häfen wieder auf Karte verlinken || || Markus || 30' || Matthias || <br />
|-<br />
| Gespräch mit dem Vorsitzenden des KNF || || Hans-Jürgen || Fr 19, 30' || Plenum || <br />
|-<br />
--><br />
| .. || || || || || <br />
|}<br />
<br />
== Unterkunft ==<br />
<br />
; privat bei Markus<br />
: Bei mir können 3..4 Gäste gratis übernachten. Gern bereits ab Donnerstag bzw bis Montag.<br />
:{| class="wikitable"<br />
! wer || Do || Fr || Sa || So<br />
|-<br />
| Alexej || || x || x || x <br />
|-<br />
| .. || || || || <br />
|}<br />
<br />
; Landgasthof "Lang"<br />
: 5 Minuten zu Fuss, beim Bahnhof Simmelsdorf, [http://map.openseamap.org/?zoom=16&mlat=49.59830&mlon=11.34050&mtext=%3Cb%3ELandgasthaus%20Lang%3C%2Fb%3E%0ABahnhofstra%C3%9Fe%209%0A91245%20Simmelsdorf%0A%2B49%209155%20237&layers=BFTFFFTFFTF0FFFFFFTT Karte]<br />
: EZ Ü/F: ab 33 € (28,20 € ohne Frühstück)<br />
: Bahnhofstraße 9, 91245 Simmelsdorf, +49 9155 237, [http://www.landgasthaus-lang.de/ Landgasthof-Lang.de]<br />
<br />
; Hotel "Igelwirt"<br />
: 10 Minuten mit dem Auto, [http://map.openseamap.org/map/?zoom=14&mlat=49.58696&mlon=11.37649&mtext=%3Cb%3EIgelwirt%3C%2Fb%3E%0AIgelweg%206%0A91220%20Schnaittach-Osternohe%0A%2B49%209153%204060&layers=BFTFFFTFFTF0FFFFFFTT Karte]<br />
: EZ Ü/F: ab 64 € (59 € ohne Frühstück )<br />
: Igelweg 6, 91220 Schnaittach-Osternohe, +49 9153 4060, [http://www.igelwirt.de/ Igelwirt.de]<br />
<br />
; Gasthof Schuster<br />
: 3 Minuten mit dem Auto, 20 Minuten mit dem Fahrrad [http://map.openseamap.org/map/?zoom=14&mlat=49.56896&mlon=11.33958&mtext=%3Cb%3EGasthof%20Schuster%3C%2Fb%3E%0AKirchenweg%206%0A91220%20Hedersdorf%0A%2B49%209153%201288%20&layers=BTTFFFTFFTF0FFFFFFTT Karte]<br />
: EZ Ü/F 34 € (30 € ohne Frühstück)<br />
: Kirchenweg 6, 91220 Hedersdorf, +49 9153 1288<br />
<br />
== Verpflegung ==<br />
Schön wäre, wenn die Tagesgäste oder "Heimschläfer" Lust hätten, etwas zum Essen zu organisieren. Beispielsweise das Frühstück mitbringen, etwas zum "kalten Buffet", oder Pizza, oder etwas zum Kaffee, oder einen Salat...<br />
Bitte trage hier ein, wenn Du etwas mitbringen willst. Frage bevor Du kommst kurz telefonisch wieviele da sind, oder vielleicht magst Du Pizza-Bestellungen entgegennehmen und die Pizzen abholen und mitbringen?<br />
<br />
Getränke und Tee/Kaffee sind im Haus. Ebenso Aufbackbrötchen und Nudeln für alle Fälle.<br />
<br />
{| class="wikitable"<br />
! style="width: 6em" | wer organisiert || Do || Do Abend || Fr Früh || Fr Mitt || Fr Abend || Sa Früh || Sa Mitt || Sa nachm || Sa Abend || So Früh || So Mitt || So nachm || So Abend || Mo Früh || Bemerkungen<br />
|-<br />
| Markus || X || || || || || || || || || || || || || || Food for all <br />
|-<br />
| Markus || || X || || || || || || || || || || || || || Abendessen bei mir für alle die angemeldet sind<br />
|-<br />
| Markus || || || X || || || X || || || || X || || || || X || Frühstück bei mir für alle die angemeldet sind<br />
|-<br />
| Landgasthof || || || || || X || || || || X || || || || X || || <br />
|-<br />
| .. || || || || || || || || || || || || || || || <br />
|}<br />
<br />
{| class="wikitable"<br />
! class="unsortable" style="width: 6em" | wer isst mit || Do Abend || Fr Früh || Fr Abend || Sa Früh || Sa Mitt || Sa nachm || Sa Abend || So Früh || So Mitt || So nachm || So Abend || Mo Früh || class="unsortable" | Bemerkungen<br />
|-<br />
| Markus || X || X || X || X || X || X || X || X || X || X || X || X || <br />
|-<br />
| Cornelia || || X || X || X || X || X || X || X || X || X || X || X || vegetarisch<br />
|-<br />
| Martin || || || || || X || X || X || X || X || || || || vegetarisch<br />
|-<br />
| .. || || || || || || || || || || || || || <br />
|}<br />
<br />
== Fahrgemeinschaft ==<br />
; Suche<br />
{| class="wikitable"<br />
! wer || ab wo || Abfahrt || Plätze || Bemerkungen<br />
|-<br />
| .. || || || || <br />
|}<br />
<br />
; Biete<br />
{| class="wikitable"<br />
! wer || ab wo || Abfahrt || Plätze || Bemerkungen<br />
|-<br />
| .. || || || || <br />
|}<br />
<br />
Bitte nehmt direkt miteinander Kontakt auf.<br />
<br />
== Zusammenfassung / ToDo ==<br />
* [[OpenSeaMap-dev:10._Entwicklerwochenende/Bericht | Bericht / ToDo]]<br />
* [[OpenSeaMap-dev:9._Entwicklerwochenende/Bericht | Bericht / ToDo Herbst 2015]]<br />
* [[OpenSeaMap-dev:8._Entwicklerwochenende/Bericht | Bericht / ToDo Früjahr 2014]]<br />
* [[OpenSeaMap-dev:7._Entwicklerwochenende/Bericht | Bericht / ToDo Herbst 2013]]<br />
* [[OpenSeaMap-dev:6._Entwicklerwochenende/Bericht | Bericht / ToDo Frühjahr 2013]]</div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:Entwicklerwochenende_2015-04&diff=3444OpenSeaMap-dev:Entwicklerwochenende 2015-042015-04-12T19:11:03Z<p>MartinOver: /* Anmeldung */</p>
<hr />
<div>[[Datei:Konzept OpenSeaMap.jpg|thumb|Konzept von OpenSeaMap]]<br />
<br />
Planung zum 10. Entwicklerwochenende am '''24.-26. 4. 2015'''<br />
<br />
<br />
== Anmeldung ==<br />
[mailto:liste12A45q7@gmx.de?subject=9.%20Entwicklerwochenende%20-%20Anmeldung Anmeldung bitte per Mail] <br>oder besser: gleich hier in der Liste:<br />
{| class="wikitable sortable"<br />
! Nr || Do || Fr || Sa || So || Mo || wer || von wo || Übernachtung || class="unsortable" | Bemerkungen<br />
|-<br />
| 1 || 19:00 || x || x || x || 16:00 || [[Benutzer:Markus|Markus]] || - || - || Orga<br />
|-<br />
| 2 || 19:00 || x || x || x || 07:00 || Cornelia || - || - || Tutorials, Artikel, Website, Support<br />
|-<br />
| 3 || || x ||x || x || || Alexej Humbach|| Aachen (DE) || bei Markus || Karten, Tiden, Wassertiefen<br />
|-<br />
| 4 || || || || || || Joachim Bobrich || Frankfurt/Main (DE) || || Echo, Logger, Anwendungen<br />
|-<br />
| 5 || || || x 9:00|| x || || Martin Over || Köln (DE) || Landgasthof || Wassertiefen<br />
|-<br />
| 6 || || 19:00 || x || x || || Wolfgang Schildbach || Nürnberg (DE) || - || Daten-Kompression<br />
|-<br />
| 7 || || || || || || Wolfgang Sommers || Erkelenz (DE) || || AT5-Karten<br />
|-<br />
| 8 || || || 10:00 || 19:00 || || Marek Skleciak || Erlangen (DE) || - || DEM (Doktorandenstelle), 3D<br />
|-<br />
| 9 || || || || || || Andreas Merz || Erlangen (DE) || - || Wassertiefen, ...<br />
|-<br />
| 10 || || || || || || Herbert Oppmann || Nürnberg (DE) || - || AT5<br />
|-<br />
| 11 || || || || || || ? || ? || || <br />
<!-- |-<br />
| 5 || || || || || || Jens Kübler || Karlsruhe (DE) || || Wassertiefen<br />
|-<br />
| 6 || 19:00 || x || x || x || || Werner König || Velbert (DE) ||bei Markus || WinNav<br />
|-<br />
| 7 || || 19:00 || || || || Hans-Jürgen Beie || Nürnberg (DE) || - || KNF, Typo3<br />
|-<br />
| 8 || || || x || || || Reiner Schmalzl || Nürnberg (DE) || - || Datenschutz, Typo3<br />
|-<br />
| 10 || || 12:00 || x || || || Victor Klein || Essen (DE) || bei Lang || offline Karten Android<br />
|-<br />
| 11 || || || x || || || Thorsten Baur || Bamberg (DE) || || Website, Stategie<br />
|-<br />
| 12 || || || x || || || Thomas Waldecker || München (DE) || bei Markus || Whitewater, Offline chart<br />
|-<br />
| 14 || || 23:00 || x || x || || Niko Ehrenfeuchter || Freiburg (DE) || bei Markus || Server, GitHub<br />
|<br />
| 4 || || || || || || Hakan Tandogan || München (DE) || || <br />
|-<br />
| 5 || || || x || || || Inger Holndonner || Nürnberg (DE) || nein || Tauchen <br />
|-<br />
| 9 || || || || || || Werner ? || || || <br />
|-<br />
| 10 || || || || || || Claas Kähler || Münster (DE) || || <br />
--><br />
|-<br />
| .. || || || || || || || || || <br />
|}<br />
<br />
== Programm ==<br />
Das Programm werden wir je nach anwesenden Personen, Interessen und Prioritäten gestalten <br>und möglichst hier vorher gemeinsam planen. <br />
<br />
Hacking: Gut fände ich, wenn wir wie letztes Mal wieder Zeit für Coding, Scripting, Hacking verwenden.<br />
<br />
Schwerpunkt wird sein:<br />
* Workflow im Entwickler-Team <br>wie können wir unterstützend, effizient, lustvoll, produktiv zusammenarbeiten <br>wie gestalten wir Planung, Doku, Kommunikation<br />
* Servers<br />
* Water depths<br />
* Charts for Android, iOS, Garmin, Lowrance, B&G, Simrad. <br />
* Vector chart (AT5, OsmAnd, S-57)<br />
* ...<br />
<br />
Und natürlich werden wir auch für alle anderen wichtigen Themen Zeit haben: <br>Visionen, Ideen, Pläne zu Apps, Community, Qualität, Server, Tidenrechner, Hafendatenbank, Wassersportwiki, Bericht von "boot", etc, etc.<br />
<br />
; Struktur<br />
: Die Idee ist, dass jeder "Maintainer" bzw. jedes Team eines Projektes ein Zeitfenster hat, <br>um die zentralen Fragen mit allen anderen Entwicklern zu diskutieren und Lösungen bzw Lösungswege zu finden.<br />
: Ergebnis soll jeweils eine ToDo-Liste sein.<br />
: Bewährt hat sich beim letzten Mal, das Treffen auch als Hack-Weekend zu gestalten.<br />
: Und natürlich wie immer Zeit für's Kennenlernen und Fachsimpeln!<br />
<br />
{| class="wikitable"<br />
! Zeit || Thema || Wer || Bemerkungen<br />
|-<br />
| Do || Core-Dev-Meeting || || open for everybody<br />
|-<br />
| Fr || Pre-Dev-Meeting || || open for everybody<br />
|-<br />
| Fr 19:00 || <small>Abendessen</small> || <small>bei Markus</small> || (bitte anmelden)<br />
|-<br />
| Sa 08:00 || <small>Frühstück</small> || <small>Gäste von Markus</small> || wer mag kann gern dazukommen (bitte anmelden)<br />
|-<br />
| '''Sa 09:00''' || Intro || Markus || Rückblick, Ausblick<br />
|-<br />
| Sa 09:30 || Vorstellungsrunde || alle || vermutlich beginnen wir gleich mit der Arbeit, da die Meisten bereits Do/Fr kommen <br />
|-<br />
| Sa 12:00 || || || <br />
|-<br />
| Sa 14:00 || <small>Mittagspause</small> || || "kaltes Buffet"<br />
|-<br />
| Sa 15:00 || || || <br />
|-<br />
| Sa 17:00 || || || <br />
|-<br />
| Sa 19:00 || <small>Abendessen</small> || || Landgasthof<br />
|-<br />
| Sa 20:00 || || || <br />
|-<br />
| So 08:00 || <small>Frühstück</small> || <small>Gäste von Markus</small> || wer mag kann gern dazukommen (bitte anmelden)<br />
|-<br />
| '''So 09:00''' || || || <br />
|-<br />
| So 12:00 || || || <br />
|-<br />
| So 14:00 || || || <br />
|-<br />
| '''So 16:00''' || Ende des Hauptteils || || <br />
|-<br />
| So 18:00 || || || <br />
|-<br />
| So 20:00 || || || <br />
|-<br />
| So 22:00 || || || <br />
|-<br />
| Mo 08:00 || Arbeits-Frühstück || || Rückblick, Planung<br />
|-<br />
| Mo 10:00 || || || Umsetzung? (je nachdem wer noch da ist)<br />
|}<br />
<br />
== Themenvorschläge ==<br />
{| class="wikitable"<br />
! Thema || Prio || wer || Zeit || wer wird gewünscht || Bemerkungen<br />
|-<br />
| Standortbestimmung OpenSeaMap || 1 || Markus || Sa || alle || <br />
|-<br />
| Quo Vadis OpenSeaMap || 1 || Markus || Sa || alle || <br />
|-<br />
| Kooperation, Kommunikation, Doku || 1 || Markus || Sa || alle || wie Martin?<br />
|-<br />
| Visualisierung von Wassertiefen || || Martin || Sa/bis So Mittag || || <br />
|-<br />
| Entscheidungsstrukturen & Kommunikation || || Martin || Sa/bis So Mittag || || <br />
|-<br />
| Serverstruktur optimieren || || Niko? || || Alexej, Jens, Matthias, KNF || <br />
|-<br />
<!--<br />
| Redaktionsplan Facebook, Website-Gestaltung, Marketing-Konzept || || Cornelia, Thorsten || Sa 9-14 || Markus für Rückfragen || <br />
|-<br />
| Verpflichtung auf Datenschutz BDSG §5, für alle Admins || || Reiner || Sa 15' || alle Admins || <br />
|-<br />
| Serverstruktur aufzeichnen || || Markus || 15' || Alexej, Jens, Matthias, Niko || <br />
|-<br />
| Logger-Vertrieb: 100€ statt 35€, 100 v. 500 verkauft <br>Ziel: Strategie entwickeln || 1 || Markus || 30' || Hans-Jürgen, Wolfgang, Alexej || <br />
|-<br />
| Video/Screencast-Tutorial JOSM || || Cornelia || || Wolfgang || <br />
|-<br />
| WPI-Häfen wieder auf Karte verlinken || || Markus || 30' || Matthias || <br />
|-<br />
| Gespräch mit dem Vorsitzenden des KNF || || Hans-Jürgen || Fr 19, 30' || Plenum || <br />
|-<br />
--><br />
| .. || || || || || <br />
|}<br />
<br />
== Unterkunft ==<br />
<br />
; privat bei Markus<br />
: Bei mir können 3..4 Gäste gratis übernachten. Gern bereits ab Donnerstag bzw bis Montag.<br />
:{| class="wikitable"<br />
! wer || Do || Fr || Sa || So<br />
|-<br />
| Alexej || || x || x || x <br />
|-<br />
| .. || || || || <br />
|}<br />
<br />
; Landgasthof "Lang"<br />
: 5 Minuten zu Fuss, beim Bahnhof Simmelsdorf, [http://map.openseamap.org/?zoom=16&mlat=49.59830&mlon=11.34050&mtext=%3Cb%3ELandgasthaus%20Lang%3C%2Fb%3E%0ABahnhofstra%C3%9Fe%209%0A91245%20Simmelsdorf%0A%2B49%209155%20237&layers=BFTFFFTFFTF0FFFFFFTT Karte]<br />
: EZ Ü/F: ab 33 € (28,20 € ohne Frühstück)<br />
: Bahnhofstraße 9, 91245 Simmelsdorf, +49 9155 237, [http://www.landgasthaus-lang.de/ Landgasthof-Lang.de]<br />
<br />
; Hotel "Igelwirt"<br />
: 10 Minuten mit dem Auto, [http://map.openseamap.org/map/?zoom=14&mlat=49.58696&mlon=11.37649&mtext=%3Cb%3EIgelwirt%3C%2Fb%3E%0AIgelweg%206%0A91220%20Schnaittach-Osternohe%0A%2B49%209153%204060&layers=BFTFFFTFFTF0FFFFFFTT Karte]<br />
: EZ Ü/F: ab 64 € (59 € ohne Frühstück )<br />
: Igelweg 6, 91220 Schnaittach-Osternohe, +49 9153 4060, [http://www.igelwirt.de/ Igelwirt.de]<br />
<br />
; Gasthof Schuster<br />
: 3 Minuten mit dem Auto, 20 Minuten mit dem Fahrrad [http://map.openseamap.org/map/?zoom=14&mlat=49.56896&mlon=11.33958&mtext=%3Cb%3EGasthof%20Schuster%3C%2Fb%3E%0AKirchenweg%206%0A91220%20Hedersdorf%0A%2B49%209153%201288%20&layers=BTTFFFTFFTF0FFFFFFTT Karte]<br />
: EZ Ü/F 34 € (30 € ohne Frühstück)<br />
: Kirchenweg 6, 91220 Hedersdorf, +49 9153 1288<br />
<br />
== Verpflegung ==<br />
Schön wäre, wenn die Tagesgäste oder "Heimschläfer" Lust hätten, etwas zum Essen zu organisieren. Beispielsweise das Frühstück mitbringen, etwas zum "kalten Buffet", oder Pizza, oder etwas zum Kaffee, oder einen Salat...<br />
Bitte trage hier ein, wenn Du etwas mitbringen willst. Frage bevor Du kommst kurz telefonisch wieviele da sind, oder vielleicht magst Du Pizza-Bestellungen entgegennehmen und die Pizzen abholen und mitbringen?<br />
<br />
Getränke und Tee/Kaffee sind im Haus. Ebenso Aufbackbrötchen und Nudeln für alle Fälle.<br />
<br />
{| class="wikitable"<br />
! style="width: 6em" | wer organisiert || Do || Do Abend || Fr Früh || Fr Mitt || Fr Abend || Sa Früh || Sa Mitt || Sa nachm || Sa Abend || So Früh || So Mitt || So nachm || So Abend || Mo Früh || Bemerkungen<br />
|-<br />
| Markus || X || || || || || || || || || || || || || || Food for all <br />
|-<br />
| Markus || || X || || || || || || || || || || || || || Abendessen bei mir für alle die angemeldet sind<br />
|-<br />
| Markus || || || X || || || X || || || || X || || || || X || Frühstück bei mir für alle die angemeldet sind<br />
|-<br />
| Landgasthof || || || || || X || || || || X || || || || X || || <br />
|-<br />
| .. || || || || || || || || || || || || || || || <br />
|}<br />
<br />
{| class="wikitable"<br />
! class="unsortable" style="width: 6em" | wer isst mit || Do Abend || Fr Früh || Fr Abend || Sa Früh || Sa Mitt || Sa nachm || Sa Abend || So Früh || So Mitt || So nachm || So Abend || Mo Früh || class="unsortable" | Bemerkungen<br />
|-<br />
| Markus || X || X || X || X || X || X || X || X || X || X || X || X || <br />
|-<br />
| Cornelia || || X || X || X || X || X || X || X || X || X || X || X || vegetarisch<br />
|-<br />
| Martin || || || || || X || X || X || X || X || || || || vegetarisch<br />
|-<br />
| .. || || || || || || || || || || || || || <br />
|}<br />
<br />
== Fahrgemeinschaft ==<br />
; Suche<br />
{| class="wikitable"<br />
! wer || ab wo || Abfahrt || Plätze || Bemerkungen<br />
|-<br />
| .. || || || || <br />
|}<br />
<br />
; Biete<br />
{| class="wikitable"<br />
! wer || ab wo || Abfahrt || Plätze || Bemerkungen<br />
|-<br />
| .. || || || || <br />
|}<br />
<br />
Bitte nehmt direkt miteinander Kontakt auf.<br />
<br />
== Zusammenfassung / ToDo ==<br />
* [[OpenSeaMap-dev:10._Entwicklerwochenende/Bericht | Bericht / ToDo]]<br />
* [[OpenSeaMap-dev:9._Entwicklerwochenende/Bericht | Bericht / ToDo Herbst 2015]]<br />
* [[OpenSeaMap-dev:8._Entwicklerwochenende/Bericht | Bericht / ToDo Früjahr 2014]]<br />
* [[OpenSeaMap-dev:7._Entwicklerwochenende/Bericht | Bericht / ToDo Herbst 2013]]<br />
* [[OpenSeaMap-dev:6._Entwicklerwochenende/Bericht | Bericht / ToDo Frühjahr 2013]]</div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:Entwicklerwochenende_2015-04&diff=3437OpenSeaMap-dev:Entwicklerwochenende 2015-042015-03-30T05:26:20Z<p>MartinOver: /* Themenvorschläge */</p>
<hr />
<div>[[Datei:Konzept OpenSeaMap.jpg|thumb|Konzept von OpenSeaMap]]<br />
<br />
Planung zum 10. Entwicklerwochenende am '''24.-26. 4. 2015'''<br />
<br />
<br />
== Anmeldung ==<br />
[mailto:liste12A45q7@gmx.de?subject=9.%20Entwicklerwochenende%20-%20Anmeldung Anmeldung bitte per Mail] <br>oder besser: gleich hier in der Liste:<br />
{| class="wikitable sortable"<br />
! Nr || Do || Fr || Sa || So || Mo || wer || von wo || Übernachtung || class="unsortable" | Bemerkungen<br />
|-<br />
| 1 || 19:00 || x || x || x || 16:00 || [[Benutzer:Markus|Markus]] || - || - || Orga<br />
|-<br />
| 2 || 19:00 || x || x || x || 07:00 || Cornelia || - || - || Tutorials, Artikel, Website, Support<br />
|-<br />
| 3 || || x ||x || x || || Alexej Humbach|| Aachen (DE) || bei Markus || Karten, Tiden, Wassertiefen<br />
|-<br />
| 4 || || || || || || Joachim Bobrich || Frankfurt/Main (DE) || || Echo, Logger, Anwendungen<br />
|-<br />
| 5 || || || x || x || || Martin Over || Köln (DE) || Landgasthof || Wassertiefen<br />
|-<br />
| 6 || || || || || || Wolfgang Schildbach || Nürnberg (DE) || - || Daten-Kompression<br />
|-<br />
| 7 || || || || || || Wolfgang Sommers || Erkelenz (DE) || || AT5-Karten<br />
|-<br />
| 8 || || || || || || Marek Skleciak || Erlangen (DE) || - || DEM (Doktorandenstelle), 3D<br />
|-<br />
| 9 || || || || || || Andreas Merz || Erlangen (DE) || - || Wassertiefen, ...<br />
|-<br />
| 10 || || || || || || Herbert Oppmann || Nürnberg (DE) || - || AT5<br />
|-<br />
| 11 || || || || || || ? || ? || || <br />
<!-- |-<br />
| 5 || || || || || || Jens Kübler || Karlsruhe (DE) || || Wassertiefen<br />
|-<br />
| 6 || 19:00 || x || x || x || || Werner König || Velbert (DE) ||bei Markus || WinNav<br />
|-<br />
| 7 || || 19:00 || || || || Hans-Jürgen Beie || Nürnberg (DE) || - || KNF, Typo3<br />
|-<br />
| 8 || || || x || || || Reiner Schmalzl || Nürnberg (DE) || - || Datenschutz, Typo3<br />
|-<br />
| 10 || || 12:00 || x || || || Victor Klein || Essen (DE) || bei Lang || offline Karten Android<br />
|-<br />
| 11 || || || x || || || Thorsten Baur || Bamberg (DE) || || Website, Stategie<br />
|-<br />
| 12 || || || x || || || Thomas Waldecker || München (DE) || bei Markus || Whitewater, Offline chart<br />
|-<br />
| 14 || || 23:00 || x || x || || Niko Ehrenfeuchter || Freiburg (DE) || bei Markus || Server, GitHub<br />
|<br />
| 4 || || || || || || Hakan Tandogan || München (DE) || || <br />
|-<br />
| 5 || || || x || || || Inger Holndonner || Nürnberg (DE) || nein || Tauchen <br />
|-<br />
| 9 || || || || || || Werner ? || || || <br />
|-<br />
| 10 || || || || || || Claas Kähler || Münster (DE) || || <br />
--><br />
|-<br />
| .. || || || || || || || || || <br />
|}<br />
<br />
== Programm ==<br />
Das Programm werden wir je nach anwesenden Personen, Interessen und Prioritäten gestalten <br>und möglichst hier vorher gemeinsam planen. <br />
<br />
Hacking: Gut fände ich, wenn wir wie letztes Mal wieder Zeit für Coding, Scripting, Hacking verwenden.<br />
<br />
Schwerpunkt wird sein:<br />
* Workflow im Entwickler-Team <br>wie können wir unterstützend, effizient, lustvoll, produktiv zusammenarbeiten <br>wie gestalten wir Planung, Doku, Kommunikation<br />
* Servers<br />
* Water depths<br />
* Charts for Android, iOS, Garmin, Lowrance, B&G, Simrad. <br />
* Vector chart (AT5, OsmAnd, S-57)<br />
* ...<br />
<br />
Und natürlich werden wir auch für alle anderen wichtigen Themen Zeit haben: <br>Visionen, Ideen, Pläne zu Apps, Community, Qualität, Server, Tidenrechner, Hafendatenbank, Wassersportwiki, Bericht von "boot", etc, etc.<br />
<br />
; Struktur<br />
: Die Idee ist, dass jeder "Maintainer" bzw. jedes Team eines Projektes ein Zeitfenster hat, <br>um die zentralen Fragen mit allen anderen Entwicklern zu diskutieren und Lösungen bzw Lösungswege zu finden.<br />
: Ergebnis soll jeweils eine ToDo-Liste sein.<br />
: Bewährt hat sich beim letzten Mal, das Treffen auch als Hack-Weekend zu gestalten.<br />
: Und natürlich wie immer Zeit für's Kennenlernen und Fachsimpeln!<br />
<br />
{| class="wikitable"<br />
! Zeit || Thema || Wer || Bemerkungen<br />
|-<br />
| Do || Core-Dev-Meeting || || open for everybody<br />
|-<br />
| Fr || Pre-Dev-Meeting || || open for everybody<br />
|-<br />
| Fr 19:00 || <small>Abendessen</small> || <small>bei Markus</small> || (bitte anmelden)<br />
|-<br />
| Sa 08:00 || <small>Frühstück</small> || <small>Gäste von Markus</small> || wer mag kann gern dazukommen (bitte anmelden)<br />
|-<br />
| '''Sa 09:00''' || Intro || Markus || Rückblick, Ausblick<br />
|-<br />
| Sa 09:30 || Vorstellungsrunde || alle || vermutlich beginnen wir gleich mit der Arbeit, da die Meisten bereits Do/Fr kommen <br />
|-<br />
| Sa 12:00 || || || <br />
|-<br />
| Sa 14:00 || <small>Mittagspause</small> || || "kaltes Buffet"<br />
|-<br />
| Sa 15:00 || || || <br />
|-<br />
| Sa 17:00 || || || <br />
|-<br />
| Sa 19:00 || <small>Abendessen</small> || || Landgasthof<br />
|-<br />
| Sa 20:00 || || || <br />
|-<br />
| So 08:00 || <small>Frühstück</small> || <small>Gäste von Markus</small> || wer mag kann gern dazukommen (bitte anmelden)<br />
|-<br />
| '''So 09:00''' || || || <br />
|-<br />
| So 12:00 || || || <br />
|-<br />
| So 14:00 || || || <br />
|-<br />
| '''So 16:00''' || Ende des Hauptteils || || <br />
|-<br />
| So 18:00 || || || <br />
|-<br />
| So 20:00 || || || <br />
|-<br />
| So 22:00 || || || <br />
|-<br />
| Mo 08:00 || Arbeits-Frühstück || || Rückblick, Planung<br />
|-<br />
| Mo 10:00 || || || Umsetzung? (je nachdem wer noch da ist)<br />
|}<br />
<br />
== Themenvorschläge ==<br />
{| class="wikitable"<br />
! Thema || Prio || wer || Zeit || wer wird gewünscht || Bemerkungen<br />
|-<br />
| Visualisierung von Wassertiefen || Prio || Martin || Sa/bis So Mittag || wer wird gewünscht || Bemerkungen<br />
|-<br />
| Entscheidungsstrukturen & Kommunikation || Prio || Martin || Sa/bis So Mittag || wer wird gewünscht || Bemerkungen<br />
|-<br />
<!--<br />
| Redaktionsplan Facebook, Website-Gestaltung, Marketing-Konzept || || Cornelia, Thorsten || Sa 9-14 || Markus für Rückfragen || <br />
|-<br />
| Verpflichtung auf Datenschutz BDSG §5, für alle Admins || || Reiner || Sa 15' || alle Admins || <br />
|-<br />
| Serverstruktur aufzeichnen || || Markus || 15' || Alexej, Jens, Matthias, Niko || <br />
|-<br />
| Serverstruktur optimieren (Konzept erstellen) || || Niko || 30' || Alexej, Jens, Matthias, KNF || <br />
|-<br />
| Logger-Vertrieb: 100€ statt 35€, 100 v. 500 verkauft <br>Ziel: Strategie entwickeln || 1 || Markus || 30' || Hans-Jürgen, Wolfgang, Alexej || <br />
|-<br />
| Video/Screencast-Tutorial JOSM || || Cornelia || || Wolfgang || <br />
|-<br />
| WPI-Häfen wieder auf Karte verlinken || || Markus || 30' || Matthias || <br />
|-<br />
| Gespräch mit dem Vorsitzenden des KNF || || Hans-Jürgen || Fr 19, 30' || Plenum || <br />
|-<br />
--><br />
| .. || || || || || <br />
|}<br />
<br />
== Unterkunft ==<br />
<br />
; privat bei Markus<br />
: Bei mir können 3..4 Gäste gratis übernachten. Gern bereits ab Donnerstag bzw bis Montag.<br />
:{| class="wikitable"<br />
! wer || Do || Fr || Sa || So<br />
|-<br />
| Alexej || || x || x || x <br />
|-<br />
| .. || || || || <br />
|}<br />
<br />
; Landgasthof "Lang"<br />
: 5 Minuten zu Fuss, beim Bahnhof Simmelsdorf, [http://map.openseamap.org/?zoom=16&mlat=49.59830&mlon=11.34050&mtext=%3Cb%3ELandgasthaus%20Lang%3C%2Fb%3E%0ABahnhofstra%C3%9Fe%209%0A91245%20Simmelsdorf%0A%2B49%209155%20237&layers=BFTFFFTFFTF0FFFFFFTT Karte]<br />
: EZ Ü/F: ab 33 € (28,20 € ohne Frühstück)<br />
: Bahnhofstraße 9, 91245 Simmelsdorf, +49 9155 237, [http://www.landgasthaus-lang.de/ Landgasthof-Lang.de]<br />
<br />
; Hotel "Igelwirt"<br />
: 10 Minuten mit dem Auto, [http://map.openseamap.org/map/?zoom=14&mlat=49.58696&mlon=11.37649&mtext=%3Cb%3EIgelwirt%3C%2Fb%3E%0AIgelweg%206%0A91220%20Schnaittach-Osternohe%0A%2B49%209153%204060&layers=BFTFFFTFFTF0FFFFFFTT Karte]<br />
: EZ Ü/F: ab 64 € (59 € ohne Frühstück )<br />
: Igelweg 6, 91220 Schnaittach-Osternohe, +49 9153 4060, [http://www.igelwirt.de/ Igelwirt.de]<br />
<br />
; Gasthof Schuster<br />
: 3 Minuten mit dem Auto, 20 Minuten mit dem Fahrrad [http://map.openseamap.org/map/?zoom=14&mlat=49.56896&mlon=11.33958&mtext=%3Cb%3EGasthof%20Schuster%3C%2Fb%3E%0AKirchenweg%206%0A91220%20Hedersdorf%0A%2B49%209153%201288%20&layers=BTTFFFTFFTF0FFFFFFTT Karte]<br />
: EZ Ü/F 34 € (30 € ohne Frühstück)<br />
: Kirchenweg 6, 91220 Hedersdorf, +49 9153 1288<br />
<br />
== Verpflegung ==<br />
Schön wäre, wenn die Tagesgäste oder "Heimschläfer" Lust hätten, etwas zum Essen zu organisieren. Beispielsweise das Frühstück mitbringen, etwas zum "kalten Buffet", oder Pizza, oder etwas zum Kaffee, oder einen Salat...<br />
Bitte trage hier ein, wenn Du etwas mitbringen willst. Frage bevor Du kommst kurz telefonisch wieviele da sind, oder vielleicht magst Du Pizza-Bestellungen entgegennehmen und die Pizzen abholen und mitbringen?<br />
<br />
Getränke und Tee/Kaffee sind im Haus. Ebenso Aufbackbrötchen und Nudeln für alle Fälle.<br />
<br />
{| class="wikitable"<br />
! style="width: 6em" | wer organisiert || Do || Do Abend || Fr Früh || Fr Mitt || Fr Abend || Sa Früh || Sa Mitt || Sa nachm || Sa Abend || So Früh || So Mitt || So nachm || So Abend || Mo Früh || Bemerkungen<br />
|-<br />
| Markus || X || || || || || || || || || || || || || || Food for all <br />
|-<br />
| Markus || || X || || || || || || || || || || || || || Abendessen bei mir für alle die angemeldet sind<br />
|-<br />
| Markus || || || X || || || X || || || || X || || || || X || Frühstück bei mir für alle die angemeldet sind<br />
|-<br />
| Landgasthof || || || || || X || || || || X || || || || X || || <br />
|-<br />
| .. || || || || || || || || || || || || || || || <br />
|}<br />
<br />
{| class="wikitable"<br />
! class="unsortable" style="width: 6em" | wer isst mit || Do Abend || Fr Früh || Fr Abend || Sa Früh || Sa Mitt || Sa nachm || Sa Abend || So Früh || So Mitt || So nachm || So Abend || Mo Früh || class="unsortable" | Bemerkungen<br />
|-<br />
| Markus || X || X || X || X || X || X || X || X || X || X || X || X || <br />
|-<br />
| Cornelia || || X || X || X || X || X || X || X || X || X || X || X || vegetarisch<br />
|-<br />
| Martin || || || || || X || X || X || X || X || || || || vegetarisch<br />
|-<br />
| .. || || || || || || || || || || || || || <br />
|}<br />
<br />
== Fahrgemeinschaft ==<br />
; Suche<br />
{| class="wikitable"<br />
! wer || ab wo || Abfahrt || Plätze || Bemerkungen<br />
|-<br />
| .. || || || || <br />
|}<br />
<br />
; Biete<br />
{| class="wikitable"<br />
! wer || ab wo || Abfahrt || Plätze || Bemerkungen<br />
|-<br />
| .. || || || || <br />
|}<br />
<br />
Bitte nehmt direkt miteinander Kontakt auf.<br />
<br />
== Zusammenfassung / ToDo ==<br />
* [[OpenSeaMap-dev:10._Entwicklerwochenende/Bericht | Bericht / ToDo]]<br />
* [[OpenSeaMap-dev:9._Entwicklerwochenende/Bericht | Bericht / ToDo Herbst 2015]]<br />
* [[OpenSeaMap-dev:8._Entwicklerwochenende/Bericht | Bericht / ToDo Früjahr 2014]]<br />
* [[OpenSeaMap-dev:7._Entwicklerwochenende/Bericht | Bericht / ToDo Herbst 2013]]<br />
* [[OpenSeaMap-dev:6._Entwicklerwochenende/Bericht | Bericht / ToDo Frühjahr 2013]]</div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:Entwicklerwochenende_2013-04&diff=3436OpenSeaMap-dev:Entwicklerwochenende 2013-042015-03-30T05:24:39Z<p>MartinOver: /* Themen */</p>
<hr />
<div>[[Datei:Konzept OpenSeaMap.jpg|thumb|Konzept für OpenSeaMap]]<br />
<br />
Planung zum 6. Entwicklerwochenende am '''11.-15. 4. 2013'''<br />
<br />
<br />
== Anmeldung ==<br />
[mailto:liste12A45q7@gmx.de?subject=5.%20Entwicklerwochenende%20-%20Anmeldung Anmeldung bitte per Mail] <br>oder hier in der Liste:<br />
{| class="wikitable sortable"<br />
! Nr || Do || Fr || Sa || So || Mo || wer || von wo || Übernachtung || class="unsortable" | Bemerkungen<br />
|-<br />
| 1 || x || x || x || x || x || [[Benutzer:Markus|Markus]] || || - || <br />
|-<br />
| 2 || || || || '''X''' || || Wolfgang Bosch || Wien || - || DGFI<br />
|-<br />
| 3 || || 19:00 || x || x || || Jens Kübler || Karlsruhe || Landgasthof || SW-Logger<br />
|-<br />
| 4 || || x || x || x || || Andreas Merz || Nürnberg || - || <br />
|-<br />
| 5 || || x || x || x || || Cornelia || Nürnberg || bei Markus || <br />
|-<br />
| 6 || || x || x || x || || Inger Holndonner || Nürnberg || - || Wassertiefen, Tauchen<br />
|-<br />
| 7 || || x || x || 18:00 || || Victor Klein || Essen || Landgasthof || Android-App, Wassertiefen<br />
|-<br />
| 8 || || 16:00 || x || 12:00 || || Martin Over || Köln || || Wassertiefen, Höhen<br />
|-<br />
| 9 || || || || x || || Martin Dörig || St.Gallen || - || Wassertiefen<br />
|-<br />
| 10 || || || || x || || Leonard Dushi || St.Gallen || - || Wassertiefen<br />
|-<br />
| 11 || || 15:30 || x || x || || Nils Werner || Erlangen || - || Wassertiefen (Raspberry Pi), Git?<br />
|-<br />
| 12 || || || || || || || || || <br />
|}<br />
<br />
== Programm ==<br />
Das Programm werden wir je nach anwesenden Personen, Interessen und Prioritäten gestalten <br>und möglichst hier vorher gemeinsam planen. <br />
<br />
Schwerpunkt wir sein:<br />
* Wassertiefenerfassung<br />
* Korrektur der Rohdaten<br />
* HW-Logger<br />
<br />
Wolfgang Bosch hilft uns beim Konzept für die Erfassung der Wassertiefen und bei der Korrektur der Rohdaten. <br>Er arbeitet am [http://www.dgfi.badw.de/ deutschen geodätischen Forschungsinstitut (DGFI)] in München, und ist Spezialist für Wellen- und Tidenmodelle. <br>Er wird am '''Sonntag''' seine Arbeit vorstellen.<br />
<br />
Und natürlich werden wir auch für alle anderen wichtigen Temen Zeit haben: <br>Visionen, Ideen, Pläne zu Apps, Vektorkarten, Community, Qualität, Server, Tidenrechner, Hafendatenbank, Wassersportwiki, etc, etc.<br />
<br />
; Struktur<br />
: Die Idee ist, dass jeder "Maintainer" bzw. jedes Team eines Projektes ein Zeitfenster hat, <br>um die zentralen Fragen mit allen anderen Entwicklern zu diskutieren und Lösungen bzw Lösungswege zu finden.<br />
: Ergebnis soll jeweils eine ToDo-Liste sein.<br />
: Bewährt hat sich beim letzten Mal, das Treffen auch als Hack-Weekend zu gestalten.<br />
: Und natürlich wie immer Zeit für's Kennenlernen und Fachsimpeln!<br />
<br />
{| class="wikitable"<br />
! Zeit || Thema || Wer || Bemerkungen<br />
|-<br />
| Do || Core-Dev-Meeting || || open for everybody<br />
|-<br />
| Fr || Pre-Dev-Meeting || || open for everybody<br />
|-<br />
| Fr 19:00 || <small>Abendessen</small> || <small>bei Markus</small> || (bitte anmelden)<br />
|-<br />
| Sa 08:00 || <small>Frühstück</small> || <small>Gäste von Markus</small> || wer mag kann gern dazukommen (bitte anmelden)<br />
|-<br />
| '''Sa 10:00''' || Intro || Markus || Rückblick, Ausblick<br />
|-<br />
| Sa 10:30 || Vorstellungsrunde || alle || je max 5' incl. Kurzvorstellung des Teilprojektes <br>bitte Flipchart mitbringen, oder 1 PPT-Folie (vorab an Markus schicken)<br />
|-<br />
| Sa 12:00 || || || <br />
|-<br />
| Sa 14:00 || <small>Mittagspause</small> || || "kaltes Buffet"<br />
|-<br />
| Sa 15:00 || || || <br />
|-<br />
| Sa 17:00 || || || <br />
|-<br />
| Sa 19:00 || <small>Abendessen</small> || || Landgasthof<br />
|-<br />
| Sa 20:00 || || || <br />
|-<br />
| So 08:00 || <small>Frühstück</small> || <small>Gäste von Markus</small> || wer mag kann gern dazukommen (bitte anmelden)<br />
|-<br />
| '''So 10:00''' || '''Korrektur der Rohdaten''' <br>Welle, Tide, etc. || Wolfgang Bosch || <br />
|-<br />
| So 12:00 || || || <br />
|-<br />
| So 14:00 || || || <br />
|-<br />
| '''So 16:00''' || Ende des Hauptteils || || <br />
|-<br />
| So 18:00 || || || <br />
|-<br />
| So 20:00 || || || <br />
|-<br />
| So 22:00 || || || <br />
|-<br />
| Mo 08:00 || Arbeits-Frühstück || || Rückblick, Planung<br />
|-<br />
| Mo 10:00 || || || Umsetzung? (je nachdem wer noch da ist)<br />
|}<br />
<br />
== Themen ==<br />
{| class="wikitable"<br />
! Thema || Prio || wer || Bemerkungen<br />
|-<br />
| HW-Logger || || || <br />
|-<br />
| SW-Logger || || || <br />
|-<br />
| Datenaufbereitung || || Wolfgang || <br />
|-<br />
| PR || || Markus || <br />
|-<br />
| ... || || || <br />
|}<br />
<br />
== Unterkunft ==<br />
<br />
; privat bei Markus<br />
: Bei mir können 3..4 Gäste gratis übernachten. Gern bereits ab Donnerstag bzw bis Montag.<br />
:{| class="wikitable"<br />
! wer || Do || Fr || Sa || So<br />
|-<br />
| ... || || || || <br />
|-<br />
| ... || || || || <br />
|-<br />
| ... || || || || <br />
|}<br />
<br />
; Landgasthof "Lang"<br />
: 5 Minuten zu Fuss, beim Bahnhof Simmelsdorf, [http://map.openseamap.org/map/?zoom=16&mlat=49.59824&mlon=11.3405&mtext=Landgashaus%20Lang&layers=BFTTFFTFFTF0FF&lat=49.59815&lon=11.34048 Karte]<br />
: EZ Ü/F: ab 30 € (25,20 € ohne Frühstück)<br />
: Bahnhofstraße 9, 91245 Simmelsdorf, +49 9155 237, [http://www.landgasthaus-lang.de/ Landgasthof-Lang.de]<br />
<br />
; Hotel "Igelwirt"<br />
: 10 Minuten mit dem Auto, [http://www.openstreetmap.org/?mlat=49.5873&mlon=11.3765&zoom=14 Karte]<br />
: EZ Ü/F: ab 57 € (52 € ohne Frühstück )<br />
: Igelweg 6, 91220 Schnaittach-Osternohe, +40 9153 4060, [http://www.igelwirt.de/ Igelwirt.de]<br />
<br />
; Gasthof Schuster<br />
: 3 Minuten mit dem Auto, 20 Minuten mit dem Fahrrad [http://map.openseamap.org/map/?zoom=14&mlat=49.5689&mlon=11.3396&mtext=Gasthof%20Schuster&layers=BFTTFFTFFTF0FF&lat=49.58219&lon=11.34367 Karte]<br />
: EZ Ü/F 33 € (29 € ohne Frühstück)<br />
: Kirchenweg 6, 91220 Hedersdorf, +49 9153 1288<br />
<br />
== Verpflegung ==<br />
Schön wäre, wenn die Tagesgäste oder "Heimschläfer" Lust hätten, etwas zum Essen zu organisieren. Beispielsweise das Frühstück mitbringen, etwas zum "kalten Buffet", oder Pizza, oder etwas zum Kaffee, oder einen Salat...<br />
Bitte trage hier ein, wenn Du etwas mitbringen willst. Frage bevor Du kommst kurz telefonisch wieviele da sind, oder vielleicht magst Du Pizza-Bestellungen entgegennehmen und die Pizzen abholen und mitbringen?<br />
<br />
Getränke und Tee/Kaffee sind im Haus. Ebenso Aufbackbrötchen und Nudeln für alle Fälle.<br />
<br />
{| class="wikitable"<br />
! style="width: 6em" | wer organisiert || Do || Do Abend || Fr Früh || Fr Mitt || Fr Abend || Sa Früh || Sa Mitt || Sa nachm || Sa Abend || So Früh || So Mitt || So nachm || So Abend || Mo Früh || Bemerkungen<br />
|-<br />
| Markus || X || || || || || || || || || || || || || || Food for all <br />
|-<br />
| Markus || || X || || || || || || || || || || || || || Abendessen bei mir für alle die angemeldet sind<br />
|-<br />
| Markus || || || X || || || X || || || || X || || || || X || Frühstück bei mir für alle die angemeldet sind<br />
|-<br />
| Martin || || || || || || || || || || || X || || || || Chicks for free - wer lieber Pizza hat, soll sich melden<br />
|-<br />
| Landgasthof || || || || || X || || || || X || || || || X || || <br />
|-<br />
| ... || || || || || || || || || || || || || || || <br />
|}<br />
<br />
{| class="wikitable"<br />
! class="unsortable" style="width: 6em" | wer isst mit || Do Abend || Fr Früh || Fr Abend || Sa Früh || Sa Mitt || Sa nachm || Sa Abend || So Früh || So Mitt || So nachm || So Abend || Mo Früh || class="unsortable" | Bemerkungen<br />
|-<br />
| Markus || X || X || X || X || X || X || X || X || X || X || X || X || <br />
|-<br />
| Leo || || || || || || || || || X || || || || <br />
|-<br />
| Martin || || || || || || || || || X || || || || <br />
|-<br />
| ... || || || || || || || || || || || || || <br />
|}<br />
<br />
== Fahrgemeinschaft ==<br />
; Suche<br />
{| class="wikitable"<br />
! wer || ab wo || Abfahrt || Plätze || Bemerkungen<br />
huhu<br />
|-<br />
| .. || || || || <br />
|}<br />
<br />
; Biete<br />
{| class="wikitable"<br />
! wer || ab wo || Abfahrt || Plätze || Bemerkungen<br />
|-<br />
| .. || || || || <br />
|}<br />
<br />
Bitte nehmt direkt miteinander Kontakt auf.<br />
<br />
== Zusammenfassung / ToDo ==<br />
* [[OpenSeaMap-dev:6._Entwicklerwochenende/Bericht | Bericht / ToDo]]<br />
* [[OpenSeaMap-dev:5._Entwicklerwochenende/Bericht | Bericht / ToDo vom letzten Entwicklertreffen]]</div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:Entwicklerwochenende_2013-04&diff=3435OpenSeaMap-dev:Entwicklerwochenende 2013-042015-03-28T16:25:24Z<p>MartinOver: /* Themen */</p>
<hr />
<div>[[Datei:Konzept OpenSeaMap.jpg|thumb|Konzept für OpenSeaMap]]<br />
<br />
Planung zum 6. Entwicklerwochenende am '''11.-15. 4. 2013'''<br />
<br />
<br />
== Anmeldung ==<br />
[mailto:liste12A45q7@gmx.de?subject=5.%20Entwicklerwochenende%20-%20Anmeldung Anmeldung bitte per Mail] <br>oder hier in der Liste:<br />
{| class="wikitable sortable"<br />
! Nr || Do || Fr || Sa || So || Mo || wer || von wo || Übernachtung || class="unsortable" | Bemerkungen<br />
|-<br />
| 1 || x || x || x || x || x || [[Benutzer:Markus|Markus]] || || - || <br />
|-<br />
| 2 || || || || '''X''' || || Wolfgang Bosch || Wien || - || DGFI<br />
|-<br />
| 3 || || 19:00 || x || x || || Jens Kübler || Karlsruhe || Landgasthof || SW-Logger<br />
|-<br />
| 4 || || x || x || x || || Andreas Merz || Nürnberg || - || <br />
|-<br />
| 5 || || x || x || x || || Cornelia || Nürnberg || bei Markus || <br />
|-<br />
| 6 || || x || x || x || || Inger Holndonner || Nürnberg || - || Wassertiefen, Tauchen<br />
|-<br />
| 7 || || x || x || 18:00 || || Victor Klein || Essen || Landgasthof || Android-App, Wassertiefen<br />
|-<br />
| 8 || || 16:00 || x || 12:00 || || Martin Over || Köln || || Wassertiefen, Höhen<br />
|-<br />
| 9 || || || || x || || Martin Dörig || St.Gallen || - || Wassertiefen<br />
|-<br />
| 10 || || || || x || || Leonard Dushi || St.Gallen || - || Wassertiefen<br />
|-<br />
| 11 || || 15:30 || x || x || || Nils Werner || Erlangen || - || Wassertiefen (Raspberry Pi), Git?<br />
|-<br />
| 12 || || || || || || || || || <br />
|}<br />
<br />
== Programm ==<br />
Das Programm werden wir je nach anwesenden Personen, Interessen und Prioritäten gestalten <br>und möglichst hier vorher gemeinsam planen. <br />
<br />
Schwerpunkt wir sein:<br />
* Wassertiefenerfassung<br />
* Korrektur der Rohdaten<br />
* HW-Logger<br />
<br />
Wolfgang Bosch hilft uns beim Konzept für die Erfassung der Wassertiefen und bei der Korrektur der Rohdaten. <br>Er arbeitet am [http://www.dgfi.badw.de/ deutschen geodätischen Forschungsinstitut (DGFI)] in München, und ist Spezialist für Wellen- und Tidenmodelle. <br>Er wird am '''Sonntag''' seine Arbeit vorstellen.<br />
<br />
Und natürlich werden wir auch für alle anderen wichtigen Temen Zeit haben: <br>Visionen, Ideen, Pläne zu Apps, Vektorkarten, Community, Qualität, Server, Tidenrechner, Hafendatenbank, Wassersportwiki, etc, etc.<br />
<br />
; Struktur<br />
: Die Idee ist, dass jeder "Maintainer" bzw. jedes Team eines Projektes ein Zeitfenster hat, <br>um die zentralen Fragen mit allen anderen Entwicklern zu diskutieren und Lösungen bzw Lösungswege zu finden.<br />
: Ergebnis soll jeweils eine ToDo-Liste sein.<br />
: Bewährt hat sich beim letzten Mal, das Treffen auch als Hack-Weekend zu gestalten.<br />
: Und natürlich wie immer Zeit für's Kennenlernen und Fachsimpeln!<br />
<br />
{| class="wikitable"<br />
! Zeit || Thema || Wer || Bemerkungen<br />
|-<br />
| Do || Core-Dev-Meeting || || open for everybody<br />
|-<br />
| Fr || Pre-Dev-Meeting || || open for everybody<br />
|-<br />
| Fr 19:00 || <small>Abendessen</small> || <small>bei Markus</small> || (bitte anmelden)<br />
|-<br />
| Sa 08:00 || <small>Frühstück</small> || <small>Gäste von Markus</small> || wer mag kann gern dazukommen (bitte anmelden)<br />
|-<br />
| '''Sa 10:00''' || Intro || Markus || Rückblick, Ausblick<br />
|-<br />
| Sa 10:30 || Vorstellungsrunde || alle || je max 5' incl. Kurzvorstellung des Teilprojektes <br>bitte Flipchart mitbringen, oder 1 PPT-Folie (vorab an Markus schicken)<br />
|-<br />
| Sa 12:00 || || || <br />
|-<br />
| Sa 14:00 || <small>Mittagspause</small> || || "kaltes Buffet"<br />
|-<br />
| Sa 15:00 || || || <br />
|-<br />
| Sa 17:00 || || || <br />
|-<br />
| Sa 19:00 || <small>Abendessen</small> || || Landgasthof<br />
|-<br />
| Sa 20:00 || || || <br />
|-<br />
| So 08:00 || <small>Frühstück</small> || <small>Gäste von Markus</small> || wer mag kann gern dazukommen (bitte anmelden)<br />
|-<br />
| '''So 10:00''' || '''Korrektur der Rohdaten''' <br>Welle, Tide, etc. || Wolfgang Bosch || <br />
|-<br />
| So 12:00 || || || <br />
|-<br />
| So 14:00 || || || <br />
|-<br />
| '''So 16:00''' || Ende des Hauptteils || || <br />
|-<br />
| So 18:00 || || || <br />
|-<br />
| So 20:00 || || || <br />
|-<br />
| So 22:00 || || || <br />
|-<br />
| Mo 08:00 || Arbeits-Frühstück || || Rückblick, Planung<br />
|-<br />
| Mo 10:00 || || || Umsetzung? (je nachdem wer noch da ist)<br />
|}<br />
<br />
== Themen ==<br />
{| class="wikitable"<br />
! Thema || Prio || wer || Bemerkungen<br />
|-<br />
| HW-Logger || || || <br />
|-<br />
| SW-Logger || || || <br />
|-<br />
| Datenaufbereitung || || Wolfgang || <br />
|-<br />
| PR || || Markus || <br />
|-<br />
| Darstellung von Wassertiefen || || Martin || <br />
|-<br />
| Entscheidungsstrukturen im Projekt || || Martin || <br />
|-<br />
| ... || || || <br />
|}<br />
<br />
== Unterkunft ==<br />
<br />
; privat bei Markus<br />
: Bei mir können 3..4 Gäste gratis übernachten. Gern bereits ab Donnerstag bzw bis Montag.<br />
:{| class="wikitable"<br />
! wer || Do || Fr || Sa || So<br />
|-<br />
| ... || || || || <br />
|-<br />
| ... || || || || <br />
|-<br />
| ... || || || || <br />
|}<br />
<br />
; Landgasthof "Lang"<br />
: 5 Minuten zu Fuss, beim Bahnhof Simmelsdorf, [http://map.openseamap.org/map/?zoom=16&mlat=49.59824&mlon=11.3405&mtext=Landgashaus%20Lang&layers=BFTTFFTFFTF0FF&lat=49.59815&lon=11.34048 Karte]<br />
: EZ Ü/F: ab 30 € (25,20 € ohne Frühstück)<br />
: Bahnhofstraße 9, 91245 Simmelsdorf, +49 9155 237, [http://www.landgasthaus-lang.de/ Landgasthof-Lang.de]<br />
<br />
; Hotel "Igelwirt"<br />
: 10 Minuten mit dem Auto, [http://www.openstreetmap.org/?mlat=49.5873&mlon=11.3765&zoom=14 Karte]<br />
: EZ Ü/F: ab 57 € (52 € ohne Frühstück )<br />
: Igelweg 6, 91220 Schnaittach-Osternohe, +40 9153 4060, [http://www.igelwirt.de/ Igelwirt.de]<br />
<br />
; Gasthof Schuster<br />
: 3 Minuten mit dem Auto, 20 Minuten mit dem Fahrrad [http://map.openseamap.org/map/?zoom=14&mlat=49.5689&mlon=11.3396&mtext=Gasthof%20Schuster&layers=BFTTFFTFFTF0FF&lat=49.58219&lon=11.34367 Karte]<br />
: EZ Ü/F 33 € (29 € ohne Frühstück)<br />
: Kirchenweg 6, 91220 Hedersdorf, +49 9153 1288<br />
<br />
== Verpflegung ==<br />
Schön wäre, wenn die Tagesgäste oder "Heimschläfer" Lust hätten, etwas zum Essen zu organisieren. Beispielsweise das Frühstück mitbringen, etwas zum "kalten Buffet", oder Pizza, oder etwas zum Kaffee, oder einen Salat...<br />
Bitte trage hier ein, wenn Du etwas mitbringen willst. Frage bevor Du kommst kurz telefonisch wieviele da sind, oder vielleicht magst Du Pizza-Bestellungen entgegennehmen und die Pizzen abholen und mitbringen?<br />
<br />
Getränke und Tee/Kaffee sind im Haus. Ebenso Aufbackbrötchen und Nudeln für alle Fälle.<br />
<br />
{| class="wikitable"<br />
! style="width: 6em" | wer organisiert || Do || Do Abend || Fr Früh || Fr Mitt || Fr Abend || Sa Früh || Sa Mitt || Sa nachm || Sa Abend || So Früh || So Mitt || So nachm || So Abend || Mo Früh || Bemerkungen<br />
|-<br />
| Markus || X || || || || || || || || || || || || || || Food for all <br />
|-<br />
| Markus || || X || || || || || || || || || || || || || Abendessen bei mir für alle die angemeldet sind<br />
|-<br />
| Markus || || || X || || || X || || || || X || || || || X || Frühstück bei mir für alle die angemeldet sind<br />
|-<br />
| Martin || || || || || || || || || || || X || || || || Chicks for free - wer lieber Pizza hat, soll sich melden<br />
|-<br />
| Landgasthof || || || || || X || || || || X || || || || X || || <br />
|-<br />
| ... || || || || || || || || || || || || || || || <br />
|}<br />
<br />
{| class="wikitable"<br />
! class="unsortable" style="width: 6em" | wer isst mit || Do Abend || Fr Früh || Fr Abend || Sa Früh || Sa Mitt || Sa nachm || Sa Abend || So Früh || So Mitt || So nachm || So Abend || Mo Früh || class="unsortable" | Bemerkungen<br />
|-<br />
| Markus || X || X || X || X || X || X || X || X || X || X || X || X || <br />
|-<br />
| Leo || || || || || || || || || X || || || || <br />
|-<br />
| Martin || || || || || || || || || X || || || || <br />
|-<br />
| ... || || || || || || || || || || || || || <br />
|}<br />
<br />
== Fahrgemeinschaft ==<br />
; Suche<br />
{| class="wikitable"<br />
! wer || ab wo || Abfahrt || Plätze || Bemerkungen<br />
huhu<br />
|-<br />
| .. || || || || <br />
|}<br />
<br />
; Biete<br />
{| class="wikitable"<br />
! wer || ab wo || Abfahrt || Plätze || Bemerkungen<br />
|-<br />
| .. || || || || <br />
|}<br />
<br />
Bitte nehmt direkt miteinander Kontakt auf.<br />
<br />
== Zusammenfassung / ToDo ==<br />
* [[OpenSeaMap-dev:6._Entwicklerwochenende/Bericht | Bericht / ToDo]]<br />
* [[OpenSeaMap-dev:5._Entwicklerwochenende/Bericht | Bericht / ToDo vom letzten Entwicklertreffen]]</div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:Entwicklerwochenende_2013-04&diff=3434OpenSeaMap-dev:Entwicklerwochenende 2013-042015-03-28T16:12:39Z<p>MartinOver: /* Themen */</p>
<hr />
<div>[[Datei:Konzept OpenSeaMap.jpg|thumb|Konzept für OpenSeaMap]]<br />
<br />
Planung zum 6. Entwicklerwochenende am '''11.-15. 4. 2013'''<br />
<br />
<br />
== Anmeldung ==<br />
[mailto:liste12A45q7@gmx.de?subject=5.%20Entwicklerwochenende%20-%20Anmeldung Anmeldung bitte per Mail] <br>oder hier in der Liste:<br />
{| class="wikitable sortable"<br />
! Nr || Do || Fr || Sa || So || Mo || wer || von wo || Übernachtung || class="unsortable" | Bemerkungen<br />
|-<br />
| 1 || x || x || x || x || x || [[Benutzer:Markus|Markus]] || || - || <br />
|-<br />
| 2 || || || || '''X''' || || Wolfgang Bosch || Wien || - || DGFI<br />
|-<br />
| 3 || || 19:00 || x || x || || Jens Kübler || Karlsruhe || Landgasthof || SW-Logger<br />
|-<br />
| 4 || || x || x || x || || Andreas Merz || Nürnberg || - || <br />
|-<br />
| 5 || || x || x || x || || Cornelia || Nürnberg || bei Markus || <br />
|-<br />
| 6 || || x || x || x || || Inger Holndonner || Nürnberg || - || Wassertiefen, Tauchen<br />
|-<br />
| 7 || || x || x || 18:00 || || Victor Klein || Essen || Landgasthof || Android-App, Wassertiefen<br />
|-<br />
| 8 || || 16:00 || x || 12:00 || || Martin Over || Köln || || Wassertiefen, Höhen<br />
|-<br />
| 9 || || || || x || || Martin Dörig || St.Gallen || - || Wassertiefen<br />
|-<br />
| 10 || || || || x || || Leonard Dushi || St.Gallen || - || Wassertiefen<br />
|-<br />
| 11 || || 15:30 || x || x || || Nils Werner || Erlangen || - || Wassertiefen (Raspberry Pi), Git?<br />
|-<br />
| 12 || || || || || || || || || <br />
|}<br />
<br />
== Programm ==<br />
Das Programm werden wir je nach anwesenden Personen, Interessen und Prioritäten gestalten <br>und möglichst hier vorher gemeinsam planen. <br />
<br />
Schwerpunkt wir sein:<br />
* Wassertiefenerfassung<br />
* Korrektur der Rohdaten<br />
* HW-Logger<br />
<br />
Wolfgang Bosch hilft uns beim Konzept für die Erfassung der Wassertiefen und bei der Korrektur der Rohdaten. <br>Er arbeitet am [http://www.dgfi.badw.de/ deutschen geodätischen Forschungsinstitut (DGFI)] in München, und ist Spezialist für Wellen- und Tidenmodelle. <br>Er wird am '''Sonntag''' seine Arbeit vorstellen.<br />
<br />
Und natürlich werden wir auch für alle anderen wichtigen Temen Zeit haben: <br>Visionen, Ideen, Pläne zu Apps, Vektorkarten, Community, Qualität, Server, Tidenrechner, Hafendatenbank, Wassersportwiki, etc, etc.<br />
<br />
; Struktur<br />
: Die Idee ist, dass jeder "Maintainer" bzw. jedes Team eines Projektes ein Zeitfenster hat, <br>um die zentralen Fragen mit allen anderen Entwicklern zu diskutieren und Lösungen bzw Lösungswege zu finden.<br />
: Ergebnis soll jeweils eine ToDo-Liste sein.<br />
: Bewährt hat sich beim letzten Mal, das Treffen auch als Hack-Weekend zu gestalten.<br />
: Und natürlich wie immer Zeit für's Kennenlernen und Fachsimpeln!<br />
<br />
{| class="wikitable"<br />
! Zeit || Thema || Wer || Bemerkungen<br />
|-<br />
| Do || Core-Dev-Meeting || || open for everybody<br />
|-<br />
| Fr || Pre-Dev-Meeting || || open for everybody<br />
|-<br />
| Fr 19:00 || <small>Abendessen</small> || <small>bei Markus</small> || (bitte anmelden)<br />
|-<br />
| Sa 08:00 || <small>Frühstück</small> || <small>Gäste von Markus</small> || wer mag kann gern dazukommen (bitte anmelden)<br />
|-<br />
| '''Sa 10:00''' || Intro || Markus || Rückblick, Ausblick<br />
|-<br />
| Sa 10:30 || Vorstellungsrunde || alle || je max 5' incl. Kurzvorstellung des Teilprojektes <br>bitte Flipchart mitbringen, oder 1 PPT-Folie (vorab an Markus schicken)<br />
|-<br />
| Sa 12:00 || || || <br />
|-<br />
| Sa 14:00 || <small>Mittagspause</small> || || "kaltes Buffet"<br />
|-<br />
| Sa 15:00 || || || <br />
|-<br />
| Sa 17:00 || || || <br />
|-<br />
| Sa 19:00 || <small>Abendessen</small> || || Landgasthof<br />
|-<br />
| Sa 20:00 || || || <br />
|-<br />
| So 08:00 || <small>Frühstück</small> || <small>Gäste von Markus</small> || wer mag kann gern dazukommen (bitte anmelden)<br />
|-<br />
| '''So 10:00''' || '''Korrektur der Rohdaten''' <br>Welle, Tide, etc. || Wolfgang Bosch || <br />
|-<br />
| So 12:00 || || || <br />
|-<br />
| So 14:00 || || || <br />
|-<br />
| '''So 16:00''' || Ende des Hauptteils || || <br />
|-<br />
| So 18:00 || || || <br />
|-<br />
| So 20:00 || || || <br />
|-<br />
| So 22:00 || || || <br />
|-<br />
| Mo 08:00 || Arbeits-Frühstück || || Rückblick, Planung<br />
|-<br />
| Mo 10:00 || || || Umsetzung? (je nachdem wer noch da ist)<br />
|}<br />
<br />
== Themen ==<br />
{| class="wikitable"<br />
! Thema || Prio || wer || Bemerkungen<br />
|-<br />
| HW-Logger || || || <br />
|-<br />
| SW-Logger || || || <br />
|-<br />
| Datenaufbereitung || || Wolfgang || <br />
|-<br />
| PR || || Markus || <br />
|-<br />
| Darstellung von Wassertiefen || || Martin || <br />
|-<br />
| ... || || || <br />
|}<br />
<br />
== Unterkunft ==<br />
<br />
; privat bei Markus<br />
: Bei mir können 3..4 Gäste gratis übernachten. Gern bereits ab Donnerstag bzw bis Montag.<br />
:{| class="wikitable"<br />
! wer || Do || Fr || Sa || So<br />
|-<br />
| ... || || || || <br />
|-<br />
| ... || || || || <br />
|-<br />
| ... || || || || <br />
|}<br />
<br />
; Landgasthof "Lang"<br />
: 5 Minuten zu Fuss, beim Bahnhof Simmelsdorf, [http://map.openseamap.org/map/?zoom=16&mlat=49.59824&mlon=11.3405&mtext=Landgashaus%20Lang&layers=BFTTFFTFFTF0FF&lat=49.59815&lon=11.34048 Karte]<br />
: EZ Ü/F: ab 30 € (25,20 € ohne Frühstück)<br />
: Bahnhofstraße 9, 91245 Simmelsdorf, +49 9155 237, [http://www.landgasthaus-lang.de/ Landgasthof-Lang.de]<br />
<br />
; Hotel "Igelwirt"<br />
: 10 Minuten mit dem Auto, [http://www.openstreetmap.org/?mlat=49.5873&mlon=11.3765&zoom=14 Karte]<br />
: EZ Ü/F: ab 57 € (52 € ohne Frühstück )<br />
: Igelweg 6, 91220 Schnaittach-Osternohe, +40 9153 4060, [http://www.igelwirt.de/ Igelwirt.de]<br />
<br />
; Gasthof Schuster<br />
: 3 Minuten mit dem Auto, 20 Minuten mit dem Fahrrad [http://map.openseamap.org/map/?zoom=14&mlat=49.5689&mlon=11.3396&mtext=Gasthof%20Schuster&layers=BFTTFFTFFTF0FF&lat=49.58219&lon=11.34367 Karte]<br />
: EZ Ü/F 33 € (29 € ohne Frühstück)<br />
: Kirchenweg 6, 91220 Hedersdorf, +49 9153 1288<br />
<br />
== Verpflegung ==<br />
Schön wäre, wenn die Tagesgäste oder "Heimschläfer" Lust hätten, etwas zum Essen zu organisieren. Beispielsweise das Frühstück mitbringen, etwas zum "kalten Buffet", oder Pizza, oder etwas zum Kaffee, oder einen Salat...<br />
Bitte trage hier ein, wenn Du etwas mitbringen willst. Frage bevor Du kommst kurz telefonisch wieviele da sind, oder vielleicht magst Du Pizza-Bestellungen entgegennehmen und die Pizzen abholen und mitbringen?<br />
<br />
Getränke und Tee/Kaffee sind im Haus. Ebenso Aufbackbrötchen und Nudeln für alle Fälle.<br />
<br />
{| class="wikitable"<br />
! style="width: 6em" | wer organisiert || Do || Do Abend || Fr Früh || Fr Mitt || Fr Abend || Sa Früh || Sa Mitt || Sa nachm || Sa Abend || So Früh || So Mitt || So nachm || So Abend || Mo Früh || Bemerkungen<br />
|-<br />
| Markus || X || || || || || || || || || || || || || || Food for all <br />
|-<br />
| Markus || || X || || || || || || || || || || || || || Abendessen bei mir für alle die angemeldet sind<br />
|-<br />
| Markus || || || X || || || X || || || || X || || || || X || Frühstück bei mir für alle die angemeldet sind<br />
|-<br />
| Martin || || || || || || || || || || || X || || || || Chicks for free - wer lieber Pizza hat, soll sich melden<br />
|-<br />
| Landgasthof || || || || || X || || || || X || || || || X || || <br />
|-<br />
| ... || || || || || || || || || || || || || || || <br />
|}<br />
<br />
{| class="wikitable"<br />
! class="unsortable" style="width: 6em" | wer isst mit || Do Abend || Fr Früh || Fr Abend || Sa Früh || Sa Mitt || Sa nachm || Sa Abend || So Früh || So Mitt || So nachm || So Abend || Mo Früh || class="unsortable" | Bemerkungen<br />
|-<br />
| Markus || X || X || X || X || X || X || X || X || X || X || X || X || <br />
|-<br />
| Leo || || || || || || || || || X || || || || <br />
|-<br />
| Martin || || || || || || || || || X || || || || <br />
|-<br />
| ... || || || || || || || || || || || || || <br />
|}<br />
<br />
== Fahrgemeinschaft ==<br />
; Suche<br />
{| class="wikitable"<br />
! wer || ab wo || Abfahrt || Plätze || Bemerkungen<br />
huhu<br />
|-<br />
| .. || || || || <br />
|}<br />
<br />
; Biete<br />
{| class="wikitable"<br />
! wer || ab wo || Abfahrt || Plätze || Bemerkungen<br />
|-<br />
| .. || || || || <br />
|}<br />
<br />
Bitte nehmt direkt miteinander Kontakt auf.<br />
<br />
== Zusammenfassung / ToDo ==<br />
* [[OpenSeaMap-dev:6._Entwicklerwochenende/Bericht | Bericht / ToDo]]<br />
* [[OpenSeaMap-dev:5._Entwicklerwochenende/Bericht | Bericht / ToDo vom letzten Entwicklertreffen]]</div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:Entwicklerwochenende_2015-04&diff=3418OpenSeaMap-dev:Entwicklerwochenende 2015-042015-03-04T15:22:15Z<p>MartinOver: /* Themenvorschläge */</p>
<hr />
<div>[[Datei:Konzept OpenSeaMap.jpg|thumb|Konzept von OpenSeaMap]]<br />
<br />
Planung zum 10. Entwicklerwochenende am '''24.-26. 4. 2015'''<br />
<br />
<br />
== Anmeldung ==<br />
[mailto:liste12A45q7@gmx.de?subject=9.%20Entwicklerwochenende%20-%20Anmeldung Anmeldung bitte per Mail] <br>oder besser: gleich hier in der Liste:<br />
{| class="wikitable sortable"<br />
! Nr || Do || Fr || Sa || So || Mo || wer || von wo || Übernachtung || class="unsortable" | Bemerkungen<br />
|-<br />
| 1 || 19:00 || x || x || x || 16:00 || [[Benutzer:Markus|Markus]] || - || - || Orga<br />
|-<br />
| 2 || 19:00 || x || x || x || 07:00 || Cornelia || - || - || Tutorials, Artikel, Website, Support<br />
|-<br />
| 3 || || x ||x || x || || Alexej Humbach|| Aachen (DE) || bei Markus || Karten, Tiden, Wassertiefen<br />
|-<br />
| 4 || || || || || || Joachim Bobrich || Frankfurt/Main (DE) || || Echo, Logger, Anwendungen<br />
|-<br />
| 5 || || || x || x || || Martin Over || Köln (DE) || Landgasthof || Wassertiefen<br />
|-<br />
| 6 || || || || || || Wolfgang Schildbach || Nürnberg (DE) || - || Daten-Kompression<br />
|-<br />
| 7 || || || || || || Wolfgang Sommers || Erkelenz (DE) || || AT5-Karten<br />
|-<br />
| 8 || || || || || || Marek Skleciak || Erlangen (DE) || - || DEM (Doktorandenstelle), 3D<br />
|-<br />
| 9 || || || || || || Andreas Merz || Erlangen (DE) || - || Wassertiefen, ...<br />
|-<br />
| 10 || || || || || || Herbert Oppmann || Nürnberg (DE) || - || AT5<br />
|-<br />
| 11 || || || || || || ? || ? || || <br />
<!-- |-<br />
| 5 || || || || || || Jens Kübler || Karlsruhe (DE) || || Wassertiefen<br />
|-<br />
| 6 || 19:00 || x || x || x || || Werner König || Velbert (DE) ||bei Markus || WinNav<br />
|-<br />
| 7 || || 19:00 || || || || Hans-Jürgen Beie || Nürnberg (DE) || - || KNF, Typo3<br />
|-<br />
| 8 || || || x || || || Reiner Schmalzl || Nürnberg (DE) || - || Datenschutz, Typo3<br />
|-<br />
| 10 || || 12:00 || x || || || Victor Klein || Essen (DE) || bei Lang || offline Karten Android<br />
|-<br />
| 11 || || || x || || || Thorsten Baur || Bamberg (DE) || || Website, Stategie<br />
|-<br />
| 12 || || || x || || || Thomas Waldecker || München (DE) || bei Markus || Whitewater, Offline chart<br />
|-<br />
| 14 || || 23:00 || x || x || || Niko Ehrenfeuchter || Freiburg (DE) || bei Markus || Server, GitHub<br />
|<br />
| 4 || || || || || || Hakan Tandogan || München (DE) || || <br />
|-<br />
| 5 || || || x || || || Inger Holndonner || Nürnberg (DE) || nein || Tauchen <br />
|-<br />
| 9 || || || || || || Werner ? || || || <br />
|-<br />
| 10 || || || || || || Claas Kähler || Münster (DE) || || <br />
--><br />
|-<br />
| .. || || || || || || || || || <br />
|}<br />
<br />
== Programm ==<br />
Das Programm werden wir je nach anwesenden Personen, Interessen und Prioritäten gestalten <br>und möglichst hier vorher gemeinsam planen. <br />
<br />
Hacking: Gut fände ich, wenn wir wie letztes Mal wieder Zeit für Coding, Scripting, Hacking verwenden.<br />
<br />
Schwerpunkt wird sein:<br />
* Workflow im Entwickler-Team <br>wie können wir unterstützend, effizient, lustvoll, produktiv zusammenarbeiten <br>wie gestalten wir Planung, Doku, Kommunikation<br />
* Servers<br />
* Water depths<br />
* Charts for Android, iOS, Garmin, Lowrance, B&G, Simrad. <br />
* Vector chart (AT5, OsmAnd, S-57)<br />
* ...<br />
<br />
Und natürlich werden wir auch für alle anderen wichtigen Themen Zeit haben: <br>Visionen, Ideen, Pläne zu Apps, Community, Qualität, Server, Tidenrechner, Hafendatenbank, Wassersportwiki, Bericht von "boot", etc, etc.<br />
<br />
; Struktur<br />
: Die Idee ist, dass jeder "Maintainer" bzw. jedes Team eines Projektes ein Zeitfenster hat, <br>um die zentralen Fragen mit allen anderen Entwicklern zu diskutieren und Lösungen bzw Lösungswege zu finden.<br />
: Ergebnis soll jeweils eine ToDo-Liste sein.<br />
: Bewährt hat sich beim letzten Mal, das Treffen auch als Hack-Weekend zu gestalten.<br />
: Und natürlich wie immer Zeit für's Kennenlernen und Fachsimpeln!<br />
<br />
{| class="wikitable"<br />
! Zeit || Thema || Wer || Bemerkungen<br />
|-<br />
| Do || Core-Dev-Meeting || || open for everybody<br />
|-<br />
| Fr || Pre-Dev-Meeting || || open for everybody<br />
|-<br />
| Fr 19:00 || <small>Abendessen</small> || <small>bei Markus</small> || (bitte anmelden)<br />
|-<br />
| Sa 08:00 || <small>Frühstück</small> || <small>Gäste von Markus</small> || wer mag kann gern dazukommen (bitte anmelden)<br />
|-<br />
| '''Sa 09:00''' || Intro || Markus || Rückblick, Ausblick<br />
|-<br />
| Sa 09:30 || Vorstellungsrunde || alle || vermutlich beginnen wir gleich mit der Arbeit, da die Meisten bereits Do/Fr kommen <br />
|-<br />
| Sa 12:00 || || || <br />
|-<br />
| Sa 14:00 || <small>Mittagspause</small> || || "kaltes Buffet"<br />
|-<br />
| Sa 15:00 || || || <br />
|-<br />
| Sa 17:00 || || || <br />
|-<br />
| Sa 19:00 || <small>Abendessen</small> || || Landgasthof<br />
|-<br />
| Sa 20:00 || || || <br />
|-<br />
| So 08:00 || <small>Frühstück</small> || <small>Gäste von Markus</small> || wer mag kann gern dazukommen (bitte anmelden)<br />
|-<br />
| '''So 09:00''' || || || <br />
|-<br />
| So 12:00 || || || <br />
|-<br />
| So 14:00 || || || <br />
|-<br />
| '''So 16:00''' || Ende des Hauptteils || || <br />
|-<br />
| So 18:00 || || || <br />
|-<br />
| So 20:00 || || || <br />
|-<br />
| So 22:00 || || || <br />
|-<br />
| Mo 08:00 || Arbeits-Frühstück || || Rückblick, Planung<br />
|-<br />
| Mo 10:00 || || || Umsetzung? (je nachdem wer noch da ist)<br />
|}<br />
<br />
== Themenvorschläge ==<br />
{| class="wikitable"<br />
! Thema || Prio || wer || Zeit || wer wird gewünscht || Bemerkungen<br />
|-<br />
| Visualisierung von Wassertiefen || Prio || Martin || Sa/bis So Mittag || wer wird gewünscht || Bemerkungen<br />
|-<br />
<!--<br />
| Redaktionsplan Facebook, Website-Gestaltung, Marketing-Konzept || || Cornelia, Thorsten || Sa 9-14 || Markus für Rückfragen || <br />
|-<br />
| Verpflichtung auf Datenschutz BDSG §5, für alle Admins || || Reiner || Sa 15' || alle Admins || <br />
|-<br />
| Serverstruktur aufzeichnen || || Markus || 15' || Alexej, Jens, Matthias, Niko || <br />
|-<br />
| Serverstruktur optimieren (Konzept erstellen) || || Niko || 30' || Alexej, Jens, Matthias, KNF || <br />
|-<br />
| Logger-Vertrieb: 100€ statt 35€, 100 v. 500 verkauft <br>Ziel: Strategie entwickeln || 1 || Markus || 30' || Hans-Jürgen, Wolfgang, Alexej || <br />
|-<br />
| Video/Screencast-Tutorial JOSM || || Cornelia || || Wolfgang || <br />
|-<br />
| WPI-Häfen wieder auf Karte verlinken || || Markus || 30' || Matthias || <br />
|-<br />
| Gespräch mit dem Vorsitzenden des KNF || || Hans-Jürgen || Fr 19, 30' || Plenum || <br />
|-<br />
--><br />
| .. || || || || || <br />
|}<br />
<br />
== Unterkunft ==<br />
<br />
; privat bei Markus<br />
: Bei mir können 3..4 Gäste gratis übernachten. Gern bereits ab Donnerstag bzw bis Montag.<br />
:{| class="wikitable"<br />
! wer || Do || Fr || Sa || So<br />
|-<br />
| Alexej || || x || x || x <br />
|-<br />
| .. || || || || <br />
|}<br />
<br />
; Landgasthof "Lang"<br />
: 5 Minuten zu Fuss, beim Bahnhof Simmelsdorf, [http://map.openseamap.org/?zoom=16&mlat=49.59830&mlon=11.34050&mtext=%3Cb%3ELandgasthaus%20Lang%3C%2Fb%3E%0ABahnhofstra%C3%9Fe%209%0A91245%20Simmelsdorf%0A%2B49%209155%20237&layers=BFTFFFTFFTF0FFFFFFTT Karte]<br />
: EZ Ü/F: ab 33 € (28,20 € ohne Frühstück)<br />
: Bahnhofstraße 9, 91245 Simmelsdorf, +49 9155 237, [http://www.landgasthaus-lang.de/ Landgasthof-Lang.de]<br />
<br />
; Hotel "Igelwirt"<br />
: 10 Minuten mit dem Auto, [http://map.openseamap.org/map/?zoom=14&mlat=49.58696&mlon=11.37649&mtext=%3Cb%3EIgelwirt%3C%2Fb%3E%0AIgelweg%206%0A91220%20Schnaittach-Osternohe%0A%2B49%209153%204060&layers=BFTFFFTFFTF0FFFFFFTT Karte]<br />
: EZ Ü/F: ab 64 € (59 € ohne Frühstück )<br />
: Igelweg 6, 91220 Schnaittach-Osternohe, +49 9153 4060, [http://www.igelwirt.de/ Igelwirt.de]<br />
<br />
; Gasthof Schuster<br />
: 3 Minuten mit dem Auto, 20 Minuten mit dem Fahrrad [http://map.openseamap.org/map/?zoom=14&mlat=49.56896&mlon=11.33958&mtext=%3Cb%3EGasthof%20Schuster%3C%2Fb%3E%0AKirchenweg%206%0A91220%20Hedersdorf%0A%2B49%209153%201288%20&layers=BTTFFFTFFTF0FFFFFFTT Karte]<br />
: EZ Ü/F 34 € (30 € ohne Frühstück)<br />
: Kirchenweg 6, 91220 Hedersdorf, +49 9153 1288<br />
<br />
== Verpflegung ==<br />
Schön wäre, wenn die Tagesgäste oder "Heimschläfer" Lust hätten, etwas zum Essen zu organisieren. Beispielsweise das Frühstück mitbringen, etwas zum "kalten Buffet", oder Pizza, oder etwas zum Kaffee, oder einen Salat...<br />
Bitte trage hier ein, wenn Du etwas mitbringen willst. Frage bevor Du kommst kurz telefonisch wieviele da sind, oder vielleicht magst Du Pizza-Bestellungen entgegennehmen und die Pizzen abholen und mitbringen?<br />
<br />
Getränke und Tee/Kaffee sind im Haus. Ebenso Aufbackbrötchen und Nudeln für alle Fälle.<br />
<br />
{| class="wikitable"<br />
! style="width: 6em" | wer organisiert || Do || Do Abend || Fr Früh || Fr Mitt || Fr Abend || Sa Früh || Sa Mitt || Sa nachm || Sa Abend || So Früh || So Mitt || So nachm || So Abend || Mo Früh || Bemerkungen<br />
|-<br />
| Markus || X || || || || || || || || || || || || || || Food for all <br />
|-<br />
| Markus || || X || || || || || || || || || || || || || Abendessen bei mir für alle die angemeldet sind<br />
|-<br />
| Markus || || || X || || || X || || || || X || || || || X || Frühstück bei mir für alle die angemeldet sind<br />
|-<br />
| Landgasthof || || || || || X || || || || X || || || || X || || <br />
|-<br />
| .. || || || || || || || || || || || || || || || <br />
|}<br />
<br />
{| class="wikitable"<br />
! class="unsortable" style="width: 6em" | wer isst mit || Do Abend || Fr Früh || Fr Abend || Sa Früh || Sa Mitt || Sa nachm || Sa Abend || So Früh || So Mitt || So nachm || So Abend || Mo Früh || class="unsortable" | Bemerkungen<br />
|-<br />
| Markus || X || X || X || X || X || X || X || X || X || X || X || X || <br />
|-<br />
| Cornelia || || X || X || X || X || X || X || X || X || X || X || X || vegetarisch<br />
|-<br />
| Martin || || || || || X || X || X || X || X || || || || vegetarisch<br />
|-<br />
| .. || || || || || || || || || || || || || <br />
|}<br />
<br />
== Fahrgemeinschaft ==<br />
; Suche<br />
{| class="wikitable"<br />
! wer || ab wo || Abfahrt || Plätze || Bemerkungen<br />
|-<br />
| .. || || || || <br />
|}<br />
<br />
; Biete<br />
{| class="wikitable"<br />
! wer || ab wo || Abfahrt || Plätze || Bemerkungen<br />
|-<br />
| .. || || || || <br />
|}<br />
<br />
Bitte nehmt direkt miteinander Kontakt auf.<br />
<br />
== Zusammenfassung / ToDo ==<br />
* [[OpenSeaMap-dev:10._Entwicklerwochenende/Bericht | Bericht / ToDo]]<br />
* [[OpenSeaMap-dev:9._Entwicklerwochenende/Bericht | Bericht / ToDo Herbst 2015]]<br />
* [[OpenSeaMap-dev:8._Entwicklerwochenende/Bericht | Bericht / ToDo Früjahr 2014]]<br />
* [[OpenSeaMap-dev:7._Entwicklerwochenende/Bericht | Bericht / ToDo Herbst 2013]]<br />
* [[OpenSeaMap-dev:6._Entwicklerwochenende/Bericht | Bericht / ToDo Frühjahr 2013]]</div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:Entwicklerwochenende_2015-04&diff=3417OpenSeaMap-dev:Entwicklerwochenende 2015-042015-03-04T15:19:37Z<p>MartinOver: /* Anmeldung */</p>
<hr />
<div>[[Datei:Konzept OpenSeaMap.jpg|thumb|Konzept von OpenSeaMap]]<br />
<br />
Planung zum 10. Entwicklerwochenende am '''24.-26. 4. 2015'''<br />
<br />
<br />
== Anmeldung ==<br />
[mailto:liste12A45q7@gmx.de?subject=9.%20Entwicklerwochenende%20-%20Anmeldung Anmeldung bitte per Mail] <br>oder besser: gleich hier in der Liste:<br />
{| class="wikitable sortable"<br />
! Nr || Do || Fr || Sa || So || Mo || wer || von wo || Übernachtung || class="unsortable" | Bemerkungen<br />
|-<br />
| 1 || 19:00 || x || x || x || 16:00 || [[Benutzer:Markus|Markus]] || - || - || Orga<br />
|-<br />
| 2 || 19:00 || x || x || x || 07:00 || Cornelia || - || - || Tutorials, Artikel, Website, Support<br />
|-<br />
| 3 || || x ||x || x || || Alexej Humbach|| Aachen (DE) || bei Markus || Karten, Tiden, Wassertiefen<br />
|-<br />
| 4 || || || || || || Joachim Bobrich || Frankfurt/Main (DE) || || Echo, Logger, Anwendungen<br />
|-<br />
| 5 || || || x || x || || Martin Over || Köln (DE) || Landgasthof || Wassertiefen<br />
|-<br />
| 6 || || || || || || Wolfgang Schildbach || Nürnberg (DE) || - || Daten-Kompression<br />
|-<br />
| 7 || || || || || || Wolfgang Sommers || Erkelenz (DE) || || AT5-Karten<br />
|-<br />
| 8 || || || || || || Marek Skleciak || Erlangen (DE) || - || DEM (Doktorandenstelle), 3D<br />
|-<br />
| 9 || || || || || || Andreas Merz || Erlangen (DE) || - || Wassertiefen, ...<br />
|-<br />
| 10 || || || || || || Herbert Oppmann || Nürnberg (DE) || - || AT5<br />
|-<br />
| 11 || || || || || || ? || ? || || <br />
<!-- |-<br />
| 5 || || || || || || Jens Kübler || Karlsruhe (DE) || || Wassertiefen<br />
|-<br />
| 6 || 19:00 || x || x || x || || Werner König || Velbert (DE) ||bei Markus || WinNav<br />
|-<br />
| 7 || || 19:00 || || || || Hans-Jürgen Beie || Nürnberg (DE) || - || KNF, Typo3<br />
|-<br />
| 8 || || || x || || || Reiner Schmalzl || Nürnberg (DE) || - || Datenschutz, Typo3<br />
|-<br />
| 10 || || 12:00 || x || || || Victor Klein || Essen (DE) || bei Lang || offline Karten Android<br />
|-<br />
| 11 || || || x || || || Thorsten Baur || Bamberg (DE) || || Website, Stategie<br />
|-<br />
| 12 || || || x || || || Thomas Waldecker || München (DE) || bei Markus || Whitewater, Offline chart<br />
|-<br />
| 14 || || 23:00 || x || x || || Niko Ehrenfeuchter || Freiburg (DE) || bei Markus || Server, GitHub<br />
|<br />
| 4 || || || || || || Hakan Tandogan || München (DE) || || <br />
|-<br />
| 5 || || || x || || || Inger Holndonner || Nürnberg (DE) || nein || Tauchen <br />
|-<br />
| 9 || || || || || || Werner ? || || || <br />
|-<br />
| 10 || || || || || || Claas Kähler || Münster (DE) || || <br />
--><br />
|-<br />
| .. || || || || || || || || || <br />
|}<br />
<br />
== Programm ==<br />
Das Programm werden wir je nach anwesenden Personen, Interessen und Prioritäten gestalten <br>und möglichst hier vorher gemeinsam planen. <br />
<br />
Hacking: Gut fände ich, wenn wir wie letztes Mal wieder Zeit für Coding, Scripting, Hacking verwenden.<br />
<br />
Schwerpunkt wird sein:<br />
* Workflow im Entwickler-Team <br>wie können wir unterstützend, effizient, lustvoll, produktiv zusammenarbeiten <br>wie gestalten wir Planung, Doku, Kommunikation<br />
* Servers<br />
* Water depths<br />
* Charts for Android, iOS, Garmin, Lowrance, B&G, Simrad. <br />
* Vector chart (AT5, OsmAnd, S-57)<br />
* ...<br />
<br />
Und natürlich werden wir auch für alle anderen wichtigen Themen Zeit haben: <br>Visionen, Ideen, Pläne zu Apps, Community, Qualität, Server, Tidenrechner, Hafendatenbank, Wassersportwiki, Bericht von "boot", etc, etc.<br />
<br />
; Struktur<br />
: Die Idee ist, dass jeder "Maintainer" bzw. jedes Team eines Projektes ein Zeitfenster hat, <br>um die zentralen Fragen mit allen anderen Entwicklern zu diskutieren und Lösungen bzw Lösungswege zu finden.<br />
: Ergebnis soll jeweils eine ToDo-Liste sein.<br />
: Bewährt hat sich beim letzten Mal, das Treffen auch als Hack-Weekend zu gestalten.<br />
: Und natürlich wie immer Zeit für's Kennenlernen und Fachsimpeln!<br />
<br />
{| class="wikitable"<br />
! Zeit || Thema || Wer || Bemerkungen<br />
|-<br />
| Do || Core-Dev-Meeting || || open for everybody<br />
|-<br />
| Fr || Pre-Dev-Meeting || || open for everybody<br />
|-<br />
| Fr 19:00 || <small>Abendessen</small> || <small>bei Markus</small> || (bitte anmelden)<br />
|-<br />
| Sa 08:00 || <small>Frühstück</small> || <small>Gäste von Markus</small> || wer mag kann gern dazukommen (bitte anmelden)<br />
|-<br />
| '''Sa 09:00''' || Intro || Markus || Rückblick, Ausblick<br />
|-<br />
| Sa 09:30 || Vorstellungsrunde || alle || vermutlich beginnen wir gleich mit der Arbeit, da die Meisten bereits Do/Fr kommen <br />
|-<br />
| Sa 12:00 || || || <br />
|-<br />
| Sa 14:00 || <small>Mittagspause</small> || || "kaltes Buffet"<br />
|-<br />
| Sa 15:00 || || || <br />
|-<br />
| Sa 17:00 || || || <br />
|-<br />
| Sa 19:00 || <small>Abendessen</small> || || Landgasthof<br />
|-<br />
| Sa 20:00 || || || <br />
|-<br />
| So 08:00 || <small>Frühstück</small> || <small>Gäste von Markus</small> || wer mag kann gern dazukommen (bitte anmelden)<br />
|-<br />
| '''So 09:00''' || || || <br />
|-<br />
| So 12:00 || || || <br />
|-<br />
| So 14:00 || || || <br />
|-<br />
| '''So 16:00''' || Ende des Hauptteils || || <br />
|-<br />
| So 18:00 || || || <br />
|-<br />
| So 20:00 || || || <br />
|-<br />
| So 22:00 || || || <br />
|-<br />
| Mo 08:00 || Arbeits-Frühstück || || Rückblick, Planung<br />
|-<br />
| Mo 10:00 || || || Umsetzung? (je nachdem wer noch da ist)<br />
|}<br />
<br />
== Themenvorschläge ==<br />
{| class="wikitable"<br />
! Thema || Prio || wer || Zeit || wer wird gewünscht || Bemerkungen<br />
|-<br />
<!--<br />
| Redaktionsplan Facebook, Website-Gestaltung, Marketing-Konzept || || Cornelia, Thorsten || Sa 9-14 || Markus für Rückfragen || <br />
|-<br />
| Verpflichtung auf Datenschutz BDSG §5, für alle Admins || || Reiner || Sa 15' || alle Admins || <br />
|-<br />
| Serverstruktur aufzeichnen || || Markus || 15' || Alexej, Jens, Matthias, Niko || <br />
|-<br />
| Serverstruktur optimieren (Konzept erstellen) || || Niko || 30' || Alexej, Jens, Matthias, KNF || <br />
|-<br />
| Logger-Vertrieb: 100€ statt 35€, 100 v. 500 verkauft <br>Ziel: Strategie entwickeln || 1 || Markus || 30' || Hans-Jürgen, Wolfgang, Alexej || <br />
|-<br />
| Video/Screencast-Tutorial JOSM || || Cornelia || || Wolfgang || <br />
|-<br />
| WPI-Häfen wieder auf Karte verlinken || || Markus || 30' || Matthias || <br />
|-<br />
| Gespräch mit dem Vorsitzenden des KNF || || Hans-Jürgen || Fr 19, 30' || Plenum || <br />
|-<br />
--><br />
| .. || || || || || <br />
|}<br />
<br />
== Unterkunft ==<br />
<br />
; privat bei Markus<br />
: Bei mir können 3..4 Gäste gratis übernachten. Gern bereits ab Donnerstag bzw bis Montag.<br />
:{| class="wikitable"<br />
! wer || Do || Fr || Sa || So<br />
|-<br />
| Alexej || || x || x || x <br />
|-<br />
| .. || || || || <br />
|}<br />
<br />
; Landgasthof "Lang"<br />
: 5 Minuten zu Fuss, beim Bahnhof Simmelsdorf, [http://map.openseamap.org/?zoom=16&mlat=49.59830&mlon=11.34050&mtext=%3Cb%3ELandgasthaus%20Lang%3C%2Fb%3E%0ABahnhofstra%C3%9Fe%209%0A91245%20Simmelsdorf%0A%2B49%209155%20237&layers=BFTFFFTFFTF0FFFFFFTT Karte]<br />
: EZ Ü/F: ab 33 € (28,20 € ohne Frühstück)<br />
: Bahnhofstraße 9, 91245 Simmelsdorf, +49 9155 237, [http://www.landgasthaus-lang.de/ Landgasthof-Lang.de]<br />
<br />
; Hotel "Igelwirt"<br />
: 10 Minuten mit dem Auto, [http://map.openseamap.org/map/?zoom=14&mlat=49.58696&mlon=11.37649&mtext=%3Cb%3EIgelwirt%3C%2Fb%3E%0AIgelweg%206%0A91220%20Schnaittach-Osternohe%0A%2B49%209153%204060&layers=BFTFFFTFFTF0FFFFFFTT Karte]<br />
: EZ Ü/F: ab 64 € (59 € ohne Frühstück )<br />
: Igelweg 6, 91220 Schnaittach-Osternohe, +49 9153 4060, [http://www.igelwirt.de/ Igelwirt.de]<br />
<br />
; Gasthof Schuster<br />
: 3 Minuten mit dem Auto, 20 Minuten mit dem Fahrrad [http://map.openseamap.org/map/?zoom=14&mlat=49.56896&mlon=11.33958&mtext=%3Cb%3EGasthof%20Schuster%3C%2Fb%3E%0AKirchenweg%206%0A91220%20Hedersdorf%0A%2B49%209153%201288%20&layers=BTTFFFTFFTF0FFFFFFTT Karte]<br />
: EZ Ü/F 34 € (30 € ohne Frühstück)<br />
: Kirchenweg 6, 91220 Hedersdorf, +49 9153 1288<br />
<br />
== Verpflegung ==<br />
Schön wäre, wenn die Tagesgäste oder "Heimschläfer" Lust hätten, etwas zum Essen zu organisieren. Beispielsweise das Frühstück mitbringen, etwas zum "kalten Buffet", oder Pizza, oder etwas zum Kaffee, oder einen Salat...<br />
Bitte trage hier ein, wenn Du etwas mitbringen willst. Frage bevor Du kommst kurz telefonisch wieviele da sind, oder vielleicht magst Du Pizza-Bestellungen entgegennehmen und die Pizzen abholen und mitbringen?<br />
<br />
Getränke und Tee/Kaffee sind im Haus. Ebenso Aufbackbrötchen und Nudeln für alle Fälle.<br />
<br />
{| class="wikitable"<br />
! style="width: 6em" | wer organisiert || Do || Do Abend || Fr Früh || Fr Mitt || Fr Abend || Sa Früh || Sa Mitt || Sa nachm || Sa Abend || So Früh || So Mitt || So nachm || So Abend || Mo Früh || Bemerkungen<br />
|-<br />
| Markus || X || || || || || || || || || || || || || || Food for all <br />
|-<br />
| Markus || || X || || || || || || || || || || || || || Abendessen bei mir für alle die angemeldet sind<br />
|-<br />
| Markus || || || X || || || X || || || || X || || || || X || Frühstück bei mir für alle die angemeldet sind<br />
|-<br />
| Landgasthof || || || || || X || || || || X || || || || X || || <br />
|-<br />
| .. || || || || || || || || || || || || || || || <br />
|}<br />
<br />
{| class="wikitable"<br />
! class="unsortable" style="width: 6em" | wer isst mit || Do Abend || Fr Früh || Fr Abend || Sa Früh || Sa Mitt || Sa nachm || Sa Abend || So Früh || So Mitt || So nachm || So Abend || Mo Früh || class="unsortable" | Bemerkungen<br />
|-<br />
| Markus || X || X || X || X || X || X || X || X || X || X || X || X || <br />
|-<br />
| Cornelia || || X || X || X || X || X || X || X || X || X || X || X || vegetarisch<br />
|-<br />
| Martin || || || || || X || X || X || X || X || || || || vegetarisch<br />
|-<br />
| .. || || || || || || || || || || || || || <br />
|}<br />
<br />
== Fahrgemeinschaft ==<br />
; Suche<br />
{| class="wikitable"<br />
! wer || ab wo || Abfahrt || Plätze || Bemerkungen<br />
|-<br />
| .. || || || || <br />
|}<br />
<br />
; Biete<br />
{| class="wikitable"<br />
! wer || ab wo || Abfahrt || Plätze || Bemerkungen<br />
|-<br />
| .. || || || || <br />
|}<br />
<br />
Bitte nehmt direkt miteinander Kontakt auf.<br />
<br />
== Zusammenfassung / ToDo ==<br />
* [[OpenSeaMap-dev:10._Entwicklerwochenende/Bericht | Bericht / ToDo]]<br />
* [[OpenSeaMap-dev:9._Entwicklerwochenende/Bericht | Bericht / ToDo Herbst 2015]]<br />
* [[OpenSeaMap-dev:8._Entwicklerwochenende/Bericht | Bericht / ToDo Früjahr 2014]]<br />
* [[OpenSeaMap-dev:7._Entwicklerwochenende/Bericht | Bericht / ToDo Herbst 2013]]<br />
* [[OpenSeaMap-dev:6._Entwicklerwochenende/Bericht | Bericht / ToDo Frühjahr 2013]]</div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:Entwicklerwochenende_2015-04&diff=3416OpenSeaMap-dev:Entwicklerwochenende 2015-042015-03-04T15:16:43Z<p>MartinOver: /* Verpflegung */</p>
<hr />
<div>[[Datei:Konzept OpenSeaMap.jpg|thumb|Konzept von OpenSeaMap]]<br />
<br />
Planung zum 10. Entwicklerwochenende am '''24.-26. 4. 2015'''<br />
<br />
<br />
== Anmeldung ==<br />
[mailto:liste12A45q7@gmx.de?subject=9.%20Entwicklerwochenende%20-%20Anmeldung Anmeldung bitte per Mail] <br>oder besser: gleich hier in der Liste:<br />
{| class="wikitable sortable"<br />
! Nr || Do || Fr || Sa || So || Mo || wer || von wo || Übernachtung || class="unsortable" | Bemerkungen<br />
|-<br />
| 1 || 19:00 || x || x || x || 16:00 || [[Benutzer:Markus|Markus]] || - || - || Orga<br />
|-<br />
| 2 || 19:00 || x || x || x || 07:00 || Cornelia || - || - || Tutorials, Artikel, Website, Support<br />
|-<br />
| 3 || || x ||x || x || || Alexej Humbach|| Aachen (DE) || bei Markus || Karten, Tiden, Wassertiefen<br />
|-<br />
| 4 || || || || || || Joachim Bobrich || Frankfurt/Main (DE) || || Echo, Logger, Anwendungen<br />
|-<br />
| 5 || || || || || || Martin Over || Köln (DE) || || Wassertiefen<br />
|-<br />
| 6 || || || || || || Wolfgang Schildbach || Nürnberg (DE) || - || Daten-Kompression<br />
|-<br />
| 7 || || || || || || Wolfgang Sommers || Erkelenz (DE) || || AT5-Karten<br />
|-<br />
| 8 || || || || || || Marek Skleciak || Erlangen (DE) || - || DEM (Doktorandenstelle), 3D<br />
|-<br />
| 9 || || || || || || Andreas Merz || Erlangen (DE) || - || Wassertiefen, ...<br />
|-<br />
| 10 || || || || || || Herbert Oppmann || Nürnberg (DE) || - || AT5<br />
|-<br />
| 11 || || || || || || ? || ? || || <br />
<!-- |-<br />
| 5 || || || || || || Jens Kübler || Karlsruhe (DE) || || Wassertiefen<br />
|-<br />
| 6 || 19:00 || x || x || x || || Werner König || Velbert (DE) ||bei Markus || WinNav<br />
|-<br />
| 7 || || 19:00 || || || || Hans-Jürgen Beie || Nürnberg (DE) || - || KNF, Typo3<br />
|-<br />
| 8 || || || x || || || Reiner Schmalzl || Nürnberg (DE) || - || Datenschutz, Typo3<br />
|-<br />
| 10 || || 12:00 || x || || || Victor Klein || Essen (DE) || bei Lang || offline Karten Android<br />
|-<br />
| 11 || || || x || || || Thorsten Baur || Bamberg (DE) || || Website, Stategie<br />
|-<br />
| 12 || || || x || || || Thomas Waldecker || München (DE) || bei Markus || Whitewater, Offline chart<br />
|-<br />
| 14 || || 23:00 || x || x || || Niko Ehrenfeuchter || Freiburg (DE) || bei Markus || Server, GitHub<br />
|<br />
| 4 || || || || || || Hakan Tandogan || München (DE) || || <br />
|-<br />
| 5 || || || x || || || Inger Holndonner || Nürnberg (DE) || nein || Tauchen <br />
|-<br />
| 9 || || || || || || Werner ? || || || <br />
|-<br />
| 10 || || || || || || Claas Kähler || Münster (DE) || || <br />
--><br />
|-<br />
| .. || || || || || || || || || <br />
|}<br />
<br />
== Programm ==<br />
Das Programm werden wir je nach anwesenden Personen, Interessen und Prioritäten gestalten <br>und möglichst hier vorher gemeinsam planen. <br />
<br />
Hacking: Gut fände ich, wenn wir wie letztes Mal wieder Zeit für Coding, Scripting, Hacking verwenden.<br />
<br />
Schwerpunkt wird sein:<br />
* Workflow im Entwickler-Team <br>wie können wir unterstützend, effizient, lustvoll, produktiv zusammenarbeiten <br>wie gestalten wir Planung, Doku, Kommunikation<br />
* Servers<br />
* Water depths<br />
* Charts for Android, iOS, Garmin, Lowrance, B&G, Simrad. <br />
* Vector chart (AT5, OsmAnd, S-57)<br />
* ...<br />
<br />
Und natürlich werden wir auch für alle anderen wichtigen Themen Zeit haben: <br>Visionen, Ideen, Pläne zu Apps, Community, Qualität, Server, Tidenrechner, Hafendatenbank, Wassersportwiki, Bericht von "boot", etc, etc.<br />
<br />
; Struktur<br />
: Die Idee ist, dass jeder "Maintainer" bzw. jedes Team eines Projektes ein Zeitfenster hat, <br>um die zentralen Fragen mit allen anderen Entwicklern zu diskutieren und Lösungen bzw Lösungswege zu finden.<br />
: Ergebnis soll jeweils eine ToDo-Liste sein.<br />
: Bewährt hat sich beim letzten Mal, das Treffen auch als Hack-Weekend zu gestalten.<br />
: Und natürlich wie immer Zeit für's Kennenlernen und Fachsimpeln!<br />
<br />
{| class="wikitable"<br />
! Zeit || Thema || Wer || Bemerkungen<br />
|-<br />
| Do || Core-Dev-Meeting || || open for everybody<br />
|-<br />
| Fr || Pre-Dev-Meeting || || open for everybody<br />
|-<br />
| Fr 19:00 || <small>Abendessen</small> || <small>bei Markus</small> || (bitte anmelden)<br />
|-<br />
| Sa 08:00 || <small>Frühstück</small> || <small>Gäste von Markus</small> || wer mag kann gern dazukommen (bitte anmelden)<br />
|-<br />
| '''Sa 09:00''' || Intro || Markus || Rückblick, Ausblick<br />
|-<br />
| Sa 09:30 || Vorstellungsrunde || alle || vermutlich beginnen wir gleich mit der Arbeit, da die Meisten bereits Do/Fr kommen <br />
|-<br />
| Sa 12:00 || || || <br />
|-<br />
| Sa 14:00 || <small>Mittagspause</small> || || "kaltes Buffet"<br />
|-<br />
| Sa 15:00 || || || <br />
|-<br />
| Sa 17:00 || || || <br />
|-<br />
| Sa 19:00 || <small>Abendessen</small> || || Landgasthof<br />
|-<br />
| Sa 20:00 || || || <br />
|-<br />
| So 08:00 || <small>Frühstück</small> || <small>Gäste von Markus</small> || wer mag kann gern dazukommen (bitte anmelden)<br />
|-<br />
| '''So 09:00''' || || || <br />
|-<br />
| So 12:00 || || || <br />
|-<br />
| So 14:00 || || || <br />
|-<br />
| '''So 16:00''' || Ende des Hauptteils || || <br />
|-<br />
| So 18:00 || || || <br />
|-<br />
| So 20:00 || || || <br />
|-<br />
| So 22:00 || || || <br />
|-<br />
| Mo 08:00 || Arbeits-Frühstück || || Rückblick, Planung<br />
|-<br />
| Mo 10:00 || || || Umsetzung? (je nachdem wer noch da ist)<br />
|}<br />
<br />
== Themenvorschläge ==<br />
{| class="wikitable"<br />
! Thema || Prio || wer || Zeit || wer wird gewünscht || Bemerkungen<br />
|-<br />
<!--<br />
| Redaktionsplan Facebook, Website-Gestaltung, Marketing-Konzept || || Cornelia, Thorsten || Sa 9-14 || Markus für Rückfragen || <br />
|-<br />
| Verpflichtung auf Datenschutz BDSG §5, für alle Admins || || Reiner || Sa 15' || alle Admins || <br />
|-<br />
| Serverstruktur aufzeichnen || || Markus || 15' || Alexej, Jens, Matthias, Niko || <br />
|-<br />
| Serverstruktur optimieren (Konzept erstellen) || || Niko || 30' || Alexej, Jens, Matthias, KNF || <br />
|-<br />
| Logger-Vertrieb: 100€ statt 35€, 100 v. 500 verkauft <br>Ziel: Strategie entwickeln || 1 || Markus || 30' || Hans-Jürgen, Wolfgang, Alexej || <br />
|-<br />
| Video/Screencast-Tutorial JOSM || || Cornelia || || Wolfgang || <br />
|-<br />
| WPI-Häfen wieder auf Karte verlinken || || Markus || 30' || Matthias || <br />
|-<br />
| Gespräch mit dem Vorsitzenden des KNF || || Hans-Jürgen || Fr 19, 30' || Plenum || <br />
|-<br />
--><br />
| .. || || || || || <br />
|}<br />
<br />
== Unterkunft ==<br />
<br />
; privat bei Markus<br />
: Bei mir können 3..4 Gäste gratis übernachten. Gern bereits ab Donnerstag bzw bis Montag.<br />
:{| class="wikitable"<br />
! wer || Do || Fr || Sa || So<br />
|-<br />
| Alexej || || x || x || x <br />
|-<br />
| .. || || || || <br />
|}<br />
<br />
; Landgasthof "Lang"<br />
: 5 Minuten zu Fuss, beim Bahnhof Simmelsdorf, [http://map.openseamap.org/?zoom=16&mlat=49.59830&mlon=11.34050&mtext=%3Cb%3ELandgasthaus%20Lang%3C%2Fb%3E%0ABahnhofstra%C3%9Fe%209%0A91245%20Simmelsdorf%0A%2B49%209155%20237&layers=BFTFFFTFFTF0FFFFFFTT Karte]<br />
: EZ Ü/F: ab 33 € (28,20 € ohne Frühstück)<br />
: Bahnhofstraße 9, 91245 Simmelsdorf, +49 9155 237, [http://www.landgasthaus-lang.de/ Landgasthof-Lang.de]<br />
<br />
; Hotel "Igelwirt"<br />
: 10 Minuten mit dem Auto, [http://map.openseamap.org/map/?zoom=14&mlat=49.58696&mlon=11.37649&mtext=%3Cb%3EIgelwirt%3C%2Fb%3E%0AIgelweg%206%0A91220%20Schnaittach-Osternohe%0A%2B49%209153%204060&layers=BFTFFFTFFTF0FFFFFFTT Karte]<br />
: EZ Ü/F: ab 64 € (59 € ohne Frühstück )<br />
: Igelweg 6, 91220 Schnaittach-Osternohe, +49 9153 4060, [http://www.igelwirt.de/ Igelwirt.de]<br />
<br />
; Gasthof Schuster<br />
: 3 Minuten mit dem Auto, 20 Minuten mit dem Fahrrad [http://map.openseamap.org/map/?zoom=14&mlat=49.56896&mlon=11.33958&mtext=%3Cb%3EGasthof%20Schuster%3C%2Fb%3E%0AKirchenweg%206%0A91220%20Hedersdorf%0A%2B49%209153%201288%20&layers=BTTFFFTFFTF0FFFFFFTT Karte]<br />
: EZ Ü/F 34 € (30 € ohne Frühstück)<br />
: Kirchenweg 6, 91220 Hedersdorf, +49 9153 1288<br />
<br />
== Verpflegung ==<br />
Schön wäre, wenn die Tagesgäste oder "Heimschläfer" Lust hätten, etwas zum Essen zu organisieren. Beispielsweise das Frühstück mitbringen, etwas zum "kalten Buffet", oder Pizza, oder etwas zum Kaffee, oder einen Salat...<br />
Bitte trage hier ein, wenn Du etwas mitbringen willst. Frage bevor Du kommst kurz telefonisch wieviele da sind, oder vielleicht magst Du Pizza-Bestellungen entgegennehmen und die Pizzen abholen und mitbringen?<br />
<br />
Getränke und Tee/Kaffee sind im Haus. Ebenso Aufbackbrötchen und Nudeln für alle Fälle.<br />
<br />
{| class="wikitable"<br />
! style="width: 6em" | wer organisiert || Do || Do Abend || Fr Früh || Fr Mitt || Fr Abend || Sa Früh || Sa Mitt || Sa nachm || Sa Abend || So Früh || So Mitt || So nachm || So Abend || Mo Früh || Bemerkungen<br />
|-<br />
| Markus || X || || || || || || || || || || || || || || Food for all <br />
|-<br />
| Markus || || X || || || || || || || || || || || || || Abendessen bei mir für alle die angemeldet sind<br />
|-<br />
| Markus || || || X || || || X || || || || X || || || || X || Frühstück bei mir für alle die angemeldet sind<br />
|-<br />
| Landgasthof || || || || || X || || || || X || || || || X || || <br />
|-<br />
| .. || || || || || || || || || || || || || || || <br />
|}<br />
<br />
{| class="wikitable"<br />
! class="unsortable" style="width: 6em" | wer isst mit || Do Abend || Fr Früh || Fr Abend || Sa Früh || Sa Mitt || Sa nachm || Sa Abend || So Früh || So Mitt || So nachm || So Abend || Mo Früh || class="unsortable" | Bemerkungen<br />
|-<br />
| Markus || X || X || X || X || X || X || X || X || X || X || X || X || <br />
|-<br />
| Cornelia || || X || X || X || X || X || X || X || X || X || X || X || vegetarisch<br />
|-<br />
| Martin || || || || || X || X || X || X || X || || || || vegetarisch<br />
|-<br />
| .. || || || || || || || || || || || || || <br />
|}<br />
<br />
== Fahrgemeinschaft ==<br />
; Suche<br />
{| class="wikitable"<br />
! wer || ab wo || Abfahrt || Plätze || Bemerkungen<br />
|-<br />
| .. || || || || <br />
|}<br />
<br />
; Biete<br />
{| class="wikitable"<br />
! wer || ab wo || Abfahrt || Plätze || Bemerkungen<br />
|-<br />
| .. || || || || <br />
|}<br />
<br />
Bitte nehmt direkt miteinander Kontakt auf.<br />
<br />
== Zusammenfassung / ToDo ==<br />
* [[OpenSeaMap-dev:10._Entwicklerwochenende/Bericht | Bericht / ToDo]]<br />
* [[OpenSeaMap-dev:9._Entwicklerwochenende/Bericht | Bericht / ToDo Herbst 2015]]<br />
* [[OpenSeaMap-dev:8._Entwicklerwochenende/Bericht | Bericht / ToDo Früjahr 2014]]<br />
* [[OpenSeaMap-dev:7._Entwicklerwochenende/Bericht | Bericht / ToDo Herbst 2013]]<br />
* [[OpenSeaMap-dev:6._Entwicklerwochenende/Bericht | Bericht / ToDo Frühjahr 2013]]</div>MartinOverhttps://wiki.openseamap.org/index.php?title=Datei:Balitc_sea_scatter_plot_2_68_all.jpeg&diff=3396Datei:Balitc sea scatter plot 2 68 all.jpeg2015-02-24T19:18:35Z<p>MartinOver: MartinOver lud eine neue Version von „Datei:Balitc sea scatter plot 2 68 all.jpeg“ hoch</p>
<hr />
<div></div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:En:Depth_Data&diff=2980OpenSeaMap-dev:En:Depth Data2014-09-30T20:14:05Z<p>MartinOver: /* Preliminary Conclusions */</p>
<hr />
<div>This Page describes the necessary efforts to retrieve and analyze depth data as well as create renderings from it<br />
<br />
= Data Aquisition =<br />
Depth data can be retrieved from public domain sources or from crowd sourced data.<br />
<br />
== GEBCO ==<br />
DIe Daten sind gerendert und stehen als Layer zur Verfügung:<br />
{| class="wikitable"<br />
! Zoom || Inhalt<br />
|-<br />
| 0..10 || Blaustufen und Schattierung<br />
|-<br />
| 11..18 || beschriftete Tiefenlinien, Blaustufen und Schattierung<br />
|}<br />
<br />
Noch zu lösende Probleme:<br />
* der GEBCO-Layer erzeugt einen milchigen Schleier über der Basiskarte<br />
* Tiefenlinien sind ab z=14 etwas grob (also ab da, wo dann die Flachwassertiefen beginnen) [http://map.openseamap.org/?zoom=14&lat=36.03097&lon=-5.49153&layers=BFTFTTTFFFF0 Karte]<br />
* Überschneidungen von 100m-Linie und Küstenlinie [http://map.openseamap.org/?zoom=15&lat=36.00318&lon=-5.60819&layers=BFFFTTTFFFF0FFFFF Karte]<br />
* Steilküsten (Cuba) [http://map.openseamap.org/?zoom=14&lat=19.94808&lon=-76.04289&layers=BFTFTTTFFFF0 Karte]<br />
<br />
== Crowd Sourced Data ==<br />
Crowd sourced data may be gathered by YOU. There are two options in development. A hardware and a software option.<br />
<br />
=== Workflow ===<br />
[[Datei:Workflow_depth.png]]<br />
<br />
Here you can find the document with the previous thoughts about the workflow:<br />
[http://osm.franken.de/wiki/FWT-Projekt%C3%BCbersicht-NMEA2Contours_2.1.ppt PPT Dokument]<br />
<br />
=== Hardware logger ===<br />
We are currently developing a hardware logger that may easily be plugged to the ship's network in order to log the networks data to a SD card.<br />
That data may then be uploaded by plugging the SD card to a normal computer with internet connection for upload.<br />
The main goal is to support NMEA 0183 data with options for NMEA 2000.<br />
<br />
=== Software logger ===<br />
A [[Software logger]] is in development and [http://seesea.sourceforge.net/datalogger/index.html can be downloaded here]. <br />
<br />
It currently supports: <br />
: Bluetooth <br />
: Serial ports<br />
: Internet Protocol (IP)<br />
It processes NMEA 0183 and AIS data.<br />
<br />
For vendor specific protocols such as SeaTalk 1 you have to use a [[De:NMEA-Logger_anschliessen|converter]] to NMEA 0183 data.<br />
<br />
NMEA 2000 support is only available if data is transcoded to NMEA 0183 by a converter.<br />
<br />
=== Chart Plotters ===<br />
<br />
Some chart plotters are able to save tracks out-of-the-box, e.g. several Raymarine (FSH files) and Humminbird (SON files) devices. Those files may directly be used as data source.<br />
<br />
<br />
=== Upload Process ===<br />
Uploading data is possible through using the [http://seesea.sourceforge.net/datalogger/index.html OpenSeaMap Data Logger Software] or via [http://depth.openseamap.org/ Web Interface].<br />
The system is currently being tested. <br />
<br />
[[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|You'll find further information here]].<br />
<br />
=== Test Data ===<br />
<br />
<br />
==== Brombachsee (Germany)====<br />
<br />
Test data for Openseamap: [http://osm.franken.de/wiki/test_data_brombachsee.zip Brombachsee_Test_Data]<br />
<br />
dgm_brombachsee.tif: Digital Elevation Model of the sea derived from height lines WWA (C).<br />
<br />
shapes_brombachsee.shp: Shape File derived from 4 NMEA Tracks. "dbs" is the original Sounding and "deep_cor" the depth after a correction (gauge levl).<br />
<br />
gpx_brombachsee.gpx: ele = "dbs" from the Shape File<br />
<br />
[[Datei:Brombachsee.png]]<br />
Resulting Digital Elevation Model<br />
<br />
==== Baltic Sea - near Großenbrode (Germany)====<br />
<br />
First results with an RMS error < 1,5 meter compared to an official dataset of the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].<br />
<br />
[[Datei: Bsh_results_overview.jpg]]<br />
<br />
[Picture 1] '''''OSM map in background, raster Depth Model derived from BSH data and crowed sourced OpenSeaMap Points - Overview'''''<br />
<br />
Blue = flat BSH data, red = deep BSH data.<br />
<br>Blue points = OpenSeaMap raw measuring points.<br />
<br />
{| class="wikitable"<br />
|-<br />
| n || 5062<br />
|-<br />
|-<br />
| datasets || 21<br />
|-<br />
| max deviation || 3,43 meters<br />
|-<br />
| mean (abs) || 0,69 meters<br />
|-<br />
| RMS +/- || 0,91 meters<br />
|}<br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| VesselConfig ID || 68<br />
|-<br />
| Manufacturer || Bavaria Yachtbau<br />
|-<br />
| Model || B32<br />
|-<br />
| Length || 10,0 meters<br />
|-<br />
| Beam || 3,35 meters<br />
|-<br />
| Draft || 1,6 meters<br />
|-<br />
| Height || 14 meters<br />
|-<br />
| Displacement || 4,2 t<br />
|-<br />
| Sensor manufacturer || Raymarine<br />
|-<br />
| Sensor Offset to waterline || 0,45 meters<br />
|-<br />
| Sensor Offset to keel || 1,15 meters<br />
|}<br />
<br />
<br />
<br />
A digital Deep Model raster was computed from the BSH point dataset (c).<br />
The depth of the crowed sourced dataset was compared to the derived raster dataset from the BSH.<br />
The raw crowed sourced dataset was corrected by the sensor offset (0,45 meters).<br />
<br />
[[Datei: Scatter_cor_sensor.jpeg]]<br />
<br />
[Picture 2] '''''Scatter plot: BSH data on the x-axis and the crowed sourced data on the y-axis. Trend line in black and optimal line in red.'''''<br />
<br />
The deviation from the reference dataset increases with the depth measured.<br />
<br />
As you see in the picture below the difference between the datasets has an regular pattern maybe deepending on waves.<br />
<br />
[[Datei: Bsh_results_detail_10_classes.jpg]]<br />
<br />
[Picture 3] '''''Crowed sourced OpenSeaMap track points and the difference from the BSH dataset'''''<br />
<br />
White = low difference, orange = medium difference, red = strong difference<br />
<br />
Download of the data http://osm.franken.de/data/baltic_sea_test_data.zip<br />
'''Be aware of the copyright from the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].'''<br />
The data in the dataset is not corrected by sensor offset.<br />
<br />
==== Baltic Sea Olpenitz (Germany)====<br />
<br />
In this test area we have tracks from two different vessel configurations. <br />
The fist one was the one from the test area Großenbrode (config ID 68).<br />
<br />
In the Table below the settings for die vesselconfigid 110 are shown: <br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| VesselConfigId || 110<br />
|-<br />
| Manufacturer || Waarschip<br />
|-<br />
| Model || 570<br />
|-<br />
| Length || 5,7 meters<br />
|-<br />
| Beam || 2,45 meters<br />
|-<br />
| Draft || 1,0 meters<br />
|-<br />
| Height || 9.1 meters<br />
|-<br />
| Displacement || 0,8 t<br />
|-<br />
| Sensor manufacturer || Tacktick/ Airmar<br />
|-<br />
| Sensor Model || T912<br />
|-<br />
| Sensor Offset to waterline || 0,2 meters<br />
|-<br />
| Sensor Offset to keel || 0,45 meters<br />
|}<br />
<br />
[[Datei: Balitc_sea_scatter_plot_2.jpeg]]<br />
<br />
[Picture 1] Scatterplot for vesselconfigID 110. Trendline in Black and optimal line in red (after correction of the sensor offset to waterline).<br />
<br />
{| class="wikitable"<br />
|-<br />
| vsselConfigId || 110<br />
|-<br />
| n || 247<br />
|-<br />
| mean || 0,49 meters<br />
|-<br />
| rms || 0,62 meters<br />
|-<br />
| max|| 2,53 meters<br />
|}<br />
<br />
The distribution is quite different from the data recorded in the test area Großenbrode with an different sensor.<br />
<br />
Fortunately we have also data from the VesselConfigId 68 in this test area to compare the measurements.<br />
<br />
[[Datei: Balitc_sea_scatter_plot_2_68_all.jpeg]]<br />
<br />
[Picture 2] Scatterplot for vesselconfigID 68 after correction of the sensor offset to waterline.<br />
<br />
Obviously there are some outliers which are shown in picture 3.<br />
<br />
[[Datei: Bsh 2 outliers.jpg]]<br />
<br />
[Picture 2] Outliers along the track 9064 in yellow - vesselconfigID 68.<br />
<br />
Without the outliers the behavier of distribution is very same the results in the test area Großenbrode.<br />
<br />
[[Datei: Balitc_sea_scatter_plot_2_68_without.jpeg]]<br />
<br />
[Picture 1] Scatterplot for vesselconfigID 68 without outliers. Trendline in Black and optimal line in red (after correction of the sensor offset to waterline).<br />
<br />
{| class="wikitable"<br />
|-<br />
| vsselConfigId || 68 () without outliers<br />
|-<br />
| n || 100<br />
|-<br />
| mean || 0,38 meters<br />
|-<br />
| rms || 0,53 meters<br />
|-<br />
| max|| 2,1 meters<br />
|}<br />
<br />
==== Preliminary Conclusions ====<br />
<br />
1. The distribution of the data derived from the measurements depends on the sensor. The realationships are almost linear and could be corrected if the sensor is known. Therefore the fill out in the form of the Web Frontend should be obligatory.<br />
<br />
2. The sensor offset to the waterline is very easy to correct and should be obligatory in the fill out in the form.<br />
<br />
3. There are outliers which should be investigated. Perhaps this data could be corrected or identified with the data from the uploaded tracks (speed, etc.).<br />
<br />
=== Meta Data Statistics ===<br />
<br />
Statistics for the metadata entrees with some personal comments (by MartinOver). Stand 20.9.2014.<br />
<br />
{| class="prettytable"<br />
|-<br />
|<br />
'''Step'''<br />
<br />
|<br />
'''Topic'''<br />
<br />
|<br />
'''Count'''<br />
<br />
|<br />
'''State'''<br />
<br />
|<br />
'''Comment'''<br />
<br />
|-<br />
|<br />
1/1<br />
<br />
|<br />
Name<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
1/2<br />
<br />
|<br />
Description<br />
<br />
|<br />
76/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/1<br />
<br />
|<br />
Length<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
Some wrong entrees like mail addresses or comments <br />
<br />
24 “0.00” Values<br />
<br />
|-<br />
|<br />
2/2<br />
<br />
|<br />
Beam<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
37 „0.00“ Values<br />
<br />
|-<br />
|<br />
2/3<br />
<br />
|<br />
Draft<br />
<br />
|<br />
79/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/4<br />
<br />
|<br />
Displacement<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/5<br />
<br />
|<br />
Height<br />
<br />
|<br />
78/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/6<br />
<br />
|<br />
Manufacturer<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Model<br />
<br />
|<br />
49/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Type<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/3<br />
<br />
|<br />
Position below Waterline<br />
<br />
|<br />
57/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Should be Obligatory<br />
<br />
|-<br />
|<br />
3/4<br />
<br />
|<br />
Depth Measurement<br />
<br />
|<br />
?<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Where in DB?<br />
<br />
|-<br />
|<br />
3/5<br />
<br />
|<br />
Sensor Offset to Keel<br />
<br />
|<br />
6/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/6<br />
<br />
|<br />
Producer of Depth Sensor<br />
<br />
|<br />
63/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/7<br />
<br />
|<br />
Device Model<br />
<br />
|<br />
40/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
58 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
51 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/3<br />
<br />
|<br />
Position abbove Waterline<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/4<br />
<br />
|<br />
Producer<br />
<br />
|<br />
77/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/5<br />
<br />
|<br />
Model<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|}<br />
<br />
= Data Preprocessing =<br />
<br />
== Data Condition ==<br />
Raw data is usually erronous and must be corrected<br />
<br />
=== Internal data problems ===<br />
Depth data may be affected by electrical conditions and software implementations<br />
* Data is incomplete and fail their checksum (bus errors from physical transmissions errors)<br />
* Data is retrived out of sequence<br />
* Data is erronous sensor data <br />
** Approximate correctable data i.e. invalid GPS position that may be interpolated<br />
** Uncorrectable data i.e. failed log sensor that shows slow speeds<br />
* Data resolution is low i.e. for energy saving purposes GPS position is updated every 10 seconds instead of every second<br />
* Sensor data is actively miscalibrated i.e. charter companies add additional draft to the sensor depth for safety reasons<br />
<br />
=== External data problems ===<br />
Depth data may be affected by different environmental circumstances <br />
*# The water temperature affects the ultrasound echo. An inhomogen water temperature yields unwanted echos<br />
*# The seabed affects the ultrasound echo<br />
*# The seastate affects the measurement. There even may be waves when there is no wind.<br />
*# Waves may affect the roll of the measuring vessel resulting in steep measurements that are invalid.<br />
*# The sounder sensor is not the position of the GPS antenna. A position offset including heading must be incorporated.<br />
*# The time of the measurement need not correlate with the time the position was received. This may even happen due to processing time of the hard or software.<br />
*# Corrections for tide induced water levels must happen<br />
<br />
Solutions probably are<br />
*# Water temperature may be measure from the sensor, other data may be unavailable<br />
*# Modern sidescan sonar may yield information about the seabed through classifications<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# Position offsets must be provided by the user<br />
*# Time outages may be handled by the filter if precise timestamps are available in recorded data<br />
*# LAT to Mean sea level differences may be calculated from DTU10 worldwide, river gauges need to monitored<br />
<br />
[[Datei:LAT2MSLDiff.png]]<br />
<br />
<br />
== Data Condition Examples / Showcases ==<br />
<br />
=== Missing measurments (Position) ===<br />
Distribution for position updates taken from an example dataset. Left column shows the time between two consecutive measurements, right column shows how many measurements had this time update.<br />
One can see from the distribtion that the sensor is updated every second but many measurements are one or more seconds late.<br />
21 seconds with no position update may result in an instability of the subsequent filter.<br />
<pre><br />
MeasuredPosition3D<br />
GP<br />
0 :4285<br />
1000 :11295<br />
2000 :5056<br />
3000 :2134<br />
4000 :1135<br />
5000 :315<br />
6000 :154<br />
7000 :46<br />
8000 :36<br />
9000 :16<br />
10000 :12<br />
11000 :3<br />
12000 :4<br />
13000 :1<br />
14000 :7<br />
15000 :3<br />
16000 :1<br />
21000 :1<br />
</pre><br />
<br />
=== Missing measurments (Position) with erronous clock ===<br />
This example is at a 10 second position update rate. However the measurment time is faulty causing large negative and positive update rates. The clock jumps by +- one year/month/day/hour. One can further see from the many 0 time measurements that the rate at which data is sent to the nmea bus is higher than the actual position update (data is sent every second, a position update is every 10 seconds)<br />
<pre><br />
MeasuredPosition3D<br />
II<br />
-21340000 :1<br />
-13194000 :1<br />
-7998000 :1<br />
-2674000 :1<br />
-2434000 :1<br />
-2402000 :1<br />
-2030000 :1<br />
-1926000 :1<br />
-1894000 :1<br />
-1806000 :1<br />
-1480000 :1<br />
-1430000 :1<br />
-1382000 :1<br />
-1114000 :1<br />
-814000 :1<br />
-634000 :1<br />
-590000 :1<br />
-546000 :1<br />
-470000 :1<br />
-290000 :1<br />
-230000 :1<br />
-198000 :1<br />
-110000 :1<br />
-94000 :2<br />
0 :182200<br />
5000 :1<br />
10000 :20230<br />
15000 :1<br />
20000 :84<br />
50000 :1<br />
114000 :2<br />
130000 :2<br />
218000 :1<br />
250000 :1<br />
310000 :1<br />
490000 :1<br />
566000 :1<br />
610000 :1<br />
654000 :1<br />
834000 :1<br />
1134000 :1<br />
1402000 :1<br />
1450000 :1</pre><br />
<br />
== Solution Proposal ==<br />
<br />
=== Outline ===<br />
The ship is influenced by the outlined environment which can be observed. Naturally what is observed is not the state of the<br />
ship as i.e. the position if taken from GPS is 95% less than 10m accurate. To improve quality an estimation of the true state yields better results if this noise taken into account properly.<br />
<br />
=== Details ===<br />
The ship moves according to physical laws. For the easist case imagine a ship with constant velocity and direction. For any point in time you can tell where the ship is with easy math. Considering the full blown setup a ships movement is affected by many parameters such as wind speed, water current, waves, tide, and many more. The ship moves also triaxial in a dynamic way in itself (roll, pitch, yaw). Heeling even changes the measurement position with respect to the depth position. In terms of a filter this is called a system model that describes how the state of the ship may change. Given such a state you can measure what your sensor readings are and compare that to where the system thinks you are.<br />
<br />
The [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter] is known to be the best linear estimator for such situations. Unfortunately the system model is not linear which is why the Extended Kalman Filter needs to be used in order to linearize the system at hand.<br />
<br />
Todo:<br />
* Construct ship system model with at least the position state and probably its course and speed or even more (depth)<br />
* Estimate the system variance (This is a hard one, proposals welcome)<br />
* Construct the measurement model according to the data available (GPS, Log)<br />
* Estimate the measurement noise according to specifc sensors (DPGS is more accurate than GPS)<br />
<br />
The estimation with the position and depth can be retrieved and stored in a database.<br />
<br />
Pitfalls:<br />
* If the system noise is badly chosen the estimation of the system state does not converge to the true state / measurement.<br />
* If the system is very detailed the system variance can be reduced. The required cpu time for processing increases<br />
<br />
Benefits:<br />
* Having the best estimation of the true position even if measurements are noisy<br />
* Easy and effective algorithmic processing<br />
<br />
== Analysis == <br />
<br />
=== Data Sets ===<br />
Currently two test data sets are available recorded during trips from Mallorca and the Baltic Sea.<br />
In terms of data quality the Mallorca data shows many challenges. <br />
* The minimum recommended sentences from NMEA showed up with false date and time readings while having correct (!!!) message checksums. <br />
* The log on the ship was defective and delivered no readings from time to time. <br />
* The same holds true for the water temperature.<br />
* The GPS positions relatively imprecise because some last decimal digits are missing in the recordings.<br />
* The GPS positions are updated every 10 seconds while other sensor readings update almost every second.<br />
* The GPS position are sometimes way off due to false readings<br />
<br />
The Baltic Sea data set is a little bit better<br />
* Only a single day is available<br />
* GPS positions are updated every second<br />
<br />
One problem with the data is that there is time available when sensor readings were recorded. This yields problems to the filter algorithm.<br />
<br />
<br />
=== Filter Algorithm ===<br />
At first the Extended Kalman Filter is being analyzed. Using an apache implementation with the available data the filter quickly throw an exception that<br />
a matrix is not invertible because of numeric instabilities. When removing this exception the filter seems to work but the removal and its effects have yet to be analyzed.<br />
Literature suggest that a fixed interval smoother may yield better results in case of offline data processing. As it is an extension to the existing kalman filter<br />
we may consider that for the future.<br />
<br />
One problem are the different update rates of the sensors. As GPS may deliver positions at 0.1Hz speed is updated at 1Hz. Literature suggests that<br />
the missing measurements shell be modelled as a random variable with the standard deviation of the sensor. It may even be possible to update covariance matrices only partially with the sensor readings received. Input for the best solution may be formulated on the developer mailing list.<br />
<br />
== Results == <br />
A prototype implementation is shown in the following screenshots. An Extended Kalman Filter is being used. It has the position<br />
and the current bearing and velocity as system state. The input is the measurement of these four observables. The system function is<br />
good old pythagoras. In a first implementation I tried to use orthodrome distances but the system function is not differentiable which is a requirement of the Extended Kalman Filter (due to acrtan2). For small distances pythagoras should be sufficiently accurate. <br />
The initial state is taken from the first measurement for convergence reasons.<br />
<br />
The following gallery shows the results. <br />
* You can see the bad position resolution and an outlier in the first screenshot.<br />
* The second shows the same data overlaid with the applied filter. The outlier is gone and the resolution has improved.<br />
* The third screenshot shows data from a different GPS sensor with more precision (not DGPS) versus the filtered data.<br />
<br />
This of course is just a preliminary test and many setups need to be considered to make it work for most datasets.<br />
<br />
<gallery><br />
UnfilteredNMEA.png | Unfiltered GPS data<br />
FilteredNMEAVsOriginal.png | Unfiltered GPS data and Filtered GPS data<br />
PreciseGPSvsFilter.png | Another precise GPS vs Filtered GPS data<br />
</gallery><br />
<br />
The overall process even gives an estimation of the current error which is a capability of the [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter].<br />
This way positional inaccuracies may be added to the overall depth measurement inaccuracy.<br />
<br />
== Quality rating ==<br />
<br />
Each record (time, positon, depth) should become a quality rating.<br />
<br />
=== Points ===<br />
<br />
Derived from the Fibonacci series.<br />
<br />
{| class="wikitable"<br />
! Point || Description<br />
|-<br />
| 1 || extra small improvement<br />
|-<br />
| 2 || small improvement<br />
|-<br />
| 3 || medium improvement<br />
|-<br />
| 5 || large improvement<br />
|-<br />
| 8 || extra large improvement<br />
|}<br />
<br />
=== Factors ===<br />
<br />
{| class="wikitable"<br />
! style="width:15%" | Name<br />
! style="width:17%" | Factor<br />
! style="width:68%" | Description<br />
|-<br />
| depth offset || 8 (extra large) || The difference between the depth measured by the echo sounder and the depth (waterline) measured by hand.<br />
|-<br />
| device distance || 3 (medium) || The distance between gps antenna and echo sounder (lengthwise and crosswise).<br />
|-<br />
| SBAS || 3 (medium) || Satellite based augmentation system (WAAS, EGNOS, MSAS) which allows to correct the gps position.<br />
|-<br />
| position interpolation || 2 (small improvement) || Arrival of depth and position packets can have a time difference. It is/should be possible to interpolate the position.<br />
|}<br />
<br />
= Depth Rendering =<br />
<br />
= Siehe auch =<br />
* [[De:Bordnetz|Bordnetz]]<br />
* [[De:NMEA-Logger_anschliessen|NMEA-Logger_anschliessen]]<br />
* [http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCkQFjAA&url=http%3A%2F%2Fwww.dei.unipd.it%2F~chiuso%2FDOWNLOAD%2FPositioning_Heading_Kalman.pdf&ei=sSWNUMWnL4eC4gTRlYHAAw&usg=AFQjCNHq5V-PePNmDTZaGYvq0JeQFgqHVw Kalman Filtering for Positioning and Heading Control of Ships and Offshore Rigs]<br />
* [http://users.isr.ist.utl.pt/~pedro/publications/CAMS10.pdf A Multiple Model Adaptive Wave Filter for Dynamic Ship Positioning]<br />
* [http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4449205&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4449205 Echosounder Depth Tracking with the Extended Kalman Filter]</div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:En:Depth_Data&diff=2979OpenSeaMap-dev:En:Depth Data2014-09-30T20:09:38Z<p>MartinOver: /* preliminary Conclusions */</p>
<hr />
<div>This Page describes the necessary efforts to retrieve and analyze depth data as well as create renderings from it<br />
<br />
= Data Aquisition =<br />
Depth data can be retrieved from public domain sources or from crowd sourced data.<br />
<br />
== GEBCO ==<br />
DIe Daten sind gerendert und stehen als Layer zur Verfügung:<br />
{| class="wikitable"<br />
! Zoom || Inhalt<br />
|-<br />
| 0..10 || Blaustufen und Schattierung<br />
|-<br />
| 11..18 || beschriftete Tiefenlinien, Blaustufen und Schattierung<br />
|}<br />
<br />
Noch zu lösende Probleme:<br />
* der GEBCO-Layer erzeugt einen milchigen Schleier über der Basiskarte<br />
* Tiefenlinien sind ab z=14 etwas grob (also ab da, wo dann die Flachwassertiefen beginnen) [http://map.openseamap.org/?zoom=14&lat=36.03097&lon=-5.49153&layers=BFTFTTTFFFF0 Karte]<br />
* Überschneidungen von 100m-Linie und Küstenlinie [http://map.openseamap.org/?zoom=15&lat=36.00318&lon=-5.60819&layers=BFFFTTTFFFF0FFFFF Karte]<br />
* Steilküsten (Cuba) [http://map.openseamap.org/?zoom=14&lat=19.94808&lon=-76.04289&layers=BFTFTTTFFFF0 Karte]<br />
<br />
== Crowd Sourced Data ==<br />
Crowd sourced data may be gathered by YOU. There are two options in development. A hardware and a software option.<br />
<br />
=== Workflow ===<br />
[[Datei:Workflow_depth.png]]<br />
<br />
Here you can find the document with the previous thoughts about the workflow:<br />
[http://osm.franken.de/wiki/FWT-Projekt%C3%BCbersicht-NMEA2Contours_2.1.ppt PPT Dokument]<br />
<br />
=== Hardware logger ===<br />
We are currently developing a hardware logger that may easily be plugged to the ship's network in order to log the networks data to a SD card.<br />
That data may then be uploaded by plugging the SD card to a normal computer with internet connection for upload.<br />
The main goal is to support NMEA 0183 data with options for NMEA 2000.<br />
<br />
=== Software logger ===<br />
A [[Software logger]] is in development and [http://seesea.sourceforge.net/datalogger/index.html can be downloaded here]. <br />
<br />
It currently supports: <br />
: Bluetooth <br />
: Serial ports<br />
: Internet Protocol (IP)<br />
It processes NMEA 0183 and AIS data.<br />
<br />
For vendor specific protocols such as SeaTalk 1 you have to use a [[De:NMEA-Logger_anschliessen|converter]] to NMEA 0183 data.<br />
<br />
NMEA 2000 support is only available if data is transcoded to NMEA 0183 by a converter.<br />
<br />
=== Chart Plotters ===<br />
<br />
Some chart plotters are able to save tracks out-of-the-box, e.g. several Raymarine (FSH files) and Humminbird (SON files) devices. Those files may directly be used as data source.<br />
<br />
<br />
=== Upload Process ===<br />
Uploading data is possible through using the [http://seesea.sourceforge.net/datalogger/index.html OpenSeaMap Data Logger Software] or via [http://depth.openseamap.org/ Web Interface].<br />
The system is currently being tested. <br />
<br />
[[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|You'll find further information here]].<br />
<br />
=== Test Data ===<br />
<br />
<br />
==== Brombachsee (Germany)====<br />
<br />
Test data for Openseamap: [http://osm.franken.de/wiki/test_data_brombachsee.zip Brombachsee_Test_Data]<br />
<br />
dgm_brombachsee.tif: Digital Elevation Model of the sea derived from height lines WWA (C).<br />
<br />
shapes_brombachsee.shp: Shape File derived from 4 NMEA Tracks. "dbs" is the original Sounding and "deep_cor" the depth after a correction (gauge levl).<br />
<br />
gpx_brombachsee.gpx: ele = "dbs" from the Shape File<br />
<br />
[[Datei:Brombachsee.png]]<br />
Resulting Digital Elevation Model<br />
<br />
==== Baltic Sea - near Großenbrode (Germany)====<br />
<br />
First results with an RMS error < 1,5 meter compared to an official dataset of the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].<br />
<br />
[[Datei: Bsh_results_overview.jpg]]<br />
<br />
[Picture 1] '''''OSM map in background, raster Depth Model derived from BSH data and crowed sourced OpenSeaMap Points - Overview'''''<br />
<br />
Blue = flat BSH data, red = deep BSH data.<br />
<br>Blue points = OpenSeaMap raw measuring points.<br />
<br />
{| class="wikitable"<br />
|-<br />
| n || 5062<br />
|-<br />
|-<br />
| datasets || 21<br />
|-<br />
| max deviation || 3,43 meters<br />
|-<br />
| mean (abs) || 0,69 meters<br />
|-<br />
| RMS +/- || 0,91 meters<br />
|}<br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| VesselConfig ID || 68<br />
|-<br />
| Manufacturer || Bavaria Yachtbau<br />
|-<br />
| Model || B32<br />
|-<br />
| Length || 10,0 meters<br />
|-<br />
| Beam || 3,35 meters<br />
|-<br />
| Draft || 1,6 meters<br />
|-<br />
| Height || 14 meters<br />
|-<br />
| Displacement || 4,2 t<br />
|-<br />
| Sensor manufacturer || Raymarine<br />
|-<br />
| Sensor Offset to waterline || 0,45 meters<br />
|-<br />
| Sensor Offset to keel || 1,15 meters<br />
|}<br />
<br />
<br />
<br />
A digital Deep Model raster was computed from the BSH point dataset (c).<br />
The depth of the crowed sourced dataset was compared to the derived raster dataset from the BSH.<br />
The raw crowed sourced dataset was corrected by the sensor offset (0,45 meters).<br />
<br />
[[Datei: Scatter_cor_sensor.jpeg]]<br />
<br />
[Picture 2] '''''Scatter plot: BSH data on the x-axis and the crowed sourced data on the y-axis. Trend line in black and optimal line in red.'''''<br />
<br />
The deviation from the reference dataset increases with the depth measured.<br />
<br />
As you see in the picture below the difference between the datasets has an regular pattern maybe deepending on waves.<br />
<br />
[[Datei: Bsh_results_detail_10_classes.jpg]]<br />
<br />
[Picture 3] '''''Crowed sourced OpenSeaMap track points and the difference from the BSH dataset'''''<br />
<br />
White = low difference, orange = medium difference, red = strong difference<br />
<br />
Download of the data http://osm.franken.de/data/baltic_sea_test_data.zip<br />
'''Be aware of the copyright from the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].'''<br />
The data in the dataset is not corrected by sensor offset.<br />
<br />
==== Baltic Sea Olpenitz (Germany)====<br />
<br />
In this test area we have tracks from two different vessel configurations. <br />
The fist one was the one from the test area Großenbrode (config ID 68).<br />
<br />
In the Table below the settings for die vesselconfigid 110 are shown: <br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| VesselConfigId || 110<br />
|-<br />
| Manufacturer || Waarschip<br />
|-<br />
| Model || 570<br />
|-<br />
| Length || 5,7 meters<br />
|-<br />
| Beam || 2,45 meters<br />
|-<br />
| Draft || 1,0 meters<br />
|-<br />
| Height || 9.1 meters<br />
|-<br />
| Displacement || 0,8 t<br />
|-<br />
| Sensor manufacturer || Tacktick/ Airmar<br />
|-<br />
| Sensor Model || T912<br />
|-<br />
| Sensor Offset to waterline || 0,2 meters<br />
|-<br />
| Sensor Offset to keel || 0,45 meters<br />
|}<br />
<br />
[[Datei: Balitc_sea_scatter_plot_2.jpeg]]<br />
<br />
[Picture 1] Scatterplot for vesselconfigID 110. Trendline in Black and optimal line in red (after correction of the sensor offset to waterline).<br />
<br />
{| class="wikitable"<br />
|-<br />
| vsselConfigId || 110<br />
|-<br />
| n || 247<br />
|-<br />
| mean || 0,49 meters<br />
|-<br />
| rms || 0,62 meters<br />
|-<br />
| max|| 2,53 meters<br />
|}<br />
<br />
The distribution is quite different from the data recorded in the test area Großenbrode with an different sensor.<br />
<br />
Fortunately we have also data from the VesselConfigId 68 in this test area to compare the measurements.<br />
<br />
[[Datei: Balitc_sea_scatter_plot_2_68_all.jpeg]]<br />
<br />
[Picture 2] Scatterplot for vesselconfigID 68 after correction of the sensor offset to waterline.<br />
<br />
Obviously there are some outliers which are shown in picture 3.<br />
<br />
[[Datei: Bsh 2 outliers.jpg]]<br />
<br />
[Picture 2] Outliers along the track 9064 in yellow - vesselconfigID 68.<br />
<br />
Without the outliers the behavier of distribution is very same the results in the test area Großenbrode.<br />
<br />
[[Datei: Balitc_sea_scatter_plot_2_68_without.jpeg]]<br />
<br />
[Picture 1] Scatterplot for vesselconfigID 68 without outliers. Trendline in Black and optimal line in red (after correction of the sensor offset to waterline).<br />
<br />
{| class="wikitable"<br />
|-<br />
| vsselConfigId || 68 () without outliers<br />
|-<br />
| n || 100<br />
|-<br />
| mean || 0,38 meters<br />
|-<br />
| rms || 0,53 meters<br />
|-<br />
| max|| 2,1 meters<br />
|}<br />
<br />
==== Preliminary Conclusions ====<br />
<br />
1. The distribution of the data derived from the measurements depends on the sensor. The realationships are almost linear and could be corrected if the sensor is known. Therefore the fill out in the form of the Web Frontend should be obligatory.<br />
<br />
2. The sensor offset to the waterline is very easy to correct and should be obligatory in the fill out in the form.<br />
<br />
3. There are outliers which should be investigated. Perhaps this data could be corrected or idnetified with the data from the uploaded tracks (speed, etc.).<br />
<br />
=== Meta Data Statistics ===<br />
<br />
Statistics for the metadata entrees with some personal comments (by MartinOver). Stand 20.9.2014.<br />
<br />
{| class="prettytable"<br />
|-<br />
|<br />
'''Step'''<br />
<br />
|<br />
'''Topic'''<br />
<br />
|<br />
'''Count'''<br />
<br />
|<br />
'''State'''<br />
<br />
|<br />
'''Comment'''<br />
<br />
|-<br />
|<br />
1/1<br />
<br />
|<br />
Name<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
1/2<br />
<br />
|<br />
Description<br />
<br />
|<br />
76/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/1<br />
<br />
|<br />
Length<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
Some wrong entrees like mail addresses or comments <br />
<br />
24 “0.00” Values<br />
<br />
|-<br />
|<br />
2/2<br />
<br />
|<br />
Beam<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
37 „0.00“ Values<br />
<br />
|-<br />
|<br />
2/3<br />
<br />
|<br />
Draft<br />
<br />
|<br />
79/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/4<br />
<br />
|<br />
Displacement<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/5<br />
<br />
|<br />
Height<br />
<br />
|<br />
78/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/6<br />
<br />
|<br />
Manufacturer<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Model<br />
<br />
|<br />
49/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Type<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/3<br />
<br />
|<br />
Position below Waterline<br />
<br />
|<br />
57/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Should be Obligatory<br />
<br />
|-<br />
|<br />
3/4<br />
<br />
|<br />
Depth Measurement<br />
<br />
|<br />
?<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Where in DB?<br />
<br />
|-<br />
|<br />
3/5<br />
<br />
|<br />
Sensor Offset to Keel<br />
<br />
|<br />
6/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/6<br />
<br />
|<br />
Producer of Depth Sensor<br />
<br />
|<br />
63/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/7<br />
<br />
|<br />
Device Model<br />
<br />
|<br />
40/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
58 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
51 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/3<br />
<br />
|<br />
Position abbove Waterline<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/4<br />
<br />
|<br />
Producer<br />
<br />
|<br />
77/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/5<br />
<br />
|<br />
Model<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|}<br />
<br />
= Data Preprocessing =<br />
<br />
== Data Condition ==<br />
Raw data is usually erronous and must be corrected<br />
<br />
=== Internal data problems ===<br />
Depth data may be affected by electrical conditions and software implementations<br />
* Data is incomplete and fail their checksum (bus errors from physical transmissions errors)<br />
* Data is retrived out of sequence<br />
* Data is erronous sensor data <br />
** Approximate correctable data i.e. invalid GPS position that may be interpolated<br />
** Uncorrectable data i.e. failed log sensor that shows slow speeds<br />
* Data resolution is low i.e. for energy saving purposes GPS position is updated every 10 seconds instead of every second<br />
* Sensor data is actively miscalibrated i.e. charter companies add additional draft to the sensor depth for safety reasons<br />
<br />
=== External data problems ===<br />
Depth data may be affected by different environmental circumstances <br />
*# The water temperature affects the ultrasound echo. An inhomogen water temperature yields unwanted echos<br />
*# The seabed affects the ultrasound echo<br />
*# The seastate affects the measurement. There even may be waves when there is no wind.<br />
*# Waves may affect the roll of the measuring vessel resulting in steep measurements that are invalid.<br />
*# The sounder sensor is not the position of the GPS antenna. A position offset including heading must be incorporated.<br />
*# The time of the measurement need not correlate with the time the position was received. This may even happen due to processing time of the hard or software.<br />
*# Corrections for tide induced water levels must happen<br />
<br />
Solutions probably are<br />
*# Water temperature may be measure from the sensor, other data may be unavailable<br />
*# Modern sidescan sonar may yield information about the seabed through classifications<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# Position offsets must be provided by the user<br />
*# Time outages may be handled by the filter if precise timestamps are available in recorded data<br />
*# LAT to Mean sea level differences may be calculated from DTU10 worldwide, river gauges need to monitored<br />
<br />
[[Datei:LAT2MSLDiff.png]]<br />
<br />
<br />
== Data Condition Examples / Showcases ==<br />
<br />
=== Missing measurments (Position) ===<br />
Distribution for position updates taken from an example dataset. Left column shows the time between two consecutive measurements, right column shows how many measurements had this time update.<br />
One can see from the distribtion that the sensor is updated every second but many measurements are one or more seconds late.<br />
21 seconds with no position update may result in an instability of the subsequent filter.<br />
<pre><br />
MeasuredPosition3D<br />
GP<br />
0 :4285<br />
1000 :11295<br />
2000 :5056<br />
3000 :2134<br />
4000 :1135<br />
5000 :315<br />
6000 :154<br />
7000 :46<br />
8000 :36<br />
9000 :16<br />
10000 :12<br />
11000 :3<br />
12000 :4<br />
13000 :1<br />
14000 :7<br />
15000 :3<br />
16000 :1<br />
21000 :1<br />
</pre><br />
<br />
=== Missing measurments (Position) with erronous clock ===<br />
This example is at a 10 second position update rate. However the measurment time is faulty causing large negative and positive update rates. The clock jumps by +- one year/month/day/hour. One can further see from the many 0 time measurements that the rate at which data is sent to the nmea bus is higher than the actual position update (data is sent every second, a position update is every 10 seconds)<br />
<pre><br />
MeasuredPosition3D<br />
II<br />
-21340000 :1<br />
-13194000 :1<br />
-7998000 :1<br />
-2674000 :1<br />
-2434000 :1<br />
-2402000 :1<br />
-2030000 :1<br />
-1926000 :1<br />
-1894000 :1<br />
-1806000 :1<br />
-1480000 :1<br />
-1430000 :1<br />
-1382000 :1<br />
-1114000 :1<br />
-814000 :1<br />
-634000 :1<br />
-590000 :1<br />
-546000 :1<br />
-470000 :1<br />
-290000 :1<br />
-230000 :1<br />
-198000 :1<br />
-110000 :1<br />
-94000 :2<br />
0 :182200<br />
5000 :1<br />
10000 :20230<br />
15000 :1<br />
20000 :84<br />
50000 :1<br />
114000 :2<br />
130000 :2<br />
218000 :1<br />
250000 :1<br />
310000 :1<br />
490000 :1<br />
566000 :1<br />
610000 :1<br />
654000 :1<br />
834000 :1<br />
1134000 :1<br />
1402000 :1<br />
1450000 :1</pre><br />
<br />
== Solution Proposal ==<br />
<br />
=== Outline ===<br />
The ship is influenced by the outlined environment which can be observed. Naturally what is observed is not the state of the<br />
ship as i.e. the position if taken from GPS is 95% less than 10m accurate. To improve quality an estimation of the true state yields better results if this noise taken into account properly.<br />
<br />
=== Details ===<br />
The ship moves according to physical laws. For the easist case imagine a ship with constant velocity and direction. For any point in time you can tell where the ship is with easy math. Considering the full blown setup a ships movement is affected by many parameters such as wind speed, water current, waves, tide, and many more. The ship moves also triaxial in a dynamic way in itself (roll, pitch, yaw). Heeling even changes the measurement position with respect to the depth position. In terms of a filter this is called a system model that describes how the state of the ship may change. Given such a state you can measure what your sensor readings are and compare that to where the system thinks you are.<br />
<br />
The [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter] is known to be the best linear estimator for such situations. Unfortunately the system model is not linear which is why the Extended Kalman Filter needs to be used in order to linearize the system at hand.<br />
<br />
Todo:<br />
* Construct ship system model with at least the position state and probably its course and speed or even more (depth)<br />
* Estimate the system variance (This is a hard one, proposals welcome)<br />
* Construct the measurement model according to the data available (GPS, Log)<br />
* Estimate the measurement noise according to specifc sensors (DPGS is more accurate than GPS)<br />
<br />
The estimation with the position and depth can be retrieved and stored in a database.<br />
<br />
Pitfalls:<br />
* If the system noise is badly chosen the estimation of the system state does not converge to the true state / measurement.<br />
* If the system is very detailed the system variance can be reduced. The required cpu time for processing increases<br />
<br />
Benefits:<br />
* Having the best estimation of the true position even if measurements are noisy<br />
* Easy and effective algorithmic processing<br />
<br />
== Analysis == <br />
<br />
=== Data Sets ===<br />
Currently two test data sets are available recorded during trips from Mallorca and the Baltic Sea.<br />
In terms of data quality the Mallorca data shows many challenges. <br />
* The minimum recommended sentences from NMEA showed up with false date and time readings while having correct (!!!) message checksums. <br />
* The log on the ship was defective and delivered no readings from time to time. <br />
* The same holds true for the water temperature.<br />
* The GPS positions relatively imprecise because some last decimal digits are missing in the recordings.<br />
* The GPS positions are updated every 10 seconds while other sensor readings update almost every second.<br />
* The GPS position are sometimes way off due to false readings<br />
<br />
The Baltic Sea data set is a little bit better<br />
* Only a single day is available<br />
* GPS positions are updated every second<br />
<br />
One problem with the data is that there is time available when sensor readings were recorded. This yields problems to the filter algorithm.<br />
<br />
<br />
=== Filter Algorithm ===<br />
At first the Extended Kalman Filter is being analyzed. Using an apache implementation with the available data the filter quickly throw an exception that<br />
a matrix is not invertible because of numeric instabilities. When removing this exception the filter seems to work but the removal and its effects have yet to be analyzed.<br />
Literature suggest that a fixed interval smoother may yield better results in case of offline data processing. As it is an extension to the existing kalman filter<br />
we may consider that for the future.<br />
<br />
One problem are the different update rates of the sensors. As GPS may deliver positions at 0.1Hz speed is updated at 1Hz. Literature suggests that<br />
the missing measurements shell be modelled as a random variable with the standard deviation of the sensor. It may even be possible to update covariance matrices only partially with the sensor readings received. Input for the best solution may be formulated on the developer mailing list.<br />
<br />
== Results == <br />
A prototype implementation is shown in the following screenshots. An Extended Kalman Filter is being used. It has the position<br />
and the current bearing and velocity as system state. The input is the measurement of these four observables. The system function is<br />
good old pythagoras. In a first implementation I tried to use orthodrome distances but the system function is not differentiable which is a requirement of the Extended Kalman Filter (due to acrtan2). For small distances pythagoras should be sufficiently accurate. <br />
The initial state is taken from the first measurement for convergence reasons.<br />
<br />
The following gallery shows the results. <br />
* You can see the bad position resolution and an outlier in the first screenshot.<br />
* The second shows the same data overlaid with the applied filter. The outlier is gone and the resolution has improved.<br />
* The third screenshot shows data from a different GPS sensor with more precision (not DGPS) versus the filtered data.<br />
<br />
This of course is just a preliminary test and many setups need to be considered to make it work for most datasets.<br />
<br />
<gallery><br />
UnfilteredNMEA.png | Unfiltered GPS data<br />
FilteredNMEAVsOriginal.png | Unfiltered GPS data and Filtered GPS data<br />
PreciseGPSvsFilter.png | Another precise GPS vs Filtered GPS data<br />
</gallery><br />
<br />
The overall process even gives an estimation of the current error which is a capability of the [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter].<br />
This way positional inaccuracies may be added to the overall depth measurement inaccuracy.<br />
<br />
== Quality rating ==<br />
<br />
Each record (time, positon, depth) should become a quality rating.<br />
<br />
=== Points ===<br />
<br />
Derived from the Fibonacci series.<br />
<br />
{| class="wikitable"<br />
! Point || Description<br />
|-<br />
| 1 || extra small improvement<br />
|-<br />
| 2 || small improvement<br />
|-<br />
| 3 || medium improvement<br />
|-<br />
| 5 || large improvement<br />
|-<br />
| 8 || extra large improvement<br />
|}<br />
<br />
=== Factors ===<br />
<br />
{| class="wikitable"<br />
! style="width:15%" | Name<br />
! style="width:17%" | Factor<br />
! style="width:68%" | Description<br />
|-<br />
| depth offset || 8 (extra large) || The difference between the depth measured by the echo sounder and the depth (waterline) measured by hand.<br />
|-<br />
| device distance || 3 (medium) || The distance between gps antenna and echo sounder (lengthwise and crosswise).<br />
|-<br />
| SBAS || 3 (medium) || Satellite based augmentation system (WAAS, EGNOS, MSAS) which allows to correct the gps position.<br />
|-<br />
| position interpolation || 2 (small improvement) || Arrival of depth and position packets can have a time difference. It is/should be possible to interpolate the position.<br />
|}<br />
<br />
= Depth Rendering =<br />
<br />
= Siehe auch =<br />
* [[De:Bordnetz|Bordnetz]]<br />
* [[De:NMEA-Logger_anschliessen|NMEA-Logger_anschliessen]]<br />
* [http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCkQFjAA&url=http%3A%2F%2Fwww.dei.unipd.it%2F~chiuso%2FDOWNLOAD%2FPositioning_Heading_Kalman.pdf&ei=sSWNUMWnL4eC4gTRlYHAAw&usg=AFQjCNHq5V-PePNmDTZaGYvq0JeQFgqHVw Kalman Filtering for Positioning and Heading Control of Ships and Offshore Rigs]<br />
* [http://users.isr.ist.utl.pt/~pedro/publications/CAMS10.pdf A Multiple Model Adaptive Wave Filter for Dynamic Ship Positioning]<br />
* [http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4449205&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4449205 Echosounder Depth Tracking with the Extended Kalman Filter]</div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:En:Depth_Data&diff=2978OpenSeaMap-dev:En:Depth Data2014-09-30T20:00:26Z<p>MartinOver: /* Baltic Sea Olpenitz (Germany) */</p>
<hr />
<div>This Page describes the necessary efforts to retrieve and analyze depth data as well as create renderings from it<br />
<br />
= Data Aquisition =<br />
Depth data can be retrieved from public domain sources or from crowd sourced data.<br />
<br />
== GEBCO ==<br />
DIe Daten sind gerendert und stehen als Layer zur Verfügung:<br />
{| class="wikitable"<br />
! Zoom || Inhalt<br />
|-<br />
| 0..10 || Blaustufen und Schattierung<br />
|-<br />
| 11..18 || beschriftete Tiefenlinien, Blaustufen und Schattierung<br />
|}<br />
<br />
Noch zu lösende Probleme:<br />
* der GEBCO-Layer erzeugt einen milchigen Schleier über der Basiskarte<br />
* Tiefenlinien sind ab z=14 etwas grob (also ab da, wo dann die Flachwassertiefen beginnen) [http://map.openseamap.org/?zoom=14&lat=36.03097&lon=-5.49153&layers=BFTFTTTFFFF0 Karte]<br />
* Überschneidungen von 100m-Linie und Küstenlinie [http://map.openseamap.org/?zoom=15&lat=36.00318&lon=-5.60819&layers=BFFFTTTFFFF0FFFFF Karte]<br />
* Steilküsten (Cuba) [http://map.openseamap.org/?zoom=14&lat=19.94808&lon=-76.04289&layers=BFTFTTTFFFF0 Karte]<br />
<br />
== Crowd Sourced Data ==<br />
Crowd sourced data may be gathered by YOU. There are two options in development. A hardware and a software option.<br />
<br />
=== Workflow ===<br />
[[Datei:Workflow_depth.png]]<br />
<br />
Here you can find the document with the previous thoughts about the workflow:<br />
[http://osm.franken.de/wiki/FWT-Projekt%C3%BCbersicht-NMEA2Contours_2.1.ppt PPT Dokument]<br />
<br />
=== Hardware logger ===<br />
We are currently developing a hardware logger that may easily be plugged to the ship's network in order to log the networks data to a SD card.<br />
That data may then be uploaded by plugging the SD card to a normal computer with internet connection for upload.<br />
The main goal is to support NMEA 0183 data with options for NMEA 2000.<br />
<br />
=== Software logger ===<br />
A [[Software logger]] is in development and [http://seesea.sourceforge.net/datalogger/index.html can be downloaded here]. <br />
<br />
It currently supports: <br />
: Bluetooth <br />
: Serial ports<br />
: Internet Protocol (IP)<br />
It processes NMEA 0183 and AIS data.<br />
<br />
For vendor specific protocols such as SeaTalk 1 you have to use a [[De:NMEA-Logger_anschliessen|converter]] to NMEA 0183 data.<br />
<br />
NMEA 2000 support is only available if data is transcoded to NMEA 0183 by a converter.<br />
<br />
=== Chart Plotters ===<br />
<br />
Some chart plotters are able to save tracks out-of-the-box, e.g. several Raymarine (FSH files) and Humminbird (SON files) devices. Those files may directly be used as data source.<br />
<br />
<br />
=== Upload Process ===<br />
Uploading data is possible through using the [http://seesea.sourceforge.net/datalogger/index.html OpenSeaMap Data Logger Software] or via [http://depth.openseamap.org/ Web Interface].<br />
The system is currently being tested. <br />
<br />
[[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|You'll find further information here]].<br />
<br />
=== Test Data ===<br />
<br />
<br />
==== Brombachsee (Germany)====<br />
<br />
Test data for Openseamap: [http://osm.franken.de/wiki/test_data_brombachsee.zip Brombachsee_Test_Data]<br />
<br />
dgm_brombachsee.tif: Digital Elevation Model of the sea derived from height lines WWA (C).<br />
<br />
shapes_brombachsee.shp: Shape File derived from 4 NMEA Tracks. "dbs" is the original Sounding and "deep_cor" the depth after a correction (gauge levl).<br />
<br />
gpx_brombachsee.gpx: ele = "dbs" from the Shape File<br />
<br />
[[Datei:Brombachsee.png]]<br />
Resulting Digital Elevation Model<br />
<br />
==== Baltic Sea - near Großenbrode (Germany)====<br />
<br />
First results with an RMS error < 1,5 meter compared to an official dataset of the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].<br />
<br />
[[Datei: Bsh_results_overview.jpg]]<br />
<br />
[Picture 1] '''''OSM map in background, raster Depth Model derived from BSH data and crowed sourced OpenSeaMap Points - Overview'''''<br />
<br />
Blue = flat BSH data, red = deep BSH data.<br />
<br>Blue points = OpenSeaMap raw measuring points.<br />
<br />
{| class="wikitable"<br />
|-<br />
| n || 5062<br />
|-<br />
|-<br />
| datasets || 21<br />
|-<br />
| max deviation || 3,43 meters<br />
|-<br />
| mean (abs) || 0,69 meters<br />
|-<br />
| RMS +/- || 0,91 meters<br />
|}<br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| VesselConfig ID || 68<br />
|-<br />
| Manufacturer || Bavaria Yachtbau<br />
|-<br />
| Model || B32<br />
|-<br />
| Length || 10,0 meters<br />
|-<br />
| Beam || 3,35 meters<br />
|-<br />
| Draft || 1,6 meters<br />
|-<br />
| Height || 14 meters<br />
|-<br />
| Displacement || 4,2 t<br />
|-<br />
| Sensor manufacturer || Raymarine<br />
|-<br />
| Sensor Offset to waterline || 0,45 meters<br />
|-<br />
| Sensor Offset to keel || 1,15 meters<br />
|}<br />
<br />
<br />
<br />
A digital Deep Model raster was computed from the BSH point dataset (c).<br />
The depth of the crowed sourced dataset was compared to the derived raster dataset from the BSH.<br />
The raw crowed sourced dataset was corrected by the sensor offset (0,45 meters).<br />
<br />
[[Datei: Scatter_cor_sensor.jpeg]]<br />
<br />
[Picture 2] '''''Scatter plot: BSH data on the x-axis and the crowed sourced data on the y-axis. Trend line in black and optimal line in red.'''''<br />
<br />
The deviation from the reference dataset increases with the depth measured.<br />
<br />
As you see in the picture below the difference between the datasets has an regular pattern maybe deepending on waves.<br />
<br />
[[Datei: Bsh_results_detail_10_classes.jpg]]<br />
<br />
[Picture 3] '''''Crowed sourced OpenSeaMap track points and the difference from the BSH dataset'''''<br />
<br />
White = low difference, orange = medium difference, red = strong difference<br />
<br />
Download of the data http://osm.franken.de/data/baltic_sea_test_data.zip<br />
'''Be aware of the copyright from the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].'''<br />
The data in the dataset is not corrected by sensor offset.<br />
<br />
==== Baltic Sea Olpenitz (Germany)====<br />
<br />
In this test area we have tracks from two different vessel configurations. <br />
The fist one was the one from the test area Großenbrode (config ID 68).<br />
<br />
In the Table below the settings for die vesselconfigid 110 are shown: <br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| VesselConfigId || 110<br />
|-<br />
| Manufacturer || Waarschip<br />
|-<br />
| Model || 570<br />
|-<br />
| Length || 5,7 meters<br />
|-<br />
| Beam || 2,45 meters<br />
|-<br />
| Draft || 1,0 meters<br />
|-<br />
| Height || 9.1 meters<br />
|-<br />
| Displacement || 0,8 t<br />
|-<br />
| Sensor manufacturer || Tacktick/ Airmar<br />
|-<br />
| Sensor Model || T912<br />
|-<br />
| Sensor Offset to waterline || 0,2 meters<br />
|-<br />
| Sensor Offset to keel || 0,45 meters<br />
|}<br />
<br />
[[Datei: Balitc_sea_scatter_plot_2.jpeg]]<br />
<br />
[Picture 1] Scatterplot for vesselconfigID 110. Trendline in Black and optimal line in red (after correction of the sensor offset to waterline).<br />
<br />
{| class="wikitable"<br />
|-<br />
| vsselConfigId || 110<br />
|-<br />
| n || 247<br />
|-<br />
| mean || 0,49 meters<br />
|-<br />
| rms || 0,62 meters<br />
|-<br />
| max|| 2,53 meters<br />
|}<br />
<br />
The distribution is quite different from the data recorded in the test area Großenbrode with an different sensor.<br />
<br />
Fortunately we have also data from the VesselConfigId 68 in this test area to compare the measurements.<br />
<br />
[[Datei: Balitc_sea_scatter_plot_2_68_all.jpeg]]<br />
<br />
[Picture 2] Scatterplot for vesselconfigID 68 after correction of the sensor offset to waterline.<br />
<br />
Obviously there are some outliers which are shown in picture 3.<br />
<br />
[[Datei: Bsh 2 outliers.jpg]]<br />
<br />
[Picture 2] Outliers along the track 9064 in yellow - vesselconfigID 68.<br />
<br />
Without the outliers the behavier of distribution is very same the results in the test area Großenbrode.<br />
<br />
[[Datei: Balitc_sea_scatter_plot_2_68_without.jpeg]]<br />
<br />
[Picture 1] Scatterplot for vesselconfigID 68 without outliers. Trendline in Black and optimal line in red (after correction of the sensor offset to waterline).<br />
<br />
{| class="wikitable"<br />
|-<br />
| vsselConfigId || 68 () without outliers<br />
|-<br />
| n || 100<br />
|-<br />
| mean || 0,38 meters<br />
|-<br />
| rms || 0,53 meters<br />
|-<br />
| max|| 2,1 meters<br />
|}<br />
<br />
==== preliminary Conclusions ====<br />
<br />
=== Meta Data Statistics ===<br />
<br />
Statistics for the metadata entrees with some personal comments (by MartinOver). Stand 20.9.2014.<br />
<br />
{| class="prettytable"<br />
|-<br />
|<br />
'''Step'''<br />
<br />
|<br />
'''Topic'''<br />
<br />
|<br />
'''Count'''<br />
<br />
|<br />
'''State'''<br />
<br />
|<br />
'''Comment'''<br />
<br />
|-<br />
|<br />
1/1<br />
<br />
|<br />
Name<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
1/2<br />
<br />
|<br />
Description<br />
<br />
|<br />
76/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/1<br />
<br />
|<br />
Length<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
Some wrong entrees like mail addresses or comments <br />
<br />
24 “0.00” Values<br />
<br />
|-<br />
|<br />
2/2<br />
<br />
|<br />
Beam<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
37 „0.00“ Values<br />
<br />
|-<br />
|<br />
2/3<br />
<br />
|<br />
Draft<br />
<br />
|<br />
79/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/4<br />
<br />
|<br />
Displacement<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/5<br />
<br />
|<br />
Height<br />
<br />
|<br />
78/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/6<br />
<br />
|<br />
Manufacturer<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Model<br />
<br />
|<br />
49/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Type<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/3<br />
<br />
|<br />
Position below Waterline<br />
<br />
|<br />
57/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Should be Obligatory<br />
<br />
|-<br />
|<br />
3/4<br />
<br />
|<br />
Depth Measurement<br />
<br />
|<br />
?<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Where in DB?<br />
<br />
|-<br />
|<br />
3/5<br />
<br />
|<br />
Sensor Offset to Keel<br />
<br />
|<br />
6/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/6<br />
<br />
|<br />
Producer of Depth Sensor<br />
<br />
|<br />
63/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/7<br />
<br />
|<br />
Device Model<br />
<br />
|<br />
40/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
58 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
51 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/3<br />
<br />
|<br />
Position abbove Waterline<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/4<br />
<br />
|<br />
Producer<br />
<br />
|<br />
77/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/5<br />
<br />
|<br />
Model<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|}<br />
<br />
= Data Preprocessing =<br />
<br />
== Data Condition ==<br />
Raw data is usually erronous and must be corrected<br />
<br />
=== Internal data problems ===<br />
Depth data may be affected by electrical conditions and software implementations<br />
* Data is incomplete and fail their checksum (bus errors from physical transmissions errors)<br />
* Data is retrived out of sequence<br />
* Data is erronous sensor data <br />
** Approximate correctable data i.e. invalid GPS position that may be interpolated<br />
** Uncorrectable data i.e. failed log sensor that shows slow speeds<br />
* Data resolution is low i.e. for energy saving purposes GPS position is updated every 10 seconds instead of every second<br />
* Sensor data is actively miscalibrated i.e. charter companies add additional draft to the sensor depth for safety reasons<br />
<br />
=== External data problems ===<br />
Depth data may be affected by different environmental circumstances <br />
*# The water temperature affects the ultrasound echo. An inhomogen water temperature yields unwanted echos<br />
*# The seabed affects the ultrasound echo<br />
*# The seastate affects the measurement. There even may be waves when there is no wind.<br />
*# Waves may affect the roll of the measuring vessel resulting in steep measurements that are invalid.<br />
*# The sounder sensor is not the position of the GPS antenna. A position offset including heading must be incorporated.<br />
*# The time of the measurement need not correlate with the time the position was received. This may even happen due to processing time of the hard or software.<br />
*# Corrections for tide induced water levels must happen<br />
<br />
Solutions probably are<br />
*# Water temperature may be measure from the sensor, other data may be unavailable<br />
*# Modern sidescan sonar may yield information about the seabed through classifications<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# Position offsets must be provided by the user<br />
*# Time outages may be handled by the filter if precise timestamps are available in recorded data<br />
*# LAT to Mean sea level differences may be calculated from DTU10 worldwide, river gauges need to monitored<br />
<br />
[[Datei:LAT2MSLDiff.png]]<br />
<br />
<br />
== Data Condition Examples / Showcases ==<br />
<br />
=== Missing measurments (Position) ===<br />
Distribution for position updates taken from an example dataset. Left column shows the time between two consecutive measurements, right column shows how many measurements had this time update.<br />
One can see from the distribtion that the sensor is updated every second but many measurements are one or more seconds late.<br />
21 seconds with no position update may result in an instability of the subsequent filter.<br />
<pre><br />
MeasuredPosition3D<br />
GP<br />
0 :4285<br />
1000 :11295<br />
2000 :5056<br />
3000 :2134<br />
4000 :1135<br />
5000 :315<br />
6000 :154<br />
7000 :46<br />
8000 :36<br />
9000 :16<br />
10000 :12<br />
11000 :3<br />
12000 :4<br />
13000 :1<br />
14000 :7<br />
15000 :3<br />
16000 :1<br />
21000 :1<br />
</pre><br />
<br />
=== Missing measurments (Position) with erronous clock ===<br />
This example is at a 10 second position update rate. However the measurment time is faulty causing large negative and positive update rates. The clock jumps by +- one year/month/day/hour. One can further see from the many 0 time measurements that the rate at which data is sent to the nmea bus is higher than the actual position update (data is sent every second, a position update is every 10 seconds)<br />
<pre><br />
MeasuredPosition3D<br />
II<br />
-21340000 :1<br />
-13194000 :1<br />
-7998000 :1<br />
-2674000 :1<br />
-2434000 :1<br />
-2402000 :1<br />
-2030000 :1<br />
-1926000 :1<br />
-1894000 :1<br />
-1806000 :1<br />
-1480000 :1<br />
-1430000 :1<br />
-1382000 :1<br />
-1114000 :1<br />
-814000 :1<br />
-634000 :1<br />
-590000 :1<br />
-546000 :1<br />
-470000 :1<br />
-290000 :1<br />
-230000 :1<br />
-198000 :1<br />
-110000 :1<br />
-94000 :2<br />
0 :182200<br />
5000 :1<br />
10000 :20230<br />
15000 :1<br />
20000 :84<br />
50000 :1<br />
114000 :2<br />
130000 :2<br />
218000 :1<br />
250000 :1<br />
310000 :1<br />
490000 :1<br />
566000 :1<br />
610000 :1<br />
654000 :1<br />
834000 :1<br />
1134000 :1<br />
1402000 :1<br />
1450000 :1</pre><br />
<br />
== Solution Proposal ==<br />
<br />
=== Outline ===<br />
The ship is influenced by the outlined environment which can be observed. Naturally what is observed is not the state of the<br />
ship as i.e. the position if taken from GPS is 95% less than 10m accurate. To improve quality an estimation of the true state yields better results if this noise taken into account properly.<br />
<br />
=== Details ===<br />
The ship moves according to physical laws. For the easist case imagine a ship with constant velocity and direction. For any point in time you can tell where the ship is with easy math. Considering the full blown setup a ships movement is affected by many parameters such as wind speed, water current, waves, tide, and many more. The ship moves also triaxial in a dynamic way in itself (roll, pitch, yaw). Heeling even changes the measurement position with respect to the depth position. In terms of a filter this is called a system model that describes how the state of the ship may change. Given such a state you can measure what your sensor readings are and compare that to where the system thinks you are.<br />
<br />
The [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter] is known to be the best linear estimator for such situations. Unfortunately the system model is not linear which is why the Extended Kalman Filter needs to be used in order to linearize the system at hand.<br />
<br />
Todo:<br />
* Construct ship system model with at least the position state and probably its course and speed or even more (depth)<br />
* Estimate the system variance (This is a hard one, proposals welcome)<br />
* Construct the measurement model according to the data available (GPS, Log)<br />
* Estimate the measurement noise according to specifc sensors (DPGS is more accurate than GPS)<br />
<br />
The estimation with the position and depth can be retrieved and stored in a database.<br />
<br />
Pitfalls:<br />
* If the system noise is badly chosen the estimation of the system state does not converge to the true state / measurement.<br />
* If the system is very detailed the system variance can be reduced. The required cpu time for processing increases<br />
<br />
Benefits:<br />
* Having the best estimation of the true position even if measurements are noisy<br />
* Easy and effective algorithmic processing<br />
<br />
== Analysis == <br />
<br />
=== Data Sets ===<br />
Currently two test data sets are available recorded during trips from Mallorca and the Baltic Sea.<br />
In terms of data quality the Mallorca data shows many challenges. <br />
* The minimum recommended sentences from NMEA showed up with false date and time readings while having correct (!!!) message checksums. <br />
* The log on the ship was defective and delivered no readings from time to time. <br />
* The same holds true for the water temperature.<br />
* The GPS positions relatively imprecise because some last decimal digits are missing in the recordings.<br />
* The GPS positions are updated every 10 seconds while other sensor readings update almost every second.<br />
* The GPS position are sometimes way off due to false readings<br />
<br />
The Baltic Sea data set is a little bit better<br />
* Only a single day is available<br />
* GPS positions are updated every second<br />
<br />
One problem with the data is that there is time available when sensor readings were recorded. This yields problems to the filter algorithm.<br />
<br />
<br />
=== Filter Algorithm ===<br />
At first the Extended Kalman Filter is being analyzed. Using an apache implementation with the available data the filter quickly throw an exception that<br />
a matrix is not invertible because of numeric instabilities. When removing this exception the filter seems to work but the removal and its effects have yet to be analyzed.<br />
Literature suggest that a fixed interval smoother may yield better results in case of offline data processing. As it is an extension to the existing kalman filter<br />
we may consider that for the future.<br />
<br />
One problem are the different update rates of the sensors. As GPS may deliver positions at 0.1Hz speed is updated at 1Hz. Literature suggests that<br />
the missing measurements shell be modelled as a random variable with the standard deviation of the sensor. It may even be possible to update covariance matrices only partially with the sensor readings received. Input for the best solution may be formulated on the developer mailing list.<br />
<br />
== Results == <br />
A prototype implementation is shown in the following screenshots. An Extended Kalman Filter is being used. It has the position<br />
and the current bearing and velocity as system state. The input is the measurement of these four observables. The system function is<br />
good old pythagoras. In a first implementation I tried to use orthodrome distances but the system function is not differentiable which is a requirement of the Extended Kalman Filter (due to acrtan2). For small distances pythagoras should be sufficiently accurate. <br />
The initial state is taken from the first measurement for convergence reasons.<br />
<br />
The following gallery shows the results. <br />
* You can see the bad position resolution and an outlier in the first screenshot.<br />
* The second shows the same data overlaid with the applied filter. The outlier is gone and the resolution has improved.<br />
* The third screenshot shows data from a different GPS sensor with more precision (not DGPS) versus the filtered data.<br />
<br />
This of course is just a preliminary test and many setups need to be considered to make it work for most datasets.<br />
<br />
<gallery><br />
UnfilteredNMEA.png | Unfiltered GPS data<br />
FilteredNMEAVsOriginal.png | Unfiltered GPS data and Filtered GPS data<br />
PreciseGPSvsFilter.png | Another precise GPS vs Filtered GPS data<br />
</gallery><br />
<br />
The overall process even gives an estimation of the current error which is a capability of the [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter].<br />
This way positional inaccuracies may be added to the overall depth measurement inaccuracy.<br />
<br />
== Quality rating ==<br />
<br />
Each record (time, positon, depth) should become a quality rating.<br />
<br />
=== Points ===<br />
<br />
Derived from the Fibonacci series.<br />
<br />
{| class="wikitable"<br />
! Point || Description<br />
|-<br />
| 1 || extra small improvement<br />
|-<br />
| 2 || small improvement<br />
|-<br />
| 3 || medium improvement<br />
|-<br />
| 5 || large improvement<br />
|-<br />
| 8 || extra large improvement<br />
|}<br />
<br />
=== Factors ===<br />
<br />
{| class="wikitable"<br />
! style="width:15%" | Name<br />
! style="width:17%" | Factor<br />
! style="width:68%" | Description<br />
|-<br />
| depth offset || 8 (extra large) || The difference between the depth measured by the echo sounder and the depth (waterline) measured by hand.<br />
|-<br />
| device distance || 3 (medium) || The distance between gps antenna and echo sounder (lengthwise and crosswise).<br />
|-<br />
| SBAS || 3 (medium) || Satellite based augmentation system (WAAS, EGNOS, MSAS) which allows to correct the gps position.<br />
|-<br />
| position interpolation || 2 (small improvement) || Arrival of depth and position packets can have a time difference. It is/should be possible to interpolate the position.<br />
|}<br />
<br />
= Depth Rendering =<br />
<br />
= Siehe auch =<br />
* [[De:Bordnetz|Bordnetz]]<br />
* [[De:NMEA-Logger_anschliessen|NMEA-Logger_anschliessen]]<br />
* [http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCkQFjAA&url=http%3A%2F%2Fwww.dei.unipd.it%2F~chiuso%2FDOWNLOAD%2FPositioning_Heading_Kalman.pdf&ei=sSWNUMWnL4eC4gTRlYHAAw&usg=AFQjCNHq5V-PePNmDTZaGYvq0JeQFgqHVw Kalman Filtering for Positioning and Heading Control of Ships and Offshore Rigs]<br />
* [http://users.isr.ist.utl.pt/~pedro/publications/CAMS10.pdf A Multiple Model Adaptive Wave Filter for Dynamic Ship Positioning]<br />
* [http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4449205&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4449205 Echosounder Depth Tracking with the Extended Kalman Filter]</div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:En:Depth_Data&diff=2977OpenSeaMap-dev:En:Depth Data2014-09-30T19:57:35Z<p>MartinOver: /* Conclusions */</p>
<hr />
<div>This Page describes the necessary efforts to retrieve and analyze depth data as well as create renderings from it<br />
<br />
= Data Aquisition =<br />
Depth data can be retrieved from public domain sources or from crowd sourced data.<br />
<br />
== GEBCO ==<br />
DIe Daten sind gerendert und stehen als Layer zur Verfügung:<br />
{| class="wikitable"<br />
! Zoom || Inhalt<br />
|-<br />
| 0..10 || Blaustufen und Schattierung<br />
|-<br />
| 11..18 || beschriftete Tiefenlinien, Blaustufen und Schattierung<br />
|}<br />
<br />
Noch zu lösende Probleme:<br />
* der GEBCO-Layer erzeugt einen milchigen Schleier über der Basiskarte<br />
* Tiefenlinien sind ab z=14 etwas grob (also ab da, wo dann die Flachwassertiefen beginnen) [http://map.openseamap.org/?zoom=14&lat=36.03097&lon=-5.49153&layers=BFTFTTTFFFF0 Karte]<br />
* Überschneidungen von 100m-Linie und Küstenlinie [http://map.openseamap.org/?zoom=15&lat=36.00318&lon=-5.60819&layers=BFFFTTTFFFF0FFFFF Karte]<br />
* Steilküsten (Cuba) [http://map.openseamap.org/?zoom=14&lat=19.94808&lon=-76.04289&layers=BFTFTTTFFFF0 Karte]<br />
<br />
== Crowd Sourced Data ==<br />
Crowd sourced data may be gathered by YOU. There are two options in development. A hardware and a software option.<br />
<br />
=== Workflow ===<br />
[[Datei:Workflow_depth.png]]<br />
<br />
Here you can find the document with the previous thoughts about the workflow:<br />
[http://osm.franken.de/wiki/FWT-Projekt%C3%BCbersicht-NMEA2Contours_2.1.ppt PPT Dokument]<br />
<br />
=== Hardware logger ===<br />
We are currently developing a hardware logger that may easily be plugged to the ship's network in order to log the networks data to a SD card.<br />
That data may then be uploaded by plugging the SD card to a normal computer with internet connection for upload.<br />
The main goal is to support NMEA 0183 data with options for NMEA 2000.<br />
<br />
=== Software logger ===<br />
A [[Software logger]] is in development and [http://seesea.sourceforge.net/datalogger/index.html can be downloaded here]. <br />
<br />
It currently supports: <br />
: Bluetooth <br />
: Serial ports<br />
: Internet Protocol (IP)<br />
It processes NMEA 0183 and AIS data.<br />
<br />
For vendor specific protocols such as SeaTalk 1 you have to use a [[De:NMEA-Logger_anschliessen|converter]] to NMEA 0183 data.<br />
<br />
NMEA 2000 support is only available if data is transcoded to NMEA 0183 by a converter.<br />
<br />
=== Chart Plotters ===<br />
<br />
Some chart plotters are able to save tracks out-of-the-box, e.g. several Raymarine (FSH files) and Humminbird (SON files) devices. Those files may directly be used as data source.<br />
<br />
<br />
=== Upload Process ===<br />
Uploading data is possible through using the [http://seesea.sourceforge.net/datalogger/index.html OpenSeaMap Data Logger Software] or via [http://depth.openseamap.org/ Web Interface].<br />
The system is currently being tested. <br />
<br />
[[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|You'll find further information here]].<br />
<br />
=== Test Data ===<br />
<br />
<br />
==== Brombachsee (Germany)====<br />
<br />
Test data for Openseamap: [http://osm.franken.de/wiki/test_data_brombachsee.zip Brombachsee_Test_Data]<br />
<br />
dgm_brombachsee.tif: Digital Elevation Model of the sea derived from height lines WWA (C).<br />
<br />
shapes_brombachsee.shp: Shape File derived from 4 NMEA Tracks. "dbs" is the original Sounding and "deep_cor" the depth after a correction (gauge levl).<br />
<br />
gpx_brombachsee.gpx: ele = "dbs" from the Shape File<br />
<br />
[[Datei:Brombachsee.png]]<br />
Resulting Digital Elevation Model<br />
<br />
==== Baltic Sea - near Großenbrode (Germany)====<br />
<br />
First results with an RMS error < 1,5 meter compared to an official dataset of the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].<br />
<br />
[[Datei: Bsh_results_overview.jpg]]<br />
<br />
[Picture 1] '''''OSM map in background, raster Depth Model derived from BSH data and crowed sourced OpenSeaMap Points - Overview'''''<br />
<br />
Blue = flat BSH data, red = deep BSH data.<br />
<br>Blue points = OpenSeaMap raw measuring points.<br />
<br />
{| class="wikitable"<br />
|-<br />
| n || 5062<br />
|-<br />
|-<br />
| datasets || 21<br />
|-<br />
| max deviation || 3,43 meters<br />
|-<br />
| mean (abs) || 0,69 meters<br />
|-<br />
| RMS +/- || 0,91 meters<br />
|}<br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| VesselConfig ID || 68<br />
|-<br />
| Manufacturer || Bavaria Yachtbau<br />
|-<br />
| Model || B32<br />
|-<br />
| Length || 10,0 meters<br />
|-<br />
| Beam || 3,35 meters<br />
|-<br />
| Draft || 1,6 meters<br />
|-<br />
| Height || 14 meters<br />
|-<br />
| Displacement || 4,2 t<br />
|-<br />
| Sensor manufacturer || Raymarine<br />
|-<br />
| Sensor Offset to waterline || 0,45 meters<br />
|-<br />
| Sensor Offset to keel || 1,15 meters<br />
|}<br />
<br />
<br />
<br />
A digital Deep Model raster was computed from the BSH point dataset (c).<br />
The depth of the crowed sourced dataset was compared to the derived raster dataset from the BSH.<br />
The raw crowed sourced dataset was corrected by the sensor offset (0,45 meters).<br />
<br />
[[Datei: Scatter_cor_sensor.jpeg]]<br />
<br />
[Picture 2] '''''Scatter plot: BSH data on the x-axis and the crowed sourced data on the y-axis. Trend line in black and optimal line in red.'''''<br />
<br />
The deviation from the reference dataset increases with the depth measured.<br />
<br />
As you see in the picture below the difference between the datasets has an regular pattern maybe deepending on waves.<br />
<br />
[[Datei: Bsh_results_detail_10_classes.jpg]]<br />
<br />
[Picture 3] '''''Crowed sourced OpenSeaMap track points and the difference from the BSH dataset'''''<br />
<br />
White = low difference, orange = medium difference, red = strong difference<br />
<br />
Download of the data http://osm.franken.de/data/baltic_sea_test_data.zip<br />
'''Be aware of the copyright from the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].'''<br />
The data in the dataset is not corrected by sensor offset.<br />
<br />
==== Baltic Sea Olpenitz (Germany)====<br />
<br />
In this test area we have tracks from two different vessel configurations. <br />
The fist one was the one from the test area Großenbrode (config ID 68).<br />
<br />
In the Table below the settings for die vesselconfigid 110 are shown: <br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| VesselConfigId || 110<br />
|-<br />
| Manufacturer || Waarschip<br />
|-<br />
| Model || 570<br />
|-<br />
| Length || 5,7 meters<br />
|-<br />
| Beam || 2,45 meters<br />
|-<br />
| Draft || 1,0 meters<br />
|-<br />
| Height || 9.1 meters<br />
|-<br />
| Displacement || 0,8 t<br />
|-<br />
| Sensor manufacturer || Tacktick/ Airmar<br />
|-<br />
| Sensor Model || T912<br />
|-<br />
| Sensor Offset to waterline || 0,2 meters<br />
|-<br />
| Sensor Offset to keel || 0,45 meters<br />
|}<br />
<br />
[[Datei: Balitc_sea_scatter_plot_2.jpeg]]<br />
<br />
[Picture 1] Scatterplot for vesselconfigID 110. Trendline in Black and optimal line in red (after correction of the sensor offset to waterline).<br />
<br />
{| class="wikitable"<br />
|-<br />
| vsselConfigId || 110<br />
|-<br />
| n || 247<br />
|-<br />
| mean || 0,49 meters<br />
|-<br />
| rms || 0,62 meters<br />
|-<br />
| max|| 2,53 meters<br />
|}<br />
<br />
The distribution is quite different from the data recorded in the test area Großenbrode with an different sensor.<br />
<br />
Fortunately we have also data from the VesselConfigId 68 in this test area to compare the measurements.<br />
<br />
[[Datei: Balitc_sea_scatter_plot_2_68_all.jpeg]]<br />
<br />
[Picture 2] Scatterplot for vesselconfigID 68 after correction of the sensor offset to waterline.<br />
<br />
Obviously there are some outliers which are shown in picture 3.<br />
<br />
[[Datei: Bsh 2 outliers.jpg]]<br />
<br />
[Picture 2] Outliers along the track 9064 in yellow - vesselconfigID 68.<br />
<br />
Without the outliers the behavier of distribution is very same the results in the test area Großenbrode.<br />
<br />
[[Datei: Balitc_sea_scatter_plot_2_68_without.jpeg]]<br />
<br />
[Picture 1] Scatterplot for vesselconfigID 68 without outliers. Trendline in Black and optimal line in red (after correction of the sensor offset to waterline).<br />
<br />
{| class="wikitable"<br />
|-<br />
| vsselConfigId || 68 () without outliers<br />
|-<br />
| n || 100<br />
|-<br />
| mean || 0,38 meters<br />
|-<br />
| rms || 0,53 meters<br />
|-<br />
| max|| 2,1 meters<br />
|}<br />
<br />
=== Meta Data Statistics ===<br />
<br />
Statistics for the metadata entrees with some personal comments (by MartinOver). Stand 20.9.2014.<br />
<br />
{| class="prettytable"<br />
|-<br />
|<br />
'''Step'''<br />
<br />
|<br />
'''Topic'''<br />
<br />
|<br />
'''Count'''<br />
<br />
|<br />
'''State'''<br />
<br />
|<br />
'''Comment'''<br />
<br />
|-<br />
|<br />
1/1<br />
<br />
|<br />
Name<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
1/2<br />
<br />
|<br />
Description<br />
<br />
|<br />
76/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/1<br />
<br />
|<br />
Length<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
Some wrong entrees like mail addresses or comments <br />
<br />
24 “0.00” Values<br />
<br />
|-<br />
|<br />
2/2<br />
<br />
|<br />
Beam<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
37 „0.00“ Values<br />
<br />
|-<br />
|<br />
2/3<br />
<br />
|<br />
Draft<br />
<br />
|<br />
79/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/4<br />
<br />
|<br />
Displacement<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/5<br />
<br />
|<br />
Height<br />
<br />
|<br />
78/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/6<br />
<br />
|<br />
Manufacturer<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Model<br />
<br />
|<br />
49/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Type<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/3<br />
<br />
|<br />
Position below Waterline<br />
<br />
|<br />
57/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Should be Obligatory<br />
<br />
|-<br />
|<br />
3/4<br />
<br />
|<br />
Depth Measurement<br />
<br />
|<br />
?<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Where in DB?<br />
<br />
|-<br />
|<br />
3/5<br />
<br />
|<br />
Sensor Offset to Keel<br />
<br />
|<br />
6/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/6<br />
<br />
|<br />
Producer of Depth Sensor<br />
<br />
|<br />
63/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/7<br />
<br />
|<br />
Device Model<br />
<br />
|<br />
40/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
58 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
51 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/3<br />
<br />
|<br />
Position abbove Waterline<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/4<br />
<br />
|<br />
Producer<br />
<br />
|<br />
77/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/5<br />
<br />
|<br />
Model<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|}<br />
<br />
= Data Preprocessing =<br />
<br />
== Data Condition ==<br />
Raw data is usually erronous and must be corrected<br />
<br />
=== Internal data problems ===<br />
Depth data may be affected by electrical conditions and software implementations<br />
* Data is incomplete and fail their checksum (bus errors from physical transmissions errors)<br />
* Data is retrived out of sequence<br />
* Data is erronous sensor data <br />
** Approximate correctable data i.e. invalid GPS position that may be interpolated<br />
** Uncorrectable data i.e. failed log sensor that shows slow speeds<br />
* Data resolution is low i.e. for energy saving purposes GPS position is updated every 10 seconds instead of every second<br />
* Sensor data is actively miscalibrated i.e. charter companies add additional draft to the sensor depth for safety reasons<br />
<br />
=== External data problems ===<br />
Depth data may be affected by different environmental circumstances <br />
*# The water temperature affects the ultrasound echo. An inhomogen water temperature yields unwanted echos<br />
*# The seabed affects the ultrasound echo<br />
*# The seastate affects the measurement. There even may be waves when there is no wind.<br />
*# Waves may affect the roll of the measuring vessel resulting in steep measurements that are invalid.<br />
*# The sounder sensor is not the position of the GPS antenna. A position offset including heading must be incorporated.<br />
*# The time of the measurement need not correlate with the time the position was received. This may even happen due to processing time of the hard or software.<br />
*# Corrections for tide induced water levels must happen<br />
<br />
Solutions probably are<br />
*# Water temperature may be measure from the sensor, other data may be unavailable<br />
*# Modern sidescan sonar may yield information about the seabed through classifications<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# Position offsets must be provided by the user<br />
*# Time outages may be handled by the filter if precise timestamps are available in recorded data<br />
*# LAT to Mean sea level differences may be calculated from DTU10 worldwide, river gauges need to monitored<br />
<br />
[[Datei:LAT2MSLDiff.png]]<br />
<br />
<br />
== Data Condition Examples / Showcases ==<br />
<br />
=== Missing measurments (Position) ===<br />
Distribution for position updates taken from an example dataset. Left column shows the time between two consecutive measurements, right column shows how many measurements had this time update.<br />
One can see from the distribtion that the sensor is updated every second but many measurements are one or more seconds late.<br />
21 seconds with no position update may result in an instability of the subsequent filter.<br />
<pre><br />
MeasuredPosition3D<br />
GP<br />
0 :4285<br />
1000 :11295<br />
2000 :5056<br />
3000 :2134<br />
4000 :1135<br />
5000 :315<br />
6000 :154<br />
7000 :46<br />
8000 :36<br />
9000 :16<br />
10000 :12<br />
11000 :3<br />
12000 :4<br />
13000 :1<br />
14000 :7<br />
15000 :3<br />
16000 :1<br />
21000 :1<br />
</pre><br />
<br />
=== Missing measurments (Position) with erronous clock ===<br />
This example is at a 10 second position update rate. However the measurment time is faulty causing large negative and positive update rates. The clock jumps by +- one year/month/day/hour. One can further see from the many 0 time measurements that the rate at which data is sent to the nmea bus is higher than the actual position update (data is sent every second, a position update is every 10 seconds)<br />
<pre><br />
MeasuredPosition3D<br />
II<br />
-21340000 :1<br />
-13194000 :1<br />
-7998000 :1<br />
-2674000 :1<br />
-2434000 :1<br />
-2402000 :1<br />
-2030000 :1<br />
-1926000 :1<br />
-1894000 :1<br />
-1806000 :1<br />
-1480000 :1<br />
-1430000 :1<br />
-1382000 :1<br />
-1114000 :1<br />
-814000 :1<br />
-634000 :1<br />
-590000 :1<br />
-546000 :1<br />
-470000 :1<br />
-290000 :1<br />
-230000 :1<br />
-198000 :1<br />
-110000 :1<br />
-94000 :2<br />
0 :182200<br />
5000 :1<br />
10000 :20230<br />
15000 :1<br />
20000 :84<br />
50000 :1<br />
114000 :2<br />
130000 :2<br />
218000 :1<br />
250000 :1<br />
310000 :1<br />
490000 :1<br />
566000 :1<br />
610000 :1<br />
654000 :1<br />
834000 :1<br />
1134000 :1<br />
1402000 :1<br />
1450000 :1</pre><br />
<br />
== Solution Proposal ==<br />
<br />
=== Outline ===<br />
The ship is influenced by the outlined environment which can be observed. Naturally what is observed is not the state of the<br />
ship as i.e. the position if taken from GPS is 95% less than 10m accurate. To improve quality an estimation of the true state yields better results if this noise taken into account properly.<br />
<br />
=== Details ===<br />
The ship moves according to physical laws. For the easist case imagine a ship with constant velocity and direction. For any point in time you can tell where the ship is with easy math. Considering the full blown setup a ships movement is affected by many parameters such as wind speed, water current, waves, tide, and many more. The ship moves also triaxial in a dynamic way in itself (roll, pitch, yaw). Heeling even changes the measurement position with respect to the depth position. In terms of a filter this is called a system model that describes how the state of the ship may change. Given such a state you can measure what your sensor readings are and compare that to where the system thinks you are.<br />
<br />
The [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter] is known to be the best linear estimator for such situations. Unfortunately the system model is not linear which is why the Extended Kalman Filter needs to be used in order to linearize the system at hand.<br />
<br />
Todo:<br />
* Construct ship system model with at least the position state and probably its course and speed or even more (depth)<br />
* Estimate the system variance (This is a hard one, proposals welcome)<br />
* Construct the measurement model according to the data available (GPS, Log)<br />
* Estimate the measurement noise according to specifc sensors (DPGS is more accurate than GPS)<br />
<br />
The estimation with the position and depth can be retrieved and stored in a database.<br />
<br />
Pitfalls:<br />
* If the system noise is badly chosen the estimation of the system state does not converge to the true state / measurement.<br />
* If the system is very detailed the system variance can be reduced. The required cpu time for processing increases<br />
<br />
Benefits:<br />
* Having the best estimation of the true position even if measurements are noisy<br />
* Easy and effective algorithmic processing<br />
<br />
== Analysis == <br />
<br />
=== Data Sets ===<br />
Currently two test data sets are available recorded during trips from Mallorca and the Baltic Sea.<br />
In terms of data quality the Mallorca data shows many challenges. <br />
* The minimum recommended sentences from NMEA showed up with false date and time readings while having correct (!!!) message checksums. <br />
* The log on the ship was defective and delivered no readings from time to time. <br />
* The same holds true for the water temperature.<br />
* The GPS positions relatively imprecise because some last decimal digits are missing in the recordings.<br />
* The GPS positions are updated every 10 seconds while other sensor readings update almost every second.<br />
* The GPS position are sometimes way off due to false readings<br />
<br />
The Baltic Sea data set is a little bit better<br />
* Only a single day is available<br />
* GPS positions are updated every second<br />
<br />
One problem with the data is that there is time available when sensor readings were recorded. This yields problems to the filter algorithm.<br />
<br />
<br />
=== Filter Algorithm ===<br />
At first the Extended Kalman Filter is being analyzed. Using an apache implementation with the available data the filter quickly throw an exception that<br />
a matrix is not invertible because of numeric instabilities. When removing this exception the filter seems to work but the removal and its effects have yet to be analyzed.<br />
Literature suggest that a fixed interval smoother may yield better results in case of offline data processing. As it is an extension to the existing kalman filter<br />
we may consider that for the future.<br />
<br />
One problem are the different update rates of the sensors. As GPS may deliver positions at 0.1Hz speed is updated at 1Hz. Literature suggests that<br />
the missing measurements shell be modelled as a random variable with the standard deviation of the sensor. It may even be possible to update covariance matrices only partially with the sensor readings received. Input for the best solution may be formulated on the developer mailing list.<br />
<br />
== Results == <br />
A prototype implementation is shown in the following screenshots. An Extended Kalman Filter is being used. It has the position<br />
and the current bearing and velocity as system state. The input is the measurement of these four observables. The system function is<br />
good old pythagoras. In a first implementation I tried to use orthodrome distances but the system function is not differentiable which is a requirement of the Extended Kalman Filter (due to acrtan2). For small distances pythagoras should be sufficiently accurate. <br />
The initial state is taken from the first measurement for convergence reasons.<br />
<br />
The following gallery shows the results. <br />
* You can see the bad position resolution and an outlier in the first screenshot.<br />
* The second shows the same data overlaid with the applied filter. The outlier is gone and the resolution has improved.<br />
* The third screenshot shows data from a different GPS sensor with more precision (not DGPS) versus the filtered data.<br />
<br />
This of course is just a preliminary test and many setups need to be considered to make it work for most datasets.<br />
<br />
<gallery><br />
UnfilteredNMEA.png | Unfiltered GPS data<br />
FilteredNMEAVsOriginal.png | Unfiltered GPS data and Filtered GPS data<br />
PreciseGPSvsFilter.png | Another precise GPS vs Filtered GPS data<br />
</gallery><br />
<br />
The overall process even gives an estimation of the current error which is a capability of the [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter].<br />
This way positional inaccuracies may be added to the overall depth measurement inaccuracy.<br />
<br />
== Quality rating ==<br />
<br />
Each record (time, positon, depth) should become a quality rating.<br />
<br />
=== Points ===<br />
<br />
Derived from the Fibonacci series.<br />
<br />
{| class="wikitable"<br />
! Point || Description<br />
|-<br />
| 1 || extra small improvement<br />
|-<br />
| 2 || small improvement<br />
|-<br />
| 3 || medium improvement<br />
|-<br />
| 5 || large improvement<br />
|-<br />
| 8 || extra large improvement<br />
|}<br />
<br />
=== Factors ===<br />
<br />
{| class="wikitable"<br />
! style="width:15%" | Name<br />
! style="width:17%" | Factor<br />
! style="width:68%" | Description<br />
|-<br />
| depth offset || 8 (extra large) || The difference between the depth measured by the echo sounder and the depth (waterline) measured by hand.<br />
|-<br />
| device distance || 3 (medium) || The distance between gps antenna and echo sounder (lengthwise and crosswise).<br />
|-<br />
| SBAS || 3 (medium) || Satellite based augmentation system (WAAS, EGNOS, MSAS) which allows to correct the gps position.<br />
|-<br />
| position interpolation || 2 (small improvement) || Arrival of depth and position packets can have a time difference. It is/should be possible to interpolate the position.<br />
|}<br />
<br />
= Depth Rendering =<br />
<br />
= Siehe auch =<br />
* [[De:Bordnetz|Bordnetz]]<br />
* [[De:NMEA-Logger_anschliessen|NMEA-Logger_anschliessen]]<br />
* [http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCkQFjAA&url=http%3A%2F%2Fwww.dei.unipd.it%2F~chiuso%2FDOWNLOAD%2FPositioning_Heading_Kalman.pdf&ei=sSWNUMWnL4eC4gTRlYHAAw&usg=AFQjCNHq5V-PePNmDTZaGYvq0JeQFgqHVw Kalman Filtering for Positioning and Heading Control of Ships and Offshore Rigs]<br />
* [http://users.isr.ist.utl.pt/~pedro/publications/CAMS10.pdf A Multiple Model Adaptive Wave Filter for Dynamic Ship Positioning]<br />
* [http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4449205&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4449205 Echosounder Depth Tracking with the Extended Kalman Filter]</div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:En:Depth_Data&diff=2976OpenSeaMap-dev:En:Depth Data2014-09-30T19:56:53Z<p>MartinOver: /* Baltic Sea Olpenitz (Germany) */</p>
<hr />
<div>This Page describes the necessary efforts to retrieve and analyze depth data as well as create renderings from it<br />
<br />
= Data Aquisition =<br />
Depth data can be retrieved from public domain sources or from crowd sourced data.<br />
<br />
== GEBCO ==<br />
DIe Daten sind gerendert und stehen als Layer zur Verfügung:<br />
{| class="wikitable"<br />
! Zoom || Inhalt<br />
|-<br />
| 0..10 || Blaustufen und Schattierung<br />
|-<br />
| 11..18 || beschriftete Tiefenlinien, Blaustufen und Schattierung<br />
|}<br />
<br />
Noch zu lösende Probleme:<br />
* der GEBCO-Layer erzeugt einen milchigen Schleier über der Basiskarte<br />
* Tiefenlinien sind ab z=14 etwas grob (also ab da, wo dann die Flachwassertiefen beginnen) [http://map.openseamap.org/?zoom=14&lat=36.03097&lon=-5.49153&layers=BFTFTTTFFFF0 Karte]<br />
* Überschneidungen von 100m-Linie und Küstenlinie [http://map.openseamap.org/?zoom=15&lat=36.00318&lon=-5.60819&layers=BFFFTTTFFFF0FFFFF Karte]<br />
* Steilküsten (Cuba) [http://map.openseamap.org/?zoom=14&lat=19.94808&lon=-76.04289&layers=BFTFTTTFFFF0 Karte]<br />
<br />
== Crowd Sourced Data ==<br />
Crowd sourced data may be gathered by YOU. There are two options in development. A hardware and a software option.<br />
<br />
=== Workflow ===<br />
[[Datei:Workflow_depth.png]]<br />
<br />
Here you can find the document with the previous thoughts about the workflow:<br />
[http://osm.franken.de/wiki/FWT-Projekt%C3%BCbersicht-NMEA2Contours_2.1.ppt PPT Dokument]<br />
<br />
=== Hardware logger ===<br />
We are currently developing a hardware logger that may easily be plugged to the ship's network in order to log the networks data to a SD card.<br />
That data may then be uploaded by plugging the SD card to a normal computer with internet connection for upload.<br />
The main goal is to support NMEA 0183 data with options for NMEA 2000.<br />
<br />
=== Software logger ===<br />
A [[Software logger]] is in development and [http://seesea.sourceforge.net/datalogger/index.html can be downloaded here]. <br />
<br />
It currently supports: <br />
: Bluetooth <br />
: Serial ports<br />
: Internet Protocol (IP)<br />
It processes NMEA 0183 and AIS data.<br />
<br />
For vendor specific protocols such as SeaTalk 1 you have to use a [[De:NMEA-Logger_anschliessen|converter]] to NMEA 0183 data.<br />
<br />
NMEA 2000 support is only available if data is transcoded to NMEA 0183 by a converter.<br />
<br />
=== Chart Plotters ===<br />
<br />
Some chart plotters are able to save tracks out-of-the-box, e.g. several Raymarine (FSH files) and Humminbird (SON files) devices. Those files may directly be used as data source.<br />
<br />
<br />
=== Upload Process ===<br />
Uploading data is possible through using the [http://seesea.sourceforge.net/datalogger/index.html OpenSeaMap Data Logger Software] or via [http://depth.openseamap.org/ Web Interface].<br />
The system is currently being tested. <br />
<br />
[[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|You'll find further information here]].<br />
<br />
=== Test Data ===<br />
<br />
<br />
==== Brombachsee (Germany)====<br />
<br />
Test data for Openseamap: [http://osm.franken.de/wiki/test_data_brombachsee.zip Brombachsee_Test_Data]<br />
<br />
dgm_brombachsee.tif: Digital Elevation Model of the sea derived from height lines WWA (C).<br />
<br />
shapes_brombachsee.shp: Shape File derived from 4 NMEA Tracks. "dbs" is the original Sounding and "deep_cor" the depth after a correction (gauge levl).<br />
<br />
gpx_brombachsee.gpx: ele = "dbs" from the Shape File<br />
<br />
[[Datei:Brombachsee.png]]<br />
Resulting Digital Elevation Model<br />
<br />
==== Baltic Sea - near Großenbrode (Germany)====<br />
<br />
First results with an RMS error < 1,5 meter compared to an official dataset of the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].<br />
<br />
[[Datei: Bsh_results_overview.jpg]]<br />
<br />
[Picture 1] '''''OSM map in background, raster Depth Model derived from BSH data and crowed sourced OpenSeaMap Points - Overview'''''<br />
<br />
Blue = flat BSH data, red = deep BSH data.<br />
<br>Blue points = OpenSeaMap raw measuring points.<br />
<br />
{| class="wikitable"<br />
|-<br />
| n || 5062<br />
|-<br />
|-<br />
| datasets || 21<br />
|-<br />
| max deviation || 3,43 meters<br />
|-<br />
| mean (abs) || 0,69 meters<br />
|-<br />
| RMS +/- || 0,91 meters<br />
|}<br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| VesselConfig ID || 68<br />
|-<br />
| Manufacturer || Bavaria Yachtbau<br />
|-<br />
| Model || B32<br />
|-<br />
| Length || 10,0 meters<br />
|-<br />
| Beam || 3,35 meters<br />
|-<br />
| Draft || 1,6 meters<br />
|-<br />
| Height || 14 meters<br />
|-<br />
| Displacement || 4,2 t<br />
|-<br />
| Sensor manufacturer || Raymarine<br />
|-<br />
| Sensor Offset to waterline || 0,45 meters<br />
|-<br />
| Sensor Offset to keel || 1,15 meters<br />
|}<br />
<br />
<br />
<br />
A digital Deep Model raster was computed from the BSH point dataset (c).<br />
The depth of the crowed sourced dataset was compared to the derived raster dataset from the BSH.<br />
The raw crowed sourced dataset was corrected by the sensor offset (0,45 meters).<br />
<br />
[[Datei: Scatter_cor_sensor.jpeg]]<br />
<br />
[Picture 2] '''''Scatter plot: BSH data on the x-axis and the crowed sourced data on the y-axis. Trend line in black and optimal line in red.'''''<br />
<br />
The deviation from the reference dataset increases with the depth measured.<br />
<br />
As you see in the picture below the difference between the datasets has an regular pattern maybe deepending on waves.<br />
<br />
[[Datei: Bsh_results_detail_10_classes.jpg]]<br />
<br />
[Picture 3] '''''Crowed sourced OpenSeaMap track points and the difference from the BSH dataset'''''<br />
<br />
White = low difference, orange = medium difference, red = strong difference<br />
<br />
Download of the data http://osm.franken.de/data/baltic_sea_test_data.zip<br />
'''Be aware of the copyright from the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].'''<br />
The data in the dataset is not corrected by sensor offset.<br />
<br />
==== Baltic Sea Olpenitz (Germany)====<br />
<br />
In this test area we have tracks from two different vessel configurations. <br />
The fist one was the one from the test area Großenbrode (config ID 68).<br />
<br />
In the Table below the settings for die vesselconfigid 110 are shown: <br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| VesselConfigId || 110<br />
|-<br />
| Manufacturer || Waarschip<br />
|-<br />
| Model || 570<br />
|-<br />
| Length || 5,7 meters<br />
|-<br />
| Beam || 2,45 meters<br />
|-<br />
| Draft || 1,0 meters<br />
|-<br />
| Height || 9.1 meters<br />
|-<br />
| Displacement || 0,8 t<br />
|-<br />
| Sensor manufacturer || Tacktick/ Airmar<br />
|-<br />
| Sensor Model || T912<br />
|-<br />
| Sensor Offset to waterline || 0,2 meters<br />
|-<br />
| Sensor Offset to keel || 0,45 meters<br />
|}<br />
<br />
[[Datei: Balitc_sea_scatter_plot_2.jpeg]]<br />
<br />
[Picture 1] Scatterplot for vesselconfigID 110. Trendline in Black and optimal line in red (after correction of the sensor offset to waterline).<br />
<br />
{| class="wikitable"<br />
|-<br />
| vsselConfigId || 110<br />
|-<br />
| n || 247<br />
|-<br />
| mean || 0,49 meters<br />
|-<br />
| rms || 0,62 meters<br />
|-<br />
| max|| 2,53 meters<br />
|}<br />
<br />
The distribution is quite different from the data recorded in the test area Großenbrode with an different sensor.<br />
<br />
Fortunately we have also data from the VesselConfigId 68 in this test area to compare the measurements.<br />
<br />
[[Datei: Balitc_sea_scatter_plot_2_68_all.jpeg]]<br />
<br />
[Picture 2] Scatterplot for vesselconfigID 68 after correction of the sensor offset to waterline.<br />
<br />
Obviously there are some outliers which are shown in picture 3.<br />
<br />
[[Datei: Bsh 2 outliers.jpg]]<br />
<br />
[Picture 2] Outliers along the track 9064 in yellow - vesselconfigID 68.<br />
<br />
Without the outliers the behavier of distribution is very same the results in the test area Großenbrode.<br />
<br />
[[Datei: Balitc_sea_scatter_plot_2_68_without.jpeg]]<br />
<br />
[Picture 1] Scatterplot for vesselconfigID 68 without outliers. Trendline in Black and optimal line in red (after correction of the sensor offset to waterline).<br />
<br />
{| class="wikitable"<br />
|-<br />
| vsselConfigId || 68 () without outliers<br />
|-<br />
| n || 100<br />
|-<br />
| mean || 0,38 meters<br />
|-<br />
| rms || 0,53 meters<br />
|-<br />
| max|| 2,1 meters<br />
|}<br />
<br />
==== Conclusions ====<br />
<br />
=== Meta Data Statistics ===<br />
<br />
Statistics for the metadata entrees with some personal comments (by MartinOver). Stand 20.9.2014.<br />
<br />
{| class="prettytable"<br />
|-<br />
|<br />
'''Step'''<br />
<br />
|<br />
'''Topic'''<br />
<br />
|<br />
'''Count'''<br />
<br />
|<br />
'''State'''<br />
<br />
|<br />
'''Comment'''<br />
<br />
|-<br />
|<br />
1/1<br />
<br />
|<br />
Name<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
1/2<br />
<br />
|<br />
Description<br />
<br />
|<br />
76/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/1<br />
<br />
|<br />
Length<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
Some wrong entrees like mail addresses or comments <br />
<br />
24 “0.00” Values<br />
<br />
|-<br />
|<br />
2/2<br />
<br />
|<br />
Beam<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
37 „0.00“ Values<br />
<br />
|-<br />
|<br />
2/3<br />
<br />
|<br />
Draft<br />
<br />
|<br />
79/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/4<br />
<br />
|<br />
Displacement<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/5<br />
<br />
|<br />
Height<br />
<br />
|<br />
78/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/6<br />
<br />
|<br />
Manufacturer<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Model<br />
<br />
|<br />
49/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Type<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/3<br />
<br />
|<br />
Position below Waterline<br />
<br />
|<br />
57/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Should be Obligatory<br />
<br />
|-<br />
|<br />
3/4<br />
<br />
|<br />
Depth Measurement<br />
<br />
|<br />
?<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Where in DB?<br />
<br />
|-<br />
|<br />
3/5<br />
<br />
|<br />
Sensor Offset to Keel<br />
<br />
|<br />
6/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/6<br />
<br />
|<br />
Producer of Depth Sensor<br />
<br />
|<br />
63/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/7<br />
<br />
|<br />
Device Model<br />
<br />
|<br />
40/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
58 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
51 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/3<br />
<br />
|<br />
Position abbove Waterline<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/4<br />
<br />
|<br />
Producer<br />
<br />
|<br />
77/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/5<br />
<br />
|<br />
Model<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|}<br />
<br />
= Data Preprocessing =<br />
<br />
== Data Condition ==<br />
Raw data is usually erronous and must be corrected<br />
<br />
=== Internal data problems ===<br />
Depth data may be affected by electrical conditions and software implementations<br />
* Data is incomplete and fail their checksum (bus errors from physical transmissions errors)<br />
* Data is retrived out of sequence<br />
* Data is erronous sensor data <br />
** Approximate correctable data i.e. invalid GPS position that may be interpolated<br />
** Uncorrectable data i.e. failed log sensor that shows slow speeds<br />
* Data resolution is low i.e. for energy saving purposes GPS position is updated every 10 seconds instead of every second<br />
* Sensor data is actively miscalibrated i.e. charter companies add additional draft to the sensor depth for safety reasons<br />
<br />
=== External data problems ===<br />
Depth data may be affected by different environmental circumstances <br />
*# The water temperature affects the ultrasound echo. An inhomogen water temperature yields unwanted echos<br />
*# The seabed affects the ultrasound echo<br />
*# The seastate affects the measurement. There even may be waves when there is no wind.<br />
*# Waves may affect the roll of the measuring vessel resulting in steep measurements that are invalid.<br />
*# The sounder sensor is not the position of the GPS antenna. A position offset including heading must be incorporated.<br />
*# The time of the measurement need not correlate with the time the position was received. This may even happen due to processing time of the hard or software.<br />
*# Corrections for tide induced water levels must happen<br />
<br />
Solutions probably are<br />
*# Water temperature may be measure from the sensor, other data may be unavailable<br />
*# Modern sidescan sonar may yield information about the seabed through classifications<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# Position offsets must be provided by the user<br />
*# Time outages may be handled by the filter if precise timestamps are available in recorded data<br />
*# LAT to Mean sea level differences may be calculated from DTU10 worldwide, river gauges need to monitored<br />
<br />
[[Datei:LAT2MSLDiff.png]]<br />
<br />
<br />
== Data Condition Examples / Showcases ==<br />
<br />
=== Missing measurments (Position) ===<br />
Distribution for position updates taken from an example dataset. Left column shows the time between two consecutive measurements, right column shows how many measurements had this time update.<br />
One can see from the distribtion that the sensor is updated every second but many measurements are one or more seconds late.<br />
21 seconds with no position update may result in an instability of the subsequent filter.<br />
<pre><br />
MeasuredPosition3D<br />
GP<br />
0 :4285<br />
1000 :11295<br />
2000 :5056<br />
3000 :2134<br />
4000 :1135<br />
5000 :315<br />
6000 :154<br />
7000 :46<br />
8000 :36<br />
9000 :16<br />
10000 :12<br />
11000 :3<br />
12000 :4<br />
13000 :1<br />
14000 :7<br />
15000 :3<br />
16000 :1<br />
21000 :1<br />
</pre><br />
<br />
=== Missing measurments (Position) with erronous clock ===<br />
This example is at a 10 second position update rate. However the measurment time is faulty causing large negative and positive update rates. The clock jumps by +- one year/month/day/hour. One can further see from the many 0 time measurements that the rate at which data is sent to the nmea bus is higher than the actual position update (data is sent every second, a position update is every 10 seconds)<br />
<pre><br />
MeasuredPosition3D<br />
II<br />
-21340000 :1<br />
-13194000 :1<br />
-7998000 :1<br />
-2674000 :1<br />
-2434000 :1<br />
-2402000 :1<br />
-2030000 :1<br />
-1926000 :1<br />
-1894000 :1<br />
-1806000 :1<br />
-1480000 :1<br />
-1430000 :1<br />
-1382000 :1<br />
-1114000 :1<br />
-814000 :1<br />
-634000 :1<br />
-590000 :1<br />
-546000 :1<br />
-470000 :1<br />
-290000 :1<br />
-230000 :1<br />
-198000 :1<br />
-110000 :1<br />
-94000 :2<br />
0 :182200<br />
5000 :1<br />
10000 :20230<br />
15000 :1<br />
20000 :84<br />
50000 :1<br />
114000 :2<br />
130000 :2<br />
218000 :1<br />
250000 :1<br />
310000 :1<br />
490000 :1<br />
566000 :1<br />
610000 :1<br />
654000 :1<br />
834000 :1<br />
1134000 :1<br />
1402000 :1<br />
1450000 :1</pre><br />
<br />
== Solution Proposal ==<br />
<br />
=== Outline ===<br />
The ship is influenced by the outlined environment which can be observed. Naturally what is observed is not the state of the<br />
ship as i.e. the position if taken from GPS is 95% less than 10m accurate. To improve quality an estimation of the true state yields better results if this noise taken into account properly.<br />
<br />
=== Details ===<br />
The ship moves according to physical laws. For the easist case imagine a ship with constant velocity and direction. For any point in time you can tell where the ship is with easy math. Considering the full blown setup a ships movement is affected by many parameters such as wind speed, water current, waves, tide, and many more. The ship moves also triaxial in a dynamic way in itself (roll, pitch, yaw). Heeling even changes the measurement position with respect to the depth position. In terms of a filter this is called a system model that describes how the state of the ship may change. Given such a state you can measure what your sensor readings are and compare that to where the system thinks you are.<br />
<br />
The [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter] is known to be the best linear estimator for such situations. Unfortunately the system model is not linear which is why the Extended Kalman Filter needs to be used in order to linearize the system at hand.<br />
<br />
Todo:<br />
* Construct ship system model with at least the position state and probably its course and speed or even more (depth)<br />
* Estimate the system variance (This is a hard one, proposals welcome)<br />
* Construct the measurement model according to the data available (GPS, Log)<br />
* Estimate the measurement noise according to specifc sensors (DPGS is more accurate than GPS)<br />
<br />
The estimation with the position and depth can be retrieved and stored in a database.<br />
<br />
Pitfalls:<br />
* If the system noise is badly chosen the estimation of the system state does not converge to the true state / measurement.<br />
* If the system is very detailed the system variance can be reduced. The required cpu time for processing increases<br />
<br />
Benefits:<br />
* Having the best estimation of the true position even if measurements are noisy<br />
* Easy and effective algorithmic processing<br />
<br />
== Analysis == <br />
<br />
=== Data Sets ===<br />
Currently two test data sets are available recorded during trips from Mallorca and the Baltic Sea.<br />
In terms of data quality the Mallorca data shows many challenges. <br />
* The minimum recommended sentences from NMEA showed up with false date and time readings while having correct (!!!) message checksums. <br />
* The log on the ship was defective and delivered no readings from time to time. <br />
* The same holds true for the water temperature.<br />
* The GPS positions relatively imprecise because some last decimal digits are missing in the recordings.<br />
* The GPS positions are updated every 10 seconds while other sensor readings update almost every second.<br />
* The GPS position are sometimes way off due to false readings<br />
<br />
The Baltic Sea data set is a little bit better<br />
* Only a single day is available<br />
* GPS positions are updated every second<br />
<br />
One problem with the data is that there is time available when sensor readings were recorded. This yields problems to the filter algorithm.<br />
<br />
<br />
=== Filter Algorithm ===<br />
At first the Extended Kalman Filter is being analyzed. Using an apache implementation with the available data the filter quickly throw an exception that<br />
a matrix is not invertible because of numeric instabilities. When removing this exception the filter seems to work but the removal and its effects have yet to be analyzed.<br />
Literature suggest that a fixed interval smoother may yield better results in case of offline data processing. As it is an extension to the existing kalman filter<br />
we may consider that for the future.<br />
<br />
One problem are the different update rates of the sensors. As GPS may deliver positions at 0.1Hz speed is updated at 1Hz. Literature suggests that<br />
the missing measurements shell be modelled as a random variable with the standard deviation of the sensor. It may even be possible to update covariance matrices only partially with the sensor readings received. Input for the best solution may be formulated on the developer mailing list.<br />
<br />
== Results == <br />
A prototype implementation is shown in the following screenshots. An Extended Kalman Filter is being used. It has the position<br />
and the current bearing and velocity as system state. The input is the measurement of these four observables. The system function is<br />
good old pythagoras. In a first implementation I tried to use orthodrome distances but the system function is not differentiable which is a requirement of the Extended Kalman Filter (due to acrtan2). For small distances pythagoras should be sufficiently accurate. <br />
The initial state is taken from the first measurement for convergence reasons.<br />
<br />
The following gallery shows the results. <br />
* You can see the bad position resolution and an outlier in the first screenshot.<br />
* The second shows the same data overlaid with the applied filter. The outlier is gone and the resolution has improved.<br />
* The third screenshot shows data from a different GPS sensor with more precision (not DGPS) versus the filtered data.<br />
<br />
This of course is just a preliminary test and many setups need to be considered to make it work for most datasets.<br />
<br />
<gallery><br />
UnfilteredNMEA.png | Unfiltered GPS data<br />
FilteredNMEAVsOriginal.png | Unfiltered GPS data and Filtered GPS data<br />
PreciseGPSvsFilter.png | Another precise GPS vs Filtered GPS data<br />
</gallery><br />
<br />
The overall process even gives an estimation of the current error which is a capability of the [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter].<br />
This way positional inaccuracies may be added to the overall depth measurement inaccuracy.<br />
<br />
== Quality rating ==<br />
<br />
Each record (time, positon, depth) should become a quality rating.<br />
<br />
=== Points ===<br />
<br />
Derived from the Fibonacci series.<br />
<br />
{| class="wikitable"<br />
! Point || Description<br />
|-<br />
| 1 || extra small improvement<br />
|-<br />
| 2 || small improvement<br />
|-<br />
| 3 || medium improvement<br />
|-<br />
| 5 || large improvement<br />
|-<br />
| 8 || extra large improvement<br />
|}<br />
<br />
=== Factors ===<br />
<br />
{| class="wikitable"<br />
! style="width:15%" | Name<br />
! style="width:17%" | Factor<br />
! style="width:68%" | Description<br />
|-<br />
| depth offset || 8 (extra large) || The difference between the depth measured by the echo sounder and the depth (waterline) measured by hand.<br />
|-<br />
| device distance || 3 (medium) || The distance between gps antenna and echo sounder (lengthwise and crosswise).<br />
|-<br />
| SBAS || 3 (medium) || Satellite based augmentation system (WAAS, EGNOS, MSAS) which allows to correct the gps position.<br />
|-<br />
| position interpolation || 2 (small improvement) || Arrival of depth and position packets can have a time difference. It is/should be possible to interpolate the position.<br />
|}<br />
<br />
= Depth Rendering =<br />
<br />
= Siehe auch =<br />
* [[De:Bordnetz|Bordnetz]]<br />
* [[De:NMEA-Logger_anschliessen|NMEA-Logger_anschliessen]]<br />
* [http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCkQFjAA&url=http%3A%2F%2Fwww.dei.unipd.it%2F~chiuso%2FDOWNLOAD%2FPositioning_Heading_Kalman.pdf&ei=sSWNUMWnL4eC4gTRlYHAAw&usg=AFQjCNHq5V-PePNmDTZaGYvq0JeQFgqHVw Kalman Filtering for Positioning and Heading Control of Ships and Offshore Rigs]<br />
* [http://users.isr.ist.utl.pt/~pedro/publications/CAMS10.pdf A Multiple Model Adaptive Wave Filter for Dynamic Ship Positioning]<br />
* [http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4449205&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4449205 Echosounder Depth Tracking with the Extended Kalman Filter]</div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:En:Depth_Data&diff=2975OpenSeaMap-dev:En:Depth Data2014-09-30T19:55:15Z<p>MartinOver: /* Baltic Sea Olpenitz (Germany) */</p>
<hr />
<div>This Page describes the necessary efforts to retrieve and analyze depth data as well as create renderings from it<br />
<br />
= Data Aquisition =<br />
Depth data can be retrieved from public domain sources or from crowd sourced data.<br />
<br />
== GEBCO ==<br />
DIe Daten sind gerendert und stehen als Layer zur Verfügung:<br />
{| class="wikitable"<br />
! Zoom || Inhalt<br />
|-<br />
| 0..10 || Blaustufen und Schattierung<br />
|-<br />
| 11..18 || beschriftete Tiefenlinien, Blaustufen und Schattierung<br />
|}<br />
<br />
Noch zu lösende Probleme:<br />
* der GEBCO-Layer erzeugt einen milchigen Schleier über der Basiskarte<br />
* Tiefenlinien sind ab z=14 etwas grob (also ab da, wo dann die Flachwassertiefen beginnen) [http://map.openseamap.org/?zoom=14&lat=36.03097&lon=-5.49153&layers=BFTFTTTFFFF0 Karte]<br />
* Überschneidungen von 100m-Linie und Küstenlinie [http://map.openseamap.org/?zoom=15&lat=36.00318&lon=-5.60819&layers=BFFFTTTFFFF0FFFFF Karte]<br />
* Steilküsten (Cuba) [http://map.openseamap.org/?zoom=14&lat=19.94808&lon=-76.04289&layers=BFTFTTTFFFF0 Karte]<br />
<br />
== Crowd Sourced Data ==<br />
Crowd sourced data may be gathered by YOU. There are two options in development. A hardware and a software option.<br />
<br />
=== Workflow ===<br />
[[Datei:Workflow_depth.png]]<br />
<br />
Here you can find the document with the previous thoughts about the workflow:<br />
[http://osm.franken.de/wiki/FWT-Projekt%C3%BCbersicht-NMEA2Contours_2.1.ppt PPT Dokument]<br />
<br />
=== Hardware logger ===<br />
We are currently developing a hardware logger that may easily be plugged to the ship's network in order to log the networks data to a SD card.<br />
That data may then be uploaded by plugging the SD card to a normal computer with internet connection for upload.<br />
The main goal is to support NMEA 0183 data with options for NMEA 2000.<br />
<br />
=== Software logger ===<br />
A [[Software logger]] is in development and [http://seesea.sourceforge.net/datalogger/index.html can be downloaded here]. <br />
<br />
It currently supports: <br />
: Bluetooth <br />
: Serial ports<br />
: Internet Protocol (IP)<br />
It processes NMEA 0183 and AIS data.<br />
<br />
For vendor specific protocols such as SeaTalk 1 you have to use a [[De:NMEA-Logger_anschliessen|converter]] to NMEA 0183 data.<br />
<br />
NMEA 2000 support is only available if data is transcoded to NMEA 0183 by a converter.<br />
<br />
=== Chart Plotters ===<br />
<br />
Some chart plotters are able to save tracks out-of-the-box, e.g. several Raymarine (FSH files) and Humminbird (SON files) devices. Those files may directly be used as data source.<br />
<br />
<br />
=== Upload Process ===<br />
Uploading data is possible through using the [http://seesea.sourceforge.net/datalogger/index.html OpenSeaMap Data Logger Software] or via [http://depth.openseamap.org/ Web Interface].<br />
The system is currently being tested. <br />
<br />
[[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|You'll find further information here]].<br />
<br />
=== Test Data ===<br />
<br />
<br />
==== Brombachsee (Germany)====<br />
<br />
Test data for Openseamap: [http://osm.franken.de/wiki/test_data_brombachsee.zip Brombachsee_Test_Data]<br />
<br />
dgm_brombachsee.tif: Digital Elevation Model of the sea derived from height lines WWA (C).<br />
<br />
shapes_brombachsee.shp: Shape File derived from 4 NMEA Tracks. "dbs" is the original Sounding and "deep_cor" the depth after a correction (gauge levl).<br />
<br />
gpx_brombachsee.gpx: ele = "dbs" from the Shape File<br />
<br />
[[Datei:Brombachsee.png]]<br />
Resulting Digital Elevation Model<br />
<br />
==== Baltic Sea - near Großenbrode (Germany)====<br />
<br />
First results with an RMS error < 1,5 meter compared to an official dataset of the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].<br />
<br />
[[Datei: Bsh_results_overview.jpg]]<br />
<br />
[Picture 1] '''''OSM map in background, raster Depth Model derived from BSH data and crowed sourced OpenSeaMap Points - Overview'''''<br />
<br />
Blue = flat BSH data, red = deep BSH data.<br />
<br>Blue points = OpenSeaMap raw measuring points.<br />
<br />
{| class="wikitable"<br />
|-<br />
| n || 5062<br />
|-<br />
|-<br />
| datasets || 21<br />
|-<br />
| max deviation || 3,43 meters<br />
|-<br />
| mean (abs) || 0,69 meters<br />
|-<br />
| RMS +/- || 0,91 meters<br />
|}<br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| VesselConfig ID || 68<br />
|-<br />
| Manufacturer || Bavaria Yachtbau<br />
|-<br />
| Model || B32<br />
|-<br />
| Length || 10,0 meters<br />
|-<br />
| Beam || 3,35 meters<br />
|-<br />
| Draft || 1,6 meters<br />
|-<br />
| Height || 14 meters<br />
|-<br />
| Displacement || 4,2 t<br />
|-<br />
| Sensor manufacturer || Raymarine<br />
|-<br />
| Sensor Offset to waterline || 0,45 meters<br />
|-<br />
| Sensor Offset to keel || 1,15 meters<br />
|}<br />
<br />
<br />
<br />
A digital Deep Model raster was computed from the BSH point dataset (c).<br />
The depth of the crowed sourced dataset was compared to the derived raster dataset from the BSH.<br />
The raw crowed sourced dataset was corrected by the sensor offset (0,45 meters).<br />
<br />
[[Datei: Scatter_cor_sensor.jpeg]]<br />
<br />
[Picture 2] '''''Scatter plot: BSH data on the x-axis and the crowed sourced data on the y-axis. Trend line in black and optimal line in red.'''''<br />
<br />
The deviation from the reference dataset increases with the depth measured.<br />
<br />
As you see in the picture below the difference between the datasets has an regular pattern maybe deepending on waves.<br />
<br />
[[Datei: Bsh_results_detail_10_classes.jpg]]<br />
<br />
[Picture 3] '''''Crowed sourced OpenSeaMap track points and the difference from the BSH dataset'''''<br />
<br />
White = low difference, orange = medium difference, red = strong difference<br />
<br />
Download of the data http://osm.franken.de/data/baltic_sea_test_data.zip<br />
'''Be aware of the copyright from the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].'''<br />
The data in the dataset is not corrected by sensor offset.<br />
<br />
==== Baltic Sea Olpenitz (Germany)====<br />
<br />
In this test area we have tracks from two different vessel configurations. <br />
The fist one was the one from the test area Großenbrode (config ID 68).<br />
<br />
In the Table below the settings for die vesselconfigid 110 are shown: <br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| VesselConfigId || 110<br />
|-<br />
| Manufacturer || Waarschip<br />
|-<br />
| Model || 570<br />
|-<br />
| Length || 5,7 meters<br />
|-<br />
| Beam || 2,45 meters<br />
|-<br />
| Draft || 1,0 meters<br />
|-<br />
| Height || 9.1 meters<br />
|-<br />
| Displacement || 0,8 t<br />
|-<br />
| Sensor manufacturer || Tacktick/ Airmar<br />
|-<br />
| Sensor Model || T912<br />
|-<br />
| Sensor Offset to waterline || 0,2 meters<br />
|-<br />
| Sensor Offset to keel || 0,45 meters<br />
|}<br />
<br />
[[Datei: Balitc_sea_scatter_plot_2.jpeg]]<br />
<br />
[Picture 1] Scatterplot for vesselconfigID 110. Trendline in Black and optimal line in red (after correction of the sensor offset to waterline).<br />
<br />
{| class="wikitable"<br />
|-<br />
| vsselConfigId || 110<br />
|-<br />
| n || 247<br />
|-<br />
| mean || 0,49 meters<br />
|-<br />
| rms || 0,62 meters<br />
|-<br />
| max|| 2,53 meters<br />
|}<br />
<br />
The distribution is quite different from the data recorded in the test area Großenbrode with an different sensor.<br />
<br />
Fortunately we have also data from the VesselConfigId 68 in this test area to compare the measurements.<br />
<br />
[[Datei: Balitc_sea_scatter_plot_2_68_all.jpeg]]<br />
<br />
[Picture 2] Scatterplot for vesselconfigID 68 after correction of the sensor offset to waterline.<br />
<br />
Obviously there are some outliers which are shown in picture 3.<br />
<br />
[[Datei: Bsh 2 outliers.jpg]]<br />
<br />
[Picture 2] Outliers along the track 9064 in yellow - vesselconfigID 68.<br />
<br />
Without the outliers the behavier of distribution is very same teh results in the test area Großenbrode.<br />
<br />
[[Datei: Balitc_sea_scatter_plot_2_68_without.jpeg]]<br />
<br />
[Picture 1] Scatterplot for vesselconfigID 68 without outliers. Trendline in Black and optimal line in red (after correction of the sensor offset to waterline).<br />
<br />
{| class="wikitable"<br />
|-<br />
| vsselConfigId || 68 () without outliers<br />
|-<br />
| n || 100<br />
|-<br />
| mean || 0,38 meters<br />
|-<br />
| rms || 0,53 meters<br />
|-<br />
| max|| 2,1 meters<br />
|}<br />
<br />
=== Meta Data Statistics ===<br />
<br />
Statistics for the metadata entrees with some personal comments (by MartinOver). Stand 20.9.2014.<br />
<br />
{| class="prettytable"<br />
|-<br />
|<br />
'''Step'''<br />
<br />
|<br />
'''Topic'''<br />
<br />
|<br />
'''Count'''<br />
<br />
|<br />
'''State'''<br />
<br />
|<br />
'''Comment'''<br />
<br />
|-<br />
|<br />
1/1<br />
<br />
|<br />
Name<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
1/2<br />
<br />
|<br />
Description<br />
<br />
|<br />
76/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/1<br />
<br />
|<br />
Length<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
Some wrong entrees like mail addresses or comments <br />
<br />
24 “0.00” Values<br />
<br />
|-<br />
|<br />
2/2<br />
<br />
|<br />
Beam<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
37 „0.00“ Values<br />
<br />
|-<br />
|<br />
2/3<br />
<br />
|<br />
Draft<br />
<br />
|<br />
79/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/4<br />
<br />
|<br />
Displacement<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/5<br />
<br />
|<br />
Height<br />
<br />
|<br />
78/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/6<br />
<br />
|<br />
Manufacturer<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Model<br />
<br />
|<br />
49/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Type<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/3<br />
<br />
|<br />
Position below Waterline<br />
<br />
|<br />
57/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Should be Obligatory<br />
<br />
|-<br />
|<br />
3/4<br />
<br />
|<br />
Depth Measurement<br />
<br />
|<br />
?<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Where in DB?<br />
<br />
|-<br />
|<br />
3/5<br />
<br />
|<br />
Sensor Offset to Keel<br />
<br />
|<br />
6/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/6<br />
<br />
|<br />
Producer of Depth Sensor<br />
<br />
|<br />
63/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/7<br />
<br />
|<br />
Device Model<br />
<br />
|<br />
40/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
58 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
51 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/3<br />
<br />
|<br />
Position abbove Waterline<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/4<br />
<br />
|<br />
Producer<br />
<br />
|<br />
77/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/5<br />
<br />
|<br />
Model<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|}<br />
<br />
= Data Preprocessing =<br />
<br />
== Data Condition ==<br />
Raw data is usually erronous and must be corrected<br />
<br />
=== Internal data problems ===<br />
Depth data may be affected by electrical conditions and software implementations<br />
* Data is incomplete and fail their checksum (bus errors from physical transmissions errors)<br />
* Data is retrived out of sequence<br />
* Data is erronous sensor data <br />
** Approximate correctable data i.e. invalid GPS position that may be interpolated<br />
** Uncorrectable data i.e. failed log sensor that shows slow speeds<br />
* Data resolution is low i.e. for energy saving purposes GPS position is updated every 10 seconds instead of every second<br />
* Sensor data is actively miscalibrated i.e. charter companies add additional draft to the sensor depth for safety reasons<br />
<br />
=== External data problems ===<br />
Depth data may be affected by different environmental circumstances <br />
*# The water temperature affects the ultrasound echo. An inhomogen water temperature yields unwanted echos<br />
*# The seabed affects the ultrasound echo<br />
*# The seastate affects the measurement. There even may be waves when there is no wind.<br />
*# Waves may affect the roll of the measuring vessel resulting in steep measurements that are invalid.<br />
*# The sounder sensor is not the position of the GPS antenna. A position offset including heading must be incorporated.<br />
*# The time of the measurement need not correlate with the time the position was received. This may even happen due to processing time of the hard or software.<br />
*# Corrections for tide induced water levels must happen<br />
<br />
Solutions probably are<br />
*# Water temperature may be measure from the sensor, other data may be unavailable<br />
*# Modern sidescan sonar may yield information about the seabed through classifications<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# Position offsets must be provided by the user<br />
*# Time outages may be handled by the filter if precise timestamps are available in recorded data<br />
*# LAT to Mean sea level differences may be calculated from DTU10 worldwide, river gauges need to monitored<br />
<br />
[[Datei:LAT2MSLDiff.png]]<br />
<br />
<br />
== Data Condition Examples / Showcases ==<br />
<br />
=== Missing measurments (Position) ===<br />
Distribution for position updates taken from an example dataset. Left column shows the time between two consecutive measurements, right column shows how many measurements had this time update.<br />
One can see from the distribtion that the sensor is updated every second but many measurements are one or more seconds late.<br />
21 seconds with no position update may result in an instability of the subsequent filter.<br />
<pre><br />
MeasuredPosition3D<br />
GP<br />
0 :4285<br />
1000 :11295<br />
2000 :5056<br />
3000 :2134<br />
4000 :1135<br />
5000 :315<br />
6000 :154<br />
7000 :46<br />
8000 :36<br />
9000 :16<br />
10000 :12<br />
11000 :3<br />
12000 :4<br />
13000 :1<br />
14000 :7<br />
15000 :3<br />
16000 :1<br />
21000 :1<br />
</pre><br />
<br />
=== Missing measurments (Position) with erronous clock ===<br />
This example is at a 10 second position update rate. However the measurment time is faulty causing large negative and positive update rates. The clock jumps by +- one year/month/day/hour. One can further see from the many 0 time measurements that the rate at which data is sent to the nmea bus is higher than the actual position update (data is sent every second, a position update is every 10 seconds)<br />
<pre><br />
MeasuredPosition3D<br />
II<br />
-21340000 :1<br />
-13194000 :1<br />
-7998000 :1<br />
-2674000 :1<br />
-2434000 :1<br />
-2402000 :1<br />
-2030000 :1<br />
-1926000 :1<br />
-1894000 :1<br />
-1806000 :1<br />
-1480000 :1<br />
-1430000 :1<br />
-1382000 :1<br />
-1114000 :1<br />
-814000 :1<br />
-634000 :1<br />
-590000 :1<br />
-546000 :1<br />
-470000 :1<br />
-290000 :1<br />
-230000 :1<br />
-198000 :1<br />
-110000 :1<br />
-94000 :2<br />
0 :182200<br />
5000 :1<br />
10000 :20230<br />
15000 :1<br />
20000 :84<br />
50000 :1<br />
114000 :2<br />
130000 :2<br />
218000 :1<br />
250000 :1<br />
310000 :1<br />
490000 :1<br />
566000 :1<br />
610000 :1<br />
654000 :1<br />
834000 :1<br />
1134000 :1<br />
1402000 :1<br />
1450000 :1</pre><br />
<br />
== Solution Proposal ==<br />
<br />
=== Outline ===<br />
The ship is influenced by the outlined environment which can be observed. Naturally what is observed is not the state of the<br />
ship as i.e. the position if taken from GPS is 95% less than 10m accurate. To improve quality an estimation of the true state yields better results if this noise taken into account properly.<br />
<br />
=== Details ===<br />
The ship moves according to physical laws. For the easist case imagine a ship with constant velocity and direction. For any point in time you can tell where the ship is with easy math. Considering the full blown setup a ships movement is affected by many parameters such as wind speed, water current, waves, tide, and many more. The ship moves also triaxial in a dynamic way in itself (roll, pitch, yaw). Heeling even changes the measurement position with respect to the depth position. In terms of a filter this is called a system model that describes how the state of the ship may change. Given such a state you can measure what your sensor readings are and compare that to where the system thinks you are.<br />
<br />
The [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter] is known to be the best linear estimator for such situations. Unfortunately the system model is not linear which is why the Extended Kalman Filter needs to be used in order to linearize the system at hand.<br />
<br />
Todo:<br />
* Construct ship system model with at least the position state and probably its course and speed or even more (depth)<br />
* Estimate the system variance (This is a hard one, proposals welcome)<br />
* Construct the measurement model according to the data available (GPS, Log)<br />
* Estimate the measurement noise according to specifc sensors (DPGS is more accurate than GPS)<br />
<br />
The estimation with the position and depth can be retrieved and stored in a database.<br />
<br />
Pitfalls:<br />
* If the system noise is badly chosen the estimation of the system state does not converge to the true state / measurement.<br />
* If the system is very detailed the system variance can be reduced. The required cpu time for processing increases<br />
<br />
Benefits:<br />
* Having the best estimation of the true position even if measurements are noisy<br />
* Easy and effective algorithmic processing<br />
<br />
== Analysis == <br />
<br />
=== Data Sets ===<br />
Currently two test data sets are available recorded during trips from Mallorca and the Baltic Sea.<br />
In terms of data quality the Mallorca data shows many challenges. <br />
* The minimum recommended sentences from NMEA showed up with false date and time readings while having correct (!!!) message checksums. <br />
* The log on the ship was defective and delivered no readings from time to time. <br />
* The same holds true for the water temperature.<br />
* The GPS positions relatively imprecise because some last decimal digits are missing in the recordings.<br />
* The GPS positions are updated every 10 seconds while other sensor readings update almost every second.<br />
* The GPS position are sometimes way off due to false readings<br />
<br />
The Baltic Sea data set is a little bit better<br />
* Only a single day is available<br />
* GPS positions are updated every second<br />
<br />
One problem with the data is that there is time available when sensor readings were recorded. This yields problems to the filter algorithm.<br />
<br />
<br />
=== Filter Algorithm ===<br />
At first the Extended Kalman Filter is being analyzed. Using an apache implementation with the available data the filter quickly throw an exception that<br />
a matrix is not invertible because of numeric instabilities. When removing this exception the filter seems to work but the removal and its effects have yet to be analyzed.<br />
Literature suggest that a fixed interval smoother may yield better results in case of offline data processing. As it is an extension to the existing kalman filter<br />
we may consider that for the future.<br />
<br />
One problem are the different update rates of the sensors. As GPS may deliver positions at 0.1Hz speed is updated at 1Hz. Literature suggests that<br />
the missing measurements shell be modelled as a random variable with the standard deviation of the sensor. It may even be possible to update covariance matrices only partially with the sensor readings received. Input for the best solution may be formulated on the developer mailing list.<br />
<br />
== Results == <br />
A prototype implementation is shown in the following screenshots. An Extended Kalman Filter is being used. It has the position<br />
and the current bearing and velocity as system state. The input is the measurement of these four observables. The system function is<br />
good old pythagoras. In a first implementation I tried to use orthodrome distances but the system function is not differentiable which is a requirement of the Extended Kalman Filter (due to acrtan2). For small distances pythagoras should be sufficiently accurate. <br />
The initial state is taken from the first measurement for convergence reasons.<br />
<br />
The following gallery shows the results. <br />
* You can see the bad position resolution and an outlier in the first screenshot.<br />
* The second shows the same data overlaid with the applied filter. The outlier is gone and the resolution has improved.<br />
* The third screenshot shows data from a different GPS sensor with more precision (not DGPS) versus the filtered data.<br />
<br />
This of course is just a preliminary test and many setups need to be considered to make it work for most datasets.<br />
<br />
<gallery><br />
UnfilteredNMEA.png | Unfiltered GPS data<br />
FilteredNMEAVsOriginal.png | Unfiltered GPS data and Filtered GPS data<br />
PreciseGPSvsFilter.png | Another precise GPS vs Filtered GPS data<br />
</gallery><br />
<br />
The overall process even gives an estimation of the current error which is a capability of the [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter].<br />
This way positional inaccuracies may be added to the overall depth measurement inaccuracy.<br />
<br />
== Quality rating ==<br />
<br />
Each record (time, positon, depth) should become a quality rating.<br />
<br />
=== Points ===<br />
<br />
Derived from the Fibonacci series.<br />
<br />
{| class="wikitable"<br />
! Point || Description<br />
|-<br />
| 1 || extra small improvement<br />
|-<br />
| 2 || small improvement<br />
|-<br />
| 3 || medium improvement<br />
|-<br />
| 5 || large improvement<br />
|-<br />
| 8 || extra large improvement<br />
|}<br />
<br />
=== Factors ===<br />
<br />
{| class="wikitable"<br />
! style="width:15%" | Name<br />
! style="width:17%" | Factor<br />
! style="width:68%" | Description<br />
|-<br />
| depth offset || 8 (extra large) || The difference between the depth measured by the echo sounder and the depth (waterline) measured by hand.<br />
|-<br />
| device distance || 3 (medium) || The distance between gps antenna and echo sounder (lengthwise and crosswise).<br />
|-<br />
| SBAS || 3 (medium) || Satellite based augmentation system (WAAS, EGNOS, MSAS) which allows to correct the gps position.<br />
|-<br />
| position interpolation || 2 (small improvement) || Arrival of depth and position packets can have a time difference. It is/should be possible to interpolate the position.<br />
|}<br />
<br />
= Depth Rendering =<br />
<br />
= Siehe auch =<br />
* [[De:Bordnetz|Bordnetz]]<br />
* [[De:NMEA-Logger_anschliessen|NMEA-Logger_anschliessen]]<br />
* [http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCkQFjAA&url=http%3A%2F%2Fwww.dei.unipd.it%2F~chiuso%2FDOWNLOAD%2FPositioning_Heading_Kalman.pdf&ei=sSWNUMWnL4eC4gTRlYHAAw&usg=AFQjCNHq5V-PePNmDTZaGYvq0JeQFgqHVw Kalman Filtering for Positioning and Heading Control of Ships and Offshore Rigs]<br />
* [http://users.isr.ist.utl.pt/~pedro/publications/CAMS10.pdf A Multiple Model Adaptive Wave Filter for Dynamic Ship Positioning]<br />
* [http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4449205&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4449205 Echosounder Depth Tracking with the Extended Kalman Filter]</div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:En:Depth_Data&diff=2974OpenSeaMap-dev:En:Depth Data2014-09-30T19:53:01Z<p>MartinOver: /* Baltic Sea Olpenitz (Germany) */</p>
<hr />
<div>This Page describes the necessary efforts to retrieve and analyze depth data as well as create renderings from it<br />
<br />
= Data Aquisition =<br />
Depth data can be retrieved from public domain sources or from crowd sourced data.<br />
<br />
== GEBCO ==<br />
DIe Daten sind gerendert und stehen als Layer zur Verfügung:<br />
{| class="wikitable"<br />
! Zoom || Inhalt<br />
|-<br />
| 0..10 || Blaustufen und Schattierung<br />
|-<br />
| 11..18 || beschriftete Tiefenlinien, Blaustufen und Schattierung<br />
|}<br />
<br />
Noch zu lösende Probleme:<br />
* der GEBCO-Layer erzeugt einen milchigen Schleier über der Basiskarte<br />
* Tiefenlinien sind ab z=14 etwas grob (also ab da, wo dann die Flachwassertiefen beginnen) [http://map.openseamap.org/?zoom=14&lat=36.03097&lon=-5.49153&layers=BFTFTTTFFFF0 Karte]<br />
* Überschneidungen von 100m-Linie und Küstenlinie [http://map.openseamap.org/?zoom=15&lat=36.00318&lon=-5.60819&layers=BFFFTTTFFFF0FFFFF Karte]<br />
* Steilküsten (Cuba) [http://map.openseamap.org/?zoom=14&lat=19.94808&lon=-76.04289&layers=BFTFTTTFFFF0 Karte]<br />
<br />
== Crowd Sourced Data ==<br />
Crowd sourced data may be gathered by YOU. There are two options in development. A hardware and a software option.<br />
<br />
=== Workflow ===<br />
[[Datei:Workflow_depth.png]]<br />
<br />
Here you can find the document with the previous thoughts about the workflow:<br />
[http://osm.franken.de/wiki/FWT-Projekt%C3%BCbersicht-NMEA2Contours_2.1.ppt PPT Dokument]<br />
<br />
=== Hardware logger ===<br />
We are currently developing a hardware logger that may easily be plugged to the ship's network in order to log the networks data to a SD card.<br />
That data may then be uploaded by plugging the SD card to a normal computer with internet connection for upload.<br />
The main goal is to support NMEA 0183 data with options for NMEA 2000.<br />
<br />
=== Software logger ===<br />
A [[Software logger]] is in development and [http://seesea.sourceforge.net/datalogger/index.html can be downloaded here]. <br />
<br />
It currently supports: <br />
: Bluetooth <br />
: Serial ports<br />
: Internet Protocol (IP)<br />
It processes NMEA 0183 and AIS data.<br />
<br />
For vendor specific protocols such as SeaTalk 1 you have to use a [[De:NMEA-Logger_anschliessen|converter]] to NMEA 0183 data.<br />
<br />
NMEA 2000 support is only available if data is transcoded to NMEA 0183 by a converter.<br />
<br />
=== Chart Plotters ===<br />
<br />
Some chart plotters are able to save tracks out-of-the-box, e.g. several Raymarine (FSH files) and Humminbird (SON files) devices. Those files may directly be used as data source.<br />
<br />
<br />
=== Upload Process ===<br />
Uploading data is possible through using the [http://seesea.sourceforge.net/datalogger/index.html OpenSeaMap Data Logger Software] or via [http://depth.openseamap.org/ Web Interface].<br />
The system is currently being tested. <br />
<br />
[[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|You'll find further information here]].<br />
<br />
=== Test Data ===<br />
<br />
<br />
==== Brombachsee (Germany)====<br />
<br />
Test data for Openseamap: [http://osm.franken.de/wiki/test_data_brombachsee.zip Brombachsee_Test_Data]<br />
<br />
dgm_brombachsee.tif: Digital Elevation Model of the sea derived from height lines WWA (C).<br />
<br />
shapes_brombachsee.shp: Shape File derived from 4 NMEA Tracks. "dbs" is the original Sounding and "deep_cor" the depth after a correction (gauge levl).<br />
<br />
gpx_brombachsee.gpx: ele = "dbs" from the Shape File<br />
<br />
[[Datei:Brombachsee.png]]<br />
Resulting Digital Elevation Model<br />
<br />
==== Baltic Sea - near Großenbrode (Germany)====<br />
<br />
First results with an RMS error < 1,5 meter compared to an official dataset of the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].<br />
<br />
[[Datei: Bsh_results_overview.jpg]]<br />
<br />
[Picture 1] '''''OSM map in background, raster Depth Model derived from BSH data and crowed sourced OpenSeaMap Points - Overview'''''<br />
<br />
Blue = flat BSH data, red = deep BSH data.<br />
<br>Blue points = OpenSeaMap raw measuring points.<br />
<br />
{| class="wikitable"<br />
|-<br />
| n || 5062<br />
|-<br />
|-<br />
| datasets || 21<br />
|-<br />
| max deviation || 3,43 meters<br />
|-<br />
| mean (abs) || 0,69 meters<br />
|-<br />
| RMS +/- || 0,91 meters<br />
|}<br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| VesselConfig ID || 68<br />
|-<br />
| Manufacturer || Bavaria Yachtbau<br />
|-<br />
| Model || B32<br />
|-<br />
| Length || 10,0 meters<br />
|-<br />
| Beam || 3,35 meters<br />
|-<br />
| Draft || 1,6 meters<br />
|-<br />
| Height || 14 meters<br />
|-<br />
| Displacement || 4,2 t<br />
|-<br />
| Sensor manufacturer || Raymarine<br />
|-<br />
| Sensor Offset to waterline || 0,45 meters<br />
|-<br />
| Sensor Offset to keel || 1,15 meters<br />
|}<br />
<br />
<br />
<br />
A digital Deep Model raster was computed from the BSH point dataset (c).<br />
The depth of the crowed sourced dataset was compared to the derived raster dataset from the BSH.<br />
The raw crowed sourced dataset was corrected by the sensor offset (0,45 meters).<br />
<br />
[[Datei: Scatter_cor_sensor.jpeg]]<br />
<br />
[Picture 2] '''''Scatter plot: BSH data on the x-axis and the crowed sourced data on the y-axis. Trend line in black and optimal line in red.'''''<br />
<br />
The deviation from the reference dataset increases with the depth measured.<br />
<br />
As you see in the picture below the difference between the datasets has an regular pattern maybe deepending on waves.<br />
<br />
[[Datei: Bsh_results_detail_10_classes.jpg]]<br />
<br />
[Picture 3] '''''Crowed sourced OpenSeaMap track points and the difference from the BSH dataset'''''<br />
<br />
White = low difference, orange = medium difference, red = strong difference<br />
<br />
Download of the data http://osm.franken.de/data/baltic_sea_test_data.zip<br />
'''Be aware of the copyright from the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].'''<br />
The data in the dataset is not corrected by sensor offset.<br />
<br />
==== Baltic Sea Olpenitz (Germany)====<br />
<br />
In this test area we have tracks from two different vessel configurations. <br />
The fist one was the one from the test area Großenbrode (config ID 68).<br />
<br />
In the Table below the settings for die vesselconfigid 110 are shown: <br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| VesselConfigId || 110<br />
|-<br />
| Manufacturer || Waarschip<br />
|-<br />
| Model || 570<br />
|-<br />
| Length || 5,7 meters<br />
|-<br />
| Beam || 2,45 meters<br />
|-<br />
| Draft || 1,0 meters<br />
|-<br />
| Height || 9.1 meters<br />
|-<br />
| Displacement || 0,8 t<br />
|-<br />
| Sensor manufacturer || Tacktick/ Airmar<br />
|-<br />
| Sensor Model || T912<br />
|-<br />
| Sensor Offset to waterline || 0,2 meters<br />
|-<br />
| Sensor Offset to keel || 0,45 meters<br />
|}<br />
<br />
[[Datei: Balitc_sea_scatter_plot_2.jpeg]]<br />
<br />
[Picture 1] Scatterplot for vesselconfigID 110. Trendline in Black and optimal line in red (after correction of the sensor offset to waterline).<br />
<br />
{| class="wikitable"<br />
|-<br />
| vsselConfigId || 110<br />
|-<br />
| n || 247<br />
|-<br />
| mean || 0,49 meters<br />
|-<br />
| rms || 0,62 meters<br />
|-<br />
| max|| 2,53 meters<br />
|}<br />
<br />
The distribution is quite different from the data recorded in the test area Großenbrode with an different sensor.<br />
<br />
Fortunately we have also data from the VesselConfigId 68 in this test area to compare the measurements.<br />
<br />
[[Datei: Balitc_sea_scatter_plot_2_68_all.jpeg]]<br />
<br />
[Picture 2] Scatterplot for vesselconfigID 68 after correction of the sensor offset to waterline.<br />
<br />
Obviously there are some outliers which are shown in picture 3.<br />
<br />
[[Datei: Bsh 2 outliers.jpg]]<br />
<br />
[Picture 2] Outliers along the track 9064 in yellow - vesselconfigID 68.<br />
<br />
Without the outliers the behavier of distribution is very same teh results in the test area Großenbrode.<br />
<br />
[[Datei: Balitc_sea_scatter_plot_2_68_without.jpeg]]<br />
<br />
[Picture 1] Scatterplot for vesselconfigID 68 without outliers. Trendline in Black and optimal line in red (after correction of the sensor offset to waterline).<br />
<br />
=== Meta Data Statistics ===<br />
<br />
Statistics for the metadata entrees with some personal comments (by MartinOver). Stand 20.9.2014.<br />
<br />
{| class="prettytable"<br />
|-<br />
|<br />
'''Step'''<br />
<br />
|<br />
'''Topic'''<br />
<br />
|<br />
'''Count'''<br />
<br />
|<br />
'''State'''<br />
<br />
|<br />
'''Comment'''<br />
<br />
|-<br />
|<br />
1/1<br />
<br />
|<br />
Name<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
1/2<br />
<br />
|<br />
Description<br />
<br />
|<br />
76/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/1<br />
<br />
|<br />
Length<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
Some wrong entrees like mail addresses or comments <br />
<br />
24 “0.00” Values<br />
<br />
|-<br />
|<br />
2/2<br />
<br />
|<br />
Beam<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
37 „0.00“ Values<br />
<br />
|-<br />
|<br />
2/3<br />
<br />
|<br />
Draft<br />
<br />
|<br />
79/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/4<br />
<br />
|<br />
Displacement<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/5<br />
<br />
|<br />
Height<br />
<br />
|<br />
78/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/6<br />
<br />
|<br />
Manufacturer<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Model<br />
<br />
|<br />
49/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Type<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/3<br />
<br />
|<br />
Position below Waterline<br />
<br />
|<br />
57/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Should be Obligatory<br />
<br />
|-<br />
|<br />
3/4<br />
<br />
|<br />
Depth Measurement<br />
<br />
|<br />
?<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Where in DB?<br />
<br />
|-<br />
|<br />
3/5<br />
<br />
|<br />
Sensor Offset to Keel<br />
<br />
|<br />
6/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/6<br />
<br />
|<br />
Producer of Depth Sensor<br />
<br />
|<br />
63/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/7<br />
<br />
|<br />
Device Model<br />
<br />
|<br />
40/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
58 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
51 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/3<br />
<br />
|<br />
Position abbove Waterline<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/4<br />
<br />
|<br />
Producer<br />
<br />
|<br />
77/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/5<br />
<br />
|<br />
Model<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|}<br />
<br />
= Data Preprocessing =<br />
<br />
== Data Condition ==<br />
Raw data is usually erronous and must be corrected<br />
<br />
=== Internal data problems ===<br />
Depth data may be affected by electrical conditions and software implementations<br />
* Data is incomplete and fail their checksum (bus errors from physical transmissions errors)<br />
* Data is retrived out of sequence<br />
* Data is erronous sensor data <br />
** Approximate correctable data i.e. invalid GPS position that may be interpolated<br />
** Uncorrectable data i.e. failed log sensor that shows slow speeds<br />
* Data resolution is low i.e. for energy saving purposes GPS position is updated every 10 seconds instead of every second<br />
* Sensor data is actively miscalibrated i.e. charter companies add additional draft to the sensor depth for safety reasons<br />
<br />
=== External data problems ===<br />
Depth data may be affected by different environmental circumstances <br />
*# The water temperature affects the ultrasound echo. An inhomogen water temperature yields unwanted echos<br />
*# The seabed affects the ultrasound echo<br />
*# The seastate affects the measurement. There even may be waves when there is no wind.<br />
*# Waves may affect the roll of the measuring vessel resulting in steep measurements that are invalid.<br />
*# The sounder sensor is not the position of the GPS antenna. A position offset including heading must be incorporated.<br />
*# The time of the measurement need not correlate with the time the position was received. This may even happen due to processing time of the hard or software.<br />
*# Corrections for tide induced water levels must happen<br />
<br />
Solutions probably are<br />
*# Water temperature may be measure from the sensor, other data may be unavailable<br />
*# Modern sidescan sonar may yield information about the seabed through classifications<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# Position offsets must be provided by the user<br />
*# Time outages may be handled by the filter if precise timestamps are available in recorded data<br />
*# LAT to Mean sea level differences may be calculated from DTU10 worldwide, river gauges need to monitored<br />
<br />
[[Datei:LAT2MSLDiff.png]]<br />
<br />
<br />
== Data Condition Examples / Showcases ==<br />
<br />
=== Missing measurments (Position) ===<br />
Distribution for position updates taken from an example dataset. Left column shows the time between two consecutive measurements, right column shows how many measurements had this time update.<br />
One can see from the distribtion that the sensor is updated every second but many measurements are one or more seconds late.<br />
21 seconds with no position update may result in an instability of the subsequent filter.<br />
<pre><br />
MeasuredPosition3D<br />
GP<br />
0 :4285<br />
1000 :11295<br />
2000 :5056<br />
3000 :2134<br />
4000 :1135<br />
5000 :315<br />
6000 :154<br />
7000 :46<br />
8000 :36<br />
9000 :16<br />
10000 :12<br />
11000 :3<br />
12000 :4<br />
13000 :1<br />
14000 :7<br />
15000 :3<br />
16000 :1<br />
21000 :1<br />
</pre><br />
<br />
=== Missing measurments (Position) with erronous clock ===<br />
This example is at a 10 second position update rate. However the measurment time is faulty causing large negative and positive update rates. The clock jumps by +- one year/month/day/hour. One can further see from the many 0 time measurements that the rate at which data is sent to the nmea bus is higher than the actual position update (data is sent every second, a position update is every 10 seconds)<br />
<pre><br />
MeasuredPosition3D<br />
II<br />
-21340000 :1<br />
-13194000 :1<br />
-7998000 :1<br />
-2674000 :1<br />
-2434000 :1<br />
-2402000 :1<br />
-2030000 :1<br />
-1926000 :1<br />
-1894000 :1<br />
-1806000 :1<br />
-1480000 :1<br />
-1430000 :1<br />
-1382000 :1<br />
-1114000 :1<br />
-814000 :1<br />
-634000 :1<br />
-590000 :1<br />
-546000 :1<br />
-470000 :1<br />
-290000 :1<br />
-230000 :1<br />
-198000 :1<br />
-110000 :1<br />
-94000 :2<br />
0 :182200<br />
5000 :1<br />
10000 :20230<br />
15000 :1<br />
20000 :84<br />
50000 :1<br />
114000 :2<br />
130000 :2<br />
218000 :1<br />
250000 :1<br />
310000 :1<br />
490000 :1<br />
566000 :1<br />
610000 :1<br />
654000 :1<br />
834000 :1<br />
1134000 :1<br />
1402000 :1<br />
1450000 :1</pre><br />
<br />
== Solution Proposal ==<br />
<br />
=== Outline ===<br />
The ship is influenced by the outlined environment which can be observed. Naturally what is observed is not the state of the<br />
ship as i.e. the position if taken from GPS is 95% less than 10m accurate. To improve quality an estimation of the true state yields better results if this noise taken into account properly.<br />
<br />
=== Details ===<br />
The ship moves according to physical laws. For the easist case imagine a ship with constant velocity and direction. For any point in time you can tell where the ship is with easy math. Considering the full blown setup a ships movement is affected by many parameters such as wind speed, water current, waves, tide, and many more. The ship moves also triaxial in a dynamic way in itself (roll, pitch, yaw). Heeling even changes the measurement position with respect to the depth position. In terms of a filter this is called a system model that describes how the state of the ship may change. Given such a state you can measure what your sensor readings are and compare that to where the system thinks you are.<br />
<br />
The [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter] is known to be the best linear estimator for such situations. Unfortunately the system model is not linear which is why the Extended Kalman Filter needs to be used in order to linearize the system at hand.<br />
<br />
Todo:<br />
* Construct ship system model with at least the position state and probably its course and speed or even more (depth)<br />
* Estimate the system variance (This is a hard one, proposals welcome)<br />
* Construct the measurement model according to the data available (GPS, Log)<br />
* Estimate the measurement noise according to specifc sensors (DPGS is more accurate than GPS)<br />
<br />
The estimation with the position and depth can be retrieved and stored in a database.<br />
<br />
Pitfalls:<br />
* If the system noise is badly chosen the estimation of the system state does not converge to the true state / measurement.<br />
* If the system is very detailed the system variance can be reduced. The required cpu time for processing increases<br />
<br />
Benefits:<br />
* Having the best estimation of the true position even if measurements are noisy<br />
* Easy and effective algorithmic processing<br />
<br />
== Analysis == <br />
<br />
=== Data Sets ===<br />
Currently two test data sets are available recorded during trips from Mallorca and the Baltic Sea.<br />
In terms of data quality the Mallorca data shows many challenges. <br />
* The minimum recommended sentences from NMEA showed up with false date and time readings while having correct (!!!) message checksums. <br />
* The log on the ship was defective and delivered no readings from time to time. <br />
* The same holds true for the water temperature.<br />
* The GPS positions relatively imprecise because some last decimal digits are missing in the recordings.<br />
* The GPS positions are updated every 10 seconds while other sensor readings update almost every second.<br />
* The GPS position are sometimes way off due to false readings<br />
<br />
The Baltic Sea data set is a little bit better<br />
* Only a single day is available<br />
* GPS positions are updated every second<br />
<br />
One problem with the data is that there is time available when sensor readings were recorded. This yields problems to the filter algorithm.<br />
<br />
<br />
=== Filter Algorithm ===<br />
At first the Extended Kalman Filter is being analyzed. Using an apache implementation with the available data the filter quickly throw an exception that<br />
a matrix is not invertible because of numeric instabilities. When removing this exception the filter seems to work but the removal and its effects have yet to be analyzed.<br />
Literature suggest that a fixed interval smoother may yield better results in case of offline data processing. As it is an extension to the existing kalman filter<br />
we may consider that for the future.<br />
<br />
One problem are the different update rates of the sensors. As GPS may deliver positions at 0.1Hz speed is updated at 1Hz. Literature suggests that<br />
the missing measurements shell be modelled as a random variable with the standard deviation of the sensor. It may even be possible to update covariance matrices only partially with the sensor readings received. Input for the best solution may be formulated on the developer mailing list.<br />
<br />
== Results == <br />
A prototype implementation is shown in the following screenshots. An Extended Kalman Filter is being used. It has the position<br />
and the current bearing and velocity as system state. The input is the measurement of these four observables. The system function is<br />
good old pythagoras. In a first implementation I tried to use orthodrome distances but the system function is not differentiable which is a requirement of the Extended Kalman Filter (due to acrtan2). For small distances pythagoras should be sufficiently accurate. <br />
The initial state is taken from the first measurement for convergence reasons.<br />
<br />
The following gallery shows the results. <br />
* You can see the bad position resolution and an outlier in the first screenshot.<br />
* The second shows the same data overlaid with the applied filter. The outlier is gone and the resolution has improved.<br />
* The third screenshot shows data from a different GPS sensor with more precision (not DGPS) versus the filtered data.<br />
<br />
This of course is just a preliminary test and many setups need to be considered to make it work for most datasets.<br />
<br />
<gallery><br />
UnfilteredNMEA.png | Unfiltered GPS data<br />
FilteredNMEAVsOriginal.png | Unfiltered GPS data and Filtered GPS data<br />
PreciseGPSvsFilter.png | Another precise GPS vs Filtered GPS data<br />
</gallery><br />
<br />
The overall process even gives an estimation of the current error which is a capability of the [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter].<br />
This way positional inaccuracies may be added to the overall depth measurement inaccuracy.<br />
<br />
== Quality rating ==<br />
<br />
Each record (time, positon, depth) should become a quality rating.<br />
<br />
=== Points ===<br />
<br />
Derived from the Fibonacci series.<br />
<br />
{| class="wikitable"<br />
! Point || Description<br />
|-<br />
| 1 || extra small improvement<br />
|-<br />
| 2 || small improvement<br />
|-<br />
| 3 || medium improvement<br />
|-<br />
| 5 || large improvement<br />
|-<br />
| 8 || extra large improvement<br />
|}<br />
<br />
=== Factors ===<br />
<br />
{| class="wikitable"<br />
! style="width:15%" | Name<br />
! style="width:17%" | Factor<br />
! style="width:68%" | Description<br />
|-<br />
| depth offset || 8 (extra large) || The difference between the depth measured by the echo sounder and the depth (waterline) measured by hand.<br />
|-<br />
| device distance || 3 (medium) || The distance between gps antenna and echo sounder (lengthwise and crosswise).<br />
|-<br />
| SBAS || 3 (medium) || Satellite based augmentation system (WAAS, EGNOS, MSAS) which allows to correct the gps position.<br />
|-<br />
| position interpolation || 2 (small improvement) || Arrival of depth and position packets can have a time difference. It is/should be possible to interpolate the position.<br />
|}<br />
<br />
= Depth Rendering =<br />
<br />
= Siehe auch =<br />
* [[De:Bordnetz|Bordnetz]]<br />
* [[De:NMEA-Logger_anschliessen|NMEA-Logger_anschliessen]]<br />
* [http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCkQFjAA&url=http%3A%2F%2Fwww.dei.unipd.it%2F~chiuso%2FDOWNLOAD%2FPositioning_Heading_Kalman.pdf&ei=sSWNUMWnL4eC4gTRlYHAAw&usg=AFQjCNHq5V-PePNmDTZaGYvq0JeQFgqHVw Kalman Filtering for Positioning and Heading Control of Ships and Offshore Rigs]<br />
* [http://users.isr.ist.utl.pt/~pedro/publications/CAMS10.pdf A Multiple Model Adaptive Wave Filter for Dynamic Ship Positioning]<br />
* [http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4449205&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4449205 Echosounder Depth Tracking with the Extended Kalman Filter]</div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:En:Depth_Data&diff=2973OpenSeaMap-dev:En:Depth Data2014-09-30T19:51:32Z<p>MartinOver: /* Baltic Sea Olpenitz (Germany) */</p>
<hr />
<div>This Page describes the necessary efforts to retrieve and analyze depth data as well as create renderings from it<br />
<br />
= Data Aquisition =<br />
Depth data can be retrieved from public domain sources or from crowd sourced data.<br />
<br />
== GEBCO ==<br />
DIe Daten sind gerendert und stehen als Layer zur Verfügung:<br />
{| class="wikitable"<br />
! Zoom || Inhalt<br />
|-<br />
| 0..10 || Blaustufen und Schattierung<br />
|-<br />
| 11..18 || beschriftete Tiefenlinien, Blaustufen und Schattierung<br />
|}<br />
<br />
Noch zu lösende Probleme:<br />
* der GEBCO-Layer erzeugt einen milchigen Schleier über der Basiskarte<br />
* Tiefenlinien sind ab z=14 etwas grob (also ab da, wo dann die Flachwassertiefen beginnen) [http://map.openseamap.org/?zoom=14&lat=36.03097&lon=-5.49153&layers=BFTFTTTFFFF0 Karte]<br />
* Überschneidungen von 100m-Linie und Küstenlinie [http://map.openseamap.org/?zoom=15&lat=36.00318&lon=-5.60819&layers=BFFFTTTFFFF0FFFFF Karte]<br />
* Steilküsten (Cuba) [http://map.openseamap.org/?zoom=14&lat=19.94808&lon=-76.04289&layers=BFTFTTTFFFF0 Karte]<br />
<br />
== Crowd Sourced Data ==<br />
Crowd sourced data may be gathered by YOU. There are two options in development. A hardware and a software option.<br />
<br />
=== Workflow ===<br />
[[Datei:Workflow_depth.png]]<br />
<br />
Here you can find the document with the previous thoughts about the workflow:<br />
[http://osm.franken.de/wiki/FWT-Projekt%C3%BCbersicht-NMEA2Contours_2.1.ppt PPT Dokument]<br />
<br />
=== Hardware logger ===<br />
We are currently developing a hardware logger that may easily be plugged to the ship's network in order to log the networks data to a SD card.<br />
That data may then be uploaded by plugging the SD card to a normal computer with internet connection for upload.<br />
The main goal is to support NMEA 0183 data with options for NMEA 2000.<br />
<br />
=== Software logger ===<br />
A [[Software logger]] is in development and [http://seesea.sourceforge.net/datalogger/index.html can be downloaded here]. <br />
<br />
It currently supports: <br />
: Bluetooth <br />
: Serial ports<br />
: Internet Protocol (IP)<br />
It processes NMEA 0183 and AIS data.<br />
<br />
For vendor specific protocols such as SeaTalk 1 you have to use a [[De:NMEA-Logger_anschliessen|converter]] to NMEA 0183 data.<br />
<br />
NMEA 2000 support is only available if data is transcoded to NMEA 0183 by a converter.<br />
<br />
=== Chart Plotters ===<br />
<br />
Some chart plotters are able to save tracks out-of-the-box, e.g. several Raymarine (FSH files) and Humminbird (SON files) devices. Those files may directly be used as data source.<br />
<br />
<br />
=== Upload Process ===<br />
Uploading data is possible through using the [http://seesea.sourceforge.net/datalogger/index.html OpenSeaMap Data Logger Software] or via [http://depth.openseamap.org/ Web Interface].<br />
The system is currently being tested. <br />
<br />
[[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|You'll find further information here]].<br />
<br />
=== Test Data ===<br />
<br />
<br />
==== Brombachsee (Germany)====<br />
<br />
Test data for Openseamap: [http://osm.franken.de/wiki/test_data_brombachsee.zip Brombachsee_Test_Data]<br />
<br />
dgm_brombachsee.tif: Digital Elevation Model of the sea derived from height lines WWA (C).<br />
<br />
shapes_brombachsee.shp: Shape File derived from 4 NMEA Tracks. "dbs" is the original Sounding and "deep_cor" the depth after a correction (gauge levl).<br />
<br />
gpx_brombachsee.gpx: ele = "dbs" from the Shape File<br />
<br />
[[Datei:Brombachsee.png]]<br />
Resulting Digital Elevation Model<br />
<br />
==== Baltic Sea - near Großenbrode (Germany)====<br />
<br />
First results with an RMS error < 1,5 meter compared to an official dataset of the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].<br />
<br />
[[Datei: Bsh_results_overview.jpg]]<br />
<br />
[Picture 1] '''''OSM map in background, raster Depth Model derived from BSH data and crowed sourced OpenSeaMap Points - Overview'''''<br />
<br />
Blue = flat BSH data, red = deep BSH data.<br />
<br>Blue points = OpenSeaMap raw measuring points.<br />
<br />
{| class="wikitable"<br />
|-<br />
| n || 5062<br />
|-<br />
|-<br />
| datasets || 21<br />
|-<br />
| max deviation || 3,43 meters<br />
|-<br />
| mean (abs) || 0,69 meters<br />
|-<br />
| RMS +/- || 0,91 meters<br />
|}<br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| VesselConfig ID || 68<br />
|-<br />
| Manufacturer || Bavaria Yachtbau<br />
|-<br />
| Model || B32<br />
|-<br />
| Length || 10,0 meters<br />
|-<br />
| Beam || 3,35 meters<br />
|-<br />
| Draft || 1,6 meters<br />
|-<br />
| Height || 14 meters<br />
|-<br />
| Displacement || 4,2 t<br />
|-<br />
| Sensor manufacturer || Raymarine<br />
|-<br />
| Sensor Offset to waterline || 0,45 meters<br />
|-<br />
| Sensor Offset to keel || 1,15 meters<br />
|}<br />
<br />
<br />
<br />
A digital Deep Model raster was computed from the BSH point dataset (c).<br />
The depth of the crowed sourced dataset was compared to the derived raster dataset from the BSH.<br />
The raw crowed sourced dataset was corrected by the sensor offset (0,45 meters).<br />
<br />
[[Datei: Scatter_cor_sensor.jpeg]]<br />
<br />
[Picture 2] '''''Scatter plot: BSH data on the x-axis and the crowed sourced data on the y-axis. Trend line in black and optimal line in red.'''''<br />
<br />
The deviation from the reference dataset increases with the depth measured.<br />
<br />
As you see in the picture below the difference between the datasets has an regular pattern maybe deepending on waves.<br />
<br />
[[Datei: Bsh_results_detail_10_classes.jpg]]<br />
<br />
[Picture 3] '''''Crowed sourced OpenSeaMap track points and the difference from the BSH dataset'''''<br />
<br />
White = low difference, orange = medium difference, red = strong difference<br />
<br />
Download of the data http://osm.franken.de/data/baltic_sea_test_data.zip<br />
'''Be aware of the copyright from the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].'''<br />
The data in the dataset is not corrected by sensor offset.<br />
<br />
==== Baltic Sea Olpenitz (Germany)====<br />
<br />
In this test area we have tracks from two different vessel configurations. <br />
The fist one was the one from the test area Großenbrode (config ID 68).<br />
<br />
In the Table below the settings for die vesselconfigid 110 are shown: <br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| VesselConfigId || 110<br />
|-<br />
| Manufacturer || Waarschip<br />
|-<br />
| Model || 570<br />
|-<br />
| Length || 5,7 meters<br />
|-<br />
| Beam || 2,45 meters<br />
|-<br />
| Draft || 1,0 meters<br />
|-<br />
| Height || 9.1 meters<br />
|-<br />
| Displacement || 0,8 t<br />
|-<br />
| Sensor manufacturer || Tacktick/ Airmar<br />
|-<br />
| Sensor Model || T912<br />
|-<br />
| Sensor Offset to waterline || 0,2 meters<br />
|-<br />
| Sensor Offset to keel || 0,45 meters<br />
|}<br />
<br />
[[Datei: Balitc_sea_scatter_plot_2.jpeg]]<br />
<br />
[Picture 1] Scatterplot for vesselconfigID 110. Trendline in Black and optimal line in red (after correction of the sensor offset to waterline).<br />
<br />
{| class="wikitable"<br />
|-<br />
| vsselConfigId || 110<br />
|-<br />
| n || 247<br />
|-<br />
| mean || 0,49 meters<br />
|-<br />
| rms || 0,62 meters<br />
|-<br />
| max|| 2,53 meters<br />
|}<br />
<br />
The distribution is quite different from the data recorded in the test area Großenbrode with an different sensor.<br />
<br />
Fortunately we have also data from the VesselConfigId 68 in this test area to compare the measurements.<br />
<br />
[[Datei: Balitc_sea_scatter_plot_2_68_all.jpeg]]<br />
<br />
[Picture 2] Scatterplot for vesselconfigID 68 after correction of the sensor offset to waterline.<br />
<br />
Obviously there are some outliers which are shown in picture 3.<br />
<br />
[[Datei: Bsh 2 outliers.jpg]]<br />
<br />
[Picture 2] Outliers along the track 9064 - vesselconfigID 68.<br />
<br />
Without the outliers the behavier of distribution is very same teh results in the test area Großenbrode.<br />
<br />
[[Datei: Balitc_sea_scatter_plot_2_68_without.jpeg]]<br />
<br />
=== Meta Data Statistics ===<br />
<br />
Statistics for the metadata entrees with some personal comments (by MartinOver). Stand 20.9.2014.<br />
<br />
{| class="prettytable"<br />
|-<br />
|<br />
'''Step'''<br />
<br />
|<br />
'''Topic'''<br />
<br />
|<br />
'''Count'''<br />
<br />
|<br />
'''State'''<br />
<br />
|<br />
'''Comment'''<br />
<br />
|-<br />
|<br />
1/1<br />
<br />
|<br />
Name<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
1/2<br />
<br />
|<br />
Description<br />
<br />
|<br />
76/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/1<br />
<br />
|<br />
Length<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
Some wrong entrees like mail addresses or comments <br />
<br />
24 “0.00” Values<br />
<br />
|-<br />
|<br />
2/2<br />
<br />
|<br />
Beam<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
37 „0.00“ Values<br />
<br />
|-<br />
|<br />
2/3<br />
<br />
|<br />
Draft<br />
<br />
|<br />
79/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/4<br />
<br />
|<br />
Displacement<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/5<br />
<br />
|<br />
Height<br />
<br />
|<br />
78/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/6<br />
<br />
|<br />
Manufacturer<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Model<br />
<br />
|<br />
49/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Type<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/3<br />
<br />
|<br />
Position below Waterline<br />
<br />
|<br />
57/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Should be Obligatory<br />
<br />
|-<br />
|<br />
3/4<br />
<br />
|<br />
Depth Measurement<br />
<br />
|<br />
?<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Where in DB?<br />
<br />
|-<br />
|<br />
3/5<br />
<br />
|<br />
Sensor Offset to Keel<br />
<br />
|<br />
6/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/6<br />
<br />
|<br />
Producer of Depth Sensor<br />
<br />
|<br />
63/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/7<br />
<br />
|<br />
Device Model<br />
<br />
|<br />
40/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
58 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
51 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/3<br />
<br />
|<br />
Position abbove Waterline<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/4<br />
<br />
|<br />
Producer<br />
<br />
|<br />
77/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/5<br />
<br />
|<br />
Model<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|}<br />
<br />
= Data Preprocessing =<br />
<br />
== Data Condition ==<br />
Raw data is usually erronous and must be corrected<br />
<br />
=== Internal data problems ===<br />
Depth data may be affected by electrical conditions and software implementations<br />
* Data is incomplete and fail their checksum (bus errors from physical transmissions errors)<br />
* Data is retrived out of sequence<br />
* Data is erronous sensor data <br />
** Approximate correctable data i.e. invalid GPS position that may be interpolated<br />
** Uncorrectable data i.e. failed log sensor that shows slow speeds<br />
* Data resolution is low i.e. for energy saving purposes GPS position is updated every 10 seconds instead of every second<br />
* Sensor data is actively miscalibrated i.e. charter companies add additional draft to the sensor depth for safety reasons<br />
<br />
=== External data problems ===<br />
Depth data may be affected by different environmental circumstances <br />
*# The water temperature affects the ultrasound echo. An inhomogen water temperature yields unwanted echos<br />
*# The seabed affects the ultrasound echo<br />
*# The seastate affects the measurement. There even may be waves when there is no wind.<br />
*# Waves may affect the roll of the measuring vessel resulting in steep measurements that are invalid.<br />
*# The sounder sensor is not the position of the GPS antenna. A position offset including heading must be incorporated.<br />
*# The time of the measurement need not correlate with the time the position was received. This may even happen due to processing time of the hard or software.<br />
*# Corrections for tide induced water levels must happen<br />
<br />
Solutions probably are<br />
*# Water temperature may be measure from the sensor, other data may be unavailable<br />
*# Modern sidescan sonar may yield information about the seabed through classifications<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# Position offsets must be provided by the user<br />
*# Time outages may be handled by the filter if precise timestamps are available in recorded data<br />
*# LAT to Mean sea level differences may be calculated from DTU10 worldwide, river gauges need to monitored<br />
<br />
[[Datei:LAT2MSLDiff.png]]<br />
<br />
<br />
== Data Condition Examples / Showcases ==<br />
<br />
=== Missing measurments (Position) ===<br />
Distribution for position updates taken from an example dataset. Left column shows the time between two consecutive measurements, right column shows how many measurements had this time update.<br />
One can see from the distribtion that the sensor is updated every second but many measurements are one or more seconds late.<br />
21 seconds with no position update may result in an instability of the subsequent filter.<br />
<pre><br />
MeasuredPosition3D<br />
GP<br />
0 :4285<br />
1000 :11295<br />
2000 :5056<br />
3000 :2134<br />
4000 :1135<br />
5000 :315<br />
6000 :154<br />
7000 :46<br />
8000 :36<br />
9000 :16<br />
10000 :12<br />
11000 :3<br />
12000 :4<br />
13000 :1<br />
14000 :7<br />
15000 :3<br />
16000 :1<br />
21000 :1<br />
</pre><br />
<br />
=== Missing measurments (Position) with erronous clock ===<br />
This example is at a 10 second position update rate. However the measurment time is faulty causing large negative and positive update rates. The clock jumps by +- one year/month/day/hour. One can further see from the many 0 time measurements that the rate at which data is sent to the nmea bus is higher than the actual position update (data is sent every second, a position update is every 10 seconds)<br />
<pre><br />
MeasuredPosition3D<br />
II<br />
-21340000 :1<br />
-13194000 :1<br />
-7998000 :1<br />
-2674000 :1<br />
-2434000 :1<br />
-2402000 :1<br />
-2030000 :1<br />
-1926000 :1<br />
-1894000 :1<br />
-1806000 :1<br />
-1480000 :1<br />
-1430000 :1<br />
-1382000 :1<br />
-1114000 :1<br />
-814000 :1<br />
-634000 :1<br />
-590000 :1<br />
-546000 :1<br />
-470000 :1<br />
-290000 :1<br />
-230000 :1<br />
-198000 :1<br />
-110000 :1<br />
-94000 :2<br />
0 :182200<br />
5000 :1<br />
10000 :20230<br />
15000 :1<br />
20000 :84<br />
50000 :1<br />
114000 :2<br />
130000 :2<br />
218000 :1<br />
250000 :1<br />
310000 :1<br />
490000 :1<br />
566000 :1<br />
610000 :1<br />
654000 :1<br />
834000 :1<br />
1134000 :1<br />
1402000 :1<br />
1450000 :1</pre><br />
<br />
== Solution Proposal ==<br />
<br />
=== Outline ===<br />
The ship is influenced by the outlined environment which can be observed. Naturally what is observed is not the state of the<br />
ship as i.e. the position if taken from GPS is 95% less than 10m accurate. To improve quality an estimation of the true state yields better results if this noise taken into account properly.<br />
<br />
=== Details ===<br />
The ship moves according to physical laws. For the easist case imagine a ship with constant velocity and direction. For any point in time you can tell where the ship is with easy math. Considering the full blown setup a ships movement is affected by many parameters such as wind speed, water current, waves, tide, and many more. The ship moves also triaxial in a dynamic way in itself (roll, pitch, yaw). Heeling even changes the measurement position with respect to the depth position. In terms of a filter this is called a system model that describes how the state of the ship may change. Given such a state you can measure what your sensor readings are and compare that to where the system thinks you are.<br />
<br />
The [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter] is known to be the best linear estimator for such situations. Unfortunately the system model is not linear which is why the Extended Kalman Filter needs to be used in order to linearize the system at hand.<br />
<br />
Todo:<br />
* Construct ship system model with at least the position state and probably its course and speed or even more (depth)<br />
* Estimate the system variance (This is a hard one, proposals welcome)<br />
* Construct the measurement model according to the data available (GPS, Log)<br />
* Estimate the measurement noise according to specifc sensors (DPGS is more accurate than GPS)<br />
<br />
The estimation with the position and depth can be retrieved and stored in a database.<br />
<br />
Pitfalls:<br />
* If the system noise is badly chosen the estimation of the system state does not converge to the true state / measurement.<br />
* If the system is very detailed the system variance can be reduced. The required cpu time for processing increases<br />
<br />
Benefits:<br />
* Having the best estimation of the true position even if measurements are noisy<br />
* Easy and effective algorithmic processing<br />
<br />
== Analysis == <br />
<br />
=== Data Sets ===<br />
Currently two test data sets are available recorded during trips from Mallorca and the Baltic Sea.<br />
In terms of data quality the Mallorca data shows many challenges. <br />
* The minimum recommended sentences from NMEA showed up with false date and time readings while having correct (!!!) message checksums. <br />
* The log on the ship was defective and delivered no readings from time to time. <br />
* The same holds true for the water temperature.<br />
* The GPS positions relatively imprecise because some last decimal digits are missing in the recordings.<br />
* The GPS positions are updated every 10 seconds while other sensor readings update almost every second.<br />
* The GPS position are sometimes way off due to false readings<br />
<br />
The Baltic Sea data set is a little bit better<br />
* Only a single day is available<br />
* GPS positions are updated every second<br />
<br />
One problem with the data is that there is time available when sensor readings were recorded. This yields problems to the filter algorithm.<br />
<br />
<br />
=== Filter Algorithm ===<br />
At first the Extended Kalman Filter is being analyzed. Using an apache implementation with the available data the filter quickly throw an exception that<br />
a matrix is not invertible because of numeric instabilities. When removing this exception the filter seems to work but the removal and its effects have yet to be analyzed.<br />
Literature suggest that a fixed interval smoother may yield better results in case of offline data processing. As it is an extension to the existing kalman filter<br />
we may consider that for the future.<br />
<br />
One problem are the different update rates of the sensors. As GPS may deliver positions at 0.1Hz speed is updated at 1Hz. Literature suggests that<br />
the missing measurements shell be modelled as a random variable with the standard deviation of the sensor. It may even be possible to update covariance matrices only partially with the sensor readings received. Input for the best solution may be formulated on the developer mailing list.<br />
<br />
== Results == <br />
A prototype implementation is shown in the following screenshots. An Extended Kalman Filter is being used. It has the position<br />
and the current bearing and velocity as system state. The input is the measurement of these four observables. The system function is<br />
good old pythagoras. In a first implementation I tried to use orthodrome distances but the system function is not differentiable which is a requirement of the Extended Kalman Filter (due to acrtan2). For small distances pythagoras should be sufficiently accurate. <br />
The initial state is taken from the first measurement for convergence reasons.<br />
<br />
The following gallery shows the results. <br />
* You can see the bad position resolution and an outlier in the first screenshot.<br />
* The second shows the same data overlaid with the applied filter. The outlier is gone and the resolution has improved.<br />
* The third screenshot shows data from a different GPS sensor with more precision (not DGPS) versus the filtered data.<br />
<br />
This of course is just a preliminary test and many setups need to be considered to make it work for most datasets.<br />
<br />
<gallery><br />
UnfilteredNMEA.png | Unfiltered GPS data<br />
FilteredNMEAVsOriginal.png | Unfiltered GPS data and Filtered GPS data<br />
PreciseGPSvsFilter.png | Another precise GPS vs Filtered GPS data<br />
</gallery><br />
<br />
The overall process even gives an estimation of the current error which is a capability of the [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter].<br />
This way positional inaccuracies may be added to the overall depth measurement inaccuracy.<br />
<br />
== Quality rating ==<br />
<br />
Each record (time, positon, depth) should become a quality rating.<br />
<br />
=== Points ===<br />
<br />
Derived from the Fibonacci series.<br />
<br />
{| class="wikitable"<br />
! Point || Description<br />
|-<br />
| 1 || extra small improvement<br />
|-<br />
| 2 || small improvement<br />
|-<br />
| 3 || medium improvement<br />
|-<br />
| 5 || large improvement<br />
|-<br />
| 8 || extra large improvement<br />
|}<br />
<br />
=== Factors ===<br />
<br />
{| class="wikitable"<br />
! style="width:15%" | Name<br />
! style="width:17%" | Factor<br />
! style="width:68%" | Description<br />
|-<br />
| depth offset || 8 (extra large) || The difference between the depth measured by the echo sounder and the depth (waterline) measured by hand.<br />
|-<br />
| device distance || 3 (medium) || The distance between gps antenna and echo sounder (lengthwise and crosswise).<br />
|-<br />
| SBAS || 3 (medium) || Satellite based augmentation system (WAAS, EGNOS, MSAS) which allows to correct the gps position.<br />
|-<br />
| position interpolation || 2 (small improvement) || Arrival of depth and position packets can have a time difference. It is/should be possible to interpolate the position.<br />
|}<br />
<br />
= Depth Rendering =<br />
<br />
= Siehe auch =<br />
* [[De:Bordnetz|Bordnetz]]<br />
* [[De:NMEA-Logger_anschliessen|NMEA-Logger_anschliessen]]<br />
* [http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCkQFjAA&url=http%3A%2F%2Fwww.dei.unipd.it%2F~chiuso%2FDOWNLOAD%2FPositioning_Heading_Kalman.pdf&ei=sSWNUMWnL4eC4gTRlYHAAw&usg=AFQjCNHq5V-PePNmDTZaGYvq0JeQFgqHVw Kalman Filtering for Positioning and Heading Control of Ships and Offshore Rigs]<br />
* [http://users.isr.ist.utl.pt/~pedro/publications/CAMS10.pdf A Multiple Model Adaptive Wave Filter for Dynamic Ship Positioning]<br />
* [http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4449205&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4449205 Echosounder Depth Tracking with the Extended Kalman Filter]</div>MartinOverhttps://wiki.openseamap.org/index.php?title=Datei:Bsh_2_outliers.jpg&diff=2972Datei:Bsh 2 outliers.jpg2014-09-30T19:47:55Z<p>MartinOver: </p>
<hr />
<div></div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:En:Depth_Data&diff=2971OpenSeaMap-dev:En:Depth Data2014-09-30T19:46:42Z<p>MartinOver: /* Baltic Sea Olpenitz (Germany) */</p>
<hr />
<div>This Page describes the necessary efforts to retrieve and analyze depth data as well as create renderings from it<br />
<br />
= Data Aquisition =<br />
Depth data can be retrieved from public domain sources or from crowd sourced data.<br />
<br />
== GEBCO ==<br />
DIe Daten sind gerendert und stehen als Layer zur Verfügung:<br />
{| class="wikitable"<br />
! Zoom || Inhalt<br />
|-<br />
| 0..10 || Blaustufen und Schattierung<br />
|-<br />
| 11..18 || beschriftete Tiefenlinien, Blaustufen und Schattierung<br />
|}<br />
<br />
Noch zu lösende Probleme:<br />
* der GEBCO-Layer erzeugt einen milchigen Schleier über der Basiskarte<br />
* Tiefenlinien sind ab z=14 etwas grob (also ab da, wo dann die Flachwassertiefen beginnen) [http://map.openseamap.org/?zoom=14&lat=36.03097&lon=-5.49153&layers=BFTFTTTFFFF0 Karte]<br />
* Überschneidungen von 100m-Linie und Küstenlinie [http://map.openseamap.org/?zoom=15&lat=36.00318&lon=-5.60819&layers=BFFFTTTFFFF0FFFFF Karte]<br />
* Steilküsten (Cuba) [http://map.openseamap.org/?zoom=14&lat=19.94808&lon=-76.04289&layers=BFTFTTTFFFF0 Karte]<br />
<br />
== Crowd Sourced Data ==<br />
Crowd sourced data may be gathered by YOU. There are two options in development. A hardware and a software option.<br />
<br />
=== Workflow ===<br />
[[Datei:Workflow_depth.png]]<br />
<br />
Here you can find the document with the previous thoughts about the workflow:<br />
[http://osm.franken.de/wiki/FWT-Projekt%C3%BCbersicht-NMEA2Contours_2.1.ppt PPT Dokument]<br />
<br />
=== Hardware logger ===<br />
We are currently developing a hardware logger that may easily be plugged to the ship's network in order to log the networks data to a SD card.<br />
That data may then be uploaded by plugging the SD card to a normal computer with internet connection for upload.<br />
The main goal is to support NMEA 0183 data with options for NMEA 2000.<br />
<br />
=== Software logger ===<br />
A [[Software logger]] is in development and [http://seesea.sourceforge.net/datalogger/index.html can be downloaded here]. <br />
<br />
It currently supports: <br />
: Bluetooth <br />
: Serial ports<br />
: Internet Protocol (IP)<br />
It processes NMEA 0183 and AIS data.<br />
<br />
For vendor specific protocols such as SeaTalk 1 you have to use a [[De:NMEA-Logger_anschliessen|converter]] to NMEA 0183 data.<br />
<br />
NMEA 2000 support is only available if data is transcoded to NMEA 0183 by a converter.<br />
<br />
=== Chart Plotters ===<br />
<br />
Some chart plotters are able to save tracks out-of-the-box, e.g. several Raymarine (FSH files) and Humminbird (SON files) devices. Those files may directly be used as data source.<br />
<br />
<br />
=== Upload Process ===<br />
Uploading data is possible through using the [http://seesea.sourceforge.net/datalogger/index.html OpenSeaMap Data Logger Software] or via [http://depth.openseamap.org/ Web Interface].<br />
The system is currently being tested. <br />
<br />
[[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|You'll find further information here]].<br />
<br />
=== Test Data ===<br />
<br />
<br />
==== Brombachsee (Germany)====<br />
<br />
Test data for Openseamap: [http://osm.franken.de/wiki/test_data_brombachsee.zip Brombachsee_Test_Data]<br />
<br />
dgm_brombachsee.tif: Digital Elevation Model of the sea derived from height lines WWA (C).<br />
<br />
shapes_brombachsee.shp: Shape File derived from 4 NMEA Tracks. "dbs" is the original Sounding and "deep_cor" the depth after a correction (gauge levl).<br />
<br />
gpx_brombachsee.gpx: ele = "dbs" from the Shape File<br />
<br />
[[Datei:Brombachsee.png]]<br />
Resulting Digital Elevation Model<br />
<br />
==== Baltic Sea - near Großenbrode (Germany)====<br />
<br />
First results with an RMS error < 1,5 meter compared to an official dataset of the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].<br />
<br />
[[Datei: Bsh_results_overview.jpg]]<br />
<br />
[Picture 1] '''''OSM map in background, raster Depth Model derived from BSH data and crowed sourced OpenSeaMap Points - Overview'''''<br />
<br />
Blue = flat BSH data, red = deep BSH data.<br />
<br>Blue points = OpenSeaMap raw measuring points.<br />
<br />
{| class="wikitable"<br />
|-<br />
| n || 5062<br />
|-<br />
|-<br />
| datasets || 21<br />
|-<br />
| max deviation || 3,43 meters<br />
|-<br />
| mean (abs) || 0,69 meters<br />
|-<br />
| RMS +/- || 0,91 meters<br />
|}<br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| VesselConfig ID || 68<br />
|-<br />
| Manufacturer || Bavaria Yachtbau<br />
|-<br />
| Model || B32<br />
|-<br />
| Length || 10,0 meters<br />
|-<br />
| Beam || 3,35 meters<br />
|-<br />
| Draft || 1,6 meters<br />
|-<br />
| Height || 14 meters<br />
|-<br />
| Displacement || 4,2 t<br />
|-<br />
| Sensor manufacturer || Raymarine<br />
|-<br />
| Sensor Offset to waterline || 0,45 meters<br />
|-<br />
| Sensor Offset to keel || 1,15 meters<br />
|}<br />
<br />
<br />
<br />
A digital Deep Model raster was computed from the BSH point dataset (c).<br />
The depth of the crowed sourced dataset was compared to the derived raster dataset from the BSH.<br />
The raw crowed sourced dataset was corrected by the sensor offset (0,45 meters).<br />
<br />
[[Datei: Scatter_cor_sensor.jpeg]]<br />
<br />
[Picture 2] '''''Scatter plot: BSH data on the x-axis and the crowed sourced data on the y-axis. Trend line in black and optimal line in red.'''''<br />
<br />
The deviation from the reference dataset increases with the depth measured.<br />
<br />
As you see in the picture below the difference between the datasets has an regular pattern maybe deepending on waves.<br />
<br />
[[Datei: Bsh_results_detail_10_classes.jpg]]<br />
<br />
[Picture 3] '''''Crowed sourced OpenSeaMap track points and the difference from the BSH dataset'''''<br />
<br />
White = low difference, orange = medium difference, red = strong difference<br />
<br />
Download of the data http://osm.franken.de/data/baltic_sea_test_data.zip<br />
'''Be aware of the copyright from the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].'''<br />
The data in the dataset is not corrected by sensor offset.<br />
<br />
==== Baltic Sea Olpenitz (Germany)====<br />
<br />
In this test area we have tracks from two different vessel configurations. <br />
The fist one was the one from the test area Großenbrode (config ID 68).<br />
<br />
In the Table below the settings for die vesselconfigid 110 are shown: <br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| VesselConfigId || 110<br />
|-<br />
| Manufacturer || Waarschip<br />
|-<br />
| Model || 570<br />
|-<br />
| Length || 5,7 meters<br />
|-<br />
| Beam || 2,45 meters<br />
|-<br />
| Draft || 1,0 meters<br />
|-<br />
| Height || 9.1 meters<br />
|-<br />
| Displacement || 0,8 t<br />
|-<br />
| Sensor manufacturer || Tacktick/ Airmar<br />
|-<br />
| Sensor Model || T912<br />
|-<br />
| Sensor Offset to waterline || 0,2 meters<br />
|-<br />
| Sensor Offset to keel || 0,45 meters<br />
|}<br />
<br />
[[Datei: Balitc_sea_scatter_plot_2.jpeg]]<br />
<br />
[Picture 1] Scatterplot for vesselconfigID 110. Trendline in Black and optimal line in red (after correction of the sensor offset to waterline).<br />
<br />
{| class="wikitable"<br />
|-<br />
| vsselConfigId || 110<br />
|-<br />
| n || 247<br />
|-<br />
| mean || 0,49 meters<br />
|-<br />
| rms || 0,62 meters<br />
|-<br />
| max|| 2,53 meters<br />
|}<br />
<br />
The distribution is quite different from the data recorded in the test area Großenbrode with an different sensor.<br />
<br />
Fortunately we have also data from the VesselConfigId 68 in this test area to compare the measurements.<br />
<br />
[[Datei: Balitc_sea_scatter_plot_2_68_all.jpeg]]<br />
<br />
[Picture 2] Scatterplot for vesselconfigID 68 after correction of the sensor offset to waterline.<br />
<br />
Obviously there are some outliers which are<br />
<br />
=== Meta Data Statistics ===<br />
<br />
Statistics for the metadata entrees with some personal comments (by MartinOver). Stand 20.9.2014.<br />
<br />
{| class="prettytable"<br />
|-<br />
|<br />
'''Step'''<br />
<br />
|<br />
'''Topic'''<br />
<br />
|<br />
'''Count'''<br />
<br />
|<br />
'''State'''<br />
<br />
|<br />
'''Comment'''<br />
<br />
|-<br />
|<br />
1/1<br />
<br />
|<br />
Name<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
1/2<br />
<br />
|<br />
Description<br />
<br />
|<br />
76/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/1<br />
<br />
|<br />
Length<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
Some wrong entrees like mail addresses or comments <br />
<br />
24 “0.00” Values<br />
<br />
|-<br />
|<br />
2/2<br />
<br />
|<br />
Beam<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
37 „0.00“ Values<br />
<br />
|-<br />
|<br />
2/3<br />
<br />
|<br />
Draft<br />
<br />
|<br />
79/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/4<br />
<br />
|<br />
Displacement<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/5<br />
<br />
|<br />
Height<br />
<br />
|<br />
78/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/6<br />
<br />
|<br />
Manufacturer<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Model<br />
<br />
|<br />
49/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Type<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/3<br />
<br />
|<br />
Position below Waterline<br />
<br />
|<br />
57/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Should be Obligatory<br />
<br />
|-<br />
|<br />
3/4<br />
<br />
|<br />
Depth Measurement<br />
<br />
|<br />
?<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Where in DB?<br />
<br />
|-<br />
|<br />
3/5<br />
<br />
|<br />
Sensor Offset to Keel<br />
<br />
|<br />
6/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/6<br />
<br />
|<br />
Producer of Depth Sensor<br />
<br />
|<br />
63/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/7<br />
<br />
|<br />
Device Model<br />
<br />
|<br />
40/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
58 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
51 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/3<br />
<br />
|<br />
Position abbove Waterline<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/4<br />
<br />
|<br />
Producer<br />
<br />
|<br />
77/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/5<br />
<br />
|<br />
Model<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|}<br />
<br />
= Data Preprocessing =<br />
<br />
== Data Condition ==<br />
Raw data is usually erronous and must be corrected<br />
<br />
=== Internal data problems ===<br />
Depth data may be affected by electrical conditions and software implementations<br />
* Data is incomplete and fail their checksum (bus errors from physical transmissions errors)<br />
* Data is retrived out of sequence<br />
* Data is erronous sensor data <br />
** Approximate correctable data i.e. invalid GPS position that may be interpolated<br />
** Uncorrectable data i.e. failed log sensor that shows slow speeds<br />
* Data resolution is low i.e. for energy saving purposes GPS position is updated every 10 seconds instead of every second<br />
* Sensor data is actively miscalibrated i.e. charter companies add additional draft to the sensor depth for safety reasons<br />
<br />
=== External data problems ===<br />
Depth data may be affected by different environmental circumstances <br />
*# The water temperature affects the ultrasound echo. An inhomogen water temperature yields unwanted echos<br />
*# The seabed affects the ultrasound echo<br />
*# The seastate affects the measurement. There even may be waves when there is no wind.<br />
*# Waves may affect the roll of the measuring vessel resulting in steep measurements that are invalid.<br />
*# The sounder sensor is not the position of the GPS antenna. A position offset including heading must be incorporated.<br />
*# The time of the measurement need not correlate with the time the position was received. This may even happen due to processing time of the hard or software.<br />
*# Corrections for tide induced water levels must happen<br />
<br />
Solutions probably are<br />
*# Water temperature may be measure from the sensor, other data may be unavailable<br />
*# Modern sidescan sonar may yield information about the seabed through classifications<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# Position offsets must be provided by the user<br />
*# Time outages may be handled by the filter if precise timestamps are available in recorded data<br />
*# LAT to Mean sea level differences may be calculated from DTU10 worldwide, river gauges need to monitored<br />
<br />
[[Datei:LAT2MSLDiff.png]]<br />
<br />
<br />
== Data Condition Examples / Showcases ==<br />
<br />
=== Missing measurments (Position) ===<br />
Distribution for position updates taken from an example dataset. Left column shows the time between two consecutive measurements, right column shows how many measurements had this time update.<br />
One can see from the distribtion that the sensor is updated every second but many measurements are one or more seconds late.<br />
21 seconds with no position update may result in an instability of the subsequent filter.<br />
<pre><br />
MeasuredPosition3D<br />
GP<br />
0 :4285<br />
1000 :11295<br />
2000 :5056<br />
3000 :2134<br />
4000 :1135<br />
5000 :315<br />
6000 :154<br />
7000 :46<br />
8000 :36<br />
9000 :16<br />
10000 :12<br />
11000 :3<br />
12000 :4<br />
13000 :1<br />
14000 :7<br />
15000 :3<br />
16000 :1<br />
21000 :1<br />
</pre><br />
<br />
=== Missing measurments (Position) with erronous clock ===<br />
This example is at a 10 second position update rate. However the measurment time is faulty causing large negative and positive update rates. The clock jumps by +- one year/month/day/hour. One can further see from the many 0 time measurements that the rate at which data is sent to the nmea bus is higher than the actual position update (data is sent every second, a position update is every 10 seconds)<br />
<pre><br />
MeasuredPosition3D<br />
II<br />
-21340000 :1<br />
-13194000 :1<br />
-7998000 :1<br />
-2674000 :1<br />
-2434000 :1<br />
-2402000 :1<br />
-2030000 :1<br />
-1926000 :1<br />
-1894000 :1<br />
-1806000 :1<br />
-1480000 :1<br />
-1430000 :1<br />
-1382000 :1<br />
-1114000 :1<br />
-814000 :1<br />
-634000 :1<br />
-590000 :1<br />
-546000 :1<br />
-470000 :1<br />
-290000 :1<br />
-230000 :1<br />
-198000 :1<br />
-110000 :1<br />
-94000 :2<br />
0 :182200<br />
5000 :1<br />
10000 :20230<br />
15000 :1<br />
20000 :84<br />
50000 :1<br />
114000 :2<br />
130000 :2<br />
218000 :1<br />
250000 :1<br />
310000 :1<br />
490000 :1<br />
566000 :1<br />
610000 :1<br />
654000 :1<br />
834000 :1<br />
1134000 :1<br />
1402000 :1<br />
1450000 :1</pre><br />
<br />
== Solution Proposal ==<br />
<br />
=== Outline ===<br />
The ship is influenced by the outlined environment which can be observed. Naturally what is observed is not the state of the<br />
ship as i.e. the position if taken from GPS is 95% less than 10m accurate. To improve quality an estimation of the true state yields better results if this noise taken into account properly.<br />
<br />
=== Details ===<br />
The ship moves according to physical laws. For the easist case imagine a ship with constant velocity and direction. For any point in time you can tell where the ship is with easy math. Considering the full blown setup a ships movement is affected by many parameters such as wind speed, water current, waves, tide, and many more. The ship moves also triaxial in a dynamic way in itself (roll, pitch, yaw). Heeling even changes the measurement position with respect to the depth position. In terms of a filter this is called a system model that describes how the state of the ship may change. Given such a state you can measure what your sensor readings are and compare that to where the system thinks you are.<br />
<br />
The [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter] is known to be the best linear estimator for such situations. Unfortunately the system model is not linear which is why the Extended Kalman Filter needs to be used in order to linearize the system at hand.<br />
<br />
Todo:<br />
* Construct ship system model with at least the position state and probably its course and speed or even more (depth)<br />
* Estimate the system variance (This is a hard one, proposals welcome)<br />
* Construct the measurement model according to the data available (GPS, Log)<br />
* Estimate the measurement noise according to specifc sensors (DPGS is more accurate than GPS)<br />
<br />
The estimation with the position and depth can be retrieved and stored in a database.<br />
<br />
Pitfalls:<br />
* If the system noise is badly chosen the estimation of the system state does not converge to the true state / measurement.<br />
* If the system is very detailed the system variance can be reduced. The required cpu time for processing increases<br />
<br />
Benefits:<br />
* Having the best estimation of the true position even if measurements are noisy<br />
* Easy and effective algorithmic processing<br />
<br />
== Analysis == <br />
<br />
=== Data Sets ===<br />
Currently two test data sets are available recorded during trips from Mallorca and the Baltic Sea.<br />
In terms of data quality the Mallorca data shows many challenges. <br />
* The minimum recommended sentences from NMEA showed up with false date and time readings while having correct (!!!) message checksums. <br />
* The log on the ship was defective and delivered no readings from time to time. <br />
* The same holds true for the water temperature.<br />
* The GPS positions relatively imprecise because some last decimal digits are missing in the recordings.<br />
* The GPS positions are updated every 10 seconds while other sensor readings update almost every second.<br />
* The GPS position are sometimes way off due to false readings<br />
<br />
The Baltic Sea data set is a little bit better<br />
* Only a single day is available<br />
* GPS positions are updated every second<br />
<br />
One problem with the data is that there is time available when sensor readings were recorded. This yields problems to the filter algorithm.<br />
<br />
<br />
=== Filter Algorithm ===<br />
At first the Extended Kalman Filter is being analyzed. Using an apache implementation with the available data the filter quickly throw an exception that<br />
a matrix is not invertible because of numeric instabilities. When removing this exception the filter seems to work but the removal and its effects have yet to be analyzed.<br />
Literature suggest that a fixed interval smoother may yield better results in case of offline data processing. As it is an extension to the existing kalman filter<br />
we may consider that for the future.<br />
<br />
One problem are the different update rates of the sensors. As GPS may deliver positions at 0.1Hz speed is updated at 1Hz. Literature suggests that<br />
the missing measurements shell be modelled as a random variable with the standard deviation of the sensor. It may even be possible to update covariance matrices only partially with the sensor readings received. Input for the best solution may be formulated on the developer mailing list.<br />
<br />
== Results == <br />
A prototype implementation is shown in the following screenshots. An Extended Kalman Filter is being used. It has the position<br />
and the current bearing and velocity as system state. The input is the measurement of these four observables. The system function is<br />
good old pythagoras. In a first implementation I tried to use orthodrome distances but the system function is not differentiable which is a requirement of the Extended Kalman Filter (due to acrtan2). For small distances pythagoras should be sufficiently accurate. <br />
The initial state is taken from the first measurement for convergence reasons.<br />
<br />
The following gallery shows the results. <br />
* You can see the bad position resolution and an outlier in the first screenshot.<br />
* The second shows the same data overlaid with the applied filter. The outlier is gone and the resolution has improved.<br />
* The third screenshot shows data from a different GPS sensor with more precision (not DGPS) versus the filtered data.<br />
<br />
This of course is just a preliminary test and many setups need to be considered to make it work for most datasets.<br />
<br />
<gallery><br />
UnfilteredNMEA.png | Unfiltered GPS data<br />
FilteredNMEAVsOriginal.png | Unfiltered GPS data and Filtered GPS data<br />
PreciseGPSvsFilter.png | Another precise GPS vs Filtered GPS data<br />
</gallery><br />
<br />
The overall process even gives an estimation of the current error which is a capability of the [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter].<br />
This way positional inaccuracies may be added to the overall depth measurement inaccuracy.<br />
<br />
== Quality rating ==<br />
<br />
Each record (time, positon, depth) should become a quality rating.<br />
<br />
=== Points ===<br />
<br />
Derived from the Fibonacci series.<br />
<br />
{| class="wikitable"<br />
! Point || Description<br />
|-<br />
| 1 || extra small improvement<br />
|-<br />
| 2 || small improvement<br />
|-<br />
| 3 || medium improvement<br />
|-<br />
| 5 || large improvement<br />
|-<br />
| 8 || extra large improvement<br />
|}<br />
<br />
=== Factors ===<br />
<br />
{| class="wikitable"<br />
! style="width:15%" | Name<br />
! style="width:17%" | Factor<br />
! style="width:68%" | Description<br />
|-<br />
| depth offset || 8 (extra large) || The difference between the depth measured by the echo sounder and the depth (waterline) measured by hand.<br />
|-<br />
| device distance || 3 (medium) || The distance between gps antenna and echo sounder (lengthwise and crosswise).<br />
|-<br />
| SBAS || 3 (medium) || Satellite based augmentation system (WAAS, EGNOS, MSAS) which allows to correct the gps position.<br />
|-<br />
| position interpolation || 2 (small improvement) || Arrival of depth and position packets can have a time difference. It is/should be possible to interpolate the position.<br />
|}<br />
<br />
= Depth Rendering =<br />
<br />
= Siehe auch =<br />
* [[De:Bordnetz|Bordnetz]]<br />
* [[De:NMEA-Logger_anschliessen|NMEA-Logger_anschliessen]]<br />
* [http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCkQFjAA&url=http%3A%2F%2Fwww.dei.unipd.it%2F~chiuso%2FDOWNLOAD%2FPositioning_Heading_Kalman.pdf&ei=sSWNUMWnL4eC4gTRlYHAAw&usg=AFQjCNHq5V-PePNmDTZaGYvq0JeQFgqHVw Kalman Filtering for Positioning and Heading Control of Ships and Offshore Rigs]<br />
* [http://users.isr.ist.utl.pt/~pedro/publications/CAMS10.pdf A Multiple Model Adaptive Wave Filter for Dynamic Ship Positioning]<br />
* [http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4449205&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4449205 Echosounder Depth Tracking with the Extended Kalman Filter]</div>MartinOverhttps://wiki.openseamap.org/index.php?title=Datei:Balitc_sea_scatter_plot_2_68_without.jpeg&diff=2970Datei:Balitc sea scatter plot 2 68 without.jpeg2014-09-30T19:39:27Z<p>MartinOver: </p>
<hr />
<div></div>MartinOverhttps://wiki.openseamap.org/index.php?title=Datei:Balitc_sea_scatter_plot_2_68_all.jpeg&diff=2969Datei:Balitc sea scatter plot 2 68 all.jpeg2014-09-30T19:38:59Z<p>MartinOver: </p>
<hr />
<div></div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:En:Depth_Data&diff=2968OpenSeaMap-dev:En:Depth Data2014-09-30T19:07:56Z<p>MartinOver: /* Baltic Sea Olpenitz (Germany) */</p>
<hr />
<div>This Page describes the necessary efforts to retrieve and analyze depth data as well as create renderings from it<br />
<br />
= Data Aquisition =<br />
Depth data can be retrieved from public domain sources or from crowd sourced data.<br />
<br />
== GEBCO ==<br />
DIe Daten sind gerendert und stehen als Layer zur Verfügung:<br />
{| class="wikitable"<br />
! Zoom || Inhalt<br />
|-<br />
| 0..10 || Blaustufen und Schattierung<br />
|-<br />
| 11..18 || beschriftete Tiefenlinien, Blaustufen und Schattierung<br />
|}<br />
<br />
Noch zu lösende Probleme:<br />
* der GEBCO-Layer erzeugt einen milchigen Schleier über der Basiskarte<br />
* Tiefenlinien sind ab z=14 etwas grob (also ab da, wo dann die Flachwassertiefen beginnen) [http://map.openseamap.org/?zoom=14&lat=36.03097&lon=-5.49153&layers=BFTFTTTFFFF0 Karte]<br />
* Überschneidungen von 100m-Linie und Küstenlinie [http://map.openseamap.org/?zoom=15&lat=36.00318&lon=-5.60819&layers=BFFFTTTFFFF0FFFFF Karte]<br />
* Steilküsten (Cuba) [http://map.openseamap.org/?zoom=14&lat=19.94808&lon=-76.04289&layers=BFTFTTTFFFF0 Karte]<br />
<br />
== Crowd Sourced Data ==<br />
Crowd sourced data may be gathered by YOU. There are two options in development. A hardware and a software option.<br />
<br />
=== Workflow ===<br />
[[Datei:Workflow_depth.png]]<br />
<br />
Here you can find the document with the previous thoughts about the workflow:<br />
[http://osm.franken.de/wiki/FWT-Projekt%C3%BCbersicht-NMEA2Contours_2.1.ppt PPT Dokument]<br />
<br />
=== Hardware logger ===<br />
We are currently developing a hardware logger that may easily be plugged to the ship's network in order to log the networks data to a SD card.<br />
That data may then be uploaded by plugging the SD card to a normal computer with internet connection for upload.<br />
The main goal is to support NMEA 0183 data with options for NMEA 2000.<br />
<br />
=== Software logger ===<br />
A [[Software logger]] is in development and [http://seesea.sourceforge.net/datalogger/index.html can be downloaded here]. <br />
<br />
It currently supports: <br />
: Bluetooth <br />
: Serial ports<br />
: Internet Protocol (IP)<br />
It processes NMEA 0183 and AIS data.<br />
<br />
For vendor specific protocols such as SeaTalk 1 you have to use a [[De:NMEA-Logger_anschliessen|converter]] to NMEA 0183 data.<br />
<br />
NMEA 2000 support is only available if data is transcoded to NMEA 0183 by a converter.<br />
<br />
=== Chart Plotters ===<br />
<br />
Some chart plotters are able to save tracks out-of-the-box, e.g. several Raymarine (FSH files) and Humminbird (SON files) devices. Those files may directly be used as data source.<br />
<br />
<br />
=== Upload Process ===<br />
Uploading data is possible through using the [http://seesea.sourceforge.net/datalogger/index.html OpenSeaMap Data Logger Software] or via [http://depth.openseamap.org/ Web Interface].<br />
The system is currently being tested. <br />
<br />
[[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|You'll find further information here]].<br />
<br />
=== Test Data ===<br />
<br />
<br />
==== Brombachsee (Germany)====<br />
<br />
Test data for Openseamap: [http://osm.franken.de/wiki/test_data_brombachsee.zip Brombachsee_Test_Data]<br />
<br />
dgm_brombachsee.tif: Digital Elevation Model of the sea derived from height lines WWA (C).<br />
<br />
shapes_brombachsee.shp: Shape File derived from 4 NMEA Tracks. "dbs" is the original Sounding and "deep_cor" the depth after a correction (gauge levl).<br />
<br />
gpx_brombachsee.gpx: ele = "dbs" from the Shape File<br />
<br />
[[Datei:Brombachsee.png]]<br />
Resulting Digital Elevation Model<br />
<br />
==== Baltic Sea - near Großenbrode (Germany)====<br />
<br />
First results with an RMS error < 1,5 meter compared to an official dataset of the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].<br />
<br />
[[Datei: Bsh_results_overview.jpg]]<br />
<br />
[Picture 1] '''''OSM map in background, raster Depth Model derived from BSH data and crowed sourced OpenSeaMap Points - Overview'''''<br />
<br />
Blue = flat BSH data, red = deep BSH data.<br />
<br>Blue points = OpenSeaMap raw measuring points.<br />
<br />
{| class="wikitable"<br />
|-<br />
| n || 5062<br />
|-<br />
|-<br />
| datasets || 21<br />
|-<br />
| max deviation || 3,43 meters<br />
|-<br />
| mean (abs) || 0,69 meters<br />
|-<br />
| RMS +/- || 0,91 meters<br />
|}<br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| VesselConfig ID || 68<br />
|-<br />
| Manufacturer || Bavaria Yachtbau<br />
|-<br />
| Model || B32<br />
|-<br />
| Length || 10,0 meters<br />
|-<br />
| Beam || 3,35 meters<br />
|-<br />
| Draft || 1,6 meters<br />
|-<br />
| Height || 14 meters<br />
|-<br />
| Displacement || 4,2 t<br />
|-<br />
| Sensor manufacturer || Raymarine<br />
|-<br />
| Sensor Offset to waterline || 0,45 meters<br />
|-<br />
| Sensor Offset to keel || 1,15 meters<br />
|}<br />
<br />
<br />
<br />
A digital Deep Model raster was computed from the BSH point dataset (c).<br />
The depth of the crowed sourced dataset was compared to the derived raster dataset from the BSH.<br />
The raw crowed sourced dataset was corrected by the sensor offset (0,45 meters).<br />
<br />
[[Datei: Scatter_cor_sensor.jpeg]]<br />
<br />
[Picture 2] '''''Scatter plot: BSH data on the x-axis and the crowed sourced data on the y-axis. Trend line in black and optimal line in red.'''''<br />
<br />
The deviation from the reference dataset increases with the depth measured.<br />
<br />
As you see in the picture below the difference between the datasets has an regular pattern maybe deepending on waves.<br />
<br />
[[Datei: Bsh_results_detail_10_classes.jpg]]<br />
<br />
[Picture 3] '''''Crowed sourced OpenSeaMap track points and the difference from the BSH dataset'''''<br />
<br />
White = low difference, orange = medium difference, red = strong difference<br />
<br />
Download of the data http://osm.franken.de/data/baltic_sea_test_data.zip<br />
'''Be aware of the copyright from the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].'''<br />
The data in the dataset is not corrected by sensor offset.<br />
<br />
==== Baltic Sea Olpenitz (Germany)====<br />
<br />
In this test area we have tracks from two different vessel configurations. <br />
The fist one was the one from the test area Großenbrode (config ID 68).<br />
<br />
In the Table below the settings for die vesselconfigid 110 are shown: <br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| VesselConfigId || 110<br />
|-<br />
| Manufacturer || Waarschip<br />
|-<br />
| Model || 570<br />
|-<br />
| Length || 5,7 meters<br />
|-<br />
| Beam || 2,45 meters<br />
|-<br />
| Draft || 1,0 meters<br />
|-<br />
| Height || 9.1 meters<br />
|-<br />
| Displacement || 0,8 t<br />
|-<br />
| Sensor manufacturer || Tacktick/ Airmar<br />
|-<br />
| Sensor Model || T912<br />
|-<br />
| Sensor Offset to waterline || 0,2 meters<br />
|-<br />
| Sensor Offset to keel || 0,45 meters<br />
|}<br />
<br />
[[Datei: Balitc_sea_scatter_plot_2.jpeg]]<br />
<br />
[Picture 1] Scatterplot for vesselconfigID 110. Trendline in Black and optimal line in red (after correction of the sensor offset to waterline).<br />
<br />
{| class="wikitable"<br />
|-<br />
| vsselConfigId || 110<br />
|-<br />
| n || 247<br />
|-<br />
| mean || 0,49 meters<br />
|-<br />
| rms || 0,62 meters<br />
|-<br />
| max|| 2,53 meters<br />
|}<br />
<br />
The distribution is quite different from the data recorded in the test area Großenbrode with an different sensor.<br />
<br />
Fortunately<br />
<br />
=== Meta Data Statistics ===<br />
<br />
Statistics for the metadata entrees with some personal comments (by MartinOver). Stand 20.9.2014.<br />
<br />
{| class="prettytable"<br />
|-<br />
|<br />
'''Step'''<br />
<br />
|<br />
'''Topic'''<br />
<br />
|<br />
'''Count'''<br />
<br />
|<br />
'''State'''<br />
<br />
|<br />
'''Comment'''<br />
<br />
|-<br />
|<br />
1/1<br />
<br />
|<br />
Name<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
1/2<br />
<br />
|<br />
Description<br />
<br />
|<br />
76/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/1<br />
<br />
|<br />
Length<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
Some wrong entrees like mail addresses or comments <br />
<br />
24 “0.00” Values<br />
<br />
|-<br />
|<br />
2/2<br />
<br />
|<br />
Beam<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
37 „0.00“ Values<br />
<br />
|-<br />
|<br />
2/3<br />
<br />
|<br />
Draft<br />
<br />
|<br />
79/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/4<br />
<br />
|<br />
Displacement<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/5<br />
<br />
|<br />
Height<br />
<br />
|<br />
78/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/6<br />
<br />
|<br />
Manufacturer<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Model<br />
<br />
|<br />
49/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Type<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/3<br />
<br />
|<br />
Position below Waterline<br />
<br />
|<br />
57/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Should be Obligatory<br />
<br />
|-<br />
|<br />
3/4<br />
<br />
|<br />
Depth Measurement<br />
<br />
|<br />
?<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Where in DB?<br />
<br />
|-<br />
|<br />
3/5<br />
<br />
|<br />
Sensor Offset to Keel<br />
<br />
|<br />
6/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/6<br />
<br />
|<br />
Producer of Depth Sensor<br />
<br />
|<br />
63/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/7<br />
<br />
|<br />
Device Model<br />
<br />
|<br />
40/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
58 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
51 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/3<br />
<br />
|<br />
Position abbove Waterline<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/4<br />
<br />
|<br />
Producer<br />
<br />
|<br />
77/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/5<br />
<br />
|<br />
Model<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|}<br />
<br />
= Data Preprocessing =<br />
<br />
== Data Condition ==<br />
Raw data is usually erronous and must be corrected<br />
<br />
=== Internal data problems ===<br />
Depth data may be affected by electrical conditions and software implementations<br />
* Data is incomplete and fail their checksum (bus errors from physical transmissions errors)<br />
* Data is retrived out of sequence<br />
* Data is erronous sensor data <br />
** Approximate correctable data i.e. invalid GPS position that may be interpolated<br />
** Uncorrectable data i.e. failed log sensor that shows slow speeds<br />
* Data resolution is low i.e. for energy saving purposes GPS position is updated every 10 seconds instead of every second<br />
* Sensor data is actively miscalibrated i.e. charter companies add additional draft to the sensor depth for safety reasons<br />
<br />
=== External data problems ===<br />
Depth data may be affected by different environmental circumstances <br />
*# The water temperature affects the ultrasound echo. An inhomogen water temperature yields unwanted echos<br />
*# The seabed affects the ultrasound echo<br />
*# The seastate affects the measurement. There even may be waves when there is no wind.<br />
*# Waves may affect the roll of the measuring vessel resulting in steep measurements that are invalid.<br />
*# The sounder sensor is not the position of the GPS antenna. A position offset including heading must be incorporated.<br />
*# The time of the measurement need not correlate with the time the position was received. This may even happen due to processing time of the hard or software.<br />
*# Corrections for tide induced water levels must happen<br />
<br />
Solutions probably are<br />
*# Water temperature may be measure from the sensor, other data may be unavailable<br />
*# Modern sidescan sonar may yield information about the seabed through classifications<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# Position offsets must be provided by the user<br />
*# Time outages may be handled by the filter if precise timestamps are available in recorded data<br />
*# LAT to Mean sea level differences may be calculated from DTU10 worldwide, river gauges need to monitored<br />
<br />
[[Datei:LAT2MSLDiff.png]]<br />
<br />
<br />
== Data Condition Examples / Showcases ==<br />
<br />
=== Missing measurments (Position) ===<br />
Distribution for position updates taken from an example dataset. Left column shows the time between two consecutive measurements, right column shows how many measurements had this time update.<br />
One can see from the distribtion that the sensor is updated every second but many measurements are one or more seconds late.<br />
21 seconds with no position update may result in an instability of the subsequent filter.<br />
<pre><br />
MeasuredPosition3D<br />
GP<br />
0 :4285<br />
1000 :11295<br />
2000 :5056<br />
3000 :2134<br />
4000 :1135<br />
5000 :315<br />
6000 :154<br />
7000 :46<br />
8000 :36<br />
9000 :16<br />
10000 :12<br />
11000 :3<br />
12000 :4<br />
13000 :1<br />
14000 :7<br />
15000 :3<br />
16000 :1<br />
21000 :1<br />
</pre><br />
<br />
=== Missing measurments (Position) with erronous clock ===<br />
This example is at a 10 second position update rate. However the measurment time is faulty causing large negative and positive update rates. The clock jumps by +- one year/month/day/hour. One can further see from the many 0 time measurements that the rate at which data is sent to the nmea bus is higher than the actual position update (data is sent every second, a position update is every 10 seconds)<br />
<pre><br />
MeasuredPosition3D<br />
II<br />
-21340000 :1<br />
-13194000 :1<br />
-7998000 :1<br />
-2674000 :1<br />
-2434000 :1<br />
-2402000 :1<br />
-2030000 :1<br />
-1926000 :1<br />
-1894000 :1<br />
-1806000 :1<br />
-1480000 :1<br />
-1430000 :1<br />
-1382000 :1<br />
-1114000 :1<br />
-814000 :1<br />
-634000 :1<br />
-590000 :1<br />
-546000 :1<br />
-470000 :1<br />
-290000 :1<br />
-230000 :1<br />
-198000 :1<br />
-110000 :1<br />
-94000 :2<br />
0 :182200<br />
5000 :1<br />
10000 :20230<br />
15000 :1<br />
20000 :84<br />
50000 :1<br />
114000 :2<br />
130000 :2<br />
218000 :1<br />
250000 :1<br />
310000 :1<br />
490000 :1<br />
566000 :1<br />
610000 :1<br />
654000 :1<br />
834000 :1<br />
1134000 :1<br />
1402000 :1<br />
1450000 :1</pre><br />
<br />
== Solution Proposal ==<br />
<br />
=== Outline ===<br />
The ship is influenced by the outlined environment which can be observed. Naturally what is observed is not the state of the<br />
ship as i.e. the position if taken from GPS is 95% less than 10m accurate. To improve quality an estimation of the true state yields better results if this noise taken into account properly.<br />
<br />
=== Details ===<br />
The ship moves according to physical laws. For the easist case imagine a ship with constant velocity and direction. For any point in time you can tell where the ship is with easy math. Considering the full blown setup a ships movement is affected by many parameters such as wind speed, water current, waves, tide, and many more. The ship moves also triaxial in a dynamic way in itself (roll, pitch, yaw). Heeling even changes the measurement position with respect to the depth position. In terms of a filter this is called a system model that describes how the state of the ship may change. Given such a state you can measure what your sensor readings are and compare that to where the system thinks you are.<br />
<br />
The [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter] is known to be the best linear estimator for such situations. Unfortunately the system model is not linear which is why the Extended Kalman Filter needs to be used in order to linearize the system at hand.<br />
<br />
Todo:<br />
* Construct ship system model with at least the position state and probably its course and speed or even more (depth)<br />
* Estimate the system variance (This is a hard one, proposals welcome)<br />
* Construct the measurement model according to the data available (GPS, Log)<br />
* Estimate the measurement noise according to specifc sensors (DPGS is more accurate than GPS)<br />
<br />
The estimation with the position and depth can be retrieved and stored in a database.<br />
<br />
Pitfalls:<br />
* If the system noise is badly chosen the estimation of the system state does not converge to the true state / measurement.<br />
* If the system is very detailed the system variance can be reduced. The required cpu time for processing increases<br />
<br />
Benefits:<br />
* Having the best estimation of the true position even if measurements are noisy<br />
* Easy and effective algorithmic processing<br />
<br />
== Analysis == <br />
<br />
=== Data Sets ===<br />
Currently two test data sets are available recorded during trips from Mallorca and the Baltic Sea.<br />
In terms of data quality the Mallorca data shows many challenges. <br />
* The minimum recommended sentences from NMEA showed up with false date and time readings while having correct (!!!) message checksums. <br />
* The log on the ship was defective and delivered no readings from time to time. <br />
* The same holds true for the water temperature.<br />
* The GPS positions relatively imprecise because some last decimal digits are missing in the recordings.<br />
* The GPS positions are updated every 10 seconds while other sensor readings update almost every second.<br />
* The GPS position are sometimes way off due to false readings<br />
<br />
The Baltic Sea data set is a little bit better<br />
* Only a single day is available<br />
* GPS positions are updated every second<br />
<br />
One problem with the data is that there is time available when sensor readings were recorded. This yields problems to the filter algorithm.<br />
<br />
<br />
=== Filter Algorithm ===<br />
At first the Extended Kalman Filter is being analyzed. Using an apache implementation with the available data the filter quickly throw an exception that<br />
a matrix is not invertible because of numeric instabilities. When removing this exception the filter seems to work but the removal and its effects have yet to be analyzed.<br />
Literature suggest that a fixed interval smoother may yield better results in case of offline data processing. As it is an extension to the existing kalman filter<br />
we may consider that for the future.<br />
<br />
One problem are the different update rates of the sensors. As GPS may deliver positions at 0.1Hz speed is updated at 1Hz. Literature suggests that<br />
the missing measurements shell be modelled as a random variable with the standard deviation of the sensor. It may even be possible to update covariance matrices only partially with the sensor readings received. Input for the best solution may be formulated on the developer mailing list.<br />
<br />
== Results == <br />
A prototype implementation is shown in the following screenshots. An Extended Kalman Filter is being used. It has the position<br />
and the current bearing and velocity as system state. The input is the measurement of these four observables. The system function is<br />
good old pythagoras. In a first implementation I tried to use orthodrome distances but the system function is not differentiable which is a requirement of the Extended Kalman Filter (due to acrtan2). For small distances pythagoras should be sufficiently accurate. <br />
The initial state is taken from the first measurement for convergence reasons.<br />
<br />
The following gallery shows the results. <br />
* You can see the bad position resolution and an outlier in the first screenshot.<br />
* The second shows the same data overlaid with the applied filter. The outlier is gone and the resolution has improved.<br />
* The third screenshot shows data from a different GPS sensor with more precision (not DGPS) versus the filtered data.<br />
<br />
This of course is just a preliminary test and many setups need to be considered to make it work for most datasets.<br />
<br />
<gallery><br />
UnfilteredNMEA.png | Unfiltered GPS data<br />
FilteredNMEAVsOriginal.png | Unfiltered GPS data and Filtered GPS data<br />
PreciseGPSvsFilter.png | Another precise GPS vs Filtered GPS data<br />
</gallery><br />
<br />
The overall process even gives an estimation of the current error which is a capability of the [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter].<br />
This way positional inaccuracies may be added to the overall depth measurement inaccuracy.<br />
<br />
== Quality rating ==<br />
<br />
Each record (time, positon, depth) should become a quality rating.<br />
<br />
=== Points ===<br />
<br />
Derived from the Fibonacci series.<br />
<br />
{| class="wikitable"<br />
! Point || Description<br />
|-<br />
| 1 || extra small improvement<br />
|-<br />
| 2 || small improvement<br />
|-<br />
| 3 || medium improvement<br />
|-<br />
| 5 || large improvement<br />
|-<br />
| 8 || extra large improvement<br />
|}<br />
<br />
=== Factors ===<br />
<br />
{| class="wikitable"<br />
! style="width:15%" | Name<br />
! style="width:17%" | Factor<br />
! style="width:68%" | Description<br />
|-<br />
| depth offset || 8 (extra large) || The difference between the depth measured by the echo sounder and the depth (waterline) measured by hand.<br />
|-<br />
| device distance || 3 (medium) || The distance between gps antenna and echo sounder (lengthwise and crosswise).<br />
|-<br />
| SBAS || 3 (medium) || Satellite based augmentation system (WAAS, EGNOS, MSAS) which allows to correct the gps position.<br />
|-<br />
| position interpolation || 2 (small improvement) || Arrival of depth and position packets can have a time difference. It is/should be possible to interpolate the position.<br />
|}<br />
<br />
= Depth Rendering =<br />
<br />
= Siehe auch =<br />
* [[De:Bordnetz|Bordnetz]]<br />
* [[De:NMEA-Logger_anschliessen|NMEA-Logger_anschliessen]]<br />
* [http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCkQFjAA&url=http%3A%2F%2Fwww.dei.unipd.it%2F~chiuso%2FDOWNLOAD%2FPositioning_Heading_Kalman.pdf&ei=sSWNUMWnL4eC4gTRlYHAAw&usg=AFQjCNHq5V-PePNmDTZaGYvq0JeQFgqHVw Kalman Filtering for Positioning and Heading Control of Ships and Offshore Rigs]<br />
* [http://users.isr.ist.utl.pt/~pedro/publications/CAMS10.pdf A Multiple Model Adaptive Wave Filter for Dynamic Ship Positioning]<br />
* [http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4449205&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4449205 Echosounder Depth Tracking with the Extended Kalman Filter]</div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:En:Depth_Data&diff=2967OpenSeaMap-dev:En:Depth Data2014-09-30T19:05:36Z<p>MartinOver: /* Baltic Sea Olpenitz (Germany) */</p>
<hr />
<div>This Page describes the necessary efforts to retrieve and analyze depth data as well as create renderings from it<br />
<br />
= Data Aquisition =<br />
Depth data can be retrieved from public domain sources or from crowd sourced data.<br />
<br />
== GEBCO ==<br />
DIe Daten sind gerendert und stehen als Layer zur Verfügung:<br />
{| class="wikitable"<br />
! Zoom || Inhalt<br />
|-<br />
| 0..10 || Blaustufen und Schattierung<br />
|-<br />
| 11..18 || beschriftete Tiefenlinien, Blaustufen und Schattierung<br />
|}<br />
<br />
Noch zu lösende Probleme:<br />
* der GEBCO-Layer erzeugt einen milchigen Schleier über der Basiskarte<br />
* Tiefenlinien sind ab z=14 etwas grob (also ab da, wo dann die Flachwassertiefen beginnen) [http://map.openseamap.org/?zoom=14&lat=36.03097&lon=-5.49153&layers=BFTFTTTFFFF0 Karte]<br />
* Überschneidungen von 100m-Linie und Küstenlinie [http://map.openseamap.org/?zoom=15&lat=36.00318&lon=-5.60819&layers=BFFFTTTFFFF0FFFFF Karte]<br />
* Steilküsten (Cuba) [http://map.openseamap.org/?zoom=14&lat=19.94808&lon=-76.04289&layers=BFTFTTTFFFF0 Karte]<br />
<br />
== Crowd Sourced Data ==<br />
Crowd sourced data may be gathered by YOU. There are two options in development. A hardware and a software option.<br />
<br />
=== Workflow ===<br />
[[Datei:Workflow_depth.png]]<br />
<br />
Here you can find the document with the previous thoughts about the workflow:<br />
[http://osm.franken.de/wiki/FWT-Projekt%C3%BCbersicht-NMEA2Contours_2.1.ppt PPT Dokument]<br />
<br />
=== Hardware logger ===<br />
We are currently developing a hardware logger that may easily be plugged to the ship's network in order to log the networks data to a SD card.<br />
That data may then be uploaded by plugging the SD card to a normal computer with internet connection for upload.<br />
The main goal is to support NMEA 0183 data with options for NMEA 2000.<br />
<br />
=== Software logger ===<br />
A [[Software logger]] is in development and [http://seesea.sourceforge.net/datalogger/index.html can be downloaded here]. <br />
<br />
It currently supports: <br />
: Bluetooth <br />
: Serial ports<br />
: Internet Protocol (IP)<br />
It processes NMEA 0183 and AIS data.<br />
<br />
For vendor specific protocols such as SeaTalk 1 you have to use a [[De:NMEA-Logger_anschliessen|converter]] to NMEA 0183 data.<br />
<br />
NMEA 2000 support is only available if data is transcoded to NMEA 0183 by a converter.<br />
<br />
=== Chart Plotters ===<br />
<br />
Some chart plotters are able to save tracks out-of-the-box, e.g. several Raymarine (FSH files) and Humminbird (SON files) devices. Those files may directly be used as data source.<br />
<br />
<br />
=== Upload Process ===<br />
Uploading data is possible through using the [http://seesea.sourceforge.net/datalogger/index.html OpenSeaMap Data Logger Software] or via [http://depth.openseamap.org/ Web Interface].<br />
The system is currently being tested. <br />
<br />
[[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|You'll find further information here]].<br />
<br />
=== Test Data ===<br />
<br />
<br />
==== Brombachsee (Germany)====<br />
<br />
Test data for Openseamap: [http://osm.franken.de/wiki/test_data_brombachsee.zip Brombachsee_Test_Data]<br />
<br />
dgm_brombachsee.tif: Digital Elevation Model of the sea derived from height lines WWA (C).<br />
<br />
shapes_brombachsee.shp: Shape File derived from 4 NMEA Tracks. "dbs" is the original Sounding and "deep_cor" the depth after a correction (gauge levl).<br />
<br />
gpx_brombachsee.gpx: ele = "dbs" from the Shape File<br />
<br />
[[Datei:Brombachsee.png]]<br />
Resulting Digital Elevation Model<br />
<br />
==== Baltic Sea - near Großenbrode (Germany)====<br />
<br />
First results with an RMS error < 1,5 meter compared to an official dataset of the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].<br />
<br />
[[Datei: Bsh_results_overview.jpg]]<br />
<br />
[Picture 1] '''''OSM map in background, raster Depth Model derived from BSH data and crowed sourced OpenSeaMap Points - Overview'''''<br />
<br />
Blue = flat BSH data, red = deep BSH data.<br />
<br>Blue points = OpenSeaMap raw measuring points.<br />
<br />
{| class="wikitable"<br />
|-<br />
| n || 5062<br />
|-<br />
|-<br />
| datasets || 21<br />
|-<br />
| max deviation || 3,43 meters<br />
|-<br />
| mean (abs) || 0,69 meters<br />
|-<br />
| RMS +/- || 0,91 meters<br />
|}<br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| VesselConfig ID || 68<br />
|-<br />
| Manufacturer || Bavaria Yachtbau<br />
|-<br />
| Model || B32<br />
|-<br />
| Length || 10,0 meters<br />
|-<br />
| Beam || 3,35 meters<br />
|-<br />
| Draft || 1,6 meters<br />
|-<br />
| Height || 14 meters<br />
|-<br />
| Displacement || 4,2 t<br />
|-<br />
| Sensor manufacturer || Raymarine<br />
|-<br />
| Sensor Offset to waterline || 0,45 meters<br />
|-<br />
| Sensor Offset to keel || 1,15 meters<br />
|}<br />
<br />
<br />
<br />
A digital Deep Model raster was computed from the BSH point dataset (c).<br />
The depth of the crowed sourced dataset was compared to the derived raster dataset from the BSH.<br />
The raw crowed sourced dataset was corrected by the sensor offset (0,45 meters).<br />
<br />
[[Datei: Scatter_cor_sensor.jpeg]]<br />
<br />
[Picture 2] '''''Scatter plot: BSH data on the x-axis and the crowed sourced data on the y-axis. Trend line in black and optimal line in red.'''''<br />
<br />
The deviation from the reference dataset increases with the depth measured.<br />
<br />
As you see in the picture below the difference between the datasets has an regular pattern maybe deepending on waves.<br />
<br />
[[Datei: Bsh_results_detail_10_classes.jpg]]<br />
<br />
[Picture 3] '''''Crowed sourced OpenSeaMap track points and the difference from the BSH dataset'''''<br />
<br />
White = low difference, orange = medium difference, red = strong difference<br />
<br />
Download of the data http://osm.franken.de/data/baltic_sea_test_data.zip<br />
'''Be aware of the copyright from the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].'''<br />
The data in the dataset is not corrected by sensor offset.<br />
<br />
==== Baltic Sea Olpenitz (Germany)====<br />
<br />
In this test area we have tracks from two different vessel configurations. <br />
The fist one was the one from the test area Großenbrode (config ID 68).<br />
<br />
In the Table below the settings for die vesselconfigid 110 are shown: <br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| VesselConfigId || 110<br />
|-<br />
| Manufacturer || Waarschip<br />
|-<br />
| Model || 570<br />
|-<br />
| Length || 5,7 meters<br />
|-<br />
| Beam || 2,45 meters<br />
|-<br />
| Draft || 1,0 meters<br />
|-<br />
| Height || 9.1 meters<br />
|-<br />
| Displacement || 0,8 t<br />
|-<br />
| Sensor manufacturer || Tacktick/ Airmar<br />
|-<br />
| Sensor Model || T912<br />
|-<br />
| Sensor Offset to waterline || 0,2 meters<br />
|-<br />
| Sensor Offset to keel || 0,45 meters<br />
|}<br />
<br />
[[Datei: Balitc_sea_scatter_plot_2.jpeg]]<br />
<br />
[Picture 1] Scatterplot for vesselconfigID 110. Trendline in Black and optimal line in red (after correction of the sensor offset to waterline).<br />
<br />
{| class="wikitable"<br />
|-<br />
| vsselConfigId || 110<br />
|-<br />
| n || 247<br />
|-<br />
| mean || 0,49 meters<br />
|-<br />
| rms || 0,62 meters<br />
|-<br />
| max|| 2,53 meters<br />
<br />
|}<br />
<br />
=== Meta Data Statistics ===<br />
<br />
Statistics for the metadata entrees with some personal comments (by MartinOver). Stand 20.9.2014.<br />
<br />
{| class="prettytable"<br />
|-<br />
|<br />
'''Step'''<br />
<br />
|<br />
'''Topic'''<br />
<br />
|<br />
'''Count'''<br />
<br />
|<br />
'''State'''<br />
<br />
|<br />
'''Comment'''<br />
<br />
|-<br />
|<br />
1/1<br />
<br />
|<br />
Name<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
1/2<br />
<br />
|<br />
Description<br />
<br />
|<br />
76/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/1<br />
<br />
|<br />
Length<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
Some wrong entrees like mail addresses or comments <br />
<br />
24 “0.00” Values<br />
<br />
|-<br />
|<br />
2/2<br />
<br />
|<br />
Beam<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
37 „0.00“ Values<br />
<br />
|-<br />
|<br />
2/3<br />
<br />
|<br />
Draft<br />
<br />
|<br />
79/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/4<br />
<br />
|<br />
Displacement<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/5<br />
<br />
|<br />
Height<br />
<br />
|<br />
78/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/6<br />
<br />
|<br />
Manufacturer<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Model<br />
<br />
|<br />
49/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Type<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/3<br />
<br />
|<br />
Position below Waterline<br />
<br />
|<br />
57/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Should be Obligatory<br />
<br />
|-<br />
|<br />
3/4<br />
<br />
|<br />
Depth Measurement<br />
<br />
|<br />
?<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Where in DB?<br />
<br />
|-<br />
|<br />
3/5<br />
<br />
|<br />
Sensor Offset to Keel<br />
<br />
|<br />
6/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/6<br />
<br />
|<br />
Producer of Depth Sensor<br />
<br />
|<br />
63/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/7<br />
<br />
|<br />
Device Model<br />
<br />
|<br />
40/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
58 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
51 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/3<br />
<br />
|<br />
Position abbove Waterline<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/4<br />
<br />
|<br />
Producer<br />
<br />
|<br />
77/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/5<br />
<br />
|<br />
Model<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|}<br />
<br />
= Data Preprocessing =<br />
<br />
== Data Condition ==<br />
Raw data is usually erronous and must be corrected<br />
<br />
=== Internal data problems ===<br />
Depth data may be affected by electrical conditions and software implementations<br />
* Data is incomplete and fail their checksum (bus errors from physical transmissions errors)<br />
* Data is retrived out of sequence<br />
* Data is erronous sensor data <br />
** Approximate correctable data i.e. invalid GPS position that may be interpolated<br />
** Uncorrectable data i.e. failed log sensor that shows slow speeds<br />
* Data resolution is low i.e. for energy saving purposes GPS position is updated every 10 seconds instead of every second<br />
* Sensor data is actively miscalibrated i.e. charter companies add additional draft to the sensor depth for safety reasons<br />
<br />
=== External data problems ===<br />
Depth data may be affected by different environmental circumstances <br />
*# The water temperature affects the ultrasound echo. An inhomogen water temperature yields unwanted echos<br />
*# The seabed affects the ultrasound echo<br />
*# The seastate affects the measurement. There even may be waves when there is no wind.<br />
*# Waves may affect the roll of the measuring vessel resulting in steep measurements that are invalid.<br />
*# The sounder sensor is not the position of the GPS antenna. A position offset including heading must be incorporated.<br />
*# The time of the measurement need not correlate with the time the position was received. This may even happen due to processing time of the hard or software.<br />
*# Corrections for tide induced water levels must happen<br />
<br />
Solutions probably are<br />
*# Water temperature may be measure from the sensor, other data may be unavailable<br />
*# Modern sidescan sonar may yield information about the seabed through classifications<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# Position offsets must be provided by the user<br />
*# Time outages may be handled by the filter if precise timestamps are available in recorded data<br />
*# LAT to Mean sea level differences may be calculated from DTU10 worldwide, river gauges need to monitored<br />
<br />
[[Datei:LAT2MSLDiff.png]]<br />
<br />
<br />
== Data Condition Examples / Showcases ==<br />
<br />
=== Missing measurments (Position) ===<br />
Distribution for position updates taken from an example dataset. Left column shows the time between two consecutive measurements, right column shows how many measurements had this time update.<br />
One can see from the distribtion that the sensor is updated every second but many measurements are one or more seconds late.<br />
21 seconds with no position update may result in an instability of the subsequent filter.<br />
<pre><br />
MeasuredPosition3D<br />
GP<br />
0 :4285<br />
1000 :11295<br />
2000 :5056<br />
3000 :2134<br />
4000 :1135<br />
5000 :315<br />
6000 :154<br />
7000 :46<br />
8000 :36<br />
9000 :16<br />
10000 :12<br />
11000 :3<br />
12000 :4<br />
13000 :1<br />
14000 :7<br />
15000 :3<br />
16000 :1<br />
21000 :1<br />
</pre><br />
<br />
=== Missing measurments (Position) with erronous clock ===<br />
This example is at a 10 second position update rate. However the measurment time is faulty causing large negative and positive update rates. The clock jumps by +- one year/month/day/hour. One can further see from the many 0 time measurements that the rate at which data is sent to the nmea bus is higher than the actual position update (data is sent every second, a position update is every 10 seconds)<br />
<pre><br />
MeasuredPosition3D<br />
II<br />
-21340000 :1<br />
-13194000 :1<br />
-7998000 :1<br />
-2674000 :1<br />
-2434000 :1<br />
-2402000 :1<br />
-2030000 :1<br />
-1926000 :1<br />
-1894000 :1<br />
-1806000 :1<br />
-1480000 :1<br />
-1430000 :1<br />
-1382000 :1<br />
-1114000 :1<br />
-814000 :1<br />
-634000 :1<br />
-590000 :1<br />
-546000 :1<br />
-470000 :1<br />
-290000 :1<br />
-230000 :1<br />
-198000 :1<br />
-110000 :1<br />
-94000 :2<br />
0 :182200<br />
5000 :1<br />
10000 :20230<br />
15000 :1<br />
20000 :84<br />
50000 :1<br />
114000 :2<br />
130000 :2<br />
218000 :1<br />
250000 :1<br />
310000 :1<br />
490000 :1<br />
566000 :1<br />
610000 :1<br />
654000 :1<br />
834000 :1<br />
1134000 :1<br />
1402000 :1<br />
1450000 :1</pre><br />
<br />
== Solution Proposal ==<br />
<br />
=== Outline ===<br />
The ship is influenced by the outlined environment which can be observed. Naturally what is observed is not the state of the<br />
ship as i.e. the position if taken from GPS is 95% less than 10m accurate. To improve quality an estimation of the true state yields better results if this noise taken into account properly.<br />
<br />
=== Details ===<br />
The ship moves according to physical laws. For the easist case imagine a ship with constant velocity and direction. For any point in time you can tell where the ship is with easy math. Considering the full blown setup a ships movement is affected by many parameters such as wind speed, water current, waves, tide, and many more. The ship moves also triaxial in a dynamic way in itself (roll, pitch, yaw). Heeling even changes the measurement position with respect to the depth position. In terms of a filter this is called a system model that describes how the state of the ship may change. Given such a state you can measure what your sensor readings are and compare that to where the system thinks you are.<br />
<br />
The [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter] is known to be the best linear estimator for such situations. Unfortunately the system model is not linear which is why the Extended Kalman Filter needs to be used in order to linearize the system at hand.<br />
<br />
Todo:<br />
* Construct ship system model with at least the position state and probably its course and speed or even more (depth)<br />
* Estimate the system variance (This is a hard one, proposals welcome)<br />
* Construct the measurement model according to the data available (GPS, Log)<br />
* Estimate the measurement noise according to specifc sensors (DPGS is more accurate than GPS)<br />
<br />
The estimation with the position and depth can be retrieved and stored in a database.<br />
<br />
Pitfalls:<br />
* If the system noise is badly chosen the estimation of the system state does not converge to the true state / measurement.<br />
* If the system is very detailed the system variance can be reduced. The required cpu time for processing increases<br />
<br />
Benefits:<br />
* Having the best estimation of the true position even if measurements are noisy<br />
* Easy and effective algorithmic processing<br />
<br />
== Analysis == <br />
<br />
=== Data Sets ===<br />
Currently two test data sets are available recorded during trips from Mallorca and the Baltic Sea.<br />
In terms of data quality the Mallorca data shows many challenges. <br />
* The minimum recommended sentences from NMEA showed up with false date and time readings while having correct (!!!) message checksums. <br />
* The log on the ship was defective and delivered no readings from time to time. <br />
* The same holds true for the water temperature.<br />
* The GPS positions relatively imprecise because some last decimal digits are missing in the recordings.<br />
* The GPS positions are updated every 10 seconds while other sensor readings update almost every second.<br />
* The GPS position are sometimes way off due to false readings<br />
<br />
The Baltic Sea data set is a little bit better<br />
* Only a single day is available<br />
* GPS positions are updated every second<br />
<br />
One problem with the data is that there is time available when sensor readings were recorded. This yields problems to the filter algorithm.<br />
<br />
<br />
=== Filter Algorithm ===<br />
At first the Extended Kalman Filter is being analyzed. Using an apache implementation with the available data the filter quickly throw an exception that<br />
a matrix is not invertible because of numeric instabilities. When removing this exception the filter seems to work but the removal and its effects have yet to be analyzed.<br />
Literature suggest that a fixed interval smoother may yield better results in case of offline data processing. As it is an extension to the existing kalman filter<br />
we may consider that for the future.<br />
<br />
One problem are the different update rates of the sensors. As GPS may deliver positions at 0.1Hz speed is updated at 1Hz. Literature suggests that<br />
the missing measurements shell be modelled as a random variable with the standard deviation of the sensor. It may even be possible to update covariance matrices only partially with the sensor readings received. Input for the best solution may be formulated on the developer mailing list.<br />
<br />
== Results == <br />
A prototype implementation is shown in the following screenshots. An Extended Kalman Filter is being used. It has the position<br />
and the current bearing and velocity as system state. The input is the measurement of these four observables. The system function is<br />
good old pythagoras. In a first implementation I tried to use orthodrome distances but the system function is not differentiable which is a requirement of the Extended Kalman Filter (due to acrtan2). For small distances pythagoras should be sufficiently accurate. <br />
The initial state is taken from the first measurement for convergence reasons.<br />
<br />
The following gallery shows the results. <br />
* You can see the bad position resolution and an outlier in the first screenshot.<br />
* The second shows the same data overlaid with the applied filter. The outlier is gone and the resolution has improved.<br />
* The third screenshot shows data from a different GPS sensor with more precision (not DGPS) versus the filtered data.<br />
<br />
This of course is just a preliminary test and many setups need to be considered to make it work for most datasets.<br />
<br />
<gallery><br />
UnfilteredNMEA.png | Unfiltered GPS data<br />
FilteredNMEAVsOriginal.png | Unfiltered GPS data and Filtered GPS data<br />
PreciseGPSvsFilter.png | Another precise GPS vs Filtered GPS data<br />
</gallery><br />
<br />
The overall process even gives an estimation of the current error which is a capability of the [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter].<br />
This way positional inaccuracies may be added to the overall depth measurement inaccuracy.<br />
<br />
== Quality rating ==<br />
<br />
Each record (time, positon, depth) should become a quality rating.<br />
<br />
=== Points ===<br />
<br />
Derived from the Fibonacci series.<br />
<br />
{| class="wikitable"<br />
! Point || Description<br />
|-<br />
| 1 || extra small improvement<br />
|-<br />
| 2 || small improvement<br />
|-<br />
| 3 || medium improvement<br />
|-<br />
| 5 || large improvement<br />
|-<br />
| 8 || extra large improvement<br />
|}<br />
<br />
=== Factors ===<br />
<br />
{| class="wikitable"<br />
! style="width:15%" | Name<br />
! style="width:17%" | Factor<br />
! style="width:68%" | Description<br />
|-<br />
| depth offset || 8 (extra large) || The difference between the depth measured by the echo sounder and the depth (waterline) measured by hand.<br />
|-<br />
| device distance || 3 (medium) || The distance between gps antenna and echo sounder (lengthwise and crosswise).<br />
|-<br />
| SBAS || 3 (medium) || Satellite based augmentation system (WAAS, EGNOS, MSAS) which allows to correct the gps position.<br />
|-<br />
| position interpolation || 2 (small improvement) || Arrival of depth and position packets can have a time difference. It is/should be possible to interpolate the position.<br />
|}<br />
<br />
= Depth Rendering =<br />
<br />
= Siehe auch =<br />
* [[De:Bordnetz|Bordnetz]]<br />
* [[De:NMEA-Logger_anschliessen|NMEA-Logger_anschliessen]]<br />
* [http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCkQFjAA&url=http%3A%2F%2Fwww.dei.unipd.it%2F~chiuso%2FDOWNLOAD%2FPositioning_Heading_Kalman.pdf&ei=sSWNUMWnL4eC4gTRlYHAAw&usg=AFQjCNHq5V-PePNmDTZaGYvq0JeQFgqHVw Kalman Filtering for Positioning and Heading Control of Ships and Offshore Rigs]<br />
* [http://users.isr.ist.utl.pt/~pedro/publications/CAMS10.pdf A Multiple Model Adaptive Wave Filter for Dynamic Ship Positioning]<br />
* [http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4449205&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4449205 Echosounder Depth Tracking with the Extended Kalman Filter]</div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:En:Depth_Data&diff=2966OpenSeaMap-dev:En:Depth Data2014-09-30T19:04:03Z<p>MartinOver: /* Baltic Sea Olpenitz (Germany) */</p>
<hr />
<div>This Page describes the necessary efforts to retrieve and analyze depth data as well as create renderings from it<br />
<br />
= Data Aquisition =<br />
Depth data can be retrieved from public domain sources or from crowd sourced data.<br />
<br />
== GEBCO ==<br />
DIe Daten sind gerendert und stehen als Layer zur Verfügung:<br />
{| class="wikitable"<br />
! Zoom || Inhalt<br />
|-<br />
| 0..10 || Blaustufen und Schattierung<br />
|-<br />
| 11..18 || beschriftete Tiefenlinien, Blaustufen und Schattierung<br />
|}<br />
<br />
Noch zu lösende Probleme:<br />
* der GEBCO-Layer erzeugt einen milchigen Schleier über der Basiskarte<br />
* Tiefenlinien sind ab z=14 etwas grob (also ab da, wo dann die Flachwassertiefen beginnen) [http://map.openseamap.org/?zoom=14&lat=36.03097&lon=-5.49153&layers=BFTFTTTFFFF0 Karte]<br />
* Überschneidungen von 100m-Linie und Küstenlinie [http://map.openseamap.org/?zoom=15&lat=36.00318&lon=-5.60819&layers=BFFFTTTFFFF0FFFFF Karte]<br />
* Steilküsten (Cuba) [http://map.openseamap.org/?zoom=14&lat=19.94808&lon=-76.04289&layers=BFTFTTTFFFF0 Karte]<br />
<br />
== Crowd Sourced Data ==<br />
Crowd sourced data may be gathered by YOU. There are two options in development. A hardware and a software option.<br />
<br />
=== Workflow ===<br />
[[Datei:Workflow_depth.png]]<br />
<br />
Here you can find the document with the previous thoughts about the workflow:<br />
[http://osm.franken.de/wiki/FWT-Projekt%C3%BCbersicht-NMEA2Contours_2.1.ppt PPT Dokument]<br />
<br />
=== Hardware logger ===<br />
We are currently developing a hardware logger that may easily be plugged to the ship's network in order to log the networks data to a SD card.<br />
That data may then be uploaded by plugging the SD card to a normal computer with internet connection for upload.<br />
The main goal is to support NMEA 0183 data with options for NMEA 2000.<br />
<br />
=== Software logger ===<br />
A [[Software logger]] is in development and [http://seesea.sourceforge.net/datalogger/index.html can be downloaded here]. <br />
<br />
It currently supports: <br />
: Bluetooth <br />
: Serial ports<br />
: Internet Protocol (IP)<br />
It processes NMEA 0183 and AIS data.<br />
<br />
For vendor specific protocols such as SeaTalk 1 you have to use a [[De:NMEA-Logger_anschliessen|converter]] to NMEA 0183 data.<br />
<br />
NMEA 2000 support is only available if data is transcoded to NMEA 0183 by a converter.<br />
<br />
=== Chart Plotters ===<br />
<br />
Some chart plotters are able to save tracks out-of-the-box, e.g. several Raymarine (FSH files) and Humminbird (SON files) devices. Those files may directly be used as data source.<br />
<br />
<br />
=== Upload Process ===<br />
Uploading data is possible through using the [http://seesea.sourceforge.net/datalogger/index.html OpenSeaMap Data Logger Software] or via [http://depth.openseamap.org/ Web Interface].<br />
The system is currently being tested. <br />
<br />
[[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|You'll find further information here]].<br />
<br />
=== Test Data ===<br />
<br />
<br />
==== Brombachsee (Germany)====<br />
<br />
Test data for Openseamap: [http://osm.franken.de/wiki/test_data_brombachsee.zip Brombachsee_Test_Data]<br />
<br />
dgm_brombachsee.tif: Digital Elevation Model of the sea derived from height lines WWA (C).<br />
<br />
shapes_brombachsee.shp: Shape File derived from 4 NMEA Tracks. "dbs" is the original Sounding and "deep_cor" the depth after a correction (gauge levl).<br />
<br />
gpx_brombachsee.gpx: ele = "dbs" from the Shape File<br />
<br />
[[Datei:Brombachsee.png]]<br />
Resulting Digital Elevation Model<br />
<br />
==== Baltic Sea - near Großenbrode (Germany)====<br />
<br />
First results with an RMS error < 1,5 meter compared to an official dataset of the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].<br />
<br />
[[Datei: Bsh_results_overview.jpg]]<br />
<br />
[Picture 1] '''''OSM map in background, raster Depth Model derived from BSH data and crowed sourced OpenSeaMap Points - Overview'''''<br />
<br />
Blue = flat BSH data, red = deep BSH data.<br />
<br>Blue points = OpenSeaMap raw measuring points.<br />
<br />
{| class="wikitable"<br />
|-<br />
| n || 5062<br />
|-<br />
|-<br />
| datasets || 21<br />
|-<br />
| max deviation || 3,43 meters<br />
|-<br />
| mean (abs) || 0,69 meters<br />
|-<br />
| RMS +/- || 0,91 meters<br />
|}<br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| VesselConfig ID || 68<br />
|-<br />
| Manufacturer || Bavaria Yachtbau<br />
|-<br />
| Model || B32<br />
|-<br />
| Length || 10,0 meters<br />
|-<br />
| Beam || 3,35 meters<br />
|-<br />
| Draft || 1,6 meters<br />
|-<br />
| Height || 14 meters<br />
|-<br />
| Displacement || 4,2 t<br />
|-<br />
| Sensor manufacturer || Raymarine<br />
|-<br />
| Sensor Offset to waterline || 0,45 meters<br />
|-<br />
| Sensor Offset to keel || 1,15 meters<br />
|}<br />
<br />
<br />
<br />
A digital Deep Model raster was computed from the BSH point dataset (c).<br />
The depth of the crowed sourced dataset was compared to the derived raster dataset from the BSH.<br />
The raw crowed sourced dataset was corrected by the sensor offset (0,45 meters).<br />
<br />
[[Datei: Scatter_cor_sensor.jpeg]]<br />
<br />
[Picture 2] '''''Scatter plot: BSH data on the x-axis and the crowed sourced data on the y-axis. Trend line in black and optimal line in red.'''''<br />
<br />
The deviation from the reference dataset increases with the depth measured.<br />
<br />
As you see in the picture below the difference between the datasets has an regular pattern maybe deepending on waves.<br />
<br />
[[Datei: Bsh_results_detail_10_classes.jpg]]<br />
<br />
[Picture 3] '''''Crowed sourced OpenSeaMap track points and the difference from the BSH dataset'''''<br />
<br />
White = low difference, orange = medium difference, red = strong difference<br />
<br />
Download of the data http://osm.franken.de/data/baltic_sea_test_data.zip<br />
'''Be aware of the copyright from the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].'''<br />
The data in the dataset is not corrected by sensor offset.<br />
<br />
==== Baltic Sea Olpenitz (Germany)====<br />
<br />
In this test area we have tracks from two different vessel configurations. <br />
The fist one was the one from the test area Großenbrode (config ID 68).<br />
<br />
In the Table below the settings for die vesselconfigid 110 are shown: <br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| VesselConfigId || 110<br />
|-<br />
| Manufacturer || Waarschip<br />
|-<br />
| Model || 570<br />
|-<br />
| Length || 5,7 meters<br />
|-<br />
| Beam || 2,45 meters<br />
|-<br />
| Draft || 1,0 meters<br />
|-<br />
| Height || 9.1 meters<br />
|-<br />
| Displacement || 0,8 t<br />
|-<br />
| Sensor manufacturer || Tacktick/ Airmar<br />
|-<br />
| Sensor Model || T912<br />
|-<br />
| Sensor Offset to waterline || 0,2 meters<br />
|-<br />
| Sensor Offset to keel || 0,45 meters<br />
|}<br />
<br />
[[Datei: Balitc_sea_scatter_plot_2.jpeg]]<br />
<br />
[Picture 1] Scatterplot for vesselconfigID 110. Trendline in Black and optimal line in red (after correction of the sensor offset to waterline).<br />
<br />
{| class="wikitable"<br />
|-<br />
| vsselConfigId || 110<br />
|-<br />
| n || 247<br />
|-<br />
| mean || 0,49 meters<br />
|-<br />
| rms || 0,62 meters<br />
|}<br />
<br />
=== Meta Data Statistics ===<br />
<br />
Statistics for the metadata entrees with some personal comments (by MartinOver). Stand 20.9.2014.<br />
<br />
{| class="prettytable"<br />
|-<br />
|<br />
'''Step'''<br />
<br />
|<br />
'''Topic'''<br />
<br />
|<br />
'''Count'''<br />
<br />
|<br />
'''State'''<br />
<br />
|<br />
'''Comment'''<br />
<br />
|-<br />
|<br />
1/1<br />
<br />
|<br />
Name<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
1/2<br />
<br />
|<br />
Description<br />
<br />
|<br />
76/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/1<br />
<br />
|<br />
Length<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
Some wrong entrees like mail addresses or comments <br />
<br />
24 “0.00” Values<br />
<br />
|-<br />
|<br />
2/2<br />
<br />
|<br />
Beam<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
37 „0.00“ Values<br />
<br />
|-<br />
|<br />
2/3<br />
<br />
|<br />
Draft<br />
<br />
|<br />
79/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/4<br />
<br />
|<br />
Displacement<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/5<br />
<br />
|<br />
Height<br />
<br />
|<br />
78/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/6<br />
<br />
|<br />
Manufacturer<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Model<br />
<br />
|<br />
49/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Type<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/3<br />
<br />
|<br />
Position below Waterline<br />
<br />
|<br />
57/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Should be Obligatory<br />
<br />
|-<br />
|<br />
3/4<br />
<br />
|<br />
Depth Measurement<br />
<br />
|<br />
?<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Where in DB?<br />
<br />
|-<br />
|<br />
3/5<br />
<br />
|<br />
Sensor Offset to Keel<br />
<br />
|<br />
6/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/6<br />
<br />
|<br />
Producer of Depth Sensor<br />
<br />
|<br />
63/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/7<br />
<br />
|<br />
Device Model<br />
<br />
|<br />
40/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
58 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
51 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/3<br />
<br />
|<br />
Position abbove Waterline<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/4<br />
<br />
|<br />
Producer<br />
<br />
|<br />
77/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/5<br />
<br />
|<br />
Model<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|}<br />
<br />
= Data Preprocessing =<br />
<br />
== Data Condition ==<br />
Raw data is usually erronous and must be corrected<br />
<br />
=== Internal data problems ===<br />
Depth data may be affected by electrical conditions and software implementations<br />
* Data is incomplete and fail their checksum (bus errors from physical transmissions errors)<br />
* Data is retrived out of sequence<br />
* Data is erronous sensor data <br />
** Approximate correctable data i.e. invalid GPS position that may be interpolated<br />
** Uncorrectable data i.e. failed log sensor that shows slow speeds<br />
* Data resolution is low i.e. for energy saving purposes GPS position is updated every 10 seconds instead of every second<br />
* Sensor data is actively miscalibrated i.e. charter companies add additional draft to the sensor depth for safety reasons<br />
<br />
=== External data problems ===<br />
Depth data may be affected by different environmental circumstances <br />
*# The water temperature affects the ultrasound echo. An inhomogen water temperature yields unwanted echos<br />
*# The seabed affects the ultrasound echo<br />
*# The seastate affects the measurement. There even may be waves when there is no wind.<br />
*# Waves may affect the roll of the measuring vessel resulting in steep measurements that are invalid.<br />
*# The sounder sensor is not the position of the GPS antenna. A position offset including heading must be incorporated.<br />
*# The time of the measurement need not correlate with the time the position was received. This may even happen due to processing time of the hard or software.<br />
*# Corrections for tide induced water levels must happen<br />
<br />
Solutions probably are<br />
*# Water temperature may be measure from the sensor, other data may be unavailable<br />
*# Modern sidescan sonar may yield information about the seabed through classifications<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# Position offsets must be provided by the user<br />
*# Time outages may be handled by the filter if precise timestamps are available in recorded data<br />
*# LAT to Mean sea level differences may be calculated from DTU10 worldwide, river gauges need to monitored<br />
<br />
[[Datei:LAT2MSLDiff.png]]<br />
<br />
<br />
== Data Condition Examples / Showcases ==<br />
<br />
=== Missing measurments (Position) ===<br />
Distribution for position updates taken from an example dataset. Left column shows the time between two consecutive measurements, right column shows how many measurements had this time update.<br />
One can see from the distribtion that the sensor is updated every second but many measurements are one or more seconds late.<br />
21 seconds with no position update may result in an instability of the subsequent filter.<br />
<pre><br />
MeasuredPosition3D<br />
GP<br />
0 :4285<br />
1000 :11295<br />
2000 :5056<br />
3000 :2134<br />
4000 :1135<br />
5000 :315<br />
6000 :154<br />
7000 :46<br />
8000 :36<br />
9000 :16<br />
10000 :12<br />
11000 :3<br />
12000 :4<br />
13000 :1<br />
14000 :7<br />
15000 :3<br />
16000 :1<br />
21000 :1<br />
</pre><br />
<br />
=== Missing measurments (Position) with erronous clock ===<br />
This example is at a 10 second position update rate. However the measurment time is faulty causing large negative and positive update rates. The clock jumps by +- one year/month/day/hour. One can further see from the many 0 time measurements that the rate at which data is sent to the nmea bus is higher than the actual position update (data is sent every second, a position update is every 10 seconds)<br />
<pre><br />
MeasuredPosition3D<br />
II<br />
-21340000 :1<br />
-13194000 :1<br />
-7998000 :1<br />
-2674000 :1<br />
-2434000 :1<br />
-2402000 :1<br />
-2030000 :1<br />
-1926000 :1<br />
-1894000 :1<br />
-1806000 :1<br />
-1480000 :1<br />
-1430000 :1<br />
-1382000 :1<br />
-1114000 :1<br />
-814000 :1<br />
-634000 :1<br />
-590000 :1<br />
-546000 :1<br />
-470000 :1<br />
-290000 :1<br />
-230000 :1<br />
-198000 :1<br />
-110000 :1<br />
-94000 :2<br />
0 :182200<br />
5000 :1<br />
10000 :20230<br />
15000 :1<br />
20000 :84<br />
50000 :1<br />
114000 :2<br />
130000 :2<br />
218000 :1<br />
250000 :1<br />
310000 :1<br />
490000 :1<br />
566000 :1<br />
610000 :1<br />
654000 :1<br />
834000 :1<br />
1134000 :1<br />
1402000 :1<br />
1450000 :1</pre><br />
<br />
== Solution Proposal ==<br />
<br />
=== Outline ===<br />
The ship is influenced by the outlined environment which can be observed. Naturally what is observed is not the state of the<br />
ship as i.e. the position if taken from GPS is 95% less than 10m accurate. To improve quality an estimation of the true state yields better results if this noise taken into account properly.<br />
<br />
=== Details ===<br />
The ship moves according to physical laws. For the easist case imagine a ship with constant velocity and direction. For any point in time you can tell where the ship is with easy math. Considering the full blown setup a ships movement is affected by many parameters such as wind speed, water current, waves, tide, and many more. The ship moves also triaxial in a dynamic way in itself (roll, pitch, yaw). Heeling even changes the measurement position with respect to the depth position. In terms of a filter this is called a system model that describes how the state of the ship may change. Given such a state you can measure what your sensor readings are and compare that to where the system thinks you are.<br />
<br />
The [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter] is known to be the best linear estimator for such situations. Unfortunately the system model is not linear which is why the Extended Kalman Filter needs to be used in order to linearize the system at hand.<br />
<br />
Todo:<br />
* Construct ship system model with at least the position state and probably its course and speed or even more (depth)<br />
* Estimate the system variance (This is a hard one, proposals welcome)<br />
* Construct the measurement model according to the data available (GPS, Log)<br />
* Estimate the measurement noise according to specifc sensors (DPGS is more accurate than GPS)<br />
<br />
The estimation with the position and depth can be retrieved and stored in a database.<br />
<br />
Pitfalls:<br />
* If the system noise is badly chosen the estimation of the system state does not converge to the true state / measurement.<br />
* If the system is very detailed the system variance can be reduced. The required cpu time for processing increases<br />
<br />
Benefits:<br />
* Having the best estimation of the true position even if measurements are noisy<br />
* Easy and effective algorithmic processing<br />
<br />
== Analysis == <br />
<br />
=== Data Sets ===<br />
Currently two test data sets are available recorded during trips from Mallorca and the Baltic Sea.<br />
In terms of data quality the Mallorca data shows many challenges. <br />
* The minimum recommended sentences from NMEA showed up with false date and time readings while having correct (!!!) message checksums. <br />
* The log on the ship was defective and delivered no readings from time to time. <br />
* The same holds true for the water temperature.<br />
* The GPS positions relatively imprecise because some last decimal digits are missing in the recordings.<br />
* The GPS positions are updated every 10 seconds while other sensor readings update almost every second.<br />
* The GPS position are sometimes way off due to false readings<br />
<br />
The Baltic Sea data set is a little bit better<br />
* Only a single day is available<br />
* GPS positions are updated every second<br />
<br />
One problem with the data is that there is time available when sensor readings were recorded. This yields problems to the filter algorithm.<br />
<br />
<br />
=== Filter Algorithm ===<br />
At first the Extended Kalman Filter is being analyzed. Using an apache implementation with the available data the filter quickly throw an exception that<br />
a matrix is not invertible because of numeric instabilities. When removing this exception the filter seems to work but the removal and its effects have yet to be analyzed.<br />
Literature suggest that a fixed interval smoother may yield better results in case of offline data processing. As it is an extension to the existing kalman filter<br />
we may consider that for the future.<br />
<br />
One problem are the different update rates of the sensors. As GPS may deliver positions at 0.1Hz speed is updated at 1Hz. Literature suggests that<br />
the missing measurements shell be modelled as a random variable with the standard deviation of the sensor. It may even be possible to update covariance matrices only partially with the sensor readings received. Input for the best solution may be formulated on the developer mailing list.<br />
<br />
== Results == <br />
A prototype implementation is shown in the following screenshots. An Extended Kalman Filter is being used. It has the position<br />
and the current bearing and velocity as system state. The input is the measurement of these four observables. The system function is<br />
good old pythagoras. In a first implementation I tried to use orthodrome distances but the system function is not differentiable which is a requirement of the Extended Kalman Filter (due to acrtan2). For small distances pythagoras should be sufficiently accurate. <br />
The initial state is taken from the first measurement for convergence reasons.<br />
<br />
The following gallery shows the results. <br />
* You can see the bad position resolution and an outlier in the first screenshot.<br />
* The second shows the same data overlaid with the applied filter. The outlier is gone and the resolution has improved.<br />
* The third screenshot shows data from a different GPS sensor with more precision (not DGPS) versus the filtered data.<br />
<br />
This of course is just a preliminary test and many setups need to be considered to make it work for most datasets.<br />
<br />
<gallery><br />
UnfilteredNMEA.png | Unfiltered GPS data<br />
FilteredNMEAVsOriginal.png | Unfiltered GPS data and Filtered GPS data<br />
PreciseGPSvsFilter.png | Another precise GPS vs Filtered GPS data<br />
</gallery><br />
<br />
The overall process even gives an estimation of the current error which is a capability of the [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter].<br />
This way positional inaccuracies may be added to the overall depth measurement inaccuracy.<br />
<br />
== Quality rating ==<br />
<br />
Each record (time, positon, depth) should become a quality rating.<br />
<br />
=== Points ===<br />
<br />
Derived from the Fibonacci series.<br />
<br />
{| class="wikitable"<br />
! Point || Description<br />
|-<br />
| 1 || extra small improvement<br />
|-<br />
| 2 || small improvement<br />
|-<br />
| 3 || medium improvement<br />
|-<br />
| 5 || large improvement<br />
|-<br />
| 8 || extra large improvement<br />
|}<br />
<br />
=== Factors ===<br />
<br />
{| class="wikitable"<br />
! style="width:15%" | Name<br />
! style="width:17%" | Factor<br />
! style="width:68%" | Description<br />
|-<br />
| depth offset || 8 (extra large) || The difference between the depth measured by the echo sounder and the depth (waterline) measured by hand.<br />
|-<br />
| device distance || 3 (medium) || The distance between gps antenna and echo sounder (lengthwise and crosswise).<br />
|-<br />
| SBAS || 3 (medium) || Satellite based augmentation system (WAAS, EGNOS, MSAS) which allows to correct the gps position.<br />
|-<br />
| position interpolation || 2 (small improvement) || Arrival of depth and position packets can have a time difference. It is/should be possible to interpolate the position.<br />
|}<br />
<br />
= Depth Rendering =<br />
<br />
= Siehe auch =<br />
* [[De:Bordnetz|Bordnetz]]<br />
* [[De:NMEA-Logger_anschliessen|NMEA-Logger_anschliessen]]<br />
* [http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCkQFjAA&url=http%3A%2F%2Fwww.dei.unipd.it%2F~chiuso%2FDOWNLOAD%2FPositioning_Heading_Kalman.pdf&ei=sSWNUMWnL4eC4gTRlYHAAw&usg=AFQjCNHq5V-PePNmDTZaGYvq0JeQFgqHVw Kalman Filtering for Positioning and Heading Control of Ships and Offshore Rigs]<br />
* [http://users.isr.ist.utl.pt/~pedro/publications/CAMS10.pdf A Multiple Model Adaptive Wave Filter for Dynamic Ship Positioning]<br />
* [http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4449205&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4449205 Echosounder Depth Tracking with the Extended Kalman Filter]</div>MartinOverhttps://wiki.openseamap.org/index.php?title=Datei:Balitc_sea_scatter_plot_2.jpeg&diff=2965Datei:Balitc sea scatter plot 2.jpeg2014-09-30T18:57:23Z<p>MartinOver: MartinOver lud eine neue Version von „Datei:Balitc sea scatter plot 2.jpeg“ hoch</p>
<hr />
<div></div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:En:Depth_Data&diff=2964OpenSeaMap-dev:En:Depth Data2014-09-30T18:38:24Z<p>MartinOver: /* Baltic Sea Olpenitz (Germany) */</p>
<hr />
<div>This Page describes the necessary efforts to retrieve and analyze depth data as well as create renderings from it<br />
<br />
= Data Aquisition =<br />
Depth data can be retrieved from public domain sources or from crowd sourced data.<br />
<br />
== GEBCO ==<br />
DIe Daten sind gerendert und stehen als Layer zur Verfügung:<br />
{| class="wikitable"<br />
! Zoom || Inhalt<br />
|-<br />
| 0..10 || Blaustufen und Schattierung<br />
|-<br />
| 11..18 || beschriftete Tiefenlinien, Blaustufen und Schattierung<br />
|}<br />
<br />
Noch zu lösende Probleme:<br />
* der GEBCO-Layer erzeugt einen milchigen Schleier über der Basiskarte<br />
* Tiefenlinien sind ab z=14 etwas grob (also ab da, wo dann die Flachwassertiefen beginnen) [http://map.openseamap.org/?zoom=14&lat=36.03097&lon=-5.49153&layers=BFTFTTTFFFF0 Karte]<br />
* Überschneidungen von 100m-Linie und Küstenlinie [http://map.openseamap.org/?zoom=15&lat=36.00318&lon=-5.60819&layers=BFFFTTTFFFF0FFFFF Karte]<br />
* Steilküsten (Cuba) [http://map.openseamap.org/?zoom=14&lat=19.94808&lon=-76.04289&layers=BFTFTTTFFFF0 Karte]<br />
<br />
== Crowd Sourced Data ==<br />
Crowd sourced data may be gathered by YOU. There are two options in development. A hardware and a software option.<br />
<br />
=== Workflow ===<br />
[[Datei:Workflow_depth.png]]<br />
<br />
Here you can find the document with the previous thoughts about the workflow:<br />
[http://osm.franken.de/wiki/FWT-Projekt%C3%BCbersicht-NMEA2Contours_2.1.ppt PPT Dokument]<br />
<br />
=== Hardware logger ===<br />
We are currently developing a hardware logger that may easily be plugged to the ship's network in order to log the networks data to a SD card.<br />
That data may then be uploaded by plugging the SD card to a normal computer with internet connection for upload.<br />
The main goal is to support NMEA 0183 data with options for NMEA 2000.<br />
<br />
=== Software logger ===<br />
A [[Software logger]] is in development and [http://seesea.sourceforge.net/datalogger/index.html can be downloaded here]. <br />
<br />
It currently supports: <br />
: Bluetooth <br />
: Serial ports<br />
: Internet Protocol (IP)<br />
It processes NMEA 0183 and AIS data.<br />
<br />
For vendor specific protocols such as SeaTalk 1 you have to use a [[De:NMEA-Logger_anschliessen|converter]] to NMEA 0183 data.<br />
<br />
NMEA 2000 support is only available if data is transcoded to NMEA 0183 by a converter.<br />
<br />
=== Chart Plotters ===<br />
<br />
Some chart plotters are able to save tracks out-of-the-box, e.g. several Raymarine (FSH files) and Humminbird (SON files) devices. Those files may directly be used as data source.<br />
<br />
<br />
=== Upload Process ===<br />
Uploading data is possible through using the [http://seesea.sourceforge.net/datalogger/index.html OpenSeaMap Data Logger Software] or via [http://depth.openseamap.org/ Web Interface].<br />
The system is currently being tested. <br />
<br />
[[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|You'll find further information here]].<br />
<br />
=== Test Data ===<br />
<br />
<br />
==== Brombachsee (Germany)====<br />
<br />
Test data for Openseamap: [http://osm.franken.de/wiki/test_data_brombachsee.zip Brombachsee_Test_Data]<br />
<br />
dgm_brombachsee.tif: Digital Elevation Model of the sea derived from height lines WWA (C).<br />
<br />
shapes_brombachsee.shp: Shape File derived from 4 NMEA Tracks. "dbs" is the original Sounding and "deep_cor" the depth after a correction (gauge levl).<br />
<br />
gpx_brombachsee.gpx: ele = "dbs" from the Shape File<br />
<br />
[[Datei:Brombachsee.png]]<br />
Resulting Digital Elevation Model<br />
<br />
==== Baltic Sea - near Großenbrode (Germany)====<br />
<br />
First results with an RMS error < 1,5 meter compared to an official dataset of the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].<br />
<br />
[[Datei: Bsh_results_overview.jpg]]<br />
<br />
[Picture 1] '''''OSM map in background, raster Depth Model derived from BSH data and crowed sourced OpenSeaMap Points - Overview'''''<br />
<br />
Blue = flat BSH data, red = deep BSH data.<br />
<br>Blue points = OpenSeaMap raw measuring points.<br />
<br />
{| class="wikitable"<br />
|-<br />
| n || 5062<br />
|-<br />
|-<br />
| datasets || 21<br />
|-<br />
| max deviation || 3,43 meters<br />
|-<br />
| mean (abs) || 0,69 meters<br />
|-<br />
| RMS +/- || 0,91 meters<br />
|}<br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| VesselConfig ID || 68<br />
|-<br />
| Manufacturer || Bavaria Yachtbau<br />
|-<br />
| Model || B32<br />
|-<br />
| Length || 10,0 meters<br />
|-<br />
| Beam || 3,35 meters<br />
|-<br />
| Draft || 1,6 meters<br />
|-<br />
| Height || 14 meters<br />
|-<br />
| Displacement || 4,2 t<br />
|-<br />
| Sensor manufacturer || Raymarine<br />
|-<br />
| Sensor Offset to waterline || 0,45 meters<br />
|-<br />
| Sensor Offset to keel || 1,15 meters<br />
|}<br />
<br />
<br />
<br />
A digital Deep Model raster was computed from the BSH point dataset (c).<br />
The depth of the crowed sourced dataset was compared to the derived raster dataset from the BSH.<br />
The raw crowed sourced dataset was corrected by the sensor offset (0,45 meters).<br />
<br />
[[Datei: Scatter_cor_sensor.jpeg]]<br />
<br />
[Picture 2] '''''Scatter plot: BSH data on the x-axis and the crowed sourced data on the y-axis. Trend line in black and optimal line in red.'''''<br />
<br />
The deviation from the reference dataset increases with the depth measured.<br />
<br />
As you see in the picture below the difference between the datasets has an regular pattern maybe deepending on waves.<br />
<br />
[[Datei: Bsh_results_detail_10_classes.jpg]]<br />
<br />
[Picture 3] '''''Crowed sourced OpenSeaMap track points and the difference from the BSH dataset'''''<br />
<br />
White = low difference, orange = medium difference, red = strong difference<br />
<br />
Download of the data http://osm.franken.de/data/baltic_sea_test_data.zip<br />
'''Be aware of the copyright from the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].'''<br />
The data in the dataset is not corrected by sensor offset.<br />
<br />
==== Baltic Sea Olpenitz (Germany)====<br />
<br />
In this test area we have tracks from two different vessel configurations. <br />
The fist one was the one from the test area Großenbrode (config ID 68).<br />
<br />
In the Table below the settings for die vesselconfigid 110 are shown: <br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| VesselConfigId || 110<br />
|-<br />
| Manufacturer || Waarschip<br />
|-<br />
| Model || 570<br />
|-<br />
| Length || 5,7 meters<br />
|-<br />
| Beam || 2,45 meters<br />
|-<br />
| Draft || 1,0 meters<br />
|-<br />
| Height || 9.1 meters<br />
|-<br />
| Displacement || 0,8 t<br />
|-<br />
| Sensor manufacturer || Tacktick/ Airmar<br />
|-<br />
| Sensor Model || T912<br />
|-<br />
| Sensor Offset to waterline || 0,2 meters<br />
|-<br />
| Sensor Offset to keel || 0,45 meters<br />
|}<br />
<br />
[[Datei: Balitc_sea_scatter_plot_2.jpeg]]<br />
<br />
[Picture 1] Scatterplot for vesselconfigID 110. Trendline in Black and optimal line in red.<br />
<br />
=== Meta Data Statistics ===<br />
<br />
Statistics for the metadata entrees with some personal comments (by MartinOver). Stand 20.9.2014.<br />
<br />
{| class="prettytable"<br />
|-<br />
|<br />
'''Step'''<br />
<br />
|<br />
'''Topic'''<br />
<br />
|<br />
'''Count'''<br />
<br />
|<br />
'''State'''<br />
<br />
|<br />
'''Comment'''<br />
<br />
|-<br />
|<br />
1/1<br />
<br />
|<br />
Name<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
1/2<br />
<br />
|<br />
Description<br />
<br />
|<br />
76/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/1<br />
<br />
|<br />
Length<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
Some wrong entrees like mail addresses or comments <br />
<br />
24 “0.00” Values<br />
<br />
|-<br />
|<br />
2/2<br />
<br />
|<br />
Beam<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
37 „0.00“ Values<br />
<br />
|-<br />
|<br />
2/3<br />
<br />
|<br />
Draft<br />
<br />
|<br />
79/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/4<br />
<br />
|<br />
Displacement<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/5<br />
<br />
|<br />
Height<br />
<br />
|<br />
78/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/6<br />
<br />
|<br />
Manufacturer<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Model<br />
<br />
|<br />
49/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Type<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/3<br />
<br />
|<br />
Position below Waterline<br />
<br />
|<br />
57/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Should be Obligatory<br />
<br />
|-<br />
|<br />
3/4<br />
<br />
|<br />
Depth Measurement<br />
<br />
|<br />
?<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Where in DB?<br />
<br />
|-<br />
|<br />
3/5<br />
<br />
|<br />
Sensor Offset to Keel<br />
<br />
|<br />
6/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/6<br />
<br />
|<br />
Producer of Depth Sensor<br />
<br />
|<br />
63/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/7<br />
<br />
|<br />
Device Model<br />
<br />
|<br />
40/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
58 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
51 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/3<br />
<br />
|<br />
Position abbove Waterline<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/4<br />
<br />
|<br />
Producer<br />
<br />
|<br />
77/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/5<br />
<br />
|<br />
Model<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|}<br />
<br />
= Data Preprocessing =<br />
<br />
== Data Condition ==<br />
Raw data is usually erronous and must be corrected<br />
<br />
=== Internal data problems ===<br />
Depth data may be affected by electrical conditions and software implementations<br />
* Data is incomplete and fail their checksum (bus errors from physical transmissions errors)<br />
* Data is retrived out of sequence<br />
* Data is erronous sensor data <br />
** Approximate correctable data i.e. invalid GPS position that may be interpolated<br />
** Uncorrectable data i.e. failed log sensor that shows slow speeds<br />
* Data resolution is low i.e. for energy saving purposes GPS position is updated every 10 seconds instead of every second<br />
* Sensor data is actively miscalibrated i.e. charter companies add additional draft to the sensor depth for safety reasons<br />
<br />
=== External data problems ===<br />
Depth data may be affected by different environmental circumstances <br />
*# The water temperature affects the ultrasound echo. An inhomogen water temperature yields unwanted echos<br />
*# The seabed affects the ultrasound echo<br />
*# The seastate affects the measurement. There even may be waves when there is no wind.<br />
*# Waves may affect the roll of the measuring vessel resulting in steep measurements that are invalid.<br />
*# The sounder sensor is not the position of the GPS antenna. A position offset including heading must be incorporated.<br />
*# The time of the measurement need not correlate with the time the position was received. This may even happen due to processing time of the hard or software.<br />
*# Corrections for tide induced water levels must happen<br />
<br />
Solutions probably are<br />
*# Water temperature may be measure from the sensor, other data may be unavailable<br />
*# Modern sidescan sonar may yield information about the seabed through classifications<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# Position offsets must be provided by the user<br />
*# Time outages may be handled by the filter if precise timestamps are available in recorded data<br />
*# LAT to Mean sea level differences may be calculated from DTU10 worldwide, river gauges need to monitored<br />
<br />
[[Datei:LAT2MSLDiff.png]]<br />
<br />
<br />
== Data Condition Examples / Showcases ==<br />
<br />
=== Missing measurments (Position) ===<br />
Distribution for position updates taken from an example dataset. Left column shows the time between two consecutive measurements, right column shows how many measurements had this time update.<br />
One can see from the distribtion that the sensor is updated every second but many measurements are one or more seconds late.<br />
21 seconds with no position update may result in an instability of the subsequent filter.<br />
<pre><br />
MeasuredPosition3D<br />
GP<br />
0 :4285<br />
1000 :11295<br />
2000 :5056<br />
3000 :2134<br />
4000 :1135<br />
5000 :315<br />
6000 :154<br />
7000 :46<br />
8000 :36<br />
9000 :16<br />
10000 :12<br />
11000 :3<br />
12000 :4<br />
13000 :1<br />
14000 :7<br />
15000 :3<br />
16000 :1<br />
21000 :1<br />
</pre><br />
<br />
=== Missing measurments (Position) with erronous clock ===<br />
This example is at a 10 second position update rate. However the measurment time is faulty causing large negative and positive update rates. The clock jumps by +- one year/month/day/hour. One can further see from the many 0 time measurements that the rate at which data is sent to the nmea bus is higher than the actual position update (data is sent every second, a position update is every 10 seconds)<br />
<pre><br />
MeasuredPosition3D<br />
II<br />
-21340000 :1<br />
-13194000 :1<br />
-7998000 :1<br />
-2674000 :1<br />
-2434000 :1<br />
-2402000 :1<br />
-2030000 :1<br />
-1926000 :1<br />
-1894000 :1<br />
-1806000 :1<br />
-1480000 :1<br />
-1430000 :1<br />
-1382000 :1<br />
-1114000 :1<br />
-814000 :1<br />
-634000 :1<br />
-590000 :1<br />
-546000 :1<br />
-470000 :1<br />
-290000 :1<br />
-230000 :1<br />
-198000 :1<br />
-110000 :1<br />
-94000 :2<br />
0 :182200<br />
5000 :1<br />
10000 :20230<br />
15000 :1<br />
20000 :84<br />
50000 :1<br />
114000 :2<br />
130000 :2<br />
218000 :1<br />
250000 :1<br />
310000 :1<br />
490000 :1<br />
566000 :1<br />
610000 :1<br />
654000 :1<br />
834000 :1<br />
1134000 :1<br />
1402000 :1<br />
1450000 :1</pre><br />
<br />
== Solution Proposal ==<br />
<br />
=== Outline ===<br />
The ship is influenced by the outlined environment which can be observed. Naturally what is observed is not the state of the<br />
ship as i.e. the position if taken from GPS is 95% less than 10m accurate. To improve quality an estimation of the true state yields better results if this noise taken into account properly.<br />
<br />
=== Details ===<br />
The ship moves according to physical laws. For the easist case imagine a ship with constant velocity and direction. For any point in time you can tell where the ship is with easy math. Considering the full blown setup a ships movement is affected by many parameters such as wind speed, water current, waves, tide, and many more. The ship moves also triaxial in a dynamic way in itself (roll, pitch, yaw). Heeling even changes the measurement position with respect to the depth position. In terms of a filter this is called a system model that describes how the state of the ship may change. Given such a state you can measure what your sensor readings are and compare that to where the system thinks you are.<br />
<br />
The [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter] is known to be the best linear estimator for such situations. Unfortunately the system model is not linear which is why the Extended Kalman Filter needs to be used in order to linearize the system at hand.<br />
<br />
Todo:<br />
* Construct ship system model with at least the position state and probably its course and speed or even more (depth)<br />
* Estimate the system variance (This is a hard one, proposals welcome)<br />
* Construct the measurement model according to the data available (GPS, Log)<br />
* Estimate the measurement noise according to specifc sensors (DPGS is more accurate than GPS)<br />
<br />
The estimation with the position and depth can be retrieved and stored in a database.<br />
<br />
Pitfalls:<br />
* If the system noise is badly chosen the estimation of the system state does not converge to the true state / measurement.<br />
* If the system is very detailed the system variance can be reduced. The required cpu time for processing increases<br />
<br />
Benefits:<br />
* Having the best estimation of the true position even if measurements are noisy<br />
* Easy and effective algorithmic processing<br />
<br />
== Analysis == <br />
<br />
=== Data Sets ===<br />
Currently two test data sets are available recorded during trips from Mallorca and the Baltic Sea.<br />
In terms of data quality the Mallorca data shows many challenges. <br />
* The minimum recommended sentences from NMEA showed up with false date and time readings while having correct (!!!) message checksums. <br />
* The log on the ship was defective and delivered no readings from time to time. <br />
* The same holds true for the water temperature.<br />
* The GPS positions relatively imprecise because some last decimal digits are missing in the recordings.<br />
* The GPS positions are updated every 10 seconds while other sensor readings update almost every second.<br />
* The GPS position are sometimes way off due to false readings<br />
<br />
The Baltic Sea data set is a little bit better<br />
* Only a single day is available<br />
* GPS positions are updated every second<br />
<br />
One problem with the data is that there is time available when sensor readings were recorded. This yields problems to the filter algorithm.<br />
<br />
<br />
=== Filter Algorithm ===<br />
At first the Extended Kalman Filter is being analyzed. Using an apache implementation with the available data the filter quickly throw an exception that<br />
a matrix is not invertible because of numeric instabilities. When removing this exception the filter seems to work but the removal and its effects have yet to be analyzed.<br />
Literature suggest that a fixed interval smoother may yield better results in case of offline data processing. As it is an extension to the existing kalman filter<br />
we may consider that for the future.<br />
<br />
One problem are the different update rates of the sensors. As GPS may deliver positions at 0.1Hz speed is updated at 1Hz. Literature suggests that<br />
the missing measurements shell be modelled as a random variable with the standard deviation of the sensor. It may even be possible to update covariance matrices only partially with the sensor readings received. Input for the best solution may be formulated on the developer mailing list.<br />
<br />
== Results == <br />
A prototype implementation is shown in the following screenshots. An Extended Kalman Filter is being used. It has the position<br />
and the current bearing and velocity as system state. The input is the measurement of these four observables. The system function is<br />
good old pythagoras. In a first implementation I tried to use orthodrome distances but the system function is not differentiable which is a requirement of the Extended Kalman Filter (due to acrtan2). For small distances pythagoras should be sufficiently accurate. <br />
The initial state is taken from the first measurement for convergence reasons.<br />
<br />
The following gallery shows the results. <br />
* You can see the bad position resolution and an outlier in the first screenshot.<br />
* The second shows the same data overlaid with the applied filter. The outlier is gone and the resolution has improved.<br />
* The third screenshot shows data from a different GPS sensor with more precision (not DGPS) versus the filtered data.<br />
<br />
This of course is just a preliminary test and many setups need to be considered to make it work for most datasets.<br />
<br />
<gallery><br />
UnfilteredNMEA.png | Unfiltered GPS data<br />
FilteredNMEAVsOriginal.png | Unfiltered GPS data and Filtered GPS data<br />
PreciseGPSvsFilter.png | Another precise GPS vs Filtered GPS data<br />
</gallery><br />
<br />
The overall process even gives an estimation of the current error which is a capability of the [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter].<br />
This way positional inaccuracies may be added to the overall depth measurement inaccuracy.<br />
<br />
== Quality rating ==<br />
<br />
Each record (time, positon, depth) should become a quality rating.<br />
<br />
=== Points ===<br />
<br />
Derived from the Fibonacci series.<br />
<br />
{| class="wikitable"<br />
! Point || Description<br />
|-<br />
| 1 || extra small improvement<br />
|-<br />
| 2 || small improvement<br />
|-<br />
| 3 || medium improvement<br />
|-<br />
| 5 || large improvement<br />
|-<br />
| 8 || extra large improvement<br />
|}<br />
<br />
=== Factors ===<br />
<br />
{| class="wikitable"<br />
! style="width:15%" | Name<br />
! style="width:17%" | Factor<br />
! style="width:68%" | Description<br />
|-<br />
| depth offset || 8 (extra large) || The difference between the depth measured by the echo sounder and the depth (waterline) measured by hand.<br />
|-<br />
| device distance || 3 (medium) || The distance between gps antenna and echo sounder (lengthwise and crosswise).<br />
|-<br />
| SBAS || 3 (medium) || Satellite based augmentation system (WAAS, EGNOS, MSAS) which allows to correct the gps position.<br />
|-<br />
| position interpolation || 2 (small improvement) || Arrival of depth and position packets can have a time difference. It is/should be possible to interpolate the position.<br />
|}<br />
<br />
= Depth Rendering =<br />
<br />
= Siehe auch =<br />
* [[De:Bordnetz|Bordnetz]]<br />
* [[De:NMEA-Logger_anschliessen|NMEA-Logger_anschliessen]]<br />
* [http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCkQFjAA&url=http%3A%2F%2Fwww.dei.unipd.it%2F~chiuso%2FDOWNLOAD%2FPositioning_Heading_Kalman.pdf&ei=sSWNUMWnL4eC4gTRlYHAAw&usg=AFQjCNHq5V-PePNmDTZaGYvq0JeQFgqHVw Kalman Filtering for Positioning and Heading Control of Ships and Offshore Rigs]<br />
* [http://users.isr.ist.utl.pt/~pedro/publications/CAMS10.pdf A Multiple Model Adaptive Wave Filter for Dynamic Ship Positioning]<br />
* [http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4449205&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4449205 Echosounder Depth Tracking with the Extended Kalman Filter]</div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:En:Depth_Data&diff=2963OpenSeaMap-dev:En:Depth Data2014-09-27T18:04:28Z<p>MartinOver: /* Baltic Sea Olpenitz (Germany) */</p>
<hr />
<div>This Page describes the necessary efforts to retrieve and analyze depth data as well as create renderings from it<br />
<br />
= Data Aquisition =<br />
Depth data can be retrieved from public domain sources or from crowd sourced data.<br />
<br />
== GEBCO ==<br />
DIe Daten sind gerendert und stehen als Layer zur Verfügung:<br />
{| class="wikitable"<br />
! Zoom || Inhalt<br />
|-<br />
| 0..10 || Blaustufen und Schattierung<br />
|-<br />
| 11..18 || beschriftete Tiefenlinien, Blaustufen und Schattierung<br />
|}<br />
<br />
Noch zu lösende Probleme:<br />
* der GEBCO-Layer erzeugt einen milchigen Schleier über der Basiskarte<br />
* Tiefenlinien sind ab z=14 etwas grob (also ab da, wo dann die Flachwassertiefen beginnen) [http://map.openseamap.org/?zoom=14&lat=36.03097&lon=-5.49153&layers=BFTFTTTFFFF0 Karte]<br />
* Überschneidungen von 100m-Linie und Küstenlinie [http://map.openseamap.org/?zoom=15&lat=36.00318&lon=-5.60819&layers=BFFFTTTFFFF0FFFFF Karte]<br />
* Steilküsten (Cuba) [http://map.openseamap.org/?zoom=14&lat=19.94808&lon=-76.04289&layers=BFTFTTTFFFF0 Karte]<br />
<br />
== Crowd Sourced Data ==<br />
Crowd sourced data may be gathered by YOU. There are two options in development. A hardware and a software option.<br />
<br />
=== Workflow ===<br />
[[Datei:Workflow_depth.png]]<br />
<br />
Here you can find the document with the previous thoughts about the workflow:<br />
[http://osm.franken.de/wiki/FWT-Projekt%C3%BCbersicht-NMEA2Contours_2.1.ppt PPT Dokument]<br />
<br />
=== Hardware logger ===<br />
We are currently developing a hardware logger that may easily be plugged to the ship's network in order to log the networks data to a SD card.<br />
That data may then be uploaded by plugging the SD card to a normal computer with internet connection for upload.<br />
The main goal is to support NMEA 0183 data with options for NMEA 2000.<br />
<br />
=== Software logger ===<br />
A [[Software logger]] is in development and [http://seesea.sourceforge.net/datalogger/index.html can be downloaded here]. <br />
<br />
It currently supports: <br />
: Bluetooth <br />
: Serial ports<br />
: Internet Protocol (IP)<br />
It processes NMEA 0183 and AIS data.<br />
<br />
For vendor specific protocols such as SeaTalk 1 you have to use a [[De:NMEA-Logger_anschliessen|converter]] to NMEA 0183 data.<br />
<br />
NMEA 2000 support is only available if data is transcoded to NMEA 0183 by a converter.<br />
<br />
=== Chart Plotters ===<br />
<br />
Some chart plotters are able to save tracks out-of-the-box, e.g. several Raymarine (FSH files) and Humminbird (SON files) devices. Those files may directly be used as data source.<br />
<br />
<br />
=== Upload Process ===<br />
Uploading data is possible through using the [http://seesea.sourceforge.net/datalogger/index.html OpenSeaMap Data Logger Software] or via [http://depth.openseamap.org/ Web Interface].<br />
The system is currently being tested. <br />
<br />
[[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|You'll find further information here]].<br />
<br />
=== Test Data ===<br />
<br />
<br />
==== Brombachsee (Germany)====<br />
<br />
Test data for Openseamap: [http://osm.franken.de/wiki/test_data_brombachsee.zip Brombachsee_Test_Data]<br />
<br />
dgm_brombachsee.tif: Digital Elevation Model of the sea derived from height lines WWA (C).<br />
<br />
shapes_brombachsee.shp: Shape File derived from 4 NMEA Tracks. "dbs" is the original Sounding and "deep_cor" the depth after a correction (gauge levl).<br />
<br />
gpx_brombachsee.gpx: ele = "dbs" from the Shape File<br />
<br />
[[Datei:Brombachsee.png]]<br />
Resulting Digital Elevation Model<br />
<br />
==== Baltic Sea - near Großenbrode (Germany)====<br />
<br />
First results with an RMS error < 1,5 meter compared to an official dataset of the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].<br />
<br />
[[Datei: Bsh_results_overview.jpg]]<br />
<br />
[Picture 1] '''''OSM map in background, raster Depth Model derived from BSH data and crowed sourced OpenSeaMap Points - Overview'''''<br />
<br />
Blue = flat BSH data, red = deep BSH data.<br />
<br>Blue points = OpenSeaMap raw measuring points.<br />
<br />
{| class="wikitable"<br />
|-<br />
| n || 5062<br />
|-<br />
|-<br />
| datasets || 21<br />
|-<br />
| max deviation || 3,43 meters<br />
|-<br />
| mean (abs) || 0,69 meters<br />
|-<br />
| RMS +/- || 0,91 meters<br />
|}<br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| VesselConfig ID || 68<br />
|-<br />
| Manufacturer || Bavaria Yachtbau<br />
|-<br />
| Model || B32<br />
|-<br />
| Length || 10,0 meters<br />
|-<br />
| Beam || 3,35 meters<br />
|-<br />
| Draft || 1,6 meters<br />
|-<br />
| Height || 14 meters<br />
|-<br />
| Displacement || 4,2 t<br />
|-<br />
| Sensor manufacturer || Raymarine<br />
|-<br />
| Sensor Offset to waterline || 0,45 meters<br />
|-<br />
| Sensor Offset to keel || 1,15 meters<br />
|}<br />
<br />
<br />
<br />
A digital Deep Model raster was computed from the BSH point dataset (c).<br />
The depth of the crowed sourced dataset was compared to the derived raster dataset from the BSH.<br />
The raw crowed sourced dataset was corrected by the sensor offset (0,45 meters).<br />
<br />
[[Datei: Scatter_cor_sensor.jpeg]]<br />
<br />
[Picture 2] '''''Scatter plot: BSH data on the x-axis and the crowed sourced data on the y-axis. Trend line in black and optimal line in red.'''''<br />
<br />
The deviation from the reference dataset increases with the depth measured.<br />
<br />
As you see in the picture below the difference between the datasets has an regular pattern maybe deepending on waves.<br />
<br />
[[Datei: Bsh_results_detail_10_classes.jpg]]<br />
<br />
[Picture 3] '''''Crowed sourced OpenSeaMap track points and the difference from the BSH dataset'''''<br />
<br />
White = low difference, orange = medium difference, red = strong difference<br />
<br />
Download of the data http://osm.franken.de/data/baltic_sea_test_data.zip<br />
'''Be aware of the copyright from the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].'''<br />
The data in the dataset is not corrected by sensor offset.<br />
<br />
==== Baltic Sea Olpenitz (Germany)====<br />
<br />
In the test area were tracks from two different vessel configurations. <br />
The fist one was the one from the test area Großenbrode (config ID 68).<br />
<br />
In the Table below the settings for die vesselconfigid 110 are shown: <br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| VesselConfigId || 110<br />
|-<br />
| Manufacturer || Waarschip<br />
|-<br />
| Model || 570<br />
|-<br />
| Length || 5,7 meters<br />
|-<br />
| Beam || 2,45 meters<br />
|-<br />
| Draft || 1,0 meters<br />
|-<br />
| Height || 9.1 meters<br />
|-<br />
| Displacement || 0,8 t<br />
|-<br />
| Sensor manufacturer || Tacktick/ Airmar<br />
|-<br />
| Sensor Model || T912<br />
|-<br />
| Sensor Offset to waterline || 0,2 meters<br />
|-<br />
| Sensor Offset to keel || 0,45 meters<br />
|}<br />
<br />
[[Datei: Balitc_sea_scatter_plot_2.jpeg]]<br />
<br />
[Picture 1] Scatterplot for vesselconfigID 110. Trendline in Black and optimal line in red.<br />
<br />
=== Meta Data Statistics ===<br />
<br />
Statistics for the metadata entrees with some personal comments (by MartinOver). Stand 20.9.2014.<br />
<br />
{| class="prettytable"<br />
|-<br />
|<br />
'''Step'''<br />
<br />
|<br />
'''Topic'''<br />
<br />
|<br />
'''Count'''<br />
<br />
|<br />
'''State'''<br />
<br />
|<br />
'''Comment'''<br />
<br />
|-<br />
|<br />
1/1<br />
<br />
|<br />
Name<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
1/2<br />
<br />
|<br />
Description<br />
<br />
|<br />
76/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/1<br />
<br />
|<br />
Length<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
Some wrong entrees like mail addresses or comments <br />
<br />
24 “0.00” Values<br />
<br />
|-<br />
|<br />
2/2<br />
<br />
|<br />
Beam<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
37 „0.00“ Values<br />
<br />
|-<br />
|<br />
2/3<br />
<br />
|<br />
Draft<br />
<br />
|<br />
79/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/4<br />
<br />
|<br />
Displacement<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/5<br />
<br />
|<br />
Height<br />
<br />
|<br />
78/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/6<br />
<br />
|<br />
Manufacturer<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Model<br />
<br />
|<br />
49/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Type<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/3<br />
<br />
|<br />
Position below Waterline<br />
<br />
|<br />
57/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Should be Obligatory<br />
<br />
|-<br />
|<br />
3/4<br />
<br />
|<br />
Depth Measurement<br />
<br />
|<br />
?<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Where in DB?<br />
<br />
|-<br />
|<br />
3/5<br />
<br />
|<br />
Sensor Offset to Keel<br />
<br />
|<br />
6/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/6<br />
<br />
|<br />
Producer of Depth Sensor<br />
<br />
|<br />
63/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/7<br />
<br />
|<br />
Device Model<br />
<br />
|<br />
40/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
58 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
51 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/3<br />
<br />
|<br />
Position abbove Waterline<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/4<br />
<br />
|<br />
Producer<br />
<br />
|<br />
77/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/5<br />
<br />
|<br />
Model<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|}<br />
<br />
= Data Preprocessing =<br />
<br />
== Data Condition ==<br />
Raw data is usually erronous and must be corrected<br />
<br />
=== Internal data problems ===<br />
Depth data may be affected by electrical conditions and software implementations<br />
* Data is incomplete and fail their checksum (bus errors from physical transmissions errors)<br />
* Data is retrived out of sequence<br />
* Data is erronous sensor data <br />
** Approximate correctable data i.e. invalid GPS position that may be interpolated<br />
** Uncorrectable data i.e. failed log sensor that shows slow speeds<br />
* Data resolution is low i.e. for energy saving purposes GPS position is updated every 10 seconds instead of every second<br />
* Sensor data is actively miscalibrated i.e. charter companies add additional draft to the sensor depth for safety reasons<br />
<br />
=== External data problems ===<br />
Depth data may be affected by different environmental circumstances <br />
*# The water temperature affects the ultrasound echo. An inhomogen water temperature yields unwanted echos<br />
*# The seabed affects the ultrasound echo<br />
*# The seastate affects the measurement. There even may be waves when there is no wind.<br />
*# Waves may affect the roll of the measuring vessel resulting in steep measurements that are invalid.<br />
*# The sounder sensor is not the position of the GPS antenna. A position offset including heading must be incorporated.<br />
*# The time of the measurement need not correlate with the time the position was received. This may even happen due to processing time of the hard or software.<br />
*# Corrections for tide induced water levels must happen<br />
<br />
Solutions probably are<br />
*# Water temperature may be measure from the sensor, other data may be unavailable<br />
*# Modern sidescan sonar may yield information about the seabed through classifications<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# Position offsets must be provided by the user<br />
*# Time outages may be handled by the filter if precise timestamps are available in recorded data<br />
*# LAT to Mean sea level differences may be calculated from DTU10 worldwide, river gauges need to monitored<br />
<br />
[[Datei:LAT2MSLDiff.png]]<br />
<br />
<br />
== Data Condition Examples / Showcases ==<br />
<br />
=== Missing measurments (Position) ===<br />
Distribution for position updates taken from an example dataset. Left column shows the time between two consecutive measurements, right column shows how many measurements had this time update.<br />
One can see from the distribtion that the sensor is updated every second but many measurements are one or more seconds late.<br />
21 seconds with no position update may result in an instability of the subsequent filter.<br />
<pre><br />
MeasuredPosition3D<br />
GP<br />
0 :4285<br />
1000 :11295<br />
2000 :5056<br />
3000 :2134<br />
4000 :1135<br />
5000 :315<br />
6000 :154<br />
7000 :46<br />
8000 :36<br />
9000 :16<br />
10000 :12<br />
11000 :3<br />
12000 :4<br />
13000 :1<br />
14000 :7<br />
15000 :3<br />
16000 :1<br />
21000 :1<br />
</pre><br />
<br />
=== Missing measurments (Position) with erronous clock ===<br />
This example is at a 10 second position update rate. However the measurment time is faulty causing large negative and positive update rates. The clock jumps by +- one year/month/day/hour. One can further see from the many 0 time measurements that the rate at which data is sent to the nmea bus is higher than the actual position update (data is sent every second, a position update is every 10 seconds)<br />
<pre><br />
MeasuredPosition3D<br />
II<br />
-21340000 :1<br />
-13194000 :1<br />
-7998000 :1<br />
-2674000 :1<br />
-2434000 :1<br />
-2402000 :1<br />
-2030000 :1<br />
-1926000 :1<br />
-1894000 :1<br />
-1806000 :1<br />
-1480000 :1<br />
-1430000 :1<br />
-1382000 :1<br />
-1114000 :1<br />
-814000 :1<br />
-634000 :1<br />
-590000 :1<br />
-546000 :1<br />
-470000 :1<br />
-290000 :1<br />
-230000 :1<br />
-198000 :1<br />
-110000 :1<br />
-94000 :2<br />
0 :182200<br />
5000 :1<br />
10000 :20230<br />
15000 :1<br />
20000 :84<br />
50000 :1<br />
114000 :2<br />
130000 :2<br />
218000 :1<br />
250000 :1<br />
310000 :1<br />
490000 :1<br />
566000 :1<br />
610000 :1<br />
654000 :1<br />
834000 :1<br />
1134000 :1<br />
1402000 :1<br />
1450000 :1</pre><br />
<br />
== Solution Proposal ==<br />
<br />
=== Outline ===<br />
The ship is influenced by the outlined environment which can be observed. Naturally what is observed is not the state of the<br />
ship as i.e. the position if taken from GPS is 95% less than 10m accurate. To improve quality an estimation of the true state yields better results if this noise taken into account properly.<br />
<br />
=== Details ===<br />
The ship moves according to physical laws. For the easist case imagine a ship with constant velocity and direction. For any point in time you can tell where the ship is with easy math. Considering the full blown setup a ships movement is affected by many parameters such as wind speed, water current, waves, tide, and many more. The ship moves also triaxial in a dynamic way in itself (roll, pitch, yaw). Heeling even changes the measurement position with respect to the depth position. In terms of a filter this is called a system model that describes how the state of the ship may change. Given such a state you can measure what your sensor readings are and compare that to where the system thinks you are.<br />
<br />
The [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter] is known to be the best linear estimator for such situations. Unfortunately the system model is not linear which is why the Extended Kalman Filter needs to be used in order to linearize the system at hand.<br />
<br />
Todo:<br />
* Construct ship system model with at least the position state and probably its course and speed or even more (depth)<br />
* Estimate the system variance (This is a hard one, proposals welcome)<br />
* Construct the measurement model according to the data available (GPS, Log)<br />
* Estimate the measurement noise according to specifc sensors (DPGS is more accurate than GPS)<br />
<br />
The estimation with the position and depth can be retrieved and stored in a database.<br />
<br />
Pitfalls:<br />
* If the system noise is badly chosen the estimation of the system state does not converge to the true state / measurement.<br />
* If the system is very detailed the system variance can be reduced. The required cpu time for processing increases<br />
<br />
Benefits:<br />
* Having the best estimation of the true position even if measurements are noisy<br />
* Easy and effective algorithmic processing<br />
<br />
== Analysis == <br />
<br />
=== Data Sets ===<br />
Currently two test data sets are available recorded during trips from Mallorca and the Baltic Sea.<br />
In terms of data quality the Mallorca data shows many challenges. <br />
* The minimum recommended sentences from NMEA showed up with false date and time readings while having correct (!!!) message checksums. <br />
* The log on the ship was defective and delivered no readings from time to time. <br />
* The same holds true for the water temperature.<br />
* The GPS positions relatively imprecise because some last decimal digits are missing in the recordings.<br />
* The GPS positions are updated every 10 seconds while other sensor readings update almost every second.<br />
* The GPS position are sometimes way off due to false readings<br />
<br />
The Baltic Sea data set is a little bit better<br />
* Only a single day is available<br />
* GPS positions are updated every second<br />
<br />
One problem with the data is that there is time available when sensor readings were recorded. This yields problems to the filter algorithm.<br />
<br />
<br />
=== Filter Algorithm ===<br />
At first the Extended Kalman Filter is being analyzed. Using an apache implementation with the available data the filter quickly throw an exception that<br />
a matrix is not invertible because of numeric instabilities. When removing this exception the filter seems to work but the removal and its effects have yet to be analyzed.<br />
Literature suggest that a fixed interval smoother may yield better results in case of offline data processing. As it is an extension to the existing kalman filter<br />
we may consider that for the future.<br />
<br />
One problem are the different update rates of the sensors. As GPS may deliver positions at 0.1Hz speed is updated at 1Hz. Literature suggests that<br />
the missing measurements shell be modelled as a random variable with the standard deviation of the sensor. It may even be possible to update covariance matrices only partially with the sensor readings received. Input for the best solution may be formulated on the developer mailing list.<br />
<br />
== Results == <br />
A prototype implementation is shown in the following screenshots. An Extended Kalman Filter is being used. It has the position<br />
and the current bearing and velocity as system state. The input is the measurement of these four observables. The system function is<br />
good old pythagoras. In a first implementation I tried to use orthodrome distances but the system function is not differentiable which is a requirement of the Extended Kalman Filter (due to acrtan2). For small distances pythagoras should be sufficiently accurate. <br />
The initial state is taken from the first measurement for convergence reasons.<br />
<br />
The following gallery shows the results. <br />
* You can see the bad position resolution and an outlier in the first screenshot.<br />
* The second shows the same data overlaid with the applied filter. The outlier is gone and the resolution has improved.<br />
* The third screenshot shows data from a different GPS sensor with more precision (not DGPS) versus the filtered data.<br />
<br />
This of course is just a preliminary test and many setups need to be considered to make it work for most datasets.<br />
<br />
<gallery><br />
UnfilteredNMEA.png | Unfiltered GPS data<br />
FilteredNMEAVsOriginal.png | Unfiltered GPS data and Filtered GPS data<br />
PreciseGPSvsFilter.png | Another precise GPS vs Filtered GPS data<br />
</gallery><br />
<br />
The overall process even gives an estimation of the current error which is a capability of the [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter].<br />
This way positional inaccuracies may be added to the overall depth measurement inaccuracy.<br />
<br />
== Quality rating ==<br />
<br />
Each record (time, positon, depth) should become a quality rating.<br />
<br />
=== Points ===<br />
<br />
Derived from the Fibonacci series.<br />
<br />
{| class="wikitable"<br />
! Point || Description<br />
|-<br />
| 1 || extra small improvement<br />
|-<br />
| 2 || small improvement<br />
|-<br />
| 3 || medium improvement<br />
|-<br />
| 5 || large improvement<br />
|-<br />
| 8 || extra large improvement<br />
|}<br />
<br />
=== Factors ===<br />
<br />
{| class="wikitable"<br />
! style="width:15%" | Name<br />
! style="width:17%" | Factor<br />
! style="width:68%" | Description<br />
|-<br />
| depth offset || 8 (extra large) || The difference between the depth measured by the echo sounder and the depth (waterline) measured by hand.<br />
|-<br />
| device distance || 3 (medium) || The distance between gps antenna and echo sounder (lengthwise and crosswise).<br />
|-<br />
| SBAS || 3 (medium) || Satellite based augmentation system (WAAS, EGNOS, MSAS) which allows to correct the gps position.<br />
|-<br />
| position interpolation || 2 (small improvement) || Arrival of depth and position packets can have a time difference. It is/should be possible to interpolate the position.<br />
|}<br />
<br />
= Depth Rendering =<br />
<br />
= Siehe auch =<br />
* [[De:Bordnetz|Bordnetz]]<br />
* [[De:NMEA-Logger_anschliessen|NMEA-Logger_anschliessen]]<br />
* [http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCkQFjAA&url=http%3A%2F%2Fwww.dei.unipd.it%2F~chiuso%2FDOWNLOAD%2FPositioning_Heading_Kalman.pdf&ei=sSWNUMWnL4eC4gTRlYHAAw&usg=AFQjCNHq5V-PePNmDTZaGYvq0JeQFgqHVw Kalman Filtering for Positioning and Heading Control of Ships and Offshore Rigs]<br />
* [http://users.isr.ist.utl.pt/~pedro/publications/CAMS10.pdf A Multiple Model Adaptive Wave Filter for Dynamic Ship Positioning]<br />
* [http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4449205&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4449205 Echosounder Depth Tracking with the Extended Kalman Filter]</div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:En:Depth_Data&diff=2962OpenSeaMap-dev:En:Depth Data2014-09-27T18:02:43Z<p>MartinOver: /* Baltic Sea Olpenitz (Germany) */</p>
<hr />
<div>This Page describes the necessary efforts to retrieve and analyze depth data as well as create renderings from it<br />
<br />
= Data Aquisition =<br />
Depth data can be retrieved from public domain sources or from crowd sourced data.<br />
<br />
== GEBCO ==<br />
DIe Daten sind gerendert und stehen als Layer zur Verfügung:<br />
{| class="wikitable"<br />
! Zoom || Inhalt<br />
|-<br />
| 0..10 || Blaustufen und Schattierung<br />
|-<br />
| 11..18 || beschriftete Tiefenlinien, Blaustufen und Schattierung<br />
|}<br />
<br />
Noch zu lösende Probleme:<br />
* der GEBCO-Layer erzeugt einen milchigen Schleier über der Basiskarte<br />
* Tiefenlinien sind ab z=14 etwas grob (also ab da, wo dann die Flachwassertiefen beginnen) [http://map.openseamap.org/?zoom=14&lat=36.03097&lon=-5.49153&layers=BFTFTTTFFFF0 Karte]<br />
* Überschneidungen von 100m-Linie und Küstenlinie [http://map.openseamap.org/?zoom=15&lat=36.00318&lon=-5.60819&layers=BFFFTTTFFFF0FFFFF Karte]<br />
* Steilküsten (Cuba) [http://map.openseamap.org/?zoom=14&lat=19.94808&lon=-76.04289&layers=BFTFTTTFFFF0 Karte]<br />
<br />
== Crowd Sourced Data ==<br />
Crowd sourced data may be gathered by YOU. There are two options in development. A hardware and a software option.<br />
<br />
=== Workflow ===<br />
[[Datei:Workflow_depth.png]]<br />
<br />
Here you can find the document with the previous thoughts about the workflow:<br />
[http://osm.franken.de/wiki/FWT-Projekt%C3%BCbersicht-NMEA2Contours_2.1.ppt PPT Dokument]<br />
<br />
=== Hardware logger ===<br />
We are currently developing a hardware logger that may easily be plugged to the ship's network in order to log the networks data to a SD card.<br />
That data may then be uploaded by plugging the SD card to a normal computer with internet connection for upload.<br />
The main goal is to support NMEA 0183 data with options for NMEA 2000.<br />
<br />
=== Software logger ===<br />
A [[Software logger]] is in development and [http://seesea.sourceforge.net/datalogger/index.html can be downloaded here]. <br />
<br />
It currently supports: <br />
: Bluetooth <br />
: Serial ports<br />
: Internet Protocol (IP)<br />
It processes NMEA 0183 and AIS data.<br />
<br />
For vendor specific protocols such as SeaTalk 1 you have to use a [[De:NMEA-Logger_anschliessen|converter]] to NMEA 0183 data.<br />
<br />
NMEA 2000 support is only available if data is transcoded to NMEA 0183 by a converter.<br />
<br />
=== Chart Plotters ===<br />
<br />
Some chart plotters are able to save tracks out-of-the-box, e.g. several Raymarine (FSH files) and Humminbird (SON files) devices. Those files may directly be used as data source.<br />
<br />
<br />
=== Upload Process ===<br />
Uploading data is possible through using the [http://seesea.sourceforge.net/datalogger/index.html OpenSeaMap Data Logger Software] or via [http://depth.openseamap.org/ Web Interface].<br />
The system is currently being tested. <br />
<br />
[[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|You'll find further information here]].<br />
<br />
=== Test Data ===<br />
<br />
<br />
==== Brombachsee (Germany)====<br />
<br />
Test data for Openseamap: [http://osm.franken.de/wiki/test_data_brombachsee.zip Brombachsee_Test_Data]<br />
<br />
dgm_brombachsee.tif: Digital Elevation Model of the sea derived from height lines WWA (C).<br />
<br />
shapes_brombachsee.shp: Shape File derived from 4 NMEA Tracks. "dbs" is the original Sounding and "deep_cor" the depth after a correction (gauge levl).<br />
<br />
gpx_brombachsee.gpx: ele = "dbs" from the Shape File<br />
<br />
[[Datei:Brombachsee.png]]<br />
Resulting Digital Elevation Model<br />
<br />
==== Baltic Sea - near Großenbrode (Germany)====<br />
<br />
First results with an RMS error < 1,5 meter compared to an official dataset of the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].<br />
<br />
[[Datei: Bsh_results_overview.jpg]]<br />
<br />
[Picture 1] '''''OSM map in background, raster Depth Model derived from BSH data and crowed sourced OpenSeaMap Points - Overview'''''<br />
<br />
Blue = flat BSH data, red = deep BSH data.<br />
<br>Blue points = OpenSeaMap raw measuring points.<br />
<br />
{| class="wikitable"<br />
|-<br />
| n || 5062<br />
|-<br />
|-<br />
| datasets || 21<br />
|-<br />
| max deviation || 3,43 meters<br />
|-<br />
| mean (abs) || 0,69 meters<br />
|-<br />
| RMS +/- || 0,91 meters<br />
|}<br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| VesselConfig ID || 68<br />
|-<br />
| Manufacturer || Bavaria Yachtbau<br />
|-<br />
| Model || B32<br />
|-<br />
| Length || 10,0 meters<br />
|-<br />
| Beam || 3,35 meters<br />
|-<br />
| Draft || 1,6 meters<br />
|-<br />
| Height || 14 meters<br />
|-<br />
| Displacement || 4,2 t<br />
|-<br />
| Sensor manufacturer || Raymarine<br />
|-<br />
| Sensor Offset to waterline || 0,45 meters<br />
|-<br />
| Sensor Offset to keel || 1,15 meters<br />
|}<br />
<br />
<br />
<br />
A digital Deep Model raster was computed from the BSH point dataset (c).<br />
The depth of the crowed sourced dataset was compared to the derived raster dataset from the BSH.<br />
The raw crowed sourced dataset was corrected by the sensor offset (0,45 meters).<br />
<br />
[[Datei: Scatter_cor_sensor.jpeg]]<br />
<br />
[Picture 2] '''''Scatter plot: BSH data on the x-axis and the crowed sourced data on the y-axis. Trend line in black and optimal line in red.'''''<br />
<br />
The deviation from the reference dataset increases with the depth measured.<br />
<br />
As you see in the picture below the difference between the datasets has an regular pattern maybe deepending on waves.<br />
<br />
[[Datei: Bsh_results_detail_10_classes.jpg]]<br />
<br />
[Picture 3] '''''Crowed sourced OpenSeaMap track points and the difference from the BSH dataset'''''<br />
<br />
White = low difference, orange = medium difference, red = strong difference<br />
<br />
Download of the data http://osm.franken.de/data/baltic_sea_test_data.zip<br />
'''Be aware of the copyright from the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].'''<br />
The data in the dataset is not corrected by sensor offset.<br />
<br />
==== Baltic Sea Olpenitz (Germany)====<br />
<br />
In the test area were tracks from two different vessel configurations. <br />
The fist one was the one from the test area Großenbrode (config ID 68).<br />
<br />
In the Table below the settings for die vesselconfigid 110 are shown: <br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| VesselConfigId || 110<br />
|-<br />
| Manufacturer || Waarschip<br />
|-<br />
| Model || 570<br />
|-<br />
| Length || 5,7 meters<br />
|-<br />
| Beam || 2,45 meters<br />
|-<br />
| Draft || 1,0 meters<br />
|-<br />
| Height || 9.1 meters<br />
|-<br />
| Displacement || 0,8 t<br />
|-<br />
| Sensor manufacturer || Tacktick/ Airmar<br />
|-<br />
| Sensor Model || T912<br />
|-<br />
| Sensor Offset to waterline || 0,2 meters<br />
|-<br />
| Sensor Offset to keel || 0,45 meters<br />
|}<br />
<br />
[[Datei: Balitc_sea_scatter_plot_2.jpeg]]<br />
<br />
=== Meta Data Statistics ===<br />
<br />
Statistics for the metadata entrees with some personal comments (by MartinOver). Stand 20.9.2014.<br />
<br />
{| class="prettytable"<br />
|-<br />
|<br />
'''Step'''<br />
<br />
|<br />
'''Topic'''<br />
<br />
|<br />
'''Count'''<br />
<br />
|<br />
'''State'''<br />
<br />
|<br />
'''Comment'''<br />
<br />
|-<br />
|<br />
1/1<br />
<br />
|<br />
Name<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
1/2<br />
<br />
|<br />
Description<br />
<br />
|<br />
76/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/1<br />
<br />
|<br />
Length<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
Some wrong entrees like mail addresses or comments <br />
<br />
24 “0.00” Values<br />
<br />
|-<br />
|<br />
2/2<br />
<br />
|<br />
Beam<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
37 „0.00“ Values<br />
<br />
|-<br />
|<br />
2/3<br />
<br />
|<br />
Draft<br />
<br />
|<br />
79/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/4<br />
<br />
|<br />
Displacement<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/5<br />
<br />
|<br />
Height<br />
<br />
|<br />
78/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/6<br />
<br />
|<br />
Manufacturer<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Model<br />
<br />
|<br />
49/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Type<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/3<br />
<br />
|<br />
Position below Waterline<br />
<br />
|<br />
57/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Should be Obligatory<br />
<br />
|-<br />
|<br />
3/4<br />
<br />
|<br />
Depth Measurement<br />
<br />
|<br />
?<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Where in DB?<br />
<br />
|-<br />
|<br />
3/5<br />
<br />
|<br />
Sensor Offset to Keel<br />
<br />
|<br />
6/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/6<br />
<br />
|<br />
Producer of Depth Sensor<br />
<br />
|<br />
63/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/7<br />
<br />
|<br />
Device Model<br />
<br />
|<br />
40/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
58 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
51 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/3<br />
<br />
|<br />
Position abbove Waterline<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/4<br />
<br />
|<br />
Producer<br />
<br />
|<br />
77/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/5<br />
<br />
|<br />
Model<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|}<br />
<br />
= Data Preprocessing =<br />
<br />
== Data Condition ==<br />
Raw data is usually erronous and must be corrected<br />
<br />
=== Internal data problems ===<br />
Depth data may be affected by electrical conditions and software implementations<br />
* Data is incomplete and fail their checksum (bus errors from physical transmissions errors)<br />
* Data is retrived out of sequence<br />
* Data is erronous sensor data <br />
** Approximate correctable data i.e. invalid GPS position that may be interpolated<br />
** Uncorrectable data i.e. failed log sensor that shows slow speeds<br />
* Data resolution is low i.e. for energy saving purposes GPS position is updated every 10 seconds instead of every second<br />
* Sensor data is actively miscalibrated i.e. charter companies add additional draft to the sensor depth for safety reasons<br />
<br />
=== External data problems ===<br />
Depth data may be affected by different environmental circumstances <br />
*# The water temperature affects the ultrasound echo. An inhomogen water temperature yields unwanted echos<br />
*# The seabed affects the ultrasound echo<br />
*# The seastate affects the measurement. There even may be waves when there is no wind.<br />
*# Waves may affect the roll of the measuring vessel resulting in steep measurements that are invalid.<br />
*# The sounder sensor is not the position of the GPS antenna. A position offset including heading must be incorporated.<br />
*# The time of the measurement need not correlate with the time the position was received. This may even happen due to processing time of the hard or software.<br />
*# Corrections for tide induced water levels must happen<br />
<br />
Solutions probably are<br />
*# Water temperature may be measure from the sensor, other data may be unavailable<br />
*# Modern sidescan sonar may yield information about the seabed through classifications<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# Position offsets must be provided by the user<br />
*# Time outages may be handled by the filter if precise timestamps are available in recorded data<br />
*# LAT to Mean sea level differences may be calculated from DTU10 worldwide, river gauges need to monitored<br />
<br />
[[Datei:LAT2MSLDiff.png]]<br />
<br />
<br />
== Data Condition Examples / Showcases ==<br />
<br />
=== Missing measurments (Position) ===<br />
Distribution for position updates taken from an example dataset. Left column shows the time between two consecutive measurements, right column shows how many measurements had this time update.<br />
One can see from the distribtion that the sensor is updated every second but many measurements are one or more seconds late.<br />
21 seconds with no position update may result in an instability of the subsequent filter.<br />
<pre><br />
MeasuredPosition3D<br />
GP<br />
0 :4285<br />
1000 :11295<br />
2000 :5056<br />
3000 :2134<br />
4000 :1135<br />
5000 :315<br />
6000 :154<br />
7000 :46<br />
8000 :36<br />
9000 :16<br />
10000 :12<br />
11000 :3<br />
12000 :4<br />
13000 :1<br />
14000 :7<br />
15000 :3<br />
16000 :1<br />
21000 :1<br />
</pre><br />
<br />
=== Missing measurments (Position) with erronous clock ===<br />
This example is at a 10 second position update rate. However the measurment time is faulty causing large negative and positive update rates. The clock jumps by +- one year/month/day/hour. One can further see from the many 0 time measurements that the rate at which data is sent to the nmea bus is higher than the actual position update (data is sent every second, a position update is every 10 seconds)<br />
<pre><br />
MeasuredPosition3D<br />
II<br />
-21340000 :1<br />
-13194000 :1<br />
-7998000 :1<br />
-2674000 :1<br />
-2434000 :1<br />
-2402000 :1<br />
-2030000 :1<br />
-1926000 :1<br />
-1894000 :1<br />
-1806000 :1<br />
-1480000 :1<br />
-1430000 :1<br />
-1382000 :1<br />
-1114000 :1<br />
-814000 :1<br />
-634000 :1<br />
-590000 :1<br />
-546000 :1<br />
-470000 :1<br />
-290000 :1<br />
-230000 :1<br />
-198000 :1<br />
-110000 :1<br />
-94000 :2<br />
0 :182200<br />
5000 :1<br />
10000 :20230<br />
15000 :1<br />
20000 :84<br />
50000 :1<br />
114000 :2<br />
130000 :2<br />
218000 :1<br />
250000 :1<br />
310000 :1<br />
490000 :1<br />
566000 :1<br />
610000 :1<br />
654000 :1<br />
834000 :1<br />
1134000 :1<br />
1402000 :1<br />
1450000 :1</pre><br />
<br />
== Solution Proposal ==<br />
<br />
=== Outline ===<br />
The ship is influenced by the outlined environment which can be observed. Naturally what is observed is not the state of the<br />
ship as i.e. the position if taken from GPS is 95% less than 10m accurate. To improve quality an estimation of the true state yields better results if this noise taken into account properly.<br />
<br />
=== Details ===<br />
The ship moves according to physical laws. For the easist case imagine a ship with constant velocity and direction. For any point in time you can tell where the ship is with easy math. Considering the full blown setup a ships movement is affected by many parameters such as wind speed, water current, waves, tide, and many more. The ship moves also triaxial in a dynamic way in itself (roll, pitch, yaw). Heeling even changes the measurement position with respect to the depth position. In terms of a filter this is called a system model that describes how the state of the ship may change. Given such a state you can measure what your sensor readings are and compare that to where the system thinks you are.<br />
<br />
The [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter] is known to be the best linear estimator for such situations. Unfortunately the system model is not linear which is why the Extended Kalman Filter needs to be used in order to linearize the system at hand.<br />
<br />
Todo:<br />
* Construct ship system model with at least the position state and probably its course and speed or even more (depth)<br />
* Estimate the system variance (This is a hard one, proposals welcome)<br />
* Construct the measurement model according to the data available (GPS, Log)<br />
* Estimate the measurement noise according to specifc sensors (DPGS is more accurate than GPS)<br />
<br />
The estimation with the position and depth can be retrieved and stored in a database.<br />
<br />
Pitfalls:<br />
* If the system noise is badly chosen the estimation of the system state does not converge to the true state / measurement.<br />
* If the system is very detailed the system variance can be reduced. The required cpu time for processing increases<br />
<br />
Benefits:<br />
* Having the best estimation of the true position even if measurements are noisy<br />
* Easy and effective algorithmic processing<br />
<br />
== Analysis == <br />
<br />
=== Data Sets ===<br />
Currently two test data sets are available recorded during trips from Mallorca and the Baltic Sea.<br />
In terms of data quality the Mallorca data shows many challenges. <br />
* The minimum recommended sentences from NMEA showed up with false date and time readings while having correct (!!!) message checksums. <br />
* The log on the ship was defective and delivered no readings from time to time. <br />
* The same holds true for the water temperature.<br />
* The GPS positions relatively imprecise because some last decimal digits are missing in the recordings.<br />
* The GPS positions are updated every 10 seconds while other sensor readings update almost every second.<br />
* The GPS position are sometimes way off due to false readings<br />
<br />
The Baltic Sea data set is a little bit better<br />
* Only a single day is available<br />
* GPS positions are updated every second<br />
<br />
One problem with the data is that there is time available when sensor readings were recorded. This yields problems to the filter algorithm.<br />
<br />
<br />
=== Filter Algorithm ===<br />
At first the Extended Kalman Filter is being analyzed. Using an apache implementation with the available data the filter quickly throw an exception that<br />
a matrix is not invertible because of numeric instabilities. When removing this exception the filter seems to work but the removal and its effects have yet to be analyzed.<br />
Literature suggest that a fixed interval smoother may yield better results in case of offline data processing. As it is an extension to the existing kalman filter<br />
we may consider that for the future.<br />
<br />
One problem are the different update rates of the sensors. As GPS may deliver positions at 0.1Hz speed is updated at 1Hz. Literature suggests that<br />
the missing measurements shell be modelled as a random variable with the standard deviation of the sensor. It may even be possible to update covariance matrices only partially with the sensor readings received. Input for the best solution may be formulated on the developer mailing list.<br />
<br />
== Results == <br />
A prototype implementation is shown in the following screenshots. An Extended Kalman Filter is being used. It has the position<br />
and the current bearing and velocity as system state. The input is the measurement of these four observables. The system function is<br />
good old pythagoras. In a first implementation I tried to use orthodrome distances but the system function is not differentiable which is a requirement of the Extended Kalman Filter (due to acrtan2). For small distances pythagoras should be sufficiently accurate. <br />
The initial state is taken from the first measurement for convergence reasons.<br />
<br />
The following gallery shows the results. <br />
* You can see the bad position resolution and an outlier in the first screenshot.<br />
* The second shows the same data overlaid with the applied filter. The outlier is gone and the resolution has improved.<br />
* The third screenshot shows data from a different GPS sensor with more precision (not DGPS) versus the filtered data.<br />
<br />
This of course is just a preliminary test and many setups need to be considered to make it work for most datasets.<br />
<br />
<gallery><br />
UnfilteredNMEA.png | Unfiltered GPS data<br />
FilteredNMEAVsOriginal.png | Unfiltered GPS data and Filtered GPS data<br />
PreciseGPSvsFilter.png | Another precise GPS vs Filtered GPS data<br />
</gallery><br />
<br />
The overall process even gives an estimation of the current error which is a capability of the [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter].<br />
This way positional inaccuracies may be added to the overall depth measurement inaccuracy.<br />
<br />
== Quality rating ==<br />
<br />
Each record (time, positon, depth) should become a quality rating.<br />
<br />
=== Points ===<br />
<br />
Derived from the Fibonacci series.<br />
<br />
{| class="wikitable"<br />
! Point || Description<br />
|-<br />
| 1 || extra small improvement<br />
|-<br />
| 2 || small improvement<br />
|-<br />
| 3 || medium improvement<br />
|-<br />
| 5 || large improvement<br />
|-<br />
| 8 || extra large improvement<br />
|}<br />
<br />
=== Factors ===<br />
<br />
{| class="wikitable"<br />
! style="width:15%" | Name<br />
! style="width:17%" | Factor<br />
! style="width:68%" | Description<br />
|-<br />
| depth offset || 8 (extra large) || The difference between the depth measured by the echo sounder and the depth (waterline) measured by hand.<br />
|-<br />
| device distance || 3 (medium) || The distance between gps antenna and echo sounder (lengthwise and crosswise).<br />
|-<br />
| SBAS || 3 (medium) || Satellite based augmentation system (WAAS, EGNOS, MSAS) which allows to correct the gps position.<br />
|-<br />
| position interpolation || 2 (small improvement) || Arrival of depth and position packets can have a time difference. It is/should be possible to interpolate the position.<br />
|}<br />
<br />
= Depth Rendering =<br />
<br />
= Siehe auch =<br />
* [[De:Bordnetz|Bordnetz]]<br />
* [[De:NMEA-Logger_anschliessen|NMEA-Logger_anschliessen]]<br />
* [http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCkQFjAA&url=http%3A%2F%2Fwww.dei.unipd.it%2F~chiuso%2FDOWNLOAD%2FPositioning_Heading_Kalman.pdf&ei=sSWNUMWnL4eC4gTRlYHAAw&usg=AFQjCNHq5V-PePNmDTZaGYvq0JeQFgqHVw Kalman Filtering for Positioning and Heading Control of Ships and Offshore Rigs]<br />
* [http://users.isr.ist.utl.pt/~pedro/publications/CAMS10.pdf A Multiple Model Adaptive Wave Filter for Dynamic Ship Positioning]<br />
* [http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4449205&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4449205 Echosounder Depth Tracking with the Extended Kalman Filter]</div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:En:Depth_Data&diff=2961OpenSeaMap-dev:En:Depth Data2014-09-27T18:01:22Z<p>MartinOver: /* Baltic Sea Olpenitz (Germany) */</p>
<hr />
<div>This Page describes the necessary efforts to retrieve and analyze depth data as well as create renderings from it<br />
<br />
= Data Aquisition =<br />
Depth data can be retrieved from public domain sources or from crowd sourced data.<br />
<br />
== GEBCO ==<br />
DIe Daten sind gerendert und stehen als Layer zur Verfügung:<br />
{| class="wikitable"<br />
! Zoom || Inhalt<br />
|-<br />
| 0..10 || Blaustufen und Schattierung<br />
|-<br />
| 11..18 || beschriftete Tiefenlinien, Blaustufen und Schattierung<br />
|}<br />
<br />
Noch zu lösende Probleme:<br />
* der GEBCO-Layer erzeugt einen milchigen Schleier über der Basiskarte<br />
* Tiefenlinien sind ab z=14 etwas grob (also ab da, wo dann die Flachwassertiefen beginnen) [http://map.openseamap.org/?zoom=14&lat=36.03097&lon=-5.49153&layers=BFTFTTTFFFF0 Karte]<br />
* Überschneidungen von 100m-Linie und Küstenlinie [http://map.openseamap.org/?zoom=15&lat=36.00318&lon=-5.60819&layers=BFFFTTTFFFF0FFFFF Karte]<br />
* Steilküsten (Cuba) [http://map.openseamap.org/?zoom=14&lat=19.94808&lon=-76.04289&layers=BFTFTTTFFFF0 Karte]<br />
<br />
== Crowd Sourced Data ==<br />
Crowd sourced data may be gathered by YOU. There are two options in development. A hardware and a software option.<br />
<br />
=== Workflow ===<br />
[[Datei:Workflow_depth.png]]<br />
<br />
Here you can find the document with the previous thoughts about the workflow:<br />
[http://osm.franken.de/wiki/FWT-Projekt%C3%BCbersicht-NMEA2Contours_2.1.ppt PPT Dokument]<br />
<br />
=== Hardware logger ===<br />
We are currently developing a hardware logger that may easily be plugged to the ship's network in order to log the networks data to a SD card.<br />
That data may then be uploaded by plugging the SD card to a normal computer with internet connection for upload.<br />
The main goal is to support NMEA 0183 data with options for NMEA 2000.<br />
<br />
=== Software logger ===<br />
A [[Software logger]] is in development and [http://seesea.sourceforge.net/datalogger/index.html can be downloaded here]. <br />
<br />
It currently supports: <br />
: Bluetooth <br />
: Serial ports<br />
: Internet Protocol (IP)<br />
It processes NMEA 0183 and AIS data.<br />
<br />
For vendor specific protocols such as SeaTalk 1 you have to use a [[De:NMEA-Logger_anschliessen|converter]] to NMEA 0183 data.<br />
<br />
NMEA 2000 support is only available if data is transcoded to NMEA 0183 by a converter.<br />
<br />
=== Chart Plotters ===<br />
<br />
Some chart plotters are able to save tracks out-of-the-box, e.g. several Raymarine (FSH files) and Humminbird (SON files) devices. Those files may directly be used as data source.<br />
<br />
<br />
=== Upload Process ===<br />
Uploading data is possible through using the [http://seesea.sourceforge.net/datalogger/index.html OpenSeaMap Data Logger Software] or via [http://depth.openseamap.org/ Web Interface].<br />
The system is currently being tested. <br />
<br />
[[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|You'll find further information here]].<br />
<br />
=== Test Data ===<br />
<br />
<br />
==== Brombachsee (Germany)====<br />
<br />
Test data for Openseamap: [http://osm.franken.de/wiki/test_data_brombachsee.zip Brombachsee_Test_Data]<br />
<br />
dgm_brombachsee.tif: Digital Elevation Model of the sea derived from height lines WWA (C).<br />
<br />
shapes_brombachsee.shp: Shape File derived from 4 NMEA Tracks. "dbs" is the original Sounding and "deep_cor" the depth after a correction (gauge levl).<br />
<br />
gpx_brombachsee.gpx: ele = "dbs" from the Shape File<br />
<br />
[[Datei:Brombachsee.png]]<br />
Resulting Digital Elevation Model<br />
<br />
==== Baltic Sea - near Großenbrode (Germany)====<br />
<br />
First results with an RMS error < 1,5 meter compared to an official dataset of the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].<br />
<br />
[[Datei: Bsh_results_overview.jpg]]<br />
<br />
[Picture 1] '''''OSM map in background, raster Depth Model derived from BSH data and crowed sourced OpenSeaMap Points - Overview'''''<br />
<br />
Blue = flat BSH data, red = deep BSH data.<br />
<br>Blue points = OpenSeaMap raw measuring points.<br />
<br />
{| class="wikitable"<br />
|-<br />
| n || 5062<br />
|-<br />
|-<br />
| datasets || 21<br />
|-<br />
| max deviation || 3,43 meters<br />
|-<br />
| mean (abs) || 0,69 meters<br />
|-<br />
| RMS +/- || 0,91 meters<br />
|}<br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| VesselConfig ID || 68<br />
|-<br />
| Manufacturer || Bavaria Yachtbau<br />
|-<br />
| Model || B32<br />
|-<br />
| Length || 10,0 meters<br />
|-<br />
| Beam || 3,35 meters<br />
|-<br />
| Draft || 1,6 meters<br />
|-<br />
| Height || 14 meters<br />
|-<br />
| Displacement || 4,2 t<br />
|-<br />
| Sensor manufacturer || Raymarine<br />
|-<br />
| Sensor Offset to waterline || 0,45 meters<br />
|-<br />
| Sensor Offset to keel || 1,15 meters<br />
|}<br />
<br />
<br />
<br />
A digital Deep Model raster was computed from the BSH point dataset (c).<br />
The depth of the crowed sourced dataset was compared to the derived raster dataset from the BSH.<br />
The raw crowed sourced dataset was corrected by the sensor offset (0,45 meters).<br />
<br />
[[Datei: Scatter_cor_sensor.jpeg]]<br />
<br />
[Picture 2] '''''Scatter plot: BSH data on the x-axis and the crowed sourced data on the y-axis. Trend line in black and optimal line in red.'''''<br />
<br />
The deviation from the reference dataset increases with the depth measured.<br />
<br />
As you see in the picture below the difference between the datasets has an regular pattern maybe deepending on waves.<br />
<br />
[[Datei: Bsh_results_detail_10_classes.jpg]]<br />
<br />
[Picture 3] '''''Crowed sourced OpenSeaMap track points and the difference from the BSH dataset'''''<br />
<br />
White = low difference, orange = medium difference, red = strong difference<br />
<br />
Download of the data http://osm.franken.de/data/baltic_sea_test_data.zip<br />
'''Be aware of the copyright from the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].'''<br />
The data in the dataset is not corrected by sensor offset.<br />
<br />
==== Baltic Sea Olpenitz (Germany)====<br />
<br />
In the test area were tracks from two different vessel configurations. <br />
The fist one was the one from the test area Großenbrode (config ID 68).<br />
<br />
In the Table below the settings for die vesselconfigid 110 are shown: <br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| VesselConfigId || 110<br />
|-<br />
| Manufacturer || Waarschip<br />
|-<br />
| Model || 570<br />
|-<br />
| Length || 5,7 meters<br />
|-<br />
| Beam || 2,45 meters<br />
|-<br />
| Draft || 1,0 meters<br />
|-<br />
| Height || 9.1 meters<br />
|-<br />
| Displacement || 0,8 t<br />
|-<br />
| Sensor manufacturer || Tacktick/ Airmar<br />
|-<br />
| Sensor Model || T912<br />
|-<br />
| Sensor Offset to waterline || 0,2 meters<br />
|-<br />
| Sensor Offset to keel || 0,45 meters<br />
|}<br />
<br />
=== Meta Data Statistics ===<br />
<br />
Statistics for the metadata entrees with some personal comments (by MartinOver). Stand 20.9.2014.<br />
<br />
{| class="prettytable"<br />
|-<br />
|<br />
'''Step'''<br />
<br />
|<br />
'''Topic'''<br />
<br />
|<br />
'''Count'''<br />
<br />
|<br />
'''State'''<br />
<br />
|<br />
'''Comment'''<br />
<br />
|-<br />
|<br />
1/1<br />
<br />
|<br />
Name<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
1/2<br />
<br />
|<br />
Description<br />
<br />
|<br />
76/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/1<br />
<br />
|<br />
Length<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
Some wrong entrees like mail addresses or comments <br />
<br />
24 “0.00” Values<br />
<br />
|-<br />
|<br />
2/2<br />
<br />
|<br />
Beam<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
37 „0.00“ Values<br />
<br />
|-<br />
|<br />
2/3<br />
<br />
|<br />
Draft<br />
<br />
|<br />
79/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/4<br />
<br />
|<br />
Displacement<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/5<br />
<br />
|<br />
Height<br />
<br />
|<br />
78/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/6<br />
<br />
|<br />
Manufacturer<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Model<br />
<br />
|<br />
49/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Type<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/3<br />
<br />
|<br />
Position below Waterline<br />
<br />
|<br />
57/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Should be Obligatory<br />
<br />
|-<br />
|<br />
3/4<br />
<br />
|<br />
Depth Measurement<br />
<br />
|<br />
?<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Where in DB?<br />
<br />
|-<br />
|<br />
3/5<br />
<br />
|<br />
Sensor Offset to Keel<br />
<br />
|<br />
6/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/6<br />
<br />
|<br />
Producer of Depth Sensor<br />
<br />
|<br />
63/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/7<br />
<br />
|<br />
Device Model<br />
<br />
|<br />
40/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
58 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
51 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/3<br />
<br />
|<br />
Position abbove Waterline<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/4<br />
<br />
|<br />
Producer<br />
<br />
|<br />
77/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/5<br />
<br />
|<br />
Model<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|}<br />
<br />
= Data Preprocessing =<br />
<br />
== Data Condition ==<br />
Raw data is usually erronous and must be corrected<br />
<br />
=== Internal data problems ===<br />
Depth data may be affected by electrical conditions and software implementations<br />
* Data is incomplete and fail their checksum (bus errors from physical transmissions errors)<br />
* Data is retrived out of sequence<br />
* Data is erronous sensor data <br />
** Approximate correctable data i.e. invalid GPS position that may be interpolated<br />
** Uncorrectable data i.e. failed log sensor that shows slow speeds<br />
* Data resolution is low i.e. for energy saving purposes GPS position is updated every 10 seconds instead of every second<br />
* Sensor data is actively miscalibrated i.e. charter companies add additional draft to the sensor depth for safety reasons<br />
<br />
=== External data problems ===<br />
Depth data may be affected by different environmental circumstances <br />
*# The water temperature affects the ultrasound echo. An inhomogen water temperature yields unwanted echos<br />
*# The seabed affects the ultrasound echo<br />
*# The seastate affects the measurement. There even may be waves when there is no wind.<br />
*# Waves may affect the roll of the measuring vessel resulting in steep measurements that are invalid.<br />
*# The sounder sensor is not the position of the GPS antenna. A position offset including heading must be incorporated.<br />
*# The time of the measurement need not correlate with the time the position was received. This may even happen due to processing time of the hard or software.<br />
*# Corrections for tide induced water levels must happen<br />
<br />
Solutions probably are<br />
*# Water temperature may be measure from the sensor, other data may be unavailable<br />
*# Modern sidescan sonar may yield information about the seabed through classifications<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# Position offsets must be provided by the user<br />
*# Time outages may be handled by the filter if precise timestamps are available in recorded data<br />
*# LAT to Mean sea level differences may be calculated from DTU10 worldwide, river gauges need to monitored<br />
<br />
[[Datei:LAT2MSLDiff.png]]<br />
<br />
<br />
== Data Condition Examples / Showcases ==<br />
<br />
=== Missing measurments (Position) ===<br />
Distribution for position updates taken from an example dataset. Left column shows the time between two consecutive measurements, right column shows how many measurements had this time update.<br />
One can see from the distribtion that the sensor is updated every second but many measurements are one or more seconds late.<br />
21 seconds with no position update may result in an instability of the subsequent filter.<br />
<pre><br />
MeasuredPosition3D<br />
GP<br />
0 :4285<br />
1000 :11295<br />
2000 :5056<br />
3000 :2134<br />
4000 :1135<br />
5000 :315<br />
6000 :154<br />
7000 :46<br />
8000 :36<br />
9000 :16<br />
10000 :12<br />
11000 :3<br />
12000 :4<br />
13000 :1<br />
14000 :7<br />
15000 :3<br />
16000 :1<br />
21000 :1<br />
</pre><br />
<br />
=== Missing measurments (Position) with erronous clock ===<br />
This example is at a 10 second position update rate. However the measurment time is faulty causing large negative and positive update rates. The clock jumps by +- one year/month/day/hour. One can further see from the many 0 time measurements that the rate at which data is sent to the nmea bus is higher than the actual position update (data is sent every second, a position update is every 10 seconds)<br />
<pre><br />
MeasuredPosition3D<br />
II<br />
-21340000 :1<br />
-13194000 :1<br />
-7998000 :1<br />
-2674000 :1<br />
-2434000 :1<br />
-2402000 :1<br />
-2030000 :1<br />
-1926000 :1<br />
-1894000 :1<br />
-1806000 :1<br />
-1480000 :1<br />
-1430000 :1<br />
-1382000 :1<br />
-1114000 :1<br />
-814000 :1<br />
-634000 :1<br />
-590000 :1<br />
-546000 :1<br />
-470000 :1<br />
-290000 :1<br />
-230000 :1<br />
-198000 :1<br />
-110000 :1<br />
-94000 :2<br />
0 :182200<br />
5000 :1<br />
10000 :20230<br />
15000 :1<br />
20000 :84<br />
50000 :1<br />
114000 :2<br />
130000 :2<br />
218000 :1<br />
250000 :1<br />
310000 :1<br />
490000 :1<br />
566000 :1<br />
610000 :1<br />
654000 :1<br />
834000 :1<br />
1134000 :1<br />
1402000 :1<br />
1450000 :1</pre><br />
<br />
== Solution Proposal ==<br />
<br />
=== Outline ===<br />
The ship is influenced by the outlined environment which can be observed. Naturally what is observed is not the state of the<br />
ship as i.e. the position if taken from GPS is 95% less than 10m accurate. To improve quality an estimation of the true state yields better results if this noise taken into account properly.<br />
<br />
=== Details ===<br />
The ship moves according to physical laws. For the easist case imagine a ship with constant velocity and direction. For any point in time you can tell where the ship is with easy math. Considering the full blown setup a ships movement is affected by many parameters such as wind speed, water current, waves, tide, and many more. The ship moves also triaxial in a dynamic way in itself (roll, pitch, yaw). Heeling even changes the measurement position with respect to the depth position. In terms of a filter this is called a system model that describes how the state of the ship may change. Given such a state you can measure what your sensor readings are and compare that to where the system thinks you are.<br />
<br />
The [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter] is known to be the best linear estimator for such situations. Unfortunately the system model is not linear which is why the Extended Kalman Filter needs to be used in order to linearize the system at hand.<br />
<br />
Todo:<br />
* Construct ship system model with at least the position state and probably its course and speed or even more (depth)<br />
* Estimate the system variance (This is a hard one, proposals welcome)<br />
* Construct the measurement model according to the data available (GPS, Log)<br />
* Estimate the measurement noise according to specifc sensors (DPGS is more accurate than GPS)<br />
<br />
The estimation with the position and depth can be retrieved and stored in a database.<br />
<br />
Pitfalls:<br />
* If the system noise is badly chosen the estimation of the system state does not converge to the true state / measurement.<br />
* If the system is very detailed the system variance can be reduced. The required cpu time for processing increases<br />
<br />
Benefits:<br />
* Having the best estimation of the true position even if measurements are noisy<br />
* Easy and effective algorithmic processing<br />
<br />
== Analysis == <br />
<br />
=== Data Sets ===<br />
Currently two test data sets are available recorded during trips from Mallorca and the Baltic Sea.<br />
In terms of data quality the Mallorca data shows many challenges. <br />
* The minimum recommended sentences from NMEA showed up with false date and time readings while having correct (!!!) message checksums. <br />
* The log on the ship was defective and delivered no readings from time to time. <br />
* The same holds true for the water temperature.<br />
* The GPS positions relatively imprecise because some last decimal digits are missing in the recordings.<br />
* The GPS positions are updated every 10 seconds while other sensor readings update almost every second.<br />
* The GPS position are sometimes way off due to false readings<br />
<br />
The Baltic Sea data set is a little bit better<br />
* Only a single day is available<br />
* GPS positions are updated every second<br />
<br />
One problem with the data is that there is time available when sensor readings were recorded. This yields problems to the filter algorithm.<br />
<br />
<br />
=== Filter Algorithm ===<br />
At first the Extended Kalman Filter is being analyzed. Using an apache implementation with the available data the filter quickly throw an exception that<br />
a matrix is not invertible because of numeric instabilities. When removing this exception the filter seems to work but the removal and its effects have yet to be analyzed.<br />
Literature suggest that a fixed interval smoother may yield better results in case of offline data processing. As it is an extension to the existing kalman filter<br />
we may consider that for the future.<br />
<br />
One problem are the different update rates of the sensors. As GPS may deliver positions at 0.1Hz speed is updated at 1Hz. Literature suggests that<br />
the missing measurements shell be modelled as a random variable with the standard deviation of the sensor. It may even be possible to update covariance matrices only partially with the sensor readings received. Input for the best solution may be formulated on the developer mailing list.<br />
<br />
== Results == <br />
A prototype implementation is shown in the following screenshots. An Extended Kalman Filter is being used. It has the position<br />
and the current bearing and velocity as system state. The input is the measurement of these four observables. The system function is<br />
good old pythagoras. In a first implementation I tried to use orthodrome distances but the system function is not differentiable which is a requirement of the Extended Kalman Filter (due to acrtan2). For small distances pythagoras should be sufficiently accurate. <br />
The initial state is taken from the first measurement for convergence reasons.<br />
<br />
The following gallery shows the results. <br />
* You can see the bad position resolution and an outlier in the first screenshot.<br />
* The second shows the same data overlaid with the applied filter. The outlier is gone and the resolution has improved.<br />
* The third screenshot shows data from a different GPS sensor with more precision (not DGPS) versus the filtered data.<br />
<br />
This of course is just a preliminary test and many setups need to be considered to make it work for most datasets.<br />
<br />
<gallery><br />
UnfilteredNMEA.png | Unfiltered GPS data<br />
FilteredNMEAVsOriginal.png | Unfiltered GPS data and Filtered GPS data<br />
PreciseGPSvsFilter.png | Another precise GPS vs Filtered GPS data<br />
</gallery><br />
<br />
The overall process even gives an estimation of the current error which is a capability of the [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter].<br />
This way positional inaccuracies may be added to the overall depth measurement inaccuracy.<br />
<br />
== Quality rating ==<br />
<br />
Each record (time, positon, depth) should become a quality rating.<br />
<br />
=== Points ===<br />
<br />
Derived from the Fibonacci series.<br />
<br />
{| class="wikitable"<br />
! Point || Description<br />
|-<br />
| 1 || extra small improvement<br />
|-<br />
| 2 || small improvement<br />
|-<br />
| 3 || medium improvement<br />
|-<br />
| 5 || large improvement<br />
|-<br />
| 8 || extra large improvement<br />
|}<br />
<br />
=== Factors ===<br />
<br />
{| class="wikitable"<br />
! style="width:15%" | Name<br />
! style="width:17%" | Factor<br />
! style="width:68%" | Description<br />
|-<br />
| depth offset || 8 (extra large) || The difference between the depth measured by the echo sounder and the depth (waterline) measured by hand.<br />
|-<br />
| device distance || 3 (medium) || The distance between gps antenna and echo sounder (lengthwise and crosswise).<br />
|-<br />
| SBAS || 3 (medium) || Satellite based augmentation system (WAAS, EGNOS, MSAS) which allows to correct the gps position.<br />
|-<br />
| position interpolation || 2 (small improvement) || Arrival of depth and position packets can have a time difference. It is/should be possible to interpolate the position.<br />
|}<br />
<br />
= Depth Rendering =<br />
<br />
= Siehe auch =<br />
* [[De:Bordnetz|Bordnetz]]<br />
* [[De:NMEA-Logger_anschliessen|NMEA-Logger_anschliessen]]<br />
* [http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCkQFjAA&url=http%3A%2F%2Fwww.dei.unipd.it%2F~chiuso%2FDOWNLOAD%2FPositioning_Heading_Kalman.pdf&ei=sSWNUMWnL4eC4gTRlYHAAw&usg=AFQjCNHq5V-PePNmDTZaGYvq0JeQFgqHVw Kalman Filtering for Positioning and Heading Control of Ships and Offshore Rigs]<br />
* [http://users.isr.ist.utl.pt/~pedro/publications/CAMS10.pdf A Multiple Model Adaptive Wave Filter for Dynamic Ship Positioning]<br />
* [http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4449205&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4449205 Echosounder Depth Tracking with the Extended Kalman Filter]</div>MartinOverhttps://wiki.openseamap.org/index.php?title=Datei:Balitc_sea_scatter_plot_2.jpeg&diff=2960Datei:Balitc sea scatter plot 2.jpeg2014-09-27T18:01:01Z<p>MartinOver: </p>
<hr />
<div></div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:En:Depth_Data&diff=2959OpenSeaMap-dev:En:Depth Data2014-09-27T17:46:25Z<p>MartinOver: /* Baltic Sea - near Großenbrode (Germany) */</p>
<hr />
<div>This Page describes the necessary efforts to retrieve and analyze depth data as well as create renderings from it<br />
<br />
= Data Aquisition =<br />
Depth data can be retrieved from public domain sources or from crowd sourced data.<br />
<br />
== GEBCO ==<br />
DIe Daten sind gerendert und stehen als Layer zur Verfügung:<br />
{| class="wikitable"<br />
! Zoom || Inhalt<br />
|-<br />
| 0..10 || Blaustufen und Schattierung<br />
|-<br />
| 11..18 || beschriftete Tiefenlinien, Blaustufen und Schattierung<br />
|}<br />
<br />
Noch zu lösende Probleme:<br />
* der GEBCO-Layer erzeugt einen milchigen Schleier über der Basiskarte<br />
* Tiefenlinien sind ab z=14 etwas grob (also ab da, wo dann die Flachwassertiefen beginnen) [http://map.openseamap.org/?zoom=14&lat=36.03097&lon=-5.49153&layers=BFTFTTTFFFF0 Karte]<br />
* Überschneidungen von 100m-Linie und Küstenlinie [http://map.openseamap.org/?zoom=15&lat=36.00318&lon=-5.60819&layers=BFFFTTTFFFF0FFFFF Karte]<br />
* Steilküsten (Cuba) [http://map.openseamap.org/?zoom=14&lat=19.94808&lon=-76.04289&layers=BFTFTTTFFFF0 Karte]<br />
<br />
== Crowd Sourced Data ==<br />
Crowd sourced data may be gathered by YOU. There are two options in development. A hardware and a software option.<br />
<br />
=== Workflow ===<br />
[[Datei:Workflow_depth.png]]<br />
<br />
Here you can find the document with the previous thoughts about the workflow:<br />
[http://osm.franken.de/wiki/FWT-Projekt%C3%BCbersicht-NMEA2Contours_2.1.ppt PPT Dokument]<br />
<br />
=== Hardware logger ===<br />
We are currently developing a hardware logger that may easily be plugged to the ship's network in order to log the networks data to a SD card.<br />
That data may then be uploaded by plugging the SD card to a normal computer with internet connection for upload.<br />
The main goal is to support NMEA 0183 data with options for NMEA 2000.<br />
<br />
=== Software logger ===<br />
A [[Software logger]] is in development and [http://seesea.sourceforge.net/datalogger/index.html can be downloaded here]. <br />
<br />
It currently supports: <br />
: Bluetooth <br />
: Serial ports<br />
: Internet Protocol (IP)<br />
It processes NMEA 0183 and AIS data.<br />
<br />
For vendor specific protocols such as SeaTalk 1 you have to use a [[De:NMEA-Logger_anschliessen|converter]] to NMEA 0183 data.<br />
<br />
NMEA 2000 support is only available if data is transcoded to NMEA 0183 by a converter.<br />
<br />
=== Chart Plotters ===<br />
<br />
Some chart plotters are able to save tracks out-of-the-box, e.g. several Raymarine (FSH files) and Humminbird (SON files) devices. Those files may directly be used as data source.<br />
<br />
<br />
=== Upload Process ===<br />
Uploading data is possible through using the [http://seesea.sourceforge.net/datalogger/index.html OpenSeaMap Data Logger Software] or via [http://depth.openseamap.org/ Web Interface].<br />
The system is currently being tested. <br />
<br />
[[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|You'll find further information here]].<br />
<br />
=== Test Data ===<br />
<br />
<br />
==== Brombachsee (Germany)====<br />
<br />
Test data for Openseamap: [http://osm.franken.de/wiki/test_data_brombachsee.zip Brombachsee_Test_Data]<br />
<br />
dgm_brombachsee.tif: Digital Elevation Model of the sea derived from height lines WWA (C).<br />
<br />
shapes_brombachsee.shp: Shape File derived from 4 NMEA Tracks. "dbs" is the original Sounding and "deep_cor" the depth after a correction (gauge levl).<br />
<br />
gpx_brombachsee.gpx: ele = "dbs" from the Shape File<br />
<br />
[[Datei:Brombachsee.png]]<br />
Resulting Digital Elevation Model<br />
<br />
==== Baltic Sea - near Großenbrode (Germany)====<br />
<br />
First results with an RMS error < 1,5 meter compared to an official dataset of the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].<br />
<br />
[[Datei: Bsh_results_overview.jpg]]<br />
<br />
[Picture 1] '''''OSM map in background, raster Depth Model derived from BSH data and crowed sourced OpenSeaMap Points - Overview'''''<br />
<br />
Blue = flat BSH data, red = deep BSH data.<br />
<br>Blue points = OpenSeaMap raw measuring points.<br />
<br />
{| class="wikitable"<br />
|-<br />
| n || 5062<br />
|-<br />
|-<br />
| datasets || 21<br />
|-<br />
| max deviation || 3,43 meters<br />
|-<br />
| mean (abs) || 0,69 meters<br />
|-<br />
| RMS +/- || 0,91 meters<br />
|}<br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| VesselConfig ID || 68<br />
|-<br />
| Manufacturer || Bavaria Yachtbau<br />
|-<br />
| Model || B32<br />
|-<br />
| Length || 10,0 meters<br />
|-<br />
| Beam || 3,35 meters<br />
|-<br />
| Draft || 1,6 meters<br />
|-<br />
| Height || 14 meters<br />
|-<br />
| Displacement || 4,2 t<br />
|-<br />
| Sensor manufacturer || Raymarine<br />
|-<br />
| Sensor Offset to waterline || 0,45 meters<br />
|-<br />
| Sensor Offset to keel || 1,15 meters<br />
|}<br />
<br />
<br />
<br />
A digital Deep Model raster was computed from the BSH point dataset (c).<br />
The depth of the crowed sourced dataset was compared to the derived raster dataset from the BSH.<br />
The raw crowed sourced dataset was corrected by the sensor offset (0,45 meters).<br />
<br />
[[Datei: Scatter_cor_sensor.jpeg]]<br />
<br />
[Picture 2] '''''Scatter plot: BSH data on the x-axis and the crowed sourced data on the y-axis. Trend line in black and optimal line in red.'''''<br />
<br />
The deviation from the reference dataset increases with the depth measured.<br />
<br />
As you see in the picture below the difference between the datasets has an regular pattern maybe deepending on waves.<br />
<br />
[[Datei: Bsh_results_detail_10_classes.jpg]]<br />
<br />
[Picture 3] '''''Crowed sourced OpenSeaMap track points and the difference from the BSH dataset'''''<br />
<br />
White = low difference, orange = medium difference, red = strong difference<br />
<br />
Download of the data http://osm.franken.de/data/baltic_sea_test_data.zip<br />
'''Be aware of the copyright from the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].'''<br />
The data in the dataset is not corrected by sensor offset.<br />
<br />
==== Baltic Sea Olpenitz (Germany)====<br />
<br />
In the test area were tracks from two differnetvessel vessel configurations. <br />
The fist one was the one from the test area Großenbrode (config ID 68).<br />
<br />
In the Table below the settings for die vesselconfigid 110: <br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| VesselConfigId || 110<br />
|-<br />
| Manufacturer || Waarschip<br />
|-<br />
| Model || 570<br />
|-<br />
| Length || 5,7 meters<br />
|-<br />
| Beam || 2,45 meters<br />
|-<br />
| Draft || 1,0 meters<br />
|-<br />
| Height || 9.1 meters<br />
|-<br />
| Displacement || 0,8 t<br />
|-<br />
| Sensor manufacturer || Tacktick/ Airmar<br />
|-<br />
| Sensor Model || T912<br />
|-<br />
| Sensor Offset to waterline || 0,2 meters<br />
|-<br />
| Sensor Offset to keel || 0,45 meters<br />
|}<br />
<br />
=== Meta Data Statistics ===<br />
<br />
Statistics for the metadata entrees with some personal comments (by MartinOver). Stand 20.9.2014.<br />
<br />
{| class="prettytable"<br />
|-<br />
|<br />
'''Step'''<br />
<br />
|<br />
'''Topic'''<br />
<br />
|<br />
'''Count'''<br />
<br />
|<br />
'''State'''<br />
<br />
|<br />
'''Comment'''<br />
<br />
|-<br />
|<br />
1/1<br />
<br />
|<br />
Name<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
1/2<br />
<br />
|<br />
Description<br />
<br />
|<br />
76/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/1<br />
<br />
|<br />
Length<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
Some wrong entrees like mail addresses or comments <br />
<br />
24 “0.00” Values<br />
<br />
|-<br />
|<br />
2/2<br />
<br />
|<br />
Beam<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
37 „0.00“ Values<br />
<br />
|-<br />
|<br />
2/3<br />
<br />
|<br />
Draft<br />
<br />
|<br />
79/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/4<br />
<br />
|<br />
Displacement<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/5<br />
<br />
|<br />
Height<br />
<br />
|<br />
78/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/6<br />
<br />
|<br />
Manufacturer<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Model<br />
<br />
|<br />
49/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Type<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/3<br />
<br />
|<br />
Position below Waterline<br />
<br />
|<br />
57/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Should be Obligatory<br />
<br />
|-<br />
|<br />
3/4<br />
<br />
|<br />
Depth Measurement<br />
<br />
|<br />
?<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Where in DB?<br />
<br />
|-<br />
|<br />
3/5<br />
<br />
|<br />
Sensor Offset to Keel<br />
<br />
|<br />
6/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/6<br />
<br />
|<br />
Producer of Depth Sensor<br />
<br />
|<br />
63/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/7<br />
<br />
|<br />
Device Model<br />
<br />
|<br />
40/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
58 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
51 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/3<br />
<br />
|<br />
Position abbove Waterline<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/4<br />
<br />
|<br />
Producer<br />
<br />
|<br />
77/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/5<br />
<br />
|<br />
Model<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|}<br />
<br />
= Data Preprocessing =<br />
<br />
== Data Condition ==<br />
Raw data is usually erronous and must be corrected<br />
<br />
=== Internal data problems ===<br />
Depth data may be affected by electrical conditions and software implementations<br />
* Data is incomplete and fail their checksum (bus errors from physical transmissions errors)<br />
* Data is retrived out of sequence<br />
* Data is erronous sensor data <br />
** Approximate correctable data i.e. invalid GPS position that may be interpolated<br />
** Uncorrectable data i.e. failed log sensor that shows slow speeds<br />
* Data resolution is low i.e. for energy saving purposes GPS position is updated every 10 seconds instead of every second<br />
* Sensor data is actively miscalibrated i.e. charter companies add additional draft to the sensor depth for safety reasons<br />
<br />
=== External data problems ===<br />
Depth data may be affected by different environmental circumstances <br />
*# The water temperature affects the ultrasound echo. An inhomogen water temperature yields unwanted echos<br />
*# The seabed affects the ultrasound echo<br />
*# The seastate affects the measurement. There even may be waves when there is no wind.<br />
*# Waves may affect the roll of the measuring vessel resulting in steep measurements that are invalid.<br />
*# The sounder sensor is not the position of the GPS antenna. A position offset including heading must be incorporated.<br />
*# The time of the measurement need not correlate with the time the position was received. This may even happen due to processing time of the hard or software.<br />
*# Corrections for tide induced water levels must happen<br />
<br />
Solutions probably are<br />
*# Water temperature may be measure from the sensor, other data may be unavailable<br />
*# Modern sidescan sonar may yield information about the seabed through classifications<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# Position offsets must be provided by the user<br />
*# Time outages may be handled by the filter if precise timestamps are available in recorded data<br />
*# LAT to Mean sea level differences may be calculated from DTU10 worldwide, river gauges need to monitored<br />
<br />
[[Datei:LAT2MSLDiff.png]]<br />
<br />
<br />
== Data Condition Examples / Showcases ==<br />
<br />
=== Missing measurments (Position) ===<br />
Distribution for position updates taken from an example dataset. Left column shows the time between two consecutive measurements, right column shows how many measurements had this time update.<br />
One can see from the distribtion that the sensor is updated every second but many measurements are one or more seconds late.<br />
21 seconds with no position update may result in an instability of the subsequent filter.<br />
<pre><br />
MeasuredPosition3D<br />
GP<br />
0 :4285<br />
1000 :11295<br />
2000 :5056<br />
3000 :2134<br />
4000 :1135<br />
5000 :315<br />
6000 :154<br />
7000 :46<br />
8000 :36<br />
9000 :16<br />
10000 :12<br />
11000 :3<br />
12000 :4<br />
13000 :1<br />
14000 :7<br />
15000 :3<br />
16000 :1<br />
21000 :1<br />
</pre><br />
<br />
=== Missing measurments (Position) with erronous clock ===<br />
This example is at a 10 second position update rate. However the measurment time is faulty causing large negative and positive update rates. The clock jumps by +- one year/month/day/hour. One can further see from the many 0 time measurements that the rate at which data is sent to the nmea bus is higher than the actual position update (data is sent every second, a position update is every 10 seconds)<br />
<pre><br />
MeasuredPosition3D<br />
II<br />
-21340000 :1<br />
-13194000 :1<br />
-7998000 :1<br />
-2674000 :1<br />
-2434000 :1<br />
-2402000 :1<br />
-2030000 :1<br />
-1926000 :1<br />
-1894000 :1<br />
-1806000 :1<br />
-1480000 :1<br />
-1430000 :1<br />
-1382000 :1<br />
-1114000 :1<br />
-814000 :1<br />
-634000 :1<br />
-590000 :1<br />
-546000 :1<br />
-470000 :1<br />
-290000 :1<br />
-230000 :1<br />
-198000 :1<br />
-110000 :1<br />
-94000 :2<br />
0 :182200<br />
5000 :1<br />
10000 :20230<br />
15000 :1<br />
20000 :84<br />
50000 :1<br />
114000 :2<br />
130000 :2<br />
218000 :1<br />
250000 :1<br />
310000 :1<br />
490000 :1<br />
566000 :1<br />
610000 :1<br />
654000 :1<br />
834000 :1<br />
1134000 :1<br />
1402000 :1<br />
1450000 :1</pre><br />
<br />
== Solution Proposal ==<br />
<br />
=== Outline ===<br />
The ship is influenced by the outlined environment which can be observed. Naturally what is observed is not the state of the<br />
ship as i.e. the position if taken from GPS is 95% less than 10m accurate. To improve quality an estimation of the true state yields better results if this noise taken into account properly.<br />
<br />
=== Details ===<br />
The ship moves according to physical laws. For the easist case imagine a ship with constant velocity and direction. For any point in time you can tell where the ship is with easy math. Considering the full blown setup a ships movement is affected by many parameters such as wind speed, water current, waves, tide, and many more. The ship moves also triaxial in a dynamic way in itself (roll, pitch, yaw). Heeling even changes the measurement position with respect to the depth position. In terms of a filter this is called a system model that describes how the state of the ship may change. Given such a state you can measure what your sensor readings are and compare that to where the system thinks you are.<br />
<br />
The [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter] is known to be the best linear estimator for such situations. Unfortunately the system model is not linear which is why the Extended Kalman Filter needs to be used in order to linearize the system at hand.<br />
<br />
Todo:<br />
* Construct ship system model with at least the position state and probably its course and speed or even more (depth)<br />
* Estimate the system variance (This is a hard one, proposals welcome)<br />
* Construct the measurement model according to the data available (GPS, Log)<br />
* Estimate the measurement noise according to specifc sensors (DPGS is more accurate than GPS)<br />
<br />
The estimation with the position and depth can be retrieved and stored in a database.<br />
<br />
Pitfalls:<br />
* If the system noise is badly chosen the estimation of the system state does not converge to the true state / measurement.<br />
* If the system is very detailed the system variance can be reduced. The required cpu time for processing increases<br />
<br />
Benefits:<br />
* Having the best estimation of the true position even if measurements are noisy<br />
* Easy and effective algorithmic processing<br />
<br />
== Analysis == <br />
<br />
=== Data Sets ===<br />
Currently two test data sets are available recorded during trips from Mallorca and the Baltic Sea.<br />
In terms of data quality the Mallorca data shows many challenges. <br />
* The minimum recommended sentences from NMEA showed up with false date and time readings while having correct (!!!) message checksums. <br />
* The log on the ship was defective and delivered no readings from time to time. <br />
* The same holds true for the water temperature.<br />
* The GPS positions relatively imprecise because some last decimal digits are missing in the recordings.<br />
* The GPS positions are updated every 10 seconds while other sensor readings update almost every second.<br />
* The GPS position are sometimes way off due to false readings<br />
<br />
The Baltic Sea data set is a little bit better<br />
* Only a single day is available<br />
* GPS positions are updated every second<br />
<br />
One problem with the data is that there is time available when sensor readings were recorded. This yields problems to the filter algorithm.<br />
<br />
<br />
=== Filter Algorithm ===<br />
At first the Extended Kalman Filter is being analyzed. Using an apache implementation with the available data the filter quickly throw an exception that<br />
a matrix is not invertible because of numeric instabilities. When removing this exception the filter seems to work but the removal and its effects have yet to be analyzed.<br />
Literature suggest that a fixed interval smoother may yield better results in case of offline data processing. As it is an extension to the existing kalman filter<br />
we may consider that for the future.<br />
<br />
One problem are the different update rates of the sensors. As GPS may deliver positions at 0.1Hz speed is updated at 1Hz. Literature suggests that<br />
the missing measurements shell be modelled as a random variable with the standard deviation of the sensor. It may even be possible to update covariance matrices only partially with the sensor readings received. Input for the best solution may be formulated on the developer mailing list.<br />
<br />
== Results == <br />
A prototype implementation is shown in the following screenshots. An Extended Kalman Filter is being used. It has the position<br />
and the current bearing and velocity as system state. The input is the measurement of these four observables. The system function is<br />
good old pythagoras. In a first implementation I tried to use orthodrome distances but the system function is not differentiable which is a requirement of the Extended Kalman Filter (due to acrtan2). For small distances pythagoras should be sufficiently accurate. <br />
The initial state is taken from the first measurement for convergence reasons.<br />
<br />
The following gallery shows the results. <br />
* You can see the bad position resolution and an outlier in the first screenshot.<br />
* The second shows the same data overlaid with the applied filter. The outlier is gone and the resolution has improved.<br />
* The third screenshot shows data from a different GPS sensor with more precision (not DGPS) versus the filtered data.<br />
<br />
This of course is just a preliminary test and many setups need to be considered to make it work for most datasets.<br />
<br />
<gallery><br />
UnfilteredNMEA.png | Unfiltered GPS data<br />
FilteredNMEAVsOriginal.png | Unfiltered GPS data and Filtered GPS data<br />
PreciseGPSvsFilter.png | Another precise GPS vs Filtered GPS data<br />
</gallery><br />
<br />
The overall process even gives an estimation of the current error which is a capability of the [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter].<br />
This way positional inaccuracies may be added to the overall depth measurement inaccuracy.<br />
<br />
== Quality rating ==<br />
<br />
Each record (time, positon, depth) should become a quality rating.<br />
<br />
=== Points ===<br />
<br />
Derived from the Fibonacci series.<br />
<br />
{| class="wikitable"<br />
! Point || Description<br />
|-<br />
| 1 || extra small improvement<br />
|-<br />
| 2 || small improvement<br />
|-<br />
| 3 || medium improvement<br />
|-<br />
| 5 || large improvement<br />
|-<br />
| 8 || extra large improvement<br />
|}<br />
<br />
=== Factors ===<br />
<br />
{| class="wikitable"<br />
! style="width:15%" | Name<br />
! style="width:17%" | Factor<br />
! style="width:68%" | Description<br />
|-<br />
| depth offset || 8 (extra large) || The difference between the depth measured by the echo sounder and the depth (waterline) measured by hand.<br />
|-<br />
| device distance || 3 (medium) || The distance between gps antenna and echo sounder (lengthwise and crosswise).<br />
|-<br />
| SBAS || 3 (medium) || Satellite based augmentation system (WAAS, EGNOS, MSAS) which allows to correct the gps position.<br />
|-<br />
| position interpolation || 2 (small improvement) || Arrival of depth and position packets can have a time difference. It is/should be possible to interpolate the position.<br />
|}<br />
<br />
= Depth Rendering =<br />
<br />
= Siehe auch =<br />
* [[De:Bordnetz|Bordnetz]]<br />
* [[De:NMEA-Logger_anschliessen|NMEA-Logger_anschliessen]]<br />
* [http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCkQFjAA&url=http%3A%2F%2Fwww.dei.unipd.it%2F~chiuso%2FDOWNLOAD%2FPositioning_Heading_Kalman.pdf&ei=sSWNUMWnL4eC4gTRlYHAAw&usg=AFQjCNHq5V-PePNmDTZaGYvq0JeQFgqHVw Kalman Filtering for Positioning and Heading Control of Ships and Offshore Rigs]<br />
* [http://users.isr.ist.utl.pt/~pedro/publications/CAMS10.pdf A Multiple Model Adaptive Wave Filter for Dynamic Ship Positioning]<br />
* [http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4449205&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4449205 Echosounder Depth Tracking with the Extended Kalman Filter]</div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:En:Depth_Data&diff=2958OpenSeaMap-dev:En:Depth Data2014-09-27T17:45:37Z<p>MartinOver: /* Baltic Sea Olpenitz (Germany) */</p>
<hr />
<div>This Page describes the necessary efforts to retrieve and analyze depth data as well as create renderings from it<br />
<br />
= Data Aquisition =<br />
Depth data can be retrieved from public domain sources or from crowd sourced data.<br />
<br />
== GEBCO ==<br />
DIe Daten sind gerendert und stehen als Layer zur Verfügung:<br />
{| class="wikitable"<br />
! Zoom || Inhalt<br />
|-<br />
| 0..10 || Blaustufen und Schattierung<br />
|-<br />
| 11..18 || beschriftete Tiefenlinien, Blaustufen und Schattierung<br />
|}<br />
<br />
Noch zu lösende Probleme:<br />
* der GEBCO-Layer erzeugt einen milchigen Schleier über der Basiskarte<br />
* Tiefenlinien sind ab z=14 etwas grob (also ab da, wo dann die Flachwassertiefen beginnen) [http://map.openseamap.org/?zoom=14&lat=36.03097&lon=-5.49153&layers=BFTFTTTFFFF0 Karte]<br />
* Überschneidungen von 100m-Linie und Küstenlinie [http://map.openseamap.org/?zoom=15&lat=36.00318&lon=-5.60819&layers=BFFFTTTFFFF0FFFFF Karte]<br />
* Steilküsten (Cuba) [http://map.openseamap.org/?zoom=14&lat=19.94808&lon=-76.04289&layers=BFTFTTTFFFF0 Karte]<br />
<br />
== Crowd Sourced Data ==<br />
Crowd sourced data may be gathered by YOU. There are two options in development. A hardware and a software option.<br />
<br />
=== Workflow ===<br />
[[Datei:Workflow_depth.png]]<br />
<br />
Here you can find the document with the previous thoughts about the workflow:<br />
[http://osm.franken.de/wiki/FWT-Projekt%C3%BCbersicht-NMEA2Contours_2.1.ppt PPT Dokument]<br />
<br />
=== Hardware logger ===<br />
We are currently developing a hardware logger that may easily be plugged to the ship's network in order to log the networks data to a SD card.<br />
That data may then be uploaded by plugging the SD card to a normal computer with internet connection for upload.<br />
The main goal is to support NMEA 0183 data with options for NMEA 2000.<br />
<br />
=== Software logger ===<br />
A [[Software logger]] is in development and [http://seesea.sourceforge.net/datalogger/index.html can be downloaded here]. <br />
<br />
It currently supports: <br />
: Bluetooth <br />
: Serial ports<br />
: Internet Protocol (IP)<br />
It processes NMEA 0183 and AIS data.<br />
<br />
For vendor specific protocols such as SeaTalk 1 you have to use a [[De:NMEA-Logger_anschliessen|converter]] to NMEA 0183 data.<br />
<br />
NMEA 2000 support is only available if data is transcoded to NMEA 0183 by a converter.<br />
<br />
=== Chart Plotters ===<br />
<br />
Some chart plotters are able to save tracks out-of-the-box, e.g. several Raymarine (FSH files) and Humminbird (SON files) devices. Those files may directly be used as data source.<br />
<br />
<br />
=== Upload Process ===<br />
Uploading data is possible through using the [http://seesea.sourceforge.net/datalogger/index.html OpenSeaMap Data Logger Software] or via [http://depth.openseamap.org/ Web Interface].<br />
The system is currently being tested. <br />
<br />
[[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|You'll find further information here]].<br />
<br />
=== Test Data ===<br />
<br />
<br />
==== Brombachsee (Germany)====<br />
<br />
Test data for Openseamap: [http://osm.franken.de/wiki/test_data_brombachsee.zip Brombachsee_Test_Data]<br />
<br />
dgm_brombachsee.tif: Digital Elevation Model of the sea derived from height lines WWA (C).<br />
<br />
shapes_brombachsee.shp: Shape File derived from 4 NMEA Tracks. "dbs" is the original Sounding and "deep_cor" the depth after a correction (gauge levl).<br />
<br />
gpx_brombachsee.gpx: ele = "dbs" from the Shape File<br />
<br />
[[Datei:Brombachsee.png]]<br />
Resulting Digital Elevation Model<br />
<br />
==== Baltic Sea - near Großenbrode (Germany)====<br />
<br />
First results with an RMS error < 1,5 meter compared to an official dataset of the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].<br />
<br />
[[Datei: Bsh_results_overview.jpg]]<br />
<br />
[Picture 1] '''''OSM map in background, raster Depth Model derived from BSH data and crowed sourced OpenSeaMap Points - Overview'''''<br />
<br />
Blue = flat BSH data, red = deep BSH data.<br />
<br>Blue points = OpenSeaMap raw measuring points.<br />
<br />
{| class="wikitable"<br />
|-<br />
| n || 5062<br />
|-<br />
|-<br />
| datasets || 21<br />
|-<br />
| max deviation || 3,43 meters<br />
|-<br />
| mean (abs) || 0,69 meters<br />
|-<br />
| RMS +/- || 0,91 meters<br />
|}<br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| Manufacturer || Bavaria Yachtbau<br />
|-<br />
| Model || B32<br />
|-<br />
| Length || 10,0 meters<br />
|-<br />
| Beam || 3,35 meters<br />
|-<br />
| Draft || 1,6 meters<br />
|-<br />
| Height || 14 meters<br />
|-<br />
| Displacement || 4,2 t<br />
|-<br />
| Sensor manufacturer || Raymarine<br />
|-<br />
| Sensor Offset to waterline || 0,45 meters<br />
|-<br />
| Sensor Offset to keel || 1,15 meters<br />
|}<br />
<br />
<br />
<br />
A digital Deep Model raster was computed from the BSH point dataset (c).<br />
The depth of the crowed sourced dataset was compared to the derived raster dataset from the BSH.<br />
The raw crowed sourced dataset was corrected by the sensor offset (0,45 meters).<br />
<br />
[[Datei: Scatter_cor_sensor.jpeg]]<br />
<br />
[Picture 2] '''''Scatter plot: BSH data on the x-axis and the crowed sourced data on the y-axis. Trend line in black and optimal line in red.'''''<br />
<br />
The deviation from the reference dataset increases with the depth measured.<br />
<br />
As you see in the picture below the difference between the datasets has an regular pattern maybe deepending on waves.<br />
<br />
[[Datei: Bsh_results_detail_10_classes.jpg]]<br />
<br />
[Picture 3] '''''Crowed sourced OpenSeaMap track points and the difference from the BSH dataset'''''<br />
<br />
White = low difference, orange = medium difference, red = strong difference<br />
<br />
Download of the data http://osm.franken.de/data/baltic_sea_test_data.zip<br />
'''Be aware of the copyright from the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].'''<br />
The data in the dataset is not corrected by sensor offset.<br />
<br />
==== Baltic Sea Olpenitz (Germany)====<br />
<br />
In the test area were tracks from two differnetvessel vessel configurations. <br />
The fist one was the one from the test area Großenbrode (config ID 68).<br />
<br />
In the Table below the settings for die vesselconfigid 110: <br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| VesselConfigId || 110<br />
|-<br />
| Manufacturer || Waarschip<br />
|-<br />
| Model || 570<br />
|-<br />
| Length || 5,7 meters<br />
|-<br />
| Beam || 2,45 meters<br />
|-<br />
| Draft || 1,0 meters<br />
|-<br />
| Height || 9.1 meters<br />
|-<br />
| Displacement || 0,8 t<br />
|-<br />
| Sensor manufacturer || Tacktick/ Airmar<br />
|-<br />
| Sensor Model || T912<br />
|-<br />
| Sensor Offset to waterline || 0,2 meters<br />
|-<br />
| Sensor Offset to keel || 0,45 meters<br />
|}<br />
<br />
=== Meta Data Statistics ===<br />
<br />
Statistics for the metadata entrees with some personal comments (by MartinOver). Stand 20.9.2014.<br />
<br />
{| class="prettytable"<br />
|-<br />
|<br />
'''Step'''<br />
<br />
|<br />
'''Topic'''<br />
<br />
|<br />
'''Count'''<br />
<br />
|<br />
'''State'''<br />
<br />
|<br />
'''Comment'''<br />
<br />
|-<br />
|<br />
1/1<br />
<br />
|<br />
Name<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
1/2<br />
<br />
|<br />
Description<br />
<br />
|<br />
76/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/1<br />
<br />
|<br />
Length<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
Some wrong entrees like mail addresses or comments <br />
<br />
24 “0.00” Values<br />
<br />
|-<br />
|<br />
2/2<br />
<br />
|<br />
Beam<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
37 „0.00“ Values<br />
<br />
|-<br />
|<br />
2/3<br />
<br />
|<br />
Draft<br />
<br />
|<br />
79/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/4<br />
<br />
|<br />
Displacement<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/5<br />
<br />
|<br />
Height<br />
<br />
|<br />
78/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/6<br />
<br />
|<br />
Manufacturer<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Model<br />
<br />
|<br />
49/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Type<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/3<br />
<br />
|<br />
Position below Waterline<br />
<br />
|<br />
57/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Should be Obligatory<br />
<br />
|-<br />
|<br />
3/4<br />
<br />
|<br />
Depth Measurement<br />
<br />
|<br />
?<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Where in DB?<br />
<br />
|-<br />
|<br />
3/5<br />
<br />
|<br />
Sensor Offset to Keel<br />
<br />
|<br />
6/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/6<br />
<br />
|<br />
Producer of Depth Sensor<br />
<br />
|<br />
63/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/7<br />
<br />
|<br />
Device Model<br />
<br />
|<br />
40/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
58 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
51 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/3<br />
<br />
|<br />
Position abbove Waterline<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/4<br />
<br />
|<br />
Producer<br />
<br />
|<br />
77/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/5<br />
<br />
|<br />
Model<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|}<br />
<br />
= Data Preprocessing =<br />
<br />
== Data Condition ==<br />
Raw data is usually erronous and must be corrected<br />
<br />
=== Internal data problems ===<br />
Depth data may be affected by electrical conditions and software implementations<br />
* Data is incomplete and fail their checksum (bus errors from physical transmissions errors)<br />
* Data is retrived out of sequence<br />
* Data is erronous sensor data <br />
** Approximate correctable data i.e. invalid GPS position that may be interpolated<br />
** Uncorrectable data i.e. failed log sensor that shows slow speeds<br />
* Data resolution is low i.e. for energy saving purposes GPS position is updated every 10 seconds instead of every second<br />
* Sensor data is actively miscalibrated i.e. charter companies add additional draft to the sensor depth for safety reasons<br />
<br />
=== External data problems ===<br />
Depth data may be affected by different environmental circumstances <br />
*# The water temperature affects the ultrasound echo. An inhomogen water temperature yields unwanted echos<br />
*# The seabed affects the ultrasound echo<br />
*# The seastate affects the measurement. There even may be waves when there is no wind.<br />
*# Waves may affect the roll of the measuring vessel resulting in steep measurements that are invalid.<br />
*# The sounder sensor is not the position of the GPS antenna. A position offset including heading must be incorporated.<br />
*# The time of the measurement need not correlate with the time the position was received. This may even happen due to processing time of the hard or software.<br />
*# Corrections for tide induced water levels must happen<br />
<br />
Solutions probably are<br />
*# Water temperature may be measure from the sensor, other data may be unavailable<br />
*# Modern sidescan sonar may yield information about the seabed through classifications<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# Position offsets must be provided by the user<br />
*# Time outages may be handled by the filter if precise timestamps are available in recorded data<br />
*# LAT to Mean sea level differences may be calculated from DTU10 worldwide, river gauges need to monitored<br />
<br />
[[Datei:LAT2MSLDiff.png]]<br />
<br />
<br />
== Data Condition Examples / Showcases ==<br />
<br />
=== Missing measurments (Position) ===<br />
Distribution for position updates taken from an example dataset. Left column shows the time between two consecutive measurements, right column shows how many measurements had this time update.<br />
One can see from the distribtion that the sensor is updated every second but many measurements are one or more seconds late.<br />
21 seconds with no position update may result in an instability of the subsequent filter.<br />
<pre><br />
MeasuredPosition3D<br />
GP<br />
0 :4285<br />
1000 :11295<br />
2000 :5056<br />
3000 :2134<br />
4000 :1135<br />
5000 :315<br />
6000 :154<br />
7000 :46<br />
8000 :36<br />
9000 :16<br />
10000 :12<br />
11000 :3<br />
12000 :4<br />
13000 :1<br />
14000 :7<br />
15000 :3<br />
16000 :1<br />
21000 :1<br />
</pre><br />
<br />
=== Missing measurments (Position) with erronous clock ===<br />
This example is at a 10 second position update rate. However the measurment time is faulty causing large negative and positive update rates. The clock jumps by +- one year/month/day/hour. One can further see from the many 0 time measurements that the rate at which data is sent to the nmea bus is higher than the actual position update (data is sent every second, a position update is every 10 seconds)<br />
<pre><br />
MeasuredPosition3D<br />
II<br />
-21340000 :1<br />
-13194000 :1<br />
-7998000 :1<br />
-2674000 :1<br />
-2434000 :1<br />
-2402000 :1<br />
-2030000 :1<br />
-1926000 :1<br />
-1894000 :1<br />
-1806000 :1<br />
-1480000 :1<br />
-1430000 :1<br />
-1382000 :1<br />
-1114000 :1<br />
-814000 :1<br />
-634000 :1<br />
-590000 :1<br />
-546000 :1<br />
-470000 :1<br />
-290000 :1<br />
-230000 :1<br />
-198000 :1<br />
-110000 :1<br />
-94000 :2<br />
0 :182200<br />
5000 :1<br />
10000 :20230<br />
15000 :1<br />
20000 :84<br />
50000 :1<br />
114000 :2<br />
130000 :2<br />
218000 :1<br />
250000 :1<br />
310000 :1<br />
490000 :1<br />
566000 :1<br />
610000 :1<br />
654000 :1<br />
834000 :1<br />
1134000 :1<br />
1402000 :1<br />
1450000 :1</pre><br />
<br />
== Solution Proposal ==<br />
<br />
=== Outline ===<br />
The ship is influenced by the outlined environment which can be observed. Naturally what is observed is not the state of the<br />
ship as i.e. the position if taken from GPS is 95% less than 10m accurate. To improve quality an estimation of the true state yields better results if this noise taken into account properly.<br />
<br />
=== Details ===<br />
The ship moves according to physical laws. For the easist case imagine a ship with constant velocity and direction. For any point in time you can tell where the ship is with easy math. Considering the full blown setup a ships movement is affected by many parameters such as wind speed, water current, waves, tide, and many more. The ship moves also triaxial in a dynamic way in itself (roll, pitch, yaw). Heeling even changes the measurement position with respect to the depth position. In terms of a filter this is called a system model that describes how the state of the ship may change. Given such a state you can measure what your sensor readings are and compare that to where the system thinks you are.<br />
<br />
The [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter] is known to be the best linear estimator for such situations. Unfortunately the system model is not linear which is why the Extended Kalman Filter needs to be used in order to linearize the system at hand.<br />
<br />
Todo:<br />
* Construct ship system model with at least the position state and probably its course and speed or even more (depth)<br />
* Estimate the system variance (This is a hard one, proposals welcome)<br />
* Construct the measurement model according to the data available (GPS, Log)<br />
* Estimate the measurement noise according to specifc sensors (DPGS is more accurate than GPS)<br />
<br />
The estimation with the position and depth can be retrieved and stored in a database.<br />
<br />
Pitfalls:<br />
* If the system noise is badly chosen the estimation of the system state does not converge to the true state / measurement.<br />
* If the system is very detailed the system variance can be reduced. The required cpu time for processing increases<br />
<br />
Benefits:<br />
* Having the best estimation of the true position even if measurements are noisy<br />
* Easy and effective algorithmic processing<br />
<br />
== Analysis == <br />
<br />
=== Data Sets ===<br />
Currently two test data sets are available recorded during trips from Mallorca and the Baltic Sea.<br />
In terms of data quality the Mallorca data shows many challenges. <br />
* The minimum recommended sentences from NMEA showed up with false date and time readings while having correct (!!!) message checksums. <br />
* The log on the ship was defective and delivered no readings from time to time. <br />
* The same holds true for the water temperature.<br />
* The GPS positions relatively imprecise because some last decimal digits are missing in the recordings.<br />
* The GPS positions are updated every 10 seconds while other sensor readings update almost every second.<br />
* The GPS position are sometimes way off due to false readings<br />
<br />
The Baltic Sea data set is a little bit better<br />
* Only a single day is available<br />
* GPS positions are updated every second<br />
<br />
One problem with the data is that there is time available when sensor readings were recorded. This yields problems to the filter algorithm.<br />
<br />
<br />
=== Filter Algorithm ===<br />
At first the Extended Kalman Filter is being analyzed. Using an apache implementation with the available data the filter quickly throw an exception that<br />
a matrix is not invertible because of numeric instabilities. When removing this exception the filter seems to work but the removal and its effects have yet to be analyzed.<br />
Literature suggest that a fixed interval smoother may yield better results in case of offline data processing. As it is an extension to the existing kalman filter<br />
we may consider that for the future.<br />
<br />
One problem are the different update rates of the sensors. As GPS may deliver positions at 0.1Hz speed is updated at 1Hz. Literature suggests that<br />
the missing measurements shell be modelled as a random variable with the standard deviation of the sensor. It may even be possible to update covariance matrices only partially with the sensor readings received. Input for the best solution may be formulated on the developer mailing list.<br />
<br />
== Results == <br />
A prototype implementation is shown in the following screenshots. An Extended Kalman Filter is being used. It has the position<br />
and the current bearing and velocity as system state. The input is the measurement of these four observables. The system function is<br />
good old pythagoras. In a first implementation I tried to use orthodrome distances but the system function is not differentiable which is a requirement of the Extended Kalman Filter (due to acrtan2). For small distances pythagoras should be sufficiently accurate. <br />
The initial state is taken from the first measurement for convergence reasons.<br />
<br />
The following gallery shows the results. <br />
* You can see the bad position resolution and an outlier in the first screenshot.<br />
* The second shows the same data overlaid with the applied filter. The outlier is gone and the resolution has improved.<br />
* The third screenshot shows data from a different GPS sensor with more precision (not DGPS) versus the filtered data.<br />
<br />
This of course is just a preliminary test and many setups need to be considered to make it work for most datasets.<br />
<br />
<gallery><br />
UnfilteredNMEA.png | Unfiltered GPS data<br />
FilteredNMEAVsOriginal.png | Unfiltered GPS data and Filtered GPS data<br />
PreciseGPSvsFilter.png | Another precise GPS vs Filtered GPS data<br />
</gallery><br />
<br />
The overall process even gives an estimation of the current error which is a capability of the [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter].<br />
This way positional inaccuracies may be added to the overall depth measurement inaccuracy.<br />
<br />
== Quality rating ==<br />
<br />
Each record (time, positon, depth) should become a quality rating.<br />
<br />
=== Points ===<br />
<br />
Derived from the Fibonacci series.<br />
<br />
{| class="wikitable"<br />
! Point || Description<br />
|-<br />
| 1 || extra small improvement<br />
|-<br />
| 2 || small improvement<br />
|-<br />
| 3 || medium improvement<br />
|-<br />
| 5 || large improvement<br />
|-<br />
| 8 || extra large improvement<br />
|}<br />
<br />
=== Factors ===<br />
<br />
{| class="wikitable"<br />
! style="width:15%" | Name<br />
! style="width:17%" | Factor<br />
! style="width:68%" | Description<br />
|-<br />
| depth offset || 8 (extra large) || The difference between the depth measured by the echo sounder and the depth (waterline) measured by hand.<br />
|-<br />
| device distance || 3 (medium) || The distance between gps antenna and echo sounder (lengthwise and crosswise).<br />
|-<br />
| SBAS || 3 (medium) || Satellite based augmentation system (WAAS, EGNOS, MSAS) which allows to correct the gps position.<br />
|-<br />
| position interpolation || 2 (small improvement) || Arrival of depth and position packets can have a time difference. It is/should be possible to interpolate the position.<br />
|}<br />
<br />
= Depth Rendering =<br />
<br />
= Siehe auch =<br />
* [[De:Bordnetz|Bordnetz]]<br />
* [[De:NMEA-Logger_anschliessen|NMEA-Logger_anschliessen]]<br />
* [http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCkQFjAA&url=http%3A%2F%2Fwww.dei.unipd.it%2F~chiuso%2FDOWNLOAD%2FPositioning_Heading_Kalman.pdf&ei=sSWNUMWnL4eC4gTRlYHAAw&usg=AFQjCNHq5V-PePNmDTZaGYvq0JeQFgqHVw Kalman Filtering for Positioning and Heading Control of Ships and Offshore Rigs]<br />
* [http://users.isr.ist.utl.pt/~pedro/publications/CAMS10.pdf A Multiple Model Adaptive Wave Filter for Dynamic Ship Positioning]<br />
* [http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4449205&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4449205 Echosounder Depth Tracking with the Extended Kalman Filter]</div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:En:Depth_Data&diff=2957OpenSeaMap-dev:En:Depth Data2014-09-27T17:45:13Z<p>MartinOver: /* Baltic Sea Olpenitz (Germany) */</p>
<hr />
<div>This Page describes the necessary efforts to retrieve and analyze depth data as well as create renderings from it<br />
<br />
= Data Aquisition =<br />
Depth data can be retrieved from public domain sources or from crowd sourced data.<br />
<br />
== GEBCO ==<br />
DIe Daten sind gerendert und stehen als Layer zur Verfügung:<br />
{| class="wikitable"<br />
! Zoom || Inhalt<br />
|-<br />
| 0..10 || Blaustufen und Schattierung<br />
|-<br />
| 11..18 || beschriftete Tiefenlinien, Blaustufen und Schattierung<br />
|}<br />
<br />
Noch zu lösende Probleme:<br />
* der GEBCO-Layer erzeugt einen milchigen Schleier über der Basiskarte<br />
* Tiefenlinien sind ab z=14 etwas grob (also ab da, wo dann die Flachwassertiefen beginnen) [http://map.openseamap.org/?zoom=14&lat=36.03097&lon=-5.49153&layers=BFTFTTTFFFF0 Karte]<br />
* Überschneidungen von 100m-Linie und Küstenlinie [http://map.openseamap.org/?zoom=15&lat=36.00318&lon=-5.60819&layers=BFFFTTTFFFF0FFFFF Karte]<br />
* Steilküsten (Cuba) [http://map.openseamap.org/?zoom=14&lat=19.94808&lon=-76.04289&layers=BFTFTTTFFFF0 Karte]<br />
<br />
== Crowd Sourced Data ==<br />
Crowd sourced data may be gathered by YOU. There are two options in development. A hardware and a software option.<br />
<br />
=== Workflow ===<br />
[[Datei:Workflow_depth.png]]<br />
<br />
Here you can find the document with the previous thoughts about the workflow:<br />
[http://osm.franken.de/wiki/FWT-Projekt%C3%BCbersicht-NMEA2Contours_2.1.ppt PPT Dokument]<br />
<br />
=== Hardware logger ===<br />
We are currently developing a hardware logger that may easily be plugged to the ship's network in order to log the networks data to a SD card.<br />
That data may then be uploaded by plugging the SD card to a normal computer with internet connection for upload.<br />
The main goal is to support NMEA 0183 data with options for NMEA 2000.<br />
<br />
=== Software logger ===<br />
A [[Software logger]] is in development and [http://seesea.sourceforge.net/datalogger/index.html can be downloaded here]. <br />
<br />
It currently supports: <br />
: Bluetooth <br />
: Serial ports<br />
: Internet Protocol (IP)<br />
It processes NMEA 0183 and AIS data.<br />
<br />
For vendor specific protocols such as SeaTalk 1 you have to use a [[De:NMEA-Logger_anschliessen|converter]] to NMEA 0183 data.<br />
<br />
NMEA 2000 support is only available if data is transcoded to NMEA 0183 by a converter.<br />
<br />
=== Chart Plotters ===<br />
<br />
Some chart plotters are able to save tracks out-of-the-box, e.g. several Raymarine (FSH files) and Humminbird (SON files) devices. Those files may directly be used as data source.<br />
<br />
<br />
=== Upload Process ===<br />
Uploading data is possible through using the [http://seesea.sourceforge.net/datalogger/index.html OpenSeaMap Data Logger Software] or via [http://depth.openseamap.org/ Web Interface].<br />
The system is currently being tested. <br />
<br />
[[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|You'll find further information here]].<br />
<br />
=== Test Data ===<br />
<br />
<br />
==== Brombachsee (Germany)====<br />
<br />
Test data for Openseamap: [http://osm.franken.de/wiki/test_data_brombachsee.zip Brombachsee_Test_Data]<br />
<br />
dgm_brombachsee.tif: Digital Elevation Model of the sea derived from height lines WWA (C).<br />
<br />
shapes_brombachsee.shp: Shape File derived from 4 NMEA Tracks. "dbs" is the original Sounding and "deep_cor" the depth after a correction (gauge levl).<br />
<br />
gpx_brombachsee.gpx: ele = "dbs" from the Shape File<br />
<br />
[[Datei:Brombachsee.png]]<br />
Resulting Digital Elevation Model<br />
<br />
==== Baltic Sea - near Großenbrode (Germany)====<br />
<br />
First results with an RMS error < 1,5 meter compared to an official dataset of the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].<br />
<br />
[[Datei: Bsh_results_overview.jpg]]<br />
<br />
[Picture 1] '''''OSM map in background, raster Depth Model derived from BSH data and crowed sourced OpenSeaMap Points - Overview'''''<br />
<br />
Blue = flat BSH data, red = deep BSH data.<br />
<br>Blue points = OpenSeaMap raw measuring points.<br />
<br />
{| class="wikitable"<br />
|-<br />
| n || 5062<br />
|-<br />
|-<br />
| datasets || 21<br />
|-<br />
| max deviation || 3,43 meters<br />
|-<br />
| mean (abs) || 0,69 meters<br />
|-<br />
| RMS +/- || 0,91 meters<br />
|}<br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| Manufacturer || Bavaria Yachtbau<br />
|-<br />
| Model || B32<br />
|-<br />
| Length || 10,0 meters<br />
|-<br />
| Beam || 3,35 meters<br />
|-<br />
| Draft || 1,6 meters<br />
|-<br />
| Height || 14 meters<br />
|-<br />
| Displacement || 4,2 t<br />
|-<br />
| Sensor manufacturer || Raymarine<br />
|-<br />
| Sensor Offset to waterline || 0,45 meters<br />
|-<br />
| Sensor Offset to keel || 1,15 meters<br />
|}<br />
<br />
<br />
<br />
A digital Deep Model raster was computed from the BSH point dataset (c).<br />
The depth of the crowed sourced dataset was compared to the derived raster dataset from the BSH.<br />
The raw crowed sourced dataset was corrected by the sensor offset (0,45 meters).<br />
<br />
[[Datei: Scatter_cor_sensor.jpeg]]<br />
<br />
[Picture 2] '''''Scatter plot: BSH data on the x-axis and the crowed sourced data on the y-axis. Trend line in black and optimal line in red.'''''<br />
<br />
The deviation from the reference dataset increases with the depth measured.<br />
<br />
As you see in the picture below the difference between the datasets has an regular pattern maybe deepending on waves.<br />
<br />
[[Datei: Bsh_results_detail_10_classes.jpg]]<br />
<br />
[Picture 3] '''''Crowed sourced OpenSeaMap track points and the difference from the BSH dataset'''''<br />
<br />
White = low difference, orange = medium difference, red = strong difference<br />
<br />
Download of the data http://osm.franken.de/data/baltic_sea_test_data.zip<br />
'''Be aware of the copyright from the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].'''<br />
The data in the dataset is not corrected by sensor offset.<br />
<br />
==== Baltic Sea Olpenitz (Germany)====<br />
<br />
In the test area were tracks from two differnetvessel configurations. <br />
The fist one was the one from the test area Großenbrode (config ID 68).<br />
<br />
In the Table below the settings for die vesselconfigid 110: <br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| VesselConfigId || 110<br />
|-<br />
| Manufacturer || Waarschip<br />
|-<br />
| Model || 570<br />
|-<br />
| Length || 5,7 meters<br />
|-<br />
| Beam || 2,45 meters<br />
|-<br />
| Draft || 1,0 meters<br />
|-<br />
| Height || 9.1 meters<br />
|-<br />
| Displacement || 0,8 t<br />
|-<br />
| Sensor manufacturer || Tacktick/ Airmar<br />
|-<br />
| Sensor Model || T912<br />
|-<br />
| Sensor Offset to waterline || 0,2 meters<br />
|-<br />
| Sensor Offset to keel || 0,45 meters<br />
|}<br />
<br />
=== Meta Data Statistics ===<br />
<br />
Statistics for the metadata entrees with some personal comments (by MartinOver). Stand 20.9.2014.<br />
<br />
{| class="prettytable"<br />
|-<br />
|<br />
'''Step'''<br />
<br />
|<br />
'''Topic'''<br />
<br />
|<br />
'''Count'''<br />
<br />
|<br />
'''State'''<br />
<br />
|<br />
'''Comment'''<br />
<br />
|-<br />
|<br />
1/1<br />
<br />
|<br />
Name<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
1/2<br />
<br />
|<br />
Description<br />
<br />
|<br />
76/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/1<br />
<br />
|<br />
Length<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
Some wrong entrees like mail addresses or comments <br />
<br />
24 “0.00” Values<br />
<br />
|-<br />
|<br />
2/2<br />
<br />
|<br />
Beam<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
37 „0.00“ Values<br />
<br />
|-<br />
|<br />
2/3<br />
<br />
|<br />
Draft<br />
<br />
|<br />
79/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/4<br />
<br />
|<br />
Displacement<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/5<br />
<br />
|<br />
Height<br />
<br />
|<br />
78/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/6<br />
<br />
|<br />
Manufacturer<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Model<br />
<br />
|<br />
49/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Type<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/3<br />
<br />
|<br />
Position below Waterline<br />
<br />
|<br />
57/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Should be Obligatory<br />
<br />
|-<br />
|<br />
3/4<br />
<br />
|<br />
Depth Measurement<br />
<br />
|<br />
?<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Where in DB?<br />
<br />
|-<br />
|<br />
3/5<br />
<br />
|<br />
Sensor Offset to Keel<br />
<br />
|<br />
6/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/6<br />
<br />
|<br />
Producer of Depth Sensor<br />
<br />
|<br />
63/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/7<br />
<br />
|<br />
Device Model<br />
<br />
|<br />
40/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
58 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
51 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/3<br />
<br />
|<br />
Position abbove Waterline<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/4<br />
<br />
|<br />
Producer<br />
<br />
|<br />
77/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/5<br />
<br />
|<br />
Model<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|}<br />
<br />
= Data Preprocessing =<br />
<br />
== Data Condition ==<br />
Raw data is usually erronous and must be corrected<br />
<br />
=== Internal data problems ===<br />
Depth data may be affected by electrical conditions and software implementations<br />
* Data is incomplete and fail their checksum (bus errors from physical transmissions errors)<br />
* Data is retrived out of sequence<br />
* Data is erronous sensor data <br />
** Approximate correctable data i.e. invalid GPS position that may be interpolated<br />
** Uncorrectable data i.e. failed log sensor that shows slow speeds<br />
* Data resolution is low i.e. for energy saving purposes GPS position is updated every 10 seconds instead of every second<br />
* Sensor data is actively miscalibrated i.e. charter companies add additional draft to the sensor depth for safety reasons<br />
<br />
=== External data problems ===<br />
Depth data may be affected by different environmental circumstances <br />
*# The water temperature affects the ultrasound echo. An inhomogen water temperature yields unwanted echos<br />
*# The seabed affects the ultrasound echo<br />
*# The seastate affects the measurement. There even may be waves when there is no wind.<br />
*# Waves may affect the roll of the measuring vessel resulting in steep measurements that are invalid.<br />
*# The sounder sensor is not the position of the GPS antenna. A position offset including heading must be incorporated.<br />
*# The time of the measurement need not correlate with the time the position was received. This may even happen due to processing time of the hard or software.<br />
*# Corrections for tide induced water levels must happen<br />
<br />
Solutions probably are<br />
*# Water temperature may be measure from the sensor, other data may be unavailable<br />
*# Modern sidescan sonar may yield information about the seabed through classifications<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# Position offsets must be provided by the user<br />
*# Time outages may be handled by the filter if precise timestamps are available in recorded data<br />
*# LAT to Mean sea level differences may be calculated from DTU10 worldwide, river gauges need to monitored<br />
<br />
[[Datei:LAT2MSLDiff.png]]<br />
<br />
<br />
== Data Condition Examples / Showcases ==<br />
<br />
=== Missing measurments (Position) ===<br />
Distribution for position updates taken from an example dataset. Left column shows the time between two consecutive measurements, right column shows how many measurements had this time update.<br />
One can see from the distribtion that the sensor is updated every second but many measurements are one or more seconds late.<br />
21 seconds with no position update may result in an instability of the subsequent filter.<br />
<pre><br />
MeasuredPosition3D<br />
GP<br />
0 :4285<br />
1000 :11295<br />
2000 :5056<br />
3000 :2134<br />
4000 :1135<br />
5000 :315<br />
6000 :154<br />
7000 :46<br />
8000 :36<br />
9000 :16<br />
10000 :12<br />
11000 :3<br />
12000 :4<br />
13000 :1<br />
14000 :7<br />
15000 :3<br />
16000 :1<br />
21000 :1<br />
</pre><br />
<br />
=== Missing measurments (Position) with erronous clock ===<br />
This example is at a 10 second position update rate. However the measurment time is faulty causing large negative and positive update rates. The clock jumps by +- one year/month/day/hour. One can further see from the many 0 time measurements that the rate at which data is sent to the nmea bus is higher than the actual position update (data is sent every second, a position update is every 10 seconds)<br />
<pre><br />
MeasuredPosition3D<br />
II<br />
-21340000 :1<br />
-13194000 :1<br />
-7998000 :1<br />
-2674000 :1<br />
-2434000 :1<br />
-2402000 :1<br />
-2030000 :1<br />
-1926000 :1<br />
-1894000 :1<br />
-1806000 :1<br />
-1480000 :1<br />
-1430000 :1<br />
-1382000 :1<br />
-1114000 :1<br />
-814000 :1<br />
-634000 :1<br />
-590000 :1<br />
-546000 :1<br />
-470000 :1<br />
-290000 :1<br />
-230000 :1<br />
-198000 :1<br />
-110000 :1<br />
-94000 :2<br />
0 :182200<br />
5000 :1<br />
10000 :20230<br />
15000 :1<br />
20000 :84<br />
50000 :1<br />
114000 :2<br />
130000 :2<br />
218000 :1<br />
250000 :1<br />
310000 :1<br />
490000 :1<br />
566000 :1<br />
610000 :1<br />
654000 :1<br />
834000 :1<br />
1134000 :1<br />
1402000 :1<br />
1450000 :1</pre><br />
<br />
== Solution Proposal ==<br />
<br />
=== Outline ===<br />
The ship is influenced by the outlined environment which can be observed. Naturally what is observed is not the state of the<br />
ship as i.e. the position if taken from GPS is 95% less than 10m accurate. To improve quality an estimation of the true state yields better results if this noise taken into account properly.<br />
<br />
=== Details ===<br />
The ship moves according to physical laws. For the easist case imagine a ship with constant velocity and direction. For any point in time you can tell where the ship is with easy math. Considering the full blown setup a ships movement is affected by many parameters such as wind speed, water current, waves, tide, and many more. The ship moves also triaxial in a dynamic way in itself (roll, pitch, yaw). Heeling even changes the measurement position with respect to the depth position. In terms of a filter this is called a system model that describes how the state of the ship may change. Given such a state you can measure what your sensor readings are and compare that to where the system thinks you are.<br />
<br />
The [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter] is known to be the best linear estimator for such situations. Unfortunately the system model is not linear which is why the Extended Kalman Filter needs to be used in order to linearize the system at hand.<br />
<br />
Todo:<br />
* Construct ship system model with at least the position state and probably its course and speed or even more (depth)<br />
* Estimate the system variance (This is a hard one, proposals welcome)<br />
* Construct the measurement model according to the data available (GPS, Log)<br />
* Estimate the measurement noise according to specifc sensors (DPGS is more accurate than GPS)<br />
<br />
The estimation with the position and depth can be retrieved and stored in a database.<br />
<br />
Pitfalls:<br />
* If the system noise is badly chosen the estimation of the system state does not converge to the true state / measurement.<br />
* If the system is very detailed the system variance can be reduced. The required cpu time for processing increases<br />
<br />
Benefits:<br />
* Having the best estimation of the true position even if measurements are noisy<br />
* Easy and effective algorithmic processing<br />
<br />
== Analysis == <br />
<br />
=== Data Sets ===<br />
Currently two test data sets are available recorded during trips from Mallorca and the Baltic Sea.<br />
In terms of data quality the Mallorca data shows many challenges. <br />
* The minimum recommended sentences from NMEA showed up with false date and time readings while having correct (!!!) message checksums. <br />
* The log on the ship was defective and delivered no readings from time to time. <br />
* The same holds true for the water temperature.<br />
* The GPS positions relatively imprecise because some last decimal digits are missing in the recordings.<br />
* The GPS positions are updated every 10 seconds while other sensor readings update almost every second.<br />
* The GPS position are sometimes way off due to false readings<br />
<br />
The Baltic Sea data set is a little bit better<br />
* Only a single day is available<br />
* GPS positions are updated every second<br />
<br />
One problem with the data is that there is time available when sensor readings were recorded. This yields problems to the filter algorithm.<br />
<br />
<br />
=== Filter Algorithm ===<br />
At first the Extended Kalman Filter is being analyzed. Using an apache implementation with the available data the filter quickly throw an exception that<br />
a matrix is not invertible because of numeric instabilities. When removing this exception the filter seems to work but the removal and its effects have yet to be analyzed.<br />
Literature suggest that a fixed interval smoother may yield better results in case of offline data processing. As it is an extension to the existing kalman filter<br />
we may consider that for the future.<br />
<br />
One problem are the different update rates of the sensors. As GPS may deliver positions at 0.1Hz speed is updated at 1Hz. Literature suggests that<br />
the missing measurements shell be modelled as a random variable with the standard deviation of the sensor. It may even be possible to update covariance matrices only partially with the sensor readings received. Input for the best solution may be formulated on the developer mailing list.<br />
<br />
== Results == <br />
A prototype implementation is shown in the following screenshots. An Extended Kalman Filter is being used. It has the position<br />
and the current bearing and velocity as system state. The input is the measurement of these four observables. The system function is<br />
good old pythagoras. In a first implementation I tried to use orthodrome distances but the system function is not differentiable which is a requirement of the Extended Kalman Filter (due to acrtan2). For small distances pythagoras should be sufficiently accurate. <br />
The initial state is taken from the first measurement for convergence reasons.<br />
<br />
The following gallery shows the results. <br />
* You can see the bad position resolution and an outlier in the first screenshot.<br />
* The second shows the same data overlaid with the applied filter. The outlier is gone and the resolution has improved.<br />
* The third screenshot shows data from a different GPS sensor with more precision (not DGPS) versus the filtered data.<br />
<br />
This of course is just a preliminary test and many setups need to be considered to make it work for most datasets.<br />
<br />
<gallery><br />
UnfilteredNMEA.png | Unfiltered GPS data<br />
FilteredNMEAVsOriginal.png | Unfiltered GPS data and Filtered GPS data<br />
PreciseGPSvsFilter.png | Another precise GPS vs Filtered GPS data<br />
</gallery><br />
<br />
The overall process even gives an estimation of the current error which is a capability of the [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter].<br />
This way positional inaccuracies may be added to the overall depth measurement inaccuracy.<br />
<br />
== Quality rating ==<br />
<br />
Each record (time, positon, depth) should become a quality rating.<br />
<br />
=== Points ===<br />
<br />
Derived from the Fibonacci series.<br />
<br />
{| class="wikitable"<br />
! Point || Description<br />
|-<br />
| 1 || extra small improvement<br />
|-<br />
| 2 || small improvement<br />
|-<br />
| 3 || medium improvement<br />
|-<br />
| 5 || large improvement<br />
|-<br />
| 8 || extra large improvement<br />
|}<br />
<br />
=== Factors ===<br />
<br />
{| class="wikitable"<br />
! style="width:15%" | Name<br />
! style="width:17%" | Factor<br />
! style="width:68%" | Description<br />
|-<br />
| depth offset || 8 (extra large) || The difference between the depth measured by the echo sounder and the depth (waterline) measured by hand.<br />
|-<br />
| device distance || 3 (medium) || The distance between gps antenna and echo sounder (lengthwise and crosswise).<br />
|-<br />
| SBAS || 3 (medium) || Satellite based augmentation system (WAAS, EGNOS, MSAS) which allows to correct the gps position.<br />
|-<br />
| position interpolation || 2 (small improvement) || Arrival of depth and position packets can have a time difference. It is/should be possible to interpolate the position.<br />
|}<br />
<br />
= Depth Rendering =<br />
<br />
= Siehe auch =<br />
* [[De:Bordnetz|Bordnetz]]<br />
* [[De:NMEA-Logger_anschliessen|NMEA-Logger_anschliessen]]<br />
* [http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCkQFjAA&url=http%3A%2F%2Fwww.dei.unipd.it%2F~chiuso%2FDOWNLOAD%2FPositioning_Heading_Kalman.pdf&ei=sSWNUMWnL4eC4gTRlYHAAw&usg=AFQjCNHq5V-PePNmDTZaGYvq0JeQFgqHVw Kalman Filtering for Positioning and Heading Control of Ships and Offshore Rigs]<br />
* [http://users.isr.ist.utl.pt/~pedro/publications/CAMS10.pdf A Multiple Model Adaptive Wave Filter for Dynamic Ship Positioning]<br />
* [http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4449205&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4449205 Echosounder Depth Tracking with the Extended Kalman Filter]</div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:En:Depth_Data&diff=2956OpenSeaMap-dev:En:Depth Data2014-09-27T17:33:55Z<p>MartinOver: /* Test Data */</p>
<hr />
<div>This Page describes the necessary efforts to retrieve and analyze depth data as well as create renderings from it<br />
<br />
= Data Aquisition =<br />
Depth data can be retrieved from public domain sources or from crowd sourced data.<br />
<br />
== GEBCO ==<br />
DIe Daten sind gerendert und stehen als Layer zur Verfügung:<br />
{| class="wikitable"<br />
! Zoom || Inhalt<br />
|-<br />
| 0..10 || Blaustufen und Schattierung<br />
|-<br />
| 11..18 || beschriftete Tiefenlinien, Blaustufen und Schattierung<br />
|}<br />
<br />
Noch zu lösende Probleme:<br />
* der GEBCO-Layer erzeugt einen milchigen Schleier über der Basiskarte<br />
* Tiefenlinien sind ab z=14 etwas grob (also ab da, wo dann die Flachwassertiefen beginnen) [http://map.openseamap.org/?zoom=14&lat=36.03097&lon=-5.49153&layers=BFTFTTTFFFF0 Karte]<br />
* Überschneidungen von 100m-Linie und Küstenlinie [http://map.openseamap.org/?zoom=15&lat=36.00318&lon=-5.60819&layers=BFFFTTTFFFF0FFFFF Karte]<br />
* Steilküsten (Cuba) [http://map.openseamap.org/?zoom=14&lat=19.94808&lon=-76.04289&layers=BFTFTTTFFFF0 Karte]<br />
<br />
== Crowd Sourced Data ==<br />
Crowd sourced data may be gathered by YOU. There are two options in development. A hardware and a software option.<br />
<br />
=== Workflow ===<br />
[[Datei:Workflow_depth.png]]<br />
<br />
Here you can find the document with the previous thoughts about the workflow:<br />
[http://osm.franken.de/wiki/FWT-Projekt%C3%BCbersicht-NMEA2Contours_2.1.ppt PPT Dokument]<br />
<br />
=== Hardware logger ===<br />
We are currently developing a hardware logger that may easily be plugged to the ship's network in order to log the networks data to a SD card.<br />
That data may then be uploaded by plugging the SD card to a normal computer with internet connection for upload.<br />
The main goal is to support NMEA 0183 data with options for NMEA 2000.<br />
<br />
=== Software logger ===<br />
A [[Software logger]] is in development and [http://seesea.sourceforge.net/datalogger/index.html can be downloaded here]. <br />
<br />
It currently supports: <br />
: Bluetooth <br />
: Serial ports<br />
: Internet Protocol (IP)<br />
It processes NMEA 0183 and AIS data.<br />
<br />
For vendor specific protocols such as SeaTalk 1 you have to use a [[De:NMEA-Logger_anschliessen|converter]] to NMEA 0183 data.<br />
<br />
NMEA 2000 support is only available if data is transcoded to NMEA 0183 by a converter.<br />
<br />
=== Chart Plotters ===<br />
<br />
Some chart plotters are able to save tracks out-of-the-box, e.g. several Raymarine (FSH files) and Humminbird (SON files) devices. Those files may directly be used as data source.<br />
<br />
<br />
=== Upload Process ===<br />
Uploading data is possible through using the [http://seesea.sourceforge.net/datalogger/index.html OpenSeaMap Data Logger Software] or via [http://depth.openseamap.org/ Web Interface].<br />
The system is currently being tested. <br />
<br />
[[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|You'll find further information here]].<br />
<br />
=== Test Data ===<br />
<br />
<br />
==== Brombachsee (Germany)====<br />
<br />
Test data for Openseamap: [http://osm.franken.de/wiki/test_data_brombachsee.zip Brombachsee_Test_Data]<br />
<br />
dgm_brombachsee.tif: Digital Elevation Model of the sea derived from height lines WWA (C).<br />
<br />
shapes_brombachsee.shp: Shape File derived from 4 NMEA Tracks. "dbs" is the original Sounding and "deep_cor" the depth after a correction (gauge levl).<br />
<br />
gpx_brombachsee.gpx: ele = "dbs" from the Shape File<br />
<br />
[[Datei:Brombachsee.png]]<br />
Resulting Digital Elevation Model<br />
<br />
==== Baltic Sea - near Großenbrode (Germany)====<br />
<br />
First results with an RMS error < 1,5 meter compared to an official dataset of the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].<br />
<br />
[[Datei: Bsh_results_overview.jpg]]<br />
<br />
[Picture 1] '''''OSM map in background, raster Depth Model derived from BSH data and crowed sourced OpenSeaMap Points - Overview'''''<br />
<br />
Blue = flat BSH data, red = deep BSH data.<br />
<br>Blue points = OpenSeaMap raw measuring points.<br />
<br />
{| class="wikitable"<br />
|-<br />
| n || 5062<br />
|-<br />
|-<br />
| datasets || 21<br />
|-<br />
| max deviation || 3,43 meters<br />
|-<br />
| mean (abs) || 0,69 meters<br />
|-<br />
| RMS +/- || 0,91 meters<br />
|}<br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| Manufacturer || Bavaria Yachtbau<br />
|-<br />
| Model || B32<br />
|-<br />
| Length || 10,0 meters<br />
|-<br />
| Beam || 3,35 meters<br />
|-<br />
| Draft || 1,6 meters<br />
|-<br />
| Height || 14 meters<br />
|-<br />
| Displacement || 4,2 t<br />
|-<br />
| Sensor manufacturer || Raymarine<br />
|-<br />
| Sensor Offset to waterline || 0,45 meters<br />
|-<br />
| Sensor Offset to keel || 1,15 meters<br />
|}<br />
<br />
<br />
<br />
A digital Deep Model raster was computed from the BSH point dataset (c).<br />
The depth of the crowed sourced dataset was compared to the derived raster dataset from the BSH.<br />
The raw crowed sourced dataset was corrected by the sensor offset (0,45 meters).<br />
<br />
[[Datei: Scatter_cor_sensor.jpeg]]<br />
<br />
[Picture 2] '''''Scatter plot: BSH data on the x-axis and the crowed sourced data on the y-axis. Trend line in black and optimal line in red.'''''<br />
<br />
The deviation from the reference dataset increases with the depth measured.<br />
<br />
As you see in the picture below the difference between the datasets has an regular pattern maybe deepending on waves.<br />
<br />
[[Datei: Bsh_results_detail_10_classes.jpg]]<br />
<br />
[Picture 3] '''''Crowed sourced OpenSeaMap track points and the difference from the BSH dataset'''''<br />
<br />
White = low difference, orange = medium difference, red = strong difference<br />
<br />
Download of the data http://osm.franken.de/data/baltic_sea_test_data.zip<br />
'''Be aware of the copyright from the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].'''<br />
The data in the dataset is not corrected by sensor offset.<br />
<br />
==== Baltic Sea Olpenitz (Germany)====<br />
<br />
=== Meta Data Statistics ===<br />
<br />
Statistics for the metadata entrees with some personal comments (by MartinOver). Stand 20.9.2014.<br />
<br />
{| class="prettytable"<br />
|-<br />
|<br />
'''Step'''<br />
<br />
|<br />
'''Topic'''<br />
<br />
|<br />
'''Count'''<br />
<br />
|<br />
'''State'''<br />
<br />
|<br />
'''Comment'''<br />
<br />
|-<br />
|<br />
1/1<br />
<br />
|<br />
Name<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
1/2<br />
<br />
|<br />
Description<br />
<br />
|<br />
76/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/1<br />
<br />
|<br />
Length<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
Some wrong entrees like mail addresses or comments <br />
<br />
24 “0.00” Values<br />
<br />
|-<br />
|<br />
2/2<br />
<br />
|<br />
Beam<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
37 „0.00“ Values<br />
<br />
|-<br />
|<br />
2/3<br />
<br />
|<br />
Draft<br />
<br />
|<br />
79/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/4<br />
<br />
|<br />
Displacement<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/5<br />
<br />
|<br />
Height<br />
<br />
|<br />
78/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/6<br />
<br />
|<br />
Manufacturer<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Model<br />
<br />
|<br />
49/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Type<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/3<br />
<br />
|<br />
Position below Waterline<br />
<br />
|<br />
57/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Should be Obligatory<br />
<br />
|-<br />
|<br />
3/4<br />
<br />
|<br />
Depth Measurement<br />
<br />
|<br />
?<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Where in DB?<br />
<br />
|-<br />
|<br />
3/5<br />
<br />
|<br />
Sensor Offset to Keel<br />
<br />
|<br />
6/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/6<br />
<br />
|<br />
Producer of Depth Sensor<br />
<br />
|<br />
63/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/7<br />
<br />
|<br />
Device Model<br />
<br />
|<br />
40/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
58 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
51 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/3<br />
<br />
|<br />
Position abbove Waterline<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/4<br />
<br />
|<br />
Producer<br />
<br />
|<br />
77/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/5<br />
<br />
|<br />
Model<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|}<br />
<br />
= Data Preprocessing =<br />
<br />
== Data Condition ==<br />
Raw data is usually erronous and must be corrected<br />
<br />
=== Internal data problems ===<br />
Depth data may be affected by electrical conditions and software implementations<br />
* Data is incomplete and fail their checksum (bus errors from physical transmissions errors)<br />
* Data is retrived out of sequence<br />
* Data is erronous sensor data <br />
** Approximate correctable data i.e. invalid GPS position that may be interpolated<br />
** Uncorrectable data i.e. failed log sensor that shows slow speeds<br />
* Data resolution is low i.e. for energy saving purposes GPS position is updated every 10 seconds instead of every second<br />
* Sensor data is actively miscalibrated i.e. charter companies add additional draft to the sensor depth for safety reasons<br />
<br />
=== External data problems ===<br />
Depth data may be affected by different environmental circumstances <br />
*# The water temperature affects the ultrasound echo. An inhomogen water temperature yields unwanted echos<br />
*# The seabed affects the ultrasound echo<br />
*# The seastate affects the measurement. There even may be waves when there is no wind.<br />
*# Waves may affect the roll of the measuring vessel resulting in steep measurements that are invalid.<br />
*# The sounder sensor is not the position of the GPS antenna. A position offset including heading must be incorporated.<br />
*# The time of the measurement need not correlate with the time the position was received. This may even happen due to processing time of the hard or software.<br />
*# Corrections for tide induced water levels must happen<br />
<br />
Solutions probably are<br />
*# Water temperature may be measure from the sensor, other data may be unavailable<br />
*# Modern sidescan sonar may yield information about the seabed through classifications<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# Position offsets must be provided by the user<br />
*# Time outages may be handled by the filter if precise timestamps are available in recorded data<br />
*# LAT to Mean sea level differences may be calculated from DTU10 worldwide, river gauges need to monitored<br />
<br />
[[Datei:LAT2MSLDiff.png]]<br />
<br />
<br />
== Data Condition Examples / Showcases ==<br />
<br />
=== Missing measurments (Position) ===<br />
Distribution for position updates taken from an example dataset. Left column shows the time between two consecutive measurements, right column shows how many measurements had this time update.<br />
One can see from the distribtion that the sensor is updated every second but many measurements are one or more seconds late.<br />
21 seconds with no position update may result in an instability of the subsequent filter.<br />
<pre><br />
MeasuredPosition3D<br />
GP<br />
0 :4285<br />
1000 :11295<br />
2000 :5056<br />
3000 :2134<br />
4000 :1135<br />
5000 :315<br />
6000 :154<br />
7000 :46<br />
8000 :36<br />
9000 :16<br />
10000 :12<br />
11000 :3<br />
12000 :4<br />
13000 :1<br />
14000 :7<br />
15000 :3<br />
16000 :1<br />
21000 :1<br />
</pre><br />
<br />
=== Missing measurments (Position) with erronous clock ===<br />
This example is at a 10 second position update rate. However the measurment time is faulty causing large negative and positive update rates. The clock jumps by +- one year/month/day/hour. One can further see from the many 0 time measurements that the rate at which data is sent to the nmea bus is higher than the actual position update (data is sent every second, a position update is every 10 seconds)<br />
<pre><br />
MeasuredPosition3D<br />
II<br />
-21340000 :1<br />
-13194000 :1<br />
-7998000 :1<br />
-2674000 :1<br />
-2434000 :1<br />
-2402000 :1<br />
-2030000 :1<br />
-1926000 :1<br />
-1894000 :1<br />
-1806000 :1<br />
-1480000 :1<br />
-1430000 :1<br />
-1382000 :1<br />
-1114000 :1<br />
-814000 :1<br />
-634000 :1<br />
-590000 :1<br />
-546000 :1<br />
-470000 :1<br />
-290000 :1<br />
-230000 :1<br />
-198000 :1<br />
-110000 :1<br />
-94000 :2<br />
0 :182200<br />
5000 :1<br />
10000 :20230<br />
15000 :1<br />
20000 :84<br />
50000 :1<br />
114000 :2<br />
130000 :2<br />
218000 :1<br />
250000 :1<br />
310000 :1<br />
490000 :1<br />
566000 :1<br />
610000 :1<br />
654000 :1<br />
834000 :1<br />
1134000 :1<br />
1402000 :1<br />
1450000 :1</pre><br />
<br />
== Solution Proposal ==<br />
<br />
=== Outline ===<br />
The ship is influenced by the outlined environment which can be observed. Naturally what is observed is not the state of the<br />
ship as i.e. the position if taken from GPS is 95% less than 10m accurate. To improve quality an estimation of the true state yields better results if this noise taken into account properly.<br />
<br />
=== Details ===<br />
The ship moves according to physical laws. For the easist case imagine a ship with constant velocity and direction. For any point in time you can tell where the ship is with easy math. Considering the full blown setup a ships movement is affected by many parameters such as wind speed, water current, waves, tide, and many more. The ship moves also triaxial in a dynamic way in itself (roll, pitch, yaw). Heeling even changes the measurement position with respect to the depth position. In terms of a filter this is called a system model that describes how the state of the ship may change. Given such a state you can measure what your sensor readings are and compare that to where the system thinks you are.<br />
<br />
The [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter] is known to be the best linear estimator for such situations. Unfortunately the system model is not linear which is why the Extended Kalman Filter needs to be used in order to linearize the system at hand.<br />
<br />
Todo:<br />
* Construct ship system model with at least the position state and probably its course and speed or even more (depth)<br />
* Estimate the system variance (This is a hard one, proposals welcome)<br />
* Construct the measurement model according to the data available (GPS, Log)<br />
* Estimate the measurement noise according to specifc sensors (DPGS is more accurate than GPS)<br />
<br />
The estimation with the position and depth can be retrieved and stored in a database.<br />
<br />
Pitfalls:<br />
* If the system noise is badly chosen the estimation of the system state does not converge to the true state / measurement.<br />
* If the system is very detailed the system variance can be reduced. The required cpu time for processing increases<br />
<br />
Benefits:<br />
* Having the best estimation of the true position even if measurements are noisy<br />
* Easy and effective algorithmic processing<br />
<br />
== Analysis == <br />
<br />
=== Data Sets ===<br />
Currently two test data sets are available recorded during trips from Mallorca and the Baltic Sea.<br />
In terms of data quality the Mallorca data shows many challenges. <br />
* The minimum recommended sentences from NMEA showed up with false date and time readings while having correct (!!!) message checksums. <br />
* The log on the ship was defective and delivered no readings from time to time. <br />
* The same holds true for the water temperature.<br />
* The GPS positions relatively imprecise because some last decimal digits are missing in the recordings.<br />
* The GPS positions are updated every 10 seconds while other sensor readings update almost every second.<br />
* The GPS position are sometimes way off due to false readings<br />
<br />
The Baltic Sea data set is a little bit better<br />
* Only a single day is available<br />
* GPS positions are updated every second<br />
<br />
One problem with the data is that there is time available when sensor readings were recorded. This yields problems to the filter algorithm.<br />
<br />
<br />
=== Filter Algorithm ===<br />
At first the Extended Kalman Filter is being analyzed. Using an apache implementation with the available data the filter quickly throw an exception that<br />
a matrix is not invertible because of numeric instabilities. When removing this exception the filter seems to work but the removal and its effects have yet to be analyzed.<br />
Literature suggest that a fixed interval smoother may yield better results in case of offline data processing. As it is an extension to the existing kalman filter<br />
we may consider that for the future.<br />
<br />
One problem are the different update rates of the sensors. As GPS may deliver positions at 0.1Hz speed is updated at 1Hz. Literature suggests that<br />
the missing measurements shell be modelled as a random variable with the standard deviation of the sensor. It may even be possible to update covariance matrices only partially with the sensor readings received. Input for the best solution may be formulated on the developer mailing list.<br />
<br />
== Results == <br />
A prototype implementation is shown in the following screenshots. An Extended Kalman Filter is being used. It has the position<br />
and the current bearing and velocity as system state. The input is the measurement of these four observables. The system function is<br />
good old pythagoras. In a first implementation I tried to use orthodrome distances but the system function is not differentiable which is a requirement of the Extended Kalman Filter (due to acrtan2). For small distances pythagoras should be sufficiently accurate. <br />
The initial state is taken from the first measurement for convergence reasons.<br />
<br />
The following gallery shows the results. <br />
* You can see the bad position resolution and an outlier in the first screenshot.<br />
* The second shows the same data overlaid with the applied filter. The outlier is gone and the resolution has improved.<br />
* The third screenshot shows data from a different GPS sensor with more precision (not DGPS) versus the filtered data.<br />
<br />
This of course is just a preliminary test and many setups need to be considered to make it work for most datasets.<br />
<br />
<gallery><br />
UnfilteredNMEA.png | Unfiltered GPS data<br />
FilteredNMEAVsOriginal.png | Unfiltered GPS data and Filtered GPS data<br />
PreciseGPSvsFilter.png | Another precise GPS vs Filtered GPS data<br />
</gallery><br />
<br />
The overall process even gives an estimation of the current error which is a capability of the [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter].<br />
This way positional inaccuracies may be added to the overall depth measurement inaccuracy.<br />
<br />
== Quality rating ==<br />
<br />
Each record (time, positon, depth) should become a quality rating.<br />
<br />
=== Points ===<br />
<br />
Derived from the Fibonacci series.<br />
<br />
{| class="wikitable"<br />
! Point || Description<br />
|-<br />
| 1 || extra small improvement<br />
|-<br />
| 2 || small improvement<br />
|-<br />
| 3 || medium improvement<br />
|-<br />
| 5 || large improvement<br />
|-<br />
| 8 || extra large improvement<br />
|}<br />
<br />
=== Factors ===<br />
<br />
{| class="wikitable"<br />
! style="width:15%" | Name<br />
! style="width:17%" | Factor<br />
! style="width:68%" | Description<br />
|-<br />
| depth offset || 8 (extra large) || The difference between the depth measured by the echo sounder and the depth (waterline) measured by hand.<br />
|-<br />
| device distance || 3 (medium) || The distance between gps antenna and echo sounder (lengthwise and crosswise).<br />
|-<br />
| SBAS || 3 (medium) || Satellite based augmentation system (WAAS, EGNOS, MSAS) which allows to correct the gps position.<br />
|-<br />
| position interpolation || 2 (small improvement) || Arrival of depth and position packets can have a time difference. It is/should be possible to interpolate the position.<br />
|}<br />
<br />
= Depth Rendering =<br />
<br />
= Siehe auch =<br />
* [[De:Bordnetz|Bordnetz]]<br />
* [[De:NMEA-Logger_anschliessen|NMEA-Logger_anschliessen]]<br />
* [http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCkQFjAA&url=http%3A%2F%2Fwww.dei.unipd.it%2F~chiuso%2FDOWNLOAD%2FPositioning_Heading_Kalman.pdf&ei=sSWNUMWnL4eC4gTRlYHAAw&usg=AFQjCNHq5V-PePNmDTZaGYvq0JeQFgqHVw Kalman Filtering for Positioning and Heading Control of Ships and Offshore Rigs]<br />
* [http://users.isr.ist.utl.pt/~pedro/publications/CAMS10.pdf A Multiple Model Adaptive Wave Filter for Dynamic Ship Positioning]<br />
* [http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4449205&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4449205 Echosounder Depth Tracking with the Extended Kalman Filter]</div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:En:Depth_Data&diff=2955OpenSeaMap-dev:En:Depth Data2014-09-27T17:32:01Z<p>MartinOver: /* Baltic Sea - near Großenbrode (Germany) */</p>
<hr />
<div>This Page describes the necessary efforts to retrieve and analyze depth data as well as create renderings from it<br />
<br />
= Data Aquisition =<br />
Depth data can be retrieved from public domain sources or from crowd sourced data.<br />
<br />
== GEBCO ==<br />
DIe Daten sind gerendert und stehen als Layer zur Verfügung:<br />
{| class="wikitable"<br />
! Zoom || Inhalt<br />
|-<br />
| 0..10 || Blaustufen und Schattierung<br />
|-<br />
| 11..18 || beschriftete Tiefenlinien, Blaustufen und Schattierung<br />
|}<br />
<br />
Noch zu lösende Probleme:<br />
* der GEBCO-Layer erzeugt einen milchigen Schleier über der Basiskarte<br />
* Tiefenlinien sind ab z=14 etwas grob (also ab da, wo dann die Flachwassertiefen beginnen) [http://map.openseamap.org/?zoom=14&lat=36.03097&lon=-5.49153&layers=BFTFTTTFFFF0 Karte]<br />
* Überschneidungen von 100m-Linie und Küstenlinie [http://map.openseamap.org/?zoom=15&lat=36.00318&lon=-5.60819&layers=BFFFTTTFFFF0FFFFF Karte]<br />
* Steilküsten (Cuba) [http://map.openseamap.org/?zoom=14&lat=19.94808&lon=-76.04289&layers=BFTFTTTFFFF0 Karte]<br />
<br />
== Crowd Sourced Data ==<br />
Crowd sourced data may be gathered by YOU. There are two options in development. A hardware and a software option.<br />
<br />
=== Workflow ===<br />
[[Datei:Workflow_depth.png]]<br />
<br />
Here you can find the document with the previous thoughts about the workflow:<br />
[http://osm.franken.de/wiki/FWT-Projekt%C3%BCbersicht-NMEA2Contours_2.1.ppt PPT Dokument]<br />
<br />
=== Hardware logger ===<br />
We are currently developing a hardware logger that may easily be plugged to the ship's network in order to log the networks data to a SD card.<br />
That data may then be uploaded by plugging the SD card to a normal computer with internet connection for upload.<br />
The main goal is to support NMEA 0183 data with options for NMEA 2000.<br />
<br />
=== Software logger ===<br />
A [[Software logger]] is in development and [http://seesea.sourceforge.net/datalogger/index.html can be downloaded here]. <br />
<br />
It currently supports: <br />
: Bluetooth <br />
: Serial ports<br />
: Internet Protocol (IP)<br />
It processes NMEA 0183 and AIS data.<br />
<br />
For vendor specific protocols such as SeaTalk 1 you have to use a [[De:NMEA-Logger_anschliessen|converter]] to NMEA 0183 data.<br />
<br />
NMEA 2000 support is only available if data is transcoded to NMEA 0183 by a converter.<br />
<br />
=== Chart Plotters ===<br />
<br />
Some chart plotters are able to save tracks out-of-the-box, e.g. several Raymarine (FSH files) and Humminbird (SON files) devices. Those files may directly be used as data source.<br />
<br />
<br />
=== Upload Process ===<br />
Uploading data is possible through using the [http://seesea.sourceforge.net/datalogger/index.html OpenSeaMap Data Logger Software] or via [http://depth.openseamap.org/ Web Interface].<br />
The system is currently being tested. <br />
<br />
[[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|You'll find further information here]].<br />
<br />
=== Test Data ===<br />
<br />
<br />
==== Brombachsee (Germany)====<br />
<br />
Test data for Openseamap: [http://osm.franken.de/wiki/test_data_brombachsee.zip Brombachsee_Test_Data]<br />
<br />
dgm_brombachsee.tif: Digital Elevation Model of the sea derived from height lines WWA (C).<br />
<br />
shapes_brombachsee.shp: Shape File derived from 4 NMEA Tracks. "dbs" is the original Sounding and "deep_cor" the depth after a correction (gauge levl).<br />
<br />
gpx_brombachsee.gpx: ele = "dbs" from the Shape File<br />
<br />
[[Datei:Brombachsee.png]]<br />
Resulting Digital Elevation Model<br />
<br />
==== Baltic Sea - near Großenbrode (Germany)====<br />
<br />
First results with an RMS error < 1,5 meter compared to an official dataset of the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].<br />
<br />
[[Datei: Bsh_results_overview.jpg]]<br />
<br />
[Picture 1] '''''OSM map in background, raster Depth Model derived from BSH data and crowed sourced OpenSeaMap Points - Overview'''''<br />
<br />
Blue = flat BSH data, red = deep BSH data.<br />
<br>Blue points = OpenSeaMap raw measuring points.<br />
<br />
{| class="wikitable"<br />
|-<br />
| n || 5062<br />
|-<br />
|-<br />
| datasets || 21<br />
|-<br />
| max deviation || 3,43 meters<br />
|-<br />
| mean (abs) || 0,69 meters<br />
|-<br />
| RMS +/- || 0,91 meters<br />
|}<br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| Manufacturer || Bavaria Yachtbau<br />
|-<br />
| Model || B32<br />
|-<br />
| Length || 10,0 meters<br />
|-<br />
| Beam || 3,35 meters<br />
|-<br />
| Draft || 1,6 meters<br />
|-<br />
| Height || 14 meters<br />
|-<br />
| Displacement || 4,2 t<br />
|-<br />
| Sensor manufacturer || Raymarine<br />
|-<br />
| Sensor Offset to waterline || 0,45 meters<br />
|-<br />
| Sensor Offset to keel || 1,15 meters<br />
|}<br />
<br />
<br />
<br />
A digital Deep Model raster was computed from the BSH point dataset (c).<br />
The depth of the crowed sourced dataset was compared to the derived raster dataset from the BSH.<br />
The raw crowed sourced dataset was corrected by the sensor offset (0,45 meters).<br />
<br />
[[Datei: Scatter_cor_sensor.jpeg]]<br />
<br />
[Picture 2] '''''Scatter plot: BSH data on the x-axis and the crowed sourced data on the y-axis. Trend line in black and optimal line in red.'''''<br />
<br />
The deviation from the reference dataset increases with the depth measured.<br />
<br />
As you see in the picture below the difference between the datasets has an regular pattern maybe deepending on waves.<br />
<br />
[[Datei: Bsh_results_detail_10_classes.jpg]]<br />
<br />
[Picture 3] '''''Crowed sourced OpenSeaMap track points and the difference from the BSH dataset'''''<br />
<br />
White = low difference, orange = medium difference, red = strong difference<br />
<br />
Download of the data http://osm.franken.de/data/baltic_sea_test_data.zip<br />
'''Be aware of the copyright from the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].'''<br />
The data in the dataset is not corrected by sensor offset.<br />
<br />
=== Meta Data Statistics ===<br />
<br />
Statistics for the metadata entrees with some personal comments (by MartinOver). Stand 20.9.2014.<br />
<br />
{| class="prettytable"<br />
|-<br />
|<br />
'''Step'''<br />
<br />
|<br />
'''Topic'''<br />
<br />
|<br />
'''Count'''<br />
<br />
|<br />
'''State'''<br />
<br />
|<br />
'''Comment'''<br />
<br />
|-<br />
|<br />
1/1<br />
<br />
|<br />
Name<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
1/2<br />
<br />
|<br />
Description<br />
<br />
|<br />
76/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/1<br />
<br />
|<br />
Length<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
Some wrong entrees like mail addresses or comments <br />
<br />
24 “0.00” Values<br />
<br />
|-<br />
|<br />
2/2<br />
<br />
|<br />
Beam<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
37 „0.00“ Values<br />
<br />
|-<br />
|<br />
2/3<br />
<br />
|<br />
Draft<br />
<br />
|<br />
79/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/4<br />
<br />
|<br />
Displacement<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/5<br />
<br />
|<br />
Height<br />
<br />
|<br />
78/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/6<br />
<br />
|<br />
Manufacturer<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Model<br />
<br />
|<br />
49/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Type<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/3<br />
<br />
|<br />
Position below Waterline<br />
<br />
|<br />
57/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Should be Obligatory<br />
<br />
|-<br />
|<br />
3/4<br />
<br />
|<br />
Depth Measurement<br />
<br />
|<br />
?<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Where in DB?<br />
<br />
|-<br />
|<br />
3/5<br />
<br />
|<br />
Sensor Offset to Keel<br />
<br />
|<br />
6/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/6<br />
<br />
|<br />
Producer of Depth Sensor<br />
<br />
|<br />
63/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/7<br />
<br />
|<br />
Device Model<br />
<br />
|<br />
40/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
58 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
51 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/3<br />
<br />
|<br />
Position abbove Waterline<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/4<br />
<br />
|<br />
Producer<br />
<br />
|<br />
77/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/5<br />
<br />
|<br />
Model<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|}<br />
<br />
= Data Preprocessing =<br />
<br />
== Data Condition ==<br />
Raw data is usually erronous and must be corrected<br />
<br />
=== Internal data problems ===<br />
Depth data may be affected by electrical conditions and software implementations<br />
* Data is incomplete and fail their checksum (bus errors from physical transmissions errors)<br />
* Data is retrived out of sequence<br />
* Data is erronous sensor data <br />
** Approximate correctable data i.e. invalid GPS position that may be interpolated<br />
** Uncorrectable data i.e. failed log sensor that shows slow speeds<br />
* Data resolution is low i.e. for energy saving purposes GPS position is updated every 10 seconds instead of every second<br />
* Sensor data is actively miscalibrated i.e. charter companies add additional draft to the sensor depth for safety reasons<br />
<br />
=== External data problems ===<br />
Depth data may be affected by different environmental circumstances <br />
*# The water temperature affects the ultrasound echo. An inhomogen water temperature yields unwanted echos<br />
*# The seabed affects the ultrasound echo<br />
*# The seastate affects the measurement. There even may be waves when there is no wind.<br />
*# Waves may affect the roll of the measuring vessel resulting in steep measurements that are invalid.<br />
*# The sounder sensor is not the position of the GPS antenna. A position offset including heading must be incorporated.<br />
*# The time of the measurement need not correlate with the time the position was received. This may even happen due to processing time of the hard or software.<br />
*# Corrections for tide induced water levels must happen<br />
<br />
Solutions probably are<br />
*# Water temperature may be measure from the sensor, other data may be unavailable<br />
*# Modern sidescan sonar may yield information about the seabed through classifications<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# Position offsets must be provided by the user<br />
*# Time outages may be handled by the filter if precise timestamps are available in recorded data<br />
*# LAT to Mean sea level differences may be calculated from DTU10 worldwide, river gauges need to monitored<br />
<br />
[[Datei:LAT2MSLDiff.png]]<br />
<br />
<br />
== Data Condition Examples / Showcases ==<br />
<br />
=== Missing measurments (Position) ===<br />
Distribution for position updates taken from an example dataset. Left column shows the time between two consecutive measurements, right column shows how many measurements had this time update.<br />
One can see from the distribtion that the sensor is updated every second but many measurements are one or more seconds late.<br />
21 seconds with no position update may result in an instability of the subsequent filter.<br />
<pre><br />
MeasuredPosition3D<br />
GP<br />
0 :4285<br />
1000 :11295<br />
2000 :5056<br />
3000 :2134<br />
4000 :1135<br />
5000 :315<br />
6000 :154<br />
7000 :46<br />
8000 :36<br />
9000 :16<br />
10000 :12<br />
11000 :3<br />
12000 :4<br />
13000 :1<br />
14000 :7<br />
15000 :3<br />
16000 :1<br />
21000 :1<br />
</pre><br />
<br />
=== Missing measurments (Position) with erronous clock ===<br />
This example is at a 10 second position update rate. However the measurment time is faulty causing large negative and positive update rates. The clock jumps by +- one year/month/day/hour. One can further see from the many 0 time measurements that the rate at which data is sent to the nmea bus is higher than the actual position update (data is sent every second, a position update is every 10 seconds)<br />
<pre><br />
MeasuredPosition3D<br />
II<br />
-21340000 :1<br />
-13194000 :1<br />
-7998000 :1<br />
-2674000 :1<br />
-2434000 :1<br />
-2402000 :1<br />
-2030000 :1<br />
-1926000 :1<br />
-1894000 :1<br />
-1806000 :1<br />
-1480000 :1<br />
-1430000 :1<br />
-1382000 :1<br />
-1114000 :1<br />
-814000 :1<br />
-634000 :1<br />
-590000 :1<br />
-546000 :1<br />
-470000 :1<br />
-290000 :1<br />
-230000 :1<br />
-198000 :1<br />
-110000 :1<br />
-94000 :2<br />
0 :182200<br />
5000 :1<br />
10000 :20230<br />
15000 :1<br />
20000 :84<br />
50000 :1<br />
114000 :2<br />
130000 :2<br />
218000 :1<br />
250000 :1<br />
310000 :1<br />
490000 :1<br />
566000 :1<br />
610000 :1<br />
654000 :1<br />
834000 :1<br />
1134000 :1<br />
1402000 :1<br />
1450000 :1</pre><br />
<br />
== Solution Proposal ==<br />
<br />
=== Outline ===<br />
The ship is influenced by the outlined environment which can be observed. Naturally what is observed is not the state of the<br />
ship as i.e. the position if taken from GPS is 95% less than 10m accurate. To improve quality an estimation of the true state yields better results if this noise taken into account properly.<br />
<br />
=== Details ===<br />
The ship moves according to physical laws. For the easist case imagine a ship with constant velocity and direction. For any point in time you can tell where the ship is with easy math. Considering the full blown setup a ships movement is affected by many parameters such as wind speed, water current, waves, tide, and many more. The ship moves also triaxial in a dynamic way in itself (roll, pitch, yaw). Heeling even changes the measurement position with respect to the depth position. In terms of a filter this is called a system model that describes how the state of the ship may change. Given such a state you can measure what your sensor readings are and compare that to where the system thinks you are.<br />
<br />
The [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter] is known to be the best linear estimator for such situations. Unfortunately the system model is not linear which is why the Extended Kalman Filter needs to be used in order to linearize the system at hand.<br />
<br />
Todo:<br />
* Construct ship system model with at least the position state and probably its course and speed or even more (depth)<br />
* Estimate the system variance (This is a hard one, proposals welcome)<br />
* Construct the measurement model according to the data available (GPS, Log)<br />
* Estimate the measurement noise according to specifc sensors (DPGS is more accurate than GPS)<br />
<br />
The estimation with the position and depth can be retrieved and stored in a database.<br />
<br />
Pitfalls:<br />
* If the system noise is badly chosen the estimation of the system state does not converge to the true state / measurement.<br />
* If the system is very detailed the system variance can be reduced. The required cpu time for processing increases<br />
<br />
Benefits:<br />
* Having the best estimation of the true position even if measurements are noisy<br />
* Easy and effective algorithmic processing<br />
<br />
== Analysis == <br />
<br />
=== Data Sets ===<br />
Currently two test data sets are available recorded during trips from Mallorca and the Baltic Sea.<br />
In terms of data quality the Mallorca data shows many challenges. <br />
* The minimum recommended sentences from NMEA showed up with false date and time readings while having correct (!!!) message checksums. <br />
* The log on the ship was defective and delivered no readings from time to time. <br />
* The same holds true for the water temperature.<br />
* The GPS positions relatively imprecise because some last decimal digits are missing in the recordings.<br />
* The GPS positions are updated every 10 seconds while other sensor readings update almost every second.<br />
* The GPS position are sometimes way off due to false readings<br />
<br />
The Baltic Sea data set is a little bit better<br />
* Only a single day is available<br />
* GPS positions are updated every second<br />
<br />
One problem with the data is that there is time available when sensor readings were recorded. This yields problems to the filter algorithm.<br />
<br />
<br />
=== Filter Algorithm ===<br />
At first the Extended Kalman Filter is being analyzed. Using an apache implementation with the available data the filter quickly throw an exception that<br />
a matrix is not invertible because of numeric instabilities. When removing this exception the filter seems to work but the removal and its effects have yet to be analyzed.<br />
Literature suggest that a fixed interval smoother may yield better results in case of offline data processing. As it is an extension to the existing kalman filter<br />
we may consider that for the future.<br />
<br />
One problem are the different update rates of the sensors. As GPS may deliver positions at 0.1Hz speed is updated at 1Hz. Literature suggests that<br />
the missing measurements shell be modelled as a random variable with the standard deviation of the sensor. It may even be possible to update covariance matrices only partially with the sensor readings received. Input for the best solution may be formulated on the developer mailing list.<br />
<br />
== Results == <br />
A prototype implementation is shown in the following screenshots. An Extended Kalman Filter is being used. It has the position<br />
and the current bearing and velocity as system state. The input is the measurement of these four observables. The system function is<br />
good old pythagoras. In a first implementation I tried to use orthodrome distances but the system function is not differentiable which is a requirement of the Extended Kalman Filter (due to acrtan2). For small distances pythagoras should be sufficiently accurate. <br />
The initial state is taken from the first measurement for convergence reasons.<br />
<br />
The following gallery shows the results. <br />
* You can see the bad position resolution and an outlier in the first screenshot.<br />
* The second shows the same data overlaid with the applied filter. The outlier is gone and the resolution has improved.<br />
* The third screenshot shows data from a different GPS sensor with more precision (not DGPS) versus the filtered data.<br />
<br />
This of course is just a preliminary test and many setups need to be considered to make it work for most datasets.<br />
<br />
<gallery><br />
UnfilteredNMEA.png | Unfiltered GPS data<br />
FilteredNMEAVsOriginal.png | Unfiltered GPS data and Filtered GPS data<br />
PreciseGPSvsFilter.png | Another precise GPS vs Filtered GPS data<br />
</gallery><br />
<br />
The overall process even gives an estimation of the current error which is a capability of the [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter].<br />
This way positional inaccuracies may be added to the overall depth measurement inaccuracy.<br />
<br />
== Quality rating ==<br />
<br />
Each record (time, positon, depth) should become a quality rating.<br />
<br />
=== Points ===<br />
<br />
Derived from the Fibonacci series.<br />
<br />
{| class="wikitable"<br />
! Point || Description<br />
|-<br />
| 1 || extra small improvement<br />
|-<br />
| 2 || small improvement<br />
|-<br />
| 3 || medium improvement<br />
|-<br />
| 5 || large improvement<br />
|-<br />
| 8 || extra large improvement<br />
|}<br />
<br />
=== Factors ===<br />
<br />
{| class="wikitable"<br />
! style="width:15%" | Name<br />
! style="width:17%" | Factor<br />
! style="width:68%" | Description<br />
|-<br />
| depth offset || 8 (extra large) || The difference between the depth measured by the echo sounder and the depth (waterline) measured by hand.<br />
|-<br />
| device distance || 3 (medium) || The distance between gps antenna and echo sounder (lengthwise and crosswise).<br />
|-<br />
| SBAS || 3 (medium) || Satellite based augmentation system (WAAS, EGNOS, MSAS) which allows to correct the gps position.<br />
|-<br />
| position interpolation || 2 (small improvement) || Arrival of depth and position packets can have a time difference. It is/should be possible to interpolate the position.<br />
|}<br />
<br />
= Depth Rendering =<br />
<br />
= Siehe auch =<br />
* [[De:Bordnetz|Bordnetz]]<br />
* [[De:NMEA-Logger_anschliessen|NMEA-Logger_anschliessen]]<br />
* [http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCkQFjAA&url=http%3A%2F%2Fwww.dei.unipd.it%2F~chiuso%2FDOWNLOAD%2FPositioning_Heading_Kalman.pdf&ei=sSWNUMWnL4eC4gTRlYHAAw&usg=AFQjCNHq5V-PePNmDTZaGYvq0JeQFgqHVw Kalman Filtering for Positioning and Heading Control of Ships and Offshore Rigs]<br />
* [http://users.isr.ist.utl.pt/~pedro/publications/CAMS10.pdf A Multiple Model Adaptive Wave Filter for Dynamic Ship Positioning]<br />
* [http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4449205&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4449205 Echosounder Depth Tracking with the Extended Kalman Filter]</div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:En:Depth_Data&diff=2954OpenSeaMap-dev:En:Depth Data2014-09-26T19:59:08Z<p>MartinOver: /* Meta Data Stats */</p>
<hr />
<div>This Page describes the necessary efforts to retrieve and analyze depth data as well as create renderings from it<br />
<br />
= Data Aquisition =<br />
Depth data can be retrieved from public domain sources or from crowd sourced data.<br />
<br />
== GEBCO ==<br />
DIe Daten sind gerendert und stehen als Layer zur Verfügung:<br />
{| class="wikitable"<br />
! Zoom || Inhalt<br />
|-<br />
| 0..10 || Blaustufen und Schattierung<br />
|-<br />
| 11..18 || beschriftete Tiefenlinien, Blaustufen und Schattierung<br />
|}<br />
<br />
Noch zu lösende Probleme:<br />
* der GEBCO-Layer erzeugt einen milchigen Schleier über der Basiskarte<br />
* Tiefenlinien sind ab z=14 etwas grob (also ab da, wo dann die Flachwassertiefen beginnen) [http://map.openseamap.org/?zoom=14&lat=36.03097&lon=-5.49153&layers=BFTFTTTFFFF0 Karte]<br />
* Überschneidungen von 100m-Linie und Küstenlinie [http://map.openseamap.org/?zoom=15&lat=36.00318&lon=-5.60819&layers=BFFFTTTFFFF0FFFFF Karte]<br />
* Steilküsten (Cuba) [http://map.openseamap.org/?zoom=14&lat=19.94808&lon=-76.04289&layers=BFTFTTTFFFF0 Karte]<br />
<br />
== Crowd Sourced Data ==<br />
Crowd sourced data may be gathered by YOU. There are two options in development. A hardware and a software option.<br />
<br />
=== Workflow ===<br />
[[Datei:Workflow_depth.png]]<br />
<br />
Here you can find the document with the previous thoughts about the workflow:<br />
[http://osm.franken.de/wiki/FWT-Projekt%C3%BCbersicht-NMEA2Contours_2.1.ppt PPT Dokument]<br />
<br />
=== Hardware logger ===<br />
We are currently developing a hardware logger that may easily be plugged to the ship's network in order to log the networks data to a SD card.<br />
That data may then be uploaded by plugging the SD card to a normal computer with internet connection for upload.<br />
The main goal is to support NMEA 0183 data with options for NMEA 2000.<br />
<br />
=== Software logger ===<br />
A [[Software logger]] is in development and [http://seesea.sourceforge.net/datalogger/index.html can be downloaded here]. <br />
<br />
It currently supports: <br />
: Bluetooth <br />
: Serial ports<br />
: Internet Protocol (IP)<br />
It processes NMEA 0183 and AIS data.<br />
<br />
For vendor specific protocols such as SeaTalk 1 you have to use a [[De:NMEA-Logger_anschliessen|converter]] to NMEA 0183 data.<br />
<br />
NMEA 2000 support is only available if data is transcoded to NMEA 0183 by a converter.<br />
<br />
=== Chart Plotters ===<br />
<br />
Some chart plotters are able to save tracks out-of-the-box, e.g. several Raymarine (FSH files) and Humminbird (SON files) devices. Those files may directly be used as data source.<br />
<br />
<br />
=== Upload Process ===<br />
Uploading data is possible through using the [http://seesea.sourceforge.net/datalogger/index.html OpenSeaMap Data Logger Software] or via [http://depth.openseamap.org/ Web Interface].<br />
The system is currently being tested. <br />
<br />
[[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|You'll find further information here]].<br />
<br />
=== Test Data ===<br />
<br />
<br />
==== Brombachsee (Germany)====<br />
<br />
Test data for Openseamap: [http://osm.franken.de/wiki/test_data_brombachsee.zip Brombachsee_Test_Data]<br />
<br />
dgm_brombachsee.tif: Digital Elevation Model of the sea derived from height lines WWA (C).<br />
<br />
shapes_brombachsee.shp: Shape File derived from 4 NMEA Tracks. "dbs" is the original Sounding and "deep_cor" the depth after a correction (gauge levl).<br />
<br />
gpx_brombachsee.gpx: ele = "dbs" from the Shape File<br />
<br />
[[Datei:Brombachsee.png]]<br />
Resulting Digital Elevation Model<br />
<br />
==== Baltic Sea - near Großenbrode (Germany)====<br />
<br />
First results with an RMS error < 1,5 meter compared to an official dataset of the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].<br />
<br />
[[Datei: Bsh_results_overview.jpg]]<br />
<br />
[Picture 1] '''''OSM map in background, raster Depth Model derived from BSH data and crowed sourced OpenSeaMap Points - Overview'''''<br />
<br />
Blue = flat BSH data, red = deep BSH data.<br />
<br>Blue points = OpenSeaMap raw measuring points.<br />
<br />
{| class="wikitable"<br />
|-<br />
| n || 5062<br />
|-<br />
|-<br />
| datasets || 21<br />
|-<br />
| max deviation || 3,43 meters<br />
|-<br />
| mean (abs) || 0,69 meters<br />
|-<br />
| RMS +/- || 0,91 meters<br />
|}<br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| Manufacturer || Bavaria Yachtbau<br />
|-<br />
| Model || B32<br />
|-<br />
| Length || 10,0 meters<br />
|-<br />
| Beam || 3,35 meters<br />
|-<br />
| Draft || 1,6 meters<br />
|-<br />
| Height || 14 meters<br />
|-<br />
| Displacement || 4,2 t<br />
|-<br />
| Sensor manufacturer || Raymarine<br />
|-<br />
| Sensor Offset || 0,45 meters<br />
|}<br />
<br />
<br />
A digital Deep Model raster was computed from the BSH point dataset (c).<br />
The depth of the crowed sourced dataset was compared to the derived raster dataset from the BSH.<br />
The raw crowed sourced dataset was corrected by the sensor offset (0,45 meters).<br />
<br />
[[Datei: Scatter_cor_sensor.jpeg]]<br />
<br />
[Picture 2] '''''Scatter plot: BSH data on the x-axis and the crowed sourced data on the y-axis. Trend line in black and optimal line in red.'''''<br />
<br />
The deviation from the reference dataset increases with the depth measured.<br />
<br />
As you see in the picture below the difference between the datasets has an regular pattern maybe deepending on waves.<br />
<br />
[[Datei: Bsh_results_detail_10_classes.jpg]]<br />
<br />
[Picture 3] '''''Crowed sourced OpenSeaMap track points and the difference from the BSH dataset'''''<br />
<br />
White = low difference, orange = medium difference, red = strong difference<br />
<br />
Download of the data http://osm.franken.de/data/baltic_sea_test_data.zip<br />
'''Be aware of the copyright from the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].'''<br />
The data in the dataset is not corrected by sensor offset.<br />
<br />
=== Meta Data Statistics ===<br />
<br />
Statistics for the metadata entrees with some personal comments (by MartinOver). Stand 20.9.2014.<br />
<br />
{| class="prettytable"<br />
|-<br />
|<br />
'''Step'''<br />
<br />
|<br />
'''Topic'''<br />
<br />
|<br />
'''Count'''<br />
<br />
|<br />
'''State'''<br />
<br />
|<br />
'''Comment'''<br />
<br />
|-<br />
|<br />
1/1<br />
<br />
|<br />
Name<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
1/2<br />
<br />
|<br />
Description<br />
<br />
|<br />
76/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/1<br />
<br />
|<br />
Length<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
Some wrong entrees like mail addresses or comments <br />
<br />
24 “0.00” Values<br />
<br />
|-<br />
|<br />
2/2<br />
<br />
|<br />
Beam<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
37 „0.00“ Values<br />
<br />
|-<br />
|<br />
2/3<br />
<br />
|<br />
Draft<br />
<br />
|<br />
79/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/4<br />
<br />
|<br />
Displacement<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/5<br />
<br />
|<br />
Height<br />
<br />
|<br />
78/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/6<br />
<br />
|<br />
Manufacturer<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Model<br />
<br />
|<br />
49/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Type<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/3<br />
<br />
|<br />
Position below Waterline<br />
<br />
|<br />
57/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Should be Obligatory<br />
<br />
|-<br />
|<br />
3/4<br />
<br />
|<br />
Depth Measurement<br />
<br />
|<br />
?<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Where in DB?<br />
<br />
|-<br />
|<br />
3/5<br />
<br />
|<br />
Sensor Offset to Keel<br />
<br />
|<br />
6/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/6<br />
<br />
|<br />
Producer of Depth Sensor<br />
<br />
|<br />
63/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/7<br />
<br />
|<br />
Device Model<br />
<br />
|<br />
40/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
58 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
51 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/3<br />
<br />
|<br />
Position abbove Waterline<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/4<br />
<br />
|<br />
Producer<br />
<br />
|<br />
77/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/5<br />
<br />
|<br />
Model<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|}<br />
<br />
= Data Preprocessing =<br />
<br />
== Data Condition ==<br />
Raw data is usually erronous and must be corrected<br />
<br />
=== Internal data problems ===<br />
Depth data may be affected by electrical conditions and software implementations<br />
* Data is incomplete and fail their checksum (bus errors from physical transmissions errors)<br />
* Data is retrived out of sequence<br />
* Data is erronous sensor data <br />
** Approximate correctable data i.e. invalid GPS position that may be interpolated<br />
** Uncorrectable data i.e. failed log sensor that shows slow speeds<br />
* Data resolution is low i.e. for energy saving purposes GPS position is updated every 10 seconds instead of every second<br />
* Sensor data is actively miscalibrated i.e. charter companies add additional draft to the sensor depth for safety reasons<br />
<br />
=== External data problems ===<br />
Depth data may be affected by different environmental circumstances <br />
*# The water temperature affects the ultrasound echo. An inhomogen water temperature yields unwanted echos<br />
*# The seabed affects the ultrasound echo<br />
*# The seastate affects the measurement. There even may be waves when there is no wind.<br />
*# Waves may affect the roll of the measuring vessel resulting in steep measurements that are invalid.<br />
*# The sounder sensor is not the position of the GPS antenna. A position offset including heading must be incorporated.<br />
*# The time of the measurement need not correlate with the time the position was received. This may even happen due to processing time of the hard or software.<br />
*# Corrections for tide induced water levels must happen<br />
<br />
Solutions probably are<br />
*# Water temperature may be measure from the sensor, other data may be unavailable<br />
*# Modern sidescan sonar may yield information about the seabed through classifications<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# Position offsets must be provided by the user<br />
*# Time outages may be handled by the filter if precise timestamps are available in recorded data<br />
*# LAT to Mean sea level differences may be calculated from DTU10 worldwide, river gauges need to monitored<br />
<br />
[[Datei:LAT2MSLDiff.png]]<br />
<br />
<br />
== Data Condition Examples / Showcases ==<br />
<br />
=== Missing measurments (Position) ===<br />
Distribution for position updates taken from an example dataset. Left column shows the time between two consecutive measurements, right column shows how many measurements had this time update.<br />
One can see from the distribtion that the sensor is updated every second but many measurements are one or more seconds late.<br />
21 seconds with no position update may result in an instability of the subsequent filter.<br />
<pre><br />
MeasuredPosition3D<br />
GP<br />
0 :4285<br />
1000 :11295<br />
2000 :5056<br />
3000 :2134<br />
4000 :1135<br />
5000 :315<br />
6000 :154<br />
7000 :46<br />
8000 :36<br />
9000 :16<br />
10000 :12<br />
11000 :3<br />
12000 :4<br />
13000 :1<br />
14000 :7<br />
15000 :3<br />
16000 :1<br />
21000 :1<br />
</pre><br />
<br />
=== Missing measurments (Position) with erronous clock ===<br />
This example is at a 10 second position update rate. However the measurment time is faulty causing large negative and positive update rates. The clock jumps by +- one year/month/day/hour. One can further see from the many 0 time measurements that the rate at which data is sent to the nmea bus is higher than the actual position update (data is sent every second, a position update is every 10 seconds)<br />
<pre><br />
MeasuredPosition3D<br />
II<br />
-21340000 :1<br />
-13194000 :1<br />
-7998000 :1<br />
-2674000 :1<br />
-2434000 :1<br />
-2402000 :1<br />
-2030000 :1<br />
-1926000 :1<br />
-1894000 :1<br />
-1806000 :1<br />
-1480000 :1<br />
-1430000 :1<br />
-1382000 :1<br />
-1114000 :1<br />
-814000 :1<br />
-634000 :1<br />
-590000 :1<br />
-546000 :1<br />
-470000 :1<br />
-290000 :1<br />
-230000 :1<br />
-198000 :1<br />
-110000 :1<br />
-94000 :2<br />
0 :182200<br />
5000 :1<br />
10000 :20230<br />
15000 :1<br />
20000 :84<br />
50000 :1<br />
114000 :2<br />
130000 :2<br />
218000 :1<br />
250000 :1<br />
310000 :1<br />
490000 :1<br />
566000 :1<br />
610000 :1<br />
654000 :1<br />
834000 :1<br />
1134000 :1<br />
1402000 :1<br />
1450000 :1</pre><br />
<br />
== Solution Proposal ==<br />
<br />
=== Outline ===<br />
The ship is influenced by the outlined environment which can be observed. Naturally what is observed is not the state of the<br />
ship as i.e. the position if taken from GPS is 95% less than 10m accurate. To improve quality an estimation of the true state yields better results if this noise taken into account properly.<br />
<br />
=== Details ===<br />
The ship moves according to physical laws. For the easist case imagine a ship with constant velocity and direction. For any point in time you can tell where the ship is with easy math. Considering the full blown setup a ships movement is affected by many parameters such as wind speed, water current, waves, tide, and many more. The ship moves also triaxial in a dynamic way in itself (roll, pitch, yaw). Heeling even changes the measurement position with respect to the depth position. In terms of a filter this is called a system model that describes how the state of the ship may change. Given such a state you can measure what your sensor readings are and compare that to where the system thinks you are.<br />
<br />
The [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter] is known to be the best linear estimator for such situations. Unfortunately the system model is not linear which is why the Extended Kalman Filter needs to be used in order to linearize the system at hand.<br />
<br />
Todo:<br />
* Construct ship system model with at least the position state and probably its course and speed or even more (depth)<br />
* Estimate the system variance (This is a hard one, proposals welcome)<br />
* Construct the measurement model according to the data available (GPS, Log)<br />
* Estimate the measurement noise according to specifc sensors (DPGS is more accurate than GPS)<br />
<br />
The estimation with the position and depth can be retrieved and stored in a database.<br />
<br />
Pitfalls:<br />
* If the system noise is badly chosen the estimation of the system state does not converge to the true state / measurement.<br />
* If the system is very detailed the system variance can be reduced. The required cpu time for processing increases<br />
<br />
Benefits:<br />
* Having the best estimation of the true position even if measurements are noisy<br />
* Easy and effective algorithmic processing<br />
<br />
== Analysis == <br />
<br />
=== Data Sets ===<br />
Currently two test data sets are available recorded during trips from Mallorca and the Baltic Sea.<br />
In terms of data quality the Mallorca data shows many challenges. <br />
* The minimum recommended sentences from NMEA showed up with false date and time readings while having correct (!!!) message checksums. <br />
* The log on the ship was defective and delivered no readings from time to time. <br />
* The same holds true for the water temperature.<br />
* The GPS positions relatively imprecise because some last decimal digits are missing in the recordings.<br />
* The GPS positions are updated every 10 seconds while other sensor readings update almost every second.<br />
* The GPS position are sometimes way off due to false readings<br />
<br />
The Baltic Sea data set is a little bit better<br />
* Only a single day is available<br />
* GPS positions are updated every second<br />
<br />
One problem with the data is that there is time available when sensor readings were recorded. This yields problems to the filter algorithm.<br />
<br />
<br />
=== Filter Algorithm ===<br />
At first the Extended Kalman Filter is being analyzed. Using an apache implementation with the available data the filter quickly throw an exception that<br />
a matrix is not invertible because of numeric instabilities. When removing this exception the filter seems to work but the removal and its effects have yet to be analyzed.<br />
Literature suggest that a fixed interval smoother may yield better results in case of offline data processing. As it is an extension to the existing kalman filter<br />
we may consider that for the future.<br />
<br />
One problem are the different update rates of the sensors. As GPS may deliver positions at 0.1Hz speed is updated at 1Hz. Literature suggests that<br />
the missing measurements shell be modelled as a random variable with the standard deviation of the sensor. It may even be possible to update covariance matrices only partially with the sensor readings received. Input for the best solution may be formulated on the developer mailing list.<br />
<br />
== Results == <br />
A prototype implementation is shown in the following screenshots. An Extended Kalman Filter is being used. It has the position<br />
and the current bearing and velocity as system state. The input is the measurement of these four observables. The system function is<br />
good old pythagoras. In a first implementation I tried to use orthodrome distances but the system function is not differentiable which is a requirement of the Extended Kalman Filter (due to acrtan2). For small distances pythagoras should be sufficiently accurate. <br />
The initial state is taken from the first measurement for convergence reasons.<br />
<br />
The following gallery shows the results. <br />
* You can see the bad position resolution and an outlier in the first screenshot.<br />
* The second shows the same data overlaid with the applied filter. The outlier is gone and the resolution has improved.<br />
* The third screenshot shows data from a different GPS sensor with more precision (not DGPS) versus the filtered data.<br />
<br />
This of course is just a preliminary test and many setups need to be considered to make it work for most datasets.<br />
<br />
<gallery><br />
UnfilteredNMEA.png | Unfiltered GPS data<br />
FilteredNMEAVsOriginal.png | Unfiltered GPS data and Filtered GPS data<br />
PreciseGPSvsFilter.png | Another precise GPS vs Filtered GPS data<br />
</gallery><br />
<br />
The overall process even gives an estimation of the current error which is a capability of the [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter].<br />
This way positional inaccuracies may be added to the overall depth measurement inaccuracy.<br />
<br />
== Quality rating ==<br />
<br />
Each record (time, positon, depth) should become a quality rating.<br />
<br />
=== Points ===<br />
<br />
Derived from the Fibonacci series.<br />
<br />
{| class="wikitable"<br />
! Point || Description<br />
|-<br />
| 1 || extra small improvement<br />
|-<br />
| 2 || small improvement<br />
|-<br />
| 3 || medium improvement<br />
|-<br />
| 5 || large improvement<br />
|-<br />
| 8 || extra large improvement<br />
|}<br />
<br />
=== Factors ===<br />
<br />
{| class="wikitable"<br />
! style="width:15%" | Name<br />
! style="width:17%" | Factor<br />
! style="width:68%" | Description<br />
|-<br />
| depth offset || 8 (extra large) || The difference between the depth measured by the echo sounder and the depth (waterline) measured by hand.<br />
|-<br />
| device distance || 3 (medium) || The distance between gps antenna and echo sounder (lengthwise and crosswise).<br />
|-<br />
| SBAS || 3 (medium) || Satellite based augmentation system (WAAS, EGNOS, MSAS) which allows to correct the gps position.<br />
|-<br />
| position interpolation || 2 (small improvement) || Arrival of depth and position packets can have a time difference. It is/should be possible to interpolate the position.<br />
|}<br />
<br />
= Depth Rendering =<br />
<br />
= Siehe auch =<br />
* [[De:Bordnetz|Bordnetz]]<br />
* [[De:NMEA-Logger_anschliessen|NMEA-Logger_anschliessen]]<br />
* [http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCkQFjAA&url=http%3A%2F%2Fwww.dei.unipd.it%2F~chiuso%2FDOWNLOAD%2FPositioning_Heading_Kalman.pdf&ei=sSWNUMWnL4eC4gTRlYHAAw&usg=AFQjCNHq5V-PePNmDTZaGYvq0JeQFgqHVw Kalman Filtering for Positioning and Heading Control of Ships and Offshore Rigs]<br />
* [http://users.isr.ist.utl.pt/~pedro/publications/CAMS10.pdf A Multiple Model Adaptive Wave Filter for Dynamic Ship Positioning]<br />
* [http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4449205&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4449205 Echosounder Depth Tracking with the Extended Kalman Filter]</div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:En:Depth_Data&diff=2953OpenSeaMap-dev:En:Depth Data2014-09-26T19:58:33Z<p>MartinOver: /* Meta Data Stats */</p>
<hr />
<div>This Page describes the necessary efforts to retrieve and analyze depth data as well as create renderings from it<br />
<br />
= Data Aquisition =<br />
Depth data can be retrieved from public domain sources or from crowd sourced data.<br />
<br />
== GEBCO ==<br />
DIe Daten sind gerendert und stehen als Layer zur Verfügung:<br />
{| class="wikitable"<br />
! Zoom || Inhalt<br />
|-<br />
| 0..10 || Blaustufen und Schattierung<br />
|-<br />
| 11..18 || beschriftete Tiefenlinien, Blaustufen und Schattierung<br />
|}<br />
<br />
Noch zu lösende Probleme:<br />
* der GEBCO-Layer erzeugt einen milchigen Schleier über der Basiskarte<br />
* Tiefenlinien sind ab z=14 etwas grob (also ab da, wo dann die Flachwassertiefen beginnen) [http://map.openseamap.org/?zoom=14&lat=36.03097&lon=-5.49153&layers=BFTFTTTFFFF0 Karte]<br />
* Überschneidungen von 100m-Linie und Küstenlinie [http://map.openseamap.org/?zoom=15&lat=36.00318&lon=-5.60819&layers=BFFFTTTFFFF0FFFFF Karte]<br />
* Steilküsten (Cuba) [http://map.openseamap.org/?zoom=14&lat=19.94808&lon=-76.04289&layers=BFTFTTTFFFF0 Karte]<br />
<br />
== Crowd Sourced Data ==<br />
Crowd sourced data may be gathered by YOU. There are two options in development. A hardware and a software option.<br />
<br />
=== Workflow ===<br />
[[Datei:Workflow_depth.png]]<br />
<br />
Here you can find the document with the previous thoughts about the workflow:<br />
[http://osm.franken.de/wiki/FWT-Projekt%C3%BCbersicht-NMEA2Contours_2.1.ppt PPT Dokument]<br />
<br />
=== Hardware logger ===<br />
We are currently developing a hardware logger that may easily be plugged to the ship's network in order to log the networks data to a SD card.<br />
That data may then be uploaded by plugging the SD card to a normal computer with internet connection for upload.<br />
The main goal is to support NMEA 0183 data with options for NMEA 2000.<br />
<br />
=== Software logger ===<br />
A [[Software logger]] is in development and [http://seesea.sourceforge.net/datalogger/index.html can be downloaded here]. <br />
<br />
It currently supports: <br />
: Bluetooth <br />
: Serial ports<br />
: Internet Protocol (IP)<br />
It processes NMEA 0183 and AIS data.<br />
<br />
For vendor specific protocols such as SeaTalk 1 you have to use a [[De:NMEA-Logger_anschliessen|converter]] to NMEA 0183 data.<br />
<br />
NMEA 2000 support is only available if data is transcoded to NMEA 0183 by a converter.<br />
<br />
=== Chart Plotters ===<br />
<br />
Some chart plotters are able to save tracks out-of-the-box, e.g. several Raymarine (FSH files) and Humminbird (SON files) devices. Those files may directly be used as data source.<br />
<br />
<br />
=== Upload Process ===<br />
Uploading data is possible through using the [http://seesea.sourceforge.net/datalogger/index.html OpenSeaMap Data Logger Software] or via [http://depth.openseamap.org/ Web Interface].<br />
The system is currently being tested. <br />
<br />
[[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|You'll find further information here]].<br />
<br />
=== Test Data ===<br />
<br />
<br />
==== Brombachsee (Germany)====<br />
<br />
Test data for Openseamap: [http://osm.franken.de/wiki/test_data_brombachsee.zip Brombachsee_Test_Data]<br />
<br />
dgm_brombachsee.tif: Digital Elevation Model of the sea derived from height lines WWA (C).<br />
<br />
shapes_brombachsee.shp: Shape File derived from 4 NMEA Tracks. "dbs" is the original Sounding and "deep_cor" the depth after a correction (gauge levl).<br />
<br />
gpx_brombachsee.gpx: ele = "dbs" from the Shape File<br />
<br />
[[Datei:Brombachsee.png]]<br />
Resulting Digital Elevation Model<br />
<br />
==== Baltic Sea - near Großenbrode (Germany)====<br />
<br />
First results with an RMS error < 1,5 meter compared to an official dataset of the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].<br />
<br />
[[Datei: Bsh_results_overview.jpg]]<br />
<br />
[Picture 1] '''''OSM map in background, raster Depth Model derived from BSH data and crowed sourced OpenSeaMap Points - Overview'''''<br />
<br />
Blue = flat BSH data, red = deep BSH data.<br />
<br>Blue points = OpenSeaMap raw measuring points.<br />
<br />
{| class="wikitable"<br />
|-<br />
| n || 5062<br />
|-<br />
|-<br />
| datasets || 21<br />
|-<br />
| max deviation || 3,43 meters<br />
|-<br />
| mean (abs) || 0,69 meters<br />
|-<br />
| RMS +/- || 0,91 meters<br />
|}<br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| Manufacturer || Bavaria Yachtbau<br />
|-<br />
| Model || B32<br />
|-<br />
| Length || 10,0 meters<br />
|-<br />
| Beam || 3,35 meters<br />
|-<br />
| Draft || 1,6 meters<br />
|-<br />
| Height || 14 meters<br />
|-<br />
| Displacement || 4,2 t<br />
|-<br />
| Sensor manufacturer || Raymarine<br />
|-<br />
| Sensor Offset || 0,45 meters<br />
|}<br />
<br />
<br />
A digital Deep Model raster was computed from the BSH point dataset (c).<br />
The depth of the crowed sourced dataset was compared to the derived raster dataset from the BSH.<br />
The raw crowed sourced dataset was corrected by the sensor offset (0,45 meters).<br />
<br />
[[Datei: Scatter_cor_sensor.jpeg]]<br />
<br />
[Picture 2] '''''Scatter plot: BSH data on the x-axis and the crowed sourced data on the y-axis. Trend line in black and optimal line in red.'''''<br />
<br />
The deviation from the reference dataset increases with the depth measured.<br />
<br />
As you see in the picture below the difference between the datasets has an regular pattern maybe deepending on waves.<br />
<br />
[[Datei: Bsh_results_detail_10_classes.jpg]]<br />
<br />
[Picture 3] '''''Crowed sourced OpenSeaMap track points and the difference from the BSH dataset'''''<br />
<br />
White = low difference, orange = medium difference, red = strong difference<br />
<br />
Download of the data http://osm.franken.de/data/baltic_sea_test_data.zip<br />
'''Be aware of the copyright from the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].'''<br />
The data in the dataset is not corrected by sensor offset.<br />
<br />
=== Meta Data Stats ===<br />
<br />
Statistics for the metadata entrees with some personal comments (by MartinOver). Stand 20.9.2014.<br />
<br />
{| class="prettytable"<br />
|-<br />
|<br />
'''Step'''<br />
<br />
|<br />
'''Topic'''<br />
<br />
|<br />
'''Count'''<br />
<br />
|<br />
'''State'''<br />
<br />
|<br />
'''Comment'''<br />
<br />
|-<br />
|<br />
1/1<br />
<br />
|<br />
Name<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
1/2<br />
<br />
|<br />
Description<br />
<br />
|<br />
76/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/1<br />
<br />
|<br />
Length<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
Some wrong entrees like mail addresses or comments <br />
<br />
24 “0.00” Values<br />
<br />
|-<br />
|<br />
2/2<br />
<br />
|<br />
Beam<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
37 „0.00“ Values<br />
<br />
|-<br />
|<br />
2/3<br />
<br />
|<br />
Draft<br />
<br />
|<br />
79/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/4<br />
<br />
|<br />
Displacement<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/5<br />
<br />
|<br />
Height<br />
<br />
|<br />
78/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/6<br />
<br />
|<br />
Manufacturer<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Model<br />
<br />
|<br />
49/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Type<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/3<br />
<br />
|<br />
Position below Waterline<br />
<br />
|<br />
57/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Should be Obligatory<br />
<br />
|-<br />
|<br />
3/4<br />
<br />
|<br />
Depth Measurement<br />
<br />
|<br />
?<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Where in DB?<br />
<br />
|-<br />
|<br />
3/5<br />
<br />
|<br />
Sensor Offset to Keel<br />
<br />
|<br />
6/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/6<br />
<br />
|<br />
Producer of Depth Sensor<br />
<br />
|<br />
63/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/7<br />
<br />
|<br />
Device Model<br />
<br />
|<br />
40/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
58 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
51 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/3<br />
<br />
|<br />
Position abbove Waterline<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/4<br />
<br />
|<br />
Producer<br />
<br />
|<br />
77/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/5<br />
<br />
|<br />
Model<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|}<br />
<br />
= Data Preprocessing =<br />
<br />
== Data Condition ==<br />
Raw data is usually erronous and must be corrected<br />
<br />
=== Internal data problems ===<br />
Depth data may be affected by electrical conditions and software implementations<br />
* Data is incomplete and fail their checksum (bus errors from physical transmissions errors)<br />
* Data is retrived out of sequence<br />
* Data is erronous sensor data <br />
** Approximate correctable data i.e. invalid GPS position that may be interpolated<br />
** Uncorrectable data i.e. failed log sensor that shows slow speeds<br />
* Data resolution is low i.e. for energy saving purposes GPS position is updated every 10 seconds instead of every second<br />
* Sensor data is actively miscalibrated i.e. charter companies add additional draft to the sensor depth for safety reasons<br />
<br />
=== External data problems ===<br />
Depth data may be affected by different environmental circumstances <br />
*# The water temperature affects the ultrasound echo. An inhomogen water temperature yields unwanted echos<br />
*# The seabed affects the ultrasound echo<br />
*# The seastate affects the measurement. There even may be waves when there is no wind.<br />
*# Waves may affect the roll of the measuring vessel resulting in steep measurements that are invalid.<br />
*# The sounder sensor is not the position of the GPS antenna. A position offset including heading must be incorporated.<br />
*# The time of the measurement need not correlate with the time the position was received. This may even happen due to processing time of the hard or software.<br />
*# Corrections for tide induced water levels must happen<br />
<br />
Solutions probably are<br />
*# Water temperature may be measure from the sensor, other data may be unavailable<br />
*# Modern sidescan sonar may yield information about the seabed through classifications<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# Position offsets must be provided by the user<br />
*# Time outages may be handled by the filter if precise timestamps are available in recorded data<br />
*# LAT to Mean sea level differences may be calculated from DTU10 worldwide, river gauges need to monitored<br />
<br />
[[Datei:LAT2MSLDiff.png]]<br />
<br />
<br />
== Data Condition Examples / Showcases ==<br />
<br />
=== Missing measurments (Position) ===<br />
Distribution for position updates taken from an example dataset. Left column shows the time between two consecutive measurements, right column shows how many measurements had this time update.<br />
One can see from the distribtion that the sensor is updated every second but many measurements are one or more seconds late.<br />
21 seconds with no position update may result in an instability of the subsequent filter.<br />
<pre><br />
MeasuredPosition3D<br />
GP<br />
0 :4285<br />
1000 :11295<br />
2000 :5056<br />
3000 :2134<br />
4000 :1135<br />
5000 :315<br />
6000 :154<br />
7000 :46<br />
8000 :36<br />
9000 :16<br />
10000 :12<br />
11000 :3<br />
12000 :4<br />
13000 :1<br />
14000 :7<br />
15000 :3<br />
16000 :1<br />
21000 :1<br />
</pre><br />
<br />
=== Missing measurments (Position) with erronous clock ===<br />
This example is at a 10 second position update rate. However the measurment time is faulty causing large negative and positive update rates. The clock jumps by +- one year/month/day/hour. One can further see from the many 0 time measurements that the rate at which data is sent to the nmea bus is higher than the actual position update (data is sent every second, a position update is every 10 seconds)<br />
<pre><br />
MeasuredPosition3D<br />
II<br />
-21340000 :1<br />
-13194000 :1<br />
-7998000 :1<br />
-2674000 :1<br />
-2434000 :1<br />
-2402000 :1<br />
-2030000 :1<br />
-1926000 :1<br />
-1894000 :1<br />
-1806000 :1<br />
-1480000 :1<br />
-1430000 :1<br />
-1382000 :1<br />
-1114000 :1<br />
-814000 :1<br />
-634000 :1<br />
-590000 :1<br />
-546000 :1<br />
-470000 :1<br />
-290000 :1<br />
-230000 :1<br />
-198000 :1<br />
-110000 :1<br />
-94000 :2<br />
0 :182200<br />
5000 :1<br />
10000 :20230<br />
15000 :1<br />
20000 :84<br />
50000 :1<br />
114000 :2<br />
130000 :2<br />
218000 :1<br />
250000 :1<br />
310000 :1<br />
490000 :1<br />
566000 :1<br />
610000 :1<br />
654000 :1<br />
834000 :1<br />
1134000 :1<br />
1402000 :1<br />
1450000 :1</pre><br />
<br />
== Solution Proposal ==<br />
<br />
=== Outline ===<br />
The ship is influenced by the outlined environment which can be observed. Naturally what is observed is not the state of the<br />
ship as i.e. the position if taken from GPS is 95% less than 10m accurate. To improve quality an estimation of the true state yields better results if this noise taken into account properly.<br />
<br />
=== Details ===<br />
The ship moves according to physical laws. For the easist case imagine a ship with constant velocity and direction. For any point in time you can tell where the ship is with easy math. Considering the full blown setup a ships movement is affected by many parameters such as wind speed, water current, waves, tide, and many more. The ship moves also triaxial in a dynamic way in itself (roll, pitch, yaw). Heeling even changes the measurement position with respect to the depth position. In terms of a filter this is called a system model that describes how the state of the ship may change. Given such a state you can measure what your sensor readings are and compare that to where the system thinks you are.<br />
<br />
The [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter] is known to be the best linear estimator for such situations. Unfortunately the system model is not linear which is why the Extended Kalman Filter needs to be used in order to linearize the system at hand.<br />
<br />
Todo:<br />
* Construct ship system model with at least the position state and probably its course and speed or even more (depth)<br />
* Estimate the system variance (This is a hard one, proposals welcome)<br />
* Construct the measurement model according to the data available (GPS, Log)<br />
* Estimate the measurement noise according to specifc sensors (DPGS is more accurate than GPS)<br />
<br />
The estimation with the position and depth can be retrieved and stored in a database.<br />
<br />
Pitfalls:<br />
* If the system noise is badly chosen the estimation of the system state does not converge to the true state / measurement.<br />
* If the system is very detailed the system variance can be reduced. The required cpu time for processing increases<br />
<br />
Benefits:<br />
* Having the best estimation of the true position even if measurements are noisy<br />
* Easy and effective algorithmic processing<br />
<br />
== Analysis == <br />
<br />
=== Data Sets ===<br />
Currently two test data sets are available recorded during trips from Mallorca and the Baltic Sea.<br />
In terms of data quality the Mallorca data shows many challenges. <br />
* The minimum recommended sentences from NMEA showed up with false date and time readings while having correct (!!!) message checksums. <br />
* The log on the ship was defective and delivered no readings from time to time. <br />
* The same holds true for the water temperature.<br />
* The GPS positions relatively imprecise because some last decimal digits are missing in the recordings.<br />
* The GPS positions are updated every 10 seconds while other sensor readings update almost every second.<br />
* The GPS position are sometimes way off due to false readings<br />
<br />
The Baltic Sea data set is a little bit better<br />
* Only a single day is available<br />
* GPS positions are updated every second<br />
<br />
One problem with the data is that there is time available when sensor readings were recorded. This yields problems to the filter algorithm.<br />
<br />
<br />
=== Filter Algorithm ===<br />
At first the Extended Kalman Filter is being analyzed. Using an apache implementation with the available data the filter quickly throw an exception that<br />
a matrix is not invertible because of numeric instabilities. When removing this exception the filter seems to work but the removal and its effects have yet to be analyzed.<br />
Literature suggest that a fixed interval smoother may yield better results in case of offline data processing. As it is an extension to the existing kalman filter<br />
we may consider that for the future.<br />
<br />
One problem are the different update rates of the sensors. As GPS may deliver positions at 0.1Hz speed is updated at 1Hz. Literature suggests that<br />
the missing measurements shell be modelled as a random variable with the standard deviation of the sensor. It may even be possible to update covariance matrices only partially with the sensor readings received. Input for the best solution may be formulated on the developer mailing list.<br />
<br />
== Results == <br />
A prototype implementation is shown in the following screenshots. An Extended Kalman Filter is being used. It has the position<br />
and the current bearing and velocity as system state. The input is the measurement of these four observables. The system function is<br />
good old pythagoras. In a first implementation I tried to use orthodrome distances but the system function is not differentiable which is a requirement of the Extended Kalman Filter (due to acrtan2). For small distances pythagoras should be sufficiently accurate. <br />
The initial state is taken from the first measurement for convergence reasons.<br />
<br />
The following gallery shows the results. <br />
* You can see the bad position resolution and an outlier in the first screenshot.<br />
* The second shows the same data overlaid with the applied filter. The outlier is gone and the resolution has improved.<br />
* The third screenshot shows data from a different GPS sensor with more precision (not DGPS) versus the filtered data.<br />
<br />
This of course is just a preliminary test and many setups need to be considered to make it work for most datasets.<br />
<br />
<gallery><br />
UnfilteredNMEA.png | Unfiltered GPS data<br />
FilteredNMEAVsOriginal.png | Unfiltered GPS data and Filtered GPS data<br />
PreciseGPSvsFilter.png | Another precise GPS vs Filtered GPS data<br />
</gallery><br />
<br />
The overall process even gives an estimation of the current error which is a capability of the [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter].<br />
This way positional inaccuracies may be added to the overall depth measurement inaccuracy.<br />
<br />
== Quality rating ==<br />
<br />
Each record (time, positon, depth) should become a quality rating.<br />
<br />
=== Points ===<br />
<br />
Derived from the Fibonacci series.<br />
<br />
{| class="wikitable"<br />
! Point || Description<br />
|-<br />
| 1 || extra small improvement<br />
|-<br />
| 2 || small improvement<br />
|-<br />
| 3 || medium improvement<br />
|-<br />
| 5 || large improvement<br />
|-<br />
| 8 || extra large improvement<br />
|}<br />
<br />
=== Factors ===<br />
<br />
{| class="wikitable"<br />
! style="width:15%" | Name<br />
! style="width:17%" | Factor<br />
! style="width:68%" | Description<br />
|-<br />
| depth offset || 8 (extra large) || The difference between the depth measured by the echo sounder and the depth (waterline) measured by hand.<br />
|-<br />
| device distance || 3 (medium) || The distance between gps antenna and echo sounder (lengthwise and crosswise).<br />
|-<br />
| SBAS || 3 (medium) || Satellite based augmentation system (WAAS, EGNOS, MSAS) which allows to correct the gps position.<br />
|-<br />
| position interpolation || 2 (small improvement) || Arrival of depth and position packets can have a time difference. It is/should be possible to interpolate the position.<br />
|}<br />
<br />
= Depth Rendering =<br />
<br />
= Siehe auch =<br />
* [[De:Bordnetz|Bordnetz]]<br />
* [[De:NMEA-Logger_anschliessen|NMEA-Logger_anschliessen]]<br />
* [http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCkQFjAA&url=http%3A%2F%2Fwww.dei.unipd.it%2F~chiuso%2FDOWNLOAD%2FPositioning_Heading_Kalman.pdf&ei=sSWNUMWnL4eC4gTRlYHAAw&usg=AFQjCNHq5V-PePNmDTZaGYvq0JeQFgqHVw Kalman Filtering for Positioning and Heading Control of Ships and Offshore Rigs]<br />
* [http://users.isr.ist.utl.pt/~pedro/publications/CAMS10.pdf A Multiple Model Adaptive Wave Filter for Dynamic Ship Positioning]<br />
* [http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4449205&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4449205 Echosounder Depth Tracking with the Extended Kalman Filter]</div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:En:Depth_Data&diff=2952OpenSeaMap-dev:En:Depth Data2014-09-26T19:57:52Z<p>MartinOver: /* Meta Data Stats */</p>
<hr />
<div>This Page describes the necessary efforts to retrieve and analyze depth data as well as create renderings from it<br />
<br />
= Data Aquisition =<br />
Depth data can be retrieved from public domain sources or from crowd sourced data.<br />
<br />
== GEBCO ==<br />
DIe Daten sind gerendert und stehen als Layer zur Verfügung:<br />
{| class="wikitable"<br />
! Zoom || Inhalt<br />
|-<br />
| 0..10 || Blaustufen und Schattierung<br />
|-<br />
| 11..18 || beschriftete Tiefenlinien, Blaustufen und Schattierung<br />
|}<br />
<br />
Noch zu lösende Probleme:<br />
* der GEBCO-Layer erzeugt einen milchigen Schleier über der Basiskarte<br />
* Tiefenlinien sind ab z=14 etwas grob (also ab da, wo dann die Flachwassertiefen beginnen) [http://map.openseamap.org/?zoom=14&lat=36.03097&lon=-5.49153&layers=BFTFTTTFFFF0 Karte]<br />
* Überschneidungen von 100m-Linie und Küstenlinie [http://map.openseamap.org/?zoom=15&lat=36.00318&lon=-5.60819&layers=BFFFTTTFFFF0FFFFF Karte]<br />
* Steilküsten (Cuba) [http://map.openseamap.org/?zoom=14&lat=19.94808&lon=-76.04289&layers=BFTFTTTFFFF0 Karte]<br />
<br />
== Crowd Sourced Data ==<br />
Crowd sourced data may be gathered by YOU. There are two options in development. A hardware and a software option.<br />
<br />
=== Workflow ===<br />
[[Datei:Workflow_depth.png]]<br />
<br />
Here you can find the document with the previous thoughts about the workflow:<br />
[http://osm.franken.de/wiki/FWT-Projekt%C3%BCbersicht-NMEA2Contours_2.1.ppt PPT Dokument]<br />
<br />
=== Hardware logger ===<br />
We are currently developing a hardware logger that may easily be plugged to the ship's network in order to log the networks data to a SD card.<br />
That data may then be uploaded by plugging the SD card to a normal computer with internet connection for upload.<br />
The main goal is to support NMEA 0183 data with options for NMEA 2000.<br />
<br />
=== Software logger ===<br />
A [[Software logger]] is in development and [http://seesea.sourceforge.net/datalogger/index.html can be downloaded here]. <br />
<br />
It currently supports: <br />
: Bluetooth <br />
: Serial ports<br />
: Internet Protocol (IP)<br />
It processes NMEA 0183 and AIS data.<br />
<br />
For vendor specific protocols such as SeaTalk 1 you have to use a [[De:NMEA-Logger_anschliessen|converter]] to NMEA 0183 data.<br />
<br />
NMEA 2000 support is only available if data is transcoded to NMEA 0183 by a converter.<br />
<br />
=== Chart Plotters ===<br />
<br />
Some chart plotters are able to save tracks out-of-the-box, e.g. several Raymarine (FSH files) and Humminbird (SON files) devices. Those files may directly be used as data source.<br />
<br />
<br />
=== Upload Process ===<br />
Uploading data is possible through using the [http://seesea.sourceforge.net/datalogger/index.html OpenSeaMap Data Logger Software] or via [http://depth.openseamap.org/ Web Interface].<br />
The system is currently being tested. <br />
<br />
[[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|You'll find further information here]].<br />
<br />
=== Test Data ===<br />
<br />
<br />
==== Brombachsee (Germany)====<br />
<br />
Test data for Openseamap: [http://osm.franken.de/wiki/test_data_brombachsee.zip Brombachsee_Test_Data]<br />
<br />
dgm_brombachsee.tif: Digital Elevation Model of the sea derived from height lines WWA (C).<br />
<br />
shapes_brombachsee.shp: Shape File derived from 4 NMEA Tracks. "dbs" is the original Sounding and "deep_cor" the depth after a correction (gauge levl).<br />
<br />
gpx_brombachsee.gpx: ele = "dbs" from the Shape File<br />
<br />
[[Datei:Brombachsee.png]]<br />
Resulting Digital Elevation Model<br />
<br />
==== Baltic Sea - near Großenbrode (Germany)====<br />
<br />
First results with an RMS error < 1,5 meter compared to an official dataset of the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].<br />
<br />
[[Datei: Bsh_results_overview.jpg]]<br />
<br />
[Picture 1] '''''OSM map in background, raster Depth Model derived from BSH data and crowed sourced OpenSeaMap Points - Overview'''''<br />
<br />
Blue = flat BSH data, red = deep BSH data.<br />
<br>Blue points = OpenSeaMap raw measuring points.<br />
<br />
{| class="wikitable"<br />
|-<br />
| n || 5062<br />
|-<br />
|-<br />
| datasets || 21<br />
|-<br />
| max deviation || 3,43 meters<br />
|-<br />
| mean (abs) || 0,69 meters<br />
|-<br />
| RMS +/- || 0,91 meters<br />
|}<br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| Manufacturer || Bavaria Yachtbau<br />
|-<br />
| Model || B32<br />
|-<br />
| Length || 10,0 meters<br />
|-<br />
| Beam || 3,35 meters<br />
|-<br />
| Draft || 1,6 meters<br />
|-<br />
| Height || 14 meters<br />
|-<br />
| Displacement || 4,2 t<br />
|-<br />
| Sensor manufacturer || Raymarine<br />
|-<br />
| Sensor Offset || 0,45 meters<br />
|}<br />
<br />
<br />
A digital Deep Model raster was computed from the BSH point dataset (c).<br />
The depth of the crowed sourced dataset was compared to the derived raster dataset from the BSH.<br />
The raw crowed sourced dataset was corrected by the sensor offset (0,45 meters).<br />
<br />
[[Datei: Scatter_cor_sensor.jpeg]]<br />
<br />
[Picture 2] '''''Scatter plot: BSH data on the x-axis and the crowed sourced data on the y-axis. Trend line in black and optimal line in red.'''''<br />
<br />
The deviation from the reference dataset increases with the depth measured.<br />
<br />
As you see in the picture below the difference between the datasets has an regular pattern maybe deepending on waves.<br />
<br />
[[Datei: Bsh_results_detail_10_classes.jpg]]<br />
<br />
[Picture 3] '''''Crowed sourced OpenSeaMap track points and the difference from the BSH dataset'''''<br />
<br />
White = low difference, orange = medium difference, red = strong difference<br />
<br />
Download of the data http://osm.franken.de/data/baltic_sea_test_data.zip<br />
'''Be aware of the copyright from the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].'''<br />
The data in the dataset is not corrected by sensor offset.<br />
<br />
=== Meta Data Stats ===<br />
<br />
Statistik for the metadata entrees with some personal comments (MartinOver). Stand 20.9.2014.<br />
<br />
{| class="prettytable"<br />
|-<br />
|<br />
'''Step'''<br />
<br />
|<br />
'''Topic'''<br />
<br />
|<br />
'''Count'''<br />
<br />
|<br />
'''State'''<br />
<br />
|<br />
'''Comment'''<br />
<br />
|-<br />
|<br />
1/1<br />
<br />
|<br />
Name<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
1/2<br />
<br />
|<br />
Description<br />
<br />
|<br />
76/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/1<br />
<br />
|<br />
Length<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
Some wrong entrees like mail addresses or comments <br />
<br />
24 “0.00” Values<br />
<br />
|-<br />
|<br />
2/2<br />
<br />
|<br />
Beam<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
37 „0.00“ Values<br />
<br />
|-<br />
|<br />
2/3<br />
<br />
|<br />
Draft<br />
<br />
|<br />
79/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/4<br />
<br />
|<br />
Displacement<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/5<br />
<br />
|<br />
Height<br />
<br />
|<br />
78/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/6<br />
<br />
|<br />
Manufacturer<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Model<br />
<br />
|<br />
49/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Type<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/3<br />
<br />
|<br />
Position below Waterline<br />
<br />
|<br />
57/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Should be Obligatory<br />
<br />
|-<br />
|<br />
3/4<br />
<br />
|<br />
Depth Measurement<br />
<br />
|<br />
?<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Where in DB?<br />
<br />
|-<br />
|<br />
3/5<br />
<br />
|<br />
Sensor Offset to Keel<br />
<br />
|<br />
6/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/6<br />
<br />
|<br />
Producer of Depth Sensor<br />
<br />
|<br />
63/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/7<br />
<br />
|<br />
Device Model<br />
<br />
|<br />
40/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
58 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
51 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/3<br />
<br />
|<br />
Position abbove Waterline<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/4<br />
<br />
|<br />
Producer<br />
<br />
|<br />
77/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/5<br />
<br />
|<br />
Model<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|}<br />
<br />
= Data Preprocessing =<br />
<br />
== Data Condition ==<br />
Raw data is usually erronous and must be corrected<br />
<br />
=== Internal data problems ===<br />
Depth data may be affected by electrical conditions and software implementations<br />
* Data is incomplete and fail their checksum (bus errors from physical transmissions errors)<br />
* Data is retrived out of sequence<br />
* Data is erronous sensor data <br />
** Approximate correctable data i.e. invalid GPS position that may be interpolated<br />
** Uncorrectable data i.e. failed log sensor that shows slow speeds<br />
* Data resolution is low i.e. for energy saving purposes GPS position is updated every 10 seconds instead of every second<br />
* Sensor data is actively miscalibrated i.e. charter companies add additional draft to the sensor depth for safety reasons<br />
<br />
=== External data problems ===<br />
Depth data may be affected by different environmental circumstances <br />
*# The water temperature affects the ultrasound echo. An inhomogen water temperature yields unwanted echos<br />
*# The seabed affects the ultrasound echo<br />
*# The seastate affects the measurement. There even may be waves when there is no wind.<br />
*# Waves may affect the roll of the measuring vessel resulting in steep measurements that are invalid.<br />
*# The sounder sensor is not the position of the GPS antenna. A position offset including heading must be incorporated.<br />
*# The time of the measurement need not correlate with the time the position was received. This may even happen due to processing time of the hard or software.<br />
*# Corrections for tide induced water levels must happen<br />
<br />
Solutions probably are<br />
*# Water temperature may be measure from the sensor, other data may be unavailable<br />
*# Modern sidescan sonar may yield information about the seabed through classifications<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# Position offsets must be provided by the user<br />
*# Time outages may be handled by the filter if precise timestamps are available in recorded data<br />
*# LAT to Mean sea level differences may be calculated from DTU10 worldwide, river gauges need to monitored<br />
<br />
[[Datei:LAT2MSLDiff.png]]<br />
<br />
<br />
== Data Condition Examples / Showcases ==<br />
<br />
=== Missing measurments (Position) ===<br />
Distribution for position updates taken from an example dataset. Left column shows the time between two consecutive measurements, right column shows how many measurements had this time update.<br />
One can see from the distribtion that the sensor is updated every second but many measurements are one or more seconds late.<br />
21 seconds with no position update may result in an instability of the subsequent filter.<br />
<pre><br />
MeasuredPosition3D<br />
GP<br />
0 :4285<br />
1000 :11295<br />
2000 :5056<br />
3000 :2134<br />
4000 :1135<br />
5000 :315<br />
6000 :154<br />
7000 :46<br />
8000 :36<br />
9000 :16<br />
10000 :12<br />
11000 :3<br />
12000 :4<br />
13000 :1<br />
14000 :7<br />
15000 :3<br />
16000 :1<br />
21000 :1<br />
</pre><br />
<br />
=== Missing measurments (Position) with erronous clock ===<br />
This example is at a 10 second position update rate. However the measurment time is faulty causing large negative and positive update rates. The clock jumps by +- one year/month/day/hour. One can further see from the many 0 time measurements that the rate at which data is sent to the nmea bus is higher than the actual position update (data is sent every second, a position update is every 10 seconds)<br />
<pre><br />
MeasuredPosition3D<br />
II<br />
-21340000 :1<br />
-13194000 :1<br />
-7998000 :1<br />
-2674000 :1<br />
-2434000 :1<br />
-2402000 :1<br />
-2030000 :1<br />
-1926000 :1<br />
-1894000 :1<br />
-1806000 :1<br />
-1480000 :1<br />
-1430000 :1<br />
-1382000 :1<br />
-1114000 :1<br />
-814000 :1<br />
-634000 :1<br />
-590000 :1<br />
-546000 :1<br />
-470000 :1<br />
-290000 :1<br />
-230000 :1<br />
-198000 :1<br />
-110000 :1<br />
-94000 :2<br />
0 :182200<br />
5000 :1<br />
10000 :20230<br />
15000 :1<br />
20000 :84<br />
50000 :1<br />
114000 :2<br />
130000 :2<br />
218000 :1<br />
250000 :1<br />
310000 :1<br />
490000 :1<br />
566000 :1<br />
610000 :1<br />
654000 :1<br />
834000 :1<br />
1134000 :1<br />
1402000 :1<br />
1450000 :1</pre><br />
<br />
== Solution Proposal ==<br />
<br />
=== Outline ===<br />
The ship is influenced by the outlined environment which can be observed. Naturally what is observed is not the state of the<br />
ship as i.e. the position if taken from GPS is 95% less than 10m accurate. To improve quality an estimation of the true state yields better results if this noise taken into account properly.<br />
<br />
=== Details ===<br />
The ship moves according to physical laws. For the easist case imagine a ship with constant velocity and direction. For any point in time you can tell where the ship is with easy math. Considering the full blown setup a ships movement is affected by many parameters such as wind speed, water current, waves, tide, and many more. The ship moves also triaxial in a dynamic way in itself (roll, pitch, yaw). Heeling even changes the measurement position with respect to the depth position. In terms of a filter this is called a system model that describes how the state of the ship may change. Given such a state you can measure what your sensor readings are and compare that to where the system thinks you are.<br />
<br />
The [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter] is known to be the best linear estimator for such situations. Unfortunately the system model is not linear which is why the Extended Kalman Filter needs to be used in order to linearize the system at hand.<br />
<br />
Todo:<br />
* Construct ship system model with at least the position state and probably its course and speed or even more (depth)<br />
* Estimate the system variance (This is a hard one, proposals welcome)<br />
* Construct the measurement model according to the data available (GPS, Log)<br />
* Estimate the measurement noise according to specifc sensors (DPGS is more accurate than GPS)<br />
<br />
The estimation with the position and depth can be retrieved and stored in a database.<br />
<br />
Pitfalls:<br />
* If the system noise is badly chosen the estimation of the system state does not converge to the true state / measurement.<br />
* If the system is very detailed the system variance can be reduced. The required cpu time for processing increases<br />
<br />
Benefits:<br />
* Having the best estimation of the true position even if measurements are noisy<br />
* Easy and effective algorithmic processing<br />
<br />
== Analysis == <br />
<br />
=== Data Sets ===<br />
Currently two test data sets are available recorded during trips from Mallorca and the Baltic Sea.<br />
In terms of data quality the Mallorca data shows many challenges. <br />
* The minimum recommended sentences from NMEA showed up with false date and time readings while having correct (!!!) message checksums. <br />
* The log on the ship was defective and delivered no readings from time to time. <br />
* The same holds true for the water temperature.<br />
* The GPS positions relatively imprecise because some last decimal digits are missing in the recordings.<br />
* The GPS positions are updated every 10 seconds while other sensor readings update almost every second.<br />
* The GPS position are sometimes way off due to false readings<br />
<br />
The Baltic Sea data set is a little bit better<br />
* Only a single day is available<br />
* GPS positions are updated every second<br />
<br />
One problem with the data is that there is time available when sensor readings were recorded. This yields problems to the filter algorithm.<br />
<br />
<br />
=== Filter Algorithm ===<br />
At first the Extended Kalman Filter is being analyzed. Using an apache implementation with the available data the filter quickly throw an exception that<br />
a matrix is not invertible because of numeric instabilities. When removing this exception the filter seems to work but the removal and its effects have yet to be analyzed.<br />
Literature suggest that a fixed interval smoother may yield better results in case of offline data processing. As it is an extension to the existing kalman filter<br />
we may consider that for the future.<br />
<br />
One problem are the different update rates of the sensors. As GPS may deliver positions at 0.1Hz speed is updated at 1Hz. Literature suggests that<br />
the missing measurements shell be modelled as a random variable with the standard deviation of the sensor. It may even be possible to update covariance matrices only partially with the sensor readings received. Input for the best solution may be formulated on the developer mailing list.<br />
<br />
== Results == <br />
A prototype implementation is shown in the following screenshots. An Extended Kalman Filter is being used. It has the position<br />
and the current bearing and velocity as system state. The input is the measurement of these four observables. The system function is<br />
good old pythagoras. In a first implementation I tried to use orthodrome distances but the system function is not differentiable which is a requirement of the Extended Kalman Filter (due to acrtan2). For small distances pythagoras should be sufficiently accurate. <br />
The initial state is taken from the first measurement for convergence reasons.<br />
<br />
The following gallery shows the results. <br />
* You can see the bad position resolution and an outlier in the first screenshot.<br />
* The second shows the same data overlaid with the applied filter. The outlier is gone and the resolution has improved.<br />
* The third screenshot shows data from a different GPS sensor with more precision (not DGPS) versus the filtered data.<br />
<br />
This of course is just a preliminary test and many setups need to be considered to make it work for most datasets.<br />
<br />
<gallery><br />
UnfilteredNMEA.png | Unfiltered GPS data<br />
FilteredNMEAVsOriginal.png | Unfiltered GPS data and Filtered GPS data<br />
PreciseGPSvsFilter.png | Another precise GPS vs Filtered GPS data<br />
</gallery><br />
<br />
The overall process even gives an estimation of the current error which is a capability of the [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter].<br />
This way positional inaccuracies may be added to the overall depth measurement inaccuracy.<br />
<br />
== Quality rating ==<br />
<br />
Each record (time, positon, depth) should become a quality rating.<br />
<br />
=== Points ===<br />
<br />
Derived from the Fibonacci series.<br />
<br />
{| class="wikitable"<br />
! Point || Description<br />
|-<br />
| 1 || extra small improvement<br />
|-<br />
| 2 || small improvement<br />
|-<br />
| 3 || medium improvement<br />
|-<br />
| 5 || large improvement<br />
|-<br />
| 8 || extra large improvement<br />
|}<br />
<br />
=== Factors ===<br />
<br />
{| class="wikitable"<br />
! style="width:15%" | Name<br />
! style="width:17%" | Factor<br />
! style="width:68%" | Description<br />
|-<br />
| depth offset || 8 (extra large) || The difference between the depth measured by the echo sounder and the depth (waterline) measured by hand.<br />
|-<br />
| device distance || 3 (medium) || The distance between gps antenna and echo sounder (lengthwise and crosswise).<br />
|-<br />
| SBAS || 3 (medium) || Satellite based augmentation system (WAAS, EGNOS, MSAS) which allows to correct the gps position.<br />
|-<br />
| position interpolation || 2 (small improvement) || Arrival of depth and position packets can have a time difference. It is/should be possible to interpolate the position.<br />
|}<br />
<br />
= Depth Rendering =<br />
<br />
= Siehe auch =<br />
* [[De:Bordnetz|Bordnetz]]<br />
* [[De:NMEA-Logger_anschliessen|NMEA-Logger_anschliessen]]<br />
* [http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCkQFjAA&url=http%3A%2F%2Fwww.dei.unipd.it%2F~chiuso%2FDOWNLOAD%2FPositioning_Heading_Kalman.pdf&ei=sSWNUMWnL4eC4gTRlYHAAw&usg=AFQjCNHq5V-PePNmDTZaGYvq0JeQFgqHVw Kalman Filtering for Positioning and Heading Control of Ships and Offshore Rigs]<br />
* [http://users.isr.ist.utl.pt/~pedro/publications/CAMS10.pdf A Multiple Model Adaptive Wave Filter for Dynamic Ship Positioning]<br />
* [http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4449205&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4449205 Echosounder Depth Tracking with the Extended Kalman Filter]</div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:En:Depth_Data&diff=2951OpenSeaMap-dev:En:Depth Data2014-09-26T19:56:11Z<p>MartinOver: /* Meta Data Stats */</p>
<hr />
<div>This Page describes the necessary efforts to retrieve and analyze depth data as well as create renderings from it<br />
<br />
= Data Aquisition =<br />
Depth data can be retrieved from public domain sources or from crowd sourced data.<br />
<br />
== GEBCO ==<br />
DIe Daten sind gerendert und stehen als Layer zur Verfügung:<br />
{| class="wikitable"<br />
! Zoom || Inhalt<br />
|-<br />
| 0..10 || Blaustufen und Schattierung<br />
|-<br />
| 11..18 || beschriftete Tiefenlinien, Blaustufen und Schattierung<br />
|}<br />
<br />
Noch zu lösende Probleme:<br />
* der GEBCO-Layer erzeugt einen milchigen Schleier über der Basiskarte<br />
* Tiefenlinien sind ab z=14 etwas grob (also ab da, wo dann die Flachwassertiefen beginnen) [http://map.openseamap.org/?zoom=14&lat=36.03097&lon=-5.49153&layers=BFTFTTTFFFF0 Karte]<br />
* Überschneidungen von 100m-Linie und Küstenlinie [http://map.openseamap.org/?zoom=15&lat=36.00318&lon=-5.60819&layers=BFFFTTTFFFF0FFFFF Karte]<br />
* Steilküsten (Cuba) [http://map.openseamap.org/?zoom=14&lat=19.94808&lon=-76.04289&layers=BFTFTTTFFFF0 Karte]<br />
<br />
== Crowd Sourced Data ==<br />
Crowd sourced data may be gathered by YOU. There are two options in development. A hardware and a software option.<br />
<br />
=== Workflow ===<br />
[[Datei:Workflow_depth.png]]<br />
<br />
Here you can find the document with the previous thoughts about the workflow:<br />
[http://osm.franken.de/wiki/FWT-Projekt%C3%BCbersicht-NMEA2Contours_2.1.ppt PPT Dokument]<br />
<br />
=== Hardware logger ===<br />
We are currently developing a hardware logger that may easily be plugged to the ship's network in order to log the networks data to a SD card.<br />
That data may then be uploaded by plugging the SD card to a normal computer with internet connection for upload.<br />
The main goal is to support NMEA 0183 data with options for NMEA 2000.<br />
<br />
=== Software logger ===<br />
A [[Software logger]] is in development and [http://seesea.sourceforge.net/datalogger/index.html can be downloaded here]. <br />
<br />
It currently supports: <br />
: Bluetooth <br />
: Serial ports<br />
: Internet Protocol (IP)<br />
It processes NMEA 0183 and AIS data.<br />
<br />
For vendor specific protocols such as SeaTalk 1 you have to use a [[De:NMEA-Logger_anschliessen|converter]] to NMEA 0183 data.<br />
<br />
NMEA 2000 support is only available if data is transcoded to NMEA 0183 by a converter.<br />
<br />
=== Chart Plotters ===<br />
<br />
Some chart plotters are able to save tracks out-of-the-box, e.g. several Raymarine (FSH files) and Humminbird (SON files) devices. Those files may directly be used as data source.<br />
<br />
<br />
=== Upload Process ===<br />
Uploading data is possible through using the [http://seesea.sourceforge.net/datalogger/index.html OpenSeaMap Data Logger Software] or via [http://depth.openseamap.org/ Web Interface].<br />
The system is currently being tested. <br />
<br />
[[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|You'll find further information here]].<br />
<br />
=== Test Data ===<br />
<br />
<br />
==== Brombachsee (Germany)====<br />
<br />
Test data for Openseamap: [http://osm.franken.de/wiki/test_data_brombachsee.zip Brombachsee_Test_Data]<br />
<br />
dgm_brombachsee.tif: Digital Elevation Model of the sea derived from height lines WWA (C).<br />
<br />
shapes_brombachsee.shp: Shape File derived from 4 NMEA Tracks. "dbs" is the original Sounding and "deep_cor" the depth after a correction (gauge levl).<br />
<br />
gpx_brombachsee.gpx: ele = "dbs" from the Shape File<br />
<br />
[[Datei:Brombachsee.png]]<br />
Resulting Digital Elevation Model<br />
<br />
==== Baltic Sea - near Großenbrode (Germany)====<br />
<br />
First results with an RMS error < 1,5 meter compared to an official dataset of the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].<br />
<br />
[[Datei: Bsh_results_overview.jpg]]<br />
<br />
[Picture 1] '''''OSM map in background, raster Depth Model derived from BSH data and crowed sourced OpenSeaMap Points - Overview'''''<br />
<br />
Blue = flat BSH data, red = deep BSH data.<br />
<br>Blue points = OpenSeaMap raw measuring points.<br />
<br />
{| class="wikitable"<br />
|-<br />
| n || 5062<br />
|-<br />
|-<br />
| datasets || 21<br />
|-<br />
| max deviation || 3,43 meters<br />
|-<br />
| mean (abs) || 0,69 meters<br />
|-<br />
| RMS +/- || 0,91 meters<br />
|}<br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| Manufacturer || Bavaria Yachtbau<br />
|-<br />
| Model || B32<br />
|-<br />
| Length || 10,0 meters<br />
|-<br />
| Beam || 3,35 meters<br />
|-<br />
| Draft || 1,6 meters<br />
|-<br />
| Height || 14 meters<br />
|-<br />
| Displacement || 4,2 t<br />
|-<br />
| Sensor manufacturer || Raymarine<br />
|-<br />
| Sensor Offset || 0,45 meters<br />
|}<br />
<br />
<br />
A digital Deep Model raster was computed from the BSH point dataset (c).<br />
The depth of the crowed sourced dataset was compared to the derived raster dataset from the BSH.<br />
The raw crowed sourced dataset was corrected by the sensor offset (0,45 meters).<br />
<br />
[[Datei: Scatter_cor_sensor.jpeg]]<br />
<br />
[Picture 2] '''''Scatter plot: BSH data on the x-axis and the crowed sourced data on the y-axis. Trend line in black and optimal line in red.'''''<br />
<br />
The deviation from the reference dataset increases with the depth measured.<br />
<br />
As you see in the picture below the difference between the datasets has an regular pattern maybe deepending on waves.<br />
<br />
[[Datei: Bsh_results_detail_10_classes.jpg]]<br />
<br />
[Picture 3] '''''Crowed sourced OpenSeaMap track points and the difference from the BSH dataset'''''<br />
<br />
White = low difference, orange = medium difference, red = strong difference<br />
<br />
Download of the data http://osm.franken.de/data/baltic_sea_test_data.zip<br />
'''Be aware of the copyright from the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].'''<br />
The data in the dataset is not corrected by sensor offset.<br />
<br />
=== Meta Data Stats ===<br />
<br />
Stand 20.9.2014<br />
<br />
{| class="prettytable"<br />
|-<br />
|<br />
'''Step'''<br />
<br />
|<br />
'''Topic'''<br />
<br />
|<br />
'''Count'''<br />
<br />
|<br />
'''State'''<br />
<br />
|<br />
'''Comment'''<br />
<br />
|-<br />
|<br />
1/1<br />
<br />
|<br />
Name<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
1/2<br />
<br />
|<br />
Description<br />
<br />
|<br />
76/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/1<br />
<br />
|<br />
Length<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
Some wrong entrees like mail addresses or comments <br />
<br />
24 “0.00” Values<br />
<br />
|-<br />
|<br />
2/2<br />
<br />
|<br />
Beam<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
37 „0.00“ Values<br />
<br />
|-<br />
|<br />
2/3<br />
<br />
|<br />
Draft<br />
<br />
|<br />
79/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/4<br />
<br />
|<br />
Displacement<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/5<br />
<br />
|<br />
Height<br />
<br />
|<br />
78/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/6<br />
<br />
|<br />
Manufacturer<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Model<br />
<br />
|<br />
49/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
2/7<br />
<br />
|<br />
Type<br />
<br />
|<br />
72/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
55 “0.0” Values<br />
<br />
|-<br />
|<br />
3/3<br />
<br />
|<br />
Position below Waterline<br />
<br />
|<br />
57/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Should be Obligatory<br />
<br />
|-<br />
|<br />
3/4<br />
<br />
|<br />
Depth Measurement<br />
<br />
|<br />
?<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
Where in DB?<br />
<br />
|-<br />
|<br />
3/5<br />
<br />
|<br />
Sensor Offset to Keel<br />
<br />
|<br />
6/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/6<br />
<br />
|<br />
Producer of Depth Sensor<br />
<br />
|<br />
63/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
3/7<br />
<br />
|<br />
Device Model<br />
<br />
|<br />
40/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/1<br />
<br />
|<br />
Distance from Stern<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
58 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/2<br />
<br />
|<br />
Distance from Centerline<br />
<br />
|<br />
118/118<br />
<br />
|<br />
Obligatory<br />
<br />
|<br />
51 „0.0“ Values<br />
<br />
|-<br />
|<br />
4/3<br />
<br />
|<br />
Position abbove Waterline<br />
<br />
|<br />
52/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/4<br />
<br />
|<br />
Producer<br />
<br />
|<br />
77/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|-<br />
|<br />
4/5<br />
<br />
|<br />
Model<br />
<br />
|<br />
60/118<br />
<br />
|<br />
Manditory<br />
<br />
|<br />
<br />
<br />
|}<br />
<br />
= Data Preprocessing =<br />
<br />
== Data Condition ==<br />
Raw data is usually erronous and must be corrected<br />
<br />
=== Internal data problems ===<br />
Depth data may be affected by electrical conditions and software implementations<br />
* Data is incomplete and fail their checksum (bus errors from physical transmissions errors)<br />
* Data is retrived out of sequence<br />
* Data is erronous sensor data <br />
** Approximate correctable data i.e. invalid GPS position that may be interpolated<br />
** Uncorrectable data i.e. failed log sensor that shows slow speeds<br />
* Data resolution is low i.e. for energy saving purposes GPS position is updated every 10 seconds instead of every second<br />
* Sensor data is actively miscalibrated i.e. charter companies add additional draft to the sensor depth for safety reasons<br />
<br />
=== External data problems ===<br />
Depth data may be affected by different environmental circumstances <br />
*# The water temperature affects the ultrasound echo. An inhomogen water temperature yields unwanted echos<br />
*# The seabed affects the ultrasound echo<br />
*# The seastate affects the measurement. There even may be waves when there is no wind.<br />
*# Waves may affect the roll of the measuring vessel resulting in steep measurements that are invalid.<br />
*# The sounder sensor is not the position of the GPS antenna. A position offset including heading must be incorporated.<br />
*# The time of the measurement need not correlate with the time the position was received. This may even happen due to processing time of the hard or software.<br />
*# Corrections for tide induced water levels must happen<br />
<br />
Solutions probably are<br />
*# Water temperature may be measure from the sensor, other data may be unavailable<br />
*# Modern sidescan sonar may yield information about the seabed through classifications<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# Position offsets must be provided by the user<br />
*# Time outages may be handled by the filter if precise timestamps are available in recorded data<br />
*# LAT to Mean sea level differences may be calculated from DTU10 worldwide, river gauges need to monitored<br />
<br />
[[Datei:LAT2MSLDiff.png]]<br />
<br />
<br />
== Data Condition Examples / Showcases ==<br />
<br />
=== Missing measurments (Position) ===<br />
Distribution for position updates taken from an example dataset. Left column shows the time between two consecutive measurements, right column shows how many measurements had this time update.<br />
One can see from the distribtion that the sensor is updated every second but many measurements are one or more seconds late.<br />
21 seconds with no position update may result in an instability of the subsequent filter.<br />
<pre><br />
MeasuredPosition3D<br />
GP<br />
0 :4285<br />
1000 :11295<br />
2000 :5056<br />
3000 :2134<br />
4000 :1135<br />
5000 :315<br />
6000 :154<br />
7000 :46<br />
8000 :36<br />
9000 :16<br />
10000 :12<br />
11000 :3<br />
12000 :4<br />
13000 :1<br />
14000 :7<br />
15000 :3<br />
16000 :1<br />
21000 :1<br />
</pre><br />
<br />
=== Missing measurments (Position) with erronous clock ===<br />
This example is at a 10 second position update rate. However the measurment time is faulty causing large negative and positive update rates. The clock jumps by +- one year/month/day/hour. One can further see from the many 0 time measurements that the rate at which data is sent to the nmea bus is higher than the actual position update (data is sent every second, a position update is every 10 seconds)<br />
<pre><br />
MeasuredPosition3D<br />
II<br />
-21340000 :1<br />
-13194000 :1<br />
-7998000 :1<br />
-2674000 :1<br />
-2434000 :1<br />
-2402000 :1<br />
-2030000 :1<br />
-1926000 :1<br />
-1894000 :1<br />
-1806000 :1<br />
-1480000 :1<br />
-1430000 :1<br />
-1382000 :1<br />
-1114000 :1<br />
-814000 :1<br />
-634000 :1<br />
-590000 :1<br />
-546000 :1<br />
-470000 :1<br />
-290000 :1<br />
-230000 :1<br />
-198000 :1<br />
-110000 :1<br />
-94000 :2<br />
0 :182200<br />
5000 :1<br />
10000 :20230<br />
15000 :1<br />
20000 :84<br />
50000 :1<br />
114000 :2<br />
130000 :2<br />
218000 :1<br />
250000 :1<br />
310000 :1<br />
490000 :1<br />
566000 :1<br />
610000 :1<br />
654000 :1<br />
834000 :1<br />
1134000 :1<br />
1402000 :1<br />
1450000 :1</pre><br />
<br />
== Solution Proposal ==<br />
<br />
=== Outline ===<br />
The ship is influenced by the outlined environment which can be observed. Naturally what is observed is not the state of the<br />
ship as i.e. the position if taken from GPS is 95% less than 10m accurate. To improve quality an estimation of the true state yields better results if this noise taken into account properly.<br />
<br />
=== Details ===<br />
The ship moves according to physical laws. For the easist case imagine a ship with constant velocity and direction. For any point in time you can tell where the ship is with easy math. Considering the full blown setup a ships movement is affected by many parameters such as wind speed, water current, waves, tide, and many more. The ship moves also triaxial in a dynamic way in itself (roll, pitch, yaw). Heeling even changes the measurement position with respect to the depth position. In terms of a filter this is called a system model that describes how the state of the ship may change. Given such a state you can measure what your sensor readings are and compare that to where the system thinks you are.<br />
<br />
The [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter] is known to be the best linear estimator for such situations. Unfortunately the system model is not linear which is why the Extended Kalman Filter needs to be used in order to linearize the system at hand.<br />
<br />
Todo:<br />
* Construct ship system model with at least the position state and probably its course and speed or even more (depth)<br />
* Estimate the system variance (This is a hard one, proposals welcome)<br />
* Construct the measurement model according to the data available (GPS, Log)<br />
* Estimate the measurement noise according to specifc sensors (DPGS is more accurate than GPS)<br />
<br />
The estimation with the position and depth can be retrieved and stored in a database.<br />
<br />
Pitfalls:<br />
* If the system noise is badly chosen the estimation of the system state does not converge to the true state / measurement.<br />
* If the system is very detailed the system variance can be reduced. The required cpu time for processing increases<br />
<br />
Benefits:<br />
* Having the best estimation of the true position even if measurements are noisy<br />
* Easy and effective algorithmic processing<br />
<br />
== Analysis == <br />
<br />
=== Data Sets ===<br />
Currently two test data sets are available recorded during trips from Mallorca and the Baltic Sea.<br />
In terms of data quality the Mallorca data shows many challenges. <br />
* The minimum recommended sentences from NMEA showed up with false date and time readings while having correct (!!!) message checksums. <br />
* The log on the ship was defective and delivered no readings from time to time. <br />
* The same holds true for the water temperature.<br />
* The GPS positions relatively imprecise because some last decimal digits are missing in the recordings.<br />
* The GPS positions are updated every 10 seconds while other sensor readings update almost every second.<br />
* The GPS position are sometimes way off due to false readings<br />
<br />
The Baltic Sea data set is a little bit better<br />
* Only a single day is available<br />
* GPS positions are updated every second<br />
<br />
One problem with the data is that there is time available when sensor readings were recorded. This yields problems to the filter algorithm.<br />
<br />
<br />
=== Filter Algorithm ===<br />
At first the Extended Kalman Filter is being analyzed. Using an apache implementation with the available data the filter quickly throw an exception that<br />
a matrix is not invertible because of numeric instabilities. When removing this exception the filter seems to work but the removal and its effects have yet to be analyzed.<br />
Literature suggest that a fixed interval smoother may yield better results in case of offline data processing. As it is an extension to the existing kalman filter<br />
we may consider that for the future.<br />
<br />
One problem are the different update rates of the sensors. As GPS may deliver positions at 0.1Hz speed is updated at 1Hz. Literature suggests that<br />
the missing measurements shell be modelled as a random variable with the standard deviation of the sensor. It may even be possible to update covariance matrices only partially with the sensor readings received. Input for the best solution may be formulated on the developer mailing list.<br />
<br />
== Results == <br />
A prototype implementation is shown in the following screenshots. An Extended Kalman Filter is being used. It has the position<br />
and the current bearing and velocity as system state. The input is the measurement of these four observables. The system function is<br />
good old pythagoras. In a first implementation I tried to use orthodrome distances but the system function is not differentiable which is a requirement of the Extended Kalman Filter (due to acrtan2). For small distances pythagoras should be sufficiently accurate. <br />
The initial state is taken from the first measurement for convergence reasons.<br />
<br />
The following gallery shows the results. <br />
* You can see the bad position resolution and an outlier in the first screenshot.<br />
* The second shows the same data overlaid with the applied filter. The outlier is gone and the resolution has improved.<br />
* The third screenshot shows data from a different GPS sensor with more precision (not DGPS) versus the filtered data.<br />
<br />
This of course is just a preliminary test and many setups need to be considered to make it work for most datasets.<br />
<br />
<gallery><br />
UnfilteredNMEA.png | Unfiltered GPS data<br />
FilteredNMEAVsOriginal.png | Unfiltered GPS data and Filtered GPS data<br />
PreciseGPSvsFilter.png | Another precise GPS vs Filtered GPS data<br />
</gallery><br />
<br />
The overall process even gives an estimation of the current error which is a capability of the [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter].<br />
This way positional inaccuracies may be added to the overall depth measurement inaccuracy.<br />
<br />
== Quality rating ==<br />
<br />
Each record (time, positon, depth) should become a quality rating.<br />
<br />
=== Points ===<br />
<br />
Derived from the Fibonacci series.<br />
<br />
{| class="wikitable"<br />
! Point || Description<br />
|-<br />
| 1 || extra small improvement<br />
|-<br />
| 2 || small improvement<br />
|-<br />
| 3 || medium improvement<br />
|-<br />
| 5 || large improvement<br />
|-<br />
| 8 || extra large improvement<br />
|}<br />
<br />
=== Factors ===<br />
<br />
{| class="wikitable"<br />
! style="width:15%" | Name<br />
! style="width:17%" | Factor<br />
! style="width:68%" | Description<br />
|-<br />
| depth offset || 8 (extra large) || The difference between the depth measured by the echo sounder and the depth (waterline) measured by hand.<br />
|-<br />
| device distance || 3 (medium) || The distance between gps antenna and echo sounder (lengthwise and crosswise).<br />
|-<br />
| SBAS || 3 (medium) || Satellite based augmentation system (WAAS, EGNOS, MSAS) which allows to correct the gps position.<br />
|-<br />
| position interpolation || 2 (small improvement) || Arrival of depth and position packets can have a time difference. It is/should be possible to interpolate the position.<br />
|}<br />
<br />
= Depth Rendering =<br />
<br />
= Siehe auch =<br />
* [[De:Bordnetz|Bordnetz]]<br />
* [[De:NMEA-Logger_anschliessen|NMEA-Logger_anschliessen]]<br />
* [http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCkQFjAA&url=http%3A%2F%2Fwww.dei.unipd.it%2F~chiuso%2FDOWNLOAD%2FPositioning_Heading_Kalman.pdf&ei=sSWNUMWnL4eC4gTRlYHAAw&usg=AFQjCNHq5V-PePNmDTZaGYvq0JeQFgqHVw Kalman Filtering for Positioning and Heading Control of Ships and Offshore Rigs]<br />
* [http://users.isr.ist.utl.pt/~pedro/publications/CAMS10.pdf A Multiple Model Adaptive Wave Filter for Dynamic Ship Positioning]<br />
* [http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4449205&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4449205 Echosounder Depth Tracking with the Extended Kalman Filter]</div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:En:Depth_Data&diff=2950OpenSeaMap-dev:En:Depth Data2014-09-26T19:54:59Z<p>MartinOver: /* Data Preprocessing */</p>
<hr />
<div>This Page describes the necessary efforts to retrieve and analyze depth data as well as create renderings from it<br />
<br />
= Data Aquisition =<br />
Depth data can be retrieved from public domain sources or from crowd sourced data.<br />
<br />
== GEBCO ==<br />
DIe Daten sind gerendert und stehen als Layer zur Verfügung:<br />
{| class="wikitable"<br />
! Zoom || Inhalt<br />
|-<br />
| 0..10 || Blaustufen und Schattierung<br />
|-<br />
| 11..18 || beschriftete Tiefenlinien, Blaustufen und Schattierung<br />
|}<br />
<br />
Noch zu lösende Probleme:<br />
* der GEBCO-Layer erzeugt einen milchigen Schleier über der Basiskarte<br />
* Tiefenlinien sind ab z=14 etwas grob (also ab da, wo dann die Flachwassertiefen beginnen) [http://map.openseamap.org/?zoom=14&lat=36.03097&lon=-5.49153&layers=BFTFTTTFFFF0 Karte]<br />
* Überschneidungen von 100m-Linie und Küstenlinie [http://map.openseamap.org/?zoom=15&lat=36.00318&lon=-5.60819&layers=BFFFTTTFFFF0FFFFF Karte]<br />
* Steilküsten (Cuba) [http://map.openseamap.org/?zoom=14&lat=19.94808&lon=-76.04289&layers=BFTFTTTFFFF0 Karte]<br />
<br />
== Crowd Sourced Data ==<br />
Crowd sourced data may be gathered by YOU. There are two options in development. A hardware and a software option.<br />
<br />
=== Workflow ===<br />
[[Datei:Workflow_depth.png]]<br />
<br />
Here you can find the document with the previous thoughts about the workflow:<br />
[http://osm.franken.de/wiki/FWT-Projekt%C3%BCbersicht-NMEA2Contours_2.1.ppt PPT Dokument]<br />
<br />
=== Hardware logger ===<br />
We are currently developing a hardware logger that may easily be plugged to the ship's network in order to log the networks data to a SD card.<br />
That data may then be uploaded by plugging the SD card to a normal computer with internet connection for upload.<br />
The main goal is to support NMEA 0183 data with options for NMEA 2000.<br />
<br />
=== Software logger ===<br />
A [[Software logger]] is in development and [http://seesea.sourceforge.net/datalogger/index.html can be downloaded here]. <br />
<br />
It currently supports: <br />
: Bluetooth <br />
: Serial ports<br />
: Internet Protocol (IP)<br />
It processes NMEA 0183 and AIS data.<br />
<br />
For vendor specific protocols such as SeaTalk 1 you have to use a [[De:NMEA-Logger_anschliessen|converter]] to NMEA 0183 data.<br />
<br />
NMEA 2000 support is only available if data is transcoded to NMEA 0183 by a converter.<br />
<br />
=== Chart Plotters ===<br />
<br />
Some chart plotters are able to save tracks out-of-the-box, e.g. several Raymarine (FSH files) and Humminbird (SON files) devices. Those files may directly be used as data source.<br />
<br />
<br />
=== Upload Process ===<br />
Uploading data is possible through using the [http://seesea.sourceforge.net/datalogger/index.html OpenSeaMap Data Logger Software] or via [http://depth.openseamap.org/ Web Interface].<br />
The system is currently being tested. <br />
<br />
[[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|You'll find further information here]].<br />
<br />
=== Test Data ===<br />
<br />
<br />
==== Brombachsee (Germany)====<br />
<br />
Test data for Openseamap: [http://osm.franken.de/wiki/test_data_brombachsee.zip Brombachsee_Test_Data]<br />
<br />
dgm_brombachsee.tif: Digital Elevation Model of the sea derived from height lines WWA (C).<br />
<br />
shapes_brombachsee.shp: Shape File derived from 4 NMEA Tracks. "dbs" is the original Sounding and "deep_cor" the depth after a correction (gauge levl).<br />
<br />
gpx_brombachsee.gpx: ele = "dbs" from the Shape File<br />
<br />
[[Datei:Brombachsee.png]]<br />
Resulting Digital Elevation Model<br />
<br />
==== Baltic Sea - near Großenbrode (Germany)====<br />
<br />
First results with an RMS error < 1,5 meter compared to an official dataset of the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].<br />
<br />
[[Datei: Bsh_results_overview.jpg]]<br />
<br />
[Picture 1] '''''OSM map in background, raster Depth Model derived from BSH data and crowed sourced OpenSeaMap Points - Overview'''''<br />
<br />
Blue = flat BSH data, red = deep BSH data.<br />
<br>Blue points = OpenSeaMap raw measuring points.<br />
<br />
{| class="wikitable"<br />
|-<br />
| n || 5062<br />
|-<br />
|-<br />
| datasets || 21<br />
|-<br />
| max deviation || 3,43 meters<br />
|-<br />
| mean (abs) || 0,69 meters<br />
|-<br />
| RMS +/- || 0,91 meters<br />
|}<br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| Manufacturer || Bavaria Yachtbau<br />
|-<br />
| Model || B32<br />
|-<br />
| Length || 10,0 meters<br />
|-<br />
| Beam || 3,35 meters<br />
|-<br />
| Draft || 1,6 meters<br />
|-<br />
| Height || 14 meters<br />
|-<br />
| Displacement || 4,2 t<br />
|-<br />
| Sensor manufacturer || Raymarine<br />
|-<br />
| Sensor Offset || 0,45 meters<br />
|}<br />
<br />
<br />
A digital Deep Model raster was computed from the BSH point dataset (c).<br />
The depth of the crowed sourced dataset was compared to the derived raster dataset from the BSH.<br />
The raw crowed sourced dataset was corrected by the sensor offset (0,45 meters).<br />
<br />
[[Datei: Scatter_cor_sensor.jpeg]]<br />
<br />
[Picture 2] '''''Scatter plot: BSH data on the x-axis and the crowed sourced data on the y-axis. Trend line in black and optimal line in red.'''''<br />
<br />
The deviation from the reference dataset increases with the depth measured.<br />
<br />
As you see in the picture below the difference between the datasets has an regular pattern maybe deepending on waves.<br />
<br />
[[Datei: Bsh_results_detail_10_classes.jpg]]<br />
<br />
[Picture 3] '''''Crowed sourced OpenSeaMap track points and the difference from the BSH dataset'''''<br />
<br />
White = low difference, orange = medium difference, red = strong difference<br />
<br />
Download of the data http://osm.franken.de/data/baltic_sea_test_data.zip<br />
'''Be aware of the copyright from the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].'''<br />
The data in the dataset is not corrected by sensor offset.<br />
<br />
=== Meta Data Stats ===<br />
= Data Preprocessing =<br />
<br />
== Data Condition ==<br />
Raw data is usually erronous and must be corrected<br />
<br />
=== Internal data problems ===<br />
Depth data may be affected by electrical conditions and software implementations<br />
* Data is incomplete and fail their checksum (bus errors from physical transmissions errors)<br />
* Data is retrived out of sequence<br />
* Data is erronous sensor data <br />
** Approximate correctable data i.e. invalid GPS position that may be interpolated<br />
** Uncorrectable data i.e. failed log sensor that shows slow speeds<br />
* Data resolution is low i.e. for energy saving purposes GPS position is updated every 10 seconds instead of every second<br />
* Sensor data is actively miscalibrated i.e. charter companies add additional draft to the sensor depth for safety reasons<br />
<br />
=== External data problems ===<br />
Depth data may be affected by different environmental circumstances <br />
*# The water temperature affects the ultrasound echo. An inhomogen water temperature yields unwanted echos<br />
*# The seabed affects the ultrasound echo<br />
*# The seastate affects the measurement. There even may be waves when there is no wind.<br />
*# Waves may affect the roll of the measuring vessel resulting in steep measurements that are invalid.<br />
*# The sounder sensor is not the position of the GPS antenna. A position offset including heading must be incorporated.<br />
*# The time of the measurement need not correlate with the time the position was received. This may even happen due to processing time of the hard or software.<br />
*# Corrections for tide induced water levels must happen<br />
<br />
Solutions probably are<br />
*# Water temperature may be measure from the sensor, other data may be unavailable<br />
*# Modern sidescan sonar may yield information about the seabed through classifications<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# Position offsets must be provided by the user<br />
*# Time outages may be handled by the filter if precise timestamps are available in recorded data<br />
*# LAT to Mean sea level differences may be calculated from DTU10 worldwide, river gauges need to monitored<br />
<br />
[[Datei:LAT2MSLDiff.png]]<br />
<br />
<br />
== Data Condition Examples / Showcases ==<br />
<br />
=== Missing measurments (Position) ===<br />
Distribution for position updates taken from an example dataset. Left column shows the time between two consecutive measurements, right column shows how many measurements had this time update.<br />
One can see from the distribtion that the sensor is updated every second but many measurements are one or more seconds late.<br />
21 seconds with no position update may result in an instability of the subsequent filter.<br />
<pre><br />
MeasuredPosition3D<br />
GP<br />
0 :4285<br />
1000 :11295<br />
2000 :5056<br />
3000 :2134<br />
4000 :1135<br />
5000 :315<br />
6000 :154<br />
7000 :46<br />
8000 :36<br />
9000 :16<br />
10000 :12<br />
11000 :3<br />
12000 :4<br />
13000 :1<br />
14000 :7<br />
15000 :3<br />
16000 :1<br />
21000 :1<br />
</pre><br />
<br />
=== Missing measurments (Position) with erronous clock ===<br />
This example is at a 10 second position update rate. However the measurment time is faulty causing large negative and positive update rates. The clock jumps by +- one year/month/day/hour. One can further see from the many 0 time measurements that the rate at which data is sent to the nmea bus is higher than the actual position update (data is sent every second, a position update is every 10 seconds)<br />
<pre><br />
MeasuredPosition3D<br />
II<br />
-21340000 :1<br />
-13194000 :1<br />
-7998000 :1<br />
-2674000 :1<br />
-2434000 :1<br />
-2402000 :1<br />
-2030000 :1<br />
-1926000 :1<br />
-1894000 :1<br />
-1806000 :1<br />
-1480000 :1<br />
-1430000 :1<br />
-1382000 :1<br />
-1114000 :1<br />
-814000 :1<br />
-634000 :1<br />
-590000 :1<br />
-546000 :1<br />
-470000 :1<br />
-290000 :1<br />
-230000 :1<br />
-198000 :1<br />
-110000 :1<br />
-94000 :2<br />
0 :182200<br />
5000 :1<br />
10000 :20230<br />
15000 :1<br />
20000 :84<br />
50000 :1<br />
114000 :2<br />
130000 :2<br />
218000 :1<br />
250000 :1<br />
310000 :1<br />
490000 :1<br />
566000 :1<br />
610000 :1<br />
654000 :1<br />
834000 :1<br />
1134000 :1<br />
1402000 :1<br />
1450000 :1</pre><br />
<br />
== Solution Proposal ==<br />
<br />
=== Outline ===<br />
The ship is influenced by the outlined environment which can be observed. Naturally what is observed is not the state of the<br />
ship as i.e. the position if taken from GPS is 95% less than 10m accurate. To improve quality an estimation of the true state yields better results if this noise taken into account properly.<br />
<br />
=== Details ===<br />
The ship moves according to physical laws. For the easist case imagine a ship with constant velocity and direction. For any point in time you can tell where the ship is with easy math. Considering the full blown setup a ships movement is affected by many parameters such as wind speed, water current, waves, tide, and many more. The ship moves also triaxial in a dynamic way in itself (roll, pitch, yaw). Heeling even changes the measurement position with respect to the depth position. In terms of a filter this is called a system model that describes how the state of the ship may change. Given such a state you can measure what your sensor readings are and compare that to where the system thinks you are.<br />
<br />
The [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter] is known to be the best linear estimator for such situations. Unfortunately the system model is not linear which is why the Extended Kalman Filter needs to be used in order to linearize the system at hand.<br />
<br />
Todo:<br />
* Construct ship system model with at least the position state and probably its course and speed or even more (depth)<br />
* Estimate the system variance (This is a hard one, proposals welcome)<br />
* Construct the measurement model according to the data available (GPS, Log)<br />
* Estimate the measurement noise according to specifc sensors (DPGS is more accurate than GPS)<br />
<br />
The estimation with the position and depth can be retrieved and stored in a database.<br />
<br />
Pitfalls:<br />
* If the system noise is badly chosen the estimation of the system state does not converge to the true state / measurement.<br />
* If the system is very detailed the system variance can be reduced. The required cpu time for processing increases<br />
<br />
Benefits:<br />
* Having the best estimation of the true position even if measurements are noisy<br />
* Easy and effective algorithmic processing<br />
<br />
== Analysis == <br />
<br />
=== Data Sets ===<br />
Currently two test data sets are available recorded during trips from Mallorca and the Baltic Sea.<br />
In terms of data quality the Mallorca data shows many challenges. <br />
* The minimum recommended sentences from NMEA showed up with false date and time readings while having correct (!!!) message checksums. <br />
* The log on the ship was defective and delivered no readings from time to time. <br />
* The same holds true for the water temperature.<br />
* The GPS positions relatively imprecise because some last decimal digits are missing in the recordings.<br />
* The GPS positions are updated every 10 seconds while other sensor readings update almost every second.<br />
* The GPS position are sometimes way off due to false readings<br />
<br />
The Baltic Sea data set is a little bit better<br />
* Only a single day is available<br />
* GPS positions are updated every second<br />
<br />
One problem with the data is that there is time available when sensor readings were recorded. This yields problems to the filter algorithm.<br />
<br />
<br />
=== Filter Algorithm ===<br />
At first the Extended Kalman Filter is being analyzed. Using an apache implementation with the available data the filter quickly throw an exception that<br />
a matrix is not invertible because of numeric instabilities. When removing this exception the filter seems to work but the removal and its effects have yet to be analyzed.<br />
Literature suggest that a fixed interval smoother may yield better results in case of offline data processing. As it is an extension to the existing kalman filter<br />
we may consider that for the future.<br />
<br />
One problem are the different update rates of the sensors. As GPS may deliver positions at 0.1Hz speed is updated at 1Hz. Literature suggests that<br />
the missing measurements shell be modelled as a random variable with the standard deviation of the sensor. It may even be possible to update covariance matrices only partially with the sensor readings received. Input for the best solution may be formulated on the developer mailing list.<br />
<br />
== Results == <br />
A prototype implementation is shown in the following screenshots. An Extended Kalman Filter is being used. It has the position<br />
and the current bearing and velocity as system state. The input is the measurement of these four observables. The system function is<br />
good old pythagoras. In a first implementation I tried to use orthodrome distances but the system function is not differentiable which is a requirement of the Extended Kalman Filter (due to acrtan2). For small distances pythagoras should be sufficiently accurate. <br />
The initial state is taken from the first measurement for convergence reasons.<br />
<br />
The following gallery shows the results. <br />
* You can see the bad position resolution and an outlier in the first screenshot.<br />
* The second shows the same data overlaid with the applied filter. The outlier is gone and the resolution has improved.<br />
* The third screenshot shows data from a different GPS sensor with more precision (not DGPS) versus the filtered data.<br />
<br />
This of course is just a preliminary test and many setups need to be considered to make it work for most datasets.<br />
<br />
<gallery><br />
UnfilteredNMEA.png | Unfiltered GPS data<br />
FilteredNMEAVsOriginal.png | Unfiltered GPS data and Filtered GPS data<br />
PreciseGPSvsFilter.png | Another precise GPS vs Filtered GPS data<br />
</gallery><br />
<br />
The overall process even gives an estimation of the current error which is a capability of the [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter].<br />
This way positional inaccuracies may be added to the overall depth measurement inaccuracy.<br />
<br />
== Quality rating ==<br />
<br />
Each record (time, positon, depth) should become a quality rating.<br />
<br />
=== Points ===<br />
<br />
Derived from the Fibonacci series.<br />
<br />
{| class="wikitable"<br />
! Point || Description<br />
|-<br />
| 1 || extra small improvement<br />
|-<br />
| 2 || small improvement<br />
|-<br />
| 3 || medium improvement<br />
|-<br />
| 5 || large improvement<br />
|-<br />
| 8 || extra large improvement<br />
|}<br />
<br />
=== Factors ===<br />
<br />
{| class="wikitable"<br />
! style="width:15%" | Name<br />
! style="width:17%" | Factor<br />
! style="width:68%" | Description<br />
|-<br />
| depth offset || 8 (extra large) || The difference between the depth measured by the echo sounder and the depth (waterline) measured by hand.<br />
|-<br />
| device distance || 3 (medium) || The distance between gps antenna and echo sounder (lengthwise and crosswise).<br />
|-<br />
| SBAS || 3 (medium) || Satellite based augmentation system (WAAS, EGNOS, MSAS) which allows to correct the gps position.<br />
|-<br />
| position interpolation || 2 (small improvement) || Arrival of depth and position packets can have a time difference. It is/should be possible to interpolate the position.<br />
|}<br />
<br />
= Depth Rendering =<br />
<br />
= Siehe auch =<br />
* [[De:Bordnetz|Bordnetz]]<br />
* [[De:NMEA-Logger_anschliessen|NMEA-Logger_anschliessen]]<br />
* [http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCkQFjAA&url=http%3A%2F%2Fwww.dei.unipd.it%2F~chiuso%2FDOWNLOAD%2FPositioning_Heading_Kalman.pdf&ei=sSWNUMWnL4eC4gTRlYHAAw&usg=AFQjCNHq5V-PePNmDTZaGYvq0JeQFgqHVw Kalman Filtering for Positioning and Heading Control of Ships and Offshore Rigs]<br />
* [http://users.isr.ist.utl.pt/~pedro/publications/CAMS10.pdf A Multiple Model Adaptive Wave Filter for Dynamic Ship Positioning]<br />
* [http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4449205&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4449205 Echosounder Depth Tracking with the Extended Kalman Filter]</div>MartinOverhttps://wiki.openseamap.org/index.php?title=OpenSeaMap-dev:En:Depth_Data&diff=2949OpenSeaMap-dev:En:Depth Data2014-09-26T19:04:32Z<p>MartinOver: /* Baltic Sea - near Großenbrode (Germany) */</p>
<hr />
<div>This Page describes the necessary efforts to retrieve and analyze depth data as well as create renderings from it<br />
<br />
= Data Aquisition =<br />
Depth data can be retrieved from public domain sources or from crowd sourced data.<br />
<br />
== GEBCO ==<br />
DIe Daten sind gerendert und stehen als Layer zur Verfügung:<br />
{| class="wikitable"<br />
! Zoom || Inhalt<br />
|-<br />
| 0..10 || Blaustufen und Schattierung<br />
|-<br />
| 11..18 || beschriftete Tiefenlinien, Blaustufen und Schattierung<br />
|}<br />
<br />
Noch zu lösende Probleme:<br />
* der GEBCO-Layer erzeugt einen milchigen Schleier über der Basiskarte<br />
* Tiefenlinien sind ab z=14 etwas grob (also ab da, wo dann die Flachwassertiefen beginnen) [http://map.openseamap.org/?zoom=14&lat=36.03097&lon=-5.49153&layers=BFTFTTTFFFF0 Karte]<br />
* Überschneidungen von 100m-Linie und Küstenlinie [http://map.openseamap.org/?zoom=15&lat=36.00318&lon=-5.60819&layers=BFFFTTTFFFF0FFFFF Karte]<br />
* Steilküsten (Cuba) [http://map.openseamap.org/?zoom=14&lat=19.94808&lon=-76.04289&layers=BFTFTTTFFFF0 Karte]<br />
<br />
== Crowd Sourced Data ==<br />
Crowd sourced data may be gathered by YOU. There are two options in development. A hardware and a software option.<br />
<br />
=== Workflow ===<br />
[[Datei:Workflow_depth.png]]<br />
<br />
Here you can find the document with the previous thoughts about the workflow:<br />
[http://osm.franken.de/wiki/FWT-Projekt%C3%BCbersicht-NMEA2Contours_2.1.ppt PPT Dokument]<br />
<br />
=== Hardware logger ===<br />
We are currently developing a hardware logger that may easily be plugged to the ship's network in order to log the networks data to a SD card.<br />
That data may then be uploaded by plugging the SD card to a normal computer with internet connection for upload.<br />
The main goal is to support NMEA 0183 data with options for NMEA 2000.<br />
<br />
=== Software logger ===<br />
A [[Software logger]] is in development and [http://seesea.sourceforge.net/datalogger/index.html can be downloaded here]. <br />
<br />
It currently supports: <br />
: Bluetooth <br />
: Serial ports<br />
: Internet Protocol (IP)<br />
It processes NMEA 0183 and AIS data.<br />
<br />
For vendor specific protocols such as SeaTalk 1 you have to use a [[De:NMEA-Logger_anschliessen|converter]] to NMEA 0183 data.<br />
<br />
NMEA 2000 support is only available if data is transcoded to NMEA 0183 by a converter.<br />
<br />
=== Chart Plotters ===<br />
<br />
Some chart plotters are able to save tracks out-of-the-box, e.g. several Raymarine (FSH files) and Humminbird (SON files) devices. Those files may directly be used as data source.<br />
<br />
<br />
=== Upload Process ===<br />
Uploading data is possible through using the [http://seesea.sourceforge.net/datalogger/index.html OpenSeaMap Data Logger Software] or via [http://depth.openseamap.org/ Web Interface].<br />
The system is currently being tested. <br />
<br />
[[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|You'll find further information here]].<br />
<br />
=== Test Data ===<br />
<br />
<br />
==== Brombachsee (Germany)====<br />
<br />
Test data for Openseamap: [http://osm.franken.de/wiki/test_data_brombachsee.zip Brombachsee_Test_Data]<br />
<br />
dgm_brombachsee.tif: Digital Elevation Model of the sea derived from height lines WWA (C).<br />
<br />
shapes_brombachsee.shp: Shape File derived from 4 NMEA Tracks. "dbs" is the original Sounding and "deep_cor" the depth after a correction (gauge levl).<br />
<br />
gpx_brombachsee.gpx: ele = "dbs" from the Shape File<br />
<br />
[[Datei:Brombachsee.png]]<br />
Resulting Digital Elevation Model<br />
<br />
==== Baltic Sea - near Großenbrode (Germany)====<br />
<br />
First results with an RMS error < 1,5 meter compared to an official dataset of the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].<br />
<br />
[[Datei: Bsh_results_overview.jpg]]<br />
<br />
[Picture 1] '''''OSM map in background, raster Depth Model derived from BSH data and crowed sourced OpenSeaMap Points - Overview'''''<br />
<br />
Blue = flat BSH data, red = deep BSH data.<br />
<br>Blue points = OpenSeaMap raw measuring points.<br />
<br />
{| class="wikitable"<br />
|-<br />
| n || 5062<br />
|-<br />
|-<br />
| datasets || 21<br />
|-<br />
| max deviation || 3,43 meters<br />
|-<br />
| mean (abs) || 0,69 meters<br />
|-<br />
| RMS +/- || 0,91 meters<br />
|}<br />
<br />
'''Vessel Metadata'''<br />
{| class="wikitable"<br />
|-<br />
| Manufacturer || Bavaria Yachtbau<br />
|-<br />
| Model || B32<br />
|-<br />
| Length || 10,0 meters<br />
|-<br />
| Beam || 3,35 meters<br />
|-<br />
| Draft || 1,6 meters<br />
|-<br />
| Height || 14 meters<br />
|-<br />
| Displacement || 4,2 t<br />
|-<br />
| Sensor manufacturer || Raymarine<br />
|-<br />
| Sensor Offset || 0,45 meters<br />
|}<br />
<br />
<br />
A digital Deep Model raster was computed from the BSH point dataset (c).<br />
The depth of the crowed sourced dataset was compared to the derived raster dataset from the BSH.<br />
The raw crowed sourced dataset was corrected by the sensor offset (0,45 meters).<br />
<br />
[[Datei: Scatter_cor_sensor.jpeg]]<br />
<br />
[Picture 2] '''''Scatter plot: BSH data on the x-axis and the crowed sourced data on the y-axis. Trend line in black and optimal line in red.'''''<br />
<br />
The deviation from the reference dataset increases with the depth measured.<br />
<br />
As you see in the picture below the difference between the datasets has an regular pattern maybe deepending on waves.<br />
<br />
[[Datei: Bsh_results_detail_10_classes.jpg]]<br />
<br />
[Picture 3] '''''Crowed sourced OpenSeaMap track points and the difference from the BSH dataset'''''<br />
<br />
White = low difference, orange = medium difference, red = strong difference<br />
<br />
Download of the data http://osm.franken.de/data/baltic_sea_test_data.zip<br />
'''Be aware of the copyright from the Bundesamt für Seeschifffahrt und Hydrographie (BSH) [http://www.bsh.de/].'''<br />
The data in the dataset is not corrected by sensor offset.<br />
<br />
= Data Preprocessing =<br />
<br />
== Data Condition ==<br />
Raw data is usually erronous and must be corrected<br />
<br />
=== Internal data problems ===<br />
Depth data may be affected by electrical conditions and software implementations<br />
* Data is incomplete and fail their checksum (bus errors from physical transmissions errors)<br />
* Data is retrived out of sequence<br />
* Data is erronous sensor data <br />
** Approximate correctable data i.e. invalid GPS position that may be interpolated<br />
** Uncorrectable data i.e. failed log sensor that shows slow speeds<br />
* Data resolution is low i.e. for energy saving purposes GPS position is updated every 10 seconds instead of every second<br />
* Sensor data is actively miscalibrated i.e. charter companies add additional draft to the sensor depth for safety reasons<br />
<br />
=== External data problems ===<br />
Depth data may be affected by different environmental circumstances <br />
*# The water temperature affects the ultrasound echo. An inhomogen water temperature yields unwanted echos<br />
*# The seabed affects the ultrasound echo<br />
*# The seastate affects the measurement. There even may be waves when there is no wind.<br />
*# Waves may affect the roll of the measuring vessel resulting in steep measurements that are invalid.<br />
*# The sounder sensor is not the position of the GPS antenna. A position offset including heading must be incorporated.<br />
*# The time of the measurement need not correlate with the time the position was received. This may even happen due to processing time of the hard or software.<br />
*# Corrections for tide induced water levels must happen<br />
<br />
Solutions probably are<br />
*# Water temperature may be measure from the sensor, other data may be unavailable<br />
*# Modern sidescan sonar may yield information about the seabed through classifications<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# A gyro and accelerometer may be used to remove the waves<br />
*# Position offsets must be provided by the user<br />
*# Time outages may be handled by the filter if precise timestamps are available in recorded data<br />
*# LAT to Mean sea level differences may be calculated from DTU10 worldwide, river gauges need to monitored<br />
<br />
[[Datei:LAT2MSLDiff.png]]<br />
<br />
<br />
== Data Condition Examples / Showcases ==<br />
<br />
=== Missing measurments (Position) ===<br />
Distribution for position updates taken from an example dataset. Left column shows the time between two consecutive measurements, right column shows how many measurements had this time update.<br />
One can see from the distribtion that the sensor is updated every second but many measurements are one or more seconds late.<br />
21 seconds with no position update may result in an instability of the subsequent filter.<br />
<pre><br />
MeasuredPosition3D<br />
GP<br />
0 :4285<br />
1000 :11295<br />
2000 :5056<br />
3000 :2134<br />
4000 :1135<br />
5000 :315<br />
6000 :154<br />
7000 :46<br />
8000 :36<br />
9000 :16<br />
10000 :12<br />
11000 :3<br />
12000 :4<br />
13000 :1<br />
14000 :7<br />
15000 :3<br />
16000 :1<br />
21000 :1<br />
</pre><br />
<br />
=== Missing measurments (Position) with erronous clock ===<br />
This example is at a 10 second position update rate. However the measurment time is faulty causing large negative and positive update rates. The clock jumps by +- one year/month/day/hour. One can further see from the many 0 time measurements that the rate at which data is sent to the nmea bus is higher than the actual position update (data is sent every second, a position update is every 10 seconds)<br />
<pre><br />
MeasuredPosition3D<br />
II<br />
-21340000 :1<br />
-13194000 :1<br />
-7998000 :1<br />
-2674000 :1<br />
-2434000 :1<br />
-2402000 :1<br />
-2030000 :1<br />
-1926000 :1<br />
-1894000 :1<br />
-1806000 :1<br />
-1480000 :1<br />
-1430000 :1<br />
-1382000 :1<br />
-1114000 :1<br />
-814000 :1<br />
-634000 :1<br />
-590000 :1<br />
-546000 :1<br />
-470000 :1<br />
-290000 :1<br />
-230000 :1<br />
-198000 :1<br />
-110000 :1<br />
-94000 :2<br />
0 :182200<br />
5000 :1<br />
10000 :20230<br />
15000 :1<br />
20000 :84<br />
50000 :1<br />
114000 :2<br />
130000 :2<br />
218000 :1<br />
250000 :1<br />
310000 :1<br />
490000 :1<br />
566000 :1<br />
610000 :1<br />
654000 :1<br />
834000 :1<br />
1134000 :1<br />
1402000 :1<br />
1450000 :1</pre><br />
<br />
== Solution Proposal ==<br />
<br />
=== Outline ===<br />
The ship is influenced by the outlined environment which can be observed. Naturally what is observed is not the state of the<br />
ship as i.e. the position if taken from GPS is 95% less than 10m accurate. To improve quality an estimation of the true state yields better results if this noise taken into account properly.<br />
<br />
=== Details ===<br />
The ship moves according to physical laws. For the easist case imagine a ship with constant velocity and direction. For any point in time you can tell where the ship is with easy math. Considering the full blown setup a ships movement is affected by many parameters such as wind speed, water current, waves, tide, and many more. The ship moves also triaxial in a dynamic way in itself (roll, pitch, yaw). Heeling even changes the measurement position with respect to the depth position. In terms of a filter this is called a system model that describes how the state of the ship may change. Given such a state you can measure what your sensor readings are and compare that to where the system thinks you are.<br />
<br />
The [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter] is known to be the best linear estimator for such situations. Unfortunately the system model is not linear which is why the Extended Kalman Filter needs to be used in order to linearize the system at hand.<br />
<br />
Todo:<br />
* Construct ship system model with at least the position state and probably its course and speed or even more (depth)<br />
* Estimate the system variance (This is a hard one, proposals welcome)<br />
* Construct the measurement model according to the data available (GPS, Log)<br />
* Estimate the measurement noise according to specifc sensors (DPGS is more accurate than GPS)<br />
<br />
The estimation with the position and depth can be retrieved and stored in a database.<br />
<br />
Pitfalls:<br />
* If the system noise is badly chosen the estimation of the system state does not converge to the true state / measurement.<br />
* If the system is very detailed the system variance can be reduced. The required cpu time for processing increases<br />
<br />
Benefits:<br />
* Having the best estimation of the true position even if measurements are noisy<br />
* Easy and effective algorithmic processing<br />
<br />
== Analysis == <br />
<br />
=== Data Sets ===<br />
Currently two test data sets are available recorded during trips from Mallorca and the Baltic Sea.<br />
In terms of data quality the Mallorca data shows many challenges. <br />
* The minimum recommended sentences from NMEA showed up with false date and time readings while having correct (!!!) message checksums. <br />
* The log on the ship was defective and delivered no readings from time to time. <br />
* The same holds true for the water temperature.<br />
* The GPS positions relatively imprecise because some last decimal digits are missing in the recordings.<br />
* The GPS positions are updated every 10 seconds while other sensor readings update almost every second.<br />
* The GPS position are sometimes way off due to false readings<br />
<br />
The Baltic Sea data set is a little bit better<br />
* Only a single day is available<br />
* GPS positions are updated every second<br />
<br />
One problem with the data is that there is time available when sensor readings were recorded. This yields problems to the filter algorithm.<br />
<br />
<br />
=== Filter Algorithm ===<br />
At first the Extended Kalman Filter is being analyzed. Using an apache implementation with the available data the filter quickly throw an exception that<br />
a matrix is not invertible because of numeric instabilities. When removing this exception the filter seems to work but the removal and its effects have yet to be analyzed.<br />
Literature suggest that a fixed interval smoother may yield better results in case of offline data processing. As it is an extension to the existing kalman filter<br />
we may consider that for the future.<br />
<br />
One problem are the different update rates of the sensors. As GPS may deliver positions at 0.1Hz speed is updated at 1Hz. Literature suggests that<br />
the missing measurements shell be modelled as a random variable with the standard deviation of the sensor. It may even be possible to update covariance matrices only partially with the sensor readings received. Input for the best solution may be formulated on the developer mailing list.<br />
<br />
== Results == <br />
A prototype implementation is shown in the following screenshots. An Extended Kalman Filter is being used. It has the position<br />
and the current bearing and velocity as system state. The input is the measurement of these four observables. The system function is<br />
good old pythagoras. In a first implementation I tried to use orthodrome distances but the system function is not differentiable which is a requirement of the Extended Kalman Filter (due to acrtan2). For small distances pythagoras should be sufficiently accurate. <br />
The initial state is taken from the first measurement for convergence reasons.<br />
<br />
The following gallery shows the results. <br />
* You can see the bad position resolution and an outlier in the first screenshot.<br />
* The second shows the same data overlaid with the applied filter. The outlier is gone and the resolution has improved.<br />
* The third screenshot shows data from a different GPS sensor with more precision (not DGPS) versus the filtered data.<br />
<br />
This of course is just a preliminary test and many setups need to be considered to make it work for most datasets.<br />
<br />
<gallery><br />
UnfilteredNMEA.png | Unfiltered GPS data<br />
FilteredNMEAVsOriginal.png | Unfiltered GPS data and Filtered GPS data<br />
PreciseGPSvsFilter.png | Another precise GPS vs Filtered GPS data<br />
</gallery><br />
<br />
The overall process even gives an estimation of the current error which is a capability of the [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter].<br />
This way positional inaccuracies may be added to the overall depth measurement inaccuracy.<br />
<br />
== Quality rating ==<br />
<br />
Each record (time, positon, depth) should become a quality rating.<br />
<br />
=== Points ===<br />
<br />
Derived from the Fibonacci series.<br />
<br />
{| class="wikitable"<br />
! Point || Description<br />
|-<br />
| 1 || extra small improvement<br />
|-<br />
| 2 || small improvement<br />
|-<br />
| 3 || medium improvement<br />
|-<br />
| 5 || large improvement<br />
|-<br />
| 8 || extra large improvement<br />
|}<br />
<br />
=== Factors ===<br />
<br />
{| class="wikitable"<br />
! style="width:15%" | Name<br />
! style="width:17%" | Factor<br />
! style="width:68%" | Description<br />
|-<br />
| depth offset || 8 (extra large) || The difference between the depth measured by the echo sounder and the depth (waterline) measured by hand.<br />
|-<br />
| device distance || 3 (medium) || The distance between gps antenna and echo sounder (lengthwise and crosswise).<br />
|-<br />
| SBAS || 3 (medium) || Satellite based augmentation system (WAAS, EGNOS, MSAS) which allows to correct the gps position.<br />
|-<br />
| position interpolation || 2 (small improvement) || Arrival of depth and position packets can have a time difference. It is/should be possible to interpolate the position.<br />
|}<br />
<br />
= Depth Rendering =<br />
<br />
= Siehe auch =<br />
* [[De:Bordnetz|Bordnetz]]<br />
* [[De:NMEA-Logger_anschliessen|NMEA-Logger_anschliessen]]<br />
* [http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCkQFjAA&url=http%3A%2F%2Fwww.dei.unipd.it%2F~chiuso%2FDOWNLOAD%2FPositioning_Heading_Kalman.pdf&ei=sSWNUMWnL4eC4gTRlYHAAw&usg=AFQjCNHq5V-PePNmDTZaGYvq0JeQFgqHVw Kalman Filtering for Positioning and Heading Control of Ships and Offshore Rigs]<br />
* [http://users.isr.ist.utl.pt/~pedro/publications/CAMS10.pdf A Multiple Model Adaptive Wave Filter for Dynamic Ship Positioning]<br />
* [http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4449205&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4449205 Echosounder Depth Tracking with the Extended Kalman Filter]</div>MartinOverhttps://wiki.openseamap.org/index.php?title=Datei:Scatter_cor_sensor.jpeg&diff=2948Datei:Scatter cor sensor.jpeg2014-09-26T19:02:25Z<p>MartinOver: MartinOver lud eine neue Version von „Datei:Scatter cor sensor.jpeg“ hoch</p>
<hr />
<div></div>MartinOver