NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Aaron- from our implementation experience it is a substantial difference for a server to support - 1-D time series (such as classical SCADA systems) - 2-D maps - 3-D+ data sets Now imagine use case scenarios: an environmental sensor system supplier develops a client and a server. The server wouldn't be happy to support 2D (data formats; CRSs; spatial subsetting; ...) which never ever is going to be used. Likewise, the client is streamlined towards value sequences. Next, a 2-D vendor wants maps, but not 1-D timeseries nor 3D+. One of the issues would be that some CRSs do not support x/z slices and such stuff. My personal (not necessarily WCS, but we anyway are heterogeneous as well ;-) ) opinion is that the supported dimensionality should be factored out into extensions dealing with CRSs (that's the natural point IMHO). The issue of n-D CRSs actually is with the CRS group currently where we wait for their decision on the approach to be adopted (Arliss Whiteside, our Grand Guru, has produced suggestions). This n-D extension would (will?) allow spatial, temporal, and any further axes in free combination. Current status is to put emphasis on the GIS community (which has a strong influence & importance, if not for historic reasons) and fix 2D in the core. The n-D extension would go separate. ...just to share some goings-on and some of our trouble ;-) -Peter Aaron Braeckel wrote:
Renamed thread per Ben's suggestion. If a 2D client talks to a 4D server, it has to be able to detect that the WCS is beyond its capabilities but otherwise I'm not sure that much additional complexity is imposed on clients. A process for describing the dimensionality of the server is definitely important with an N-dimensional WCS, but I think this is already largely covered by the CRS description in the current WCS specification. I see it as another flexible point in the specification. Just as the WCS does not mandate any particular encoding format or specific CRS/data projection, it would not mandate the dimensionality of the data. As in cases where an unknown CRS is in use by a WCS server, a client makes a decision about whether it is capable of handling that WCS implementation. The reason I see N-dimensionality as preferable to a restricted dimensionality is that the restriction: -forces non-2D WCS implementors to fulfill a more complicated extension, even when simple core functionality is all that is needed -increases the number of necessary extensions, at least with how the current extensions are described and laid out. Minimizing the number of extensions seems beneficial to interoperability overall -seems to cut the WCS functionality into groupings at a different angle than the general coverage concept (i.e. less generalized coverage capability) Are there cases I am forgetting that might cause problems for 2D implementors? Aaron
galeon archives: