-
Notifications
You must be signed in to change notification settings - Fork 1
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
Please change the way "default" layers are shown on the map #84
Comments
O.K. This is a modification of the respective resources the European Data Package. I can look into this.
Considering how resources and references are modelled in CSIS Drupal, this is currently not possible without changing the data model. We could add a boolean field 'selected' to the resource entity type, however, since a resource can contain multiple references (service paths) each of which is expanded into a separate layer, all layers of the resources would be selected. This is e.g. the case for the EEA Discovery Map Services Resource, which consists of 8 different references and layers respectively. Furthermore, since resources can be arbitrarily combined in data packages, it would be counter productive to define the default selection status at the level of the resource. It would have to be defined at the level of the data package making the data package data model and thus the data package from more complex (keeping information on the state of resources).
No those are conceptually different things. The name 'default' is just a fallback name if no hazard type is associated with the resource, e.g. for exposure resources. |
O.K. Now I understand what you mean by 'default' layers. You are talking about the Hazard LE Input Layers in the HC-LE step. The layer group name 'default' is misleading but as before, it is just a fallback name. What we can do without changing data models, etc. is use the name of the GL step as group title, in this case 'Hazard Characterization - Local Effects'. ATM it's not easily possible to chose more than one because of this request. |
|
Sorry for any confusion. My request was mainly to be able to unselect layers. I agree that it would be nice to be able to select more than 1 background layer for display. This might also become important for the basic screening method. |
This is currently possible. Background Layers have check boxes (0-n selectable) any another layers have de-selectable option boxes (0-1 selectable). The reason is simple: Most background layers are based on vector data and are partially transparent, so it makes sense to show several of them in one map (buildings + roads + vegetation, ...). Any other layers are in most cases gridded raster layers, so showing more than one at a time does not offer any benefit because they obscure each other. Of course, we've got also some non-transparent background layers and a few transparent 'other' layers (the 'default' Urban-Atlas based HC-LE input layers for example). So the current solution is not optimal, but IMHO a compromise we can live with. While we could implement an exception for the HC-LE input layers and allow multi-selection via checkboxes as suggested above, we have to be aware that HC-LE includes also non-transparent raster layers (TMRT, etc.) calculated by EMIKAT. There was also an idea to allow user to overlay several layers and decide how to colour-code each, but this is technically difficult to implement on client side and the current situation does not allow us to invest effort on costly features. |
Thanks for clarifying! I don't think it will be necessary to let the user decide how to color code layers. For a basic screening we could decide upfront which layers should have what color and we could write in plain text, which layers to select in order to display potentially critical areas.
That sounds like a good idea to me. Also, adding original urban atlas layers (if they are available anyway) might be nice for the user to explore the area. |
"clarity background" sounds good to me. The reason why I asked for a
possibility to choose multiple was because these layers never overlap.
…On Thu, 27 Feb 2020, 16:21 claudiahahn, ***@***.***> wrote:
Thanks for clarifying!
I don't think it will be necessary to let the user decide how to color
code layers. For a basic screening we could decide upfront which layers
should have what color and we could write in plain text, which layers to
select in order to display potentially critical areas.
Or call this "CLARITY background" as opposed to background layers from
other sources? That would IMO be a good thing, e.g. to be able to
demonstrate the difference between the urban atlas "buildings" layers and
ours.
That sounds like a good idea to me. Also, adding original urban atlas
layers (if they are available anyway) might be nice for the user to explore
the area.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#84?email_source=notifications&email_token=AAWTC7UBUY2ALK4N6SPYWBTRE7D6RA5CNFSM4KSJ2DEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENESFIY#issuecomment-591995555>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAWTC7RDZMN3WHUK7EV7VZ3RE7D6RANCNFSM4KSJ2DEA>
.
|
I've introduced a new tag clarity-background-layer, tagged the HC-LE input layers accordingly and removed the EU-GL local-effects tag from these layers (reason explained here). HC-LE output layers (UTCI, TMRT, ..) are not affected. Map Component on csis.myclimateservice.eu (which is still on old DEV server) is updated. @negroscuro Can you please create an new resource for the sports layer in the European Wide Data Package. Please tag it with clarity-background-layer, not with background-layer and local-effects. Thanks! |
I just updated CKAN with new sports data: Then I modified built_up obsolete entry in CSIS under 'European wide data package' (https://csis.myclimateservice.eu/node/682), to match new 'sports' layer which now is: |
@negroscuro can you please update the two resources in CKAN with proper URLs or files to the actual data? This way they lead to nowhere. Thanks!! |
done |
@ghilbrae sorry I missplaced URL, I also realized that most URL's of resources in CKAN defined by me are using URL's of request to Geoserver with specific bounding boxes and probably when contents get bigger that bbox should be updated in order to be able get/see the whole dataset. |
@negroscuro Thanks!! |
While testing for clarity-h2020/data-package#59, I realised that following things need to be changed for the "default" layers presentation:
Last point is mostly cosmetics, but there is a bit of overlap between "background" and "default" layers. Maybe we should merge the two groups and drop the overlapping layers?
Or call this "CLARITY background" as opposed to background layers from other sources? That would IMO be a good think, e.g. to be able to demonstrate the difference between the urban atlas "buildings" layers and ours.
The text was updated successfully, but these errors were encountered: