Dataset metadata end geoportal interface

[dcesari]

The datasets in the geoportal menu could be structured in the following tree view, based on the corresponding metadata:

|_Observations[adriaclim_dataset == 'observation']
|      |_?
|
|_Numerical models[adriaclim_dataset == 'model']
|      |_Large scale[adriaclim_scale == 'large']
|      |_Pilot scale[adriaclim_scale == 'pilot']
|      |_...(possibly other scales)
|
|_Indicators[adriaclim_dataset == 'indicator']
|      |_Large scale[adriaclim_scale == 'large']
|      |_Pilot scale[adriaclim_scale == 'pilot']
|      |_...(possibly other scales)
|
|_all datasets(in a flat list as now)

a zoom e.g. on Indicators-Large scale (the same would be valid for all the other branches at the same level):

 |_model1[adriaclim_model='model1']
 |_model2[adriaclim_model='model2']
 |_...(dynamic list based on the possible values of adriaclim_model when adriaclim_dataset == 'indicator' && adriaclim_scale == 'large'

Further levels or branching could be based on adriaclim_timeperiod (for observations, models and indicators) and on adriaclim_type (for indicators only), but this has to be decided in a special meeting with the users or their representors.

adriaclim_timeperiod may also influence the operations available when the user selects data on a point or area, e.g. yearly cycle month by month does not make sense with seasonal or yearly data, etc.

Also adriaclim_scale rather than being a level of the tree structure may be a selector based on the size of the areas currently selected by the user.

The metadata key and value names may also change in the future.

[dcesari]

So, as said, this is a draft subject to change, however it is important to start implementing some levels of branching in order to show them to the potential users and have feedback leading to the final structure.

[fraFerrari99]

Hi Davide,

I don't understand when you say Numerical models that are the ones where adriaclim_dataset = "indicator", this is not the case of Indicators as you wrote after it?

When you talk about the zoom on, for example Indicators-Large Scale, do you mean that all the Large-Scale must have this type of branching?

I'm trying to think how I should realize in a pretty way this tree structure in the panel that we already have, do you have already a specific idea on how I should create it or I have carte blanche?

[dcesari]

I don't understand when you say Numerical models that are the ones where adriaclim_dataset = "indicator", this is not the case of Indicators as you wrote after it?

It was a mistake of mine, I updated the comment.

When you talk about the zoom on, for example Indicators-Large Scale, do you mean that all the Large-Scale must have this type of branching?

My initial idea was that, depending on the type or size of polygons displayed, the systems chooses automatically to show only e.g. large scale or pilot scale or local scale indicators and/or models (thus we would not have this level of choice in the tree), but I am not sure this is the best choice, both for the user and from the implementation point of view, so probably making this a level of the tree structure is probably a good choice.

[fraFerrari99]

My initial idea was that, depending on the type or size of polygons displayed, the systems chooses automatically to show only e.g. large scale or pilot scale or local scale indicators and/or models (thus we would not have this level of choice in the tree), but I am not sure this is the best choice, both for the user and from the implementation point of view, so probably making this a level of the tree structure is probably a good choice.

For the implementation is not a problem, because I can change dinamically the content (large scale, pilot ecc.) based on the view that the user selected but, for the user, I think they will not understand how this works since it's not very immediate to them.

Maybe we should think about something that can result easier to them to understand, like displaying every scale and disable the scales based on the view selected and if they hover the ones that are the disabled, tell them to change view to select that scale.

[dcesari]

For the structure of the menu/tree you have carte blanche, you surely know much better the widget you are using. I am curious to see new proposals.

Just keep in mind that the purpose of this job is to guide the user and limit the dataset shown to the minimum superset of what they are looking for. It could also be the case that after a certain level the tree structure is not the most suitable. What I mean is that, reasonably, the user will initially choose [indicator or model or observation], then the spatial scale of interest and they will not probably come back on these choices during that session, so it is good to hide all the unchosen branches. But at this point the user may want to start playing with the remaining metadata such as (speaking about indicators): adriaclim_model (model from which the indicator is derived), adriaclim_timeperiod, adriaclim_type (and possibly others) without an obvious hierarchical order, in order to see which datasets are available, so that a different, non tree-like view could be thought of at a certain level, maybe a search form? But I am not sure if and how this is feasible.

I propose to start with a minimum tree structure, then I will try to organize a meeting with the users to define the following development.

[fraFerrari99]

I was thinking at something like this for the tree structure:

This is an example to show you what I was saying before about the possibility of disabling, for example, the large scale button if the view is not the one with large polygons:

To implement the functionality of hiding the other possible selections once the user selects one, here you can see it:

Once the user selects "indicators", the other choices temporarily disappear, meaning that, if the user reclicks on indicators, all the other choices reapper.

For the search form, I don't understand how do you want the user to filter using timeperiod, model ecc. Do you mean to pass in the search form like some filters that we can use to suggest the user on how to filter the datasets?

[dcesari]

After rethinking, it's not probably a good idea to hide datasets depending on the scale of the areas selected, I would keep the things separate. The current idea is to start the tree from the choice of adriaclim_type (observation|model|indicator) then adriaclim_scale with a single choice, then allow multiple choices for subsetting the datasets on the other metadata such as adriaclim_model and adriaclim_timescale, etc.