[postgis-devel] Public/Private API, ST_*/_ST_*

[Obe, Regina]

On the topic of stuff that shouldn't be exposed.  I always thought the
geom operators cast to box checks.  So what are these things used for?
They seem to call different lwgeom functions than the box ones do.

st_geometry_above
st_geometry_analyze
st_geometry_below
st_geometry_cmp
st_geometry_contain
st_geometry_contained
st_geometry_eq
st_geometry_ge
st_geometry_gt
st_geometry_in
st_geometry_le
st_geometry_left
st_geometry_lt
st_geometry_out
st_geometry_overabove
st_geometry_overbelow
st_geometry_overlap
st_geometry_overleft
st_geometry_overright
st_geometry_recv
st_geometry_right
st_geometry_same
st_geometry_send 

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Obe,
Regina
Sent: Tuesday, January 20, 2009 6:56 AM
To: PostGIS Development Discussion
Subject: RE: [postgis-devel] Public/Private API, ST_*/_ST_*

Yes agreed.  I'll accept if they need to be renamed but then again if
I'm going to depend on them, and you consider them just glue code now
that is a more serious problem.  Just thought I'd bring it up as a
potential issue and somewhat grey area in that they have great use apart
from their intended.

If we are adding stuff to the list that hmm should be hidden - here is a
few that come to mind if Paul hasn't thought about them already (I can't
think of why I would ever use these directly instead of their
operator/other forms)

st_create_histogram2d (do we even do these things by hand anymore?)
st_histogram2d_in
st_histogram2d_out
st_box2d_contain
st_box2d_contained
st_box2d_in
st_box2d_intersects
st_box2d_left
st_box2d_out
st_box2d_overlap
st_box2d_overleft
st_box2d_overright
st_box2d_right
st_box2d_same
st_box3d
st_box3d
st_box3d_in
st_box3d_out
st_chip_in
st_chip_out
st_spheroid_in
st_spheroid_out


I would prefer you leave my friends alone though :).

Thanks,
Regina
 

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Mark
Cave-Ayland
Sent: Tuesday, January 20, 2009 4:41 AM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Public/Private API, ST_*/_ST_*

Obe, Regina wrote:

> Well actually I should elaborate.  If you are building your own 
> aggregate functions or doing something like
> 
> SELECT ST_Unite_garray(ARRAY(SELECT the_geom FROM foo))
> FROM foo2
> 
> Is often times much more efficient than using ST_Union.  Aside from
you 
> can't easily use ST_Union with something like the above.

I think it would make sense if Paul posts a complete list of changes for

comment before committing anything to SVN. Then we can work out which 
functions will cause issues if they are renamed, and decide on a 
suitable course of action.


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel
-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel