Hi Moritz, I'm writing some modules (in python) to basically do the same thing.
I'm trying to apply a Object-based classification for a quite big area (the region is more than 14 billions of cells). At the moment I'm working with a smaller area with "only" ~1 billions of cells, but it is still quite challenging. To speed-up the segmentation process I did the i.segment.hierarchical module [0]. that split the region in several tiles, compute the segment for each tile, patch all the tiles together and run a last time i segment using the patched map as a seed. for a region of 24k row for 48k cols it required less than two hour to run and patch all the tiles, and more than 5 hours to run the "final" i.segment over the patched map (using only 3 iterations!). >From my experience I can say that the use "v.to.db" is terribly slow if you want to apply to a vector map with more than 2.7 Millions of areas. So I've develop a python function that compute the same values, but it is much faster that the v.to.db module, and should be possible to split the operation in several processes for further speed up... (It is still under testing). On Wednesday 30 Oct 2013 21:04:22 Moritz Lennert wrote: > - It uses the v.class.mlpy addon module for classification, so that > needs to be installed. Kudos to Vaclav for that module ! It currently > only uses the DLDA classifier. The mlpy library offers many more, and I > think it should be quite easy to add them. Obviously, one could also > simply export the attribute table of the segments and of the training > areas to csv files and use R to do the classification. I'm extended to use tree/k-NN/SVM Machine learning from MLPY [1] (I've used also Parzen, but the results were not good enough) and to work also with the scikit [2] classifiers. Scikit it seems to have a larger community and should be easier to install than MLPY, and last but not least it seems generally faster [3]. > - Many other variables could be calculated for the segments: other > texture variables (possibly variables by segment, not as average of > pixel-based variables, cf [1]), other shape variables (cf the new work > of MarkusM on center lines and skeletons of polygons in v.voronoi), band > indices, etc. It would be interesting to hear what most people find useful. I'm working to add also a C function to the GRASS library to compute the barycentre and the a polar second moment of Area (or Moment of Inertia), that return a number that it is independent from the orientation and dimension. > - I do the step of digitizing training areas in the wxGUI digitizer > using the attribute editing tool and filling in the 'class' attribute > for those polygons I find representative. As already mentioned in > previous discussions [2], I do think that it would be nice if we could > have an attribute editing form that is independent of the vector digitizer. I use the i.gui.class to generate the training vector map, and then use this map to select the training areas, and export the final results into a file (at the moment only csv and npy formats are supported). > More generally, it would be great to get feedback from interested people > on this approach to object-based image classification to see what we can > do to make it better. I'm definitely interested on the topic! :-) Some days ago I've discussed with MarkusM, that may be I could do a GSoC next year to modify the i.segment module to automatically split the domain in tiles, run as a multiprocess, and then "patch" only the segments that are on the border of the tiles, this solution should be much faster than my actual solution[0]. Moreover we should consider to skip to transform the segments into vector to extract the shape parameters and extract shape and others parameters (mean, median, skewness, std, etc.) directly as last step before to free the memory from the segments structures, writing a csv/npy file. All the best. Pietro [0] https://github.com/zarch/i.segment.hierarchical [1] http://mlpy.sourceforge.net/ [2] http://scikit-learn.org/ [3] http://scikit-learn.org/ml-benchmarks/
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
