On Wed, Jan 7, 2009 at 3:09 PM, A Lanzer wrote:
> Dylan Beaudette-3 wrote:
>> Does anyone know the status of the commands:
>> r.sim.water
>> r.sim.sediment
>> r.simwe
>>
>> in either GRASS54 or GRASS6 ?
In GRASS5 not recommended, in GRASS6 + GRASS7 usable.
> I found these pages on the web.
>
> h
Maris Nartiss wrote:
> > The only trouble this gives me in practice arises when I need to
> > import data created in non-topological GIS (e.g. ArcView Shapefiles)
> > that contains overlapping polygons. Granted, those should not exist
> > in the first place, but bad data quality and faulty topolo
On Tue, Jan 6, 2009 at 2:33 PM, Markus Neteler wrote:
> Dylan,
>
> On Tue, Jan 6, 2009 at 10:01 PM, Dylan Beaudette
> wrote:
>> Hi,
>>
>> For some crazy reason I was under the impression that it is possible to do
>> interpolation with a covariate with v.vol.rst. Are there any examples on how
>> t
Hi list members,
with the help of Markus I managed to add the r.usler module to my
GRASS 6.4 RC1 installation.
I tried the modul with some of my precipitation data and I figured out
that only the first option (roose) for the methods is working. Also
the result I got is strange...
Please h
Dylan Beaudette-3 wrote:
>
> Hi,
>
> Does anyone know the status of the commands:
> r.sim.water
> r.sim.sediment
> r.simwe
>
> in either GRASS54 or GRASS6 ?
>
> i have been drooling over the possiblity of using them...
>
> any help would be appreciated!
>
> --
> Dylan Beaudette
> Soils and
Hello there,
yes this can be seen as a limitation of grass, or more precisely of the
topological data model. But I think one must remind of the strict border
that should lie between geometry and a "semantic" contents.
With a relational database structure you can of course overlap various
characte
Hello,
GRASS vector model is advanced, but sometimes it fails for simple
usage. It's one of best features is also it's point of failure.
Vector areas support in GRASS is built around bogous assumption, that
areas can not overlap. Such assumption holds true for many vector
usages (i.e. property boun
On Wed, January 7, 2009 12:58, Benjamin Ducke wrote:
> Thanks for your clarification, Moritz, that makes perfect sense
> from the data model point of view.
>
> The only trouble this gives me in practice arises when I need to
> import data created in non-topological GIS (e.g. ArcView Shapefiles)
> t
Thanks for your clarification, Moritz, that makes perfect sense
from the data model point of view.
The only trouble this gives me in practice arises when I need to
import data created in non-topological GIS (e.g. ArcView Shapefiles)
that contains overlapping polygons. Granted, those should not exi
[forwarding this to the list for Micha, as it ended up in my mailbox ;)
- Ben]
Thanks for the suggestions. Some additional comments below:
Benjamin Ducke wrote:
> GRASS modules that create area type features should already be generating
> centroids and adding categories to them automatically, sh
On 06/01/09 22:18, Michael Barton wrote:
From: Benjamin Ducke Subject: Re:
[GRASS-user] v.centroids and cat values Cc: grass-user
Message-ID:
<1559037892.138311231273729471.javamail.r...@mail.thehumanjourney.net>
Content-Type: text/plain; charset=utf-8
GRASS modules that create area type f
Thanks for the suggestions. Some additional comments below:
Benjamin Ducke wrote:
GRASS modules that create area type features should already be generating
centroids and adding categories to them automatically, shouldn't they?
As far as I am aware, e.g., v.in.ogr does this, so we are talking ma
12 matches
Mail list logo
