Re: [GRASS-dev] r.statistics in G7

2013-06-29 Thread Helmut Kudrnovsky
hi, r.statistics r.statistics2 r.statistics3 r.statistics2 is intended to be a partial replacement for r.statistics, with support for floating-point cover maps at the expense of not support quantiles. [1] r.statistics3 is intended to be a partial replacement for r.statistics, with support for

Re: [GRASS-dev] GRASS GIS 7 tech-preview release preparations

2013-07-12 Thread Helmut Kudrnovsky
- the python issues in wingrass (notably how to correctly install python to be able to launch scripts and addons) IMHO it's one of the showstoppers in winGRASS7 not only correctly installing python, but also what is the structure/approach in C:\Users\\AppData\Roaming\GRASS7\addons\ of

Re: [GRASS-dev] v.kcv - new version

2013-07-16 Thread Helmut Kudrnovsky
Dear developers, in connection with attempts to rewrite some GRASS module with OpenMP we have rewrote the v.kcv module. The new version is much faster that the previous (no OpenMP is now needed - there is only one loop now with direct writing to the resulting layer). We believe that the new

[GRASS-dev] g.extension.py at (win)grass7-wxgui-startup needed?

2013-07-22 Thread Helmut Kudrnovsky
hi, system here: System Info GRASS version: 7.0.svn GRASS SVN Revision: 57202 Build Date: 2013-07-18

Re: [GRASS-dev] g.extension.py at (win)grass7-wxgui-startup needed?

2013-07-22 Thread Helmut Kudrnovsky
hi, Since r57144 menu can contain an entry which will show the list of installed addons. In the current version, the addons entry is included in Search module (in module tree) if some addons are installed. [1] http://trac.osgeo.org/grass/changeset/57144 is this needed? g.extension is

Re: [GRASS-dev] GRASS 6.4.3 release planning

2013-07-23 Thread Helmut Kudrnovsky
Today could be a great rlease-6.4.3-day :) we are so close to 30 July that we could wait a week and release in the same day of his born :-) +1 - best regards Helmut -- View this message in context:

Re: [GRASS-dev] Python handling in winGRASS7 [was: Re: GRASS GIS 7 tech-preview release preparations]

2013-07-25 Thread Helmut Kudrnovsky
hi Moritz, Is this a correct summary of the issues ? Anything I'm missing ? thanks for the summary, some additions below. On 12/07/13 23:50, Helmut Kudrnovsky wrote: - the python issues in wingrass (notably how to correctly install python to be able to launch scripts and addons) IMHO it's

Re: [GRASS-dev] Python handling in winGRASS7 [was: Re: GRASS GIS 7 tech-preview release preparations]

2013-07-25 Thread Helmut Kudrnovsky
e.g. here in my Win7-box ArcGIS10.1 does a system wide registry entry for python 2.7 (see above) and therefore the standalone-WinGRASS 7-installer with an embedded python 2.7 doesn't start because of a mismatch of some lib/etc. small correction: standalone-WinGRASS 7-installer -

Re: [GRASS-dev] Python handling in winGRASS7 [was: Re: GRASS GIS 7 tech-preview release preparations]

2013-07-26 Thread Helmut Kudrnovsky
hi, On 26/07/13 00:04, Helmut Kudrnovsky wrote: [...] Would it be a possible option to implement only a) there is already a bundled/embedded python in standalone WinGRASS6/7 and OSGeo4w-WinGRASS6/7. some more issues related to WinGRASS and python are mentioned also in http://trac.osgeo.org

Re: [GRASS-dev] Python handling in winGRASS7 [was: Re: GRASS GIS 7 tech-preview release preparations]

2013-07-26 Thread Helmut Kudrnovsky
[...] Yes, so this should be reformulated as keep the current option of bundling an embedded python. yes However, again within the limits of my understanding, aren't the issues of - calling a script from a script and - making addons easily callable linked to the question of system-wide vs

Re: [GRASS-dev] Python handling in winGRASS7 [was: Re: GRASS GIS 7 tech-preview release preparations]

2013-07-26 Thread Helmut Kudrnovsky
IMHO the question is/will be: is there a robust mechanism for calling a script from a script and making addons easily callable by the embedded python interpreter working on WinXp, WinVista, Win7 and Win8? if this is working robustely, I think we are on a good way for a nice (python) usable

Re: [GRASS-dev] Python handling in winGRASS7 [was: Re: GRASS GIS 7 tech-preview release preparations]

2013-07-26 Thread Helmut Kudrnovsky
Note that Python 3 includes a launcher utility for Windows: http://docs.python.org/3/using/windows.html#launcher The idea is that the .py extension can be associated with the launcher, which can be configured to use a specific version of Python in a specific context. I don't know

Re: [GRASS-dev] Python handling in winGRASS7 [was: Re: GRASS GIS 7 tech-preview release preparations]

2013-07-27 Thread Helmut Kudrnovsky
Note that Python 3 includes a launcher utility for Windows: http://docs.python.org/3/using/windows.html#launcher The idea is that the .py extension can be associated with the launcher, which can be configured to use a specific version of Python in a specific context. I don't know

