Closed PeterPetrik closed 5 years ago
@PeterPetrik if this makes stuff simpler: fine? MDAL api is still 'flexible', isn't it? I'm not a mesh-guru but I wonder why you would put data with different time references in one file.
But IF somebody would give MDAL such a dataset in future, could we not decide to for example 'list' the different time-ranges/formats, just like you can list the layers and sublayers in gdal? So in case of different times-ranges/types, you have to decide which one you pick (as sub/layer/filter), and then only the data with that time-range is loaded?
I'll ask around.
Yep I would imagine that IF such dataset exists, it will be loaded into 2 separate mesh layers and user will be able to choose which "sublayer" to load. But I have never seen such data in my life.
API is still Experimental, but this and error reporting #102 are only 2 changes I would like to have changes in it.
I wonder why you would put data with different time references in one file
It is a common method of having different reference time in ensemble forecasts or past forecast.
For loading selected variable there is already a feature request
I do not think it is such a problem if each dataset has the different reference time, because in MDAL we can always do some simple math, set one common reference time and recalculate all times based on this one. BUT with this change it would be difficult to have multiple dataset groups with different absolute times.
discussed with @wonder-sk and decided to keep the current implementation as more flexible
Currently, from MDAL point of view, each dataset has it own timestamp. So for different dataset groups, each dataset has its own timestamp, e.g.
the current model, you CAN have different times for different datasets, even different number of timesteps.
But, we haven't got any data model from any supported format or any format on market we know of to support such general approach. Also, in QGIS we have a single time-slider and we somehow "assume" that all datasets have common times or no time at all (bed elevation)
Also, some formats support reference time, which now must be set manually in QGIS time settings dialog.
We propose to change underlying data model and C-API to follow this new model
during parsing of the formats, we will accept only dataset groups that have SAME amount of dataset than the first parsed group or just 1 (bed elevation or maximums).
advantages of the api change: