On Tue, May 3, 2011 at 11:03 AM, Jody Garnett <[email protected]> wrote: > It sounds like an interesting idea; is there any chance of making this > relationship a bit more formal (as was done with DirectoryDataStore) so that > your "main directory" support additional file formats over time?
Hi Jody, what you're after there is CoverageStore, which is in unsupported and does not have at the moment resources backing it to actually be able to push it into supported land (would also be a landslide change on all coverage i/o, so large work). In this case we just want to take a directory tree that is controlled by an external application, constantly adding and removing images in it, and allow a client having access to a queryable catalog of this images to ask for a specific one (the images being served by GeoServer). We don't want to publish each and every single image as a separate store in GeoServer, nor we can have these layers be handled and exposed one by one because that would result in a massive capabilities document. The client would be overwhelmed by it, besides, we need searchability so the other service the client is talking to would behave more like a OGC catalog (but custom developed for specific needs). Long story short, having a mechanism to advertise what coverages are inside the thing really goes in the opposite direction vs our requirements. I understand this is custom and most of the motivation lies in the web services part of the work. Maybe we should share this work as a GeoServer community module instead? > Having the path hanging out in the open like that seems a bit of a security > risk does it not? Very much agree there should be checks so that the relative path cannot be used to inspect random files on the file system. > I am not sure how PATH="subfolder1/draft3/image2.tif" is a > CQL expression? attribute = value is a cql expression all right. Again, there is some GeoServer bias here. In other readers we have this idea that coverages can be associated to attributes, especially evident in mosaic where each granule can have any number of extra attributes that can be used for filtering (think time/elevation and other dimensions, but really any kind of attribute, mosaic can use a generic geotools data store to keep the granule index and information). So we want to take the CQL_FILTER/FILTER/FEATURE_ID filtering that is already exposed by GeoServer and pass it down to the coverage readers if they expose a Param with name "FILTER" and type Filter It is also a generic way to work again geotiff files having multiple images, netcdf and so on: you decide what you want to get out of the file by providing a filter. The attributes in the case of the mosaic are coming from the index store, in others are conventionally chosen to represent some features of the elements contained in the store (in this case, the image path). > - CQL defines a Filter - it is not used to stage a parameter for reading > (confusing the topic of "=" which is a test, and "==" which defines a value) in CQL = is a test and we used it that way in the example, there is no confusion > I would feel more comfortable if the library was consistent in this respect? I don't think we can abide for the reasons stated above. As said, don't want to cause troubles, we realize the specific nature of the plugin, it's just that we have no requirement to make it closed source so we wanted to share it anyways, but it may be somewhere else (afaik we have no requirement to make it open source either). Cheers Andrea -- ------------------------------------------------------- Ing. Andrea Aime GeoSolutions S.A.S. Tech lead Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 962313 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.youtube.com/user/GeoSolutionsIT http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf ------------------------------------------------------- ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
