Greetings! As requested, I've fiddled around a bit with this to try and break it for you. I chose “GRACE Water-Equivalent-Thickness Surface-Mass Anomaly; CSR RL06, 1.0°, 2002-2017” as a test case (since I know what that data should look like). Here's what I thought as I went through:
The “graph” option:
1.) It would be incredibly useful to have the ability to use your mouse to draw a box on the map, showing the lat/lon bounds of the data you want. I found the zoom options really frustrating to use, and it took me a while to see the lat/lon sliders to the left.
2.) It would be helpful if the time option gave a pull-down list or something, not merely a “next” and “previous” option.
3.) When I type “2014-10” for a monthly product, I mean the one labelled “2014-10-16”, not “2014-09-16”. I assume you’ve got it coded to give the nearest time value, but for monthly data that’s not really what’s implied.
(Don’t have much more to say on the graphing section. I’d never use such an auto-graphing option in real life, so I’m probably not the best judge.)
The “data” option:
1.) Pretty big (and correctable) error found here. I started by giving it the inputs of:
dates: 2002 to 2018
lats: -80 to -40
lons: 0 to 360
I got back no data and this error message:
message="Not Found: Your query produced no matching results. Query error: For variable=lwe_thickness axis#0=time Constraint=\"[(2002):1:(2018)]\": Start=\"2002\" is less than the axis minimum=2002-04-18T00:00:00Z (and even 2002-03-31T22:11:06Z).";
I tried again from 2003 to 2017, and got the same error. This is plainly being caused by the date format. But no one’s going to automatically type in “2017-06-10T12:00:00Z” when they mean 2017-06, and giving a range in years (even ones just before/after the mission so you can get all the data) is likely going to be pretty normal.
2.) Upon downloading the data, the output (csv form) looks like this:
Would there be any way to offer an option for a different time format? As is, this doesn’t allow simple plotting/reading, but needs a specifically-defined formatted input read to put the date into anything usable. This isn’t critical, but avoiding the T and Z, in particular, would make life easier for most users. And again, with monthly data (as opposed to, say, along track altimetry or something) the times really only require YR-MO, nothing more. YR-MO-DY would be plenty – and easier to use.
That's about all I noticed on a quick pass through. Thanks, guys!
-- Jennifer Bonin