AsGml: Export a Shape as Namespaced XML

I use AsGml when a consumer needs a geometry represented as GML XML. The namespace belongs to that representation. A path using only familiar element names can miss data that are present under the qualified names.

Export two explicit lines

The first LineString passes through three coordinate pairs. The second reverses that sequence. Both use geometry with SRID zero, and both are exported through the same method. AsGml returns an XML value rather than ordinary text.

I keep that XML value in the Exported CTE. The output includes a text serialization for reading and several XML-method results for checking. The conversion to nvarchar(max) happens only in the display column. It doesn’t replace the typed XML used by the other expressions.

WITH Inputs AS
(
 SELECT CaseId, Shape
 FROM (VALUES
  (1,geometry::STGeomFromText('LINESTRING(0 0,0 2,3 0)',0)),
  (2,geometry::STGeomFromText('LINESTRING(3 0,0 2,0 0)',0))
 ) v(CaseId,Shape)
), Exported AS
(
 SELECT CaseId, Shape.AsGml() AS Gml FROM Inputs
)
SELECT CaseId, CAST(Gml AS nvarchar(max)) AS GmlText,
       Gml.value('declare namespace g="http://www.opengis.net/gml";
                  (/g:LineString/g:posList/text())[1]','nvarchar(80)') AS Coordinates,
       Gml.exist('declare namespace g="http://www.opengis.net/gml";
                  /g:LineString/g:posList') AS QualifiedPathFound,
       Gml.exist('/LineString/posList') AS UnqualifiedPathFound
FROM Exported
ORDER BY CaseId;

Read the namespace-qualified path

The exported LineString and posList belong to the GML namespace. The XQuery declares a local prefix g for that namespace URI. It then uses the prefix on both names in the path.

That prefix is a query convenience, not a requirement that the serialized document visibly use the letter g. The namespace URI establishes the element identity. I’d keep that distinction clear when adapting an export. A different chosen prefix can still address the same namespaced XML elements.

Compare the unqualified search

QualifiedPathFound expects true for both rows. UnqualifiedPathFound expects false, even though the serialized output visibly contains LineString and posList. The unqualified path looks for elements in no namespace.

This is a useful check before treating an empty extraction as missing geometry. The data can be present under another qualified name. I’d inspect namespace declarations before changing the source or adding a default coordinate. A failed path doesn’t automatically mean that the exported shape has no positions.

Preserve the coordinate sequence

The first extracted list is zero, zero, zero, two, three, zero. The second starts at three, zero and returns through zero, two to zero, zero. The example preserves each source LineString’s position sequence.

I’d compare the full text and coordinate list for these small fixed inputs. Looking only for one coordinate would miss a reversed or incomplete sequence. The named fields also make the expected check readable. The example doesn’t rely solely on a spatial thumbnail to describe the exported value.

Keep interpretation separate from serialization

The source coordinates are planar example values. Exporting them as GML doesn’t establish physical units or transform the underlying reference system. A receiving application still needs the coordinate contract agreed with the producer.

I’d document that contract alongside an integration format. XML gives the data structure, but the application decides how to interpret the coordinates. A recognizable element name alone doesn’t establish map projection or geographic axis order. This lesson concerns namespaced export and extraction, not a coordinate conversion.

Validate the complete interface

The query creates no tables and makes no writes. CaseId supplies a stable result order, and the original source definitions remain visible. The result includes both full serialized documents and all extraction checks.

I’d preserve typed XML where subsequent XML operations are required. Text is useful at an export boundary, but repeated ad hoc parsing can obscure namespace mistakes. Validate the receiving consumer separately with the agreed format. A successful local extraction doesn’t prove every downstream parser accepts the same contract.

Declare the namespace first, and the coordinates show up where they should.

An empty path result is not missing data, it is a namespace you forgot to declare.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.