Re: [GRASS-dev] GRASS on Debian [was: Re: [GRASS-user] G7-gui and G64 add-on problems on Xubuntu (installation from grass/ubuntugis ppa)]

2013-10-31 Thread Hamish 


Hi,

thanks for re-posting the '@gprel relocation against dynamic symbol' linking 
error on Itanium Markus, right now I'm still only able to get online for a few 
minutes every two or three days.

cc'd to the DebianGIS list for a wider audience who might have come across this 
before.

see also the bug against grass in the debian system re. building on big-endian 
systems, MarkusM posted about the two checkins to trunk which already fixed it 
there, those two commits should be considered for backport, or at least into 
the debian/patches/ list after testing in devbr6. But it seems the latest 
package build isn't complaining about ppc64 and s390x, so..?

http://bugs.debian.org/728150
http://bugs.debian.org/672719


thanks,
Hamish





> On Friday, November 1, 2013 2:28 AM, Markus Neteler wrote:
> > On Thu, Oct 31, 2013 at 2:19 PM, Moritz Lennert
>  wrote:
> ...
>>  A bit off-topic, but since we're discussing packaging on Debian & 
> co:
>>  Hamish, do you know what is going on for grass 6.4.3 ? I see that it 
> hasn't
>>  migrated to testing, yet, because of failure to build on ia64:
>> 
>>  http://release.debian.org/migration/testing.pl?package=grass
>> 
>>  Any idea what the trouble is ? In the build logs I see stuff like:
>> 
>>  Status: gcc -E      -DPACKAGE="grasslibs" 
> -DPACKAGE="grasslibs"
>>  -I/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/include -U __GNUC__ -dD
>>  "-Dinline=" "-D__inline__=" 
> "-D__extension__=" "-D_Bool=uint8_t"
>>  "-D__const=const" "-D__asm__(x)=" 
> "-D__asm(x)=" "-DCTYPESGEN=1"
>>  /tmp/tmp3imMK2.h
>>  Status: Parsing /tmp/tmp3imMK2.h
>>  Error: /usr/include/GL/gl.h:109: Syntax error at '\n'
>>  Error: /usr/include/GL/gl.h:112: Syntax error at '\n'
> 
> 
> This happens on all Linux platforms and is not an issue usually.
> 
> https://buildd.debian.org/status/fetch.php?pkg=grass&arch=ia64&ver=6.4.3-2&stamp=1380196645
> shows
> 
> GRASS GIS compilation log
> -
> Started compilation: Thu Sep 26 11:30:48 UTC 2013
> --
> Errors in:
> /«PKGBUILDDIR»/lib/display
> /«PKGBUILDDIR»/lib/db/dbmi_driver
> ...
> which is really
> 
> make[4]: Entering directory `/«PKGBUILDDIR»/lib/display'
> test -d OBJ.ia64-unknown-linux-gnu || mkdir -p OBJ.ia64-unknown-linux-gnu
> gcc -I/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/include  -g -O2
> -Wformat -Werror=format-security  -fPIE    -D_FORTIFY_SOURCE=2
> -Wformat -Wformat-security -Werror=format-security
> -Wno-error=format-security -Wall -O    -fPIC
> -DPACKAGE=\""grasslibs"\"    
> -DPACKAGE=\""grasslibs"\"
> -I/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/include -o
> OBJ.ia64-unknown-linux-gnu/cnversions.o -c cnversions.c
> ...
> gcc -I/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/include  -g -O2
> -Wformat -Werror=format-security  -fPIE    -D_FORTIFY_SOURCE=2
> -Wformat -Wformat-security -Werror=format-security
> -Wno-error=format-security -Wall -O    -fPIC
> 
> -DPACKAGE=\""grasslibs"\"    
> -DPACKAGE=\""grasslibs"\"
> -I/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/include -o
> OBJ.ia64-unknown-linux-gnu/window.o -c window.c
> gcc -shared -o 
> /«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/lib/libgrass_display.6.4.3.so
> -L/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/lib -Wl,--export-dynamic
> -Wl,-rpath-link,/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/lib
> OBJ.ia64-unknown-linux-gnu/cnversions.o
> OBJ.ia64-unknown-linux-gnu/color_list.o
> OBJ.ia64-unknown-linux-gnu/draw.o OBJ.ia64-unknown-linux-gnu/draw2.o
> OBJ.ia64-unknown-linux-gnu/get_win.o
> OBJ.ia64-unknown-linux-gnu/ident_win.o
> OBJ.ia64-unknown-linux-gnu/list.o OBJ.ia64-unknown-linux-gnu/popup.o
> OBJ.ia64-unknown-linux-gnu/raster.o
> OBJ.ia64-unknown-linux-gnu/raster2.o
> OBJ.ia64-unknown-linux-gnu/setup.o OBJ.ia64-unknown-linux-gnu/symbol.o
> OBJ.ia64-unknown-linux-gnu/tran_colr.o
> OBJ.ia64-unknown-linux-gnu/window.o -lgrass_gis.6.4.3
> -lgrass_datetime.6.4.3 -lz     -lgrass_raster.6.4.3
> -lgrass_pngdriver.6.4.3 -lgrass_driver.6.4.3 -lgrass_gis.6.4.3
> -lgrass_datetime.6.4.3 -lz     -lfreetype    -lgrass_gis.6.4.3
> -lgrass_datetime.6.4.3 -lz     -lpng  -lz  -lm  -lgrass_psdriver.6.4.3
> -lgrass_driver.6.4.3 -lgrass_gis.6.4.3 -lgrass_datetime.6.4.3 -lz
> -lfreetype    -lgrass_gis.6.4.3 -lgrass_datetime.6.4.3 -lz
> -lgrass_driver.6.4.3 -lgrass_gis.6.4.3 -lgrass_datetime.6.4.3 -lz
> -lfreetype    -lgrass_gis.6.4.3 -lgrass_datetime.6.4.3 -lz
> /usr/bin/ld: OBJ.ia64-unknown-linux-gnu/raster2.o: @gprel relocation
> against dynamic symbol D__overlay_mode
> /usr/bin/ld: final link failed: Nonrepresentable section on output
> collect2: ld returned 1 exit status
> make[4]: *** 
> [/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/lib/libgrass_display.6.4.3.so]
> Error 1
> make[4]: Leaving directory `/«PKGBUILDDIR»/lib/display'
> 
> and so on
> ...
> 
> gcc -I/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/include  -g -O2
> -Wformat -Werror=format-security  -fPIE    -D_FORTIFY_SOURCE=2
> -Wformat -Wformat-security -Werror=format-security
> -Wno-error=format-security -Wall -O    -fPIC
> -

