WinGrass: displaying r.external-linked raster data not working

[hellik]

fresh Grass64svn, self compiled, nc-sample-dataset

elevation exported as gtiff

linking by r.external seems to work

r.external input=C:\wd\testoutput\elevtestoit.tif output=testrasterlink title=ElevationData
Die Projektionsinformationen des Eingabedatensatzes und der aktuellen Location scheinen übereinzustimmen.
Importing band 1 of 1...
Kategorie-Informationen für [testrasterlink] in [user1] fehlen oder sind ungültig.
<testrasterlink> erzeugt.
r.external komplett.

basic information raster of the linked data is available

r.info map=testrasterlink@user1                                                 
Kategorie Unterstützung für [testrasterlink@user1] im Mapset [user1] missing
 +----------------------------------------------------------------------------+
 | Layer:    testrasterlink@user1           Date: Tue Jan 19 20:54:42 2010    |
 | Mapset:   user1                          Login of Creator: syringia        |
 | Location: nc_spm_08                                                        |
 | DataBase: C:/gisdata/grassdata                                             |
 | Title:    ?? ( testrasterlink )                                            |
 | Timestamp: none                                                            |
 |----------------------------------------------------------------------------|
 |                                                                            |
 |   Type of Map:  raster               Number of Categories: ??              |
 |   Data Type:    FCELL                                                      |
 |   Rows:         1350                                                       |
 |   Columns:      1500                                                       |
 |   Total Cells:  2025000                                                    |
 |        Projection: Lambert Conformal Conic                                 |
 |            N:     228500    S:     215000   Res:    10                     |
 |            E:     645000    W:     630000   Res:    10                     |
 |   Range of data:    min = 55.988194  max = 155.935272                      |
 |                                                                            |
 |   Data Description:                                                        |
 |    generated by r.external                                                 |
 |                                                                            |
 |   Comments:                                                                |
 |    r.external input="C:\wd\testoutput\elevtestoit.tif" output="testrast\   |
 |    erlink" band=1 title="ElevationData"                                    |
 |                                                                            |
 +----------------------------------------------------------------------------+

but if i want to display the linked raster in the wxgui, following error message comes up:

Execution failed:
"d.rast -o map=testrasterlink@user1 --q"
Details:
"Error: Unable to locate symbol <GDALAllRegister>

with debug-level=3

GRASS 6.4.0svn (nc_spm_08):c:/ > d.rast -o map=testrasterlink@user1
WARNUNG: c:/OSGeo4W/apps/grass/grass-6.4.0svn/etc/fontcap: Keine
         Zeichensatz-Definitionsdatei gefunden
PNG: GRASS_TRUECOLOR status: FALSE
PNG: collecting to file: map.png,
GRASS_WIDTH=640, GRASS_HEIGHT=480
D2/3: G__read_Cell_head
D2/3: G__read_Cell_head_array
D3/3: region item: proj:       99
D3/3: region item: zone:       0
D3/3: region item: north:      228500
D3/3: region item: south:      215000
D3/3: region item: east:       645000
D3/3: region item: west:       630000
D3/3: region item: cols:       1500
D3/3: region item: rows:       1350
D3/3: region item: e-w resol:  10
D3/3: region item: n-s resol:  10
D3/3: region item: top:        1
D3/3: region item: bottom:     0
D3/3: region item: cols3:      1500
D3/3: region item: rows3:      1350
D3/3: region item: depths:     1
D3/3: region item: e-w resol3: 10
D3/3: region item: n-s resol3: 10
D3/3: region item: t-b resol:  1
D2/3: G__read_Cell_head
D2/3: G__read_Cell_head_array
D3/3: region item: proj:       99
D3/3: region item: zone:       0
D3/3: region item: north:      228500
D3/3: region item: south:      215000
D3/3: region item: east:       645000
D3/3: region item: west:       630000
D3/3: region item: cols:       1500
D3/3: region item: rows:       1350
D3/3: region item: e-w resol:  10
D3/3: region item: n-s resol:  10
D3/3: region item: format:     -1
D3/3: region item: compressed: 0
FEHLER: Unable to locate symbol <GDALAllRegister>

Helmut

[glynn]

Replying to hellik:

fresh Grass64svn, self compiled, nc-sample-dataset elevation exported as gtiff linking by r.external seems to work

