QGIS » QGIS Application

When the user makes a query to a CSW server using the current map extent as a bounding box, the resulting gml:Envelope XML element lacks the srsName attribute, therefore leaving room for interpretation by the catalogue server.

Metasearch creates a bounding box with a list of coordinates that are:

• lower_left_x
• lower_left_y
• upper_right_x
• upper_right_y

which results in an XML fragment like:

<ogc:BBOX>
    <ogc:PropertyName>ows:BoundingBox</ogc:PropertyName>
        <gml:Envelope>
            <gml:lowerCorner>lower_left_x lower_left_y</gml:lowerCorner>
            <gml:upperCorner>upper_right_x upper_right_y</gml:upperCorner>
        </gml:Envelope>
</ogc:BBOX>

Due to the nature of GML, since the resulting XML element does not specify a coordinate reference system, it is up to the catalogue that is being queried to decide what CRS to use and how to interpret the values in the bounding box.

A pycsw catalogue will default to interpret the gml:Envelope using the CRS specified by urn:x-ogc:def:crs:EPSG:6.11:4326. This CRS definition specifies that coordinates are to be intepreted as YX (lat lon) and not as XY (lon lat). This means that the bounding box specified in QGIS is not interpreted correctly by a pycsw server.

This problem is specially relevant for areas over Asia, that are above 90º longitude because they cause the server to not find any records, as it thinks the client is requesting a bbox that is beyond 90º latitude.

Possible solutions:

• Include the srsName attribute in the gml:Envelope element with a CRS that specifies XY as its axis order - This is the preferred solution, as it should work on any CSW server. It eliminates the need for the server to have to resort to some nonstandard default CRS.
• Switch the coordinate pairs in the gml:lowerCorner and gml:upperCorner elements so that they are YX by default - This is an easier fix that will make metasearch work OK against a pycsw server. However, it may break it for other CSW implementations.