All Activity
- Earlier
-
Hm, then I am really not sure. Perhaps the URL is not accessible for you somehow. Can you access the URL "esa-worldcover.s3.eu-central-1.amazonaws.com" directly?
-
Hello Rogier! Thank you so much for your time and your help. I used your script: "Create bounding box form lat/lon" for create the rectangular polygon and then use it to run the script "Get Worldcover landcover polygons" but with same result . Unfortunately, the error continues while I'm trying to connect with it seem the original data source host='esa-worldcover.s3.eu-central-1.amazonaws.com'. I tried in version 3.14 & 3.28. Next, I copy the error message that QGis shows. Should I have to connect with a different URL? Thanks in advance Dulce 2023-09-18T12:48:56 CRITICAL Traceback (most recent call last): File "C:\PROGRA~1\QGIS32~1.2\apps\Python39\lib\site-packages\urllib3\connection.py", line 159, in _new_conn conn = connection.create_connection( File "C:\PROGRA~1\QGIS32~1.2\apps\Python39\lib\site-packages\urllib3\util\connection.py", line 84, in create_connection raise err File "C:\PROGRA~1\QGIS32~1.2\apps\Python39\lib\site-packages\urllib3\util\connection.py", line 74, in create_connection sock.connect(sa) TimeoutError: [WinError 10060] A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond During handling of the above exception, another exception occurred: Traceback (most recent call last): File "C:\PROGRA~1\QGIS32~1.2\apps\Python39\lib\site-packages\urllib3\connectionpool.py", line 670, in urlopen httplib_response = self._make_request( File "C:\PROGRA~1\QGIS32~1.2\apps\Python39\lib\site-packages\urllib3\connectionpool.py", line 381, in _make_request self._validate_conn(conn) File "C:\PROGRA~1\QGIS32~1.2\apps\Python39\lib\site-packages\urllib3\connectionpool.py", line 978, in _validate_conn conn.connect() File "C:\PROGRA~1\QGIS32~1.2\apps\Python39\lib\site-packages\urllib3\connection.py", line 309, in connect conn = self._new_conn() File "C:\PROGRA~1\QGIS32~1.2\apps\Python39\lib\site-packages\urllib3\connection.py", line 171, in _new_conn raise NewConnectionError( urllib3.exceptions.NewConnectionError: : Failed to establish a new connection: [WinError 10060] A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond During handling of the above exception, another exception occurred: Traceback (most recent call last): File "C:\PROGRA~1\QGIS32~1.2\apps\Python39\lib\site-packages\requests\adapters.py", line 439, in send resp = conn.urlopen( File "C:\PROGRA~1\QGIS32~1.2\apps\Python39\lib\site-packages\urllib3\connectionpool.py", line 726, in urlopen retries = retries.increment( File "C:\PROGRA~1\QGIS32~1.2\apps\Python39\lib\site-packages\urllib3\util\retry.py", line 446, in increment raise MaxRetryError(_pool, url, error or ResponseError(cause)) urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='esa-worldcover.s3.eu-central-1.amazonaws.com', port=443): Max retries exceeded with url: /v100/2020/map/ESA_WorldCover_10m_2020_v100_N12W090_Map.tif (Caused by NewConnectionError(': Failed to establish a new connection: [WinError 10060] A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond')) During handling of the above exception, another exception occurred: Traceback (most recent call last): File "C:\Users/----/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\wasp_scripts\processing_provider\worldcover.py", line 291, in processAlgorithm r = requests.get(url, allow_redirects=True) File "C:\PROGRA~1\QGIS32~1.2\apps\Python39\lib\site-packages\requests\api.py", line 76, in get return request('get', url, params=params, **kwargs) File "C:\PROGRA~1\QGIS32~1.2\apps\Python39\lib\site-packages\requests\api.py", line 61, in request return session.request(method=method, url=url, **kwargs) File "C:\PROGRA~1\QGIS32~1.2\apps\Python39\lib\site-packages\requests\sessions.py", line 530, in request resp = self.send(prep, **send_kwargs) File "C:\PROGRA~1\QGIS32~1.2\apps\Python39\lib\site-packages\requests\sessions.py", line 643, in send r = adapter.send(request, **kwargs) File "C:\PROGRA~1\QGIS32~1.2\apps\Python39\lib\site-packages\requests\adapters.py", line 516, in send raise ConnectionError(e, request=request) requests.exceptions.ConnectionError: HTTPSConnectionPool(host='esa-worldcover.s3.eu-central-1.amazonaws.com', port=443): Max retries exceeded with url: /v100/2020/map/ESA_WorldCover_10m_2020_v100_N12W090_Map.tif (Caused by NewConnectionError(': Failed to establish a new connection: [WinError 10060] A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond'))
-
I looked at your polygon and the first problem is that it is in a geographic coordinate system. So you will have to reproject to for example a UTM projection. Another problem is that ideally your bounding box should be rectangular so we can crop the boundary lines. I recommend to use the newest plugin that I uploaded: https://data.dtu.dk/articles/software/Using_QGIS_to_create_WAsP_maps/20495178 There is a new script included where you can create a bounding box from lat/lon and a option to download worldcover data. I have also updated the instruction videos.
-
Hello Rogier, Sorry for my delayed answer. Here is the polygon in .shp format https://drive.google.com/drive/folders/1wm32IwDg40uBrkXU313USWJR6SYV0f2y?usp=sharing Could you reproduce the error? This continiuous. Thanks
-
Chanon Mahisanan joined the community
-
Hi Neil, Thanks for details. I had to check and compare. also read other papers as well from them, I have concluded one cell size of 275m x 250m resolution based on GASP.
-
danghoangtung joined the community
-
Hi Lidia, Here (https://www.wasp.dk/wasp/calculation-of-wind-farm-production), you will find information on how the Annual Energy Production (AEP) is calculated in WAsP: Annual energy production + Wake losses —> Net annual energy production of entire wind farm For further details about the wake model being utilized, please refer to this link: https://www.wasp.dk/wasp/wake-effect-model If you need to calculate AEP that includes technical losses and uncertainty, you can utilize the Windfarm Assessment Tool (WAT) provided in the WAsP Bundle. Learn more at: https://www.wasp.dk/wat/wataep. Best regards, Katerina
-
Good morning, I would like to gain a better understanding of the losses that WAsP takes into account. I know that there's the wake effect but what are the rest? And What models to you use to calculate them? Thank you in advance 🙂 Lidia N
-
Dear Mustafa The new suite doesn't have Wasp 11. If I installed this suite, would my licensed v.11 version will work?
-
Is the problem perhaps that we started to require a projection to be specified, and in earlier WAsP you could use Lambert or any other projection? The only time we needed the projection was for Google Earth rendering, so if you skipped that you could probably keep working. Now in WAsP 12 we depend more strictly on the projection because we need to offer auxiliary data for the GWCs. I guess this is what you've found: you open an old project and we start nagging you to set the projection, and you can't find the Lambert projection there? We are working on this, but I can't give you a date for a fix, I'm afraid. If you have WAsP 11 installed, and you run the latest WAsP 12 suite installer, then 11 will be updated to the latest version, but version 11 is not installed if it hasn't been installed previously. Do you have and old WAsP suite installer including W11? If not, then email me directly and I'll send you a link.
-
Another way to address this question is to by considering the data in the classic GWC files: the LIB format. Looking at the modelling workflow on page 584 of the EWA, we can see that there are four stages of calculation between geostrophic wind climate and the data in the generalised wind climates. To do these calculations, I think that we would need the latitude, friction velocities, surface land fractions, and heat flux parameters for stability corrections. None of these are stored in the LIB files. Instead, we do these calculations in the generalisation and then store results for standard conditions. As Rogier says, this was convenient in the past, and in practice causes only negligible interpolation errors in most cases. Note that the stability correction is applied at the very last stage of preparing the GWC. This is why the wind speed profiles in the GWC data set are not logarithmic.
-
Hi Duncan, There was no problem to work with Lambert 93 coordinates under WAsP11, but, ok, it is not possible under WAsP12; the problem i have is to transform roughness maps, from Lambert 93 to UTM; which is not easy. Well, i was working with 2 PCs, one with WAsP11, and one with WAsP12, but only one now is left, with WAsP12; i asked WAsP support to know if i can install WAsP11 after WAsP 12 on my PC left, without answer at that time... Best wishes
-
Hello Antoine, I'm a bit confused by your question. The set of available projections in WAsP has not changed between WAsP 11 and WAsP 12, as far as I know. Lambert is not included in the list. The latest Map Editor does support Lambert, but WAsP 12 has not yet received a corresponding update. So for WAsP work, Lambert is not yet possible. I don't think it was possible before, though. Best wishes, Duncan.
-
Hello everyone, I am having the same problem as Kwak, with the Energy Yield calculator showing up as "Currently Not Available" in the Global Wind Atlas website. Hopefully we will get an update on the issue soon :)
-
delirious1290 joined the community
-
I have been working with WAsP11 projects for years, in Lambert 93 coordinates; Is it possible to work with these projects under WAsP12?? Thanks
-
Antoine MOLIN joined the community
-
Neil Davis started following 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.
-
Dear Team, based on the Information available from: https://globalwindatlas.info/en/about/introduction, a grid spacing of 250m for microscale mode was generated. this was double-checked in the report: Larsén, X. G., Davis, N., Hannesdóttir, Á., Kelly, M., Olsen, B., Floors, R., Nielsen, M., & Imberger, M. (2021). Calculation of Global Atlas of Siting Parameters. DTU Wind Energy. DTU Wind Energy E No. E-Report-0208 however, the report: The Global Atlas for Siting Parameters project: Extreme wind, turbulence, and turbine classes - Larsén - 2022 - Wind Energy - Wiley Online Library shows at a 275m resolution. could you pleaes clarify which one is the correct resolution? if I misunderstood something, could you please advise me? Regards, Gyeongil
-
yogi.murthi joined the community
-
ManPC joined the community
-
Dear Neil, it seems that the problem is not solved or there maybe an update of this feature. i tried to test a few countries following the video tutorials "https://globalwindatlas.info/en/about/VideoTutorials". however, whatever I do, i end up with a message " Currently now available" in Energy Yield tab. could you please double check and fix if you see the same problem? Thanks. Gyeongil
-
Yes, you can either attach it here or send it to the support: https://www.wasp.dk/support
-
Could I sent you by an URL to google drive with shapefile?
-
Yes there is no height and roughness classes there, but I don't think this is what WindPRO is using. This code is in beta and has not left DTU as far as know. Regarding your other questions: the problem is that the observed wind climate is valid for a certain roughness and height, so if your output location is not for exactly that location you will need more information about what the wind climate is for other heights and roughnesses.
-
Could you sent me the polygon that you are using? Because I can't reproduce the error.
-
yes, that's what I did before, cut with ONE polygon layer. But it gives me an error that it can't connect to the page I mentioned, that's why I think it needs to connect to the URL for the whole script to run correctly.
-
Hi Rogier, thank you for the explanation. An interesting information is that WAsP knows, beyond its GUI, to calculate directly from geostrophic wind to local wind, without generalization. It means that for such calculation, no height and roughness classes are applied? This is what WindPRO uses in its time series calculation (the scaler)? Though I still struggle to fully understand the logic. I would expect that it would be sufficient do define the general wind climate for just one roughness and one height and the rest can be derived from it. And that the recalculation to different classes would be relatively simple, without need to store pre-calculated data, because this it is not site- and project- dependent. Am I wrong? The most confusing thing to me is that different general wind climatologies sometimes provide different wind shears. You write that if my input wind climate, height, location and stability for the generalization is the same and the wind climate at z0=0.1 and h=10 m is the same, all other heights and roughnesses should also be the same. This is expectable. But why this need not apply if the wind climate at z0=0.1 and h=10 m is the same, but the wind climate, height, location and stability for generalization are different? David
-
Hi David, these are some good questions. Since some of these decisions were already made when WAsP was developed for the first time (80s/90s) and I have been at DTU only since since 2010 I can only give you my best guesses. 1) The generalized wind climate can be considered as a lookup table for the wind climate conditions. Typically, the workflow would be that you have one mast that you convert to a generalized wind climate and apply it to many turbines positions or a many points (resource grid). Therefore it computationally it make sense to do the transformation to a generalized wind climate only once. For all turbine positions or points in a resource grid we then only have to do a lookup in the generalized wind climate and not reprocess the whole histogram. Technically, the input histogram is actually first converted to a geostrophic wind climate (using the geostrophic drag law) and the the down transformation is continued (see page 585 here: https://backend.orbit.dtu.dk/ws/portalfiles/portal/112135732/European_Wind_Atlas.pdf ). But you could also continue from the geostrophic wind climate straight to the output locations, thereby removing some of the small interpolations errors that are made when interpolating the generalized wind climate. There is some code for doing this that we may introduce in the future, but it is not available in the WAsP GUI, also because the interpolations errors are typically very small. It is also easier to compare wind conditions if you have some standard heights and roughness you can compare with (as is done in the original european wind atlas tables). So in other words, the generalized heights and roughness are not strictly required but just a model choice that were made at some point. 2) The generalized wind climate is already 'cleaned' for effects of stability so these will not have an impact. So if your input wind climate, height, location (comes in via the coriolis parameter which depends on latitude) and stability for the generalization is the same and the wind climate at z0=0.1 and h=10 m is the same, all other heights and roughnesses should also be the same. 3) The main rules of thumb related to the generalized wind climate are to set the height of your observations and prediction close the heights of the generalized wind climate. Like that there will be minimal interpolation errors related to heights. Typically the generalized roughness classes interpolation errors are harder to avoid, unless the roughness length at your site is the same for all wind directions. If there are differences in roughness, you can set them so that the roughness length classes span the mesoscale roughnesses that are observed in your observed wind climate and your predicted wind climate. 4) The only literature that described the generalized wind climate procedure (as far as I know) is the European wind atlas itself (mostly around page 585). Some details may be different in the code that is currently in WAsP though.
-
i suggest extract as csv file within the pywasp using windtool kit rather than download and extracting.