Re: [GRASS-dev] r.modis in GRASS 7 trunk

2012-10-31 Thread Yann Chemin
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  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 
> ___
> 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

[GRASS-dev] archaeology grand challenges

2012-10-31 Thread Michael Barton
Here is what we submitted for the retreat…and our questions drove a lot of 
discussion.

Michael



archy vision 2011-rev.doc
Description: archy vision 2011-rev.doc

__C. Michael Barton Director, Center for Social Dynamics & ComplexityProfessor of Anthropology, School of Human Evolution & Social ChangeArizona State UniversityTempe, AZ  85287-2402USAvoice: 	480-965-6262 (SHESC), 480-727-9746 (CSDC)fax:          480-965-7671(SHESC), 480-727-0709 (CSDC)www: 	http://csdc.asu.edu, http://shesc.asu.edu		http://www.public.asu.edu/~cmbarton

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

Re: [GRASS-dev] v.net.allpairs seems broken

2012-10-31 Thread Michael Barton
Excellent!

Michael
__
C. Michael Barton 
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ  85287-2402
USA

voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax:  480-965-7671(SHESC), 480-727-0709 (CSDC)
www:http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

On Oct 31, 2012, at 2:29 PM, Markus Metz 
 wrote:

> On Mon, Oct 15, 2012 at 5:11 PM, Markus Metz
>  wrote:
>> 
>> On Mon, Oct 15, 2012 at 4:34 PM, Michael Barton 
>> wrote:
>>> 
>>> One thing that is confusing is that the text for both entries alayer and
>>> nlayer shows up as "Layer number or name" instead of the text that is
>>> actually in the description field "Arc layer" and "Node layer". Any idea why
>>> this is so?
>>> 
>> 
>> The label for the standard option G_OPT_V_FIELD is by default set to "Layer
>> number or name", and the label, if set, is used as text next to the option
>> key. Having "Arc layer" or "Node layer" next to the key can be easily done
>> be making "Arc layer" or "Node layer" option labels, which should then be
>> done for all v.net.* modules.
> 
> Done for trunk in r53630.
> 
> Markus M

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


Re: [GRASS-dev] r.modis in GRASS 7 trunk

2012-10-31 Thread Glynn Clements

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 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev


Re: [GRASS-dev] v.net.allpairs seems broken

2012-10-31 Thread Markus Metz
On Mon, Oct 15, 2012 at 5:11 PM, Markus Metz
 wrote:
>
> On Mon, Oct 15, 2012 at 4:34 PM, Michael Barton 
> wrote:
>>
>> One thing that is confusing is that the text for both entries alayer and
>> nlayer shows up as "Layer number or name" instead of the text that is
>> actually in the description field "Arc layer" and "Node layer". Any idea why
>> this is so?
>>
>
> The label for the standard option G_OPT_V_FIELD is by default set to "Layer
> number or name", and the label, if set, is used as text next to the option
> key. Having "Arc layer" or "Node layer" next to the key can be easily done
> be making "Arc layer" or "Node layer" option labels, which should then be
> done for all v.net.* modules.

Done for trunk in r53630.

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


Re: [GRASS-dev] [GRASS GIS] #1776: Python error by startup

2012-10-31 Thread GRASS GIS
#1776: Python error by startup
---+
 Reporter:  pvanbosgeo |   Owner:  martinl  
 Type:  defect |  Status:  assigned 
 Priority:  normal |   Milestone:  6.4.3
Component:  Startup| Version:  svn-trunk
 Keywords:  language settings  |Platform:  Linux
  Cpu:  x86-64 |  
---+

Comment(by pvanbosgeo):

 just tried r53623 and only one error message on the command line (Failed
 to set LC_ALL to None.UTF-8 (unsupported locale setting)). No pop-up
 window with error message anymore and no error messages when starting R
 from within GRASS.

 Paulo

-- 
Ticket URL: 
GRASS GIS 

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


Re: [GRASS-dev] [GRASS GIS] #1776: Python error by startup

2012-10-31 Thread GRASS GIS
#1776: Python error by startup
---+
 Reporter:  pvanbosgeo |   Owner:  martinl  
 Type:  defect |  Status:  assigned 
 Priority:  normal |   Milestone:  6.4.3
Component:  Startup| Version:  svn-trunk
 Keywords:  language settings  |Platform:  Linux
  Cpu:  x86-64 |  
