[GRASS-SVN] r33808 - in grass-addons/raster/mcda: r.mcda.electre
r.mcda.fuzzy r.mcda.regime r.roughset
svn_grass at osgeo.org
svn_grass at osgeo.org
Fri Oct 10 09:39:58 EDT 2008
Author: gianluca
Date: 2008-10-10 09:39:57 -0400 (Fri, 10 Oct 2008)
New Revision: 33808
Removed:
grass-addons/raster/mcda/r.mcda.electre/COMMENTS
grass-addons/raster/mcda/r.mcda.electre/r.mcda.electre.tmp.html
grass-addons/raster/mcda/r.mcda.fuzzy/COMMENTS
grass-addons/raster/mcda/r.mcda.regime/COMMENTS
grass-addons/raster/mcda/r.mcda.regime/r.mcda.regime.tmp.html
grass-addons/raster/mcda/r.roughset/README.txt
grass-addons/raster/mcda/r.roughset/VERSIONE.txt
grass-addons/raster/mcda/r.roughset/description.html
grass-addons/raster/mcda/r.roughset/r.roughset.tmp.html
Log:
geographics multi-criteria analysis and knowledge discovery
Deleted: grass-addons/raster/mcda/r.mcda.electre/COMMENTS
===================================================================
--- grass-addons/raster/mcda/r.mcda.electre/COMMENTS 2008-10-10 13:07:46 UTC (rev 33807)
+++ grass-addons/raster/mcda/r.mcda.electre/COMMENTS 2008-10-10 13:39:57 UTC (rev 33808)
@@ -1,211 +0,0 @@
-From: Glynn Clements <glynn.clements at virgin.net>
-Date: Tue, 5 Mar 2002 16:44:33 +0000
-To: Markus Neteler <neteler at itc.it>
-Subject: Re: Question on raster programming
-
-
-Markus Neteler wrote:
-
-> may I ask you for some assistance for a simple example on
-> GRASS raster programming?
-> I would like to have r.example as reference for raster
-> programming. The module will do nothing exciting but show
-> how to deal with the different precisions.
->
-> the line in question is the inner col-loop, where I
-> copy the cell values from the old to the new map.
-> It does not compile due to the variable definition.
->
-> In old modules I have seen ugly things to deal with
-> INT, FCELL and DCELL (lots of cases etc). Probably it
-> is much more simple using the
->
-> void *inrast;
->
-> definition on top. But then, I don't understand to access
-> it... Yes, programming newbie question. Perhaps you have the
-> patience to help me. I have several older modules in the queue
-> which I would like to release after an update. Before hacking
-> in lots of case statements, I prefer to learn the up-to-date
-> method.
-
-If you want to handle multiple data types, you generally[1] have to
-use a switch statement.
-
-[1] If you are only copying values, you can use other methods (e.g.
-memcpy), but if you wish to actually process the cell values, they
-need to be stored in a variable of the appropriate type.
-
-Suppose you wanted the equivalent of:
-
- r.mapcalc 'out = f(in)'
-
-The main loop would look something like:
-
- extern CELL f_c(CELL);
- extern FCELL f_f(FCELL);
- extern DCELL f_d(DCELL);
-
- ...
-
- for (col=0; col < ncols; col++)
- {
- CELL c;
- FCELL f;
- DCELL d;
-
- switch (data_type)
- {
- case CELL_TYPE:
- c = ((CELL *) inrast)[col];
- c = f_c(c);
- ((CELL *) outrast)[col] = c;
- break;
- case FCELL_TYPE:
- f = ((FCELL *) inrast)[col];
- f = f_f(f);
- ((FCELL *) outrast)[col] = f;
- break;
- case DCELL_TYPE:
- d = ((DCELL *) inrast)[col];
- d = f_d(d);
- ((DCELL *) outrast)[col] = d;
- break;
- }
- }
-
-In the most extreme case, you might have nested switch statements to
-deal with all of the different combinations of input/output types.
-
-If it isn't important that the operation is done at the map's native
-precision, a simpler approach is to just use DCELL values and let the
-G_{get,put}_*_row functions handle the conversion, e.g.
-
- DCELL f_d(DCELL x)
- {
- /* some function */
- return x;
- }
-
- extern DCELL f_d(DCELL);
-
- ...
-
- DCELL *inrast = G_allocate_d_raster_buf();
- DCELL *outrast = G_allocate_d_raster_buf();
-
- for (row = 0; row < nrows; row++)
- {
- if (G_get_d_raster_row (infd, inrast, row) < 0)
- G_fatal_error(...);
-
- for (col=0; col < ncols; col++)
- outrast[col] = f_d(inrast[col]);
-
- if (G_put_d_raster_row (outfd, outrast) < 0)
- G_fatal_error(...);
- }
-
-One other comment about the example: it isn't necessary to use
-sprintf() to format error messages; G_fatal_error() takes a format
-string and arguments, e.g.
-
- G_fatal_error("cell file [%s] not found", name);
-
---
-Glynn Clements <glynn.clements at virgin.net>
-
-From: Glynn Clements <glynn.clements at virgin.net>
-Date: Thu, 7 Mar 2002 16:51:43 +0000
-To: Markus Neteler <neteler at itc.it>
-Subject: Re: Question on raster programming
-
-
-Markus Neteler wrote:
-
-> What do you think about the macro method implemented in
-> r.sunmask (src/raster/r.sunmask/)? Is that a good
-> or possibly slowing down the module for FCELL and DCELL
-> (in fact it's incredible slow, just for INT DEMs it is acceptable).
-
-In the case of r.sunmask, the raster_value() macro/function is
-pointless. The data is always converted to DCELL before being used;
-the code should just allocate DCELL buffers and read the data with
-G_get_d_raster_row().
-
-As for speed, I wouldn't have thought that type-handling logic would
-be significant compared to the amount of work that's done in the
-various G_get_*_row() functions.
-
-Most code should probably just work with DCELL values, and let libgis
-perform the conversions, unless the code is only applicable to CELL
-values, or it handles CELL values differently.
-
---
-Glynn Clements <glynn.clements at virgin.net>
-
-
-Markus Neteler wrote:
-
-> sorry to bother you again. I am now continuing to write
-> r.example (which just copies a file) to have an example
-> on raster programming. Maybe you recall our conversation on
-> that some time ago (find it attached as well).
->
-> A remaining question is how to define this:
->
-> extern CELL f_c(CELL);
-> extern FCELL f_f(FCELL);
-> extern DCELL f_d(DCELL);
->
-> f_c, f_f, f_d
->
-> Sorry for this question, but I am clueless here.
-
-For copying a file, these would just be identity functions, e.g.
-
- CELL f_c(CELL x)
- {
- return x;
- }
-
-Actually, there aren't many things which you could do within that
-framework. For most practical applications, a cell in the output map
-would depend upon more than just the corresponding cell in a single
-input map. You would typically have multiple input maps, and/or use
-the values of multiple cells in computing the value of each output
-cell.
-
-Some other points:
-
-1. Copying input parameters into a buffer, i.e.:
-
- strcpy (name, option.input->answer);
- strcpy (result, option.output->answer);
-
-is usually unnecessary. Furthermore, it's something which should be
-discouraged, due to the usual problems with fixed-size buffers.
-
-2. Pre-formatting error/warning messages, e.g.:
-
- if (mapset == NULL)
- {
- char buf[200];
- sprintf (buf, "cell file [%s] not found", name);
- G_fatal_error (buf);
- }
-
-is unnecessary, as G_fatal_error() and G_warning() already do this,
-e.g.
-
- if (!mapset)
- G_fatal_error("cell file [%s] not found", name);
-
-3. Ideally, all abnormal exits would be via G_fatal_error(), rather
-than calling exit() directly.
-
-4. The value passed to exit() should be non-negative. exit(-1) is just
-a confusing way of writing exit(255).
-
---
-Glynn Clements <glynn.clements at virgin.net>
Deleted: grass-addons/raster/mcda/r.mcda.electre/r.mcda.electre.tmp.html
===================================================================
--- grass-addons/raster/mcda/r.mcda.electre/r.mcda.electre.tmp.html 2008-10-10 13:07:46 UTC (rev 33807)
+++ grass-addons/raster/mcda/r.mcda.electre/r.mcda.electre.tmp.html 2008-10-10 13:39:57 UTC (rev 33808)
@@ -1,44 +0,0 @@
-
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html><head><title>r.mcda.electre</title></head>
-<body>
-<h2 style="text-align: justify;">DESCRIPTION</h2>
-<div style="text-align: justify;"><span style="font-weight: bold;">r.mcda.electre </span>implementa
-l'algoritmo di analisi multi-criterio "ELECTRE" in ambiente GRASS GIS e
-costituisce uno dei tools disponibili nella suite r.mcda.<br>
-Richiede
-in input la lista dei raster che rappresentano i criteri da
-utilizzare nell'analisi multicriterio e il vettore dei pesi da inserire nello
-<span style="font-style: italic;">stesso ordine</span> di immissione di quello dei criteri. <br>
-Ogni singola i-esima cella della region di GRASS è considerata come una
-delle possibili alternative da valutare ed è descritta dai valori
-assunti per la stessa cella dai raster indicati come criteri.<br>L'output
-è costituito da due file di cui uno rappresenta la distribuzione
-spaziale dell'indice di concordanza ed uno quella dell'indice di
-discordanza. La localizzazione ottimale è quella che contemporaneamente
-ha ilmassimo valore di concordanza ed il minimo valore di discordanza
-rispetto ai criteri inseriti<br>
-<br>
-</div>
-<h2 style="text-align: justify;">NOTES</h2>
-<div style="text-align: justify;">Il modulo non opera
-alcun tipo di standardizzazione sui raster dei criteri che, pertanto, devono
-essere preventivemente preparati utilizzando, ad esempio, r.mapcalc. Il
-vettore dei pesi, invece, viene normalizzato sempre ad 1, quindi se
-l'immissione è già standardizzata il valore di ponderazione rimane
-inalterato, altrimente viene eseguito il calcolo che riporta la somma
-dei pesi ad un valore pari a 1.
-</div><h2 style="text-align: justify;">REFERENCE</h2>
-<div style="text-align: justify;">Yager R. (1977) -
-Multiple objective decision making using fuzzy set, Internationale
-Journal of Man-Machine Studies, 12, 299-322<br><br>GRASS Development Team (2008)<br><br></div><h2 style="text-align: justify;">SEE ALSO</h2>
-<div style="text-align: justify;"><em>r.mcda.regime,
-r.mcda.fuzzy, r.roughet, r.mapcalc</em><br>
-<em></em><em></em></div>
-<h2 style="text-align: justify;">AUTHORS</h2>
-<div style="text-align: justify;">Gianluca Massei - Antonio Boggia - Dipartimento di Scienze Economico Estimative e degli Alimenti - Università di Perugia - Italy
-</div>
-
-<p><i><br>
-</i></p>
-</body></html>
\ No newline at end of file
Deleted: grass-addons/raster/mcda/r.mcda.fuzzy/COMMENTS
===================================================================
--- grass-addons/raster/mcda/r.mcda.fuzzy/COMMENTS 2008-10-10 13:07:46 UTC (rev 33807)
+++ grass-addons/raster/mcda/r.mcda.fuzzy/COMMENTS 2008-10-10 13:39:57 UTC (rev 33808)
@@ -1,211 +0,0 @@
-From: Glynn Clements <glynn.clements at virgin.net>
-Date: Tue, 5 Mar 2002 16:44:33 +0000
-To: Markus Neteler <neteler at itc.it>
-Subject: Re: Question on raster programming
-
-
-Markus Neteler wrote:
-
-> may I ask you for some assistance for a simple example on
-> GRASS raster programming?
-> I would like to have r.example as reference for raster
-> programming. The module will do nothing exciting but show
-> how to deal with the different precisions.
->
-> the line in question is the inner col-loop, where I
-> copy the cell values from the old to the new map.
-> It does not compile due to the variable definition.
->
-> In old modules I have seen ugly things to deal with
-> INT, FCELL and DCELL (lots of cases etc). Probably it
-> is much more simple using the
->
-> void *inrast;
->
-> definition on top. But then, I don't understand to access
-> it... Yes, programming newbie question. Perhaps you have the
-> patience to help me. I have several older modules in the queue
-> which I would like to release after an update. Before hacking
-> in lots of case statements, I prefer to learn the up-to-date
-> method.
-
-If you want to handle multiple data types, you generally[1] have to
-use a switch statement.
-
-[1] If you are only copying values, you can use other methods (e.g.
-memcpy), but if you wish to actually process the cell values, they
-need to be stored in a variable of the appropriate type.
-
-Suppose you wanted the equivalent of:
-
- r.mapcalc 'out = f(in)'
-
-The main loop would look something like:
-
- extern CELL f_c(CELL);
- extern FCELL f_f(FCELL);
- extern DCELL f_d(DCELL);
-
- ...
-
- for (col=0; col < ncols; col++)
- {
- CELL c;
- FCELL f;
- DCELL d;
-
- switch (data_type)
- {
- case CELL_TYPE:
- c = ((CELL *) inrast)[col];
- c = f_c(c);
- ((CELL *) outrast)[col] = c;
- break;
- case FCELL_TYPE:
- f = ((FCELL *) inrast)[col];
- f = f_f(f);
- ((FCELL *) outrast)[col] = f;
- break;
- case DCELL_TYPE:
- d = ((DCELL *) inrast)[col];
- d = f_d(d);
- ((DCELL *) outrast)[col] = d;
- break;
- }
- }
-
-In the most extreme case, you might have nested switch statements to
-deal with all of the different combinations of input/output types.
-
-If it isn't important that the operation is done at the map's native
-precision, a simpler approach is to just use DCELL values and let the
-G_{get,put}_*_row functions handle the conversion, e.g.
-
- DCELL f_d(DCELL x)
- {
- /* some function */
- return x;
- }
-
- extern DCELL f_d(DCELL);
-
- ...
-
- DCELL *inrast = G_allocate_d_raster_buf();
- DCELL *outrast = G_allocate_d_raster_buf();
-
- for (row = 0; row < nrows; row++)
- {
- if (G_get_d_raster_row (infd, inrast, row) < 0)
- G_fatal_error(...);
-
- for (col=0; col < ncols; col++)
- outrast[col] = f_d(inrast[col]);
-
- if (G_put_d_raster_row (outfd, outrast) < 0)
- G_fatal_error(...);
- }
-
-One other comment about the example: it isn't necessary to use
-sprintf() to format error messages; G_fatal_error() takes a format
-string and arguments, e.g.
-
- G_fatal_error("cell file [%s] not found", name);
-
---
-Glynn Clements <glynn.clements at virgin.net>
-
-From: Glynn Clements <glynn.clements at virgin.net>
-Date: Thu, 7 Mar 2002 16:51:43 +0000
-To: Markus Neteler <neteler at itc.it>
-Subject: Re: Question on raster programming
-
-
-Markus Neteler wrote:
-
-> What do you think about the macro method implemented in
-> r.sunmask (src/raster/r.sunmask/)? Is that a good
-> or possibly slowing down the module for FCELL and DCELL
-> (in fact it's incredible slow, just for INT DEMs it is acceptable).
-
-In the case of r.sunmask, the raster_value() macro/function is
-pointless. The data is always converted to DCELL before being used;
-the code should just allocate DCELL buffers and read the data with
-G_get_d_raster_row().
-
-As for speed, I wouldn't have thought that type-handling logic would
-be significant compared to the amount of work that's done in the
-various G_get_*_row() functions.
-
-Most code should probably just work with DCELL values, and let libgis
-perform the conversions, unless the code is only applicable to CELL
-values, or it handles CELL values differently.
-
---
-Glynn Clements <glynn.clements at virgin.net>
-
-
-Markus Neteler wrote:
-
-> sorry to bother you again. I am now continuing to write
-> r.example (which just copies a file) to have an example
-> on raster programming. Maybe you recall our conversation on
-> that some time ago (find it attached as well).
->
-> A remaining question is how to define this:
->
-> extern CELL f_c(CELL);
-> extern FCELL f_f(FCELL);
-> extern DCELL f_d(DCELL);
->
-> f_c, f_f, f_d
->
-> Sorry for this question, but I am clueless here.
-
-For copying a file, these would just be identity functions, e.g.
-
- CELL f_c(CELL x)
- {
- return x;
- }
-
-Actually, there aren't many things which you could do within that
-framework. For most practical applications, a cell in the output map
-would depend upon more than just the corresponding cell in a single
-input map. You would typically have multiple input maps, and/or use
-the values of multiple cells in computing the value of each output
-cell.
-
-Some other points:
-
-1. Copying input parameters into a buffer, i.e.:
-
- strcpy (name, option.input->answer);
- strcpy (result, option.output->answer);
-
-is usually unnecessary. Furthermore, it's something which should be
-discouraged, due to the usual problems with fixed-size buffers.
-
-2. Pre-formatting error/warning messages, e.g.:
-
- if (mapset == NULL)
- {
- char buf[200];
- sprintf (buf, "cell file [%s] not found", name);
- G_fatal_error (buf);
- }
-
-is unnecessary, as G_fatal_error() and G_warning() already do this,
-e.g.
-
- if (!mapset)
- G_fatal_error("cell file [%s] not found", name);
-
-3. Ideally, all abnormal exits would be via G_fatal_error(), rather
-than calling exit() directly.
-
-4. The value passed to exit() should be non-negative. exit(-1) is just
-a confusing way of writing exit(255).
-
---
-Glynn Clements <glynn.clements at virgin.net>
Deleted: grass-addons/raster/mcda/r.mcda.regime/COMMENTS
===================================================================
--- grass-addons/raster/mcda/r.mcda.regime/COMMENTS 2008-10-10 13:07:46 UTC (rev 33807)
+++ grass-addons/raster/mcda/r.mcda.regime/COMMENTS 2008-10-10 13:39:57 UTC (rev 33808)
@@ -1,211 +0,0 @@
-From: Glynn Clements <glynn.clements at virgin.net>
-Date: Tue, 5 Mar 2002 16:44:33 +0000
-To: Markus Neteler <neteler at itc.it>
-Subject: Re: Question on raster programming
-
-
-Markus Neteler wrote:
-
-> may I ask you for some assistance for a simple example on
-> GRASS raster programming?
-> I would like to have r.example as reference for raster
-> programming. The module will do nothing exciting but show
-> how to deal with the different precisions.
->
-> the line in question is the inner col-loop, where I
-> copy the cell values from the old to the new map.
-> It does not compile due to the variable definition.
->
-> In old modules I have seen ugly things to deal with
-> INT, FCELL and DCELL (lots of cases etc). Probably it
-> is much more simple using the
->
-> void *inrast;
->
-> definition on top. But then, I don't understand to access
-> it... Yes, programming newbie question. Perhaps you have the
-> patience to help me. I have several older modules in the queue
-> which I would like to release after an update. Before hacking
-> in lots of case statements, I prefer to learn the up-to-date
-> method.
-
-If you want to handle multiple data types, you generally[1] have to
-use a switch statement.
-
-[1] If you are only copying values, you can use other methods (e.g.
-memcpy), but if you wish to actually process the cell values, they
-need to be stored in a variable of the appropriate type.
-
-Suppose you wanted the equivalent of:
-
- r.mapcalc 'out = f(in)'
-
-The main loop would look something like:
-
- extern CELL f_c(CELL);
- extern FCELL f_f(FCELL);
- extern DCELL f_d(DCELL);
-
- ...
-
- for (col=0; col < ncols; col++)
- {
- CELL c;
- FCELL f;
- DCELL d;
-
- switch (data_type)
- {
- case CELL_TYPE:
- c = ((CELL *) inrast)[col];
- c = f_c(c);
- ((CELL *) outrast)[col] = c;
- break;
- case FCELL_TYPE:
- f = ((FCELL *) inrast)[col];
- f = f_f(f);
- ((FCELL *) outrast)[col] = f;
- break;
- case DCELL_TYPE:
- d = ((DCELL *) inrast)[col];
- d = f_d(d);
- ((DCELL *) outrast)[col] = d;
- break;
- }
- }
-
-In the most extreme case, you might have nested switch statements to
-deal with all of the different combinations of input/output types.
-
-If it isn't important that the operation is done at the map's native
-precision, a simpler approach is to just use DCELL values and let the
-G_{get,put}_*_row functions handle the conversion, e.g.
-
- DCELL f_d(DCELL x)
- {
- /* some function */
- return x;
- }
-
- extern DCELL f_d(DCELL);
-
- ...
-
- DCELL *inrast = G_allocate_d_raster_buf();
- DCELL *outrast = G_allocate_d_raster_buf();
-
- for (row = 0; row < nrows; row++)
- {
- if (G_get_d_raster_row (infd, inrast, row) < 0)
- G_fatal_error(...);
-
- for (col=0; col < ncols; col++)
- outrast[col] = f_d(inrast[col]);
-
- if (G_put_d_raster_row (outfd, outrast) < 0)
- G_fatal_error(...);
- }
-
-One other comment about the example: it isn't necessary to use
-sprintf() to format error messages; G_fatal_error() takes a format
-string and arguments, e.g.
-
- G_fatal_error("cell file [%s] not found", name);
-
---
-Glynn Clements <glynn.clements at virgin.net>
-
-From: Glynn Clements <glynn.clements at virgin.net>
-Date: Thu, 7 Mar 2002 16:51:43 +0000
-To: Markus Neteler <neteler at itc.it>
-Subject: Re: Question on raster programming
-
-
-Markus Neteler wrote:
-
-> What do you think about the macro method implemented in
-> r.sunmask (src/raster/r.sunmask/)? Is that a good
-> or possibly slowing down the module for FCELL and DCELL
-> (in fact it's incredible slow, just for INT DEMs it is acceptable).
-
-In the case of r.sunmask, the raster_value() macro/function is
-pointless. The data is always converted to DCELL before being used;
-the code should just allocate DCELL buffers and read the data with
-G_get_d_raster_row().
-
-As for speed, I wouldn't have thought that type-handling logic would
-be significant compared to the amount of work that's done in the
-various G_get_*_row() functions.
-
-Most code should probably just work with DCELL values, and let libgis
-perform the conversions, unless the code is only applicable to CELL
-values, or it handles CELL values differently.
-
---
-Glynn Clements <glynn.clements at virgin.net>
-
-
-Markus Neteler wrote:
-
-> sorry to bother you again. I am now continuing to write
-> r.example (which just copies a file) to have an example
-> on raster programming. Maybe you recall our conversation on
-> that some time ago (find it attached as well).
->
-> A remaining question is how to define this:
->
-> extern CELL f_c(CELL);
-> extern FCELL f_f(FCELL);
-> extern DCELL f_d(DCELL);
->
-> f_c, f_f, f_d
->
-> Sorry for this question, but I am clueless here.
-
-For copying a file, these would just be identity functions, e.g.
-
- CELL f_c(CELL x)
- {
- return x;
- }
-
-Actually, there aren't many things which you could do within that
-framework. For most practical applications, a cell in the output map
-would depend upon more than just the corresponding cell in a single
-input map. You would typically have multiple input maps, and/or use
-the values of multiple cells in computing the value of each output
-cell.
-
-Some other points:
-
-1. Copying input parameters into a buffer, i.e.:
-
- strcpy (name, option.input->answer);
- strcpy (result, option.output->answer);
-
-is usually unnecessary. Furthermore, it's something which should be
-discouraged, due to the usual problems with fixed-size buffers.
-
-2. Pre-formatting error/warning messages, e.g.:
-
- if (mapset == NULL)
- {
- char buf[200];
- sprintf (buf, "cell file [%s] not found", name);
- G_fatal_error (buf);
- }
-
-is unnecessary, as G_fatal_error() and G_warning() already do this,
-e.g.
-
- if (!mapset)
- G_fatal_error("cell file [%s] not found", name);
-
-3. Ideally, all abnormal exits would be via G_fatal_error(), rather
-than calling exit() directly.
-
-4. The value passed to exit() should be non-negative. exit(-1) is just
-a confusing way of writing exit(255).
-
---
-Glynn Clements <glynn.clements at virgin.net>
Deleted: grass-addons/raster/mcda/r.mcda.regime/r.mcda.regime.tmp.html
===================================================================
--- grass-addons/raster/mcda/r.mcda.regime/r.mcda.regime.tmp.html 2008-10-10 13:07:46 UTC (rev 33807)
+++ grass-addons/raster/mcda/r.mcda.regime/r.mcda.regime.tmp.html 2008-10-10 13:39:57 UTC (rev 33808)
@@ -1,43 +0,0 @@
-
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html><head><title>r.mcda.regime</title></head>
-<body>
-<h2 style="text-align: justify;">DESCRIPTION</h2>
-<div style="text-align: justify;"><span style="font-weight: bold;">r.mcda.regime </span>implementa
-l'algoritmo di analisi multi-criterio "REGIME" in ambiente GRASS GIS e
-costituisce uno dei tools disponibili nella suite r.mcda.<br>Richiede
-in input la lista dei raster che rappresentano i criteri da
-utilizzare nell'analisi multicriterio e il vettore dei pesi da inserire nello
-<span style="font-style: italic;">stesso ordine</span> di immissione di quello dei criteri. <br>
-Ogni singola i-esima cella della region di GRASS è considerata come una
-delle possibili alternative da valutare ed è descritta dai valori
-assunti per la stessa cella dai raster indicati come criteri.
-<br>
-</div>
-<h2 style="text-align: justify;">NOTES</h2>
-<div style="text-align: justify;">Il modulo non opera
-alcun tipo di standardizzazione sui raster dei criteri che, pertanto, devono
-essere preventivemente preparati utilizzando, ad esempio, r.mapcalc. Il
-vettore dei pesi, invece, viene normalizzato sempre ad 1, quindi se
-l'immissione è già standardizzata il valore di ponderazione rimane
-inalterato, altrimente viene eseguito il calcolo che riporta la somma
-dei pesi ad un valore pari a 1.
-</div>
-<h2 style="text-align: justify;">REFERENCE</h2>
-<div style="text-align: justify;"><br>
-Janssen R. (1994) - Multiobjective decision support for enviromental management, Kluwe Accademic Publishers.<br><br>GRASS Development Team (2008)<br><br><br>
-</div>
-<h2 style="text-align: justify;">SEE ALSO</h2>
-<div style="text-align: justify;"><em>r.mcda.fuzzy,
-r.mcda.electre, r.roughet, r.mapcalc</em><br>
-<em></em><em></em></div>
-<h2 style="text-align: justify;">AUTHORS</h2>
-<div style="text-align: justify;">Antonio Boggia - Gianluca Massei -
-Dipartimento di Scienze Economico Estimative e degli Alimenti -
-Università di Perugia - Italy
-</div>
-<p style="text-align: justify;">
-</p>
-<p><i><br>
-</i></p>
-</body></html>
\ No newline at end of file
Deleted: grass-addons/raster/mcda/r.roughset/README.txt
===================================================================
--- grass-addons/raster/mcda/r.roughset/README.txt 2008-10-10 13:07:46 UTC (rev 33807)
+++ grass-addons/raster/mcda/r.roughset/README.txt 2008-10-10 13:39:57 UTC (rev 33808)
@@ -1,10 +0,0 @@
-release 24 august 2008
-
-r.mcda package:
-->r.mcda.electre
-->r.mcda.fuzzy
-->r.mcda.regime
-->r.roughset
-
-gianluca massei (g_massa at libero.it)
-
Deleted: grass-addons/raster/mcda/r.roughset/VERSIONE.txt
===================================================================
--- grass-addons/raster/mcda/r.roughset/VERSIONE.txt 2008-10-10 13:07:46 UTC (rev 33807)
+++ grass-addons/raster/mcda/r.roughset/VERSIONE.txt 2008-10-10 13:39:57 UTC (rev 33808)
@@ -1,3 +0,0 @@
-versione stabile 18 giugno 2008
-
-autore: gianluca massei
\ No newline at end of file
Deleted: grass-addons/raster/mcda/r.roughset/description.html
===================================================================
--- grass-addons/raster/mcda/r.roughset/description.html 2008-10-10 13:07:46 UTC (rev 33807)
+++ grass-addons/raster/mcda/r.roughset/description.html 2008-10-10 13:39:57 UTC (rev 33808)
@@ -1,56 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html><head><title>r.roughset</title></head>
-<body><h2 style="text-align: justify;">NAME</h2><div style="text-align: justify;">
-<em><b>r.roughset</b></em> - Rough set based geographics knowledg
-</div><h2 style="text-align: justify;">KEYWORDS</h2><div style="text-align: justify;">
-raster, geographics knowledg<span style="font-weight: bold;"> </span>discovery
-</div><h2 style="text-align: justify;">SYNOPSIS</h2><div style="text-align: justify;">
-<b>r.roughset</b><br>
-<b>r.roughset help</b><br>
-<b>r.roughset</b> <b>attributes</b>=<em>string</em>[,<i>string</i>,...] <b>decision</b>=<em>string</em> <b>strategy</b>=<em>string</em> <b>InfoSys</b>=<em>string</em> [--<b>verbose</b>] [--<b>quiet</b>]
-
-
-</div><h3 style="text-align: justify;">Parameters:</h3><div style="text-align: justify;">
-</div><dl style="text-align: justify;"><dt><b>attributes</b>=<em>string[,<i>string</i>,...]</em></dt><dd>Input geographics attributes in information system</dd><dt><b>decision</b>=<em>string</em></dt><dd>Input geographics decision in information system</dd><dt><b>strategy</b>=<em>string</em></dt><dd>Choose strategy for generating rules</dd><dd>Options: <em>Very fast,Fast,Medium,Best,All,Low,Upp,Normal</em></dd><dt><b>InfoSys</b>=<em>string</em></dt><dd>Output information system file</dd><dd>Default: <em>InfoSys</em></dd></dl><br><br><h2 style="text-align: justify;">DESCRIPTION</h2><div style="text-align: justify;">
-
-<b>r.roughset </b>è un modulo che consente l'applicazione
-della rough set theory [] a database geografici in ambiente GRASS GIS.
-L'input è costituito da due gruppi di dati: <br>1. gli attributi
-geografici che costituiscono il sistema informativo della rough set
-analisys e che si ritiene siano sufficienti a descrivere un
-determinato fenomeno naturale, sociale od economico (<b>attributes</b>=<em>string[,<i>string</i>,...]</em>);<br>2.
-il tematismo decisionale nel quale sono identificate le aree per cui il
-fenomeno da studaire si è presentato con una certa modalità(<b>decision</b>=<em>string</em>);<br>Il
-sistema informativo così generato viene trattato con le funzioni della
-versione 2 delle rough set library (RSL, ver. 2.0) [1993,
-M.Gawrys, J.Sienkiewicz] secondo una delle strategie decisionali
-disponibili (<b>strategy</b>=<em>string</em>).<br><br>L'output è costituito da tre differenti files testuali, con prefisso definito dall'utente nel campo <b>InfoSys</b>=<em>string, </em>e in dettaglio:<br>a.
-file testo strutturato secondo lo standard suggerito dalla rough set
-library, contraddistinto dallo stesso nome indicato nel campo InfoSys
-senza ulteriori suffissi; non riveste particolare interesse per
-l'utente a meno che non si vogliano utilizare le RSL al di fuori
-dall'ambiente GIS;<br>b. file testo, contraddistinto dal suffisso .out,
-contenente le regole decisionali estratte dal sistema informativo
-geografico, oltre che il core e i ridotti; le regole
-decisionali sono nella forma: <span style="font-style: italic;">if ... then </span>e sono facilmente leggibile ed interpretabili dall'analista per finalità descritive del fenomeno oggetto di studio;<br>c.
-file shell bash, contraddistinto dal suffisso .out.sh, che serve ad
-elaborare i file utilizzati quali attributi nel sistema informativo
-e generare un nuovo file di classificazione e previsione del
-fenomeno oggetto di studio secondo le regole decisionali estratte; in
-altri termini serve e trasferire le regole decisionali al contesto
-geografico. Per fare ciò è sufficiente lanciare ilfile di shell
-all'interno di una sessione di GRASS e può essere opportunamente
-modificato per adattare gli output alle esigenze dell'utente.<br> ́<br><br></div><h2 style="text-align: justify;">NOTES</h2><div style="text-align: justify;">Il
-modulo è in grado di trattare raster di qualsiasi tipo
-(CELL,FCELL,DCELL) ma le elaborazioni vengono eseguite tutte su
-variabili di tipo intero (int) perchè questo è imposto dalle rough set
-library. Le regole decisionali, conseguentemente, restituiscono
-informazioni esclusivamente di tipo intero.<br></div><h2 style="text-align: justify;">REFERENCE</h2><div style="text-align: justify;">Pawlak Z. Rough Sets, International Journal of Information and Computer Science Vol. 11, No. 5, 1982, pp. 344-356.<br>Pawlak’91 Pawlak Z. Rough Sets, Theoretical Aspects of Reasoning about Data, Kluwer Academic Publishers, 1991.<br>Gawrys M., Sienkiewicz J. Rough Set Library - User's manual (ver. 2.0), September 1993<br><br><br>
-
-</div><h2 style="text-align: justify;">SEE ALSO</h2><div style="text-align: justify;">
-<em>r.mcda.fuzzy, r.mcda.electre, r.mcda.regime</em><br><em></em><em><a href="r.rescale.html"></a></em>
-
-</div><h2 style="text-align: justify;">AUTHORS</h2><div style="text-align: justify;">
-Gianluca Massei - Antonio Boggia - Dipartimento di Scienze Economico Estimative e degli Alimenti - Università di Perugia - Italy</div><p style="text-align: justify;"><br>
-
-</p><p><i><br></i></p></body></html>
\ No newline at end of file
Deleted: grass-addons/raster/mcda/r.roughset/r.roughset.tmp.html
===================================================================
--- grass-addons/raster/mcda/r.roughset/r.roughset.tmp.html 2008-10-10 13:07:46 UTC (rev 33807)
+++ grass-addons/raster/mcda/r.roughset/r.roughset.tmp.html 2008-10-10 13:39:57 UTC (rev 33808)
@@ -1,57 +0,0 @@
-
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html><head><title>r.roughset</title></head>
-<body><h2 style="text-align: justify;">NAME</h2><div style="text-align: justify;">
-<em><b>r.roughset</b></em> - Rough set based geographics knowledg
-</div><h2 style="text-align: justify;">KEYWORDS</h2><div style="text-align: justify;">
-raster, geographics knowledg<span style="font-weight: bold;"> </span>discovery
-</div><h2 style="text-align: justify;">SYNOPSIS</h2><div style="text-align: justify;">
-<b>r.roughset</b><br>
-<b>r.roughset help</b><br>
-<b>r.roughset</b> <b>attributes</b>=<em>string</em>[,<i>string</i>,...] <b>decision</b>=<em>string</em> <b>strategy</b>=<em>string</em> <b>InfoSys</b>=<em>string</em> [--<b>verbose</b>] [--<b>quiet</b>]
-
-
-</div><h3 style="text-align: justify;">Parameters:</h3><div style="text-align: justify;">
-</div><dl style="text-align: justify;"><dt><b>attributes</b>=<em>string[,<i>string</i>,...]</em></dt><dd>Input geographics attributes in information system</dd><dt><b>decision</b>=<em>string</em></dt><dd>Input geographics decision in information system</dd><dt><b>strategy</b>=<em>string</em></dt><dd>Choose strategy for generating rules</dd><dd>Options: <em>Very fast,Fast,Medium,Best,All,Low,Upp,Normal</em></dd><dt><b>InfoSys</b>=<em>string</em></dt><dd>Output information system file</dd><dd>Default: <em>InfoSys</em></dd></dl><br><br><h2 style="text-align: justify;">DESCRIPTION</h2><div style="text-align: justify;">
-
-<b>r.roughset </b>è un modulo che consente l'applicazione
-della rough set theory [] a database geografici in ambiente GRASS GIS.
-L'input è costituito da due gruppi di dati: <br>1. gli attributi
-geografici che costituiscono il sistema informativo della rough set
-analisys e che si ritiene siano sufficienti a descrivere un
-determinato fenomeno naturale, sociale od economico (<b>attributes</b>=<em>string[,<i>string</i>,...]</em>);<br>2.
-il tematismo decisionale nel quale sono identificate le aree per cui il
-fenomeno da studaire si è presentato con una certa modalità(<b>decision</b>=<em>string</em>);<br>Il
-sistema informativo così generato viene trattato con le funzioni della
-versione 2 delle rough set library (RSL, ver. 2.0) [1993,
-M.Gawrys, J.Sienkiewicz] secondo una delle strategie decisionali
-disponibili (<b>strategy</b>=<em>string</em>).<br><br>L'output è costituito da tre differenti files testuali, con prefisso definito dall'utente nel campo <b>InfoSys</b>=<em>string, </em>e in dettaglio:<br>a.
-file testo strutturato secondo lo standard suggerito dalla rough set
-library, contraddistinto dallo stesso nome indicato nel campo InfoSys
-senza ulteriori suffissi; non riveste particolare interesse per
-l'utente a meno che non si vogliano utilizare le RSL al di fuori
-dall'ambiente GIS;<br>b. file testo, contraddistinto dal suffisso .out,
-contenente le regole decisionali estratte dal sistema informativo
-geografico, oltre che il core e i ridotti; le regole
-decisionali sono nella forma: <span style="font-style: italic;">if ... then </span>e sono facilmente leggibile ed interpretabili dall'analista per finalità descritive del fenomeno oggetto di studio;<br>c.
-file shell bash, contraddistinto dal suffisso .out.sh, che serve ad
-elaborare i file utilizzati quali attributi nel sistema informativo
-e generare un nuovo file di classificazione e previsione del
-fenomeno oggetto di studio secondo le regole decisionali estratte; in
-altri termini serve e trasferire le regole decisionali al contesto
-geografico. Per fare ciò è sufficiente lanciare ilfile di shell
-all'interno di una sessione di GRASS e può essere opportunamente
-modificato per adattare gli output alle esigenze dell'utente.<br> ́<br><br></div><h2 style="text-align: justify;">NOTES</h2><div style="text-align: justify;">Il
-modulo è in grado di trattare raster di qualsiasi tipo
-(CELL,FCELL,DCELL) ma le elaborazioni vengono eseguite tutte su
-variabili di tipo intero (int) perchè questo è imposto dalle rough set
-library. Le regole decisionali, conseguentemente, restituiscono
-informazioni esclusivamente di tipo intero.<br></div><h2 style="text-align: justify;">REFERENCE</h2><div style="text-align: justify;">Pawlak Z. Rough Sets, International Journal of Information and Computer Science Vol. 11, No. 5, 1982, pp. 344-356.<br>Pawlak’91 Pawlak Z. Rough Sets, Theoretical Aspects of Reasoning about Data, Kluwer Academic Publishers, 1991.<br>Gawrys M., Sienkiewicz J. Rough Set Library - User's manual (ver. 2.0), September 1993<br><br><br>
-
-</div><h2 style="text-align: justify;">SEE ALSO</h2><div style="text-align: justify;">
-<em>r.mcda.fuzzy, r.mcda.electre, r.mcda.regime</em><br><em></em><em><a href="r.rescale.html"></a></em>
-
-</div><h2 style="text-align: justify;">AUTHORS</h2><div style="text-align: justify;">
-Gianluca Massei - Antonio Boggia - Dipartimento di Scienze Economico Estimative e degli Alimenti - Università di Perugia - Italy</div><p style="text-align: justify;"><br>
-
-</p><p><i><br></i></p></body></html>
\ No newline at end of file
More information about the grass-commit
mailing list