On Wed, 30 Dec 2009, Hamish wrote:
In this case the box created by v.in.region should be an area.
That's what I thought.
Here is an example using the Spearfish sample dataset:
#set to the default region
g.region -dp
# shrink the region in by 6km on all sides
g.region w=w+6000 e=e-6000 n=
Rich wrote:
> I'll try again, both creating the new region as a line rather
> than an area and explicitly setting the operator=and.
In this case the box created by v.in.region should be an area.
Here is an example using the Spearfish sample dataset:
#set to the default region
g.region -dp
#
On Wed, 30 Dec 2009, Rich Shepard wrote:
I'll try again, both creating the new region as a line rather than an
area and explicitly setting the operator=and.
Nuts! I'm still doing it incorrectly.
Using g.region and v.in.region I created a map called 'abernathy' that has
the bounds of the
On Wed, 30 Dec 2009, Hamish wrote:
Unfortunately, mukey is alphanumeric rather than strictly numeric. I
guess this means I need to build a lookup table, or modify the map
attribute table itself. Ah, well.
ok, so v.colors should probably be extended.
as a hackish thought experiment, I wonder
On Wed, 30 Dec 2009, Hamish wrote:
ie g.region + v.in.region?
Hamish,
I believe so; I didn't note the specific sequence and syntax, but I'd have
to have used v.in.region. Probably set type=area rather than line.
Yet running v.overlay like this:
GRASS 6.5.svn (Oregon):/usr4/grassbase > v.
> > you want v.overlay or v.select, not v.patch.
Rich wrote:
> Simple tool, but I somehow messed it up. I get
> either the bmap or a blank display monitor.
...
> I created the map using g.region for the area of
> interest, and named that region 'abernethy'.
ie g.region + v.in.region?
> Yet
Hi Helmut,
Thanks for the reply. Apparently evething is working fine, thanks.
Have happy holidays,
milton
2009/12/30 Helmut Kudrnovsky
> Hi Milton,
>
> >Dear all,
> >
> >I am still trying to compile the grass under Vista/MSYS,
> >and following the instructions available at:
> >
> >
> >When I
Hamish
> > v.colors column=mukey color=random
> > d.vect -a
Rich:
> Unfortunately, mukey is alphanumeric
> rather than strictly numeric. I guess
> this means I need to build a lookup table, or modify the
> map attribute table itself. Ah, well.
ok, so v.colors should probably be extended.
as a
Paolo wrote:
> r.watershed elevation=...@permanent threshold=100
> basin=watershed2
>
> and loading the output through QGIS, I get repeated
> errors:
>
> /home/paolo/Desktop/Dati/grass/Toscana_corso/paolo/cellhd/1000
> is not a valid or recognized raster data source
>
> Is this a local problem,
Paolo wrote:
> If I zoom to a small map full of nulls, with only a
> non-nulla area on one side, and
> zoom back to the full extent, I do not see the difference:
fyi 'g.region zoom=' starts at the current region settings*,
so maybe try:
g.region rast=foo
g.region zoom=foo
* this lets you zoom
On Wed, 30 Dec 2009, Hamish wrote:
or if mukey isn't the cat column:
v.colors column=mukey color=random
d.vect -a
Hamish,
Unfortunately, mukey is alphanumeric rather than strictly numeric. I guess
this means I need to build a lookup table, or modify the map attribute table
itself. Ah, well
Rich wrote:
> I have a map of water bodies
> for the entire state. Yesterday, when I
> re-imported it (correctly), it took about 3 hours to
> complete; most of the
> time was waiting for it to 'break boundaries'.
fyi this is the classic "Florida Coastline" problem.
to work around it, after it is
On Tue, 29 Dec 2009, Hamish wrote:
you want v.overlay or v.select, not v.patch.
Simple tool, but I somehow messed it up. I get either the bmap or a blank
display monitor. I suspect that what I need is the outline of the area used
as the clipping boundary, not a polygon of that area.
I cre
Rich wrote:
> Don't see the answer in the
> man page or wiki so a pointer to the
> information is appreciated.
>
> I have a table of soil mapping units (polygons) and
> one of the columns is
> 'mukey' (map unit key). If I want to display each mukey in
> a different
> color, do I need to pre-de
Don't see the answer in the man page or wiki so a pointer to the
information is appreciated.
I have a table of soil mapping units (polygons) and one of the columns is
'mukey' (map unit key). If I want to display each mukey in a different
color, do I need to pre-define these within the databas
On Wed, 30 Dec 2009, MS wrote:
v.select can be a nice first pass to filter back a substantial amount of
unnecessary data.
Mark,
Thank you. I'll keep this in mind for future clipping.
Rich
___
grass-user mailing list
grass-user@lists.osgeo.org
htt
v.select can be a nice first pass to filter back a substantial amount
of unnecessary data.
Mark
On Dec 30, 2009, at 2:33 PM, Rich Shepard
wrote:
I have a map of water bodies for the entire state. Yesterday, when I
re-imported it (correctly), it took about 3 hours to complete; most
of
On Wed, 30 Dec 2009, Michael Barton wrote:
I'm about to suggest that we scrap the spin box and return to a simple
text box (rather than the long pull-down) and have it validate only
values 1-60.
I concur: it's easier to keep the hands on the keyboard, tab between
widgets, and type the desire
Hi Milton,
>Dear all,
>
>I am still trying to compile the grass under Vista/MSYS,
>and following the instructions available at:
>
>
>When I run ./mswindows/osgeo4w/package.sh
>I get the following error message:
>[...]
>Mon Dec 28 21:56:25 EST 2009: STARTING cleanup
>Mon Dec 28 21:56:26 EST 2009: S
On Dec 30, 2009, at 10:00 AM, grass-user-requ...@lists.osgeo.org wrote:
> Date: Wed, 30 Dec 2009 06:18:58 -0800 (PST)
> From: Rich Shepard
> Subject: Re: [GRASS-user] Cannot Create UTM Location: -6.5svn
> To: grass-user grass-user
> Message-ID:
>
> Content-Type: TEXT/PLAIN; charset=US-
I have a map of water bodies for the entire state. Yesterday, when I
re-imported it (correctly), it took about 3 hours to complete; most of the
time was waiting for it to 'break boundaries'.
Today I'm clipping it to a very small region, one drainage basin and parts
of the surrounding basins,
Hi Paulo,
Have you tried g.region -d ?
ciao
milton
2009/12/30 Paolo Cavallini
> Hi all.
> If I zoom to a small map full of nulls, with only a non-nulla area on one
> side, and
> zoom back to the full extent, I do not see the difference:
> ===
> > g.region zoom=los_175_...@paolo
> > g.region
Hi all.
If I zoom to a small map full of nulls, with only a non-nulla area on one side,
and
zoom back to the full extent, I do not see the difference:
===
> g.region zoom=los_175_...@paolo
> g.region -p
projection: 99 (Transverse Mercator)
zone: 0
datum: rome40
ellipsoid: international
Hi all.
While running:
r.watershed elevation=...@permanent threshold=100 basin=watershed2
and loading the output through QGIS, I get repeated errors:
/home/paolo/Desktop/Dati/grass/Toscana_corso/paolo/cellhd/1000 is not a valid or
recognized raster data source
Is this a local problem, or a gene
Hi all.
While running r.los at increasing values for obs_elev and max_dist, the module
starts
crshing, e.g.:
r.los input=...@permanent coordinate=1676844,4830417 obs_elev=50 max_dist=5000
output=los4
Using maximum distance from the viewing point (meters): 5000.00
Module crashed or killed
Thi
On Tue, 29 Dec 2009, Hamish wrote:
In that case you should double check that if(?) the PROJ_INFO file has a
+lon_0 set, it is set appropriately and not still using the central
longitude from Zone 30...
Hamish,
It doesn't:
name: Universal Transverse Mercator
proj: utm
datum: nad83
ellps: gr
On Tue, 29 Dec 2009, Michael Barton wrote:
Rich, what is your OS?
Linux; Slackware-12.2 with the 2.6.27.7-smp kernel.
I'm about to suggest that we scrap the spin box and return to a simple
text box (rather than the long pull-down) and have it validate only values
1-60.
I concur: it's e
On Wed, 30 Dec 2009, Glynn Clements wrote:
OTOH, it's common for US spellings to be used for computing, even amongst
people who use the UK spellings natively. One notable exception is
wxWidgets, which uses "colour" throughout the API and documentation.
That's true for wxPython, too. I though
Glynn wrote:
> Also: the DEFAULT_WIND and WIND files contain a zone field.
they would, as would (I think) any $MAPSET/cellhd/ files and
perhaps vector equivalent of cellhd, if not for this bug-
https://trac.osgeo.org/grass/ticket/842
Hamish
Glynn wrote:
> The importation won't be affected by the resolution (or the
> bounds),
n.b. r.proj cares.
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
30 matches
Mail list logo
