search

SignalK / specification

Signal K is a JSON-based format for storing and sharing marine data from different sources (e.g. nmea 0183, 2000, seatalk, etc)
Other
92 stars 69 forks source link

"This is log playback data" #428

Open tkurki opened 6 years ago

tkurki commented 6 years ago

It would be useful to indicate in deltas, possibly also in full, that the data is from log playback and not real. This would allow UIs to indicate that the data is not real.

tkurki commented 6 years ago

Another possibility is creating different endpoints / parameters for real and playback data.

bkp7 commented 6 years ago

What are the use cases? Why would you want it (just wanting to get a list of all use cases)?

Timestamp is mandatory in full, but not in delta.. could that cover it?.

If you wanted to lookback at data for real wouldn't a totally different format be appropriate to give a historic dataset? InfluxDb?

tkurki commented 6 years ago

The use cases you are listing are real but not exactly the issue here.

Here the issue is being able to distinguish playback data from real. For example if we add a button in the UI that switches off real inputs and plays back logged data the UI should (must ?) indicate that the data is not real.

Your point about timestamp is good. It is somewhat problematic that for example NMEA log does not contain timestamps, but we could use file's last modification date instead.

bkp7 commented 6 years ago

I guess my question is why would you ever want to playback data in real life?

If an event has occurred wouldn't it be much better to look at a time series version of the data so you can easily see trends etc. Even if a user did prefer playback, a slider type control (like for video playback) would seem intuitive but that would require the client either having a full timeseries dataset, or a method to ask the server for specific points in time.

tkurki commented 6 years ago

Good points. Simulation/demo is a real use case, but not really relevant for switching between that and real inputs.

Maybe I have a bias, because development happens mostly on playback data.

Nevertheless indicating that the data is not "real" and being able to act on that could be a useful protocol level enhancement.

bkp7 commented 6 years ago

The only problem with the development test use case is that you really want the client to be behaving exactly as it would with real data, not somehow treating it differently, so I'm not convinced that counts

Demo, is a fair point. I've never seem a marine display without a switchable demo mode, although that's using data internally within the device rather than on the network....

Also, setup on board could be a use case. Setting preferences for individual screens, etc...