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.
http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage_062009