basic information raster of the linked data is available

but if i want to display the linked raster in the wxgui, following error message comes up:

"Error: Unable to locate symbol <GDALAllRegister>

I suspect that it needs to be e.g. GDALAllRegister@0, as the functions use the "stdcall" (aka "pascal") calling convention.

It works with the version of GDAL I have here (which I built from source), which for some reason seems to be using "ccall" (the symbols don't have the @<size> suffix).

You could try using "make GDAL_DYNAMIC=" to link libgis directly against GDAL, rather than using LoadLibrary().

To make it work with a stdcall version of GDAL, I need to know the decorated names.

OTOH, it may be better to simply omit the r.external support from 6.5; it's very out of date (it was back-ported shortly after the first draft of the code was added to 7.0, and hasn't been updated since).

[hellik]

Replying to glynn:

Replying to hellik:

fresh Grass64svn, self compiled, nc-sample-dataset elevation exported as gtiff linking by r.external seems to work

basic information raster of the linked data is available

but if i want to display the linked raster in the wxgui, following error message comes up:

{{{ "Error: Unable to locate symbol <GDALAllRegister> }}} I suspect that it needs to be e.g. GDALAllRegister@0, as the functions use the "stdcall" (aka "pascal") calling convention. It works with the version of GDAL I have here (which I built from source), which for some reason seems to be using "ccall" (the symbols don't have the @<size> suffix).

I'm using at the moment the precompiled gdal-16 provided by the osgeo4w-stack and no self compiled gdal.

You could try using "make GDAL_DYNAMIC=" to link libgis directly against GDAL, rather than using LoadLibrary().

I'm using at moment the predefined options in package.sh (\grass64svn\mswindows\osgeo4w)

./configure \
		--with-libs="$OSGEO4W_ROOT_MSYS/apps/gdal-16/lib $OSGEO4W_ROOT_MSYS/lib" \
		--with-includes="$OSGEO4W_ROOT_MSYS/apps/gdal-16/include $OSGEO4W_ROOT_MSYS/include" \
		--exec-prefix=$OSGEO4W_ROOT_MSYS/bin \
		--libexecdir=$OSGEO4W_ROOT_MSYS/bin \
		--prefix=$OSGEO4W_ROOT_MSYS/apps/grass \
		--includedir=$OSGEO4W_ROOT_MSYS/include \
		--disable-x --without-x \
		--with-cxx \
		--enable-shared \
		--enable-largefile \
		--with-opengl=windows \
		--with-fftw \
		--with-freetype \
		--with-proj-share=$OSGEO4W_ROOT_MSYS/share/proj \
		--with-gdal=$OSGEO4W_ROOT_MSYS/bin/gdal-config \
		--with-tcltk \
		--with-sqlite \
		--with-postgres \
		--with-curses \
		--with-regex \
		--with-nls \
		--without-swig \
		--with-freetype-includes=$OSGEO4W_ROOT_MSYS/include/freetype2 \
		--with-odbc
[...]
echo $(date): STARTING make
make || make
[...]

what would be the exact "GDAL_DYNAMIC" options so I could try this way?

To make it work with a stdcall version of GDAL, I need to know the decorated names.

because I'm compiled gdal provided by osgeo4w, I'm not able to get the decorated names, right?

OTOH, it may be better to simply omit the r.external support from 6.5; it's very out of date (it was back-ported shortly after the first draft of the code was added to 7.0, and hasn't been updated since).

I think, r.external is very useful.

Helmut

[neteler]

Am I right that the involved files are

grass70/lib/raster/gdal.c

and

grass70/raster/r.external/main.c

? I would suggest to tag this as 6.4.1 milestone.

Markus

[glynn]

Replying to neteler:

Am I right that the involved files are grass70/lib/raster/gdal.c and grass70/raster/r.external/main.c

Only the first one; r.external links directly against GDAL.

? I would suggest to tag this as 6.4.1 milestone.

If this isn't fixed in time, the 6.4.0 needs to be built without GDAL_DYNAMIC. Otherwise, r.external will exist and will appear to work but "linked" maps won't actually work.

[glynn]

Replying to hellik:

what would be the exact "GDAL_DYNAMIC" options so I could try this way?

There isn't a configure option for it; you need to use

make GDAL_DYNAMIC=

to override the setting in lib/gis/Makefile.

To make it work with a stdcall version of GDAL, I need to know the decorated names.

because I'm compiled gdal provided by osgeo4w, I'm not able to get the decorated names, right?

Try running "nm" on r.in.gdal.

[neteler]

Replying to glynn:

Replying to neteler:

Am I right that the involved files are grass70/lib/raster/gdal.c and grass70/raster/r.external/main.c

Only the first one; r.external links directly against GDAL.

It seems that gdal.c depends on lib/gis/counter.c which isn't in 6.x. Add that as well?

[glynn]

Replying to neteler:

It seems that gdal.c depends on lib/gis/counter.c which isn't in 6.x. Add that as well?

That's overkill; I would just add the following to gdal.c:

static int G_is_initialized(int *p)
{
    return *p;
}

static void G_initialize_done(int *p)
{
    *p = 1;
}

counter.c was added to 7.0 to support multi-threaded code, which wouldn't work in 6.x without a lot of other changes.

[hellik]

Replying to glynn: [...]

To make it work with a stdcall version of GDAL, I need to know the decorated names.

because I'm compiled gdal provided by osgeo4w, I'm not able to get the decorated names, right?

Try running "nm" on r.in.gdal.

I couldn't find nm for mingw/msys/gnuwin32 on the net... :o(

LibDump? (Similar to Microsoft's DumpBin? utility ...) isn't working on my WinVista?32-box ...

for DumpBin? ... there have to be installed 1,3 GB for MS SDK :o(

by Dependency Walker there is following output for the functions

GDALGetColorInterpretationName
_GDALAllRegister@0
_GDALGetColorEntryAsRGB@12
_GDALGetColorEntryCount@4
_GDALGetDatasetDriver@4
_GDALGetDriver@4
_GDALGetDriverCount@0
_GDALGetDriverLongName@4
_GDALGetDriverShortName@4
_GDALGetGCPCount@4
_GDALGetGCPProjection@4
_GDALGetGCPs@4
_GDALGetGeoTransform@8
_GDALGetMetadataItem@12
_GDALGetProjectionRef@4
_GDALGetRasterBand@8
_GDALGetRasterBandXSize@4
_GDALGetRasterBandYSize@4
_GDALGetRasterColorInterpretation@4
_GDALGetRasterColorTable@4
_GDALGetRasterCount@4
_GDALGetRasterDataType@4
_GDALGetRasterNoDataValue@8
_GDALGetRasterXSize@4
_GDALGetRasterYSize@4
_GDALOpen@8
_GDALRasterIO@48

i don't know if above information is helpfull for this issue.

but it's maybe interesting ...

./configure \
		--with-libs="$OSGEO4W_ROOT_MSYS/apps/gdal-16/lib $OSGEO4W_ROOT_MSYS/lib" \
		--with-includes="$OSGEO4W_ROOT_MSYS/apps/gdal-16/include $OSGEO4W_ROOT_MSYS/include" \
[...]

in the output from Dependency Walker there is gdal15 mentioned (see screenshot)

Helmut

[hellik]

Dependency Walker output

[hellik]

Replying to hellik:

i don't know if above information is helpfull for this issue. but it's maybe interesting ... {{{ ./configure \ --with-libs="$OSGEO4W_ROOT_MSYS/apps/gdal-16/lib $OSGEO4W_ROOT_MSYS/lib" \ --with-includes="$OSGEO4W_ROOT_MSYS/apps/gdal-16/include $OSGEO4W_ROOT_MSYS/include" \ [...] }}} in the output from Dependency Walker there is gdal15 mentioned (see screenshot)

... for completness

./configure \
		--with-libs="$OSGEO4W_ROOT_MSYS/apps/gdal-16/lib $OSGEO4W_ROOT_MSYS/lib" \
		--with-includes="$OSGEO4W_ROOT_MSYS/apps/gdal-16/include $OSGEO4W_ROOT_MSYS/include" \
[...]
--with-gdal=$OSGEO4W_ROOT_MSYS/bin/gdal-config \

so maybe there is some mixing of gdal15 and gdal16 of the osgeo4w-stack during compiling?

Helmut

[neteler]

Replying to glynn:

Replying to neteler:

It seems that gdal.c depends on lib/gis/counter.c which isn't in 6.x. Add that as well?

That's overkill; I would just add the following to gdal.c:

...

counter.c was added to 7.0 to support multi-threaded code, which wouldn't work in 6.x without a lot of other changes.

Done so - see attached diff. I am now stuck with these compile error:

gdal.c: In function ‘G_create_gdal_link’:
gdal.c:366: warning: implicit declaration of function ‘G__init’
gdal.c:393: error: ‘struct G__’ has no member named ‘nbytes’

Markus

[glynn]

Replying to hellik:

I couldn't find nm for mingw/msys/gnuwin32 on the net... :o(

It should be part of the core MinGW package (it's part of binutils).

in the output from Dependency Walker there is gdal15 mentioned (see screenshot)

The following change makes linked maps work with the GDAL library from OSGeo4W:

Index: gdal.c
===================================================================
--- gdal.c	(revision 40542)
+++ gdal.c	(working copy)
@@ -102,11 +102,19 @@
 {
     load_library();
 
+# ifdef _WIN32
+    pGDALAllRegister   = get_symbol("_GDALAllRegister@0");
+    pGDALOpen          = get_symbol("_GDALOpen@8");
+    pGDALClose         = get_symbol("_GDALClose@4");
+    pGDALGetRasterBand = get_symbol("_GDALGetRasterBand@8");
+    pGDALRasterIO      = get_symbol("_GDALRasterIO@48");
+#else
     pGDALAllRegister   = get_symbol("GDALAllRegister");
     pGDALOpen          = get_symbol("GDALOpen");
     pGDALClose         = get_symbol("GDALClose");
     pGDALGetRasterBand = get_symbol("GDALGetRasterBand");
     pGDALRasterIO      = get_symbol("GDALRasterIO");
+#endif
 }
 
 #else /* GDAL_DYNAMIC */

However: this would probably need to change for a 64-bit version of GDAL, as the sizes of the various types are different (does 64-bit even use stdcall? IIRC, it was originally chosen due to it reducing code size, but that was back in the days of "640K is more than enough for any application").

Also, the example given  here doesn't use a decorated name, even though this is the standard for all Windows system functions (except for variadic functions, which have to use ccall).

[glynn]

Replying to neteler:

Done so - see attached diff. I am now stuck with these compile error:

gdal.c: In function ‘G_create_gdal_link’:
gdal.c:366: warning: implicit declaration of function ‘G__init’
gdal.c:393: error: ‘struct G__’ has no member named ‘nbytes’

R__init() is the equivalent of G__gisinit() for the raster library; it shouldn't be necessary in 6.x.

The 6.x equivalent of R__.nbytes is the static variable NBYTES in opencell.c, which is set by G_set_cell_format(). In 6.x, it isn't possible to get at this setting from gdal.c.

I'd suggest sync'ing any changes to the functions which are already in 6.x (i.e. G_get_gdal_link(), G_close_gdal_link(), and G_gdal_raster_IO()) to ensure that linked maps are compatible between the two versions, and not bothering about the write support (which won't work without also sync'ing the corresponding changes to G_open_*_new() and G_put_*_row(), which is probably unrealistic given the divergence between 6.x and 7.0 in the raster code).

[hellik]

Replying to glynn: [...]

The following change makes linked maps work with the GDAL library from OSGeo4W:

> {{{
> Index: gdal.c
> ===================================================================
> --- gdal.c	(revision 40542)
> +++ gdal.c	(working copy)
> @@ -102,11 +102,19 @@
>  {
>      load_library();
>  
> +# ifdef _WIN32
> +    pGDALAllRegister   = get_symbol("_GDALAllRegister@0");
> +    pGDALOpen          = get_symbol("_GDALOpen@8");
> +    pGDALClose         = get_symbol("_GDALClose@4");
> +    pGDALGetRasterBand = get_symbol("_GDALGetRasterBand@8");
> +    pGDALRasterIO      = get_symbol("_GDALRasterIO@48");
> +#else
>      pGDALAllRegister   = get_symbol("GDALAllRegister");
>      pGDALOpen          = get_symbol("GDALOpen");
>      pGDALClose         = get_symbol("GDALClose");
>      pGDALGetRasterBand = get_symbol("GDALGetRasterBand");
>      pGDALRasterIO      = get_symbol("GDALRasterIO");
> +#endif
>  }
>  
>  #else /* GDAL_DYNAMIC */
> }}}

I've tried above in a fresh Grass64svn, the original error message "Error: Unable to locate symbol <GDALAllRegister>" dissapears, but d.rast is still crashing

GRASS 6.4.0svn (nc_spm_08):c:/ > d.rast -o map=TestLinkRaster
WARNUNG: c:/OSGeo4W/apps/grass/grass-6.4.0svn/etc/fontcap: Keine
         Zeichensatz-Definitionsdatei gefunden
PNG: GRASS_TRUECOLOR status: FALSE
PNG: collecting to file: map.png,
GRASS_WIDTH=640, GRASS_HEIGHT=480
D2/3: G__read_Cell_head
D2/3: G__read_Cell_head_array
D3/3: region item: proj:       99
D3/3: region item: zone:       0
D3/3: region item: north:      228500
D3/3: region item: south:      215000
D3/3: region item: east:       645000
D3/3: region item: west:       630000
D3/3: region item: cols:       1500
D3/3: region item: rows:       1350
D3/3: region item: e-w resol:  10
D3/3: region item: n-s resol:  10
D3/3: region item: top:        1
D3/3: region item: bottom:     0
D3/3: region item: cols3:      1500
D3/3: region item: rows3:      1350
D3/3: region item: depths:     1
D3/3: region item: e-w resol3: 10
D3/3: region item: n-s resol3: 10
D3/3: region item: t-b resol:  1
D2/3: G__read_Cell_head
D2/3: G__read_Cell_head_array
D3/3: region item: proj:       99
D3/3: region item: zone:       0
D3/3: region item: north:      228500
D3/3: region item: south:      215000
D3/3: region item: east:       645000
D3/3: region item: west:       630000
D3/3: region item: cols:       1500
D3/3: region item: rows:       1350
D3/3: region item: e-w resol:  10
D3/3: region item: n-s resol:  10
D3/3: region item: format:     -1
D3/3: region item: compressed: 0
D3/3: create window mapping (1500 columns)

[hellik]

Replying to hellik:

configure in /mswindows/osgeo4w/package.sh with follwing options

./configure \
--with-libs="$OSGEO4W_ROOT_MSYS/apps/gdal-16/lib $OSGEO4W_ROOT_MSYS/lib" \
--with-includes="$OSGEO4W_ROOT_MSYS/apps/gdal-16/include $OSGEO4W_ROOT_MSYS/include" \
[...]
--with-gdal=$OSGEO4W_ROOT_MSYS/bin/gdal-config \
[...]

so maybe there is some mixing of gdal15 and gdal16 of the osgeo4w-stack during compiling?

with-libs and with-includes point to gdal16 (living in c/osgeo4w/apps/gdal-16/lib and c/osgeo4w/apps/gdal-16/include), but gdal-config (living in c/osgeo4w/bin) points to gdal15 (living in c/osgeo4w/bin, c/osgeo4w/lib, ...)

#!/bin/sh
CONFIG_LIBS="-L/c/OSGeo4W/lib -lgdal15"
CONFIG_DEP_LIBS="-L/c/OSGeo4W/lib -lpng -lz"
CONFIG_PREFIX="/c/OSGeo4W"
CONFIG_CFLAGS="-I/c/OSGeo4W/include"
CONFIG_VERSION="1.5.0"
CONFIG_OGR_ENABLED=yes
[...}

[hamish]

is there a copy of gdal-config in osgeo4w\apps\gdal-16 or similar?

if not, probably file a bug against the package,

 https://trac.osgeo.org/osgeo4w/wiki/pkg-gdal16

Hamish

[hellik]

Replying to hamish:

is there a copy of gdal-config in osgeo4w\apps\gdal-16 or similar? if not, probably file a bug against the package,  https://trac.osgeo.org/osgeo4w/wiki/pkg-gdal16 Hamish

there is only a file called gdal-config.tmpl in osgeo4w\apps\gdal-16\bin, but its content it's not uptodate regarding to gdal16.

so i open a report at the osgeo4w-trac.

Helmut

[hellik]

Replying to glynn: [...]

There isn't a configure option for it; you need to use

make GDAL_DYNAMIC=

to override the setting in lib/gis/Makefile.

i've tested make GDAL_DYNAMIC= together with the patch for gdal.c, r.external is working and d.rast map=LinkedRaster? is working in the wx-gui.

is "make GDAL_DYNAMIC=" maybe interfering with other things and should this be turned on for Grass64?

Helmut

[glynn]

Replying to hellik:

i've tested make GDAL_DYNAMIC= together with the patch for gdal.c, r.external is working and d.rast map=LinkedRaster is working in the wx-gui. is "make GDAL_DYNAMIC=" maybe interfering with other things and should this be turned on for Grass64?

The support for loading GDAL dynamically was added to prevent GDAL from becoming a critical dependency. If GDAL is linked at compile time, any linkage errors for GDAL would make GRASS entirely unusable.

And GDAL is a very heavy-weight dependency; on my system, libgdal.so has 32 dependencies, and that's with some of the less common formats disabled.

OTOH, given that programs such as g.region and g.proj require it, it's essentially a critical dependency already.

[neteler]

Replying to glynn:

Replying to neteler:

Done so - see attached diff. I am now stuck with these compile error:

{{{ gdal.c: In function ‘G_create_gdal_link’: gdal.c:366: warning: implicit declaration of function ‘Ginit’ gdal.c:393: error: ‘struct G’ has no member named ‘nbytes’ }}} R__init() is the equivalent of G__gisinit() for the raster library; it shouldn't be necessary in 6.x. The 6.x equivalent of R__.nbytes is the static variable NBYTES in opencell.c, which is set by G_set_cell_format(). In 6.x, it isn't possible to get at this setting from gdal.c. I'd suggest sync'ing any changes to the functions which are already in 6.x (i.e. G_get_gdal_link(), G_close_gdal_link(), and G_gdal_raster_IO()) to ensure that linked maps are compatible between the two versions, and not bothering about the write support (which won't work without also sync'ing the corresponding changes to G_open_*_new() and G_put_*_row(), which is probably unrealistic given the divergence between 6.x and 7.0 in the raster code).

This is somewhat too complex for me. I have attached the latest patch against the reformatted & submitted older version of lib/gis/gdal.c and related files. Not sure what to take out/substitute.

Markus

[hellik]

Replying to glynn:

{{{ Index: gdal.c =================================================================== --- gdal.c (revision 40542) +++ gdal.c (working copy) @@ -102,11 +102,19 @@ { load_library(); +# ifdef _WIN32 + pGDALAllRegister = get_symbol("_GDALAllRegister@0"); + pGDALOpen = get_symbol("_GDALOpen@8"); + pGDALClose = get_symbol("_GDALClose@4"); + pGDALGetRasterBand = get_symbol("_GDALGetRasterBand@8"); + pGDALRasterIO = get_symbol("_GDALRasterIO@48"); +#else pGDALAllRegister = get_symbol("GDALAllRegister"); pGDALOpen = get_symbol("GDALOpen"); pGDALClose = get_symbol("GDALClose"); pGDALGetRasterBand = get_symbol("GDALGetRasterBand"); pGDALRasterIO = get_symbol("GDALRasterIO"); +#endif } #else /* GDAL_DYNAMIC */ }}}

patch applied by r40741 to Grass64 (see r40714)

[neteler]

Attempt for backport from GRASS 7

[neteler]

New patch attached for testing. The write functionality has been removed from my previous patch upon offlist suggestion from Glynn.

Markus

[hellik]

Replying to neteler:

New patch attached for testing. The write functionality has been removed from my previous patch upon offlist suggestion from Glynn. Markus

i've tested the patch with a fresh-Grass64svn-checkout and default options in /mswindows/osego4w/package.sh (so no GDAL_DYNAMIC=).

export nc-spm-elevation-data by r.out.gdal and linking by r.external are working, but "d.rast -o map=externRlink" crashes with error "Unable to load GDAL library". GDAL_DYNAMIC= turned on, d.rast the linked external raster is working.

Helmut

[glynn]

Replying to neteler:

New patch attached for testing. The write functionality has been removed from my previous patch upon offlist suggestion from Glynn.

AFAICT, the patch is almost entirely unnecessary. The only necessary part seems to be the removal of lines 22-23 (regarding CPL_STDCALL). I've committed this in r40757.

The extra functions (GDALCreate etc) are only necessary for the write support, as is "struct GDAL_Options" and the declaration for G_create_gdal_link().

The references to gdal15.dll and gdal16.dll should be forward-ported to 7.0 rather than removed from 6.x. Done in r40758.

[neteler]

Replying to glynn:

Replying to neteler:

New patch attached for testing. The write functionality has been removed from my previous patch upon offlist suggestion from Glynn.

AFAICT, the patch is almost entirely unnecessary. The only necessary part seems to be the removal of lines 22-23 (regarding CPL_STDCALL). I've committed this in r40757.

Backported to 6.4.

As it stands, the current gdal.c in 6.4 should be functional and the patch attached here can be ignored. Please test current gdal.c in 6.4.svn on Windows.

Markus

[neteler]

Sincerely, I am a bit confused here. According to the change history nothing but the decorated names being added and the CPL_STDCALL lines being removed has been changed:

 https://trac.osgeo.org/grass/log/grass/branches/releasebranch_6_4/lib/gis/gdal.c

I don't see any particular backport from GRASS 7 so far.

[glynn]

Replying to neteler:

Sincerely, I am a bit confused here. According to the change history nothing but the decorated names being added and the CPL_STDCALL lines being removed has been changed:

That's correct.

The remaining differences between 6.x and 7.0 are due to 7.0 allowing new raster maps to be written via GDAL (r.external.out). Back-porting this feature would require back-porting the corresponding changes to the open_new and put_row code, which isn't feasible; the raster I/O code has diverged too much between 6.x and 7.0.

Regarding my comments in comment:1 :

OTOH, it may be better to simply omit the r.external support from 6.5; it's very out of date (it was back-ported shortly after the first draft of the code was added to 7.0, and hasn't been updated since).

It turns out that the read support hasn't actually changed significantly, and back-porting the write support isn't really an option.

[hellik]

Replying to glynn:

Regarding my comments in comment:1 :

OTOH, it may be better to simply omit the r.external support from 6.5; it's very out of date (it was back-ported shortly after the first draft of the code was added to 7.0, and hasn't been updated since).

It turns out that the read support hasn't actually changed significantly, and back-porting the write support isn't really an option.

fresh grass65svn (r40780), self compiled with default configure options in /mswindows/osgeo4w/package.sh

=>"d.rast -o map=testRlink@user1" is working and the linked testRlink-data is displayed in the wx-gui!

what is the difference between Grass64 and Grass65 in this case?

maybe anyone else can test the nightly builts of Grass64 and Grass65 for this issue?

r.info map=testRlink@user1                                                      
Kategorie Unterstützung für [testRlink@user1] im Mapset [user1] missing
 +----------------------------------------------------------------------------+
 | Layer:    testRlink@user1                Date: Tue Feb 02 20:23:46 2010    |
 | Mapset:   user1                          Login of Creator: syringia        |
 | Location: nc_spm_08                                                        |
 | DataBase: C:\gisdata\grassdata                                             |
 | Title:    ?? ( testRlink )                                                 |
 | Timestamp: none                                                            |
 |----------------------------------------------------------------------------|
 |                                                                            |
 |   Type of Map:  raster               Number of Categories: ??              |
 |   Data Type:    FCELL                                                      |
 |   Rows:         1350                                                       |
 |   Columns:      1500                                                       |
 |   Total Cells:  2025000                                                    |
 |        Projection: Lambert Conformal Conic                                 |
 |            N:     228500    S:     215000   Res:    10                     |
 |            E:     645000    W:     630000   Res:    10                     |
 |   Range of data:    min = 55.98819  max = 155.9353                         |
 |                                                                            |
 |   Data Description:                                                        |
 |    generated by r.external                                                 |
 |                                                                            |
 |   Comments:                                                                |
 |    r.external input="C:\wd\mg\elev_export.tif" output="testRlink" band=1   |
 |                                                                            |
 +----------------------------------------------------------------------------+

Helmut

[hellik]

Replying to hellik:

Grass65 =>"d.rast -o map=testRlink@user1" is working and the linked testRlink-data is displayed in the wx-gui! what is the difference between Grass64 and Grass65 in this case? maybe anyone else can test the nightly builts of Grass64 and Grass65 for this issue?

tested with the nightly build WinGRASS-6.4.SVN-r40852-1-Setup.exe on a

WinXP32, displaying the linked raster in the wxgui is working.

Helmut

[neteler]

Closing since reported issue is fixed.