Rob Atkinson <[EMAIL PROTECTED]> wrote on 11/15/2006 04:55:51 AM:
> Bryce L Nordgren wrote: > > 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 ? My first statement was uninformed, as my assumption was that WCS didn't support resampling. Delving into it, WCS allows specification of 5 interpolation functions, the default being nearest neighbor. WCS also allows for a server or client to specify "no interpolation". I think it would be unfair to say that it doesn't expose the interpolation function. Let me modify my previous statement to: + WCS implements ContinuousQGC for requests which resample + WCS also implements DiscreteGPC for requests which subset with no resampling. These are only "approximate" implementations: Neither implementation supports evaluation at a single point unless you fudge by making a grid with one point in it, and the coverage spec doesn't include an evaluate(GM_PointGrid) signature. Sorry for being so pedantic. In order for me to understand, I need a single vocabulary to describe everything from standards to implementation. > > 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. All right. I think I see. Reading the proposal again, it looks like you want to write an adapter between the new feature model and the Hibernate introspection mechanism? I had an idea like this long ago, only the adapters I had in mind were between the new feature model and... + EMF + standard Java Beans Introspection I think everyone can coexist happily. My question is where does this fit in the big picture? Are these really separate adapters or data source plugins? > > 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 How far does this extend? For instance, do you intend to generate GML which indicates the presence of Coverage operations, or are these operations assumed to be present since you're describing a coverage. Also, do you intend to advertise the operations which are specified in 19123, or the operations which are actually implemented in a WCS, and therefore available? > > 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. The coverage schema itself is pretty light on metadata and heavy on operations. Are you talking mainly about exposing the Domain and Range associations (WCS: domainSet; rangeSet from describeCoverage)? Also, what counts as coverage (as opposed to server) metadata? In terms of CRS, do you count only the native CRS of the coverage, or all the CRSes that the server will reproject to? The last one almost seems like server metadata to me. But of course, how you look at it depends on what you're using the metadata for. > > 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. 19123 allows queries by values in the range, but does not allow anything so flexible as the Filter deal. You can provide one tuple of range values and it'll return all the "matches", where the coverage decides what is meant by a "match". No expressions allowed. Although I can certainly see that it would be useful to provide an implementation where you could set a filter on a coverage, then from that point on, "evaluateInverse" obeyed the filter. Let me see...I just looked up what you can do with WCS 1.0 and the spec confuses me. Can anyone explain the optional _PARAMETER_ argument to GetCoverage to me? My issue is that the examples in Table 9 on Page 32 seem contradictory. "band=1,3,5" means return only the data in bands 1, 3, and 5; but "age=0/18" means return only those points where the value of the "age" field is between 0 and 18? Which is it, an index into a "range vector" or limits on the values in one particular element of that vector? I think this makes a difference as to whether you can just provide a URL for the user to go get the data themselves or not. > > 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. When I said this, I think my mindset was that continuous coverages must be discreteized before they can be served. Once this happens, they're no longer continuous. Perhaps it would be better to say that all WCS-served data are the result of an evaluate() operation applied to each point on a regular grid in the domain. This is a sampling of the coverage and not the coverage itself. :) In terms of coverage IO, I think all coverages on disk are going to be initially represented with DiscreteGridPointCoverages. If someone wants to interpolate, I think it logical to provide a constructor to ContinuousQGC which takes a DiscreteGPC as an initializer. Coffee. Need. Coffee. 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 Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
