[postgis-users] raster extent and performance problem... anyone?

[Bborie Park]

>From the testing I've done (http://trac.osgeo.org/postgis/ticket/1808)
where I test pixel for pixel what is stored in PostGIS raster versus
what GDAL sees in the source raster, I can't find anything wrong.  But,
only time will tell.

-bborie

On 08/23/2012 04:53 PM, William Kyngesburye wrote:
> 1.9.1 - yes, I saw your discussion about GDAL problems.  Maybe the rounding bug has something to do with it, but even when no bounding box is used from GDAL (like when I just want to query what the extent is of the whole raster), I get the wrong extents and horrible performance.
> 
> I'd like to at least verify that the PostGIS raster is OK first.  GDAL dev is not really a good option since I need to deploy the extraction scripts on a few computers very soon, and it's best if I can use a packaged distribution.
> 
> The vrt of the original geotiffs works, so that's what I'll probably be using.
> 
> On Aug 23, 2012, at 1:37 PM, Bborie Park wrote:
> 
>> What version of GDAL are you using?  Could you try GDAL trunk?  I don't
>> trust anything other than trunk (1.9.x or below) due to various bugs.
>> At some point, I'll dig into the PostGIS raster driver...
>>
>> -bborie
>>
>> On 08/23/2012 07:01 AM, William Kyngesburye wrote:
>>> almost forgot: PostGIS 2.0.1, on PG 9.1.4.  PPC OS X.
>>>
>>> On Aug 23, 2012, at 8:46 AM, William Kyngesburye wrote:
>>>
>>>> I created a raster table for a large area of DEM data, with index and constraints, no overviews.  When I run gdalinfo on the table, it takes about 15m to query to get the extents, which are then wrong.
>>>>
>>>> Original 32bit float geotiffs = 27GiB (uncompressed), 84W, 36N to 71W, 45.5N (not complete coverage)
>>>>
>>>> In PostGIS = 25GiB, 74W, 33.5N to 61W, 43N
>>>>
>>>> There are 15936 records in the table, which matches the number of input TIFFs and the tile size I used (actually 22 more than the input), so it looks like all the data was imported.
>>>>
>>>> It looks like the data was shifted 10 deg east and 2.5 deg south.
>>>>
>>>> When I try to extract a region from that with gdal_translate, it takes the 15m to check the extants again, then extracts garbage.
>>>>
>>>> I'm just getting started with PG rasters and don't know enough about the SQL needed to check within PG if everything is OK there or not (extents, extract some data to tif) or if it's a GDAL problem.
>>>>
>>>> A GDAL vrt of the geotiffs processes quickly and reports the correct extents.
>>>>
>>>> -----
>>>> William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
>>>> http://www.kyngchaos.com/
>>>>
>>>> "Time is an illusion - lunchtime doubly so."
>>>>
>>>> - Ford Prefect
>>>>
>>>> _______________________________________________
>>>> postgis-users mailing list
>>>> postgis-users at postgis.refractions.net
>>>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>>
>>> -----
>>> William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
>>> http://www.kyngchaos.com/
>>>
>>> "I ache, therefore I am.  Or in my case - I am, therefore I ache."
>>>
>>> - Marvin
>>>
>>>
>>> _______________________________________________
>>> postgis-users mailing list
>>> postgis-users at postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>>
>>
>> -- 
>> Bborie Park
>> Programmer
>> Center for Vectorborne Diseases
>> UC Davis
>> 530-752-8380
>> bkpark at ucdavis.edu
>> _______________________________________________
>> postgis-users mailing list
>> postgis-users at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
> 
> -----
> William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
> http://www.kyngchaos.com/
> 
> All generalizations are dangerous, even this one.
> 
> 
> 

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