NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
This is an enlightening thread. Removing the artificial distinctions between features and coverages and between the WFS, WCS, and SOS specs is key in understanding their relationships. I have to admit I'm one of the people John referred to as not fully understanding how "everything is a feature," but is seems that declaring one spec as the "front" to another, or that one is a "sub-type" of another brings these artificial distinctions back into the picture. I don't think absolute rules like this can be defined in relating the specs. As has been said by many in this thread, it comes down to your perspective whether one service sits in front or behind another. Simon's slides nicely depict a few use cases where multiple specs come into play (or don't come into play). It would be great if we could augment his start with other multi-spec cases driven by our respective implementation experiences. Exploring how specifications relate to one another in practice will help identify if and how the individual specifications need to be modified to support such relations. -Stefan On 5/10/07, Ron Lake <rlake@xxxxxxxxxxxxx> wrote:
John: I don't disagree – except we don't seem to have a top down model with respect to services and how those services should fit together and what they are all for. I think we have a reasonably coherent model for data in the abstract specification. That is the top down part that I see as missing. I do agree that everything is a feature – and most especially coverages and observations – and to me a consequence of that ought to be that a WCS is a kind of WFS as is a SOS. Ron
galeon archives: