Opened 17 years ago
Closed 17 years ago
#1653 closed defect (invalid)
Gdalwarp accuracy variations per CPU type
Reported by: | kaplanski | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | OGR_SRS | Version: | 1.4.1 |
Severity: | normal | Keywords: | |
Cc: |
Description
I was wondering if you could point me in the right direction here.
I've developed a method of inserting georeferenced images from Doug Cox's USA Photomaps application (terra server) to AutoCAD Map 3D. We use DGWARP to convert from UTM to NAD27 State plane. The system consists of a VB application to write the DGWARP batch file and LISP code to automate the image insertion process.
The system works great except that the accuracy of the DGWARP conversion is variable between systems. For example, on a Xeon based PC with 2GB of ram, the converted image inserts into AutoCAD with an error of approx. 5'. On a P4 based system with the same configuration the same image is off by 80'. The systems that it seems to work the best on are 5 year old Xeon based machines. I just tested the process on a brand new Xeon based machine and the error is about 80'.
The -RCS switch has no effect.
How would I be able to predict the accuracy of the DGARP process? In other words, how can I reliably spec a machine that will deliver the 5' accuracy? Are there known specifications for system configurations? Is this a floating point calculation issue?
Thanks
Rick Kaplan Engineering Consulting Services rkaplan@… (703) 810-1319
Attachments (4)
Change History (13)
comment:1 by , 17 years ago
Status: | new → assigned |
---|
by , 17 years ago
Attachment: | ecs_demo.zip added |
---|
by , 17 years ago
Attachment: | Good_conversion.zip added |
---|
by , 17 years ago
Attachment: | bad_conversion.zip added |
---|
by , 17 years ago
Attachment: | results.zip added |
---|
comment:2 by , 17 years ago
Thanks for the quick response.
Attached you will find the files you requested.
ecs_demo.zip USA Photo maps output files: e293950n4314050z18u_USA_Map_Output.jgw e293950n4314050z18u_USA_Map_Output.jpg e293950n4314050z18u_USA_Map_Output.txt
DGWARP call batch file: ecs.bat
Bad_conversions.zip: 194_13024BLD_bad_conversion.tfw 194_13024BLD_bad_conversion.tif
Good_conversion.zip: 556_13024BLD_good_conversion.tfw 556_13024BLD_good_conversion.tif
Results.zip: Screen shots showing the good and bad images inserted below known good vector data.
comment:3 by , 17 years ago
Rick,
I see the warp includes a datum shift. Based on the error you are seeing, and the fact that it is with reprojection, not polynomial warping, I am pretty much convinced that the issue is the datum shift files being found on one system, and not on the other.
Generally speaking, gdalwarp needs to find the "conus" datum shift file to do NAD83->NAD27 datum shifts. One way it looks for this is through the PROJ_LIB environment variable. You can define the PROJ_DEBUG environment variable (to any value) to get extra reporting on attempts to find PROJ support data files.
I'll leave this open till you confirm, but I'm pretty certain this is the issue.
comment:4 by , 17 years ago
Both systems have a "GDAL_DATA" environmental variable set to thier local GDWARP\bin folders which are identical. I'll add a "proj_lib" variable to check it out.
Dosn't GDALWARP usually throw an error if it can't find the datum shift file?
The VB program I wrote to build the batch file references a lookup table to convert the state plane number into a format that GDALWARP understands. Maybe this file is not being read properly.
I'll look into it and get back to you.
Thanks again.
Rick
comment:5 by , 17 years ago
I added the additional "proj_debug" system variable to the system that's doing the bad conversion, but it had no effect.
Both batch files (which are generated by code) are identical, so the lookup table is being read properly.
You may be right that the "conis" file is being read on one system and not the other, but how can we varify that?
Thanks
Rick
comment:6 by , 17 years ago
Rick,
I'm pretty sure PROJ_DEBUG is case sensitive, so if you actually set proj_debug it would likely have no effect. The filename is "conus", not "conis".
It isn't part of GDAL per-se, but rather part of PROJ.4. If it is not found PROJ.4 just proceeds without the datum shift. This is a questionable decision of course....
I'd suggest you search your systems for a file named "conus". Without knowing what build you are using it is hard for me to give advice on where it might be.
comment:7 by , 17 years ago
"conus" is on both systems in the "dgwarp\bin" directory. The system variable was in all upper case.
I'ts unclear why the "conus" file would be found in some systems and not in others, given identical system variables, files and file permissions.
I'll keep digging...
comment:8 by , 17 years ago
OK...
I found the problem! You were right about it not being able to find the conus file.
When I tested the DGWARP batch file on it's own, I didn’t see any errors, but since the DGWARP batch file is called from the AutoCAD shell, the command window is only visible for a split second. I was able to capture it with a video screen capture utility and it revealed that DGWARP was looking in "c:\proj\nad" for the conus file.
Its unclear to me why it wants the bin files there on some machines and not on others, but creating that directory and copying the bin files to it worked.
It's probable that the AutoCAD environment has something to do with this.
Thanks for pointing me in the right direction.
Rick
comment:9 by , 17 years ago
Component: | GDAL_Raster → OGR_SRS |
---|---|
Resolution: | → invalid |
Status: | assigned → closed |
Rick,
I'm pleased this is worked out. If using C:\PROJ\NAD (the build default) is a problem at some point, you can just set PROJ_LIB in the .bat file you create I should imagine.
closing...
Rick,
I'd appreciate a demonstration of the problem you are encountering. At higher orders the polynomial transforming functions are somewhat unstable, and at first, and second order this should not be an issue. The thin plate spline transformer is generally not very predictable.
What I'd like then is a small input file, the command you use to warp it and the "good" and "bad" output of that warp.
Then I'll see what sort of results I get, and try to determine what might be causing variations.
Then perhaps I can try to answer the question with some authority.