[GRASS-user] Is "i.cluster" an implementation of the ISODATA algorithm?

NikosAlexandris · October 30, 2012, 6:35am

Hi PowerUsers!

I am slowly scratching (again) the image classification modules. I've found an
interesting lecture presentation, entitled "The application of GIS in
formulation and implementation of integrated coastal area management plans in
the Guinea current region" by Alberto Altobelli [1].

In it, the ISODATA clustering algorithm is described (page 10, upper box).
Following, two classification methods are mentioned, namely the MLC and the MDC
(page 10, lower box).

I wonder why the term ISODATA [2] is not to be traced anywhere in the GRASS
manuals, nor in the GRASS book (3rd ed.). Can someone confirm that i.cluster
is an(other) implementation of the ISODATA clustering algorithm?

Thank you, Nikos

ps- btw, the presentation contains two very nice tri-dimensional scatterplots
(in pages 5 and 9). Does anyone know with which tool they have been created?

---
[1] <http://www.ics.trieste.it/media/135451/df2456.pdf>
[2] ISODATA, aka Migrating Means or Iterative Optimization Clustering
Algorithm

neteler · October 30, 2012, 8:42am

Hi Nikos,

On Tue, Oct 30, 2012 at 7:35 AM, Nikos Alexandris
<nik@nikosalexandris.net> wrote:
...

I wonder why the term ISODATA [2] is not to be traced anywhere in the GRASS
manuals, nor in the GRASS book (3rd ed.). Can someone confirm that i.cluster
is an(other) implementation of the ISODATA clustering algorithm?

I search in my inbox and found some earlier discussion with the
Subject: "Re: [GRASS-user] Re: algorithm used in i.cluster", see
below.

cheers
Markus

PS: Still we need a text snippet to improve the manual...

On Thu, Apr 22, 2010 at 5:21 PM, Georg Kaspar <georg - muenster.de> wrote:

Georg Kaspar schrieb:

the steps described in
http://download.osgeo.org/grass/grass6_progman/c__exec_8c_source.html

seem to fit the migrating means algorithm described in richards and jia
(2006) and based on the isodata algorithm in ball and hall (1965):

which is in principle the same as k-means.
I wrote a mail to Michael Shapiro, who wrote the code back in the 90's and
received this answer:

Georg,

It has been a very long time since I wrote that code so my memory may be
suspect, but I think that is correct.

On Thu, Apr 22, 2010 at 5:35 PM, Georg Kaspar <georg@muenster.de> wrote:

Sorry for flooding the list, but i found an interesting note in Schowengerdt
(2007), p. 400:

"The ISODATA algorithm (Ball and Hall, 1967) is a common modification of the
K-means algorithm and includes merging of clusters if their separation is
below a threshold, and splitting of a single cluster into two clusters if it
becomes too large"

The algorithm implemented in the i.cluster module involves merging of
classes (I_cluster_merge) though no splitting function seems to be
implemented.
Since Michael Shapiro stated that he might have used the K-means algorithm,
I think we can be pretty shure that it is a modified version similar to the
isodata algorithm, which is described as migrating means in Richards (2006).
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

NikosAlexandris · October 30, 2012, 9:20am

NikosA:

> I wonder why the term ISODATA [2] is not to be traced anywhere in the
> GRASS manuals, nor in the GRASS book (3rd ed.). Can someone confirm that
> i.cluster is an(other) implementation of the ISODATA clustering
> algorithm?

MarkusN:

I search in my inbox and found some earlier discussion with the
Subject: "Re: [GRASS-user] Re: algorithm used in i.cluster", see
below.

PS: Still we need a text snippet to improve the manual...

Things to keep in mind from the archived discussions (below):

- the ISODATA algorithm (Ball and Hall, 1967) is a common modification of the
K-means algorithm

- the algorithm implemented in the "i.cluster" module involves merging of
classes (I_cluster_merge) though no splitting function seems to be implemented

Thank you Markus,
Nikos