Re: [GRASS-dev] r57291: configure.in: disable pwd -W (WinGRASS)

2013-07-28 Thread Helmut Kudrnovsky
Martin Landa wrote: When spending time on that and other fucking Windows issues thanks a lot for your attempt to tame the beast!! - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/r57291-configure-in-disable-pwd-W-WinGRASS-tp5069162p5069229.html

Re: [GRASS-dev] Celebrating 30 years of GRASS GIS!

2013-07-30 Thread Helmut Kudrnovsky
*Press release* *29 July 2013* Today marks 30 years of GRASS GIS development Markus, thank you very much for coordinating and keeping things running for such a long time!!! - best regards Helmut -- View this message in context:

Re: [GRASS-dev] wingrass7 nightly builds

2013-08-01 Thread Helmut Kudrnovsky
On 26/07/13 13:45, Moritz Lennert wrote: Any idea when wingrass7 nightly builds will be available again ? As many of the current critical issues for grass7 are windows specific, it would be great to have the nightly builds to help in testing. ping at least osgeo4w-wingrass is again there

Re: [GRASS-dev] standalone installer cleanup

2013-08-02 Thread Helmut Kudrnovsky
hi, Martin Landa wrote 2013/8/2 Martin Landa lt; landa.martin@ gt;: 2013/8/2 Hamish lt; hamish_b@ gt;: re. r57342, the PROJ_LIB variable is needed by e.g. cs2cs used by some scripts, are you sure about that?, proj lib in the path (`extralib`) or it refers to share stuff?

Re: [GRASS-dev] WinGRASS6.4.3 crashing

2013-08-16 Thread Helmut Kudrnovsky
hi Helena, After clicking on the GRASS icon the cli window just flashes and the startup page does not open. did you activated to download the needed microsoft runtimes? it's on the download tab (ms files and sample datasets) during the installation of the standalone installer. It is worrisome

[GRASS-dev] osgeo4w-wingrass7 broken

2013-09-02 Thread Helmut Kudrnovsky
hi, since a few days osgeo4w-wingrass7 seems to be broken http://wingrass.fsv.cvut.cz/grass70/logs/log-r57581-691/ http://wingrass.fsv.cvut.cz/grass70/logs/log-r57581-691/error.log seems to be related to http://lists.osgeo.org/pipermail/grass-dev/2013-September/065518.html any chance to fix

Re: [GRASS-dev] Weekly report #14 - GRASS Interactive Scatter Plot Tool

2013-09-23 Thread Helmut Kudrnovsky
Štěpán Turek wrote Hi, I have created documentation and tutorial video (more info at [1]).  Also I have started to move scatter plot code into trunk. Today or tomorrow it should be there all. Best Stepan [1] http://grasswiki.osgeo.org/wiki/GRASS_GSoC_2013_GRASS_GIS_Interactive_

Re: [GRASS-dev] Handling of Python scripts on MS Windows

2013-10-07 Thread Helmut Kudrnovsky
Markus Neteler wrote On Mon, Oct 7, 2013 at 9:57 AM, Moritz Lennert lt; mlennert@.worldonline gt; wrote: A solution might be to try to focus resources in the form of a specific Windows code sprint, ideally with some Windows power hackers who could help us. BTW, it seems that the same

Re: [GRASS-dev] Handling of Python scripts on MS Windows

2013-10-07 Thread Helmut Kudrnovsky
To start with, it needs to be established that Python is actually installed correctly. To this end, I need to see the output from the shell commands: assoc .py ftype python.file echo %PATHEXT% tested with a _not pristine_ win7 + python-installation, so more eventualities

Re: [GRASS-dev] Handling of Python scripts on MS Windows

2013-10-09 Thread Helmut Kudrnovsky
I was referring to cmd.exe *within* a GRASS session. ok, 2 tests with another windows VISTA box because of travelling (win7-box from earlier test not available atm), now within a GRASS session: --- winGRASS-session (1) winGRASS 7 standalone installer and no python

Re: [GRASS-dev] 6.4.4 planning

2013-11-24 Thread Helmut Kudrnovsky
Markus Neteler wrote On Sat, Nov 16, 2013 at 3:00 AM, Hamish lt; hamish_b@ gt; wrote: on the grass-user ML Markus N wrote: (and it is time to get 6.4.4 out...) Important bugs concerning the next release https://trac.osgeo.org/grass/report/13 No blocker at time! The other two

Re: [GRASS-dev] Handling of Python scripts on MS Windows

2014-01-20 Thread Helmut Kudrnovsky
Hi Moritz, Maybe we could try to organize a virtual sprint where we all decide of a day and time for which we all prepare windows machines so that we can try to concentrate on this, major, issue and hopefully solve it once and for all. maybe the GRASS Community Sprint Vienna 2014

Re: [GRASS-dev] Handling of Python scripts on MS Windows

2014-01-21 Thread Helmut Kudrnovsky
Moritz Lennert wrote On 21/01/14 16:34, Glynn Clements wrote: Moritz Lennert wrote: Another option would be to do what Glynn has been proposing all along (IIUC), which is to not install Python with Wingrass, but rather leave it up to the user to make sure a suitable Python is installed in

