[GRASS-dev] small interface inconsistency in r.to.vect in GRASS 7

[Michael Barton]

______________________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University
Tempe, AZ  85287-2402
USA

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax:          480-965-7671(SHESC), 480-727-0709 (CSDC)
www:  http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

On Dec 2, 2014, at 6:29 AM, Anna Petrášová <kratochanna at gmail.com<mailto:kratochanna at gmail.com>> wrote:



On Tue, Dec 2, 2014 at 12:01 AM, Michael Barton <Michael.Barton at asu.edu<mailto:Michael.Barton at asu.edu>> wrote:


On Dec 1, 2014, at 9:31 PM, Anna Petrášová <kratochanna at gmail.com<mailto:kratochanna at gmail.com>> wrote:



On Mon, Dec 1, 2014 at 6:21 PM, Michael Barton <Michael.Barton at asu.edu<mailto:Michael.Barton at asu.edu>> wrote:
In r.to.vect, this argument ONLY refers to the output vector feature. There are not any different feature types for the 2D raster maps that are input to this module. I assume that while the nature of the raster map affects the vector feature type to some extent, this argument can force it to output a particular feature type when there is the potential for multiple feature type output.

I suppose simply “feature type” is OK. But it is the output vector map that is being referred to in any case and “input” feature type is misleading IMHO.

Probably revert http://trac.osgeo.org/grass/changeset/59324? Or create separate options G_OPT_V_TYPE_INPUT, G_OPT_V_TYPE_OUTPUT?

But the input is always a raster. So there is no reason for an option G_OPT_V_TYPE_INPUT

The output is always a vector, which CAN have different feature types, so there is a reason for G_OPT_V_TYPE_OUTPUT.

I was talking about introducing new standard options G_OPT_V_TYPE_INPUT, G_OPT_V_TYPE_OUTPUT which would differ only in description (Input feature type/Output feature type). r.to.vect would then use G_OPT_V_TYPE_OUTPUT, v.to.rast would use  G_OPT_V_TYPE_INPUT. Or we just stay with G_OPT_V_TYPE and redefine description.

Yes. This makes sense.

Michael



Michael


Anna


Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262<tel:480-965-6262> (SHESC), 480-965-8130<tel:480-965-8130>/727-9746 (CSDC)
fax: 480-965-7671<tel:480-965-7671> (SHESC),  480-727-0709<tel:480-727-0709> (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu<http://csdc.asu.edu/>















On Dec 1, 2014, at 4:13 PM, Markus Neteler <neteler at osgeo.org<mailto:neteler at osgeo.org>> wrote:

> On Sat, Nov 29, 2014 at 6:20 PM, Michael Barton <Michael.Barton at asu.edu<mailto:Michael.Barton at asu.edu>> wrote:
>> I just ran into this last night.
>>
>> The description for the “type” argument for r.to.vect calls it “Input
>> feature type”, but actually it should be “Output feature type”.
>
> I'm not sure. The raster input defines also the output to some extent.
> In G6 it was simply called "Feature type", perhaps we should restore
> that description?
>
> Markus

_______________________________________________
grass-dev mailing list
grass-dev at lists.osgeo.org<mailto:grass-dev at lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/grass-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20141202/2877778f/attachment-0001.html>