This is basically correct, although much of the work is done for you in
the ucar.nc2.dataset.conv package. A lot depends on what information is
already in the netccdf file.
From: John del Corral <jdcorral@xxxxxxxxxxxxxxxx>
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-31 i686)
CC: benno@xxxxxxxxxxxxxxxx, jdcorral@xxxxxxxxxxxxxxxx
Subject: Question about NcML Coordinate System and OpenGIS
Content-Type: text/plain; charset=us-ascii
I had a question about the NcML Coordinate System and how
it can incorporate the OpenGIS EPSG projections (see
I was reading the information about the NcML Coordinate System 1.0
and the AWIPS NcML example. It looks like the process of incorporating
projection into NcML requirs 4 steps:
1) Define the coordinateTransform using parameters
2) Define x,y coordinateAxes with an axisType of 'GeoX' and 'GeoY'
3) Define a coordinateSystem using the coordinate...Refs
4) Specify the coordinateSystem for each variable in the file
I would like to know if this is the correct approach for me to take
and if you have an example of using an OpenGIS EPSG projection in NcML.
This may be a naive question, but will it be possible in future releases
of NcML to incorporate OpenGIS projections in a less complicated
structure? Possibly a common reference file or library like udunits?
or some other type of a more direct reference?
NcML Coordinate System is a very simple first pass at representing this
information. Stefano Nativi has proposed a more comprehensive XML
encoding, and we will be working on that again this summer.
However, one can use NcML Coordinate System as they are now. A
coordinateTransform XML element is really just a container for
name/value parameters of things like projections. The names and meanings
of those parameters are arbitrary, and are intended to be specified by
some outside "authority", in your case "EPSG".
Heres a possible example I made up based on this entry of the above table:
PROJCS["Belge 1950 (Brussels) / Belge Lambert 50",GEOGCS["Belge 1950 (Brussels)",DATUM["Reseau_National_Belge_1950",SPHEROID["International
<nc:coordinateTransform name="Belge 1950 (Brussels)" authority="EPSG"
<nc:parameter name="Datum" type="string"
<nc:parameter name="Spheriod" type="string" value="International
<nc:parameter name="Projection" type="string"
<nc:parameter name="standard_parallel_1" type="double"
<nc:parameter name="standard_parallel_2" type="double"
<nc:parameter name="latitude_of_origin" type="double" value="90.0" />
<nc:parameter name="central_meridian" type="double" value="0" />
<nc:parameter name="false_easting" type="double" value="150000" />
<nc:parameter name="false_northing" type="double" value="540000" />
<nc:parameter name="unit" type="string" value="metre" />
<nc:parameter name="EPSG" type="string" value="21790" />
So you get the idea, this is not so hard, although Stefano's encodings
carry much more semantic information.
There are 2 other parts to the problem that are much harder:
1) Where does this information come from? As it stands now, it is placed
into the netcdf file using some convention, and then some softwrae knows
how to read that convention and construct the NcML Coordinate System.
2) Given the EPSG Coordinate Transform information, we need a software
library that can do the mathematical transformations between projection
coordinates and lat/lon. We have done a few of the most popular
projections in the ucar.unidata.geoloc.projection package.
Both require some framework that application software can use. If you
are interested in adding EPSG projections in the context of the
java-netcdf library, that would be very exciting for us.