[GRASS-dev] Keywords, help pages...

GRASS GIS GRASS GIS developer
1

Posting an answer to the user list....

On Mon, 28 Aug 2006 22:14:56 +1200
Hamish <hamish_nospam@yahoo.com> wrote:

In GRASS-land boundaries + centroids make polygons, so convert lines to
boundaries with v.type and add centroids with "v.category option=add".

Here is a classic case of something being difficult to find where
properly defined keywords might help. I'd wondered about how to add
centroids to areas before, but never bothered to figure it out when
nothing obvious showed up scanning the command listing and descriptions.

Even trickier, with v.category the option=add with the type=centroid
doesn't add centroids, the type must be set to areas. I can't imagine
how the naming could be more counter-intuitive. Even the help page
example isn't all that clear on this IMHO.

Would it be a good idea to add something explicit about this on
v.category page as well as the grass vector intro page??

T
--
Trevor Wiens
twiens@interbaun.com

The significant problems that we face cannot be solved at the same
level of thinking we were at when we created them.
(Albert Einstein)

2

Trevor Wiens wrote on 08/28/2006 03:20 PM:

Posting an answer to the user list....

On Mon, 28 Aug 2006 22:14:56 +1200
Hamish <hamish_nospam@yahoo.com> wrote:

In GRASS-land boundaries + centroids make polygons, so convert lines to
boundaries with v.type and add centroids with "v.category option=add".
    
Here is a classic case of something being difficult to find where
properly defined keywords might help. I'd wondered about how to add
centroids to areas before, but never bothered to figure it out when
nothing obvious showed up scanning the command listing and descriptions.

Even trickier, with v.category the option=add with the type=centroid
doesn't add centroids, the type must be set to areas. I can't imagine
how the naming could be more counter-intuitive.

This sounds like a bug to me.

Markus

Even the help page
example isn't all that clear on this IMHO.

Would it be a good idea to add something explicit about this on
v.category page as well as the grass vector intro page??

T
  

3

Trevor Wiens wrote:

> In GRASS-land boundaries + centroids make polygons, so convert lines
> to boundaries with v.type and add centroids with "v.category
> option=add".

Here is a classic case of something being difficult to find where
properly defined keywords might help. I'd wondered about how to add
centroids to areas before, but never bothered to figure it out when
nothing obvious showed up scanning the command listing and
descriptions.

Even trickier, with v.category the option=add with the type=centroid
doesn't add centroids, the type must be set to areas. I can't imagine
how the naming could be more counter-intuitive. Even the help page
example isn't all that clear on this IMHO.

Would it be a good idea to add something explicit about this on
v.category page as well as the grass vector intro page??

AFAIK, a module was never specifically written for this as v.category
could do it (if you knew about it).

Rather than keywords and updated help pages, I offer the attached
script as a more direct solution.

If folks feel it more appropriate a new C modules using the
Vect_get_point_in_area() function [lib/vector/Vlib/poly.c] directly
could be written, but I think this script is fine for now.

In a similar vein, a v.dissolve script could be written as a front end to
"v.extract -d".

Hamish

(attachments)

v.add.centroids (1.79 KB)

4

On Tue, 29 Aug 2006 14:45:21 +1200
Hamish <hamish_nospam@yahoo.com> wrote:

...snip....

AFAIK, a module was never specifically written for this as v.category
could do it (if you knew about it).

Rather than keywords and updated help pages, I offer the attached
script as a more direct solution.

If folks feel it more appropriate a new C modules using the
Vect_get_point_in_area() function [lib/vector/Vlib/poly.c] directly
could be written, but I think this script is fine for now.

In a similar vein, a v.dissolve script could be written as a front end to
"v.extract -d".

Hamish,

Thanks, that is a much better solution.

I like the idea of a v.dissolve script especially if it had the option
to dissolve according using the values in one of the columns of the
attached attribute table; it would be much quicker to use.

I could write description.html files for v.add.centroids and v.dissolve
if it would be helpful.

T
--
Trevor Wiens
twiens@interbaun.com

