Hi list,
as a regular user of MODIS, I would like to call other MODIS users to express interest to include r.modis into GRASS 7 SVN.
Cheers,
Yann
–
Yann Chemin
On Tuesday 30 of October 2012 11:31:49 Yann Chemin wrote:
Hi list,
as a regular user of MODIS, I would like to call other MODIS users to
express interest to include r.modis into GRASS 7 SVN.
Herewith I express my HUGE interest in the integration of r.modis into GRASS 7
SVN.
Thank you for the great work, Nikos
ps- my statement is, though, inexpensive as I am currently without a real work
Hi,
2012/10/30 Yann Chemin <yann.chemin@gmail.com>:
as a regular user of MODIS, I would like to call other MODIS users to
express interest to include r.modis into GRASS 7 SVN.
we cannot extend number of modules in trunk forever. Probably some
modules should be reviewed and moved to addons.
Do you have any problem with installing r.modis using g.extension?
Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
Hi Martin,
I have no worries, since I do load modules directly. I am worried about the learning curve for Windows-bound students in need of MODIS images, but not comfortable with GRASS GIS yet.
But this is an old story coming back,
I am all for reducing significantly the number of modules in GRASS, to have a lean download.
We can indeed have groups of plugins to get through g.extension:
- Hydrologically related
- Imagery
- Temporal
- 3D
- DB (though I am not a user, so cannot be sure of how much needed)
This would keep import/export, some of the basic raster and vector ones. Neat small download, use g.extension for anything else, by group or on demand.
Yann
On 30 October 2012 15:08, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2012/10/30 Yann Chemin <yann.chemin@gmail.com>:
as a regular user of MODIS, I would like to call other MODIS users to
express interest to include r.modis into GRASS 7 SVN.we cannot extend number of modules in trunk forever. Probably some
modules should be reviewed and moved to addons.Do you have any problem with installing r.modis using g.extension?
Martin
–
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
–
Yann Chemin
I would like to express a different point of view.
One of the nice things about GRASS in its current
form is that one download will get you hundreds
of modules without having to worry about installing
add-ons.
What's the difference between having 300 or 500
modules in the base distribution? GRASS has the
file layout required to scale up to this size
easily, and each individual module is small and
lean. Even if we were to triple the number of
modules in the base distribution, the download
size would not increase significantly (and vice
versa).
On the other hand:
- Having to compile add-ons written in C/C++ is a
big obstace, g.extension or not, for many users,
especially on Windows.
- It is hard to ensure consistent quality across
external add-ons.
- Documentation for such add-ons cannot be included
in the main online index.
- There is always a risk that useful add-ons maintained
by external developers will be abandoned.
- Putting modules into extension groups will never
be free of overlap and always leave people wondering
where the wanted module is. The basic r.*, v.* etc.
and some good keywords are a much better system IMHO.
So I am not convinced about the merits of breaking
the GRASS distribution into smaller pieces and add-ons.
Instead, I would say the base distribution should grow
as required and include new, useful modules such as r.modis.
Cheers,
Ben
On 10/30/2012 11:43 AM, Yann Chemin wrote:
Hi Martin,
I have no worries, since I do load modules directly. I am worried about
the learning curve for Windows-bound students in need of MODIS images,
but not comfortable with GRASS GIS yet.But this is an old story coming back,
I am all for reducing significantly the number of modules in GRASS, to
have a lean download.We can indeed have groups of plugins to get through g.extension:
- Hydrologically related
- Imagery
- Temporal
- 3D
- DB (though I am not a user, so cannot be sure of how much needed)This would keep import/export, some of the basic raster and vector ones.
Neat small download, use g.extension for anything else, by group or on
demand.Yann
On 30 October 2012 15:08, Martin Landa <landa.martin@gmail.com
<mailto:landa.martin@gmail.com>> wrote:Hi,
2012/10/30 Yann Chemin <yann.chemin@gmail.com
<mailto:yann.chemin@gmail.com>>:
> as a regular user of MODIS, I would like to call other MODIS users to
> express interest to include r.modis into GRASS 7 SVN.we cannot extend number of modules in trunk forever. Probably some
modules should be reviewed and moved to addons.Do you have any problem with installing r.modis using g.extension?
Martin
--
Martin Landa <landa.martin gmail.com <http://gmail.com>> *
http://geo.fsv.cvut.cz/~landa <http://geo.fsv.cvut.cz/~landa>--
Yann Chemin_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
benducke@fastmail.fm
Hi,
2012/10/30 Benjamin Ducke <benducke@fastmail.fm>:
What's the difference between having 300 or 500
modules in the base distribution? GRASS has the
file layout required to scale up to this size
easily, and each individual module is small and
lean. Even if we were to triple the number of
modules in the base distribution, the download
size would not increase significantly (and vice
versa).
btw, see a new toolbox-like proposal by Soeren from Prague's Community
Sprint [1].
- Having to compile add-ons written in C/C++ is a
big obstace, g.extension or not, for many users,
especially on Windows.
why? There are pre-compiled binaries. No problem to install addons on Windows.
[...]
So I am not convinced about the merits of breaking
the GRASS distribution into smaller pieces and add-ons.
Instead, I would say the base distribution should grow
as required and include new, useful modules such as r.modis.
I am not against including r.modis into trunk. I just wanted to
express my option that there were several modules in the past added to
the trunk which probably should stay in addons.
Martin
[1] http://grass.osgeo.org/wiki/Toolboxes
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
Hi Martin,
It would be good to return modules that are less frequently used to add-ons.
Yann
--
Yann Chemin
Maybe g.extension (or some other module) could work like R’s CRAN Task Views. For those who don’t know what CRAN Task Views are, take a look at http://decisionstats.com/2011/03/28/using-views-in-r-and-comparing-functions-across-multiple-packages/
-Bob
Robert Moskovitz
California Geological Survey
Seismic Hazards Zonation Program
http://www.conservation.ca.gov/cgs/shzp
CONFIDENTIALITY NOTICE: This communication is intended only for the use of the individual or entity to which it is addressed. This message contains information from the State of California, California Geological Survey, which may be privileged, confidential and exempt from disclosure under applicable law, including the Electronic Communications Privacy Act. If the reader of this communication is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited.
···
From: grass-dev-bounces@lists.osgeo.org [mailto:grass-dev-bounces@lists.osgeo.org] On Behalf Of Yann Chemin
Sent: Tuesday, October 30, 2012 3:43 AM
To: Martin Landa
Cc: GRASS developers list
Subject: Re: [GRASS-dev] r.modis in GRASS 7 trunk
Hi Martin,
I have no worries, since I do load modules directly. I am worried about the learning curve for Windows-bound students in need of MODIS images, but not comfortable with GRASS GIS yet.
But this is an old story coming back,
I am all for reducing significantly the number of modules in GRASS, to have a lean download.
We can indeed have groups of plugins to get through g.extension:
- Hydrologically related
- Imagery
- Temporal
- 3D
- DB (though I am not a user, so cannot be sure of how much needed)
This would keep import/export, some of the basic raster and vector ones. Neat small download, use g.extension for anything else, by group or on demand.
Yann
On 30 October 2012 15:08, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2012/10/30 Yann Chemin <yann.chemin@gmail.com>:
as a regular user of MODIS, I would like to call other MODIS users to
express interest to include r.modis into GRASS 7 SVN.
we cannot extend number of modules in trunk forever. Probably some
modules should be reviewed and moved to addons.
Do you have any problem with installing r.modis using g.extension?
Martin
–
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
–
Yann Chemin
Martin Landa wrote:
> as a regular user of MODIS, I would like to call other MODIS users to
> express interest to include r.modis into GRASS 7 SVN.we cannot extend number of modules in trunk forever. Probably some
modules should be reviewed and moved to addons.
Why?
Keeping modules in trunk ensures that any breakage resulting from
changes to APIs or to the build system will be noticed. Also, the
module will be included in the linkage database created by
tools/sql.sh, and in any recursive grep of the source tree.
Personally, I'd rather see most "normal" add-ons moved into trunk.
OTOH, v.in.dwg should be moved to add-ons unless LibreDWG support is
expected in the foreseeable future.
--
Glynn Clements <glynn@gclements.plus.com>
I agree with Glynn and Ben,
when working with students on 50+ different projects it is really great to have everything
in one package and not to worry about which additional tool to install and whether it will work with the latest release.
We used to have the code split into core, alpha and several other groups and it was pain to maintain,
I think it works much better now and the toolbox concept should be implemented at the GUI level.
Maybe PSC should have some mechanism to decide on which add-ons to move to trunk based on a defined set of criteria.
Helena
On Oct 30, 2012, at 12:53 PM, Glynn Clements wrote:
Martin Landa wrote:
as a regular user of MODIS, I would like to call other MODIS users to
express interest to include r.modis into GRASS 7 SVN.we cannot extend number of modules in trunk forever. Probably some
modules should be reviewed and moved to addons.Why?
Keeping modules in trunk ensures that any breakage resulting from
changes to APIs or to the build system will be noticed. Also, the
module will be included in the linkage database created by
tools/sql.sh, and in any recursive grep of the source tree.Personally, I'd rather see most "normal" add-ons moved into trunk.
OTOH, v.in.dwg should be moved to add-ons unless LibreDWG support is
expected in the foreseeable future.--
Glynn Clements <glynn@gclements.plus.com>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hi,
2012/10/30 Helena Mitasova <hmitaso@ncsu.edu>:
I agree with Glynn and Ben,
when working with students on 50+ different projects it is really great to have everything
in one package and not to worry about which additional tool to install and whether it will work with the latest release.
We used to have the code split into core, alpha and several other groups and it was pain to maintain,
I think it works much better now and the toolbox concept should be implemented at the GUI level.
sure on the other hand all GRASS modules included in trunk (or main
branch) should be solid, well tested and actively *maintained*. Note
that the GRASS development team is relatively small.
Maybe PSC should have some mechanism to decide on which add-ons to move to trunk based on a defined set of criteria.
We definitely need to define some criteria. Probably we should also
review which addons modules should go to trunk (well written,
maintained), and which should go from trunk to addons (not maintained,
rarely used, seriously broken).
From my POV, r.modis or r.streams.* modules are examples of the
modules which should go to trunk.
Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
Hi,
I’m with Helena, Glynn and Ben,
I think that having many module in one package is better for users that do not have to take care of anything else.
If I have GRASS installed, I can find anything there (without need of searching for additional modules that are not found in the manuals!).
And the criteria to add a module in the trunk should not be the frequency of usage, but the quality of the code: I would like to see in the trunk any module well written, without bug even if seldom used.
Maxi
On Tue, Oct 30, 2012 at 10:44 PM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2012/10/30 Helena Mitasova <hmitaso@ncsu.edu>:
I agree with Glynn and Ben,
when working with students on 50+ different projects it is really great to have everything
in one package and not to worry about which additional tool to install and whether it will work with the latest release.
We used to have the code split into core, alpha and several other groups and it was pain to maintain,
I think it works much better now and the toolbox concept should be implemented at the GUI level.sure on the other hand all GRASS modules included in trunk (or main
branch) should be solid, well tested and actively maintained. Note
that the GRASS development team is relatively small.Maybe PSC should have some mechanism to decide on which add-ons to move to trunk based on a defined set of criteria.
We definitely need to define some criteria. Probably we should also
review which addons modules should go to trunk (well written,
maintained), and which should go from trunk to addons (not maintained,
rarely used, seriously broken).From my POV, r.modis or r.streams.* modules are examples of the
modules which should go to trunk.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
–
Dr. Eng. Massimiliano Cannata
Responsabile Area Geomatica
Istituto Scienze della Terra
Scuola Universitaria Professionale della Svizzera Italiana
Via Trevano, c.p. 72
CH-6952 Canobbio-Lugano
Tel: +41 (0)58 666 62 14
Fax +41 (0)58 666 62 09
On 31 October 2012 02:25, Helena Mitasova <hmitaso@ncsu.edu> wrote:
I agree with Glynn and Ben,
when working with students on 50+ different projects it is really great to have everything
in one package and not to worry about which additional tool to install and whether it will work with the latest release.
Same conclusion here for teaching…
We used to have the code split into core, alpha and several other groups and it was pain to maintain,
I think it works much better now and the toolbox concept should be implemented at the GUI level.
+1
Maybe PSC should have some mechanism to decide on which add-ons to move to trunk based on a defined set of criteria.
+1
Yann
Helena
On Oct 30, 2012, at 12:53 PM, Glynn Clements wrote:
Martin Landa wrote:
as a regular user of MODIS, I would like to call other MODIS users to
express interest to include r.modis into GRASS 7 SVN.we cannot extend number of modules in trunk forever. Probably some
modules should be reviewed and moved to addons.Why?
Keeping modules in trunk ensures that any breakage resulting from
changes to APIs or to the build system will be noticed. Also, the
module will be included in the linkage database created by
tools/sql.sh, and in any recursive grep of the source tree.Personally, I’d rather see most “normal” add-ons moved into trunk.
OTOH, v.in.dwg should be moved to add-ons unless LibreDWG support is
expected in the foreseeable future.–
Glynn Clements <glynn@gclements.plus.com>
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
On Wed, Oct 31, 2012 at 5:58 AM, Yann Chemin <yann.chemin@gmail.com> wrote:
On 31 October 2012 02:25, Helena Mitasova <hmitaso@ncsu.edu> wrote:
I agree with Glynn and Ben,
when working with students on 50+ different projects it is really great to
have everything
in one package and not to worry about which additional tool to install and
whether it will work with the latest release.Same conclusion here for teaching...
+1
We used to have the code split into core, alpha and several other groups
and it was pain to maintain,
I think it works much better now and the toolbox concept should be
implemented at the GUI level.+1
+1
I think the toolbox concept on GUI level could help users a lot.
Maybe PSC should have some mechanism to decide on which add-ons to move to
trunk based on a defined set of criteria.+1
I suggest that modules should not simply be moved from addons to
trunk, but that a developer has a close look at a module including
testing before moving it to trunk.
Markus M
Yann
Helena
On Oct 30, 2012, at 12:53 PM, Glynn Clements wrote:
>
> Martin Landa wrote:
>
>>> as a regular user of MODIS, I would like to call other MODIS users to
>>> express interest to include r.modis into GRASS 7 SVN.
>>
>> we cannot extend number of modules in trunk forever. Probably some
>> modules should be reviewed and moved to addons.
>
> Why?
>
> Keeping modules in trunk ensures that any breakage resulting from
> changes to APIs or to the build system will be noticed. Also, the
> module will be included in the linkage database created by
> tools/sql.sh, and in any recursive grep of the source tree.
>
> Personally, I'd rather see most "normal" add-ons moved into trunk.
>
> OTOH, v.in.dwg should be moved to add-ons unless LibreDWG support is
> expected in the foreseeable future.
>
> --
> Glynn Clements <glynn@gclements.plus.com>
> _______________________________________________
> 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_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
On 31/10/12 09:15, Markus Metz wrote:
On Wed, Oct 31, 2012 at 5:58 AM, Yann Chemin<yann.chemin@gmail.com> wrote:
On 31 October 2012 02:25, Helena Mitasova<hmitaso@ncsu.edu> wrote:
I agree with Glynn and Ben,
when working with students on 50+ different projects it is really great to
have everything
in one package and not to worry about which additional tool to install and
whether it will work with the latest release.Same conclusion here for teaching...
+1
+1, especially from teaching to students from countries with very poor, or inexistant, internet connections. Having all in one package makes life so much easier for them.
We used to have the code split into core, alpha and several other groups
and it was pain to maintain,
I think it works much better now and the toolbox concept should be
implemented at the GUI level.+1
+1
I think the toolbox concept on GUI level could help users a lot.
+1
Some way of (des)activating certain parts of the menus in order to only see what you need, while still having all modules available whenever necessary.
Maybe PSC should have some mechanism to decide on which add-ons to move to
trunk based on a defined set of criteria.+1
I suggest that modules should not simply be moved from addons to
trunk, but that a developer has a close look at a module including
testing before moving it to trunk.
+1, but I see Martin's point about lack of dev power. So the trade-off has to be between quality of code and value added of having a functionality in trunk even if the code is not perfect.
Moritz
On Wed, Oct 31, 2012 at 9:31 AM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:
On 31/10/12 09:15, Markus Metz wrote:
On Wed, Oct 31, 2012 at 5:58 AM, Yann Chemin<yann.chemin@gmail.com>
wrote:On 31 October 2012 02:25, Helena Mitasova<hmitaso@ncsu.edu> wrote:
Maybe PSC should have some mechanism to decide on which add-ons to move
to
trunk based on a defined set of criteria.+1
I suggest that modules should not simply be moved from addons to
trunk, but that a developer has a close look at a module including
testing before moving it to trunk.+1, but I see Martin's point about lack of dev power. So the trade-off has
to be between quality of code and value added of having a functionality in
trunk even if the code is not perfect.
True, but still, a little effort could be made. I did not mean
exhaustive testing of the functionality, rather basic stuff like code
formatting, checking for and removing any justified compiler warnings,
for raster modules checking NULL handling and CELL/FCELL/DCELL
handling, for vector modules checking feature type, category, and
layer handling.
Markus M
On 31/10/12 10:47, Markus Metz wrote:
On Wed, Oct 31, 2012 at 9:31 AM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:On 31/10/12 09:15, Markus Metz wrote:
On Wed, Oct 31, 2012 at 5:58 AM, Yann Chemin<yann.chemin@gmail.com>
wrote:On 31 October 2012 02:25, Helena Mitasova<hmitaso@ncsu.edu> wrote:
Maybe PSC should have some mechanism to decide on which add-ons to move
to
trunk based on a defined set of criteria.+1
I suggest that modules should not simply be moved from addons to
trunk, but that a developer has a close look at a module including
testing before moving it to trunk.+1, but I see Martin's point about lack of dev power. So the trade-off has
to be between quality of code and value added of having a functionality in
trunk even if the code is not perfect.True, but still, a little effort could be made. I did not mean
exhaustive testing of the functionality, rather basic stuff like code
formatting, checking for and removing any justified compiler warnings,
for raster modules checking NULL handling and CELL/FCELL/DCELL
handling, for vector modules checking feature type, category, and
layer handling.
We should probably put all this into a quality check list for integration of modules into trunk. Maybe parts of those checks could even be automated ?
Moritz
Moritz Lennert wrote:
> I suggest that modules should not simply be moved from addons to
> trunk, but that a developer has a close look at a module including
> testing before moving it to trunk.+1, but I see Martin's point about lack of dev power. So the trade-off
has to be between quality of code and value added of having a
functionality in trunk even if the code is not perfect.
Relegating something to add-ons is a reliable way to reduce the amount
of developer oversight it gets. E.g. currently you can't just "make"
the add-ons/grass7 directory (it lacks a Makefile), so most developers
won't even try to compile it. If the modules were in trunk, developers
may notice errors or warnings as part of the normal build process.
--
Glynn Clements <glynn@gclements.plus.com>
Hi Glynn,
I would like to have that kind of Makefile,
so I can build all grass add-ons related to GRASS 7 SVN without changing anything in the structure of the SVN
Could anyone help us to get somewhere near to that effect, even if we would need a configure option like --build-addons-dir=…/grass-addons/grass7 that would be neat.
Thank you,
Yann
···
On 1 November 2012 03:03, Glynn Clements <glynn@gclements.plus.com> wrote:
Moritz Lennert wrote:
I suggest that modules should not simply be moved from addons to
trunk, but that a developer has a close look at a module including
testing before moving it to trunk.+1, but I see Martin’s point about lack of dev power. So the trade-off
has to be between quality of code and value added of having a
functionality in trunk even if the code is not perfect.Relegating something to add-ons is a reliable way to reduce the amount
of developer oversight it gets. E.g. currently you can’t just “make”
the add-ons/grass7 directory (it lacks a Makefile), so most developers
won’t even try to compile it. If the modules were in trunk, developers
may notice errors or warnings as part of the normal build process.–
Glynn Clements <glynn@gclements.plus.com>
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
–
Yann Chemin
On Wed, Oct 31, 2012 at 10:33 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:
Moritz Lennert wrote:
> I suggest that modules should not simply be moved from addons to
> trunk, but that a developer has a close look at a module including
> testing before moving it to trunk.+1, but I see Martin's point about lack of dev power. So the trade-off
has to be between quality of code and value added of having a
functionality in trunk even if the code is not perfect.Relegating something to add-ons is a reliable way to reduce the amount
of developer oversight it gets. E.g. currently you can't just "make"
the add-ons/grass7 directory (it lacks a Makefile),
Now there is.
so most developers
won't even try to compile it. If the modules were in trunk, developers
may notice errors or warnings as part of the normal build process.
Agreed.
I also think that we need the toolbox concept rather at GUI level than
at directory level.
Markus