FYI @LindsayRAbrams. Curious if you know who manages https://opendap.co-ops.nos.noaa.gov/erddap/index.html?

The CO-OPS ERDDAP is very non-standard in that it requires the extra STATION_ID and possibly other parameters to return results.

It's been awhile since I've looked into it, but I recall it's a design limitation within the CO-OPS database that requires such parameters by design in order to return data. Maybe they have an alternate data source at this point that could replace this that ERDDAP could run from. Although looking at the error message you included @ocefpaf, it looks like it's PostgreSQL now, whereas last I looked it was still running Sybase, so maybe they've updated but the underlying parameter requirement is unchanged.

I got the 504 timeout error when trying to access the ERDDAP homepage link above just now. So it may be that it's just not operationally supported at the moment too.

The CO-OPS ERDDAP is very non-standard in that it requires the extra STATION_ID and possibly other parameters to return results.

Indeed. Not only that, they must be double quoted!

Although looking at the error message you included @ocefpaf, it looks like it's PostgreSQL now, whereas last I looked it was still running Sybase, so maybe they've updated but the underlying parameter requirement is unchanged.

I'm not sure if that is a red herring or a real error. Updating the date format fixes it, but there is still the matter of variable order in the URL that should not play a role in the query. (I may be wrong here. I haven't seem any ERDDAP server that requires variables to be in a fixed order.) See https://gist.github.com/ocefpaf/bb0fd4551d5c8ce91f4b778c8cc54ec3 for an example.

Needs ioos/erddapy#399

The jupyterbook/content/code_gallery/data_management_notebooks/2023-03-20-Reading_and_writing_zarr.ipynb is failing but the co-ops one is finally OK again. Let's merge this one and I'll fix the zarr syntax in another PR.