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

Darko Androsevic dandrosevic at galdosinc.com
Thu Sep 23 15:16:31 PDT 2004


The namespace prefix is arbitrary--it could be "tns". What's essential
is that the prefix is bound to the correct namespace:

<tns:Polygon xmlns:tns="http://www.opengis.net/gml">
...
</tns:Polygon>



We would recommend that even if you only support the geometry types defined
in GML 2.x (Simple Features Model), you should still use GML 3.x
representations with no deprecated parts. GML 2.x is history.


Cheers,
Darko



-----Original Message-----
From: postgis-users-bounces at postgis.refractions.net
[mailto:postgis-users-bounces at postgis.refractions.net]On Behalf Of
strk at refractions.net
Sent: Thursday, September 23, 2004 8:16 AM
To: Martin Daly
Cc: Frank Warmerdam; PostGIS Development Discussion; Paul Ramsey;
PostGIS Users Discussion
Subject: Re: [postgis-users] RE: [postgis-devel] GML output


Ok. I've added gml: prefix, srsName on outer element and
support for multitypes and collections.

The srsName is omitted if SRID=-1.

GeometryCollection are not flattened, srsName is appended only once
in outmost tag, please let me know if you find this an annoying
approximation (might check for difference from parent srsName...).

Coordinates support is 2d,3d and 4d (are them all supported by GML?)
Coordinate values format is by default 15 significant digits, but
can be lowered providing a second argument. Scientific notation
will be used when appropriate (is this supported by GML?).

That's all folks!

--strk;


On Thu, Sep 23, 2004 at 02:05:19PM +0100, 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-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
_______________________________________________
postgis-users mailing list
postgis-users at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users






More information about the postgis-users mailing list