Opened 16 years ago
Closed 13 years ago
#906 closed defect (fixed)
GETCAPABILITIES and DESCRIBESCHEMA with WFS does not match
Reported by: | ksgeograf | Owned by: | |
---|---|---|---|
Priority: | low | Milestone: | 2.4 |
Component: | WFS Interface | Version: | 2.1.0 |
Severity: | trivial | Keywords: | |
Cc: | External ID: |
Description
When issuing the "GETCAPABILITIES" call for WFS on MapGuide, the following fragment is part of the response: <FeatureType> <Name>ns180401301:BuildingOutlines</Name> <Title>Building Outlines</Title> <Abstract>Building Outlines.</Abstract> <Keyword>Buildings, Outlines</Keyword> <SRS>EPSG:4326</SRS> <LatLongBoundingBox minx="-87.74" miny="43.68" maxx="-87.69" maxy="43.815"/> </FeatureType>
The name is set to be "ns180401301:BuildingOutlines", where the prefix is some random number to prevent name clashes, I presume.
When issuing the the "DESCRIBEFEATURETYPE" call for the above type, this fragment is part of the response: <xs:schema xmlns:xs="..." xmlns:fdo="..." xmlns:gml="..." xmlns:SHP_Schema="..." elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="BuildingOutlines"
type="SHP_Schema:BuildingOutlinesType" abstract="false" substitutionGroup="gml:_Feature">
<xs:key name="BuildingOutlinesKey">
<xs:selector xpath=".//BuildingOutlines"/> <xs:field xpath="Autogenerated_SDF_ID"/>
</xs:key>
</xs:element>
In the response, the name is now missing the prefix. Also, the prefixed namespace is not listed in the "GETCAPABILITIES" response.
Change History (4)
comment:1 by , 15 years ago
comment:3 by , 13 years ago
Milestone: | → 2.4 |
---|
comment:4 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
The same namespace in the GETCAPABILITIES response is now also found in the DESCRIBEFEATURETYPE response instead of SHP_Schema
Again, unlikely that this has changed. If still a problem with 2.1, please update the version #.