Dear Moritz,

On Thu, Jan 9, 2014 at 10:13 AM, Moritz Lennert
<[email protected]> wrote:
>>      3. v.stats [r58637] => Extract statistics from a vector map
>>         (statistics about shape and about raster maps).
>>         v.stats internally use (in grass-addons):
>>          - v.area.stats [r58636] => extract some statistics about
>>            the shape (in grass-addons);
>
>
> Looking at the code of v.area.stats, I don't understand what it does
> differently than v.to.db, except that it outputs all indicators in one go. I
> think it would be better to avoid module inflation and maybe either make
> v.area.stats into a script that calls v.to.db several times to collect the
> different variables, or modify v.to.db to allow upload/output of several
> variables at once (see [1]).

yes, v.area.stats is just a subset (it works only with areas) of the
v.to.db compute all the parameters and export to a csv in one step, it
is much faster than run several times v.to.db.
I agree that would be better to avoid to make a new module... But the
easier and faster solution to my problem was to rewrite this module. I
can remove v.area.stats from grass-addons.


>>          - r.univar2 [r58439] => extract some general statistics from
>>            raster using the zones (consume much less memory than
>>            r.univar, and compute more general statistics like:
>>            skewness, kurtosis, and mode (in grass-addons);
>
> What is the difference between your r.univar2 and the original r.univar ?
> Couldn't your modifications be merged directly into r.univar ?

Yes, I think so, should be possible to merge r.univar2 => r.univar,
but at the moment r.univar2 is working only with the map of zones and
the only output is tabular (not "g" and "e" flags)... moreover I did
not add only some extra statistical parameters, I've changed the main
logic to reduce the memory footprint, so I prefer to push the change
in grass-addons, in order to avoid to break the original r.univar.


>>      4. v.class.ml [r58638] => classify a vector map, at the moment
>>          only a supervisionate classification is tested/supported.
>>          To select the segment that must use for training the different
>>          machine-learning techniques you can define a training
>>          map using the g.gui.iclass.
>>          The v.class.ml module can:
>>          - extract the training,
>>          - balance and scale the training set;
>>          - optimize the training set;
>>          - test several machine learning techniques;
>>          - explore the SVC domain;
>>          - export the accuracy of different ML to a csv file;
>>          - find and export the optimum training set,
>>          - classify the vector map using several ML techniques and
>>            export to a new layer of the vector map with the results
>>            of the classification;
>>          - export the classification results to several raster maps,
>>            the vector map coming from a segment raster map is too
>>            big to be exported to a shape file (the limit for a shape file
>>            is 4Gb [0]).
>
>
> Wow, this looks great ! I'll test this as soon as possible.

The main logic is to use the flags to prepare/test each step, the
command produce several npy files so you should be able to load the
npy files and ply directly with the classifiers, if you like.


>> * so far, only a supervised classification is supported.
>
> What would be needed to make unsupervised classification work ?

I guess that you need only to make a list of unsupervised classifiers
and add an optional parameter with the number class that you want to
extract from your data set.


All the best.

Pietro
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev

Reply via email to