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

[Havard Tveite]

Paragon Corporation wrote:
...
> Did we ever figure out what ST stands for?  I used to know.  I thought it
> stood for Spatial Type.

I have thought that the ST prefix was decided in the early
stages of the SQL/MM work, when the spatial part of the
standard included a temporal object data type.
So the T in ST used to stand for Temporal.

I did a quick search, and found this substantiated in:
http://showusyourcode.spaces.live.com/blog/cns!15630F96CB7D86C1!546.entry?&_c02_owner=1?

Which refers to this paper from 2003:
http://doesen0.informatik.uni-leipzig.de/proceedings/paper/68.pdf
The paper seems to have been presented at the conference:
BTW 2003, Datenbanksysteme für Business, Technologie und Web,
Tagungsband der 10. BTW-Konferenz, 26.-28. Februar 2003, Leipzig.

There is probably more evidence out there...

Håvard Tveite

> 
> Thanks,
> Regina
> 
>  
> 
> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net
> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Havard
> Tveite
> Sent: Monday, April 06, 2009 4:59 AM
> To: PostGIS Development Discussion
> Subject: Re: [postgis-devel] WKT Raster: Back from RT_ to ST_
> 
> I agree with strk, reserve the ST prefix for things that complies with the
> SQL/MM Spatial standard.  The fact that the standard currently is not
> followed in all details by all (commercial) spatial DBMS products, and that
> the standard itself might not be specific enough on some of the details does
> not justify that PostGIS shall add to the confusion!
> Instead of "dismissing" the the standard we should help improve it - we need
> the standard.
> In my opinion, a good open source spatial database management system should
> take standards compliance very seriously.
> Standards compliance has been one of the major "selling points"
> of PostGIS, and standards are very important for the success of open source
> products such as PostGIS!
> 
> We should use other prefixes than ST or no prefixes at all for PostGIS
> specific things.
> 
> Håvard Tveite
> 
> 
> Paragon Corporation wrote:
>> Strk,
>> Your code wouldn't just work anyway.  There is enough variant between 
>> the IBM, MS, Oracle, PostGIS, ArcSDE (dear I mention MySQL here) 
>> versions that the "just work" idea doesn't "just work".  At best you 
>> are talking about portability of knowledge.  It would just "sort of work".
>>
>> For example MS uses camel case so its STIntersects not ST_Intersects.
>> Oracle based on my understanding if you use ST_GeomFromText you get a 
>> generic geometry object, but if you use ST_PolygonFromText you get a 
>> qualified Polygon object with completely different structure. Then 
>> Oracle has this whole ordinate array thing going on. I think IBM comes 
>> closest to being cross compatible with PostGIS but they allow mixed 
>> SRIDs I think and silently convert. Oracle ST_Distance takes unit type 
>> as an arg. So that's why I'm not too too bothered that we use ST_ a little
> more than we should.
>>   
>> The reason I like the overloading idea for RASTER is that if you had 
>> written code to work with PostGIS geometries and later decided you 
>> want it to work with RASTER, I think its an easier exercise if RASTER uses
> the same names.
>> Otherwise you'd have to macro replace the code everywhere.  You'd 
>> probably still need to test and depending on the language rewrite 
>> since the outputs are different, but my feeling is that it's a bit of 
>> an easier task if the names are the same.
>>
>> Thanks,
>> Regina
>>
>>
>>
>>  
>>
>> -----Original Message-----
>> From: postgis-devel-bounces at postgis.refractions.net
>> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of 
>> strk
>> Sent: Friday, April 03, 2009 4:39 AM
>> To: PostGIS Development Discussion
>> Subject: Re: [postgis-devel] WKT Raster: Back from RT_ to ST_
>>
>> On Thu, Apr 02, 2009 at 08:26:38PM -0400, Paragon Corporation wrote:
>>> 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.
>>
>> Actually, I think anyone using postgis-specific things should use the 
>> version with no ST_ prefix. When you use ST_ it's because you're 
>> hoping your code will "just work" with any ISO-compliant thingy.
>>
>> If you're using rasters, and they are not ISO-standard, you should use
>> Intersect() for both rasters and vectors. You know you're talking to 
>> postgis and not a generic ISO standard SF dbms.
>>
>> --strk;
>>
>>  Free GIS & Flash consultant/developer      ()  ASCII Ribbon Campaign
>>  http://foo.keybit.net/~strk/services.html  /\  Keep it simple! 
>> _______________________________________________
>> 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
>>
> 
> --
> Håvard Tveite
> Department of Mathematical Sciences and Technology, UMB Drøbakveien 31,
> POBox 5003, N-1432 Ås, NORWAY
> Phone: +47 64965483 Fax: +47 64965401 http://www.umb.no/imt/
> _______________________________________________
> 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
> 

-- 
Håvard Tveite
Department of Mathematical Sciences and Technology, UMB
Drøbakveien 31, POBox 5003, N-1432 Ås, NORWAY
Phone: +47 64965483 Fax: +47 64965401 http://www.umb.no/imt/