Real Time animation speed for KML files with TimeSpans specified

[GoogleCodeExporter]

The animation speed open in Google Earth is extremely limited.  Instead of
"slow" to "fast", it should read "very fast" to "extremely fast".

If I have a kml file that tracks the progress of a road trip that took 2
hours.  I would like the ability to reply it in real time(2 hours);
currently the slowest I can possibly get it down to is 12 seconds (the
slowest!!!!).  On the fastest setting its about 1 (maybe 2) seconds..

There are currently no work-around's to speak of, and it seems that LOTS of
other users are experiencing this same issue.

Original issue reported on code.google.com by marzi...@gmail.com on 19 Sep 2008 at 7:11

[GoogleCodeExporter]

I agree. I would really love to have a way to be able to specify the animation
speed-up factor (i.e. 86400 -> one second per day).

Also, right now, if I have a week's worth of data loaded, the smallest I can 
make the
animation sliding window is 1 hour 43 minutes. I would live to be able to 
specify its
length to second resolution.

Original comment by frankian...@gmail.com on 23 Sep 2008 at 6:12

[GoogleCodeExporter]

I'm also struggling w/ the same issue.  My streetcar looks like it's on 
steriods 
going down the street so fast!  Can we please have 1 second to equal one second 
in 
time on the timeslider?

Original comment by sped...@gmail.com on 4 Nov 2008 at 7:57

Attachments:

• str_11-4.kmz

[GoogleCodeExporter]

Original comment by api.roman.public@gmail.com on 2 Dec 2008 at 10:14

• Added labels: Product-Earth

[GoogleCodeExporter]

why? why cant we view our tour/path etc... in real time?
why?

you have a time bar but with slow or fast option... it doesnt make sence...

can google please explain the logic behind this?

is this option available in the plus or pro versions?

help!!!

Original comment by willdoi...@gmail.com on 15 Feb 2009 at 12:18

[GoogleCodeExporter]

I would like to replay GPS track points in real time, ie 1 point per 1 second. 
Currently, the slowest Annimation Speed in the slider seems to be about 2 
points per
second.

Original comment by msperlin...@gtempaccount.com on 5 Feb 2010 at 9:57

[GoogleCodeExporter]

There seems to be a work around.
See here:
http://tecrepublic.blogspot.com/2010/07/google-earth-missing-speedcontrol-for.ht
ml
I haven't tried it.

Original comment by marcel.v...@gmail.com on 21 Aug 2010 at 1:35

[GoogleCodeExporter]

The time slider in google earth has always lacked the ability to make fine 
grained playback.  In fact in GE 5.0 they made it worse (less ticks per time 
window).  The problem is in the way that the time slider is designed.  Your 
data (regardless of whether its 5 seconds or 5 months) get divided into X 
ticks.  So for long periods of time, 1 tick could be 1 day, 1 month or even 1 
year or as the user states above 1 hour and 43 minutes.

This is painful, when you have for example 5 months of data, but only 2 days 
are interesting and you wish to play them back slower.  How I think the time 
adjustment *should* work is that the user should be able to select 1 second of 
timer time = X amount of time, where X could be less than 1 second for slower 
than realtime greater than 1 second, which would be faster.  Let the user 
define X.  This would greatly increase the usefulness of the playback feature.

The only real current work-around is to break-up your data into segments, which 
can be extremely painstaking especially when you have data from multiple 
sources.

Original comment by philipdi...@gmail.com on 1 Oct 2010 at 6:03

[GoogleCodeExporter]

Most of the work I have been doing recently works with the new gx:tracks 
options, and having a more fine grained playback is pretty essential to looking 
at the large datasets that we use for our app.

Original comment by mishy...@gmail.com on 4 Oct 2010 at 3:58

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I found a solution of sorts.

http://www.google.com/support/forum/p/earth/label?lid=5c5ffe191f168248&hl=en

The problem is that the camera position is pre-defined and so you can no longer 
spin the globe during the animation.

The good news is that you could define (say) four camera positions that are at 
1 hour intervals.  With this technique you can have 20s for the first interval, 
60s for the second and 10s for the last.   Time is flexible!

Any better ideas out there?

Original comment by Steve31...@gmail.com on 26 Nov 2010 at 3:34

[GoogleCodeExporter]

The link in comment does not point to any solutions that I see, just a list of 
the most recent forum posts.

Original comment by philipdi...@gmail.com on 30 Nov 2010 at 11:16

[GoogleCodeExporter]

We use the timestamp feature for replaying Air Traffic Control scenarios and we 
would definitly need a real time replay.
A simple replay rate speed parameter would be fantastic.

Original comment by blanche...@gmail.com on 22 Mar 2012 at 10:27

[GoogleCodeExporter]

I'm amazed that this feature hasn't been implemented yet.
Is there anyone from Google that can comment on it ?

Original comment by JacobPi...@gmail.com on 15 Jan 2013 at 7:36

[GoogleCodeExporter]

Hey Guys, the way to control the animation speed is trough the 
ge.getTime().setRate(rate) method of the GE (browser) Plugin APIs, where rate=1 
means real time, you can check out a demo replay for a glider contest we 
sponsored here: http://3d.evogps.com/sgp2011/ 

The javascript functions for controlling the speed are:

function setRate() {
    ge.getTime().setRate(rate);
    setTimeout("setRate()", 10)
    if (rate > 1) document.getElementById("speed").innerHTML = +rate + "x";
    if (rate == 1) document.getElementById("speed").innerHTML = "Real time";
    if (rate == 0) document.getElementById("speed").innerHTML = "Pause";
}

function upRate() {
    rate += 1;
}

function downRate() {
    if (rate > 0) rate -= 1;
}

Unfortunatelly there is now way to do the same for the GE desktop application 
as its COM APIs are no longer developed and supported by Google, but probably 
most applications can be implemented using the GE Plugin in the browser.

Original comment by alexand...@evotracking.com on 15 Jan 2013 at 9:21