Re: [GRASS-dev] Object-based image classification in GRASS

2013-10-31 Thread Luca Delucchi 
On 31 October 2013 00:34, Pietro Zambelli  wrote:
> Hi Moritz,
>
>

Hi Pietro


>
>
> [0] https://github.com/zarch/i.segment.hierarchical
>

Could I suggest you to use the grass-addons repository ;-)
Thanks


-- 
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Interface description flag

2013-10-31 Thread Tyler Smith 
Hello,

(sorry if this gets posted multiple times, I'm having email problems at my end)

I'm developing an Emacs mode for interacting with the GRASS process,
available here:

https://bitbucket.org/tws/grass-mode.el/wiki/Home

One of the features of this mode is offering tab-completion of command
parameters. I use a lookup-table for this, populated by running all
the programs in the bin/ directory with the -interface-description
flag and parsing their output. This works fine for parameters that
have a set list of possible values, like d.vect icon.

However, I also have utility functions that provide completion of
vector and raster map names. I don't understand the output of
--interface-description well enough to know if there's a way to
automatically identify parameters that should be completed with a
vector name lookup. For example, all of the following combinations are
completed by a vector map file:

v.convert input= d.vect map= r.volume centroids= v.split input=

I notice that each of them has the following item in their  tag:



The age and element values differ, but all four have prompt="vector".

Can I use this to identify parameters that take a vector file name?
That is, is the value of  present for all
commands that should be completed by a vector map name, and is this
value absent from all other parameters?

If not, is their another way to get this information directly from the programs?

Thanks for your help,

Tyler
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS on Debian [was: Re: [GRASS-user] G7-gui and G64 add-on problems on Xubuntu (installation from grass/ubuntugis ppa)]

2013-10-31 Thread Markus Neteler 
On Thu, Oct 31, 2013 at 2:19 PM, Moritz Lennert
 wrote:
...
> A bit off-topic, but since we're discussing packaging on Debian & co:
> Hamish, do you know what is going on for grass 6.4.3 ? I see that it hasn't
> migrated to testing, yet, because of failure to build on ia64:
>
> http://release.debian.org/migration/testing.pl?package=grass
>
> Any idea what the trouble is ? In the build logs I see stuff like:
>
> Status: gcc -E  -DPACKAGE="grasslibs" -DPACKAGE="grasslibs"
> -I/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/include -U __GNUC__ -dD
> "-Dinline=" "-D__inline__=" "-D__extension__=" "-D_Bool=uint8_t"
> "-D__const=const" "-D__asm__(x)=" "-D__asm(x)=" "-DCTYPESGEN=1"
> /tmp/tmp3imMK2.h
> Status: Parsing /tmp/tmp3imMK2.h
> Error: /usr/include/GL/gl.h:109: Syntax error at '\n'
> Error: /usr/include/GL/gl.h:112: Syntax error at '\n'


This happens on all Linux platforms and is not an issue usually.

https://buildd.debian.org/status/fetch.php?pkg=grass&arch=ia64&ver=6.4.3-2&stamp=1380196645
shows

GRASS GIS compilation log
-
Started compilation: Thu Sep 26 11:30:48 UTC 2013
--
Errors in:
/«PKGBUILDDIR»/lib/display
/«PKGBUILDDIR»/lib/db/dbmi_driver
...
which is really

make[4]: Entering directory `/«PKGBUILDDIR»/lib/display'
test -d OBJ.ia64-unknown-linux-gnu || mkdir -p OBJ.ia64-unknown-linux-gnu
gcc -I/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/include  -g -O2
-Wformat -Werror=format-security  -fPIE-D_FORTIFY_SOURCE=2
-Wformat -Wformat-security -Werror=format-security
-Wno-error=format-security -Wall -O-fPIC
-DPACKAGE=\""grasslibs"\"-DPACKAGE=\""grasslibs"\"
-I/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/include -o
OBJ.ia64-unknown-linux-gnu/cnversions.o -c cnversions.c
...
gcc -I/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/include  -g -O2
-Wformat -Werror=format-security  -fPIE-D_FORTIFY_SOURCE=2
-Wformat -Wformat-security -Werror=format-security
-Wno-error=format-security -Wall -O-fPIC
-DPACKAGE=\""grasslibs"\"-DPACKAGE=\""grasslibs"\"
-I/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/include -o
OBJ.ia64-unknown-linux-gnu/window.o -c window.c
gcc -shared -o 
/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/lib/libgrass_display.6.4.3.so
-L/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/lib -Wl,--export-dynamic
-Wl,-rpath-link,/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/lib
OBJ.ia64-unknown-linux-gnu/cnversions.o
OBJ.ia64-unknown-linux-gnu/color_list.o
OBJ.ia64-unknown-linux-gnu/draw.o OBJ.ia64-unknown-linux-gnu/draw2.o
OBJ.ia64-unknown-linux-gnu/get_win.o
OBJ.ia64-unknown-linux-gnu/ident_win.o
OBJ.ia64-unknown-linux-gnu/list.o OBJ.ia64-unknown-linux-gnu/popup.o
OBJ.ia64-unknown-linux-gnu/raster.o
OBJ.ia64-unknown-linux-gnu/raster2.o
OBJ.ia64-unknown-linux-gnu/setup.o OBJ.ia64-unknown-linux-gnu/symbol.o
OBJ.ia64-unknown-linux-gnu/tran_colr.o
OBJ.ia64-unknown-linux-gnu/window.o -lgrass_gis.6.4.3
-lgrass_datetime.6.4.3 -lz -lgrass_raster.6.4.3
-lgrass_pngdriver.6.4.3 -lgrass_driver.6.4.3 -lgrass_gis.6.4.3
-lgrass_datetime.6.4.3 -lz -lfreetype-lgrass_gis.6.4.3
-lgrass_datetime.6.4.3 -lz -lpng  -lz  -lm  -lgrass_psdriver.6.4.3
-lgrass_driver.6.4.3 -lgrass_gis.6.4.3 -lgrass_datetime.6.4.3 -lz
-lfreetype-lgrass_gis.6.4.3 -lgrass_datetime.6.4.3 -lz
-lgrass_driver.6.4.3 -lgrass_gis.6.4.3 -lgrass_datetime.6.4.3 -lz
-lfreetype-lgrass_gis.6.4.3 -lgrass_datetime.6.4.3 -lz
/usr/bin/ld: OBJ.ia64-unknown-linux-gnu/raster2.o: @gprel relocation
against dynamic symbol D__overlay_mode
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
make[4]: *** 
[/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/lib/libgrass_display.6.4.3.so]
Error 1
make[4]: Leaving directory `/«PKGBUILDDIR»/lib/display'

and so on
...

gcc -I/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/include  -g -O2
-Wformat -Werror=format-security  -fPIE-D_FORTIFY_SOURCE=2
-Wformat -Wformat-security -Werror=format-security
-Wno-error=format-security -Wall -O-fPIC
-DPACKAGE=\""grasslibs"\"   -I../dbmi_base   -DPACKAGE=\""grasslibs"\"
 -I/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/include -o
OBJ.ia64-unknown-linux-gnu/driver_state.o -c driver_state.c
gcc -shared -o 
/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/lib/libgrass_dbmidriver.6.4.3.so
-L/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/lib -Wl,--export-dynamic
-Wl,-rpath-link,/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/lib
OBJ.ia64-unknown-linux-gnu/d_add_col.o
OBJ.ia64-unknown-linux-gnu/d_bindupdate.o
OBJ.ia64-unknown-linux-gnu/d_close_cur.o
OBJ.ia64-unknown-linux-gnu/d_closedb.o
OBJ.ia64-unknown-linux-gnu/d_create_idx.o
OBJ.ia64-unknown-linux-gnu/d_create_tab.o
OBJ.ia64-unknown-linux-gnu/d_createdb.o
OBJ.ia64-unknown-linux-gnu/d_delete.o
OBJ.ia64-unknown-linux-gnu/d_deletedb.o
OBJ.ia64-unknown-linux-gnu/d_desc_table.o
OBJ.ia64-unknown-linux-gnu/d_drop_col.o
OBJ.ia64-unknown-linux-gnu/d_drop_index.o
OBJ.ia64-unknown-linux-gnu/d_drop_tab.o
OBJ.ia64-unknown-linux-gnu/d_execute.o
OBJ.ia64-unknown-linux-gnu/d_fetch.o
OBJ.

[GRASS-dev] GRASS on Debian [was: Re: [GRASS-user] G7-gui and G64 add-on problems on Xubuntu (installation from grass/ubuntugis ppa)]

2013-10-31 Thread Moritz Lennert 

On 27/10/13 02:28, Hamish wrote:

Jürgen wrote:


You mean based on a newer GRASS?  Otherwise there is a nightly
build of QGIS on qgis.org (or even two one on based on plain ubuntu
and anther one based on ubuntugis).


What can we do to get an updated qgis package into upstream
debian/sid? right now it is stuck at 1.7.4 and so all downstream
ubuntus&  friends are stuck there too. I am happy to help but I'm not
sure if there was a reason for it being stuck?


A bit off-topic, but since we're discussing packaging on Debian & co: 
Hamish, do you know what is going on for grass 6.4.3 ? I see that it 
hasn't migrated to testing, yet, because of failure to build on ia64:


http://release.debian.org/migration/testing.pl?package=grass

Any idea what the trouble is ? In the build logs I see stuff like:

Status: gcc -E  -DPACKAGE="grasslibs" -DPACKAGE="grasslibs" 
-I/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/include -U __GNUC__ -dD 
"-Dinline=" "-D__inline__=" "-D__extension__=" "-D_Bool=uint8_t" 
"-D__const=const" "-D__asm__(x)=" "-D__asm(x)=" "-DCTYPESGEN=1" 
/tmp/tmp3imMK2.h

Status: Parsing /tmp/tmp3imMK2.h
Error: /usr/include/GL/gl.h:109: Syntax error at '\n'
Error: /usr/include/GL/gl.h:112: Syntax error at '\n'

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [osgeo4w-dev] hdf5dll.dll missing

2013-10-31 Thread Martin Landa 
Hi Jurgen,

2013/10/29 Jürgen E. :
>> Could be related to the recent introducing GDAL 1.10 in OSGeo4W
>> environment (seems to be problem with liblas package)?
>
> Maybe, but I don't see how.   gdal depends on gdal19dll and that contains the
> old gdal19.dll and hdf5dll.dll.

right, reinstalling this package helped. Sorry for the noise. Best
regards, Martin

-- 
Martin Landa  * http://geo.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Object-based image classification in GRASS

2013-10-31 Thread Pietro Zambelli 
On Thursday 31 Oct 2013 10:09:20 Moritz Lennert wrote:
> Great ! Then I won't continue on that and rather wait for your stuff. Do
> you have code, yet (except for i.segment.hierarchical) ? Don't hesitate
> to publish early.

I did some stuff here: https://github.com/zarch/ml.class

But I'm working to a main re-factoring to integrate my work with 
"v.class.mlpy". It is still under development.


> I guess we should focus on getting the functionality, first and then
> think about optimisation for size...

I agree, but I'm a phD student and I need the results now! :-)


> > 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.
> 
> Any reason other than preference for git over svn for not putting your
> module into grass-addons ?

No, I was worry to add too much stuff on grass-addons, and moreover is 
still under development so maybe it is not ready for a production 
environment...
But I think that now I can move i.segment.hierarchical to grass-addons.


> > 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!).
> 
> That's still only 7 hours for segmentation of a billion-cell size image.
> Not bad compared to other solutions out there...