Re: [GRASS-dev] Handling of Python scripts on MS Windows

2014-01-28 Thread Helmut Kudrnovsky
WinGRASS does not set registry associations for Python scripts, nor does it install Python system-wide. This is because we do not want to modify an existing Python installation. I second this. - best regards Helmut -- View this message in context:

Re: [GRASS-dev] Handling of Python scripts on MS Windows

2014-01-28 Thread Helmut Kudrnovsky
As someone who uses both ArcGIS and GRASS on windows, I see it as a bonus that the python installations are separate. I can recommend that folks in my agency install GRASS on a computer and I can assure them that it does not affect their ArcGIS installation, with it's own ESRI - specific version

Re: [GRASS-dev] Handling of Python scripts on MS Windows

2014-02-06 Thread Helmut Kudrnovsky
Glynn Clements wrote Markus Metz wrote: Other projects such as gimp or libreoffice are AFAICT reasonably bundled with Python, without a Python installer. They aren't attempting to support Python scripts as stand-alone programs (i.e. something which can be run from the command prompt,

Re: [GRASS-dev] Handling of Python scripts on MS Windows

2014-02-08 Thread Helmut Kudrnovsky
hi, But there are also downsides to this: We would need to think about different mechanisms for each supported OS; we could get tangled up in all sorts of flawed decisions by the OS designers; I think we are already there regarding MS windos OS and python ... Whatever the decision may be:

Re: [GRASS-dev] Handling of Python scripts on MS Windows

2014-02-10 Thread Helmut Kudrnovsky
Therefore we need hard-coded special treatment for shell and Python scripts in order to make sure that the correct interpreter is used. Just for my understanding: When you say hard-coded special treatment for shell scripts, are you speaking about the .bat files ? I think yes. - best

Re: [GRASS-dev] Handling of Python scripts on MS Windows

2014-02-10 Thread Helmut Kudrnovsky
GRASS Python scripts are currently executed using the system-wide installed Python if it exists. No attempt has been made to explicitly use GRASS_PYTHON, therefore it is not possible to say if the system's Python would really be completely ignored. it is (partly) implemented ( and tested on Win7

Re: [GRASS-dev] Handling of Python scripts on MS Windows

2014-02-10 Thread Helmut Kudrnovsky
wenzeslaus wrote If I remember correctly, Python scripts were not working from Python scripts, they were working from command line. And we were not able to explain why the right Python (or Python DLL) is used at one point but not the other. If there wouldn't be shell=True [1], I would say that

Re: [GRASS-dev] r.profile limits in Windows 7

