No worries. I compiled a recent version of raster2pgsql just to check, but got the same issue:
$ raster2pgsql RELEASE: 3.5.0 GDAL_VERSION=36 (d2c3ca4) Just to reiterate: When using raster2pgsql I get 'WARNING'..: WARNING: Raster with different alignment found in the set of rasters being converted to PostGIS raster and 'NOTICE' after the ANALYZE is run: NOTICE: Adding SRID constraint NOTICE: Adding scale-X constraint NOTICE: Adding scale-Y constraint NOTICE: Adding blocksize-X constraint NOTICE: Adding blocksize-Y constraint NOTICE: Adding alignment constraint NOTICE: The rasters (pixel corner coordinates) are not aligned NOTICE: Unable to add constraint: enforce_same_alignment_rast NOTICE: SQL used for failed constraint: ALTER TABLE public.merge_raster2pgsql ADD CONSTRAINT enforce_same_alignment_rast CHECK (st_samealignment(rast, '0100000000000000000000494000000000000049C00000000050B3FCC0000000C02246584100000000000000000000000000000000E964000001000100'::raster)) NOTICE: Returned error message: check constraint "enforce_same_alignment_rast" of relation "merge_raster2pgsql" is violated by some row (23514) WARNING: Unable to add constraint: 'same_alignment'. Skipping NOTICE: Adding number of bands constraint NOTICE: Adding pixel type constraint NOTICE: Adding nodata value constraint NOTICE: Adding out-of-database constraint NOTICE: Adding maximum extent constraint This does not occur when I make a virtual raster (vrt) with gdalbuildvrt, and use that as input to raster2pgsql; no warning or notices, and the data looks good in QGIS. Best, Andreas On Sun, Dec 15, 2024 at 12:35 AM Regina Obe <l...@pcorp.us> wrote: > Sorry haven’t had a chance to look thru this yet. Going to be tied up for > the next two weeks so I might not get a chance until much later. > > > > If any others are interested in investigating, please don’t wait for me. > > > > Thanks, > > Regina > > > > *From:* Andreas B <pan...@gmail.com> > *Sent:* Friday, December 13, 2024 6:48 AM > *To:* postgis-users@lists.osgeo.org > *Subject:* Re: Importing tiles with raster2pgsql > > > > Regina, > > > > I'm linking to a folder with a zip containing a subset of tiles that > demonstrates my problem, a script to run the commands, and two screenshots. > Note that I'm a PostGIS beginner, so it's possible I'm doing something > wrong! > > The issues encountered differs a bit from what I described yesterday, but > the essence is the same. > > > > Link to folder: > https://www.dropbox.com/scl/fo/bk8cwktahry0oj0ab2rsz/AHdTD73unb4Efxtgf7exfm0?rlkey=esjtw2iyzysan2hdqklwmj5e3&st=hupv5tsr&dl=0 > > > > Best, > > Andreas > > > > On Thu, Dec 12, 2024 at 3:26 PM Regina Obe <l...@pcorp.us> wrote: > > Andreas, > > > > Yes I would expect them to give the same result. > > > > What version of raster2pgsql are you running? It should tell you if you > run raster2pgsql without any args. > > > > Also what platform are you on? Any chance you have some of those tiles > available so we can check it out? > > > > *From:* Andreas B <pan...@gmail.com> > *Sent:* Thursday, December 12, 2024 6:17 AM > *To:* postgis-users@lists.osgeo.org > *Subject:* Importing tiles with raster2pgsql > > > > Hi all, > > I have a dataset with several hundred tiles (GeoTIFFs) that make up a > digital terrain model. > Each tile is 0.5d x 0.5d. > > I tried to load these GeoTIFFs to PostGIS with: > > $ raster2pgsql -s 32631 -I -M -F -C -t auto -d -l 2,4,8,16,32 tif/*.tif (1) > > The data was loaded, but when viewing in QGIS, it looked like jagged lines > with areas of white overlain by pieces of neighboring tiles, etc. > This didn't look right. > I also noticed that for each tif, the constraints were printed. > I expected this to be done once, after the last tile was loaded. > > I then created a virtual raster with gdalbuildvrt: > > $ gdalbuildvrt merge.vrt tif/*.tif (2) > > And then used raster2pgsql to load in the vrt: > > $ raster2pgsql -s 32631 -I -M -F -C -t auto -d -l 2,4,8,16,32 merge.vrt | > psql (3) > > The data was loaded, and looked good in QGIS. > > Shouldn't commands (1) and (3) give the same results, or am I > misunderstanding? > > Best, Andreas > >
