Thanks Bryce,

comments and clarifications inline.

Bryce L Nordgren wrote:
> Source:
> http://docs.codehaus.org/pages/viewpage.action?pageId=62876
>
> I don't know anything about goals 1 & 2.
>
>   
These relate to discussions already underway about handling new types.
> Goal 3 seems appropriately positioned.
>
> Prologue to the rest:
> "Features" and "Coverages" ala ISO do not seem to correspond to that which
> is served by a Web Feature Service / Web Coverage Service. 
Yes - this is true. Its a function of a parochial approach to WCS. WCS 
also has a historic arbitrary refusal to inherit from emerging ideas of 
an OWS_common at the time. One reasone to say if we want to do arbitrary 
coverages, we'd be better off starting with WFS and treat WCS as a 
"convenience API" for 2D raster grids.

>  In particular,
> WCS/WFS divide the problem into the Raster/Vector problem spaces, and ISO
> divides the problem into single-valued/multi-valued problem spaces.  A WFS,
> serving a particular feature, performs many of the functions which belong
> to a DiscreteCoverage in the ISO world. 
Feature collections may not represent a coverage - there is no 
requirement for a mapping from a domain to a range, but this may be 
splitting hairs in practice.
>  (e.g., spatially indexed lookup of
> values from a collection of range/value pairs, where the values are
> homogeneous within the collection; range=defaultGeometry; value=everything
> else).  I remain blissfully ignorant of ISO's efforts to adopt WFS into
> their framework (19141, I think).
>   
> Short version: if I was pressed to describe what an WFS is, I'd have to say
> it is a discrete coverage implementation using Web Services technology.  A
> WCS would then be an implementation of DiscreteGridPointCoverage
> implementation.  Messy, because this implies a parent-child relationship
> between WFS & WCS.
>   
WCS could also be seen as implementing a 
ContinuousQuadrilateralGridCoverage, but not exposing the interpolation 
function ?
> Goal 4:
> Not sure I understand what is the main point.  Why limit ourselves to POJO
> databases?  Conversely, if we can create featuretypes from inspection of an
> arbitrary JDBC data source now, why does this not carry over to POJO
> databases?  Why do POJO databases require an extra abstraction layer
> instead of just a driver?  I'm not sure I "get it" enough to ask anything
> intelligent.
>   
OK - there are two kinda non-obvious reasons for this - one is that its 
a separate set of business goals that shares the need for operations 
etc, but also because we I hope can make POJOs to implement coverage 
operations and inject them using this mechanism, allowing us to extend 
the types of coverages supported.
> Goal 5:
> Unsure as to the proposal.  Is this an addition to a WFS which basically
> allows the server to "cascade" to a WCS?  Are we trying to wrap the bare
> bones raster data with GML representative of a Feature possessing the
> characteristics of a 19123 Coverage?  
yes
> Should we also consider repackaging
> the whole shootin' match into GML: each returned pixel/grid cell gets its
> own record in the returned GML (or shapefile)?  In ISO speak, someone might
> want to treat DiscreteGridPointCoverage data as if it were a plain
> DiscreteCoverage.
>   
we might want to, but at the moment I have seen no strong drivers for 
this. But we do want to shift the rest of the metadata about coverages 
through processing chains.
> Goal 6:
> This is the Holy Grail!  I know exactly whazzup with this one!  For some
> thoughts on how vertical/temporal subsetting may be handled, see the
> analysis of WMS 1.3.0 on the Multidimensional WCS page.  They've provided
> for this functionality.  (
> http://docs.codehaus.org/display/GEOS/Multidimensional+WCS)  Perhaps future
> versions of WMS/WFS will adopt the same strategy?  I'm not sure you're
> going to be able to use a WFS to query a WCS based on the grid cell values
> unless you adopt a cascading mentality.  The WFS is going to have to hide
> the WCS entirely, and can't just include a link so the user can get the
> data directly.
>   
I think I agree - WCS 1.0 can be used only for subsetting a small 
subclass of coverage types we might enable. Maybe a WCS 2.0+ will be 
more flexible one day.
> One minor point: if it's served by a WCS, it's a discrete grid point
> coverage.  No continuous coverages are served over the net.
>   
But we want to free ourselves of this very arbitrary limitation. Without 
having to redefine WCS, by using WFS which is perfectly capable, if we 
can invoke operations.


> Bryce
>   



-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to