The significant problems that we face cannot be solved at the same
level of thinking we were at when we created them.
(Albert Einstein)

5

On 8/28/06, Markus Neteler <neteler@itc.it> wrote:

Trevor Wiens wrote on 08/28/2006 03:20 PM:
> Posting an answer to the user list....
>
> On Mon, 28 Aug 2006 22:14:56 +1200
> Hamish <hamish_nospam@yahoo.com> wrote:
>
>> In GRASS-land boundaries + centroids make polygons, so convert lines to
>> boundaries with v.type and add centroids with "v.category option=add".
>>
>
> Here is a classic case of something being difficult to find where
> properly defined keywords might help. I'd wondered about how to add
> centroids to areas before, but never bothered to figure it out when
> nothing obvious showed up scanning the command listing and descriptions.
>
> Even trickier, with v.category the option=add with the type=centroid
> doesn't add centroids, the type must be set to areas. I can't imagine
> how the naming could be more counter-intuitive.

v.category adds category to geometry objects. The option 'type'
specifies the type of geometry objects to which the cattegory is added.
The 'type' option is something like input filter, only the geometry
specified in 'type' is processed. This works the same way for all modules.
If you use type=centroid, that means that you want to add cats to centroids
not that you want to add centroids.
Areas are special case because it is impossible to attach a cat to area
without centroid, the module places the centroids in areas automaticaly.

The only thing I can imagene it would be possible to do is to remove
type area and move the functionality to a new module v.centroid.
That would certainly make use more difficult.

Please dont change anything. Thanks

Radim

This sounds like a bug to me.

Markus

> Even the help page
> example isn't all that clear on this IMHO.
>
> Would it be a good idea to add something explicit about this on
> v.category page as well as the grass vector intro page??
>
> T
>

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

6

On Tue, 29 Aug 2006 12:27:42 +0200
"Radim Blazek" <radim.blazek@gmail.com> wrote:

On 8/28/06, Markus Neteler <neteler@itc.it> wrote:
> Trevor Wiens wrote on 08/28/2006 03:20 PM:
> > Posting an answer to the user list....
> >
> > On Mon, 28 Aug 2006 22:14:56 +1200
> > Hamish <hamish_nospam@yahoo.com> wrote:
> >
> >
> >> In GRASS-land boundaries + centroids make polygons, so convert lines to
> >> boundaries with v.type and add centroids with "v.category option=add".
> >>
> >
> > Here is a classic case of something being difficult to find where
> > properly defined keywords might help. I'd wondered about how to add
> > centroids to areas before, but never bothered to figure it out when
> > nothing obvious showed up scanning the command listing and descriptions.
> >
> > Even trickier, with v.category the option=add with the type=centroid
> > doesn't add centroids, the type must be set to areas. I can't imagine
> > how the naming could be more counter-intuitive.

v.category adds category to geometry objects. The option 'type'
specifies the type of geometry objects to which the cattegory is added.
The 'type' option is something like input filter, only the geometry
specified in 'type' is processed. This works the same way for all modules.

Radim,

By this logic, then to add centroids one should specify boundary not
area, because no areas exist before you add a centroid. In which case
this still doesn't make any sense.

If you use type=centroid, that means that you want to add cats to centroids
not that you want to add centroids.

This was not clear to me on a quick read through the help page.

Areas are special case because it is impossible to attach a cat to area
without centroid, the module places the centroids in areas automaticaly.

The only thing I can imagene it would be possible to do is to remove
type area and move the functionality to a new module v.centroid.
That would certainly make use more difficult.

I don't know how properly separating functionality into logical units
makes things more difficult to use. Adding centroids and categorizing
vector objects are two completely different things. It might be nice
to be able to do them both at once, but it would be more logical to
have the base functionality separated into two functions and then
super function which would allow doing both at once. My complaint was
that the documentation was unclear.

Now that I read your explanation, it is clear to me that there is mixed
functionality and inconsistent use of type in this module. If Markus
wants to split it off that would be much cleaner as well as more
understandable to most people. However I am happy to update the help
page so that it is clear what is going on, even though the terminology
is questionable and its use inconsistent...

