Neil Davis

The issue is that the time-series data is a raster in the projected space, but not in the lat/lon space. Therefore, the XLAT/XLON have to be two-dimensional, as the values at each point depends on both the x and y dimensions. The approach from David above will give you a non-raster dataset in the new projection. If you want to get a raster back in the new projection, you can use the Windkit tool we have developed, which will "warp" the data from one projection to another, keeping the grid spacing approximately the same. When warping, you will be performing an interpolation, nearest neighbor by default. import windkit as wk import xarray as xr ds = xr.open_dataset("mesotimeseries-Area 2.nc") ds ds_warped = wk.spatial.warp(ds, 3035) ds_warped

The timeseries data is defined on a lambert conformal grid. The WKT of the grid can be found in the crs_wkt attribute of the crs variable of the downloaded NetCDF file. It doesn't have an EPSG as it is a custom projection defined specifcally for the NEWA mesoscale simulations.

The timezone is UTC, so it is the same everywhere.

We have released new versions of PyWAsP and Windkit. Both versions include breaking changes, but only a small number. The highlights of Windkit include improved interpolation routines, several improvements to the map conversion tools to create polygon data from your roughness line maps, and additional derived fields for weibull wind climates. Full release notes can be found at: https://docs.wasp.dk/windkit/release_notes.html#id1 For PyWAsP the hightlights include a bugfix to the license manager on Windows, so now this should work correctly. We have also updated the dependencies, and aim to follow the SPEC-0 versions of our Scientific Python dependencies. This means that Python 3.10 is the oldest version of Python supported with this release. You can now use WAsP CFD results files for estimating your predicted wind climate, and we have improved the performance of the AEP calculator. Full release notes are found at: https://docs.wasp.dk/pywasp/release_notes.html#id1

I think the issue is that the library you are using is quite old and only supports TLSv1. We have recently disabled TLSv1 and TLSv2. There is also a space between 2018 and -12 in the dt_stop variable of the URL you pasted above. Here is a script using python3 that I used to download and save the file to a named temporary file. from urllib.request import urlopen from shutil import copyfileobj from tempfile import NamedTemporaryFile url = 'https://wps.neweuropeanwindatlas.eu/api/mesoscale-ts/v1/get-data-point?latitude=53.800651&longitude=3.955078&variable=WD10&variable=WS10&dt_start=2018-12-20T00:00:00&dt_stop=2018-12-31T23:30:00' with urlopen(url) as fsrc, NamedTemporaryFile(delete=False) as fdst: copyfileobj(fsrc, fdst)

What is the URL you are trying to access? The OpenDap service has been removed, about a year ago, after we restructured our data on the backend. You should now use the daTap interfaces explained in the forum post below for accessing the data.

Hi Gyeongil, Sorry for the confusion. The answer is that technically both are correct and neither is correct. Both the GWA and GASP were run on UTM projections with a 250m grid spacing. However, to make the global map, these were interpolated to a lat/lon map projection with a grid spacing of 0.0025 grid spacing. This has then often been presented as a 250m grid spacing, using the approximation of 100 km per degree. However, for the GASP paper it was decided to use the more accurate 111 km per degree, which would then come to 277.5m, which we rounded to 275. Of course, both the 275 and 250m resolutions only apply to longitude near the equator. Hope this helps.

We have released new versions of PyWAsP and Windkit. The highlights of Windkit include further improvment to the writing of wrg/rsf files, the ability to read polygon based landcover features, and enhanced the bounding box object. Full release notes can be found at: https://docs.wasp.dk/windkit/release_notes.html#id1 For PyWAsP the hightlights include a bugfix to the gross_aep calculator, where previously all turbines were assumed to be stall regulated when performing air density adjustments. Now you need to define a variable `regulation_type` on you wind turbine variables, which ensure the correct air density adjustment is applied. Full release notes are found at: https://docs.wasp.dk/pywasp/release_notes.html#id1

We have released windkit 0.6.2 which includes a few new functions for reading time-series data and cfdres files into Windkit. We also fixed an issue with writing RSF and WRG files from PyWAsP downscale output. Full release notes can be found at: https://docs.wasp.dk/windkit/release_notes.html#id1

Sorry for the long delay. We have fixed the issue in an updated release of Windkit 0.6.2. You should be able to install it from both pip and mamba now.

