ST_AsGML: optionally output LineString.posList rather than Curve.segments.LineStringSegments.posList

[strk]

Add an option to select LineString.posList output instead of Curve.segments.LineString for LINESTRING geometries in GML3.

[strk]

Since we're at it... did anyone consider changing the GML output routines to return XML rather than text ? See ​http://www.postgresql.org/docs/8.3/interactive/functions-xml.html

[colivier]

PostgreSQL are not always compiled with libxml, so keeping text are a good idea IMO. But yes why not adding also XML output.

What kind of use case do you see ?

[strk]

None, as the XML type is still new to me. Was just an idea to make it clear what we were outputting. But if libxml is not guaranteed to be there it's a better choice to keep text. Can probably easily be casted to XML anyway.

[strk]

Uhm, I've found the use case:

SELECT xmlelement(name traffic_sign, 
                  xmlforest(feature_name),
                  topology.asgml(feature)
                  )
 FROM features.traffic_signs 
 WHERE feature_name = 'S1';

The xmlelement call encodes the xml tags brackets in output:

 <land_parcel><feature_name>S1</feature_name>&lt;gml:TopoPoint&gt;&lt;gml:directedNode&gt;&lt;gml:Node gml:id="N14"&gt;&lt;gml:pointProperty&gt;&lt;gml:Point srsName="urn:ogc:def:crs:EPSG::4326"&gt;&lt;gml:pos srsDimension="2"&gt;21 14&lt;/gml:pos&gt;&lt;/gml:Point&gt;&lt;/gml:pointProperty&gt;&lt;/gml:Node&gt;&lt;/gml:directedNode&gt;&lt;/gml:TopoPoint&gt;</land_parcel>

[strk]

Oh, but the cast trick works fine:

SELECT xmlelement(name traffic_sign, 
                  xmlforest(feature_name),
                  topology.asgml(feature)::xml
                  )
 FROM features.traffic_signs 
 WHERE feature_name = 'S1';

... sorry, I'm feeling a trac spammer now :/

[strk]

For the record, coliver wrote:

You're right LineString is shorter and is still valid in 3.1.1 I think that the reason to use Curve was that we didn't knows few years ago, that LineString were still available in GML 3. In ST_GeomFromGML both are allowed. I agree to #816 to allow the users to choose beetween the two.

[strk]

Done with r6852. cunit, sql regress and dox.