--%<---

On Thu, Apr 22, 2010 at 5:21 PM, Georg Kaspar <georg - muenster.de> wrote:
> Georg Kaspar schrieb:

>> the steps described in
>> http://download.osgeo.org/grass/grass6_progman/c__exec_8c_source.html
>> seem to fit the migrating means algorithm described in richards and jia
>> (2006) and based on the isodata algorithm in ball and hall (1965):

> which is in principle the same as k-means.

> I wrote a mail to Michael Shapiro, who wrote the code back in the 90's and
> received this answer:

>> Georg,

> >> It has been a very long time since I wrote that code so my memory may be

>> suspect, but I think that is correct.

On Thu, Apr 22, 2010 at 5:35 PM, Georg Kaspar <georg@muenster.de> wrote:
> Sorry for flooding the list, but i found an interesting note in
> Schowengerdt (2007), p. 400:

> "The ISODATA algorithm (Ball and Hall, 1967) is a common modification of
> the K-means algorithm and includes merging of clusters if their
> separation is below a threshold, and splitting of a single cluster into
> two clusters if it becomes too large"

> The algorithm implemented in the i.cluster module involves merging of
> classes (I_cluster_merge) though no splitting function seems to be
> implemented.

> Since Michael Shapiro stated that he might have used the K-means
> algorithm, I think we can be pretty shure that it is a modified version
> similar to the isodata algorithm, which is described as migrating means in
> Richards (2006).

--->%--

mlennert · October 30, 2012, 5:06pm

On 30/10/12 10:20, Nikos Alexandris wrote:

NikosA:

I wonder why the term ISODATA [2] is not to be traced anywhere in the
GRASS manuals, nor in the GRASS book (3rd ed.). Can someone confirm that
i.cluster is an(other) implementation of the ISODATA clustering
algorithm?

MarkusN:

I search in my inbox and found some earlier discussion with the
Subject: "Re: [GRASS-user] Re: algorithm used in i.cluster", see
below.

PS: Still we need a text snippet to improve the manual...

Things to keep in mind from the archived discussions (below):

- the ISODATA algorithm (Ball and Hall, 1967) is a common modification of the
K-means algorithm

- the algorithm implemented in the "i.cluster" module involves merging of
classes (I_cluster_merge) though no splitting function seems to be implemented

To add: i.cluster output is also not equivalent to ISODATA in so far as it does not classify all pixels, but only creates signature files for the classes. Classification is then done by i.maxlik which is not equivalent to ISODATA. It might be an interesting addition to i.cluster to work with all pixels (not only a subset) and to create an output assigning each pixel to a given class which would be close (but not equal) to ISODATA output.

Moritz

NikosAlexandris · October 30, 2012, 11:48pm

NikosA:

>>> I wonder why the term ISODATA [2] is not to be traced anywhere in the
>>> GRASS manuals, nor in the GRASS book (3rd ed.). Can someone confirm
>>> that i.cluster is an(other) implementation of the ISODATA clustering
>>> algorithm?

MarkusN:

>> I search in my inbox and found some earlier discussion with the
>> Subject: "Re: [GRASS-user] Re: algorithm used in i.cluster", see
>> below.

>> PS: Still we need a text snippet to improve the manual...

> Things to keep in mind from the archived discussions (below):

> - the ISODATA algorithm (Ball and Hall, 1967) is a common modification of
> the K-means algorithm

> - the algorithm implemented in the "i.cluster" module involves merging of
> classes (I_cluster_merge) though no splitting function seems to be
> implemented

Moritz:

To add: i.cluster output is also not equivalent to ISODATA in so far as
it does not classify all pixels, but only creates signature files for
the classes. Classification is then done by i.maxlik which is not
equivalent to ISODATA. It might be an interesting addition to i.cluster
to work with all pixels (not only a subset) and to create an output
assigning each pixel to a given class which would be close (but not
equal) to ISODATA output.

Moritz,

please correct me if I am wrong. I feel that the above sentences draw
actually an unnecessary confusion.

The first step is to cluster pixels according to their (similar, spectral)
properties. The second step is to classify the clusters, meaning labeling of
the resulted clusters. So, I don't see were confusions might arise, apart
from the question whether "i.cluster" is an exact implementation of the
ISODATA algorithm or not.

- ISODATA is a clustering algorithm, not a classification algorithm per se --
skimming through Richards book (1999) [1], pages 182, 189, 225. And the
"i.cluster" module might not be identical to the ISODATA clustering algorithm,
yet, it performs clustering. So, both do the same job, most likely in a more
or less similar way.

- "i.maxlik" performs the classification of the clusters, which is not a
clustering process. Thus, the module can/should not be identical to the
ISODATA clustering algorithm. I might have missed something (skimming through
the manuals), but I didn't read anywhere that "i.maxlik" is performing
clustering.

Your attention to details is highly appreciated.
Thanks, Nikos

---
[1] @BOOK{Richards1999,
  title = {{{R}emote {S}ensing {D}igital {I}mage {A}nalysis. {A}n
{I}ntroduction,
  3rd revised and enlarged edition.: xxi + 363 pp.}},
  publisher = {Berlin, Heidelberg, New York, London, Paris, Tokyo, Hong Kong:
Springer-Verlag.},
  year = {1999},
  author = {JA Richards and X Jia},
  pages = {363},
  edition = {3},
  note = {Hard cover},
  isbn = {3-540-64860-7}
}

kalxas · October 31, 2012, 9:32am

Hi all,

This is an ISODATA implementation in C, written under GPL by Christos Iossifidis, a colleague of mine at NTUA.
Would anyone be interested porting it to GRASS?

http://users.ntua.gr/chiossif/Free_As_Freedom_Software/isodata.c

Cheers,
Angelos

On 10/31/2012 01:48 AM, Nikos Alexandris wrote:

NikosA:

I wonder why the term ISODATA [2] is not to be traced anywhere in the
GRASS manuals, nor in the GRASS book (3rd ed.). Can someone confirm
that i.cluster is an(other) implementation of the ISODATA clustering
algorithm?

MarkusN:

I search in my inbox and found some earlier discussion with the
Subject: "Re: [GRASS-user] Re: algorithm used in i.cluster", see
below.
PS: Still we need a text snippet to improve the manual...

Things to keep in mind from the archived discussions (below):
- the ISODATA algorithm (Ball and Hall, 1967) is a common modification of
the K-means algorithm
- the algorithm implemented in the "i.cluster" module involves merging of
classes (I_cluster_merge) though no splitting function seems to be
implemented

Moritz:

To add: i.cluster output is also not equivalent to ISODATA in so far as
it does not classify all pixels, but only creates signature files for
the classes. Classification is then done by i.maxlik which is not
equivalent to ISODATA. It might be an interesting addition to i.cluster
to work with all pixels (not only a subset) and to create an output
assigning each pixel to a given class which would be close (but not
equal) to ISODATA output.

Moritz,

please correct me if I am wrong. I feel that the above sentences draw
actually an unnecessary confusion.

The first step is to cluster pixels according to their (similar, spectral)
properties. The second step is to classify the clusters, meaning labeling of
the resulted clusters. So, I don't see were confusions might arise, apart
from the question whether "i.cluster" is an exact implementation of the
ISODATA algorithm or not.

- ISODATA is a clustering algorithm, not a classification algorithm per se --
skimming through Richards book (1999) [1], pages 182, 189, 225. And the
"i.cluster" module might not be identical to the ISODATA clustering algorithm,
yet, it performs clustering. So, both do the same job, most likely in a more
or less similar way.

- "i.maxlik" performs the classification of the clusters, which is not a
clustering process. Thus, the module can/should not be identical to the
ISODATA clustering algorithm. I might have missed something (skimming through
the manuals), but I didn't read anywhere that "i.maxlik" is performing
clustering.

Your attention to details is highly appreciated.
Thanks, Nikos

---
[1] @BOOK{Richards1999,
   title = {{{R}emote {S}ensing {D}igital {I}mage {A}nalysis. {A}n
{I}ntroduction,
  3rd revised and enlarged edition.: xxi + 363 pp.}},
   publisher = {Berlin, Heidelberg, New York, London, Paris, Tokyo, Hong Kong:
Springer-Verlag.},
   year = {1999},
   author = {JA Richards and X Jia},
   pages = {363},
   edition = {3},
   note = {Hard cover},
   isbn = {3-540-64860-7}
}
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

--
Angelos Tzotsos
Remote Sensing Laboratory
National Technical University of Athens
http://users.ntua.gr/tzotsos

kalxas · October 31, 2012, 9:36am

Sorry, I forgot to CC Christos

On 10/31/2012 11:32 AM, Angelos Tzotsos wrote:

Hi all,

This is an ISODATA implementation in C, written under GPL by Christos Iossifidis, a colleague of mine at NTUA.
Would anyone be interested porting it to GRASS?

http://users.ntua.gr/chiossif/Free_As_Freedom_Software/isodata.c

Cheers,
Angelos

On 10/31/2012 01:48 AM, Nikos Alexandris wrote:

NikosA:

I wonder why the term ISODATA [2] is not to be traced anywhere in the
GRASS manuals, nor in the GRASS book (3rd ed.). Can someone confirm
that i.cluster is an(other) implementation of the ISODATA clustering
algorithm?

MarkusN:

I search in my inbox and found some earlier discussion with the
Subject: "Re: [GRASS-user] Re: algorithm used in i.cluster", see
below.
PS: Still we need a text snippet to improve the manual...

Things to keep in mind from the archived discussions (below):
- the ISODATA algorithm (Ball and Hall, 1967) is a common modification of
the K-means algorithm
- the algorithm implemented in the "i.cluster" module involves merging of
classes (I_cluster_merge) though no splitting function seems to be
implemented

Moritz:

To add: i.cluster output is also not equivalent to ISODATA in so far as
it does not classify all pixels, but only creates signature files for
the classes. Classification is then done by i.maxlik which is not
equivalent to ISODATA. It might be an interesting addition to i.cluster
to work with all pixels (not only a subset) and to create an output
assigning each pixel to a given class which would be close (but not
equal) to ISODATA output.

Moritz,

please correct me if I am wrong. I feel that the above sentences draw
actually an unnecessary confusion.

The first step is to cluster pixels according to their (similar, spectral)
properties. The second step is to classify the clusters, meaning labeling of
the resulted clusters. So, I don't see were confusions might arise, apart
from the question whether "i.cluster" is an exact implementation of the
ISODATA algorithm or not.

- ISODATA is a clustering algorithm, not a classification algorithm per se --
skimming through Richards book (1999) [1], pages 182, 189, 225. And the
"i.cluster" module might not be identical to the ISODATA clustering algorithm,
yet, it performs clustering. So, both do the same job, most likely in a more
or less similar way.

- "i.maxlik" performs the classification of the clusters, which is not a
clustering process. Thus, the module can/should not be identical to the
ISODATA clustering algorithm. I might have missed something (skimming through
the manuals), but I didn't read anywhere that "i.maxlik" is performing
clustering.

Your attention to details is highly appreciated.
Thanks, Nikos

---
[1] @BOOK{Richards1999,
   title = {{{R}emote {S}ensing {D}igital {I}mage {A}nalysis. {A}n
{I}ntroduction,
    3rd revised and enlarged edition.: xxi + 363 pp.}},
   publisher = {Berlin, Heidelberg, New York, London, Paris, Tokyo, Hong Kong:
Springer-Verlag.},
   year = {1999},
   author = {JA Richards and X Jia},
   pages = {363},
   edition = {3},
   note = {Hard cover},
   isbn = {3-540-64860-7}
}
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

--
Angelos Tzotsos
Remote Sensing Laboratory
National Technical University of Athens
http://users.ntua.gr/tzotsos

NikosAlexandris · October 31, 2012, 9:47am

Angelos Tzotsos wrote:

Hi all,
This is an ISODATA implementation in C, written under GPL by Christos
Iossifidis, a colleague of mine at NTUA.

Would anyone be interested porting it to GRASS?
http://users.ntua.gr/chiossif/Free_As_Freedom_Software/isodata.c

Nice!

...

Rebecca_Bennett · October 31, 2012, 2:30pm

Dear Grass Users,

Trying to compile 6.4.3 from source on Ubuntu 12.04 in order to get at the add-ons which are not working in my prepackaged install.

Following these instructions (http://grass.osgeo.org/wiki/Compile_and_Install_Ubuntu) I check out the release_20121024_grass_6_4_3RC1 get as far as

./configure \

but get the following error:
checking for long long int... yes
checking for W11... no
checking for X... no
checking whether to use Curses... yes
checking for curses.h... no
configure: error: *** Unable to locate curses includes.

Any suggestions / ideas welcome!

Many thanks for reading,

Rebecca

madi · October 31, 2012, 2:46pm

Dear Rebecca,

On Wed, Oct 31, 2012 at 3:30 PM, Rebecca Bennett <rabennett@ymail.com> wrote:

Dear Grass Users,

Trying to compile 6.4.3 from source on Ubuntu 12.04 in order to get at the add-ons which are not working in my prepackaged install.

Which add-on is not working?

Following these instructions (http://grass.osgeo.org/wiki/Compile_and_Install_Ubuntu) I check out the release_20121024_grass_6_4_3RC1 get as far as
./configure \

but get the following error:
checking for long long int... yes
checking for W11... no
checking for X... no
checking whether to use Curses... yes
checking for curses.h... no
configure: error: *** Unable to locate curses includes.

Any suggestions / ideas welcome!

I think you miss libncurses5-dev.
In general, when you get an error like this, you can do the search yourself here: http://packages.ubuntu.com/
You have to search “contents of packages” and specify your version/distribution.

Hope this helps,

madi

–
Margherita DI LEO

Postdoctoral Researcher
European Commission - DG JRC
Forest Resources and Climate
I-21020 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-leo@jrc.ec.europa.eu

Rebecca_Bennett · October 31, 2012, 2:56pm

Great thanks Madi - I’d used that approach for the two earlier errors when running this command but couldn’t find a package relating to curses in my search for unintalled packages (probably due to the curses but being surrounded by other letters!)

Incedentally non-of the add-ons are working through the gui - I know this is a freqently reported problem to which the only guaranteed solution (after scouring the mailing list and trying solutions posted here http://planetflux.adamwilson.us/2012/02/installing-grass-extensions-on-ubuntu.html and http://comments.gmane.org/gmane.comp.gis.grass.user/43974) appears to be to compile from source.

…I wanted large file support anyway so I was just being lazy to only use the Ubuntu:GIS repository version

cheers!
Rebecca

From: Margherita Di Leo diregola@gmail.com
To: Rebecca Bennett rabennett@ymail.com
Cc: “grass-user@lists.osgeo.org” grass-user@lists.osgeo.org
Sent: Wednesday, 31 October 2012, 10:46
Subject: Re: [GRASS-user] Unable to locate Curses Includes

Dear Rebecca,

On Wed, Oct 31, 2012 at 3:30 PM, Rebecca Bennett <rabennett@ymail.com> wrote:

Dear Grass Users,

Trying to compile 6.4.3 from source on Ubuntu 12.04 in order to get at the add-ons which are not working in my prepackaged install.

Which add-on is not working?
Following these instructions (http://grass.osgeo.org/wiki/Compile_and_Install_Ubuntu) I check out the release_20121024_grass_6_4_3RC1 get as far as
./configure \

but get the following error:
checking for long long int... yes
checking for W11... no
checking for X... no
checking whether to use Curses... yes
checking for curses.h... no
configure: error: *** Unable to locate curses includes.

Any suggestions / ideas welcome!
I think you miss libncurses5-dev.
In general, when you get an error like this, you can do the search yourself here: http://packages.ubuntu.com/
You have to search “contents of packages” and specify your version/distribution.

Hope this helps,

madi

–
Margherita DI LEO

Postdoctoral Researcher
European Commission - DG JRC
Forest Resources and Climate
I-21020 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-leo@jrc.ec.europa.eu

mlennert · October 31, 2012, 4:56pm

On 31/10/12 00:48, Nikos Alexandris wrote:

NikosA:

I wonder why the term ISODATA [2] is not to be traced anywhere in the
GRASS manuals, nor in the GRASS book (3rd ed.). Can someone confirm
that i.cluster is an(other) implementation of the ISODATA clustering
algorithm?

MarkusN:

I search in my inbox and found some earlier discussion with the
Subject: "Re: [GRASS-user] Re: algorithm used in i.cluster", see
below.

PS: Still we need a text snippet to improve the manual...

Things to keep in mind from the archived discussions (below):

- the ISODATA algorithm (Ball and Hall, 1967) is a common modification of
the K-means algorithm

- the algorithm implemented in the "i.cluster" module involves merging of
classes (I_cluster_merge) though no splitting function seems to be
implemented

Moritz:

To add: i.cluster output is also not equivalent to ISODATA in so far as
it does not classify all pixels, but only creates signature files for
the classes. Classification is then done by i.maxlik which is not
equivalent to ISODATA. It might be an interesting addition to i.cluster
to work with all pixels (not only a subset) and to create an output
assigning each pixel to a given class which would be close (but not
equal) to ISODATA output.

Moritz,

please correct me if I am wrong. I feel that the above sentences draw
actually an unnecessary confusion.

The first step is to cluster pixels according to their (similar, spectral)
properties. The second step is to classify the clusters, meaning labeling of
the resulted clusters. So, I don't see were confusions might arise, apart
from the question whether "i.cluster" is an exact implementation of the
ISODATA algorithm or not.

In GRASS, you don't have exactly these steps. i.cluster does not cluster all pixels, but only a sample (see parameter 'sample'). The result of that clustering is not that all pixels are assigned to a given cluster, but only that you have signatures that are "representative" of a given cluster. If you run i.cluster on the same data asking for the same number of classes, but with different sample sizes, you will probably get slightly different signatures for each cluster at each run.

In the second step, you use i.maxlik to then assign each pixel to one of the clusters / classes created by i.cluster.

Labelling is actually a third step in that process.

So, i.cluster is used for creating signatures of representative classes, just as i.gensig.

ISODATA, OTOH, clusters all pixels and thus already assigns each pixel to a given cluster / class, without going through the i.maxlik phase.

i.cluster with a sample=1,1 (if you can get that to run without an alloc error on your machine) should use all pixels for the creation of the clusters, but it does not allow you to produce a raster layer indicating for each pixel the cluster it is assigned to. You have to do i.maxlik to do that.

However, i.maxlik does not use the same algorithm to assign pixels to clusters / classes as ISODATA. So the result is not exactly the same.

- ISODATA is a clustering algorithm, not a classification algorithm per se --
skimming through Richards book (1999) [1], pages 182, 189, 225. And the
"i.cluster" module might not be identical to the ISODATA clustering algorithm,
yet, it performs clustering. So, both do the same job, most likely in a more
or less similar way.

Well, as explained above, i.cluster does not cluster the entire map, and does not show you the result of the clustering other than in form of a signature file, so i.cluster does not perform clustering in the same meaning as ISODATA.

- "i.maxlik" performs the classification of the clusters, which is not a
clustering process. Thus, the module can/should not be identical to the
ISODATA clustering algorithm. I might have missed something (skimming through
the manuals), but I didn't read anywhere that "i.maxlik" is performing
clustering.

i.maxlik does not perform clustering but assignment of pixels to classes/clusters based on signatures of such classes that are either created by clustering or through training maps. ISODATA assigns pixels to classes through clustering.

I hope I'm being understandable...

Moritz

NikosAlexandris · October 31, 2012, 5:06pm

[...]

Moritz:

I hope I'm being understandable...

Absolutely :-).
Thank you, Nikos

neteler · November 1, 2012, 6:46am

On Wed, Oct 31, 2012 at 6:06 PM, Nikos Alexandris
<nik@nikosalexandris.net> wrote:

[...]

Moritz:

I hope I'm being understandable...

Absolutely :-).

Since this questions comes up from time to time, it would be nice to get
the summary of this comparative discussion into the Wiki... volunteers needed.

Markus

NikosAlexandris · November 1, 2012, 6:57am

..
Moritz:

>> I hope I'm being understandable...

Nikos Alexandris:

> Absolutely :-).

Markus Neteler:

Since this questions comes up from time to time, it would be nice to get
the summary of this comparative discussion into the Wiki... volunteers
needed.

Already started working it out! If there are no objections, leave it to me.
Please, consider assistance in reviewing it in the end, which is after all
always useful.

Thanks, Nikos

Rebecca_Bennett · November 1, 2012, 1:23pm

Hello all,

Unfortunately I’m really struggling with getting the plugins to work on Grass 6.4.2 Ubuntu 12.04 so I’m hoping someone can help!

I spotted this listing for the exact same problem http://osgeo-org.1560.n6.nabble.com/installing-addons-grass-6-4-3svn-ubuntu-11-10-td4498897.html
and tried to follow the instuctions it linked to for compiling grass with Debian rules but I get stuck here:

# In your favorite text editor open debian/changelog and adjust the
# version number on the top line to reflect the GRASS SVN checkout number.
# e.g. for r50540: grass (6.4.2~rc3+svn50540-0) unstable; urgency=low

  nano debian/changelog

But there is no changelog file, only a changelog.gz. So I edited the file in the gz as instructed and extracted it to the debian folder.
Now when I try to run debuild -i -uc -us -b

debuild: fatal error at line 627:
cannot find readable debian/changelog anywhere!
Are you in the source code tree?

I don’t know what to do next so if anyone could help I would be very, very grateful!

Many thanks for reading,
Rebecca

From: Rebecca Bennett rabennett@ymail.com
To: Margherita Di Leo diregola@gmail.com
Cc: “grass-user@lists.osgeo.org” grass-user@lists.osgeo.org
Sent: Wednesday, 31 October 2012, 10:56
Subject: Re: [GRASS-user] Unable to locate Curses Includes

Great thanks Madi - I’d used that approach for the two earlier errors when running this command but couldn’t find a package relating to curses in my search for unintalled packages (probably due to the curses but being surrounded by other letters!)

Incedentally non-of the add-ons are working through the gui - I know this is a freqently reported problem to which the only guaranteed solution (after scouring the mailing list and trying solutions posted here http://planetflux.adamwilson.us/2012/02/installing-grass-extensions-on-ubuntu.html and http://comments.gmane.org/gmane.comp.gis.grass.user/43974) appears to be to compile from source.

…I wanted large file support anyway so I was just being lazy to only use the Ubuntu:GIS repository version

cheers!
Rebecca
From: Margherita Di Leo diregola@gmail.com
To: Rebecca Bennett rabennett@ymail.com
Cc: “grass-user@lists.osgeo.org” grass-user@lists.osgeo.org
Sent: Wednesday, 31 October 2012, 10:46
Subject: Re: [GRASS-user] Unable to locate Curses Includes

Dear Rebecca,

On Wed, Oct 31, 2012 at 3:30 PM, Rebecca Bennett <rabennett@ymail.com> wrote:

Dear Grass Users,

Trying to compile 6.4.3 from source on Ubuntu 12.04 in order to get at the add-ons which are not working in my prepackaged install.

Which add-on is not working?
Following these instructions (http://grass.osgeo.org/wiki/Compile_and_Install_Ubuntu) I check out the release_20121024_grass_6_4_3RC1 get as far as
./configure \

but get the following error:
checking for long long int... yes
checking for W11... no
checking for X... no
checking whether to use Curses... yes
checking for curses.h... no
configure: error: *** Unable to locate curses includes.

Any suggestions / ideas welcome!
I think you miss libncurses5-dev.
In general, when you get an error like this, you can do the search yourself here: http://packages.ubuntu.com/
You have to search “contents of packages” and specify your version/distribution.

Hope this helps,

madi

–
Margherita DI LEO

Postdoctoral Researcher
European Commission - DG JRC
Forest Resources and Climate
I-21020 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-leo@jrc.ec.europa.eu
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Rebecca_Bennett · November 5, 2012, 6:07pm

Hello,

Can anyone help with this problem?

Following these instructions for a debian build of Grass http://svn.osgeo.org/grass/grass/branches/releasebranch_6_4/debian/README.debian

I get to:

debuild -i -uc -us -b

debuild: found debian/changelog for package grass in the directory
/home/becca/debiangis
but this directory name does not match the package name according to the
regex PACKAGE(-.+)?.

I have edited the changelog to reflect the SVN checkout number so the first line of the file now reads

grass (6.4.3~rc1+svn53691) unstable; urgency=low

but I think I have the annotation wrong?

Any help much appreciated!
Rebecca

NikosAlexandris · November 6, 2012, 10:21am

Markus Neteler:

> Since this questions comes up from time to time, it would be nice to get
> the summary of this comparative discussion into the Wiki... volunteers
> needed.

Nikos:

Already started working it out! If there are no objections, leave it to me.
Please, consider assistance in reviewing it in the end, which is after all
always useful.

I have filtered sentence by sentence the discussions, the manuals and the GRASS
4 Image Processing Tutorial. I am (almost) ready scratching a final version of
a text explaining

(not how i.cluster works -- this is already well documented, though some
wording changes might not be bad to improve the existing manual)

the differences/similarities between the algorithm behind i.cluster and the
ISODATA algorithm. It might be also worthy to summarise the information in a
table, instead of a big text -- or in addition(?). However, I don't think
that something like "i.cluster vs ISODATA" could be a valid title. i.cluster
is a module implementing some (step of an) algorithm. ISODATA is an algorithm
per se.

Ideas for a/the (wiki-page-)title?

- Clustering based on i.cluster
- Clustering algorithm in i.cluster
- Unsupervised clustering based on i.cluster
- Unsupervised clustering via i.cluster

Nikos

NikosAlexandris · February 23, 2013, 10:40am

Nikos Alexandris wrote:
..

Ideas for a/the (wiki-page-)title?

- Clustering based on i.cluster
- Clustering algorithm in i.cluster
- Unsupervised clustering based on i.cluster
- Unsupervised clustering via i.cluster

I still haven't created that page. I will.

There is, however, a small detail which makes me think if implementing an
ISODATA algorithm for grass is useful after all:

the ISODATA algorithm can run on a single band/raster -- i.cluster requires
at least two.

Best, Nikos

NikosAlexandris · February 23, 2013, 2:36pm

Nikos Alexandris wrote:

> Ideas for a/the (wiki-page-)title?
> - Clustering based on i.cluster
> - Clustering algorithm in i.cluster
> - Unsupervised clustering based on i.cluster
> - Unsupervised clustering via i.cluster

Nikos A:

I still haven't created that page. I will.

There is, however, a small detail which makes me think if implementing an
ISODATA algorithm for grass is useful after all:

the ISODATA algorithm can run on a single band/raster -- i.cluster
requires at least two.

Maybe of interest (?):

A GPL-ed "Fast implementation of the ISODATA clustering algorithm":

<http://www.cs.umd.edu/~mount/Projects/ISODATA/>

Best, Nikos