> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Cameron Shorter > Sent: 08 September, 2007 7:34 AM > To: Joshua Lieberman > Cc: [EMAIL PROTECTED]; > [email protected] > Subject: Re: [Mapbuilder-devel] [Context.RWG] Associating WMS > and WFS in thesame layer > > 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?
e.g. - invoke http://example.org/wms?service=WMS&version=1.1.1&request=DescribeLayer&l ayers=obs - if WMS_DescribeLayerResponse/LayerDescription/@owsType eq "WFS" - pick up WMS_DescribeLayerResponse/LayerDescription/@owsURL and WMS_DescribeLayerResponse/LayerDescription/Query/@typeName and invoke a GetFeature request > 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. > True. The hack above makes assumptions without checking some info (i.e. version, etc.). How about if we make the Server/@service attribute repeatable, so, for example we could have: <Layer queryable="0" hidden="0" group="Layers"> <ows:Title>hydro</ows:Title> <ows:Abstract>hydro</ows:Abstract> <ows:Identifier>hydro</ows:Identifier> <ows:OutputFormat>image/gif</ows:OutputFormat> <ows:OutputFormat>image/png</ows:OutputFormat> <ows:OutputFormat>image/jpeg</ows:OutputFormat> <ows:AvailableCRS>EPSG:4326</ows:AvailableCRS> <Server service="OGC:WMS" service="OGC:WFS" version="1.1.1" title="Boston on Oracle"> <OnlineResource xlink:type="simple" xlink:href="http://webservices.ionicsoft.com/ionicweb/wfs/BOSTON_ORA"/> </Server> Of course this would make @version questionable. Or we could always make Server itself repeatable. > 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 > ------------------------------------------------------------------------- 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
