Building GDAL with eVC++ 4.0

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Building GDAL with eVC++ 4.0

Mateusz Loskot
Hi,

I'm trying to build (and port if necessary) GDAL
using Microsoft eMbedded Visual C++ 4.0 compiler.
It is a kind of better Visual C++ 6.0 compiler, so it
supports some of new C++ features.
So, I'd like to ask a few question:
1)Has anybody built GDAL with eVC++ 4.0?
2)Is there any documentation for CPL?

Greets
--
Mateusz Łoskot
mateusz at loskot dot net

_______________________________________________
Gdal-dev mailing list
[hidden email]
http://xserve.flids.com/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Building GDAL with eVC++ 4.0

Andrey Kiselev
On Mon, May 30, 2005 at 11:21:01AM +0200, Mateusz Łoskot wrote:
> I'm trying to build (and port if necessary) GDAL using Microsoft
> eMbedded Visual C++ 4.0 compiler. It is a kind of better Visual C++
> 6.0 compiler, so it supports some of new C++ features. So, I'd like to
> ask a few question:
> 1)Has anybody built GDAL with eVC++ 4.0?
> 2)Is there any documentation for CPL?

Mateusz,

It is not easy task to compile GDAL with the Embedded VC (but it is
possible, I am sure). The main problem is that we do not have a way to
automatically determine the embedded modification of the VC compiler. Of
course, we can use a special option in the nmake.opt file, but this is
not implemented yet. The main work is in proper header guards placement.

The problem is not in GDAL only, all supporting libraries (libtiff,
libjpeg, libpng, zlib, proj4) should be revised too.

Regards,
Andrey

--
Andrey V. Kiselev
Home phone:  +7 812 5970603  ICQ# 26871517
_______________________________________________
Gdal-dev mailing list
[hidden email]
http://xserve.flids.com/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Building GDAL with eVC++ 4.0

Mateusz Loskot
Andrey Kiselev napisał(a):

> On Mon, May 30, 2005 at 11:21:01AM +0200, Mateusz Łoskot wrote:
>
>>I'm trying to build (and port if necessary) GDAL using Microsoft
>>eMbedded Visual C++ 4.0 compiler. It is a kind of better Visual C++
>>6.0 compiler, so it supports some of new C++ features. So, I'd like to
>>ask a few question:
>>1)Has anybody built GDAL with eVC++ 4.0?
>>2)Is there any documentation for CPL?
>
>
> Mateusz,
>
> It is not easy task to compile GDAL with the Embedded VC (but it is
> possible, I am sure).

I belive it is possible :-)

 > The main problem is that we do not have a way to
> automatically determine the embedded modification of the VC compiler. Of
> course, we can use a special option in the nmake.opt file, but this is
> not implemented yet. The main work is in proper header guards placement.

I don't think that main problem is with the compiler determination.
For now, I see there are some libraries/files missed in C standard
library used by eVC++. But it is also possible to work wih this.

eVC++ IDE prvides similar BAT file as "big" Visual Studi to reconfigure
build environment (INCLUDE/LINK path, etc.)

What do you mean as "heade guards placement"?

> The problem is not in GDAL only, all supporting libraries (libtiff,
> libjpeg, libpng, zlib, proj4) should be revised too.

Yes, you are right. But i do not want to use/have libtiff/libjpeg/libpng
in my GDAL (OGR) for Windows CE.
I do only need Vector support.
But proj4 is needed.

Greets


--
Mateusz Łoskot
mateusz at loskot dot net

_______________________________________________
Gdal-dev mailing list
[hidden email]
http://xserve.flids.com/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Re: Building GDAL with eVC++ 4.0

Andrey Kiselev
On Mon, May 30, 2005 at 11:02:55PM +0200, Mateusz Łoskot wrote:
> I don't think that main problem is with the compiler determination.
> For now, I see there are some libraries/files missed in C standard
> library used by eVC++. But it is also possible to work wih this.
>
> eVC++ IDE prvides similar BAT file as "big" Visual Studi to
> reconfigure build environment (INCLUDE/LINK path, etc.)
>
> What do you mean as "heade guards placement"?

Guards are the special preprocessor definitions used to enable/disable
compilation of the various program blocks. For example, look at the
cpl_port.h module, it contains constructions like

#ifdef HAVE_LOCALE_H
#  include <locale.h>
#endif

