#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)
Change History (10)
by , 13 years ago
Attachment: | raster_beta2_regress_failures.zip added |
---|
comment:1 by , 13 years ago
Keywords: | windows 32-bit mingw345 added |
---|---|
Summary: | raster regress failures → [raster] raster regress failures |
comment:2 by , 13 years ago
comment:3 by , 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 , 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 , 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 , 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 , 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 , 13 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:9 by , 13 years ago
Keywords: | windows 32-bit mingw345 removed |
---|
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.