Re: [GRASS-dev] libgrass_gis.7.8 not found issue
Hi Markus and Helmut, It is fixed now: https://trac.osgeo.org/osgeo4w/ticket/661#comment:11 Thank you very much! Best regards, Pedro Markus Neteler escreveu no dia quarta, 3/03/2021 à(s) 21:25: > On Wed, Mar 3, 2021 at 10:04 PM Helmut Kudrnovsky wrote: > ... > > >I've installed GRASS 7.8.5 from new OSGeo4W installer [0], > > >[0] https://download.osgeo.org/osgeo4w/testing/ > > > > see > > > > http://download.osgeo.org/osgeo4w/testing/x86_64/release/python3/ > > > > it seems python 3.9 is used in the new OSGeo4W environment: > > > > python3-3.9.0-7-src.tar.bz2 35172020-Oct-13 21:04 > > > > not sure if GRASS GIS 7.8.x is (already) supporting python 3.9 > > I think it does, at least I am using GRASS GIS 7.8.x with Python 3.9 > on Fedora 33 without any problems. > > > @Anna: any idea? > > No idea about Windows, though. > > > kind regards > > Helmut > > Markus > ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] libgrass_gis.7.8 not found issue
Hi all,
I've installed GRASS 7.8.5 from new OSGeo4W installer [0], but when I run
GRASS and try to start a new session I get:
Cleaning up temporary files...
D1/1: G_set_program_name(): clean_temp
D1/1: G_set_program_name(): db.connect
D1/1: Creating new default DB params with db_set_default_connection()
__ ___ _____
/ / __ \/ | / ___/ ___/ / / _/ ___/
/ / __/ /_/ / /| | \__ \\_ \ / / __ / / \__ \
/ /_/ / _, _/ ___ |___/ /__/ / / /_/ // / ___/ /
\/_/ |_/_/ |_/// \/___///
Welcome to GRASS GIS 7.8.5
GRASS GIS homepage: https://grass.osgeo.org
This version running through:Command Prompt
(C:\WINDOWS\system32\cmd.exe)
Help is available with the command: g.manual -i
See the licence terms with: g.version -c
See citation options with: g.version -x
If required, restart the GUI with: g.gui wxpython
When ready to quit enter:exit
Launching GUI in the background, please wait...
Microsoft Windows [Version 10.0.19042.804]
(c) 2020 Microsoft Corporation. Todos os direitos reservados.
C:\OSGeo4W64\bin>D1/1: G_set_program_name(): g.gisenv
D1/1: grass.script.core.start_command(): g.gisenv -n
D1/1: G_set_program_name(): g.gisenv
wxnviz.py: Could not find module
'C:\OSGEO4~1\apps\grass\grass78\lib\libgrass_gis.7.8.dll' (or one of
its dependencies). Try using the full path with constructor syntax.
wxdigit.py: Could not find module
'C:\OSGEO4~1\apps\grass\grass78\lib\libgrass_gis.7.8.dll' (or one of
its dependencies). Try using the full path with constructor syntax.
Traceback (most recent call last):
File "C:\OSGEO4~1\apps\grass\grass78\gui\wxpython\wxgui.py", line
104, in OnInit
from lmgr.frame import GMFrame
File "C:\OSGEO4~1\apps\grass\grass78\gui\wxpython\lmgr\frame.py",
line 51, in
from lmgr.layertree import LayerTree, LMIcons
File "C:\OSGEO4~1\apps\grass\grass78\gui\wxpython\lmgr\layertree.py",
line 38, in
from mapdisp.frame import MapFrame
File "C:\OSGEO4~1\apps\grass\grass78\gui\wxpython\mapdisp\frame.py",
line 43, in
from mapwin.buffered import BufferedMapWindow
File "C:\OSGEO4~1\apps\grass\grass78\gui\wxpython\mapwin\buffered.py",
line 52, in
import grass.lib.gis as gislib
File "C:\OSGEO4~1\apps\grass\grass78\etc\python\grass\lib\gis.py",
line 23, in
_libs["grass_gis.7.8"] = load_library("grass_gis.7.8")
File "C:\OSGEO4~1\apps\grass\grass78\etc\python\grass\lib\ctypes_loader.py",
line 62, in load_library
return self.load(path)
File "C:\OSGEO4~1\apps\grass\grass78\etc\python\grass\lib\ctypes_loader.py",
line 240, in load
return _WindowsLibrary(path)
File "C:\OSGEO4~1\apps\grass\grass78\etc\python\grass\lib\ctypes_loader.py",
line 223, in __init__
self.cdll = ctypes.cdll.LoadLibrary(path)
File "C:\OSGEO4~1\apps\Python39\lib\ctypes\__init__.py", line 452,
in LoadLibrary
return self._dlltype(name)
File "C:\OSGEO4~1\apps\Python39\lib\ctypes\__init__.py", line 374, in __init__
self._handle = _dlopen(self._name, mode)
FileNotFoundError: Could not find module
'C:\OSGEO4~1\apps\grass\grass78\lib\libgrass_gis.7.8.dll' (or one of
its dependencies). Try using the full path with constructor syntax.
OnInit returned false, exiting...
This seems to affect Windows 10 operating systems in locale languages,
in this case, portuguese, where the issue is confirmed on 3 different
machines.
I've reported it in OSGeo4W tracker [1], because I thought it was
related to some kind of packaging issue, but I decided to post it here
to get your opinions.
Thank you very much.
Best regards,
Pedro Venâncio
[0] https://download.osgeo.org/osgeo4w/testing/
[1] https://trac.osgeo.org/osgeo4w/ticket/661
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Daily build available at OSGeo4W 7.9.dev-6842631ae-366 does not start
Hi all, The last daily build available at OSGeo4W (7.9.dev-6842631ae-366) does not start: Starting GRASS GIS... ATENÇÃO: Concurrent mapset locking is not supported on Windows Cleaning up temporary files... D1/1: G_set_program_name(): clean_temp __ ___ _____ / / __ \/ | / ___/ ___/ / / _/ ___/ / / __/ /_/ / /| | \__ \\_ \ / / __ / / \__ \ / /_/ / _, _/ ___ |___/ /__/ / / /_/ // / ___/ / \/_/ |_/_/ |_/// \/___/// Welcome to GRASS GIS 7.9.dev (6842631ae) GRASS GIS homepage: https://grass.osgeo.org This version running through:Command Prompt (C:\WINDOWS\system32\cmd.exe) Help is available with the command: g.manual -i See the licence terms with: g.version -c See citation options with: g.version -x If required, restart the GUI with: g.gui wxpython When ready to quit enter:exit Launching GUI in the background, please wait... Microsoft Windows [Version 10.0.19041.630] (c) 2020 Microsoft Corporation. Todos os direitos reservados. C:\>D1/1: G_set_program_name(): g.gisenv D1/1: grass.script.core.start_command(): g.gisenv -n D1/1: G_set_program_name(): g.gisenv Traceback (most recent call last): File "C:\OSGEO4~1\apps\grass\grass79\gui\wxpython\wxgui.py", line 104, in OnInit from lmgr.frame import GMFrame File "C:\OSGEO4~1\apps\grass\grass79\gui\wxpython\lmgr\frame.py", line 69, in from datacatalog.catalog import DataCatalog File "C:\OSGEO4~1\apps\grass\grass79\gui\wxpython\datacatalog\catalog.py", line 22, in from datacatalog.tree import DataCatalogTree File "C:\OSGEO4~1\apps\grass\grass79\gui\wxpython\datacatalog\tree.py", line 189, in class MapWatch(PatternMatchingEventHandler): NameError: name 'PatternMatchingEventHandler' is not defined OnInit returned false, exiting... The previous one (GRASS GIS 7.9.dev-297c43fe8-365) works as expected. Best regards, Pedro Venâncio ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.sun.daily insolation time parameter
Hi Anna, Sorry for the late reply. I've opened a FR at https://github.com/OSGeo/grass-addons/issues/325 Thank you very much! Best regards, Pedro Anna Petrášová escreveu no dia quarta, 21/10/2020 à(s) 02:47: > > > On Tue, Oct 20, 2020 at 9:41 AM Pedro Venâncio > wrote: > >> Hi all, >> >> I was trying to use r.sun.daily to get the total insolation time between >> two dates, but I see that insol_time is not an available parameter in >> r.sun.daily. >> >> Was there any reason to not include insol_time in r.sun.daily script? >> > > I don't remember any specific reason, it certainly looks like it would be > possible. You can create a feature request or even a PR: > > https://github.com/OSGeo/grass-addons > > the code is here: > > https://github.com/OSGeo/grass-addons/blob/master/grass7/raster/r.sun.daily/r.sun.daily.py > >> >> Thank you very much! >> >> Best regards, >> Pedro Venâncio >> ___ >> grass-dev mailing list >> grass-dev@lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/grass-dev > > ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] r.sun.daily insolation time parameter
Hi all, I was trying to use r.sun.daily to get the total insolation time between two dates, but I see that insol_time is not an available parameter in r.sun.daily. Was there any reason to not include insol_time in r.sun.daily script? Thank you very much! Best regards, Pedro Venâncio ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.slope.aspect with -n flag giving aspect of flat areas as -9998
Hi Markus and Anna, It's fixed now! Thank you very much! The #320 <https://github.com/OSGeo/grass/pull/320> part will be fixed after the merge. -e and -n flags are now used also in QGIS Processing Framework: qgis/QGIS#34087 <https://github.com/qgis/QGIS/pull/34087> Best regards, Pedro Markus Metz escreveu no dia sábado, 1/02/2020 à(s) 22:10: > > > On Fri, Jan 31, 2020 at 9:35 PM Markus Neteler wrote: > > > > On Fri, Jan 31, 2020 at 10:39 AM Pedro Venâncio > > wrote: > > > > > > Hi Anna and Markus, > > > > > > Thank you very much! > > > > > > A filled a ticket: https://github.com/OSGeo/grass/issues/319 > > > > It was fixed in master f449ea5 and relbr78 fdd079c by Markus M. > > > > Please test and update/close the issue. > > there is a new PR #320 by Anna (https://github.com/OSGeo/grass/pull/320) > fixing also the title and the color table. Please test! > > Markus M > > > > > Best > > markusN > ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.slope.aspect with -n flag giving aspect of flat areas as -9998
Hi Anna and Markus, Thank you very much! A filled a ticket: https://github.com/OSGeo/grass/issues/319 Best regards, Pedro Markus Metz escreveu no dia quinta, 30/01/2020 à(s) 08:26: > > > On Tue, Jan 28, 2020 at 12:50 PM Pedro Venâncio > wrote: > > > > Hi all, > > > > I was testing r.slope.aspect with the "new" -n flag, also to include -e > and -n flags in QGIS Processing, but -n flag is giving aspect values of > flat areas as -9998, instead of -, when the precision choosed is CELL, > and the output data type is CELL. > > that seems to be a rounding error, even though float or double should be > able to represent - exactly. Should be easy to fix. > > Markus M > > > > https://grass.osgeo.org/grass78/manuals/r.slope.aspect.html > > > > I've tested with GRASS 7.6 (on Linux) and GRASS 7.8.2 (on Windows), both > in the GUI and CLI. > > > > (Tue Jan 28 11:19:40 2020) > > > r.slope.aspect -e -n --verbose elevation=SRTM_PT_25m@PERMANENT > slope=SRTM_PT_25m_Slope_Deg_GRASS aspect=SRTM_PT_25m_Aspect_Std_GRASS > precision=CELL > > Percent complete... > > Elevation products for mapset in > > Min computed aspect 0., max computed aspect 360. > > Aspect raster map complete > > Min computed slope 0., max computed slope 75.2970 > > Slope raster map complete > > (Tue Jan 28 11:20:24 2020) Comando terminado (43 sec) > > > > r.info map=SRTM_PT_25m_Aspect_Std_GRASS@PERMANENT > > > > > ++ > > | Map: SRTM_PT_25m_Aspect_Std_GRASS@ Date: Tue Jan 28 11:20:24 > 2020| > > | Mapset: PERMANENT Login of Creator: > PedroVenancio | > > | Location: SRTM_PT_25m > | > > | DataBase: D:\ICNF\Modelos_Combustivel_2018\Landscape_File\grass78 > | > > | Title:Aspect counterclockwise in degrees from east > | > > | Timestamp: none > | > > > > || > > | > | > > | Type of Map: raster Number of Categories: 360 > | > > | Data Type:CELL > | > > | Rows: 23200 > | > > | Columns: 11360 > | > > | Total Cells: 263552000 > | > > |Projection: ETRS89 / Portugal TM06 > | > > |N: 278000S:-302000 Res:25 > | > > |E: 164000W:-12 Res:25 > | > > | Range of data:min = -9998 max = 360 > | > > | > | > > | Data Source: > | > > |raster elevation file SRTM_PT_25m@PERMANENT > | > > | > | > > | > | > > | Data Description: > | > > |generated by r.slope.aspect > | > > | > | > > | Comments: > | > > |aspect map elev = SRTM_PT_25m@PERMANENT > | > > |zfactor = 1.00 > | > > |min_slope = 0.00 > | > > | > | > > |r.slope.aspect --verbose -e -n elevation="SRTM_PT_25m@PERMANENT" > slo\ | > > |pe="SRTM_PT_25m_Slope_Deg_GRASS" > aspect="SRTM_PT_25m_Aspect_Std_GRAS\ | > > |S" format="degrees" precision="CELL" zscale=1.0 min_slope=0.0 > | > > | > | > > > > ++ > > (Tue Jan 28 11:26:09 2020) Comando terminado (0 sec) > > > > > > > Using the default precision as FCELL, all goes ok: > > > > (Tue Jan 28 11:33:08 2020) > > > r.slope.aspect -e -n --verbose elevation=SRTM_PT_25m@PERMANENT > slope=SRTM_PT_25m_Slope_Deg_GRASS_2 aspect=SRTM_PT_25m_Aspect_Std_GRASS_2 > > Percent complete... > > Elevation products for mapset in > > Min computed aspect 0., max computed aspect 359.8096 > > Aspect raster map complete > > Min computed slope 0., max computed slope 75.2970 > > Slope raster map complete > > (Tue Jan 28 11:34:01 2020) Comando terminado (53 sec) > > > > (Tue Jan 28 11:34:27 2020) > > > r.info map=SRTM_PT_25m_Aspect_Std_GRASS_2@PERMANENT > > > > > ++ > > | Map: SRTM_PT_25m_Aspect_Std_GRASS_ Date: Tue Jan 28 11:34:01 > 2020| > > | Mapset: PERMANENT Login of Creator: > PedroVenancio | > > | Location: SRTM_PT_25m >
[GRASS-dev] r.slope.aspect with -n flag giving aspect of flat areas as -9998
a range from -2,147,483,647 to +2,147,483,647, - should be fine to conform inside it. Another issue I see is in r.info, that is showing the title as | Title:Aspect counterclockwise in degrees from east which is not correct in this case, as the -n flag was used. Could these be bugs? Thank you very much. Best regards, Pedro Venâncio ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] WinGRASS build up (WIP)
Hi Helmut, checking here: > > QGIS version 3.10.0-A Coruña > Compiled against Qt 5.11.2 > Compiled against GDAL/OGR 3.0.2 <= > Compiled against GEOS 3.8.0-CAPI-1.13.1 > Compiled against SQLite 3.29.0 > PostgreSQL Client Version 11.5 > > 3.10.0 is now available in OSGeo4W without the need to install gdal-dev > I'm using nightly builds (qgis-rel-dev), and this one needs gdal-dev. QGIS version 3.10.0-A Coruña QGIS code revision 1ffa829539 Compiled against GDAL/OGR 3.1.0dev Running against GDAL/OGR 3.1.0dev > I compared your explorer search results here with mine on a windows 10 box. > > in > > https://lists.osgeo.org/pipermail/grass-dev/attachments/20191116/8570c76d/attachment-0005.jpg > > there are 2 libcurl.dlls from 2016. > > I don't have them in my win 10 box. not sure if you have admin rights on > your box, but you can rename them and then try to start winGRASS again. > Perfect!!! These libcurl.dlls were the problem! More precisely, the one on System32. After changed their names, everything works again! Issue solved! Thank you very very much for your help and persistence Helmut! Best regards, Pedro Venâncio ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] WinGRASS build up (WIP)
Hi Jurgen and Helmut, I'd uninstalled everything related with QGIS, GRASS, GDAL, GMT, etc, and installed again from OSGeo4W. At the final stages of OSGeo4W installation, I get the same curl_mime_init error with crssync.exe, but referring to gdal301.dll (image attached). Jürgen E. Fischer escreveu no dia sábado, 16/11/2019 à(s) 14:32: > Hi Helmut, > > On Sat, 16. Nov 2019 at 15:22:32 +0100, Jürgen E. Fischer wrote: > > That update is unrelated. > > Oh, I didn't see the screen shot - maybe the update helps - but it was > at least not done for this. > > > Jürgen > > -- > Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 > Dipl.-Inf. (FH) Rheinstraße 13 Fax. +49-4931-918175-50 > Software Engineer D-26506 Norden > https://www.norbit.de > QGIS release manager (PSC) GermanyIRC: jef on FreeNode > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] WinGRASS build up (WIP)
I've seen there was a curl update today in OSGeo4W 64bit. please try to
> update your OSGeo4W environment and try again to start winGRASS in
> OSGeo4W.
>
Updated now, but same error when running any algorithm.
Also when starting the gui I get
C:\OSGeo4W64\bin>g.gui
Launching GUI in the background, please wait...
C:\OSGeo4W64\bin>Traceback (most recent call last):
File "C:\OSGEO4~1\apps\grass\grass78/gui/wxpython/wxgui.py", line 107, in
OnInit
workspace=self.workspaceFile)
File "C:\OSGEO4~1\apps\grass\grass78\gui\wxpython\lmgr\frame.py", line
143, in __init__
self.notebook = self._createNoteBook()
File "C:\OSGEO4~1\apps\grass\grass78\gui\wxpython\lmgr\frame.py", line
338, in _createNoteBook
gcstyle=GC_PROMPT)
File "C:\OSGEO4~1\apps\grass\grass78\gui\wxpython\gui_core\goutput.py",
line 118, in __init__
self.cmdPrompt = GPromptSTC(parent=self, menuModel=self._menuModel)
File "C:\OSGEO4~1\apps\grass\grass78\gui\wxpython\gui_core\prompt.py",
line 138, in __init__
GPrompt.__init__(self, parent=parent, menuModel=menuModel)
File "C:\OSGEO4~1\apps\grass\grass78\gui\wxpython\gui_core\prompt.py",
line 56, in __init__
self.mapList = self._getListOfMaps()
File "C:\OSGEO4~1\apps\grass\grass78\gui\wxpython\gui_core\prompt.py",
line 100, in _getListOfMaps
result['raster'] = grass.list_strings('raster')
File "C:\OSGEO4~1\apps\grass\grass78\etc\python\grass\script\core.py",
line 1288, in list_strings
mapset=mapset).splitlines():
File "C:\OSGEO4~1\apps\grass\grass78\etc\python\grass\script\core.py",
line 503, in read_command
return handle_errors(returncode, stdout, args, kwargs)
File "C:\OSGEO4~1\apps\grass\grass78\etc\python\grass\script\core.py",
line 343, in handle_errors
returncode=returncode)
grass.exceptions.CalledModuleError: Module run None g.list --q -m
type=raster ended with error
Process ended with non-zero return code 3221225785. See errors in the
(error) output.
OnInit returned false, exiting...
Error in atexit._run_exitfuncs:
wx._core.wxAssertionError: C++ assertion "GetEventHandler() == this" failed
at ..\..\src\common\wincmn.cpp(478) in wxWindowBase::~wxWindowBase(): any
pushed event handlers must have been removed
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] WinGRASS build up (WIP)
Hi Helmut, Thank you very much for the assistance. So: C:\OSGeo4W64>where gdal300.dll C:\OSGeo4W64\bin\gdal300.dll C:\Users\PedroVenancio>where gdal300.dll INFO: Could not find files for the given pattern(s). depwalk_bin.log has no reference to gdal3. depwalk_lib.log has some: [ 6] c:\osgeo4~1\bin\GDAL300.DLL [ 6] c:\osgeo4~1\bin\OGDI.DLL [ ^6] c:\osgeo4~1\bin\ZLIB1.DLL [ ^6] c:\osgeo4~1\bin\EXPAT.DLL [ ^6] c:\windows\system32\WSOCK32.DLL [F^6] c:\windows\system32\WS2_32.DLL [ ^6] c:\windows\system32\ADVAPI32.DLL [ ^6] c:\windows\system32\KERNEL32.DLL [F^6] c:\windows\system32\NTDLL.DLL [ ^6] c:\windows\system32\VCRUNTIME140.DLL [ ? ] API-MS-WIN-CRT-HEAP-L1-1-0.DLL [ ? ] API-MS-WIN-CRT-STRING-L1-1-0.DLL [ ? ] API-MS-WIN-CRT-ENVIRONMENT-L1-1-0.DLL [ ? ] API-MS-WIN-CRT-STDIO-L1-1-0.DLL [ ? ] API-MS-WIN-CRT-FILESYSTEM-L1-1-0.DLL [ ? ] API-MS-WIN-CRT-MATH-L1-1-0.DLL [ ? ] API-MS-WIN-CRT-UTILITY-L1-1-0.DLL [ ? ] API-MS-WIN-CRT-CONVERT-L1-1-0.DLL [ ? ] API-MS-WIN-CRT-RUNTIME-L1-1-0.DLL [ 6] c:\osgeo4~1\bin\XERCES-C_3_2.DLL [ ^6] c:\windows\system32\KERNEL32.DLL [F^6] c:\windows\system32\NTDLL.DLL [ ^6] c:\windows\system32\ADVAPI32.DLL [ ^6] c:\windows\system32\VCRUNTIME140.DLL [ ? ] API-MS-WIN-CRT-RUNTIME-L1-1-0.DLL [ ? ] API-MS-WIN-CRT-STDIO-L1-1-0.DLL [ ? ] API-MS-WIN-CRT-TIME-L1-1-0.DLL [ ? ] API-MS-WIN-CRT-CONVERT-L1-1-0.DLL [ ? ] API-MS-WIN-CRT-LOCALE-L1-1-0.DLL [ ? ] API-MS-WIN-CRT-UTILITY-L1-1-0.DLL [ ? ] API-MS-WIN-CRT-MATH-L1-1-0.DLL [ ? ] API-MS-WIN-CRT-STRING-L1-1-0.DLL [ ? ] API-MS-WIN-CRT-ENVIRONMENT-L1-1-0.DLL [ ? ] API-MS-WIN-CRT-HEAP-L1-1-0.DLL [ 6] c:\osgeo4~1\bin\EXPAT.DLL [ ^6] c:\windows\system32\MSVCR100.DLL [ ^6] c:\windows\system32\KERNEL32.DLL [F^6] c:\windows\system32\NTDLL.DLL [ ^6] c:\osgeo4~1\bin\LIBPQ.DLL [ 6] c:\windows\system32\WSOCK32.DLL [ ^6] c:\windows\system32\MSVCRT.DLL [ ^6] c:\windows\system32\WS2_32.DLL [ ? ] API-MS-WIN-CORE-ERRORHANDLING-L1-1-0.DLL [ ? ] API-MS-WIN-CORE-SYNCH-L1-2-0.DLL [ ? ] API-MS-WIN-CORE-PROFILE-L1-1-0.DLL [ ? ] API-MS-WIN-CORE-PROCESSTHREADS-L1-1-0.DLL [ ? ] API-MS-WIN-CORE-SYSINFO-L1-1-0.DLL [ ? ] API-MS-WIN-CORE-RTLSUPPORT-L1-1-0.DLL [F^6] c:\windows\system32\WS2_32.DLL [ ^6] c:\windows\system32\WS2_32.DLL [...] [ 6] c:\osgeo4~1\apps\grass\grass78\lib\LIBGRASS_GPROJ.7.8.DLL [ ? ] LIBINTL-8.DLL [ ^6] c:\windows\system32\KERNEL32.DLL [F^6] c:\windows\system32\NTDLL.DLL [ ^6] c:\windows\system32\MSVCRT.DLL [ ^6] c:\osgeo4~1\bin\PROJ_6_2.DLL [ ^6] c:\osgeo4~1\bin\GDAL300.DLL [ ^6] c:\osgeo4~1\apps\grass\grass78\lib\LIBGRASS_GIS.7.8.DLL [...] [ 6] c:\osgeo4~1\bin\GDAL300.DLL 03/11/2019 00:33 03/11/2019 00:33 20 789 760 A 0x 0x013DF7F0 x64 GUIUnknown 0x00018000 Unknown 0x0144B000Not Loaded 3.0.2.0 3.0.2.0 0.0 14.06.0 6.0 Do you see anything suspicious? The message I get (screenshot attached) is something like "It was not possible to find the entry point of the procedure curl_mime_init in the DLL C:\OSGEO4~1\bin\gdal300.dll". Thanks! Pedro Helmut Kudrnovsky escreveu no dia sexta, 15/11/2019 à(s) 20:31: > Pedro Venâncio-2 wrote > > Hi Helmut, > > > > > > What is gdalinfo --version in the OSGeo4W shell telling? > >> > > > > > > C:\OSGeo4W64>gdalinfo --version > > GDAL 3.0.2, released 2019/10/28 > > and type the same in a normal windows console, here: > > C:\Users\myusername>where gdal300.dll > INFORMATION: no file with this pattern could be found > > > > > - > best regards > Helmut > -- > Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org
Re: [GRASS-dev] [GRASS-user] WinGRASS build up (WIP)
Hi Helmut, What is gdalinfo --version in the OSGeo4W shell telling? > C:\OSGeo4W64>gdalinfo --version GDAL 3.0.2, released 2019/10/28 Thank you very much! Best regards, Pedro ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] WinGRASS build up (WIP)
Hi Jurgen, > Try dependency walker called from the GRASS prompt and load gdal300.dll. > There's probably something missing that the dll needs or conflicting in > system32 that takes precendence over something shipped with OSGeo4W (see > also > [0]) > > I'm not used with dependency walker, can you tell me the command I should run to call it from GRASS cli? I already have it in %OSGEO4W_ROOT%\bin folder. Thank you very much! Best regards, Pedro ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] WinGRASS build up (WIP)
Hi Markus and Markus, I hope someone else can test, because here in my machine: - GRASS 7.8.1 standalone 64bits does not work; - GRASS 7.8.0 standalone 64bits work fine; - GRASS 7.8.1 from OSGeo4W64 does not work, also inside QGIS; - GRASS 7.8.0 from OSGeo4W64 does not work, also inside QGIS; - GRASS 7.8.1 installed with QGIS 3.4.13-2 and QGIS 3.10.0-2 does not work, also inside QGIS; - GRASS 7.6.1 installed with QGIS 3.4.13-1 and QGIS 3.10.0-1 work fine, alone and inside QGIS. In all of them, when I try to run any GRASS algorithm from grass78 --text, I get the gdal300.dll error. Best regards, Pedro Markus Metz escreveu no dia quarta, 13/11/2019 à(s) 15:03: > > > On Wed, Nov 13, 2019 at 3:39 PM Markus Neteler wrote: > > > > On Wed, Nov 13, 2019 at 3:27 PM Pedro Venâncio > > wrote: > > > > > > Hi all again, > > > > > > I've tested GRASS standalone and I got the same error with > WinGRASS-7.8.1-1-Setup-x86_64. > > > > > > Then I uninstalled this version and installed > WinGRASS-7.8.0-2-Setup-x86_64 and everything worked fine. > > > > > > So, it seems that there is something wrong with GRASS-7.8.1 in my > machine. Also when running algorithms in CLI, GRASS throws the message > about gdal300.dll, but that dll is present in the path specified > (screenshot attached). > > > > > > Any hint about what can be wrong? > > > > Probably this recent fix is needed? > > https://github.com/OSGeo/grass/pull/191 > > No, because GRASS is actually looking for gdal300.dll. > > Looks like a packaging error in WinGRASS-7.8.1-1-Setup-x86_64, if others > can confirm this. > > Markus M > > > > It will be part of 7.8.2. > > > > Best regards, > > Markus > > ___ > > grass-dev mailing list > > grass-dev@lists.osgeo.org > > https://lists.osgeo.org/mailman/listinfo/grass-dev > ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] WinGRASS build up (WIP)
Hi all again,
I've tested GRASS standalone and I got the same error with
WinGRASS-7.8.1-1-Setup-x86_64.
Then I uninstalled this version and installed WinGRASS-7.8.0-2-Setup-x86_64
and everything worked fine.
So, it seems that there is something wrong with GRASS-7.8.1 in my machine.
Also when running algorithms in CLI, GRASS throws the message about
gdal300.dll, but that dll is present in the path specified (screenshot
attached).
Any hint about what can be wrong?
Thanks.
Best regards,
Pedro
Pedro Venâncio escreveu no dia terça,
12/11/2019 à(s) 15:02:
> Hi Martin,
>
> Hum, it can be related, because starting GRASS with
>
> grass --text
>
> and then
>
> v.buffer
>
> I get a windows message saying that the gdal300.dll is missing. However, I
> have a gdal300.dll file in OSGeoW folder: C:\OSGeo4W64\bin.
>
> GRASS config gives:
>
> C:\>grass78 --config
> x86_64-w64-mingw32
> ./configure --host=x86_64-w64-mingw32 '--with-libs=C:\\OS3944~1/lib'
> --with-includes=/c/OSGeo4W64/include --libexecdir=/c/OSGeo4W64/bin
> --prefix=/c/OSGeo4W64/apps/grass --bindir=/c/OSGeo4W64/bin
> --includedir=/c/OSGeo4W64/include --without-x --with-cxx --enable-shared
> --enable-largefile --with-fftw --with-freetype
> --with-freetype-includes=/mingw64/include/freetype2
> --with-proj-share=/c/OSGeo4W64/share/proj
> --with-proj-includes=/c/OSGeo4W64/include
> --with-proj-libs=/usr/src/grass781/mswindows/osgeo4w/lib --with-postgres
> --with-postgres-includes=/c/OSGeo4W64/include
> --with-postgres-libs=/usr/src/grass781/mswindows/osgeo4w/lib
> --with-gdal=/usr/src/grass781/mswindows/osgeo4w/gdal-config
> --with-geos=/usr/src/grass781/mswindows/osgeo4w/geos-config --with-sqlite
> --with-sqlite-includes=/c/OSGeo4W64/include
> --with-sqlite-libs=/usr/src/grass781/mswindows/osgeo4w/lib --with-regex
> --with-nls --with-zstd --with-odbc --with-cairo --with-opengl=windows
> --with-bzlib --with-liblas=/usr/src/grass781/mswindows/osgeo4w/liblas-config
> gcc
> C:\OSGEO4~1\apps\grass\grass78
> Traceback (most recent call last):
> File "C:\OSGEO4~1\apps\grass\grass78\etc\grass78.py", line 2025, in main
> index = sys.argv.index(batch_exec_param)
> ValueError: '--exec' is not in list
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
> File "C:\OSGEO4~1\apps\grass\grass78\etc\grass78.py", line 2216, in
>
> main()
> File "C:\OSGEO4~1\apps\grass\grass78\etc\grass78.py", line 2030, in main
> params = parse_cmdline(sys.argv[1:], default_gui=default_gui)
> File "C:\OSGEO4~1\apps\grass\grass78\etc\grass78.py", line 1951, in
> parse_cmdline
> print_params()
> File "C:\OSGEO4~1\apps\grass\grass78\etc\grass78.py", line 1862, in
> print_params
> "%s\n" % val[0].split(':')[1].rstrip('$"\n').strip())
> IndexError: list index out of range
> Press any key to continue . . .
>
>
>
> Martin Landa escreveu no dia terça, 12/11/2019
> à(s) 14:26:
>
>> Hi,
>>
>> út 12. 11. 2019 v 15:14 odesílatel Pedro Venâncio
>> napsal:
>> > GDAL version: 3.1.0dev
>> > GEOS version: 3.8.0-CAPI-1.13.1
>> > PROJ version: Rel. 7.0.0, March 1st, 2020
>>
>> it's probably unrelated, but GRASS 7.8.1 is compiled with GDAL 3.0 and
>> PROJ 6.0.
>>
>> Ma
>>
>> --
>> Martin Landa
>> http://geo.fsv.cvut.cz/gwiki/Landa
>> http://gismentors.cz/mentors/landa
>>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [release planning] GRASS GIS 7.4.4 - as a "friendship release" for QGIS
Thanks Martin! I already alerted to this in qgis-dev mailing list. Best regards, Pedro Martin Landa escreveu no dia segunda, 7/01/2019 à(s) 12:13: > Hi, > > po 7. 1. 2019 v 12:27 odesílatel Pedro Venâncio > napsal: > > Is it something you can fix? > > it should be fixed by QGIS devs/packagers. Ma > > -- > Martin Landa > http://geo.fsv.cvut.cz/gwiki/Landa > http://gismentors.cz/mentors/landa > ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [release planning] GRASS GIS 7.4.4 - as a "friendship release" for QGIS
Hi Martin, QGIS batch files in OSGeo4W are still calling GRASS 7.4.2, instead of 7.4.4: call "%OSGEO4W_ROOT%"\apps\grass\grass-7.4.4\etc\env.bat path %OSGEO4W_ROOT%\apps\qgis-ltr-dev\bin;%OSGEO4W_ROOT%\apps\grass\grass-7.4.2\lib;%OSGEO4W_ROOT%\apps\grass\grass-7.4.2\bin;%PATH% This happens with all versions: qgis-ltr-dev-g7.4.2.bat qgis-rel-dev-g7.bat etc. Is it something you can fix? Thank you very much! Best regards, Pedro Venâncio Martin Landa escreveu no dia sábado, 5/01/2019 à(s) 22:00: > Hi, > > so 5. 1. 2019 v 0:36 odesílatel Markus Neteler napsal: > > osgeo4w and wingrass standalone packages uploaded. Ma > > -- > Martin Landa > http://geo.fsv.cvut.cz/gwiki/Landa > http://gismentors.cz/mentors/landa > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Problem starting GRASS GUI - ntpath splitdrive
Hi Martin and Helmut, About this issue, I finally find the problem. I had changed the default code page in this machine long time ago (Regional Settings -> Language for non-Unicode programs -> and marked the beta option "Use Unicode UTF-8 for worldwide language support"). And so, the active code page in windows console was 65001. Unchecking that option, the defaut CHCP came back to 850, and the problem gone away! Thank you very much for your help! Best regards, Pedro Venâncio Pedro Venâncio escreveu no dia quarta, 7/11/2018 à(s) 14:10: > Hi Martin, > > Yes, I tried to update wxPython by pip, but it does not solved the problem. > > Returning to 2.8.12 also does not help: > > C:\>pip uninstall wxpython > Uninstalling wxPython-4.0.3: > Would remove: > c:\osgeo4~1\apps\python27\lib\site-packages\wx\* > c:\osgeo4~1\apps\python27\lib\site-packages\wxpython-4.0.3.dist-info\* > c:\osgeo4~1\apps\python27\scripts\helpviewer.exe > c:\osgeo4~1\apps\python27\scripts\img2png.exe > c:\osgeo4~1\apps\python27\scripts\img2py.exe > c:\osgeo4~1\apps\python27\scripts\img2xpm.exe > c:\osgeo4~1\apps\python27\scripts\pycrust.exe > c:\osgeo4~1\apps\python27\scripts\pyshell.exe > c:\osgeo4~1\apps\python27\scripts\pyslices.exe > c:\osgeo4~1\apps\python27\scripts\pyslicesshell.exe > c:\osgeo4~1\apps\python27\scripts\pywxrc.exe > c:\osgeo4~1\apps\python27\scripts\wxdemo.exe > c:\osgeo4~1\apps\python27\scripts\wxdocs.exe > c:\osgeo4~1\apps\python27\scripts\wxget.exe > Proceed (y/n)? y > Successfully uninstalled wxPython-4.0.3 > You are using pip version 18.0, however version 18.1 is available. > You should consider upgrading via the 'python -m pip install --upgrade > pip' command. > > C:\>grass74 > Cleaning up temporary files... > Starting GRASS GIS... > ATENÇÃO: Concurrent mapset locking is not supported on Windows > > __ ___ _____ > / / __ \/ | / ___/ ___/ / / _/ ___/ > / / __/ /_/ / /| | \__ \\_ \ / / __ / / \__ \ >/ /_/ / _, _/ ___ |___/ /__/ / / /_/ // / ___/ / >\/_/ |_/_/ |_/// \/___/// > > Welcome to GRASS GIS 7.4.2 > GRASS GIS homepage: http://grass.osgeo.org > This version running through:Command Shell > (C:\WINDOWS\system32\cmd.exe) > Help is available with the command: g.manual -i > See the licence terms with: g.version -c > See citation options with: g.version -x > Start the GUI with: g.gui wxpython > When ready to quit enter:exit > > Microsoft Windows [Version 10.0.17134.345] > (c) 2018 Microsoft Corporation. Todos os direitos reservados. > > C:\>g.gui wxpython > Launching GUI in the background, please wait... > > C:\>python > Python 2.7.14 (v2.7.14:84471935ed, Sep 16 2017, 20:25:58) [MSC v.1500 64 > bit (AMD64)] on win32 > Type "help", "copyright", "credits" or "license" for more information. > > >>> import wx > >>> wx.version() > '2.8.12.1 (msw-unicode)' > > >>> import sys > >>> print '\n'.join(sys.path) > > C:\OSGEO4~1\apps\grass\grass-7.4.2\etc\python > C:\OSGeo4W64\apps\Python27 > C:\OSGEO4~1\bin\python27.zip > C:\OSGEO4~1\apps\Python27\DLLs > C:\OSGEO4~1\apps\Python27\lib > C:\OSGEO4~1\apps\Python27\lib\plat-win > C:\OSGEO4~1\apps\Python27\lib\lib-tk > C:\OSGEO4~1\bin > C:\OSGEO4~1\apps\Python27 > C:\OSGEO4~1\apps\Python27\lib\site-packages > C:\OSGEO4~1\apps\Python27\lib\site-packages\jinja2-2.7.2-py2.7.egg > > C:\OSGEO4~1\apps\Python27\lib\site-packages\markupsafe-0.23-py2.7-win-amd64.egg > C:\OSGEO4~1\apps\Python27\lib\site-packages\win32 > C:\OSGEO4~1\apps\Python27\lib\site-packages\win32\lib > C:\OSGEO4~1\apps\Python27\lib\site-packages\Pythonwin > C:\OSGEO4~1\apps\Python27\lib\site-packages\wx-2.8-msw-unicode > > Thanks! > > Best regards, > Pedro > > > > Martin Landa escreveu no dia quarta, 7/11/2018 > à(s) 12:52: > >> Hi, >> >> st 7. 11. 2018 v 12:02 odesílatel Pedro Venâncio >> napsal: >> > >>> import wx >> > >>> wx.version() >> > u'4.0.3 msw (phoenix) wxWidgets 3.0.5' >> >> btw, have you installed wxPython on your own by pip? OSGeo4W still >> comes with version 2.8.12 [1] >> >> Ma >> >> [1] https://download.osgeo.org/osgeo4w/x86_64/release/python/python-wx/ >> >> -- >> Martin Landa >> http://geo.fsv.cvut.cz/gwiki/Landa >> http://gismentors.cz/mentors/landa >> > ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [release planning] GRASS GIS 7.4.3
Hi all, When do you think the new r.mapcalculator can be introduced in GRASS core? https://trac.osgeo.org/grass/ticket/3431 It would be great to be introduced in one of the 7.4.x release cicle, to be used with QGIS 2.18.x. Thank you very much! Best regards, Pedro Na(o) sáb, 24/11/2018, 10:14, Markus Neteler escreveu: > On Tue, Nov 20, 2018 at 8:18 PM Markus Neteler wrote: > > > > Hi, > > > > due to the now fixed: > > #3692: The python gcore message() function does not work in 7.4.2 > > > > This fix is important to be released since otherwise users willl be > > confused due to the lack of messages. > > ... we need to release asap! > > > > Proposed time schedule (https://trac.osgeo.org/grass/milestone/7.4.3) > > - Proposal of release: 20 Nov 2018 - [DONE] > > - Soft freeze of release branch: 21 Nov 2018 > > - RC1: 22 Nov 2018 > > The 7.4.3RC1 is released and online available: > https://trac.osgeo.org/grass/wiki/Release/7.4.3-News#ReleaseCandidate3RC1 > > Please check the announcement. > > Markus > > > - Final release: 26 Nov 2018 > > > > Critical bugs: > > > https://trac.osgeo.org/grass/query?status=new=assigned=reopened=blocker=critical=7.4.3=7.4.2=7.4.1=7.4.0=type=priority > > --> none > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Problem starting GRASS GUI - ntpath splitdrive
Hi Martin, Yes, I tried to update wxPython by pip, but it does not solved the problem. Returning to 2.8.12 also does not help: C:\>pip uninstall wxpython Uninstalling wxPython-4.0.3: Would remove: c:\osgeo4~1\apps\python27\lib\site-packages\wx\* c:\osgeo4~1\apps\python27\lib\site-packages\wxpython-4.0.3.dist-info\* c:\osgeo4~1\apps\python27\scripts\helpviewer.exe c:\osgeo4~1\apps\python27\scripts\img2png.exe c:\osgeo4~1\apps\python27\scripts\img2py.exe c:\osgeo4~1\apps\python27\scripts\img2xpm.exe c:\osgeo4~1\apps\python27\scripts\pycrust.exe c:\osgeo4~1\apps\python27\scripts\pyshell.exe c:\osgeo4~1\apps\python27\scripts\pyslices.exe c:\osgeo4~1\apps\python27\scripts\pyslicesshell.exe c:\osgeo4~1\apps\python27\scripts\pywxrc.exe c:\osgeo4~1\apps\python27\scripts\wxdemo.exe c:\osgeo4~1\apps\python27\scripts\wxdocs.exe c:\osgeo4~1\apps\python27\scripts\wxget.exe Proceed (y/n)? y Successfully uninstalled wxPython-4.0.3 You are using pip version 18.0, however version 18.1 is available. You should consider upgrading via the 'python -m pip install --upgrade pip' command. C:\>grass74 Cleaning up temporary files... Starting GRASS GIS... ATENÇÃO: Concurrent mapset locking is not supported on Windows __ ___ _____ / / __ \/ | / ___/ ___/ / / _/ ___/ / / __/ /_/ / /| | \__ \\_ \ / / __ / / \__ \ / /_/ / _, _/ ___ |___/ /__/ / / /_/ // / ___/ / \/_/ |_/_/ |_/// \/___/// Welcome to GRASS GIS 7.4.2 GRASS GIS homepage: http://grass.osgeo.org This version running through:Command Shell (C:\WINDOWS\system32\cmd.exe) Help is available with the command: g.manual -i See the licence terms with: g.version -c See citation options with: g.version -x Start the GUI with: g.gui wxpython When ready to quit enter:exit Microsoft Windows [Version 10.0.17134.345] (c) 2018 Microsoft Corporation. Todos os direitos reservados. C:\>g.gui wxpython Launching GUI in the background, please wait... C:\>python Python 2.7.14 (v2.7.14:84471935ed, Sep 16 2017, 20:25:58) [MSC v.1500 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import wx >>> wx.version() '2.8.12.1 (msw-unicode)' >>> import sys >>> print '\n'.join(sys.path) C:\OSGEO4~1\apps\grass\grass-7.4.2\etc\python C:\OSGeo4W64\apps\Python27 C:\OSGEO4~1\bin\python27.zip C:\OSGEO4~1\apps\Python27\DLLs C:\OSGEO4~1\apps\Python27\lib C:\OSGEO4~1\apps\Python27\lib\plat-win C:\OSGEO4~1\apps\Python27\lib\lib-tk C:\OSGEO4~1\bin C:\OSGEO4~1\apps\Python27 C:\OSGEO4~1\apps\Python27\lib\site-packages C:\OSGEO4~1\apps\Python27\lib\site-packages\jinja2-2.7.2-py2.7.egg C:\OSGEO4~1\apps\Python27\lib\site-packages\markupsafe-0.23-py2.7-win-amd64.egg C:\OSGEO4~1\apps\Python27\lib\site-packages\win32 C:\OSGEO4~1\apps\Python27\lib\site-packages\win32\lib C:\OSGEO4~1\apps\Python27\lib\site-packages\Pythonwin C:\OSGEO4~1\apps\Python27\lib\site-packages\wx-2.8-msw-unicode Thanks! Best regards, Pedro Martin Landa escreveu no dia quarta, 7/11/2018 à(s) 12:52: > Hi, > > st 7. 11. 2018 v 12:02 odesílatel Pedro Venâncio > napsal: > > >>> import wx > > >>> wx.version() > > u'4.0.3 msw (phoenix) wxWidgets 3.0.5' > > btw, have you installed wxPython on your own by pip? OSGeo4W still > comes with version 2.8.12 [1] > > Ma > > [1] https://download.osgeo.org/osgeo4w/x86_64/release/python/python-wx/ > > -- > Martin Landa > http://geo.fsv.cvut.cz/gwiki/Landa > http://gismentors.cz/mentors/landa > ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Problem starting GRASS GUI - ntpath splitdrive
rosoft Corporation. Todos os direitos reservados.
GRASS 6.4.3 (pinhel)> g.gui
Launching 'wxpython' GUI in the background, please wait ...
Traceback (most recent call last):
File "C:/OSGEO4~1/apps/grass/grass-6.4.3/etc/wxpython/wxgui.py", line 34,
in
from lmgr.frame import GMFrame
File "C:\OSGEO4~1\apps\grass\grass-6.4.3\etc\wxpython\lmgr\frame.py",
line 46, in
from lmgr.layertreeimport LayerTree, LMIcons
File "C:\OSGEO4~1\apps\grass\grass-6.4.3\etc\wxpython\lmgr\layertree.py",
line 37, in
from mapdisp.frame import MapFrame
File "C:\OSGEO4~1\apps\grass\grass-6.4.3\etc\wxpython\mapdisp\frame.py",
line 38, in
from vdigit.toolbarsimport VDigitToolbar
File
"C:\OSGEO4~1\apps\grass\grass-6.4.3\etc\wxpython\vdigit\toolbars.py", line
23, in
from vdigit.mainimport VDigit
File "C:\OSGEO4~1\apps\grass\grass-6.4.3\etc\wxpython\vdigit\main.py",
line 18, in
from vdigit.wxdigit import IVDigit, GV_LINES
File "C:\OSGEO4~1\apps\grass\grass-6.4.3\etc\wxpython\vdigit\wxdigit.py",
line 33, in
from vdigit.wxdisplay import DisplayDriver
File
"C:\OSGEO4~1\apps\grass\grass-6.4.3\etc\wxpython\vdigit\wxdisplay.py", line
29, in
from grass.lib.vector import *
File "C:\OSGEO4~1\apps\grass\grass-6.4.3\etc\python\grass\lib\vector.py",
line 23, in
_libs["grass_vect.6.4.3"] = load_library("grass_vect.6.4.3")
File
"C:\OSGEO4~1\apps\grass\grass-6.4.3\etc\python\grass\lib\ctypes_loader.py",
line 55, in load_library
return self.load(path)
File
"C:\OSGEO4~1\apps\grass\grass-6.4.3\etc\python\grass\lib\ctypes_loader.py",
line 221, in load
return _WindowsLibrary(path)
File
"C:\OSGEO4~1\apps\grass\grass-6.4.3\etc\python\grass\lib\ctypes_loader.py",
line 207, in __init__
self.cdll = ctypes.cdll.LoadLibrary(path)
File "C:\OSGEO4~1\apps\Python27\lib\ctypes\__init__.py", line 444, in
LoadLibrary
return self._dlltype(name)
File "C:\OSGEO4~1\apps\Python27\lib\ctypes\__init__.py", line 366, in
__init__
self._handle = _dlopen(self._name, mode)
WindowsError: [Error 126] The specified module could not be found
GRASS 6.4.3 (pinhel)>
Any help will be very welcome!
Thank you very much!
Best regards,
Pedro
Pedro Venâncio escreveu no dia terça, 6/11/2018
à(s) 20:11:
> Hi Helmut,
>
>
>
> Helmut Kudrnovsky escreveu no dia terça, 6/11/2018 à(s)
> 19:24:
>
>> >C:\>grass74
>> >Cleaning up temporary files...
>> >Starting GRASS GIS...
>> >ERROR: Invalid return code from GUI startup script.
>> >Please advise GRASS developers of this error.
>> >Exiting...
>> >Press any key to continue . . .
>>
>> what is the invalid return code?
>>
>
>
> The error falls here, like Markus said:
>
> def gui_startup(grass_gui):
> """Start GUI for startup (setting gisrc file)"""
> if grass_gui in ('wxpython', 'gtext'):
> ret = call([os.getenv('GRASS_PYTHON'), wxpath("gis_set.py")])
>
> # this if could be simplified to three branches (0, 5, rest)
> # if there is no need to handle unknown code separately
> if ret == 0:
> pass
> elif ret in [1, 2]:
> # 1 probably error coming from gis_set.py
> # 2 probably file not found from python interpreter
> # formerly we were starting in text mode instead, now we just fail
> # which is more straightforward for everybody
> fatal(_("Error in GUI startup. See messages above (if any)"
> " and if necessary, please"
> " report this error to the GRASS developers.\n"
> "On systems with package manager, make sure you have the
> right"
> " GUI package, probably named grass-gui, installed.\n"
> "To run GRASS GIS in text mode use the -text flag.\n"
> "Use '--help' for further options\n"
> " {cmd_name} --help\n"
> "See also:
> https://grass.osgeo.org/{cmd_name}/manuals/helptext.html;).format(
> cmd_name=cmd_name))
> elif ret == 5: # defined in gui/wxpython/gis_set.py
> # User wants to exit from GRASS
> message(_("Exit was requested in GUI.\nGRASS GIS will not start.
> Bye."))
> sys.exit(0)
> else:
> fatal(_("Invalid return code from GUI startup script.\n"
> "Please advise GRASS developers of this error."))
>
>
>
>>
>> is there another python installation on this windows system?
>>
>>
> Yes, I'v
Re: [GRASS-dev] Problem starting GRASS GUI - ntpath splitdrive
Hi Helmut,
Helmut Kudrnovsky escreveu no dia terça, 6/11/2018 à(s)
19:24:
> >C:\>grass74
> >Cleaning up temporary files...
> >Starting GRASS GIS...
> >ERROR: Invalid return code from GUI startup script.
> >Please advise GRASS developers of this error.
> >Exiting...
> >Press any key to continue . . .
>
> what is the invalid return code?
>
The error falls here, like Markus said:
def gui_startup(grass_gui):
"""Start GUI for startup (setting gisrc file)"""
if grass_gui in ('wxpython', 'gtext'):
ret = call([os.getenv('GRASS_PYTHON'), wxpath("gis_set.py")])
# this if could be simplified to three branches (0, 5, rest)
# if there is no need to handle unknown code separately
if ret == 0:
pass
elif ret in [1, 2]:
# 1 probably error coming from gis_set.py
# 2 probably file not found from python interpreter
# formerly we were starting in text mode instead, now we just fail
# which is more straightforward for everybody
fatal(_("Error in GUI startup. See messages above (if any)"
" and if necessary, please"
" report this error to the GRASS developers.\n"
"On systems with package manager, make sure you have the
right"
" GUI package, probably named grass-gui, installed.\n"
"To run GRASS GIS in text mode use the -text flag.\n"
"Use '--help' for further options\n"
" {cmd_name} --help\n"
"See also:
https://grass.osgeo.org/{cmd_name}/manuals/helptext.html;).format(
cmd_name=cmd_name))
elif ret == 5: # defined in gui/wxpython/gis_set.py
# User wants to exit from GRASS
message(_("Exit was requested in GUI.\nGRASS GIS will not start.
Bye."))
sys.exit(0)
else:
fatal(_("Invalid return code from GUI startup script.\n"
"Please advise GRASS developers of this error."))
>
> is there another python installation on this windows system?
>
>
Yes, I've Python 2.7 and Python 3.7, both instaled with OSGeo4W, one for
QGIS 2.18 and another for QGIS 3.4. But I've the same on another machine.
> >The strange thing is that both systems are similar, and it works in one,
> and not in another.
>
> can you delete all the content in:
>
> C:\Users\YourUserName\AppData\Roaming\GRASS7
>
> and try to restart
>
>
I already tested this, but after delete it, it only create an empty GRASS7
folder.
>
> what is happening when you're in text mode and do
>
> C:\>g.gui wxpython
>
> ?
C:\>g.gui wxpython
Launching GUI in the background, please wait...
C:\>
but it does not launch the GUI. Looking at the windows task manager
processes, the GRASS GUI process shows up, but closes right after a second
or so.
Thank you very much for the help Helmut and Markus!
Best regards,
Pedro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Problem starting GRASS GUI - ntpath splitdrive
Hi all,
It seems a local problem here, because I've tested in another machine and
everything works ok.
The strange thing is that both systems are similar, and it works in one,
and not in another.
Now I only get this message:
C:\>grass74
Cleaning up temporary files...
Starting GRASS GIS...
ERROR: Invalid return code from GUI startup script.
Please advise GRASS developers of this error.
Exiting...
Press any key to continue . . .
Running GRASS from the command line, works perfectly:
C:\>grass74 -text
Cleaning up temporary files...
Starting GRASS GIS...
ATENÇÃO: Concurrent mapset locking is not supported on Windows
__ ___ _____
/ / __ \/ | / ___/ ___/ / / _/ ___/
/ / __/ /_/ / /| | \__ \\_ \ / / __ / / \__ \
/ /_/ / _, _/ ___ |___/ /__/ / / /_/ // / ___/ /
\/_/ |_/_/ |_/// \/___///
Welcome to GRASS GIS 7.4.2
GRASS GIS homepage: http://grass.osgeo.org
This version running through:Command Shell
(C:\WINDOWS\system32\cmd.exe)
Help is available with the command: g.manual -i
See the licence terms with: g.version -c
See citation options with: g.version -x
Start the GUI with: g.gui wxpython
When ready to quit enter:exit
Microsoft Windows [Version 10.0.17134.345]
(c) 2018 Microsoft Corporation. Todos os direitos reservados.
C:\>
And also from QGIS (Processing and GRASS Plugin).
Any clue about what the problem could be?
Thank you very much.
Best regards,
Pedro
Pedro Venâncio escreveu no dia segunda,
5/11/2018 à(s) 17:28:
> Hi Martin,
>
> I did not have this environment variable set, but I set it and it still
> does not work.
>
> Anyway, I don't remember the last time I used GRASS GUI on this machine,
> but it was about 2 weeks ago.
>
> Then this problem must have resulted from a recent change / update.
>
> Thanks Martin.
>
> Best regards,
> Pedro
>
>
>
> Martin Landa escreveu no dia segunda, 5/11/2018
> à(s) 16:40:
>
>> Hi,
>>
>> po 5. 11. 2018 v 17:36 odesílatel Pedro Venâncio
>> napsal:
>> > os.getenv('HOMEPATH'))
>> > File "C:\OSGEO4~1\apps\Python27\lib\ntpath.py", line 65, in join
>> > result_drive, result_path = splitdrive(path)
>> > File "C:\OSGEO4~1\apps\Python27\lib\ntpath.py", line 115, in
>> splitdrive
>> > if len(p) > 1:
>> > TypeError: object of type 'NoneType' has no len()
>>
>> it seems that HOMEPATH environmental variable is not defined for your
>> account.
>>
>> > I'm using Windows 10.
>>
>> Based on [1] HOMEPATH should be defined on Windows 10 too.
>>
>> Haven't you unset HOMEPATH for your account by chance? Try to set
>> HOMEPATH pointing to your home directory.
>>
>> Martin
>>
>> [1]
>> https://www.tenforums.com/tutorials/3234-environment-variables-windows-10-a.html
>>
>> --
>> Martin Landa
>> http://geo.fsv.cvut.cz/gwiki/Landa
>> http://gismentors.cz/mentors/landa
>>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Problem starting GRASS GUI - ntpath splitdrive
Hi Martin,
I did not have this environment variable set, but I set it and it still
does not work.
Anyway, I don't remember the last time I used GRASS GUI on this machine,
but it was about 2 weeks ago.
Then this problem must have resulted from a recent change / update.
Thanks Martin.
Best regards,
Pedro
Martin Landa escreveu no dia segunda, 5/11/2018
à(s) 16:40:
> Hi,
>
> po 5. 11. 2018 v 17:36 odesílatel Pedro Venâncio
> napsal:
> > os.getenv('HOMEPATH'))
> > File "C:\OSGEO4~1\apps\Python27\lib\ntpath.py", line 65, in join
> > result_drive, result_path = splitdrive(path)
> > File "C:\OSGEO4~1\apps\Python27\lib\ntpath.py", line 115, in splitdrive
> > if len(p) > 1:
> > TypeError: object of type 'NoneType' has no len()
>
> it seems that HOMEPATH environmental variable is not defined for your
> account.
>
> > I'm using Windows 10.
>
> Based on [1] HOMEPATH should be defined on Windows 10 too.
>
> Haven't you unset HOMEPATH for your account by chance? Try to set
> HOMEPATH pointing to your home directory.
>
> Martin
>
> [1]
> https://www.tenforums.com/tutorials/3234-environment-variables-windows-10-a.html
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Problem starting GRASS GUI - ntpath splitdrive
Hi all,
I'm trying to start GRASS GUI, but I always get this error message:
Cleaning up temporary files...
Starting GRASS GIS...
ERROR: Invalid return code from GUI startup script.
Please advise GRASS developers of this error.
Exiting...
Press any key to continue . . .
I tried GRASS 7.4.2 and 7.4.1 from OSGeo4W 64bits, and the standalone
versions (32 and 64 bits). I also tried the 7.2.2, but without success.
C:\Windows\System32>grass74
Traceback (most recent call last):
File "C:\OSGEO4~1\apps\grass\grass-7.4.2\etc\grass74.py", line 2025, in
main()
File "C:\OSGEO4~1\apps\grass\grass-7.4.2\etc\grass74.py", line 1874, in
main
ensure_home()
File "C:\OSGEO4~1\apps\grass\grass-7.4.2\etc\grass74.py", line 720, in
ensure_home
os.getenv('HOMEPATH'))
File "C:\OSGEO4~1\apps\Python27\lib\ntpath.py", line 65, in join
result_drive, result_path = splitdrive(path)
File "C:\OSGEO4~1\apps\Python27\lib\ntpath.py", line 115, in splitdrive
if len(p) > 1:
TypeError: object of type 'NoneType' has no len()
Press any key to continue . . .
Traceback (most recent call last):
File "C:\Program Files (x86)\GRASS GIS 7.4.2\etc\grass74.py", line 2025,
in
main()
File "C:\Program Files (x86)\GRASS GIS 7.4.2\etc\grass74.py", line 1874,
in main
ensure_home()
File "C:\Program Files (x86)\GRASS GIS 7.4.2\etc\grass74.py", line 720,
in ensure_home
os.getenv('HOMEPATH'))
File "C:\Program Files (x86)\GRASS GIS 7.4.2\Python27\lib\ntpath.py",
line 65, in join
result_drive, result_path = splitdrive(path)
File "C:\Program Files (x86)\GRASS GIS 7.4.2\Python27\lib\ntpath.py",
line 115, in splitdrive
if len(p) > 1:
TypeError: object of type 'NoneType' has no len()
Press any key to continue . . .
Traceback (most recent call last):
File "C:\Program Files\GRASS GIS 7.2.2\etc\grass72.py", line 1984, in
main()
File "C:\Program Files\GRASS GIS 7.2.2\etc\grass72.py", line 1833, in main
ensure_home()
File "C:\Program Files\GRASS GIS 7.2.2\etc\grass72.py", line 716, in
ensure_home
os.getenv('HOMEPATH'))
File "C:\Program Files\GRASS GIS 7.2.2\Python27\lib\ntpath.py", line 73,
in join
elif isabs(b):
File "C:\Program Files\GRASS GIS 7.2.2\Python27\lib\ntpath.py", line 57,
in isabs
s = splitdrive(s)[1]
File "C:\Program Files\GRASS GIS 7.2.2\Python27\lib\ntpath.py", line 125,
in splitdrive
if p[1:2] == ':':
TypeError: 'NoneType' object has no attribute '__getitem__'
Press any key to continue . . .
Running GRASS algorithms from QGIS Processing, they work like expected, so
the problem must be only on the GUI (WXPython?).
I'm using Windows 10.
Any tip for overcoming this problem?
Thank you very much!
Best regards,
Pedro Venâncio
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] v.net.distance route description
Hi all, Is there any possibility, or is it a planned feature, to get the alphanumeric attributes of the network, in the results of v.net.distance tool? For example, if the network attribute table has the name of the streets, and if the result of v.net.distance (and other v.net.* tools) maintain the attributes of the original layer, and the resulting ordering of navigation, we could have the route description. Thank you very much. Best regards, Pedro ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] v.net.distance/path calculate the route in the reverse way
Hi Moritz,
Thank you for your test!
Can you try to run v.net.distance with the same sample data?
v.net.distance --overwrite input=mynet@PERMANENT output=distance_7779_7780
from_layer=2 from_cats=7779 to_layer=2 to_cats=7780 arc_column=FT_COST
arc_backward_column=TF_COST
v.net.distance --overwrite input=mynet@PERMANENT output=distance_7780_7779
from_layer=2 from_cats=7780 to_layer=2 to_cats=7779 arc_column=FT_COST
arc_backward_column=TF_COST
In the image attached, green line is the result of the first run
(from_layer=2 from_cats=7779 to_layer=2 to_cats=7780), and red line is the
result of (from_layer=2 from_cats=7780 to_layer=2 to_cats=7779).
It seems that it calculates the route in the reverse way. What do you think?
Thank you very much!
Best regards,
Pedro
2016-02-23 16:27 GMT+00:00 Moritz Lennert <mlenn...@club.worldonline.be>:
> On 23/02/16 15:44, Pedro Venâncio wrote:
>
>> Hi,
>>
>> I was testing the v.net.distance (in QGIS) and noticed something
>> strange. Apparently the route is calculated in a reverse way.
>>
>> If you see in this screencast
>>
>>
>> https://dl.dropboxusercontent.com/u/5772257/qgis/processing_grass_v_net_distance.ogv
>>
>>
>> I have a network of streets with two-way (green) and some with only
>> one-way (in red, with the arrow indicating the direction of traffic).
>> The two-way cost is in "dois_senti" field of the attribute table, and
>> the sections of one-way have -1 value in the "um_senti" field of the
>> attribute table.
>>
>> The starting point is the orange pentagon ("ponto_inicio"), and the
>> destination point is the green star ("ponto_chegada").
>>
>> As you can see, v.net.distance calculate the route in the reverse way,
>> that is, when I choose "ponto_inicio" as "from", and "ponto_chegada" as
>> "to" (first run in the screencast), it gives me the route by the south
>> ("ponto_chegada" -> "ponto_inicio"). In the second run, I choose
>> "ponto_chegada" as "from", and "ponto_inicio" as "to", and it uses the
>> one-way street. So, the topology is respected, but it seems that "from"
>> and "to" are used in a reverse manner.
>>
>> I thought it might be a mistake in implementing the tool in QGIS
>> Processing, but then I performed the same procedure on GRASS 7.0.2
>> native, and the result is the same.
>>
>> Médéric Ribreux has done also some tests and concluded that from_layer
>> is used as to_layer.
>>
>> It seems to be a GRASS problem because the point layers order is correct:
>> - layer 2 is imported from FROM_CENTERS QGIS layer.
>> - layer 3 is imported from TO_CENTERS QGIS layer.
>> - layer 2 is used as from_layer in v.net.distance.
>> - layer 3 is used as to_layer in v.net.distance.
>>
>> He has tried with v.net.path and got the same results than for
>> v.net.distance.
>>
>> Could it be a mis-interpretation of forward and backward costs? A bug?
>> Or simply how the tool works?
>>
>
>
> I cannot reproduce this with the NC demo data set;
>
> v.net -c streets_wake op=nodes out=mynet
> v.db.update map=mynet@user1 column=TF_COST value=-1 where=ONE_WAY='FT'
> v.db.update map=mynet@user1 column=FT_COST value=-1 where=ONE_WAY='TF'
> echo "1 7779 7780
> 2 7780 7779" | v.net.path mynet out=paths arc_column=FT_COST
> arc_backward_column=TF_COST
>
> Display:
> d.vect map=mynet@user1
> d.vect map=mynet@user1 display=shape,dir where="ONE_WAY='FT' OR
> ONE_WAY='TF'" color=red attribute_column=ONE_WAY yref=top
> d.vect map=mynet@user1 layer=2 display=shape,cat cats=7779-7780
> fill_color=255:165:0 icon=basic/circle label_layer=2
> d.vect map=paths@user1 display=shape,cat cats=1 color=0:128:0 width=2
> label_color=0:128:0
> d.vect map=paths@user1 display=shape,cat cats=2 color=128:0:128 width=2
> label_color=128:0:128
>
> gives the expected result (see attached image).
>
> Note that the line connecting 7779 and 7780 directly has a one_way value
> of 'TF' meaning that it is one-way in direction to-from, i.e. from 7780 to
> 7779 (direction of the line being indicated by the arrows).
>
> Errors can occur if the costs are not well-defined or too small. In the
> source code of the Vect_net_build_graph() function which builds the network
> graph the path is found upon, it says:
>
> "Internal format for edge costs is integer, costs are multiplied before
> conversion to int by 1000"
>
> This means that if you have a cost lower than 1/1000, you might end up
> with costs = 0.
>
> This is noted as a todo in the source code:
>
> "/* TODO int costs -> double (waiting for dglib) */"
>
> But AFAICS, dglib still uses integers for costs.
>
> This is not mentioned in the man page, and should be.
>
> Please verify if this is the origin of your problem.
>
> If yes, please post a bug report on bad documentation. If this isn't the
> problem, please post a bug report with a reproducible example.
>
> Moritz
>
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] v.net.distance/path calculate the route in the reverse way
Hi,
I was testing the v.net.distance (in QGIS) and noticed something strange.
Apparently the route is calculated in a reverse way.
If you see in this screencast
https://dl.dropboxusercontent.com/u/5772257/qgis/processing_grass_v_net_distance.ogv
I have a network of streets with two-way (green) and some with only one-way
(in red, with the arrow indicating the direction of traffic). The two-way
cost is in "dois_senti" field of the attribute table, and the sections of
one-way have -1 value in the "um_senti" field of the attribute table.
The starting point is the orange pentagon ("ponto_inicio"), and the
destination point is the green star ("ponto_chegada").
As you can see, v.net.distance calculate the route in the reverse way, that
is, when I choose "ponto_inicio" as "from", and "ponto_chegada" as "to"
(first run in the screencast), it gives me the route by the south
("ponto_chegada" -> "ponto_inicio"). In the second run, I choose
"ponto_chegada" as "from", and "ponto_inicio" as "to", and it uses the
one-way street. So, the topology is respected, but it seems that "from" and
"to" are used in a reverse manner.
I thought it might be a mistake in implementing the tool in QGIS
Processing, but then I performed the same procedure on GRASS 7.0.2 native,
and the result is the same.
Médéric Ribreux has done also some tests and concluded that from_layer is
used as to_layer.
It seems to be a GRASS problem because the point layers order is correct:
- layer 2 is imported from FROM_CENTERS QGIS layer.
- layer 3 is imported from TO_CENTERS QGIS layer.
- layer 2 is used as from_layer in v.net.distance.
- layer 3 is used as to_layer in v.net.distance.
He has tried with v.net.path and got the same results than for
v.net.distance.
Could it be a mis-interpretation of forward and backward costs? A bug? Or
simply how the tool works?
Thanks!
Best regards,
Pedro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] no grass plugin in qgis installed from osgeo4w
Hi Veronica, Did you install GRASS in OSGeo4W? Which version? On Sunday I made an installation on Windows and I found a problem. GRASS 7.0.2RC is already available on OSGeo4W. However, the .bat file that is created for the use of GRASS7 with QGIS, does not work, because it points to the folder structure of GRASS 7.0.1. I don't know if this has been corrected since then, and whether this might be your problem. I am forwarding this thread also for QGIS mailing list. Best regards, Pedro Venâncio 2015-10-27 13:23 GMT+00:00 Veronica Andreo <veroand...@gmail.com>: > Hi devs, > > me again, sorry... > > So, this comes from the previous email, but it is a different issue... > > I also got qgis stable (2.12) from osgeo4w 32bits installer and there > seems to be NO grass plugin installed nor available in the plugin list. > > There's also NO grass tools in Processing and I have the latest version > avilable. I guess I missed selecting some other things in the installation > process, but don't know what. > > Any instruction is welcome! :) > > Cheers, > Vero > > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev > ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] no grass plugin in qgis installed from osgeo4w
Veronica, Yes! Thanks much, Moritz! Was searching in the wrong place (hihihi). This > solved the issue with using grass tools through Processing. > > Still grass plugin missing. > > Can you please install GRASS 7.0.1-1 instead of 7.0.2RC1-1? To do so, go to OSGeo4W -> Advanced Install -> Desktop You should have something like 7.0.2RC1-1 Skip ... grass: GRAS GIS - stable release Please, click in "Skip" and you should get 7.0.1-1. Click Next, install this version and then try again GRASS plugin in QGIS (search for GRASS 7 in Plugins -> Manage and Install Plugins). As Moritz said, Processing GRASS is independent from GRASS Plugin. Thanks, Pedro ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [Qgis-developer] QGIS and GRASS 7.0.0
Hi Radim, The new GRASS vector editing tool preview screencast: https://www.youtube.com/watch?v=PPno1aLYHFE It looks really really great! Best regards, Pedro ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] ubuntu 7.0.0RC1
Hi Martin, I also confirm, everything is ok now with sudo apt-get install grass70 Thank you very much! Best regards, Pedro ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] ubuntu 7.0.0RC1
Hi Martin, sudo add-apt-repository ppa:ubuntugis/ubuntugis-unstable sudo add-apt-repository ppa:grass/grass-stable sudo apt-get update sudo apt-get install grass70 I also get the dependencies error. But it works with sudo apt-get install grass70-core grass70-gui grass70-doc Is there something wrong with grass70 metapackage? Thanks! Best regards, Pedro ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 7 - Ubuntu package build problem on Launchpad
Martin, could you trigger update + recompile? I hope I just fixed the
annoying no Version issue on Ubuntu.
Hi Markus, Ivan, Martin,
I just installed version 7.0.0+1svn63885~ubuntu12.04.1 (Ubuntu 12.04
32bits), and the problem with version persists:
Launching wxpython GUI in the background, please wait...
Unable to get GRASS version
Unable to get GRASS version
GRASS 7.0.0 (pinhel):~ g.version -g --v
version=7.0.0svn
date=2014
revision=0
build_date=2014-12-31
build_platform=i686-pc-linux-gnu
GRASS 7.0.0 (pinhel):~ g.extension -c -a
Traceback (most recent call last):
File /usr/lib/grass70/scripts/g.extension, line 1088, in module
version = grass.version()['version'].split('.')
KeyError: 'version'
Moreover, it continually crashes the g.extension, as soon as I start GRASS.
Thanks.
Best regards,
Pedro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] Using r.quantile result with r.recode
Hi Glynn, - Original Message - From: Glynn Clements r.recode will treat boundary values as belonging to the upper range, e.g. in the above example, 6.0 will get recoded to 2. So we can not use directly the result of r.quantile with -r flag in r.recode, right? In the example, 6 should be recoded to 1, right? Thank you very much! Best regards, Pedro Pedro Venâncio wrote: Thank you very much for your answer! My question lies precisely in the need to know if a quantile value which falls as the upper limit for one range and the lower limit of the next, should belong to the class anterior or posterior. For example, assuming that r.quantile (with -r flag) gives this result: 2:6:1 6:8:2 8:12:3 12:20:4 20:873:5 the value 6 should belong to the first class or second? r.recode will treat boundary values as belonging to the upper range, e.g. in the above example, 6.0 will get recoded to 2. This behaviour stems from Rast_fpreclass_get_cell_value() in lib/raster/fpreclass.c, and isn't configurable (i.e. there's no way that r.recode's behaviour could be modified without modifying the fpreclass functions). -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Using r.quantile result with r.recode
Hi, I have a doubt about using the r.quantile output with r.recode. r.quantile returns the upper limit value corresponding to each class, right? But r.recode uses r.quantile result as closed interval in the lower value and open interval in the upper value. In other words, assuming that r.quantile returns the following result: 2.00:6.00:1 6.00:8.00:2 8.00:12.00:3 12.00:20.00:4 20.00:872.727295:5 r.recode will use these data as follows: [2.00:6.00[ - 1 [6.00:8.00[ - 2 [8.00:12.00[ - 3 [12.00:20.00[ - 4 [20.00:872.727295[ - 5 But this is not correct. According to quantiles method, the reclassification should be as follows: ]2.00:6.00] - 1 ]6.00:8.00] - 2 ]8.00:12.00] - 3 ]12.00:20.00] - 4 ]20.00:872.727295] - 5 or am I wrong? Thanks! Best regards, Pedro Venâncio ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
