[postgis-devel] Spatial relationship functions

Paul Ramsey pramsey at opengeo.org
Fri Jul 20 15:31:44 PDT 2012


My understanding is that relationship(rast, vect) functions do a
vectorization and then run the relationship, which strikes me as a
silly thing to spend development time on when the
relationship(vectorize(rast), vect) option is right at hand. I think
working on more pure raster functionality would be great.

P.

On Fri, Jul 20, 2012 at 2:04 PM, Bborie Park <bkpark at ucdavis.edu> wrote:
> 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
>
>
> _______________________________________________
> 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