1 / 22

NetCDF to GIS: the Good, the Bad, and the Ugly

NetCDF to GIS: the Good, the Bad, and the Ugly. John Caron, Unidata/UCAR Stefano Nativi, University of Florence. Acknowledgements. Yuan Ho (Unidata) for netCDF/GeoTIFF development Giacomo Villoresi (Florence) for WCS package development

millie
Download Presentation

NetCDF to GIS: the Good, the Bad, and the Ugly

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. NetCDF to GIS: the Good, the Bad, and the Ugly John Caron, Unidata/UCAR Stefano Nativi, University of Florence

  2. Acknowledgements • Yuan Ho (Unidata) for netCDF/GeoTIFF development • Giacomo Villoresi (Florence) for WCS package development • Jeff Weber (Unidata), Roland Schweitzer and John Cartwright (PMEL) for testing • Steve Kopp (ESRI) for technical help

  3. Early experiences in creating a Web Coverage Service for scientific data stored in netCDF files.

  4. Geographic Information Systems • Relational database with spatial capabilities • “Find all that are contained in a lat/lon bounding box” • “Two and a half” dimensional • Effort to use 4D (time, vertical) data

  5. Web Coverage Service (WCS) • Client-server protocol for “coverage” data • XML over HTTP / SOAP • From Open GIS Consortium (OGC) • Industry/government consortium for creating interoperable standards for GIS • Specification version 1.0 (August 27, 2003) • No client or server reference implementations • Not yet available to public

  6. OGC Web Services (OWS) • Features: info associated with an area (WFS) • polylines with attributes • Maps: 2D images (WMS) • images in JPEG, GIF • Coverage: satellite images, model output • Floating data values • Vertical and time dimensions • Subset, resample, reproject operations • All are georeferenced

  7. Familiar Land of Scientific Data Strange land of Geographic Information Systems (GIS) GIS Client WCS Server

  8. WCS interface • Client has a WCS server URL • Make GetCapabilities request • contact, access, fees, etc • list of coverages • label, desc, keywords, lat/lon BB, xlinks • no controlled vocabularies for label, keyword • DescribeCoverage for detailed info • GetCoverage to get data

  9. WCS: DescribeCoverage • Domain: space/time location of the data • bounding polygon or coordinates • Range: type of data, units, scalar/vector • Supported coordinate reference systems • Supported data formats • Supported interpolations • nearest neighbor, bilinear, etc; may be none

  10. WCS: GetCoverage • which coverage • space/time subset using bounding box • specify data resolution (resample) • specify coordinate reference system (reproject) • specify data format

  11. WCS: Good • Clean protocol design • XML/SOAP/HTTP standards • Server/client versioning • Data model • working towards compatibility with ISO • Adequate data semantics • Vertical and time dimensions • Subsetting, resampling, reprojecting • Have georeferencing!

  12. WCS: Bad / Limitations • Regular spaced grids • Homogenous ranges (eg wavelength) • Flat dataset namespace • Granularity issues • Escape to search service • Alternative: nested collections

  13. Ugly: getting the actual data • Must support at least one data format: • GeoTIFF (TIFF with geospatial tags) • HDF-EOS (HDF4 plus NASA metadata) • DTED (NIMA/DOD digital elevation) • NITF (NIMA/DOD images) • GML (OGC XML data encoding) • Not clear what you’ll actually get back • No support for data format version?

  14. NetCDF • General purpose scientific data format • Multidimensional arrays of numbers • Shared, named Dimensions for array indices • Arbitrary name/value attributes • Working to merge with HDF5 file format • Work closely with OpenDAP client/server

  15. NetCDF/HDF5/OpenDAP • Data models do not have integrated coordinate systems, so georeferencing not part of API • Need attribute conventions to specify • Bad DOG!

  16. NetCDF File OpenDAP Dataset WCS netCDF server Convention Parser GeoTIFF GeoTIFF WCS Client WCS Server XML THREDDS Catalog tomcat web server

  17. THREDDS data server NetCDF File OpenDAP Dataset WCS netCDF proxy server THREDDS Catalog register Convention Parser GeoTIFF WCS Client GeoTIFF WCS Server XML tomcat web server

  18. Good and Bad • Put Convention parsing on the server • Client need not know anything • Server code knows the convention • Can provide a remote service to other data servers • Not generic THREDDS Catalog/netCDF dataset

  19. Problems with GeoTIFF • Evenly spaced grids • Floating data format is optional for readers • longitude ranges +/- 180 • No standard for time series / 3D • one image per file • No active authority/user group to resolve problems or evolve new standards • Workarounds • Guess at tags, try out different clients • Resample if grids are irregular

  20. WCS: should we bother? • immature specification • no reference implementations • no working examples yet • good XML/HTTP client/server protocol • standard, not extraordinary. • data model is quite valuable • the georeferencing is thorough, • eventual integration into ISO standards.

  21. WCS: data transfer formats • five or more data transfer formats • data format remains unclear • The georeferencing info is specified twice, once in the XML in the WCS protocol and also in the data format. • Possible solution: extend GML to allow binary data, specify the georeferencing once in GML. • Recommend the simplicity of the netCDF data model

  22. Contact Google THREDDS WCS caron@unidata.ucar.edu nativi@unidata.ucar.edu

More Related