Closed rsbivand closed 11 months ago
System Info
GRASS Version: 7.8.6
Code revision: exported
Build date: 2021-10-11
Build platform: x86_64-w64-mingw32
GDAL: 3.3.1
PROJ: 8.1.1
GEOS: 3.9.1
SQLite: 3.35.2
Python: 3.9.5
wxPython: 4.1.1
Platform: Windows-10-10.0.19043-SP0 (OSGeo4W)
winGRASS windows console
g.proj -w
PROJCRS["NAD83(HARN) / North Carolina",
BASEGEOGCRS["NAD83(HARN)",
DATUM["NAD83 (High Accuracy Reference Network)",
ELLIPSOID["GRS 1980",6378137,298.257222101,
LENGTHUNIT["metre",1]]],
PRIMEM["Greenwich",0,
ANGLEUNIT["degree",0.0174532925199433]],
ID["EPSG",4152]],
CONVERSION["SPCS83 North Carolina zone (meters)",
METHOD["Lambert Conic Conformal (2SP)",
ID["EPSG",9802]],
PARAMETER["Latitude of false origin",33.75,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8821]],
PARAMETER["Longitude of false origin",-79,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8822]],
PARAMETER["Latitude of 1st standard parallel",36.1666666666667,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8823]],
PARAMETER["Latitude of 2nd standard parallel",34.3333333333333,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8824]],
PARAMETER["Easting at false origin",609601.22,
LENGTHUNIT["metre",1],
ID["EPSG",8826]],
PARAMETER["Northing at false origin",0,
LENGTHUNIT["metre",1],
ID["EPSG",8827]]],
CS[Cartesian,2],
AXIS["easting (X)",east,
ORDER[1],
LENGTHUNIT["metre",1]],
AXIS["northing (Y)",north,
ORDER[2],
LENGTHUNIT["metre",1]],
USAGE[
SCOPE["Engineering survey, topographic mapping."],
AREA["United States (USA) - North Carolina - counties of Alamance; Alexander; Alleghany; Anson; Ashe; Avery; Beaufort; Bertie; Bladen; Brunswick; Buncombe; Burke; Cabarrus; Caldwell; Camden; Carteret; Caswell; Catawba; Chatham; Cherokee; Chowan; Clay; Cleveland; Columbus; Craven; Cumberland; Currituck; Dare; Davidson; Davie; Duplin; Durham; Edgecombe; Forsyth; Franklin; Gaston; Gates; Graham; Granville; Greene; Guilford; Halifax; Harnett; Haywood; Henderson; Hertford; Hoke; Hyde; Iredell; Jackson; Johnston; Jones; Lee; Lenoir; Lincoln; Macon; Madison; Martin; McDowell; Mecklenburg; Mitchell; Montgomery; Moore; Nash; New Hanover; Northampton; Onslow; Orange; Pamlico; Pasquotank; Pender; Perquimans; Person; Pitt; Polk; Randolph; Richmond; Robeson; Rockingham; Rowan; Rutherford; Sampson; Scotland; Stanly; Stokes; Surry; Swain; Transylvania; Tyrrell; Union; Vance; Wake; Warren; Washington; Watauga; Wayne; Wilkes; Wilson; Yadkin; Yancey."],
BBOX[33.83,-84.33,36.59,-75.38]],
ID["EPSG",3358]]
=> output ok
GUI
(Sun Oct 24 10:18:22 2021)
g.proj -w
(Sun Oct 24 10:18:24 2021) Befehl ausgeführt (1 Sek)
=> no output
g.gisenv set=DEBUG=3
GUI
g.proj -w
D1/3: G_set_program_name(): g.proj
D2/3: G_file_name(): path =
D:\grassdata\nc_spm_08_grass7\PERMANENT\DEFAULT_WIND
D2/3: G_file_name(): path =
D:\grassdata\nc_spm_08_grass7\PERMANENT\DEFAULT_WIND
D2/3: file open: read (mode = r)
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: 320000
D3/3: region item: south: 10000
D3/3: region item: east: 935000
D3/3: region item: west: 120000
D3/3: region item: cols: 1630
D3/3: region item: rows: 620
D3/3: region item: e-w resol: 500
D3/3: region item: n-s resol: 500
D3/3: region item: top: 500
D3/3: region item: bottom: -500
D3/3: region item: cols3: 815
D3/3: region item: rows3: 310
D3/3: region item: depths: 10
D3/3: region item: e-w resol3: 1000
D3/3: region item: n-s resol3: 1000
D3/3: region item: t-b resol: 100
D2/3: G_file_name(): path =
D:\grassdata\nc_spm_08_grass7\PERMANENT\PROJ_SRID
D2/3: G_file_name(): path =
D:\grassdata\nc_spm_08_grass7\user1\WIND
D2/3: G_file_name(): path =
D:\grassdata\nc_spm_08_grass7\user1\WIND
D2/3: file open: read (mode = r)
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.000000000000000
D3/3: region item: bottom: 0.000000000000000
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
D1/3: <PROJ_SRID> file not found for location
<nc_spm_08_grass7>
D2/3: G_file_name(): path =
D:\grassdata\nc_spm_08_grass7\PERMANENT\PROJ_EPSG
D1/3: Using <PROJ_EPSG> file instead for location
<nc_spm_08_grass7>
D2/3: G_file_name(): path =
D:\grassdata\nc_spm_08_grass7\PERMANENT\PROJ_WKT
D1/3: <PROJ_WKT> file not found for location
<nc_spm_08_grass7>
D2/3: G_file_name(): path =
D:\grassdata\nc_spm_08_grass7\PERMANENT\PROJ_INFO
D2/3: G_file_name(): path =
D:\grassdata\nc_spm_08_grass7\PERMANENT\PROJ_EPSG
D2/3: G_file_name(): path =
D:\grassdata\nc_spm_08_grass7\PERMANENT\PROJ_UNITS
D3/3: GPJ__get_datum_params: datumname: <nad83>
D3/3: set_datumtrans(): GPJ__get_datum_params() status=1
D3/3: set_datumtrans(): datum transform terms found with 6
options
D3/3: set_datumtrans(): looking up available datum
transforms for <nad83>
(Sun Oct 24 10:22:13 2021) Befehl ausgeführt (1 Sek)
winGRASS windows console
g.proj -w
D1/3: G_set_program_name(): g.proj
D2/3: G_file_name(): path = D:\grassdata\nc_spm_08_grass7\PERMANENT\DEFAULT_WIND
D2/3: G_file_name(): path = D:\grassdata\nc_spm_08_grass7\PERMANENT\DEFAULT_WIND
D2/3: file open: read (mode = r)
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: 320000
D3/3: region item: south: 10000
D3/3: region item: east: 935000
D3/3: region item: west: 120000
D3/3: region item: cols: 1630
D3/3: region item: rows: 620
D3/3: region item: e-w resol: 500
D3/3: region item: n-s resol: 500
D3/3: region item: top: 500
D3/3: region item: bottom: -500
D3/3: region item: cols3: 815
D3/3: region item: rows3: 310
D3/3: region item: depths: 10
D3/3: region item: e-w resol3: 1000
D3/3: region item: n-s resol3: 1000
D3/3: region item: t-b resol: 100
D2/3: G_file_name(): path = D:\grassdata\nc_spm_08_grass7\PERMANENT\PROJ_SRID
D2/3: G_file_name(): path = D:\grassdata\nc_spm_08_grass7\user1\WIND
D2/3: G_file_name(): path = D:\grassdata\nc_spm_08_grass7\user1\WIND
D2/3: file open: read (mode = r)
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.000000000000000
D3/3: region item: bottom: 0.000000000000000
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
D1/3: <PROJ_SRID> file not found for location <nc_spm_08_grass7>
D2/3: G_file_name(): path = D:\grassdata\nc_spm_08_grass7\PERMANENT\PROJ_EPSG
D1/3: Using <PROJ_EPSG> file instead for location <nc_spm_08_grass7>
D2/3: G_file_name(): path = D:\grassdata\nc_spm_08_grass7\PERMANENT\PROJ_WKT
D1/3: <PROJ_WKT> file not found for location <nc_spm_08_grass7>
D2/3: G_file_name(): path = D:\grassdata\nc_spm_08_grass7\PERMANENT\PROJ_INFO
D2/3: G_file_name(): path = D:\grassdata\nc_spm_08_grass7\PERMANENT\PROJ_EPSG
D2/3: G_file_name(): path = D:\grassdata\nc_spm_08_grass7\PERMANENT\PROJ_UNITS
D3/3: GPJ__get_datum_params: datumname: <nad83>
D3/3: set_datumtrans(): GPJ__get_datum_params() status=1
D3/3: set_datumtrans(): datum transform terms found with 6 options
D3/3: set_datumtrans(): looking up available datum transforms for <nad83>
PROJCRS["NAD83(HARN) / North Carolina",
BASEGEOGCRS["NAD83(HARN)",
DATUM["NAD83 (High Accuracy Reference Network)",
ELLIPSOID["GRS 1980",6378137,298.257222101,
LENGTHUNIT["metre",1]]],
PRIMEM["Greenwich",0,
ANGLEUNIT["degree",0.0174532925199433]],
ID["EPSG",4152]],
CONVERSION["SPCS83 North Carolina zone (meters)",
METHOD["Lambert Conic Conformal (2SP)",
ID["EPSG",9802]],
PARAMETER["Latitude of false origin",33.75,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8821]],
PARAMETER["Longitude of false origin",-79,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8822]],
PARAMETER["Latitude of 1st standard parallel",36.1666666666667,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8823]],
PARAMETER["Latitude of 2nd standard parallel",34.3333333333333,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8824]],
PARAMETER["Easting at false origin",609601.22,
LENGTHUNIT["metre",1],
ID["EPSG",8826]],
PARAMETER["Northing at false origin",0,
LENGTHUNIT["metre",1],
ID["EPSG",8827]]],
CS[Cartesian,2],
AXIS["easting (X)",east,
ORDER[1],
LENGTHUNIT["metre",1]],
AXIS["northing (Y)",north,
ORDER[2],
LENGTHUNIT["metre",1]],
USAGE[
SCOPE["Engineering survey, topographic mapping."],
AREA["United States (USA) - North Carolina - counties of Alamance; Alexander; Alleghany; Anson; Ashe; Avery; Beaufort; Bertie; Bladen; Brunswick; Buncombe; Burke; Cabarrus; Caldwell; Camden; Carteret; Caswell; Catawba; Chatham; Cherokee; Chowan; Clay; Cleveland; Columbus; Craven; Cumberland; Currituck; Dare; Davidson; Davie; Duplin; Durham; Edgecombe; Forsyth; Franklin; Gaston; Gates; Graham; Granville; Greene; Guilford; Halifax; Harnett; Haywood; Henderson; Hertford; Hoke; Hyde; Iredell; Jackson; Johnston; Jones; Lee; Lenoir; Lincoln; Macon; Madison; Martin; McDowell; Mecklenburg; Mitchell; Montgomery; Moore; Nash; New Hanover; Northampton; Onslow; Orange; Pamlico; Pasquotank; Pender; Perquimans; Person; Pitt; Polk; Randolph; Richmond; Robeson; Rockingham; Rowan; Rutherford; Sampson; Scotland; Stanly; Stokes; Surry; Swain; Transylvania; Tyrrell; Union; Vance; Wake; Warren; Washington; Watauga; Wayne; Wilkes; Wilson; Yadkin; Yancey."],
BBOX[33.83,-84.33,36.59,-75.38]],
ID["EPSG",3358]]
@metzm @landam any idea about different g.proj -w
behaviour between GUI and windows console?
Do the other print options work with g.proj
?
Googling a bit I found that "It is basically related to your Windows registry. Sometimes due to missing registry files or dll files, our application starts crashing with error code 884."
Further testing could be done with gdalsrsinfo
and projinfo
with e.g. EPSG:3358 (the NC EPSG code).
Do the other print options work with
g.proj
? Googling a bit I found that "It is basically related to your Windows registry. Sometimes due to missing registry files or dll files, our application starts crashing with error code 884." Further testing could be done withgdalsrsinfo
andprojinfo
with e.g. EPSG:3358 (the NC EPSG code).
(Sun Oct 24 20:15:41 2021)
g.proj -p
-PROJ_INFO-------------------------------------------------
name : Lambert Conformal Conic
proj : lcc
datum : nad83
a : 6378137.0
es : 0.006694380022900787
lat_1 : 36.16666666666666
lat_2 : 34.33333333333334
lat_0 : 33.75
lon_0 : -79
x_0 : 609601.22
y_0 : 0
no_defs : defined
-PROJ_SRID-------------------------------------------------
SRID : EPSG:3358
-PROJ_UNITS------------------------------------------------
unit : Meter
units : Meters
meters : 1
(Sun Oct 24 20:15:41 2021) Befehl ausgeführt (0 Sek)
(Sun Oct 24 20:15:51 2021)
g.proj -g
name=Lambert Conformal Conic
proj=lcc
datum=nad83
a=6378137.0
es=0.006694380022900787
lat_1=36.16666666666666
lat_2=34.33333333333334
lat_0=33.75
lon_0=-79
x_0=609601.22
y_0=0
no_defs=defined
srid=EPSG:3358
unit=Meter
units=Meters
meters=1
(Sun Oct 24 20:15:51 2021) Befehl ausgeführt (0 Sek)
(Sun Oct 24 20:16:01 2021)
g.proj -d
GRASS datum code: nad83
WKT Name: North_American_Datum_1983
Datum parameters not present; default for nad83 is:
towgs84=0.000,0.000,0.000
(Sun Oct 24 20:16:02 2021) Befehl ausgeführt (0 Sek)
(Sun Oct 24 20:16:12 2021)
g.proj -j
+proj=lcc
+lat_0=33.75
+lon_0=-79
+lat_1=36.1666666666667
+lat_2=34.3333333333333
+x_0=609601.22
+y_0=0
+ellps=GRS80
+units=m
+no_defs
+type=crs
(Sun Oct 24 20:16:13 2021) Befehl ausgeführt (0 Sek)
(Sun Oct 24 20:16:29 2021)
g.proj -w
(Sun Oct 24 20:16:31 2021) Befehl ausgeführt (2 Sek)
(Sun Oct 24 20:16:40 2021)
g.proj -e
(Sun Oct 24 20:16:41 2021) Befehl ausgeführt (1 Sek)
(Sun Oct 24 20:16:53 2021)
g.proj -w -e
(Sun Oct 24 20:16:54 2021) Befehl ausgeführt (1 Sek)
no crash here.
tested above in the GUI.
the mysterious thing is: g.proj -w
produces the correct output in the winGRASS provided windows console, but not in the GUI (see above) and
(Sun Oct 24 20:16:29 2021)
g.proj -w
(Sun Oct 24 20:16:31 2021) Befehl ausgeführt (2 Sek)
that's the output in the winGRASS windows console:
C:\Users\myuser\Documents>g.proj -w
PROJCRS["NAD83(HARN) / North Carolina",
BASEGEOGCRS["NAD83(HARN)",
DATUM["NAD83 (High Accuracy Reference Network)",
ELLIPSOID["GRS 1980",6378137,298.257222101,
LENGTHUNIT["metre",1]]],
PRIMEM["Greenwich",0,
ANGLEUNIT["degree",0.0174532925199433]],
ID["EPSG",4152]],
CONVERSION["SPCS83 North Carolina zone (meters)",
METHOD["Lambert Conic Conformal (2SP)",
ID["EPSG",9802]],
PARAMETER["Latitude of false origin",33.75,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8821]],
PARAMETER["Longitude of false origin",-79,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8822]],
PARAMETER["Latitude of 1st standard parallel",36.1666666666667,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8823]],
PARAMETER["Latitude of 2nd standard parallel",34.3333333333333,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8824]],
PARAMETER["Easting at false origin",609601.22,
LENGTHUNIT["metre",1],
ID["EPSG",8826]],
PARAMETER["Northing at false origin",0,
LENGTHUNIT["metre",1],
ID["EPSG",8827]]],
CS[Cartesian,2],
AXIS["easting (X)",east,
ORDER[1],
LENGTHUNIT["metre",1]],
AXIS["northing (Y)",north,
ORDER[2],
LENGTHUNIT["metre",1]],
USAGE[
SCOPE["Engineering survey, topographic mapping."],
AREA["United States (USA) - North Carolina - counties of Alamance; Alexander; Alleghany; Anson; Ashe; Avery; Beaufort; Bertie; Bladen; Brunswick; Buncombe; Burke; Cabarrus; Caldwell; Camden; Carteret; Caswell; Catawba; Chatham; Cherokee; Chowan; Clay; Cleveland; Columbus; Craven; Cumberland; Currituck; Dare; Davidson; Davie; Duplin; Durham; Edgecombe; Forsyth; Franklin; Gaston; Gates; Graham; Granville; Greene; Guilford; Halifax; Harnett; Haywood; Henderson; Hertford; Hoke; Hyde; Iredell; Jackson; Johnston; Jones; Lee; Lenoir; Lincoln; Macon; Madison; Martin; McDowell; Mecklenburg; Mitchell; Montgomery; Moore; Nash; New Hanover; Northampton; Onslow; Orange; Pamlico; Pasquotank; Pender; Perquimans; Person; Pitt; Polk; Randolph; Richmond; Robeson; Rockingham; Rowan; Rutherford; Sampson; Scotland; Stanly; Stokes; Surry; Swain; Transylvania; Tyrrell; Union; Vance; Wake; Warren; Washington; Watauga; Wayne; Wilkes; Wilson; Yadkin; Yancey."],
BBOX[33.83,-84.33,36.59,-75.38]],
ID["EPSG",3358]]
maybe WKT not handled in the python GUI?
Attached CSV from ProcessMonitor (which is not obvious for me, I'm afraid I know little of Windows internals https://docs.microsoft.com/en-us/sysinternals/downloads/procmon) on running g.proj -w
in demolocation for 7.8.6 stand-alone GUI console, and reporting only RESULTS != SUCCESS
, for g.proj
only:
Logfile_g.proj_GUI_console_RESULT_not_SUCCESS.CSV
I don't think it is just Python as the same problem exists in R (rgrass7::getLocationProj()
), for WinGRASS and OSGeo4W.
In another context we've seen sf and rgdal having problems with PROJ_NETWORK
on Windows (UCRT project), and the reference to procmon was suggested in thaat connection to try to see whether openssl or similar from Proj's curl dependency wasn't having certificate issues (unresolved at the moment for R on UCRT, works with CRT/winlib R builds).
Thanks @rsbivand for the CSV file! I found
C:\Program Files\GRASS GIS 7.8\bin\g.proj.exe BUFFER OVERFLOW
this can explain the problems, also why it sometimes work, sometimes not, and should be easy to fix.
Thanks @rsbivand for the CSV file! I found
C:\Program Files\GRASS GIS 7.8\bin\g.proj.exe BUFFER OVERFLOW
this can explain the problems, also why it sometimes work, sometimes not, and should be easy to fix.
Wrong track, according to valgrind there is no buffer overflow in g.proj
.
Inspired by https://github.com/rsbivand/rgrass7/issues/33 is it possible that the Python GUI for WinGRASS and OSGeo4W GRASS pulls in a different version of GDAL or PROJ?
Thanks @rsbivand for the CSV file! I found
C:\Program Files\GRASS GIS 7.8\bin\g.proj.exe BUFFER OVERFLOW
this can explain the problems, also why it sometimes work, sometimes not, and should be easy to fix.Wrong track, according to valgrind there is no buffer overflow in
g.proj
.Inspired by rsbivand/rgrass7#33 is it possible that the Python GUI for WinGRASS and OSGeo4W GRASS pulls in a different version of GDAL or PROJ?
C:\OSGeo4W\bin>dir /b | findstr gdal
gdal302.dll
gdal303.dll
gdaladdo.exe
gdalbuildvrt.exe
gdaldem.exe
gdalenhance.exe
gdalinfo.exe
gdallocationinfo.exe
gdalmanage.exe
gdalmdiminfo.exe
gdalmdimtranslate.exe
gdalplugins
gdalsrsinfo.exe
gdaltindex.exe
gdaltransform.exe
gdalwarp.exe
gdal_contour.exe
gdal_create.exe
gdal_grid.exe
gdal_rasterize.exe
gdal_translate.exe
gdal_viewshed.exe
g.version -b
GRASS 7.8.6 (2021)
./configure
[...]
--with-gdal=/d/src/osgeo4w/src/grass/grass-7.8.6/mswindows/osgeo4w/gdal-config
System Info
GRASS Version: 7.8.6
Code revision: exported
Build date: 2021-10-11
Build platform: x86_64-w64-mingw32
GDAL: 3.3.1
C:\OSGeo4W\bin>dir /b | findstr proj_
proj_7_2.dll
proj_8_0.dll
proj_8_1.dll
Maybe related to: #1872 ?
Maybe related to: #1872 ?
could be
With latest GRASS 7.8.6-6 from OSGeo4W the following R
line returns fine:
rgrass7::getLocationProj()
[1] "+proj=longlat +datum=WGS84 +no_defs +type=crs"
However, g.proj -w
and g.proj -e
still do not work in the GUI, while all other output formats work...
This OSGeo4W output is not fine, and only signals that the use of the fallback g.proj -j
as g.proj -w
fails as it has for a long time, previously because proj.db
shipping with rgdal and sf (PROJ 7.2.1) differed from that shipping with OSGeo4W (and GRASS standalone).
Why GRASS and OSGeo4W mandate download and installation of proj_data at 0.5GB remains a mystery with a large carbon footprint, so I cannot cross-check until that download completes.
Debugging output from 7.8.6-6 and rgrass7 with fall-back workaround:
Browse[2]>
debug: res <- paste(execGRASS("g.proj", flags = c("w"),
intern = TRUE, ignore.stderr = ignore.stderr), collapse = "\n")
Browse[2]>
debug: if (substr(res, 1, 5) != "ERROR") {
if (nchar(res) == 0L) {
res <- paste(execGRASS("g.proj", flags = c("j"),
intern = TRUE, ignore.stderr = ignore.stderr), collapse = " ")
}
return(res)
}
Warning message:
In system(syscmd, intern = intern, ignore.stderr = ignore.stderr, :
running command 'g.proj.exe -w' had status 884
Browse[2]> res
[1] ""
Browse[2]>
debug: if (nchar(res) == 0L) {
res <- paste(execGRASS("g.proj", flags = c("j"),
intern = TRUE, ignore.stderr = ignore.stderr), collapse = " ")
}
Browse[2]>
debug: res <- paste(execGRASS("g.proj", flags = c("j"),
intern = TRUE, ignore.stderr = ignore.stderr), collapse = " ")
Browse[2]>
debug: return(res)
Browse[2]>
exiting from: getLocationProj()
[1] "+proj=longlat +a=6378137 +rf=298.257223563 +no_defs +towgs84=0.000,0.000,0.000 +type=crs "
>
Note:
running command 'g.proj.exe -w' had status 884
so the same error status that we started with. You can also get the same outcome if rgdal is not installed.
OK, so this is what is returned in Python:
p = gscript.run_command("g.proj", flags="w")
PROJCRS["ETRS89 / UTM zone 33N",
BASEGEOGCRS["ETRS89",
ENSEMBLE["European Terrestrial Reference System 1989 ensemble",
MEMBER["European Terrestrial Reference Frame 1989"],
MEMBER["European Terrestrial Reference Frame 1990"],
MEMBER["European Terrestrial Reference Frame 1991"],
MEMBER["European Terrestrial Reference Frame 1992"],
MEMBER["European Terrestrial Reference Frame 1993"],
MEMBER["European Terrestrial Reference Frame 1994"],
MEMBER["European Terrestrial Reference Frame 1996"],
MEMBER["European Terrestrial Reference Frame 1997"],
MEMBER["European Terrestrial Reference Frame 2000"],
MEMBER["European Terrestrial Reference Frame 2005"],
MEMBER["European Terrestrial Reference Frame 2014"],
ELLIPSOID["GRS 1980",6378137,298.257222101,
LENGTHUNIT["metre",1]],
ENSEMBLEACCURACY[0.1]],
PRIMEM["Greenwich",0,
ANGLEUNIT["degree",0.0174532925199433]],
ID["EPSG",4258]],
CONVERSION["UTM zone 33N",
METHOD["Transverse Mercator",
ID["EPSG",9807]],
PARAMETER["Latitude of natural origin",0,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8801]],
PARAMETER["Longitude of natural origin",15,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8802]],
PARAMETER["Scale factor at natural origin",0.9996,
SCALEUNIT["unity",1],
ID["EPSG",8805]],
PARAMETER["False easting",500000,
LENGTHUNIT["metre",1],
ID["EPSG",8806]],
PARAMETER["False northing",0,
LENGTHUNIT["metre",1],
ID["EPSG",8807]]],
CS[Cartesian,2],
AXIS["(E)",east,
ORDER[1],
LENGTHUNIT["metre",1]],
AXIS["(N)",north,
ORDER[2],
LENGTHUNIT["metre",1]],
USAGE[
SCOPE["Engineering survey, topographic mapping."],
AREA["Europe between 12°E and 18°E: Austria; Denmark - offshore and offshore; Germany - onshore and offshore; Norway including Svalbard - onshore and offshore."],
BBOX[46.4,12,84.42,18]],
ID["EPSG",25833]]
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\OSGEO4~3\apps\grass\grass78\etc\python\grass\script\core.py", line 441, in run_command
return handle_errors(returncode, returncode, args, kwargs)
File "C:\OSGEO4~3\apps\grass\grass78\etc\python\grass\script\core.py", line 342, in handle_errors
raise CalledModuleError(module=None, code=code,
File "C:\OSGEO4~3\apps\grass\grass78\etc\python\grass\exceptions\__init__.py", line 68, in __init__
msg = _("Module run %s %s ended with error") % (module, code)
TypeError: 'str' object is not callable
I notice some encoding issue, in AREA["Europe between 12°E and 18°E: Austria; Denmark - offshore and offshore; Germany - onshore and offshore; Norway including Svalbard - onshore and offshore."],
, but I don`t think that is related.
Also the Python error seems to occurr because an underlying error is not handled properly...
Also:
p = gscript.read_command("g.proj", flags="j")
>>> p
'+proj=utm\r\n+zone=33\r\n+ellps=GRS80\r\n+units=m\r\n+no_defs\r\n+type=crs\r\n'
contains windows line endings. Not sure if that is as it should be...
I see:
p = gscript.run_command("g.proj", flags="w")
Traceback (most recent call last):
File "<input>", line 1, in <module>
File "C:\OSGeo4W\apps\grass\grass78\etc\python\grass\script\core.py", line 441, in run_command
return handle_errors(returncode, returncode, args, kwargs)
File "C:\OSGeo4W\apps\grass\grass78\etc\python\grass\script\core.py", line 342, in handle_errors
raise CalledModuleError(module=None, code=code,
grass.exceptions.CalledModuleError: Module run None g.proj -w ended with error
Process ended with non-zero return code 3221226356. See errors in the (error) output.
but
p = gscript.run_command("g.proj", flags="j")
p
0
in the GRASS GUI Python console (same OSGeo4W 7.8.6-6).
Hello,
I have a similar error when using GRASS 8.3.1.
5: In system(syscmd, intern = intern, ignore.stderr = ignore.stderr, : running command 'g.proj.exe -w' had status 884
See the whole problem associated with having to initiate the session when using an existing location:
https://matrix.to/#/!BOjyJgENYOLyXbRKxO:gitter.im/$fKj3VTwoHnJ5V2_ZupYdloIZaEc8036CqDYnh27XCKQ?via=gitter.im&via=matrix.org&via=osgeo.org
Hello, I have a similar error when using GRASS 8.3.1.
5: In system(syscmd, intern = intern, ignore.stderr = ignore.stderr, : running command 'g.proj.exe -w' had status 884
See the whole problem associated with having to initiate the session when using an existing location: https://matrix.to/#/!BOjyJgENYOLyXbRKxO:gitter.im/$fKj3VTwoHnJ5V2_ZupYdloIZaEc8036CqDYnh27XCKQ?via=gitter.im&via=matrix.org&via=osgeo.org
yes, the bug still exits.
GRASS version: 8.3.1
Code revision: exported
Build date: 2023-12-02
Build platform: x86_64-w64-mingw32
GDAL: 3.8.1
PROJ: 9.3.1
GEOS: 3.12.1
SQLite: 3.41.1
Python: 3.9.5
wxPython: 4.2.0
Platform: Windows-10-10.0.19045-SP0 (OSGeo4W)
interesting issue, it works on the winGRASS windows console
C:\Users\userxyz\Documents>g.proj -w
PROJCRS["MGI / Austria GK West",
BASEGEOGCRS["MGI",
DATUM["Militar-Geographische Institut",
ELLIPSOID["Bessel 1841",6377397.155,299.1528128,
LENGTHUNIT["metre",1]]],
PRIMEM["Greenwich",0,
ANGLEUNIT["degree",0.0174532925199433]],
ID["EPSG",4312]],
CONVERSION["Austria Gauss-Kruger West",
METHOD["Transverse Mercator",
ID["EPSG",9807]],
PARAMETER["Latitude of natural origin",0,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8801]],
PARAMETER["Longitude of natural origin",10.3333333333333,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8802]],
PARAMETER["Scale factor at natural origin",1,
SCALEUNIT["unity",1],
ID["EPSG",8805]],
PARAMETER["False easting",0,
LENGTHUNIT["metre",1],
ID["EPSG",8806]],
PARAMETER["False northing",-5000000,
LENGTHUNIT["metre",1],
ID["EPSG",8807]]],
CS[Cartesian,2],
AXIS["northing (X)",north,
ORDER[1],
LENGTHUNIT["metre",1]],
AXIS["easting (Y)",east,
ORDER[2],
LENGTHUNIT["metre",1]],
USAGE[
SCOPE["Engineering survey, topographic mapping."],
AREA["Austria west of 11°50'E of Greenwich (29°30'E of Ferro)."],
BBOX[46.77,9.53,47.61,11.84]],
ID["EPSG",31254]]
though it does not work in the GUI console:
g.proj -w
(Wed Dec 13 19:20:43 2023) Command ended with non-zero return code 3221226356 (1 sec)
c:\OSGeo4W\bin>dir /b | findstr gdal
gdal-config
gdal302.dll
gdal303.dll
gdal304.dll
gdal305.dll
gdal306.dll
gdal307.dll
gdal308.dll
some random googling
It looks like there is no difference between GUI and terminal, the segfault happens always on Windows, it's just not visible, because it happens after the WKT string is printed (GUI doesn't show anything in that case for some reason). That suggests the problem is here: https://github.com/OSGeo/grass/blob/main/general/g.proj/output.c#L277
and given what the documentation of exportToWkt
says about freeing the wkt string:
https://gdal.org/api/ogrspatialref.html#_CPPv4NK19OGRSpatialReference11exportToWktEPPcPPCKc
I suggest this change:
diff --git a/general/g.proj/output.c b/general/g.proj/output.c
index 365578ab52..33b7b6042d 100644
--- a/general/g.proj/output.c
+++ b/general/g.proj/output.c
@@ -22,6 +22,10 @@
#include <grass/glocale.h>
#include <grass/config.h>
+#ifdef HAVE_OGR
+#include <cpl_csv.h>
+#endif
+
#include "local_proto.h"
static int check_xy(int shell);
@@ -274,7 +278,7 @@ void print_wkt(int esristyle, int dontprettify)
if (outwkt != NULL) {
fprintf(stdout, "%s\n", outwkt);
- G_free(outwkt);
+ CPLFree(outwkt);
}
else
G_warning(_("Unable to convert to WKT"));
Somewhat related discussion https://github.com/OSGeo/gdal/pull/51 links heap corruption on Windows with not using CPLFree. But obviously I haven't tested this on Windows. Any opinions?
WinGRASS and OSGeo4W
g.proj -w
in demolocation succeed in outputting WKT only from the shell command prompt. Neither work in the GUI console or throughrgrass7::getLocationProj()
, which reports 884 as the error code; see also https://github.com/rsbivand/rgrass7/issues/33.Freshly installed WinGRASS 7.8.6-1 and GRASS 7.8.6 installed in fresh OSGeo4W; fully updated Windows 10.