Thanks for the pointers. This could be helpful.
The data updater that I've implemented actually serves a couple of different purposes. In addition to creating and updating stores and layers in GeoServer, it also assembles layer names composed of meaningful tokens representing layer metadata. So, for example, a file name such as anom.2008.01.tiff is parsed, and combined with metadata contained in an XML config file to produce a layer name like:
tpw-one-month-2008-01-mm-anomaly
The tokens comprising the above layer name represent the dataset acronym (workspace name), periodicity, period, units and statistic represented.
In my JavaScript web GUI, I can then assemble the same layer name, based on user actions, and request this layer for display in OpenLayers, or file download. You can see an example of this approach in action on our development server:
http://zippy.geog.ucsb.edu:8080/EWX/index.html
Currently, this system is strongly coupled to our file naming convention, and to the metadata that we care about for our application. In order to make this thing suitable for general use, I think it would be necessary define an XML schema that allows application developers to declare arbitrary tokens, as well as the range of values that each token may contain.
Extra bonus: I can see going in a couple of directions with this in the future. Firstly, once the Hibernate module is ready for production, the Hibernate POJOs could be extended, perhaps even dynamically, to store the tokens in class properties/RDBMS table fields. This would make them searchable using *QL queries. Over time, this might evolve into something resembling a simple OGC Catalog Service.
Another possibility would be using the XML configuration to generate custom web GUIs containing controls for configuring the values of the various tokens defined in the XML config.
Thoughts?
Cheers,
Greg
On Dec 4, 2009, at 1:06 PM, Chris Holmes wrote:
Greg Ederer wrote:
Hi,
My automated data updater is nearly finished. One thing I still need to do is wipe the GeoWebCache for a layer when either the backing file or the default style has changed. I am injecting my updater Spring bean with a reference to the running GeoServer instance. Is there a convenient way to traverse the object graph from the GeoServer object in order to get the paths to the GEOSERVER_DATA_DIR (which always contains the styles directory) and the GWC directory (which could be somewhere else)?
What version of GeoServer are you using? Arne just last week implemented code on 2.0.x and trunk to automatically expire a GWC Cache based on a change in style or a wfs-t transaction.
See
http://svn.codehaus.org/geoserver/branches/2.0.x/src/gwc/src/main/java/org/geoserver/gwc/GWCCatalogListener.java
http://svn.codehaus.org/geoserver/branches/2.0.x/src/gwc/src/main/java/org/geoserver/gwc/GWCTransactionListener.java
You probably could just use his cleanser class and have it listen to your updater. It uses GWC classes directly to delete the cache.
http://svn.codehaus.org/geoserver/branches/2.0.x/src/gwc/src/main/java/org/geoserver/gwc/GWCCleanser.java
BTW, this automated updating feature is going to be a huge time-saver for the maintainers of our application. We have large volumes of time series data that get updated frequently. My updater is configured using an XML file with a section for each dataset. The updater scans the data directories once per minute, and adds a store and layer for any new data files that it finds.
Currently, the updater relies on our file-naming convention to pull temporal information from the file name. But, this could be generalized by putting regexes in the XML configuration file. Might this make a good community module?
This would make a _great_ community module. GeoSolutions did some similar work, but I don't think it ever got to a community module. Perhaps there could be some collaboration. But I think it's a pretty common, that people would appreciate a solution to. I imagine there are quite a few interesting directions one could take it, but in general being able to listen to a file system for updates is pretty powerful.
best regards,
Chris
Thanks!
Greg
------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Chris Holmes
OpenGeo - http://opengeo.org
Expert service straight from the developers.