Re: [GRASS-dev] pyGRASS strange error on loading raster modules shortcuts
Hi Yann, On Thu, Jun 27, 2013 at 3:20 AM, Yann Chemin yche...@gmail.com wrote: Hi, this is found on a cluster, it is running on Pythn 2.6.6, it is a 64 bit system the svn tree is few days old, updating it now. Can you open a python2.6.6 shell and try this import: from xml.etree.ElementTree import fromstring Do you receive the same error? TypeError: __new__() takes at most 2 arguments (3 given) Pietro ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] pygrass numpy object int and float data
Hi, I have a CELL (integer) layer. If I write these lines: map=raster.RasterNumpy(grassmap) map.open() map.close() I obtain: File ./r.grow.dir.incl4.py, line 310, in module main() File ./r.grow.dir.incl4.py, line 133, in main visited.close() File /usr/local/grass-7.0.svn/etc/python/grass/pygrass/raster/__init__.py, line 664, in close self._write() File /usr/local/grass-7.0.svn/etc/python/grass/pygrass/raster/__init__.py, line 607, in _write self.tofile(self.filename) ValueError: 16 requested and 0 written if i write: map=raster.RasterNumpy(grassmap) map.open() map=map*1.0 map.close() it works. Do the numpy raster object is, by default, a float type? what I miss? Many thanks Ivan ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] pygrass numpy object int and float data
Hi Ivan, On Thu, Jun 27, 2013 at 10:03 AM, Ivan Marchesini ivan.marches...@gmail.com wrote: Hi, I have a CELL (integer) layer. Do the numpy raster object is, by default, a float type? yes, a numpy array is by default a float, you can open a map with different type with: rast.open(mode='w', mtype='CELL') This should work, however I had some Segmentation Fault using RasterNumpy and integer in the past and I'm not sure it is working at the moment... Let me know! :-) Pietro ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSOC Horizon based stratigraphy
On 06/26/2013 06:48 PM, Pierre Roudier wrote:
Hi all,
This is an excellent point. While I like the mention of AQP in this context,
I totally support a GRASS-based implementation with as few dependencies as
possible.
+1 - I think a native GRASS implementation would make a lot of sense.
Yes, the thought of such waffel voxels is not exactly appealing.
However, they may be a smaller problem in practice, since the voxel
models themselves are often used to derive vertical slices
(profiles), and those might look perfectly fine, even if derived
from malformed voxels. GRASS does allow for individual X, Y and Z
dimensions of voxels, so there is no technical problem with this.
The results of the interpolation don't need to be beautiful, they
just need to be as accurate and as true to the data as possible.
That's the very nature of soils data - we soil scientists often deal
with pixels of 10 to 500m resolution, to observe processes that occur
generally in the first meter in the z axis! It is not a problem, and
the challenge is to come up with tools that allow us to store, query
and interpolate such data.
This is a popular topic in the soils literature-- vertical anisotropy can be
an order of magnitude greater than what is found in the horizontal.
Restricted cubic splines have some desirable characteristics for dealing
with this kind of data-- however, these work best in the context of a
regression model. Also, there are the mass-preserving splines that are more
useful in the interpolation along the soil profile sense. For categorical
data, I would recommend the ordinal-ratio logistic regression model, which
generates class-wise probability estimates. I have found this quite useful
for generating probability depth-functions for categorical soil properties.
I can elaborate as needed.
The mass-preserving splines has become a key tool in the GlobalSoilMap
project. An implementation in R exists but is not very efficient. This
could be an opportunity to come up with a reference implementation! As
mentioned by Dylan, various interpolation methods are available,
restricted cubic splines look good as well.
But is that method suitable for categorized input data?
Or does it only work for continuous soil properties?
A spline-based interpolator from 3D vector to 3D raster
already exists in GRASS (v.vol.rst).
Best,
Ben
Cheers,
P
--
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] GSOC Horizons and Stratigraphy
On 06/26/2013 07:00 PM, Pierre Roudier wrote:
Hi Benjamin,
As far as soils data, we would probably often mask with depths min or
max, use a plan to cut the profile collection to return points (give
the carbon value at 13.5cm depth for this collection of profiles).
Yes, however, please keep in mind that this project
works with soil horizons, i.e. just categories, not
measurable quantities/properties.
Cutting through the interpolated voxel model to get a
2D distribution of horizons can easily be done with
the existing GRASS tools.
Alternatively, we would try to interpolate a profile collection to
harmonise soil depths: while data is usually collected on
heterogeneous depths intervals, one might want to harmonise the
collection for quantitative analysis: for example the new depth
support might be {0-5cm, 5-10cm, 10-30 cm, 30-60cm, 60-100cm}.
That should be possible by retrieving new cross-sections
from the interpolated voxel model.
Best,
Ben
Just 2 cents,
Pierre
2013/6/25 Benjamin Ducke bendu...@fastmail.fm:
On 06/25/2013 10:00 AM, Tim Bailey wrote:
Hi Ben,
All that I meant by mask is, in this case, an r3 map that defines a
subset of space that subsequent operations are constrained to. I guess I
was just expressing worry about creating runaway data demands.The region
settings act as a three dimensional bounding cube, does not seem
adequate to constrain a tiling scheme with relatively sparse data.In the
compromise scenario that Dylan suggested with 10 meter xy and 1 cm z
resolution and 1 meter depth we would be looking at populating 1
voxels per hectare for a flat landscape. However if we were using a
simple bounding box to define the region and we had 5 meters of relief
we would end up with 5 or 6 voxels. As the area of coverage gets
bigger cost of the range in z values gets worse.
That's a good point that I hadn't thought about.
Clearly, we don't want the interpolation to go
beyond the limits of the terrain surface. It would
probably be a good idea for the user to be able to
supply an additional DEM input that could supply
upper cut-off values. A lower cut-off could simply
be defined as a constant depth value, and the same
for the extents along the X-Y plane. Apart from that,
the interpolator should use a configurable search
radius for points, so that it won't start interpolating
values in areas that have no sample data.
Ben
Tim
___
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
--
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] GSOC Horizon based stratigraphy
Hi Ben,
You are right, these mass-preserving splines are for continuous data -
it seems I have been carried away from the original scope of the
project while writing my email :)
Cheers,
P
2013/6/27 Benjamin Ducke bendu...@fastmail.fm:
On 06/26/2013 06:48 PM, Pierre Roudier wrote:
Hi all,
This is an excellent point. While I like the mention of AQP in this
context,
I totally support a GRASS-based implementation with as few dependencies
as
possible.
+1 - I think a native GRASS implementation would make a lot of sense.
Yes, the thought of such waffel voxels is not exactly appealing.
However, they may be a smaller problem in practice, since the voxel
models themselves are often used to derive vertical slices
(profiles), and those might look perfectly fine, even if derived
from malformed voxels. GRASS does allow for individual X, Y and Z
dimensions of voxels, so there is no technical problem with this.
The results of the interpolation don't need to be beautiful, they
just need to be as accurate and as true to the data as possible.
That's the very nature of soils data - we soil scientists often deal
with pixels of 10 to 500m resolution, to observe processes that occur
generally in the first meter in the z axis! It is not a problem, and
the challenge is to come up with tools that allow us to store, query
and interpolate such data.
This is a popular topic in the soils literature-- vertical anisotropy can
be
an order of magnitude greater than what is found in the horizontal.
Restricted cubic splines have some desirable characteristics for dealing
with this kind of data-- however, these work best in the context of a
regression model. Also, there are the mass-preserving splines that are
more
useful in the interpolation along the soil profile sense. For
categorical
data, I would recommend the ordinal-ratio logistic regression model,
which
generates class-wise probability estimates. I have found this quite
useful
for generating probability depth-functions for categorical soil
properties.
I can elaborate as needed.
The mass-preserving splines has become a key tool in the GlobalSoilMap
project. An implementation in R exists but is not very efficient. This
could be an opportunity to come up with a reference implementation! As
mentioned by Dylan, various interpolation methods are available,
restricted cubic splines look good as well.
But is that method suitable for categorized input data?
Or does it only work for continuous soil properties?
A spline-based interpolator from 3D vector to 3D raster
already exists in GRASS (v.vol.rst).
Best,
Ben
Cheers,
P
--
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
--
Scientist
Landcare Research, New Zealand
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.3 release planning
On Wed, Jun 26, 2013 at 10:29 PM, Hamish hamis...@yahoo.com wrote: I've worked through the changelog and the 6.4.3rc4 release summary page seems in order now, https://trac.osgeo.org/grass/wiki/Release/6.4.3RC4-News Thanks. anything else to add? It is not clear to me (lost in too many emails): - if g.extension is sufficiently ok now - if Python scripts run on Windows - for both, if it improved in the upcoming RC4 So, perhaps either some related remarks would be good or a link to the (to be updated) http://grasswiki.osgeo.org/wiki/WinGRASS_Current_Status#Known_Issues Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.3 release planning
I am also wondering whether the r.mapcalc expressions with || (or) now run from the wxGUI command console. Is this the place to get the right binary to try it out? http://wingrass.fsv.cvut.cz/grass64/ Helena On Jun 27, 2013, at 9:33 AM, Markus Neteler wrote: On Wed, Jun 26, 2013 at 10:29 PM, Hamish hamis...@yahoo.com wrote: I've worked through the changelog and the 6.4.3rc4 release summary page seems in order now, https://trac.osgeo.org/grass/wiki/Release/6.4.3RC4-News Thanks. anything else to add? It is not clear to me (lost in too many emails): - if g.extension is sufficiently ok now - if Python scripts run on Windows - for both, if it improved in the upcoming RC4 So, perhaps either some related remarks would be good or a link to the (to be updated) http://grasswiki.osgeo.org/wiki/WinGRASS_Current_Status#Known_Issues Markus ___ 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 6.4.3 release planning
On Thu, Jun 27, 2013 at 4:49 PM, Helena Mitasova hmit...@ncsu.edu wrote: I am also wondering whether the r.mapcalc expressions with || (or) now run from the wxGUI command console. Probably yes (no idea). Is this the place to get the right binary to try it out? http://wingrass.fsv.cvut.cz/grass64/ yes. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.3 release planning
Hamish wrote: anything else to add? MarkusN: It is not clear to me (lost in too many emails): - if g.extension is sufficiently ok now AFAIK, yes. On Mac OSX Michael reported some success for grass6, but problems remain with grass7. - if Python scripts run on Windows which ones? addons or in-built wxgui ones? python addons for grass6 via g.extension are only working on *NIX afaik, but I think python addons for wingrass are not a blocker. they are only a few and we can worry about it in grass-addons svn after release. Perhaps a new include/make/PythonScipt.make for 6.4.4 with .bat file wrappers and rename as needed if the .py extension association remains unsolved? Also the wingrass g.extension[.py] addons come pre-built, so we can apply any fixes post-release there via the server. I am more concerned about people's own custom python scripts and giving them good advice about how to use them in developing their own projects. But that issue could be beyond the scope of any particular release. - for both, if it improved in the upcoming RC4 categorically I'd say yes, although RC3 likely was the main improvement. is it perfect? probably not but generally working and no longer a reason to delay IMO. So, perhaps either some related remarks would be good or a link to the (to be updated) http://grasswiki.osgeo.org/wiki/WinGRASS_Current_Status#Known_Issues ok, now added to the RC4 news wiki page along with a link to open GRASS 6.x tickets, but the wingrass wiki known issues page is well out of date and needs a cleanup. Helena: I am also wondering whether the r.mapcalc expressions with || (or) now run from the wxGUI command console. I just tried on linux 6.4.3svn wxGUI command console: r.mapcalc either = 0 || 1 and it worked. In general I wouldn't be surprised if full command line quoting took years and huge amounts of effort to (re)perfect. And even then, does it try to follow Bash conventions, or python, or DOS, or some mix of all those? How much do we try to (re)teach about command line techniques in our own docs? Will unquoted input=C:\Users\files\data.txt always be parsed to input=C:Usersfilesdata.txt (literal \U, \f, \d) in the command console in that case? best, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.3 release planning
regarding the r.mapcalc issue in command console on wingrass - (sorry I did not make it clear it was for wingrass - it always worked well on Mac and linux) It is not critical, windows users can still use the mapcalculator GUI where it runs OK, but the r.mapcalc in the command console still does not seem to work - tried by a student using June 26 snapshot this is what she says: Here are examples of the commands run and the errors received: r.mapcalc urban2_30m=if(landuse96_28m==1 || landuse96_28m==2,landuse96_28m,null()) syntax error, unexpected $end, expecting ')' Parse error 'landuse96_28m' is not recognized as an internal or external command, operable program or batch file. r.mapcalc MASK=if((elevation100 elevation60) (landuse96_28m==1 || landuse96_28m==2),1,null()) 1 was unexpected at this time. This is the same we were getting in GRASS6.4.3RC2 and apparently the proposed solutions did not work http://lists.osgeo.org/pipermail/grass-dev/2013-February/062047.html http://lists.osgeo.org/pipermail/grass-dev/2013-March/062607.html if I get this confirmed I will file a bug report (I thought I already did, but it is not there). If it is not fixable it should be at least mentioned on the known issues web page http://grasswiki.osgeo.org/wiki/WinGRASS_Current_Status#Raster_modules Helena Helena: I am also wondering whether the r.mapcalc expressions with || (or) now run from the wxGUI command console. I just tried on linux 6.4.3svn wxGUI command console: r.mapcalc either = 0 || 1 and it worked. In general I wouldn't be surprised if full command line quoting took years and huge amounts of effort to (re)perfect. And even then, does it try to follow Bash conventions, or python, or DOS, or some mix of all those? How much do we try to (re)teach about command line techniques in our own docs? Will unquoted input=C:\Users\files\data.txt always be parsed to input=C:Usersfilesdata.txt (literal \U, \f, \d) in the command console in that case? best, Hamish ___ 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] #1837: d.rast.edit error when attempting to edit a raster
#1837: d.rast.edit error when attempting to edit a raster --+- Reporter: MarcoSc | Owner: grass-dev@… Type: defect| Status: new Priority: normal| Milestone: 6.4.3 Component: wxGUI | Version: 6.4.3 RCs Keywords: d.rast.edit, tcltk, wingrass |Platform: All Cpu: x86-64| --+- Changes (by hamish): * milestone: 6.4.4 = 6.4.3 Comment: d.rast.edit from the wxGUI in WinGrass is believed now fixed in relbr64, see #86. I didn't test it from the osgeo4w installer though, maybe you could. Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/1837#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 6.4.3 release planning
Helena wrote:
regarding the r.mapcalc issue in command console on wingrass -
(sorry I did not make it clear it was for wingrass - it always worked
well on Mac and linux)
ah, ok, yes it still fails there for me to.
6.4.3svn on XP from the wxGUI command console:
{{{
r.mapcalc either = 0 || 1
unterminated string
syntax error, unexpected $end, expecting NAME or STRING
Parse error
'1\' is not recognized as an internal or external command,
operable program or batch file.
}}}
I've no idea how to fix it.
It is not critical, windows users can still use the mapcalculator
GUI where it runs OK, but the r.mapcalc in the command console
still does not seem to work -
another suggestion to bypass the problem is to start with the MSys or
C:\ command windows; that's actually the default in wingrass7. if a
real terminal should open or not when grass is started with the default
desktop icon remains an open question.
if I get this confirmed I will file a bug report (I thought I
already did, but it is not there).
I thought it was there too, maybe it was in the comments of one of
the long tickets about the C:\Files having the \F being treated as
a quoted literal F? eg https://trac.osgeo.org/grass/ticket/1447
shrug, nothing here:
https://trac.osgeo.org/grass/query?status=assignedstatus=newstatus=reopenedcomponent=wxGUIorder=prioritycol=idcol=summarycol=componentcol=statuscol=typecol=prioritycol=milestonemilestone=!7.0.0keywords=~wingrass
so maybe it needs its own ticket.
If it is not fixable it should be at least mentioned on the
known issues web page
http://grasswiki.osgeo.org/wiki/WinGRASS_Current_Status#Raster_modules
right, a ticket to refer back to would be good though.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] compilation of grass on AIX 7.1
On Wed, Jun 26, 2013 at 7:40 PM, Markus Neteler nete...@osgeo.org wrote: ... Now trying to get shared libraries enabled (almost there). Also enabled in SVN (thanks to Markus Metz). Interestingly, when *starting* GRASS 7, I get on that AIX machine: Cleaning up temporary files... Starting GRASS GIS... Could not load program g.gisenv: Could not load module /gpfs/home/neteler/software/grass-7.0.svn/dist.powerpc-ibm-aix7.1.0.0/lib/libgrass_gis.7.0.svn.so. Dependent module /usr/lib/libiconv.a(libiconv.so.2) could not be loaded. Member libiconv.so.2 is not found in archive Could not load module g.gisenv. Dependent module /gpfs/home/neteler/software/grass-7.0.svn/dist.powerpc-ibm-aix7.1.0.0/lib/libgrass_gis.7.0.svn.so could not be loaded. Could not load module . Could not load program g.gisenv: Could not load module /gpfs/home/neteler/software/grass-7.0.svn/dist.powerpc-ibm-aix7.1.0.0/lib/libgrass_gis.7.0.svn.so. Dependent module /usr/lib/libiconv.a(libiconv.so.2) could not be loaded. Member libiconv.so.2 is not found in archive Could not load module g.gisenv. Dependent module /gpfs/home/neteler/software/grass-7.0.svn/dist.powerpc-ibm-aix7.1.0.0/lib/libgrass_gis.7.0.svn.so could not be loaded. Could not load module . Indeed, the libconv stuff is in /opt/freeware/ but searched in the common /usr/ directories. Existing: /usr/include/iconv.h /* @(#)09 1.20 src/bos/usr/include/iconv.h, libiconv, bos610 8/28/03 11:09:44 */ /* IBM_PROLOG_END_TAG */ ... but no corresponding libiconv. How to tell GRASS 7 in configure to pick up the /opt/freeware/ include file and library? Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
