id summary reporter owner description type status priority milestone component version severity resolution keywords cc 6435 AutoCreateWarpedVRT function creates incorrect VRT Dataset georges tamas "I noticed different behavior between gdal.AutoCreateWarpedVRT function from gdal_csharp.dll and gdalwarp command ran from command prompt. VRT dataset created with gdal.AutoCreateWarpedVRT function definitely outputs incorrect values, while those from gdalwarp are correct. I am using Rhino5 application to generate a 3d mesh of the SRTM .tif topography model of Vesuvius. The .tif file is originally in WGS84 spatial reference system. What i do is create a new .tif file with projected reference system which uses Azimuthal Equidistant projection. a) If I use the following gdalwarp command: {{{ C:/gdalwin32-1.4.1/bin/gdalwarp.exe -s_srs EPSG:4326 -t_srs ""+proj=aeqd +lat_0=40.81266 +lon_0=14.414252 +datum=WGS84 +units=m +no_defs"" C:/vesuvius_wgs84.tif C:/vesuvius_aeqd.tif }}} And then open the new ""vesuvius_aeqd.tif"" file in Rhino5 application, everything is correct, and [https://www.dropbox.com/s/gr0r1bbin6osl30/vesuvius_gdalwarp.jpg?dl=0/ 3d mesh representation of the .tif file looks like this]. b) However when I try to do the same thing, but with gdal C# libraries by calling the following functions through Rhino5 ironpython interpreter: {{{ ... sourceSRS = osrc.SpatialReference("""") sourceSRS.ImportFromEPSG(4326) num, datasetsourceSRS = inputCRS.ExportToWkt() targetSRS = osrc.SpatialReference("""") targetSRS.ImportFromProj4(""+proj=aeqd +lat_0=40.81266 +lon_0=14.414252 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs"") num, datasetOutputSRS = outputSRS.ExportToWkt() datasetWarped = gdal.AutoCreateWarpedVRT(dataset, datasetsourceSRS, datasetOutputSRS, gdal.ResampleAlg.GRA_NearestNeighbour, 0) ... }}} [https://www.dropbox.com/s/on7sl66nce1cajt/vesuvius_AutoCreateWarpedVRT.jpg?dl=0/ this is what I get]. I also tried to replace the ''ImportFromProj4'' function with ''SetFromUserInput'' function, and I still get the upper incorrect result. Looks like for some reason the AutoCreateWarpedVRT function creates an incorrect VRT dataset. Just to mention that if I use EPSG codes, then the newly created VRT dataset is valid, and looks the same as the one generated with gdalwarp command. For example, if I use the EPSG:32633, instead of the upper one which uses Azimuthal Equidistant projection: {{{ ... targetSRS.ImportFromEPSG(32633) ... }}} in that case, the AutoCreateWarpedVRT function creates a correct VRT dataset, the same one that gdalwarp would create with: {{{ C:/gdalwin32-1.4.1/bin/gdalwarp.exe -s_srs EPSG:4326 -t_srs EPSG:32633 C:/vesuvius_wgs84.tif C:/vesuvius_32633.tif }}} So something is definitely wrong with the way AutoCreateWarpedVRT function uses Azimuthal Equidistant projection. The .tif file with WGS84 SRS can be [https://www.dropbox.com/s/3pbwtxg54rnvnqd/vesuvius2_wgs84.tif?dl=0/ downloaded from here]: Just to mention that the [https://www.google.rs/maps/place/40%C2%B048'45.6%22N+14%C2%B024'51.3%22E/@40.8054039,14.3671706,12z/data=!4m2!3m1!1s0x0:0x0?hl=en/ 40.81266, 14.414252] coordinates which appear in upper PROJ4 string, represent the center of the raster. To call the gdalwarp from the command prompt, I am using [http://download.osgeo.org/gdal/win32/1.4.1/ gdal 1.4.1]. As for the C# gdal libraries, I am using the ones from the release_1500_gdal_1.11.1_mapserver_6.4.1 as these were the last ones which supported Windows XP (I am currently using Windows XP SP3 and dotNET Framework 4.0). I would welcome any kind of reply on this issue. Thank you." defect closed normal CSharpBindings 1.11.1 normal invalid AutoCreateWarpedVRT, gdalwarp