>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@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@postgis.refractions.net >>> http://postgis.refractions.net/mailman/listinfo/postgis-users >>> >> >> -- >> Bborie Park >> Programmer >> Center for Vectorborne Diseases >> UC Davis >> 530-752-8380 >> bkp...@ucdavis.edu >> _______________________________________________ >> postgis-users mailing list >> postgis-users@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 bkp...@ucdavis.edu _______________________________________________ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