I never used other solutions, so I'm not able to compared the results, but I 
think that we have some chance to speed-up the process some 
parallelization, I've started to study the i.segment code, but I need time.


> >  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).
> 
> Does your python module load the values into an attribute table ? I
> would guess that that's the slow part in v.to.db. Generally, I think
> that's another field where optimization would be great (if possible):
> database interaction, notably writing to tables. IIUC, in v.to.db there
> is a seperate update operation for each feature. I imagine that there
> must be a faster way to do this...

yes, this is the main problem GRASS is quite bad/slow writing to the db, I've 
skipped the GRASS API and use directly the python interface that is faster.
Moreover the v.to.db create only a column per time, and if you are using 
the sqlite driver it mean that each time you have to create a new table and 
copy all the data.

Even this module is not ready yet... it is just a python function.


> > 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.
> 
> You extended v.class.mlpy ? Is that code available somewhere ?

No, I wrote ml.class and now I'm rewriting to integrate the things together.


> > 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.
> 
> Great ! I guess the more the merrier ;-)
> See also [1]. Maybe its just a small additional step to add that at the
> same time ?

I would love to have this too! :-)


> > 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).
> 
> How do you do that ? Do you generate training points (or small areas)
> and then select the areas these points fall into ?
>
> I thought it best to select training areas among the actual polygons
> coming out of i.segment.


Yes I think so, I've generated some training areas using i.gui.class, then 
I've extract all the segments that overlap this areas and assign the 
category of the training vector map. I'm working on it (so no code ready 
yet!)

So I can write here as soon as I have something to test... :-)

Best regards

Pietro

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Object-based image classification in GRASS

2013-10-31 Thread Moritz Lennert 

On 30/10/13 21:23, Pierre Roudier wrote:

Moritz,

Thanks heaps for the script. It's really is useful and will facilitate
the adoption of i.segment. It certainly would be a nice addition to
the wiki page.


I can put it there as a proof-of-concept, but apparently Pietro is 
alreay much further on this, so that will probably be the way to go.




It could also be interesting to try non-supervised approach using
i.segment to limit the "salt and pepper" noise affecting such
classifications.


AFAIU, both scikit and mlpy offer unsupervised learning and 
classification techniques, so that should be possible.


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Object-based image classification in GRASS

2013-10-31 Thread Moritz Lennert 

Hi Pietro,

On 31/10/13 00:34, Pietro Zambelli wrote:

Hi Moritz,

I'm writing some modules (in python) to basically do the same thing.


Great ! Then I won't continue on that and rather wait for your stuff. Do 
you have code, yet (except for i.segment.hierarchical) ? Don't hesitate 
to publish early.


