Re: [GRASS-dev] [GRASS GIS] #778: i.rgb.his, i.his.rgb: propagate NULLs
#778: i.rgb.his, i.his.rgb: propagate NULLs --+- Reporter: hamish| Owner: grass-dev@… Type: defect| Status: new Priority: major | Milestone: 7.0.0 Component: Raster| Version: svn-trunk Keywords: i.rgb.his, i.his.rgb |Platform: All Cpu: Unspecified | --+- Comment(by mlennert): Replying to [comment:13 cmbarton]: For pan sharpening at least, it would be helpful if these modules could deal with floating point values instead of just integers. I think this is a different issue and shouldn't be part of this ticket. It was already mentioned in #774. -- Ticket URL: https://trac.osgeo.org/grass/ticket/778#comment:14 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] #1778: Typing in g.region without parameters does not open a g.region window
#1778: Typing in g.region without parameters does not open a g.region window
+---
Reporter: pvanbosgeo | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Default | Version: svn-trunk
Keywords: g.region, r.colors, r.mask |Platform: Linux
Cpu: x86-64 |
+---
Comment(by martinl):
Replying to [comment:20 cmbarton]:
A flag (-ui) can be added to any module to ensure it launches a GUI, but
is only necessary for a few modules. AFAICT, this behavior is not
documented anywhere (run g.region help or look in the manual for GRASS). I
tend to think that 'secret' behavior of any interface element is not a
good idea from the user perspective--even if the secret is inadvertent and
logical from other perspectives.
the attached patch attachment:force_gui.diff adds '--ui' to the help
printed by the parser (see example below). I agree that this switch is not
documented well, even it's not noted in the `g.parser`'s help page.
{{{
Description:
Displays user-specified raster map in the active graphics frame.
Keywords:
display, graphics, raster
Usage:
d.rast [-ni] map=name [values=value[-value][,value[-value],...]]
[bgcolor=color] [--verbose] [--quiet] [--ui]
Flags:
-n Make null cells opaque
-i Invert value list
--v Verbose module output
--q Quiet module output
--ui Force GUI dialog to come up
Parameters:
map Name of raster map to be displayed
values List of categories or values to be displayed
bgcolor Background color (for null)
Either a standard color name or R:G:B triplet
default: white
}}}
--
Ticket URL: https://trac.osgeo.org/grass/ticket/1778#comment:21
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] #1463: Legend, Zoom to map, Map analysis and Map query does not work in Python wxgui using command line d.mon + d.rast
#1463: Legend, Zoom to map, Map analysis and Map query does not work in Python
wxgui using command line d.mon + d.rast
--+-
Reporter: huhabla | Owner: grass-dev@…
Type: defect | Status: closed
Priority: major| Milestone: 7.0.0
Component: wxGUI| Version: svn-trunk
Resolution: fixed|Keywords: d.mon
Platform: Unspecified | Cpu: Unspecified
--+-
Changes (by wenzeslaus):
* status: new = closed
* resolution: = fixed
Comment:
There were also refactoring which fixed a lot of issues like these. I
cannot list particular changesets; there was a lot of them (in 2012 and
2013).
For GUI developers: The fix usually was replacing call of
`self.tree.DoSomething` by `self.giface.DoSomethingSimilar` or by emitting
`Signal` or wxevent. But the actual fixes may differ.
For testers: There is a `test_mapdisp.py` script in `gui/wxpython/mapdisp`
which tests whether a map display and a map window works without any layer
manager and layer tree objects. It should be accessible using:
{{{
cd gui/wxpython/mapdisp
python test_mapdisp.py
}}}
But currently I'm not able to run it this way since gparser (which is
used) requires a module to by on-path (but it was working when I created
this script a month ago).
Still there may be some non-working things in `d.mon` but I remember that
I've fixed several of the issues above (they probably re-appeared after
r48828). Since it works for [comment:5 mlennert], I'm closing the ticket.
If there is some other issue, I suggest to open a new ticket for it.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/1463#comment:6
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] #469: raster data needs binary mode on windows
#469: raster data needs binary mode on windows -+-- Reporter: jef | Owner: grass-dev@… Type: defect | Status: new Priority: major| Milestone: 7.0.0 Component: Default | Version: svn-trunk Keywords: wingrass |Platform: MSWindows XP Cpu: Unspecified | -+-- Comment(by glynn): Replying to [comment:19 neteler]: Still relevant for GRASS 7? GRASS 7 sets _fmode = O_BINARY in lib/gis/gisinit.c, so fmode.o probably isn't necessary. -- Ticket URL: https://trac.osgeo.org/grass/ticket/469#comment:22 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] #459: lib/cairodriver uses FontConfig but doesn't link against it
#459: lib/cairodriver uses FontConfig but doesn't link against it -+-- Reporter: glynn| Owner: glynn Type: defect | Status: new Priority: major| Milestone: 7.0.0 Component: Display | Version: svn-trunk Keywords: |Platform: Unspecified Cpu: All | -+-- Comment(by glynn): Replying to [comment:2 mlennert]: Is this still an issue ? It may have been solved by r55040 (related to #1884). -- Ticket URL: https://trac.osgeo.org/grass/ticket/459#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] [GRASS GIS] #2034: GUI crashes on launch for newly compiled binary for Mac OS X
#2034: GUI crashes on launch for newly compiled binary for Mac OS X ---+ Reporter: cmbarton | Owner: grass-dev@… Type: defect | Status: new Priority: critical | Milestone: 7.0.0 Component: wxGUI | Version: svn-trunk Keywords: |Platform: MacOSX Cpu: OSX/Intel | ---+ Comment(by annakrat): I don't think any recent changes are related. A few days ago I compiled GRASS 7 on Mac 10.8 with wxPython 2.8 and I had problems only with the 32/64 architecture (which I expected and solved by setting VERSIONER_PYTHON_PREFER_32_BIT=yes) and other problems (r57536, r57537). None of these problems is related to the issue described here. So it could be related to the 'special hacks' you do to make the binary work with Mac 10.6, or there is some mess in your python/wxPython installation (I had similar problems myself when I upgraded to newer Ubuntu version) and another possible reason is some hidden problem in GRASS. Probably it's a combination of these problems. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2034#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] issue with vector import wrapper for v.in.ogr for GRASS 7
Hi, On Mon, Sep 2, 2013 at 3:20 PM, Michael Barton michael.bar...@asu.eduwrote: I received a report that the wrapper for v.in.ogr is throwing an error when importing files of multiple types (kml and shp tested). The error in the terminal is: pythonw2.6(5979,0xad1e72c0) malloc: *** error for object 0x6d353ed5: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug v.in.ogr works fine for the same files. So it is the wrapper. This is happening in GRASS 7 r57457, compiled 16 August. That's a couple weeks back, so it may be fixed. If not, I can do a ticket. this is a strange error, does this happen on certain platforms only? And when exactly does this error appear, when you press Import? Anna Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu ___ 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] [GRASS GIS] #1662: Caching bug in 3D raster library with large data
#1662: Caching bug in 3D raster library with large data -+-- Reporter: huhabla | Owner: grass-dev@… Type: defect | Status: new Priority: critical | Milestone: 7.0.0 Component: Raster3D | Version: svn-trunk Keywords: 3D raster, tiles, cache |Platform: Linux Cpu: x86-32 | -+-- Comment(by glynn): Replying to [comment:8 hamish]: I see many times long* is used as a variable type in lib/raster3D/, e.g.: (* and some unsigned long too) Historically, most of my bulk fixes for things like LFS skipped over the raster3D library (because the number of cases in raster3D often exceeded those in the rest of the GRASS code base combined). so to make it LFS compatible on 32bit those having to do with file offsets and cell counts should be changed to e.g. off_t or use a G_*() wrapper instead? (none for lseek(), but we do have G_ftell() and G_fseek()) File offsets should use off_t. Cell counts ... are a problem. long long and int64_t aren't in C89, long is only 32 bits on 64-bit Windows, size_t is unsigned. Windows itself doesn't have off_t (or fseeko/ftello). The POSIX functions in MSVCRT use either int (e.g. read, write) or long (e.g. lseek). Some of them have 64-bit variants using !__int64 (e.g. _lseeki64, although the name has changed between MSVCRT versions). -- Ticket URL: https://trac.osgeo.org/grass/ticket/1662#comment:10 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] #1778: Typing in g.region without parameters does not open a g.region window
#1778: Typing in g.region without parameters does not open a g.region window
+---
Reporter: pvanbosgeo | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Default | Version: svn-trunk
Keywords: g.region, r.colors, r.mask |Platform: Linux
Cpu: x86-64 |
+---
Comment(by glynn):
Replying to [comment:20 cmbarton]:
It is not critical but I'm not sure I'd call it an enhancement. Not
really a bug either, though it will appear to be one to many users. The
important conceptual issue is, should the default behavior of GRASS
modules when called without arguments be
1. to launch a GUI dialog?
2. to do something?
Arguments or not, the '''default''' behaviour behaviour should be to do
something. We're discussing the behaviour in the event of an error, i.e.
if the supplied arguments are insufficient for the module to actually do
something.
In that situation, my preference would be an error message, preferably a
more useful one than
{{{
Unable to access the X Display, is $DISPLAY set properly?
}}}
If I wanted GUI dialogs, I'd use the GUI.
My vote for #1 comes from thinking about usability for people who are
novice or infrequent users of the command line
Optimising the command-line interface for people who don't use it at the
expense of those who do doesn't seem particularly sensible. Also,
optimising for novice users results in something which is useful for the
first few weeks then a nuisance for the next decade, which again seems
like a poor trade-off.
I think the argument for #2 is primarily one of easier, more rapid use
of modules from the command line by experienced and frequent users. There
may be other arguments that have not been articulated yet.
There's also the fact that it can result in command-line modules blocking
forever in the case that the connection to the X server succeeds but
there's no user to interact with it. I.e. the same problem as with the
previous terminal-based prompting, except that closing stdin won't save
you (unsetting DISPLAY will, at least on Unix, provided that you've
already anticipated that failure mode).
To that end, I'd rather GUI dialogs were never displayed, so that e.g. a
shell script which does r.module $args (when $args is empty for whatever
reason) sees an error rather than a module which just runs forever. That
would also be consistent with almost every other command-line utility from
every package which isn't GRASS.
The problem is that it's rather hard for a module to determine whether
interactivity is a plus or a minus. An environment variable wouldn't
necessarily help; if it's set for an interactive shell, any scripts run
from the shell would inherit it. They'll also inherit the fact that stdin
is a tty and $DISPLAY is set.
--
Ticket URL: https://trac.osgeo.org/grass/ticket/1778#comment:22
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 parallelization
Thanks Soren. Do you know if there is much interest in greater parallelization? And have the Intel compilers and MPI been used with GRASS? Don -Original Message- From: Sören Gebbert [mailto:soerengebb...@googlemail.com] Sent: Friday, August 30, 2013 11:56 AM To: Gunning, Don Cc: grass-dev@lists.osgeo.org Subject: Re: [GRASS-dev] Grass parallelization Hi Don, you may have a look at: http://grasswiki.osgeo.org/wiki/Parallel_GRASS_jobs http://grasswiki.osgeo.org/wiki/OpenMP What i know personally: We have shared memory parallelization implemented in the grass mathematical library (gmath) and partial differential equation library (gpde) using OpenMP. Blas level 2 and 3 functions as well as many direct and iterative linear equation solver are parallelized as well as the creation of linear equation systems. Several modules make use of these libraries. Pthreads are used to parallelize parts of r.mapcalc. IIRC there are MPI parallelized versions of several GRASS modules available in the internet, but not directly in GRASS. :) We have parallelization on process level without message passing, by simply running several processes on different data in parallel. Several modules of the GRASS GIS Temporal Framework in GRASS7 make use of this approach and of course the grid engine - cluster parallelization. Cloud level parallelization using web service WPS is available because GRASS7 can be run as WPS backend. Best regards Soeren 2013/8/30 Gunning, Don don.gunn...@intel.com: Can someone discuss the state of shared and distributed memory parallelization of GRASS? Don Gunning Software Program Manager Technical computing group Developer Product Division Intel Corporation 1906 Fox Dr Champaign Il 61820 217 403 4213 ___ 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] d.text -c
Martin wrote: `d.text` contains apparently unused flag -c Ignored (compatibility with d.text.freetype) Because `d.text.freetype` has been removed from GRASS 7, it seems to me that this flag can be removed without any harm. sure More strangely `d.text.freetype` in GRASS 6.4/6.5 says the same as `d.text`, ie. -c Ignored (compatibility with d.text.freetype) What you're seeing there is actually the options of d.text.new, not d.text.freetype. In 6.x the old d.text and d.text.freetype modules were both replaced by d.text.new. d.text.new is built with the d.text name, and d.text.freetype is a wrapper script calling d.text. I only see the -c flag in the d.text.freetype/ code currently, which was to put it into command mode (compatibility with a d.text(.old) feature which no longer exists). Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2017: osgf compilation error
#2017: osgf compilation error
---+
Reporter: martinl| Owner: grass-dev@…
Type: defect | Status: new
Priority: blocker| Milestone: 7.0.0
Component: Compiling | Version: svn-trunk
Keywords: libc |Platform: Linux
Cpu: x86-64 |
---+
Comment(by martinl):
OK, the reason is that `/usr/include/libavutil` already contains `time.h`
header file (1). I am using
{{{
--with-ffmpeg-includes=/usr/include/libavcodec /usr/include/libavformat/
/usr/include/libswscale /usr/include/libavutil
}}}
without `/usr/include/libavutil` I get
{{{
gsd_img_mpeg.c:33:25: fatal error: mathematics.h: No such file or
directory
#include mathematics.h
}}}
(1) http://stackoverflow.com/questions/14947691/c-system-file-bits-stat-h
-suddenly-breaks-with-error-field-st-atim-has-inc
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2017#comment:8
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] #2017: osgf compilation error
#2017: osgf compilation error
---+
Reporter: martinl| Owner: grass-dev@…
Type: defect | Status: new
Priority: blocker| Milestone: 7.0.0
Component: Compiling | Version: svn-trunk
Keywords: libc, osgf, libavutil |Platform: Linux
Cpu: x86-64 |
---+
Changes (by hamish):
* keywords: libc = libc, osgf, libavutil
Comment:
martinl wrote:
gsd_img_mpeg.c:33:25: fatal error: mathematics.h: No such file or
directory
lib/ogsf/gsd_img_mpeg.c
{{{
/* FFMPEG stuff */
#ifdef HAVE_FFMPEG
#include avformat.h
#include avio.h
#if LIBAVUTIL_VERSION_MAJOR 51
#include avutil.h
#else
/* libavutil 51.22.1's avutil.h doesn't include libavutil/mathematics.h */
#include mathematics.h
#endif
}}}
Package: libavutil-dev
Source: libav
Version: 6:0.8.7-1
what version of libavutil does that provide?
(look in /usr/include/libavutil/avutil.h for
LIBAVUTIL_VERSION_MAJOR,MINOR,MICRO)
supposedly newer versions of Debian have switched to more stable versions
of these libraries which could put an end to this game of cat and mouse,
but I'm tempted to drop the in-program MPEG creation in favour of creating
a series of frames and outsourcing the encoding entirely to 3rd party
software.
anyway IIRC that code isn't used by anything in trunk right now, so no
benefit of using --with-ffmpeg when building GRASS 7 (currently).
Hamish
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2017#comment:10
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] #2017: osgf compilation error
#2017: osgf compilation error
---+
Reporter: martinl| Owner: grass-dev@…
Type: defect | Status: new
Priority: blocker| Milestone: 7.0.0
Component: Compiling | Version: svn-trunk
Keywords: libc |Platform: Linux
Cpu: x86-64 |
---+
Comment(by martinl):
Replying to [comment:8 martinl]:
OK, the reason is that `/usr/include/libavutil` already contains
`time.h` header file (1). I am using
{{{
apt-file search /usr/include/libavutil/time.h
libavutil-dev: /usr/include/libavutil/time.h
...
Package: libavutil-dev
Source: libav
Version: 6:0.8.7-1
}}}
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2017#comment:9
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] #2017: osgf compilation error
#2017: osgf compilation error
---+
Reporter: martinl| Owner: grass-dev@…
Type: defect | Status: new
Priority: blocker| Milestone: 7.0.0
Component: Compiling | Version: svn-trunk
Keywords: libc, osgf, libavutil |Platform: Linux
Cpu: x86-64 |
---+
Comment(by martinl):
Replying to [comment:10 hamish]:
what version of libavutil does that provide?
(look in /usr/include/libavutil/avutil.h for
LIBAVUTIL_VERSION_MAJOR,MINOR,MICRO)
{{{
version.h:#define LIBAVUTIL_VERSION_MAJOR 52
version.h:#define LIBAVUTIL_VERSION_MINOR 18
version.h:#define LIBAVUTIL_VERSION_MICRO 100
}}}
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2017#comment:11
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
