Frank,
after syncing (as regularly) the DBF driver from SHAPELIB embedded
in OGR, we face the problem that it no longer works with older GDAL
versions than current SVN:
http://trac.osgeo.org/grass/ticket/110
I don't know what to do. In essence, I don't want to fork our version
from yours.
Any ideas?
thanks
Markus
On Wed, Apr 9, 2008 at 11:31 AM, Maris Nartiss <maris.gis@gmail.com> wrote:
It's known as issue 110 [1].
Maris.
1. http://trac.osgeo.org/grass/ticket/110
2008/4/9, benjamin.ducke@ufg.uni-kiel.de <benjamin.ducke@ufg.uni-kiel.de>:
> FWIW, the DBF driver still does not seem to be usable.
> On Ubuntu 7.10, GDAL 1.5.1, with a version compiled from SVN (did make
> distclean), I cannot access attribute data stored in a DBF file.
>
> v.info -c simply results in a segfault.
>
> GRASS 6.3.RC6 works fine on the same system and with the same GDAL.
>
> Best,
>
> Benjamin
>
>
> _______________________________________________
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
Markus Neteler wrote:
after syncing (as regularly) the DBF driver from SHAPELIB embedded
in OGR, we face the problem that it no longer works with older GDAL
versions than current SVN:
http://trac.osgeo.org/grass/ticket/110
I don't know what to do. In essence, I don't want to fork our version
from yours.
Any ideas?
I suggest using a "stub" implementation of the I/O hooks. E.g.:
typedef struct {
FILE* (*FOpen) ( const char *filename, const char *path);
size_t (*FRead) ( void *p, size_t size, size_t nmemb, FILE* file);
size_t (*FWrite)( void *p, size_t size, size_t nmemb, FILE* file);
long (*FSeek) ( FILE* file, long offset, int whence );
long (*FTell) ( FILE* file );
int (*FFlush)( FILE* file );
int (*FClose)( FILE* file );
void (*Error) ( const char *message );
} SAHooks;
static void error_fn( const char *message )
{
G_fatal_error("%s", message);
}
static void SASetupDefaultHooks( SAHooks *psHooks )
{
psHooks->FOpen = fopen;
psHooks->FRead = fread;
psHooks->FWrite = fwrite;
psHooks->FSeek = fseek;
psHooks->FTell = ftell;
psHooks->FFlush = fflush;
psHooks->FClose = fclose;
psHooks->Error = error_fn;
}
--
Glynn Clements <glynn@gclements.plus.com>
Glynn Clements wrote:
Markus Neteler wrote:
after syncing (as regularly) the DBF driver from SHAPELIB embedded
in OGR, we face the problem that it no longer works with older GDAL
versions than current SVN:
http://trac.osgeo.org/grass/ticket/110
I don't know what to do. In essence, I don't want to fork our version
from yours.
Any ideas?
I suggest using a "stub" implementation of the I/O hooks. E.g.:
typedef struct {
FILE* (*FOpen) ( const char *filename, const char *path);
size_t (*FRead) ( void *p, size_t size, size_t nmemb, FILE* file);
size_t (*FWrite)( void *p, size_t size, size_t nmemb, FILE* file);
long (*FSeek) ( FILE* file, long offset, int whence );
long (*FTell) ( FILE* file );
int (*FFlush)( FILE* file );
int (*FClose)( FILE* file );
void (*Error) ( const char *message );
} SAHooks;
static void error_fn( const char *message )
{
G_fatal_error("%s", message);
}
static void SASetupDefaultHooks( SAHooks *psHooks )
{
psHooks->FOpen = fopen;
psHooks->FRead = fread;
psHooks->FWrite = fwrite;
psHooks->FSeek = fseek;
psHooks->FTell = ftell;
psHooks->FFlush = fflush;
psHooks->FClose = fclose;
psHooks->Error = error_fn;
}
Folks,
I'm just trying to catch up on this topic. There is already a stdio
based implementation in shapelib itself. I have attached it,and it is
normally in a file called safileio.c.
I'm afraid I'm uncertain of the implications of mixing the Shapelib 1.3
code with GDAL's using Shapelib 1.2. It seems potentially like it could
be a problem.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | President OSGeo, http://osgeo.org
(attachments)
safileio.c (9.45 KB)
Frank,
On Wed, Apr 9, 2008 at 7:01 PM, Frank Warmerdam <warmerdam@pobox.com> wrote:
...
I'm afraid I'm uncertain of the implications of mixing the Shapelib 1.3
code with GDAL's using Shapelib 1.2. It seems potentially like it could
be a problem.
This is unclear to me since I took the code from GDAL itself.
Markus