I think once the individual elements are there, it should be quite easy 
to cook up a little binding module which would allow to choose 
segmentation parameters, the variables to use for polygon 
characterization, the classification algorithm, etc and then launch the 
whole process.




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.


14 billion _is_ quite ambitious ;-)

I guess we should focus on getting the functionality, first and then 
think about optimisation for size...




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.


Any reason other than preference for git over svn for not putting your 
module into grass-addons ?



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!).


That's still only 7 hours for segmentation of a billion-cell size image. 
Not bad compared to other solutions out there...




 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).


Does your python module load the values into an attribute table ? I 
would guess that that's the slow part in v.to.db. Generally, I think 
that's another field where optimization would be great (if possible): 
database interaction, notably writing to tables. IIUC, in v.to.db there 
is a seperate update operation for each feature. I imagine that there 
must be a faster way to do this...




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.


You extended v.class.mlpy ? Is that code available somewhere ?



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].


I don't have any preferences on that. Colleagues here use R machine 
learning tools.




 > - 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.


Great ! I guess the more the merrier ;-)
See also [1]. Maybe its just a small additional step to add that at the 
same time ?




 > - 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).


How do you do that ? Do you generate training points (or small areas) 
and then select the areas these points fall into ?


I thought it best to select training areas among the actual polygons 
coming out of i.segment.



Some days ago I've discussed with MarkusM, that may be I could do a GS