Andrea,
Which java class(s) is actually going out to the database and doing an sql
query (MIN/MAX) on the tables that have time-based data ?
It appears that which ever class it is, is doing a MIN/MAX against every table
in the database, not just the tables tied to the GeoServer. Is this the case ?
Tim
Date: Sat, 22 Sep 2012 10:23:07 +0200
Subject: Re: [Geoserver-users] WMS request=getcapabilities takes a
loooooooooooooong time to return
From: andrea.a...@geo-solutions.it
To: chol...@opengeo.org
CC: t...@hotmail.com; geoserver-users@lists.sourceforge.net
On Fri, Sep 21, 2012 at 10:34 PM, Chris Holmes <chol...@opengeo.org> wrote:
Thanks for offering the possibility to code! We always love new contributors to
GeoServer.
I'm not sure on the classes, Andrea can help with that. But seems like it would
ideally work in the same way the 'bounds' works. It was built the way it is for
the same issue - dynamic requesting of data can slow capabilities documents a
lot.
The reason why this is dynamic today is that dimension handling is born for
metereological data, in whichnew entries in the mosaics/vector data happen
multiple times a day, as multiple other ones go, there
is a moving window of "fresh" data kept published.But I agree this is less than
ideal for people with large data sets that are static over time.
Perhaps we could do it in the same GUI call of the bounds on the featureType? I
mean, it seems to just be an extra dimension of the bounds. So a user would hit
'generate bounds' and it would grab not only the geographic bounds but also the
time bounds. I'm just thinking that could be nicer than two different buttons
they have to hit.
Hmm.. don't think this is feasible for a number of reasons:- for vector data
elevation and time source attributes have to be chosen first- support for
custom dimensions is incoming (those needs to be configured manually too)
- even if a source data has dimensions it does not mean the admin wants to
advertise them, because the capabilities document could grow too large (we
have mosaics with hundreds of thousands of values, publishing the as ranges it
pretty much useless
for the case at hand, so CQL_FILTER for coverages is used instead with the
end user app having a off band tool to get the list of values)- the type of
data access is different depending on the presentation of the dimension
(range, list of values)
And definitely would be good to get away from that fully dynamic generation of
any part of the capabilities document, we should try our best to make it so the
default experience is always both fast and fully standards compliant. Better to
have a user be able to choose 'dynamic mode' if they want it generated every
time, and default to a cached thing that performs better, imho.
I would default to dynamic, yet to see a single application whose set of time
values is cast in stone.Archaeology/history maybe? All the ones I'm dealing
with are based on near real time acquired data
or projected data (simulation models) where a static setup is simply a no go
But I agree having a way to choose is the best option
CheersAndrea
--
==Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.==
Ing. Andrea Aime @geowolfTechnical Lead
GeoSolutions S.A.S.Via Poggio alle Viti 118755054 Massarosa (LU)Italyphone:
+39 0584 962313
fax: +39 0584 1660272mob: +39 339 8844549
http://www.geo-solutions.ithttp://twitter.com/geosolutions_it
-------------------------------------------------------
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
