Ajay, It seems that you just contradicted yourself. First you asked how to encode time coordinates when some measurements have time of day, but the date is missing. Now you are saying that a valid date/time coordinate is required. But a valid date/time coordinate is not possible without complete date and time information for each measurement.
The comment from your data team suggests that you misstated the original problem, and that the so-called missing dates can always be determined from context. Please let us know if this is the case. If not, would you please explain the apparent contradiction. --Dave On Tue, Nov 1, 2016 at 11:21 AM, Ajay Krishnan - NOAA Affiliate < [email protected]> wrote: > Thanks a lot for the suggestions, Dave, Ed and Seth. > > Seth, here's the response from the team that's working on the data: > > The first solution is not realistic. There are too many > missing times - separating out into another data variable > would give the user a bifurcated data set. > > The second solution is doable, but still doesnt make much > sense. The power of using a convention is that the data > can be dumped, used, graphed, in software which follows > the conventions quickly and easily. What good is it to > graph against a sequential index? Date/time needs to > be a coordinate to interact seamlessly with existing > software. > > Ed, > I don't know to record the data as a time_offset in hours or seconds when > there is no information on the number of days that have passed since the > reference time. > > -Ajay > > <digest overhead omitted> >> >> Date: Tue, 25 Oct 2016 14:26:18 -0600 >> From: Seth McGinnis <[email protected]> >> To: "[email protected]" <[email protected]> >> Subject: Re: [CF-metadata] Handling time when date is "missing" >> >> But then the data is non-compliant, and it sounds like a valid CF >> solution is needed. >> >> Two possible solutions come to my mind. The first way would be to store >> the undated measurements separately. Record the normal measurements in >> the normal way, and then record the undated measurements in a separate >> data variable with an index coordinate instead of a time coordinate. >> >> The other way would be not to use time as a coordinate variable at all, >> but only as a data variable. Record all the measurements with an index >> coordinate instead of a time coordinate. Then define data variables for >> year, month, day, and time of measurement, and just fill in what's known >> for each one. (It sounds like the month and year are still known even >> if the day is not.) This is very similar to the approach taken for >> trajectories; see example H.12 in the spec. >> >> Cheers, >> >> --Seth >> >> >> On 10/25/16 1:31 PM, Dave Allured - NOAA Affiliate wrote: >> > Ajay, >> > >> > I think this is an exception to CF. I recommend using _FillValue or >> > missing_value on the time coordinate. Document this in a comment >> > attribute on the time coordinate variable. >> > >> > Also document this somehow in another global attribute that explains you >> > made this exception to the CF conventions. Follow CF conventions in all >> > other regards. >> > >> > Then, try to remember to warn people about this when you distribute the >> > data. CF compliant time coordinates are fundamental to many application >> > programs, and I expect they will choke or introduce subtle errors if >> > missing values are in there. So users will need to provide special >> > handling for such files. HTH. >> > >> > --Dave >> > (Please reply to list only) >> > >> > >> > On Tue, Oct 25, 2016 at 12:07 PM, Ajay Krishnan - NOAA Affiliate >> > <[email protected] <mailto:[email protected]>> wrote: >> > >> > Hi All, >> > >> > I have a user that's converting some IMMA format files to CF >> > compliant NetCDF files. >> > >> > The problem is that, we've run into several measurements where just >> > the hour of measurement has been recorded without the corresponding >> > "date". We would prefer not to omit these data in the conversion, >> > because they are considered valid measurements (and play a role in >> > monthly summary statistics) >> > >> > How do we represent this in a valid CF NetCDF format since we can't >> > use _FillValues for 'time'? Any suggestions for handling such >> > special cases? >> > >> > Thanks, >> > Ajay >> >
_______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
