[postgis-devel] Not receiving SRID conflict error

[Bborie Park]

Now, if you don't have a spatial index, the spatial index test (&&) does
not run and all values are passed to the "internal" _st_intersects()

On Fri, Jan 16, 2015 at 8:58 AM, Bborie Park <dustymugs at gmail.com> wrote:

> The first SELECT only uses the spatial index check (&&) and returns false.
>
> The second SELECT uses ST_Intersects() (which makes use of the spatial
> index first) and also returns false.
>
> The code for ST_Intersects(geom, raster) is...
>
> CREATE OR REPLACE FUNCTION st_intersects(geom geometry, rast raster, nband
> integer DEFAULT NULL)
> RETURNS boolean AS
> $$ SELECT $1 && $2::geometry AND _st_intersects($1, $2, $3); $$
> LANGUAGE 'sql' IMMUTABLE
> COST 1000;
>
> Because the input geometry and raster fail the spatial index test (&&),
> the "internal" _st_intersects() function never receives any data where the
> SRID check is done.
>
>
> On Fri, Jan 16, 2015 at 8:52 AM, David Haynes II <dahaynes at umn.edu> wrote:
>
>> Sorry, I am not understanding what is happening can you explain?
>>
>> On Fri, Jan 16, 2015 at 10:18 AM, Bborie Park <dustymugs at gmail.com>
>> wrote:
>>
>>> Yes, the following explains it.
>>>
>>> SELECT 'SRID=4269;POINT(-1 -1)'::geometry &&
>>> ST_AddBand(ST_MakeEmptyRaster(2, 2, 0, 0, 1, -1, 0, 0, 4326), 1, '16BUI',
>>> 1, 0)
>>>
>>> and
>>>
>>> SELECT ST_Intersects('SRID=4269;POINT(-1 -1)'::geometry,
>>> ST_AddBand(ST_MakeEmptyRaster(2, 2, 0, 0, 1, -1, 0, 0, 4326), 1, '16BUI',
>>> 1, 0))
>>>
>>>
>>> On Fri, Jan 16, 2015 at 8:14 AM, Bborie Park <dustymugs at gmail.com>
>>> wrote:
>>>
>>>> Do you have a spatial index on IGBP_2012?
>>>>
>>>> The only thing I can think of is that dasymetric.us_dem_prj has a
>>>> spatial index and since ST_Intersects() uses the spatial index first, there
>>>> is no rows to consider in ST_Intersects and ST_Clip.
>>>>
>>>> -bborie
>>>>
>>>> On Fri, Jan 16, 2015 at 7:56 AM, David Haynes II <dahaynes at umn.edu>
>>>> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I have a question about an error I am not receiving when I believe I
>>>>> should.
>>>>>
>>>>> Below are three datasets that with their SRID
>>>>> igbp_2012 (6842), us_dem_prj (3410), and us_states (4326).
>>>>>
>>>>> When I run a query determining the SRID for these datasets in
>>>>> PostgreSQL they confirm their SRIDs
>>>>> select st_srid(r.rast), st_srid(p.geom) from dasymetric.us_dem_prj r,
>>>>> dasymetric.us_states p limit 5
>>>>>
>>>>> When I run the next query, I do not receive an error, but no records
>>>>> are returned. The raster is in 3410 and the states geom column is in 4326
>>>>> SELECT state_label, ST_Clip(r.rast,p.geom) as rast FROM
>>>>> dasymetric.us_states p inner join dasymetric.us_dem_prj r on
>>>>> ST_Intersects(p.geom, r.rast) WHERE p.state_label = 'Minnesota'
>>>>>
>>>>> However, If I adjust the raster dataset to IGBP_2012, the error
>>>>> ERROR: Raster and geometry do not have the same SRID, shows up.
>>>>>
>>>>> Why am I not receiving a conflict projection error for a raster in
>>>>> 3410 and a geometry in 4326? Any idea why that is occurring?
>>>>>
>>>>> --
>>>>> David Haynes, Ph.D.
>>>>> Research Associate Terra Populus
>>>>> Minnesota Population Center
>>>>> www.terrapop.org
>>>>>
>>>>> _______________________________________________
>>>>> postgis-devel mailing list
>>>>> postgis-devel at lists.osgeo.org
>>>>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel
>>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel at lists.osgeo.org
>>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel
>>>
>>
>>
>>
>> --
>> David Haynes, Ph.D.
>> Research Associate Terra Populus
>> Minnesota Population Center
>> www.terrapop.org
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at lists.osgeo.org
>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20150116/974f5ff9/attachment.html>