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

[strk at refractions.net]

On Thu, Sep 23, 2004 at 12:33:26PM +0100, Martin Daly wrote:
> strk,
> 
> > Questions for GML users/hackers:
> > 1) Is that output correct ? For which versions ?
> 
> That is GML 2.x.  gml:coordinates has been deprecated in GML 3.x, but is
> probably more widely supported at the moment than its replacement.

Ok. We'll stick to GML 2.x only for now.

> I would recommend using the "gml:" namespace prefix on all elements, and
> adding an srsName="EPSG:xxxx" attribute to the gml:Point, gml:LineString
> and gml:Polygon elements.

If think output size is a concern.
Can't both namespace and srsName be written in a parent element ?

> 
> > 2) How would you output multi-types ?
> 
> Using gml:MultiPoint, gml:MultiLineString and gml:MultiPolygon (with
> srsName="EPSG:xxxx" only on the outer element).

Ok. cool.

> 
> > 3) How would you output geometry-collections ?
> 
> Using gml:MultiGeometry (with srsName="EPSG:xxxx" only on the outer
> element).

Do you think postgis should 'flatten' nested collections 
or keep them as they are ?

> 
> Users will have to bear in mind that you are only generating the
> geometry of a GML feature.  Other properties will presumably come from
> other columns in the table.  An XML schema will also have to be created
> so that other GML parsers can determine the structure.
> 
> Also see http://gdal.velocet.ca/projects/gml/gml_interop.html for Frank
> Warmerdam's Practical GML Interoperability tips.  I quote:
> 
> "This page purports to supply some rules of thumb that GML producers
> should follow if they want to maximize the number of software packages
> that will be able to read and recover data from the GML they produce. It
> isn't intended to constrain all GML applications, only those interested
> achieving the greatest degree of interoperability with other software
> packages."
> 
> Regards,
> Martin

Thanks a lot,
--strk;