Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#1667 closed defect (fixed)

[raster] raster regress failures

Reported by: robe Owned by: pracine
Priority: blocker Milestone: PostGIS 2.0.0
Component: raster Version: master
Keywords: Cc:

Description

These I'm getting on beta2 on my regular mingw install I've used to compile the windows 32-bit.

rt_resample, rt_intersects, rt_asraster

I did have to hack the regress make scripts because my old mingw doesn't like the change Paul put in for MingW syntax.

Attachments (1)

raster_beta2_regress_failures.zip (4.3 KB ) - added by robe 13 years ago.

Download all attachments as: .zip

Change History (10)

comment:1 by robe, 13 years ago

Keywords: windows 32-bit mingw345 added
Summary: raster regress failures[raster] raster regress failures

comment:2 by robe, 13 years ago

Looking at these errors — these are the same ones I'm getting on the 64-bit install. Plus I get one more on that. I suspect its your change to favor using EPSG codes instead of the proj4text that is causing the issue.

In that case it's probably just a gdal configuration that I have to put in the path to the data directory (that has all those epsg csv files)? That is a bit annoying since I would have to force people to put in registry entries that could possibly screw up their other GDAL stuff. Wonder if there is a way that we can default the path similar to what we do with the proj directory.

strk - I know what you are thinking — that calls for a GUC, but I think we are too late in the game to be introducing GUCs.

comment:3 by dustymugs, 13 years ago

Based upon the output you're getting, it looks like you're having the same issue that pramsey emailed me about. Try the following on the command line…

gdalsrsinfo.exe EPSG:2163

If you get output like

ERROR 1: ERROR - failed to load SRS definition from EPSG:2163

something is wrong with your GDAL environment. I don't know if pramsey resolved his issue.

comment:4 by pramsey, 13 years ago

You need to ensure the GDAL_DATA environment variable points to the install location of the GDAL support files.

comment:5 by robe, 13 years ago

hmm. That didn't work for me. I had put in:

export GDAL_DATA="/c/gdal/gdal-data"

Which has the path to my gdal data files. I copied temasz settigns more or less. Maybe something funky with using unix slashes for that. I'll try outside next.

My issue with weird messages with testapi can't find l this and that seemed to have disappeared though.

comment:6 by robe, 13 years ago

Ah nevermind. Stupid me. I forgot it has to be in my postgres environment and I was adding it to my compile script. so adding it to my postgres start up script and restarting it fixed the issue and all tests pass now.

I guess we need to document this somewhere. The only concern I have (as a package manager) is how we can set this up without screwing other people's gdal settings. I hate adding path settings to people's servers that could adversely affect other apps they are running.

comment:7 by pracine, 13 years ago

I added a note about setting GDAL_DATA in the new ticket about the readme (#1649). That's it? Ready to close?

comment:8 by robe, 13 years ago

Resolution: fixed
Status: newclosed

comment:9 by robe, 13 years ago

Keywords: windows 32-bit mingw345 removed
Note: See TracTickets for help on using tickets.