Opened 14 years ago
Closed 14 years ago
#885 closed defect (fixed)
WinGrass: displaying r.external-linked raster data not working
| Reported by: | hellik | Owned by: | |
|---|---|---|---|
| Priority: | critical | Milestone: | 6.4.0 |
| Component: | Display | Version: | svn-releasebranch64 |
| Keywords: | r.external, WinGrass, osgeo4w | Cc: | |
| CPU: | x86-32 | Platform: | MSWindows Vista |
Description
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
Attachments (2)
Change History (31)
follow-up: 2 comment:1 by , 14 years ago
follow-up: 5 comment:2 by , 14 years ago
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 usingLoadLibrary().
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
follow-up: 4 comment:3 by , 14 years ago
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
follow-up: 6 comment:4 by , 14 years ago
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.
follow-ups: 8 17 comment:5 by , 14 years ago
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.
follow-up: 7 comment:6 by , 14 years ago
follow-up: 10 comment:7 by , 14 years ago
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.
follow-ups: 9 11 comment:8 by , 14 years ago
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 WinVista32-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
follow-up: 14 comment:9 by , 14 years ago
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
follow-up: 12 comment:10 by , 14 years ago
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
follow-ups: 13 20 comment:11 by , 14 years ago
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).
follow-up: 19 comment:12 by , 14 years ago
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).
comment:13 by , 14 years ago
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)
comment:14 by , 14 years ago
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 [...}
follow-up: 16 comment:15 by , 14 years ago
| Keywords: | osgeo4w added |
|---|
is there a copy of gdal-config in osgeo4w\apps\gdal-16 or similar?
if not, probably file a bug against the package,
Hamish
comment:16 by , 14 years ago
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,
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
follow-up: 18 comment:17 by , 14 years ago
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
comment:18 by , 14 years ago
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.
comment:19 by , 14 years ago
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 ‘G__init’ gdal.c:393: error: ‘struct G__’ has no member named ‘nbytes’
R__init()is the equivalent ofG__gisinit()for the raster library; it shouldn't be necessary in 6.x.The 6.x equivalent of
R__.nbytesis the static variable NBYTES in opencell.c, which is set byG_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(), andG_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 toG_open_*_new()andG_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
comment:20 by , 14 years ago
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 */
follow-ups: 22 23 comment:21 by , 14 years ago
New patch attached for testing. The write functionality has been removed from my previous patch upon offlist suggestion from Glynn.
Markus
comment:22 by , 14 years ago
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
follow-up: 24 comment:23 by , 14 years ago
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.
comment:24 by , 14 years ago
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
follow-up: 26 comment:25 by , 14 years ago
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.
follow-up: 27 comment:26 by , 14 years ago
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.
follow-up: 28 comment:27 by , 14 years ago
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
comment:28 by , 14 years ago
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
comment:29 by , 14 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Closing since reported issue is fixed.
Replying to hellik:
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 usingLoadLibrary().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).