[CF-metadata] CF Geometry Support in GDAL

Hi All, I'm really happy to share that we have a start to the CF Geometries contributed to GDAL/OGR ! Thanks to Winor Chen, a student from the UW-Madison, for his great work on this! So far only a reader and CRS support is limited, but the writer and

Re: [CF-metadata] [CF-metadar ata] [EXTERNAL] 'months since' and 'years since' time units

e. As > units of "calendar_time", however, they would fit perfectly well into the > UNIDATA and CF model. > > > (2) place the information in a different attribute. This is clearly a new > concept for the convention, so it would be reasonably to add a new attribute. > &g

Re: [CF-metadata] [EXTERNAL] 'months since' and 'years since' time units

ing a reference to an external > document (as is now done for Udunits). > > > > Kind regards, > Lars > > > Från: David Blodgett [dblodg...@usgs.gov <mailto:dblodg...@usgs.gov>] > Skickat: den 20 oktober 2018 13:47 > Till: Bärring Lars > Kopia: cf-metadata@cgd.uc

Re: [CF-metadata] 'months since' and 'years since' time units

t;> >>>>>>> >>>>>>> I think you could go further and disallow the use of "month" or "year" >>>>>>> as a time unit when the calendar is not standard. >>>>>>> >>>>>>> >

Re: [CF-metadata] 'months since' and 'years since' time units

lt;mailto:cf-metadata@cgd.ucar.edu> >>>>> Subject: Re: [CF-metadata] 'months since' and 'years since' time units >>>>> >>>>> Dear all >>>>> >>>>> This is an interesting discussion, and I agree that's a tricky subject.

Re: [CF-metadata] [EXTERNAL] SV: 'months since' and 'years since' time units

world calendar months. But that is the topic for another thread. > > > Kind regards, > Lars > > Från: CF-metadata [cf-metadata-boun...@cgd.ucar.edu > <mailto:cf-metadata-boun...@cgd.ucar.edu>] för David Blodgett > [dblodg...@usgs.gov <mailto:dblo

Re: [CF-metadata] 'months since' and 'years since' time units

Dear Ryan, All, I hesitate to chime in on this thread as I know just how fraught this topic can be, but then I think I know how fraught it can be so may have something to offer. My experience is at the intersection of climatological models and landscape models that are calibrated with "real"

Re: [CF-metadata] Simple Geometry Proposal Next Steps

Dear all, It’s been a couple weeks with no response on this. I will open a pull request to the cf-convention GitHub repository and we can discuss it’s merits there. Best, - Dave > On Apr 7, 2017, at 11:42 AM, David Blodgett <dblodg...@usgs.gov> wrote: > > Dear All, > &g

[CF-metadata] Simple Geometry Proposal Next Steps

Dear All, We have reconciled issues brought up in review of the Simple Geometry proposal into three documents. 1) A README that is a high level overview of the proposal. 2) A more detailed wiki with linked examples

[CF-metadata] Use of GitHub instead of trac

Dear All, I don’t have a trac account so I responded to https://cf-trac.llnl.gov/trac/ticket/160 here https://github.com/cf-convention/cf-conventions/issues/106 as a bit of a demonstration

Re: [CF-metadata] Geometries in NetCDF Update

your new section doesn't belong in ch 9. > > Best wishes > > Jonathan > > - Forwarded message from David Blodgett <dblodg...@usgs.gov> - > >> Date: Thu, 16 Mar 2017 14:19:43 -0500 >> From: David Blodgett <dblodg...@usgs.gov> >> To: Jonathan Gregory

Re: [CF-metadata] Geometries in NetCDF Update

Dear Jonathan, Thank you for looking things over. Makes sense that we would add a new ‘geometry’ attribute that would point at the geometry container variable and be in both the node coordinates and the data variables. Yes, the 0 or 1 is meant to be inside or outside. We thought that would be

Re: [CF-metadata] Geometries in NetCDF Update

to visualise the geometries (e.g. using GIS, or an > enhanced ncview), so as long as it’s straightforward to pull out the > information then that’s all that matters. > > Regards, > > Dan > > > From: David Blodgett [mailto:dblodg...@usgs.gov] > Sent: 14 Mar

