wfs_service parameters is redundant

[tylermitchell@…]

In this layer def: 
 
LAYER 
    GROUP testing 
    NAME wfs_test 
    STATUS ON 
    TYPE POINT 
    CONNECTIONTYPE WFS 
    CONNECTION "http://map.ns.ec.gc.ca/envdat/map.aspx?" 
    LABELITEM "envdat:Station_ID" 
    CLASS 
      STYLE 
        OUTLINECOLOR 150 150 0 
        COLOR 250 250 0 
      END 
      LABEL 
        SIZE SMALL 
        COLOR 255 255 255 
        POSITION UR 
      END    
    END 
    METADATA 
      "wfs_srs" "EPSG:4326" 
      "wfs_version" "1.0.0" 
      "wfs_typename" "envirodat" 
      "wfs_request_method" "GET" 
    END 
  END 
 
I get an error: 
msBuildWFSLayerGetURL(): WFS connection error. Metadata wfs_service must be set 
in the layare <br> 
 
I understand the need for the wfs_Service parameter, but this is inconsistent 
with the WMS implementation.  I assume in the WMS implementation it infers 
wfs_service=WMS from the layer's connectiontype.  It would be nice to have it 
infer it here as well. 
 
(should I log the "layare" typo too? :)

[bartvde@…]

Hey Tyler,

you're right that it is redundant. Service is only mandatory for the
GetCapabilities request, since this is shared between WMS and WFS.

Mapserver WFS client only does a GetFeature request, which is only in the WFS
spec and does not need the service keyword. It is vendor specific.

This is related to bug 1262. Mapserver always needs the service parameter to
distinguish between WMS and WFS (if service is omitted for a GetFeature request
it defaults to WMS), but this is not according to spec.

So but the keyword is needed until the related WFS server part is fixed.

Bart

[dmorissette]

I have fixed the typo.

With respect to the wfs_service metadata, I would agree with Tyler that it seems
redundant (and useless). Assefa, can you remember why this was added? It seems
to me that since the CONNECTIONTYPE is WFS, it is implied that the service that
we connect to has to be WFS as well. Can it be anything else? If yes then if the
value is not set we should at least default to WFS.

[assefa]

looking into this and bug 1262.

[assefa]

Not sure why the wfs_service was necessary. It certainly can be deduced from 
the connectiontype. There is no other possible value than WFS.

Here are the changes that I propose :
   * ignore the wfs_service metadata and always set the service parameter to 
WFS 
   * update the doc to depricate usage of wfs_service

 Note : the problem decribed initally by Tyler only happens when generating a 
wfs request using the Get methid. The xml encoded post method always set the 
service to WFS.

If no comments I will do the changes. 

[dmorissette]

I agree with removing the wfs_service metadata.

With respect to docs, since we are removing/ignoring the parameter completely
this is more than just deprecating, so I would simply delete it from the docs
without any special mention.

[assefa]

Fixed according to comment #4.

Assign to Jeff for documentation update

[jmckenna@…]

removed all wfs_service metadata references.  already live on umn site.  Also
created a restructuredtext version of the wfs-client doc (my first attempt with
reST) at http://ms.gis.umn.edu:8081/ms_plone/docs/howto/wfs_client

also tested a mapfile without the wfs_service metadata, works nicely