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

Paragon Corporation lr at pcorp.us
Mon Apr 6 04:54:11 PDT 2009 

Havard,

Good point.  I guess I'm somewhat indifferent to this at this point though
I'm still more for the use of ST_ since I feel in the raster case they have
the same meaning as the geometry context.  If OGC had a standard for RASTER
then they would probably want ST_ since MM is for multi-media.  So if people
really feel strongly either way they should bring it up.  To throw out the
use of ST_ for things not strictly defined in the spec would mean we can’t
use it in

ST_Union(geometry[]) and possibly ST_Union(aggregate)

I'm more bothered by the fact that different spatial databases don't output
same results for  standard function signatures for things that are covered
by the standard  than I am about the overuse of ST.  

The main issue I see with the overuse of ST is that it does give people the
illusion that those things are standard compliant so fuzzies things a bit,
but to me this has NOTHING to do with violation of standard.  If a person
can read the OGC standard spec and limit themselves to what the standard
says within the context of PostGIS, then I think we are following the
standard.

Then on the pro side having to remember what functions have ST and which
don't does give one a bit of a headache when you are just trying to get
something done.  So to me as long as we are clear about what functions are
standards compliant and if they are not fully how they deviate from the
standard, that is the most important thing.  I think we more or less did
that in the docs -- though could require more rework detailing caveats such
as MM vs non-MM and OGC stance on 3D etc.

http://postgis.refractions.net/documentation/manual-svn/ch08.html#PostGIS_SQ
LMM_Functions

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

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

More information about the postgis-devel mailing list