Hi, Sorry for this error. The issue is that by default elevation is not included in the result from `get_wasp_down`, but is required for creating the RSF. The easiest fix would be to set the argument `return_site_factors` to `True` in the call to `get_wasp_down`, this will include all of the site effects in the `pwc_rsf` variable. Alternatively, you could just copy the elevation like `pwc_rsf["elevation"] = site_effects["elevation"]`

We are happy to announce the release of Windkit 0.6.1 and PyWAsP 0.5.1. These have fixed a few issues reported to us. The main highlight is that we have fixed an issue with PyWAsP's licensing check that prevented it always working correctly in Docker containers. Full release notes can be found in documentation for each project: WindKit 0.6.1 PyWAsP 0.5.1

Hmm good to know about Jupyter lab, will take a look at that as well to see if it is the same issue as the REPL. We haven't advanced past the notebook interface yet 🙂 Glad to hear that the package is so helpful. We have already started discussing an interface for helping convert pandas based timeseries to our xarray time-series format, so hopefully this workflow will be easier in the future.

I can take this one. There is a challenge here when you are using the Python REPL. If you use ipython, a jupyter notebook, or call it as a script the code will work. I have an issue pending about giving a better error message here.

Great, thanks. Hope the XArray to BWC works for you.

Hi Andrea, We don't have a pandas to bwc, but we have an XArray Time-series dataset to bwc converter. You can find the docs for that at: https://docs-wasp.ramtt.xyz/windkit/io/wc_autogen/windkit.binned_wind_climate.bwc_from_timeseries.html#windkit.binned_wind_climate.bwc_from_timeseries It would be interesting to know the structure of the pandas data that you have, as we are looking to add more functionality to the time-series handling this year, and creating an XArray tswc from pandas is probably something that would be good for us to support.

Hi We are aware of some performance issues. We are currently focusing on processing the remaining 20 years of NEWA data, and then will revisit performance. For now, it seems that best performance is found when downloading data in 6-month intervals, as this matches best with the resources on the server. You have the correct URL. I am not sure why data would be provided with some data missing, as it should either succeed or fail. Could you provide a list of the variables that you are using so that I can do some testing? I will be on holiday starting Wed, so won't get a chance to look until the new year unfortunately.

Hi Gyeongil, We are currently gearing up for a release of PyWAsP in Q1 next year. It will be a separate product from WAsP and will therefore require an additional license. We will announce more information when we are closer to release.

We don't have this option available at present. The points are approximately 3 km apart, which may help you in identifying how far apart you should query each point. We are working on a new API infrastructure, which should allow users to download all lib files in a bounding box. The goal is to have this available before the end of the year.

Thanks for the bug report. I have forwarded it to our team, and hopefully we will have a fix out before too long.

Hi Shehan, Thanks for sharing this with us. This is due to a typo, the name of the package is wind_validation, with an underscore. We will be updating our documentation to fix the issue.

Hi Gururaj, We have had a lot of success with Q-GIS, which is an open source GIS software.

We have made a change to the website so that now bounding boxes should always be sent to the Energy Yield Calculator, which should have solved this problem.

We have recently have a number of questions about empty GeoTiff files from the energy yield calculation. In most of those cases it has related to using a polygon for the area being calculated rather than a rectangle. We are discussing ways to fix this internally, but for now if you make your request a rectangle you should be able to get results for your region.

We have an API that converts a GeoJSON polygon bounding box to the indices used in the OpenDAP queries used to download of the mesoscale time-series. The query will return an XML file that has a complex data element, which contains the indices for the west_east and south_north dimensions. This can then be substituted into the download. https://wps.neweuropeanwindatlas.eu/cgi-bin/?SERVICE=WPS&VERSION=1.0.0&REQUEST=Execute&IDENTIFIER=opendap_helper&DataInputs=location={"type":"Polygon","coordinates":[[[14,52],[16,52],[16,54],[14,54],[14,52]]]} Additionally, several users have asked about using the OpenDAP service with Python. We have used XArray for this purpose, using a command like below: ds = xr.open_dataset("http://opendap.neweuropeanwindatlas.eu/opendap/newa/NEWA_MESOSCALE_ATLAS/2015/NEWA-2015-12-30.nc?WS[0:1:47][2:2][674:1:674][628:1:628],WD[0:1:47][2:2][674:1:674][628:1:628],time[0:1:47],height[2:2],west_east[628:1:628],south_north[674:1:674],XLON[674:1:674][628:1:628],XLAT[674:1:674][628:1:628],Times[0:1:47],crs")