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)

ecs_demo.zip (58.2 KB ) - added by kaplanski 17 years ago.
Good_conversion.zip (686.7 KB ) - added by kaplanski 17 years ago.
bad_conversion.zip (687.3 KB ) - added by kaplanski 17 years ago.
results.zip (949.1 KB ) - added by kaplanski 17 years ago.

Change History (13)

comment:1 by warmerdam, 17 years ago

Status: newassigned

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.

by kaplanski, 17 years ago

Attachment: ecs_demo.zip added

by kaplanski, 17 years ago

Attachment: Good_conversion.zip added

by kaplanski, 17 years ago

Attachment: bad_conversion.zip added

by kaplanski, 17 years ago

Attachment: results.zip added

comment:2 by kaplanski, 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 warmerdam, 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 kaplanski, 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 kaplanski, 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 warmerdam, 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 kaplanski, 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 kaplanski, 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 warmerdam, 17 years ago

Component: GDAL_RasterOGR_SRS
Resolution: invalid
Status: assignedclosed

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...

Note: See TracTickets for help on using tickets.