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 >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/geoserver-devel > > -- > Chris Holmes > OpenGeo - http://opengeo.org > Expert service straight from the developers. ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
