S-57 data: Difference between revisions
m (→Obtaining data) |
|||
(8 intermediate revisions by 5 users not shown) | |||
Line 13: | Line 13: | ||
=== 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: | |||
: ''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.'' | |||
=== | === Canada === | ||
* ... | * ... | ||
Line 219: | Line 222: | ||
* please add ideas here ... | * please add ideas here ... | ||
== See also == | |||
* [[BSB_data|Using rasterized navigation charts (RNC) with GRASS]] | |||
: importing and working with BSB charts | |||
[[Category: Geodata]] | |||
[[Category: Import]] |
Latest revision as of 05:32, 15 December 2014
More to come
Basics
- Import with v.in.ogr
- There is some more info and links on the Export for GpsDrive wiki page
- (see the mailing list posts linked at the end of that page):
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
- Nice previews / chart picker:
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
- GPL library
- housed in OpenEV CVS as contrib/S52/
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