Neil Davis

Hi Alexandru, Thanks for the issue report. Can you let us know what version of pywasp you are using? We will then take a look and get back to you. Best, Neil

Hi Vittorio, Thanks for reaching out. Yes we were overwhelmed with requests last week and had to implement some changes to avoid impact on our systems. We have currently set a limit of 4 requests per minute. If you are in need of a larger area from the timeseries, rather than trying to download it point by point, please reach out via the contact form, and we will see if we can create the subset for you. This will in part depend on how many requests we get and how big of a dataset you are requesting.

Hi Kiko, The mesoscale time-series is not available for download by bounding box, only the atlas data. We hope to return this functionality soon, but it will come with registration and a limit on the amount that can be downloaded. We are currently testing this functionality and hope to roll it out within two months.

For access to ERA5 data, you could also try to make use of the Earth Data Hub, which is part of the DestinE project, which might be faster than the ECMWF direct access.

Perhaps these images can help explain it. The name of the image is the "viewport" projection, the red box has been defined in lat/lon (epsg:4326), while the data is in the EPSG:3035 projection. You can see how the different areas warp when the viewport projection is changed. The data in its native projection is rectangular, while the one that is being projected to the viewport projection is tilted or warped. This is expected due to the warping of the earth when converting from the spherical lat/lon projection to a flat projection like the LAEA (EPSG:3035).

Hmm that is strange, so like the area that you have selected is not represented by the data that is extracted?

Hi Calum, Unfortunately there is a bug in our NetCDF file. You would need to modify the file to add the grid_mapping attribute to the file. This can be done using e.g. the ncatted tool from the NetCDF Operators library. E.g. ncatted -a grid_mapping,wind_speed,c,c,"crs" microclimate_test.nc microclimate_test_new.nc Alternatively, you can set in QGIS the projection to EPSG:3035, which is the projection used by the file.

Hi Calum, For me to properly test, can you tell me which type of file did you download the mesoscale or microscale, and was it a single point or a bounding box? Best, Neil

Hi Antoine, I don't remember us providing another interface to these data other than the data extraction as NetCDF. The data is listed on data.dtu.dk, but it is just metadata pointing to the API. As you were mentioning ASCII, perhaps you were downloading them via the API in the application-xgrdfile format, which is the same as GDAL's GSAG format. Best, Neil

Thanks for letting me know. I don't see any issues on the server. I have spun up some extra resources, hopefully that will help to make it more responsive.

Maybe this paper? https://wes.copernicus.org/articles/10/733/2025/

The issue you are seeing with the bounds being different is related to the fact that the LAEA project is not regular in lat/lon so there is a distortion when transforming the bounding box from lat/lon to LAEA and back again, as you can see below. import pyproj t = pyproj.Transformer.from_crs(4326,3035, always_xy=True) b_3035 = t.transform_bounds(left=9, right=13.5, bottom=47.5, top=50.5) print(b_3035) (4245607.3726488, 2709598.8210897828, 4584770.809779363, 3049053.257389913) b_inverse = t.transform_bounds(*b_3035, direction="INVERSE") print(b_inverse) (8.936300980840397, 47.443940587988436, 13.718813708104847, 50.553312900580195) Then there is an additional offset because of the grid spacing, so for the mesoscale it is about 3km in the map projection, and for the microscale 50m. Thanks for noting the dead link, the documentation has been moved to https://docs.wasp.dk/windkit/latest/

I'm confused about what you are asking. The data is provided in the EPSG:3035 CRS, if you want to get the latitude and longitude values, you will need to reproject to say EPSG:4326. You could for example use WindKit for doing this reprojection. Note that depending on how you do the reprojection you will either be interpolating the data or no longer have a regular grid. After loading into python and looking at the first four values of the west_east and south_north dimensions I don't see values that are 0 and 1, but more like 4 million, and 2 million. These correspond to the position in the EPSG:3035 CRS. ds.isel(south_north=[0,1,2], west_east=[0,1,2]).load() Out[5]: <xarray.Dataset> Size: 89B Dimensions: (west_east: 3, south_north: 3, height: 1) Coordinates: * west_east (west_east) float64 24B 4.246e+06 4.246e+06 4.246e+06 * south_north (south_north) float64 24B 2.771e+06 2.771e+06 2.771e+06 * height (height) int32 4B 200 crs int8 1B 0 These do not correspond directly to the corner points that you include as we only have data every 50m, so we clip the data to include the grid cell that includes your corner points, and then include all data between those corners.

This project ended in 2018, we are doing our best to continue to maintain it, but sometimes things break, and it can take a while for us to get to them. We could take them down, but it would likely be for much longer than a day. If you would like to host the data, it is available under a CC-4.0 BY license and we could discuss sharing a full copy of the data with you. We are working on new solution that we hope to make available in the first half of the year, which should help to make this system more stable, but it will take time for us to finish development of it. Not knowing where the 0 values were coming from it is hard to say if checksums would have fixed the issue. The NetCDF files that we create are created dynamically out of a larger Zarr dataset, if the zeros are coming in because of issues reading the Zarr data then the NetCDF would have a checksum that includes them. Yes, our files are written as NetCDF3 as that is the only format that can write Bytes directly to NetCDF in Python, by using the scipy NetCDF writer. I'm not sure what you are asking for with regards to the CRSs and code snippets. If you are asking for someone to help you debug / develop code, we would likely need to create a project around this as we do not have any internal funding to support that for NEWA data at this time.

Sorry for the delay in getting back to this. It got lost in my post vacation to-do list. I have tried deploying a fix this morning. It seems like downloads are still very slow, I am not sure why, but the server should be more stable now and allow you to actually get the data eventually. I found in some cases that cancelling and restarting a download could improve performance.