[raster] raster2pgsql doesn't work with windows network paths or quoted paths

[robe]

Leo ran into 2 problems using raster2pgsql

He has a batch script that looks something like this

ECHO ON

SET IMGDIR="K:\Product\*.jpg"

SET PGDATABASE=somedb
SET PGUSER=postgres
SET PGPORT=5432
SET PGHOST=localhost
SET PGPASSWORD=somepassword
SET PATH=%PATH%;C:\Program Files\PostgreSQL\9.2\bin\

raster2pgsql -F %IMGDIR% x2 | psql

In order for the above to work — he had to take out the "" and also put in a K: to get it to the drive

ECHO ON

SET IMGDIR=K:\Products\*.jpg

SET PGDATABASE=somedb
SET PGUSER=postgres
SET PGPORT=5432
SET PGHOST=localhost
SET PGPASSWORD=somepassword
SET PATH=%PATH%;C:\Program Files\PostgreSQL\9.2\bin\

K:
raster2pgsql -F %IMGDIR% x2 | psql

What he had originally tried just went in a loop and complained invalid command

ECHO ON

SET IMGDIR="\\FServer\Products\*.jpg"

SET PGDATABASE=somedb
SET PGUSER=postgres
SET PGPORT=5432
SET PGHOST=localhost
SET PGPASSWORD=somepassword
SET PATH=%PATH%;C:\Program Files\PostgreSQL\9.2\bin\

raster2pgsql -F %IMGDIR% x2 | psql

I'm guessing the
is tripping it up in some way and maybe making it think its an in memory object or something.

This is using GDAL 1.10.0, latest PostGIS 2.1.0beta3dev on 9.2 64-bit on windows 2008.

I'm honestly not sure if there is much we can do about this aside from putting in Raster FAQ

[Bborie Park]

Let me test this on my windows setups and a network drive. Windows BAT script… ew.

[Bborie Park]

I just tested raster2pgsql.exe directly from PostGIS 2.1.0beta3dev 64-bit on Windows 7 with the following:

c:\ming64\projects\pgx64\pg92\bin>raster2pgsql.exe "\\vmware-host\Shared Folders\dustymugs\Documents\raster\testraster.tif"

No problems with that. Possibly a batch script issue?

[robe]

Did you try with wild card? I think single might have worked okay though I thought we had tried that too with unc but perhaps not.

[Bborie Park]

I have now tried a wildcard on three tif files…

c:\ming64\projects\pgx64\pg92\bin>raster2pgsql.exe "\\vmware-host\Shared Folders\dustymugs\Documents\raster\temp\*.tif"

No problems there either.

[robe]

Damn — okay maybe it has to do with batch script or I had an older version of raster2pgsql on server that had a bug.

You wouldn't mind swallowing your pride and try using a batch script . I'll understood if you say "No, that's where I draw the line"

[Bborie Park]

Tried the following in a batch file…

ECHO ON
SET PATH=%PATH%;C:\ming64\projects\pgx64\pg92\bin
SET IMGDIR="\\vmware-host\Shared Folders\dustymugs\Documents\raster\temp\*.tif"

raster2pgsql %IMGDIR%

No problems…

[robe]

okay I'll retry again with latest binaries. I think the binaries he was using were a couple of months old.

Other difference is the 1) yours is missing the psql pipe call directly 2) the fact we were running under the pg92edb\bin instead of just mingw (so perhaps it was picking up some other dependency distributed by edb). 3) You also don't have a -F flag inn yours

Could it be the -F. We always run with -F.

[Bborie Park]

Ok. Tried the following

ECHO ON

SET PATH=%PATH%;C:\ming64\projects\pgx64\pg92\bin
SET IMGDIR="\\vmware-host\Shared Folders\dustymugs\Documents\raster\temp\*.tif"

raster2pgsql -F %IMGDIR% foobar > foobar.sql

Output is

C:\Users\dustymugs\Desktop>raster2pgsql -F "\\vmware-host\Shared Folders\dustymugs\Documents\raster\temp\*.tif" foobar  1>foobar.sql
Processing 1/3: \\vmware-host\Shared Folders\dustymugs\Documents\raster\temp\TMEAN-20100101.tif
Processing 2/3: \\vmware-host\Shared Folders\dustymugs\Documents\raster\temp\TMEAN-20100102.tif
Processing 3/3: \\vmware-host\Shared Folders\dustymugs\Documents\raster\temp\TMEAN-20100103.tif

Works for me. The SQL looks good too. The raster2pgsql version is 2.1.0beta3dev r11540

[robe]

Bborie,

I'm going to close this out for now as a can't reproduce until I find the files Leo was testing with and the server. If it is still an issue it could be a very isolated one cause by the fact that Leo names all his servers with single letters.

So I think the one he had issue with was called S resulting in \\S\something\something.

anyrate no point spending any more time on this since it doesn't appear to be as big of an issue as I had originally thought.