Greetings, devs,
A popular covariate in the digital soil mapping community is the
multiresolution valley bottom flatness (MrVBF) index, proposed by John
Gallnd in 2003 [0]. While an open-source implementation is available
in SAGA-GIS [1], I would like to be able to produce this in my
favourite GIS
Hi,
I am using (with enthusiasm!) Pietro's pygrass library to develop a raster
module. I am using Numpy/Scipy as my working horse, so I manipulate a lot
of the RasterNumpy objects that have been introduced with pygrass.
In a specific step, I am identifying pixels using a test (this would be
simil
rre,
>
> On Mon, Dec 17, 2012 at 7:48 AM, Pierre Roudier
> wrote:
>> Hi,
>>
>> I am using (with enthusiasm!) Pietro's pygrass library to develop a raster
>> module. I am using Numpy/Scipy as my working horse, so I manipulate a lot of
>> the RasterNumpy
to 40 interpolation steps), so I would
like to make the most of GRASS interpolation power.
Cheers,
Pierre
2012/12/18 Pietro :
> Hi Pierre,
>
> On Mon, Dec 17, 2012 at 9:44 PM, Pierre Roudier
> wrote:
>> Thanks Pietro,
>>
>> Yes that answers the question, but just partly: I w
s there a method to create a set of points (class Point) and write
it into the GRASS database?
- I would like to use this {x,y,z} set of points in v.surf.bspline. I
don't suppose I got another choice but write my numpy array into the
GRASS database first right?
Thanks again for yo
Hi Markus et al.,
Just to throw my two cents, it would be great if we could generalise
this UI to any classification workflow, including unsupervised. I
could also see this UI as a nice way to integrate r.fuzzy.* maybe?
Also, the excellent work on Markus M and Eric Momsen on i.segment
could also
Mohammed,
For segmentation please get in touch with Eric Momsen who worked on
i.segment recently, with great success. We were looking forward to add the
mean shift option. Keep also Markus Metz in the loop - he was the mentor of
the project and worked on i.segment.xl.
Also, make sure you check ou
Hi Anna,
Weird - I can launch parallel g.gui instances without any problem in
(X)Ubuntu 12.04.1, with grass70 compiled against the latest trunk.
Cheers,
Pierre
2013/2/11 Anna Kratochvílová :
> Hi,
>
> I've upgraded today from ubuntu 10.04 to 12.04 and now I have problems
> to start wxGUI. Launc
Thanks Markus and Eric,
I have similar feedback when testing on various SPOT5 scenes. XL results
are not entirely identical of course, but reasonably similar, so I support
Markus' decision.
Cheers,
Pierre
On Feb 11, 2013 10:53 PM, "Markus Metz"
wrote:
> Hi all,
>
> I have tested again i.segmen
Absolutely Markus. Let's also keep in mind that comparing segmentation
results is a very tricky exercise. There's no such thing as a perfect
segmentation result IMHO.
Pierre
2013/2/12 Markus Metz :
> On Mon, Feb 11, 2013 at 8:18 PM, Pierre Roudier
> wrote:
>> Thanks Ma
Hi Luca, Yann and the list,
That sounds very interesting - could it be possible to post code
snippets somewhere on the wiki to get newbies like me going?
Just a suggestion,
Pierre
2013/5/15 Luca Delucchi :
> On 15 May 2013 10:38, Yann Chemin wrote:
>> Hi list,
>>
>
> Hi Yann
>
>> PyWPS is Pyth
Hi,
I am a happy user the start_rast option in r.walk in GRASS 7,
Recently I realised that the option is not available on the stable
version of GRASS (6.4.2) when a student here tried one of my scripts.
Is there any plan to backport this, or should the student switch to GRASS 7?
Cheers,
Pierre
Dear devs,
I am working on Antarctica data, projected in Antarctic Polar
Stereographic (EPSG:3031, [0,1]). This projection puts the South Pole
in the "center" of the map.
I have strange results in the Ross Sea Region using r.sun from GRASS 7
compiled from trunk (SVN checkout probably about less t
Hi Tim, Hamish et al.,
Just jumping in the discussion, FYI: I am following the project with
much attention, in particular because I am working with soil data,
both at the national scale in NZ, but also on international project
that aim at storing important amounts of data [www.globalsoilmap.net].
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 no
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").
Alternatively, we would try to interpolate a profile collection to
harmonise
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 :
> On 06/26/2013 06:48 PM, Pierre Roudier wrote:
>>
>> Hi all,
Any of you guys have code around to do hierarchical segmentation?
Tried to do it in Python a few months ago, but failed (I'm not exactly
a great Python coder it seems!).
Cheers,
Pierre
2013/7/31 Moritz Lennert :
> On 27/07/13 00:19, Nikos Alexandris wrote:
>>
>> On Friday 26 of July 2013 15:41:2
Hi,
I'm having a wee problem trying to compile r.modis on the trunk
version of GRASS. It does not seem to compile the pymodis library if
I'm getting that right:
GRASS 7.0.svn (eda-rsr):~ > g.extension ext=r.modis
Fetching from GRASS-Addons SVN (be patient)...
WARNING: gnome-keyring:: couldn't co
Hi,
> On Fedora 19 no problem:
>
> GRASS 7.0.svn (nc_basic_spm_grass7):~ > g.extension r.modis
> Fetching from GRASS-Addons SVN (be patient)...
> Compiling...
> Installing...
> Updating metadata file...
> Installation of successfully finished
>
Forgot to mention that I'm running Ubuntu 12.04.2.
Moritz,
Thanks heaps for the script. It's really is useful and will facilitate
the adoption of i.segment. It certainly would be a nice addition to
the wiki page.
Unfortunately I can't comment too much on this, as my object-based
classification projects are on hold, but I'll try to give that a sho
Very useful resource Martin.
FWIW, the translation of the page is very usable for non-Czech speakers:
http://translate.google.com/translate?sl=cs&tl=en&js=n&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Fgeo.fsv.cvut.cz%2Fgwiki%2F153ZODH_%2F_15._cvi%25C4%258Den%25C3%25AD&act=url
Pierre
2014-01-29 Martin
Hi list,
I got the following error when compiling against the last update of
the grass7 trunk:
gcc -g -fPIC
-I/usr/local/src/grass_trunk/dist.x86_64-unknown-linux-gnu/include
-I/usr/local/src/grass_trunk/dist.x86_64-unknown-linux-gnu/include
-D_FILE_OFFSET_BITS=64 -DPACKAGE=\""grasslibs"\"
-I/
Thanks for your pointers,
After a clean checkout and a make clean, it compiled successfully.
Cheers,
Pierre
2011/3/21 Glynn Clements :
>
> Pierre Roudier wrote:
>
>> I got the following error when compiling against the last update of
>> the grass7 trunk:
>
>>
Hi,
I just compiled grass7-svn (revision 45721) on my server, but I can't
initiate any mapset:
pierrer@grass:~$ grass70 -text
Unable to start GRASS. You can:
- Launch GRASS with '-gui' switch (`grass70 -gui`)
- Create manually GISRC file (/home/pierrer/.grass7/rc)
- Launch GRASS with path to t
Thanks for your reply Glynn,
> As suggested in the above message, specifying the path to an existing
> mapset directory as an argument should work (but probably doesn't get
> much testing). The "demolocation" location should be installed under
> $GISBASE; you may be able to use that, provided that
Hi Martin and others, and thanks very much for your answers,
Your solution is working well Martin, however for some reason I have
to be root to start grass successfuly.
pierrer@grass:~$ grass70 -c /home/pierrer/grassdata/test2
Traceback (most recent call last):
File "/usr/local/bin/grass70", li
Hi Martin,
> you are probably overriding GISBASE variable.
>
> What gives
>
> $ echo $GISBASE
Indeed:
pierrer@grass:~$ echo $GISBASE
/home/pierrer/grassdata/
So I turned it back to void:
pierrer@grass:~$ export GISBASE=""
pierrer@grass:~$ echo $GISBASE
But unfortunately the problem remains the
nda :
> Hi,
>
> 2011/3/23 Pierre Roudier :
>> pierrer@grass:~$ export GISBASE=""
>
> unset GISBASE
>
> Martin
>
> --
> Martin Landa * http://geo.fsv.cvut.cz/~landa
>
--
Scientist
Landcare Research, New Zealand
Hi,
No add-on seems to9 be available to my system when trying to use the
g.extension command:
GRASS 7.0.svn (NZTM2000):~ > g.extension -l
svnurl=https://svn.osgeo.org/grass/grass-addons
Fetching list of modules from GRASS-Addons SVN (be patient)...
GRASS 7.0.svn (NZTM2000):~ >
Therefore, it is n
svn (NZTM2000):~ >
I'm wondering if I have to specify something special for https in my
subversion conf file?
Pierre
2011/3/30 Markus Neteler :
> On Wed, Mar 30, 2011 at 3:13 AM, Pierre Roudier
> wrote:
>> Hi,
>>
>> No add-on seems to9 be available to my system wh
Well, I think this is the case if svn is used.
What is surprising though is that:
svn co https://svn.osgeo.org/grass/grass-addons
is working well.
Should I fill a bug?
Pierre
2011/3/31 Markus Neteler :
> On Thu, Mar 31, 2011 at 1:27 AM, Pierre Roudier
> wrote:
>> T
Markus,
>> Should I fill a bug?
>
> Yes please.
Just filled http://trac.osgeo.org/grass/ticket/1341
> Sorry for the problem,
No worries - thanks for making GRASS awesome :)
Pierre
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osge
Hi Markus,
Just compiled again liblas svn trunk, everything is working as expected so far.
Thanks heaps for that new functionality, this is really very useful.
Pierre
2011/5/25 Markus Metz :
> Hi all,
>
> GRASS 7 has a new module v.in.lidar for importing LiDAR LAS files
> (*.las or *.laz). The
Hi,
I must be missing something obvious here: I'm trying to do my first
script in Python, and I go the following error when calling
grass.parser():
Line too long or missing newline at line 63
Thinking my code must be bugged, I gave it a shot with the examples on
the wiki (d.shademaps) and on the
Thanks Luca, that did the trick.
Cheers,
Pierre
2011/5/27 Luca Delucchi :
> 2011/5/27 Pierre Roudier :
>> Hi,
>>
>> I must be missing something obvious here: I'm trying to do my first
>> script in Python, and I go the following error when calling
>> grass
Hi,
I'm beginning to script GRASS using Python. Turns out it is very easy
and convivial, and in a very limited amount of time I was able to put
together a little extension to bring the main mathematical morphology
operators to GRASS.
The problem I got, however, is how to install that script into
Hi Glynn, and thanks very much for taking the time to answer my newbie
questions,
> The r.mm.html file should not contain the parts which are generated by
> "r.mm.py --html-description". The build system does this automatically
> if the .html file doesn't contain an "" tag. This ensures that
> the
Hi Glynn,
> The build system merges the --html-description output with the
> .html file (unless the .html file contains an
> tag, in which case it is used verbatim; this is intended for modules
> which don't recognise the --html-description switch, e.g. g.parser).
>
> Look at the .html files for
at 12:10 AM, Pierre Roudier
> wrote:
> ...
>> Thanks heaps. Should that be on a wiki page somewhere?
>
> Please expand this page:
> http://grass.osgeo.org/wiki/GRASS_and_Python
>
> thanks
> Markus
>
--
Scientist
Landcare Research, New Zealand
_
Hi,
I just encountered the following error while compiling the last svn up
of grass_trunk:
In file
/usr/local/src/grass7-svn/grass_trunk/dist.x86_64-unknown-linux-gnu/include/grass/gprojects.h,
couldn't find ogr_srs_api.h
I turned ogr_srs_api.h to gdal/ogr_srs_api.h and it did pass the error
an
Sorry, I did not include my ./configure line.
I do have the --with-gdal=[path/to/gdal-config] option right. I did
not changed my configure options, I used the usual ones, which
compiled successfully on svn the last 6 months.
Pierre
2011/6/8 Moritz Lennert :
> On 08/06/11 05:01, Pierre Roud
Hi,
I've been trying to use v.in.lidar. It yields good results on one LAS
file, but I get a segfault when trying it on several files:
> v.in.lidar in=BD32_1610.las,BD32_1611.las out=test_input_lidar -trb
Segmentation fault
> v.in.lidar in=BD32_161*.las out=test_input_lidar -trb
Segmentation fault
rb
to import a special subset of LAS files.
I've very few coding abilities, so this is just meant as another line
on the wishlist ;)
Thanks heaps for your work on *.in.lidar, it is working well otherwise,
Pierre
2011/7/13 Markus Metz :
> On Wed, Jul 13, 2011 at 2:08 AM, Pierre Roudier
>
Should I do it?
Cheers,
Pierre
> Pierre Roudier
> Sent by: grass-dev-boun...@lists.osgeo.org
>
> 07/13/2011 03:05 AM
>
> To
> Markus Metz
> cc
> grass-dev
> Subject
> Re: [GRASS-dev] Segmentation fault using v.in.lidar
>
>
>
>
> Thanks for the quick
Hi Rashad,
I'd be interested to hear about HPGL. As Thomas mentioned, kriging is
currently available through R using the gstat package - and has thus
the some limitations in terms of efficiency, and also on the size of
the data to be processed.
Note that from 6.4, a python module is available for
Hi,
As a user, I would also find the integration of say OTB in GRASS being a
plus - a very general segmentation algorithm like the watershed is provided
by OTB and is a handy tool at times. OTB being based on VTK, maybe you
could make use of some of Soeren's work on the vtk-grass-bridge?
Pierre
O
Hi Owen,
This page [0] is a good entry point,
Pierre
[0]: http://grass.osgeo.org/wiki/Development
2012/5/15 Owen Brown :
> All, I am a “benched” developer at an IT contracting company looking to help
> out on an open-source project. I primarily work with Java but understand C
> pretty well. Wou
Hi,
I must be missing something because I can't compile grass7.svn on a
new config. The compilation error is located in
grass_trunk/visualization/ximgview (see below).
Any pointer would be greatly appreciated,
Cheers,
Pierre
roudierp@mangatainoka:/usr/local/src/grass_trunk/visualization/ximgvi
Thanks for your help Markus and Glynn,
I do have libx11-dev installed (I'm running Xubuntu 12.04), but still
get the same error unfortunately,
Pierre
2012/7/12 Markus Neteler :
> On Thu, Jul 12, 2012 at 9:02 AM, Pierre Roudier
> wrote:
>> Hi,
>>
>> I must be miss
don't think I'm making any use of the ximgview module at the moment,
so I'm happy to try and drop it from my final install. I do need
grass7 to compile for testing Eric Momsen's GSoC project.
Any help greatly appreciated,
Cheers,
P
2012/7/13 Glynn Clements :
>
> Pierre
the same error at compilation,
P
2012/7/13 Pierre Roudier :
> Glynn,
>
> Is there an easy work-around this? It's a bit weird as the compilation
> goes well on my older machine. It seems to fail only on this newer
> configuration. After a bit of googling, I *think* that the
Thanks heaps for your help Glynn, it worked.
For reference, here's the workaround I used:
roudierp@mangatainoka:/usr/local/src/grass_trunk$ more
include/Make/Platform.make | grep -n XLIB
86:XLIBPATH= -L/usr/bin
Cheers,
Pierre
2012/7/14 Glynn Clements :
>
> Pierre Ro
Hi Glynn et al.,
I still got the same problem - I'm happy to use the workaround and
edit the Platform.make file by hand, but should I lodge a bug report
in the tracker?
Cheers,
Pierre
2012/7/14 Pierre Roudier :
> Thanks heaps for your help Glynn, it worked.
>
> For referen
Ticket created here: http://trac.osgeo.org/grass/ticket/1713
Thanks,
P
2012/8/31 Glynn Clements :
>
> Pierre Roudier wrote:
>
>> I still got the same problem - I'm happy to use the workaround and
>> edit the Platform.make file by hand, but should I lodge a bu
Hi Markus,
Here is my configure script for grass_trunk on (X)ubuntu 12.04:
./configure --enable-64bit--with-libs=/usr/lib64 \
--with-cxx \
--with-readline \
--with-freetype=yes --with-freetype-includes="/usr/include/freetype2/" \
--enable-largefile=yes \
--with-proj-share=/usr/share/pro
Hi all,
This might be very simple, but I can't find an answer in the doco - so
here I am,
I'm trying to pass several floats to a single option in a Python script:
> python my.module.py input=input output=output myoption=0.1,0.2,0.5
Is there a clever way to declare myoption so that it would pars
Thanks all for the trick,
> Added to
> http://grass.osgeo.org/wiki/GRASS_Python_Scripting_Library#Parsing_the_options_and_flags
Perfect place for it I reckon,
Pierre
--
Scientist
Landcare Research, New Zealand
___
grass-dev mailing list
grass-dev@li
Hi all,
FYI I just submitted my (first!) GRASS add-on, called v.what.rast.multi [0].
It is a super simple Python wrapper around v.what.rast, and allows to query
a suite of rasters in one go:
v.what.rast.multi map=mygeodetic_pts raster=elev_state_500m,slope,aspect
columns=elevation,slope,aspect
I guess I probably should have added the URL:
https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.what.rast.multi
Apologies!
On 8 May 2017 at 17:16, Pierre Roudier wrote:
> Hi all,
>
> FYI I just submitted my (first!) GRASS add-on, called v.what.rast.multi
> [0].
Done -- thanks for the heads-up Moritz!
On 8 May 2017 at 23:05, Moritz Lennert wrote:
> On 08/05/17 07:16, Pierre Roudier wrote:
>
>> Hi all,
>>
>> FYI I just submitted my (first!) GRASS add-on, called v.what.rast.multi
>> [0].
>>
>> It is a super sim
Thanks Luca, that would be a good idea indeed!
Any pointers to implement this? I'm unfamiliar with parallel processing in
Pygrass.
Cheers,
P
On 9 May 2017 at 18:36, Luca Delucchi wrote:
> On 8 May 2017 at 07:16, Pierre Roudier wrote:
> > Hi all,
> >
>
> Hi,
>
it to the grass addon
> repository. I might do that later, at which point we can also see if it
> makes sense to merge the two.
>
> Cheers,
>
> Paulo
>
>
> On 5/9/17 8:36 AM, Luca Delucchi wrote:
>
>> On 8 May 2017 at 07:16, Pierre Roudier wrote:
>>
Hi,
I've been compiling the geoPAT extensions for GRASS from
http://sil.uc.edu/gitlist/geoPAT/
At the time I was running GRASS 7.2.2 installed from the Ubuntu GIS
repository, but since this repo updated to GRASS 7.4, I have the following
issue:
GRASS 7.4.0 (modis_lst_2015):~ > p.sig.polygons --h
ot;finding" the old source code / headers? Is there a
> package for both GRASS binaries and development files?
>
> Dylan
>
>
> On Thu, Feb 22, 2018 at 7:28 PM, Pierre Roudier
> wrote:
> > Hi,
> >
> > I've been compiling the geoPAT extensions for GRA
> On Fri, Feb 23, 2018 at 1:10 PM, Pierre Roudier
> wrote:
> > Thanks Dylan,
> >
> > I did install using `sudo sh install.sh grass72` -- then `sudo sh
> install.sh
> > grass74` after my Grass version got updated to 7.4
> >
> > Cheers,
> &
ready defined.
>
> 3) I don't know how to contribute to the geoPAT repository.
>
> Best,
> Vaclav
>
>
>
> On Fri, Feb 23, 2018 at 6:22 PM, Dylan Beaudette <
> dylan.beaude...@gmail.com> wrote:
>
>> How about your GRASS "development" files:
Roudier wrote:
> Ticket created here: http://trac.osgeo.org/grass/ticket/1713
>
> Thanks,
>
> P
>
> 2012/8/31 Glynn Clements :
> >
> > Pierre Roudier wrote:
> >
> >> I still got the same problem - I'm happy to use the workaround and
> >
e missed?
Cheers,
Pierre
On 26 February 2018 at 16:53, Vaclav Petras wrote:
>
>
> On Sun, Feb 25, 2018 at 10:41 PM, Pierre Roudier > wrote:
>
>> Hi Vaclav, and thank you so much for your help,
>>
>
> You are welcome.
>
>
>>
>> Do I understand correc
Hi,
Just bumped into the weirdest bug in r.sun on GRASS 7.4 as installed from
the Ubuntu repository.
I am using r.sun in Mode 2 to compute the daily average global radiation.
The GRASS location is using EPSG:3031: this is data over the entire
Antarctica.
For some specific days, that seem to be i
ot; $((DAY)))
echo "Processing day ${DOY} ..."
eval `g.findfile element=cell file="glob_rad_${DOY}"`
if [ ! "$file" ]
then
r.sun elev=dem_1k aspect=aspect_1k slope=slope_1k day=$DAY
glob_rad=glob_rad_${DOY}
sleep 15
fi
done
On 16 Ma
The problem seems to be fixed in the grass7.5-svn I last checked out from
SVN and compiled about 3 weeks ago.
Hum...
On 16 March 2018 at 11:22, Pierre Roudier wrote:
> OK, something additional I noticed: I obviously wrapped the calculations
> for each day of the year in a script.
>
Hi Roberta,
On top of the review linked by Vero, I thought I'd mention the Fmask
procedure -- it seems to give great results and there is a python
library on Github.
*Relevant GRASS GIS tickets*:
https://trac.osgeo.org/grass/ticket/3473
https://trac.osgeo.org/grass/ticket/3283
*Papers*:
https:
hints!
> I have already tested Fmask with Sentinel 2 images but I didn't have great
> results. However, it is worth investigating better!
> Thanks for all the references!
>
> Roberta
>
>
> 2018-05-15 0:51 GMT+02:00 Pierre Roudier :
>>
>> Hi Roberta,
>&
; From: grass-dev On Behalf Of Roberta
> Fagandini
> Sent: onsdag 16. mai 2018 16.01
> To: Pierre Roudier
> Cc: grass-dev
> Subject: Re: [GRASS-dev] GSoC introduction Roberta Fagandini
>
>
>
>
>
> Thank you, Pierre!! I will keep the community constantly updated on
My two cents' worth: it is indeed an issue for beginners, and would be
great to see new term for it, but I would stay away from using
acronyms.
P
On 16 June 2018 at 23:28, Huidae Cho wrote:
> Dear All,
>
> I agree that this terminology needs to be changed. "Project" seems to
> simplify this issu
Hi all,
I am trying to write a little Python extension wrapping r.color to use
different kind of strecthes,
It should be pretty simple, basically just builkding rules on-the-fly
and pass them to r.color. But I can't quite seem how to retrieve the
GRASS color ramps details to create my ruleset.
I
Hi Vero and Markus,
>> I am not sure what to do about this. Disable this safety check again?
> Maybe the bb safety check makes sense for features other than points, dunno.
> Others can for sure tell some use cases that I am not aware of. But I can say
> that it is pretty striking to see that som
78 matches
Mail list logo
