All Activity

I have installed and tested the latest WAsP 12.10 release, specifically Tool 1 – Create a project from GWA data, and noticed a minor but consistent issue. When retrieving an interpolated generalized wind climate, the KML export is always named Gwa3Interpolation.kml, regardless of whether GWA3 or GWA4 climate data is selected. This leads to the file being overwritten when exporting multiple datasets. While manually renaming the file is possible, the automatic link to Google Earth makes this inconvenient. It would be helpful if the file name reflected the selected GWA version to avoid confusion.

Thanks; looks solid, looks like an N-person-year paper. 10-12 m/s (2 offshore, 2 coast, 1 rough ) in Norway is waaay more than in low-wind south Germany.

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.

There seems to be issue with the API again. It's taking a long time to respond and eventually resorts to 502. The swagger page https://wps.neweuropeanwindatlas.eu/api/microscale-atlas/v1/docs#/ also doesn't load.

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

Neil, a new thread: "This project ended in 2018 ..." The big question is, how good is the NEWA data especially at 175m, the turbine height of most new WR in Germany ? Do you know of spotchecks against windspeeds from other sources or spotchecks against electricity actually produced? cheers -- denis

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/

Thanks Neil, I missed the WKT down inside xds.crs, my mistake -- print(xds) has only `crs int8 1B ...` 😞 Is there an FAQ that mentions 3035 ? Checking the corners with pyproj.Transformer.from_crs().transform_bounds I'd have expected to get very nearly N S W E of the bbox I asked for -- https://wps.neweuropeanwindatlas.eu/api/${scale}scale-atlas/v1/get-data-bbox S=47.5 N=50.5 W=9 E=13.5 -- 13jan-to4326-meso-3035.o transform_bbox x[0] y[0] x[-1] y[-1] -> 3035 -> n s 50.53633 47.45899 w e 8.948993 13.68524 should be ~ 50.5 47.5 9 13.5 ? -- 13jan-to4326-micro-3035.o transform_bbox x[0] y[0] x[-1] y[-1] -> 3035 -> n s 50.55306 47.4442 w e 8.936555 13.71815 should be ~ 50.5 47.5 9 13.5 ? On windkit, seems it's not on github and has HUUUGE deps; also https://pypi.org/project/windkit/ -> https://docs-wasp.ramtt.xyz/windkit dead link cheers -- denis

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.

Neil, the data looks as though it's just CRS 4326, so that the corner values of e.g. wind_speed [0 0] [0 -1] [-1 0] [-1 -1] correspond *exactly" to windspeeds at (N W) (N E) (S W) (S E). Is that right ? However the CRS is actually "ETRS89-extended / LAEA Europe" which is inconsistent with the values in south_north and west_east. Does that make sense to any of your colleagues or anyone at a university who has used NEWA ? Would you use a project with 0 support ? Thanks, cheers -- denis

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.

Hi Neil wouldn't it be better to say "down until tomorrow" than to deliver junk, or require users to retry retry ... How could you + IT accomplish that ? Afaik netcdf4 files are checksummed, and xr.open_dataset( ncfile ) checks that. However your files seem to be old netcdf3 ? I know a bit about CRSs; could you put me in touch with someone who has actually used yours, and time to look at code snippets say on gist.github ? Thanks, cheers -- denis

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.

Hi Denis, We have been having a lot of stability issues with the NEWA download system lately. I am wondering if the zeros you were seeing were related to that. I have tried deploying a new fix today. I tested with your link and did not see any zeros in it after deploying the fix. However, the first time I tried to download it, it was very slow. I then cancelled the download and did it again and got it quicker, which makes sense as there would have been some file-system caching that would have sped it up the second time. I know that our IT department is upgrading our storage system currently, so maybe this is related, although I think the issues have been going back to before they started that process. For the ETRS89-extended / LAEA Europe projection, I am not sure what kind of documentation you are looking for. You can find more information about it at https://epsg.io/3035. I don't think this has a markdown mode, but you can try to use code boxes to add things that you want formatted.

