[postgis-users] RE: [postgis-devel] GML output

[Paul Ramsey]

I am tempted to do the minimum, asgml() is a convencience method, so the 
  end developer does not have to parse postgis outputs and then turn 
around and write gml. Presumably our gml will always be wrapped inside 
someone else's feature collection. (Unless we go whole hogg, and write a 
function that takes a tuple collection and turns it into a valid gml 
feature collection...) Why shouldn't we expect the user to wrap our gml 
objects in valid xmlns and srid information?

Martin Daly wrote:
> strk,
> 
> 
>>If think output size is a concern.
> 
> 
> Then don't use XML..., or gzip the output.  XML parsers can typically
> cope with gzip, or at least be modified to.
> 
> 
>>Can't both namespace and srsName be written in a parent element ?
> 
> 
> There are all sorts of ways to cope with namespaces, but for maximum
> interoperability and transparency, I'd use gml: each time.  Our
> (Cadcorp's) GML exporter puts the srsName= on the gml:Point,
> gml:LineString, gml:Polygon, and gml:Multi-s, not on any of their
> members (from memory it is even allowed on gml:coordinates).  That
> seemed a reasonable compromise between just on the FeatureCollection,
> and everywhere.
> 
> 
>>Do you think postgis should 'flatten' nested collections 
>>or keep them as they are ?
> 
> 
> Flattening is annoying for systems that support the complex types - the
> other properties are duplicated, or are wrong if pre-calculated, e.g.
> area, etc. - but unavoidable to support systems that only support simple
> types.  Not a choice I'm keen to make for you, I'm afraid.  You might
> also find systems that support a single geometry type per
> FeatureCollection, like with shapefile, but I guess a WHERE clause could
> take care of that.
> 
> Regards,
> Martin
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel