Re: [GRASS-dev] [GRASS GIS] #1825: r.tileset only returns one tile
#1825: r.tileset only returns one tile -+-- Reporter: pvanbosgeo | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: Raster | Version: svn-trunk Keywords: r.tileset|Platform: Unspecified Cpu: Unspecified | -+-- Comment(by neteler): Proposed patch submitted in r58782. Please test (and close ticket if issue is now fixed). -- Ticket URL: http://trac.osgeo.org/grass/ticket/1825#comment:4 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2152: cd command does not work in GUI Command console
#2152: cd command does not work in GUI Command console -+-- Reporter: wenzeslaus | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 6.4.4 Component: wxGUI| Version: 6.4.3 Keywords: cd, command console |Platform: All Cpu: Unspecified | -+-- Comment(by neteler): Replying to [comment:2 wenzeslaus]: Replying to [comment:1 neteler]: ... I actually like the patch for the parser, I wanted propose `--h` and inclusion of `--help` in the manual page myself. Yes, the patch adds this, too (run make distclean to see it). I just don't like the wording of the `--help` description, Submitted with improved wording in r58783 (GRASS 7 only so far). -- Ticket URL: http://trac.osgeo.org/grass/ticket/2152#comment:3 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Handling of Python scripts on MS Windows
On 25/01/14 16:48, Markus Metz wrote:
On Sat, Jan 25, 2014 at 3:59 PM, Helena Mitasova hmit...@ncsu.edu wrote:
Just a note, given that most of these problems were caused by conflicts with
python installed by ArcGIS,
I checked with our GIS support and the latest ArcGIS 10.2 installs python2.7
which (I guess) should work with GRASS.
No, there are different versions of Python 2.7, and not all work with
GRASS, see e.g. ticket 2015
On Jan 24, 2014, at 3:03 PM, Glynn Clements wrote:
Markus Metz wrote:
Where it gets problematic is if the user already has a Python
installation but it's not suitable for whatever reason. In the worst
case they may be faced with a choice between using GRASS or using
whatever the existing Python was installed for.
There is a tool called Virtualenv that seems to address exactly
this problem: https://pypi.python.org/pypi/virtualenv
See also here: http://docs.python-guide.org/en/latest/starting/install/win/
I found it via this thread:
http://stackoverflow.com/questions/1108974/switch-versions-of-python
IMHO keeping in mind that many GIS-interested winGRASS-users may already
have been installed other (GIS-)software including a system-wide python
installation, that will be the demanding challenge to provide a suitable
solution ...
I don't know in how far a pre-existing system installation of
Python would interfere with Virtualenv or similar solutions.
But I hope that the above could be a useful approach to
solving this problem.
Best,
Ben
How many users will have versions which are:
a) too old for GRASS to use, and
b) required to be that old by the existing package?
Bear in mind that GRASS won't be the only package affected by an
outdated system-wide Python installation.
GRASS should not use a system-wide Python installation, or more
precisely, should explicitly ignore any system-wide python file
associations. Expecting system-wide python file associations is the
cause of all the trouble.
The embedded but not installed Python version coming GRASS works fine
and should IMHO be used for scripts via
@%GRASS_PYTHON% %GISBASE%/scripts/SCRIPT_NAME %*
AFAIK, the primary case where another package requires a system-wide
Python installation is ArcGIS, no? IIRC, ArcGIS requires Python 2.6;
is there some fundamental reason why this isn't suitable for GRASS? If
so, does ArcGIS require that exact version, or can it use a later
version?
We can not care for all cases of other software (versions) relying on
a system-wide python installation.
yes, given that most of these problems were caused by conflicts with python
installed by ArcGIS,
I checked with our GIS support and the latest ArcGIS 10.2 installs python2.7
which should work with GRASS
(correct me if I am wrong).
We had similar situation with ArcGIS9* and GRASS6.3 where you had to use a
specific winpython2.5 build 212
to have both of them working on the same machine.
The test suggested by Markus in the related message would be still useful,
but upgrading to ArcGIS10.2 should solve the problem?
You can hardly suggest users to upgrade ArcGIS if they want to use GRASS...
Therefore I would suggest to keep using the embedded Python version
which is known to work
Actually, it known not to work, hence this thread.
It works as long as system-wide python file associations are ignored.
Other Python versions might not work.
The only way you can make execution of Python scripts seamless (i.e.
works with system(), subprocess.Popen(), etc) is for the .py extension
to be associated with a suitable interpreter (or launcher) in the
registry.
I disagree. For example, shell scripts work just fine in GRASS 6.4,
even though there is no associated suitable interpreter (or launcher)
in the registry.
Any other approach will trap us into an endless maintenance burden,
identifying cases where we have to provide special handling for Python
scripts then implementing that handling.
We did so for shell scripts, AFAIK this works.
Markus M
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Handling of Python scripts on MS Windows
Markus Metz wrote: On Sat, Jan 25, 2014 at 3:59 PM, Helena Mitasova hmit...@ncsu.edu wrote: Just a note, given that most of these problems were caused by conflicts with python installed by ArcGIS, I checked with our GIS support and the latest ArcGIS 10.2 installs python2.7 which (I guess) should work with GRASS. No, there are different versions of Python 2.7, and not all work with GRASS, see e.g. ticket 2015 Any version of Python 2.7 should be suitable for GRASS. However, it needs to be installed correctly, and GRASS needs to not attempt to bundle Python. GRASS should not use a system-wide Python installation, or more precisely, should explicitly ignore any system-wide python file associations. Expecting system-wide python file associations is the cause of all the trouble. Executing a script uses the registry associations for the script's extension. Attempting to by-pass the system's script execution mechanism (by explicitly executing Python scripts via a specific interpreter) is the cause of all the trouble. -- 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] [GRASS GIS] #2173: Tcl NVIZ: load state file Error: must be surf_id set_mask_mode BOOLEAN
#2173: Tcl NVIZ: load state file Error: must be surf_id set_mask_mode BOOLEAN
+---
Reporter: hamish | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 6.4.4
Component: Tcl/Tk NVIZ | Version: svn-develbranch6
Keywords: load state, raster |Platform: Linux
Cpu: x86-64 |
+---
Hi,
there is a bug in writing the saved-state file in tcl/tk NVIZ. It means
that re-loading a state file with raster layers leads to an inconsistent
internal state.
The reason is the mask-map inversion status being written as 00 not 0.
Fixing the file by hand solves the issue and lets you load the state file
correctly.
spearfish example:
{{{
GRASS g.region -d
GRASS nviz elev=elevation.dem
File -- Save State
Save as test.nviz
GRASS head -n 27 test.nviz | tail -n 17
surf*1390794941
map elevation.dem
0
map elevation.dem
0
unset
00
unset
const 60.00
unset
#88
0.00 0.00 0.00
3 3
2 2
poly
grid_surf
gouraud
GRASS nviz state=test.nviz
Loading raster map elevation.dem@PERMANENT...
100%
Loading raster map elevation.dem@PERMANENT...
100%
Translating colors from raster map elevation.dem@PERMANENT...
100%
Diagnostic: Error: must be surf_id set_mask_mode BOOLEAN --
Load procedure for panel start surf may not be defined
}}}
And the internal state becomes a bit messed up: The surface renders but
the Raster Surfaces controls show none loaded.
In map_obj.c set_mask_mode() fails because it is saved in the file as 00
not 0 (7th line of the 'surf' entry).
The code that creates it is get_mask_mode() in
visualization/nviz/src/map_obs.c, but that is using `sprintf(tmp, %d,
mode);` to create the string so I'm not seeing where/how the 00 is being
introduced, since %d should lead to just 0.
?
The work-around is to edit the .nviz state file by hand and change the
00 to 0. Then the Load State works as expected.
Interestingly the first time I launch tcl nviz in 6.4.3 on a different
machine it wrote out 0 but later attempts following the exact same
series of clicks writes out 00.. smashed stack?
see also scripts/panel_surf.tcl for the reading and writing of the
session-state file (Nviz_surf_save() is well commented).
Another question is if after fixing the source of the 00 trouble if we
allow sloppy-read, i.e. to auto-translate 00 to 0 upon load so the user
can load old+broken .nviz state files created by this bug. Or as a general
policy if keeping work-arounds in the code base for old bugs generates too
much code-clutter? In this case I would suggest to err on the side of
being kind to the victims.
thanks,
Hamish
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2173
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2173: Tcl NVIZ: load state file Error: must be surf_id set_mask_mode BOOLEAN
#2173: Tcl NVIZ: load state file Error: must be surf_id set_mask_mode BOOLEAN +--- Reporter: hamish | Owner: grass-dev@… Type: defect | Status: new Priority: major | Milestone: 6.5.0 Component: Tcl/Tk NVIZ | Version: svn-develbranch6 Keywords: load state, raster |Platform: Linux Cpu: x86-64 | +--- Changes (by hamish): * milestone: 6.4.4 = 6.5.0 Comment: Replying to [ticket:2173 hamish]: Interestingly the first time I launch tcl nviz in 6.4.3 on a different machine it wrote out 0 but later attempts following the exact same series of clicks writes out 00.. smashed stack? sorry, my mistake. That happened when switching between 6.4.3 and 6.5, so the bug is in 6.5 only. Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/2173#comment:1 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] change linear back to bilinear in grass7 ?
As we are going through the class material I have noticed that in GRASS7 in r.resample.interp method bilinear was changed to linear and bicubic was changed to cubic. I would like to ask whether it would be OK to change it back for two reasons: - consistency with 6.4 (minimizes changes required in tutorials, scripts, assignments etc.) - bilinear interpolation is not linear, (see the relevant text in wikipedia you need to scroll down to find the relevant section) Also, the change to linear and cubic has created additional inconsistencies in manual pages of r.resamp.bspline v.sample v.drape which have bicubic or bilinear in the examples and the text, but cubic and linear in the command SYNOPSIS parameters. Helena Helena Mitasova Associate Professor Department of Marine, Earth, and Atmospheric Sciences 2800 Faucette Drive, Rm. 1125 Jordan Hall North Carolina State University Raleigh, NC 27695-8208 hmit...@ncsu.edu All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.” ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #2174: Tcl NVIZ: load state loads then forgets the look here focus position
#2174: Tcl NVIZ: load state loads then forgets the look here focus position ---+ Reporter: hamish | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 6.4.4 Component: Tcl/Tk NVIZ| Version: svn-develbranch6 Keywords: load state, focus |Platform: Linux Cpu: x86-64 | ---+ Hi, In Tcl/Tk NVIZ if you change the map's location on the canvas with the Look Here button or change from the puck to the center view-adjust method, then 'File - Save State', the resulting position is successfully saved to the session-state file by Nget_focus(), and is loaded back in ok as part of panel_main.tcl's Nviz_main_load()'s Nset_focus(). But then the focus position gets clobbered (twice) by panel_surf.tcl and panel_vol.c calling look_center, which resets the view. On a less important note those extra two look_center mean that the screen gets redrawn a couple extra times too; minor performance hit. Commenting out the two look_center() at the ends of the Nviz_surf_load() and Nviz_vol_load() tcl functions lets it reload the correct original view upon File - Load State. I hesitate to commit any change without some sort of check that the focus has already been loaded/set, maybe those two look_center() are there for the first layer to be loaded when starting from a blank canvas? Note that AFAIK the canvas center focus is based on g.region not the bounds of the newly loaded surface/volume, so the view should not have to be recentered because a change of layer. thanks, Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/2174 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] change linear back to bilinear in grass7 ?
Dear Helena, 2014-01-27 Helena Mitasova hmit...@ncsu.edu: As we are going through the class material I have noticed that in GRASS7 in r.resample.interp method bilinear was changed to linear and bicubic was changed to cubic. for the record, there was a discussion about that a while ago [1]. So probably we will to open this discussion again. Martin [1] http://lists.osgeo.org/pipermail/grass-dev/2013-May/063855.html ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
