NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
John, As a follow up to my posting of the NetCDF-Java/CF projection to GeoTools/GeoAPI converter utility posting. As background we are doing geoprocessing of vector geometries obtained from Shapefiles or GML (often via WFS). Given the large number of CRS that maybe used with these vector geometries (relative to what's available with CF) and the desire to perform the calculations in the CRS used with the vector geometries we generate a GeoTools/GeoAPI CRS instance so that we can transform the CF grids into the vector geometry CRS. An issue we have with NetCDF-Java is that not the NetCDF-Java Projection instance isn't passing through the ellipsoid parameters for Projection implementations that don't have transformation to ellipsoids implemented (even though the CF spec. Ideally we could extract these from Projection.getProjectionParameters() so that we can generate a fully parameterized GeoAPI CoordinateReferenceSystem instance which will then use these parameters. Given the abstraction of GridDatatype/GridCoordSystem is very difficult to extract these parameters from the original CF grid_mapping. Could we get these parameters (semi_major_axis, semi_minor_axis and inverse_flattening) in the Projection instance for all Projections if they are in the grid_mapping for the grid? One thing i've been hoping to do is implement a ProjectionProviderFactory type architecture for NetCDF-Java that would allow the implementation of NetCDF-Java Projection instances using GeoTools or Geotk. One could register a factory using a service registration mechanism then get back Projection implementations back by their API of choice. This would remove the need for NetCDF-Java to re-implement projection transformations that are already implemented in GeoTools or Geotk. The CRSUtility class I provided earlier could be the foundation/crosswalk for a GeoToolsProjectionProviderFactory. One can easily generate transforms and their inverses once the CoordinateReferenceSystem instance is generated. These transforms can the be wrapped in a NetCDF-Java Projection instance This would also allow CF to incorporate new projections and minimize implementation time in NetCDF-Java. Tom Kunicki Center for Integrated Data Analytics U.S. Geological Survey 8505 Research Way Middleton, WI 53562
netcdf-java archives: