v.category problem - was Re: [GRASS-dev] Keywords, help pages...

[Radim Blazek]

On 8/29/06, Trevor Wiens <twiens at 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 at 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)
>