This message came from the CF Trac system. Do not reply. Instead, enter your comments in the CF Trac system at https://cf-pcmdi.llnl.gov/trac/.
#86: Allow coordinate variables to be scaled integers ---------------------------------------+------------------------------------ Reporter: [email protected] | Owner: [email protected] Type: defect | Status: new Priority: medium | Milestone: Component: cf-conventions | Version: Resolution: | Keywords: coordinate variables, scaled inetegers ---------------------------------------+------------------------------------ Comment (by davidhassell): Replying to [comment:2 [email protected]]: > Is there anything left to be done for getting for this trac item approved ? Hello Randy, Many apologies for jumping in so late - I've not thought about this for a while, but should have done so. I support the proposed change which allows for the reduction in netCDF dataset (file) size, but I have a concern about its other suggested purpose. From the e-mail list discussion, it sounds like you would like to know what the real coordinate values are but not use them, i.e. you would like to ''not'' apply the additive offset or scale factor at the time of reading. If that's right, how would the software reading the data know, when presented with add_offset or scale_factor, whether or not to unpack values? [http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf- conventions.html#packed-data 8.1 of the conventions] suggest to me that unpacking is to be expected at the time of reading. Assuming I'm still holding the right end of the stick, could I re-suggest that using scaled and offset units for this purpose is more appropriate? For example: {{{ float longitude(longitude) ; longitude:units = "0.5 degrees_east @ 98" ; longitude:standard_name = "longitude" ; data: longitude = 0, 1, 2, 3 ; }}} is completely equivalent to: {{{ float longitude(longitude) ; longitude:units = "degrees_east" ; longitude:standard_name = "longitude" ; data: longitude = 49.0, 49.5, 50.0, 50.5 }}} By using the units property in this way, it seems to me that the issue of "do I or don't I unpack" goes away and you still have the flexibility you require in your software - because you can choose whether or not to convert the units back to 'degrees_east'. The offset and scale are easily extracted from the units string. > One of these products spans the 180 degrees_east longitude (i.e. -180 degrees_east longitude) line. The implication being that the software resolving the scale factor and additive offset needs to be cognizant of the longitude coordinate variable "units". Using the units property should also solve this, I think. If I have misunderstood your use case, please let me know! All the best, David -- Ticket URL: <https://cf-pcmdi.llnl.gov/trac/ticket/86#comment:3> CF Metadata <http://cf-pcmdi.llnl.gov/> CF Metadata This message came from the CF Trac system. To unsubscribe, without unsubscribing to the regular cf-metadata list, send a message to "[email protected]" with "unsubscribe cf-metadata" in the body of your message.