Re: [CF-metadata] Geometries in NetCDF Update

t; Website: http://www.metoffice.gov.uk <http://www.metoffice.gov.uk/> > For UK climate and past weather information, visit > http://www.metoffice.gov.uk/climate <http://www.metoffice.gov.uk/climate> > > > From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu

[CF-metadata] Geometries in NetCDF Update

Dear CF, Based on feedback we’ve received and the phone call we held last week, Time Whiteaker and I have worked up a mostly complete new draft of how to store geometries in NetCDF. We’d greatly appreciate more eyes on it if you have time or interest. It’s been written up in some detail here:

Re: [CF-metadata] Telecom This Morning: Reminder and agenda

It could be used via the cell bounds / auxiliary coordinates and be attached to cells or DSG points. Need to be careful that the DSG specs' limitations on one featureType per file isn’t a problem. From this, I’ll draft up a new proposal and circulate it for the group to review. Best,

[CF-metadata] Telecom This Morning: Reminder and agenda

Dear CF, This is a reminder that we will be getting together on a google hang out in about thirty minutes to discuss the way forward on simple geometries in NetCDF-CF. I will write up a brief summary of this call and share with the list later today. Brief review: 1) There is general consensus

Re: [CF-metadata] Discussion of technical CF issues as GitHub issues?

I think this is a fantastic suggestion. > On Feb 27, 2017, at 6:51 AM, Signell, Richard wrote: > > I was trying to catch up on "Pre-proposal for charset" conversation > and found it extremely challenging to ferret out the technical thread > of discussion from the numerous

Re: [CF-metadata] Extension of Discrete Sampling Geometries for Simple Features

My apologies, I forgot to turn on time zone support in the poll below. Please use this one instead. http://doodle.com/poll/eikarnt35tdm7igd <http://doodle.com/poll/eikarnt35tdm7igd> > On Feb 17, 2017, at 1:22 PM, David Blodgett <dblodg...@usgs.gov> wrote: > > All, >

Re: [CF-metadata] Extension of Discrete Sampling Geometries for Simple Features

45, -40, -20, -10, -10, -30, -45, -20, -30, -20, -20, -30, 30, 45, 10, 30, 25, 50, 30, 25 ; y = 0, 0, 20, 20, 0, 1, 5, 1, 1, 15, 19, 15, 15, 15, 19, 15, 15, 25, 25, 29, 25, 25, 25, 29, 25, -40, -45, -30, -40, -35, -30, -10, -5, -20, -35, -20, -15, -25, -20, 20, 40, 40, 20, 5, 10,

Re: [CF-metadata] CF-metadata Digest, Vol 166, Issue 5

-length data arrays in > netcdf-java/c would solve a lot of problems, now and in the future. > Some work on this is already done: I think the netcdf-java API already > supports variable-length arrays when reading netcdf-4 files. > For Simple Features, the problem would reduce to: st

Re: [CF-metadata] Extension of Discrete Sampling Geometries for Simple Features

ssed parts of your proposal that answer these > questions. > > > On Thu, Feb 2, 2017 at 5:57 AM, <cf-metadata-requ...@cgd.ucar.edu > <mailto:cf-metadata-requ...@cgd.ucar.edu>> wrote: > Date: Thu, 2 Feb 2017 07:57:36 -0600 > From: David Blodgett <dblodg...@usgs

[CF-metadata] Extension of Discrete Sampling Geometries for Simple Features

ometry featureType, but it could be that we leave it alone and introduce a geometry featureType. This may be a minor point of discussion, but we need to be clear that this is an issue that still needs to be resolved in the proposal. Thank you for your time and consideration. Best Regards, David Blodget

Re: [CF-metadata] Feedback requested on proposed CF Simple Geometries

Dear Jonathan, As I mentioned in my response yesterday, we have worked through these issues and think we have a compromise proposal for the community. Since the conversation is active, I’ll go ahead and share our work with the list in a follow up email in a moment. A couple specific

Re: [CF-metadata] Feedback requested on proposed CF Simple Geometries

Dear Jonathan and Chris, Thanks for bringing this thread back to life! Please don’t take silence on the part of Ben and I as a lack of activity. We have been working on a thorough proposal and are hoping to share it with the community very soon. Chris, I think you will find a number of

Re: [CF-metadata] Proposed standard_name for river discharge

idcot, OX11 0QX, U.K. > > > >> -Original Message----- >> From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf >> Of David Blodgett >> Sent: 09 May 2016 15:08 >> To: Signell, Richard >> Cc: CF metadata; Jonathan Gregory >> Subject:

Re: [CF-metadata] Proposed standard_name for river discharge

er to make this clear? > > water_volume_transport_in_river_channel > water_volume_transport_over_land > water_volume_transport_in_??? > > -Rich > > On Tue, May 3, 2016 at 10:14 AM, David Blodgett <dblodg...@usgs.gov> wrote: >> I actually suggested ‘in river channel’ to rich because of the

Re: [CF-metadata] Proposed standard_name for river discharge

> better because it's simpler. Later on, if needed, you could propose further > standard names with more qualifications. It's fine to provide both general > and specific standard names, for different purposes. > > Best wishes > > Jonathan > > - Forwarded message f

Re: [CF-metadata] Proposed standard_name for river discharge

I actually suggested ‘in river channel’ to rich because of the potential to segregate into flow in fluvial sediments below the channel or in a floodplain disconnected from the channel, etc. Cheers! - Dave > On May 3, 2016, at 9:09 AM, Jonathan Gregory > wrote: >

Re: [CF-metadata] Question on WKT representation of CRS

Good points Jon, A well documented translation from WKT to CF may be all that is needed. Our web processing software that integrates OPeNDAP data with GIS data already crosswalks CF to GIS projections for use with GeoTools. We may be able to contribute this to a standard translation. A

Re: [CF-metadata] Question on WKT representation of CRS (Bentley, Philip)

All, I don't understand what is meant opaque or long and mysterious with regard to Well Known Text crs definition. Just because the parameters stored in a wkt string are complex? The fact of the matter is that coordinate reference system information is an integral component of any

Re: [CF-metadata] the need to store lat/lon coordinates in a CF-compliant netCDF file

Correction to the datum/ellipsoid explanation below. The NAD83 datum does use the GRS80 ellipsoid. The NAD27 datum uses the Clarke 1866 ellipsoid. Woops! Dave On Aug 3, 2011, at 9:07 AM, David Blodgett wrote: Dear Phil, I would have thought that if a particular piece of data analysis

Re: [CF-metadata] the need to store lat/lon coordinates in a CF metadata compliant netCDF file

Dear Jonathan, All, Coming from the perspective of a geographer, for CF to be a convention whereby people can provide accurate and complete metadata for their data. Datum specification would be required. I understand that the normal practice in the climate science community is to throw out

Re: [CF-metadata] the need to store lat/lon coordinates in a CF metadata compliant netCDF file

Without the grid_mapping, the lat and lon still make sense in the common case (and original CF case) of GCM data, and in many other cases, the intended usage of the data does not require precision about the figure of the Earth. Although this metadata could be valuable if it can be defined, I

Re: [CF-metadata] the need to store lat/lon coordinates in a CF metadata compliant netCDF file

of their output values, but we're not there yet. Best regards, Karl On 7/27/11 9:23 AM, David Blodgett wrote: Not to beat a dead horse, but this issue has been a huge stumbling block in our work to integrate data and software across the climate and geographic communities. The argument here

Re: [CF-metadata] Request for help relating Netcdf file and the projection issues!

more inclined to the approach you suggested later. Can I adopt the approach of redefining the axes if the data are in lambert conformal conic projection? and if the answer is yes, how would I do so? Thanks! Sami On Thu, Apr 14, 2011 at 11:17 AM, David Blodgett dblodg...@usgs.gov

Re: [CF-metadata] Request for help relating Netcdf file and the projection issues!

Your file appears to already be in lat/lon with no datum specified do you know what the data should be? Since it is curvilinear, ArcGIS won't read it as gridded data. Arc only really operates on raster grids.You have to import it as a collection of points using Make NetCDF Feature Layer. If