From: Jody G. <jod...@gm...> - 2011-05-03 13:13:40
|
Gak; my feedback was not intended to shut down discussion; but to start it. Please don't respond by threatening to pull the module into a geoserver community module; not productive. Look if you are rocking up with something that has to be done a specific way for customer requirements say so. To sum up: - you are correct coveage store is not what is needed - I am trying to understand where the CQL fits with the use of this beast as a Format; I am used to formats accepting a String; if the string is a CQL expression that is fine? If not I don't understand where the CQL fits (but I can wait until I see the wiki page) -- Jody Garnett On Tuesday, 3 May 2011 at 8:19 PM, Andrea Aime wrote: > On Tue, May 3, 2011 at 11:03 AM, Jody Garnett <jod...@gm...> 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 > > ------------------------------------------------------- > |