[postgis-devel] WKT Raster: Back from RT_ to ST_

[Paragon Corporation]

Yap ST_ thingy should have been left for only ISO stuff.  Right now I feel
sort of torn since the damage has already been done; seems like a lot of
effort to correct the wrong.  Maybe we can revisit in 2.0.

I do like the idea of overloading ST for raster though, but I think Paul was
dead set against the idea because it would break OGC compatibility.

I fail to see why it would break OGC compatibility.  To me OGC talks only
about the function signature ST_Intersection(geometry, geometry)

It says nothing about other types what they should do.  So to me
ST_Intersection(geometry,raster) defines something outside the space of what
OGC defines.  It just happens to have the same name. Like if a restaurant
says "No dogs" and you bring in a "horse" is that in violation.  The law
didn't say "no pets".

I mean if we go with that thinking I don't think OGC defines
ST_Union(geometry) aggregate so aren't we already in violation if we have
that thinking.

Thanks,
Regina
 

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Mark
Leslie
Sent: Thursday, April 02, 2009 7:25 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] WKT Raster: Back from RT_ to ST_

strk wrote:
> On Thu, Apr 02, 2009 at 10:47:36AM -0700, Kevin Neufeld wrote:
>> Pierre Racine wrote:
>>  > One of the argument against was that ST_ stands for "standard" (is 
>> this
>>> right?) and that (surely) none of WKT Raster is standard. But many
>>> (most?) PostGIS function are also not standard and they nevertheless 
>>> have the ST_ prefix.
>>>
>> I thought ST_ stood for "Spatial Type" ... or was it "Super 
>> Terrific"? :)
> 
> Whatever it stands for, I belive it was dictated by ISO.
> Postgis hackers liked it and used for non-ISO-specified things too, 
> which I've never been very comfortable with.
> 
> In my opinion the 'ST_' thingy should have only been 'aliases' for ISO 
> compatibility, keeping unprefixed names for everything (going up to a 
> schema, if it was for namespacing).

This actually makes the most sense when you consider that there are inherent
incompatibilities between the definitions of some few ISO, SF/SQL and
postgis specific functions (asBinary for example).
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel