OpenSeaMap-dev - Benutzerbeiträge [de]

Main Page

2015-05-06T09:51:43Z

Cleanerx:

{|border="0" cellpadding="6" cellspacing="0" width="100%"
!style="background:#E3E3E3;" | [[De:Hauptseite|Deutsch]]
!style="background:#E3E3E3;" | English
!style="background:#E3E3E3; width:100%;" |
|}



[[Image:MapFullscreen.png|400px|right]]
'''[http://www.OpenSeaMap.org OpenSeaMap]''' is a worldwide open source project for creation of a '''free nautical chart'''.

== History and fundamentals ==
OpenSeaMap was created in 2009 in response to a great need for freely-accessible seafaring maps. OpenSeaMap's goal is to add nautical and tourism information that would interest sailors OSM, and to present it in a pleasing way. This includes beacons, buoys and other seamarks, port information, repair shops, ship supplies and much more, but also shops, restaurants and places of interest. OpenSeaMap is part of [http://www.openstreetmap.org OpenStreetMap] and uses its database.

OpenSeaMap is an open Sea Map, and also open for future developments. The basemap is rendered using the OpenStreetMap-data. This map is extended with nautical data that is saved in the OSM-Database as well. OpenLayers is used to overlay additional nautical Information, which can be displayed in a popup by clicking on the map.

