When the data set starts to get large, it does not seem reasonable to have to load everything up front and wait for a loading dialog (though it's nice to have). I think it would make a lot of sense to progressively load tracks based on the set playback time. I'm thinking a simple buffering mechanism where we get back paginated chunks of data would make sense. I would suggest having a PostGIS database in the backend so that we can index the data based on a bounding box of the map rather than just time. Something like:
The point of pagination would be that the tracks data may be at any given rate, so if we specified a time block, we wouldn't necessarily get back consistently sized responses. With pagination, the server can just shoot back a certain response size and just progressively load. The loading would be likely faster than the actual playback, so the client could just keep paginating rather than changing that initial timestamp in the request.
When the data set starts to get large, it does not seem reasonable to have to load everything up front and wait for a loading dialog (though it's nice to have). I think it would make a lot of sense to progressively load tracks based on the set playback time. I'm thinking a simple buffering mechanism where we get back paginated chunks of data would make sense. I would suggest having a PostGIS database in the backend so that we can index the data based on a bounding box of the map rather than just time. Something like:
http://webapi.com/tracks?bbox=[GPSorTileBasedBBox]&tags=[IDsOrTagsDefiningWhichTracksToShow]&time=[timestamp]&page=[pageNum]
The point of pagination would be that the tracks data may be at any given rate, so if we specified a time block, we wouldn't necessarily get back consistently sized responses. With pagination, the server can just shoot back a certain response size and just progressively load. The loading would be likely faster than the actual playback, so the client could just keep paginating rather than changing that initial timestamp in the request.