Split Playback initialization into multiple methods

[lbutler]

Currently it is not possible to launch the LeafletPlayback library without providing at least a single geoJSON track. It appears that the initialize method for the Playback object tries to load tracks, the clock and controls when it is called. If the track is not include then the whole library fails to load.

I'd suggest refactoring this section into multiple methods so we can cleanly create/delete these objects if we need. This will also help if we want to delete all the tracks and reload them as suggested in #8.

I've very quickly hacked something together and made use of the addTracks function we recently fixed here https://github.com/lbutler/LeafletPlayback/commit/55d35f63d32a62b30718df1ef9c7adf1cde75960.

Let me know what you think, I'll keep working on it and see what I can come up with if you think this is a good way forward.

[hallahan]

I agree that we should be able to add tracks post initialization. I'd like to think one step further: we need a way where any tracks can be added at any time.

One feature that I think could bring Leaflet Playback to the next level would be to add streaming capability similar to what you would find with a video player. For example, wherever you cue the playback transport (slider), we should be buffering and fetching tracks for that point. We need to have a way to extend our model where you can move the cue anywhere you want and have that fetch tracks before, after, and between already fetched tracks.

This may mean that we want to treat interpolation a bit differently. Right now, we always interpolate every tick between known points during initialization. I think with a streaming cue, this would not work. We would want to interpolate for wherever the cue happens to be on the fly.

[lbutler]

You bring up some very interesting points and you seem to be wanting to head down the same path I was heading though maybe slightly different.

My "grand plan" for using this library was to connect it to a webservice that would return a json files for a whole days worth of data for continuously tracked assets. I'd want to be able to click on the calendar and change the date and for the library to hit the webservice again and get the next set of data for that day. I'd also want to be able for the library to recognise the day wasnt over and there is data still to come and for it to poll the webservice at a set period and for it to return the latest set of data and for the library to amend this to the existing tracks.

That way a person could leave the page open and it would always show the latest location of all assets in real time though they could easily move the slider around and see the history.

Core functionality that is currently missing that would allowed this to happen are: -Start Library without data #13 -Load tracks adhoc #9 (this now works with the latest PR) -Delete tracks #8 -Syncing or streaming ability -Updated GPS tracks control to display each track individually, toggle on/off, show tracks, group tracks

These are the features/enhancements that I'd love to see in the library and would be happy to work on and contribute back. Let me know where my thoughts overlap yours or where you think features would be useful to be in the library and I can prioritise those updates.

If you have any questions please let me know, also feel free to email me directly if you have some more specific questions about my application.

[hallahan]

I think all of these features will fit well into the library. Feel free to prioritize as you see fit. Regarding loading tracks ad hoc, I think some thought will need to go into how track points are interpolated. For example, if you were to add some tracks that happened a month after the last batch of tracks loaded, you would not want to interpolate every clock tick between those 2 sets -- that would take a long time to compute.

[recallfx]

Interpolation should also be optional.

Currently we are doing something like this: options.maxInterpolationInterval = 5*60*1000; // 5 minutes

if (options.maxInterpolationInterval != 0 && nextSampleTime - currSampleTime > options.maxInterpolationInterval){
     this._ticks[t] = currSample;
}
else {
     this._ticks[t] = this._interpolatePoint(currSample, nextSample, ratio);
}

[hallahan]

Interpolation is core to how the clock works. At a given tick, everything needs to be somewhere. I suppose we could have a noop when things don't hash.

On Wed, Jun 18, 2014 at 9:17 AM, Marius notifications@github.com wrote:

Interpolation should also be optional.

Currently we are doing something like this: options.maxInterpolationInterval = 5_60_1000; // 5 minutes

if (options.maxInterpolationInterval != 0 && nextSampleTime - currSampleTime > options.maxInterpolationInterval){ this._ticks[t] = currSample; } else { this._ticks[t] = this._interpolatePoint(currSample, nextSample, ratio); }

— Reply to this email directly or view it on GitHub https://github.com/hallahan/LeafletPlayback/issues/13#issuecomment-46458005 .

[recallfx]

Hi, Regarding split initialization, I have implemented it in my fork recallfx@42703bb2633eca976bd2c3c3608914fee420913c Now you dont need to pass data to the constructor, you can add it using setData (reset/add) or addData methods.

[hallahan]

@recallfx This looks great! Could you submit a pull request and I can then look it over, test it, and possibly merge it in?

[recallfx]

Hi @hallahan, I have refactored and cleaned folder structure. Mainly removed unnecessary data/lib files. Unfortunately GitHub compare page crashes every time I try to create a pull request.

[hallahan]

Looks like we're good! Thanks for submitting your pull request. I'd love to see how you apply your work!