⇐ ⇒

[CF-metadata] CF-metadata Digest, Vol 107, Issue 30

From: ghansham sangar <ghanshamsangar>
Date: Tue, 27 Mar 2012 18:37:38 +0530

Well I think, we are having here Kalpana-1 Data and INSAT-3A and the
upcoming INSAT-3D in India and also have missing values (corresponding the
cold space)
in the auxillary coordinates lat/lon.

Its only in polar orbiting satellites that we must not have NaN values for
auxillary coordiantes but for geostationary its gonna be there.

Another important issue to be discussed is when the resolution of images is
different from the coordinate variables. In MODIS,
such datasets are available.
Similar datasets are also available in Kalpana-1 and Insat-3A too.

regards
Ghansham


On Mon, Mar 26, 2012 at 8:53 PM, <cf-metadata-request at cgd.ucar.edu> wrote:

> Send CF-metadata mailing list submissions to
> cf-metadata at cgd.ucar.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> or, via email, send a message with subject or body 'help' to
> cf-metadata-request at cgd.ucar.edu
>
> You can reach the person managing the list at
> cf-metadata-owner at cgd.ucar.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of CF-metadata digest..."
>
>
> Today's Topics:
>
> 1. Re: CF-1.6 Conformance Requirements/Recommendations
> (Jonathan Gregory)
> 2. Re: CF-1.6 Conformance Requirements/Recommendations
> (Nan Galbraith)
> 3. Re: CF-1.6 Conformance Requirements/Recommendations (John Caron)
> 4. Re: CF-1.6 Conformance Requirements/Recommendations
> (Jonathan Gregory)
> 5. Re: CF-1.6 Conformance Requirements/Recommendations (Randy Horne)
> 6. Re: CF-1.6 Conformance Requirements/Recommendations
> (Nan Galbraith)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 26 Mar 2012 09:24:08 +0100
> From: Jonathan Gregory <j.m.gregory at reading.ac.uk>
> Subject: Re: [CF-metadata] CF-1.6 Conformance
> Requirements/Recommendations
> To: Rosalyn Hatcher <r.s.hatcher at reading.ac.uk>
> Cc: "cf-metadata at cgd.ucar.edu" <cf-metadata at cgd.ucar.edu>
> Message-ID: <20120326082408.GA17750 at met.reading.ac.uk>
> Content-Type: text/plain; charset=us-ascii
>
> Dear Ros
>
> Regarding this requirement:
>
> > 9.6 Where any auxiliary coordinate variable contains a missing value, all
> > other coordinate, auxiliary coordinate and data values corresponding to
> that
> > element should also contain missing values.
>
> Appendix A notes that missing data is allowed in aux coord vars only in the
> case of discrete sampling geometries. This means the checker could regard
> it as
> an error also if it finds any missing data in aux coord vars, unless a
> valid
> featureType att is present, arising from 9.6, in addition to the above.
>
> However, I think the convention should be clear that this is not allowed
> except
> for discrete sampling geometries, so I'll open a defect ticket for that.
>
> Best wishes
>
> Jonathan
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 26 Mar 2012 09:04:12 -0400
> From: Nan Galbraith <ngalbraith at whoi.edu>
> Subject: Re: [CF-metadata] CF-1.6 Conformance
> Requirements/Recommendations
> To: cf-metadata at cgd.ucar.edu
> Message-ID: <4F70694C.9060703 at whoi.edu>
> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
>
> I was unaware of this restriction on aux coordinate variables.
>
> On 3/26/12 4:24 AM, Jonathan Gregory wrote:
> > Appendix A notes that missing data is allowed in aux coord vars only in
> the
> > case of discrete sampling geometries. This means the checker could
> regard it as
> > an error also if it finds any missing data in aux coord vars, unless a
> valid
> > featureType att is present, arising from 9.6, in addition to the above.
> >
> > However, I think the convention should be clear that this is not allowed
> except
> > for discrete sampling geometries, so I'll open a defect ticket for that.
>
> For something like towed CTD data, you might have a period of time where
> data from the pressure sensor is missing. If neither the coordinate or aux
> coordinate can contain null values, does this mean the only options are
> interpolating Z or removing that section of data?
>
> Sometimes, if the pressure can clearly be interpolated, we'd prefer to fill
> the bad section with null Z values, and let the user decide if he would
> like to
> interpolate - otherwise the QC information can be lost when data is
> extracted
> from the file.
>
> Cheers -
>
> Nan
>
>
> On 3/23/12 6:29 PM, John Caron wrote:
> > On 3/23/2012 1:59 PM, Jim Biard wrote:
> >> Hi.
> >>
> >> Jonathan's reply contained the section:
> >>
> >> 9.6 Where any auxiliary coordinate variable contains a missing
> >> value, all
> >> other coordinate, auxiliary coordinate and data values
> >> corresponding to that
> >> element should also contain missing values.
> >>
> >>
> >> I thought I understood that missing values were forbidden for true
> >> coordinate variables. Has this changed?
> > No, coordinate variable cant have missing values but auxiliary
> > coordinates can.
> >
> >> This requirement seems wrong to me anyway. If the values in the data
> >> and auxiliary coordinate variables come from an external data source,
> >> it is entirely possible that you could have a measurement missing
> >> from one without it being missing from the other. Why force a
> >> missing value into the data when you might, in fact, have a valid value?
> >
> >
> > An auxiliary coordinate is important to have for valid data, not some
> > optional information. If it is optional, dont make it an auxiliary
> > coordinate.
> >
> > Allowing missing values in auxiliary coordinates is very useful, eg
> > see the discrete sampling proposal, allowing you to use a rectangular
> > array to store ragged arrays.
> >
> >
> > John
> >
> >
> > _______________________________________________
> > CF-metadata mailing list
> > CF-metadata at cgd.ucar.edu
> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
> --
> *******************************************************
> * Nan Galbraith Information Systems Specailist *
> * Upper Ocean Processes Group Mail Stop 29 *
> * Woods Hole Oceanographic Institution *
> * Woods Hole, MA 02543 (508) 289-2444 *
> *******************************************************
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20120326/26e25684/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 3
> Date: Mon, 26 Mar 2012 08:28:16 -0600
> From: John Caron <caron at unidata.ucar.edu>
> Subject: Re: [CF-metadata] CF-1.6 Conformance
> Requirements/Recommendations
> To: cf-metadata at cgd.ucar.edu
> Message-ID: <4F707D00.4080107 at unidata.ucar.edu>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 3/26/2012 2:24 AM, Jonathan Gregory wrote:
> > Dear Ros
> >
> > Regarding this requirement:
> >
> >> 9.6 Where any auxiliary coordinate variable contains a missing value,
> all
> >> other coordinate, auxiliary coordinate and data values corresponding to
> that
> >> element should also contain missing values.
> > Appendix A notes that missing data is allowed in aux coord vars only in
> the
> > case of discrete sampling geometries. This means the checker could
> regard it as
> > an error also if it finds any missing data in aux coord vars, unless a
> valid
> > featureType att is present, arising from 9.6, in addition to the above.
> >
> > However, I think the convention should be clear that this is not allowed
> except
> > for discrete sampling geometries, so I'll open a defect ticket for that.
> >
> > Best wishes
> >
> > Jonathan
> > _______________________________________________
> > CF-metadata mailing list
> > CF-metadata at cgd.ucar.edu
> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
> I think this may be more complicated.
>
> Consider a geosynch satellite with lat/lon aux coordinates. the nature
> of the image is that there are many points around the outside of the
> image that are not located on the earth. i dont see any good choices
> other than to put missing values there for lat/lon..
>
> To add insult to injury, it seems possible that there are valid data
> values at these locations. Not sure about that however. Can anyone with
> geosynch data expertise comment?
>
> It seems at minimum this is another case where missing values in aux
> coordinates are needed.
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 26 Mar 2012 15:48:29 +0100
> From: Jonathan Gregory <j.m.gregory at reading.ac.uk>
> Subject: Re: [CF-metadata] CF-1.6 Conformance
> Requirements/Recommendations
> To: cf-metadata at cgd.ucar.edu
> Message-ID: <20120326144829.GA18543 at met.reading.ac.uk>
> Content-Type: text/plain; charset=us-ascii
>
> Dear Nan and John
>
> It's a good thing we're having this discussion! In my understanding, we
> have
> always prohibiting missing data in aux coord vars, and in section 9 we
> explicitly allowed for the first time. Evidently we should be clear, one
> way
> or the other (which was one of the intentions of the defect ticket I
> opened).
>
> The restriction on coord vars not having missing data is, I think, hard to
> avoid because they are required to be distinct and monotonic.
>
> In Nan's case:
>
> > For something like towed CTD data, you might have a period of time where
> > data from the pressure sensor is missing. If neither the coordinate or
> aux
> > coordinate can contain null values, does this mean the only options are
> > interpolating Z or removing that section of data?
>
> When the sensor is missing, does that mean the data can't be geolocated? As
> you know, geolocation is one thing CF tries hard to do. Is the data useful
> if
> you don't know where it comes from? Perhaps you know in some other way?
>
> In John's case
>
> > Consider a geosynch satellite with lat/lon aux coordinates. the
> > nature of the image is that there are many points around the outside
> > of the image that are not located on the earth. i dont see any good
> > choices other than to put missing values there for lat/lon..
>
> Bert has coincidentally mentioned a similar case (not on the list). I tend
> to
> agree that if index space contains locations that simply do not exist, you
> could put missing data in aux coord vars, but I think this needs a change
> to
> the CF convention.
>
> > To add insult to injury, it seems possible that there are valid data
> > values at these locations. Not sure about that however. Can anyone
> > with geosynch data expertise comment?
>
> As in Nan's case, I am curious about how the data can be useful if it
> doesn't
> have a location.
>
> Best wishes
>
> Jonathan
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 26 Mar 2012 11:11:44 -0400
> From: "Randy Horne" <rhorne at excaliburlabs.com>
> Subject: Re: [CF-metadata] CF-1.6 Conformance
> Requirements/Recommendations
> To: <cf-metadata at cgd.ucar.edu>, John Caron <caron at unidata.ucar.edu>
> Message-ID: <201203261111.AA281018444 at excaliburlabs.com>
> Content-Type: text/plain; charset=us-ascii
>
> Folks:
>
> Regarding the geosync request for comment .....
>
> In the case of GOES-R (and also Meteosat) our coordinate variable values
> are N/S elevation angle and E/W scanning angle, which can be syntactically
> valid values albeit off the disk of the earth.
>
> However, it is very possible that there will be a need for a hemispheric
> product with lat/lon coordinate variables. Currently, GOES-R does not have
> this need (although we did before there was a change to the requirements).
> In this case, there would be a need to have some type of missing value for
> the coordinates of these off disk pixels in the earth bounding
> rectangle/square.
>
> very respectfully,
>
> randy
>
>
> Randy C. Horne (rhorne at excaliburlabs.com)
> Principal Engineer, Excalibur Laboratories Inc.
> voice & fax: (321) 952-5100
> url: http://www.excaliburlabs.com
>
> PGP Public Keys available at:
> A HREF="http://pgpkeys.mit.edu:11371">MIT's Key Server</A>
>
> ---------- Original Message ----------------------------------
> From: John Caron <caron at unidata.ucar.edu>
> Date: Mon, 26 Mar 2012 08:28:16 -0600
>
> >On 3/26/2012 2:24 AM, Jonathan Gregory wrote:
> >> Dear Ros
> >>
> >> Regarding this requirement:
> >>
> >>> 9.6 Where any auxiliary coordinate variable contains a missing value,
> all
> >>> other coordinate, auxiliary coordinate and data values corresponding
> to that
> >>> element should also contain missing values.
> >> Appendix A notes that missing data is allowed in aux coord vars only in
> the
> >> case of discrete sampling geometries. This means the checker could
> regard it as
> >> an error also if it finds any missing data in aux coord vars, unless a
> valid
> >> featureType att is present, arising from 9.6, in addition to the above.
> >>
> >> However, I think the convention should be clear that this is not
> allowed except
> >> for discrete sampling geometries, so I'll open a defect ticket for that.
> >>
> >> Best wishes
> >>
> >> Jonathan
> >> _______________________________________________
> >> CF-metadata mailing list
> >> CF-metadata at cgd.ucar.edu
> >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> >
> >I think this may be more complicated.
> >
> >Consider a geosynch satellite with lat/lon aux coordinates. the nature
> >of the image is that there are many points around the outside of the
> >image that are not located on the earth. i dont see any good choices
> >other than to put missing values there for lat/lon..
> >
> >To add insult to injury, it seems possible that there are valid data
> >values at these locations. Not sure about that however. Can anyone with
> >geosynch data expertise comment?
> >
> >It seems at minimum this is another case where missing values in aux
> >coordinates are needed.
> >
> >
> >_______________________________________________
> >CF-metadata mailing list
> >CF-metadata at cgd.ucar.edu
> >http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> >
>
>
>
> ..............End of Message ...............................-->
>
>
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 26 Mar 2012 11:20:40 -0400
> From: Nan Galbraith <ngalbraith at whoi.edu>
> Subject: Re: [CF-metadata] CF-1.6 Conformance
> Requirements/Recommendations
> To: cf-metadata at cgd.ucar.edu
> Message-ID: <4F708948.5060800 at whoi.edu>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi Jonathan -
>
> For underway CTD profiles (gliders and floats, too, I'd think) if the
> pressure
> sensor fails intermittently, you can approximate Z by interpolating over
> time, assuming there are good values along the track. In "final" data,
> we might
> do that, but we might like to present raw data in CF files, too. So,
> yes, this data
> would be useful, with fill values here and there in the pressure record.
>
> Are we getting into a grey area that might be outside the scope of the CF
> standard - judgements made about the usefulness of data? Having all your
> coordinates seems like an excellent NetCDF "best practice" and could
> certainly
> be a "rule" for many tools, but it could preempt the use of the CF
> standard for
> some kinds of observational data.
>
> Cheers -
> Nan
>
> On 3/26/12 10:48 AM, Jonathan Gregory wrote:
> > Dear Nan and John
> >
> > It's a good thing we're having this discussion! In my understanding, we
> have
> > always prohibiting missing data in aux coord vars, and in section 9 we
> > explicitly allowed for the first time. Evidently we should be clear, one
> way
> > or the other (which was one of the intentions of the defect ticket I
> opened).
> >
> > The restriction on coord vars not having missing data is, I think, hard
> to
> > avoid because they are required to be distinct and monotonic.
> >
> > In Nan's case:
> >
> >> For something like towed CTD data, you might have a period of time where
> >> data from the pressure sensor is missing. If neither the coordinate or
> aux
> >> coordinate can contain null values, does this mean the only options are
> >> interpolating Z or removing that section of data?
> > When the sensor is missing, does that mean the data can't be geolocated?
> As
> > you know, geolocation is one thing CF tries hard to do. Is the data
> useful if
> > you don't know where it comes from? Perhaps you know in some other way?
> >
> > In John's case
> >
> >> Consider a geosynch satellite with lat/lon aux coordinates. the
> >> nature of the image is that there are many points around the outside
> >> of the image that are not located on the earth. i dont see any good
> >> choices other than to put missing values there for lat/lon..
> > Bert has coincidentally mentioned a similar case (not on the list). I
> tend to
> > agree that if index space contains locations that simply do not exist,
> you
> > could put missing data in aux coord vars, but I think this needs a
> change to
> > the CF convention.
> >
> >> To add insult to injury, it seems possible that there are valid data
> >> values at these locations. Not sure about that however. Can anyone
> >> with geosynch data expertise comment?
> > As in Nan's case, I am curious about how the data can be useful if it
> doesn't
> > have a location.
> >
> > Best wishes
> >
> > Jonathan
> > _______________________________________________
> > CF-metadata mailing list
> > CF-metadata at cgd.ucar.edu
> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> >
>
>
> --
> *******************************************************
> * Nan Galbraith Information Systems Specailist *
> * Upper Ocean Processes Group Mail Stop 29 *
> * Woods Hole Oceanographic Institution *
> * Woods Hole, MA 02543 (508) 289-2444 *
> *******************************************************
>
>
>
>
>
> ------------------------------
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
> End of CF-metadata Digest, Vol 107, Issue 30
> ********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20120327/8e2cc3d3/attachment-0001.html>
Received on Tue Mar 27 2012 - 07:07:38 BST

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:41 BST

⇐ ⇒