Opened 12 years ago

Closed 12 years ago

Last modified 12 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 12 years ago.

Download all attachments as: .zip

Change History (10)

comment:1 by robe, 12 years ago

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

comment:2 by robe, 12 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 Bborie Park, 12 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, 12 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, 12 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, 12 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, 12 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, 12 years ago

Resolution: fixed
Status: newclosed

comment:9 by robe, 12 years ago

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