Opened 16 years ago
Closed 15 years ago
#2063 closed defect (fixed)
exporting ArcSDE raster results in a displaced image
Reported by: | dcarreira | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | 1.5.4 |
Component: | GDAL_Raster | Version: | 1.5.0 betas/RCs |
Severity: | normal | Keywords: | gdal, arcsde, raster |
Cc: |
Description
Using FWTools 1.3.9 with gdal_SDE_92.dll plugin, and exporting a window from an ArcSDE raster results in an image that is displaced from the original.
Example command:
gdal_translate -of JPEG -co WORLDFILE=YES -projwin 271212 148107 271512
147857 SDE:<sdeserver>,5151,database,<user>,<passwd>,<user>.rasterdataset testgdal.jpg
In this particular example the image was 64 pixels displaced to south.
Other tests resulted in other displacements that I could not relate.
The world file generated was the following:
0.4000000000
0.0000000000
0.0000000000
-0.4000000000
271212.2000000000
148107.0000000000
When it should have been:
0.4000000000
0.0000000000
0.0000000000
-0.4000000000
271212.2000000000
148132.600000000
The properties of this particular ArcSDE system and data are the following:
ArcSDE 9.2 SP3, on Oracle 9.2 (remote box)
Description of raster given by sderaster -o describe command:
ArcSDE 9.2 for Oracle9i Build 1173 Thu May 31 12:02:22 2007
Raster Layer Description ....: <None>
Table Name ..................: <owner>.<raster datasetname>
Raster Column ...............: RASTER
Raster Layer ID .............: 313
Minimum Raster ID ...........: 1
Creation Date ...............: Fri Nov 30 17:45:58 2007
User Privileges .............: SELECT, INSERT, DELETE, UPDATE
Raster Layer Configuration ..: MOSAICO
Storage Type ................: DEFAULT
Coordinate System ...........: PROJCS["Datum_73_Hayford_Gauss_IGeoE",GEOGCS["GCS
_Datum_73",DATUM["D_Datum_73",SPHEROID["International_1924",6378388.0,297.0]],PR
IMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Transverse_
Mercator"],PARAMETER["False_Easting",200180.598],PARAMETER["False_Northing",2999
13.01],PARAMETER["Central_Meridian",-8.131906111111112],PARAMETER["Scale_Factor"
,1.0],PARAMETER["Latitude_Of_Origin",39.66666666666666],UNIT["Meter",1.0]]
Description of raster given by sderaster -o list -verbose command:
ArcSDE 9.2 for Oracle9i Build 1173 Thu May 31 12:02:22 2007
Raster ID ...................: 1
Raster Dimension ............: 300000, 275250+64, 3
Raster Tile Dimension .......: 128, 128
Pixel Type ..................: uchar
Compression .................: jpeg
Image Pyramid ...............: 9, false, bilinear
Extent ......................:
minx : 175050.20000000001000
miny : 99950.19999999999700
maxx : 295049.79999999999000
maxy : 210049.80000000002000
Cell Size....................:
x : 0.40000000000000
y : 0.40000000000000
Statistics ..................: <NONE>
Could not get an answer from gdalinfo (took too long).
Change History (7)
comment:1 by , 16 years ago
Milestone: | → 1.5.0 |
---|
comment:3 by , 16 years ago
Milestone: | 1.5.0 → 1.5.1 |
---|
I think this fix may have gotten it, but the ArcSDE driver needs some reworking to support such large images. Pushing this forward to 1.5.1
comment:4 by , 15 years ago
This change is causing problems for me. The cell size of the grid is not correct anymore because of:
// adjust the bbox based on the tile origin. //dfMinX = MIN(x0, dfMinX); //dfMaxY = MAX(y0, dfMaxY);
which causes shifts in the grid in my situation.
See also:
http://lists.osgeo.org/pipermail/gdal-dev/2009-October/022519.html
comment:5 by , 15 years ago
Okay, I got it to work by also adjusting dfMaxY and dfMinY (I've verified the raster is now displayed in the correct position using Mapserver):
// we also need to adjust dfMaxX and dfMinY otherwise the cell size will change dfMaxX = (x0-dfMinX) + dfMaxX; dfMinY = (y0-dfMaxY) + dfMinY; // adjust the bbox based on the tile origin. dfMinX = MIN(x0, dfMinX); dfMaxY = MAX(y0, dfMaxY);
Duarte figured out that the data is being loaded with offsets: