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 which
new 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
Cheers
Andrea
--
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
------------------------------------------------------------------------------
How fast is your code?
3 out of 4 devs don\\\'t know how their code performs in production.
Find out how slow your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219672;13503038;z?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
