When I play back a Google Earth simulation of an event I recorded, I set the plugin time like this:
var timeStamp = ge.createTimeStamp('timeid');
timeStamp.getWhen().set(iso8601punct(f.start));
ge.getTime().setTimePrimitive(timeStamp);
f.start is the start time of the event. iso8601punct converts a Javascript Date object to a string (why does this function want a string and not a Javascript Date object anyway? – but that's not the issue).
I have also enabled historical imagery.
I believe that what happens is that Google Earth selects the imagery that was taken as close as possible to the time I requested.
It would be better for our application if we could select scenery that matches the season of the date we request, even if that scenery is farther in the past (or future) than some other scenery that is currently displayed. For example, if the date is 2012-01-20 then Winter imagery from 2011-02-25 is a better fit than Summer imagery from 2011-08-31, even if the Summer imagery is only 5 months away from the requested date and the Winter imagery is 11 months away.
I see two ways to implement this:
- If the API gave access to a list of available historical imagery dates, we could write code to choose one that suits us. I don't believe the API makes this information available though (furthermore, I imagine that it probably gets a little complicated internally because different dates are available in different geographical areas).
- The API could provide a way to register interest in different sets of imagery, say by making available a flag that says that the month and day are more important than the year. It could also be something more ambitious like registering a callback function that returns a preference score given a date.
If I have missed something and this functionality already exists, I'd appreciate a hint!
You can use ge.getTime().getControl().getAvailableImageDates() to get
a list of available timestamps for imagery in a particular view
(basically the same data that provides the tickmarks you see in the UI
control). As you zoom into different areas, this list of dates will
change.
> When I play back a Google Earth simulation of an event I recorded, I set
> the plugin time like this:
> var timeStamp = ge.createTimeStamp('timeid');
> timeStamp.getWhen().set(iso8601punct(f.start));
> ge.getTime().setTimePrimitive(timeStamp);
> f.start is the start time of the event. iso8601punct converts a Javascript
> Date object to a string (why does this function want a string and not a
> Javascript Date object anyway? – but that's not the issue).
> I have also enabled historical imagery.
> I believe that what happens is that Google Earth selects the imagery that
> was taken as close as possible to the time I requested.
> It would be better for our application if we could select scenery that
> matches the season of the date we request, even if that scenery is farther
> in the past (or future) than some other scenery that is currently
> displayed. For example, if the date is 2012-01-20 then Winter imagery from
> 2011-02-25 is a better fit than Summer imagery from 2011-08-31, even if the
> Summer imagery is only 5 months away from the requested date and the Winter
> imagery is 11 months away.
> I see two ways to implement this:
> - If the API gave access to a list of available historical imagery
> dates, we could write code to choose one that suits us. I don't believe the
> API makes this information available though (furthermore, I imagine that it
> probably gets a little complicated internally because different dates are
> available in different geographical areas).
> - The API could provide a way to register interest in different sets of
> imagery, say by making available a flag that says that the month and day
> are more important than the year. It could also be something more ambitious
> like registering a callback function that returns a preference score given
> a date.
> If I have missed something and this functionality already exists, I'd
> appreciate a hint!
I hope the OP doesn't mind me dropping another quick question in
here ... as it is related I beleive.
I might well be missing something simple but is there a way to set the
date of the imagery I wish to show but without having to have/use the
slider. I have a location where the current imagery is not as good as
some from a few years ago so I just want to be able to set the date I
use but not have any of it's selection visible to the user - just do
it all in the background.
> You can use ge.getTime().getControl().getAvailableImageDates() to get
> a list of available timestamps for imagery in a particular view
> (basically the same data that provides the tickmarks you see in the UI
> control). As you zoom into different areas, this list of dates will
> change.
> Cheers,
> -Josh
> On Feb 5, 7:24 pm, Phil Vandry wrote:
> > When I play back a Google Earth simulation of an event I recorded, I set
> > the plugin time like this:
> > f.start is the start time of the event. iso8601punct converts a Javascript
> > Date object to a string (why does this function want a string and not a
> > Javascript Date object anyway? – but that's not the issue).
> > I have also enabled historical imagery.
> > I believe that what happens is that Google Earth selects the imagery that
> > was taken as close as possible to the time I requested.
> > It would be better for our application if we could select scenery that
> > matches the season of the date we request, even if that scenery is farther
> > in the past (or future) than some other scenery that is currently
> > displayed. For example, if the date is 2012-01-20 then Winter imagery from
> > 2011-02-25 is a better fit than Summer imagery from 2011-08-31, even if the
> > Summer imagery is only 5 months away from the requested date and the Winter
> > imagery is 11 months away.
> > I see two ways to implement this:
> > - If the API gave access to a list of available historical imagery
> > dates, we could write code to choose one that suits us. I don't believe the
> > API makes this information available though (furthermore, I imagine that it
> > probably gets a little complicated internally because different dates are
> > available in different geographical areas).
> > - The API could provide a way to register interest in different sets of
> > imagery, say by making available a flag that says that the month and day
> > are more important than the year. It could also be something more ambitious
> > like registering a callback function that returns a preference score given
> > a date.
> > If I have missed something and this functionality already exists, I'd
> > appreciate a hint!
Your tools suck. This Google Groups thing is just about impossible to use. Use a normal mailing list like the rest of the people on the planet.
Thanks for the suggestion Josh. I have not tried it yet but look forward to doing so. But note that you won't be hearing from me about how it worked out unless your mail server decides it wants my reply.
> I hope the OP doesn't mind me dropping another quick question in
> here ... as it is related I beleive.
> I might well be missing something simple but is there a way to set the
> date of the imagery I wish to show but without having to have/use the
> slider. I have a location where the current imagery is not as good as
> some from a few years ago so I just want to be able to set the date I
> use but not have any of it's selection visible to the user - just do
> it all in the background.
> Is there a way to do that?
> Regards
> Nymor
> On Feb 6, 8:46 pm, Josh L wrote:
> > Hi Phil,
> > You can use ge.getTime().getControl().getAvailableImageDates() to get
> > a list of available timestamps for imagery in a particular view
> > (basically the same data that provides the tickmarks you see in the UI
> > control). As you zoom into different areas, this list of dates will
> > change.
> > Cheers,
> > -Josh
> > On Feb 5, 7:24 pm, Phil Vandry wrote:
> > > When I play back a Google Earth simulation of an event I recorded, I set
> > > the plugin time like this:
> > > f.start is the start time of the event. iso8601punct converts a Javascript
> > > Date object to a string (why does this function want a string and not a
> > > Javascript Date object anyway? – but that's not the issue).
> > > I have also enabled historical imagery.
> > > I believe that what happens is that Google Earth selects the imagery that
> > > was taken as close as possible to the time I requested.
> > > It would be better for our application if we could select scenery that
> > > matches the season of the date we request, even if that scenery is farther
> > > in the past (or future) than some other scenery that is currently
> > > displayed. For example, if the date is 2012-01-20 then Winter imagery from
> > > 2011-02-25 is a better fit than Summer imagery from 2011-08-31, even if the
> > > Summer imagery is only 5 months away from the requested date and the Winter
> > > imagery is 11 months away.
> > > I see two ways to implement this:
> > > - If the API gave access to a list of available historical imagery
> > > dates, we could write code to choose one that suits us. I don't believe the
> > > API makes this information available though (furthermore, I imagine that it
> > > probably gets a little complicated internally because different dates are
> > > available in different geographical areas).
> > > - The API could provide a way to register interest in different sets of
> > > imagery, say by making available a flag that says that the month and day
> > > are more important than the year. It could also be something more ambitious
> > > like registering a callback function that returns a preference score given
> > > a date.
> > > If I have missed something and this functionality already exists, I'd
> > > appreciate a hint!
