Bear with me a little here.. Coverage is an interface with some basic operations, which specific interfaces can implement.
Let us imagine defining a specialisation of coverage, which introduces a new operation. It would be nice to simply declare the operation as part of the new type, and plugin an implementation. This would allow us to implement any operation locally, for efficiency, but equally allow us to declare a service that will invoke that operation, since the operation is defined in a feature type - i.e. something defined by the community, allowing thoird part services to be created. The implication of this is that we ought to be able to advertise what operations we support on a given feature type. IMHO this will require a change request eventually, but I'd suggest we implement it first, then push the change request into OGC once proven. There are interested parties who would do the pushing, but it requires implementation first - which may be resourced as part of a services architecture activity - but in the meantime, the operation and data type injection would be a cool way of handling a whole raft of extension and configuration requirements. Rob Andrea Aime wrote: > Bryce L Nordgren ha scritto: > >> Arrrgh! >> >> Resampling a gridded coverage. Is this a service (ala 19119; i.e. >> portrayal), or a feature operation concept (ala 19126/N2052)? >> >> A service is a thing external to a coverage, which operates on a coverage. >> If a particular service implementation is optimized for a particular >> coverage implementation, it'll have dependencies on the coverage internals. >> (It'll use Simone's cool JAI stuff on coverages which it knows to be backed >> by J2SE Images, and won't work on other implementations.) >> >> A feature operation concept is a common method name, parameter list, and >> return type. This could well manifest itself as a "ResamplingCoverage" >> interface with a "resample(x,y,width,height,crs)" method. Interested >> coverage classes could implement this interface. This puts the code for >> resampling INSIDE all coverage classes. >> > > I don't think resampling should be a feature operation then. Resampling > is an important operation for sure, but so are a ton of others. > If I understand properly, service allows for unlimited extension without > the need to alter coverage and/or add new interfaces all of the time. > > It should be something external to coverage in my opinion, so I'd say > service too, and yes, must be damn well coupled at the implementation > level if you want to get good enough performance to make practical > applications viable. > > Just my 2 cents. > > Cheers > Andrea > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
