Open GoogleCodeExporter opened 9 years ago
The exhaustive list of possibilities right now for dataItem timeExtent behavior
in
STT project file are:
1) Follow scene time:
<timeExtent autoUpdate="#SCENE_01">
...
You can still declare lead, lag, and delta in this case. You can also still
specify
baseTime, which should be set in the grayed-out Override Master time widget.
(Pending bug fix from Issue #3
:http://code.google.com/p/space-time-toolkit/issues/detail?id=3). This is
useful
feature if you want to have an OverrideTime stored in the project, but still
start
out slaving to the Master time.
2) Override Scene Time
<timeExtent> <!-- NO attributes -->
<TimeExtent>
<baseTime>2004-01-01T23:593:59Z</baseTime>
<lagTime>900</lagTime>
<leadTime>900</leadTime>
</TimeExtent>
</timeExtent>
3) Set to realtime - note that this is not thoroughly tested and likely buggy
<timeExtent autoUpdate="realtime">
4) Omit timeExtent entirely from DataProvider declaration. This assigns a
<timeExtent> with current System time in the Override Field, Override Master
time==true, and lead, lag, delta == 0s. The better behavior may be to disallow
a
time controller if the provider does not specify an extent. Then
non-time-dependent
itmes like Coastlines would not show Time Controller (they currently do).
I think changing it is okay, and would be relatively easy, but not sure it is
desirable. Bear in mind that a Project may eventually have multiple scenes.
Thus,
having an explicit handle on which sceneTime to slave to is important. I think
that
is why we did it that way when I put the Override controls in. If we decide to
default to slave to the sceneTime, then we need a new attribute/mechanism to
explicitly indicate to OverrideSceneTime. Changes should be confined to
org.vast.stt.provider.ExtentReader and existing Project files.
Original comment by TheRest...@gmail.com
on 21 Oct 2008 at 9:36
Original issue reported on code.google.com by
mike.bot...@gtempaccount.com
on 20 Oct 2008 at 10:08