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
- 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
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
hi,
system here:
System Info
GRASS version: 7.0.svn
GRASS SVN Revision: 57202
Build Date: 2013-07-18
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
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:
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
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 -
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
[...]
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
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
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
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
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
*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:
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
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?
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
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
Š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_
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
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
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
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
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
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
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:
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
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,
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:
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
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
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
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
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
(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
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
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'
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
[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
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
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
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
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
[...]
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
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?
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
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
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:
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
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
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.)
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
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,
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
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
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
[...]
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.
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
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,
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
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
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
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 ) \
+
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
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:
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
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
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:
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:
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:
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
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
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
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 =
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
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
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
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]
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
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
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
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
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
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
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
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
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
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
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
-
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
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
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
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
--
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:
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
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
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
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
Martin Landa wrote
Hi,
please fill ticket on Trac about that. Thanks, Martin
done by #2392 #2393
-
best regards
Helmut
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/GRASS-GIS-6-4-4-r-li-modules-tp5148344p5156110.html
Sent from the Grass - Dev mailing list
1 - 100 of 1003 matches
Mail list logo