HAVE_LOCALE_H guard is defined in the cpl_config.h file. We can define a
symbol for Embedded VC in nmake.opt and use it as a guard in the various
modules to include the right headers. The first candidates are
cpl_port.h and cpl_vsisimple.cpp. That symbol will be manually enabled
in nmake.opt when appropriate.

Regards,
Andrey

--
Andrey V. Kiselev
Home phone:  +7 812 5970603  ICQ# 26871517
_______________________________________________
Gdal-dev mailing list
[hidden email]
http://xserve.flids.com/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Re: Building GDAL with eVC++ 4.0

Mateusz Loskot
Andrey Kiselev napisał(a):

>> On Mon, May 30, 2005 at 11:02:55PM +0200, Mateusz Łoskot wrote:
>>
>
>>>>I don't think that main problem is with the compiler determination.
>>>>For now, I see there are some libraries/files missed in C standard
>>>>library used by eVC++. But it is also possible to work wih this.
>>>>
>>>>eVC++ IDE prvides similar BAT file as "big" Visual Studi to
>>>>reconfigure build environment (INCLUDE/LINK path, etc.)
>>>>
>>>>What do you mean as "heade guards placement"?
>
>>
>> Guards are the special preprocessor definitions used to enable/disable
>> compilation of the various program blocks. For example, look at the
>> cpl_port.h module, it contains constructions like
>>
>> #ifdef HAVE_LOCALE_H
>> #  include <locale.h>
>> #endif


Certainly, I know that technique but the name "guard" strange for me.


>> HAVE_LOCALE_H guard is defined in the cpl_config.h file.
> We can define a
>> symbol for Embedded VC in nmake.opt and use it
> as a guard in the various
>> modules to include the right headers. The first candidates are
>> cpl_port.h and cpl_vsisimple.cpp.
>> That symbol will be manually enabled
>> in nmake.opt when appropriate.


evc++ supports nmake build system. Certainly, there are some features
in "big" Windows (and "big" namke system) not supported byt Pocket PC
SDK. I've created makefile.evc and I'm trying to go with this but it is
not enough solution. So, I will try to work with nmake.opt and other
files you are talking about. Today I will dig into this job.

Thank you for your help.

--
Mateusz Łoskot, mateusz (at) loskot (dot) net
Registered Linux User #220771, Debian (Sarge)
_______________________________________________
Gdal-dev mailing list
[hidden email]
http://xserve.flids.com/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Re: Building GDAL with eVC++ 4.0

Mateusz Loskot
In reply to this post by Mateusz Loskot
Kana, David napisał(a):
> Hi Mateusz, what kind of vector support do you need? I have ported GDAL to
> eVC++ 3.0 with Gtiff and Jpeg including necessary OGR support. If you are
> interested i can send you eVC++ project.
>

Hi David,

Some time ago, I started with my own Open GIS geometry
implementation and now I'm going to go on with my project
and implement new features.
Some days ago I found OGR as a very nice tool and
I tought I could replace my own OGC geometries with
OGR, then I could also get SRS support, etc.

So, the first requirement is to provide basic geometries as
(multi)line, (multi)poligon, (multi)point in order to
connect it (OGR vectors) to my layers/map/renderers framework.
Then I could use such library(ies) in Pocket PC mapping/GPS
applications. I use my own quad tree spatial index.

Then, after some additional work (if required) I'm going to
add SRS/coordinates transformation support.

I also would like to contribute to GDAL/OGR with
Pocket PC related features.

Talking about rasters.
I have my own rasters support. It uses tiled rasters.
So, now I do not need reastes support provided by GDAL.
But, surely I'm interested in this and I do not mind to move to GDAL
raster support.

Note: I develop only for Windows CE 4.x and higher versions.
So, I use eVC++ 4.0 (and Visual Studio 2005 when released).

So, if you don't mind, please send me your GDAL/OGR port.
Do you plan to do some work on this project and add new features from
"big" GDAL/OGR?

May be it could be nice to create a kind of branch/subproject
for Windows CE (as it is for sqlite -> sqlite-wince on SF.net)?

Best regards

--
Mateusz Łoskot, mateusz (at) loskot (dot) net
Registered Linux User #220771, Debian (Sarge)
_______________________________________________
Gdal-dev mailing list
[hidden email]
http://xserve.flids.com/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Re: Building GDAL with eVC++ 4.0

Andrey Kiselev
In reply to this post by Mateusz Loskot
On Tue, May 31, 2005 at 11:48:41AM +0200, Mateusz Łoskot wrote:
> >> #ifdef HAVE_LOCALE_H
> >> #  include <locale.h>
> >> #endif
>
> Certainly, I know that technique but the name "guard" strange for me.

I didn't read original K&R (i.e. in English), and do not know how they
call this technique, but Stroustrup uses the term "include guards".

> evc++ supports nmake build system. Certainly, there are some features
> in "big" Windows (and "big" namke system) not supported byt Pocket PC
> SDK. I've created makefile.evc and I'm trying to go with this but it
> is not enough solution. So, I will try to work with nmake.opt and
> other files you are talking about. Today I will dig into this job.

Once I tried to build libtiff using eVC. I do not remember details, but a
mess with headers was the main problem. I haven't forced enough to
commit the stuff into libtiff CVS, so all of that remains outside of the
main tree. I do not think there will be a big hassle to port GDAL to
eVC.

As a first step you should write your own cpl_config.h.evc, because
cpl_config.h.vc is not suitable for that compiler. Also conditional
compilation in cpl_vsisimple.cpp and cpl_port.h should be corrected (to
isolate fcntl.h, for example).

Regards,
Andrey

--
Andrey V. Kiselev
Home phone:  +7 812 5970603  ICQ# 26871517
_______________________________________________
Gdal-dev mailing list
[hidden email]
http://xserve.flids.com/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Building GDAL with eVC++ 4.0

Mateusz Loskot
Andrey Kiselev napisał(a):

> On Tue, May 31, 2005 at 11:48:41AM +0200, Mateusz Łoskot wrote:
>
>>>>#ifdef HAVE_LOCALE_H
>>>>#  include <locale.h>
>>>>#endif
>>
>>Certainly, I know that technique but the name "guard" strange for me.
>
>
> I didn't read original K&R (i.e. in English), and do not know how they
> call this technique, but Stroustrup uses the term "include guards".

I do not have english version of Stroustrup's book.
I read it in polish, and I haven't met "include guards" term.
Thanks for explanation.

>>evc++ supports nmake build system. Certainly, there are some features
>>in "big" Windows (and "big" namke system) not supported byt Pocket PC
>>SDK. I've created makefile.evc and I'm trying to go with this but it
>>is not enough solution. So, I will try to work with nmake.opt and
>>other files you are talking about. Today I will dig into this job.
>
>
> Once I tried to build libtiff using eVC. I do not remember details, but a
> mess with headers was the main problem. I haven't forced enough to
> commit the stuff into libtiff CVS, so all of that remains outside of the
> main tree. I do not think there will be a big hassle to port GDAL to
> eVC.

Yes, I realize that.

> As a first step you should write your own cpl_config.h.evc, because
> cpl_config.h.vc is not suitable for that compiler. Also conditional
> compilation in cpl_vsisimple.cpp and cpl_port.h should be corrected (to
> isolate fcntl.h, for example).


OK, and makefile.evc is also required, I think.
I'll work on this port this week.

Regards

--
Mateusz Łoskot
mateusz at loskot dot net

_______________________________________________
Gdal-dev mailing list
[hidden email]
http://xserve.flids.com/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

gdalwarp -tps weirdness

HamishB
I'm trying to use gdalwarp's new thin plate spline warping but it is
doing funny things. Seems like a memory stomping problem but I'm not
sure. Doing things like changing the order of GCPs (dozen placed by hand
with gdal_translate) or the length of the output filename makes it
either work or have the output go haywire.

anybody come across this before?


GDAL 1.2.6.0 on Debian.

entered in GDAL bugzilla bug # 864
  http://bugzilla.remotesensing.org/show_bug.cgi?id=864



thanks,
Hamish
_______________________________________________
Gdal-dev mailing list
[hidden email]
http://xserve.flids.com/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: gdalwarp -tps weirdness

HamishB
> I'm trying to use gdalwarp's new thin plate spline warping but it is
> doing funny things. Seems like a memory stomping problem but I'm not
> sure. Doing things like changing the order of GCPs (dozen placed by
> hand with gdal_translate) or the length of the output filename makes
> it either work or have the output go haywire.
>
> anybody come across this before?
>
>
> GDAL 1.2.6.0 on Debian.
>
> entered in GDAL bugzilla bug # 864
>   http://bugzilla.remotesensing.org/show_bug.cgi?id=864



[cc GDAL Bug 864]


recompiled on another machine from source (previous was with the Debian
packages). Same result but now I can use gdb for two segfaults I can
trigger, in addition to the weird output bug mentioned above.

Both segfaults trace back to the GDALWarpOperation::WarpRegion stage.



Segfault 1) Different GeoTIFF image than the above failure, it gets to
100% complete, then segfaults. Leaves behind a corrupted output GeoTiff.


Here's the gdb session:


$ gdb `which gdalwarp`
(gdb) run -tps -co compress=lzw 8right_gcp.tif 8right_warped_xyz123def.tif
Starting program: /usr/local/bin/gdalwarp -tps -co compress=lzw 8right_gcp.tif 8right_warped_xyz123def.tif
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 9987)]
Creating output file that is 9627P x 6717L.
:0...10...20...30...40...50...60...70...80...90...100 - done.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 9987)]
0x4070756b in memset () from /lib/libc.so.6
(gdb) bt f
#0  0x4070756b in memset () from /lib/libc.so.6
No symbol table info available.
#1  0x405138ad in _TIFFmemset () from /usr/lib/libtiff.so.4
No symbol table info available.
#2  0x40508833 in TIFFInitSGILog () from /usr/lib/libtiff.so.4
No symbol table info available.
#3  0x40511f85 in TIFFReadBufferSetup () from /usr/lib/libtiff.so.4
No symbol table info available.
#4  0x4051131c in TIFFReadEncodedStrip () from /usr/lib/libtiff.so.4
No symbol table info available.
#5  0x400f5e05 in GTiffRasterBand::IReadBlock (this=0x80512e8, nBlockXOff=0, nBlockYOff=0,
    pImage=0x8a9ab00) at geotiff.cpp:518
        poGDS = (GTiffDataset *) 0x80511d8
        nBlockBufSize = 9627
        nBlockId = 0
        nBlockIdBand0 = 0
        eErr = CE_None
#6  0x401a8d3a in GDALRasterBand::GetBlockRef (this=0x80512e8, nXBlockOff=0, nYBlockOff=0,
    bJustInitialize=0) at gdalrasterband.cpp:1142
        poBlock = (class GDALRasterBlock *) 0x8706db0
#7  0x401ac1da in GDALRasterBand::IRasterIO (this=0x80512e8, eRWFlag=GF_Write, nXOff=4813, nYOff=0,
    nXSize=4814, nYSize=6717, pData=0x41409008, nBufXSize=4814, nBufYSize=6717, eBufType=GDT_Byte,
    nPixelSpace=1, nLineSpace=4814) at rasterio.cpp:175
        bJustInitialize = 0
        nSrcByteOffset = 0
        nBandDataSize = 1
        nBufDataSize = 1
        pabySrcBlock = (GByte *) 0x0
        poBlock = (class GDALRasterBlock *) 0x40701176
        nLBlockX = -1
        nLBlockY = 0
        iBufYOff = 0
        iBufXOff = 1081866368
        iSrcY = 0
        iSrcX = 0
        dfSrcX = 2.1219957909652723e-314
        dfSrcY = 7.7813168390427143e-292
        dfSrcXInc = 48.371032714843786
        dfSrcYInc = 263.61883544908824
#8  0x401a00b0 in GDALDataset::IRasterIO (this=0x80511d8, eRWFlag=GF_Write, nXOff=4813, nYOff=0,
    nXSize=4814, nYSize=6717, pData=0x41409008, nBufXSize=4814, nBufYSize=6717, eBufType=GDT_Byte,
    nBandCount=1, panBandMap=0x80508c0, nPixelSpace=1, nLineSpace=4814, nBandSpace=32335638)
    at gdaldataset.cpp:1290
        poBand = (class GDALRasterBand *) 0x80512e8
        pabyBandData = (GByte *) 0x41409008 ""
        iBandIndex = 0
        eErr = CE_None
#9  0x401a048c in GDALDataset::RasterIO (this=0x80511d8, eRWFlag=GF_Write, nXOff=4813, nYOff=0,
    nXSize=4814, nYSize=6717, pData=0x41409008, nBufXSize=4814, nBufYSize=6717, eBufType=GDT_Byte,
    nBandCount=1, panBandMap=0x80508c0, nPixelSpace=1, nLineSpace=4814, nBandSpace=32335638)
    at gdaldataset.cpp:1481
        i = 1
        bNeedToFreeBandMap = 0
        eErr = CE_None
#10 0x401a0531 in GDALDatasetRasterIO (hDS=0x80511d8, eRWFlag=GF_Write, nXOff=4813, nYOff=0,
    nXSize=4814, nYSize=6717, pData=0x41409008, nBufXSize=4814, nBufYSize=6717, eBufType=GDT_Byte,
    nBandCount=1, panBandMap=0x80508c0, nPixelSpace=0, nLineSpace=0, nBandSpace=0)
    at gdaldataset.cpp:1515
        poDS = (GDALDataset *) 0x80511d8
#11 0x401cf63e in GDALWarpOperation::WarpRegion (this=0xbffff9b0, nDstXOff=4813, nDstYOff=0,
    nDstXSize=4814, nDstYSize=6717, nSrcXOff=0, nSrcYOff=0, nSrcXSize=1200, nSrcYSize=11100)
    at gdalwarpoperation.cpp:1190
        eErr = CE_None
        iBand = 1
        pDstBuffer = (void *) 0x41409008
        nWordSize = 1
        nBandSize = 32335638
        pszInitDest = 0x8055d8a "0"
#12 0x401ce7d9 in GDALWarpOperation::ChunkAndWarpImage (this=0xbffff9b0, nDstXOff=0, nDstYOff=0,
    nDstXSize=9627, nDstYSize=6717) at gdalwarpoperation.cpp:683
        panThisChunk = (int *) 0x80570d8
        dfChunkPixels = 32335638
        eErr = CE_None
        iChunk = 1
        dfPixelsProcessed = 32328921
        dfTotalPixels = 64664559
#13 0x0804aca6 in main (argc=6, argv=0x80504a8) at gdalwarp.cpp:657
        hSrcDS = 0x80509f8
        hDstDS = 0x80511d8
        pszFormat = 0x804b6cc "GTiff"
        pszTargetSRS = 0x0
        pszSourceSRS = 0x0
        pszSrcFilename = 0x804fdc0 "8right_gcp.tif"
        pszDstFilename = 0x80504c8 "8right_warped_xyz123def.tif"
        bCreateOutput = 1
        i = 1
        nOrder = -1
        hTransformArg = (void *) 0x8057358
        hGenImgProjArg = (void *) 0x8055f60
        hApproxArg = (void *) 0x8057358
        papszWarpOptions = (char **) 0x8055d60
        dfErrorThreshold = 0.125
        dfWarpMemoryLimit = 0
        pfnTransformer = 0x8049454 <GDALApproxTransform>
        papszCreateOptions = (char **) 0x0
        eOutputType = GDT_Unknown
        eWorkingType = GDT_Unknown
        eResampleAlg = GRA_NearestNeighbour
        pszSrcNodata = 0x0
        pszDstNodata = 0x0
        bMulti = 0
        psWO = (GDALWarpOptions *) 0x80574d0
        oWO = {_vptr.GDALWarpOperation = 0x403735d0, psOptions = 0x8056b60,
  dfProgressBase = 0.49994806274020981, dfProgressScale = 0.50005193725979014, hThread1Mutex = 0x0,
  hThread2Mutex = 0x0, hIOMutex = 0x0, hWarpMutex = 0x0, nChunkListCount = 2, nChunkListMax = 3,
  panChunkList = 0x80570b8, bReportTimings = 0, nLastTimeReported = 0}
(gdb) l
657                 oWO.ChunkAndWarpImage( 0, 0,
658                                        GDALGetRasterXSize( hDstDS ),
659                                        GDALGetRasterYSize( hDstDS ) );
660         }
661    
662     /* -------------------------------------------------------------------- */
663     /*      Cleanup                                                         */
664     /* -------------------------------------------------------------------- */
665         if( hApproxArg != NULL )
666             GDALDestroyApproxTransformer( hApproxArg );
(gdb) frame 5
#5  0x400f5e05 in GTiffRasterBand::IReadBlock (this=0x80512e8, nBlockXOff=0, nBlockYOff=0,
    pImage=0x8a9ab00) at geotiff.cpp:518
518                 if( TIFFReadEncodedStrip( poGDS->hTIFF, nBlockId, pImage,
(gdb) l
513                     eErr = CE_Failure;
514                 }
515             }
516             else
517             {
518                 if( TIFFReadEncodedStrip( poGDS->hTIFF, nBlockId, pImage,
519                                           nBlockBufSize ) == -1 )
520                 {
521                     memset( pImage, 0, nBlockBufSize );
522                     CPLError( CE_Failure, CPLE_AppDefined,
(gdb) frame 6
#6  0x401a8d3a in GDALRasterBand::GetBlockRef (this=0x80512e8, nXBlockOff=0, nYBlockOff=0,
    bJustInitialize=0) at gdalrasterband.cpp:1142
1142            if( !bJustInitialize
(gdb) l
1137                CPLError( CE_Failure, CPLE_AppDefined, "Internalize failed",
1138                          nXBlockOff, nYBlockOff);
1139                return( NULL );
1140            }
1141    
1142            if( !bJustInitialize
1143             && IReadBlock(nXBlockOff,nYBlockOff,poBlock->GetDataRef()) != CE_None)
1144            {
1145                delete poBlock;
1146                CPLError( CE_Failure, CPLE_AppDefined,



$ gdalinfo 8right_gcp.tif
Driver: GTiff/GeoTIFF
Size is 1200, 11100
Coordinate System is `'
GCP Projection =
GCP[  0]: Id=1, Info=
          (1198,3) -> [...]
[...]
GCP[ 23]: Id=24, Info=
          (970,11040) -> [...]
Corner Coordinates:
Upper Left  (    0.0,    0.0)
Lower Left  (    0.0,11100.0)
Upper Right ( 1200.0,    0.0)
Lower Right ( 1200.0,11100.0)
Center      (  600.0, 5550.0)
Band 1 Block=1200x6 Type=Byte, ColorInterp=Gray






--------

Segfault 2) Another segfault in another way using a different file.
I guess this one's only a symptom of the matrix gen failing:



$ gdb `which gdalwarp`
[...]
(gdb) run -tps -co compress=lzw 18left_gcp.tif 18left_warped_abcdefg.tif
Starting program: /usr/local/bin/gdalwarp -tps -co compress=lzw 18left_gcp.tif 18left_warped_abcdefg.tif
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 9969)]
 There is a problem to invert the interpolation matrix
Creating output file that is 4513P x 12251L.
 There is a problem to invert the interpolation matrix
:0.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 9969)]
0x401ca487 in GWKNearestNoMasksByte (poWK=0xbffff7d0) at gdalwarpkernel.cpp:2065
2065                    poWK->papabyDstImage[iBand][iDstOffset] =
(gdb) bt f
#0  0x401ca487 in GWKNearestNoMasksByte (poWK=0xbffff7d0) at gdalwarpkernel.cpp:2065
        iSrcX = -2147483648
        iSrcOffset = -2147483648
        iSrcY = -2147483648
        iBand = 0
        iDstOffset = 0
        iDstX = 0
        iDstY = 0
        nDstXSize = 4513
        nDstYSize = 12251
        nSrcXSize = 0
        nSrcYSize = 0
        eErr = CE_None
        padfX = (double *) 0x80594f8
        padfY = (double *) 0x8062208
        padfZ = (double *) 0x806af18
        pabSuccess = (int *) 0x8073c28
#1  0x401c695e in GDALWarpKernel::PerformWarp (this=0xbffff7d0) at gdalwarpkernel.cpp:591
        eErr = CE_None
#2  0x401cfda6 in GDALWarpOperation::WarpRegionToBuffer (this=0xbffff9b0, nDstXOff=0, nDstYOff=0,
    nDstXSize=4513, nDstYSize=12251, pDataBuf=0x40f04008, eBufDataType=GDT_Byte, nSrcXOff=0,
    nSrcYOff=0, nSrcXSize=0, nSrcYSize=0) at gdalwarpoperation.cpp:1475
        eErr = CE_None
        i = 1
        nWordSize = 1
        oWK = {_vptr.GDALWarpKernel = 0x40373570, papszWarpOptions = 0x8056b80,
  eResample = GRA_NearestNeighbour, eWorkingDataType = GDT_Byte, nBands = 1, nSrcXSize = 0,
  nSrcYSize = 0, papabySrcImage = 0x8056200, papanBandSrcValid = 0x0, panUnifiedSrcValid = 0x0,
  pafUnifiedSrcDensity = 0x0, nDstXSize = 4513, nDstYSize = 12251, papabyDstImage = 0x8056f40,
  panDstValid = 0x0, pafDstDensity = 0x0, nSrcXOff = 0, nSrcYOff = 0, nDstXOff = 0, nDstYOff = 0,
  pfnTransformer = 0x8049454 <GDALApproxTransform>, pTransformerArg = 0x8056ef0,
  pfnProgress = 0x8049834 <GDALTermProgress>, pProgress = 0x0, dfProgressBase = 0,
  dfProgressScale = 1}
#3  0x401cf5a8 in GDALWarpOperation::WarpRegion (this=0xbffff9b0, nDstXOff=0, nDstYOff=0,
    nDstXSize=4513, nDstYSize=12251, nSrcXOff=0, nSrcYOff=0, nSrcXSize=0, nSrcYSize=0)
    at gdalwarpoperation.cpp:1181
        eErr = CE_None
        iBand = 1
        pDstBuffer = (void *) 0x40f04008
        nWordSize = 1
        nBandSize = 55288763
        pszInitDest = 0x8056b9a "0"
#4  0x401ce7d9 in GDALWarpOperation::ChunkAndWarpImage (this=0xbffff9b0, nDstXOff=0, nDstYOff=0,
    nDstXSize=4513, nDstYSize=12251) at gdalwarpoperation.cpp:683
        panThisChunk = (int *) 0x8056f18
        dfChunkPixels = 55288763
        eErr = 134532600
        iChunk = 0
        dfPixelsProcessed = 0
        dfTotalPixels = 55288763
#5  0x0804aca6 in main (argc=6, argv=0x80504a8) at gdalwarp.cpp:657
        hSrcDS = 0x80509f8
        hDstDS = 0x8056230
        pszFormat = 0x804b6cc "GTiff"
        pszTargetSRS = 0x0
        pszSourceSRS = 0x0
        pszSrcFilename = 0x804fdc0 "18left_gcp.tif"
        pszDstFilename = 0x80504c8 "18left_warped_abcdefg.tif"
        bCreateOutput = 1
        i = 1
        nOrder = -1
        hTransformArg = (void *) 0x8056ef0
        hGenImgProjArg = (void *) 0x80511d8
        hApproxArg = (void *) 0x8056ef0
        papszWarpOptions = (char **) 0x8050750
        dfErrorThreshold = 0.125
        dfWarpMemoryLimit = 0
        pfnTransformer = 0x8049454 <GDALApproxTransform>
        papszCreateOptions = (char **) 0x0
        eOutputType = GDT_Unknown
        eWorkingType = GDT_Unknown
        eResampleAlg = GRA_NearestNeighbour
        pszSrcNodata = 0x0
        pszDstNodata = 0x0
        bMulti = 0
        psWO = (GDALWarpOptions *) 0x8057268
        oWO = {_vptr.GDALWarpOperation = 0x403735d0, psOptions = 0x8056af0, dfProgressBase = 0,
  dfProgressScale = 1, hThread1Mutex = 0x0, hThread2Mutex = 0x0, hIOMutex = 0x0, hWarpMutex = 0x0,
  nChunkListCount = 1, nChunkListMax = 1, panChunkList = 0x8056f18, bReportTimings = 0,
  nLastTimeReported = 0}
(gdb) l
657                 oWO.ChunkAndWarpImage( 0, 0,
658                                        GDALGetRasterXSize( hDstDS ),
659                                        GDALGetRasterYSize( hDstDS ) );
660         }
661    
662     /* -------------------------------------------------------------------- */
663     /*      Cleanup                                                         */
664     /* -------------------------------------------------------------------- */
665         if( hApproxArg != NULL )
666             GDALDestroyApproxTransformer( hApproxArg );
(gdb) frame 0
#0  0x401ca487 in GWKNearestNoMasksByte (poWK=0xbffff7d0) at gdalwarpkernel.cpp:2065
2065                    poWK->papabyDstImage[iBand][iDstOffset] =
(gdb) l
2060    
2061                iDstOffset = iDstX + iDstY * nDstXSize;
2062    
2063                for( iBand = 0; iBand < poWK->nBands; iBand++ )
2064                {
2065                    poWK->papabyDstImage[iBand][iDstOffset] =
2066                        poWK->papabySrcImage[iBand][iSrcOffset];
2067                }
2068            }
2069    
(gdb) frame 1
#1  0x401c695e in GDALWarpKernel::PerformWarp (this=0xbffff7d0) at gdalwarpkernel.cpp:591
591             return GWKNearestNoMasksByte( this );
(gdb) l
586             && papanBandSrcValid == NULL
587             && panUnifiedSrcValid == NULL
588             && pafUnifiedSrcDensity == NULL
589             && panDstValid == NULL
590             && pafDstDensity == NULL )
591             return GWKNearestNoMasksByte( this );
592    
593         if( eWorkingDataType == GDT_Byte
594             && eResample == GRA_Bilinear
595             && papanBandSrcValid == NULL



So I guess this segfault happens as iSrcOffset being used uninitialized
in gdalwarpkernel.cpp line 2066 ......





thanks,
Hamish
_______________________________________________
Gdal-dev mailing list
[hidden email]
http://xserve.flids.com/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

RE: gdalwarp -tps weirdness

Asger Petersen
In reply to this post by HamishB
>
> I'm trying to use gdalwarp's new thin plate spline warping but it is
> doing funny things. Seems like a memory stomping problem but I'm not
> sure. Doing things like changing the order of GCPs (dozen placed by hand
> with gdal_translate) or the length of the output filename makes it
> either work or have the output go haywire.
>
> anybody come across this before?

Hi

I had a problem much like this some time ago. Maybe you are experiencing something similar? Anyway here is an excerpt of the original correspondence with Frank:

My question:
---
> I grew some gray hair finding out, that you can´t have a numeric filename when you use gcps with gdal_translate.
> This works:
> gdal_translate -of JP2KAK -gcp 0 0 702530.030 6172016.512
> ht200414_06_7631.ecw ht200414_06_7631gcp.jp2
> This doesn't work:
> gdal_translate -of JP2KAK -gcp 0 0 702530.030 6172016.512
> 200414_06_7631.ecw 200414_06_7631gcp.jp2
> If you don't use gcps, there are no problems with numeric filenames. So this also works:
> gdal_translate -of JP2KAK 200414_06_7631.ecw 200414_06_7631gcp.jp2
---

Franks answer:
----
Asger,
The problem is that there is an optional elevation argument in the -gcp switch.  The usage message should look like this (now updated):

   [-gcp pixel line easting northing [elevation]]*

In order to determine if an elevation is supplied, the program tries to read a numeric value from the argument.  If it gets a non-zero value it treats it as elevation.
---
Regards
Asger
_______________________________________________
Gdal-dev mailing list
[hidden email]
http://xserve.flids.com/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: gdalwarp -tps weirdness

HamishB
> > I'm trying to use gdalwarp's new thin plate spline warping but it is
> > doing funny things. Seems like a memory stomping problem but I'm not
> > sure. Doing things like changing the order of GCPs (dozen placed by
> > hand with gdal_translate) or the length of the output filename makes
> > it either work or have the output go haywire.
> >
> > anybody come across this before?
>
> I had a problem much like this some time ago. Maybe you are
> experiencing something similar? Anyway here is an excerpt of the
> original correspondence with Frank:
>
> My question:
> ---
> > I grew some gray hair finding out, that you can´t have a numeric
> > filename when you use gcps with gdal_translate.
[...]

> Franks answer:
> ----
> Asger,
> The problem is that there is an optional elevation argument in the
> -gcp switch.  The usage message should look like this (now updated):
>
>    [-gcp pixel line easting northing [elevation]]*
>
> In order to determine if an elevation is supplied, the program tries
> to read a numeric value from the argument.  If it gets a non-zero
> value it treats it as elevation. ---


Yes, I found that one too. Filed it as bug # 863 (gdal_translate).
:)
My work-around was to put something after the -gcp entries and before
the input source name.  "-co compress=lzw" does the trick.


This doesn't solve bug # 864 though (gdalwarp).
:(



thanks,
Hamish
_______________________________________________
Gdal-dev mailing list
[hidden email]
http://xserve.flids.com/mailman/listinfo/gdal-dev