-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CSIS URI variables in praxis 2 [HC-LE]: Local Effects for Heatwaves #45
Comments
Potential Issues:
Wiki also claims the need for the baseline RPC, but this makes no sense to me. At baseline time period all RPCs must deliver the same result and there is AFAIK no scenario claiming that the future climate will remain the same. Do we need this? Question: is this the way to go? |
Please remark: See also discussions in #42 |
@humerh: I replaced the template URLs listed under Local Effects or Heatwaves with some variables and got the following errors:
|
Ignoring STUDY_VARIANT and EMISSION_SCENARIO (which is not needed for time period baselkine), I get an empty result for https://service.emikat.at/EmiKatTst/api/scenarios/2846/feature/view.2974/table/data?rownum=1000&filter=TIME_PERIOD%3D%27Baseline%27&filter=EVENT_FREQUENCY%3D%27rare%27&filter=SZ_ID%3D2846 |
You have to use the correct spelling: But this was not only your error, I had some errors to correct. I hope, it is now ok! |
The correct spelling is also neccessary for WMS call: |
@humerh OK, great. This works: Could you please rename Ocas
|
|
This returns empty set atm :-( By the way: according to this discussion thread, single quotes should not be used in URIs. However, when I try removing them, the call fails completely. replacing %3D with = is OK, replacing %27 with single quotes causes the call to fail completely. It would be good if we could dispose with %27, to make the URIs more readable => less probable to make an error. |
Based on this, I have entered this link for the WMS in https://csis.myclimateservice.eu/node/1272 The problem is that this isn't working now. I'm not going to update other links until I can test them. :-( |
One can indeed ignore some filters, but I would advise against it in production system.
It's IMO better to always explicitly set a filter and check if anything is returned than not to set it and risk getting double the amount of the data... |
Now, the following URLs return an empty results: :-( Yesterday, they used to work.
@humerh Can you please fix this ASAP as I need a dependable API for client development. Thanks. |
This works again now. Thanks, Heinrich. |
I fixed the problem. |
Status:
I'll change it all in the https://csis.myclimateservice.eu/node/1272 so that the URIS are easier to read. |
The "Baseline" emission scenario has been missing. I have added it now and gave it a good explanation, but this means that our software will need to know that baseline scenario can only be combined with baseline time. Hard-coded in the logic. :-( https://csis.myclimateservice.eu/taxonomy/term/2256 I have also removed all %XX signs from the links used. E.g. the one used for the map now is: https://service.emikat.at/geoserver/clarity/wms? plus: service=WMS&version=1.1.0&request=GetMap&layers=clarity:view.2974&bbox=4672000.0,1979500.0,4687500.0,1988000.0&width=768&height=421&srs=EPSG:3035&format=image/gif&CQL_FILTER=STUDY_VARIANT='${study_variant}' and TIME_PERIOD='${time_period}' AND EMISSIONS_SCENARIO='${emissions_scenario}' AND EVENT_FREQUENCY='${event_frequency}' AND SZ_ID=${emikat_id}&styles=T_A (formatting breaks here, so I took it apart) |
There are even more pitfalls: ${emikat_id} in the URL is sometimes replaced to |
That looks really promising now. I looked at maximal damage and damage probability and it changes with period and scenario as one would expect. :-) |
Oh, what a happy day! :-(
Is this affecting us when we use these links from JavaScript programs?
And if yes: how to handle this?
…On Fri, 20 Sep 2019, 17:02 Pascal Dihé, ***@***.***> wrote:
There are even more pitfalls: $*{emikat_id}* in the URL is sometimes
replaced to $%7Bemikat_id%7D(by the browser?).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#45?email_source=notifications&email_token=AAWTC7U254O2VLAZPA5BYXDQKTQZ3A5CNFSM4IXC6P3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7G7EAQ#issuecomment-533590530>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAWTC7WAIE6D66ME2YYY3O3QKTQZ3ANCNFSM4IXC6P3A>
.
|
I just tried the test table introduced by @p-a-s-c-a-l in #46 (comment) on local effects of heatwaves. It's very easy, just do this:
|
Heinrik has removed the "&filter=SZ_ID=${emikat_id}" part from the table URIs - I'll rewrite the resource now. (Someone already did this, except or the "download path") Less good news is that we need to define a way to handle three different temperatures that are returned by this view: T_A, T_MRT, T_UTCI
In fact, this is also delivering the "discomfort level"... For now, it is only possible to differentiate between these three cases (and discomfort?) in the maps, so I will add two more resources. But beware: the table data is exactly the same for al three at the moment, this needs fixing. |
OK, done. I have also removed the surplus hazards tags from all three, to avoid duplication in the data tab. Beware: since the tables are the same for all three atm., I haven't duplicated the related yet. This needs to be done once these references can be split. Oh jee. Map component is not showing this properly. Opening a new issue report: :-( |
Implemented and working. |
Related to #42, #45, #46, #47, #49
I have implemented a "Local Effects or Heatwaves" resource following the instructions from the https://github.com/clarity-h2020/csis/wiki/Services-endpoints-(used-by-CSIS).
The result is https://csis.myclimateservice.eu/node/1272 and now I wonder if this is aright way to do it.
For a start, this is how URIs look: https://service.emikat.at/EmiKatTst/api/scenarios/${emikat_id}/feature/view.2974/table/data?rownum=1000&filter=PROJECT%3D${study_variant}&filter=PERIOD%3D${time_period}&filter=RCP%3D${emissions_scenario}&filter=FREQUENCE%3D${event_frequency}&filter=SZ_ID%3D$emikat_id
That is, this resource has following variables: ${emikat_id}, ${study_variant}, ${time_period}, ${emissions_scenario}, and ${event_frequency}
And this are the allowed values for the variables:
Study_variant can be either isn't known until the user decides on some adaptation options.
The text was updated successfully, but these errors were encountered: