-
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
1st Data Package: 00 Background Layers #4
Comments
@maesbri data_package_heat_indices_summer_days.json.txt Each resource within the data package gives the:
That is, there are a total of 20 resources within this data package. I have uploaded the corresponding data here: |
IMHO this fits into the HC part of the Data Package. But ATM I not sure what we can do with this data in CSIS. @ghilbrae @luis-meteogrid Can we import it into METEOGRID Geoserver to show it on the Map? Would that make sense? But ATM we have more important things to important things to do, so I would put this task on hold. |
@p-a-s-c-a-l there's no problem on our side, we can upload the new layers in no time. |
Some background Layers are available in HC-LE. This is not optimal, but the best get can get ATM. |
This set of tasks relate to making numerous default background / inventory layers available in the CSIS Map Component. While those layers are not directly used for impact/risk calculation with or without adaptation, internally they may serve as input for creating (local effects) hazard or exposure layers (see clarity-h2020/csis#33 and in particular Modelling Workflow.pptx for more details.
Interestingly, those layers are independent of a particular Data Package or Use Case. Thus they can be considered default layers that are available in any Data Package. In addition to that tailored Data Packages may include additional background layers, e.g. high-resolution city models used as input for local (hazard) models.
Usually, there is no direct user-interaction (get feature info, modify features) with these layers. Even if some of these layers may show some kind of 'Elements at Risk', they are still not subject to modification by adaptation options, since they need to be 'rasterized' to qualify as actual Exposure Layers. (This special case has to be considered in the task for making available Exposure Layers). Therefore it is usually not needed to access theses Layers via WCS/WFS interface. Moreover, to speed up rendering in the Map Component (Leaflet.js) and to support webbrowser-based caching of tiles, such static layers that don't change (often) should be proxied by GeoWebCache and accessed via the respective TMS/WMTS service interface.
The following tasks which will be broken down in the respective repositories (e.g. Map Component) into several other issues can be identified:
The text was updated successfully, but these errors were encountered: