ncss download inconsistency about daymetr HOT 3 CLOSED

This issue is still unfixed, or returned for some reason (refresh of the system).

The coordinate system is missing in the ncss queries, which results in errors with raster reads, failing the unit checks. The required coordinates system should read something like this.

I blank out the unit tests until this gets resolved after the gov. shutdown.

+proj=lcc +lat_1=25 +lat_2=60 +lat_0=42.5 +lon_0=-100 +x_0=0 +y_0=0 +a=6378137 +b=6356752.314706705 +units=m +no_defs

from daymetr.

Things are stable again it seems.

We have applied a new configuration on storage, which we hope is addressing the data corruption issue. If you are still seeing corrupt data, we have another solution to this on-the-ready but we have not implemented on the public server. That is, to throttle requests when requests are too high.
If you feel corrupted files are still being delivered, we might see if you can do some testing to see if the throttling soln corrects the problem.

The issue of needing specifically formatted coordinate reference system information in the netCDF files.

Just today as a result of your message and the user contacting us, I noticed a subtle inconsistency in an attribute of the lcc coordinate reference system in our files. I think it’s due to an update to IDL that went un-noticed.

Can you tell me if one of these files works differently than the other in your DaymetR code?

daymet_v3_vp_2017_puertorico.nc4 vs daymet_v3_vp_2015_puertorico.nc4

from daymetr.

fixed

from daymetr.