Skip to content
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

Support for reference time and time defined for mesh. #100

Closed
PeterPetrik opened this issue Mar 14, 2019 · 5 comments
Closed

Support for reference time and time defined for mesh. #100

PeterPetrik opened this issue Mar 14, 2019 · 5 comments
Labels
API break API enhancement New feature or request

Comments

@PeterPetrik
Copy link
Contributor

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.

Bed elevation
   - terrain data
water_depth
    - t=0s data
    - t=1s data
    - t=2s data
water flow
   - t=0s data
   - t=1s data
   - t=2s data

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

mesh
     - groups
           - dataset1
           - dataset2
           - datasetN
      - vertices
      - faces
      - time
             - reference time (string)
             - std::vector<double> time; //time in hours 

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:

  • easier API for getting time for datasets from mesh object compatible with QGIS implementation
  • adding API for retrieval of reference time for formats that support it. QGIS will pick the reference time and automatically set it in the time settings for absolute time format
@rduivenvoorde
Copy link

@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.

@PeterPetrik
Copy link
Contributor Author

PeterPetrik commented Mar 15, 2019

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.

@saberraz
Copy link
Contributor

saberraz commented Mar 15, 2019

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

@PeterPetrik
Copy link
Contributor Author

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.

@PeterPetrik
Copy link
Contributor Author

discussed with @wonder-sk and decided to keep the current implementation as more flexible

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API break API enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants