TimeIntervalCollection is a poor fit for very granular time ranges

[thw0rted]

This isn't exactly a bug, but I discovered some rough edges trying to work with the recently added time-dynamic WMS support. I brought it up in #6348 and Hannah asked me to open a new issue, so here it is.

I found this sample data in a related ticket, I think. I'm working on a simple parser for the Capabilities document, so that I can advertise layers to the user and automatically configure the supported time parameters. To that end, I'm looking at the <Dimension name="time"> tag.

On this server, the value of that tag is 2011-02-16/2018-12-31/PT5M. OK, let's set up a new WebMapServiceImageryProvider with times = TimeIntervalCollection.fromISO8601({iso8601: str}). This causes parseDuration to create 828000 JulianDates, one for every 5 minutes over 7 years or so. Of course, the browser seems to hang for a long time while this is happening. But to my understanding, this is the only way of providing the time parameter value that should be sent, based on the simulation Clock's currentTime.

Is there another way to handle this? The WMS spec allows a single, simple string that they call a "range" or "periodic interval", to specify an effectively unlimited number of intervals (0001-01-01/9999-12-31/PT1M), so instantiating each interval described, all at once, seems inefficient. Is there a callback-based way of specifying intervals, so that we just describe the mechanism that maps an instant to an interval once? Are changes needed to the code to support this?

As an aside, I'm working on implementing a TimeIntervalCollection that doesn't actually store individual intervals but rather generates them on-demand based on a start/stop/period argument. I'll let you know how that goes.

[hpinkos]

Thanks for opening up this issue @thw0rted. I'll have a chance to look into this further and get back to you next week.

[hpinkos]

It does seem like a problem that we're creating so many JulianDate as soon as the imagery provider is created. @tfili do you have thoughts on this?

[tfili]

The fromISO8601* functions are just for convenience because date parsing can be a pain. All the functions will eventually call fromJulianDateArray.

You can however just call addInterval at anytime to add the interval. If you are animating via a clock, you can listen to the clock.onTick event to make sure you interval is there in time for us to use it.

[thw0rted]

Just to give you an idea of what I'm thinking, this class (in TypeScript, but easy enough to transpile, I think) is what I worked out after posting the initial issue. I know it isn't perfect and there are probably some cases where it would not be a drop-in replacement for other uses of TimeIntervalCollection. But for my specific situation -- trying to map simulation time to a TimeDynamicImagery query parameter -- it gets the job done.