2014-02-14 Thread Helmut Kudrnovsky
note WinGRASS binaries are still 32 bit, actually there is OSGeo4W-64bit ready for testing (http://trac.osgeo.org/osgeo4w/): (1) Download the 32bit or 64bit OSGeo4W network installer (previous 32bit only installer) winGRASS6.4.3.-64bit is included. - best regards Helmut -- View this

[GRASS-dev] (standalone/OSGeo4W)Wingrass-R-integration - which way to go?

2014-03-09 Thread Helmut Kudrnovsky
Hi devs, some time ago [1] I've integrated R-batch-files [2] into the GRASS GIS source [3] for a nice WinGRASS-R-integration [4]. At the moment this functionality of a dynamic R-integration is only available for standalone WinGRASS7svn, in standalone WinGRASS6.x a static approach of a

Re: [GRASS-dev] (standalone/OSGeo4W)Wingrass-R-integration - which way to go?

2014-03-09 Thread Helmut Kudrnovsky
(C) try to include the R-batch-files into OSGeo4W-environment as its own package - a R-GRASS- integration would be then possible for standalone WinGRASS6/7 AND OSGeo4W-WinGRASS6/7 just forgotten to mention, with alternative (C) OSGeo4W and other projects may benefit from a smooth

Re: [GRASS-dev] (standalone/OSGeo4W)Wingrass-R-integration - which way to go?

2014-03-10 Thread Helmut Kudrnovsky
Hi Massimo, That will be great! we do need grass able to talk with R also in osgeo4w. unlike as rpy2 are R-python-bindings, the R-batchfiles simply enables invoking R from anywhere you are, e.g. within a WinGRASS-session or within a OSGeo4W-shell/commandline: echo The script is self contained

Re: [GRASS-dev] (standalone/OSGeo4W)Wingrass-R-integration - which way to go?

2014-03-10 Thread Helmut Kudrnovsky
hi, That will be great! we do need grass able to talk with R also in osgeo4w. ok, I've testet a stripped down R-batch-file http://osgeo-org.1560.x6.nabble.com/file/n5128182/setR.bat and put it into C:\OSGeo4W\etc\ini results: - R (R and RGui) starts in 'OSGeo4W Shell' and 'OSGeo4W'

Re: [GRASS-dev] Proposal Review [is GSOC Compiling GRASS GIS on Android]

2014-03-19 Thread Helmut Kudrnovsky
Barun Paudel wrote Hey Everyone, I have attached the draft of my proposal.I do hope i would get more improvisation on the proposal. I have few questions regarding the proposal. [1].Is the proposal to be uploaded to GSoC website once we create the profile there? [2] Is the proposal need to

Re: [GRASS-dev] Proposal Review

2014-03-19 Thread Helmut Kudrnovsky
[1].Is the proposal to be uploaded to GSoC website once we create the profile there? [2] Is the proposal need to verified by the mentor and mentoring organization before uploading it? there is also a dedicated OSGeo-GSoC-mailing list (http://lists.osgeo.org/mailman/listinfo/soc). please also

[GRASS-dev] r.stream.* to trunk - what about r.stream.basins?

2014-03-27 Thread Helmut Kudrnovsky
hi, at the Vienna Code Sprint we're discussing moving the r.stream.* -modules to trunk. transition most of the r.stream.* is clear, but there may be some overlapping between r.water.outlet, r.watershed and r.stream.basins. short comparison - r.water.outlet [2] generates a watershed basin from

[GRASS-dev] [GRASS-user] winGRASS 7 - R - integration - standalone/OSGeo4W - NEWS

2014-04-05 Thread Helmut Kudrnovsky
http://lists.osgeo.org/pipermail/grass-user/2014-April/070136.html hi winGRASS-users, at the Vienna Code Sprint GRASS GIS 7.0.0 beta 1 [1] went into the wild, yeah ... :-) so it was also time to update to update winGRASS 7 - R - integration (see r59583 - r59590) with an update of the Windows

Re: [GRASS-dev] [GRASS-PSC] too many branches = retirement GRASS6.5.svn (=develbranch6)

2014-04-07 Thread Helmut Kudrnovsky
Markus Metz-3 wrote Since the code base of devbr6 and relbr6 is largely identical, the same fix can be applied to both branches which is not a lot of work. ___ grass-psc mailing list grass-psc at .osgeo

Re: [GRASS-dev] [GRASS-PSC] too many branches = retirement GRASS6.5.svn (=develbranch6)

2014-04-09 Thread Helmut Kudrnovsky
One Windows problem is that there is no package manager who takes the user's hand which is the reason for these large standalone applications on MS Windows. [...] Personally, I am a bit afraid that by going down the first route we concentrate much developer time that could be spent on other

Re: [GRASS-dev] Handling of Python scripts on MS Windows

2014-04-10 Thread Helmut Kudrnovsky
[...] GRASS 6 creates a .bat file for each shell script. And this .bat file specifies the script interpreter. Looks like a good solution to also select the correct Python version. [...] Other projects also bypass the standard execution mechanism of python scripts, and they work just fine in MS

[GRASS-dev] Tcl/Tk completly removed in grass trunk/relbranch7?

2014-04-12 Thread Helmut Kudrnovsky
hi, I've seen that in the preparing script for the standalone-installer winGRASS7/relbranch7 these lines http://trac.osgeo.org/grass/browser/grass/trunk/mswindows/GRASS-Packager.bat.tmpl#L123 @echo Copy Tcl/Tk content to PACKAGE_DIR\lib is Tcl/Tk completly in grass trunk/relbranch7?

Re: [GRASS-dev] Tcl/Tk completly removed in grass trunk/relbranch7?

2014-04-12 Thread Helmut Kudrnovsky
right, it's leftover, please remove it from trunk and relbr70. done by r59702, r59703 - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Tcl-Tk-completly-removed-in-grass-trunk-relbranch7-tp5134726p5134730.html Sent from the Grass - Dev mailing

Re: [GRASS-dev] Handling of Python scripts on MS Windows

2014-04-12 Thread Helmut Kudrnovsky
Hi Jürgen, Hi Helmut, [...] Not sure if I want to participate in this thread. thanks for sharing your experience anyway. I think a system installation of python is uncommon. yes I'm also thinking so if windows comes in ... [...] And thereby avoid having special treatment for .py scripts

Re: [GRASS-dev] Handling of Python scripts on MS Windows

2014-04-12 Thread Helmut Kudrnovsky
thanks also for the link! that's all about we're discussing here. Python Launcher just forgotten, some ugly tests for Python Launcher: http://trac.osgeo.org/grass/ticket/2015#comment:6 - best regards Helmut -- View this message in context:

Re: [GRASS-dev] Handling of Python scripts on MS Windows

2014-04-13 Thread Helmut Kudrnovsky
Hi Moritz, 1) Should GRASS be the same (i.e. feature parity) on all platforms ? for sure, why not? 2) How much less effort can we ask of Windows users than we ask of users of other platforms ? GRASS was developed in a time when Windows didn't even exist. And it was developed in a very

Re: [GRASS-dev] Handling of Python scripts on MS Windows

2014-04-14 Thread Helmut Kudrnovsky
So, there is a vision by some that for the reasons of apparent incompatibility between the way GRASS works and Windows, GRASS has to be different on windows. I.e. that GRASS has to become a monolithic application on Windows. I wouldn't call it incompatibility and I think GRASS hasn't to be

Re: [GRASS-dev] Handling of Python scripts on MS Windows

2014-04-26 Thread Helmut Kudrnovsky
wenzeslaus wrote Please consider this scenario: 1. user installs ArcGIS which installs Python system-wide 2. user installs GRASS GIS which will use system-wide Python 2. may or may not work out of the box ... there are a lot of uncertain issues to consider (version, dependencies, etc. etc.)

Re: [GRASS-dev] Handling of Python scripts on MS Windows

2014-04-28 Thread Helmut Kudrnovsky
Hamish wrote: I think that's more a reflection on the way things are done in the MS Windows world: the last program to install itself wins. yes Which leads to the usual 1st trouble shooting step on Windows after seeing if a rebooting helps: try uninstalling then reinstalling the program. Then

[GRASS-dev] wingrass71: rendering problems with raster layers automatically added by finished modules

2014-05-03 Thread Helmut Kudrnovsky
Hi, tested with winGRASS71 by osgeo4w from today. Rendering is activated in map display. start e.g. r.slope.aspect in the wxgui, define more than one outputs. Automatically adding the results to map display is activated. run r.slope.aspect, after the output results are added to map display,

[GRASS-dev] osgeo4w: gdal 1.11.0 - adapt grass/trunk/mswindows/osgeo4w/gdal-config

2014-05-04 Thread Helmut Kudrnovsky
hi, in osgeo4w, gdal was recently updated to gdal 1.11.0 in [1] it refers to gdal 1.9.0 [...] 8 CONFIG_VERSION=1.9.0 [...] should this be updated to 1.11.0? [1] http://trac.osgeo.org/grass/browser/grass/trunk/mswindows/osgeo4w/gdal-config - best regards Helmut -- View this

Re: [GRASS-dev] wingrass71: rendering problems with raster layers automatically added by finished modules

2014-05-04 Thread Helmut Kudrnovsky
Helmut Kudrnovsky wrote Hi, tested with winGRASS71 by osgeo4w from today. Rendering is activated in map display. start e.g. r.slope.aspect in the wxgui, define more than one outputs. Automatically adding the results to map display is activated. run r.slope.aspect, after the output

[GRASS-dev] how to do g.region n=n+(defined by user input option) in a python script?

2014-05-08 Thread Helmut Kudrnovsky
hi, I'm trying to understand how to use g.region n=n+x s=s-x e=e+x w=w-x in a python script, where x is a user option. some code snippets: #%option #% key: region_extension #% type: double #% key_desc: float #% description: region extension #% required : no #% answer: 5000 #%end [...]

Re: [GRASS-dev] how to do g.region n=n+(defined by user input option) in a python script?

2014-05-08 Thread Helmut Kudrnovsky
regext will be a string; you need to use e.g. regext = float(regext) before you can do arithmetic with it. ah, I see it now. Also, unless the purpose of the script is to modify the region for subsequent commands, either use use_temp_region() to localise any changes to the script.

[GRASS-dev] how to use the WHERE ... AND ... in a python script using variables?

2014-05-08 Thread Helmut Kudrnovsky
hi, given some vector with a attribute table column defined as integer/double. task: updating the attribute table by a WHERE ... AND ... clause. some code snippet Python 2.7.4 (default, Apr 6 2013, 19:54:46) [MSC v.1500 32 bit (Intel)] on win32 Type help, copyright, credits or license for

Re: [GRASS-dev] how to use the WHERE ... AND ... in a python script using variables?

2014-05-08 Thread Helmut Kudrnovsky
grass.run_command(db.execute, sql = UPDATE %s SET %s='*', WHERE %s 2 AND %s 3 % (A, B, C, C)) to answer my own question ;-), there WHERE clause is part of the sql command ... bingo. grass.run_command(db.execute, sql = UPDATE %s SET %s='*' WHERE %s 2 AND %s 3 % (A, B, C, C)) works fine,

[GRASS-dev] [gdal-dev] Update of EPSG database to v8.4

2014-05-14 Thread Helmut Kudrnovsky
fyi from the GDAL-dev ML http://lists.osgeo.org/pipermail/gdal-dev/2014-May/039054.html - Even Rouault: Hi, I've followed the update process of the EPSG SRS database to latest v8.4, and just committed the updated files into libgeotiff, GDAL and PROJ trunk. Also submitted

Re: [GRASS-dev] [GRASS-SVN] r60304 - grass/trunk/raster/r.colors

2014-05-18 Thread Helmut Kudrnovsky
Huidae Cho wrote I didn't do much backporting till now. I think it's time to read that wiki page. Thanks! On Sun, May 18, 2014 at 5:51 AM, Martin Landa lt; landa.martin@ gt;wrote: Hi, 2014-05-18 11:49 GMT+02:00 Martin Landa lt; landa.martin@ gt;: please consider backporting

[GRASS-dev] [gdal-dev] RFC 46 GDAL/OGR unification adopted and commited

2014-05-25 Thread Helmut Kudrnovsky
fyi from the GDAL-ML http://lists.osgeo.org/pipermail/gdal-dev/2014-May/039189.html Motion : I move to adopt RFC 46: GDAL/OGR unification http://trac.osgeo.org/gdal/wiki/rfc46_gdal_ogr_unification

[GRASS-dev] grass7 - python script - moving window: how to simplify/accelerate r.mapcalc?

2014-05-29 Thread Helmut Kudrnovsky
hi, in a python script within a mapcalc-expression I have moving window with 6 cells in all directions and a if(x,a,b) for each cell in r.mapcalc elevation_percentile_step2 = (100.0 / 48.0) * \ (if(eudem_osttirol[3,3] eudem_osttirol , 1, 0 ) + if(eudem_osttirol[2,2] eudem_osttirol , 1, 0 ) \ +

Re: [GRASS-dev] grass7 - python script - moving window: how to simplify/accelerate r.mapcalc?

2014-05-31 Thread Helmut Kudrnovsky
The most straightforward change is to eliminate the if() functions. Any boolean value (e.g. the result of a comparison) is an integer, with 1 for true, 0 for false. So if(ab,1,0)quot; is equivalent to just (ab)quot;. This should also provide a minor increase in efficiency. ah thanks. a quick

Re: [GRASS-dev] grass7 - python script - moving window: how to simplify/accelerate r.mapcalc?

2014-05-31 Thread Helmut Kudrnovsky
grass.mapcalc(%s % expr) or grass.mapcalc( expr ) [...] GRASS_INFO_ERROR(8628,3): Kann 'C:\grassdata/nc_spm_08_grass7/user1/cell_misc/\/ f_format' nicht finden. GRASS_INFO_END(8628,3) D2/3: G_file_name(): path = C:\grassdata/nc_spm_08_grass7/user1 GRASS_INFO_ERROR(5412,1): An error occurred

Re: [GRASS-dev] grass7 - python script - moving window: how to simplify/accelerate r.mapcalc?

2014-05-31 Thread Helmut Kudrnovsky
grass.mapcalc( expr ) None now the calculation works. for the record, there is now a wiki entry for this. http://grasswiki.osgeo.org/wiki/GRASS_Python_Scripting_Library#r.mapcalc_example:_defining_a_moving_window - best regards Helmut -- View this message in context:

Re: [GRASS-dev] grass7 - python script - moving window: how to simplify/accelerate r.mapcalc?

2014-06-01 Thread Helmut Kudrnovsky
Glynn Clements wrote Helmut Kudrnovsky wrote: to answer my own question, new lines are not recognized correctly in the expression, I should have read your follow-up before sending my reply. But, for future reference, can you test the other two options (using CR+LF, and using

[GRASS-dev] r.resamp.filter - Resamples raster map layers using an analytic kernel - how to use gauss filter?

2014-06-01 Thread Helmut Kudrnovsky
Hi, I'm trying to follow/understand the calculation/algorithm of a multiresolution index of valley bottom flatness [1] transcribed to GRASS GIS. The remaining steps are similar to the second step. The main differences are that the DEM is smoothed, the resolution becomes coarser at each step, and

Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script

2014-06-04 Thread Helmut Kudrnovsky
Martin Landa wrote 2014-06-03 9:10 GMT+02:00 Pietro lt; peter.zamb@ gt;: Remove Popen() magic on Windows; it creates more problems than it solves Please, could you explain which problems creates? I am waiting for reasonable/acceptable explanation for long time, I do not assume that it

Re: [GRASS-dev] 6.4.4 planning

2014-06-10 Thread Helmut Kudrnovsky
And back to the main topic, I'm bit lost in 6.4 releasing, is something blocking the release? as there are no blockers, the most simple thing is just tag and prepare RC1 let the nice work of coding into the wild. - best regards Helmut -- View this message in context:

[GRASS-dev] false resolution setting by g.region res= or g.region nsres= ewres=

2014-06-22 Thread Helmut Kudrnovsky
hi, given following region: g.region -p projection: 99 (Lambert Azimuthal Equal Area) zone: 0 datum: etrs89 ellipsoid: grs80 north: 2698025 south: 2609100 west: 4471150 east: 4556275 nsres:

Re: [GRASS-dev] Installing MS DLLs failed because of 404

2014-07-01 Thread Helmut Kudrnovsky
Do you have the any idea why download would fail? The computers have different system configuration some possible issues: - osgeo-server down? - winGRASS-standalone installing without admin rights? - no right to download from internet? - ... I've seen there is now:

Re: [GRASS-dev] Installing MS DLLs failed because of 404

2014-07-01 Thread Helmut Kudrnovsky
At least at one of the machines the error in GRASS installer log was something like HTTP 404 Not found. http://en.wikipedia.org/wiki/HTTP_404 The 404 or Not Found error message is a HTTP standard response code indicating that the client was able to communicate with a given server, but the

Re: [GRASS-dev] Installing MS DLLs failed because of 404

2014-07-01 Thread Helmut Kudrnovsky
The guide is there but I don't want to see the user struggling with unpacking tar.bz2 on MS Window. zip or 7z would be helpful. 7zip can unzip and untar tar.bz2. so if you have installed 7zip, you can do this. The package is 12 MB, so size is the issue? I would say manpower; there are 1-2

Re: [GRASS-dev] future of GRASS for Windows [was: Re: [GRASS-SVN] r60679 - grass/trunk/lib/python/script]

2014-07-02 Thread Helmut Kudrnovsky
Martin Landa wrote Hi, 2014-07-02 13:22 GMT+02:00 Moritz Lennert lt; mlennert@.worldonline gt;: [Starting a new thread as this is an important point on its own. Original mail is [1].] On 02/07/14 01:10, Glynn Clements wrote: But in the longer term, should we be claiming to support a

[GRASS-dev] r.mapcalc - expression line to long

2014-07-02 Thread Helmut Kudrnovsky
hi, given in a pynthon script: offsets3 = [d for j in xrange(1,6+1) for i in [j,-j] for d in [(i,0),(i,1),(i,2),(i,3),(i,4),(i,5),(i,6),(i,-1),(i,-2),(i,-3),(i,-4),(i,-5),(i,-6)]] terms3 =

Re: [GRASS-dev] r.mapcalc - expression line to long

2014-07-02 Thread Helmut Kudrnovsky
Helmut Kudrnovsky wrote hi, given in a pynthon script: offsets3 = [d for j in xrange(1,6+1) for i in [j,-j] for d in [(i,0),(i,1),(i,2),(i,3),(i,4),(i,5),(i,6),(i,-1),(i,-2),(i,-3),(i,-4),(i,-5),(i,-6

Re: [GRASS-dev] r.mapcalc - expression line to long

2014-07-03 Thread Helmut Kudrnovsky
Glynn Clements wrote Helmut Kudrnovsky wrote: by running the python script, a r.mapcalc-error pops up that the expression line is to long. Can you provide the exact message? There shouldn't be any practial limitation on the length of an expression in r60662 and later. [Previously

Re: [GRASS-dev] r.mapcalc - expression line to long

2014-07-03 Thread Helmut Kudrnovsky
Helmut Kudrnovsky wrote Glynn Clements wrote Helmut Kudrnovsky wrote: There shouldn't be any practial limitation on the length of an expression in r60662 and later. [Previously, there may have been OS-imposed limitations on the length of a command line, but r60662 changed

Re: [GRASS-dev] r.mapcalc - expression line to long

2014-07-03 Thread Helmut Kudrnovsky
There shouldn't be any practial limitation on the length of an expression in r60662 and later. there are similar steps in the script [1] http://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.valley.bottom/r.valley.bottom.py#L205 [2]

[GRASS-dev] [GRASS-SVN] r61135 - grass/trunk/lib/python/script - # TODO: what are cmd.exe's parsing rules?

2014-07-03 Thread Helmut Kudrnovsky
http://lists.osgeo.org/pipermail/grass-commit/2014-July/032050.html may be some hints: http://msdn.microsoft.com/en-us/library/a1y7w461.aspx http://blogs.msdn.com/b/twistylittlepassagesallalike/archive/2011/04/23/everyone-quotes-arguments-the-wrong-way.aspx http://ss64.com/nt/syntax-esc.html

[GRASS-dev] backport r60662 ? [was: Re: r.mapcalc - expression line to long]

2014-07-06 Thread Helmut Kudrnovsky
Glynn Clements wrote Helmut Kudrnovsky wrote: could it be that r60662 is only in trunk and not in 7.0.0svn? Yes. -- Glynn Clements ___ any opinion about backporting r60662 [1] to releasebranch_7_0? [1] http://lists.osgeo.org/pipermail

Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script

2014-07-06 Thread Helmut Kudrnovsky
Martin Landa wrote Hi, 2014-07-02 20:54 GMT+02:00 Martin Landa lt; landa.martin@ gt;: It's because it can't find v.in.gps. I suggest to add to the patch something like this: thanks, I included modified patch to the next build n1011. Martin seems to be set forward, committed as

Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script

2014-07-08 Thread Helmut Kudrnovsky
Anna Petrášová wrote On Sun, Jul 6, 2014 at 3:59 AM, Helmut Kudrnovsky lt; hellik@ gt; wrote: C:\OSGeo4W\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py, li ne 58, in __init__ raise OSError OSError It's because gui doesn't reflect recent changes by Martin. I

Re: [GRASS-dev] backport r60662 ? [was: Re: r.mapcalc - expression line to long]

2014-07-09 Thread Helmut Kudrnovsky
Glynn Clements wrote Helmut Kudrnovsky wrote: any opinion about backporting r60662 [1] to releasebranch_7_0? I recommend backporting. -- Glynn Clements lt; glynn@.plus gt; ___ grass-dev mailing list grass-dev@.osgeo http

Re: [GRASS-dev] GRASS GIS 6.4.4 r.li modules

2014-07-09 Thread Helmut Kudrnovsky
Martin Landa wrote 2014-07-04 12:48 GMT+02:00 Hamish lt; hamish.webmail@ gt;: yes, the old r.li.* daemon/worker system required unix sockets, and so would only work in the cygwin build. We never figured out how to properly support those natively on MS Windows. I believe in the new r.li

Re: [GRASS-dev] GRASS GIS 6.4.4 r.li modules

2014-07-09 Thread Helmut Kudrnovsky
Hamish wrote Hamish wrote: yes, the old r.li.* daemon/worker system required unix sockets, and so would only work in the cygwin build. We never figured out how to properly support those natively on MS Windows. Martin: r.li modules enabled in grass64 in r61153. Please test next build of

Re: [GRASS-dev] GRASS GIS 6.4.4 r.li modules

2014-07-09 Thread Helmut Kudrnovsky
Helmut Kudrnovsky wrote Martin Landa wrote 2014-07-04 12:48 GMT+02:00 Hamish lt; hamish.webmail@ gt;: yes, the old r.li.* daemon/worker system required unix sockets, and so would only work in the cygwin build. We never figured out how to properly support those natively on MS Windows. I

Re: [GRASS-dev] GRASS GIS 6.4.4 r.li modules

2014-07-09 Thread Helmut Kudrnovsky
Helmut Kudrnovsky wrote r.li.setup is missing here, but all other r.li.*-modules are there. sorry for the noise. it's now g.gui.rlisetup. - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/GRASS-GIS-6-4-4-r-li-modules-tp5148344p5150279.html Sent

Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script

2014-07-09 Thread Helmut Kudrnovsky
Anna Petrášová wrote the GUI starts now, thanks. g.gui.* modules are not found, there is no bat file created for them. Could something similar to this be used for them as well? Otherwise everything seems to be working. http://trac.osgeo.org/grass/changeset/61136 Anna g.gui.* which

Re: [GRASS-dev] GRASS 7.0beta3 planning

2014-07-18 Thread Helmut Kudrnovsky
what do you think about releasing beta3? have look in http://lists.osgeo.org/pipermail/grass-dev/2014-July/069983.html [GRASS-dev] GRASS 7: g.gui.rlisetup [...] Backport of r60219 is needed. http://trac.osgeo.org/grass/changeset/60219; g.gui.rlisetup isn't starting in winGRASS7.0 -

Re: [GRASS-dev] r.hazard.flood is not running in windows7( Grass 6.5)

2014-07-21 Thread Helmut Kudrnovsky
SWAPAN GHOSH wrote Dear all, I succesfully the module r.hazards.flood.py in windows xp but fail in windows 7. Please help me. Regards, Swapan Ghosh ___ grass-dev mailing list grass-dev@.osgeo

Re: [GRASS-dev] r.hazard.flood is not running in windows7( Grass 6.5)

2014-07-21 Thread Helmut Kudrnovsky
Actually, it needs external python installation. I solve it... but my question is that.why we need external py install.other wise get the following message first, please don't use winGRASS 6.5, it's some kind of abandoned and not meant for productive use. so try winGRASS

Re: [GRASS-dev] GRASS 7.0beta3 planning

2014-07-22 Thread Helmut Kudrnovsky
Markus Neteler wrote On Fri, Jul 18, 2014 at 8:39 AM, Helmut Kudrnovsky lt; hellik@ gt; wrote: what do you think about releasing beta3? have look in http://lists.osgeo.org/pipermail/grass-dev/2014-July/069983.html [GRASS-dev] GRASS 7: g.gui.rlisetup [...] Backport of r60219 is needed

Re: [GRASS-dev] GRASS 7.0beta3 planning

2014-07-22 Thread Helmut Kudrnovsky
Anna Petrášová wrote g.gui.rlisetup is working now; but an g.gui.rlisetup-entry in the main GUI is missing. Isn't it the 'Set up sampling and analysis framework? ' in Raster - Landscape patch analysis? Anna ah, yes, you're right, sorry for the noise. - best regards Helmut --

Re: [GRASS-dev] GRASS 7.0beta3 planning

2014-07-30 Thread Helmut Kudrnovsky
Markus Neteler wrote On Fri, Jul 18, 2014 at 12:22 AM, Vaclav Petras lt; wenzeslaus@ gt; wrote: Hi, what do you think about releasing beta3? Yes, we should really prepare for that now. I made a lot of backports in the past few days. [...] Overview:

[GRASS-dev] Landsat Metadata (MTL) File Changes Coming September 2014

2014-08-05 Thread Helmut Kudrnovsky
fyi http://landsat.usgs.gov/about_LU_Vol_8_Issue_3.php#1a In September, the following changes will be made to the Metadata (MTL) file distributed with the Landsat Level 1 data products: Remove Padding (Extra Lines) This change

Re: [GRASS-dev] GRASS GIS 6.4.4 r.li modules

2014-08-13 Thread Helmut Kudrnovsky
Martin Landa wrote Hi, 2014-07-09 13:25 GMT+02:00 Helmut Kudrnovsky lt; hellik@ gt;: it seems only r.li.setup is enabled in winGRASS6.4.5svn. recently I fixed all remaining issues, the most recent build of 6.4.5svn contains all r.li modules. Any testing welcomed... Martin

Re: [GRASS-dev] GRASS GIS 6.4.4 r.li modules

2014-08-13 Thread Helmut Kudrnovsky
Martin Landa wrote Hi, 2014-08-13 10:10 GMT+02:00 Helmut Kudrnovsky lt; hellik@ gt;: r.li.setup seems to be empty, see attached screenshot. lt;http://osgeo-org.1560.x6.nabble.com/file/n5156085/WinGrass645svncapture_13082014_100649.pnggt; I am getting the same dialog on Linux when

  1   2   3   4   5   6   7   8   9   >