== Contact ==
: [http://forum.openseamap.org Forum] {{English}} {{Deutsch}} - all about OpenSeaMap
: [https://lists.sourceforge.net/lists/listinfo/openseamap-develop OpenSeaMap-develop] {{English}} - Mailing-list for developers [http://sourceforge.net/mailarchive/forum.php?forum_name=openseamap-develop Archive]

== Usage ==
=== Online Charts ===
The main chart can be found [http://map.openseamap.org here]

==== Nautical Information ====
The main web page supports rendering of seamarks and nautical information. There is a wide variety of supported features.
We are working on support for depth contours.

==== Weather ====
We provide up to date global [http://map.openseamap.org/weather.php weather] forecasts through data provided by NOAA.

==== Trip Planner ====
You can measure distances at sea and plan your trip. You may even export your points to be used offline.

==== Automatic Identification System (AIS)====
We have up to date AIS data available so you can follow vessels on the online map.

=== Offline Digital Charts ===

==== Windows ====
You can use OpenSeaMap with the following applications on Windows
* [http://seesea.sourceforge.net/datalogger/index.html OpenSeaMap Data Logger]
* [http://opencpn.org/ocpn/ OpenCPN]

==== Android ====
[[En:OruxMaps OruxMaps]]

==== iOS ====
An external provider contributed an iOS Application
[https://itunes.apple.com/de/app/openseamap/id495210783 OpenSeaMap iOS App]

==== Other ====

==== Plotters ====

===== Garmin =====
[http://wiki.openstreetmap.org/wiki/OpenSeaMap_and_Garmin_nautical_chart_plotter]

===== Lowrance =====

===== Raymarine =====

=== Paper Charts ===
SMRender is a capable of producing paper charts as PDF. We do not provide a regular rendering of certain sea areas right now.
Feel free to get this job done and mail to [mailto:openseamap-devel@openseamap.org OpenSeaMap Development].

== User Contributions ==
=== Chart Features Editing ===
You can edit the chart features through [[JOSM_and_Plugin|JOSM]]. There is a SeaMark Editor Plugin available to make the editing more comfortable.
=== Contribute Water Depth Recordings ===

== Developer Contributions ==
[[OpenSeaMap-dev:Portal|Developer area]]

==Data model==
The data scheme applies to the international norm [http://www.iho.int/iho_pubs/standard/S-57Ed3.1/31Main.pdf IHO-S-57], as published by the IHO. This allows a simple exchange of data with other ECDIS-Applications. Because of the complexity of attributing seamarks, there will be (unlike the usual OSM procedure) a strict separation between database as backend and the frontend, to allow users to input data without knowing S-57. A graphical user interface will be provided in the form of three editors.
The depth data is stored in a separate database and is using PostGIS

== Languages ==
OpenSeaMap is multilingual.

The Website is available in [http://www.openseamap.org/index.php?page=start&lang=de German], [http://www.openseamap.org/index.php?page=start&lang=en English], [http://www.openseamap.org/index.php?page=start&lang=fr French], [http://www.openseamap.org/index.php?page=start&lang=it Italian], [http://www.openseamap.org/index.php?page=start&lang=es Spanish] and [http://www.openseamap.org/index.php?page=start&lang=ru Russian].

This Wiki and the Online-Editor is currently only available in [[de:Hauptseite|German]] and [[Hauptseite|English]].

If you're interested in translating something to your language please contact us.

[[Kategorie:Promotion]]

Main Page

2015-05-05T19:48:28Z

Cleanerx:

{|border="0" cellpadding="6" cellspacing="0" width="100%"
!style="background:#E3E3E3;" | [[De:Hauptseite|Deutsch]]
!style="background:#E3E3E3;" | English
!style="background:#E3E3E3; width:100%;" |
|}



[[Image:MapFullscreen.png|400px|right]]
'''[http://www.OpenSeaMap.org OpenSeaMap]''' is a worldwide open source project for creation of a '''free nautical chart'''.

== History and fundamentals ==
OpenSeaMap was created in 2009 in response to a great need for freely-accessible seafaring maps. OpenSeaMap's goal is to add nautical and tourism information that would interest sailors OSM, and to present it in a pleasing way. This includes beacons, buoys and other seamarks, port information, repair shops, ship supplies and much more, but also shops, restaurants and places of interest. OpenSeaMap is part of [http://www.openstreetmap.org OpenStreetMap] and uses its database.

OpenSeaMap is an open Sea Map, and also open for future developments. The basemap is rendered using the OpenStreetMap-data. This map is extended with nautical data that is saved in the OSM-Database as well. OpenLayers is used to overlay additional nautical Information, which can be displayed in a popup by clicking on the map.

== Contact ==
: [http://forum.openseamap.org Forum] {{English}} {{Deutsch}} - all about OpenSeaMap
: [https://lists.sourceforge.net/lists/listinfo/openseamap-develop OpenSeaMap-develop] {{English}} - Mailing-list for developers [http://sourceforge.net/mailarchive/forum.php?forum_name=openseamap-develop Archive]

== Usage ==
=== Online Charts ===
[[http://map.openseamap.org OpenSeaMap]]
==== Nautical Information ====
The main web page supports rendering of seamarks and nautical information. There is a wide variety of supported features.
We are working on support for depth contours.

==== Weather ====
We provide up to date global [http://map.openseamap.org/weather.php weather] forecasts through data provided by NOAA.

==== Trip Planner ====
You can measure distances at sea and plan your trip. You may even export your points to be used offline.

==== Automatic Identification System (AIS)====
We have up to date AIS data available so you can follow vessels on the online map.

=== Offline Digital Charts ===

==== Windows ====
You can use OpenSeaMap with the following applications on Windows
* [http://seesea.sourceforge.net/datalogger/index.html OpenSeaMap Data Logger]
* [http://opencpn.org/ocpn/ OpenCPN]

==== Android ====
[[En:OruxMaps OruxMaps]]

==== iOS ====
[https://itunes.apple.com/de/app/openseamap/id495210783 OpenSeaMap iOS App]

==== Other ====

=== Paper Charts ===
SMRender is a capable of producing paper charts as PDF. We do not provide a regular rendering of certain sea areas right now.
Feel free to get this job done and mail to [mailto:openseamap-devel@openseamap.org OpenSeaMap Development].

== User Contributions ==
=== Chart Features Editing ===
You can edit the chart features through [[JOSM_and_Plugin|JOSM]]. There is a SeaMark Editor Plugin available to make the editing more comfortable.
=== Contribute Water Depth Recordings ===

== Developer Contributions ==
[[OpenSeaMap-dev:Portal|Developer area]]

==Data model==
The data scheme applies to the international norm [http://www.iho.int/iho_pubs/standard/S-57Ed3.1/31Main.pdf IHO-S-57], as published by the IHO. This allows a simple exchange of data with other ECDIS-Applications. Because of the complexity of attributing seamarks, there will be (unlike the usual OSM procedure) a strict separation between database as backend and the frontend, to allow users to input data without knowing S-57. A graphical user interface will be provided in the form of three editors.
The depth data is stored in a separate database and is using PostGIS

== Languages ==
OpenSeaMap is multilingual.

The Website is available in [http://www.openseamap.org/index.php?page=start&lang=de German], [http://www.openseamap.org/index.php?page=start&lang=en English], [http://www.openseamap.org/index.php?page=start&lang=fr French], [http://www.openseamap.org/index.php?page=start&lang=it Italian], [http://www.openseamap.org/index.php?page=start&lang=es Spanish] and [http://www.openseamap.org/index.php?page=start&lang=ru Russian].

This Wiki and the Online-Editor is currently only available in [[de:Hauptseite|German]] and [[Hauptseite|English]].

If you're interested in translating something to your language please contact us.

[[Kategorie:Promotion]]

Main Page

2015-05-05T19:31:47Z

Cleanerx:

{|border="0" cellpadding="6" cellspacing="0" width="100%"
!style="background:#E3E3E3;" | [[De:Hauptseite|Deutsch]]
!style="background:#E3E3E3;" | English
!style="background:#E3E3E3; width:100%;" |
|}



[[Image:MapFullscreen.png|400px|right]]
'''[http://www.OpenSeaMap.org OpenSeaMap]''' is a worldwide open source project for creation of a '''free nautical chart'''.

== History and fundamentals ==
OpenSeaMap was created in 2009 in response to a great need for freely-accessible seafaring maps. OpenSeaMap's goal is to add nautical and tourism information that would interest sailors OSM, and to present it in a pleasing way. This includes beacons, buoys and other seamarks, port information, repair shops, ship supplies and much more, but also shops, restaurants and places of interest. OpenSeaMap is part of [http://www.openstreetmap.org OpenStreetMap] and uses its database.

OpenSeaMap is an open Sea Map, and also open for future developments. The basemap is rendered using the OpenStreetMap-data. This map is extended with nautical data that is saved in the OSM-Database as well. OpenLayers is used to overlay additional nautical Information, which can be displayed in a popup by clicking on the map.

== Contact ==
: [http://forum.openseamap.org Forum] {{English}} {{Deutsch}} - all about OpenSeaMap
: [https://lists.sourceforge.net/lists/listinfo/openseamap-develop OpenSeaMap-develop] {{English}} - Mailing-list for developers [http://sourceforge.net/mailarchive/forum.php?forum_name=openseamap-develop Archive]

== Usage ==
=== Online Charts ===
[[http://map.openseamap.org OpenSeaMap]]
==== Nautical Information ====
The main web page supports rendering of seamarks and nautical information. There is a wide variety of supported features.
We are working on support for depth contours.
==== Weather ====
We provide up to date global weather information through data provided by NOAA.

==== Trip Planner ====

==== Automatic Identification System (AIS)====

=== Offline Digital Charts ===

==== Windows ====
[[En:OpenSeaMap Data Logger]]
[[En:OpenCPN]]

==== Android ====
[[En:OruxMaps OruxMaps]]

==== iOS ====
[https://itunes.apple.com/de/app/openseamap/id495210783 OpenSeaMap iOS App]

==== Other ====

=== Paper Charts ===
SMRender is a capable of producing paper charts as PDF. We do not provide a regular rendering of certain sea areas right now.
Feel free to get this job done and mail to [mailto:openseamap-devel@openseamap.org OpenSeaMap Development].

== User Contributions ==
=== Chart Features Editing ===
You can edit the chart features through [[JOSM_and_Plugin|JOSM]]. There is a SeaMark Editor Plugin available to make the editing more comfortable.
=== Contribute Water Depth Recordings ===

== Developer Contributions ==
[[OpenSeaMap-dev:Portal|Developer area]]

==Data model==
The data scheme applies to the international norm [http://www.iho.int/iho_pubs/standard/S-57Ed3.1/31Main.pdf IHO-S-57], as published by the IHO. This allows a simple exchange of data with other ECDIS-Applications. Because of the complexity of attributing seamarks, there will be (unlike the usual OSM procedure) a strict separation between database as backend and the frontend, to allow users to input data without knowing S-57. A graphical user interface will be provided in the form of three editors.
The depth data is stored in a separate database and is using PostGIS

== Languages ==
OpenSeaMap is multilingual.

The Website is available in [http://www.openseamap.org/index.php?page=start&lang=de German], [http://www.openseamap.org/index.php?page=start&lang=en English], [http://www.openseamap.org/index.php?page=start&lang=fr French], [http://www.openseamap.org/index.php?page=start&lang=it Italian], [http://www.openseamap.org/index.php?page=start&lang=es Spanish] and [http://www.openseamap.org/index.php?page=start&lang=ru Russian].

This Wiki and the Online-Editor is currently only available in [[de:Hauptseite|German]] and [[Hauptseite|English]].

If you're interested in translating something to your language please contact us.

[[Kategorie:Promotion]]

Main Page

2015-05-05T13:15:33Z

Cleanerx: /* Offline Digital Charts */

{|border="0" cellpadding="6" cellspacing="0" width="100%"
!style="background:#E3E3E3;" | [[De:Hauptseite|Deutsch]]
!style="background:#E3E3E3;" | English
!style="background:#E3E3E3; width:100%;" |
|}



[[Image:MapFullscreen.png|400px|right]]
'''[http://www.OpenSeaMap.org OpenSeaMap]''' is a worldwide open source project for creation of a '''free nautical chart'''.

== History and fundamentals ==
OpenSeaMap was created in 2009 in response to a great need for freely-accessible seafaring maps. OpenSeaMap's goal is to add nautical and tourism information that would interest sailors OSM, and to present it in a pleasing way. This includes beacons, buoys and other seamarks, port information, repair shops, ship supplies and much more, but also shops, restaurants and places of interest. OpenSeaMap is part of [http://www.openstreetmap.org OpenStreetMap] and uses its database.

OpenSeaMap is an open Sea Map, and also open for future developments. The basemap is rendered using the OpenStreetMap-data. This map is extended with nautical data that is saved in the OSM-Database as well. OpenLayers is used to overlay additional nautical Information, which can be displayed in a popup by clicking on the map.

== Contact ==
: [http://forum.openseamap.org Forum] {{English}} {{Deutsch}} - all about OpenSeaMap
: [https://lists.sourceforge.net/lists/listinfo/openseamap-develop OpenSeaMap-develop] {{English}} - Mailing-list for developers [http://sourceforge.net/mailarchive/forum.php?forum_name=openseamap-develop Archive]

== Usage ==
=== Online Charts ===
[[http://map.openseamap.org OpenSeaMap]]
==== Nautical Information ====
The main web page supports rendering of seamarks and nautical information. There is a wide variety of supported features.
We are working on support for depth contours.
==== Automatic Identification System (AIS)====

==== Weather ====

==== Trip Planner ====

=== Offline Digital Charts ===

==== Windows ====
[[En:OpenSeaMap Data Logger]]
[[En:OpenCPN]]

==== Android ====
[[En:OruxMaps OruxMaps]]

==== iOS ====
[https://itunes.apple.com/de/app/openseamap/id495210783 OpenSeaMap iOS App]

==== Other ====

=== Paper Charts ===
SMRender is a capable of producing paper charts as PDF. We do not provide a regular rendering of certain sea areas right now.
Feel free to get this job done and mail to [mailto:openseamap-devel@openseamap.org OpenSeaMap Development].

== User Contributions ==
=== Chart Features Editing ===
You can edit the chart features through [[JOSM_and_Plugin|JOSM]]. There is a SeaMark Editor Plugin available to make the editing more comfortable.
=== Contribute Water Depth Recordings ===

== Developer Contributions ==
[[OpenSeaMap-dev:Portal|Developer area]]

==Data model==
The data scheme applies to the international norm [http://www.iho.int/iho_pubs/standard/S-57Ed3.1/31Main.pdf IHO-S-57], as published by the IHO. This allows a simple exchange of data with other ECDIS-Applications. Because of the complexity of attributing seamarks, there will be (unlike the usual OSM procedure) a strict separation between database as backend and the frontend, to allow users to input data without knowing S-57. A graphical user interface will be provided in the form of three editors.
The depth data is stored in a separate database and is using PostGIS

== Languages ==
OpenSeaMap is multilingual.

The Website is available in [http://www.openseamap.org/index.php?page=start&lang=de German], [http://www.openseamap.org/index.php?page=start&lang=en English], [http://www.openseamap.org/index.php?page=start&lang=fr French], [http://www.openseamap.org/index.php?page=start&lang=it Italian], [http://www.openseamap.org/index.php?page=start&lang=es Spanish] and [http://www.openseamap.org/index.php?page=start&lang=ru Russian].

This Wiki and the Online-Editor is currently only available in [[de:Hauptseite|German]] and [[Hauptseite|English]].

If you're interested in translating something to your language please contact us.

[[Kategorie:Promotion]]

Main Page

2015-05-05T12:09:46Z

Cleanerx: /* Online Charts */

{|border="0" cellpadding="6" cellspacing="0" width="100%"
!style="background:#E3E3E3;" | [[De:Hauptseite|Deutsch]]
!style="background:#E3E3E3;" | English
!style="background:#E3E3E3; width:100%;" |
|}



[[Image:MapFullscreen.png|400px|right]]
'''[http://www.OpenSeaMap.org OpenSeaMap]''' is a worldwide open source project for creation of a '''free nautical chart'''.

== History and fundamentals ==
OpenSeaMap was created in 2009 in response to a great need for freely-accessible seafaring maps. OpenSeaMap's goal is to add nautical and tourism information that would interest sailors OSM, and to present it in a pleasing way. This includes beacons, buoys and other seamarks, port information, repair shops, ship supplies and much more, but also shops, restaurants and places of interest. OpenSeaMap is part of [http://www.openstreetmap.org OpenStreetMap] and uses its database.

OpenSeaMap is an open Sea Map, and also open for future developments. The basemap is rendered using the OpenStreetMap-data. This map is extended with nautical data that is saved in the OSM-Database as well. OpenLayers is used to overlay additional nautical Information, which can be displayed in a popup by clicking on the map.

== Contact ==
: [http://forum.openseamap.org Forum] {{English}} {{Deutsch}} - all about OpenSeaMap
: [https://lists.sourceforge.net/lists/listinfo/openseamap-develop OpenSeaMap-develop] {{English}} - Mailing-list for developers [http://sourceforge.net/mailarchive/forum.php?forum_name=openseamap-develop Archive]

== Usage ==
=== Online Charts ===
[[http://map.openseamap.org OpenSeaMap]]
==== Nautical Information ====
The main web page supports rendering of seamarks and nautical information. There is a wide variety of supported features.
We are working on support for depth contours.
==== Automatic Identification System (AIS)====

==== Weather ====

==== Trip Planner ====

=== Offline Digital Charts ===

=== Paper Charts ===
SMRender is a capable of producing paper charts as PDF. We do not provide a regular rendering of certain sea areas right now.
Feel free to get this job done and mail to [mailto:openseamap-devel@openseamap.org OpenSeaMap Development].

== User Contributions ==
=== Chart Features Editing ===
You can edit the chart features through [[JOSM_and_Plugin|JOSM]]. There is a SeaMark Editor Plugin available to make the editing more comfortable.
=== Contribute Water Depth Recordings ===

== Developer Contributions ==
[[OpenSeaMap-dev:Portal|Developer area]]

==Data model==
The data scheme applies to the international norm [http://www.iho.int/iho_pubs/standard/S-57Ed3.1/31Main.pdf IHO-S-57], as published by the IHO. This allows a simple exchange of data with other ECDIS-Applications. Because of the complexity of attributing seamarks, there will be (unlike the usual OSM procedure) a strict separation between database as backend and the frontend, to allow users to input data without knowing S-57. A graphical user interface will be provided in the form of three editors.
The depth data is stored in a separate database and is using PostGIS

== Languages ==
OpenSeaMap is multilingual.

The Website is available in [http://www.openseamap.org/index.php?page=start&lang=de German], [http://www.openseamap.org/index.php?page=start&lang=en English], [http://www.openseamap.org/index.php?page=start&lang=fr French], [http://www.openseamap.org/index.php?page=start&lang=it Italian], [http://www.openseamap.org/index.php?page=start&lang=es Spanish] and [http://www.openseamap.org/index.php?page=start&lang=ru Russian].

This Wiki and the Online-Editor is currently only available in [[de:Hauptseite|German]] and [[Hauptseite|English]].

If you're interested in translating something to your language please contact us.

[[Kategorie:Promotion]]

Main Page

2015-05-05T12:01:26Z

Cleanerx:

{|border="0" cellpadding="6" cellspacing="0" width="100%"
!style="background:#E3E3E3;" | [[De:Hauptseite|Deutsch]]
!style="background:#E3E3E3;" | English
!style="background:#E3E3E3; width:100%;" |
|}



[[Image:MapFullscreen.png|400px|right]]
'''[http://www.OpenSeaMap.org OpenSeaMap]''' is a worldwide open source project for creation of a '''free nautical chart'''.

== History and fundamentals ==
OpenSeaMap was created in 2009 in response to a great need for freely-accessible seafaring maps. OpenSeaMap's goal is to add nautical and tourism information that would interest sailors OSM, and to present it in a pleasing way. This includes beacons, buoys and other seamarks, port information, repair shops, ship supplies and much more, but also shops, restaurants and places of interest. OpenSeaMap is part of [http://www.openstreetmap.org OpenStreetMap] and uses its database.

OpenSeaMap is an open Sea Map, and also open for future developments. The basemap is rendered using the OpenStreetMap-data. This map is extended with nautical data that is saved in the OSM-Database as well. OpenLayers is used to overlay additional nautical Information, which can be displayed in a popup by clicking on the map.

== Contact ==
: [http://forum.openseamap.org Forum] {{English}} {{Deutsch}} - all about OpenSeaMap
: [https://lists.sourceforge.net/lists/listinfo/openseamap-develop OpenSeaMap-develop] {{English}} - Mailing-list for developers [http://sourceforge.net/mailarchive/forum.php?forum_name=openseamap-develop Archive]

== Usage ==
=== Online Charts ===
[[http://map.openseamap.org| OpenSeaMap]]
==== Nautical Information ====
The main web page supports rendering of seamarks and nautical information. There is a wide variety of supported features.
We are working on support for depth contours.
==== Automatic Identification System (AIS)====

==== Weather ====

==== Trip Planner ====

=== Offline Digital Charts ===

=== Paper Charts ===
SMRender is a capable of producing paper charts as PDF. We do not provide a regular rendering of certain sea areas right now.
Feel free to get this job done and mail to [mailto:openseamap-devel@openseamap.org OpenSeaMap Development].

== User Contributions ==
=== Chart Features Editing ===
You can edit the chart features through [[JOSM_and_Plugin|JOSM]]. There is a SeaMark Editor Plugin available to make the editing more comfortable.
=== Contribute Water Depth Recordings ===

== Developer Contributions ==
[[OpenSeaMap-dev:Portal|Developer area]]

==Data model==
The data scheme applies to the international norm [http://www.iho.int/iho_pubs/standard/S-57Ed3.1/31Main.pdf IHO-S-57], as published by the IHO. This allows a simple exchange of data with other ECDIS-Applications. Because of the complexity of attributing seamarks, there will be (unlike the usual OSM procedure) a strict separation between database as backend and the frontend, to allow users to input data without knowing S-57. A graphical user interface will be provided in the form of three editors.
The depth data is stored in a separate database and is using PostGIS

== Languages ==
OpenSeaMap is multilingual.

The Website is available in [http://www.openseamap.org/index.php?page=start&lang=de German], [http://www.openseamap.org/index.php?page=start&lang=en English], [http://www.openseamap.org/index.php?page=start&lang=fr French], [http://www.openseamap.org/index.php?page=start&lang=it Italian], [http://www.openseamap.org/index.php?page=start&lang=es Spanish] and [http://www.openseamap.org/index.php?page=start&lang=ru Russian].

This Wiki and the Online-Editor is currently only available in [[de:Hauptseite|German]] and [[Hauptseite|English]].

If you're interested in translating something to your language please contact us.

[[Kategorie:Promotion]]

Main Page

2015-05-05T11:44:09Z

Cleanerx:

{|border="0" cellpadding="6" cellspacing="0" width="100%"
!style="background:#E3E3E3;" | [[De:Hauptseite|Deutsch]]
!style="background:#E3E3E3;" | English
!style="background:#E3E3E3; width:100%;" |
|}



[[Image:MapFullscreen.png|400px|right]]
'''[http://www.OpenSeaMap.org OpenSeaMap]''' is a worldwide open source project for creation of a '''free nautical chart'''.

== History and fundamentals ==
OpenSeaMap was created in 2009 in response to a great need for freely-accessible seafaring maps. OpenSeaMap's goal is to add nautical and tourism information that would interest sailors OSM, and to present it in a pleasing way. This includes beacons, buoys and other seamarks, port information, repair shops, ship supplies and much more, but also shops, restaurants and places of interest. OpenSeaMap is part of [http://www.openstreetmap.org OpenStreetMap] and uses its database.

OpenSeaMap is an open Sea Map, and also open for future developments. The basemap is rendered using the OpenStreetMap-data. This map is extended with nautical data that is saved in the OSM-Database as well. OpenLayers is used to overlay additional nautical Information, which can be displayed in a popup by clicking on the map.

== Contact ==
: [http://forum.openseamap.org Forum] {{English}} {{Deutsch}} - all about OpenSeaMap
: [https://lists.sourceforge.net/lists/listinfo/openseamap-develop OpenSeaMap-develop] {{English}} - Mailing-list for developers [http://sourceforge.net/mailarchive/forum.php?forum_name=openseamap-develop Archive]

== This Wiki ==
: [[Main Page]]
:: [[Editor]]
::: [[Online-Editor]]
:::: [[Online-Editor/Window|Window]]
:::: [[Online-Editor/edit|Edit]]
:::: [[Online-Editor/Seamark|Seamark]]
:::: [[Online-Editor/Harbour|Harbour]]
::: [[JOSM_and_Plugin|JOSM and Plugin]]
:::: [[JOSM_and_Plugin/Window|Window]]
:::: [[JOSM_and_Plugin/edit|Edit]]
:::: [[JOSM_and_Plugin/Seamark|Seamark]]
:::: [[JOSM_and_Plugin/Harbour|Harbour]]
:: [[Tools]]
::: [[Trip planner]]
:: Water depth
::: [[NMEA-Daten_hochladen|Upload NMEA-data]]
::: [[NMEA-Logger_anschliessen|Connect NMEA-Logger]]
::: [[Software_logger|Software-Logger]]
::: [[Hardware_logger|Hardware-Logger]]
::: [[Bordnetz|Ship network]]

----
[[OpenSeaMap-dev:Portal|Developer area]]

==Data model==
The data scheme applies to the international norm [http://www.iho.int/iho_pubs/standard/S-57Ed3.1/31Main.pdf IHO-S-57], as published by the IHO. This allows a simple exchange of data with other ECDIS-Applications. Because of the complexity of attributing seamarks, there will be (unlike the usual OSM procedure) a strict separation between database as backend and the frontend, to allow users to input data without knowing S-57. A graphical user interface will be provided in the form of three editors.
The depth data is stored in a separate database and is using PostGIS

== Languages ==
OpenSeaMap is multilingual.

The Website is available in [http://www.openseamap.org/index.php?page=start&lang=de German], [http://www.openseamap.org/index.php?page=start&lang=en English], [http://www.openseamap.org/index.php?page=start&lang=fr French], [http://www.openseamap.org/index.php?page=start&lang=it Italian], [http://www.openseamap.org/index.php?page=start&lang=es Spanish] and [http://www.openseamap.org/index.php?page=start&lang=ru Russian].

This Wiki and the Online-Editor is currently only available in [[de:Hauptseite|German]] and [[Hauptseite|English]].

If you're interested in translating something to your language please contact us.

[[Kategorie:Promotion]]

Main Page

2015-05-05T11:41:41Z

Cleanerx:

{|border="0" cellpadding="6" cellspacing="0" width="100%"
!style="background:#E3E3E3;" | [[De:Hauptseite|Deutsch]]
!style="background:#E3E3E3;" | English
!style="background:#E3E3E3; width:100%;" |
|}



[[Image:MapFullscreen.png|400px|right]]
'''[http://www.OpenSeaMap.org OpenSeaMap]''' is a worldwide open source project for creation of a '''free nautical chart'''.

== History and fundamentals ==
OpenSeaMap was created in 2009 in response to a great need for freely-accessible seafaring maps. OpenSeaMap's goal is to add nautical and tourism information that would interest sailors OSM, and to present it in a pleasing way. This includes beacons, buoys and other seamarks, port information, repair shops, ship supplies and much more, but also shops, restaurants and places of interest. OpenSeaMap is part of [http://www.openstreetmap.org OpenStreetMap] and uses its database.

OpenSeaMap is an open Sea Map, and also open for future developments. The basemap is rendered using the OpenStreetMap-data. This map is extended with nautical data that is saved in the OSM-Database as well. OpenLayers is used to overlay additional nautical Information, which can be displayed in a popup by clicking on the map.

==Usage==
OpenSeaMap can be viewed online.

At the moment the areas [http://openseamap.org/map/?zoom=15&lat=54.18459&lon=12.08575&layers=B0T&lang=en "Warnemünde"] and [http://openseamap.org/map/?zoom=14&lat=54.3914&lon=10.19366&layers=B0T&lang=en Kieler Förde] are online & viewable.

In the future, you will be able to download the current map onto your laptop for your cruise.

We are still searching for a way to display water depth and a method of displaying the profile of the sea bed. We are also experimenting with AIS. Of course we will provide a list of ports and later also a port guide.

==Data model==
The data scheme applies to the international norm [http://www.iho.int/iho_pubs/standard/S-57Ed3.1/31Main.pdf IHO-S-57], as published by the IHO. This allows a simple exchange of data with other ECDIS-Applications. Because of the complexity of attributing seamarks, there will be (unlike the usual OSM procedure) a strict separation between database as backend and the frontend, to allow users to input data without knowing S-57. A graphical user interface will be provided in the form of three editors.

== Contact ==
: [http://forum.openseamap.org Forum] {{English}} {{Deutsch}} - all about OpenSeaMap
: [https://lists.sourceforge.net/lists/listinfo/openseamap-develop OpenSeaMap-develop] {{English}} - Mailing-list for developers [http://sourceforge.net/mailarchive/forum.php?forum_name=openseamap-develop Archive]

== This Wiki ==
: [[Main Page]]
:: [[Editor]]
::: [[Online-Editor]]
:::: [[Online-Editor/Window|Window]]
:::: [[Online-Editor/edit|Edit]]
:::: [[Online-Editor/Seamark|Seamark]]
:::: [[Online-Editor/Harbour|Harbour]]
::: [[JOSM_and_Plugin|JOSM and Plugin]]
:::: [[JOSM_and_Plugin/Window|Window]]
:::: [[JOSM_and_Plugin/edit|Edit]]
:::: [[JOSM_and_Plugin/Seamark|Seamark]]
:::: [[JOSM_and_Plugin/Harbour|Harbour]]
:: [[Tools]]
::: [[Trip planner]]
:: Water depth
::: [[NMEA-Daten_hochladen|Upload NMEA-data]]
::: [[NMEA-Logger_anschliessen|Connect NMEA-Logger]]
::: [[Software_logger|Software-Logger]]
::: [[Hardware_logger|Hardware-Logger]]
::: [[Bordnetz|Ship network]]

----
[[OpenSeaMap-dev:Portal|Developer area]]

== Languages ==
OpenSeaMap is multilingual.

The Website is available in [http://www.openseamap.org/index.php?page=start&lang=de German], [http://www.openseamap.org/index.php?page=start&lang=en English], [http://www.openseamap.org/index.php?page=start&lang=fr French], [http://www.openseamap.org/index.php?page=start&lang=it Italian], [http://www.openseamap.org/index.php?page=start&lang=es Spanish] and [http://www.openseamap.org/index.php?page=start&lang=ru Russian].

This Wiki and the Online-Editor is currently only available in [[de:Hauptseite|German]] and [[Hauptseite|English]].

If you're interested in translating something to your language please contact us.

[[Kategorie:Promotion]]

OpenSeaMap-dev:Entwicklerwochenende 2015-04/Bericht en

2015-05-05T10:54:47Z

Cleanerx: /* Social Media */

[[Category:Meetings]]

= Protocol =
The meeting took place in Nürnberg from 2015-04-24 - 2015-04-26

== Organisation ==
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.
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
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.
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.
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.

== Depth Processing ==
=== Postprocessing ===
We have the basic processing chain setup and evaluate the performance in real world data sets.
Inshore data renders fine but large offshore data has to be improved as some queries are a little bit slow.
When performance has been improved we need to focus on data quality. Key quality contributors are the ocean tide, gauges and manual data corrections.
Ocean tide calculation is already included and gauges will be the next step to be included.
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.
As the sources are not yet online it is quite difficoult to get the system up and running in his environment.
==== Format decoding ====
Herbert has written a tool that is capable detecting patterns in file formats to decode them.
He is currently working on AT5 which is a chart format by Lowrance. Since we have several unknown formats
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
=== Web Backend ===
Editing of errors and gauges need to be addressed. 
[http://depth.openseamap.org:8080/org.osm.depth.upload.stage/api2/| Backend API] 
[https://depth.openseamap.org:8443/org.osm.depth.upload.stage/api2/| Backend API Secure] 

=== Website ===
The manual corrections involves more work and Martin will make a proposal how to integrate the editing from the gis web viewpoint.
Axel is a new contributor to the web page and contributed some valuable fixes. 
[https://depth.openseamap.org| Depth Website] 
[https://github.com/OpenSeaMap/depth_webfrontend| Sources Webfrontend]

== Rendering ==
=== Paper Chart Rendering ===
[http://www.abenteuerland.at/smrender/| SMRender]
Bernhard is actively contributing to the paper based renderer and is capable of rendering various difficult scenarios.
However he - like so many others - eagerly awaits free depth contours from OpenSeaMap to become available.

=== Software Rendering ===
==== OSM Renderer ====
Malcolm is administrating the old renderer while working on the new one. The new renderer may be found at
http://svn.openstreetmap.org/applications/editors/josm/plugins/seachart/
Progress has been slow recently.
=== Application Rendering ===
==== OSMAnd ====
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
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]

==== OpenCPN ====
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
within the osm database. KAP is a raster format that is supported. >> What is the status of these KAP files ??? <<
==== Orux Maps & Locus ====
Based on MapsForge. Alexej is looking into how we can integrate into that portal . Is that correct ?

== Vector Charts ==
=== AT5 Generation ===
Someone ? is working on activating software that can generate at5 files. The process is very cpu time consuming
and we have a hardware provider and location at hand that can take over the generation process. Everything needs to be setup though.
=== Garmin ADM ===
As of January garmin charts stopped working due to a firmware update. Investigation is underway.
The chart updates are currenlty not being handled so they are very outdated. If someone likes to
reenable the process, raise your hand.
=== Raymarine ===
There are some ideas floating around but nothing else at the moment. Contact Markus Bärlöcher to get some details.
Raster Charts

== Raster Charts ==
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
ways to intelligently select necessary tiles and compressions.

== State of the Loggers ==
=== OpenSeaMap Data Logger ===
==== NMEA0183 Seatalk ====
Since there has been a bug on the firmware the produced loggers must be flashed with
a new firmware. The recently sold loggers all had the new firmware but we are running low on patched loggers
and we need to flash the unpatched loggers in stock. Andreas Merz and Wolfgang will contact Winfried Schäfer on the instructions
how to flash the logger to speed up the process.
==== NMEA 2000 ====
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
=== Plotters from vendors ===
There are some plotter models listed on
http://wiki.openstreetmap.org/wiki/AT5-OpenSeaMap-Chart_for_Lowrance_Simrad_B%26G
http://wiki.openstreetmap.org/wiki/Garmin#Sea-Chart-Plotter
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
=== Software Data Logger ===
Since the upload API change the current logger no longer supports uploading files directly
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.

== Social Media ==
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 to integrate that appearance.
Cornelia did some valuable work for our presence. Discussions are under way to improve rendering for mobile devices. The main web page needs some updates to the underlying typo3 system.
Wolfgang offered some help with the updates.

OpenSeaMap-dev:Entwicklerwochenende 2015-04/Bericht en

2015-05-05T09:53:20Z

Cleanerx: /* OSMAnd */

[[Category:Meetings]]

= Protocol =
The meeting took place in Nürnberg from 2015-04-24 - 2015-04-26

== Organisation ==
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.
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
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.
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.
After some discussion and weighing out the pros and cons of such changes, Martin offered to draft a solution that will be communicated shortly - first for to attendees and then to the public.

== Depth Processing ==
=== Postprocessing ===
We have the basic processing chain setup and evaluate the performance in real world data sets.
Inshore data renders fine but large offshore data has to be improved as some queries are a little bit slow.
When performance has been improved we need to focus on data quality. Key quality contributors are the ocean tide, gauges and manual data corrections.
Ocean tide calculation is already included and gauges will be the next step to be included.
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.
As the sources are not yet online it is quite difficoult to get the system up and running in his environment.
==== Format decoding ====
Herbert has written a tool that is capable detecting patterns in file formats to decode them.
He is currently working on AT5 which is a chart format by Lowrance. Since we have several unknown formats
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
=== Web Backend ===
Editing of errors and gauges need to be addressed. 
[http://depth.openseamap.org:8080/org.osm.depth.upload.stage/api2/| Backend API] 
[https://depth.openseamap.org:8443/org.osm.depth.upload.stage/api2/| Backend API Secure] 

=== Website ===
The manual corrections involves more work and Martin will make a proposal how to integrate the editing from the gis web viewpoint.
Axel is a new contributor to the web page and contributed some valuable fixes. 
[https://depth.openseamap.org| Depth Website] 
[https://github.com/OpenSeaMap/depth_webfrontend| Sources Webfrontend]

== Rendering ==
=== Paper Chart Rendering ===
[http://www.abenteuerland.at/smrender/| SMRender]
Bernhard is actively contributing to the paper based renderer and is capable of rendering various difficult scenarios.
However he - like so many others - eagerly awaits free depth contours from OpenSeaMap to become available.

=== Software Rendering ===
==== OSM Renderer ====
Malcolm is administrating the old renderer while working on the new one. The new renderer may be found at
http://svn.openstreetmap.org/applications/editors/josm/plugins/seachart/
Progress has been slow recently.
=== Application Rendering ===
==== OSMAnd ====
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
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]

==== OpenCPN ====
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
within the osm database. KAP is a raster format that is supported. >> What is the status of these KAP files ??? <<
==== Orux Maps & Locus ====
Based on MapsForge. Alexej is looking into how we can integrate into that portal . Is that correct ?

== Vector Charts ==
=== AT5 Generation ===
Someone ? is working on activating software that can generate at5 files. The process is very cpu time consuming
and we have a hardware provider and location at hand that can take over the generation process. Everything needs to be setup though.
=== Garmin ADM ===
As of January garmin charts stopped working due to a firmware update. Investigation is underway.
The chart updates are currenlty not being handled so they are very outdated. If someone likes to
reenable the process, raise your hand.
=== Raymarine ===
There are some ideas floating around but nothing else at the moment. Contact Markus Bärlöcher to get some details.
Raster Charts

== Raster Charts ==
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
ways to intelligently select necessary tiles and compressions.

== State of the Loggers ==
=== OpenSeaMap Data Logger ===
==== NMEA0183 Seatalk ====
Since there has been a bug on the firmware the produced loggers must be flashed with
a new firmware. The recently sold loggers all had the new firmware but we are running low on patched loggers
and we need to flash the unpatched loggers in stock. Andreas Merz and Wolfgang will contact Winfried Schäfer on the instructions
how to flash the logger to speed up the process.
==== NMEA 2000 ====
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
=== Plotters from vendors ===
There are some plotter models listed on
http://wiki.openstreetmap.org/wiki/AT5-OpenSeaMap-Chart_for_Lowrance_Simrad_B%26G
http://wiki.openstreetmap.org/wiki/Garmin#Sea-Chart-Plotter
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
=== Software Data Logger ===
Since the upload API change the current logger no longer supports uploading files directly
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.

== Social Media ==
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.
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.
Wolfgang offered some help with the updates.

Kategorie:Meetings

2015-05-05T09:48:41Z

Cleanerx: Die Seite wurde neu angelegt: „This is a list of the meetings help by the OpenSeaMap participants“

This is a list of the meetings help by the OpenSeaMap participants

OpenSeaMap-dev:Entwicklerwochenende 2015-04/Bericht en

2015-05-05T09:47:46Z

Cleanerx:

[[Category:Meetings]]

= Protocol =
The meeting took place in Nürnberg from 2015-04-24 - 2015-04-26

== Organisation ==
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.
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
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.
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.
After some discussion and weighing out the pros and cons of such changes, Martin offered to draft a solution that will be communicated shortly - first for to attendees and then to the public.

== Depth Processing ==
=== Postprocessing ===
We have the basic processing chain setup and evaluate the performance in real world data sets.
Inshore data renders fine but large offshore data has to be improved as some queries are a little bit slow.
When performance has been improved we need to focus on data quality. Key quality contributors are the ocean tide, gauges and manual data corrections.
Ocean tide calculation is already included and gauges will be the next step to be included.
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.
As the sources are not yet online it is quite difficoult to get the system up and running in his environment.
==== Format decoding ====
Herbert has written a tool that is capable detecting patterns in file formats to decode them.
He is currently working on AT5 which is a chart format by Lowrance. Since we have several unknown formats
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
=== Web Backend ===
Editing of errors and gauges need to be addressed. 
[http://depth.openseamap.org:8080/org.osm.depth.upload.stage/api2/| Backend API] 
[https://depth.openseamap.org:8443/org.osm.depth.upload.stage/api2/| Backend API Secure] 

=== Website ===
The manual corrections involves more work and Martin will make a proposal how to integrate the editing from the gis web viewpoint.
Axel is a new contributor to the web page and contributed some valuable fixes. 
[https://depth.openseamap.org| Depth Website] 
[https://github.com/OpenSeaMap/depth_webfrontend| Sources Webfrontend]

== Rendering ==
=== Paper Chart Rendering ===
[http://www.abenteuerland.at/smrender/| SMRender]
Bernhard is actively contributing to the paper based renderer and is capable of rendering various difficult scenarios.
However he - like so many others - eagerly awaits free depth contours from OpenSeaMap to become available.

=== Software Rendering ===
==== OSM Renderer ====
Malcolm is administrating the old renderer while working on the new one. The new renderer may be found at
http://svn.openstreetmap.org/applications/editors/josm/plugins/seachart/
Progress has been slow recently.
=== Application Rendering ===
==== OSMAnd ====
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
to contributions that are capable of rendering seamarks and other sea items. Interested parties are welcome to show themselves to openseamap-devel@openseamap.org
==== OpenCPN ====
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
within the osm database. KAP is a raster format that is supported. >> What is the status of these KAP files ??? <<
==== Orux Maps & Locus ====
Based on MapsForge. Alexej is looking into how we can integrate into that portal . Is that correct ?

== Vector Charts ==
=== AT5 Generation ===
Someone ? is working on activating software that can generate at5 files. The process is very cpu time consuming
and we have a hardware provider and location at hand that can take over the generation process. Everything needs to be setup though.
=== Garmin ADM ===
As of January garmin charts stopped working due to a firmware update. Investigation is underway.
The chart updates are currenlty not being handled so they are very outdated. If someone likes to
reenable the process, raise your hand.
=== Raymarine ===
There are some ideas floating around but nothing else at the moment. Contact Markus Bärlöcher to get some details.
Raster Charts

== Raster Charts ==
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
ways to intelligently select necessary tiles and compressions.

== State of the Loggers ==
=== OpenSeaMap Data Logger ===
==== NMEA0183 Seatalk ====
Since there has been a bug on the firmware the produced loggers must be flashed with
a new firmware. The recently sold loggers all had the new firmware but we are running low on patched loggers
and we need to flash the unpatched loggers in stock. Andreas Merz and Wolfgang will contact Winfried Schäfer on the instructions
how to flash the logger to speed up the process.
==== NMEA 2000 ====
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
=== Plotters from vendors ===
There are some plotter models listed on
http://wiki.openstreetmap.org/wiki/AT5-OpenSeaMap-Chart_for_Lowrance_Simrad_B%26G
http://wiki.openstreetmap.org/wiki/Garmin#Sea-Chart-Plotter
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
=== Software Data Logger ===
Since the upload API change the current logger no longer supports uploading files directly
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.

== Social Media ==
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.
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.
Wolfgang offered some help with the updates.

OpenSeaMap-dev:Entwicklerwochenende 2015-04/Bericht en

2015-05-05T09:39:59Z

Cleanerx: /* Paper Chart Rendering */

= Protocol =
The meeting took place in Nürnberg from 2015-04-24 - 2015-04-26

== Organisation ==
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.
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
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.
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.
After some discussion and weighing out the pros and cons of such changes, Martin offered to draft a solution that will be communicated shortly - first for to attendees and then to the public.

== Depth Processing ==
=== Postprocessing ===
We have the basic processing chain setup and evaluate the performance in real world data sets.
Inshore data renders fine but large offshore data has to be improved as some queries are a little bit slow.
When performance has been improved we need to focus on data quality. Key quality contributors are the ocean tide, gauges and manual data corrections.
Ocean tide calculation is already included and gauges will be the next step to be included.
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.
As the sources are not yet online it is quite difficoult to get the system up and running in his environment.
==== Format decoding ====
Herbert has written a tool that is capable detecting patterns in file formats to decode them.
He is currently working on AT5 which is a chart format by Lowrance. Since we have several unknown formats
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
=== Web Backend ===
Editing of errors and gauges need to be addressed. 
[http://depth.openseamap.org:8080/org.osm.depth.upload.stage/api2/| Backend API] 
[https://depth.openseamap.org:8443/org.osm.depth.upload.stage/api2/| Backend API Secure] 

=== Website ===
The manual corrections involves more work and Martin will make a proposal how to integrate the editing from the gis web viewpoint.
Axel is a new contributor to the web page and contributed some valuable fixes. 
[https://depth.openseamap.org| Depth Website] 
[https://github.com/OpenSeaMap/depth_webfrontend| Sources Webfrontend]

== Rendering ==
=== Paper Chart Rendering ===
[http://www.abenteuerland.at/smrender/| SMRender]
Bernhard is actively contributing to the paper based renderer and is capable of rendering various difficult scenarios.
However he - like so many others - eagerly awaits free depth contours from OpenSeaMap to become available.

=== Software Rendering ===
==== OSM Renderer ====
Malcolm is administrating the old renderer while working on the new one. The new renderer may be found at
http://svn.openstreetmap.org/applications/editors/josm/plugins/seachart/
Progress has been slow recently.
=== Application Rendering ===
==== OSMAnd ====
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
to contributions that are capable of rendering seamarks and other sea items. Interested parties are welcome to show themselves to openseamap-devel@openseamap.org
==== OpenCPN ====
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
within the osm database. KAP is a raster format that is supported. >> What is the status of these KAP files ??? <<
==== Orux Maps & Locus ====
Based on MapsForge. Alexej is looking into how we can integrate into that portal . Is that correct ?

== Vector Charts ==
=== AT5 Generation ===
Someone ? is working on activating software that can generate at5 files. The process is very cpu time consuming
and we have a hardware provider and location at hand that can take over the generation process. Everything needs to be setup though.
=== Garmin ADM ===
As of January garmin charts stopped working due to a firmware update. Investigation is underway.
The chart updates are currenlty not being handled so they are very outdated. If someone likes to
reenable the process, raise your hand.
=== Raymarine ===
There are some ideas floating around but nothing else at the moment. Contact Markus Bärlöcher to get some details.
Raster Charts

== Raster Charts ==
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
ways to intelligently select necessary tiles and compressions.

== State of the Loggers ==
=== OpenSeaMap Data Logger ===
==== NMEA0183 Seatalk ====
Since there has been a bug on the firmware the produced loggers must be flashed with
a new firmware. The recently sold loggers all had the new firmware but we are running low on patched loggers
and we need to flash the unpatched loggers in stock. Andreas Merz and Wolfgang will contact Winfried Schäfer on the instructions
how to flash the logger to speed up the process.
==== NMEA 2000 ====
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
=== Plotters from vendors ===
There are some plotter models listed on
http://wiki.openstreetmap.org/wiki/AT5-OpenSeaMap-Chart_for_Lowrance_Simrad_B%26G
http://wiki.openstreetmap.org/wiki/Garmin#Sea-Chart-Plotter
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
=== Software Data Logger ===
Since the upload API change the current logger no longer supports uploading files directly
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.

== Social Media ==
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.
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.
Wolfgang offered some help with the updates.

OpenSeaMap-dev:Entwicklerwochenende 2015-04/Bericht en

2015-05-05T09:38:32Z

Cleanerx: /* Web Backend */

= Protocol =
The meeting took place in Nürnberg from 2015-04-24 - 2015-04-26

== Organisation ==
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.
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
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.
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.
After some discussion and weighing out the pros and cons of such changes, Martin offered to draft a solution that will be communicated shortly - first for to attendees and then to the public.

== Depth Processing ==
=== Postprocessing ===
We have the basic processing chain setup and evaluate the performance in real world data sets.
Inshore data renders fine but large offshore data has to be improved as some queries are a little bit slow.
When performance has been improved we need to focus on data quality. Key quality contributors are the ocean tide, gauges and manual data corrections.
Ocean tide calculation is already included and gauges will be the next step to be included.
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.
As the sources are not yet online it is quite difficoult to get the system up and running in his environment.
==== Format decoding ====
Herbert has written a tool that is capable detecting patterns in file formats to decode them.
He is currently working on AT5 which is a chart format by Lowrance. Since we have several unknown formats
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
=== Web Backend ===
Editing of errors and gauges need to be addressed. 
[http://depth.openseamap.org:8080/org.osm.depth.upload.stage/api2/| Backend API] 
[https://depth.openseamap.org:8443/org.osm.depth.upload.stage/api2/| Backend API Secure] 

=== Website ===
The manual corrections involves more work and Martin will make a proposal how to integrate the editing from the gis web viewpoint.
Axel is a new contributor to the web page and contributed some valuable fixes. 
[https://depth.openseamap.org| Depth Website] 
[https://github.com/OpenSeaMap/depth_webfrontend| Sources Webfrontend]

== Rendering ==
=== Paper Chart Rendering ===
SMRender : http://www.abenteuerland.at/smrender/
Bernhard is actively contributing to the paper based renderer and is capable of rendering various difficult scenarios.
However he - like so many others - eagerly awaits free depth contours from OpenSeaMap to become available.
=== Software Rendering ===
==== OSM Renderer ====
Malcolm is administrating the old renderer while working on the new one. The new renderer may be found at
http://svn.openstreetmap.org/applications/editors/josm/plugins/seachart/
Progress has been slow recently.
=== Application Rendering ===
==== OSMAnd ====
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
to contributions that are capable of rendering seamarks and other sea items. Interested parties are welcome to show themselves to openseamap-devel@openseamap.org
==== OpenCPN ====
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
within the osm database. KAP is a raster format that is supported. >> What is the status of these KAP files ??? <<
==== Orux Maps & Locus ====
Based on MapsForge. Alexej is looking into how we can integrate into that portal . Is that correct ?

== Vector Charts ==
=== AT5 Generation ===
Someone ? is working on activating software that can generate at5 files. The process is very cpu time consuming
and we have a hardware provider and location at hand that can take over the generation process. Everything needs to be setup though.
=== Garmin ADM ===
As of January garmin charts stopped working due to a firmware update. Investigation is underway.
The chart updates are currenlty not being handled so they are very outdated. If someone likes to
reenable the process, raise your hand.
=== Raymarine ===
There are some ideas floating around but nothing else at the moment. Contact Markus Bärlöcher to get some details.
Raster Charts

== Raster Charts ==
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
ways to intelligently select necessary tiles and compressions.

== State of the Loggers ==
=== OpenSeaMap Data Logger ===
==== NMEA0183 Seatalk ====
Since there has been a bug on the firmware the produced loggers must be flashed with
a new firmware. The recently sold loggers all had the new firmware but we are running low on patched loggers
and we need to flash the unpatched loggers in stock. Andreas Merz and Wolfgang will contact Winfried Schäfer on the instructions
how to flash the logger to speed up the process.
==== NMEA 2000 ====
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
=== Plotters from vendors ===
There are some plotter models listed on
http://wiki.openstreetmap.org/wiki/AT5-OpenSeaMap-Chart_for_Lowrance_Simrad_B%26G
http://wiki.openstreetmap.org/wiki/Garmin#Sea-Chart-Plotter
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
=== Software Data Logger ===
Since the upload API change the current logger no longer supports uploading files directly
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.

== Social Media ==
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.
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.
Wolfgang offered some help with the updates.

OpenSeaMap-dev:Entwicklerwochenende 2015-04/Bericht en

2015-05-05T09:34:51Z

Cleanerx: /* Website */

= Protocol =
The meeting took place in Nürnberg from 2015-04-24 - 2015-04-26

== Organisation ==
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.
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
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.
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.
After some discussion and weighing out the pros and cons of such changes, Martin offered to draft a solution that will be communicated shortly - first for to attendees and then to the public.

== Depth Processing ==
=== Postprocessing ===
We have the basic processing chain setup and evaluate the performance in real world data sets.
Inshore data renders fine but large offshore data has to be improved as some queries are a little bit slow.
When performance has been improved we need to focus on data quality. Key quality contributors are the ocean tide, gauges and manual data corrections.
Ocean tide calculation is already included and gauges will be the next step to be included.
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.
As the sources are not yet online it is quite difficoult to get the system up and running in his environment.
==== Format decoding ====
Herbert has written a tool that is capable detecting patterns in file formats to decode them.
He is currently working on AT5 which is a chart format by Lowrance. Since we have several unknown formats
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
=== Web Backend ===
Editing of errors and gauges need to be addressed.
=== Website ===
The manual corrections involves more work and Martin will make a proposal how to integrate the editing from the gis web viewpoint.
Axel is a new contributor to the web page and contributed some valuable fixes. 
[https://depth.openseamap.org| Depth Website] 
[https://github.com/OpenSeaMap/depth_webfrontend| Sources Webfrontend]

== Rendering ==
=== Paper Chart Rendering ===
SMRender : http://www.abenteuerland.at/smrender/
Bernhard is actively contributing to the paper based renderer and is capable of rendering various difficult scenarios.
However he - like so many others - eagerly awaits free depth contours from OpenSeaMap to become available.
=== Software Rendering ===
==== OSM Renderer ====
Malcolm is administrating the old renderer while working on the new one. The new renderer may be found at
http://svn.openstreetmap.org/applications/editors/josm/plugins/seachart/
Progress has been slow recently.
=== Application Rendering ===
==== OSMAnd ====
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
to contributions that are capable of rendering seamarks and other sea items. Interested parties are welcome to show themselves to openseamap-devel@openseamap.org
==== OpenCPN ====
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
within the osm database. KAP is a raster format that is supported. >> What is the status of these KAP files ??? <<
==== Orux Maps & Locus ====
Based on MapsForge. Alexej is looking into how we can integrate into that portal . Is that correct ?

== Vector Charts ==
=== AT5 Generation ===
Someone ? is working on activating software that can generate at5 files. The process is very cpu time consuming
and we have a hardware provider and location at hand that can take over the generation process. Everything needs to be setup though.
=== Garmin ADM ===
As of January garmin charts stopped working due to a firmware update. Investigation is underway.
The chart updates are currenlty not being handled so they are very outdated. If someone likes to
reenable the process, raise your hand.
=== Raymarine ===
There are some ideas floating around but nothing else at the moment. Contact Markus Bärlöcher to get some details.
Raster Charts

== Raster Charts ==
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
ways to intelligently select necessary tiles and compressions.

== State of the Loggers ==
=== OpenSeaMap Data Logger ===
==== NMEA0183 Seatalk ====
Since there has been a bug on the firmware the produced loggers must be flashed with
a new firmware. The recently sold loggers all had the new firmware but we are running low on patched loggers
and we need to flash the unpatched loggers in stock. Andreas Merz and Wolfgang will contact Winfried Schäfer on the instructions
how to flash the logger to speed up the process.
==== NMEA 2000 ====
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
=== Plotters from vendors ===
There are some plotter models listed on
http://wiki.openstreetmap.org/wiki/AT5-OpenSeaMap-Chart_for_Lowrance_Simrad_B%26G
http://wiki.openstreetmap.org/wiki/Garmin#Sea-Chart-Plotter
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
=== Software Data Logger ===
Since the upload API change the current logger no longer supports uploading files directly
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.

== Social Media ==
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.
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.
Wolfgang offered some help with the updates.

OpenSeaMap-dev:Entwicklerwochenende 2015-04/Bericht en

2015-05-05T09:17:18Z

Cleanerx: Die Seite wurde neu angelegt: „= Protocol = The meeting took place in Nürnberg from 2015-04-24 - 2015-04-26 == Organisation == There have been some intense discssions about the openess of …“

= Protocol =
The meeting took place in Nürnberg from 2015-04-24 - 2015-04-26

== Organisation ==
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.
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
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.
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.
After some discussion and weighing out the pros and cons of such changes, Martin offered to draft a solution that will be communicated shortly - first for to attendees and then to the public.

== Depth Processing ==
=== Postprocessing ===
We have the basic processing chain setup and evaluate the performance in real world data sets.
Inshore data renders fine but large offshore data has to be improved as some queries are a little bit slow.
When performance has been improved we need to focus on data quality. Key quality contributors are the ocean tide, gauges and manual data corrections.
Ocean tide calculation is already included and gauges will be the next step to be included.
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.
As the sources are not yet online it is quite difficoult to get the system up and running in his environment.
==== Format decoding ====
Herbert has written a tool that is capable detecting patterns in file formats to decode them.
He is currently working on AT5 which is a chart format by Lowrance. Since we have several unknown formats
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
=== Web Backend ===
Editing of errors and gauges need to be addressed.
=== Website ===
The manual corrections involves more work and Martin will make a proposal how to integrate the editing from the gis web viewpoint.
Axel is a new contributor to the web page and contributed some valuable fixes.
== Rendering ==
=== Paper Chart Rendering ===
SMRender : http://www.abenteuerland.at/smrender/
Bernhard is actively contributing to the paper based renderer and is capable of rendering various difficult scenarios.
However he - like so many others - eagerly awaits free depth contours from OpenSeaMap to become available.
=== Software Rendering ===
==== OSM Renderer ====
Malcolm is administrating the old renderer while working on the new one. The new renderer may be found at
http://svn.openstreetmap.org/applications/editors/josm/plugins/seachart/
Progress has been slow recently.
=== Application Rendering ===
==== OSMAnd ====
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
to contributions that are capable of rendering seamarks and other sea items. Interested parties are welcome to show themselves to openseamap-devel@openseamap.org
==== OpenCPN ====
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
within the osm database. KAP is a raster format that is supported. >> What is the status of these KAP files ??? <<
==== Orux Maps & Locus ====
Based on MapsForge. Alexej is looking into how we can integrate into that portal . Is that correct ?

== Vector Charts ==
=== AT5 Generation ===
Someone ? is working on activating software that can generate at5 files. The process is very cpu time consuming
and we have a hardware provider and location at hand that can take over the generation process. Everything needs to be setup though.
=== Garmin ADM ===
As of January garmin charts stopped working due to a firmware update. Investigation is underway.
The chart updates are currenlty not being handled so they are very outdated. If someone likes to
reenable the process, raise your hand.
=== Raymarine ===
There are some ideas floating around but nothing else at the moment. Contact Markus Bärlöcher to get some details.
Raster Charts

== Raster Charts ==
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
ways to intelligently select necessary tiles and compressions.

== State of the Loggers ==
=== OpenSeaMap Data Logger ===
==== NMEA0183 Seatalk ====
Since there has been a bug on the firmware the produced loggers must be flashed with
a new firmware. The recently sold loggers all had the new firmware but we are running low on patched loggers
and we need to flash the unpatched loggers in stock. Andreas Merz and Wolfgang will contact Winfried Schäfer on the instructions
how to flash the logger to speed up the process.
==== NMEA 2000 ====
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
=== Plotters from vendors ===
There are some plotter models listed on
http://wiki.openstreetmap.org/wiki/AT5-OpenSeaMap-Chart_for_Lowrance_Simrad_B%26G
http://wiki.openstreetmap.org/wiki/Garmin#Sea-Chart-Plotter
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
=== Software Data Logger ===
Since the upload API change the current logger no longer supports uploading files directly
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.

== Social Media ==
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.
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.
Wolfgang offered some help with the updates.

OpenSeaMap-dev:Meetings

2015-05-05T09:04:35Z

Cleanerx:

[[OpenSeaMap-dev:MeettingApril2015|Meeting April 2015]]

OpenSeaMap-dev:Meetings

2015-05-05T09:04:19Z

Cleanerx: Die Seite wurde neu angelegt: „ Meeting April 2015|“

[[OpenSeaMap-dev:MeettingApril2015| Meeting April 2015|]]

OpenSeaMap-dev:Portal

2015-05-05T09:02:51Z

Cleanerx: /* OSeaM-Wiki Dev-Portal */

{|
|
{| class="wikitable"
| Liebe Entwickler,

Willkommen auf dem OpenSeaMap-Entwicklerportal !

Auf eine tolle Zusammenarbeit freuen sich 
Markus und Olaf
|}
|      
|
{| class="wikitable"
| Dear Developpers,

Welcome to the OpenSeaMap Developer Portal !

Looking forward to great cooperation, 
Markus und Olaf
|}
|}

__TOC__

== Organisationsplattformen ==
{{de:organisation}}

== OSeaM-Wiki Dev-Portal ==
: [[OpenSeaMap-dev:Portal|Dev-Portal]]
: [[de:Develop|Dev-Hauptseite]]
: [[OpenSeaMap-dev:Guidelines|Dev-Guidelines]]
: [[OpenSeaMap-dev:Structure|Dev-Structure]]
: [[OpenSeaMap-dev:Projekte|Our Projects]]
:: [[OpenSeaMap-dev:Watersport-Wiki|Watersport-Wiki]]

:: [[OpenSeaMap-dev:Renderer|Renderer]]

:: Shallow Water
::: [[OpenSeaMap-dev:User_login|User-Login]]
::: [[Depth_Data|Depth data]]
::: [[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|Crowd Sourced Depth Data]]
::: [[OpenSeaMap-dev:De:Depth_raw_data|De:Depth raw data]]
::: [[OpenSeaMap-dev:De:Depth_meta_data|De:Depth meta data]]
::: [[OpenSeaMap-dev:De:Depth_data_processing|De:Depth data processing]]
::: [[Shipnetwork|Collecting data from the ship's network]]
::: [[OpenSeaMap-dev:HW-logger/specification|HW-Logger]]
::: [http://seesea.sourceforge.net/datalogger/index.html SW-Logger]

:: Editors
::: [[OpenSeaMap-dev:Online-Editor|Online-Editor]]
::: [[de:Online-Editor|Online-Editor HowTo]] - [[Online-Editor|(englisch)]]
::: [[OpenSeaMap-dev:SMED-2|JOSM plugin SMED2]]

:: [[OpenSeaMap-dev:Harbour|Harbour]]
::: [[OpenSeaMap-dev:Harbour-DB|Harbour-DB]]
::: [[OpenSeaMap-dev:Hafen-DB|Hafen-DB alt]]
::: [[OpenSeaMap-dev:Hafen-Editor|Harbour-Editor]]

:: Dev-ToDo's
::: [[de:OpenSeaMap_in_Website|OpenSeaMap in Website einbinden]]
::: [[OpenSeaMap-dev:Online-Editor|Online-Editor-dev]]
::: [[OpenSeaMap-dev:Renderer|Renderer-dev]]
::: [[OpenSeaMap_in_Website|How to include OpenSeaMap in your website]]
::: [[Server|Server]]

: [[OpenSeaMap-dev:Meettings|Meetings]]

== OSM-Wiki ==

; Projekte
: [http://wiki.openstreetmap.org/wiki/DE:Seekarte Ursprüngliche Projektseite "Seekarte"]
: [http://wiki.openstreetmap.org/wiki/DE:Seekarte Projektseite "für Segler"] - [http://wiki.openstreetmap.org/wiki/Marine_Mapping (english)]
: [http://wiki.openstreetmap.org/wiki/DE:Meeresprofil Bathimetrie] - [http://wiki.openstreetmap.org/wiki/Bathimetry (english)]
: [http://wiki.openstreetmap.org/wiki/DE:Water_Depth Wassertiefe]
: [http://wiki.openstreetmap.org/wiki/DE:AIS AIS] - [http://wiki.openstreetmap.org/wiki/AIS (english)]
: [http://wiki.openstreetmap.org/wiki/DE:Seamap-Editor Projektseite "SeaMap-Editor"] - [http://wiki.openstreetmap.org/wiki/DE:Seamap-Editor (english)]
: [http://wiki.openstreetmap.org/wiki/Openseamap/DE:Seamap_database Meta-DB] - [http://wiki.openstreetmap.org/wiki/Openseamap/Seamap_database (english)]

; Grundlagen
: [http://wiki.openstreetmap.org/wiki/DE:Lowest_Astronomical_Tide LAT] - [http://wiki.openstreetmap.org/wiki/Lowest_Astronomical_Tide (english)]
: [http://wiki.openstreetmap.org/wiki/DE:Genauigkeit_von_Koordinaten Genauigkeit von Koordinaten]
: [http://wiki.openstreetmap.org/wiki/DE:Genauigkeit_von_GPS-Daten Genauigkeit von GPS-Daten]
: [http://wiki.openstreetmap.org/wiki/Zoom_levels Zoomlevel]
: [http://wiki.openstreetmap.org/wiki/DE:Altitude Höhe] - [http://wiki.openstreetmap.org/wiki/Altitude (englisch)]

; Daten
: [http://wiki.openstreetmap.org/wiki/OpenSeaMap/Seamark_Tag_Values Seamark Tag Values]
: [http://wiki.openstreetmap.org/wiki/OpenSeaMap/Seamark_Objects Seamark Objects]
: [http://wiki.openstreetmap.org/wiki/OpenSeaMap/Seamark_Attributes Seamark Attributes]
: [http://wiki.openstreetmap.org/wiki/OpenSeaMap/INT-1_Cross_Reference INT-1 Cross Reference]
: and Sub-Pages.

: [http://wiki.openstreetmap.org/wiki/de:Beacon Boye] - [http://wiki.openstreetmap.org/wiki/Buoy (english)]
: [http://wiki.openstreetmap.org/wiki/de:Beacon Bake] - [http://wiki.openstreetmap.org/wiki/Beacon (english)]
: [http://wiki.openstreetmap.org/wiki/de:Leuchtfeuer Leuchtfeuer] - [http://wiki.openstreetmap.org/wiki/Lighthouse (english)]
: [http://wiki.openstreetmap.org/wiki/DE:Hafen Hafen] - [http://wiki.openstreetmap.org/wiki/Harbour (english)]
: [http://wiki.openstreetmap.org/wiki/OpenSeaMap/Buoy_Data_Model Datenmodell Boye]
: [http://wiki.openstreetmap.org/wiki/OpenSeaMap/Beacon_Data_Model Datenmodell Bake]
: [http://wiki.openstreetmap.org/wiki/OpenSeaMap/Lights_Data_Model Datenmodell Leuchtfeuer]

== Qualitätsmanagement ==
: [http://seamark.bplaced.net/lights/ Leuchtfeuer mit falscher Position]
: [http://seamark.bplaced.net/harbours/ doppelte Häfen und Marinas]
: [[OpenSeaMap-dev:Harbour-Duplicates|Harbour Duplicates]]

==Mailingliste==
[https://lists.sourceforge.net/lists/listinfo/openseamap-develop openseamap-develop]{{English}} - [http://sourceforge.net/mailarchive/forum.php?forum_name=openseamap-develop Archiv]

== Forum ==
[http://forum.openseamap.org/ OpenSeaMap-forum]

very old: [http://sourceforge.net/projects/openseamap/forums/forum/992659 openseamap-develop-de]

==Fehler berichten==
Bitte verwende den [http://sourceforge.net/tracker/?group_id=273418&atid=1162128 SourceForge Tracker] {{English}} für Problemberichte.

== Wikipedia ==
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.

Wikipedia-Artikel können direkt im OSM- oder OSeaM-Wiki verlinkt werden:
<pre>
[[wikipedia:de:Artikelname|anzuzeigender Text]] (deutsch)
[[wikipedia:en:Artikelname|anzuzeigender Text]] (englisch)
</pre>

: [[wikipedia:de:OpenSeaMap|OpenSeaMap]]
: [[wikipedia:de:Pegel_(Wasserstandsmessung)|Pegel]]
: [[wikipedia:de:Normalhöhennull|Normalhöhennull]]
: [[wikipedia:de:Höhe (Geodäsie)|Höhe]]
: [[wikipedia:de:Seekartennull|Seekartennull]]
: [[wikipedia:de:World Geodetic System 1984|WGS-84]]
: [[wikipedia:de:Automatic_Identification_System|Automatic Identification System (AIS)]]
: [[wikipedia:de:Mann über Bord|Mann über Bord]]

== OSeaM-Wiki ==
[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].

Dieses Wiki ist nur für '''Hilfetexte''' und '''HowTo'''. 
Bitte alle Beiträge in '''Deutsch''' und '''Englisch''' verfassen.

: [[de:Hauptseite|Hauptseite]] - [[Hauptseite|(english)]]
:: [[de:Editor|Editor]] - [[Editor|(english)]]
::: [[de:Online-Editor|Online-Editor]] - [[Online-Editor|(english)]]
:::: [[de:Online-Editor/Window|Fenster und Funktionen]] - [[Online-Editor/Window|(english)]]
:::: [[de:Online-Editor/edit|Editieren (neu, ändern, verschieben, löschen)]] - [[Online-Editor/edit|(english)]]
:::: [[de:Online-Editor/Seamark|Seezeichen eingeben]] - [[Online-Editor/Seamark|(english)]]
:::: [[de:Online-Editor/Harbour|Häfen eingeben]] - [[Online-Editor/Harbour|(english)]]
::: [[de:JOSM_and_Plugin|JOSM und Plugin]] - [[JOSM_and_Plugin|(english)]]
:::: [[de:JOSM_and_Plugin/Window|Fenster]] - [[JOSM_and_Plugin/Window|(english)]]
:::: [[de:JOSM_and_Plugin/edit|Editieren]] - [[JOSM_and_Plugin/edit|english]]
:::: [[de:JOSM_and_Plugin/Seamark|Plugin]] - [[JOSM_and_Plugin/Seamark|(english)]]
:::: [[de:JOSM_and_Plugin/Harbour|Hafen]] - [[JOSM_and_Plugin/Harbour|(english)]]
:: [[de:NMEA-Daten_hochladen|Wassertiefen]] - [[NMEA-Daten_hochladen|(english)]]
::: [[de:Software_logger|Software-Logger]] - [[Software_logger|(english)]]
::: [[de:Hardware_logger|Hardware-Logger]] - [[Hardware_logger|(english)]]
:: [[de:OruxMaps|Android-App]] - [[OruxMaps|(english)]]
:: [[de:OpenSeaMap_in_Website|OpenSeaMap in Website]] - [[OpenSeaMap_in_Website|(english)]]
:: [http://git.bezono.org/?p=openseamap/dfa/docs_rendering.git;a=blob_plain;f=openstreetmap/install_de.txt;hb=HEAD Tile-Server installing HowTo]

[[Kategorie:Develop]]

h:De:NMEA-Daten hochladen

2014-05-14T06:25:00Z

Cleanerx: /* Ergebnisse */

{|border="0" cellpadding="6" cellspacing="0" width="100%"
!style="background:#E3E3E3;" | [[de:NMEA-Daten_hochladen|Deutsch]]
!style="background:#E3E3E3;" | [[NMEA-Daten_hochladen|English]]
!style="background:#E3E3E3; width:100%;" |
|}

{| style="float: right"
|
| {{Vorlage:de:Water_depth}}
|}

__TOC__

== Prozess==
[[File:OpenSeaMap_water_depths_by_drowdsourcing-de.jpg|right|250px]]
Die Daten bestehen aus:
* Messdaten (Wassertiefen-Rohdaten als Datei)
* Metadaten (Schiff, Messgeräte, Sensoren)
Wassertiefen und Metadaten werden miteinander verknüpft auf den Server hochgeladen
 und dort ausgewertet.
<div style="clear: both;"></div>

== HowTo ==
So kannst Du die gesammelten Daten auf den Server hochladen:

# [http://depth.openseamap.org melde Dich als Benutzer an] (Testversion)
# fülle das Formular mit den Metadaten aus (noch nicht veröffentlicht)
# lade die Datei mit den Tiefendaten hoch

== Account ==
[[Bild:Account einrichten.jpg|thumb|Account einrichten]]
Damit wir Deine Daten dem richtigen Schiff zuordnen können, brauchst Du einen Account. Damit kannst Du Dich dann zum Hochladen der Daten anmelden. Falls Du ein eigenes Schiff hast, oder schon weisst, mit welchem Schiff Du unterwegs sein wirst, kannst Du auch schon gleich die Metadaten eingeben.

== Metadaten ==
[[Bild:Metadaten-Formular.jpg|thumb|Metadaten eingeben]]

Siehe auch [[de:Metadata_help|Hilfe zu den Metadaten]]

Damit wir aus Deinen Tiefendaten Tiefenlinien erzeugen können, müssen wir die NMEA-Rohdaten bearbeiten. Wir müssen Welle und Tide herausrechnen, Sensorpositionen berücksichtigen, Offset korrigieren und vieles mehr. Dazu brauchen wir genaue Informationen über Dein Schiff, wo die Sensoren eingebaut sind, welche Sensoren und Geräte Du verwendest, und vieles mehr.

Damit Du diese Informationen ganz simpel eingeben kannst, hat Dominik ein übersichtliches Formular gebaut. Wenn Du mehrmals dasselbe Schiff benutzt, kannst Du die bereits eingegebenen Informationen einfach mit einem Klick bestätigen.

== Tiefendaten ==
[[Bild:Upload-Formular.jpg|thumb|Daten hochladen]]
Die von Dir gesammelten Daten sind auf einer SD-Karte oder bereits auf Deiner Festplatte. Unter dem Menüpunkt [http://depth.openseamap.org/#tracks "Track hochladen"] kannst Du die Datei mit den NMEA-Daten auf Deinem Rechner suchen, auswählen und zu unserem Server hochladen. Es ist auch möglich, mehrere Dateien gleichzeitig hochzuladen. Da die Datenmenge ziemlich gross sein kann, zeigt Dir eine Balken den Verlauf und die geschätzte Restzeit. Falls die Verbindung während dem Hochladen unterbrochen wird, [...]

=== Anzeige der hochgeladenen Dateien ===
Unter [http://depth.openseamap.org/#tracks "Track hochladen"] kannst du aus deinen Schiffen (die Du bisher unter "Metadaten" eingetragen hast) das Schiff auswählen, mit dem du die Datei aufgezeichnet hast, die du hochladen willst. Wähle das Schiff aus der DropDown-Liste.

Darunter siehst du eine Tabelle aller Dateien, die du bisher hochgeladen hast.
Die Spalten sind:

{| class="wikitable"
| ID || Dateiname || Status || Dateityp || Kompression || Container Track || Fahrzeug || Lizenz || Upload Datum || Aktion
|}

Du kannst die Tabelle nach Spalten sortieren: klicke dazu auf die Spaltenüberschrift im Tabellenkopf.

{| class="wikitable"
! Spalte || colspan="2" | Bedeutung
|-
| ID || colspan="2" | eindeutige Nummer der Datei
|-
| Dateiname || colspan="2" | der von dir gewählte Dateiname
|-
| Status
| Upload erfolgreich Verarbeitet Defekt ::Unknown:: Vorverarbeitet Keine nutzbaren Daten <leer> Duplicate
| Datei wurde erfolgreich hochgeladen Datei wurde analysiert irgendetwas ist kaputt das Format konnte nicht erkannt werden ? ? ? ?
|-
| Dateityp || colspan="2" | [[De:Depth_Data_Format|erkannter Dateityp]]
|-
| Kompression || colspan="2" | Verfahren, mit dem die Datei ggf. vor dem Hochladen komprimiert wurde (ZIP, GZIP)
|-
| Container Track || colspan="2" | ?
|-
| Fahrzeug || colspan="2" | Name des Schiffes, auf dem die Datei aufgezeichnet wurde
|-
| Lizenz || colspan="2" | ?
|-
| Upload Datum || colspan="2" | Datum an dem die Datei hochgeladen wurde
|-
| Aktion || colspan="2" | durch Klick auf den Papierkorb kann z.B. eine doppelt hochgeladene Datei gelöscht werdene
|}

Während eine Datei hochgeladen wird, bewegt sich unter "Status" ein blauer Fortschrittsbalken. Je nach Dateigrösse, Geschwindigkeit der Internetverbindung und gewähltem Kompressionsverfahren dauert das unterschiedlich lang. Eine unkomprimierte Datei mit 1 GB (ungefähr 1 Woche dauerhafte Aufzeichnung von NMEA-Daten dauert etwa ... Minuten. Die gleiche Datei gezippt dauert etwa ... Minuten, und mit dem OpenSeaMap-Kompressor etwa ... Minuten.

== Ergebnisse ==
[[Datei:Messpunkte-Brombachsee.jpg|thumb|Messpunkte anzeigen]]
Wenn deine Daten auf dem Server sind, kannst du die Messpunkte wenige Tage später [http://map.openseamap.org/?zoom=5&lat=48.51836&lon=11.03538&layers=BFTFFFTFFTF0FFFFFTFF auf der Vollbildkarte sehen]. Klicke dazu auf den Layer "Wassertiefen" und zoome zu Deinem Revier. Dort kannst du auch sehen, was sonst noch so an Daten vorhanden ist.

Wenn die Datenmenge es zulässt, werden bereits erste ungefähre Tiefenlinien abgeleitet und angezeigt. Achtung: dabei handelt es sich um unkorrigierte Rohdaten! Sie zeigen nur eine grobe Annäherung an die Form des Untergrundes, die Tiefenangaben sind ausschliesslich relativ zu verstehen.
[[Datei:DelaunayContours.png|thumb|Delaunay Triangulation von Mallorca auf Küsten und 100m Linie]]
[[Datei:Contours.png|thumb|Delaunay Triangulation von Cap Formentor mit Kontourlinien]]

== Flyer zum Projekt ==
: [http://typo3.openseamap.netz.smurf.noris.de/fileadmin/user_upload/inhalt/PDF/Waterdepth_Skipper_de_web.pdf für Skipper]
: [http://typo3.openseamap.netz.smurf.noris.de/fileadmin/user_upload/inhalt/PDF/Waterdepth_Charter_de_web.pdf für Charterfirmen]
Flyer dürfen frei verwendet werden, gibt es auch in Englisch und als Printversion.

h:De:NMEA-Daten hochladen

2014-05-14T06:24:22Z

Cleanerx: /* Ergebnisse */

{|border="0" cellpadding="6" cellspacing="0" width="100%"
!style="background:#E3E3E3;" | [[de:NMEA-Daten_hochladen|Deutsch]]
!style="background:#E3E3E3;" | [[NMEA-Daten_hochladen|English]]
!style="background:#E3E3E3; width:100%;" |
|}

{| style="float: right"
|
| {{Vorlage:de:Water_depth}}
|}

__TOC__

== Prozess==
[[File:OpenSeaMap_water_depths_by_drowdsourcing-de.jpg|right|250px]]
Die Daten bestehen aus:
* Messdaten (Wassertiefen-Rohdaten als Datei)
* Metadaten (Schiff, Messgeräte, Sensoren)
Wassertiefen und Metadaten werden miteinander verknüpft auf den Server hochgeladen
 und dort ausgewertet.
<div style="clear: both;"></div>

== HowTo ==
So kannst Du die gesammelten Daten auf den Server hochladen:

# [http://depth.openseamap.org melde Dich als Benutzer an] (Testversion)
# fülle das Formular mit den Metadaten aus (noch nicht veröffentlicht)
# lade die Datei mit den Tiefendaten hoch

== Account ==
[[Bild:Account einrichten.jpg|thumb|Account einrichten]]
Damit wir Deine Daten dem richtigen Schiff zuordnen können, brauchst Du einen Account. Damit kannst Du Dich dann zum Hochladen der Daten anmelden. Falls Du ein eigenes Schiff hast, oder schon weisst, mit welchem Schiff Du unterwegs sein wirst, kannst Du auch schon gleich die Metadaten eingeben.

== Metadaten ==
[[Bild:Metadaten-Formular.jpg|thumb|Metadaten eingeben]]

Siehe auch [[de:Metadata_help|Hilfe zu den Metadaten]]

Damit wir aus Deinen Tiefendaten Tiefenlinien erzeugen können, müssen wir die NMEA-Rohdaten bearbeiten. Wir müssen Welle und Tide herausrechnen, Sensorpositionen berücksichtigen, Offset korrigieren und vieles mehr. Dazu brauchen wir genaue Informationen über Dein Schiff, wo die Sensoren eingebaut sind, welche Sensoren und Geräte Du verwendest, und vieles mehr.

Damit Du diese Informationen ganz simpel eingeben kannst, hat Dominik ein übersichtliches Formular gebaut. Wenn Du mehrmals dasselbe Schiff benutzt, kannst Du die bereits eingegebenen Informationen einfach mit einem Klick bestätigen.

== Tiefendaten ==
[[Bild:Upload-Formular.jpg|thumb|Daten hochladen]]
Die von Dir gesammelten Daten sind auf einer SD-Karte oder bereits auf Deiner Festplatte. Unter dem Menüpunkt [http://depth.openseamap.org/#tracks "Track hochladen"] kannst Du die Datei mit den NMEA-Daten auf Deinem Rechner suchen, auswählen und zu unserem Server hochladen. Es ist auch möglich, mehrere Dateien gleichzeitig hochzuladen. Da die Datenmenge ziemlich gross sein kann, zeigt Dir eine Balken den Verlauf und die geschätzte Restzeit. Falls die Verbindung während dem Hochladen unterbrochen wird, [...]

=== Anzeige der hochgeladenen Dateien ===
Unter [http://depth.openseamap.org/#tracks "Track hochladen"] kannst du aus deinen Schiffen (die Du bisher unter "Metadaten" eingetragen hast) das Schiff auswählen, mit dem du die Datei aufgezeichnet hast, die du hochladen willst. Wähle das Schiff aus der DropDown-Liste.

Darunter siehst du eine Tabelle aller Dateien, die du bisher hochgeladen hast.
Die Spalten sind:

{| class="wikitable"
| ID || Dateiname || Status || Dateityp || Kompression || Container Track || Fahrzeug || Lizenz || Upload Datum || Aktion
|}

Du kannst die Tabelle nach Spalten sortieren: klicke dazu auf die Spaltenüberschrift im Tabellenkopf.

{| class="wikitable"
! Spalte || colspan="2" | Bedeutung
|-
| ID || colspan="2" | eindeutige Nummer der Datei
|-
| Dateiname || colspan="2" | der von dir gewählte Dateiname
|-
| Status
| Upload erfolgreich Verarbeitet Defekt ::Unknown:: Vorverarbeitet Keine nutzbaren Daten <leer> Duplicate
| Datei wurde erfolgreich hochgeladen Datei wurde analysiert irgendetwas ist kaputt das Format konnte nicht erkannt werden ? ? ? ?
|-
| Dateityp || colspan="2" | [[De:Depth_Data_Format|erkannter Dateityp]]
|-
| Kompression || colspan="2" | Verfahren, mit dem die Datei ggf. vor dem Hochladen komprimiert wurde (ZIP, GZIP)
|-
| Container Track || colspan="2" | ?
|-
| Fahrzeug || colspan="2" | Name des Schiffes, auf dem die Datei aufgezeichnet wurde
|-
| Lizenz || colspan="2" | ?
|-
| Upload Datum || colspan="2" | Datum an dem die Datei hochgeladen wurde
|-
| Aktion || colspan="2" | durch Klick auf den Papierkorb kann z.B. eine doppelt hochgeladene Datei gelöscht werdene
|}

Während eine Datei hochgeladen wird, bewegt sich unter "Status" ein blauer Fortschrittsbalken. Je nach Dateigrösse, Geschwindigkeit der Internetverbindung und gewähltem Kompressionsverfahren dauert das unterschiedlich lang. Eine unkomprimierte Datei mit 1 GB (ungefähr 1 Woche dauerhafte Aufzeichnung von NMEA-Daten dauert etwa ... Minuten. Die gleiche Datei gezippt dauert etwa ... Minuten, und mit dem OpenSeaMap-Kompressor etwa ... Minuten.

== Ergebnisse ==
[[Datei:Messpunkte-Brombachsee.jpg|thumb|Messpunkte anzeigen]]
Wenn deine Daten auf dem Server sind, kannst du die Messpunkte wenige Tage später [http://map.openseamap.org/?zoom=5&lat=48.51836&lon=11.03538&layers=BFTFFFTFFTF0FFFFFTFF auf der Vollbildkarte sehen]. Klicke dazu auf den Layer "Wassertiefen" und zoome zu Deinem Revier. Dort kannst du auch sehen, was sonst noch so an Daten vorhanden ist.

Wenn die Datenmenge es zulässt, werden bereits erste ungefähre Tiefenlinien abgeleitet und angezeigt. Achtung: dabei handelt es sich um unkorrigierte Rohdaten! Sie zeigen nur eine grobe Annäherung an die Form des Untergrundes, die Tiefenangaben sind ausschliesslich relativ zu verstehen.
[[Datei:DelaunayContours.png|thumb|Delaunay Triangulation mit Kontourlinien]]
[[Datei:Contours.png|thumb|Delaunay Triangulation mit Kontourlinien]]

== Flyer zum Projekt ==
: [http://typo3.openseamap.netz.smurf.noris.de/fileadmin/user_upload/inhalt/PDF/Waterdepth_Skipper_de_web.pdf für Skipper]
: [http://typo3.openseamap.netz.smurf.noris.de/fileadmin/user_upload/inhalt/PDF/Waterdepth_Charter_de_web.pdf für Charterfirmen]
Flyer dürfen frei verwendet werden, gibt es auch in Englisch und als Printversion.

Datei:Contours.png

2014-05-14T06:22:58Z

Cleanerx: cleanerx

cleanerx

h:De:NMEA-Daten hochladen

2014-05-09T08:11:46Z

Cleanerx: /* Ergebnisse */

{|border="0" cellpadding="6" cellspacing="0" width="100%"
!style="background:#E3E3E3;" | [[de:NMEA-Daten_hochladen|Deutsch]]
!style="background:#E3E3E3;" | [[NMEA-Daten_hochladen|English]]
!style="background:#E3E3E3; width:100%;" |
|}

{| style="float: right"
|
| {{Vorlage:de:Water_depth}}
|}

__TOC__

== Prozess==
[[File:OpenSeaMap_water_depths_by_drowdsourcing-de.jpg|right|250px]]
Die Daten bestehen aus:
* Messdaten (Wassertiefen-Rohdaten als Datei)
* Metadaten (Schiff, Messgeräte, Sensoren)
Wassertiefen und Metadaten werden miteinander verknüpft auf den Server hochgeladen
 und dort ausgewertet.
<div style="clear: both;"></div>

== HowTo ==
So kannst Du die gesammelten Daten auf den Server hochladen:

# [http://depth.openseamap.org melde Dich als Benutzer an] (Testversion)
# fülle das Formular mit den Metadaten aus (noch nicht veröffentlicht)
# lade die Datei mit den Tiefendaten hoch

== Account ==
[[Bild:Account einrichten.jpg|thumb|Account einrichten]]
Damit wir Deine Daten dem richtigen Schiff zuordnen können, brauchst Du einen Account. Damit kannst Du Dich dann zum Hochladen der Daten anmelden. Falls Du ein eigenes Schiff hast, oder schon weisst, mit welchem Schiff Du unterwegs sein wirst, kannst Du auch schon gleich die Metadaten eingeben.

== Metadaten ==
[[Bild:Metadaten-Formular.jpg|thumb|Metadaten eingeben]]

Siehe auch [[de:Metadata_help|Hilfe zu den Metadaten]]

Damit wir aus Deinen Tiefendaten Tiefenlinien erzeugen können, müssen wir die NMEA-Rohdaten bearbeiten. Wir müssen Welle und Tide herausrechnen, Sensorpositionen berücksichtigen, Offset korrigieren und vieles mehr. Dazu brauchen wir genaue Informationen über Dein Schiff, wo die Sensoren eingebaut sind, welche Sensoren und Geräte Du verwendest, und vieles mehr.

Damit Du diese Informationen ganz simpel eingeben kannst, hat Dominik ein übersichtliches Formular gebaut. Wenn Du mehrmals dasselbe Schiff benutzt, kannst Du die bereits eingegebenen Informationen einfach mit einem Klick bestätigen.

== Tiefendaten ==
[[Bild:Upload-Formular.jpg|thumb|Daten hochladen]]
Die von Dir gesammelten Daten sind auf einer SD-Karte oder bereits auf Deiner Festplatte. Unter dem Menüpunkt [http://depth.openseamap.org/#tracks "Track hochladen"] kannst Du die Datei mit den NMEA-Daten auf Deinem Rechner suchen, auswählen und zu unserem Server hochladen. Es ist auch möglich, mehrere Dateien gleichzeitig hochzuladen. Da die Datenmenge ziemlich gross sein kann, zeigt Dir eine Balken den Verlauf und die geschätzte Restzeit. Falls die Verbindung während dem Hochladen unterbrochen wird, [...]

=== Anzeige der hochgeladenen Dateien ===
Unter [http://depth.openseamap.org/#tracks "Track hochladen"] kannst du aus deinen Schiffen (die Du bisher unter "Metadaten" eingetragen hast) das Schiff auswählen, mit dem du die Datei aufgezeichnet hast, die du hochladen willst. Wähle das Schiff aus der DropDown-Liste.

Darunter siehst du eine Tabelle aller Dateien, die du bisher hochgeladen hast.
Die Spalten sind:

{| class="wikitable"
| ID || Dateiname || Status || Dateityp || Kompression || Container Track || Fahrzeug || Lizenz || Upload Datum || Aktion
|}

Du kannst die Tabelle nach Spalten sortieren: klicke dazu auf die Spaltenüberschrift im Tabellenkopf.

{| class="wikitable"
! Spalte || colspan="2" | Bedeutung
|-
| ID || colspan="2" | eindeutige Nummer der Datei
|-
| Dateiname || colspan="2" | der von dir gewählte Dateiname
|-
| Status
| Upload erfolgreich Verarbeitet Defekt ::Unknown:: Vorverarbeitet Keine nutzbaren Daten <leer> Duplicate
| Datei wurde erfolgreich hochgeladen Datei wurde analysiert irgendetwas ist kaputt das Format konnte nicht erkannt werden ? ? ? ?
|-
| Dateityp || colspan="2" | [[De:Depth_Data_Format|erkannter Dateityp]]
|-
| Kompression || colspan="2" | Verfahren, mit dem die Datei ggf. vor dem Hochladen komprimiert wurde (ZIP, GZIP)
|-
| Container Track || colspan="2" | ?
|-
| Fahrzeug || colspan="2" | Name des Schiffes, auf dem die Datei aufgezeichnet wurde
|-
| Lizenz || colspan="2" | ?
|-
| Upload Datum || colspan="2" | Datum an dem die Datei hochgeladen wurde
|-
| Aktion || colspan="2" | durch Klick auf den Papierkorb kann z.B. eine doppelt hochgeladene Datei gelöscht werdene
|}

Während eine Datei hochgeladen wird, bewegt sich unter "Status" ein blauer Fortschrittsbalken. Je nach Dateigrösse, Geschwindigkeit der Internetverbindung und gewähltem Kompressionsverfahren dauert das unterschiedlich lang. Eine unkomprimierte Datei mit 1 GB (ungefähr 1 Woche dauerhafte Aufzeichnung von NMEA-Daten dauert etwa ... Minuten. Die gleiche Datei gezippt dauert etwa ... Minuten, und mit dem OpenSeaMap-Kompressor etwa ... Minuten.

== Ergebnisse ==
[[Datei:Messpunkte-Brombachsee.jpg|thumb|Messpunkte anzeigen]]
Wenn deine Daten auf dem Server sind, kannst du die Messpunkte wenige Tage später [http://map.openseamap.org/?zoom=5&lat=48.51836&lon=11.03538&layers=BFTFFFTFFTF0FFFFFTFF auf der Vollbildkarte sehen]. Klicke dazu auf den Layer "Wassertiefen" und zoome zu Deinem Revier. Dort kannst du auch sehen, was sonst noch so an Daten vorhanden ist.

Wenn die Datenmenge es zulässt, werden bereits erste ungefähre Tiefenlinien abgeleitet und angezeigt. Achtung: dabei handelt es sich um unkorrigierte Rohdaten! Sie zeigen nur eine grobe Annäherung an die Form des Untergrundes, die Tiefenangaben sind ausschliesslich relativ zu verstehen.
[[Datei:DelaunayContours.png|thumb|Delaunay Triangulation mit Kontourlinien]]

== Flyer zum Projekt ==
: [http://typo3.openseamap.netz.smurf.noris.de/fileadmin/user_upload/inhalt/PDF/Waterdepth_Skipper_de_web.pdf für Skipper]
: [http://typo3.openseamap.netz.smurf.noris.de/fileadmin/user_upload/inhalt/PDF/Waterdepth_Charter_de_web.pdf für Charterfirmen]
Flyer dürfen frei verwendet werden, gibt es auch in Englisch und als Printversion.

h:De:NMEA-Daten hochladen

2014-05-09T08:11:21Z

Cleanerx: /* Ergebnisse */

{|border="0" cellpadding="6" cellspacing="0" width="100%"
!style="background:#E3E3E3;" | [[de:NMEA-Daten_hochladen|Deutsch]]
!style="background:#E3E3E3;" | [[NMEA-Daten_hochladen|English]]
!style="background:#E3E3E3; width:100%;" |
|}

{| style="float: right"
|
| {{Vorlage:de:Water_depth}}
|}

__TOC__

== Prozess==
[[File:OpenSeaMap_water_depths_by_drowdsourcing-de.jpg|right|250px]]
Die Daten bestehen aus:
* Messdaten (Wassertiefen-Rohdaten als Datei)
* Metadaten (Schiff, Messgeräte, Sensoren)
Wassertiefen und Metadaten werden miteinander verknüpft auf den Server hochgeladen
 und dort ausgewertet.
<div style="clear: both;"></div>

== HowTo ==
So kannst Du die gesammelten Daten auf den Server hochladen:

# [http://depth.openseamap.org melde Dich als Benutzer an] (Testversion)
# fülle das Formular mit den Metadaten aus (noch nicht veröffentlicht)
# lade die Datei mit den Tiefendaten hoch

== Account ==
[[Bild:Account einrichten.jpg|thumb|Account einrichten]]
Damit wir Deine Daten dem richtigen Schiff zuordnen können, brauchst Du einen Account. Damit kannst Du Dich dann zum Hochladen der Daten anmelden. Falls Du ein eigenes Schiff hast, oder schon weisst, mit welchem Schiff Du unterwegs sein wirst, kannst Du auch schon gleich die Metadaten eingeben.

== Metadaten ==
[[Bild:Metadaten-Formular.jpg|thumb|Metadaten eingeben]]

Siehe auch [[de:Metadata_help|Hilfe zu den Metadaten]]

Damit wir aus Deinen Tiefendaten Tiefenlinien erzeugen können, müssen wir die NMEA-Rohdaten bearbeiten. Wir müssen Welle und Tide herausrechnen, Sensorpositionen berücksichtigen, Offset korrigieren und vieles mehr. Dazu brauchen wir genaue Informationen über Dein Schiff, wo die Sensoren eingebaut sind, welche Sensoren und Geräte Du verwendest, und vieles mehr.

Damit Du diese Informationen ganz simpel eingeben kannst, hat Dominik ein übersichtliches Formular gebaut. Wenn Du mehrmals dasselbe Schiff benutzt, kannst Du die bereits eingegebenen Informationen einfach mit einem Klick bestätigen.

== Tiefendaten ==
[[Bild:Upload-Formular.jpg|thumb|Daten hochladen]]
Die von Dir gesammelten Daten sind auf einer SD-Karte oder bereits auf Deiner Festplatte. Unter dem Menüpunkt [http://depth.openseamap.org/#tracks "Track hochladen"] kannst Du die Datei mit den NMEA-Daten auf Deinem Rechner suchen, auswählen und zu unserem Server hochladen. Es ist auch möglich, mehrere Dateien gleichzeitig hochzuladen. Da die Datenmenge ziemlich gross sein kann, zeigt Dir eine Balken den Verlauf und die geschätzte Restzeit. Falls die Verbindung während dem Hochladen unterbrochen wird, [...]

=== Anzeige der hochgeladenen Dateien ===
Unter [http://depth.openseamap.org/#tracks "Track hochladen"] kannst du aus deinen Schiffen (die Du bisher unter "Metadaten" eingetragen hast) das Schiff auswählen, mit dem du die Datei aufgezeichnet hast, die du hochladen willst. Wähle das Schiff aus der DropDown-Liste.

Darunter siehst du eine Tabelle aller Dateien, die du bisher hochgeladen hast.
Die Spalten sind:

{| class="wikitable"
| ID || Dateiname || Status || Dateityp || Kompression || Container Track || Fahrzeug || Lizenz || Upload Datum || Aktion
|}

Du kannst die Tabelle nach Spalten sortieren: klicke dazu auf die Spaltenüberschrift im Tabellenkopf.

{| class="wikitable"
! Spalte || colspan="2" | Bedeutung
|-
| ID || colspan="2" | eindeutige Nummer der Datei
|-
| Dateiname || colspan="2" | der von dir gewählte Dateiname
|-
| Status
| Upload erfolgreich Verarbeitet Defekt ::Unknown:: Vorverarbeitet Keine nutzbaren Daten <leer> Duplicate
| Datei wurde erfolgreich hochgeladen Datei wurde analysiert irgendetwas ist kaputt das Format konnte nicht erkannt werden ? ? ? ?
|-
| Dateityp || colspan="2" | [[De:Depth_Data_Format|erkannter Dateityp]]
|-
| Kompression || colspan="2" | Verfahren, mit dem die Datei ggf. vor dem Hochladen komprimiert wurde (ZIP, GZIP)
|-
| Container Track || colspan="2" | ?
|-
| Fahrzeug || colspan="2" | Name des Schiffes, auf dem die Datei aufgezeichnet wurde
|-
| Lizenz || colspan="2" | ?
|-
| Upload Datum || colspan="2" | Datum an dem die Datei hochgeladen wurde
|-
| Aktion || colspan="2" | durch Klick auf den Papierkorb kann z.B. eine doppelt hochgeladene Datei gelöscht werdene
|}

Während eine Datei hochgeladen wird, bewegt sich unter "Status" ein blauer Fortschrittsbalken. Je nach Dateigrösse, Geschwindigkeit der Internetverbindung und gewähltem Kompressionsverfahren dauert das unterschiedlich lang. Eine unkomprimierte Datei mit 1 GB (ungefähr 1 Woche dauerhafte Aufzeichnung von NMEA-Daten dauert etwa ... Minuten. Die gleiche Datei gezippt dauert etwa ... Minuten, und mit dem OpenSeaMap-Kompressor etwa ... Minuten.

== Ergebnisse ==
[[Datei:Messpunkte-Brombachsee.jpg|thumb|Messpunkte anzeigen]]
Wenn deine Daten auf dem Server sind, kannst du die Messpunkte wenige Tage später [http://map.openseamap.org/?zoom=5&lat=48.51836&lon=11.03538&layers=BFTFFFTFFTF0FFFFFTFF auf der Vollbildkarte sehen]. Klicke dazu auf den Layer "Wassertiefen" und zoome zu Deinem Revier. Dort kannst du auch sehen, was sonst noch so an Daten vorhanden ist.

Wenn die Datenmenge es zulässt, werden bereits erste ungefähre Tiefenlinien abgeleitet und angezeigt. Achtung: dabei handelt es sich um unkorrigierte Rohdaten! Sie zeigen nur eine grobe Annäherung an die Form des Untergrundes, die Tiefenangaben sind ausschliesslich relativ zu verstehen.
[[Datei:DelaunayContours.png|thumb|Messpunkte anzeigen]]

== Flyer zum Projekt ==
: [http://typo3.openseamap.netz.smurf.noris.de/fileadmin/user_upload/inhalt/PDF/Waterdepth_Skipper_de_web.pdf für Skipper]
: [http://typo3.openseamap.netz.smurf.noris.de/fileadmin/user_upload/inhalt/PDF/Waterdepth_Charter_de_web.pdf für Charterfirmen]
Flyer dürfen frei verwendet werden, gibt es auch in Englisch und als Printversion.

Datei:DelaunayContours.png

2014-05-09T08:10:42Z

Cleanerx: cleanerx

cleanerx

h:En:Waterdepth-ships

2013-11-13T19:12:12Z

Cleanerx:

; Ships gallery of contributor ships.

<gallery widths="200" mode="packed-hover" perrow=3>
Ship-SZ-20033-F-SG.jpg | RB "SZ 20033 F" Singapore (SG)
Ship-Gübsen-Messkat-SG-CH.jpg | RB "Gübsen" St.Gallen (CH)
Komet research ship.jpg | RS "Komet" Hamburg (DE)
RB-DLRG-Brombachsee-DE.png | RB "DLRG" Brombachsee (DE)
Ship-MS-Ibelle-Berlin-DE.jpg | MS "Ibelle" Berlin (DE)
Datei:Ship-Galeb.jpg | SY "Galeb" ? (DE)
LisJolle.jpg | SY "Dolphin Crusher" Karlsruhe (DE)

</gallery>

Datei:LisJolle.jpg

2013-11-13T19:11:24Z

Cleanerx: shot by cleanerx

shot by cleanerx

OpenSeaMap-dev:En:Depth Data

2013-10-12T07:45:51Z

Cleanerx:

This Page describes the necessary efforts to retrieve and analyze depth data as well as create renderings from it

= Data Aquisition =
Depth data can be retrieved from public domain sources or from crowd sourced data.

== GEBCO ==
DIe Daten sind gerendert und stehen als Layer zur Verfügung:
{| class="wikitable"
! Zoom || Inhalt
|-
| 0..10 || Blaustufen und Schattierung
|-
| 11..18 || beschriftete Tiefenlinien, Blaustufen und Schattierung
|}

Noch zu lösende Probleme:
* der GEBCO-Layer erzeugt einen milchigen Schleier über der Basiskarte
* Tiefenlinien sind ab z=14 etwas grob (also ab da, wo dann die Flachwassertiefen beginnen) [http://dev.openseamap.org/website/map/#?zoom=14&lat=36.03097&lon=-5.49153&layers=BFTFTTTFFFF0]
* Überschneidungen von 100m-Linie und Küstenlinie [http://dev.openseamap.org/website/map/#?zoom=15&lat=36.00318&lon=-5.60819&layers=BFTFTTTFFFF0]
* Steilküsten (Cuba) [http://dev.openseamap.org/website/map/#?zoom=14&lat=19.94808&lon=-76.04289&layers=BFTFTTTFFFF0]

== Crowd Sourced Data ==
Crowd sourced data may be gathered by YOU. There are two options in development. A hardware and a software option.

=== Workflow ===
[[Datei:Workflow_depth.png]]

Here you can find the document with the previous thoughts about the workflow:
[http://osm.franken.de/wiki/FWT-Projekt%C3%BCbersicht-NMEA2Contours_2.1.ppt PPT Dokument]

=== Hardware logger ===
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.
That data may then be uploaded by plugging the SD card to a normal computer with internet connection for upload.
The main goal is to support NMEA 0183 data with options for NMEA 2000.

=== Software logger ===
A [[Software logger]] is in development and [http://seesea.sourceforge.net/datalogger/index.html can be downloaded here].

It currently supports:
: Bluetooth
: Serial ports
: Internet Protocol (IP)
It processes NMEA 0183 and AIS data.

For vendor specific protocols such as SeaTalk 1 you have to use a [[De:NMEA-Logger_anschliessen|converter]] to NMEA 0183 data.

NMEA 2000 support is only available if data is transcoded to NMEA 0183 by a converter.

=== Chart Plotters ===

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.

=== Upload Process ===
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].
The system is currently being tested.

[[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|You'll find further information here]].

=== Test Data ===

Test data for Openseamap: [http://osm.franken.de/wiki/test_data_brombachsee.zip Brombachsee_Test_Data]

dgm_brombachsee.tif: Digital Elevation Model of the sea derived from height lines WWA (C).

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).

gpx_brombachsee.gpx: ele = "dbs" from the Shape File

[[Datei:Brombachsee.png]]
Resulting Digital Elevation Model

= Data Preprocessing =

== Data Condition ==
Raw data is usually erronous and must be corrected

=== Internal data problems ===
Depth data may be affected by electrical conditions and software implementations
* Data is incomplete and fail their checksum (bus errors from physical transmissions errors)
* Data is retrived out of sequence
* Data is erronous sensor data
** Approximate correctable data i.e. invalid GPS position that may be interpolated
** Uncorrectable data i.e. failed log sensor that shows slow speeds
* Data resolution is low i.e. for energy saving purposes GPS position is updated every 10 seconds instead of every second
* Sensor data is actively miscalibrated i.e. charter companies add additional draft to the sensor depth for safety reasons

=== External data problems ===
Depth data may be affected by different environmental circumstances
*# The water temperature affects the ultrasound echo. An inhomogen water temperature yields unwanted echos
*# The seabed affects the ultrasound echo
*# The seastate affects the measurement. There even may be waves when there is no wind.
*# Waves may affect the roll of the measuring vessel resulting in steep measurements that are invalid.
*# The sounder sensor is not the position of the GPS antenna. A position offset including heading must be incorporated.
*# 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.
*# Corrections for tide induced water levels must happen

Solutions probably are
*# Water temperature may be measure from the sensor, other data may be unavailable
*# Modern sidescan sonar may yield information about the seabed through classifications
*# A gyro and accelerometer may be used to remove the waves
*# A gyro and accelerometer may be used to remove the waves
*# Position offsets must be provided by the user
*# Time outages may be handled by the filter if precise timestamps are available in recorded data
*# LAT to Mean sea level differences may be calculated from DTU10 worldwide, river gauges need to monitored

[[Datei:LAT2MSLDiff.png]]

== Data Condition Examples / Showcases ==

=== Missing measurments (Position) ===
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.
One can see from the distribtion that the sensor is updated every second but many measurements are one or more seconds late.
21 seconds with no position update may result in an instability of the subsequent filter.
<pre>
MeasuredPosition3D
GP
0 :4285
1000 :11295
2000 :5056
3000 :2134
4000 :1135
5000 :315
6000 :154
7000 :46
8000 :36
9000 :16
10000 :12
11000 :3
12000 :4
13000 :1
14000 :7
15000 :3
16000 :1
21000 :1
</pre>

=== Missing measurments (Position) with erronous clock ===
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)
<pre>
MeasuredPosition3D
II
-21340000 :1
-13194000 :1
-7998000 :1
-2674000 :1
-2434000 :1
-2402000 :1
-2030000 :1
-1926000 :1
-1894000 :1
-1806000 :1
-1480000 :1
-1430000 :1
-1382000 :1
-1114000 :1
-814000 :1
-634000 :1
-590000 :1
-546000 :1
-470000 :1
-290000 :1
-230000 :1
-198000 :1
-110000 :1
-94000 :2
0 :182200
5000 :1
10000 :20230
15000 :1
20000 :84
50000 :1
114000 :2
130000 :2
218000 :1
250000 :1
310000 :1
490000 :1
566000 :1
610000 :1
654000 :1
834000 :1
1134000 :1
1402000 :1
1450000 :1</pre>

== Solution Proposal ==

=== Outline ===
The ship is influenced by the outlined environment which can be observed. Naturally what is observed is not the state of the
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.

=== Details ===
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.

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.

Todo:
* Construct ship system model with at least the position state and probably its course and speed or even more (depth)
* Estimate the system variance (This is a hard one, proposals welcome)
* Construct the measurement model according to the data available (GPS, Log)
* Estimate the measurement noise according to specifc sensors (DPGS is more accurate than GPS)

The estimation with the position and depth can be retrieved and stored in a database.

Pitfalls:
* If the system noise is badly chosen the estimation of the system state does not converge to the true state / measurement.
* If the system is very detailed the system variance can be reduced. The required cpu time for processing increases

Benefits:
* Having the best estimation of the true position even if measurements are noisy
* Easy and effective algorithmic processing

== Analysis ==

=== Data Sets ===
Currently two test data sets are available recorded during trips from Mallorca and the Baltic Sea.
In terms of data quality the Mallorca data shows many challenges.
* The minimum recommended sentences from NMEA showed up with false date and time readings while having correct (!!!) message checksums.
* The log on the ship was defective and delivered no readings from time to time.
* The same holds true for the water temperature.
* The GPS positions relatively imprecise because some last decimal digits are missing in the recordings.
* The GPS positions are updated every 10 seconds while other sensor readings update almost every second.
* The GPS position are sometimes way off due to false readings

The Baltic Sea data set is a little bit better
* Only a single day is available
* GPS positions are updated every second

One problem with the data is that there is time available when sensor readings were recorded. This yields problems to the filter algorithm.

=== Filter Algorithm ===
At first the Extended Kalman Filter is being analyzed. Using an apache implementation with the available data the filter quickly throw an exception that
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.
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
we may consider that for the future.

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
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.

== Results ==
A prototype implementation is shown in the following screenshots. An Extended Kalman Filter is being used. It has the position
and the current bearing and velocity as system state. The input is the measurement of these four observables. The system function is
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.
The initial state is taken from the first measurement for convergence reasons.

The following gallery shows the results.
* You can see the bad position resolution and an outlier in the first screenshot.
* The second shows the same data overlaid with the applied filter. The outlier is gone and the resolution has improved.
* The third screenshot shows data from a different GPS sensor with more precision (not DGPS) versus the filtered data.

This of course is just a preliminary test and many setups need to be considered to make it work for most datasets.

<gallery>
UnfilteredNMEA.png | Unfiltered GPS data
FilteredNMEAVsOriginal.png | Unfiltered GPS data and Filtered GPS data
PreciseGPSvsFilter.png | Another precise GPS vs Filtered GPS data
</gallery>

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].
This way positional inaccuracies may be added to the overall depth measurement inaccuracy.

== Quality rating ==

Each record (time, positon, depth) should become a quality rating.

=== Points ===

Derived from the Fibonacci series.

{| class="wikitable"
! Point || Description
|-
| 1 || extra small improvement
|-
| 2 || small improvement
|-
| 3 || medium improvement
|-
| 5 || large improvement
|-
| 8 || extra large improvement
|}

=== Factors ===

{| class="wikitable"
! style="width:15%" | Name
! style="width:17%" | Factor
! style="width:68%" | Description
|-
| depth offset || 8 (extra large) || The difference between the depth measured by the echo sounder and the depth (waterline) measured by hand.
|-
| device distance || 3 (medium) || The distance between gps antenna and echo sounder (lengthwise and crosswise).
|-
| SBAS || 3 (medium) || Satellite based augmentation system (WAAS, EGNOS, MSAS) which allows to correct the gps position.
|-
| 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.
|}

= Depth Rendering =

= Siehe auch =
* [[De:Bordnetz|Bordnetz]]
* [[De:NMEA-Logger_anschliessen|NMEA-Logger_anschliessen]]
* [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]
* [http://users.isr.ist.utl.pt/~pedro/publications/CAMS10.pdf A Multiple Model Adaptive Wave Filter for Dynamic Ship Positioning]
* [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]

Datei:LAT2MSLDiff.png

2013-10-12T07:41:35Z

Cleanerx: Differences between LAT and MSL based on DTU10 Tide Model calculations

Differences between LAT and MSL based on DTU10 Tide Model calculations

OpenSeaMap-dev:En:Depth Data

2013-10-12T07:40:26Z

Cleanerx:

This Page describes the necessary efforts to retrieve and analyze depth data as well as create renderings from it

= Data Aquisition =
Depth data can be retrieved from public domain sources or from crowd sourced data.

== GEBCO ==
DIe Daten sind gerendert und stehen als Layer zur Verfügung:
{| class="wikitable"
! Zoom || Inhalt
|-
| 0..10 || Blaustufen und Schattierung
|-
| 11..18 || beschriftete Tiefenlinien, Blaustufen und Schattierung
|}

Noch zu lösende Probleme:
* der GEBCO-Layer erzeugt einen milchigen Schleier über der Basiskarte
* Tiefenlinien sind ab z=14 etwas grob (also ab da, wo dann die Flachwassertiefen beginnen) [http://dev.openseamap.org/website/map/#?zoom=14&lat=36.03097&lon=-5.49153&layers=BFTFTTTFFFF0]
* Überschneidungen von 100m-Linie und Küstenlinie [http://dev.openseamap.org/website/map/#?zoom=15&lat=36.00318&lon=-5.60819&layers=BFTFTTTFFFF0]
* Steilküsten (Cuba) [http://dev.openseamap.org/website/map/#?zoom=14&lat=19.94808&lon=-76.04289&layers=BFTFTTTFFFF0]

== Crowd Sourced Data ==
Crowd sourced data may be gathered by YOU. There are two options in development. A hardware and a software option.

=== Workflow ===
[[Datei:Workflow_depth.png]]

Here you can find the document with the previous thoughts about the workflow:
[http://osm.franken.de/wiki/FWT-Projekt%C3%BCbersicht-NMEA2Contours_2.1.ppt PPT Dokument]

=== Hardware logger ===
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.
That data may then be uploaded by plugging the SD card to a normal computer with internet connection for upload.
The main goal is to support NMEA 0183 data with options for NMEA 2000.

=== Software logger ===
A [[Software logger]] is in development and [http://seesea.sourceforge.net/datalogger/index.html can be downloaded here].

It currently supports:
: Bluetooth
: Serial ports
: Internet Protocol (IP)
It processes NMEA 0183 and AIS data.

For vendor specific protocols such as SeaTalk 1 you have to use a [[De:NMEA-Logger_anschliessen|converter]] to NMEA 0183 data.

NMEA 2000 support is only available if data is transcoded to NMEA 0183 by a converter.

=== Chart Plotters ===

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.

=== Upload Process ===
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].
The system is currently being tested.

[[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|You'll find further information here]].

=== Test Data ===

Test data for Openseamap: [http://osm.franken.de/wiki/test_data_brombachsee.zip Brombachsee_Test_Data]

dgm_brombachsee.tif: Digital Elevation Model of the sea derived from height lines WWA (C).

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).

gpx_brombachsee.gpx: ele = "dbs" from the Shape File

[[Datei:Brombachsee.png]]
Resulting Digital Elevation Model

= Data Preprocessing =

== Data Condition ==
Raw data is usually erronous and must be corrected

=== Internal data problems ===
Depth data may be affected by electrical conditions and software implementations
* Data is incomplete and fail their checksum (bus errors from physical transmissions errors)
* Data is retrived out of sequence
* Data is erronous sensor data
** Approximate correctable data i.e. invalid GPS position that may be interpolated
** Uncorrectable data i.e. failed log sensor that shows slow speeds
* Data resolution is low i.e. for energy saving purposes GPS position is updated every 10 seconds instead of every second
* Sensor data is actively miscalibrated i.e. charter companies add additional draft to the sensor depth for safety reasons

=== External data problems ===
Depth data may be affected by different environmental circumstances
*# The water temperature affects the ultrasound echo. An inhomogen water temperature yields unwanted echos
*# The seabed affects the ultrasound echo
*# The seastate affects the measurement. There even may be waves when there is no wind.
*# Waves may affect the roll of the measuring vessel resulting in steep measurements that are invalid.
*# The sounder sensor is not the position of the GPS antenna. A position offset including heading must be incorporated.
*# 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.
*# Corrections for tide induced water levels must happen

Solutions probably are
*# Water temperature may be measure from the sensor, other data may be unavailable
*# Modern sidescan sonar may yield information about the seabed through classifications
*# A gyro and accelerometer may be used to remove the waves
*# A gyro and accelerometer may be used to remove the waves
*# Position offsets must be provided by the user
*# Time outages may be handled by the filter if precise timestamps are available in recorded data
*# LAT to Mean sea level differences may be calculated from DTU10 worldwide, river gauges need to monitored

== Data Condition Examples / Showcases ==

=== Missing measurments (Position) ===
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.
One can see from the distribtion that the sensor is updated every second but many measurements are one or more seconds late.
21 seconds with no position update may result in an instability of the subsequent filter.
<pre>
MeasuredPosition3D
GP
0 :4285
1000 :11295
2000 :5056
3000 :2134
4000 :1135
5000 :315
6000 :154
7000 :46
8000 :36
9000 :16
10000 :12
11000 :3
12000 :4
13000 :1
14000 :7
15000 :3
16000 :1
21000 :1
</pre>

=== Missing measurments (Position) with erronous clock ===
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)
<pre>
MeasuredPosition3D
II
-21340000 :1
-13194000 :1
-7998000 :1
-2674000 :1
-2434000 :1
-2402000 :1
-2030000 :1
-1926000 :1
-1894000 :1
-1806000 :1
-1480000 :1
-1430000 :1
-1382000 :1
-1114000 :1
-814000 :1
-634000 :1
-590000 :1
-546000 :1
-470000 :1
-290000 :1
-230000 :1
-198000 :1
-110000 :1
-94000 :2
0 :182200
5000 :1
10000 :20230
15000 :1
20000 :84
50000 :1
114000 :2
130000 :2
218000 :1
250000 :1
310000 :1
490000 :1
566000 :1
610000 :1
654000 :1
834000 :1
1134000 :1
1402000 :1
1450000 :1</pre>

== Solution Proposal ==

=== Outline ===
The ship is influenced by the outlined environment which can be observed. Naturally what is observed is not the state of the
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.

=== Details ===
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.

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.

Todo:
* Construct ship system model with at least the position state and probably its course and speed or even more (depth)
* Estimate the system variance (This is a hard one, proposals welcome)
* Construct the measurement model according to the data available (GPS, Log)
* Estimate the measurement noise according to specifc sensors (DPGS is more accurate than GPS)

The estimation with the position and depth can be retrieved and stored in a database.

Pitfalls:
* If the system noise is badly chosen the estimation of the system state does not converge to the true state / measurement.
* If the system is very detailed the system variance can be reduced. The required cpu time for processing increases

Benefits:
* Having the best estimation of the true position even if measurements are noisy
* Easy and effective algorithmic processing

== Analysis ==

=== Data Sets ===
Currently two test data sets are available recorded during trips from Mallorca and the Baltic Sea.
In terms of data quality the Mallorca data shows many challenges.
* The minimum recommended sentences from NMEA showed up with false date and time readings while having correct (!!!) message checksums.
* The log on the ship was defective and delivered no readings from time to time.
* The same holds true for the water temperature.
* The GPS positions relatively imprecise because some last decimal digits are missing in the recordings.
* The GPS positions are updated every 10 seconds while other sensor readings update almost every second.
* The GPS position are sometimes way off due to false readings

The Baltic Sea data set is a little bit better
* Only a single day is available
* GPS positions are updated every second

One problem with the data is that there is time available when sensor readings were recorded. This yields problems to the filter algorithm.

=== Filter Algorithm ===
At first the Extended Kalman Filter is being analyzed. Using an apache implementation with the available data the filter quickly throw an exception that
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.
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
we may consider that for the future.

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
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.

== Results ==
A prototype implementation is shown in the following screenshots. An Extended Kalman Filter is being used. It has the position
and the current bearing and velocity as system state. The input is the measurement of these four observables. The system function is
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.
The initial state is taken from the first measurement for convergence reasons.

The following gallery shows the results.
* You can see the bad position resolution and an outlier in the first screenshot.
* The second shows the same data overlaid with the applied filter. The outlier is gone and the resolution has improved.
* The third screenshot shows data from a different GPS sensor with more precision (not DGPS) versus the filtered data.

This of course is just a preliminary test and many setups need to be considered to make it work for most datasets.

<gallery>
UnfilteredNMEA.png | Unfiltered GPS data
FilteredNMEAVsOriginal.png | Unfiltered GPS data and Filtered GPS data
PreciseGPSvsFilter.png | Another precise GPS vs Filtered GPS data
</gallery>

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].
This way positional inaccuracies may be added to the overall depth measurement inaccuracy.

== Quality rating ==

Each record (time, positon, depth) should become a quality rating.

=== Points ===

Derived from the Fibonacci series.

{| class="wikitable"
! Point || Description
|-
| 1 || extra small improvement
|-
| 2 || small improvement
|-
| 3 || medium improvement
|-
| 5 || large improvement
|-
| 8 || extra large improvement
|}

=== Factors ===

{| class="wikitable"
! style="width:15%" | Name
! style="width:17%" | Factor
! style="width:68%" | Description
|-
| depth offset || 8 (extra large) || The difference between the depth measured by the echo sounder and the depth (waterline) measured by hand.
|-
| device distance || 3 (medium) || The distance between gps antenna and echo sounder (lengthwise and crosswise).
|-
| SBAS || 3 (medium) || Satellite based augmentation system (WAAS, EGNOS, MSAS) which allows to correct the gps position.
|-
| 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.
|}

= Depth Rendering =

= Siehe auch =
* [[De:Bordnetz|Bordnetz]]
* [[De:NMEA-Logger_anschliessen|NMEA-Logger_anschliessen]]
* [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]
* [http://users.isr.ist.utl.pt/~pedro/publications/CAMS10.pdf A Multiple Model Adaptive Wave Filter for Dynamic Ship Positioning]
* [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]

OpenSeaMap-dev:En:Depth Data

2013-05-27T16:20:38Z

Cleanerx: /* Test Data */

This Page describes the necessary efforts to retrieve and analyze depth data as well as create renderings from it

= Data Aquisition =
Depth data can be retrieved from public domain sources or from crowd sourced data.

== GEBCO ==
DIe Daten sind gerendert und stehen als Layer zur Verfügung:
{| class="wikitable"
! Zoom || Inhalt
|-
| 0..10 || Blaustufen und Schattierung
|-
| 11..18 || beschriftete Tiefenlinien, Blaustufen und Schattierung
|}

Noch zu lösende Probleme:
* der GEBCO-Layer erzeugt einen milchigen Schleier über der Basiskarte
* Tiefenlinien sind ab z=14 etwas grob (also ab da, wo dann die Flachwassertiefen beginnen) [http://dev.openseamap.org/website/map/#?zoom=14&lat=36.03097&lon=-5.49153&layers=BFTFTTTFFFF0]
* Überschneidungen von 100m-Linie und Küstenlinie [http://dev.openseamap.org/website/map/#?zoom=15&lat=36.00318&lon=-5.60819&layers=BFTFTTTFFFF0]
* Steilküsten (Cuba) [http://dev.openseamap.org/website/map/#?zoom=14&lat=19.94808&lon=-76.04289&layers=BFTFTTTFFFF0]

== Crowd Sourced Data ==
Crowd sourced data may be gathered by YOU. There are two options in development. A hardware and a software option.

=== Workflow ===
[[Datei:Workflow_depth.png]]

Here you can find the document with the previous thoughts about the workflow:
[http://osm.franken.de/wiki/FWT-Projekt%C3%BCbersicht-NMEA2Contours_2.1.ppt PPT Dokument]

=== Hardware logger ===
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.
That data may then be uploaded by plugging the SD card to a normal computer with internet connection for upload.
The main goal is to support NMEA 0183 data with options for NMEA 2000.

=== Software logger ===
A [[Software logger]] is in development and [http://seesea.sourceforge.net/datalogger/index.html can be downloaded here].

It currently supports:
: Bluetooth
: Serial ports
: Internet Protocol (IP)
It processes NMEA 0183 and AIS data.

For vendor specific protocols such as SeaTalk 1 you have to use a [[De:NMEA-Logger_anschliessen|converter]] to NMEA 0183 data.

NMEA 2000 support is only available if data is transcoded to NMEA 0183 by a converter.

=== Chart Plotters ===

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.

=== Upload Process ===
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].
The system is currently being tested.

[[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|You'll find further information here]].

=== Test Data ===

Test data for Openseamap: [http://osm.franken.de/wiki/test_data_brombachsee.zip Brombachsee_Test_Data]

dgm_brombachsee.tif: Digital Elevation Model of the sea derived from height lines WWA (C).

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).

gpx_brombachsee.gpx: ele = "dbs" from the Shape File

[[Datei:Brombachsee.png]]
Resulting Digital Elevation Model

= Data Preprocessing =

== Data Condition ==
Raw data is usually erronous and must be corrected

=== Internal data problems ===
Depth data may be affected by electrical conditions and software implementations
* Data is incomplete and fail their checksum (bus errors from physical transmissions errors)
* Data is retrived out of sequence
* Data is erronous sensor data
** Approximate correctable data i.e. invalid GPS position that may be interpolated
** Uncorrectable data i.e. failed log sensor that shows slow speeds
* Data resolution is low i.e. for energy saving purposes GPS position is updated every 10 seconds instead of every second
* Sensor data is actively miscalibrated i.e. charter companies add additional draft to the sensor depth for safety reasons

=== External data problems ===
Depth data may be affected by different environmental circumstances
* The water temperature affects the ultrasound echo. An inhomogen water temperature yields unwanted echos
* The seabed affects the ultrasound echo
* The seastate affects the measurement. There even may be waves when there is no wind.
* Waves may affect the roll of the measuring vessel resulting in steep measurements that are invalid.
* The sounder sensor is not the position of the GPS antenna. A position offset including heading must be incorporated.
* 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.

== Data Condition Examples / Showcases ==

=== Missing measurments (Position) ===
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.
One can see from the distribtion that the sensor is updated every second but many measurements are one or more seconds late.
21 seconds with no position update may result in an instability of the subsequent filter.
<pre>
MeasuredPosition3D
GP
0 :4285
1000 :11295
2000 :5056
3000 :2134
4000 :1135
5000 :315
6000 :154
7000 :46
8000 :36
9000 :16
10000 :12
11000 :3
12000 :4
13000 :1
14000 :7
15000 :3
16000 :1
21000 :1
</pre>

=== Missing measurments (Position) with erronous clock ===
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)
<pre>
MeasuredPosition3D
II
-21340000 :1
-13194000 :1
-7998000 :1
-2674000 :1
-2434000 :1
-2402000 :1
-2030000 :1
-1926000 :1
-1894000 :1
-1806000 :1
-1480000 :1
-1430000 :1
-1382000 :1
-1114000 :1
-814000 :1
-634000 :1
-590000 :1
-546000 :1
-470000 :1
-290000 :1
-230000 :1
-198000 :1
-110000 :1
-94000 :2
0 :182200
5000 :1
10000 :20230
15000 :1
20000 :84
50000 :1
114000 :2
130000 :2
218000 :1
250000 :1
310000 :1
490000 :1
566000 :1
610000 :1
654000 :1
834000 :1
1134000 :1
1402000 :1
1450000 :1</pre>

== Solution Proposal ==

=== Outline ===
The ship is influenced by the outlined environment which can be observed. Naturally what is observed is not the state of the
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.

=== Details ===
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.

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.

Todo:
* Construct ship system model with at least the position state and probably its course and speed or even more (depth)
* Estimate the system variance (This is a hard one, proposals welcome)
* Construct the measurement model according to the data available (GPS, Log)
* Estimate the measurement noise according to specifc sensors (DPGS is more accurate than GPS)

The estimation with the position and depth can be retrieved and stored in a database.

Pitfalls:
* If the system noise is badly chosen the estimation of the system state does not converge to the true state / measurement.
* If the system is very detailed the system variance can be reduced. The required cpu time for processing increases

Benefits:
* Having the best estimation of the true position even if measurements are noisy
* Easy and effective algorithmic processing

== Analysis ==

=== Data Sets ===
Currently two test data sets are available recorded during trips from Mallorca and the Baltic Sea.
In terms of data quality the Mallorca data shows many challenges.
* The minimum recommended sentences from NMEA showed up with false date and time readings while having correct (!!!) message checksums.
* The log on the ship was defective and delivered no readings from time to time.
* The same holds true for the water temperature.
* The GPS positions relatively imprecise because some last decimal digits are missing in the recordings.
* The GPS positions are updated every 10 seconds while other sensor readings update almost every second.
* The GPS position are sometimes way off due to false readings

The Baltic Sea data set is a little bit better
* Only a single day is available
* GPS positions are updated every second

One problem with the data is that there is time available when sensor readings were recorded. This yields problems to the filter algorithm.

=== Filter Algorithm ===
At first the Extended Kalman Filter is being analyzed. Using an apache implementation with the available data the filter quickly throw an exception that
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.
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
we may consider that for the future.

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
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.

== Results ==
A prototype implementation is shown in the following screenshots. An Extended Kalman Filter is being used. It has the position
and the current bearing and velocity as system state. The input is the measurement of these four observables. The system function is
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.
The initial state is taken from the first measurement for convergence reasons.

The following gallery shows the results.
* You can see the bad position resolution and an outlier in the first screenshot.
* The second shows the same data overlaid with the applied filter. The outlier is gone and the resolution has improved.
* The third screenshot shows data from a different GPS sensor with more precision (not DGPS) versus the filtered data.

This of course is just a preliminary test and many setups need to be considered to make it work for most datasets.

<gallery>
UnfilteredNMEA.png | Unfiltered GPS data
FilteredNMEAVsOriginal.png | Unfiltered GPS data and Filtered GPS data
PreciseGPSvsFilter.png | Another precise GPS vs Filtered GPS data
</gallery>

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].
This way positional inaccuracies may be added to the overall depth measurement inaccuracy.

== Quality rating ==

Each record (time, positon, depth) should become a quality rating.

=== Points ===

Derived from the Fibonacci series.

{| class="wikitable"
! Point || Description
|-
| 1 || extra small improvement
|-
| 2 || small improvement
|-
| 3 || medium improvement
|-
| 5 || large improvement
|-
| 8 || extra large improvement
|}

=== Factors ===

{| class="wikitable"
! style="width:15%" | Name
! style="width:17%" | Factor
! style="width:68%" | Description
|-
| depth offset || 8 (extra large) || The difference between the depth measured by the echo sounder and the depth (waterline) measured by hand.
|-
| device distance || 3 (medium) || The distance between gps antenna and echo sounder (lengthwise and crosswise).
|-
| SBAS || 3 (medium) || Satellite based augmentation system (WAAS, EGNOS, MSAS) which allows to correct the gps position.
|-
| 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.
|}

= Depth Rendering =

= Siehe auch =
* [[De:Bordnetz|Bordnetz]]
* [[De:NMEA-Logger_anschliessen|NMEA-Logger_anschliessen]]
* [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]
* [http://users.isr.ist.utl.pt/~pedro/publications/CAMS10.pdf A Multiple Model Adaptive Wave Filter for Dynamic Ship Positioning]
* [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]

Datei:Brombachsee.png

2013-05-27T16:16:17Z

Cleanerx: created from GeoTiff with geoserver by cleanerx

created from GeoTiff with geoserver by cleanerx

OpenSeaMap-dev:HW-logger/Victor.en

2013-05-12T13:32:51Z

Cleanerx:

{|border="0" cellpadding="6" cellspacing="0" width="100%"
!style="background:#E3E3E3;" | [[OpenSeaMap-dev:HW-logger/Victor|Deutsch]]
!style="background:#E3E3E3;" | [[OpenSeaMap-dev:HW-logger/Victor.en|English]]
!style="background:#E3E3E3; width:100%;" |
|}

== NMEA-0183 Logger ==
; Safety issue:
Connecting NMEA0183 devices to a an RS232-USB-Converter may cause problems. As we use the converter only for reading it may run without further problems.

; Features
* Collect data from NMEA-0183 or SeaTalk 1 sensors and route them to your hand held device for display
* Connect your mobile phone, tablet or laptop to share a common 3G UMTS/LTE or Harbour Wifi connection while aboard.
* Log data to USB Stick to help improve OpenSeaMap sea chart by simplly clicking on a button.

== Hardware ==
{| class="wikitable"
! Nr || Device || Price || Remarks
|-
| 1 || [http://www.amazon.de/TP-Link-TL-MR3020-Wireless-LAN-frustfreie-Verpackung/dp/B00634PLTW TP-Link MR3020]
| 30-35 € || Das device must be flashed and configured with a new software.
|-
| 1 || 4-Port USB-Hub
| 7 € ||
|-
| 1 || 4GB USB-Memory-Stick
| 3 € || with 4 Unix partitions und Unix-ext3-File-System
|-
| x || Seriell-USB-Converter
| 10 € || one for each nmea-device needed Attention: only the FTDI and the PL2303 Chip is supported
|-
| x || Seatalk-NMEA0183 Konverter
| || for all devices on the SeaTalk-1-Bus, should have galvanic
|-
| x || RS-232-Buchse
| 1 € || one for each device
|}

<gallery>
File:TP-LINK TL-MR3020 LAN-connector.jpg|TP-LINK TL-MR3020
File:Sanwa supply USB-HUB217BK.jpg|USB 4-port Hub
File:RS-232 to USB Serial Adapter.jpg|RS-232 to USB Adapter
File:RS-232.jpeg|RS-232 female
</gallery>

== Data sources on the boat ==
# GPS-Receiver with NMEA0183-Data at 4800 Baud
# AIS-Receiver with VDM Data at 38400 Baud
# Raymarine-Seatalk-Convetre from Gadgetpool or another Seatalk NMEA-Conveter.

These data-streams are mixed together

== Output ==
# as a TCP-IP-Data-stream via WIFI or Ethernet
# as a textfile on the usb-memory-stick.
The data-stream may be read with an android-app or a Windows 8 app and displayed

Caution: The MR3020 will be flashed with a new software. You will loose all waranty.
During the flash process the power must not be interrupted.
== Configuration of the hardware ==

=== For Beginners ===
* Contact Victor . Mail: <nowiki>vklogger at arcor.de</nowiki>
* Buy the described parts (Box und USB-Menory-Stick) und assure that the version of the hardware is: Version TL-MR3020 Ver. 1.7.
* Send the TP-Link and the USB-Stick to Victor, add 5 € for the sending back.
Victor will configure both and send it back within two weeks.

Anschrift: <pre><nowiki>vklogger at arcor.de</nowiki></pre>

=== For Eperts ===

==== Basic Idea ====
The basic idea is to replace the router software by router software from openWRT that is based on linux.
A web based configuration interface may be used to configure the router.
As the router has one usb port you will need a hub in order to attach an USB stick to have some storage space for the recorded data files and for a overlay root file system that may store openWRT packages you'll need.
The button available on the router is used to start and stop the logging process.

==== Cook Book ====
You need the file factory.bin and the folder gpsdToolsAR77xx.
Please contact "vklogger at arcor.de", you will get it per mail.

This tutorial assumes that you have a home-network with dsl. The local subnet should have the ip-range 192.168.1.xxx. The new flashed router will have the ip 192.168.1.1. You can change to another static adress for the router later.
You need some linux-basics and a running linux-machine.
There are three critical points:
: 1. the flashing must not broken
: 2. the new flashed box must be reached in the local net on 192.168.1.xxx .
: 3. There must be a usb-memory-stick with four linux partitions.

The following steps are necessary:

; prepare the usb-memory-stick:

: 1. copy the folder gpsdToolsAR77xx to a running linux-machine, within the folder is a directory tree we use later
: 2. you have to partioning the usb-stick and format with ext3
: 3. Create four partitions:
::{| class="wikitable"
! Partition || size || for || format with
|-
| part1 || 1 GB || copy of the os || ext3
|-
| part2 || 100 MB || swap || linuxSwap
|-
| part3 || || scripts and log-Data || ext3
|-
| part4 || || || ext3
|}
: 4. Format in this way: part1 with ext3, part2 with linuxSwap, part3 with ext3, part4 with ext3
: 5. Copy the data from gpsdToolsAR77xx to the partition part3.
: 6. you may throw out the stick from the linux-machine.
: We only need part3 , we prepare the stick for further use.

; make the box

: 1. Assume that the "factory.bin" is on the PC.
: 2. Connect PC and the routerbox direct with the short white network cable provided with the box.
:: power up the box. The box starts up and gives the pc a ip-adresse.
: 3. Use the browser with:
:: <pre> http://192.169.1.254</pre>
:: you will see the original webinterface of the router.
: 4. Now you make a firmaware update, use as the new firmware factory.bin from 1.
: 5. It takes about two minutes to flash, the the router reboots. This is critical, wait.
: 6. The baisis-ip of the Software has changed to 192.168.1.1. Use the browser:
:: <pre><nowiki>http://192.168.1.1</nowiki></pre>
:: you will see the gui LUCI from OpenWrt.
:: "go to password configuration" and click login, the change the password.

: 7. if you see the gui from openwrt, the box is configured in the basis.
: 8. Connect via ssh(putty) to the box, check for the password.
: 9. I assume that your local network has 192.168.1.xxx, and you local router has adress 192.168.1.251 hat.
:: First we change the configuration in the box, the box must use you local router as the gateway and provider for the dns .
:: We will disable DHCP in the new box,
:: This is critical, you will not be able to access the box, it will be bricked.
:: Here you can choose another basis adress for the router.
:: In LUCI --> Network-->Interfaces-->LAN-->Edit :
:: IP4 gateway:set it to 192.168.1.251, Use custom DNS servers : 192.168.1.251, Disable DHCP
:: please check twice, then Save&Apply, check again.

: 10. Connect the Box to your home router and make a reboot of the box.
: 11. do a http://192.168.1.1 in the browser eingeben, do we have LUCI LUCI ??, we finished the critical part.
: 12. connect again with ssh (putty) and login as root, this is a good second controll-window, do a "dmesg" you will see the kernel messages.
:: we continue with the gui, but you can also do everything from the root-console.
: 13. Test the internet-connection: Network-->Diagnostics-->Ping, if successfull we go further.
: 14. install software packages:System-->Software,
:: at the begiining about 81% are free, we will have only few space, please install only the necessary things.
:: Click Update lists.
: 15. choose "availabe packages" we install first the support for the USB-Stick
:: 15.1 k : choose "kmod-usb-storage" and install , 72% free
:: 15.2 plugin the USB-Stick with the 4 Linuxpartitions and issue a dmesg on the console: ... sda: sda1 sda2 sda3 sda4
:: 15.3 see k: choose "kmod-fs-ext3"4 and install, 54 % free
::15.4 use the console: /mnt then cd /mnt
::15.5 mkdir sd1, mkdir sd3, test with ls
:: 15.6 mount -t ext3 /dev/sda1 /mnt/sd1 and mout -t ext3 /dev/sda3 /mnt/sd3, test with dmesg
:: 15.7 change to /mnt/sd3: cd /sd3, now you should see the directories on the stick
: 16. we install the packet gpsd using LUCI: see g: gpsd install, 30% free
: 17. we install the driver for USB-RS232-converter
:: 17.1 install: k-mod-usb-serial 30%
:: 17.2 install: k-mod-usb-serial-ftdi 27%
: 18. we change to /mnt and unmount the stick: umount /mnt/sd3
: 19. plug in the 4-port-hub and a FTDI-Converter, do a "dmesg",
:: there should be an entry with " usb 1-1.4: FTDI USB Serial Device converter now attached to ttyUSB0", you can also read it in Status-->System-log.
: 20. we test the gpsd
:: 20.1. LUCI-->System -->Startup : click "gpsd Start", read the System log you should find "user.notice.gpsd Starting.." , you can ignore the IPv6-message.
:: 20.2 make a "pgrep gpsd" on the console, if the gpsd is running you get a process number.
: 21. install the gps-Client Paket, now the flash memory get low: System-Software, we have 10% left.
: 22. test gpspipe on the console
:: <pre> gpspipe -h </pre>
:: if no error try
:: <pre> gpspipe -r </pre>
:: the gpsd gives you an information about the connected devices.
:: if there are nmea-data , the data will be displayed. Wait if you do not see further data. gpsd will explore the right communication setting for you. If you have 38400 baud data, this may take 2 minutes.

Now you have the basis running.

; Extensions

: 1. configure the WPS-Button, a log-file will be written to /mnt/sd3/nmea_data/ .
:: mount -t ext3 /dev/sda3 mnt/sd3
:: install the scripts und configuration for gpsd and LUCI :
:: first for the gpsd and the strat of gpspipe by pressing the WPS-button on the Router
: 2.from the root-prompt: cd /mnt/sd3/installer , then ls. You will see some scripts with self-explaining names.
:: These scripts copy scripts from the directory-structure on the stick to the right places in the flash.
:: 2.1 set "option globally" . With this you can access gpsd not only form local host but from a Tablet or another PC
::: configure gpsd that several converters are possible:
::: <pre> ash replace_gpsd_scripts </pre>
:: 2.2 configure WPS-Button:
::: <pre>ash create_50_wps </pre>
::: if the WPS-Button is pressed , gpspipe logs the NMEA-Data, check in the System-log and search in /mnt/sd3/nmea_data for the last log-file.
::: <pre>tail -f gpsd_nmeaxx.log</pre>
:: 2.3 a second press on the WPS-Button terminates the logging, controll in syslog.
: 3. Configure the gpsd-gui in LUCI , ther will be a item in the Network-gui .
:: 3.1 ash install_model_luci_gpsd_gui
:: 3.2 ash install_controller_luci_gpsd_gui
:: 3.3 gpsd is now able to get data from several converters:LUCI--> System-->Network--> gps devices.

Now we have 10% des Flash free. If you want support for a 3G-Modem you should delete the not used programms from the gps-client Packet. They are in /usr/bin. you can delete cgps, gpsctrl, gpsdecode, gpsmon and lcdgps.

: 4. Configuration of a 3-G Modem

:: see dazu http://wiki.openwrt.org/doc/recipes/3gdongle
:: to be installed:
::: kmod-usb-serial-option,
::: kmod-usb-serial-wwan,
::: luci-proto-3g

Now you can configure in luci-Network-interfaces a new Interface.

::Name: 3g
::Protocoll: UMTS, then submit
Now set Modem-Device, Servic Servicetype, APN, Username and Password.
Watch the ttyUSB- /dev/ttyUSBx, if the stick is plugged in, he searches for a new interface typically ttyUSB2 und ttyUSB3. You can read it in the system log.We use the first inteface. If you get a messsage like "link is not 8-Bit clean" you shouls check the authetication. Try the other interface.

Parameter für e-plus:

::Modem device: aus der Auswahlliste ttyUSBx
::Service Type : UMTS/GPRS
::APN: internet.eplus.de
::username: eplus
::password: eplus

This configuration was tested with a Huawei E160.

= Troubleshooting =
* Device data missing: It is advisable to attach and power all the serial devices before powering the router itself.
* Wrong baud rate: The linux kernel tries to detect the correct baud rate. However since serial to usb converters may be in place in may fail to do so reliably. Solution: You may install stty from openWRT and set baud rates by calling stty -F /dev/tty<YourDevice> 4800. You may do this in a start script such as /etc/init.d/gpsd in order to set it correctly.

OpenSeaMap-dev:HW-logger/Victor.en

2013-05-12T13:24:45Z

Cleanerx:

{|border="0" cellpadding="6" cellspacing="0" width="100%"
!style="background:#E3E3E3;" | [[OpenSeaMap-dev:HW-logger/Victor|Deutsch]]
!style="background:#E3E3E3;" | [[OpenSeaMap-dev:HW-logger/Victor.en|English]]
!style="background:#E3E3E3; width:100%;" |
|}

== NMEA-0183 Logger ==
; Safety issue:
Connecting NMEA0183 devices to a an RS232-USB-Converter may cause problems. As we use the converter only for reading it may run without further problems.

; Functions
* Collects data from serial devices GPS, AIS, Plotter, Sounder with NMEA-0183 can be connected via a RS232-USB-Converter. Several devices (up to 4) may be plugged in an 4-Port USB-Hub. Sounder with seatalk-1 may be connected via a Seatalk-NMEA-Converter.
* logs NMEA-Data to an USB-Memory-Stick, starts and stops by pressing a button
* has an build-in Wifi-access point and make the nmne-data available on a tablet or a phone
* nmea-dat are available via LAN/Ethernet as an TCP-IP-Stream.
* UMTS-Connection to the internet with an additional 3G-Stick All crew members may have access to the internet with theit tablet or smartphone in the habour.

== Hardware ==
{| class="wikitable"
! Nr || Device || Price || Remarks
|-
| 1 || [http://www.amazon.de/TP-Link-TL-MR3020-Wireless-LAN-frustfreie-Verpackung/dp/B00634PLTW TP-Link MR3020]
| 30-35 € || Das device must be flashed and configured with a new software.
|-
| 1 || 4-Port USB-Hub
| 7 € ||
|-
| 1 || 4GB USB-Memory-Stick
| 3 € || with 4 Unix partitions und Unix-ext3-File-System
|-
| x || Seriell-USB-Converter
| 10 € || one for each nmea-device needed Attention: only the FTDI and the PL2303 Chip is supported
|-
| x || Seatalk-NMEA0183 Konverter
| || for all devices on the SeaTalk-1-Bus, should have galvanic
|-
| x || RS-232-Buchse
| 1 € || one for each device
|}

<gallery>
File:TP-LINK TL-MR3020 LAN-connector.jpg|TP-LINK TL-MR3020
File:Sanwa supply USB-HUB217BK.jpg|USB 4-port Hub
File:RS-232 to USB Serial Adapter.jpg|RS-232 to USB Adapter
File:RS-232.jpeg|RS-232 female
</gallery>

== Data sources on the boat ==
# GPS-Receiver with NMEA0183-Data at 4800 Baud
# AIS-Receiver with VDM Data at 38400 Baud
# Raymarine-Seatalk-Convetre from Gadgetpool or another Seatalk NMEA-Conveter.

These data-streams are mixed together

== Output ==
# as a TCP-IP-Data-stream via WIFI or Ethernet
# as a textfile on the usb-memory-stick.
The data-stream may be read with an android-app or a Windows 8 app and displayed

Caution: The MR3020 will be flashed with a new software. You will loose all waranty.
During the flash process the power must not be interrupted.
== Configuration of the hardware ==

=== For Beginners ===
* Contact Victor . Mail: <nowiki>vklogger at arcor.de</nowiki>
* Buy the described parts (Box und USB-Menory-Stick) und assure that the version of the hardware is: Version TL-MR3020 Ver. 1.7.
* Send the TP-Link and the USB-Stick to Victor, add 5 € for the sending back.
Victor will configure both and send it back within two weeks.

Anschrift: <pre><nowiki>vklogger at arcor.de</nowiki></pre>

=== For Eperts ===

==== Basic Idea ====
The basic idea is to replace the router software by router software from openWRT that is based on linux.
A web based configuration interface may be used to configure the router.
As the router has one usb port you will need a hub in order to attach an USB stick to have some storage space for the recorded data files and for a overlay root file system that may store openWRT packages you'll need.
The button available on the router is used to start and stop the logging process.

==== Cook Book ====
You need the file factory.bin and the folder gpsdToolsAR77xx.
Please contact "vklogger at arcor.de", you will get it per mail.

This tutorial assumes that you have a home-network with dsl. The local subnet should have the ip-range 192.168.1.xxx. The new flashed router will have the ip 192.168.1.1. You can change to another static adress for the router later.
You need some linux-basics and a running linux-machine.
There are three critical points:
: 1. the flashing must not broken
: 2. the new flashed box must be reached in the local net on 192.168.1.xxx .
: 3. There must be a usb-memory-stick with four linux partitions.

The following steps are necessary:

; prepare the usb-memory-stick:

: 1. copy the folder gpsdToolsAR77xx to a running linux-machine, within the folder is a directory tree we use later
: 2. you have to partioning the usb-stick and format with ext3
: 3. Create four partitions:
::{| class="wikitable"
! Partition || size || for || format with
|-
| part1 || 1 GB || copy of the os || ext3
|-
| part2 || 100 MB || swap || linuxSwap
|-
| part3 || || scripts and log-Data || ext3
|-
| part4 || || || ext3
|}
: 4. Format in this way: part1 with ext3, part2 with linuxSwap, part3 with ext3, part4 with ext3
: 5. Copy the data from gpsdToolsAR77xx to the partition part3.
: 6. you may throw out the stick from the linux-machine.
: We only need part3 , we prepare the stick for further use.

; make the box

: 1. Assume that the "factory.bin" is on the PC.
: 2. Connect PC and the routerbox direct with the short white network cable provided with the box.
:: power up the box. The box starts up and gives the pc a ip-adresse.
: 3. Use the browser with:
:: <pre> http://192.169.1.254</pre>
:: you will see the original webinterface of the router.
: 4. Now you make a firmaware update, use as the new firmware factory.bin from 1.
: 5. It takes about two minutes to flash, the the router reboots. This is critical, wait.
: 6. The baisis-ip of the Software has changed to 192.168.1.1. Use the browser:
:: <pre><nowiki>http://192.168.1.1</nowiki></pre>
:: you will see the gui LUCI from OpenWrt.
:: "go to password configuration" and click login, the change the password.

: 7. if you see the gui from openwrt, the box is configured in the basis.
: 8. Connect via ssh(putty) to the box, check for the password.
: 9. I assume that your local network has 192.168.1.xxx, and you local router has adress 192.168.1.251 hat.
:: First we change the configuration in the box, the box must use you local router as the gateway and provider for the dns .
:: We will disable DHCP in the new box,
:: This is critical, you will not be able to access the box, it will be bricked.
:: Here you can choose another basis adress for the router.
:: In LUCI --> Network-->Interfaces-->LAN-->Edit :
:: IP4 gateway:set it to 192.168.1.251, Use custom DNS servers : 192.168.1.251, Disable DHCP
:: please check twice, then Save&Apply, check again.

: 10. Connect the Box to your home router and make a reboot of the box.
: 11. do a http://192.168.1.1 in the browser eingeben, do we have LUCI LUCI ??, we finished the critical part.
: 12. connect again with ssh (putty) and login as root, this is a good second controll-window, do a "dmesg" you will see the kernel messages.
:: we continue with the gui, but you can also do everything from the root-console.
: 13. Test the internet-connection: Network-->Diagnostics-->Ping, if successfull we go further.
: 14. install software packages:System-->Software,
:: at the begiining about 81% are free, we will have only few space, please install only the necessary things.
:: Click Update lists.
: 15. choose "availabe packages" we install first the support for the USB-Stick
:: 15.1 k : choose "kmod-usb-storage" and install , 72% free
:: 15.2 plugin the USB-Stick with the 4 Linuxpartitions and issue a dmesg on the console: ... sda: sda1 sda2 sda3 sda4
:: 15.3 see k: choose "kmod-fs-ext3"4 and install, 54 % free
::15.4 use the console: /mnt then cd /mnt
::15.5 mkdir sd1, mkdir sd3, test with ls
:: 15.6 mount -t ext3 /dev/sda1 /mnt/sd1 and mout -t ext3 /dev/sda3 /mnt/sd3, test with dmesg
:: 15.7 change to /mnt/sd3: cd /sd3, now you should see the directories on the stick
: 16. we install the packet gpsd using LUCI: see g: gpsd install, 30% free
: 17. we install the driver for USB-RS232-converter
:: 17.1 install: k-mod-usb-serial 30%
:: 17.2 install: k-mod-usb-serial-ftdi 27%
: 18. we change to /mnt and unmount the stick: umount /mnt/sd3
: 19. plug in the 4-port-hub and a FTDI-Converter, do a "dmesg",
:: there should be an entry with " usb 1-1.4: FTDI USB Serial Device converter now attached to ttyUSB0", you can also read it in Status-->System-log.
: 20. we test the gpsd
:: 20.1. LUCI-->System -->Startup : click "gpsd Start", read the System log you should find "user.notice.gpsd Starting.." , you can ignore the IPv6-message.
:: 20.2 make a "pgrep gpsd" on the console, if the gpsd is running you get a process number.
: 21. install the gps-Client Paket, now the flash memory get low: System-Software, we have 10% left.
: 22. test gpspipe on the console
:: <pre> gpspipe -h </pre>
:: if no error try
:: <pre> gpspipe -r </pre>
:: the gpsd gives you an information about the connected devices.
:: if there are nmea-data , the data will be displayed. Wait if you do not see further data. gpsd will explore the right communication setting for you. If you have 38400 baud data, this may take 2 minutes.

Now you have the basis running.

; Extensions

: 1. configure the WPS-Button, a log-file will be written to /mnt/sd3/nmea_data/ .
:: mount -t ext3 /dev/sda3 mnt/sd3
:: install the scripts und configuration for gpsd and LUCI :
:: first for the gpsd and the strat of gpspipe by pressing the WPS-button on the Router
: 2.from the root-prompt: cd /mnt/sd3/installer , then ls. You will see some scripts with self-explaining names.
:: These scripts copy scripts from the directory-structure on the stick to the right places in the flash.
:: 2.1 set "option globally" . With this you can access gpsd not only form local host but from a Tablet or another PC
::: configure gpsd that several converters are possible:
::: <pre> ash replace_gpsd_scripts </pre>
:: 2.2 configure WPS-Button:
::: <pre>ash create_50_wps </pre>
::: if the WPS-Button is pressed , gpspipe logs the NMEA-Data, check in the System-log and search in /mnt/sd3/nmea_data for the last log-file.
::: <pre>tail -f gpsd_nmeaxx.log</pre>
:: 2.3 a second press on the WPS-Button terminates the logging, controll in syslog.
: 3. Configure the gpsd-gui in LUCI , ther will be a item in the Network-gui .
:: 3.1 ash install_model_luci_gpsd_gui
:: 3.2 ash install_controller_luci_gpsd_gui
:: 3.3 gpsd is now able to get data from several converters:LUCI--> System-->Network--> gps devices.

Now we have 10% des Flash free. If you want support for a 3G-Modem you should delete the not used programms from the gps-client Packet. They are in /usr/bin. you can delete cgps, gpsctrl, gpsdecode, gpsmon and lcdgps.

: 4. Configuration of a 3-G Modem

:: see dazu http://wiki.openwrt.org/doc/recipes/3gdongle
:: to be installed:
::: kmod-usb-serial-option,
::: kmod-usb-serial-wwan,
::: luci-proto-3g

Now you can configure in luci-Network-interfaces a new Interface.

::Name: 3g
::Protocoll: UMTS, then submit
Now set Modem-Device, Servic Servicetype, APN, Username and Password.
Watch the ttyUSB- /dev/ttyUSBx, if the stick is plugged in, he searches for a new interface typically ttyUSB2 und ttyUSB3. You can read it in the system log.We use the first inteface. If you get a messsage like "link is not 8-Bit clean" you shouls check the authetication. Try the other interface.

Parameter für e-plus:

::Modem device: aus der Auswahlliste ttyUSBx
::Service Type : UMTS/GPRS
::APN: internet.eplus.de
::username: eplus
::password: eplus

This configuration was tested with a Huawei E160.

= Troubleshooting =
Device data missing: It is advisable to attach and power all the serial devices before powering the router itself.
Wrong baud rate: The linux kernel tries to detect the correct baud rate. However since serial to usb converters may be in place in may fail to do so reliably. You may install stty from openWRT and set baud rates by calling stty -F /dev/tty<YourDevice> 4800. You may do this in a start script such as /etc/init.d/gpsd in order to set it correctly.

OpenSeaMap-dev:.SON (Humminbird)

2013-05-02T07:46:50Z

Cleanerx: /* Basic Structure */

SON is a file format that is used by Humminbird instruments. It structure allows to store data from several sonar sensors to allow for storing so called side scan data. Side scans are continous depth measurments not only below the ship but to some extent to the side of the ships.

= Basic Structure =

Byte order of data is most significant byte is the first byte in the stream (Big Endian).

== DAT File ==
For each recording a numbered file is created starting with R00001.DAT. That files stores general information such as time and date of recording and initial position. A corresponding directory R00001 holds a list of files that contain sonar sensor recordings. For earch sensor an index file and a data file is created. A multiple sensor setup may look like having a 50kHz, a 200kHz and two 455kHz side scan sensors for each side of the ship. This will result in four sensor files and four index files totalling to 9 files including the dat file.

<pre>
8 bytes : unknown
int32 : seconds (NOT milliseconds) since January 1, 1970, 00:00:00 GMT.
int32 : longitude (projected)
int32 : latitude (projected)
bytes[6] : Name
bytes[4] : Extension
</pre>

== Index Files ==
Index files contain allow to identify headers and subsequent data in the son file

typedef struct indexstructure
{
int32_t globalRecordNumber; // record number
int32_t positionInStream; // start of header in other file
}

== SON Files ==
Having analyzed the index structure one can access the positions in the file directly.
The header consists of a sequence of control characters that indicate the following data (indicated as signed byte value).

=== Header ===
<pre>
-128 : int32 // global record number
-127 : int32 // recording time since start
-126 : int32 // longitude (projected)
-125 : int32 // latitude (projected)
-124 : int16 : gps enabled (0/1); int16 : gps heading to be divided by 10.0
-123 : 2 unused bytes; int16 gps speed to be divided by 10.0
-122 : 4 bytes // unknown
-121 : int32 : depth in decimeter
-110 : int32 : sensor frequency in Hz (e.g. 85000Hz)
-107 : int32 // unknown
-96 : int32 // data length for this data block following the header

80 : byte : Beam id (0 for first beam, 1 for second beam, ... encodes the same id as the file name)
81 : byte // unknown
83 : byte // unknown
84 : byte // unknown
86 : byte // unknown
87 : byte // unknown
33 : header termination
</pre>

Example Recording time since start with 1 second in a stream
[-127, 0 , 0 , 0, 1]

=== Data ===
Yet to be discovered or documented

OpenSeaMap-dev:.SON (Humminbird)

2013-05-02T06:37:46Z

Cleanerx:

SON is a file format that is used by Humminbird instruments. It structure allows to store data from several sonar sensors to allow for storing so called side scan data. Side scans are continous depth measurments not only below the ship but to some extent to the side of the ships.

= Basic Structure =

Byte order of data is most significant byte is the first byte in the stream.

== DAT File ==
For each recording a numbered file is created starting with R00001.DAT. That files stores general information such as time and date of recording and initial position. A corresponding directory R00001 holds a list of files that contain sonar sensor recordings. For earch sensor an index file and a data file is created. A multiple sensor setup may look like having a 50kHz, a 200kHz and two 455kHz side scan sensors for each side of the ship. This will result in four sensor files and four index files totalling to 9 files including the dat file.

<pre>
8 bytes : unknown
int32 : seconds (NOT milliseconds) since January 1, 1970, 00:00:00 GMT.
int32 : longitude (projected)
int32 : latitude (projected)
bytes[6] : Name
bytes[4] : Extension
</pre>

== Index Files ==
Index files contain allow to identify headers and subsequent data in the son file

typedef struct indexstructure
{
int32_t globalRecordNumber; // record number
int32_t positionInStream; // start of header in other file
}

== SON Files ==
Having analyzed the index structure one can access the positions in the file directly.
The header consists of a sequence of control characters that indicate the following data (indicated as signed byte value).

=== Header ===
<pre>
-128 : int32 // global record number
-127 : int32 // recording time since start
-126 : int32 // longitude (projected)
-125 : int32 // latitude (projected)
-124 : int16 : gps enabled (0/1); int16 : gps heading to be divided by 10.0
-123 : 2 unused bytes; int16 gps speed to be divided by 10.0
-122 : 4 bytes // unknown
-121 : int32 : depth in decimeter
-110 : int32 : sensor frequency in Hz (e.g. 85000Hz)
-107 : int32 // unknown
-96 : int32 // data length for this data block following the header

80 : byte : Beam id (0 for first beam, 1 for second beam, ... encodes the same id as the file name)
81 : byte // unknown
83 : byte // unknown
84 : byte // unknown
86 : byte // unknown
87 : byte // unknown
33 : header termination
</pre>

Example Recording time since start with 1 second in a stream
[-127, 0 , 0 , 0, 1]

=== Data ===
Yet to be discovered or documented

OpenSeaMap-dev:.SON (Humminbird)

2013-05-02T06:37:26Z

Cleanerx:

SON is a file format that is used by Humminbird instruments. It structure allows to store data from several sonar sensors to allow for storing so called side scan data. Side scans are continous depth measurments not only below the ship but to some extent to the side of the ships.

= Basic Structure =

Byte order of data is most significant byte is the first byte in the stream.

== DAT File ==
For each recording a numbered file is created starting with R00001.DAT. That files stores general information such as time and date of recording and initial position. A corresponding directory R00001 holds a list of files that contain sonar sensor recordings. For earch sensor an index file and a data file is created. A multiple sensor setup may look like having a 50kHz, a 200kHz and two 455kHz side scan sensors for each side of the ship. This will result in four sensor files and four index files totalling to 9 files including the dat file.

8 bytes : unknown
int32 : seconds (NOT milliseconds) since January 1, 1970, 00:00:00 GMT.
int32 : longitude (projected)
int32 : latitude (projected)
bytes[6] : Name
bytes[4] : Extension

== Index Files ==
Index files contain allow to identify headers and subsequent data in the son file

typedef struct indexstructure
{
int32_t globalRecordNumber; // record number
int32_t positionInStream; // start of header in other file
}

== SON Files ==
Having analyzed the index structure one can access the positions in the file directly.
The header consists of a sequence of control characters that indicate the following data (indicated as signed byte value).

=== Header ===
<pre>
-128 : int32 // global record number
-127 : int32 // recording time since start
-126 : int32 // longitude (projected)
-125 : int32 // latitude (projected)
-124 : int16 : gps enabled (0/1); int16 : gps heading to be divided by 10.0
-123 : 2 unused bytes; int16 gps speed to be divided by 10.0
-122 : 4 bytes // unknown
-121 : int32 : depth in decimeter
-110 : int32 : sensor frequency in Hz (e.g. 85000Hz)
-107 : int32 // unknown
-96 : int32 // data length for this data block following the header

80 : byte : Beam id (0 for first beam, 1 for second beam, ... encodes the same id as the file name)
81 : byte // unknown
83 : byte // unknown
84 : byte // unknown
86 : byte // unknown
87 : byte // unknown
33 : header termination
</pre>

Example Recording time since start with 1 second in a stream
[-127, 0 , 0 , 0, 1]

=== Data ===
Yet to be discovered or documented

OpenSeaMap-dev:.SON (Humminbird)

2013-05-02T06:32:33Z

Cleanerx: /* DAT File */

SON is a file format that is used by Humminbird instruments. It structure allows to store data from several sonar sensors to allow for storing so called side scan data. Side scans are continous depth measurments not only below the ship but to some extent to the side of the ships.

= Basic Structure =

Byte order of data is most significant byte is the first byte in the stream.

== DAT File ==
For each recording a numbered file is created starting with R00001.DAT. That files stores general information such as time and date of recording and initial position. A corresponding directory R00001 holds a list of files that contain sonar sensor recordings. For earch sensor an index file and a data file is created. A multiple sensor setup may look like having a 50kHz, a 200kHz and two 455kHz side scan sensors for each side of the ship. This will result in four sensor files and four index files totalling to 9 files including the dat file.

== Index Files ==
Index files contain allow to identify headers and subsequent data in the son file

typedef struct indexstructure
{
int32_t globalRecordNumber; // record number
int32_t positionInStream; // start of header in other file
}

== SON Files ==
Having analyzed the index structure one can access the positions in the file directly.
The header consists of a sequence of control characters that indicate the following data (indicated as signed byte value).

=== Header ===
<pre>
-128 : int32 // global record number
-127 : int32 // recording time since start
-126 : int32 // longitude (projected)
-125 : int32 // latitude (projected)
-124 : int16 : gps enabled (0/1); int16 : gps heading to be divided by 10.0
-123 : 2 unused bytes; int16 gps speed to be divided by 10.0
-122 : 4 bytes // unknown
-121 : int32 : depth in decimeter
-110 : int32 : sensor frequency in Hz (e.g. 85000Hz)
-107 : int32 // unknown
-96 : int32 // data length for this data block following the header

80 : byte : Beam id (0 for first beam, 1 for second beam, ... encodes the same id as the file name)
81 : byte // unknown
83 : byte // unknown
84 : byte // unknown
86 : byte // unknown
87 : byte // unknown
33 : header termination
</pre>

Example Recording time since start with 1 second in a stream
[-127, 0 , 0 , 0, 1]

=== Data ===
Yet to be discovered or documented

OpenSeaMap-dev:.SON (Humminbird)

2013-05-01T20:15:28Z

Cleanerx: /* Header */

SON is a file format that is used by Humminbird instruments. It structure allows to store data from several sonar sensors to allow for storing so called side scan data. Side scans are continous depth measurments not only below the ship but to some extent to the side of the ships.

= Basic Structure =

Byte order of data is most significant byte is the first byte in the stream.

== DAT File ==
For each recording a numbered file is created starting with R00001.DAT. That files stores general information such as time and date of recording and initial position. A corresponding directory R00001 holds a list of files that contain sonar sensor recordings. For earch sensor an index file and a data file is created. A multiple sensor setup may look like having a 50kHz, a 200kHz and two 455kHz side scan sensors for each side of the ship. This will result in four sensor files and four index files totalling to 8 files.

== Index Files ==
Index files contain allow to identify headers and subsequent data in the son file

typedef struct indexstructure
{
int32_t globalRecordNumber; // record number
int32_t positionInStream; // start of header in other file
}

== SON Files ==
Having analyzed the index structure one can access the positions in the file directly.
The header consists of a sequence of control characters that indicate the following data (indicated as signed byte value).

=== Header ===
<pre>
-128 : int32 // global record number
-127 : int32 // recording time since start
-126 : int32 // longitude (projected)
-125 : int32 // latitude (projected)
-124 : int16 : gps enabled (0/1); int16 : gps heading to be divided by 10.0
-123 : 2 unused bytes; int16 gps speed to be divided by 10.0
-122 : 4 bytes // unknown
-121 : int32 : depth in decimeter
-110 : int32 : sensor frequency in Hz (e.g. 85000Hz)
-107 : int32 // unknown
-96 : int32 // data length for this data block following the header

80 : byte : Beam id (0 for first beam, 1 for second beam, ... encodes the same id as the file name)
81 : byte // unknown
83 : byte // unknown
84 : byte // unknown
86 : byte // unknown
87 : byte // unknown
33 : header termination
</pre>

Example Recording time since start with 1 second in a stream
[-127, 0 , 0 , 0, 1]

=== Data ===
Yet to be discovered or documented

OpenSeaMap-dev:.SON (Humminbird)

2013-05-01T20:10:34Z

Cleanerx: Die Seite wurde neu angelegt: „SON is a file format that is used by Humminbird instruments. It structure allows to store data from several sonar sensors to allow for storing so called side s…“

SON is a file format that is used by Humminbird instruments. It structure allows to store data from several sonar sensors to allow for storing so called side scan data. Side scans are continous depth measurments not only below the ship but to some extent to the side of the ships.

= Basic Structure =

Byte order of data is most significant byte is the first byte in the stream.

== DAT File ==
For each recording a numbered file is created starting with R00001.DAT. That files stores general information such as time and date of recording and initial position. A corresponding directory R00001 holds a list of files that contain sonar sensor recordings. For earch sensor an index file and a data file is created. A multiple sensor setup may look like having a 50kHz, a 200kHz and two 455kHz side scan sensors for each side of the ship. This will result in four sensor files and four index files totalling to 8 files.

== Index Files ==
Index files contain allow to identify headers and subsequent data in the son file

typedef struct indexstructure
{
int32_t globalRecordNumber; // record number
int32_t positionInStream; // start of header in other file
}

== SON Files ==
Having analyzed the index structure one can access the positions in the file directly.
The header consists of a sequence of control characters that indicate the following data (indicated as signed byte value).

=== Header ===
<pre>
-128 : int32 // global record number
-127 : int32 // recording time since start
-126 : int32 // longitude (projected)
-125 : int32 // latitude (projected)
-124 : int16 : gps enabled (0/1); int16 : gps heading to be divided by 10.0
-123 : 2 unused bytes; int16 gps speed to be divided by 10.0
-122 : 4 bytes // unknown
-121 : int32 : depth in decimeter
-110 : int32 : sensor frequency in Hz (e.g. 85000Hz)
-107 : int32 // unknown
-96 : int32 // data length for this data block following the header

80 : byte : Beam id (0 for first beam, 1 for second beam, ... encodes the same id as the file name)
81 : byte // unknown
83 : byte // unknown
84 : byte // unknown
86 : byte // unknown
87 : byte // unknown
33 : header termination
</pre>

=== Data ===
Yet to be discovered or documented

OpenSeaMap-dev:Entwicklerwochenende 2013-04

2013-04-13T14:00:37Z

Cleanerx: /* Fahrgemeinschaft */

Planung zum 6. Entwicklerwochenende am '''11.-15. 4. 2013'''

== Anmeldung ==
[mailto:liste12A45q7@gmx.de?subject=5.%20Entwicklerwochenende%20-%20Anmeldung Anmeldung bitte per Mail] oder hier in der Liste:
{| class="wikitable sortable"
! Nr || Do || Fr || Sa || So || Mo || wer || von wo || Übernachtung || class="unsortable" | Bemerkungen
|-
| 1 || x || x || x || x || x || [[Benutzer:Markus|Markus]] || || - ||
|-
| 2 || || || || '''X''' || || Wolfgang Bosch || Wien || - || DGFI
|-
| 3 || || 19:00 || x || x || || Jens Kübler || Karlsruhe || Landgasthof || SW-Logger
|-
| 4 || || x || x || x || || Andreas Merz || Nürnberg || - ||
|-
| 5 || || x || x || x || || Cornelia || Nürnberg || bei Markus ||
|-
| 6 || || x || x || x || || Inger Holndonner || Nürnberg || - || Wassertiefen, Tauchen
|-
| 7 || || x || x || 18:00 || || Victor Klein || Essen || Landgasthof || Android-App, Wassertiefen
|-
| 8 || || 16:00 || x || 12:00 || || Martin Over || Köln || || Wassertiefen, Höhen
|-
| 9 || || || || x || || Martin Dörig || St.Gallen || - || Wassertiefen
|-
| 10 || || || || x || || Leonard Dushi || St.Gallen || - || Wassertiefen
|-
| 11 || || 15:30 || x || x || || Nils Werner || Erlangen || - || Wassertiefen (Raspberry Pi), Git?
|-
| 12 || || || || || || || || ||
|}

== Programm ==
Das Programm werden wir je nach anwesenden Personen, Interessen und Prioritäten gestalten und möglichst hier vorher gemeinsam planen.

Schwerpunkt wir sein:
* Wassertiefenerfassung
* Korrektur der Rohdaten
* HW-Logger

Wolfgang Bosch hilft uns beim Konzept für die Erfassung der Wassertiefen und bei der Korrektur der Rohdaten. Er arbeitet am [http://www.dgfi.badw.de/ deutschen geodätischen Forschungsinstitut (DGFI)] in München, und ist Spezialist für Wellen- und Tidenmodelle. Er wird am '''Sonntag''' seine Arbeit vorstellen.

Und natürlich werden wir auch für alle anderen wichtigen Temen Zeit haben: Visionen, Ideen, Pläne zu Apps, Vektorkarten, Community, Qualität, Server, Tidenrechner, Hafendatenbank, Wassersportwiki, etc, etc.

; Struktur
: Die Idee ist, dass jeder "Maintainer" bzw. jedes Team eines Projektes ein Zeitfenster hat, um die zentralen Fragen mit allen anderen Entwicklern zu diskutieren und Lösungen bzw Lösungswege zu finden.
: Ergebnis soll jeweils eine ToDo-Liste sein.
: Bewährt hat sich beim letzten Mal, das Treffen auch als Hack-Weekend zu gestalten.
: Und natürlich wie immer Zeit für's Kennenlernen und Fachsimpeln!

{| class="wikitable"
! Zeit || Thema || Wer || Bemerkungen
|-
| Do || Core-Dev-Meeting || || open for everybody
|-
| Fr || Pre-Dev-Meeting || || open for everybody
|-
| Fr 19:00 || Abendessen || bei Markus || (bitte anmelden)
|-
| Sa 08:00 || Frühstück || Gäste von Markus || wer mag kann gern dazukommen (bitte anmelden)
|-
| '''Sa 10:00''' || Intro || Markus || Rückblick, Ausblick
|-
| Sa 10:30 || Vorstellungsrunde || alle || je max 5' incl. Kurzvorstellung des Teilprojektes bitte Flipchart mitbringen, oder 1 PPT-Folie (vorab an Markus schicken)
|-
| Sa 12:00 || || ||
|-
| Sa 14:00 || Mittagspause || || "kaltes Buffet"
|-
| Sa 15:00 || || ||
|-
| Sa 17:00 || || ||
|-
| Sa 19:00 || Abendessen || || Landgasthof
|-
| Sa 20:00 || || ||
|-
| So 08:00 || Frühstück || Gäste von Markus || wer mag kann gern dazukommen (bitte anmelden)
|-
| '''So 10:00''' || '''Korrektur der Rohdaten''' Welle, Tide, etc. || Wolfgang Bosch ||
|-
| So 12:00 || || ||
|-
| So 14:00 || || ||
|-
| '''So 16:00''' || Ende des Hauptteils || ||
|-
| So 18:00 || || ||
|-
| So 20:00 || || ||
|-
| So 22:00 || || ||
|-
| Mo 08:00 || Arbeits-Frühstück || || Rückblick, Planung
|-
| Mo 10:00 || || || Umsetzung? (je nachdem wer noch da ist)
|}

== Themen ==
{| class="wikitable"
! Thema || Prio || wer || Bemerkungen
|-
| HW-Logger || || ||
|-
| SW-Logger || || ||
|-
| Datenaufbereitung || || Wolfgang ||
|-
| PR || || Markus ||
|-
| ... || || ||
|}

== Unterkunft ==

; privat bei Markus
: Bei mir können 3..4 Gäste gratis übernachten. Gern bereits ab Donnerstag bzw bis Montag.
:{| class="wikitable"
! wer || Do || Fr || Sa || So
|-
| ... || || || ||
|-
| ... || || || ||
|-
| ... || || || ||
|}

; Landgasthof "Lang"
: 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]
: EZ Ü/F: ab 30 € (25,20 € ohne Frühstück)
: Bahnhofstraße 9, 91245 Simmelsdorf, +49 9155 237, [http://www.landgasthaus-lang.de/ Landgasthof-Lang.de]

; Hotel "Igelwirt"
: 10 Minuten mit dem Auto, [http://www.openstreetmap.org/?mlat=49.5873&mlon=11.3765&zoom=14 Karte]
: EZ Ü/F: ab 57 € (52 € ohne Frühstück )
: Igelweg 6, 91220 Schnaittach-Osternohe, +40 9153 4060, [http://www.igelwirt.de/ Igelwirt.de]

; Gasthof Schuster
: 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]
: EZ Ü/F 33 € (29 € ohne Frühstück)
: Kirchenweg 6, 91220 Hedersdorf, +49 9153 1288

== Verpflegung ==
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...
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?

Getränke und Tee/Kaffee sind im Haus. Ebenso Aufbackbrötchen und Nudeln für alle Fälle.

{| class="wikitable"
! 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
|-
| Markus || X || || || || || || || || || || || || || || Food for all
|-
| Markus || || X || || || || || || || || || || || || || Abendessen bei mir für alle die angemeldet sind
|-
| Markus || || || X || || || X || || || || X || || || || X || Frühstück bei mir für alle die angemeldet sind
|-
| Martin || || || || || || || || || || || X || || || || Chicks for free - wer lieber Pizza hat, soll sich melden
|-
| Landgasthof || || || || || X || || || || X || || || || X || ||
|-
| ... || || || || || || || || || || || || || || ||
|}

{| class="wikitable"
! 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
|-
| Markus || X || X || X || X || X || X || X || X || X || X || X || X ||
|-
| Leo || || || || || || || || || X || || || ||
|-
| Martin || || || || || || || || || X || || || ||
|-
| ... || || || || || || || || || || || || ||
|}

== Fahrgemeinschaft ==
; Suche
{| class="wikitable"
! wer || ab wo || Abfahrt || Plätze || Bemerkungen
huhu
|-
| .. || || || ||
|}

; Biete
{| class="wikitable"
! wer || ab wo || Abfahrt || Plätze || Bemerkungen
|-
| .. || || || ||
|}

Bitte nehmt direkt miteinander Kontakt auf.

== Zusammenfassung / ToDo ==
* [[OpenSeaMap-dev:6._Entwicklerwochenende/Bericht | Bericht / ToDo]]
* [[OpenSeaMap-dev:5._Entwicklerwochenende/Bericht | Bericht / ToDo vom letzten Entwicklertreffen]]

OpenSeaMap-dev:En:Depth Data

2013-03-03T16:58:26Z

Cleanerx: /* Upload Process */

This Page describes the necessary efforts to retrieve and analyze depth data as well as create renderings from it

= Data Aquisition =
Depth data can be retrieved from public domain sources or from crowd sourced data.

== GEBCO ==
DIe Daten sind gerendert und stehen als Layer zur Verfügung:
{| class="wikitable"
! Zoom || Inhalt
|-
| 0..10 || Blaustufen und Schattierung
|-
| 11..18 || beschriftete Tiefenlinien, Blaustufen und Schattierung
|}

Noch zu lösende Probleme:
* der GEBCO-Layer erzeugt einen milchigen Schleier über der Basiskarte
* Tiefenlinien sind ab z=14 etwas grob (also ab da, wo dann die Flachwassertiefen beginnen) [http://dev.openseamap.org/website/map/#?zoom=14&lat=36.03097&lon=-5.49153&layers=BFTFTTTFFFF0]
* Überschneidungen von 100m-Linie und Küstenlinie [http://dev.openseamap.org/website/map/#?zoom=15&lat=36.00318&lon=-5.60819&layers=BFTFTTTFFFF0]
* Steilküsten (Cuba) [http://dev.openseamap.org/website/map/#?zoom=14&lat=19.94808&lon=-76.04289&layers=BFTFTTTFFFF0]

== Crowd Sourced Data ==
Crowd sourced data may be gathered by YOU. There are two options in development. A hardware and a software option.

=== Hardware logger ===
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.
That data may then be uploaded by plugging the SD card to a normal computer with internet connection for upload.
The main goal is to support NMEA 0183 data with options for NMEA 2000.

=== Software logger ===
A Software logger is in development and [http://seesea.sourceforge.net/datalogger/index.html can be downloaded here].

It currently supports:
: Bluetooth
: Serial ports
: Internet Protocol (IP)
It processes NMEA 0183 and AIS data.

For vendor specific protocols such as SeaTalk 1 you have to use a [[De:NMEA-Logger_anschliessen|converter]] to NMEA 0183 data.

NMEA 2000 support is only available if data is transcoded to NMEA 0183 by a converter.

=== Upload Process ===
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].
The system is currently being tested.

[[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|You'll find further information here]].

= Data Preprocessing =

== Data Condition ==
Raw data is usually erronous and must be corrected

=== Internal data problems ===
Depth data may be affected by electrical conditions and software implementations
* Data is incomplete and fail their checksum (bus errors from physical transmissions errors)
* Data is retrived out of sequence
* Data is erronous sensor data
** Approximate correctable data i.e. invalid GPS position that may be interpolated
** Uncorrectable data i.e. failed log sensor that shows slow speeds
* Data resolution is low i.e. for energy saving purposes GPS position is updated every 10 seconds instead of every second
* Sensor data is actively miscalibrated i.e. charter companies add additional draft to the sensor depth for safety reasons

=== External data problems ===
Depth data may be affected by different environmental circumstances
* The water temperature affects the ultrasound echo. An inhomogen water temperature yields unwanted echos
* The seabed affects the ultrasound echo
* The seastate affects the measurement. There even may be waves when there is no wind.
* Waves may affect the roll of the measuring vessel resulting in steep measurements that are invalid.
* The sounder sensor is not the position of the GPS antenna. A position offset including heading must be incorporated.
* 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.

== Data Condition Examples / Showcases ==

=== Missing measurments (Position) ===
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.
One can see from the distribtion that the sensor is updated every second but many measurements are one or more seconds late.
21 seconds with no position update may result in an instability of the subsequent filter.
<pre>
MeasuredPosition3D
GP
0 :4285
1000 :11295
2000 :5056
3000 :2134
4000 :1135
5000 :315
6000 :154
7000 :46
8000 :36
9000 :16
10000 :12
11000 :3
12000 :4
13000 :1
14000 :7
15000 :3
16000 :1
21000 :1
</pre>

=== Missing measurments (Position) with erronous clock ===
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)
<pre>
MeasuredPosition3D
II
-21340000 :1
-13194000 :1
-7998000 :1
-2674000 :1
-2434000 :1
-2402000 :1
-2030000 :1
-1926000 :1
-1894000 :1
-1806000 :1
-1480000 :1
-1430000 :1
-1382000 :1
-1114000 :1
-814000 :1
-634000 :1
-590000 :1
-546000 :1
-470000 :1
-290000 :1
-230000 :1
-198000 :1
-110000 :1
-94000 :2
0 :182200
5000 :1
10000 :20230
15000 :1
20000 :84
50000 :1
114000 :2
130000 :2
218000 :1
250000 :1
310000 :1
490000 :1
566000 :1
610000 :1
654000 :1
834000 :1
1134000 :1
1402000 :1
1450000 :1</pre>

== Solution Proposal ==

=== Outline ===
The ship is influenced by the outlined environment which can be observed. Naturally what is observed is not the state of the
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.

=== Details ===
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.

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.

Todo:
* Construct ship system model with at least the position state and probably its course and speed or even more (depth)
* Estimate the system variance (This is a hard one, proposals welcome)
* Construct the measurement model according to the data available (GPS, Log)
* Estimate the measurement noise according to specifc sensors (DPGS is more accurate than GPS)

The estimation with the position and depth can be retrieved and stored in a database.

Pitfalls:
* If the system noise is badly chosen the estimation of the system state does not converge to the true state / measurement.
* If the system is very detailed the system variance can be reduced. The required cpu time for processing increases

Benefits:
* Having the best estimation of the true position even if measurements are noisy
* Easy and effective algorithmic processing

== Analysis ==

=== Data Sets ===
Currently two test data sets are available recorded during trips from Mallorca and the Baltic Sea.
In terms of data quality the Mallorca data shows many challenges.
* The minimum recommended sentences from NMEA showed up with false date and time readings while having correct (!!!) message checksums.
* The log on the ship was defective and delivered no readings from time to time.
* The same holds true for the water temperature.
* The GPS positions relatively imprecise because some last decimal digits are missing in the recordings.
* The GPS positions are updated every 10 seconds while other sensor readings update almost every second.
* The GPS position are sometimes way off due to false readings

The Baltic Sea data set is a little bit better
* Only a single day is available
* GPS positions are updated every second

One problem with the data is that there is time available when sensor readings were recorded. This yields problems to the filter algorithm.

=== Filter Algorithm ===
At first the Extended Kalman Filter is being analyzed. Using an apache implementation with the available data the filter quickly throw an exception that
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.
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
we may consider that for the future.

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
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.

== Results ==
A prototype implementation is shown in the following screenshots. An Extended Kalman Filter is being used. It has the position
and the current bearing and velocity as system state. The input is the measurement of these four observables. The system function is
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.
The initial state is taken from the first measurement for convergence reasons.

The following gallery shows the results.
* You can see the bad position resolution and an outlier in the first screenshot.
* The second shows the same data overlaid with the applied filter. The outlier is gone and the resolution has improved.
* The third screenshot shows data from a different GPS sensor with more precision (not DGPS) versus the filtered data.

This of course is just a preliminary test and many setups need to be considered to make it work for most datasets.

<gallery>
UnfilteredNMEA.png | Unfiltered GPS data
FilteredNMEAVsOriginal.png | Unfiltered GPS data and Filtered GPS data
PreciseGPSvsFilter.png | Another precise GPS vs Filtered GPS data
</gallery>

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].
This way positional inaccuracies may be added to the overall depth measurement inaccuracy.

== Quality rating ==

Each record (time, positon, depth) should become a quality rating.

=== Points ===

Derived from the Fibonacci series.

{| class="wikitable"
! Point || Description
|-
| 1 || extra small improvement
|-
| 2 || small improvement
|-
| 3 || medium improvement
|-
| 5 || large improvement
|-
| 8 || extra large improvement
|}

=== Factors ===

{| class="wikitable"
! style="width:15%" | Name
! style="width:17%" | Factor
! style="width:68%" | Description
|-
| depth offset || 8 (extra large) || The difference between the depth measured by the echo sounder and the depth (waterline) measured by hand.
|-
| device distance || 3 (medium) || The distance between gps antenna and echo sounder (lengthwise and crosswise).
|-
| SBAS || 3 (medium) || Satellite based augmentation system (WAAS, EGNOS, MSAS) which allows to correct the gps position.
|-
| 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.
|}

= Depth Rendering =

= Siehe auch =
* [[De:Bordnetz|Bordnetz]]
* [[De:NMEA-Logger_anschliessen|NMEA-Logger_anschliessen]]
* [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]
* [http://users.isr.ist.utl.pt/~pedro/publications/CAMS10.pdf A Multiple Model Adaptive Wave Filter for Dynamic Ship Positioning]
* [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]

OpenSeaMap-dev:En:Depth Data

2013-03-03T16:56:49Z

Cleanerx: /* Upload Process */

This Page describes the necessary efforts to retrieve and analyze depth data as well as create renderings from it

= Data Aquisition =
Depth data can be retrieved from public domain sources or from crowd sourced data.

== GEBCO ==
DIe Daten sind gerendert und stehen als Layer zur Verfügung:
{| class="wikitable"
! Zoom || Inhalt
|-
| 0..10 || Blaustufen und Schattierung
|-
| 11..18 || beschriftete Tiefenlinien, Blaustufen und Schattierung
|}

Noch zu lösende Probleme:
* der GEBCO-Layer erzeugt einen milchigen Schleier über der Basiskarte
* Tiefenlinien sind ab z=14 etwas grob (also ab da, wo dann die Flachwassertiefen beginnen) [http://dev.openseamap.org/website/map/#?zoom=14&lat=36.03097&lon=-5.49153&layers=BFTFTTTFFFF0]
* Überschneidungen von 100m-Linie und Küstenlinie [http://dev.openseamap.org/website/map/#?zoom=15&lat=36.00318&lon=-5.60819&layers=BFTFTTTFFFF0]
* Steilküsten (Cuba) [http://dev.openseamap.org/website/map/#?zoom=14&lat=19.94808&lon=-76.04289&layers=BFTFTTTFFFF0]

== Crowd Sourced Data ==
Crowd sourced data may be gathered by YOU. There are two options in development. A hardware and a software option.

=== Hardware logger ===
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.
That data may then be uploaded by plugging the SD card to a normal computer with internet connection for upload.
The main goal is to support NMEA 0183 data with options for NMEA 2000.

=== Software logger ===
A Software logger is in development and [http://seesea.sourceforge.net/datalogger/index.html can be downloaded here].

It currently supports:
: Bluetooth
: Serial ports
: Internet Protocol (IP)
It processes NMEA 0183 and AIS data.

For vendor specific protocols such as SeaTalk 1 you have to use a [[De:NMEA-Logger_anschliessen|converter]] to NMEA 0183 data.

NMEA 2000 support is only available if data is transcoded to NMEA 0183 by a converter.

=== Upload Process ===
Uploading data is possible through using the OpenSeaMap Data Logger Software or via Web Interface.
The system is currently being tested.

[[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|You'll find further information here]].

= Data Preprocessing =

== Data Condition ==
Raw data is usually erronous and must be corrected

=== Internal data problems ===
Depth data may be affected by electrical conditions and software implementations
* Data is incomplete and fail their checksum (bus errors from physical transmissions errors)
* Data is retrived out of sequence
* Data is erronous sensor data
** Approximate correctable data i.e. invalid GPS position that may be interpolated
** Uncorrectable data i.e. failed log sensor that shows slow speeds
* Data resolution is low i.e. for energy saving purposes GPS position is updated every 10 seconds instead of every second
* Sensor data is actively miscalibrated i.e. charter companies add additional draft to the sensor depth for safety reasons

=== External data problems ===
Depth data may be affected by different environmental circumstances
* The water temperature affects the ultrasound echo. An inhomogen water temperature yields unwanted echos
* The seabed affects the ultrasound echo
* The seastate affects the measurement. There even may be waves when there is no wind.
* Waves may affect the roll of the measuring vessel resulting in steep measurements that are invalid.
* The sounder sensor is not the position of the GPS antenna. A position offset including heading must be incorporated.
* 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.

== Data Condition Examples / Showcases ==

=== Missing measurments (Position) ===
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.
One can see from the distribtion that the sensor is updated every second but many measurements are one or more seconds late.
21 seconds with no position update may result in an instability of the subsequent filter.
<pre>
MeasuredPosition3D
GP
0 :4285
1000 :11295
2000 :5056
3000 :2134
4000 :1135
5000 :315
6000 :154
7000 :46
8000 :36
9000 :16
10000 :12
11000 :3
12000 :4
13000 :1
14000 :7
15000 :3
16000 :1
21000 :1
</pre>

=== Missing measurments (Position) with erronous clock ===
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)
<pre>
MeasuredPosition3D
II
-21340000 :1
-13194000 :1
-7998000 :1
-2674000 :1
-2434000 :1
-2402000 :1
-2030000 :1
-1926000 :1
-1894000 :1
-1806000 :1
-1480000 :1
-1430000 :1
-1382000 :1
-1114000 :1
-814000 :1
-634000 :1
-590000 :1
-546000 :1
-470000 :1
-290000 :1
-230000 :1
-198000 :1
-110000 :1
-94000 :2
0 :182200
5000 :1
10000 :20230
15000 :1
20000 :84
50000 :1
114000 :2
130000 :2
218000 :1
250000 :1
310000 :1
490000 :1
566000 :1
610000 :1
654000 :1
834000 :1
1134000 :1
1402000 :1
1450000 :1</pre>

== Solution Proposal ==

=== Outline ===
The ship is influenced by the outlined environment which can be observed. Naturally what is observed is not the state of the
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.

=== Details ===
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.

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.

Todo:
* Construct ship system model with at least the position state and probably its course and speed or even more (depth)
* Estimate the system variance (This is a hard one, proposals welcome)
* Construct the measurement model according to the data available (GPS, Log)
* Estimate the measurement noise according to specifc sensors (DPGS is more accurate than GPS)

The estimation with the position and depth can be retrieved and stored in a database.

Pitfalls:
* If the system noise is badly chosen the estimation of the system state does not converge to the true state / measurement.
* If the system is very detailed the system variance can be reduced. The required cpu time for processing increases

Benefits:
* Having the best estimation of the true position even if measurements are noisy
* Easy and effective algorithmic processing

== Analysis ==

=== Data Sets ===
Currently two test data sets are available recorded during trips from Mallorca and the Baltic Sea.
In terms of data quality the Mallorca data shows many challenges.
* The minimum recommended sentences from NMEA showed up with false date and time readings while having correct (!!!) message checksums.
* The log on the ship was defective and delivered no readings from time to time.
* The same holds true for the water temperature.
* The GPS positions relatively imprecise because some last decimal digits are missing in the recordings.
* The GPS positions are updated every 10 seconds while other sensor readings update almost every second.
* The GPS position are sometimes way off due to false readings

The Baltic Sea data set is a little bit better
* Only a single day is available
* GPS positions are updated every second

One problem with the data is that there is time available when sensor readings were recorded. This yields problems to the filter algorithm.

=== Filter Algorithm ===
At first the Extended Kalman Filter is being analyzed. Using an apache implementation with the available data the filter quickly throw an exception that
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.
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
we may consider that for the future.

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
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.

== Results ==
A prototype implementation is shown in the following screenshots. An Extended Kalman Filter is being used. It has the position
and the current bearing and velocity as system state. The input is the measurement of these four observables. The system function is
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.
The initial state is taken from the first measurement for convergence reasons.

The following gallery shows the results.
* You can see the bad position resolution and an outlier in the first screenshot.
* The second shows the same data overlaid with the applied filter. The outlier is gone and the resolution has improved.
* The third screenshot shows data from a different GPS sensor with more precision (not DGPS) versus the filtered data.

This of course is just a preliminary test and many setups need to be considered to make it work for most datasets.

<gallery>
UnfilteredNMEA.png | Unfiltered GPS data
FilteredNMEAVsOriginal.png | Unfiltered GPS data and Filtered GPS data
PreciseGPSvsFilter.png | Another precise GPS vs Filtered GPS data
</gallery>

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].
This way positional inaccuracies may be added to the overall depth measurement inaccuracy.

== Quality rating ==

Each record (time, positon, depth) should become a quality rating.

=== Points ===

Derived from the Fibonacci series.

{| class="wikitable"
! Point || Description
|-
| 1 || extra small improvement
|-
| 2 || small improvement
|-
| 3 || medium improvement
|-
| 5 || large improvement
|-
| 8 || extra large improvement
|}

=== Factors ===

{| class="wikitable"
! style="width:15%" | Name
! style="width:17%" | Factor
! style="width:68%" | Description
|-
| depth offset || 8 (extra large) || The difference between the depth measured by the echo sounder and the depth (waterline) measured by hand.
|-
| device distance || 3 (medium) || The distance between gps antenna and echo sounder (lengthwise and crosswise).
|-
| SBAS || 3 (medium) || Satellite based augmentation system (WAAS, EGNOS, MSAS) which allows to correct the gps position.
|-
| 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.
|}

= Depth Rendering =

= Siehe auch =
* [[De:Bordnetz|Bordnetz]]
* [[De:NMEA-Logger_anschliessen|NMEA-Logger_anschliessen]]
* [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]
* [http://users.isr.ist.utl.pt/~pedro/publications/CAMS10.pdf A Multiple Model Adaptive Wave Filter for Dynamic Ship Positioning]
* [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]

OpenSeaMap-dev:En:Depth Data

2013-03-03T16:55:12Z

Cleanerx: /* Software logger */

This Page describes the necessary efforts to retrieve and analyze depth data as well as create renderings from it

= Data Aquisition =
Depth data can be retrieved from public domain sources or from crowd sourced data.

== GEBCO ==
DIe Daten sind gerendert und stehen als Layer zur Verfügung:
{| class="wikitable"
! Zoom || Inhalt
|-
| 0..10 || Blaustufen und Schattierung
|-
| 11..18 || beschriftete Tiefenlinien, Blaustufen und Schattierung
|}

Noch zu lösende Probleme:
* der GEBCO-Layer erzeugt einen milchigen Schleier über der Basiskarte
* Tiefenlinien sind ab z=14 etwas grob (also ab da, wo dann die Flachwassertiefen beginnen) [http://dev.openseamap.org/website/map/#?zoom=14&lat=36.03097&lon=-5.49153&layers=BFTFTTTFFFF0]
* Überschneidungen von 100m-Linie und Küstenlinie [http://dev.openseamap.org/website/map/#?zoom=15&lat=36.00318&lon=-5.60819&layers=BFTFTTTFFFF0]
* Steilküsten (Cuba) [http://dev.openseamap.org/website/map/#?zoom=14&lat=19.94808&lon=-76.04289&layers=BFTFTTTFFFF0]

== Crowd Sourced Data ==
Crowd sourced data may be gathered by YOU. There are two options in development. A hardware and a software option.

=== Hardware logger ===
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.
That data may then be uploaded by plugging the SD card to a normal computer with internet connection for upload.
The main goal is to support NMEA 0183 data with options for NMEA 2000.

=== Software logger ===
A Software logger is in development and [http://seesea.sourceforge.net/datalogger/index.html can be downloaded here].

It currently supports:
: Bluetooth
: Serial ports
: Internet Protocol (IP)
It processes NMEA 0183 and AIS data.

For vendor specific protocols such as SeaTalk 1 you have to use a [[De:NMEA-Logger_anschliessen|converter]] to NMEA 0183 data.

NMEA 2000 support is only available if data is transcoded to NMEA 0183 by a converter.

=== Upload Process ===
[[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|You'll find further information here]].

= Data Preprocessing =

== Data Condition ==
Raw data is usually erronous and must be corrected

=== Internal data problems ===
Depth data may be affected by electrical conditions and software implementations
* Data is incomplete and fail their checksum (bus errors from physical transmissions errors)
* Data is retrived out of sequence
* Data is erronous sensor data
** Approximate correctable data i.e. invalid GPS position that may be interpolated
** Uncorrectable data i.e. failed log sensor that shows slow speeds
* Data resolution is low i.e. for energy saving purposes GPS position is updated every 10 seconds instead of every second
* Sensor data is actively miscalibrated i.e. charter companies add additional draft to the sensor depth for safety reasons

=== External data problems ===
Depth data may be affected by different environmental circumstances
* The water temperature affects the ultrasound echo. An inhomogen water temperature yields unwanted echos
* The seabed affects the ultrasound echo
* The seastate affects the measurement. There even may be waves when there is no wind.
* Waves may affect the roll of the measuring vessel resulting in steep measurements that are invalid.
* The sounder sensor is not the position of the GPS antenna. A position offset including heading must be incorporated.
* 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.

== Data Condition Examples / Showcases ==

=== Missing measurments (Position) ===
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.
One can see from the distribtion that the sensor is updated every second but many measurements are one or more seconds late.
21 seconds with no position update may result in an instability of the subsequent filter.
<pre>
MeasuredPosition3D
GP
0 :4285
1000 :11295
2000 :5056
3000 :2134
4000 :1135
5000 :315
6000 :154
7000 :46
8000 :36
9000 :16
10000 :12
11000 :3
12000 :4
13000 :1
14000 :7
15000 :3
16000 :1
21000 :1
</pre>

=== Missing measurments (Position) with erronous clock ===
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)
<pre>
MeasuredPosition3D
II
-21340000 :1
-13194000 :1
-7998000 :1
-2674000 :1
-2434000 :1
-2402000 :1
-2030000 :1
-1926000 :1
-1894000 :1
-1806000 :1
-1480000 :1
-1430000 :1
-1382000 :1
-1114000 :1
-814000 :1
-634000 :1
-590000 :1
-546000 :1
-470000 :1
-290000 :1
-230000 :1
-198000 :1
-110000 :1
-94000 :2
0 :182200
5000 :1
10000 :20230
15000 :1
20000 :84
50000 :1
114000 :2
130000 :2
218000 :1
250000 :1
310000 :1
490000 :1
566000 :1
610000 :1
654000 :1
834000 :1
1134000 :1
1402000 :1
1450000 :1</pre>

== Solution Proposal ==

=== Outline ===
The ship is influenced by the outlined environment which can be observed. Naturally what is observed is not the state of the
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.

=== Details ===
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.

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.

Todo:
* Construct ship system model with at least the position state and probably its course and speed or even more (depth)
* Estimate the system variance (This is a hard one, proposals welcome)
* Construct the measurement model according to the data available (GPS, Log)
* Estimate the measurement noise according to specifc sensors (DPGS is more accurate than GPS)

The estimation with the position and depth can be retrieved and stored in a database.

Pitfalls:
* If the system noise is badly chosen the estimation of the system state does not converge to the true state / measurement.
* If the system is very detailed the system variance can be reduced. The required cpu time for processing increases

Benefits:
* Having the best estimation of the true position even if measurements are noisy
* Easy and effective algorithmic processing

== Analysis ==

=== Data Sets ===
Currently two test data sets are available recorded during trips from Mallorca and the Baltic Sea.
In terms of data quality the Mallorca data shows many challenges.
* The minimum recommended sentences from NMEA showed up with false date and time readings while having correct (!!!) message checksums.
* The log on the ship was defective and delivered no readings from time to time.
* The same holds true for the water temperature.
* The GPS positions relatively imprecise because some last decimal digits are missing in the recordings.
* The GPS positions are updated every 10 seconds while other sensor readings update almost every second.
* The GPS position are sometimes way off due to false readings

The Baltic Sea data set is a little bit better
* Only a single day is available
* GPS positions are updated every second

One problem with the data is that there is time available when sensor readings were recorded. This yields problems to the filter algorithm.

=== Filter Algorithm ===
At first the Extended Kalman Filter is being analyzed. Using an apache implementation with the available data the filter quickly throw an exception that
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.
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
we may consider that for the future.

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
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.

== Results ==
A prototype implementation is shown in the following screenshots. An Extended Kalman Filter is being used. It has the position
and the current bearing and velocity as system state. The input is the measurement of these four observables. The system function is
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.
The initial state is taken from the first measurement for convergence reasons.

The following gallery shows the results.
* You can see the bad position resolution and an outlier in the first screenshot.
* The second shows the same data overlaid with the applied filter. The outlier is gone and the resolution has improved.
* The third screenshot shows data from a different GPS sensor with more precision (not DGPS) versus the filtered data.

This of course is just a preliminary test and many setups need to be considered to make it work for most datasets.

<gallery>
UnfilteredNMEA.png | Unfiltered GPS data
FilteredNMEAVsOriginal.png | Unfiltered GPS data and Filtered GPS data
PreciseGPSvsFilter.png | Another precise GPS vs Filtered GPS data
</gallery>

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].
This way positional inaccuracies may be added to the overall depth measurement inaccuracy.

== Quality rating ==

Each record (time, positon, depth) should become a quality rating.

=== Points ===

Derived from the Fibonacci series.

{| class="wikitable"
! Point || Description
|-
| 1 || extra small improvement
|-
| 2 || small improvement
|-
| 3 || medium improvement
|-
| 5 || large improvement
|-
| 8 || extra large improvement
|}

=== Factors ===

{| class="wikitable"
! style="width:15%" | Name
! style="width:17%" | Factor
! style="width:68%" | Description
|-
| depth offset || 8 (extra large) || The difference between the depth measured by the echo sounder and the depth (waterline) measured by hand.
|-
| device distance || 3 (medium) || The distance between gps antenna and echo sounder (lengthwise and crosswise).
|-
| SBAS || 3 (medium) || Satellite based augmentation system (WAAS, EGNOS, MSAS) which allows to correct the gps position.
|-
| 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.
|}

= Depth Rendering =

= Siehe auch =
* [[De:Bordnetz|Bordnetz]]
* [[De:NMEA-Logger_anschliessen|NMEA-Logger_anschliessen]]
* [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]
* [http://users.isr.ist.utl.pt/~pedro/publications/CAMS10.pdf A Multiple Model Adaptive Wave Filter for Dynamic Ship Positioning]
* [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]

OpenSeaMap-dev:Entwicklerwochenende 2013-04

2013-03-03T14:09:26Z

Cleanerx: /* Anmeldung */

Planung zum 6. Entwicklerwochenende am '''11.-15. 4. 2013'''

== Anmeldung ==
[mailto:liste12A45q7@gmx.de?subject=5.%20Entwicklerwochenende%20-%20Anmeldung Anmeldung bitte per Mail] oder hier in der Liste:
{| class="wikitable sortable"
! Nr || Do || Fr || Sa || So || Mo || wer || von wo || Übernachtung || class="unsortable" | Bemerkungen
|-
| 1 || x || x || x || x || x || [[Benutzer:Markus|Markus]] || || - ||
|-
| 2 || || || x || || || Wolfgang Bosch || Wien || - || DGFI
|-
| 3 || || || x || x || || Jens Kübler || Karlsruhe || - || -
|-
| 4 || || || || || || || || ||
|}

== Programm ==
Das Programm werden wir je nach anwesenden Personen, Interessen und Prioritäten gestalten und möglichst hier vorher gemeinsam planen.

Schwerpunkt wir sein:
* Wassertiefenerfassung
* Korrektur der Rohdaten
* HW-Logger

Wolfgang Bosch hilft uns beim Konzept für die Erfassung der Wassertiefen und bei der Korrektur der Rohdaten. Er arbeitet am [http://www.dgfi.badw.de/ deutschen geodätischen Forschungsinstitut (DGFI)] in München, und ist Spezialist für Wellen- und Tidenmodelle. Er wird am Samstag seine Arbeit vorstellen.

Und natürlich werden wir auch für alle anderen wichtigen Temen Zeit haben: Visionen, Ideen, Pläne zu Apps, Vektorkarten, Community, Qualität, Server, Tidenrechner, Hafendatenbank, Wassersportwiki, etc, etc.

; Struktur
: Die Idee ist, dass jeder "Maintainer" bzw. jedes Team eines Projektes ein Zeitfenster hat, um die zentralen Fragen mit allen anderen Entwicklern zu diskutieren und Lösungen bzw Lösungswege zu finden.
: Ergebnis soll jeweils eine ToDo-Liste sein.
: Bewährt hat sich beim letzten Mal, das Treffen auch als Hack-Weekend zu gestalten.
: Und natürlich wie immer Zeit für's Kennenlernen und Fachsimpeln!

{| class="wikitable"
! Zeit || Thema || Wer || Bemerkungen
|-
| Do || Core-Dev-Meeting || || open for everybody
|-
| Fr || Pre-Dev-Meeting || || open for everybody
|-
| Fr 19:00 || Abendessen || bei Markus || (bitte anmelden)
|-
| Sa 08:00 || Frühstück || Gäste von Markus || wer mag kann gern dazukommen (bitte anmelden)
|-
| '''Sa 10:00''' || Intro || Markus || Rückblick, Ausblick
|-
| Sa 10:30 || Vorstellungsrunde || alle || je max 5' incl. Kurzvorstellung des Teilprojektes bitte Flipchart mitbringen, oder 1 PPT-Folie (vorab an Markus schicken)
|-
| Sa 12:00 || || ||
|-
| Sa 14:00 || Mittagspause || || "kaltes Buffet"
|-
| Sa 15:00 || || ||
|-
| Sa 17:00 || || ||
|-
| Sa 19:00 || Abendessen || || Landgasthof
|-
| Sa 20:00 || || ||
|-
| So 08:00 || Frühstück || Gäste von Markus || wer mag kann gern dazukommen (bitte anmelden)
|-
| So 10:00 || || ||
|-
| So 12:00 || || ||
|-
| So 14:00 || || ||
|-
| '''So 16:00''' || Ende des Hauptteils || ||
|-
| So 18:00 || || ||
|-
| So 20:00 || || ||
|-
| So 22:00 || || ||
|-
| Mo 08:00 || Arbeits-Frühstück || || Rückblick, Planung
|-
| Mo 10:00 || || || Umsetzung? (je nachdem wer noch da ist)
|}

== Themen ==
{| class="wikitable"
! Thema || Prio || wer || Bemerkungen
|-
| HW-Logger || || ||
|-
| SW-Logger || || ||
|-
| Datenaufbereitung || || Wolfgang ||
|-
| PR || || Markus ||
|-
| ... || || ||
|}

== Unterkunft ==

; privat bei Markus
: Bei mir können 3..4 Gäste gratis übernachten. Gern bereits ab Donnerstag bzw bis Montag.
:{| class="wikitable"
! wer || Do || Fr || Sa || So
|-
| ... || || || ||
|-
| ... || || || ||
|-
| ... || || || ||
|}

; Landgasthof "Lang"
: 5 Minuten zu Fuss, beim Bahnhof Simmelsdorf, [http://www.openstreetmap.org/?mlat=49.5985&mlon=11.34&zoom=14 Karte]
: EZ Ü/F: ab 30 € (25,20 € ohne Frühstück)
: Bahnhofstraße 9, 91245 Simmelsdorf, +49 9155 237, [http://www.landgasthaus-lang.de/ Landgasthof-Lang.de]

; Hotel "Igelwirt"
: 10 Minuten mit dem Auto, [http://www.openstreetmap.org/?mlat=49.5873&mlon=11.3765&zoom=14 Karte]
: EZ Ü/F: ab 57 € (52 € ohne Frühstück )
: Igelweg 6, 91220 Schnaittach-Osternohe, +40 9153 4060, [http://www.igelwirt.de/ Igelwirt.de]

; Gasthof Schuster
: 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]
: EZ Ü/F 33 € (29 € ohne Frühstück)
: Kirchenweg 6, 91220 Hedersdorf, +49 9153 1288

== Verpflegung ==
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...
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?

Getränke und Tee/Kaffee sind im Haus. Ebenso Aufbackbrötchen und Nudeln für alle Fälle.

{| class="wikitable"
! 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
|-
| Markus || X || || || || || || || || || || || || || || Food for all
|-
| Markus || || X || || || || || || || || || || || || || Abendessen bei mir für alle die angemeldet sind
|-
| Markus || || || x || || || X || || || || X || || || || X || Frühstück bei mir für alle die angemeldet sind
|-
| Landgasthof || || || || || X || || || || X || || || || X || ||
|-
| ... || || || || || || || || || || || || || || ||
|}

{| class="wikitable"
! 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
|-
| Markus || X || X || X || X || X || X || X || X || X || X || X || X ||
|-
| ... || || || || || || || || || || || || ||
|-
| ... || || || || || || || || || || || || ||
|}

== Fahrgemeinschaft ==
; Suche
{| class="wikitable"
! wer || ab wo || Bemerkungen
|-
| .. || ||
|}

; Biete
{| class="wikitable"
! wer || ab wo || Abfahrt || Plätze || Bemerkungen
|-
| ..|| || || ||
|}

Bitte nehmt direkt miteinander Kontakt auf.

== Zusammenfassung / ToDo ==
* [[OpenSeaMap-dev:6._Entwicklerwochenende/Bericht | Bericht / ToDo]]
* [[OpenSeaMap-dev:5._Entwicklerwochenende/Bericht | Bericht / ToDo vom letzten Entwicklertreffen]]

OpenSeaMap-dev:En:Depth Data

2013-02-08T22:27:21Z

Cleanerx:

This Page describes the necessary efforts to retrieve and analyze depth data as well as create renderings from it

= Data Aquisition =
Depth data can be retrieved from public domain sources or from crowd sourced data.

== GEBCO ==
DIe Daten sind gerendert und stehen als Layer zur Verfügung:
{| class="wikitable"
! Zoom || Inhalt
|-
| 0..10 || Blaustufen und Schattierung
|-
| 11..18 || beschriftete Tiefenlinien, Blaustufen und Schattierung
|}

Noch zu lösende Probleme:
* der GEBCO-Layer erzeugt einen milchigen Schleier über der Basiskarte
* Tiefenlinien sind ab z=14 etwas grob (also ab da, wo dann die Flachwassertiefen beginnen) [http://dev.openseamap.org/website/map/#?zoom=14&lat=36.03097&lon=-5.49153&layers=BFTFTTTFFFF0]
* Überschneidungen von 100m-Linie und Küstenlinie [http://dev.openseamap.org/website/map/#?zoom=15&lat=36.00318&lon=-5.60819&layers=BFTFTTTFFFF0]
* Steilküsten (Cuba) [http://dev.openseamap.org/website/map/#?zoom=14&lat=19.94808&lon=-76.04289&layers=BFTFTTTFFFF0]

== Crowd Sourced Data ==
Crowd sourced data may be gathered by YOU. There are two options in development. A hardware and a software option.

=== Hardware logger ===
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.
That data may then be uploaded by plugging the SD card to a normal computer with internet connection for upload.
The main goal is to support NMEA 0183 data with options for NMEA 2000.

=== Software logger ===
A Software logger is in development and [http://seesea.sourceforge.net/datalogger/index.html can be retrieved here].

It currently supports:
: Bluetooth
: serial ports
retrieving NMEA 0183 data ([[De:NMEA-Logger_anschliessen|Bridge needable]])

IP Support and NMEA 2000 development is underway.

=== Upload Process ===
[[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|You'll find further information here]].

= Data Preprocessing =

== Data Condition ==
Raw data is usually erronous and must be corrected

=== Internal data problems ===
Depth data may be affected by electrical conditions and software implementations
* Data is incomplete and fail their checksum (bus errors from physical transmissions errors)
* Data is retrived out of sequence
* Data is erronous sensor data
** Approximate correctable data i.e. invalid GPS position that may be interpolated
** Uncorrectable data i.e. failed log sensor that shows slow speeds
* Data resolution is low i.e. for energy saving purposes GPS position is updated every 10 seconds instead of every second
* Sensor data is actively miscalibrated i.e. charter companies add additional draft to the sensor depth for safety reasons

=== External data problems ===
Depth data may be affected by different environmental circumstances
* The water temperature affects the ultrasound echo. An inhomogen water temperature yields unwanted echos
* The seabed affects the ultrasound echo
* The seastate affects the measurement. There even may be waves when there is no wind.
* Waves may affect the roll of the measuring vessel resulting in steep measurements that are invalid.
* The sounder sensor is not the position of the GPS antenna. A position offset including heading must be incorporated.
* 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.

== Data Condition Examples / Showcases ==

=== Missing measurments (Position) ===
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.
One can see from the distribtion that the sensor is updated every second but many measurements are one or more seconds late.
21 seconds with no position update may result in an instability of the subsequent filter.
<pre>
MeasuredPosition3D
GP
0 :4285
1000 :11295
2000 :5056
3000 :2134
4000 :1135
5000 :315
6000 :154
7000 :46
8000 :36
9000 :16
10000 :12
11000 :3
12000 :4
13000 :1
14000 :7
15000 :3
16000 :1
21000 :1
</pre>

=== Missing measurments (Position) with erronous clock ===
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)
<pre>
MeasuredPosition3D
II
-21340000 :1
-13194000 :1
-7998000 :1
-2674000 :1
-2434000 :1
-2402000 :1
-2030000 :1
-1926000 :1
-1894000 :1
-1806000 :1
-1480000 :1
-1430000 :1
-1382000 :1
-1114000 :1
-814000 :1
-634000 :1
-590000 :1
-546000 :1
-470000 :1
-290000 :1
-230000 :1
-198000 :1
-110000 :1
-94000 :2
0 :182200
5000 :1
10000 :20230
15000 :1
20000 :84
50000 :1
114000 :2
130000 :2
218000 :1
250000 :1
310000 :1
490000 :1
566000 :1
610000 :1
654000 :1
834000 :1
1134000 :1
1402000 :1
1450000 :1</pre>

== Solution Proposal ==

=== Outline ===
The ship is influenced by the outlined environment which can be observed. Naturally what is observed is not the state of the
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.

=== Details ===
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.

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.

Todo:
* Construct ship system model with at least the position state and probably its course and speed or even more (depth)
* Estimate the system variance (This is a hard one, proposals welcome)
* Construct the measurement model according to the data available (GPS, Log)
* Estimate the measurement noise according to specifc sensors (DPGS is more accurate than GPS)

The estimation with the position and depth can be retrieved and stored in a database.

Pitfalls:
* If the system noise is badly chosen the estimation of the system state does not converge to the true state / measurement.
* If the system is very detailed the system variance can be reduced. The required cpu time for processing increases

Benefits:
* Having the best estimation of the true position even if measurements are noisy
* Easy and effective algorithmic processing

== Analysis ==

=== Data Sets ===
Currently two test data sets are available recorded during trips from Mallorca and the Baltic Sea.
In terms of data quality the Mallorca data shows many challenges.
* The minimum recommended sentences from NMEA showed up with false date and time readings while having correct (!!!) message checksums.
* The log on the ship was defective and delivered no readings from time to time.
* The same holds true for the water temperature.
* The GPS positions relatively imprecise because some last decimal digits are missing in the recordings.
* The GPS positions are updated every 10 seconds while other sensor readings update almost every second.
* The GPS position are sometimes way off due to false readings

The Baltic Sea data set is a little bit better
* Only a single day is available
* GPS positions are updated every second

One problem with the data is that there is time available when sensor readings were recorded. This yields problems to the filter algorithm.

=== Filter Algorithm ===
At first the Extended Kalman Filter is being analyzed. Using an apache implementation with the available data the filter quickly throw an exception that
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.
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
we may consider that for the future.

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
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.

== Results ==
A prototype implementation is shown in the following screenshots. An Extended Kalman Filter is being used. It has the position
and the current bearing and velocity as system state. The input is the measurement of these four observables. The system function is
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.
The initial state is taken from the first measurement for convergence reasons.

The following gallery shows the results.
* You can see the bad position resolution and an outlier in the first screenshot.
* The second shows the same data overlaid with the applied filter. The outlier is gone and the resolution has improved.
* The third screenshot shows data from a different GPS sensor with more precision (not DGPS) versus the filtered data.

This of course is just a preliminary test and many setups need to be considered to make it work for most datasets.

<gallery>
UnfilteredNMEA.png | Unfiltered GPS data
FilteredNMEAVsOriginal.png | Unfiltered GPS data and Filtered GPS data
PreciseGPSvsFilter.png | Another precise GPS vs Filtered GPS data
</gallery>

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].
This way positional inaccuracies may be added to the overall depth measurement inaccuracy.

== Quality rating ==

Each record (time, positon, depth) should become a quality rating.

=== Points ===

Derived from the Fibonacci series.

{| class="wikitable"
! Point || Description
|-
| 1 || extra small improvement
|-
| 2 || small improvement
|-
| 3 || medium improvement
|-
| 5 || large improvement
|-
| 8 || extra large improvement
|}

=== Factors ===

{| class="wikitable"
! style="width:15%" | Name
! style="width:17%" | Factor
! style="width:68%" | Description
|-
| depth offset || 8 (extra large) || The difference between the depth measured by the echo sounder and the depth (waterline) measured by hand.
|-
| device distance || 3 (medium) || The distance between gps antenna and echo sounder (lengthwise and crosswise).
|-
| SBAS || 3 (medium) || Satellite based augmentation system (WAAS, EGNOS, MSAS) which allows to correct the gps position.
|-
| 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.
|}

= Depth Rendering =

= Siehe auch =
* [[De:Bordnetz|Bordnetz]]
* [[De:NMEA-Logger_anschliessen|NMEA-Logger_anschliessen]]
* [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]
* [http://users.isr.ist.utl.pt/~pedro/publications/CAMS10.pdf A Multiple Model Adaptive Wave Filter for Dynamic Ship Positioning]
* [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]

OpenSeaMap-dev:En:Depth Data

2012-11-27T08:03:32Z

Cleanerx: /* Siehe auch */

This Page describes the necessary efforts to retrieve and analyze depth data as well as create renderings from it

= Data Aquisition =
Depth data can be retrieved from public domain sources or from crowd sourced data.

== GEBCO ==
DIe Daten sind gerendert und stehen als Layer zur Verfügung:
{| class="wikitable"
! Zoom || Inhalt
|-
| 0..10 || Blaustufen und Schattierung
|-
| 11..18 || beschriftete Tiefenlinien, Blaustufen und Schattierung
|}

Noch zu lösende Probleme:
* der GEBCO-Layer erzeugt einen milchigen Schleier über der Basiskarte
* Tiefenlinien sind ab z=14 etwas grob (also ab da, wo dann die Flachwassertiefen beginnen) [http://dev.openseamap.org/website/map/#?zoom=14&lat=36.03097&lon=-5.49153&layers=BFTFTTTFFFF0]
* Überschneidungen von 100m-Linie und Küstenlinie [http://dev.openseamap.org/website/map/#?zoom=15&lat=36.00318&lon=-5.60819&layers=BFTFTTTFFFF0]
* Steilküsten (Cuba) [http://dev.openseamap.org/website/map/#?zoom=14&lat=19.94808&lon=-76.04289&layers=BFTFTTTFFFF0]

== Crowd Sourced Data ==
Crowd sourced data may be gathered by YOU. There are two options in development. A hardware and a software option.

=== Hardware logger ===
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.
That data may then be uploaded by plugging the SD card to a normal computer with internet connection for upload.
The main goal is to support NMEA 0183 data with options for NMEA 2000.

=== Software logger ===
A Software logger is in development and [http://seesea.sourceforge.net/datalogger/index.html can be retrieved here].

It currently supports:
: Bluetooth
: serial ports
retrieving NMEA 0183 data ([[De:NMEA-Logger_anschliessen|Bridge needable]])

IP Support and NMEA 2000 development is underway.

=== Upload Process ===
[[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|You'll find further information here]].

= Data Preprocessing =

== Data Condition ==
Raw data is usually erronous and must be corrected

=== Internal data problems ===
Depth data may be affected by electrical conditions and software implementations
* Data is incomplete and fail their checksum (bus errors from physical transmissions errors)
* Data is erronous sensor data
** Approximate correctable data i.e. invalid GPS position that may be interpolated
** Uncorrectable data i.e. failed log sensor that shows slow speeds
* Data resolution is low i.e. for energy saving purposes GPS position is updated every 10 seconds instead of every second
* Sensor data is actively miscalibrated i.e. charter companies add additional draft to the sensor depth for safety reasons

=== External data problems ===
Depth data may be affected by different environmental circumstances
* The water temperature affects the ultrasound echo. An inhomogen water temperature yields unwanted echos
* The seabed affects the ultrasound echo
* The seastate affects the measurement. There even may be waves when there is no wind.
* Waves may affect the roll of the measuring vessel resulting in steep measurements that are invalid.
* The sounder sensor is not the position of the GPS antenna. A position offset including heading must be incorporated.
* 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.

== Solution Proposal ==

=== Outline ===
The ship is influenced by the outlined environment which can be observed. Naturally what is observed is not the state of the
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.

=== Details ===
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.

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.

Todo:
* Construct ship system model with at least the position state and probably its course and speed or even more (depth)
* Estimate the system variance (This is a hard one, proposals welcome)
* Construct the measurement model according to the data available (GPS, Log)
* Estimate the measurement noise according to specifc sensors (DPGS is more accurate than GPS)

The estimation with the position and depth can be retrieved and stored in a database.

Pitfalls:
* If the system noise is badly chosen the estimation of the system state does not converge to the true state / measurement.
* If the system is very detailed the system variance can be reduced. The required cpu time for processing increases

Benefits:
* Having the best estimation of the true position even if measurements are noisy
* Easy and effective algorithmic processing

== Analysis ==

=== Data Sets ===
Currently two test data sets are available recorded during trips from Mallorca and the Baltic Sea.
In terms of data quality the Mallorca data shows many challenges.
* The minimum recommended sentences from NMEA showed up with false date and time readings while having correct (!!!) message checksums.
* The log on the ship was defective and delivered no readings from time to time.
* The same holds true for the water temperature.
* The GPS positions relatively imprecise because some last decimal digits are missing in the recordings.
* The GPS positions are updated every 10 seconds while other sensor readings update almost every second.
* The GPS position are sometimes way off due to false readings

The Baltic Sea data set is a little bit better
* Only a single day is available
* GPS positions are updated every second

One problem with the data is that there is time available when sensor readings were recorded. This yields problems to the filter algorithm.

=== Filter Algorithm ===
At first the Extended Kalman Filter is being analyzed. Using an apache implementation with the available data the filter quickly throw an exception that
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.
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
we may consider that for the future.

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
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.

== Results ==
A prototype implementation is shown in the following screenshots. An Extended Kalman Filter is being used. It has the position
and the current bearing and velocity as system state. The input is the measurement of these four observables. The system function is
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.
The initial state is taken from the first measurement for convergence reasons.

The following gallery shows the results.
* You can see the bad position resolution and an outlier in the first screenshot.
* The second shows the same data overlaid with the applied filter. The outlier is gone and the resolution has improved.
* The third screenshot shows data from a different GPS sensor with more precision (not DGPS) versus the filtered data.

This of course is just a preliminary test and many setups need to be considered to make it work for most datasets.

<gallery>
UnfilteredNMEA.png | Unfiltered GPS data
FilteredNMEAVsOriginal.png | Unfiltered GPS data and Filtered GPS data
PreciseGPSvsFilter.png | Another precise GPS vs Filtered GPS data
</gallery>

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].
This way positional inaccuracies may be added to the overall depth measurement inaccuracy.

== Quality rating ==

Each record (time, positon, depth) should become a quality rating.

=== Points ===

Derived from the Fibonacci series.

{| class="wikitable"
! Point || Description
|-
| 1 || extra small improvement
|-
| 2 || small improvement
|-
| 3 || medium improvement
|-
| 5 || large improvement
|-
| 8 || extra large improvement
|}

=== Factors ===

{| class="wikitable"
! style="width:15%" | Name
! style="width:17%" | Factor
! style="width:68%" | Description
|-
| depth offset || 8 (extra large) || The difference between the depth measured by the echo sounder and the depth (waterline) measured by hand.
|-
| device distance || 3 (medium) || The distance between gps antenna and echo sounder (lengthwise and crosswise).
|-
| SBAS || 3 (medium) || Satellite based augmentation system (WAAS, EGNOS, MSAS) which allows to correct the gps position.
|-
| 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.
|}

= Depth Rendering =

= Siehe auch =
* [[De:Bordnetz|Bordnetz]]
* [[De:NMEA-Logger_anschliessen|NMEA-Logger_anschliessen]]
* [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]
* [http://users.isr.ist.utl.pt/~pedro/publications/CAMS10.pdf A Multiple Model Adaptive Wave Filter for Dynamic Ship Positioning]
* [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]

OpenSeaMap-dev:En:Depth Data

2012-10-28T13:02:37Z

Cleanerx: /* Siehe auch */

This Page describes the necessary efforts to retrieve and analyze depth data as well as create renderings from it

= Data Aquisition =
Depth data can be retrieved from public domain sources or from crowd sourced data.

== GEBCO ==
DIe Daten sind gerendert und stehen als Layer zur Verfügung:
{| class="wikitable"
! Zoom || Inhalt
|-
| 0..10 || Blaustufen und Schattierung
|-
| 11..18 || beschriftete Tiefenlinien, Blaustufen und Schattierung
|}

Noch zu lösende Probleme:
* der GEBCO-Layer erzeugt einen milchigen Schleier über der Basiskarte
* Tiefenlinien sind ab z=14 etwas grob (also ab da, wo dann die Flachwassertiefen beginnen) [http://dev.openseamap.org/website/map/#?zoom=14&lat=36.03097&lon=-5.49153&layers=BFTFTTTFFFF0]
* Überschneidungen von 100m-Linie und Küstenlinie [http://dev.openseamap.org/website/map/#?zoom=15&lat=36.00318&lon=-5.60819&layers=BFTFTTTFFFF0]
* Steilküsten (Cuba) [http://dev.openseamap.org/website/map/#?zoom=14&lat=19.94808&lon=-76.04289&layers=BFTFTTTFFFF0]

== Crowd Sourced Data ==
Crowd sourced data may be gathered by YOU. There are two options in development. A hardware and a software option.

=== Hardware logger ===
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.
That data may then be uploaded by plugging the SD card to a normal computer with internet connection for upload.
The main goal is to support NMEA 0183 data with options for NMEA 2000.

=== Software logger ===
A Software logger is in development and [http://seesea.sourceforge.net/datalogger/index.html can be retrieved here].

It currently supports:
: Bluetooth
: serial ports
retrieving NMEA 0183 data ([[De:NMEA-Logger_anschliessen|Bridge needable]])

IP Support and NMEA 2000 development is underway.

=== Upload Process ===
[[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|You'll find further information here]].

= Data Preprocessing =

== Data Condition ==
Raw data is usually erronous and must be corrected

=== Internal data problems ===
Depth data may be affected by electrical conditions and software implementations
* Data is incomplete and fail their checksum (bus errors from physical transmissions errors)
* Data is erronous sensor data
** Approximate correctable data i.e. invalid GPS position that may be interpolated
** Uncorrectable data i.e. failed log sensor that shows slow speeds
* Data resolution is low i.e. for energy saving purposes GPS position is updated every 10 seconds instead of every second
* Sensor data is actively miscalibrated i.e. charter companies add additional draft to the sensor depth for safety reasons

=== External data problems ===
Depth data may be affected by different environmental circumstances
* The water temperature affects the ultrasound echo. An inhomogen water temperature yields unwanted echos
* The seabed affects the ultrasound echo
* The seastate affects the measurement. There even may be waves when there is no wind.
* Waves may affect the roll of the measuring vessel resulting in steep measurements that are invalid.
* The sounder sensor is not the position of the GPS antenna. A position offset including heading must be incorporated.
* 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.

== Solution Proposal ==

=== Outline ===
The ship is influenced by the outlined environment which can be observed. Naturally what is observed is not the state of the
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.

=== Details ===
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.

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.

Todo:
* Construct ship system model with at least the position state and probably its course and speed or even more (depth)
* Estimate the system variance (This is a hard one, proposals welcome)
* Construct the measurement model according to the data available (GPS, Log)
* Estimate the measurement noise according to specifc sensors (DPGS is more accurate than GPS)

The estimation with the position and depth can be retrieved and stored in a database.

Pitfalls:
* If the system noise is badly chosen the estimation of the system state does not converge to the true state / measurement.
* If the system is very detailed the system variance can be reduced. The required cpu time for processing increases

Benefits:
* Having the best estimation of the true position even if measurements are noisy
* Easy and effective algorithmic processing

== Analysis ==

=== Data Sets ===
Currently two test data sets are available recorded during trips from Mallorca and the Baltic Sea.
In terms of data quality the Mallorca data shows many challenges.
* The minimum recommended sentences from NMEA showed up with false date and time readings while having correct (!!!) message checksums.
* The log on the ship was defective and delivered no readings from time to time.
* The same holds true for the water temperature.
* The GPS positions relatively imprecise because some last decimal digits are missing in the recordings.
* The GPS positions are updated every 10 seconds while other sensor readings update almost every second.
* The GPS position are sometimes way off due to false readings

The Baltic Sea data set is a little bit better
* Only a single day is available
* GPS positions are updated every second

One problem with the data is that there is time available when sensor readings were recorded. This yields problems to the filter algorithm.

=== Filter Algorithm ===
At first the Extended Kalman Filter is being analyzed. Using an apache implementation with the available data the filter quickly throw an exception that
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.
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
we may consider that for the future.

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
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.

== Results ==
A prototype implementation is shown in the following screenshots. An Extended Kalman Filter is being used. It has the position
and the current bearing and velocity as system state. The input is the measurement of these four observables. The system function is
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.
The initial state is taken from the first measurement for convergence reasons.

The following gallery shows the results.
* You can see the bad position resolution and an outlier in the first screenshot.
* The second shows the same data overlaid with the applied filter. The outlier is gone and the resolution has improved.
* The third screenshot shows data from a different GPS sensor with more precision (not DGPS) versus the filtered data.

This of course is just a preliminary test and many setups need to be considered to make it work for most datasets.

<gallery>
UnfilteredNMEA.png | Unfiltered GPS data
FilteredNMEAVsOriginal.png | Unfiltered GPS data and Filtered GPS data
PreciseGPSvsFilter.png | Another precise GPS vs Filtered GPS data
</gallery>

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].
This way positional inaccuracies may be added to the overall depth measurement inaccuracy.

== Quality rating ==

Each record (time, positon, depth) should become a quality rating.

=== Points ===

Derived from the Fibonacci series.

{| class="wikitable"
! Point || Description
|-
| 1 || extra small improvement
|-
| 2 || small improvement
|-
| 3 || medium improvement
|-
| 5 || large improvement
|-
| 8 || extra large improvement
|}

=== Factors ===

{| class="wikitable"
! style="width:15%" | Name
! style="width:17%" | Factor
! style="width:68%" | Description
|-
| depth offset || 8 (extra large) || The difference between the depth measured by the echo sounder and the depth (waterline) measured by hand.
|-
| device distance || 3 (medium) || The distance between gps antenna and echo sounder (lengthwise and crosswise).
|-
| SBAS || 3 (medium) || Satellite based augmentation system (WAAS, EGNOS, MSAS) which allows to correct the gps position.
|-
| 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.
|}

= Depth Rendering =

= Siehe auch =
* [[De:Bordnetz|Bordnetz]]
* [[De:NMEA-Logger_anschliessen|NMEA-Logger_anschliessen]]
* [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]
* [http://users.isr.ist.utl.pt/~pedro/publications/CAMS10.pdf A Multiple Model Adaptive Wave Filter for Dynamic Ship Positioning]

OpenSeaMap-dev:En:Depth Data

2012-10-22T19:09:40Z

Cleanerx: /* Data Preprocessing */

This Page describes the necessary efforts to retrieve and analyze depth data as well as create renderings from it

= Data Aquisition =
Depth data can be retrieved from public domain sources or from crowd sourced data.

== GEBCO ==
DIe Daten sind gerendert und stehen als Layer zur Verfügung:
{| class="wikitable"
! Zoom || Inhalt
|-
| 0..10 || Blaustufen und Schattierung
|-
| 11..18 || beschriftete Tiefenlinien, Blaustufen und Schattierung
|}

Noch zu lösende Probleme:
* der GEBCO-Layer erzeugt einen milchigen Schleier über der Basiskarte
* Tiefenlinien sind ab z=14 etwas grob (also ab da, wo dann die Flachwassertiefen beginnen) [http://dev.openseamap.org/website/map/#?zoom=14&lat=36.03097&lon=-5.49153&layers=BFTFTTTFFFF0]
* Überschneidungen von 100m-Linie und Küstenlinie [http://dev.openseamap.org/website/map/#?zoom=15&lat=36.00318&lon=-5.60819&layers=BFTFTTTFFFF0]
* Steilküsten (Cuba) [http://dev.openseamap.org/website/map/#?zoom=14&lat=19.94808&lon=-76.04289&layers=BFTFTTTFFFF0]

== Crowd Sourced Data ==
Crowd sourced data may be gathered by YOU. There are two options in development. A hardware and a software option.

=== Hardware logger ===
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.
That data may then be uploaded by plugging the SD card to a normal computer with internet connection for upload.
The main goal is to support NMEA 0183 data with options for NMEA 2000.

=== Software logger ===
A Software logger is in development and [http://seesea.sourceforge.net/datalogger/index.html can be retrieved here].

It currently supports:
: Bluetooth
: serial ports
retrieving NMEA 0183 data ([[De:NMEA-Logger_anschliessen|Bridge needable]])

IP Support and NMEA 2000 development is underway.

=== Upload Process ===
[[OpenSeaMap-dev:Crowd_Sourced_Depth_Data|You'll find further information here]].

= Data Preprocessing =

== Data Condition ==
Raw data is usually erronous and must be corrected

=== Internal data problems ===
Depth data may be affected by electrical conditions and software implementations
* Data is incomplete and fail their checksum (bus errors from physical transmissions errors)
* Data is erronous sensor data
** Approximate correctable data i.e. invalid GPS position that may be interpolated
** Uncorrectable data i.e. failed log sensor that shows slow speeds
* Data resolution is low i.e. for energy saving purposes GPS position is updated every 10 seconds instead of every second
* Sensor data is actively miscalibrated i.e. charter companies add additional draft to the sensor depth for safety reasons

=== External data problems ===
Depth data may be affected by different environmental circumstances
* The water temperature affects the ultrasound echo. An inhomogen water temperature yields unwanted echos
* The seabed affects the ultrasound echo
* The seastate affects the measurement. There even may be waves when there is no wind.
* Waves may affect the roll of the measuring vessel resulting in steep measurements that are invalid.
* The sounder sensor is not the position of the GPS antenna. A position offset including heading must be incorporated.
* 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.

== Solution Proposal ==

=== Outline ===
The ship is influenced by the outlined environment which can be observed. Naturally what is observed is not the state of the
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.

=== Details ===
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.

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.

Todo:
* Construct ship system model with at least the position state and probably its course and speed or even more (depth)
* Estimate the system variance (This is a hard one, proposals welcome)
* Construct the measurement model according to the data available (GPS, Log)
* Estimate the measurement noise according to specifc sensors (DPGS is more accurate than GPS)

The estimation with the position and depth can be retrieved and stored in a database.

Pitfalls:
* If the system noise is badly chosen the estimation of the system state does not converge to the true state / measurement.
* If the system is very detailed the system variance can be reduced. The required cpu time for processing increases

Benefits:
* Having the best estimation of the true position even if measurements are noisy
* Easy and effective algorithmic processing

== Analysis ==

=== Data Sets ===
Currently two test data sets are available recorded during trips from Mallorca and the Baltic Sea.
In terms of data quality the Mallorca data shows many challenges.
* The minimum recommended sentences from NMEA showed up with false date and time readings while having correct (!!!) message checksums.
* The log on the ship was defective and delivered no readings from time to time.
* The same holds true for the water temperature.
* The GPS positions relatively imprecise because some last decimal digits are missing in the recordings.
* The GPS positions are updated every 10 seconds while other sensor readings update almost every second.
* The GPS position are sometimes way off due to false readings

The Baltic Sea data set is a little bit better
* Only a single day is available
* GPS positions are updated every second

One problem with the data is that there is time available when sensor readings were recorded. This yields problems to the filter algorithm.

=== Filter Algorithm ===
At first the Extended Kalman Filter is being analyzed. Using an apache implementation with the available data the filter quickly throw an exception that
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.
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
we may consider that for the future.

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
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.

== Results ==
A prototype implementation is shown in the following screenshots. An Extended Kalman Filter is being used. It has the position
and the current bearing and velocity as system state. The input is the measurement of these four observables. The system function is
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.
The initial state is taken from the first measurement for convergence reasons.

The following gallery shows the results.
* You can see the bad position resolution and an outlier in the first screenshot.
* The second shows the same data overlaid with the applied filter. The outlier is gone and the resolution has improved.
* The third screenshot shows data from a different GPS sensor with more precision (not DGPS) versus the filtered data.

This of course is just a preliminary test and many setups need to be considered to make it work for most datasets.

<gallery>
UnfilteredNMEA.png | Unfiltered GPS data
FilteredNMEAVsOriginal.png | Unfiltered GPS data and Filtered GPS data
PreciseGPSvsFilter.png | Another precise GPS vs Filtered GPS data
</gallery>

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].
This way positional inaccuracies may be added to the overall depth measurement inaccuracy.

== Quality rating ==

Each record (time, positon, depth) should become a quality rating.

=== Points ===

Derived from the Fibonacci series.

{| class="wikitable"
! Point || Description
|-
| 1 || extra small improvement
|-
| 2 || small improvement
|-
| 3 || medium improvement
|-
| 5 || large improvement
|-
| 8 || extra large improvement
|}

=== Factors ===

{| class="wikitable"
! style="width:15%" | Name
! style="width:17%" | Factor
! style="width:68%" | Description
|-
| depth offset || 8 (extra large) || The difference between the depth measured by the echo sounder and the depth (waterline) measured by hand.
|-
| device distance || 3 (medium) || The distance between gps antenna and echo sounder (lengthwise and crosswise).
|-
| SBAS || 3 (medium) || Satellite based augmentation system (WAAS, EGNOS, MSAS) which allows to correct the gps position.
|-
| 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.
|}

= Depth Rendering =

= Siehe auch =
* [[De:Bordnetz|Bordnetz]]
* [[De:NMEA-Logger_anschliessen|NMEA-Logger_anschliessen]]

OpenSeaMap-dev:En:Depth Data

2012-10-22T18:44:41Z

Cleanerx: /* Solution Proposal */