#1064 closed defect (fixed)
[raster] transform regress failing on 8.4 windows build
| Reported by: | robe | Owned by: | dustymugs |
|---|---|---|---|
| Priority: | blocker | Milestone: | PostGIS 2.0.0 |
| Component: | raster | Version: | master |
| Keywords: | Cc: |
Description (last modified by )
I'm not sure if its just something changed in my setup or not, but the rt_transform tests are failing on my 8.4 windows builds. What's odd is that they are passing on my 9.0 and 9.1beta2 windows builds.
I though it was maybe because I rebuilt gdal and perhaps my settings were off, but such things usually make all 3 fail.
Anyrate attached is the regress failure.
Attachments (2)
Change History (14)
by , 13 years ago
| Attachment: | pgis_raster_rt_transform_84windows_regress.zip added |
|---|
comment:1 by , 13 years ago
| Owner: | changed from to |
|---|---|
| Priority: | medium → blocker |
| Status: | new → assigned |
comment:2 by , 13 years ago
Can you try r7506? I think I've resolved the issue but can't test as I'm having crazier issues with 8.4.8 in 32-bit linux.
comment:3 by , 13 years ago
still fails at r7509. I've attached the regress just in case its changed.
by , 13 years ago
| Attachment: | pgis_reg_2236_windows8_4_transform_r7509.zip added |
|---|
comment:4 by , 13 years ago
Would you happen to have a postgresql log? Are you able to run PostGIS in debug mode? I'm looking to see if GDAL is throwing a SRS message. Time to finish building my Windows test box.
comment:5 by , 13 years ago
haven't had a chance to check. I can rebuild my mingw with cassert and debug on to get better info, but I was testing against VC++ enterprisedb provided build.
comment:6 by , 13 years ago
The latest regress log is the same as the previous one. I have no idea what I was thinking when mentioning "that one test" as all the tests for st_transform fails. The problem still is that the destination srs isn't being applied/used for some reason. A debug output would be ideal. I'll get my Windows build up and kicking.
comment:7 by , 13 years ago
Have you had the chance to run a debug build of postgis? Is it possible to check your postgresql server's log as it looks like GDAL error messages go to that log file?
Only reason I'm asking is because my Windows test box build is hitting walls. My current wall is the inability to load the postgis-2.0.dll library when trying to load the postgis functions into a database.
comment:8 by , 13 years ago
So, I've basically raised the white flag for compiling my own Windows PostgreSQL with PostGIS. Instead, I installed the prebuilt binaries for PostgreSQL, GDAL and PostGIS (the latest windows experimental for r7518). I ran the queries of the ST_Transform and they look correct to me instead of what you're getting in your logs. So, I have no ideas whats going on.
comment:9 by , 13 years ago
Bborie,
Did you try with the 8.4 binaries. It's only the 8.4 that is failing. The other windows builds are working fine. It could be something really stupid with the way we have our test environment setup.
One thing that makes our test environment different from our general is that our paths point at the mingw for most things but the enterprise db for build for testing. So I haven't ruled out its not just something missing in our mingw 8.4 path that we used to have there before we recompiled gdal. I'll double check to make sure we have the latest dependency files in both places.
comment:10 by , 13 years ago
Yes - if you can't load the postgis-2.0.dll library when loading the PostGIS functions into a database on Windows then that generally means the loader can't find a dependent DLL somewhere. Check that the GEOS, PROJ and libxml DLLs are somewhere not too far away or maybe even use MS's depends.exe to see what else the DLL depends upon.
comment:11 by , 13 years ago
| Description: | modified (diff) |
|---|---|
| Resolution: | → fixed |
| Status: | assigned → closed |
Bborie,
I apologize for the waste of time. I figured out what is different about my 8.4. I had an extra line in my Pg 8.4 database launch script that had:
@SET GDAL_DATA=C:\projects\gdal\rel-trunk\share\gdal
That folder has a bunch of transform csv files. It was alsoo at a time when I rebuilt GDAL so could also be a permission issue with that folder.
and it was giving errors like the below in the log when transform was done ERROR 6: Unable to load PROJ.4 library ("libproj.dll"), creation of OGRCoordinateTransformation failed.
Not sure why that line even matters unless they are proj 4.7 specific files and somehow force proj to override its standard behavior.
Anyrate we didn't have it in our 9.0 and 9.1 pg launch scripts. Once I got rid of that line all worked fine. I'm not sure though what happens if people have that in their global environment variables. They might run into the same issues I suppose as I think PostgreSQL pays attention to environment variables.
comment:12 by , 13 years ago
I have mixed feelings about how this ticket resolved. I'm concerned as you are that other users will have similar configurations thus causing the same problem. Also, I don't ever like not understanding was the problem is. I'm glad that you've found out what was causing the regression failure as that allows me to start figuring out tickets #1061 and #1066, which I have a hunch is the same issue.
Based upon your regression results, that one test is failing as the SRS isn't getting imported. I had this creep up and suspect there is a memory issue (overflow?) going on.