[postgis-devel] Spatial relationship functions

[Bborie Park]

Is it too late to remove those specific ST_Intersects variants from
trunk (2.1)?

I do like the idea of getting rid of the raster,geometry and
geometry,raster combos though.

-bborie

PS: I'm CCing the postgis-devel mailing list...

On 07/20/2012 01:52 PM, Paragon Corporation wrote:
> Bborie,
> 
> 
> I'm almost tempted to say to not bother with raster,geometry at all or at
> least wait off.
> 
> 
> I actually think it would cause more problems if you implement it.  Can we
> leave those out and just have 
> 
> ST_Contains(raster, raster)
> 
> 
> I know it's too late for ST_Intersects.  I just feel asking the question
> ST_Contains(raster,geometry)
> 
> Is bordering on the same kind of ambiguity as asking
> 
> ST_Contains(geometry,geography)
> 
> 
> I just assume force people to be explicit with how they expect the operation
> to happen and adds more cluttering functions
> To confuse people which they should use.
> 
> I've added Paul to the cc since I figure he is more opinionated on this
> topic than I am :).
> 
> It's probably good to just voice these concerns
> In PostGIS Dev anyway, though I seem to not be getting my dev mail lately.
> 
> Thanks,
> Regina
> 
> 
> 
> 
> -----Original Message-----
> From: Bborie Park [mailto:bkpark at ucdavis.edu] 
> Sent: Friday, July 20, 2012 3:46 PM
> To: Paragon Corporation; Pierre Racine
> Subject: Spatial relationship functions
> 
> Hey you two,
> 
> I'm working my way through the various raster/raster and raster/geometry
> spatial relationship functions and have hit a problem.
> 
> I'm working on ST_Contains(rast, geom) and ST_Contains(geom, rast) and
> realized that if I followed convention where the first parameter dictates
> how the two parameters are treated (as geometries or as rasters), things go
> bad quickly.  So, I'm wondering if I can get rid of that convention
> entirely.
> 
> I'm thinking that any spatial relationship function with one of the
> parameters being a raster should treat the other parameter as a raster.
>  So, the following three variants would all treat parameters as rasters for
> the test.
> 
> ST_SomeSpatialRelationshipTest(raster, raster)
> 
> ST_SomeSpatialRelationshipTest(raster, geometry)
> 
> ST_SomeSpatialRelationshipTest(geometry, raster)
> 
> If a user needs a spatial relationship test done treating parameters as
> geometries, they should use...
> 
> ST_SomeSpatialRelationshipTest(geometry, ST_Polygon(raster))
> 
> ST_SomeSpatialRelationshipTest(ST_Polygon(raster), geometry)
> 
> ST_SomeSpatialRelationshipTest(ST_Polygon(raster), ST_Polygon(raster))
> 
> Thoughts?  Sadly, I was the one to introduce this "order dictates how the
> parameters are treated" convention... *sigh*.  Not enough forethought on my
> part.
> 
> -bborie
> 
> --
> Bborie Park
> Programmer
> Center for Vectorborne Diseases
> UC Davis
> 530-752-8380
> bkpark at ucdavis.edu
> 
> 
> 
> 

-- 
Bborie Park
Programmer
Center for Vectorborne Diseases
UC Davis
530-752-8380
bkpark at ucdavis.edu