[gdal-dev] Revision 1.55

[Martin Chapman]

* Revision 1.55  2007/11/21 22:39:56  fwarmerdam

 * close shx file in readonly mode (GDAL #1956)

 

Frank,

 

Food for thought on this bug, closing access to the shape index file in read
only mode or any other mode makes little sense since that will remove random
access capability for the driver and all record fetches will have to operate
in a sequential fashion.  Not sure if it was just a mistake or was there
some other thought behind closing the shx file in read only mode?

 

Also, what are SAHooks?

 

Best regards,

 

Martin Chapman

Chief Software Architect

Fortified Datacom Inc.

http://www.fortifieddatacom.com

mchapman at fortifieddatacom.com

303-324-1065

 

From: Martin Chapman [mailto:mchapman at texelinc.com] 
Sent: Sunday, December 16, 2007 5:50 PM
To: 'Martin Chapman'; gdal-dev at lists.osgeo.org
Subject: I found the culprit! -- Possible SyncToDisk() bug in 1.5

 

I found the culprit!  It's in file \gdal\ogr\ogrsf_frmts\shape\shpopen.c on
line 686.

 

Looks like:

 

/* In read-only mode, we can close the SHX now */

    if (strcmp(pszAccess, "rb") == 0)

    {

        psSHP->sHooks.FClose( psSHP->fpSHX );

        psSHP->fpSHX = NULL; ?

    }

 

This code closes the shx in read only mode but is used in the OGR shape code
in areas that don't block readonly access.like creating the quad indexes.  I
made the fix in my local copy but I changed jobs and lost my
username/password to SVN comitter access so someone else will have to make
the fix for me.

 

Best regards,

 

Martin Chapman

Chief Software Architect

Fortified Datacom Inc.

http://www.fortifieddatacom.com

mchapman at fortifieddatacom.com

303-324-1065

 

From: Martin Chapman [mailto:mchapman at texelinc.com] 
Sent: Sunday, December 16, 2007 5:21 PM
To: 'Martin Chapman'; gdal-dev at lists.osgeo.org
Subject: RE: [gdal-dev] Possible SyncToDisk() bug in 1.5

 

Also, because SHX is not picked up rendering or looping through geometries
in a shape file is now very slow.  I will look into the bug further and see
if I can find the problem.  Is anyone else seeing this issue in 1.5 or
noticed shape files being slow?

 

Martin Chapman

Chief Software Architect

Fortified Datacom Inc.

http://www.fortifieddatacom.com

mchapman at fortifieddatacom.com

303-324-1065

 

From: gdal-dev-bounces at lists.osgeo.org
[mailto:gdal-dev-bounces at lists.osgeo.org] On Behalf Of Martin Chapman
Sent: Sunday, December 16, 2007 5:16 PM
To: gdal-dev at lists.osgeo.org
Subject: [gdal-dev] Possible SyncToDisk() bug in 1.5

 

This code:

 

--

string sLayerName = (string)
m_pDataSource->GetLayer(0)->GetLayerDefn()->GetName();

string sSQL = "CREATE SPATIAL INDEX ON " + sLayerName;

m_pDataSource->ExecuteSQL((const char*) sSQL.c_str(), NULL, "");

--

 

throws an error in the file/function below on the line -
hSHP->sHooks.FFlush( hSHP->fpSHX );

because hSHP->fpSHX is NULL.  The question is why is hSHP->fpSHX NULL when
it used to pickup the shape index file.  Anyone else have this problem with
1.5? 

 

\gdal\ogr\ogrsf_frmts\shape\ogrshapelayer.cpp

 

OGRErr OGRShapeLayer::SyncToDisk()

 

{

    if( bHeaderDirty )

    {

        if( hSHP != NULL )

            SHPWriteHeader( hSHP );

 

        if( hDBF != NULL )

            DBFUpdateHeader( hDBF );

        

        bHeaderDirty = FALSE;

    }

 

    if( hSHP != NULL )

    {

        hSHP->sHooks.FFlush( hSHP->fpSHP );

        hSHP->sHooks.FFlush( hSHP->fpSHX );  ka-boom!

    }

 

    if( hDBF != NULL )

        hDBF->sHooks.FFlush( hDBF->fp );

 

    return OGRERR_NONE;

}

 

Best regards,

 

Martin Chapman

Chief Software Architect

Fortified Datacom Inc.

http://www.fortifieddatacom.com

mchapman at fortifieddatacom.com

303-324-1065

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20071216/32a97fe5/attachment.html