Hi devs, Yann,
On Wed, Jan 12, 2011 at 5:35 AM, <svn_grass@osgeo.org> wrote:
Author: ychemin
Date: 2011-01-11 20:35:12 -0800 (Tue, 11 Jan 2011)
New Revision: 44977Added:
grass/trunk/imagery/i.evapo.PT/
grass/trunk/imagery/i.evapo.PT/i.evapo.PT.html
...
I wonder how to deal with CAPS module names. Personally, I would
prefer to avoid them.
Any opinions?
Markus
yeah no problem to move to small caps, initial reason was that it was
Family names abbreviation...
+1 to avoid them too
On 12 January 2011 20:13, Markus Neteler <neteler@osgeo.org> wrote:
Hi devs, Yann,
On Wed, Jan 12, 2011 at 5:35 AM, <svn_grass@osgeo.org> wrote:
Author: ychemin
Date: 2011-01-11 20:35:12 -0800 (Tue, 11 Jan 2011)
New Revision: 44977Added:
grass/trunk/imagery/i.evapo.PT/
grass/trunk/imagery/i.evapo.PT/i.evapo.PT.html...
I wonder how to deal with CAPS module names. Personally, I would
prefer to avoid them.
Any opinions?Markus
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Yann Chemin
www.csu.edu.au
Hi,
2011/1/12 Yann Chemin <yann.chemin@gmail.com>:
yeah no problem to move to small caps, initial reason was that it was
Family names abbreviation...+1 to avoid them too
please do.
Other issue, probably there should be discussion about new modules -
if to add them to trunk or leave them in addons. My personal
experience is that most of users (students at my courses) are confused
by number or GRASS modules. I really like idea of toolboxes which
presented Jarek some time ago [1]. Trunk should contain only core
modules from this perspective.
Martin
[1] http://lists.osgeo.org/pipermail/grass-dev/2010-April/050210.html
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
Hi Martin,
(Thx, did not read that one yet, so did now)
I would tend to agree with Jarek too.
The use of Module keywords should facilitate the three layers
mentioned, and maybe special keywords like "core", "toolbox",
"experimental" could permit three levels of compilation of GRASS GIS
(Basic, Advanced, Dev).
Yann
On 12 January 2011 22:35, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2011/1/12 Yann Chemin <yann.chemin@gmail.com>:
yeah no problem to move to small caps, initial reason was that it was
Family names abbreviation...+1 to avoid them too
please do.
Other issue, probably there should be discussion about new modules -
if to add them to trunk or leave them in addons. My personal
experience is that most of users (students at my courses) are confused
by number or GRASS modules. I really like idea of toolboxes which
presented Jarek some time ago [1]. Trunk should contain only core
modules from this perspective.Martin
[1] http://lists.osgeo.org/pipermail/grass-dev/2010-April/050210.html
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
--
Yann Chemin
www.csu.edu.au
Hi,
2011/1/12 Yann Chemin <yann.chemin@gmail.com>:
(Thx, did not read that one yet, so did now)
I would tend to agree with Jarek too.
The use of Module keywords should facilitate the three layers
mentioned, and maybe special keywords like "core", "toolbox",
"experimental" could permit three levels of compilation of GRASS GIS
(Basic, Advanced, Dev).
user should have possibility to easily install
1) whole toolboxes, eg. `g.toolbox toolbox=hydrology` would install
all modules related to hydrology
2) modules, eg. g.extension extension=r.stream` would install only
given module (or it could be integrated in g.toolbox)
Of course we could distribute packages with common toolboxes like now
we are doing. I think it would make development more transparent. The
core would contain only libs and small subset of modules with high
stability (grass/trunk), toolboxes maintained and stable modules
(grass-tools/trunk) and the reset could be in grass-addons.
Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
2011/1/12 Yann Chemin <yann.chemin@gmail.com>:
2011/1/12 Yann Chemin <yann.chemin@gmail.com>:
yeah no problem to move to small caps, initial reason was that it was
Family names abbreviation...
before adding new and new modules I would really like some discussion
on ML if the module needs to be in trunk. E.g. at least most of
modules which you have added recently breaks syntax convencion, eg.
1) don't use caps in module name
2) missing keywords
3) Flag's description should start with caps
4) Completely strange parameter names, besides caps again.
I'ts just subset, unfortunately...
Martin
Description:
Evapotranspiration Calculation Prestley and Taylor formulation, 1972.
Usage:
i.evapo.PT [-z] RNET=[W/m2] G0=[W/m2] TEMPKA=[K] PATM=[millibars]
PT=[-] output=[mm/d] [--overwrite] [--verbose] [--quiet]
Flags:
-z set negative ETa to zero
--o Allow output files to overwrite existing files
--v Verbose module output
--q Quiet module output
Parameters:
RNET Name of Net Radiation raster map
G0 Name of Soil Heat Flux raster map
TEMPKA Name of air temperature raster map
PATM Name of Atmospheric Pressure raster map
PT Prestley-Taylor Coefficient
default: 1.26
output Name of output Evapotranspiration layer
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
Hi Martin I agree with all that you say, my mistakes, and sorry for
still making some.
However, parameters names are certainly specialized
abbreviations/names, but not strange to certain fields of
hydrology/RS.
I'll run through those and correct.
Yann
On 13 January 2011 02:48, Martin Landa <landa.martin@gmail.com> wrote:
2011/1/12 Yann Chemin <yann.chemin@gmail.com>:
2011/1/12 Yann Chemin <yann.chemin@gmail.com>:
yeah no problem to move to small caps, initial reason was that it was
Family names abbreviation...before adding new and new modules I would really like some discussion
on ML if the module needs to be in trunk. E.g. at least most of
modules which you have added recently breaks syntax convencion, eg.1) don't use caps in module name
2) missing keywords
3) Flag's description should start with caps
4) Completely strange parameter names, besides caps again.I'ts just subset, unfortunately...
Martin
Description:
Evapotranspiration Calculation Prestley and Taylor formulation, 1972.Usage:
i.evapo.PT [-z] RNET=[W/m2] G0=[W/m2] TEMPKA=[K] PATM=[millibars]
PT=[-] output=[mm/d] [--overwrite] [--verbose] [--quiet]Flags:
-z set negative ETa to zero
--o Allow output files to overwrite existing files
--v Verbose module output
--q Quiet module outputParameters:
RNET Name of Net Radiation raster map
G0 Name of Soil Heat Flux raster map
TEMPKA Name of air temperature raster map
PATM Name of Atmospheric Pressure raster map
PT Prestley-Taylor Coefficient
default: 1.26
output Name of output Evapotranspiration layer--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
--
Yann Chemin
www.csu.edu.au
oh well Martin, you are also right about the parameter names, too
abbreviated, steeper learning curve.
I see you already corrected what you mentioned was not the convention
over the night. thanks
On 13 January 2011 09:27, Yann Chemin <yann.chemin@gmail.com> wrote:
Hi Martin I agree with all that you say, my mistakes, and sorry for
still making some.
However, parameters names are certainly specialized
abbreviations/names, but not strange to certain fields of
hydrology/RS.I'll run through those and correct.
YannOn 13 January 2011 02:48, Martin Landa <landa.martin@gmail.com> wrote:
2011/1/12 Yann Chemin <yann.chemin@gmail.com>:
2011/1/12 Yann Chemin <yann.chemin@gmail.com>:
yeah no problem to move to small caps, initial reason was that it was
Family names abbreviation...before adding new and new modules I would really like some discussion
on ML if the module needs to be in trunk. E.g. at least most of
modules which you have added recently breaks syntax convencion, eg.1) don't use caps in module name
2) missing keywords
3) Flag's description should start with caps
4) Completely strange parameter names, besides caps again.I'ts just subset, unfortunately...
Martin
Description:
Evapotranspiration Calculation Prestley and Taylor formulation, 1972.Usage:
i.evapo.PT [-z] RNET=[W/m2] G0=[W/m2] TEMPKA=[K] PATM=[millibars]
PT=[-] output=[mm/d] [--overwrite] [--verbose] [--quiet]Flags:
-z set negative ETa to zero
--o Allow output files to overwrite existing files
--v Verbose module output
--q Quiet module outputParameters:
RNET Name of Net Radiation raster map
G0 Name of Soil Heat Flux raster map
TEMPKA Name of air temperature raster map
PATM Name of Atmospheric Pressure raster map
PT Prestley-Taylor Coefficient
default: 1.26
output Name of output Evapotranspiration layer--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa--
Yann Chemin
www.csu.edu.au
--
Yann Chemin
www.csu.edu.au
I just noticed that GRASS GUI Help needs update for GRASS6.4.1, especially the screenshot
of GIS Layer manager is quite different from what it looks like now. Martin, perhaps you can
replace the image to keep it consistent?
Also the explanation of Show GUI settings button and Start Graphical modeler is missing
Helena
Perhaps it would be a good idea to put all of the suggestions on a wiki page and include a draft list of core modules,
to see how easy it will be to agree on them. For example I would like to keep the simwe modules outside the core
but readily available in binaries - we use it a lot but it is very specialized.
There are several add ons that would be great to have either in core or more
readily available in binaries within toolboxes.
Helena
P.S. It looks like the windows daily snapshots for grass70 http://josef.fsv.cvut.cz/wingrass/grass70/ is down?
On Jan 12, 2011, at 6:53 AM, Martin Landa wrote:
Hi,
2011/1/12 Yann Chemin <yann.chemin@gmail.com>:
(Thx, did not read that one yet, so did now)
I would tend to agree with Jarek too.
The use of Module keywords should facilitate the three layers
mentioned, and maybe special keywords like "core", "toolbox",
"experimental" could permit three levels of compilation of GRASS GIS
(Basic, Advanced, Dev).user should have possibility to easily install
1) whole toolboxes, eg. `g.toolbox toolbox=hydrology` would install
all modules related to hydrology2) modules, eg. g.extension extension=r.stream` would install only
given module (or it could be integrated in g.toolbox)Of course we could distribute packages with common toolboxes like now
we are doing. I think it would make development more transparent. The
core would contain only libs and small subset of modules with high
stability (grass/trunk), toolboxes maintained and stable modules
(grass-tools/trunk) and the reset could be in grass-addons.Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
+1
It may also be easy to agree on modules belonging to specialised
themes (i.e. hydrology is a strong one in GRASS)
yes, snapshot builds for Wingrass are down even for down under... Many
modules did not compile in imagery for the last several builds too
On 13 January 2011 15:17, Helena Mitasova <hmitaso@unity.ncsu.edu> wrote:
Perhaps it would be a good idea to put all of the suggestions on a wiki page and include a draft list of core modules,
to see how easy it will be to agree on them. For example I would like to keep the simwe modules outside the core
but readily available in binaries - we use it a lot but it is very specialized.
There are several add ons that would be great to have either in core or more
readily available in binaries within toolboxes.Helena
P.S. It looks like the windows daily snapshots for grass70 http://josef.fsv.cvut.cz/wingrass/grass70/ is down?
On Jan 12, 2011, at 6:53 AM, Martin Landa wrote:
Hi,
2011/1/12 Yann Chemin <yann.chemin@gmail.com>:
(Thx, did not read that one yet, so did now)
I would tend to agree with Jarek too.
The use of Module keywords should facilitate the three layers
mentioned, and maybe special keywords like "core", "toolbox",
"experimental" could permit three levels of compilation of GRASS GIS
(Basic, Advanced, Dev).user should have possibility to easily install
1) whole toolboxes, eg. `g.toolbox toolbox=hydrology` would install
all modules related to hydrology2) modules, eg. g.extension extension=r.stream` would install only
given module (or it could be integrated in g.toolbox)Of course we could distribute packages with common toolboxes like now
we are doing. I think it would make development more transparent. The
core would contain only libs and small subset of modules with high
stability (grass/trunk), toolboxes maintained and stable modules
(grass-tools/trunk) and the reset could be in grass-addons.Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Yann Chemin
www.csu.edu.au
Hi,
2011/1/13 Helena Mitasova <hmitaso@unity.ncsu.edu>:
I just noticed that GRASS GUI Help needs update for GRASS6.4.1, especially the screenshot
of GIS Layer manager is quite different from what it looks like now. Martin, perhaps you can
replace the image to keep it consistent?
Also the explanation of Show GUI settings button and Start Graphical modeler is missing
done in r45011.
Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
On Thu, Jan 13, 2011 at 5:17 AM, Helena Mitasova <hmitaso@unity.ncsu.edu> wrote:
Perhaps it would be a good idea to put all of the suggestions on a wiki page
and include a draft list of core modules,
to see how easy it will be to agree on them.
Yes.
For example I would like to keep the simwe modules outside the core
but readily available in binaries - we use it a lot but it is very specialized.
There are several add ons that would be great to have either in core or more
readily available in binaries within toolboxes.
I could set up a compile toolchain on the GRASS server to have Linux binaries
of the addons. Maybe William would do the same for Mac and Martin (who
does already enough!) or Helmut or .. for Windows.
[still I don't know how to generate 32bit binaries on the 64bit Linux server...]
Markus
2011/1/14 Markus Neteler <neteler@osgeo.org>:
On Thu, Jan 13, 2011 at 5:17 AM, Helena Mitasova <hmitaso@unity.ncsu.edu> wrote:
Perhaps it would be a good idea to put all of the suggestions on a wiki page
and include a draft list of core modules,
to see how easy it will be to agree on them.Yes.
http://grass.osgeo.org/wiki/GRASS_repository_layout_proposal
Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa