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: