ized are listed in the grass wiki page.
e.g. r3.in.xyz.
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Hamish wrote:
> for an example of grass.start_command() for parallelizing a bunch
> of r.cost runs, see v.surf.icw(.py) in grass7 addons:
> https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.surf.icw/v.surf.icw.py
Johannes:
> thank you for that example. I think it expl
nt to take a look
> feel free to:
>
> https://gist.github.com/3282580
Hi,
please consider to add this sort of thing to the GRASS wiki. it is very
helpful to have these snippets there.
to mark up python code in the wiki with nice colors:
code goes here
[[
n
python I think.
there's a lot of FAQ and threads out there about the Python Global
Interpreter Lock (GIL) issue which is the reason for that.
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
atial
knowledge to it, and setting a few lines of text in the PROJ_INFO file
is probably a lot simpler and faster than going to the trouble of making
lat and long raster maps to feed to r.sun. The easier solution might also
be the more correct one!
regards,
Hamish
_ullr ulx uly lrx lry:
Assign/override the georeferenced bounds of the output
file. This assigns georeferenced bounds to the output
file, ignoring what would have been derived from the
source file.
use your bbox to fill in
.2. I've got some
.debs for Debian/Squeeze if you want them.
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Hamish wrote:
> so better to try and upgrade to GRASS 6.4.2. I've got some
> .debs for Debian/Squeeze if you want them.
here they are:
http://download.osgeo.org/grass/grass64/binary/linux/debian/squeeze/
if you are running Ubuntu, try adding the UbuntuGIS ppa to your
reposito
ed for, but for the case of a
categorical area map (maybe 'v.to.rast type=area') over a shaded relief
DEM it works quite nicely.
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
the task. See
also the argyle/diamond r.mapcalc overlay trick in the GRASS Book vol.1
(not sure if it is in later editions too).
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
e which is quite nice.
http://youarealegend.blogspot.co.nz/2008_09_01_archive.html
http://downloads.sourceforge.net/project/windrose/
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
the reason why the bug is
> invalid.
...
> I have a clean installation, and in the install tree the file
> "g.html2man" is located in the directory "tools/g.html2man"
> and not directly under "tools".
Hi,
I will have another look with a fresh
lt parcels from Martin's site) e.g. for the debian/ubuntu packages
g.extension(.*) returns a non-fatal warning if the -dev package isn't
installed too, which says "what you are trying to do probably won't work,
this is why, and this is
p' say about the computational region?
in your utm location try 'g.region rast=YOUR_MAP_NAME_HERE'
before running raster modules to set the computational region
to match that map's bounds and resolution.
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
e), so
> I used new = old + 0.1
>
> and then I ran r.slope.aspect again, but my aspect raster
> still shows the artifacts.
maybe something to do with
https://trac.osgeo.org/grass/ticket/1728
?
can you try the r.slope.aspect 'prec=float' option?
does an aspect map ma
d remote; while the UIDs are typically all over the
place due to the heterogeneity/provenance of the system.
I just tried with a local user name different that the remote one, GRASS
all works fine over the sshfs link, no permissions problem since the local
file system now thinks your
fyi--
latest iso can be found here:
http://osprey.ucdavis.edu/downloads/osgeo/gisvm/6.5nightly/
give it a whirl...
-- H
--- On Thu, 1/31/13, Cameron Shorter wrote:
From: Cameron Shorter
Subject: Re: [Live-demo] OSGeo-Live Quickstart 48 hour Hackathon - starts in 30
mins
To: live-demo at lis
there sample data available showing the problem?
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Eric wrote:
> and set the color table to grey for each one.
tip: you might try the grey255 color rules to make sure they are
consistent between bands.
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mail
n think of is in simple examples where I
just wanted any variable with a gradient in it. Come to think
of it, any interger (categorical) to v.surf.rst input has been
pretty rare.
2c,
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
dow or from the wxGUI command
console? There are some issues with the wxGUI command console dealing with
"quotes", there's an active ticket about it.
From the real command line it should be ok; note the "*" pattern
parameter should be quoted to protect
Andranik wrote:
> Good day,I am trying to export raster map to an kml file, to
> overlay on Google Earth.
You might try the r.out.kml script from the GRASS 6 AddOns
repository (with GRASS 6.4).
http://grasswiki.osgeo.org/wiki/AddOns/GRASS_6#r.out.kml
Andranik wrote:
> Good day. I have sent email about this issue several days
> ago, but there is no any answer yet.
see reply here:
http://thread.gmane.org/gmane.comp.gis.grass.user/46152
Hamish
___
grass-user mailing list
grass-user@lists.osg
ny bugs you do find.
thanks,
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
and prompt: `echo $GRASS_ADDONS_PATH`)
The above '/usr/bin/lib/' is clearly trying to build it in the
wrong place, so bypassing the permission problem by running
it with sudo (the -u flag from the command prompt version) is
not advised.
thanks,
Hamish
_
when the overall
DB file gets to be larger than 2gb or 4gb in size.
Even per-mapset sqlite DBs worry me a bit for that, not to mention
the damage-fallout from a bad HD sector or accidental `rm` and
ease of moving stuff to another mapset/ system by hand.
32bit machines, and 2-4gb limit of the
filesystem doesn't seem so far away if those get set to be
cumulative. But I am fairly ignorant of DB issues and sqlite
implementations in particular, so am not really familiar with
what gains you might see from the monolith
Hamish wrote:
> > I thought the question was still up in the air for g7 and
> > for now it was user choosable by the way you constructed the
> > db.connect string.
Michael:
> How can you change the default by
> changing the db.connect string? I'd like to do it.
>
h to look
at the problem of instrument quantization (I'm fairly sure it
isn't, both technically and fundamentally), but it is probably a
job for r.reclass if you really want to do it; or adjust the
multiply by--truncate--divide by r.mapcalc trick abo
lite layers for that map saved in the same file)
"db.sqlite" or "sqlite.db" for the filename?
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
grass6/addons/v.in.ply: 86: [: 0: unexpected
> operator
Hi,
this should be fixed now in svn if you can reinstall it & try again. (untested)
on Ubuntu the default script shell is Dash instead of Bash,
which doesn't like the "a == b" Bashism, so it complains about
Hamish wrote:
> there are a couple ways to do it, here's one:
> r.mapcalc "map.2dp = int(0.5 + (map.15g * 100))/100.0"
>
> the 0.5 is added because int() truncates instead of
> rounding.
mind that if your values go negative, int() and floor() are
not the same..
le. [...] Several
> standard hatching patterns are provide [...]
see also
http://grasswiki.osgeo.org/wiki/AreaFillPatterns#Example_Pattern_files
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
ey work. Can you
> please suggest me a file where there is an example of
> calling another module?
have a look at the functions in lib/gis/spawn.c.
there is also the less portable G_system() to look at in grass6.
you might look at raster/r.
aps within a single Location will share the same map projection.
You can't mix and match (lat/lon uses a radial coordinate system;
simple xy uses a Cartesian one). after importing into a lat/lon
Location (with '-l') be sure to double chec
ild log, it seems that the module was installed
ok, just that the `man` version of the help page failed to
install for some reason, but that is a minor inconvenience.
-> Try running it, does it work? Does 'locate r.out.kml' show it
in your addons dir?
Hamish
to [v.]db.connect so you don't have to
tailor it per map &/or the link survives a g.rename of the map.
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
7;bin'],
'BIN=%s' % dirs['bin'],
'HTMLDIR=%s' % dirs['html'],
'MANDIR=%s' % dirs['man1'],
locally you can edit the /usr/lib/grass64/etc
at it's worth, for shell scripts you can
always just grab them from svn,
https://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.out.kml
put the file somewhere in $GRASS_ADDON_PATH by hand, make sure
it has 'chmod a+x g.modulename' execute perm
Martin Album Ytre-Eide wrote:
> is it possible to bars in ps.map - like you would do in
> v.thematic.chart ?
can you post an image of what you mean?
thanks,
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/m
on you'll
probably have to undertake to compile it from source (which is
not so bad, installing the gdal-dev package will get you most
of what you need).
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Markus Neteler wrote:
> out of curiosity, is there a reason to have it disabled by
> default?
I don't know, but perhaps it is so that the end-of-line connecting
nodes are not lost in the clutter of all of the along-the-way
polyline vertice
useful for point
symbols, and color from rgbcolumn. I'm pretty sure I haven't
coded in the primary/secondary color scheme for symbols that
d.vect uses yet, which will improve the rgbcolumn support
automagically.
Hamish
___
grass-u
Hamish wrote:
> > if you'd like it to be please file a ticket at bugs.debian.org
> > against the grass package &/or if you want quicker action
> > you'll probably have to undertake to compile it from source
> > (which is not so bad, installing the gdal-dev pac
stline
problem".
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
on is written to the mapset dir, not real $HOME. Using
that, the above g.cd could be simplifiled to:
alias g.home='cd `dirname "$HISTFILE"`'
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
ng this to ~/.inputrc is much
nicer to use than ^r,
# Bind page up/down wih history search -
"\e[5~": history-search-backward
"\e[6~": history-search-forward
type the first few letters, then PgUp to see earlier matches..
hoping the recent work on command lin
Hamish wrote:
> firstly, you can add this to ~/.grass.bashrc:
>
> g.cd()
> {
> MAPSET=`g.gisenv get=MAPSET`
> LOCATION_NAME=`g.gisenv get=LOCATION_NAME`
> GISDBASE=`g.gisenv get=GISDBASE`
> LOCATION="$GISDBASE/$LOCATION_NAME/$MAPSET"
> cd "$LO
Martin wrote:
> cool, as Vaclav noted please add such useful notes on the wiki.
done @ http://grasswiki.osgeo.org/wiki/GRASS_and_Shell
> Otherwise it will be lost in ML jungle.
"the distributed backup method" ;)
Hamish
___
grass-u
Hi,
missing function definitions added in svn with r55235 & now it builds. I'll
leave the other compiler warnings for the authors to look at ...
Hamish
--- On Tue, 2/26/13, Moskovitz, Bob@DOC
wrote:
From: Moskovitz, Bob@DOC
Subject: Re: [GRASS-user] Geomorphons and extension m
urface area, use r.plane or like
r.mapcalc "constmap = 100"
and load a second raster surface in NVIZ's raster controls.
You can also set its transparency level to make it translucent
for a nice see-through effect.
3D vector faces may work as well, but they are not as mature.
Hamish
or point instruction there with appropriate rotation
angle. You'll probably need to make your own symbol, but that's
pretty easy.
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
ons with yet more #ifdefs.
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Eric wrote:
> The command used to run r.contours:
> grass.run_command("r.contour", input=lp_subtract,
> output=LP_contour, minlevel=0, maxlevel=0, step=10)
minlevel and maxlevel are the same?
Hamish
___
grass-user mail
Eric wrote:
>>> The command used to run r.contours:
>>> grass.run_command("r.contour", input=lp_subtract,
>>> output=LP_contour, minlevel=0, maxlevel=0, step=10)
Hamish:
>> minlevel and maxlevel are the same?
Eric:
> Yes, only the zero contours are
ct' or by writing a little script to
change/replace the mapset's VAR file.
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
ass.osgeo.org/grass64/manuals/r.what.html
note that r.what can take multiple rasters and multiple point-
values as input, all in one pass, to make a table.
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Hamish wrote:
> > #define DB_DEFAULT_DRIVER "dbf"
> > to be
> > #define DB_DEFAULT_DRIVER "sqlite"
Vincent wrote:
> I'll give it a try.
> Is this statement sufficient to turn db-file sub-directory
> name to :
> $GISDBASE/$LOCATION_NAME/$M
e we should look at raw png/ppm
frames + the option to system() call the webm encoder on them
as a simpler and more robust alternative.
[*] fwiw Debian has just dropped ffmpeg for the more stability-
focused libav fork, for the same endless api-catch-up reasons.
good luck,
Hamish
___
that the code you
wrote for 6.4.2 should work for all future 6.4.x without
needing any changes. The bad news is that whoever built 6.4.3
on that system will have to rebuild/replace it with a version
of 6.4.3(rc/svn) that was built with support for the Postgres
optional extra.
Hamish
__
on to trigger
reading input stdin. (or else stalled module gui headaches..)
perhaps this needs to be changed to YES?
input->required = NO;
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
topologically ok.
they are just simple boxes drawn around all nodes.
see {D|G}_plot_icon() at the end of d.vect/topo.c
https://trac.osgeo.org/grass/browser/grass/trunk/display/d.vect/topo.c#L75
Hamish
___
grass-user mailing list
grass-user@lists.osge
Tom wrote:
> I would recommend a combination of GRASS and R (http://cran.r-
> project.org/). R has fuzzy K-mean cluster capability, using
> the R addon package spgrass6 to read/write to/from GRASS and R.
see Roger's tutorial here:
http://grasswiki.osgeo.org/wiki/R_stati
the grass wiki, + added expanded it a
bit too (viz. field deployment of GRASS as an embedded platform). see
http://grasswiki.osgeo.org/wiki/Raspberry_Pi
I don't actually have one of these gizmos, so my contributions are pretty much
"by ear"; I think it's ok but pl
> weeks now and this has never been an issue. As far as
> I can tell, I haven't made any changes to the grass
> installation, nor to the underlying data on which the mask
> has been based.
>
> Ideas? How can I begin to troubleshoot this?
what does 'g.region -p
ses more on the analysis of LiDAR data (which is what
will give you answers instead of just the pretty pictures :)
see also www.liblas.org
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Richard:
> I can remove the duplicate centroids with v.clean (using
> bpol) but not the centroids outside area.
>
> What would be the easiest way to remove, or at least to
> identify (filter for) and manually assess?
perhaps v.extract, to pull only the
Richard:
> > I can remove the duplicate centroids with v.clean (using
> > bpol) but not the centroids outside area.
> >
> > What would be the easiest way to remove, or at least to
> > identify (filter for) and manually assess?
Hamish:
> perhaps v.extract, t
/ticket/1803)
Also, you might need to install this:
http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
ct there.
note if you want the v.mkhexgrid script to run in g7 you should
check for a grass7 addons version of it. (or minor changes may
be required to adjust for any changed options)
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
finds another number the way glibc funtions or awk
might. An offshoot of this (mostly for importing .csv tables
from spreadsheets with v.in.ascii) is that empty data columns
are supported as containing NULL, and not messing up the placement
of columns to the right.
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
er resolution? 20000x20000
region size is known to work ok. anything bigger than about
45000x45000 gets into 64 bit/LFS territory.
Hamish
ps- 'g.region res=0.2 -a' will clean up/round off the messy
resolution value, if you like.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
93080.00 293990.00
y: 5548130.00 5549990.00
z: 256.851000 426.24
then import worked well using a 10m grid resolution.
(grid resolution confirmed by running r.univar on the method=n
map + 'r.null setnull=0')
Hamish
___
grass-user
Hamish:
>> since v.mkhexgrid is just a python script, you can just
>> download it by hand and put it somewhere in your path.
Giovanni:
> that's what I did, even before trying with a self-compiled
> 6.4.3RC2, but I cannot find the extension under the GUI menus
I think suppo
changing the resolution to 0.5 but I still have
> the same issue
> ... I will still investigate. Any clue/idea would be
> appreciate.
try watching the process in `top` in a Terminal window to
see how much memory it uses, and keep going and try changing
the region res= to be as coarse as 5m.
smoother on UNIX (Linux/Mac/...), but we're trying
to level the playing field as fast as we can. There are still a
few rough edges on Windows, but it's getting much closer.
good luck,
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
amed libraries.
The whole (re)package building exercise should be possible with
a simple 2-10 line script.
regards,
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Hamish wrote:
> > the first thing that should happen is that the control files
> > should be updated to pull from the latest from the DebianGIS
> > git repository.
Tim:
> 2 points where this is not always possible:
> * your repo is at grass (6.4.2-3), we are talking about
ime or RAM limit. Do you have
that fine of a DEM anyway? LiDAR often being binned to 2m cell
size,..
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Hamish wrote:
> by my calcs, a 6x6 cell region would want ~64gb RAM.
and your 0.2m resolution run would want ~94gb RAM.
To fit in 5.8gb RAM you could have about max 17860x17860 region
size. I see your region bounds are 15607m x 13492m, so 1m cell
resolution would fit well, and proba
an interesting module, an improvement on
r.param.scale's "feature" method.
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
please post in plain text, as often the HTML gets lost along
the way, many people don't get to see what you wrote, and the
archives don't either:
http://lists.osgeo.org/pipermail/grass-user/2013-April/067939.html
http://thread.gmane.org/gmane.comp.gis.grass.user/47096
thanks,
Hamish
or
still in development, AFAIK by placing the module in the
../Makefile the developer is announcing that it is fit for
human consumption.
thanks,
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
such file or directory
> Received EXIT message from GUI.
that should be /usr/lib/grass70/etc/ not /grass/?
Did the version number extract part of the build "rules" script
work? maybe it collapsed to an empty string.
Hamish
___
gra
witching between minor
versions. (e.g. it's been more than a year since it changed
last)
> * shall we instead of grouping by command type group by
> version?
an addon package containing grass7 addons should exclusively
depend on the grass7-core package etc. so at minimum it must
be grou
he main ubuntu one?
I wouldn't pollute the main one with our ppa experiments, but
keep it clean for problems in the official packages.
?
(not really sure how the whole ppa integration works)
thanks,
Hamish
___
grass-user mailing list
grass
here:
http://joerichards.dev.openstreetmap.org/files.html
but it is complete and ready for loading into PostGIS with
osm2pgsql.
more info at http://wiki.openstreetmap.org/wiki/LINZ
coordination of efforts is done on the NZOpenGIS google group.
regards,
Hamish
nny epsgish code for the google mercator
#
<900913> +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0
+y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs <>
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
ht
(which
isn't perfect either, as GRASS's projection def'ns can contain
more detail than +proj terms know how to express)
Defining new SRS codes as anything more than a quick hack is
simply wrong.
trying to save some later grief,
Hamish
ds set to the extent of
all maps (maybe you know that area already) you can use the
r.patch module to combine them all into a single map.
have fun,
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
ample'
...
> Is this all ok?
yes, it looks like it all went ok.
best,
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
ate systems. One way to solve the null-value issue
> would be to impose an r.what check, but this does not seem
> to be very elegant way to do it.
> Any suggestions?
r.out.xyz does just that.
Hamish
___
grass-user mailing list
grass-user@lists.
(at the bottom) DMS vs DEG +
precision.
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
3.5M points is on the limit of the number of vector points you
can work with in GRASS 6 with full topology and database tables
unless you have a computer with lots of RAM. (thus options to
disable first database creation and second topology)
Hamish
___
g
r a hint on adding temporary swap space on Linux
if you need it.
r.in.xyz can handle many billions of points without trouble for
non-exotic statistical aggregations; memory use there is more a
matter of raster region size and you can do multi-pass if memory
is an issue on a really really huge regio
lso try using "fontsize 12" or so, the default with v.labels
is to size the font by map units (to allow e.g. small towns to
dissapear as you zoom out), but if you mistake the size setting
for fontsize, you letters are e.g. 12m tall on a grid of
er of the composer not knowing anything
about labels (yet). It still doesn't know about all the things
that the ps.map back-end can do. But you don't need the composer
to render, just run ps.map manually with your .psmap input rules
file.
Hamish
_
le has not been fully ported to grass 7
yet. try it in GRASS 6.
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
mpty?
that file ships with the qgis-plugin-grass-common .deb package.
(in this case a self-built pkg, but unchanged from upstream)
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
ivar
density. typically I just do this by eye/educated guess
depending on the dataset.
then run the hole-filling interpolation.
finally the new buffer becomes a raster MASK (see r.mask),
I use "r.mapcalc interp.cropped = interpolated" to create a
new m
801 - 900 of 2230 matches
Mail list logo
