> -----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. > 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? > --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 > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ mapbuilder-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mapbuilder-devel
