1

Re: WFS -v- SOAP services

Hi,

A question came up yesterday at the NBN Technical Idea’s Exchange regarding the use of WFS services alongside the existing SOAP services that are provided.

I put the question to one of our web developers here who works with our WMS/WFS services and his response is below,

“As far as I'm aware they should be able to do this quite easily. If they can get all the data into one table then it's easy, else they will need to define a database view that spans all the needed tables (as far as I know WFS is table or view based rather than a SQL statement). I'd suggest that they look at geoserver to try this out, this will allow them to implement an XML schema to define what is sent back to the client and how the XML looks (it's also very easy to install and run as it comes as a pre-packaged java WAR). Also, WFS doesn't actually care about any of the data it accesses except for the geometry columns so providing it can see the metadata it will return it.”


Hope this helps,

Regards,

Gavin.

2

Re: WFS -v- SOAP services

I don't have any experience of Web Feature Services but from a user's perspective I would aniticipate that this should work so long as the service can be easily consumed (e.g. using SOAP?) or integrated directly into a web-based GIS system (e.g. MapServer). If this is the case, then this should make life easier for us users :)

(ePlanning Project Manager) Aberdeenshire Council

3

Re: WFS -v- SOAP services

Hi Gavin,

Thanks for that - it sort of matches my understanding.

However I might debate how easy this would be - the data can not be got into a flat file I don't think (certainly not until after the query has been performed), and the parameters sent as part of a web request query are extensive and I'm not sure how these could be sent as part of a WFS request.

The gateway response currently contains structured data - which could be exploded out to add attributes to a WFS response as a flat table I suppose - but thsi would significantly increase teh size of the response - this was one of the things that was moved away from in v2 of the webservices to improve perfomance.

The complex that the security / resolution constraints apply to querying the data means that WFS could only be generated after the gateway had undertaken its searches.

Issues I can see:

1) How to pass all the range of parameters required to the gateway as part of a WFS query (includes gateway logons - to asses what data you are allowed access to, species of interest, date ranges, datsets to use etc etc - I assume the geographical element would be replaced by the BBOX part of the WFS query).  Can they all be passed as part of the query filter of WFS

2) WFS data coming back would have to use attributes that flatten the standard gateway response thereby increasing it potentially very significantly in size.


Given that most of the data being returned is attribute data - not spatial data - I am still interested in how people intend to use this - over to SNH

Best wishes
James

4

Re: WFS -v- SOAP services

Hi,

good meeting, too many things to talk about though.

Anyway, to businness.  As James says, the response can potentially be represented in one table, but the underlying data cannot.  The source data can only be accessed via our businness logic which does up to 4 spatial queries across layers and unions the results.  So I suspect the only way of acheiving wfs is to do a transformation on the results to the wfs standard - as was suggested in the meeting.  So an intermediate server comes to mind, which would also deal with transforming the request (assuming wfs can be used to provide all the parameters). But this does seem a bit messy and probably not too fast.

Just as James has mentioned, I too am curious about how big the response will grow if each row is a feature.  At present the geometry is represented once in the schema and records link back to them - I don't know if wfs also does this.

A final point is that it would make sense if a wms was set up to allow data exploration before any wfs data was called back, so that features were only streamed back once they were needed.  Although, there are issues there too to do with creating meaningful maps in areas rich in species records and also how to give data suppliers due credit.

I'm sure a pilot project would answer these questions.

Regards, Jon

5

Re: WFS -v- SOAP services

Hi Jon,

Been thinking a bit more about this - and think I could dummy up an intermediate server solution for at least the basics with a few hours work - may give it a go if I get a chance

I was thinking of:
- intercepting the WMS/WFS request to intermediate server
- collecting the range of query parameters from the call
- perhaps using the layers parameter to specify one species per layer ?
- passing the correct call to gateway ws
- extracting results to flat table
- feed back via WMS/WFS

I'd probably use mapserver as the engine to provide the WMS/WFS return for ease of development

Think a basic version of this would not be too complex to implement - if I have a bit of time I may have a look - this approach would hit WMS/WFS as the same time

My concerns really are how slow it would be - I don't think the intermediate server would add much delay - but it could be 10-30 seconds plus whilst the data comes back from the gateway ws - and of course all queries would be using user defined polygons as WMS/WFS uses bounding box to specify area of interest.

Any suggestions / improvements ?

Best wishes
James