Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Hello John Le 03/02/11 18:30, John Caron a écrit :
i guess whats missing is a method to convert lat/lon on one ellipsoid to lat/lon on another?
Close. A method to transform lat/long on one *datum* to lat/lon on another.Many different datum may exist for the same ellipsoid. The ellipsoid axis length alone are not suffisient.
(minor note: in ISO 19111 terminology, this is a "transformation", not a "conversion". A Map projection is a "conversion" but a datum shift is a "transformation". The difference is that conversions are determined by mathematical formulas with infinite (in theory) precision while transformations are determined by empirical parameters with statistical errors).
However there is no generic method for doing the above transformation. Datum shift require empirical parameters (typically the "Bursa-Wolf parameters", but other methods are possible) which need to be stored in some kind of database (a real database like the http://www.epsg.org one, or a text file, etc.).
On a related note, the GeoAPI 3.0 interfaces are now going through the final voting process (after much delay for reasons that we don't control) in the Open Geospatial Consortium. ESRI, CNES (a French space agency) and other are among the submitters. I would suggest to set the NetCDF referencing classes as implementation of GeoAPI interfaces (I can provide help for that if you wish), so NetCDF users can start with a relatively "lightweight" referencing implementation, while other implementations are possible. For example the Geotoolkit.org referencing module alone (not including dependencies like ISO 19115 metadata) is a 900 kb JAR file, which suggest that referencing stuff may complex enough to allow the possibility to use exernal libraries.
Regards, Martin
netcdf-java
archives: