Re: [GRASS-dev] error v.what.rast
On Tue, Oct 7, 2014 at 11:20 PM, Paulo van Breugel p.vanbreu...@gmail.com wrote: I am trying to upload raster values of the raster 'grid' to the attribute table of the gbif vector layer, as below: g.region rast=grid can you please post g.region rast=grid -p v.what.rast map=gbif raster=grid column=cell2arcm Reading features from vector map... 100% ERROR: Reading raster map grid@ request for row 1830 is outside region ... and also the boundary box of gbif? Any idea what the error message is about. I have done this done before without problems (same location/mapset and script), and I am really not sure what I am doing different now. The computational region comes to mind. If that holds true, we might improve that error message. Markus Running GRASS 7.1 on Ubuntu ___ 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] error v.what.rast
On Wed, Oct 8, 2014 at 9:21 AM, Markus Neteler nete...@osgeo.org wrote: On Tue, Oct 7, 2014 at 11:20 PM, Paulo van Breugel p.vanbreu...@gmail.com wrote: I am trying to upload raster values of the raster 'grid' to the attribute table of the gbif vector layer, as below: g.region rast=grid can you please post g.region rast=grid -p GRASS 7.1.svn (latlon):~ g.region rast=grid -p projection: 3 (Latitude-Longitude) zone: 0 datum: wgs84 ellipsoid: a=6378137 es=0.006694379990141316 north: 37:22:30N south: 39S west: 20:12:30W east: 57:40E nsres: 0:02:30 ewres: 0:02:30 rows: 1833 cols: 1869 cells: 3425877 v.what.rast map=gbif raster=grid column=cell2arcm Reading features from vector map... 100% ERROR: Reading raster map grid@ request for row 1830 is outside region ... and also the boundary box of gbif? Projection: Latitude-Longitude N: 37:19:58.08N S: 38:52:30S E: 57:38:24E W: 20:02:49.92W Any idea what the error message is about. I have done this done before without problems (same location/mapset and script), and I am really not sure what I am doing different now. The computational region comes to mind. If that holds true, we might improve that error message. Markus I should add that it runs well on some resolutions (e.g., using 10 or 5 arc-minute resolution, not on others (like the 2.5 arc-minute above) Running GRASS 7.1 on Ubuntu ___ 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] casting row buffer in memory
Pietro wrote:
So even if I'm explicitly casting the result in the scaler function
with dtype(...), the result is not properly casted, do you have an
idea on how could I solve this problem?
This is a bug in pygrass:
$ r.info -g foo | fgrep datatype
datatype=CELL
$ python
Python 2.7.7 (default, Sep 26 2014, 00:18:15)
[GCC 4.6.3] on linux2
Type help, copyright, credits or license for more information.
from grass.pygrass.raster import RasterRow
out = RasterRow('foo', mode='w', mtype='DCELL', overwrite=True)
out.mtype
u'CELL'
If a map with the chosen name already exists, its type is used in
place of the one specified.
Looking at the code for grass.pygrass.raster.RasterRow.open(), the
overall structure is rather flawed. It primarily considers whether the
map already exists, then secondarily considers the mode (r/w).
It should be the other way around.
Whether you're reading an existing map or creating a new map is
fundamental. Whether the map exists is secondary; whether it ought
to exist and what to do if it does/doesn't is entirely different
depending upon whether you're reading or writing.
--
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2326: Command functions in grass.script.core miss a correct error reporting
#2326: Command functions in grass.script.core miss a correct error reporting +--- Reporter: wenzeslaus | Owner: grass-dev@… Type: enhancement | Status: new Priority: major | Milestone: 7.1.0 Component: Python | Version: svn-trunk Keywords: script, exceptions |Platform: All Cpu: Unspecified | +--- Comment(by glynn): Replying to [comment:20 wenzeslaus]: This is a serious change which will require a lot of testing in both modules (core and addons) and GUI. What are the opinions on doing something like that? The existing behaviour is wrong and should be fixed before 7.0 is released. The alternative is to go for 7.x and probably even further (8.x) with the current unsafe but broadly used API The Python scripting API is new in 7.0, which hasn't been released yet. The fundamental feature of 7.0 was that we get to break compatibility for the sake of correctness, so it makes no sense break correctness for the sake of compatibility with something which hasn't even been released. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2326#comment:24 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] r.mapcalc bug on max and min?
Pietro wrote: Perhaps we could add two new functions, like: rmin and rmax that stay for range min and range max that give this information It's not possible to implement these as functions within the current structure of r.mapcalc. r.mapcalc's functions take row buffers as inputs, and return (i.e. populate) a row buffer as output. There's no way to write a function which takes a map name as input (r.mapcalc doesn't have any data types except numbers). A map name automatically evaluates to the map's contents. IOW, for a function call such as sqrt(input), the function is called for each row, with the current row of data as its input. The function has no information on where those values came from (e.g. whether directly from a map or from the result of some other function). It would be more realistic to implement it as a modifier, e.g. min#input, similar to how colour-table lookups are performed. But that creates issues of its own: what's the type? DCELL? Or the same as the input? Is it the value for the map as a whole or do we need to invoke r.univar (or embed r.univar into r.mapcalc or libraster)? Are we going to add similar modifiers for all of the other useful statistics? For arbitrary quantiles? do you think could be useful? Not really. Just use r.info (or r.univar if you want the min/max for the current region) and substitute the result into the expression. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] python2/3 and GRASS build on Arch
Maciej Sieczka wrote:
--with-wxwidgets=/usr/bin/wx-config-2.8
Per 2.8 wxWidgets specified, I don't get it why
/usr/lib/python2.7/site-packages/wx-3.0-gtk2/ gets involved in iclass
build. I would rather expect it to pick
/usr/lib/python2.7/site-packages/wx-2.8-gtk2-unicode/. Some details:
--with-wxwidgets only affects compiled (C/C++) code which links
against the wxWidges libraries. In 7.0, this means the wximgview
module (visualization/wximgview) and nothing else. It doesn't affect
wxGUI.
In theory, code which uses the wxPython library is supposed to use
something like:
import wxversion
wxversion.select('2.8')
import wx
to ensure that the correct version is used when there are multiple
versions present on the system.
This is an Arch box. I do have all the NumPy stuff installed. There is a
problem on Arch that wx-3.0-gtk2/wx/lib/plot.py fails to import
numpy.oldnumeric [1] leading to those NumPy not found errors, but that
would not happen if iclass build referred to
wx-2.8-gtk2-unicode/wx/lib/plot.py instead - like I guess all the other
GRASS 7 Python modules do.
Maybe everything is using wx-3.0, but only iclass is using the broken
plots.py functionality?
If you can run some other g.gui.* module, you can check which
libraries it's actually using with cat /proc/pid/maps, where pid
is the PID of the g.gui.* process.
--
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.mapcalc bug on max and min?
On Wed, Oct 8, 2014 at 12:38 PM, Glynn Clements gl...@gclements.plus.com wrote: do you think could be useful? Not really. Just use r.info (or r.univar if you want the min/max for the current region) and substitute the result into the expression. Yes, I did in this way. Thank you. Pietro ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] casting row buffer in memory
On Wed, Oct 8, 2014 at 11:24 AM, Glynn Clements
gl...@gclements.plus.com wrote:
Pietro wrote:
So even if I'm explicitly casting the result in the scaler function
with dtype(...), the result is not properly casted, do you have an
idea on how could I solve this problem?
This is a bug in pygrass:
$ r.info -g foo | fgrep datatype
datatype=CELL
$ python
Python 2.7.7 (default, Sep 26 2014, 00:18:15)
[GCC 4.6.3] on linux2
Type help, copyright, credits or license for more information.
from grass.pygrass.raster import RasterRow
out = RasterRow('foo', mode='w', mtype='DCELL', overwrite=True)
out.mtype
u'CELL'
If a map with the chosen name already exists, its type is used in
place of the one specified.
Thank you to find out this bug, I didn't noticed it.
Looking at the code for grass.pygrass.raster.RasterRow.open(), the
overall structure is rather flawed. It primarily considers whether the
map already exists, then secondarily considers the mode (r/w).
It should be the other way around.
Right. Thank you for your code review!
I will try to fix this on the next days.
All the best.
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] What is the status of g.list, g.remove, g.mlist and g.mremove?
Hi all, I lost a bit of track here - what is the current state? My real question regards the needed backport to relbranch7 in order to be able to prepare the next beta (the first RC should come with the definite API). thanks, Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] python2/3 and GRASS build on Arch
W dniu 08.10.2014 o 13:04, Glynn Clements pisze:
Maciej Sieczka wrote:
--with-wxwidgets=/usr/bin/wx-config-2.8
Per 2.8 wxWidgets specified, I don't get it why
/usr/lib/python2.7/site-packages/wx-3.0-gtk2/ gets involved in iclass
build. I would rather expect it to pick
/usr/lib/python2.7/site-packages/wx-2.8-gtk2-unicode/. Some details:
--with-wxwidgets only affects compiled (C/C++) code which links
against the wxWidges libraries. In 7.0, this means the wximgview
module (visualization/wximgview) and nothing else. It doesn't affect
wxGUI.
In theory, code which uses the wxPython library is supposed to use
something like:
import wxversion
wxversion.select('2.8')
import wx
to ensure that the correct version is used when there are multiple
versions present on the system.
This is an Arch box. I do have all the NumPy stuff installed. There is a
problem on Arch that wx-3.0-gtk2/wx/lib/plot.py fails to import
numpy.oldnumeric [1] leading to those NumPy not found errors, but that
would not happen if iclass build referred to
wx-2.8-gtk2-unicode/wx/lib/plot.py instead - like I guess all the other
GRASS 7 Python modules do.
Maybe everything is using wx-3.0, but only iclass is using the broken
plots.py functionality?
If you can run some other g.gui.* module, you can check which
libraries it's actually using with cat /proc/pid/maps, where pid
is the PID of the g.gui.* process.
Indeed!
I patched iclass/g.gui.iclass.py with wxversion.select('2.8'), just to
let a full GRASS 7 build complete without errors, and actually every
g.gui.* module except iclass is using wx-3.0-gtk2...
Is using a mix of wxPython 2.8 and 3.0 like this going to pose any usage
problems in core GRASS or plugins?
Could GRASS offer a mechanism to enforce a specific wxPython version
throughout all of GRASS build and run time? Or how to hack it in a more
elegant way than patching those ~140 *.py files which import wx?
I can't just uninstall wxpython (which provides the problematic
wx-3.0-gtk2), because wxpython-2.8 (providing an OK wx-2.8-gtk2-unicode)
depends on it...
Maciek
--
Maciej Sieczka
http://www.sieczka.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wxGUI import chain
On Tue, Oct 7, 2014 at 2:24 AM, Pietro peter.z...@gmail.com wrote: On Mon, Oct 6, 2014 at 9:15 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: Is there any reason why gui/wxpython/gis_set.py imports (eventually) etc/python/grass/pygrass/raster/buffer.py? Anyway, r62196 fails to start the GUI in trunk because of broken pygrass. I doubt if it is a good idea to make pygrass a dependency of the GUI. I'm not able to reproduce the problem, what kind of error did you get? Any way I will work in the __init__ file to isolate the ctypes stuff. So, now I have seen it at someones computer. It was something about np.float* in buffer.py. The problem was in yesterday's build of 7.0 for MS Windows, it is fixed in today's one. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
