Hi,

It looks that at the moment this GetCapabilities is not valid:
http://194.66.252.155/cgi-bin/BGS_OGE_Bedrock_and_Surface_Geology_in2/ows?service=WFS&request=GetCapabilities&version=1.1.0


The WFS 1.1.0 schema contains
<xsd:choice>
<xsd:sequence>
<xsd:element name="DefaultSRS" type="xsd:anyURI"/>
<xsd:element name="OtherSRS" type="xsd:anyURI"
minOccurs="0" maxOccurs="unbounded">
</xsd:sequence>
<xsd:element name="NoSRS">
<xsd:complexType/>
</xsd:element>
</xsd:choice>

So, there must be either DefaultSRS or then NoSRS advertised, and with 
DefaultSRS optionally a list of OtherSRS.
Standard says that if srsname is not included in the request then the 
DefaultSRS is used, and that is advertised in the OtherSRS list must be 
supported. However, it does not say what should happen if request contains an 
unknown srsname (SRSNAME=UGH:00). Somehow I would like to see an error message 
but your Mapserver selects to use the default SRS. Here is part of the standard:

"The optional srsName attribute of the <Query> element is used to specify a 
specific WFS-supported SRS to be used for returned feature geometries. Its 
value may be the <DefaultSRS> or any of the <OtherSRS> values listed for the 
feature type in WFS capabilities document. If no srsName value is supplied, 
then the features shall be returned using the advertised <DefaultSRS> value. 
This attribute has no meaning for feature types with no spatial properties; if 
an srsName value is specified for a feature with no spatial properties, a web 
feature service may ignore the parameter and its value.
Any valid URI value can be assigned to the srsName attribute. However, in order 
to enhance interoperability, a web feature service must be able to process 
srsName attribute values with the following format models..."

I suggest to go on with testing and make a bug report if you can confirm with a 
reproducible way that DefaultSRS is missing.


-Jukka Rahkonen-


Passmore, James H. wrote:

> Hi Jukka,

> Thanks for persevering with this.

> OK, so, the issue is not that I'm not using a shapefile (I'm using an OGR 
> connection to an ESRI Geodatabase), or per se that I specified a list of SRS 
> (the documentation shows a WFS_SRS list), but it is to do with the first 
> cited SRS in the list.

> So this original WEB METADATA "OWS_SRS" "CRS:84 EPSG:27700 EPSG:3034 
> EPSG:4258 EPSG:4326" fails

> but his works (that is the error message in the GetCapabilities goes away)

> WEB METADATA "OWS_SRS" "EPSG:4326 CRS:84 EPSG:27700 EPSG:3034 EPSG:4258"

> with no need to specify an OWS/WFS LAYER METADATA section.

> So the error message occurs when an unrecognized SRS is specified first.

> As I understand it the processing precedence (assuming everything is 
> otherwise correct) is:

> MAP.WEB.METADATA.WFS_SRS (if this doesn't exist then check next) 
> MAP.WEB.METADATA.OWS_SRS (if this doesn't exist then check next) 
> MAP.PROJECTION (if this doesn't exist then check for the Feature) 
> LAYER.METADATA.WFS_SRS LAYER.METADATA.OWS_SRS LAYER.PROJECTION

> If none then you get error:

<!--
WARNING: Mandatory mapfile parameter: (at least one of) MAP.PROJECTION, 
LAYER.PROJECTION or wfs/ows_srs metadata was missing in this context.
-->

> There does appear to be a different processing precedence if there is some 
> issue with the SRS, in such a situation you get:

> MAP.WEB.METADATA.WFS_SRS (if this has error then check next) 
> MAP.WEB.METADATA.OWS_SRS (if this has error then check for the Feature) 
> LAYER.METADATA.WFS_SRS  (if this has error then check next) 
> LAYER.METADATA.OWS_SRS

> If there is still an error/issue you get the same (now misleading) message:

<!--
WARNING: Mandatory mapfile parameter: (at least one of) MAP.PROJECTION, 
LAYER.PROJECTION or wfs/ows_srs metadata was missing in this context.
-->

> I say misleading because MAP.PROJECTION, LAYER.PROJECTION are set here 
> (EPSG:4326) but are ignored.  It is further misleading because ows_srs 
> metadata is also set.


> As I stated the service was working even with the warning in place (I think 
> QGIS must just assume CRS:84 support because it isn't reported) e.g. this 
> request 'works':

> http://194.66.252.155/cgi-bin/BGS_OGE_Bedrock_and_Surface_Geology_in2/ows?SERVICE=WFS&VERSION=1.0.0&REQUEST=GetFeature&TYPENAME=GE.GeologicFault.BGS.EN.1M.Bedrock&SRSNAME=CRS:84

> Really I am surprised that MapServer has been able to serve the request at 
> all, but looking closer I see that I haven't got a CRS:84 response at all, 
> what I have is an EPSG:4326 response, in fact I can specify any unrecognized 
> SRSNAME and I get an EPSG:4326 response

> For example:

> http://194.66.252.155/cgi-bin/BGS_OGE_Bedrock_and_Surface_Geology_in2/ows?SERVICE=WFS&VERSION=1.0.0&REQUEST=GetFeature&TYPENAME=GE.GeologicFault.BGS.EN.1M.Bedrock&SRSNAME=UGH:00.

> To me it looks like in the background MapServer must look at MAP.PROJECTION 
> or LAYER.PROJECTION despite the error message, or else it must assume 
> EPSG:4326 as a default.

Cheers

James







This message (and any attachments) is for the recipient only. NERC is subject 
to the Freedom of Information Act 2000 and the contents of this email and any 
reply you make may be disclosed by NERC unless it is exempt from release under 
the Act. Any material supplied to NERC may be stored in an electronic records 
management system.
_______________________________________________
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Reply via email to