20000406: basic topology and the Data Model with geo-locations

• To: Doug Lindholm <lind@xxxxxxxx>
• Subject: 20000406: basic topology and the Data Model with geo-locations
• From: Don Murray <dmurray@xxxxxxxxxxxxxxxx>
• Date: Fri, 07 Apr 2000 08:11:58 -0600

>From: Doug Lindholm <lind@xxxxxxxx>
>Organization: NCAR
>Keywords: 200004062254.QAA25385

Hi Doug-

>> Actually, there isn't an intrinsic for LatLonAlt (but it
>> would be nice).  The SpatialEarth*DTuple intrinsics are
>> (lon, lat) and (lon, lat, alt), but the coordinate systems
>
>Sorry, those are my fault. ;-) But I use them every day.

No need to apologize.  Different strokes for different folks. ;-)

>OK, I am quite ignorant on the CoordinateSystem class. As I understand
>it, I can have one field with domain (lon, lat, alt) and another with
>(x,y,z) and they would work together if (x,y,z) were created with the
>appropriate CoordinateSystem mapping (x,y,z) to (lon, lat, alt). Am I
>close? Does that mean I could resample the first field with a set of the
>type (x,y,z)? What about a CoordinateSystem that would allow co-mingling
>of (lon, lat, alt) and (lat, lon, alt)? Am I missing the boat here? I'd
>sure like to be able to resample with different yet topologically
>consistent sets. And I'd like to be able to add my (x,y,z) field to my
>display with (Longitude -> XAxis)... maps without having to add (x ->
>XAxis)... maps.

Just want to add a little more to what Bill said.

In the field of meteorology, gridded data are often expressed in terms
rows/columns rather than lat/lon. An example of how the CoordinateSystem
idea is useful is to look at the visad.jmet.ShowNCEPModel application.
Data are read in from netCDF files where in some cases all you have
is a GRIB grid type (i.e. projection) and a set of values at row, column
(x,y or i,j) coordinates. To be able to meaningfully use these data with
data on other projections with different spacings, (ex: satellite
image), you can use CoordinateSystems in the Domain for both sets
of data that will have a common reference of (lat,lon) (or (lon, lat) if
you prefer). In ShowNCEPModel, a GRIBCoordinateSystem is created based
on the model projection id (or other parameters in the netCDF file) that will
translate (i,j) into (lat,lon). For a satellite image which has values
of (ImageElement, ImageLine), the AREACoordinateSystem can translate
these to (lat,lon). Since both have the same reference (lat,lon), then
you could have a a display that maps RealType.Latitude -> Display.YAxis
and RealType.Longitude -> Display.XAxis, and add the grid and image
to the display through dataReferences, and they will display with no
problem. There is no need to convert the grid and image to lat/lon
coordinates first.

Another power of this is that if I wanted to get values from the
image and/or grid at a particular lat/lon point, I can use (if they
are both fields) evaluate(Set(Lat, Lon)) to pick out values.
So, if you wanted to have a display where the user could click on
a point, you could get the lat/lon of that location (since you've
mapped your display to Lat and Lon) and then sample the data at
that point.  

And, as Bill said, you can add/subtract/divide (whatever you want
to do) the two fields since they both have the same reference.

Hope that helps show the power of the CoordinateSystem class in
the context of the work you are doing.

Don
*************************************************************
Don Murray                               UCAR Unidata Program
dmurray@xxxxxxxxxxxxxxxx                        P.O. Box 3000
(303) 497-8628                              Boulder, CO 80307
*************************************************************
Unidata WWW Server               http://www.unidata.ucar.edu/
McIDAS Demonstration Machine  http://mcdemo.unidata.ucar.edu/
*************************************************************