Hi NEWA people, I'm seeing many zeros in some .nc files like https://wps.neweuropeanwindatlas.eu/api/microscale-atlas/v1/get-data-bbox?southBoundLatitude=47.5&northBoundLatitude=48&westBoundLongitude=9&eastBoundLongitude=13.5&height=200&variable=wind_speed for example, quantiles [ 0 5 10 50 90 95 100] %: [0 0 0 6.8 8.6 8.9 12] slightly different at 100m and 200m for the same region but total file sizes differ a lot, odd. Can you reproduce this ? Also, is the CRS really "ETRS89-extended / LAEA Europe", is there doc on that ? A tiny test-nc.py with just numpy and xarray would be useful. (Is there a markdown mode here, where ?) Thanks, cheers -- denis

I've got the same response status

Hi, I can't download data, too, see this comment:

Hi, I have issues with the contact form at https://map.neweuropeanwindatlas.eu/contact After entering all required fields and doing the reCAPTCHA, the "Send Message" button is still grey and can't be clicked. I tried it with Edge, Chrome, and Firefox, both on my work PC and on my private phone. Please advise. Best, Michael

I'm unable ti download mesoscale dsta from NEWA. Is anyone else experincinh this? Do you know if it's a website issue?

Thanks Neil

Hi, I second Nadeem's motion. I've got issues with the API, too. To make sure that my code isn't the problem, I entered my parameters into the Swagger UI: Curl: curl -X 'GET' \ 'https://wps.neweuropeanwindatlas.eu/api/mesoscale-ts/v1/get-data-point?latitude=51.39&longitude=11.28&height=%5B50.0%2C%2075.0%2C%20100.0%2C%20150.0%2C%20200.0%2C%20250.0%5D&variable=%5B%22TKE%22%2C%20%22WS%22%5D&dt_start=%222020-01-01T00%3A00%3A00%22&dt_stop=%222022-12-31T23%3A30%3A00%22' \ -H 'accept: application/x-netcdf' Request URL: https://wps.neweuropeanwindatlas.eu/api/mesoscale-ts/v1/get-data-point?latitude=51.39&longitude=11.28&height=[50.0%2C 75.0%2C 100.0%2C 150.0%2C 200.0%2C 250.0]&variable=["TKE"%2C "WS"]&dt_start="2020-01-01T00%3A00%3A00"&dt_stop="2022-12-31T23%3A30%3A00" Error: response status is 502 Please advise. Best, Michael

Hello Neil, We are having trouble with API. Specifically, the 'get-data-point' API often gives 502 response code. At times it gives 200 response but without netcdf file content. Below are example API calls along with the timestamps at a dummy site. Kindly need your support. 2025-12-29 11:12:48.190 DEBUG:urllib3.connectionpool:https://wps.neweuropeanwindatlas.eu:443 "GET /api/microscale-atlas/v1/get-data-point?height=100&height=200&variable=wind_speed&latitude=55.960946&longitude=-4.385082 HTTP/2.0" 502 11 2025-12-29 11:12:48.190 DEBUG:urllib3.util.retry:Incremented Retry for (url='/api/microscale-atlas/v1/get-data-point?height=100&height=200&variable=wind_speed&latitude=55.960946&longitude=-4.385082'): Retry(total=2, connect=None, read=None, redirect=None, status=None) 2025-12-29 11:13:09.766 DEBUG:urllib3.connectionpool:https://wps.neweuropeanwindatlas.eu:443 "GET /api/microscale-atlas/v1/get-data-point?height=100&height=200&variable=wind_speed&latitude=55.960946&longitude=-4.385082 HTTP/2.0" 200 None

Hi Rémi, Thanks for letting us know. You are correct that there was a server issue. It has now been fixed. Best, Neil

Hello team, for some reason I can't visualize any data layers on https://map.neweuropeanwindatlas.eu/, is there an issue with the server maybe? BR Rémi

Dear WAsP Support Team, I hope you are doing well. I am currently working on verifying some academic data and grade conversions, and I’m encountering inconsistencies when comparing computations between different online GWA (General Weighted Average) tools. To validate the results, I tested several calculators, including one from a site I frequently use for Philippine academic grading. An online GWA calculator that provides GWA, GPA and percentage conversions. However, when I compare the results from these tools with values processed in WAsP-related workflows, the calculations do not fully align specifically when weighted inputs or multi-unit records are involved. My questions are: Could WAsP’s handling of weighted averages differ from standard academic weighted-average calculations? Is there any known issue when using externally computed data (such as GWA values) within WAsP data processing steps? Are there recommended guidelines for ensuring consistency when importing numerical values or derived datasets? Any advice, clarification, or documentation would be greatly appreciated. Best regards,