For me, here, time step is the difference between the time of two successive dataset of the same group. Do we agree? The three methods of my previous message return a time that represents the relative time associated with the dataset you point to. It is not the time range of the whole group. This relative time is from a reference time that is related to the dataset group. So you (reference time + relative time)=absolute time (date+time) of the dataset. If your time step is constant, you just have to take two successive dataset and soustract their relative times.
Le jeu. 9 mars 2023 à 10:28, Richard Duivenvoorde <[email protected]> a écrit : > Hi Vincent, > > Thanks for the clarifications! > > I am aware that netcdf's can have variable time steps. But in my case the > dataset are all run from a model which runs at variable lengths but in > fixed time steps, outputting >60 variables. > So a run of 24 hour of every hour, or one of 3 days per 6 hours or 6 hours > per 10 minutes. > > So the timestep are the same in one netcdf, it is just that I need to find > out what the used 'timestep' is; actually to set the timecontroller > timestep, because it is not set when I load a mesh using pyqgis (I have to > download the model output zipped from some service endpoint, and put custom > (logaritmic) classification styling on it...) > > So the datasetMetadata (I think) does not give me that info? As it gives > the timerange of the full dataset, but I would have to know the length of > the variables then to know my timestep? > > Thanks for your time! > > Regards, > > Richard Duivenvoorde > > > On 3/9/23 15:03, Vincent Cloarec wrote: > > Hi Richard, > > > > First, mesh layer time step is not supposed to be constant. Some dataset > could have variable time steps, so there is not ONE time step available for > each mesh layer or dataset group. > > > > If you need one time step, you can deduced if by using one of these ways: > > - QgsMeshLayer::datasetMetadata() that will return the metadata of the > dataset, this metadata contains the method time() that will return the time > of the dataset in hours from the reference time > > - QgsMeshLayer::datasetRelativeTime() that will return a QgsInteval that > is the time of the dataset from the reference time > > - QgsMeshLayer::datasetRelativeTimeInMilliseconds(), same but return in > milliseconds. > > > > By soustraction of two dataset, you will have a time step, and if your > data has constant time step it will be THE time step. > > The reference time is not needed in your case but it can be obtained > through the meta data of the dataset group. > > > > Or you can also use your method with the temporalCapabilities that > should give the same results, but it is more related to the data provider, > and I would avoid using it as it could have some issues with dataset group > indexes. > > > > Note that the temporalUnit() of the temporal capabilities is not the > unit of the time returned by the layer, but it the the data provider must > considerer to read the times value. Default is hour for MDAL, but in > certain case, when MDAL can't know the time unit, the user specify this > unit. > > > > Hope this helps. > > > > Regards. > > > > Vincent > > > > Le mer. 8 mars 2023 à 10:42, Richard Duivenvoorde via QGIS-User < > [email protected] <mailto:[email protected]>> a écrit : > > > > Ok, found it. It is in the temporalCapabilities... > > > > So given a loaded netcdf/mesh with time. > > Easiest is the firstTimeStepDuration(i) of > QgsMeshDataProviderTemporalCapabilities: > > > > >>> p = iface.activeLayer().dataProvider().temporalCapabilities() > > >>> p > > <qgis._core.QgsMeshDataProviderTemporalCapabilities object at > 0x7fa958267e20> > > >>> p.timeExtent() > > <QgsDateTimeRange:[2022-11-07T07:00:00Z, 2022-11-08T06:00:00Z]> > > >>> p.temporalUnit() > > <TemporalUnit.Hours: 3> <<< ????? > > # datasetTime() Returns the relative time in milliseconds of the > dataset > > >>> p.datasetTime(QgsMeshDatasetIndex(0,0)) > > 3600000 > > >>> p.datasetTime(QgsMeshDatasetIndex(0,1)) > > 7200000 > > >>> p.datasetTime(QgsMeshDatasetIndex(0,2)) > > 10800000 > > # firstTimeStepDuration() Returns the duration of the first time > step of the dataset group with index \a group > > # in milliseconds > > p.firstTimeStepDuration(0) > > 3600000 == 3600 s = 1 hours > > p.firstTimeStepDuration(0) > > 21600000 == 21600 s == 360 minute == 6 hours > > > > Only strange thing is that the temporalUnit() always returns > 'hours', while the actual data time is relative in minutes... > > > > Regards, > > > > Richard Duivenvoorde > > > > On 3/8/23 10:46, Richard Duivenvoorde via QGIS-User wrote: > > > Hi, > > > > > > (trying here too, sorry for cross posting) > > > > > > When loading (temporal) Netcdf files (as MeshLayers), the > 'timestep' > > > that you see in the Temporal Controller does not change. > > > > > > I had a look at the api, but could not find any indication of > knowledge > > > by the QgsMeshLayer of the size of the timesteps of the data. > > > > > > Within netcdf's it is common to define the timesteps as something > like: > > > "minutes since 2022-11-27 16:00:00.0Z" > > > then the first set has 0, and then the next one for example 60 for > > > hourly data or 10 for 10-minute data. > > > > > > Question: IS a temporal mesh layer aware of the timesteps used? > > > > > > Or if not: I seem not to be able to inspect the data array of the > 'time' > > > dimension. Should/can I? > > > > > > IF so, we could we could deduct from the first 2 or 3 timesteps, > the > > > size of the timestep. > > > > > > Anybody a hint or idea? > > > > > > Regards, > > > > > > Richard Duivenvoorde > > > > > > _______________________________________________ > > > QGIS-User mailing list > > > [email protected] <mailto:[email protected]> > > > List info: https://lists.osgeo.org/mailman/listinfo/qgis-user < > https://lists.osgeo.org/mailman/listinfo/qgis-user> > > > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user < > https://lists.osgeo.org/mailman/listinfo/qgis-user> > > > > _______________________________________________ > > QGIS-User mailing list > > [email protected] <mailto:[email protected]> > > List info: https://lists.osgeo.org/mailman/listinfo/qgis-user < > https://lists.osgeo.org/mailman/listinfo/qgis-user> > > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user < > https://lists.osgeo.org/mailman/listinfo/qgis-user> > > > >
_______________________________________________ QGIS-User mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
