Thanks Andrea for the additional feedbacks.
For your information, this is the wiki page I'm setting up:
http://docs.codehaus.org/display/GEOTOOLS/ImageCollection
Regards,
Daniele
On Tue, May 3, 2011 at 12:19 PM, Andrea Aime
<andrea.a...@geo-solutions.it>wrote:
> On Tue, May 3, 2011 at 11:03 AM, Jody Garnett <jody.garn...@gmail.com>
> 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
> Geotools-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
--
-------------------------------------------------------
Ing. Daniele Romagnoli
GeoSolutions S.A.S.
Software Engineer
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://it.linkedin.com/in/danieleromagnoli
-------------------------------------------------------
------------------------------------------------------------------------------
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
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