---+

Comment(by martinl):

 Replying to [comment:9 pvanbosgeo]:

 {{{
 > locale -a
 ...
 > en_US.utf8
 ...
 }}}

 your currently used locale seems to be available. Hm, strange.

-- 
Ticket URL: 
GRASS GIS 

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


Re: [GRASS-dev] [GRASS GIS] #1776: Python error by startup

2012-10-31 Thread GRASS GIS
#1776: Python error by startup
---+
 Reporter:  pvanbosgeo |   Owner:  martinl  
 Type:  defect |  Status:  assigned 
 Priority:  normal |   Milestone:  6.4.3
Component:  Startup| Version:  svn-trunk
 Keywords:  language settings  |Platform:  Linux
  Cpu:  x86-64 |  
---+

Comment(by pvanbosgeo):

 env | grep LANG:

 LANG=en_US.UTF-8
 LANGUAGE=en_US:en

 locale -a

 C
 C.UTF-8
 en_AG
 en_AG.utf8
 en_AU.utf8
 en_BW.utf8
 en_CA.utf8
 en_DK.utf8
 en_GB.utf8
 en_HK.utf8
 en_IE.utf8
 en_IN
 en_IN.utf8
 en_NG
 en_NG.utf8
 en_NZ.utf8
 en_PH.utf8
 en_SG.utf8
 en_US.utf8
 en_ZA.utf8
 en_ZM
 en_ZM.utf8
 en_ZW.utf8
 POSIX

-- 
Ticket URL: 
GRASS GIS 

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


Re: [GRASS-dev] [GRASS GIS] #1776: Python error by startup

2012-10-31 Thread GRASS GIS
#1776: Python error by startup
---+
 Reporter:  pvanbosgeo |   Owner:  martinl  
 Type:  defect |  Status:  assigned 
 Priority:  normal |   Milestone:  6.4.3
Component:  Startup| Version:  svn-trunk
 Keywords:  language settings  |Platform:  Linux
  Cpu:  x86-64 |  
---+
Changes (by martinl):

  * component:  Default => Startup


-- 
Ticket URL: 
GRASS GIS 

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


Re: [GRASS-dev] [GRASS GIS] #1776: Python error by startup

2012-10-31 Thread GRASS GIS
#1776: Python error by startup
---+
 Reporter:  pvanbosgeo |   Owner:  martinl  
 Type:  defect |  Status:  assigned 
 Priority:  normal |   Milestone:  6.4.3
Component:  Default| Version:  svn-trunk
 Keywords:  language settings  |Platform:  Linux
  Cpu:  x86-64 |  
---+
Changes (by martinl):

 * cc: grass-dev@… (added)
  * keywords:  => language settings
  * status:  new => assigned
  * owner:  grass-dev@… => martinl


-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #1776: Python error by startup

2012-10-31 Thread GRASS GIS
#1776: Python error by startup
+---
 Reporter:  pvanbosgeo  |   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  normal  |   Milestone:  6.4.3
Component:  Default | Version:  svn-trunk
 Keywords:  |Platform:  Linux
  Cpu:  x86-64  |  
+---

Comment(by martinl):

 Replying to [comment:2 pvanbosgeo]:

 {{{
 > LANG=en_US.UTF-8
 > LANGUAGE=en_US:en
 }}}

 do you have this locale installed? Check `locale -a`...

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #1776: Python error by startup

2012-10-31 Thread GRASS GIS
#1776: Python error by startup
+---
 Reporter:  pvanbosgeo  |   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  normal  |   Milestone:  6.4.3
Component:  Default | Version:  svn-trunk
 Keywords:  |Platform:  Linux
  Cpu:  x86-64  |  
+---

Comment(by martinl):

 Replying to [ticket:1776 pvanbosgeo]:

 {{{
 > Popup 'Python error':
 > -
 > Cannot set locale to ".
 }}}

 this error should be avoided in r53620. Can you try it out, please?

 > Messages on command line:
 > --
 > Failed to set LC_ALL to None.UTF-8

 Strange, what says

 {{{
  env | grep LANG
 }}}

 and

 {{{
 locale -a
 }}}

 ?

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Renewal of GRASS-PSC

2012-10-31 Thread Markus Neteler
Dear all,

the nomination phase for new PSC member is over,
thanks for all contributions.

The current PSC will decide in short time about the candidates.

Best
Markus

-- 
GRASS GIS PSC Chair
http://grass.osgeo.org/wiki/PSC
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev


Re: [GRASS-dev] [GRASS GIS] #1776: Python error by startup

2012-10-31 Thread GRASS GIS
#1776: Python error by startup
+---
 Reporter:  pvanbosgeo  |   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  normal  |   Milestone:  6.4.3
Component:  Default | Version:  svn-trunk
 Keywords:  |Platform:  Linux
  Cpu:  x86-64  |  
+---

Comment(by pvanbosgeo):

 When starting R from within GRASS, I am getting the following lines, which
 do not show when started R normally (not from within GRASS) from the
 command line:

 During startup - Warning messages:
 1: Setting LC_CTYPE failed, using "C"
 2: Setting LC_COLLATE failed, using "C"
 3: Setting LC_TIME failed, using "C"
 4: Setting LC_MESSAGES failed, using "C"
 5: Setting LC_PAPER failed, using "C"
 6: Setting LC_PAPER failed, using "C"
 7: Setting LC_MEASUREMENT failed, using "C"

 I am guessing this has the same underlying problem?

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #1776: Python error by startup

2012-10-31 Thread GRASS GIS
#1776: Python error by startup
+---
 Reporter:  pvanbosgeo  |   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  normal  |   Milestone:  6.4.3
Component:  Default | Version:  svn-trunk
 Keywords:  |Platform:  Linux
  Cpu:  x86-64  |  
+---

Comment(by pvanbosgeo):

 This problem started with the latest revision. However, I installed this
 latest revision after upgrading to Ubuntu 12.10, so perhaps that has
 broken something concerning the locale?

 I see the Milestone is set to 6.4.3. Just to make sure, these problems are
 with GRASS 7.0, not with GRASS 6.4

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] installing r.modis fails

2012-10-31 Thread Paulo van Breugel

Hi Luca

Thanks for looking into this. I answered your request for the ticket on 
the locale. I should perhaps add though that I was not able to install 
r.modis in an earlier revision of GRASS 7.0 either, while the locale 
error messages only started with the current revision (which I compiled 
after upgrading to Ubuntu 12.10, so perhaps that has broken something 
concerning the locale?).


Cheers,

Paulo




On 10/31/2012 11:41 AM, Luca Delucchi wrote:

2012/10/31 Paulo van Breugel :

Hi, I am trying to install r.modis using g.extension, which gives me the
error messages below. Note that the first three svn warnings also showed up
during compiling GRASS (reported here:
http://trac.osgeo.org/grass/ticket/1776) and with any extension I install.
So they are probably not related to the problem with installing r.modis

Fetching  from GRASS-Addons SVN (be patient)...
svn: warning: cannot set LC_CTYPE locale
svn: warning: environment variable LC_CTYPE is en_US
svn: warning: please check that your locale name is correct
Compiling...
ERROR: modis library not imported
make[1]: *** [r.modis.download.tmp.html] Error 1
ERROR: rmodislib library not imported
make[1]: *** [r.modis.import.tmp.html] Error 1
Installing...
/usr/bin/install: cannot stat
`/home/paulo/Data/GRASSdb/latlon/PERMANENT/.tmp/paulo-HP-Z60
0-Workstation/5191.0/r.modis/docs/html/r.modis.download.html
': No such file or directory
make[1]: *** [install] Error 1
/usr/bin/install: cannot stat
`/home/paulo/Data/GRASSdb/latlon/PERMANENT/.tmp/paulo-HP-Z60
0-Workstation/5191.0/r.modis/docs/html/r.modis.import.html':
No such file or directory
make[1]: *** [install] Error 1
ERROR: Unable to read manual page: [Errno 2] No such file or directory:
'/home/paulo/.grass7/addons/docs/html/r.modis.html'


so, here there is a problem related to r.modis libraries, I should use
'pass' in a try  exceptions but I don't like so much because if the
libraries are missing no errors are returned during running


I seems r.modis is installed, but running the command r.modis.download gives
me the warning message:

Unable to fetch interface description for command 'r.modis.download'.
Details:
GRASS_INFO_ERROR(5384,1): modis library not imported
GRASS_INFO_END(5384,1)


this seem related to your ticket, and this is related to your locale situation.
I added a request to that ticket



Best regards,

Paulo





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

Re: [GRASS-dev] [GRASS GIS] #1776: Python error by startup

2012-10-31 Thread GRASS GIS
#1776: Python error by startup
+---
 Reporter:  pvanbosgeo  |   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  normal  |   Milestone:  6.4.3
Component:  Default | Version:  svn-trunk
 Keywords:  |Platform:  Linux
  Cpu:  x86-64  |  
+---

Comment(by pvanbosgeo):

 LANG=en_US.UTF-8
 LANGUAGE=en_US:en
 LC_CTYPE=en_US.UTF-8
 LC_NUMERIC="en_US.UTF-8"
 LC_TIME="en_US.UTF-8"
 LC_COLLATE=en_US.UTF-8
 LC_MONETARY="en_US.UTF-8"
 LC_MESSAGES=en_US.UTF-8
 LC_PAPER="en_US.UTF-8"
 LC_NAME="en_US.UTF-8"
 LC_ADDRESS="en_US.UTF-8"
 LC_TELEPHONE="en_US.UTF-8"
 LC_MEASUREMENT="en_US.UTF-8"
 LC_IDENTIFICATION="en_US.UTF-8"
 LC_ALL=

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #1776: Python error by startup

2012-10-31 Thread Paulo van Breugel

LANG=en_US.UTF-8
LANGUAGE=en_US:en
LC_CTYPE=en_US.UTF-8
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE=en_US.UTF-8
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES=en_US.UTF-8
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=


On 10/31/2012 11:41 AM, GRASS GIS wrote:

#1776: Python error by startup
+---
  Reporter:  pvanbosgeo  |   Owner:  grass-dev@…
  Type:  defect  |  Status:  new
  Priority:  normal  |   Milestone:  6.4.3
Component:  Default | Version:  svn-trunk
  Keywords:  |Platform:  Linux
   Cpu:  x86-64  |
+---

Comment(by lucadelu):

  Could you return the result of unix command
  == locale ==


  Thanks
  Luca



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

Re: [GRASS-dev] installing r.modis fails

2012-10-31 Thread Luca Delucchi
2012/10/31 Paulo van Breugel :
> Hi, I am trying to install r.modis using g.extension, which gives me the
> error messages below. Note that the first three svn warnings also showed up
> during compiling GRASS (reported here:
> http://trac.osgeo.org/grass/ticket/1776) and with any extension I install.
> So they are probably not related to the problem with installing r.modis
>
> Fetching  from GRASS-Addons SVN (be patient)...
> svn: warning: cannot set LC_CTYPE locale
> svn: warning: environment variable LC_CTYPE is en_US
> svn: warning: please check that your locale name is correct
> Compiling...
> ERROR: modis library not imported
> make[1]: *** [r.modis.download.tmp.html] Error 1
> ERROR: rmodislib library not imported
> make[1]: *** [r.modis.import.tmp.html] Error 1
> Installing...
> /usr/bin/install: cannot stat
> `/home/paulo/Data/GRASSdb/latlon/PERMANENT/.tmp/paulo-HP-Z60
> 0-Workstation/5191.0/r.modis/docs/html/r.modis.download.html
> ': No such file or directory
> make[1]: *** [install] Error 1
> /usr/bin/install: cannot stat
> `/home/paulo/Data/GRASSdb/latlon/PERMANENT/.tmp/paulo-HP-Z60
> 0-Workstation/5191.0/r.modis/docs/html/r.modis.import.html':
> No such file or directory
> make[1]: *** [install] Error 1
> ERROR: Unable to read manual page: [Errno 2] No such file or directory:
> '/home/paulo/.grass7/addons/docs/html/r.modis.html'
>

so, here there is a problem related to r.modis libraries, I should use
'pass' in a try  exceptions but I don't like so much because if the
libraries are missing no errors are returned during running

> I seems r.modis is installed, but running the command r.modis.download gives
> me the warning message:
>
> Unable to fetch interface description for command 'r.modis.download'.
> Details:
> GRASS_INFO_ERROR(5384,1): modis library not imported
> GRASS_INFO_END(5384,1)
>

this seem related to your ticket, and this is related to your locale situation.
I added a request to that ticket


> Best regards,
>
> Paulo
>


-- 
ciao
Luca

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


Re: [GRASS-dev] [GRASS GIS] #1776: Python error by startup

2012-10-31 Thread GRASS GIS
#1776: Python error by startup
+---
 Reporter:  pvanbosgeo  |   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  normal  |   Milestone:  6.4.3
Component:  Default | Version:  svn-trunk
 Keywords:  |Platform:  Linux
  Cpu:  x86-64  |  
+---

Comment(by lucadelu):

 Could you return the result of unix command
 == locale ==


 Thanks
 Luca

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] r.modis in GRASS 7 trunk

2012-10-31 Thread Moritz Lennert

On 31/10/12 10:47, Markus Metz wrote:

On Wed, Oct 31, 2012 at 9:31 AM, Moritz Lennert
  wrote:

On 31/10/12 09:15, Markus Metz wrote:


On Wed, Oct 31, 2012 at 5:58 AM, Yann Chemin
wrote:


On 31 October 2012 02:25, Helena Mitasova   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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev


Re: [GRASS-dev] r.modis in GRASS 7 trunk

2012-10-31 Thread Markus Metz
On Wed, Oct 31, 2012 at 9:31 AM, Moritz Lennert
 wrote:
> On 31/10/12 09:15, Markus Metz wrote:
>>
>> On Wed, Oct 31, 2012 at 5:58 AM, Yann Chemin
>> wrote:
>>>
>>> On 31 October 2012 02:25, Helena Mitasova  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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev


[GRASS-dev] installing r.modis fails

2012-10-31 Thread Paulo van Breugel
Hi, I am trying to install r.modis using g.extension, which gives me the 
error messages below. Note that the first three svn warnings also showed 
up during compiling GRASS (reported here: 
http://trac.osgeo.org/grass/ticket/1776) and with any extension I 
install. So they are probably not related to the problem with installing 
r.modis


Fetching  from GRASS-Addons SVN (be patient)...
svn: warning: cannot set LC_CTYPE locale
svn: warning: environment variable LC_CTYPE is en_US
svn: warning: please check that your locale name is correct
Compiling...
ERROR: modis library not imported
make[1]: *** [r.modis.download.tmp.html] Error 1
ERROR: rmodislib library not imported
make[1]: *** [r.modis.import.tmp.html] Error 1
Installing...
/usr/bin/install: cannot stat
`/home/paulo/Data/GRASSdb/latlon/PERMANENT/.tmp/paulo-HP-Z60
0-Workstation/5191.0/r.modis/docs/html/r.modis.download.html
': No such file or directory
make[1]: *** [install] Error 1
/usr/bin/install: cannot stat
`/home/paulo/Data/GRASSdb/latlon/PERMANENT/.tmp/paulo-HP-Z60
0-Workstation/5191.0/r.modis/docs/html/r.modis.import.html':
No such file or directory
make[1]: *** [install] Error 1
ERROR: Unable to read manual page: [Errno 2] No such file or directory: 
'/home/paulo/.grass7/addons/docs/html/r.modis.html'


I seems r.modis is installed, but running the command r.modis.download 
gives me the warning message:


Unable to fetch interface description for command 'r.modis.download'.
Details:
GRASS_INFO_ERROR(5384,1): modis library not imported
GRASS_INFO_END(5384,1)


My system info:
GRASS version: 7.0.svn
GRASS SVN Revision: 53615
GIS Library Revision: 52468 (2012-07-27)
GDAL/OGR: 1.9.2
PROJ4: Rel. 4.7.1, 23 September 2009
Python: 2.7.3
wxPython: 2.8.12.1
Platform: Linux-3.5.0-17-generic-x86_64-with-Ubuntu-12.10-quantal

Any ideas?

Best regards,

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

Re: [GRASS-dev] r.modis in GRASS 7 trunk

2012-10-31 Thread Moritz Lennert

On 31/10/12 09:15, Markus Metz wrote:

On Wed, Oct 31, 2012 at 5:58 AM, Yann Chemin  wrote:



On 31 October 2012 02:25, Helena Mitasova  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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev


Re: [GRASS-dev] r.modis in GRASS 7 trunk

2012-10-31 Thread Markus Metz
On Wed, Oct 31, 2012 at 5:58 AM, Yann Chemin  wrote:
>
>
> On 31 October 2012 02:25, Helena Mitasova  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 
>> > ___
>> > 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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev