Hi Terry,
Do you serve aggregations, or is each NetCDF file a separate dataset? With an
aggregation, there isn’t a one-to-one correspondence between a WMS layer and a
NetCDF variable in a particular file. This is also true for things like
velocity fields, which are derived on-the-fly from vector components. One of
the THREDDS team could hopefully explain how variable attributes behave under
aggregation (do they just take the values from the first file in the
aggregation?)
One problem with “baking” this information into the NetCDF file, is that people
frequently change their mind about what the values should be. The concept of a
“sensible view range” is not an intrinsic property of the data, hence we have
always kept this as a WMS configuration issue.
By the way, valid_min/max isn’t the solution I’m afraid. These attributes
define a range, outside of which data are considered to be missing. So for an
ocean temperature field (with a sensible view range of [-2:35] degC perhaps)
the valid_min/max could perfectly legitimately be set to [-100:100] .
There was a proposal (which I don’t think is official CF) to use
“actual_min/max” attributes to denote the actual range of data in a variable.
There was reluctance to accept this into CF because it is redundant
information, but I think it can be easily calculated and inserted into a NetCDF
file using the NetCDF Operators (nco).
However, if you think that something like actual_min/max would work for your
use case, we could consider whether this would be implementable as a means of
providing the “sensible view range”.
Cheers,
Jon
--
Dr Jon Blower,
Technical Director, Reading e-Science Centre,
MELODIES project coordinator,
School of Mathematical and Physical Sciences,
University of Reading
Tel: +44 118 378 5213
Email: j.d.blower@xxxxxxxxxxxxx
On 21 Aug 2014, at 03:45, <Terry.Rankine@xxxxxxxx> <Terry.Rankine@xxxxxxxx>
wrote:
> The two workflows we have are
> 1. Dump the data in "this" folder heriachy/structure - it will magically
> appear for you.
> 2. Email us and we will host it.
>
> I cant see any issue with scripting it, but I was under the impression that
> changes to the xml file would require TDS to be restarted, plus its just
> another bit of data to keep in 'sync' somehow.
>
> My desire here would be that, as an admin, I would tell the wmsConfig.xml
> <location /this/path/his-data-set-*.nc>
> <layer name=elevation>
> <default color range>
> <min>$delegate[elevation.vmin]</min>
> <max>$delegate[elevation.vmax]</max>
> </default color range>
> </layer>
> </location>
>
> As an admin I would deliberately hand over the 'setting the right view
> stuff' for those who could control the data production/attribution. Freeing
> me from that role.
>
> I completely understand where it is not appropriate - but I don't believe
> that makes it 'inappropriate' for the simple cases.
>
> Terry
>
> -----Original Message-----
> From: thredds-bounces@xxxxxxxxxxxxxxxx
> [mailto:thredds-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Jon Blower
> Sent: Thursday, 21 August 2014 2:48 AM
> To: thredds@xxxxxxxxxxxxxxxx
> Subject: Re: [thredds] NetCDF, WMS, and auto color scale (not set by admin)
>
> Hi Terry,
>
> As far as I remember THREDDS has always required setting of the default
> colour scale range by the admin. (However the standalone ncWMS could do this
> automatically, because it scans datasets during an ingestion step, which
> THREDDS does not perform.)
>
> There is currently no way to read the default colour range from the NetCDF
> files, although a means could theoretically be invented, with "special"
> attributes. One problem is that, in a multidimensional variable, the most
> appropriate range for one z or t level may not be so appropriate for another
> value of z or t. There are other interesting issues with the behaviour of
> NetCDF attributes in aggregations (what happens if different files in the
> same aggregation have different attributes?)
>
> How do the data providers communicate their preferences to you at the
> moment? Could you, for example, craft a script that takes their values (from
> a simple text file maybe) and inserts it appropriately into the
> wmsConfig.xml automatically?
>
> Cheers,
> Jon
>
>
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Wed, 20 Aug 2014 01:19:29 +0000
>> From: <Terry.Rankine@xxxxxxxx>
>> To: <thredds@xxxxxxxxxxxxxxxx>
>> Subject: [thredds] NetCDF, WMS, and auto color scale (not set by
>> admin)
>> Message-ID:
>>
> <918EBF4F0E40D340B213B473CCAB6B126000492D@xxxxxxxxxxxxxxxxxxxxxxxxxx>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> Hi Guys
>>
>>
>>
>> In older versions of thredds I could leave the auto color scaling for
>> a WMS to thredds to take care of for me. Can I have it back - but a bit
> different.
>>
>>
>>
>> As a system admin - I am just 'serving the data' not really
>> understanding what 'sensible viewing defaults' for
>> defaultColorScaleRange for any file in the directory should be.
>> However - the data owners I interact with all have a 'preference' on
>> how to color/scale their visualisations for their data files.
>>
>>
>>
>> Is there a way to make thredds read the netCDF file - load the
>> variable, and load the visualisation range FROM THE DATA FILE - not
>> the wmsConfig.xml - where I would need to explicitly set it?
>>
>>
>>
>> IE - if on the elevation layer for this service:
>>
>> http://vhirl-dev.csiro.au/thredds/dodsC/dem/testconvert/bathymetry_sur
>> veys_G
>> A-2476_100m_version1_WGS84UTM49S_esri_grid_grid100m_GA-2476_Exmouth_10
>> 0m_exm
>> outh100m.nc4.html
>>
>>
>>
>> I set a netcdf parameter like defaultColorScaleRange or something less
>> thredds specific, max/min or something which could guide the 'lazy'
>> configuration option for the data?
>>
>>
>>
>> Regards
>>
>> Terry
>>
>>
>
> _______________________________________________
> thredds mailing list
> thredds@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe, visit:
> http://www.unidata.ucar.edu/mailing_lists/
