[gdal-dev] Question about GDALDriverManager + gdal2wktraster

Tamas Szekeres szekerest at gmail.com
Mon Jul 6 05:26:32 EDT 2009


Jorge,

I'm not aware much about the changes in the gdal2wktraster script, I can see
a r4226 which may be related to the problem. Please consult with the author
Mateusz Loskot about the possible reasons you've encountered with the
script.

I'll be trying to reproduce your appcrash and gather further information
abot the details soon.

Best regards,

Tamas



2009/7/4 Jorge Arévalo <jorge.arevalo at gmail.com>

> Hello,
>
> I have two versions of GDAL in my machine:
>
> - GDAL 1.7.0 from SVN
> - GDAL 1.7.0 with the WKT Raster driver I'm developing
>
> Today, I've updated the wktraster code from svn. I have the revision 4256.
> The last one. With this revision, there is a new version of gdal2wktraster
> script.
>
> I loaded this image
> ftp://ftp.remotesensing.org/geotiff/samples/gdal_eg/cea.tif with and old
> version of gdal2wktraster, that allowed GDAL to select the block size for
> the tiles. Then, I could load the image with default tiles of 514x15, 35
> tiles.
>
> But with the new version of the script, I have to specify the block size by
> hand. For example, 514x15 (or 100x100). When I try this:
>
> gdal2wktraster.py -r cea.tif -t table_name -s 4267 -b 1 -k 514x15 -I -M -o
> output.sql -v
>
> I get this error:
>
> ERROR 7: Assertion `FALSE' failed
> in file `gdaldrivermanager.cpp', line 309
>
> Reviewing the code, I saw that the last script's instruction called is:
>
> pixels = band.ReadAsArray(xoff, yoff, valid_read_block_size[0],
> valid_read_block_size[1],
>                                   target_block_size[0],
> target_block_size[1])
>
> That, somehow, should call the method "GDALDriverManager::RegisterDriver(
> GDALDriver * poDriver )" from gdalmanager.cpp. The code of the method is
> this:
>
> int GDALDriverManager::RegisterDriver( GDALDriver * poDriver )
> {
>     CPLMutexHolderD( &hDMMutex );
>
> /* -------------------------------------------------------------------- */
> /*      If it is already registered, just return the existing           */
> /*      index.                                                          */
> /* -------------------------------------------------------------------- */
>     if( GetDriverByName( poDriver->GetDescription() ) != NULL )
>     {
>         int             i;
>
>         for( i = 0; i < nDrivers; i++ )
>         {
>             if( papoDrivers[i] == poDriver )
>             {
>                 return i;
>             }
>         }
>
>         CPLAssert( FALSE ); // -------> THE LINE THAT CAUSES THE CRASH
> *******************************************
>     }
>
> /* -------------------------------------------------------------------- */
> /*      Otherwise grow the list to hold the new entry.                  */
> /* -------------------------------------------------------------------- */
>     papoDrivers = (GDALDriver **)
>         VSIRealloc(papoDrivers, sizeof(GDALDriver *) * (nDrivers+1));
>
>     papoDrivers[nDrivers] = poDriver;
>     nDrivers++;
>
>     if( poDriver->pfnCreate != NULL )
>         poDriver->SetMetadataItem( GDAL_DCAP_CREATE, "YES" );
>
>     if( poDriver->pfnCreateCopy != NULL )
>         poDriver->SetMetadataItem( GDAL_DCAP_CREATECOPY, "YES" );
>
>     int iResult = nDrivers - 1;
>
>     return iResult;
> }
>
> So, basically, with the base 1.7.0 version of GDAL, I can load the TIFF
> file. With my version, crash in the previous method. Clearly, it's my
> driver's problem, but I don't know why. I have a test code to create a
> dataset using my driver and works... Why could the application crash when
> trying to list the registered drivers while loading a TIFF file? I have the
> TIFF driver loaded in my GDAL version.
>
> Thanks in advance,
>
> Best regards
> Jorge
>
> Paula Poundstone<http://www.brainyquote.com/quotes/authors/p/paula_poundstone.html> - "I don't have a bank account because I don't know my mother's maiden
> name."
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090706/529afb10/attachment-0001.html


More information about the gdal-dev mailing list