On Wed, Oct 31, 2018 at 12:45 PM Johannes Weskamm
wrote:
> Maybe you could give me a hint where (files / classes) development for
> this should start off.
>
I don't have time to produce a list, but this commit added "nearest match"
for time in WMS, and it touches
many of the same files/classes
Hi,
You are right, the queries itself could be fast. I identified my
SQL-View of the layer to be the problem.
When requesting the layer via WMS, the resulting SQL query made by
geoserver will always contain an AND filter for the timestamp, which
makes the service working fast.
But when
Hi,
there is indeed no way to configure GeoServer with static time domain
values (could be done, needs coding, preventive discussion on the
devel list and then implementation according to the published contribution
rules).
However, finding min and max should be fast if you have an index on the
I have already checked that, and tried the different options, sadly it
does not change the time it takes to generate the capabilities document.
I tried dynamic values and also hardcoded timestamps, the result is the
same (timeouts).
I think geoserver is still asking the database for the min and
How are you specifying the Default value strategy?
If you change that to Reference Value, you can use a form like
fromValue/toValue. It's also possible to use relative times like
P1M/PRESENT, but note that the reference value is copied verbatim into the
capabilities document, which might not be
