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

Craig Miller craig.miller at spatialminds.com
Thu Sep 23 09:16:44 PDT 2004


I don't have a leg to stand on as I haven't contributed *anything* to
PostGIS yet, but I thought I would put out a viewpoint for people to kick
around.

I am noticing a trend to push more and more middleware functionality down
into PostGIS.  E.g. assvg, asgml, etc.  This sort of functionality appears
to be the responsibility of middleware platforms such as a Web Feature
Server, Web Mapping Server, etc.  Over time, I wouldn't want to see PostGIS
become bloated.

Where does the PostGIS development team see PostGIS ending, and middleware
beginning and why?

Btw... I do expect to give more back than trivial "How to compile on windows
instructions" within the next year, which is why I am curious about the
future direction of PostGIS.

--Craig


-----Original Message-----
From: Paul Ramsey [mailto:pramsey at refractions.net] 
Sent: Thursday, September 23, 2004 6:55 AM
To: PostGIS Development Discussion
Subject: Re: [postgis-users] RE: [postgis-devel] GML output

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

_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel






More information about the postgis-devel mailing list