T
--
Trevor Wiens
twiens@interbaun.com

The significant problems that we face cannot be solved at the same
level of thinking we were at when we created them.
(Albert Einstein)

7

On 8/29/06, Trevor Wiens <twiens@interbaun.com> wrote:

> > > Even trickier, with v.category the option=add with the type=centroid
> > > doesn't add centroids, the type must be set to areas. I can't imagine
> > > how the naming could be more counter-intuitive.
>
> v.category adds category to geometry objects. The option 'type'
> specifies the type of geometry objects to which the cattegory is added.
> The 'type' option is something like input filter, only the geometry
> specified in 'type' is processed. This works the same way for all modules.

Radim,

By this logic, then to add centroids one should specify boundary not
area, because no areas exist before you add a centroid. In which case
this still doesn't make any sense.

Areas exists, but they dont have any category. In GRASS (not QGIS)
you can query vector map with areas without category, you get area size
but no category. You cannot specify boundary because each area can be
defined by many boundaries and thos boundaries can be linked to a different
table, e.g. a boundary can be a road (typical in TIGER for example).

> If you use type=centroid, that means that you want to add cats to centroids
> not that you want to add centroids.

This was not clear to me on a quick read through the help page.

> Areas are special case because it is impossible to attach a cat to area
> without centroid, the module places the centroids in areas automaticaly.
>
> The only thing I can imagene it would be possible to do is to remove
> type area and move the functionality to a new module v.centroid.
> That would certainly make use more difficult.
>

I don't know how properly separating functionality into logical units
makes things more difficult to use. Adding centroids and categorizing
vector objects are two completely different things. It might be nice
to be able to do them both at once, but it would be more logical to
have the base functionality separated into two functions and then
super function which would allow doing both at once.

You are absolutely right, current implementation is result of my experience
that users prefer 'expected' over logical. Anyway I believe that
authomatic placement of centroids is not completely against logic
because areas are special type of geometry, they are not geometry elements
but objects compund of boundaries. If a user asks to add a category
to area, the only way to do it is to place a centroid (if does not exists).
That is not completely inconsistent.

My complaint was
that the documentation was unclear.

Now that I read your explanation, it is clear to me that there is mixed
functionality and inconsistent use of type in this module. If Markus
wants to split it off that would be much cleaner as well as more
understandable to most people.

If 'most people' I am not sure. In any case you cannot change module options
in 6.x line, that would definitely break user scripts and third party apps.

However I am happy to update the help
page so that it is clear what is going on, even though the terminology
is questionable and its use inconsistent...

Radim

T
--
Trevor Wiens
twiens@interbaun.com

The significant problems that we face cannot be solved at the same
level of thinking we were at when we created them.
(Albert Einstein)

8

Do I recall correctly that there were changes made to nviz open and play script?

I am trying to prepare a section for GRASS visualization workshop
on creating dynamic surfaces using file sequencing tool and when I try to play
the script created by the file sequencing tool I get segmentation fault.
I used it just few months ago for animation like this:
http://terrain.cs.duke.edu/topo_change/graphics/GRSLmitasanim.gif

I have attached the script (it does just the left side surface in the animation above),
it is very simple,
- I am wondering whether whoever knows about the change would have
a suggestion how to fix it - and whether there is a problem at all with this script.
I have a new 64bit machine so it maybe related to that rather than the scripting tool.
I would also like to add this to the 3rd edition of grassbook, as it is a really
effective way how to visualize e.g. dynamics of water flow or solar radiation
and it is pretty easy to do.

thanks a lot

Helena

--
Helena Mitasova
Department of Marine, Earth and Atmospheric Sciences
North Carolina State University
1125 Jordan Hall
NCSU Box 8208
Raleigh, NC 27695-8208
http://skagit.meas.ncsu.edu/~helena/

email: hmitaso@unity.ncsu.edu
ph: 919-513-1327 (no voicemail)
fax 919 515-7802

(attachments)

wksvisujrpc.script (1.71 KB)

9

On Tue, 29 Aug 2006 20:19:20 +0200
"Radim Blazek" <radim.blazek@gmail.com> wrote:

-snip-

> Radim,
>
> By this logic, then to add centroids one should specify boundary not
> area, because no areas exist before you add a centroid. In which case
> this still doesn't make any sense.

Areas exists, but they dont have any category. In GRASS (not QGIS)
you can query vector map with areas without category, you get area size
but no category. You cannot specify boundary because each area can be
defined by many boundaries and thos boundaries can be linked to a different
table, e.g. a boundary can be a road (typical in TIGER for example).

I stand corrected. I double checked and yes, although they aren't
recognized for vector to raster conversion, they are reported as
existing.

-snip-

but objects compund of boundaries. If a user asks to add a category
to area, the only way to do it is to place a centroid (if does not exists).
That is not completely inconsistent.

No, but certainly not obvious. One of my main beefs against ESRI is the
lack of clarity, adherence to standard terminology, etc. For the most
part I've found GRASS raster module to be quite clear and consistent on
this front, but the way functionality has been packaged into the v.*
modules to be a different story. This has been the reason for my past
complaints (naming of attribute table links layers) and now the hiding
of adding centroids in a v.category module is very frustrating. If
GRASS wants to attract new users we need to do a better job than ESRI.

Actually although much of the vector processing in GRASS 6.x is very
powerful, I don't use it all that often because it is just too awkward
in comparison with the simple elegance of PostGIS, especially in terms
of attribute management.

-snip-

If 'most people' I am not sure. In any case you cannot change module options
in 6.x line, that would definitely break user scripts and third party apps.

OK I'll rephrase that. Users familiar with other GIS programs, will not
at first find adding centroids, in v.category.

All that said, if v.category sacrosanct (although it is unclear to me
how this is determined) the issue remains of how to make things better.
Eric Patton has off list offered to improve some of the documentation
for v.category based on this discussion. I think however, it would be a
good idea to add in Hamish's v.centroids script with help page into the
CVS as it provides an obvious and convenient way of doing this for
users not deeply familiar with the GRASS 6.x vector modules. I also
liked the idea of a v.dissolve script which would make things more
convenient and obvious.

T
--
Trevor Wiens
twiens@interbaun.com

The significant problems that we face cannot be solved at the same
level of thinking we were at when we created them.
(Albert Einstein)

10

Trevor Wiens wrote on 08/30/2006 06:52 AM:

OK I'll rephrase that. Users familiar with other GIS programs, will not
at first find adding centroids, in v.category.

All that said, if v.category sacrosanct (although it is unclear to me
how this is determined) the issue remains of how to make things better.
Eric Patton has off list offered to improve some of the documentation
for v.category based on this discussion. I think however, it would be a
good idea to add in Hamish's v.centroids script with help page into the
CVS as it provides an obvious and convenient way of doing this for
users not deeply familiar with the GRASS 6.x vector modules. I also
liked the idea of a v.dissolve script which would make things more
convenient and obvious.

T
  
I don't see any problems to add those two scripts. The sooner, the
better :slight_smile:

Markus

11

I agree 1+

Can Hamish add the relevant menu entries or should I?

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Markus Neteler <neteler@itc.it>
Date: Wed, 30 Aug 2006 11:22:45 +0200
To: GRASS-DEV <grass-dev@grass.itc.it>
Subject: Re: v.category problem - was Re: [GRASS-dev] Keywords, help pages...

Trevor Wiens wrote on 08/30/2006 06:52 AM:

OK I'll rephrase that. Users familiar with other GIS programs, will not
at first find adding centroids, in v.category.

All that said, if v.category sacrosanct (although it is unclear to me
how this is determined) the issue remains of how to make things better.
Eric Patton has off list offered to improve some of the documentation
for v.category based on this discussion. I think however, it would be a
good idea to add in Hamish's v.centroids script with help page into the
CVS as it provides an obvious and convenient way of doing this for
users not deeply familiar with the GRASS 6.x vector modules. I also
liked the idea of a v.dissolve script which would make things more
convenient and obvious.

T
  
I don't see any problems to add those two scripts. The sooner, the
better :slight_smile:

Markus

12

Trevor wrote:
> All that said, if v.category sacrosanct (although it is unclear to
> me how this is determined)

All future GRASS 6.x must be backwards compatible with the original
GRASS 6.0.0. We can add things, but not change or remove options. The
idea is that any documentation, books, scripts, apps, data, etc.,
written for GRASS 6 will work on any future GRASS 6. When we switch to
GRASS 7 things can change. This is to provide continuity to the user.

> the issue remains of how to make things
> better. Eric Patton has off list offered to improve some of the
> documentation for v.category based on this discussion. I think
> however, it would be a good idea to add in Hamish's v.centroids
> script with help page into the CVS as it provides an obvious and
> convenient way of doing this for users not deeply familiar with the
> GRASS 6.x vector modules.

IMO we should do both.

> I also liked the idea of a v.dissolve
> script which would make things more convenient and obvious.

Markus wrote:

I don't see any problems to add those two scripts. The sooner, the
better :slight_smile:

Ok, will do. I'll take care of the tcl menus and 6.2 backporting too.
If someone else wants to write the help page, the help is greatly
appreciated.

One question for the list:

To use "v.add.centroids" or "v.centroids option=add" ? v.add.centroids
is more obvious, but v.centroids leaves the door open for future
options. I have no idea what those options could be, but someone might
think of something. CVS directory removal & above release restrictions
make it a pain to change later.

Hamish

13

On Thu, 31 Aug 2006 11:52:11 +1200
Hamish <hamish_nospam@yahoo.com> wrote:

> Trevor wrote:
> > All that said, if v.category sacrosanct (although it is unclear to
> > me how this is determined)

All future GRASS 6.x must be backwards compatible with the original
GRASS 6.0.0. We can add things, but not change or remove options. The
idea is that any documentation, books, scripts, apps, data, etc.,
written for GRASS 6 will work on any future GRASS 6. When we switch to
GRASS 7 things can change. This is to provide continuity to the user.

> > the issue remains of how to make things
> > better. Eric Patton has off list offered to improve some of the
> > documentation for v.category based on this discussion. I think
> > however, it would be a good idea to add in Hamish's v.centroids
> > script with help page into the CVS as it provides an obvious and
> > convenient way of doing this for users not deeply familiar with the
> > GRASS 6.x vector modules.

IMO we should do both.

> > I also liked the idea of a v.dissolve
> > script which would make things more convenient and obvious.

Markus wrote:
> I don't see any problems to add those two scripts. The sooner, the
> better :slight_smile:

Ok, will do. I'll take care of the tcl menus and 6.2 backporting too.
If someone else wants to write the help page, the help is greatly
appreciated.

Hamish,

I'll look after that and email it to you so you can commit it together.

One question for the list:

To use "v.add.centroids" or "v.centroids option=add" ? v.add.centroids
is more obvious, but v.centroids leaves the door open for future
options. I have no idea what those options could be, but someone might
think of something. CVS directory removal & above release restrictions
make it a pain to change later.

I suppose one could have an option=extract to pull the centroids as
points?

Do you want me to make a v.dissolve script or do you want to do that?

T
--
Trevor Wiens
twiens@interbaun.com

The significant problems that we face cannot be solved at the same
level of thinking we were at when we created them.
(Albert Einstein)

14

On Wed, 30 Aug 2006 19:34:19 -0600
Trevor Wiens wrote:

-snip-
> To use "v.add.centroids" or "v.centroids option=add" ?
v.add.centroids

> is more obvious, but v.centroids leaves the door open for future
> options. I have no idea what those options could be, but someone might
> think of something. CVS directory removal & above release restrictions
> make it a pain to change later.
>

I suppose one could have an option=extract to pull the centroids as
points?

Scratch that. That is stupid as there is already v.extract. I think
v.add.centroids is the way to go. I'll write the help page accordingly.

T
--
Trevor Wiens
twiens@interbaun.com

The significant problems that we face cannot be solved at the same
level of thinking we were at when we created them.
(Albert Einstein)