Ideas for changing/improving animations...

[karlmsmith]

Reported by @noaaroland on 21 Jun 2007 21:37 UTC We want animations to have three behaviors. One for when the server is expected to be fast, one for when it is expected to be slow and one for Google earth. Below are some ideas on how to achieve these behaviors.

We could implement a bit of Java code as a backend service to handle animation requests.

When configured for a "fast" server, the animation service should return a list of product server URLs. This can be done by contacting the current Ferret service from the animation service to build this list just as it is done now. The output template will wake up the animation client (JavaScript code) which will request each frame in sequence with the ui_timeout set to 0 (which indicates the product server should not send back progress pages). The client can display the individual images as they are returned.

When preparing an animation for a "slow" server (as defined by a property in the request), the animation service should contact the product server and request that each frame be created by the product server. Once it has all of the frames created, the animation service can return the response containing the list of product request URLs which the client will request and the PS will respond with from the cache. Or the animation service can return URLs of the resulting images.

Since Google earth seems not to be able to put up the images one at a time, then requests for Google earth animation should be done by the animation service in the same way as requests from a "slow" server.

Migrated-From: http://dunkel.pmel.noaa.gov/trac/las/ticket/47

[karlmsmith]

Comment by @noaaroland on 22 Jun 2007 15:20 UTC Jing said...

The solution is pretty clear to me. For Google Earth animation, my Java code asks the Product Server to generate all the plots and then wraps them in a KML file.

Another issue about animation is we have to limit the number of frames. I tried to run a Google Earth animation with 48 plots. It almost froze my computer.

[karlmsmith]

Comment by @noaaroland on 22 Jun 2007 15:23 UTC Yes, that will work just fine. It's easy to imagine any number of problems that could be solved by placing a servlet in front of the incoming LAS request. It seems to me that the only task for which that architecture is appropriate is where the the request message needs to be transliterated. The WMS server and the GE bbox translation are good examples. The issue for me of putting the code to make the product requests in that same place (a server in front of the request) is that in the LAS architecture these new capabilities that you are adding are going into the "wrong" place. If the animation were managed by a backend service then all of the other parts of the LAS architecture that can be brought to bear against a request (email notification, RSS feeds, etc) can be used. Implementing this capability in the servlet in front of the product server request means all that sort of work has to be done twice.

As for limits, I suppose that doing the requests for the individual images sequentially or in batches would help mitigate that. Or was the problem with Google Earth on the PC not flooding the product server?

[karlmsmith]

Comment by steven.c.hankin on 31 Jul 2007 22:36 UTC The simple (non-GE) animations are very much improved, Here are a few items that seem important to wrap up as a part of the Armstrong 1.0/V7 Alpha release.

==> Note that I have moved this ticket to the V7 Alpha milestone in trac

1. The default start-up mode should be "loop" rather than "play once", so that the animation becomes apparent after it has finished loading. The animation should begin looping immediately.
2. The default looping speed should be (say) 8 frames per second, so that the sense of animation is strong
3. Several of the Options are not applicable to animations. As a BETA (or V7+) item, we should think about how the animation product relates to the underlying image product; how do we identify and remove the irrelevant options that are not applicable to animations. (The same questions arise for interactive plots.) As an ALPHA item perhaps they should be simply removed from the list of options:
   • Post-Script output
   • reference map

[karlmsmith]

Comment by jing.y.li@noaa.gov on 1 Aug 2007 21:32 UTC

The following was done:

• set start-up play mode as 'loop'

• set initial play speed to 8 frames per second

• use appropriate options for animated XY plots and XZ (or YZ) plots