o sh install.sh
> grass74` after my Grass version got updated to 7.4
>
> Cheers,
>
> P
>
> On 23 February 2018 at 18:41, Dylan Beaudette <dylan.beaude...@gmail.com>
> wrote:
>>
>> Howdy Pierre!
>>
>> In my experience, the GeoPat modules need to k
Howdy Pierre!
In my experience, the GeoPat modules need to know where several things
are located, including (I think) parts of the GRASS source code. Have
a look through the install.sh code:
http://sil.uc.edu/gitlist/geoPAT/blob/stable/install.sh
I was able to get these modules up and running
On Mon, Oct 19, 2015 at 12:45 PM, Glynn Clements
<gl...@gclements.plus.com> wrote:
>
> Dylan Beaudette wrote:
>
>> I can now verify that t.rast.mapcalc is creating some raster maps with
>> corrupt (?) data. Corrupt in the sense that subsequent reading of the
>> m
>
> name
>
> or
>
> name | start
>
> or
>
> name | start | end
>
> do not put an additional separator at the end of the line, since this
> will confuse the simple parsing approach in t.register.
>
> Best regards
> Soeren
>
> 2015-10-14 19:26 G
On Wed, Oct 14, 2015 at 9:45 PM, Dylan Beaudette
<dylan.beaude...@gmail.com> wrote:
> On Wed, Oct 14, 2015 at 12:55 PM, Dylan Beaudette
> <dylan.beaude...@gmail.com> wrote:
>> On Wed, Oct 14, 2015 at 10:50 AM, Dylan Beaudette
>> <dylan.beaude...@gmail.com&
large set of maps are supplied as input, and, a region that has a
moderate number of total cells.
Yeah, I know, that isn't very specific. I will try re-compiling with
debugging and no optimization next.
Dylan
On Wed, Oct 14, 2015 at 9:55 AM, Dylan Beaudette
<dylan.beaude...@gmail.com> wrote
and indeed I can replicate
this behavior on my machine. I am using r66489.
Can you reproduce the behavior as described in my original posting,
when using a file specifying the start date _and_ and arguments: "-i
increment='1 days'" ?
Thanks!
Dylan
> I'm using r66429
>
> HTH,
On Tue, Oct 13, 2015 at 11:58 PM, Moritz Lennert
<mlenn...@club.worldonline.be> wrote:
> On 13/10/15 20:43, Dylan Beaudette wrote:
>>
>> Dangit... This is strange, just did an 'svn up', make distclean, make,
>> make install, and now this:
>>
>> Welcome to
On Wed, Oct 14, 2015 at 10:50 AM, Dylan Beaudette
<dylan.beaude...@gmail.com> wrote:
> Some additional clues:
>
> The original stack was 365 maps with 3105 x 7025 cells.
>
> 1. zooming into a smaller region (30 x 40 cells) and running
> t.rast.series 100x resulted in 100 &
On Wed, Oct 14, 2015 at 12:55 PM, Dylan Beaudette
<dylan.beaude...@gmail.com> wrote:
> On Wed, Oct 14, 2015 at 10:50 AM, Dylan Beaudette
> <dylan.beaude...@gmail.com> wrote:
>> Some additional clues:
>>
>> The original stack was 365 maps with 3105 x 7025 ce
On Tue, Oct 13, 2015 at 4:25 PM, Dylan Beaudette
<dylan.beaude...@gmail.com> wrote:
> On Tue, Oct 13, 2015 at 11:06 AM, Markus Neteler <nete...@osgeo.org> wrote:
>>
>> On Oct 13, 2015 7:01 PM, "Dylan Beaudette" <dylan.beaude...@gmail.com>
>>
One more piece of data:
This error only occurs when using "method=sum". I have not encountered
this error when using any of the other methods available to r.series
or t.rast.series.
Dylan
On Tue, Oct 13, 2015 at 10:00 AM, Dylan Beaudette
<dylan.beaude...@gmail.com> wrote:
> H
Hi Markus,
GRASS version information:
./configure --without-odbc --without-mysql --with-readline
--with-cxx --enable-largefile --with-freetype
--with-freetype-includes=/usr/include/freetype2 --with-sqlite
--with-python --with-pthread --with-geos=/usr/local/bin/geos-config
--without-opencl
On Tue, Oct 13, 2015 at 11:55 AM, Markus Neteler <nete...@osgeo.org> wrote:
> On Tue, Oct 13, 2015 at 8:43 PM, Dylan Beaudette
> <dylan.beaude...@gmail.com> wrote:
>> Dangit... This is strange, just did an 'svn up', make distclean, make,
>> make install, and now th
-24 16:54:05 -0800 (Tue, 24 Feb 2015)
Has it been so long since I have compiled GRASS that I have missed
something? I see that the libgis is still "old".
?
Dylan
On Tue, Oct 13, 2015 at 11:06 AM, Markus Neteler <nete...@osgeo.org> wrote:
>
> On Oct 13, 2015
istic pattern.
Strangely enough, the errors are more frequent during the morning
hours vs. afternoon hours!
# sum GDD for this year: fast from SSD, but only single CPU thread
t.rast.series --o --q in=gdd out=gdd_$year method=sum
Thanks,
Dylan
On Tue, Oct 13, 2015 at 1:04 AM, Moritz Le
On Tue, Oct 13, 2015 at 11:06 AM, Markus Neteler <nete...@osgeo.org> wrote:
>
> On Oct 13, 2015 7:01 PM, "Dylan Beaudette" <dylan.beaude...@gmail.com>
> wrote:
>>
>> Hi Markus,
>>
>> GRASS version information:
>>
>> ./conf
Hi,
I recently notices something when working with t.register and a large
collection of daily files. My typical work-flow is something like
this:
# make some data
r.mapcalc expression="prec_1 = 100"
r.mapcalc expression="prec_2 = 200"
r.mapcalc expression="prec_3 = 300"
r.mapcalc
On Tue, Oct 13, 2015 at 11:06 AM, Markus Neteler <nete...@osgeo.org> wrote:
>
> On Oct 13, 2015 7:01 PM, "Dylan Beaudette" <dylan.beaude...@gmail.com>
> wrote:
>>
>> Hi Markus,
>>
>> GRASS version information:
>>
>> ./conf
ote:
> Hi Dylan,
> r.series is a module implemented in C with no relations to r.mapcalc.
> t.rast.series is a Python module that makes use of r.series internally.
>
> Best regards
> Soeren
>
> 2015-10-13 21:06 GMT+02:00 Dylan Beaudette <dylan.beaude...@gmail.com>:
>
Hi,
Over the last couple of years I have noticed a very strange raster
corruption (?) issues when using r.series, and now more recently,
t.rast.series. Typically, I'll generate a large number of maps with
r.sun or t.rast.mapcalc and then aggregate the series with r.series or
t.rast.series. About
Thank you guys, this has been an ongoing issue for me for the last
year or two. I have experienced this error sporadically but could not
recreate it and thus figured it was something specific to my machine.
I noticed this error when using r.series and some of the new temporal
modules-- in each
+1 on the wiki documentation.
On Tue, Jul 9, 2013 at 10:14 PM, Martin Landa landa.mar...@gmail.comwrote:
Hi Tim,
2013/7/5 Tim Bailey timi...@gmail.com:
This week I worked on the voxel assignment operator for my module. I
also
explored the possibility of using a priori assigned
On Mon, Jun 24, 2013 at 10:25 AM, Tim Bailey timi...@gmail.com wrote:
Hi Pierre, and Hamish
It is nice to hear about the onset of Winter in New Zealand. Here in
California we are looking at the beginning of a severe season of drought.
Hi Tim, nice to see another person from CA on the
On Mon, Jun 24, 2013 at 1:23 PM, Benjamin Ducke bendu...@fastmail.fmwrote:
Hi All,
First of all, I am very excited to see how much interest this
project is getting, and it is great that Tim has already got the
support of so many soil science professionals. This will ensure
that the results
On Sunday, December 18, 2011, Markus Neteler wrote:
On Sun, Dec 18, 2011 at 12:07 PM, Markus Metz
markus.metz.gisw...@googlemail.com wrote:
On Wed, Nov 30, 2011 at 10:24 PM, Dylan Beaudette
debeaude...@ucdavis.edu wrote:
Just noticed a nasty bug when using v.db.dropcolumn and v.db.join
On Friday, December 02, 2011, Markus Metz wrote:
On Fri, Dec 2, 2011 at 5:36 AM, Dylan Beaudette
dylan.beaude...@gmail.com wrote:
On Thu, Dec 1, 2011 at 1:25 AM, Markus Metz
markus.metz.gisw...@googlemail.com wrote:
Dylan Beaudette wrote:
Just noticed a nasty bug when using
+1 from me, looking forward to using r.viewshed on some massive maps-
would be nice to have it in the standard install of GRASS.
Dylan
On Thu, Dec 1, 2011 at 12:52 PM, Hamish hamis...@yahoo.com wrote:
Markus Neteler wrote:
how about replacing r.los with r.viewshed?
I'm supportive of that,
On Thu, Dec 1, 2011 at 1:25 AM, Markus Metz
markus.metz.gisw...@googlemail.com wrote:
Dylan Beaudette wrote:
Just noticed a nasty bug when using v.db.dropcolumn and v.db.join with a
sqlite back-end. This seems to happen whenever a table is modified using the
'coltypes' as reported by the GRASS
Just noticed a nasty bug when using v.db.dropcolumn and v.db.join with a
sqlite back-end. This seems to happen whenever a table is modified using the
'coltypes' as reported by the GRASS-DB API:
Here are the coltypes reported from a vector newly imported
On Friday, November 04, 2011, Glynn Clements wrote:
Dylan Beaudette wrote:
however my futile attempt has resulted in a segfault. The tail end
of which looks like:
Any tips?
Compile with debug info and without optimisation:
make clean
make CFLAGS=-g build.log
Pay
Hi,
I have started tinkering around with porting some radio propagation tools
(http://commsys.ijs.si/en/software/grass-raplat) to GRASS 7... However, I have
run into a wall. Is there any documentation on the general approach for
porting code from GRASS6 - GRASS7 ? I have tried following along
On Thu, Jul 28, 2011 at 9:00 PM, Glynn Clements
gl...@gclements.plus.com wrote:
Dylan Beaudette wrote:
With this morning's SVN from GRASS 6.5 and 7, I am getting a strange
error on the configure step:
checking for cairo_create... no
configure: error: *** Unable to locate
On Fri, Jul 29, 2011 at 8:34 AM, Dylan Beaudette
dylan.beaude...@gmail.com wrote:
On Thu, Jul 28, 2011 at 9:00 PM, Glynn Clements
gl...@gclements.plus.com wrote:
Dylan Beaudette wrote:
With this morning's SVN from GRASS 6.5 and 7, I am getting a strange
error on the configure step
With this morning's SVN from GRASS 6.5 and 7, I am getting a strange
error on the configure step:
export NAD2BIN=/Library/Frameworks/PROJ.framework/Programs/nad2bin
./configure \
--without-motif --without-glw --without-odbc --without-cairo \
--with-opengl=aqua --enable-sysv --with-x --with-cxx \
On Wednesday, April 27, 2011, Hamish wrote:
Dylan wrote:
Nice work!
cheers
I had been thinking about using this type of graphic to
describe the potential movement of water/sediment flux along
landscape gradients for some time now...
With a little bit of tinkering around, I was
Nice work!
I had been thinking about using this type of graphic to describe the potential
movement of water/sediment flux along landscape gradients for some time now...
With a little bit of tinkering around, I was able to get a figure that matched
my mental picture:
On Tue, Apr 12, 2011 at 10:55 PM, Hamish hamis...@yahoo.com wrote:
Hi,
is there any reason not to exit with a fatal error if the user tries to
run v.to.db option=azimuth from a lat/lon location? (the result is
useless)
an alternative is to use libproj to calculate forward and backward
I agree with Hamish on this as well. Please add the suggested
warnings. Perhaps we can provide and link, and/or condensed summary of
the following wikipedia article:
http://en.wikipedia.org/wiki/How_Long_Is_the_Coast_of_Britain%3F_Statistical_Self-Similarity_and_Fractional_Dimension
Thanks,
python is the
future? Therefore, would it make sense to replace the sh version in GRASS65
with a modified version of the python script from GRASS7?
Dylan
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
with the mac and
windows installers. I had the opportunity to introduce 2 new users to GRASS,
and both were very impressed with the current rendition of GRASS64.
Great Job!
Dylan
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
Hi,
Not to my knowledge, but you should check out the reading GRASS data
into R. Once you have done that, just about every known algorithm
known to mankind is available to you, granted it fits into memory.
Also see the 'raster' package for R, for working with massive raster
collections.
Cheers,
appropriate.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
These also work out well for my thesis work (land cover
classification), which gives me extra motivation. ;)
~Seth
Hi,
I think that it sounds like a great idea. Have any ideas on how to keep double
precision when working with the GPU?
Cheers,
Dylan
--
Dylan Beaudette
Soil Resource Laboratory
http
://www.public.asu.edu/~cmbarton
On Dec 16, 2009, at 10:18 AM, Dylan Beaudette wrote:
On Wednesday 16 December 2009, Michael Barton wrote:
Do you have Python 2.5? Other version?
Michael
using python 2.5
Dylan
__
C. Michael Barton
Director, Center for Social
that d.erase wasn't yet
supported.
I like the idea here, but the speed of rendering is far too slow for standard
usage.
Cheers,
Dylan
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
On Tuesday 15 December 2009, Michael Barton wrote:
Hi Dylan,
Thanks very much for trying this out. A few responses below.
On Dec 15, 2009, at 12:07 PM, Dylan Beaudette wrote:
Hi Michael,
I applied the patch, and it almost works. After running a command, I am
not presented with a new
+b1
python-wxgtk2.82.8.7.1-2+b1
wx2.8-headers 2.8.7.1-2+b1
Cheers,
Dylan
Phone: 480-965-6262
Fax: 480-965-7671
www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu
On Dec 15, 2009, at 4:49 PM, Dylan Beaudette wrote:
On Tuesday 15 December
aren't registered.
Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
Greetings,
We are trying to calculate hydrologic connectivity for a 33ha catchment based
on a an interpolated raster from a series of 100 spatially distributed soil
moisture measurements. Ideally, we would like to use the methods outlined (in
pseudo-code) here:
University
Phone: 480-965-6262
Fax: 480-965-7671
www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu
___
grass-user mailing list
grass-u...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Dylan Beaudette
Soil
.
A thread from last year on this topic:
http://www.mail-archive.com/grass-dev@lists.osgeo.org/msg01925.html
Hopefully things have improved since then!
Cheers,
Dylan
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.74.7341
2009/9/2 Anne Ghisla a.ghi...@gmail.com:
Il giorno mer, 02/09/2009 alle 07.30 -0400,
grass-dev-requ...@lists.osgeo.org ha scritto:
Greetings,
I am attempting to use the v.krige.py extension with RC 5 by testing
it with 20,000 points that it is trying to allocate 3 gigabytes of
memory for
. I really like the mini-images next to the color scheme
name.
Dylan
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
___
grass-dev mailing list
grass-dev@lists.osgeo.org
On Mon, Aug 3, 2009 at 1:25 AM, Moritz
Lennertmlenn...@club.worldonline.be wrote:
On 02/08/09 04:38, Helena Mitasova wrote:
I very much agree with Markus on this -
Helena
I do too. Although I like where the WX-GRASS GUI is heading, it is
still to cumbersome for (my) daily usage. I am not
modules
from the top-level directory. Nice!
Cheers,
Dylan
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http
MODULE_TOPDIR=$HOME/grass_source_code/ install
done
Cheers,
Dylan
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http
/i.pr_sites_aggregate'
Any ideas, or suggestions on further information I can provide that would
help?
Cheers,
Dylan
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
___
grass-dev
[mailto:grass-dev-boun...@lists.osgeo.org]on Behalf Of Dylan Beaudette
Sent: Tuesday, July 28, 2009 10:08 AM
To: grass-dev@lists.osgeo.org
Subject: [GRASS-dev] erorrs compiling i.pr modules
Hi,
Just updates to today's GRASS65-SVN, and checked out the
grass-addons SVN
tree. I was able
between tables and attributes?
Any idea? Can I use sql query to interview two tables in the
same time?
What is the database back-end? As far as I know, you cannot use update
statements like this with the DBF back-end.
Dylan
--
Dylan Beaudette
Soil Resource Laboratory
http
$
$Date: 2009-05-10 04:34:32 -0700 (Sun, 10 May 2009) $
v.delaunay -l in=archisites out=t
d.vect t col=red
d.vect archsites icon=basic/box size=8
attached is the output.
Cheers,
Dylan
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California
Very Nice work. Is this an extension to ps.map, or something new? Can
you elaborate on the intermediate format-- is it completely
vector-based?
Cheers,
Dylan
On Sat, Jun 6, 2009 at 9:08 AM, E. Jorge Tizadoejtiz...@ono.com wrote:
Hi all,
I present two new features in ps.output (soon in
into the discussion of time-series modeling
that came up on the list a while back?
any details?
Cheers,
Dylan
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
___
grass-dev
On Monday 11 May 2009, C Michael Barton wrote:
Hi Dylan,
Thanks for your input on the types of joins you do. This is very useful.
On 5/11/09 11:03 AM, Dylan Beaudette debeaude...@ucdavis.edu wrote:
Note that one database per vector file, as we now have with the more
limited dbf format
datatypes would help address this problem.
Dylan
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org
On Wed, Apr 15, 2009 at 11:02 PM, GRASS GIS t...@osgeo.org wrote:
#507: CSV output option for r.report
--+-
Reporter: dylan | Owner: grass-...@lists.osgeo.org
Type: enhancement | Status: new
On Wednesday 15 April 2009, Moritz Lennert wrote:
On 15/04/09 19:22, Dylan Beaudette wrote:
On Wednesday 15 April 2009, GRASS GIS wrote:
#73: r.out.gdal tiff output does not work
--+-
--- - Reporter: helena
On Wednesday 15 April 2009, Glynn Clements wrote:
Dylan Beaudette wrote:
3. Allow the user to specify what they would like NULL cells encoded as.
Unless I am overlooking something, it would seem reasonable to export a
CELL map to a signed integer format, and use some obvious negative value
% ]
PC4 33.01 (-0.1768, 0.0165, 0.4083,-0.1576, 0.4396,-0.7640) [ 0.5888% ]
PC5 20.75 (-0.6063,-0.2610, 0.6087, 0.1795,-0.3255, 0.2357) [ 0.3701% ]
PC6 4.25 ( 0.5565,-0.7986, 0.2186, 0.0583, 0.0255,-0.0265) [ 0.0759% ]
Markus
That seems like a nice concise approach, I like it.
Dylan
--
Dylan
On Fri, Mar 6, 2009 at 12:18 AM, GRASS GIS t...@osgeo.org wrote:
#518: negative flow accumulation with r.watershed SFD or MFD
--+-
Reporter: dylan | Owner: grass-...@lists.osgeo.org
Type: enhancement
--+
- Comment (by hamish):
works for me.
{{{
/home/dylan/grass/spearfish60/PERMANENT/dbf//bugsites.dbf
}}}
I don't think it makes a difference, but //bugsites.dbf ?
Hamish
Yeah that did look kind strange... is that something I can fix with
db.connect?
Cheers,
Dylan
--
Dylan
0.07639 0.66520 2.48000
Is this just a display/semantics thing?
Dylan
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
___
grass-dev mailing list
grass-dev@lists.osgeo.org
/
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
On Sun, Dec 21, 2008 at 4:22 PM, Michael Barton michael.bar...@asu.edu wrote:
I just updated and compiled today.
r.watershed compiles without problems, but it fails when you try to run it.
It worked OK yesterday. Here is the error from Spearfish.
GRASS 6.4.svn (Spearfish60_test):~ r.watershed
into QGIS 1.0.
Let me know if there is something I can do to make this happen.
Cheers,
Dylan
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
___
grass-dev mailing
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Compiles fine here, on Debian unstable x86, using very recent proj/gdal/etc.
initial use seems to be fine, QGIS runs, etc.
Dylan
--
Dylan Beaudette
Soil Resource Laboratory
http
On Mon, Dec 15, 2008 at 4:48 AM, Markus Metz
markus.metz.gisw...@googlemail.com wrote:
Hamish wrote:
Glynn:
Is #73 actually a bug, or simply noting that programs which
claim to support TIFF invariably only support a (usually
unspecified) subset of the TIFF standard?
It's really a bug.
On Sun, Dec 14, 2008 at 9:41 AM, Markus Neteler nete...@osgeo.org wrote:
Hi GRASS-devs,
On Sun, Dec 14, 2008 at 5:40 PM, Tim Sutton t...@linfiniti.com wrote:
Hi Marco Markus
What is the plan regarding which version of GRASS will be packaged with
QGIS 1.0? Last I spoke to you I think you
On Sun, Dec 14, 2008 at 6:33 PM, GRASS GIS t...@osgeo.org wrote:
#82: new module: v.to.3d
--+-
Reporter: hamish | Owner: martinl
Type: task | Status: assigned
Priority: major|
On Fri, Dec 5, 2008 at 1:55 AM, Markus Metz [EMAIL PROTECTED] wrote:
I took the request for MFD support in r.watershed by Helena and Dylan to
heart and implemented it, but still need a few more days to clean up the
code, then I want to submit it as r.watershed2.mfd to grass-addons.
A first
On Friday 05 December 2008, Markus Metz wrote:
Dylan Beaudette wrote:
On Fri, Dec 5, 2008 at 1:55 AM, Markus Metz [EMAIL PROTECTED] wrote:
I took the request for MFD support in r.watershed by Helena and Dylan to
heart and implemented it, but still need a few more days to clean up the
code
On Tue, Dec 2, 2008 at 8:20 PM, Helena Mitasova [EMAIL PROTECTED] wrote:
I very much agree with Hamish:
it is really nice to have two independent methods to use race against
each other, and compare the results of. ie apply the scientific method.
Each will have its strength and weaknesses and
. The proposed approach would be much cleaner.
Nice work!
Dylan
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http
On Sunday 09 November 2008, Markus Neteler wrote:
On Mon, Nov 10, 2008 at 6:38 AM, Dylan Beaudette
[EMAIL PROTECTED] wrote:
On Sun, Nov 9, 2008 at 9:26 PM, GRASS GIS [EMAIL PROTECTED] wrote:
#358: new flag for r.quantile to produce output compatible with r.recode
On Sun, Nov 9, 2008 at 9:26 PM, GRASS GIS [EMAIL PROTECTED] wrote:
#358: new flag for r.quantile to produce output compatible with r.recode
--+-
Reporter: dylan| Owner: grass-dev@lists.osgeo.org
Type:
is relatively simple, however some of the matlab-specific matrix operations
may be a challenge.
1. http://dx.doi.org/10.1016/j.cageo.2006.08.009
2. http://www.usyd.edu.au/su/agric/acpa/software/matlab/vqt_matlab.zip
Cheers,
Dylan
--
Dylan Beaudette
Soil Resource Laboratory
http
On Wednesday 05 November 2008, Dylan Beaudette wrote:
Hi,
I was taking another look on a paper published in Computers and GeoSciences
on something called a 'Variance Quadtree' algorithm[1]. The main idea is to
recursively partition an image into smaller and smaller rectangles, based
On Wednesday 05 November 2008, Hamish wrote:
Dylan Beaudette wrote:
The source code for the algorithm is given in Matlab source[2]. I have
tried unsuccessfully to port the code to R, mostly because I do not
completely understand several of the matlab matrix idioms used in the
code.
what
On Wed, Nov 5, 2008 at 7:39 PM, Hamish [EMAIL PROTECTED] wrote:
Dylan Beaudette wrote:
# accumulate new quadrants
# WTF ?
cc = [cc;cord]
Qc=[Qc;Qh]
if cc is matrix, and cord is a matrix, what exactly is
happening?
coord is appended to the end of cc. e.g.:
a = [ 10 20 ]
b = [ 15 25
On Wed, Oct 29, 2008 at 3:00 AM, Markus Neteler [EMAIL PROTECTED] wrote:
On Tue, Oct 14, 2008 at 11:13 AM, Markus Neteler [EMAIL PROTECTED] wrote:
On Tue, Oct 14, 2008 at 8:59 AM, Roger Bivand [EMAIL PROTECTED] wrote:
On Mon, 13 Oct 2008, Dylan Beaudette wrote:
Have the changes in the rgdal
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http
.
Default: 1
}}}
So your use of layer is incorrect.
Also, note that the default of type= is 'line,boundary', so if you are
trying to export areas, you will have to explicitly set type=area.
Closing this bug.
Moritz
OK-- that was my mistake
thanks,
Dylan
--
Dylan Beaudette
Soil
Just checked out develbranch_6 and got this error:
Makefile:22: include/Make/Platform.make: No such file or directory
Makefile:23: include/Make/Grass.make: No such file or directory
make: *** No rule to make target `include/Make/Grass.make'. Stop.
Any ideas?
--
Dylan Beaudette
Soil Resource
On Thursday 09 October 2008, Roger Bivand wrote:
On Tue, 7 Oct 2008, Dylan Beaudette wrote:
On Tue, Oct 7, 2008 at 6:26 PM, Hamish [EMAIL PROTECTED] wrote:
Dylan:
It looks like the limiting factor in this equation is the
code used in v.out.ogr.
Following Dylan's posting on the GDAL list
On Thursday 09 October 2008, Roger Bivand wrote:
On Tue, 7 Oct 2008, Dylan Beaudette wrote:
On Tue, Oct 7, 2008 at 6:26 PM, Hamish [EMAIL PROTECTED] wrote:
Dylan:
It looks like the limiting factor in this equation is the
code used in v.out.ogr.
Following Dylan's posting on the GDAL list
On Tue, Sep 23, 2008 at 7:22 AM, Markus Neteler [EMAIL PROTECTED] wrote:
Hi,
the manual of 6.4 r.colors says:
The rules color table type will cause r.colors to read color table
specifications from standard
input (stdin) and will build the color table accordingly.
r.colors help | grep
think that it is currently done in a very robust way. Also, if the
input vector is not contained within the input raster / current region a
warning is raised and a 0 is written to the z coordinate. Perhaps a different
behavior would be more robust.
Ideas?
Cheers,
Dylan
--
Dylan Beaudette
it makes more
sense to simply default to NaN as the no-data value (the two are
essentially the same concept, so there is no information loss in using
NaN).
Do other software packages understand 'Nan' ?
Dylan
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu
,
Dylan
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
branch.
Cheers,
Dylan
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
1 - 100 of 145 matches
Mail list logo
