<div dir="ltr"><div>For me, here, time step is the difference between the time of two successive dataset of the same group. Do we agree?<br></div><div>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.</div><div>So you (reference time + relative time)=absolute time (date+time) of the dataset.</div><div>If your time step is constant, you just have to take two successive dataset and soustract their relative times.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le jeu. 9 mars 2023 à 10:28, Richard Duivenvoorde <<a href="mailto:rdmailings@duif.net">rdmailings@duif.net</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Vincent,<br>
<br>
Thanks for the clarifications!<br>
<br>
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.<br>
So a run of 24 hour of every hour, or one of 3 days per 6 hours or 6 hours per 10 minutes.<br>
<br>
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...)<br>
<br>
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?<br>
<br>
Thanks for your time!<br>
<br>
Regards,<br>
<br>
Richard Duivenvoorde<br>
<br>
<br>
On 3/9/23 15:03, Vincent Cloarec wrote:<br>
> Hi Richard,<br>
> <br>
> 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.<br>
> <br>
> If you need one time step, you can deduced if by using one of these ways:<br>
> - 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<br>
> - QgsMeshLayer::datasetRelativeTime() that will return a QgsInteval that is the time of the dataset from the reference time<br>
> - QgsMeshLayer::datasetRelativeTimeInMilliseconds(), same but return in milliseconds.<br>
> <br>
> 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.<br>
> The reference time is not needed in your case but it can be obtained through the meta data of the dataset group.<br>
> <br>
> 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.<br>
> <br>
> 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.<br>
> <br>
> Hope this helps.<br>
> <br>
> Regards.<br>
> <br>
> Vincent<br>
> <br>
> Le mer. 8 mars 2023 à 10:42, Richard Duivenvoorde via QGIS-User <<a href="mailto:qgis-user@lists.osgeo.org" target="_blank">qgis-user@lists.osgeo.org</a> <mailto:<a href="mailto:qgis-user@lists.osgeo.org" target="_blank">qgis-user@lists.osgeo.org</a>>> a écrit :<br>
> <br>
> Ok, found it. It is in the temporalCapabilities...<br>
> <br>
> So given a loaded netcdf/mesh with time.<br>
> Easiest is the firstTimeStepDuration(i) of QgsMeshDataProviderTemporalCapabilities:<br>
> <br>
> >>> p = iface.activeLayer().dataProvider().temporalCapabilities()<br>
> >>> p<br>
> <qgis._core.QgsMeshDataProviderTemporalCapabilities object at 0x7fa958267e20><br>
> >>> p.timeExtent()<br>
> <QgsDateTimeRange:[2022-11-07T07:00:00Z, 2022-11-08T06:00:00Z]><br>
> >>> p.temporalUnit()<br>
> <TemporalUnit.Hours: 3> <<< ?????<br>
> # datasetTime() Returns the relative time in milliseconds of the dataset<br>
> >>> p.datasetTime(QgsMeshDatasetIndex(0,0))<br>
> 3600000<br>
> >>> p.datasetTime(QgsMeshDatasetIndex(0,1))<br>
> 7200000<br>
> >>> p.datasetTime(QgsMeshDatasetIndex(0,2))<br>
> 10800000<br>
> # firstTimeStepDuration() Returns the duration of the first time step of the dataset group with index \a group<br>
> # in milliseconds<br>
> p.firstTimeStepDuration(0)<br>
> 3600000 == 3600 s = 1 hours<br>
> p.firstTimeStepDuration(0)<br>
> 21600000 == 21600 s == 360 minute == 6 hours<br>
> <br>
> Only strange thing is that the temporalUnit() always returns 'hours', while the actual data time is relative in minutes...<br>
> <br>
> Regards,<br>
> <br>
> Richard Duivenvoorde<br>
> <br>
> On 3/8/23 10:46, Richard Duivenvoorde via QGIS-User wrote:<br>
> > Hi,<br>
> ><br>
> > (trying here too, sorry for cross posting)<br>
> ><br>
> > When loading (temporal) Netcdf files (as MeshLayers), the 'timestep'<br>
> > that you see in the Temporal Controller does not change.<br>
> ><br>
> > I had a look at the api, but could not find any indication of knowledge<br>
> > by the QgsMeshLayer of the size of the timesteps of the data.<br>
> ><br>
> > Within netcdf's it is common to define the timesteps as something like:<br>
> > "minutes since 2022-11-27 16:00:00.0Z"<br>
> > then the first set has 0, and then the next one for example 60 for<br>
> > hourly data or 10 for 10-minute data.<br>
> ><br>
> > Question: IS a temporal mesh layer aware of the timesteps used?<br>
> ><br>
> > Or if not: I seem not to be able to inspect the data array of the 'time'<br>
> > dimension. Should/can I?<br>
> ><br>
> > IF so, we could we could deduct from the first 2 or 3 timesteps, the<br>
> > size of the timestep.<br>
> ><br>
> > Anybody a hint or idea?<br>
> ><br>
> > Regards,<br>
> ><br>
> > Richard Duivenvoorde<br>
> ><br>
> > _______________________________________________<br>
> > QGIS-User mailing list<br>
> > <a href="mailto:QGIS-User@lists.osgeo.org" target="_blank">QGIS-User@lists.osgeo.org</a> <mailto:<a href="mailto:QGIS-User@lists.osgeo.org" target="_blank">QGIS-User@lists.osgeo.org</a>><br>
> > List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-user" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-user</a> <<a href="https://lists.osgeo.org/mailman/listinfo/qgis-user" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-user</a>><br>
> > Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-user" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-user</a> <<a href="https://lists.osgeo.org/mailman/listinfo/qgis-user" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-user</a>><br>
> <br>
> _______________________________________________<br>
> QGIS-User mailing list<br>
> <a href="mailto:QGIS-User@lists.osgeo.org" target="_blank">QGIS-User@lists.osgeo.org</a> <mailto:<a href="mailto:QGIS-User@lists.osgeo.org" target="_blank">QGIS-User@lists.osgeo.org</a>><br>
> List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-user" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-user</a> <<a href="https://lists.osgeo.org/mailman/listinfo/qgis-user" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-user</a>><br>
> Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-user" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-user</a> <<a href="https://lists.osgeo.org/mailman/listinfo/qgis-user" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-user</a>><br>
> <br>
<br>
</blockquote></div>