S-57 data: Difference between revisions

From GRASS-Wiki
Jump to navigation Jump to search
mNo edit summary
 
(One intermediate revision by one other user not shown)
Line 12: Line 12:


=== Worldwide ===
=== Worldwide ===
(written in 2008 by HB)


* Often this is problematic, which is a real shame because lives depend - in a very real way - on universal access to good chart data. My frustrated take (rant?) on the matter:
* Often this is problematic, which is a real shame because lives depend - in a very real way - on universal access to good chart data. My frustrated take (rant?) on the matter:
: ''The hydrographic offices of many countries, and their associates, earn significant revenue from selling nautical chart data back to the tax payers who funded them in the first place, and they are as a whole loathe to give that up. This follows on from a tradition of selling paper charts, which did have substantial printing and distribution costs. But for electronic charts the primary cost of production is shifted the maintenance of the bathymetric survey and light lists, which must be borne as a fixed cost anyway. There are some justified worries about outdated or invalid data being used for navigational purposes, but in this sailor's opinion an out of date chart is worlds better than no chart at all; money spent on fragile fail-dangerous software is money not spent of the upkeep of the boat; we all know full well what "Not for navigational purposes" means (and that is mostly irrelevant for GIS work anyway); and cryptographically signed data packages (e.g. MD5 checksums) have been around and in wide use for more than a decade, ensuring that the end-user's data has not been corrupted or altered, without requiring a closed system. If you live in a country so effected, probably the best you can do is have your local OSGeo chapter &/or institution complain en masse to your national geospatial information office, citing the United States's NOAA as an example which can not be ignored. Even if they will sell you the data it will typically be encrypted in a form which will require one of their proprietary vendor-partners' software, OS, and typically a hardware dongle which can not be repaired or replaced at sea. These "DRM" tactics are fundamentally incompatible with almost all Free and Open Source software licenses (and goals) so there is little hope of a FOSS solution without action from higher up in the government. [http://www.gdal.org/ogr OGR]'s S-57 reader can not decrypt this data even if you own it; the IHO's technical committees are dominated (and often lead) by representatives of the established commercial vendors which have a vested interest in keeping the barrier to entry high.''
: ''The hydrographic offices of many countries, and their associates, earn significant revenue from selling nautical chart data back to the tax payers who funded them in the first place, and they are as a whole loathe to give that up. This follows on from a tradition of selling paper charts, which did have substantial printing and distribution costs. But for electronic charts the primary cost of production is shifted the maintenance of the bathymetric survey and light lists, which must be borne as a fixed cost anyway. There are some justified worries about outdated or invalid data being used for navigational purposes, but in this sailor's opinion an out of date chart is worlds better than no chart at all; money spent on fragile fail-dangerous software is money not spent of the upkeep of the boat; we all know full well what "Not for navigational purposes" means (and that is mostly irrelevant for GIS work anyway); and cryptographically signed data packages (e.g. MD5 checksums) have been around and in wide use for more than a decade, ensuring that the end-user's data has not been corrupted or altered, without requiring a closed system. If you live in a country so effected, probably the best you can do is have your local OSGeo chapter &/or institution complain en masse to your national geospatial information office, citing the United States's NOAA as an example which can not be ignored. Even if they will sell you the data it will typically be encrypted in a form which will require one of their proprietary vendor-partners' software, OS, and typically a hardware dongle which can not be repaired or replaced at sea. These "DRM" tactics are fundamentally incompatible with almost all Free and Open Source software licenses (and goals) so there is little hope of a FOSS solution without action from higher up in the government. [http://www.gdal.org/ogr OGR]'s S-57 reader can not decrypt this data even if you own it; the IHO's technical committees are dominated (and often lead) by representatives of the established commercial vendors which have a vested interest in keeping the barrier to entry high.''


=== Cananda ===
=== Canada ===


* ...
* ...

Latest revision as of 05:32, 15 December 2014

More to come

Basics

(see the mailing list posts linked at the end of that page):
http://thread.gmane.org/gmane.comp.linux.gps/3920/focus=3937
http://thread.gmane.org/gmane.comp.linux.gps/3920/focus=3934

Obtaining data

Worldwide

(written in 2008 by HB)

  • Often this is problematic, which is a real shame because lives depend - in a very real way - on universal access to good chart data. My frustrated take (rant?) on the matter:
The hydrographic offices of many countries, and their associates, earn significant revenue from selling nautical chart data back to the tax payers who funded them in the first place, and they are as a whole loathe to give that up. This follows on from a tradition of selling paper charts, which did have substantial printing and distribution costs. But for electronic charts the primary cost of production is shifted the maintenance of the bathymetric survey and light lists, which must be borne as a fixed cost anyway. There are some justified worries about outdated or invalid data being used for navigational purposes, but in this sailor's opinion an out of date chart is worlds better than no chart at all; money spent on fragile fail-dangerous software is money not spent of the upkeep of the boat; we all know full well what "Not for navigational purposes" means (and that is mostly irrelevant for GIS work anyway); and cryptographically signed data packages (e.g. MD5 checksums) have been around and in wide use for more than a decade, ensuring that the end-user's data has not been corrupted or altered, without requiring a closed system. If you live in a country so effected, probably the best you can do is have your local OSGeo chapter &/or institution complain en masse to your national geospatial information office, citing the United States's NOAA as an example which can not be ignored. Even if they will sell you the data it will typically be encrypted in a form which will require one of their proprietary vendor-partners' software, OS, and typically a hardware dongle which can not be repaired or replaced at sea. These "DRM" tactics are fundamentally incompatible with almost all Free and Open Source software licenses (and goals) so there is little hope of a FOSS solution without action from higher up in the government. OGR's S-57 reader can not decrypt this data even if you own it; the IHO's technical committees are dominated (and often lead) by representatives of the established commercial vendors which have a vested interest in keeping the barrier to entry high.

Canada

  • ...

USA

  • Free ENC vector data for the USA from NOAA
http://nauticalcharts.noaa.gov/mcd/enc/download.htm
  • Nice previews / chart picker:
http://www.oceangrafix.com/o.g/search-nautical-charts.html

Import

  • Use a Lat/lon WGS84 location
Select "create new location from georeferenced file", using the ENC *.000 file. It's just lat/lon WGS84, so you could create a new location by EPSG code (4326) or by custom entry too. Another automatic way (from within grass) is to use v.in.ogr's location= option.
  • Unzip dataset
unzip NOAA_ENCs440569.zip
  • test dataset with ogrinfo
ogrinfo --formats | grep S57
ogrinfo ENC_ROOT/US3NY01M/US3NY01M.000
  • Try to load and view it with a nice viewer like OpenEV or libS52's s52glx test app
  • Import S-57 data into GRASS GIS (grass.osgeo.org) with v.in.ogr
  # change default database from DBF to SQLite as it is less lossy
  db.connect driver=sqlite \
     database='$GISDBASE/$LOCATION_NAME/$MAPSET/sqlite.db'

  # import data  (ignore the many string warnings)
  v.in.ogr dsn=ENC_ROOT/US3NY01M/US3NY01M.000 out=noaa_12300
  # have a look
  v.info noaa_12300
  g.region vect=noaa_12300
  # render all features from all layers
  d.mon x0; d.vect noaa_12300

  # view DB columns available for layer 20:
  v.info -c noaa_12300 layer=20

  # browse attribute database
  v.db.connect -p noaa_12326 | head -n1
  sqlitebrowser $MAPSET/sqlite.db

SQLiteBrowser from http://sqlitebrowser.sourceforge.net/

(alternative: Firefox SQLite Manager addon)
  # e.g. land              Layer: LNDARE
  ogrinfo -ro ENC_ROOT/US3NY01M/US3NY01M.000 | grep LNDARE
    20: LNDARE
  d.vect noaa_12300 layer=20 type=area disp=shape,attr attrcol=objnam \
    llayer=20 fcolor=255:200:80
  # e.g. soundings         Layer: SOUNDG   (automated layer by name)
  LAYER=SOUNDG
  LAYER_ID=`ogrinfo -ro ENC_ROOT/US3NY01M/US3NY01M.000 | \
    grep "$LAYER" | cut -f1 -d':'`
    38: SOUNDG (Multi Point)
  d.vect noaa_12300 layer=$LAYER_ID type=point icon=basic/diamond \
    fcolor=yellow size=6
  # e.g. buoys             Layer: BOYSPP
  ogrinfo -ro ENC_ROOT/US3NY01M/US3NY01M.000 | grep BOY
    7: BOYLAT (Point)
    8: BOYSAW (Point)
    9: BOYSPP (Point)
  d.vect noaa_12300 layer=7 type=point icon=basic/circle \
    fcolor=orange size=8
  d.vect noaa_12300 layer=8 type=point icon=basic/circle \
    fcolor=magenta size=8
  d.vect noaa_12300 layer=9 type=point icon=basic/circle \
    fcolor=blue size=8
  • Set zoom, display layers, colors, line widths, labels, etc. in GRASS
(this will take some work)
   # show everything
   NUMLAYERS=`v.db.connect -g noaa_12326 | wc -l`
   for layer in `seq 1 $NUMLAYERS` ; do
       echo "layer=$layer"
       d.vect noaa_12326 layer=$layer \
          color=$((layer*4)):$((layer*4)):$((layer*4)) \
          fcolor=$((layer*4)):$((layer*4)):$((layer*4))
   done
  • Color and symbology standards: see libS52 from OpenEV contrib/ CVS
http://www.iho.shom.fr/ECDIS/s52intro.htm
http://www.iho.shom.fr/publicat/free/files/PresLib_3.3_Addendum_2007.pdf
    e.g. fill color for land is 255:200:80
    d.vect noaa_12326 attrcol=objnam llayer=24 disp=attr \
      layer=24 fcolor=255:200:80

?? For more colors see openev/contrib/S52/doc/C1.lup_collision.txt

Accessing S-52 symbology

S-57 is the data format. The S-52 standard contains the standardized coloring and symbology for electronic navigation charts. We want to view the S-57 data through the lens of the S-52 rules. Some ideas for that:

  • GRASS interface: (wishlist prototype) display imported S-57 data (v.in.ogr or v.external) using S-52's coloring and layer-order info. Some environment will be information like lighting level and hull depth (start at 0) will be needed
  • View with the OpenEV plugin (functional)
  • Create the dataviewer as a QGIS plugin (wishlist user app)


libS52

Example rendering a few base layers:


How to build

  • Install build dependencies
Install OpenGL and X11 -dev packages (X11/Xlib.h and GL/gl.h)
PROJ.4 for proj_api.h?
  • Build it:
make          # for s52glx simple test program
make default  # for libS52

Run simple s52glx test program

  • Get ENC data
  • Edit s52test.conf with the full path to your ENC chart datafile (*.000 file)
  • Run it with ./s52glx and you should see a new window with all layers rendered
  • Screenshots

OpenEV S52 plugin

  • Copy libS52.so to GDAL's lib directory
putting the lib in /usr/local/lib seems to work.
run ldconfig ?
  • Configure OpenEV with render plugin support:
CFLAGS='-I/usr/include/gdal' CPPFLAGS='-I/usr/include/gdal' \
  ./configure --with-double-geocoord --with-render-plugin

make
Test S52 plugin with OpenEV
  • Set environment variables
export S57_CSV=/usr/share/gdal
export OGR_S57_OPTIONS="LNAM_REFS:ON,UPDATES:ON,\
SPLIT_MULTIPOINT:ON,PRESERVE_EMPTY_NUMBERS:ON,\
RETURN_LINKAGES:ON"
  • Using gvtest:
./openev/gvtest -ogr=/path/to/ENC_ROOT/US3NY01M/US3NY01M.000 
  • Using s52test:
(s52test.conf will need ENC path adjusted)
./openev/contrib/S52/s52test


  • [??] Using pymod/openev.py:
(Open .000 file, load all layers)
export PYTHONPATH="/usr/lib/python2.4/site-packages/gtk-1.2"
python2.4 ./openev/pymod/openev.py

GRASS S-52 interface for rendering S-57 data

  • TODO
  • build little command line app to output coloring and layer order info which can be fed to d.vect et al?
Colors:
(S-52 bright mode, click to enlarge)

Specific color RGB-equivalent values can be found in the OpenEV contrib libS52 docs:

http://openev.cvs.sourceforge.net/openev/contrib/S52/doc/C1.lup_collision.txt
scroll down to "S52_dummy.BRIGHT" section of the file (not quite right?? above is based on that)

The above is just the "bright" color mode. There are also reverse background, low light, and nightime (red/black) color modes. Look in the libS52 code to convert those from CIE luminance into RGB colorspace. (S52GL.c?)

Color abbreviation key may be found in the IHO PDF document

S-52 Appendix 2 - Colour and Symbols Specifications for ECDIS, Edition 4.3, January 2008
Table 3: "Alphabetical list of colour tokens" (page 49)

for example:

DEPVS = 131:184:224 = Depth (very shallow)
DEPMS = 166:198:227 = Depth (medium shallow)
LANDA = 211:187:121 = Land (not built up)
CSTLN = 140:144:138 = Coastline

QGIS S-52 plugin for viewing S-57 data

  • Status: TODO
  • QGIS reads S-57 data via GDAL's OGR driver, but it aborts because it doesn't know what to do with all the layers. I suspect getting this working at a basic level only requires a minimal amount of work from an interested programmer.
  • Integrate libS52 as a plugin.
QGIS plugins can be written as C++ or Python. For python use SWIG to access libS52?
  • please add ideas here ...

See also

importing and working with BSB charts