[CRS of time series download]

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

[CRS of time series download]

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.

[UTM of time series]

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

[PyWAsP 0.6.0 and Windkit 0.7.0 released]

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

[Download request INTERNAL_ERROR]

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)

 

[Download request INTERNAL_ERROR]

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.

 

[a spatial resolution in GWA and GASP]

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.

[PyWAsP 0.5.2 and Windkit 0.6.3 released]

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

[Windkit 0.6.2 Released]

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

[Issue with windkit's to_rsffile function]

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.

[Issue with windkit's to_rsffile function]

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"]`

[First bug-fix release of Windkit and PyWAsP]

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

[[Windkit] 10min data to tab]

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.

[[Windkit] 10min data to tab]

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.

[[Windkit] 10min data to tab]

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

[[Windkit] 10min data to tab]

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.

[Additional features for OpenDAP handling]

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.

[how to use PyWAsP or process]

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.

[visualising and downloading specific lib files]

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.

[Windkit: Possible bug when infering number of sectors from RSF file]

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

[PackagesNotFoundError: The following packages are not available from current channels: - wind-validation]

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.

[Energy Yield Calculator Issue]

On 03/01/2022 at 6:19 PM, Gururaj said:

Hi Neil,

I am unable to extract any information from the downloaded .tif file (AEP). I just double click the file to read it . Is there any other option / software to open the file. I select a region in rectanglar form as a bouding box. Even then i see no information in the file.  Please correct my understanding.

Hi Gururaj,

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

[Energy Yield Calculator Issue]

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.

[Energy Yield Calculator Issue]

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.

[Additional features for OpenDAP handling]

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")