Interesting thoughts on this thread which have taken me time to digest. I'd like to refine the definition our problem into 2 use cases: Use case 1. Generalization using WMS/WFS. As a user zooms in, they want more detail and want to see vector data. As they zoom out, the bandwidth required for vector data becomes prohibitive and we need to either generalize the vector data, or switch to image format. When I think of it this way, it makes me wonder whether we should be using SLD to determine which dataset/service we use at different resolutions.
Use Case 2. WMS Editing: A user wants to view an WMS, select a feature on the WMS, edit it, then save it back into the WMS database. Currently WMS doesn't support transactions, so a work around we have used in Mapbuilder is to link a WMS layer to the equivalent WFS layer to perform a transaction. -- Grouping has been mentioned in this thread. Grouping works for associating similar layers (All the water layers say), but that is not what we have here. We want to describe one layer in both vector and raster formats. The client should only render one format (depending upon resolution). I think nested <ResourceLists> fits in a similar category. -- Josh, I think you suggested linking from a WFS <FeatureType> to a WMS <Layer> and visa-versa? This is a bit messy. If I have a legend widget, I only want to show the user one <Layer> not 2 and it will be messy to merge the same information from 2 layers. -- Tom, as far as I can work out, WMS doesn't support DescribeLayer like the WFS DescribeResourceType. 1. You suggest checking "if WFS-able". I'm not sure how this information can be extracted? 2. Speed is very important in clients, and chaining requests to extract information from a service is not ideal. Hence I'd argue to have the WMS<->WFS link inside the context document. Joshua Lieberman wrote: > On Sep 6, 2007, at 12:43 PM, Kralidis,Tom [Burlington] wrote: > > >> >>> -----Original Message----- >>> From: >>> [EMAIL PROTECTED] >>> [mailto:[EMAIL PROTECTED] >>> al.org] On Behalf Of Joshua Lieberman >>> Sent: 06 September, 2007 12:09 PM >>> To: Raj Singh >>> Cc: [EMAIL PROTECTED]; >>> [email protected] >>> Subject: Re: [Context.RWG] Associating WMS and WFS in the same layer >>> >>> It would be best, I think, to point link a WMS layer with a >>> WFS layer, so that they can have separate information. The >>> DataURL element in ResourceType is another way to point at >>> the right WFS for the features in a WMS layer. It is a bit >>> inferential in that you would presumably supply the >>> GetFeature request with only the featureType specified in the >>> DataURL and the client would need to infer how to create its >>> own request with the appropriate filter, possibly as a POST >>> instead of a GET. >>> >>> >> True. We do this for our Capabilities documents where applicable, >> i.e. >> put a GetFeature request in DataURL, which would return the entire >> dataset. >> >> >>> The DescribeLayer request does not necessarily supply any >>> clear WFS binding information except for the endpoint which >>> "could" differ from that of the GetFeature request. >>> >>> >> As well as Query/@typeName, which "could" differ also. Could one not >> cobble together a GetFeature from this? i.e.: >> >> - read OWC >> - foreach ResourceList/Layer >> - do a DescribeLayer request >> - if WFS-able >> - set URL, typename somewhere in app, expose as "extractable" >> - when the user wants to extract, client binds and spatial and / or >> aspatial criteria together in a Filter construct and passes along >> >> The only thing that won't be around is the WFS version, which could be >> figured out by some version negotiation either after a successful >> DescribeLayer request or before a GetFeature request. >> > > It isn't certain that a WMS supports DescribeFeature, even if the > features are available separately from a WFS. It would be possible to > have more than one DataURL, including the GetFeature operation, > GetCapabilities, and DescribeFeature links (although that could be > the MetadataURL as well). The ows:onlineResource has one or more > tags, I believe, to differentiate them. In the end, though, there > would still be a certain amount of inference on the part of the > client, whereas "Layer" and "FeatureType" have clear parallelism in > the context document as well as clear information on how a client can > use their information > >>> Perhaps the group attribute would be useful here, to group a >>> corresponding WMS and WFS resource together. We never defined >>> particular vocabulary or syntax for this element, but the >>> idea was to support various larger layer structures including >>> nesting. >>> >>> >> This is true. But what happens if you want to group a bunch of >> extratable layers together? Would we need nested grouping? >> > > This is an interesting discussion which has occurred a few times. > Three approaches (at least) which have been discussed: > > 1) Overload the group element with a path, e.g. "Infrastructure/Roads/ > RegionalRoads/ManitobaRoads", so that larger groups can be picked > out, but the lowest level is generally a group of different resource > types for the same features. The semantics of the path could > presumably be inferred (again) by comparing the resource types, > scales, and extents of each resource against their grouping. > > 2) Add a "parent" attribute to form more clearly a resource > hierarchy. This doesn't define any more clearly the purpose of a > level nor the relationships of resources within the same level, > however. It also has the problem that it requires definition of > "container" resources which only serve to group other resources. It > might make more sense, in fact, to add "parent" to resourceList and > allow multiple resourceList elements or else nest them physically in > the XML as Raj describes, but this does overload the present intent > of resourcelist as a simple XML document container element. > > 3) Add a separate mapgraph section to the context which describes the > relationships among the listed resources, essentially borrowing the > taxonomyScheme from the venerable r7 capabilities structure. This > requires reliable unique id's for each resource, at least within the > document. It has the advantage that we can annotate each group with > its purpose as well as describe the hierarchy between them. It is > also possible to provide more than one mapgraph for a given context > document, perhaps for different audiences or different scales. For > that matter, the "hidden" attribute might be more useful in this > section and could override each resource's attribute. It also allows > a simpler client to ignore the additional information altogether and > just show the resourceList in order > > This last probably introduces the most new development for client > providers, however, I suspect that most legend or layer control data > structures are set up in a way close to this anyway. > > --Josh > > >>> --Josh >>> >>> On Sep 6, 2007, at 10:27 AM, Raj Singh wrote: >>> >>> >>>> I agree with Tom. The idea of joining the 2 services so >>>> >>> explicitly in >>> >>>> the Context encoding is also limiting or misleading in a >>>> >>> way, because >>> >>>> there are scenarios where the "navigation" WMS doesn't need to be >>>> showing the same data as the "download" WFS. >>>> >>>> If the interest is in a general way to signal that two or more >>>> services only make sense when used together, maybe a better >>>> >>> idea is to >>> >>>> allow nested <ResourceList>s, and give that element some metadata, >>>> like a title and abstract. >>>> >>>> --- >>>> Raj >>>> >>>> >>>> On Sep 6, 2007, at 8:24 AM, Kralidis,Tom [Burlington] wrote: >>>> >>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Cameron Shorter [mailto:[EMAIL PROTECTED] >>>>>> Sent: 05 September, 2007 4:41 PM >>>>>> To: [EMAIL PROTECTED]; >>>>>> '[email protected]'; Kralidis,Tom >>>>>> >>> [Burlington] >>> >>>>>> Subject: Associating WMS and WFS in the same layer >>>>>> >>>>>> Tom, >>>>>> Another OWS Context question. >>>>>> In the CGDI Pilot we are working on, there is a >>>>>> >>> requirement to find >>> >>>>>> and then download GML from a WFS. >>>>>> >>>>>> When finding a dataset, a user will generally want to use WMS >>>>>> interface to view datasets because it requires less >>>>>> >>> bandwidth. Then >>> >>>>>> when the Area Of Interest has been selected, the user >>>>>> >>> will download >>> >>>>>> the dataset using WFS. >>>>>> >>>>>> In order to do this, we need to associate a WMS layer with a WFS >>>>>> layer. >>>>>> I think this should be done using something like: >>>>>> >>>>>> <Layer queryable="0" hidden="0"> >>>>>> <Server service="OGC:WMS" version="1.0.0" >>>>>> title="OGC:WMS" default="1"> >>>>>> <OnlineResource xlink:type="simple" >>>>>> xlink:href="http://localhost:8080/wms"/> >>>>>> </Server> >>>>>> <Server service="OGC:WFS" version="1.0.0" title="OGC:WFS"> >>>>>> <OnlineResource xlink:type="simple" >>>>>> xlink:href="http://localhost:8080/wms"/> >>>>>> </Server> >>>>>> <Name>basic</Name> >>>>>> <Title>World Basemap</Title> >>>>>> <SRS>EPSG:4326</SRS> >>>>>> </Layer> >>>>>> >>>>>> >>>>>> Note, this means that a WFS layer should be inserted inside a >>>>>> <Layer> tag instead of a <FeatureType> tag. >>>>>> This comment could be extended to showing the same layer as KML, >>>>>> Tiled WMS, ... >>>>>> >>>>>> Tom, what are your thoughts on this? >>>>>> >>>>>> >>>>> Isn't this what WMS DescribeLayer is for? What I would do >>>>> >>> is a WMS >>> >>>>> DescribeLayer request, which would tell you if a layer if >>>>> >>> WFS-able or >>> >>>>> not; if it is, then mark as extractable in your client and chain >>>>> along. >>>>> >>>>> Would this be feasible? >>>>> >>>>> ..Tom >>>>> >>>>> _______________________________________________ >>>>> Context.rwg mailing list >>>>> [EMAIL PROTECTED] >>>>> https://mail.opengeospatial.org/mailman/listinfo/context.rwg >>>>> >>>> _______________________________________________ >>>> Context.rwg mailing list >>>> [EMAIL PROTECTED] >>>> https://mail.opengeospatial.org/mailman/listinfo/context.rwg >>>> >>> _______________________________________________ >>> Context.rwg mailing list >>> [EMAIL PROTECTED] >>> https://mail.opengeospatial.org/mailman/listinfo/context.rwg >>> >>> > > _______________________________________________ > Context.rwg mailing list > [EMAIL PROTECTED] > https://mail.opengeospatial.org/mailman/listinfo/context.rwg > > -- Cameron Shorter Systems Architect, http://lisasoft.com.au Tel: +61 (0)2 8570 5050 Mob: +61 (0)419 142 254 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ mapbuilder-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mapbuilder-devel
