Thanks for everyone's thoughts on this. A few random comments:
We have to recognize individual datasets' Conventions, so its important
to be clear which datasets/Conventions are using degrees_west.
When no Conventions are present, the "default" coordinate builder can
look for degrees_west (and variants like Joe mentioned).
We cant change CF Conventions unilaterally, so if anyone thinks its
important that the CF conventions accept degrees_west, they should
propose that to the committtee. CF was started mostly by the global
climate modeling community, so they apparently prefer degrees_east.
All our projection implementations use degrees_east, not sure why other
than thats how the reference books like Snyder present them. So when we
recognize degrees_west, we have to multiply by -1 whenever we use
projections.
Im not sure what NCEP uses in its GRIB file output, but if it uses
degrees_west we are converting to degrees_east.
Im not sure if visualization software like the IDV wants to see
degrees_west or wants them converted to degrees_east.
Barry Herchenroder wrote:
I totally agree with Don.
Its rare in my experience that Met and Ocean models use
degrees E for longitude, except perhaps in non-U.S.
regions. Rather degrees W is almost universally used
for areas in and near the U.S.
I ran into a model for a near U.S. region, an NRL Oceanographic
model for the Gulf of Mexico, that uses degrees E for the first
time a month or two ago. I can see the U.S. Navy using degrees E
because they have models for regions around the world and it
would be a pain to have degrees E and degree W longitude. But
that use of degrees E is an exception. For areas in and near the
U.S., degrees W longitude is almost always used.
Barry
*************************************************
Barry E. Herchenroder Ph.D
Senior Scientific Application Consultant
High Performance Computing and Scientific
Visualization
Lockheed Martin Information Technology
(Contractor to the EPA)
EPA Environmental Modeling and
Visualization Lab.
Research Triangle Park, NC 27711
home email: beh80@xxxxxxxxxxx
work email: herchenroder.barry@xxxxxxx
home phone: 919-874-9980
work phone : 919-541-1991
cell phone: 919-606-9245
"My opinions do not necessarily reflect
the opinions of the EPA or Lockheed Martin."
> Date: Sun, 21 Jun 2009 06:38:14 -0600
> From: dmurray@xxxxxxxxxxxxxxxx
> To: Joe.Sirott@xxxxxxxx
> CC: netcdf-java@xxxxxxxxxxxxxxxx
> Subject: Re: [netcdf-java] Longitude unit degrees_west not recognized
>
> By convention, McIDAS datasets all use degrees_west for their longitude
> values. I think that the netCDF-Java should support this (just like it
> supports "CF" files without the required lat/lon coordinates when there
> is a addition to the grid_mapping). I also think it's reasonable for
> CF to support this since it is a valid udunit for longitude.
>
> Don
>
> Joe Sirott wrote:
> > Hi John,
> >
> > There are a lot of legacy oceanographic in-situ datasets out there
that
> > use the EPIC netCDF convention
> > <http://www.epic.noaa.gov/epic/document/convention.htm> which in turn
> > recommends use of "degree_west" (note the missing "s") for the
> > longitude units attribute.I've found that you need support the 8
> > combinations (degree_west, degrees_west, ...) of lat/lon unit
attributes
> > in order to reliably handle these kind of datasets. In practice, EPIC
> > datasets are even more complicated as there is an "epic_code"
attribute
> > that independently specifies the units for the variable. Some
datasets
> > only have the epic_code attribute, some have both, and some (as yet
> > another proof of Murphy's Law) have an epic_code attribute that
> > conflicts with the units attribute.
> >
> > It would be great (at least for me!) if netCDF-java supported all of
> > these attributes. However, I don't think they should be added to
CF, as
> > this would make CF even more complicated than it already is and I
think
> > that most data providers should be encouraged to use the
> > degrees_east/degrees_north convention.
> >
> > - Joe
> >
> > John Caron wrote:
> >> Tom Whittaker wrote:
> >>> We have some point data that has positive-west longitude values. It
> >>> appears that netcdf-java (and perhaps the CF conventions) do not
> >>> support a unit of "degrees_west". This seems inconsistent, since
> >>> degrees_east is supported. While I assume we can work arround
this by
> >>> adding a scale_factor attribute with a -1.0 value, I would encourage
> >>> you to consider this as a valid unit. (I also wonder if
> >>> "degrees_south" are recognized? I did not check this.....)
> >>>
> >>> Thanks.....
> >>>
> >>
> >> Hi Tom:
> >>
> >> CF does not recognize degrees_west (nor degrees_south). You could
> >> propose adding that to CF, which would be the best easy to solve it
> >> from our POV.
> >>
> >> One thing that complicates it is that degrees_north, degrees_east
> >> units is the way to recognize lat/lon coordinates. so now
> >> degrees_west, degees_south would also be.
> >>
> >> Can you give me some background on what datasets are likely to be
> >> using these units?
> >>
> >> _______________________________________________
> >> netcdf-java mailing list
> >> netcdf-java@xxxxxxxxxxxxxxxx
> >> For list information or to unsubscribe, visit:
> >> http://www.unidata.ucar.edu/mailing_lists/
> >
> >
> >
> >
------------------------------------------------------------------------
> >
> > _______________________________________________
> > netcdf-java mailing list
> > netcdf-java@xxxxxxxxxxxxxxxx
> > For list information or to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/
>
> --
> *************************************************************
> Don Murray UCAR Unidata Program
> dmurray@xxxxxxxxxxxxxxxx P.O. Box 3000
> (303) 497-8628 Boulder, CO 80307
> http://www.unidata.ucar.edu/staff/donm
> *************************************************************
>
> _______________________________________________
> netcdf-java mailing list
> netcdf-java@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/
------------------------------------------------------------------------
Hotmail® has ever-growing storage! Don’t worry about storage limits.
Check it out.
<http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage_062009>
------------------------------------------------------------------------
_______________________________________________
netcdf-java mailing list
netcdf-java@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/
