Re: [GRASS-dev] Re: [GRASS GIS] #908: No Font Definition File, windows xp

[Hamish]

Doug Newcomb wrote:
> Many government organizations that use Windows are
> going to LUA, http://technet.microsoft.com/en-us/library/cc700846.aspx 
> Least-privileged
> User Account environments for most users.  Having a
> normal user need to do anything as an administrator to run a
> program is almost a show-stopper for deployment in these
> environments.
>   So, I wholeheartedly applaud anything that
> can be done to make GRASS run well under Windows without any
> administrative access.

This has certainly been our intention all along. There is some stuff yet
to figure out and work around (like adding v.patch and r.patch to the
package manifest so UAC doesn't choke on the word "patch"), but for the
most part I think we are, or at least will be, in pretty good shape.

It really helps that this has already been the UNIX model since forever,
in fact even if the multi-user stuff isn't used as much anymore, this is
the model GRASS was originally designed for. I think it would be much
harder to go the other way and try and port a large DOS+Windows codebase+
way of doing things into a UNIX ecosystem.


regards,
Hamish



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

[GRASS-dev] Re: [GRASS GIS] #916: GRASS 7: make install fails with --prefix

[GRASS GIS]

#916: GRASS 7: make install fails with --prefix
--+-
  Reporter:  neteler  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  normal   |   Milestone:  7.0.0
 Component:  default  | Version:  svn-trunk
Resolution:   |Keywords:   
  Platform:  Linux| Cpu:  Unspecified  
--+-
Changes (by martin):

 * cc: martin (added)

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

Re: [GRASS-dev] Fixing r.li

[Glynn Clements]

Markus Neteler wrote:

> >> Is anyone familiar with r.li?
> >>
> >> How easy would it be to get rid of the (Unix-specific) client-server
> >> framework so that the various r.li.* modules are just normal modules?
> >
> > I've done this, but I can't test that it still works as I don't have
> > any idea how to use it.
> >
> > Also, r.li.setup is currently disabled (due to requiring Tcl/Tk) and
> > there doesn't appear to be any documention on creating a configuration
> > file without it.
> 
> Sorry for the delay. Attached a config file:
> $HOME/.grass7/r.li/landclass96_conf
> 
> Usage (North Carolina data set [1]):
> g.region rast=landclass96
> r.li.shannon map=landclas...@permanent conf=landclass96_conf 
> output=landclass96_shannon --o

Okay; it seems to work. I don't know what the output should actually
look like, but it doesn't crash or produce obviously bad data, and I
can't see any way that the changes could have "subtle" consequences.

r.li.setup still needs to replaced.

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

[GRASS-dev] Re: [GRASS GIS] #807: r.watershed doesnt consider longer distance to diagonal neighbouring pixels

[GRASS GIS]

#807: r.watershed doesnt consider longer distance to diagonal neighbouring 
pixels
-+--
  Reporter:  aread   |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect  |  Status:  new  
  Priority:  major   |   Milestone:  6.4.0
 Component:  Raster  | Version:  6.4.0 RCs
Resolution:  |Keywords:  r.watershed  
  Platform:  All | Cpu:  All  
-+--
Comment (by helena):

 Markus was right - the difference was due to handling elevations as int
 versus fp,
 so now I got the version with the diagonal fix
 and here is the comparison of spatial patterns

 grass64RC05 - SFD with integer elevation
 range ~ -20 - +20
 note zig-zag main streams, missing flow accumulation along the road on the
 west ridge
 http://skagit.meas.ncsu.edu/~helena/grasswork/accum5K_gr64rc5_3d.jpg
 http://skagit.meas.ncsu.edu/~helena/grasswork/accum5K_gr64rc5.png

 grass65 compiled in Sep 2009, SFD with FP before diagonal fix
 range ~ -20 - +55000 (why so much lower than grass64?)
 no zig-zag on main streams, more realistic pattern on streams, lots of
 diagonals on hillslopes
 http://skagit.meas.ncsu.edu/~helena/grasswork/accum5K_gr65_sep09.jpg
 http://skagit.meas.ncsu.edu/~helena/grasswork/accum_5Ksep09.jpg

 grass65 compiled Feb 2010, SFD with fp after diagonal fix
 range only slightly different, quite different pattern on hillslopes -
 note particularly NW section of the watershed where the previously
 diagonal flow changed to horizontal
 http://skagit.meas.ncsu.edu/~helena/grasswork/accum5K_gr65_feb10c_i.jpg
 http://skagit.meas.ncsu.edu/~helena/grasswork/accum_5Kdiag2010.jpg

 I can see that somebody might have liked the diagonal biased version
 better than the correct one.

 grass65 MFD - no difference between sep 2009 and feb 2010
 range ~ -20 - +16000 (lower than SFD as it should be, but still why
 such a diff between 64 and 65?)
 most realistic overall
 http://skagit.meas.ncsu.edu/~helena/grasswork/accum5K_gr65_mfd.jpg
 http://skagit.meas.ncsu.edu/~helena/grasswork/accum_5Kmfdi.jpg

 Compared to r.watershed in GRASS65, the GRASS64 results look really bad
 for this
 high resolution data - I assume for lower resolution data the difference
 won't be
 as stark but still grass64 will be much worse than the grass65 version.
 Should grass65 version of r.watershed be backported to grass64?
 although the difference in values needs to be explained (it may be mistake
 on my side)
 and Markus M may have some additional issues that need to be addressed,
 what do others think? who makes the decision?

 Helena

-- 
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 + matplotlib on mac osx snow leopard

[Michael Barton]

I installed matplotlib awhile back to test it (Leopard). It is quite nice and 
very versatile. I thought it could be a very nice addition. However, there were 
objections to another dependency and the suggestion that we should build our 
own graphing library. But this hasn't happened yet.

Michael

On Feb 8, 2010, at 6:18 PM, grass-dev-requ...@lists.osgeo.org wrote:

> Date: Mon, 8 Feb 2010 18:34:16 -0600
> From: William Kyngesburye 
> Subject: Re: [GRASS-dev] grass + matplotlib on mac osx snow leopard
> To: Massimo Di Stefano 
> Cc: GRASS developers list 
> Message-ID: <4aafa49d-bd8b-44dd-9cd1-b286d7754...@kyngchaos.com>
> Content-Type: text/plain; charset=us-ascii
> 
> That's the matplotlib freetype module, but what about the freetype library 
> used during matpotlib compilation?
> 
> On Feb 8, 2010, at 12:37 PM, Massimo Di Stefano wrote:
> 
>> Hi William,
>> 
>> don't know if these note can help to know where is the problem :
>> 
>> 
>> The matplotlib freetype libs are build with both architecture :
>> 
>> 
>> GRASS 6.5.svn (spearfish60):~ > file 
>> /Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/ft2font.so
>> /Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/ft2font.so:
>>  Mach-O universal binary with 2 architectures
>> /Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/ft2font.so
>>  (for architecture i386): Mach-O bundle i386
>> /Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/ft2font.so
>>  (for architecture x86_64):   Mach-O 64-bit bundle x86_64
>> GRASS 6.5.svn (spearfish60):~ >
>> 
> 
> -
> William Kyngesburye 
> http://www.kyngchaos.com/
> 
> The equator is so long, it could encircle the earth completely once.
> 

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

Re: re [GRASS-dev] g.proj -p - units is : meters or metres ?

[Glynn Clements]

Massimo Di Stefano wrote:

> apologize the private mail, i can see your answer on the list archive,
> but no reply is sent to my mail box (mybe some problems with the mailng
> list :-/)


Note that, by default, the Mailman list management software doesn't
send a copy of a message to any user who is listed in the To, CC, etc
headers. If you don't receive the direct copy due to e.g. anti-spam
filters, then you won't receive a copy at all.

I recommend disabling this feature in your mailmain preferences:

http://lists.osgeo.org/mailman/options/grass-dev/

I've asked for this "feature" to be disabled by default, but that
hasn't happened.

> > What do your scripts use the "unit" or "units" field for?
> 
> I'm working on a script to send data from grass to ossimplanet,
> it is :
> 
> http://svn.osgeo.org/ossim/trunk/gsoc/OssimPlanetSasha/r.planet.py
> 
> there is a "projinfo()" function i'm using it to retrieve if the location use 
> degrees or projected coordinates
> what i need is to extract the "center of the map" and use it in the  "zoom 
> to" action.
> 
> if the location is in degrees i use :
> 
> setCLL(map)
> location ..
> while if projected (meters) i use :
> 
> setCPRJ(map)

I suggest looking at the PROJ_INFO output, specifically the "proj"
field. It will have the value "ll" for lat/lon.

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

[GRASS-dev] Re: [GRASS GIS] #909: FTBFS: r.mapcalc in trunk

[GRASS GIS]

#909: FTBFS: r.mapcalc in trunk
+---
  Reporter:  hamish |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect |  Status:  new  
  Priority:  normal |   Milestone:  7.0.0
 Component:  Compiling  | Version:  svn-trunk
Resolution: |Keywords:  r.mapcalc
  Platform:  Linux  | Cpu:  x86-64   
+---
Comment (by glynn):

 Replying to [comment:4 hamish]:

 > build log with faulty r.mapcalc build attached.

 Looking at that...
 {{{
 3175:   make[4]: Entering directory
 `/home/hbowman/dev/grass/svn/trunk/raster/r.colors'
 3176:   make -C ../r.mapcalc
 ...
 3178:   make[5]: Entering directory
 `/home/hbowman/dev/grass/svn/trunk/raster/r.mapcalc'
 ...
 ...
 3569:   make -C r.mapcalc || echo
 /home/hbowman/dev/grass/svn/trunk/raster/r.mapcalc >>
 /home/hbowman/dev/grass/svn/trunk/error.log
 ...
 3577:   make[3]: Entering directory
 `/home/hbowman/dev/grass/svn/trunk/raster/r.mapcalc'
 ...
 3589:   gcc ... -o OBJ.x86_64-unknown-linux-gnu/mapcalc.yy.o -c
 mapcalc.yy.c
 ...
 3796:   gcc ... -o OBJ.x86_64-unknown-linux-gnu/mapcalc.yy.o -c
 mapcalc.yy.c
 }}}

 IOW, it's compiling it twice.

 Note: r.colors requires r.mapcalc for the thumbnails.

 It appears that the raster -> r.mapcalc build starts while
 the raster -> r.colors -> r.mapcalc build is still ongoing. The first
 build compiles mapcalc.yy.c to mapcalc.yy.o, then later tries to link it
 while the second build is compiling it, and ends up using an incomplete
 file.

 Unrelated parallel make tasks don't communicate with each other (if they
 did, the second task would note that the first task was already building
 mapcalc.yy.o, and just wait for it to finish).

 When raster/Makefile "make"s r.colors and r.mapcalc concurrently, the
 tasks are considered unrelated, and that doesn't change when they bump
 into each other in r.mapcalc.

 One option is to simply remove r.mapcalc from the SUBDIRS list in
 raster/Makefile, as r.colors is going to build it. At least, that was my
 first thought, but if r.colors.html is up-to-date, it won't happen; and,
 if r.mapcalc already exists, it won't be re-made.

 Another option is to move the thumbnail generation into e.g. man/Makefile.
 But that won't re-build the thumbnails if r.colors is re-made (OTOH, the
 thumbnail images are really a derivative of lib/gis/colors/ rather than
 r.colors per se).

 Another option is to change raster/Makefile thus:
 {{{
 -htmldir: parsubdirs
 +htmldir:
 $(MAKE) -C r.mapcalc
 $(MAKE) parsubdirs
 }}}

 BTW, given that there are 200 compilation and 40 linking commands
 occurring in the interval in question, I'm quite surprised that you
 managed to actually trigger this error.

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

[GRASS-dev] Re: [GRASS GIS] #916: GRASS 7: make install fails with --prefix

[GRASS GIS]

#916: GRASS 7: make install fails with --prefix
--+-
  Reporter:  neteler  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  normal   |   Milestone:  7.0.0
 Component:  default  | Version:  svn-trunk
Resolution:   |Keywords:   
  Platform:  Linux| Cpu:  Unspecified  
--+-
Comment (by glynn):

 Replying to [ticket:916 neteler]:

 > a series of bugs appear which indicate that the --prefix path
 > was not properly propagated. The problem might be that the
 > Makefile no longer has an "install" target (guessing).

 The "install" target is in Install.make, which is "include"d from the top-
 level Makefile.

 The problem is that r40491 removed the "BINDIR=${UNIX_BIN}" with the
 intention of just using $(UNIX_BIN) instead, but didn't follow through.

 Fixed in r40882.

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

[GRASS-dev] Re: [GRASS GIS] #916: GRASS 7: make install fails with --prefix

[GRASS GIS]

#916: GRASS 7: make install fails with --prefix
--+-
  Reporter:  neteler  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  normal   |   Milestone:  7.0.0
 Component:  default  | Version:  svn-trunk
Resolution:   |Keywords:   
  Platform:  Linux| Cpu:  Unspecified  
--+-
Comment (by hamish):

 ah,

 Casey Vandenberg wrote:
 {{{
 I was trying to install grass7.0 through svn so I could do some testing
 and see some of the future development. I had no errors after typing in
 make, but when I make install I get the following:

 r...@silver:/usr/local/src/grass_trunk# make install
 echo /usr/local/src/grass_trunk/bin.x86_64-unknown-linux-gnu/grass70
 /usr/local/src/grass_trunk/bin.x86_64-unknown-linux-gnu/grass70
 make[1]: Entering directory `/usr/local/src/grass_trunk'   test -d
 /usr/local/grass-7.0.svn || mkdir -p -m 755 /usr/local/grass-7.0.svn
 test -d  || mkdir -p -m 755
 sed -e "s#^GISBASE.*#GISBASE=/usr/local/grass-7.0.svn#"
 /usr/local/src/grass_trunk/bin.x86_64-unknown-linux-gnu/grass70.sh >
 /grass70.sh
 sed -e 's#^gisbase = ".*"#gisbase = "/usr/local/grass-7.0.svn"#'
 /usr/local/src/grass_trunk/bin.x86_64-unknown-linux-gnu/grass70 > /grass70
 chmod a+x /grass70
 tar cBCf /usr/local/src/grass_trunk/dist.x86_64-unknown-linux-gnu - . |
 tar xBCf /usr/local/grass-7.0.svn - 2>/dev/null   sed
 's#'/usr/local/src/grass_trunk/dist.x86_64-unknown-linux-
 gnu'#'/usr/local/grass-7.0.svn'#g' /usr/local/src/grass_trunk/dist.x86_64-
 unknown-linux-gnu/etc/fontcap > /usr/local/grass-7.0.svn/etc/fontcap
 /usr/bin/install -c  config.status /usr/local/grass-7.0.svn/config.status
 chmod -R a+rX /usr/local/grass-7.0.svn 2>/dev/null
 tar cBf - gem/skeleton | tar xBCf /usr/local/grass-7.0.svn/etc -
 2>/dev/null
 /usr/bin/install -c  gem/gem70  2>/dev/null
 make[1]: [real-install] Error 1 (ignored)
 make[1]: Leaving directory `/usr/local/src/grass_trunk'
 }}}


 so is that in GEM or, ... ?

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

[GRASS-dev] Re: [GRASS GIS] #916: GRASS 7: make install fails with --prefix

[GRASS GIS]

#916: GRASS 7: make install fails with --prefix
--+-
  Reporter:  neteler  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  normal   |   Milestone:  7.0.0
 Component:  default  | Version:  svn-trunk
Resolution:   |Keywords:   
  Platform:  Linux| Cpu:  Unspecified  
--+-
Comment (by hamish):

 can you post the errors? I recently added pathname variable quoting to ./
 install-sh and may have got over zealous with it.

 Does it happen with 6.5 or 6.4? (changes were backported)


 Hamish

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

[GRASS-dev] Re: [GRASS GIS] #908: No Font Definition File, windows xp

[GRASS GIS]

#908: No Font Definition File, windows xp
---+
  Reporter:  voncasec  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  critical  |   Milestone:  6.4.0
 Component:  Installation  | Version:  svn-releasebranch64  
Resolution:|Keywords:  v.label.sa, g.mkfontcap, wingrass
  Platform:  MSWindows XP  | Cpu:  Unspecified  
---+
Comment (by glynn):

 Replying to [comment:10 hellik]:

 > what does this mean for running g.mkfontcap outside a Grass-session (and
 accordingly for the NSIS-installer)? which parameters have to be set for
 working g.mkfontcap outside a Grass-session?

 GISRC should no longer have to be set. GISBASE must still be set (this
 eliminates the need for the installer to set GRASS_FONT_CAP, as the
 default of $GISBASE/etc/fontcap will work).

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

[GRASS-dev] Re: [GRASS GIS] #827: standalone-installer: execution failed on g.proj.exe -p

[GRASS GIS]

#827: standalone-installer: execution failed on g.proj.exe -p
---+
  Reporter:  timmie|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  normal|   Milestone:  6.4.0
 Component:  Installation  | Version:  svn-releasebranch64  
Resolution:|Keywords:  wingrass 
  Platform:  MSWindows XP  | Cpu:  x86-32   
---+
Comment (by glynn):

 Replying to [comment:20 timmie]:

 > what can I do to help debugging this?
 >
 > I does not work neither with wxPython nor with TCLTK.
 >
 > All report that there is either a problem with g.region or g.proj.

 The obvious common factor between g.region and g.proj is GDAL.

 I would guess that the libtiff.dll which is being loaded isn't the one
 which GDAL wants. You can use [http://www.dependencywalker.com/ Dependency
 Walker] to determine where libraries are being loaded from.

 The %PATH% environment variable is the last resort for locating libraries,
 so if there is a libtiff.dll in e.g. Windows or Windows/System32, it will
 take precedence. The only locations which are ahead of the Windows
 directories are the executable's directory (i.e. $GISBASE/bin) and any "
 Side-by-Side Assemblies" specified in the program's manifest (if it has
 one).

 We're already faced with having to create manifests to keep UAC happy, so
 it would be useful if someone could read up on this stuff and figure out
 how to use manifests to control searching for DLLs.

-- 
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 + matplotlib on mac osx snow leopard

[William Kyngesburye]

That's the matplotlib freetype module, but what about the freetype library used 
during matpotlib compilation?

On Feb 8, 2010, at 12:37 PM, Massimo Di Stefano wrote:

> Hi William,
> 
> don't know if these note can help to know where is the problem :
> 
> 
> The matplotlib freetype libs are build with both architecture : 
> 
> 
> GRASS 6.5.svn (spearfish60):~ > file 
> /Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/ft2font.so
> /Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/ft2font.so:
>  Mach-O universal binary with 2 architectures
> /Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/ft2font.so
>  (for architecture i386): Mach-O bundle i386
> /Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/ft2font.so
>  (for architecture x86_64):   Mach-O 64-bit bundle x86_64
> GRASS 6.5.svn (spearfish60):~ > 
> 

-
William Kyngesburye 
http://www.kyngchaos.com/

The equator is so long, it could encircle the earth completely once.

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

[GRASS-dev] Re: [GRASS GIS] #902: nviz (tcl) fails on wingrass

[GRASS GIS]

#902: nviz (tcl) fails on wingrass
---+
  Reporter:  hamish|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  critical  |   Milestone:  6.4.0
 Component:  NVIZ  | Version:  svn-trunk
Resolution:|Keywords:   
  Platform:  All   | Cpu:  All  
---+
Comment (by glynn):

 Replying to [comment:16 glynn]:

 > I think that it might be better to change the startup, moving the top of
 parse_command() (everything up to and including the G_parser() call) into
 main(), so that it's a normal "GRASS module" main(). If G_parser()
 indicates normal operation (i.e. not --help, --ui, etc), we call Tk_Main()
 with "fabricated" argc and argv (i.e. insert the "-f nviz2.2_script"). For
 --help, --ui etc, Tcl/Tk never gets involved.
 >
 > This doesn't allow the nviz binary to be used to run arbitrary scripts,
 but I'm not so sure that works anyhow.

 I've done this for 7.0 in r40879. The nviz binary is installed into
 $GISBASE/bin; the script and batch file aren't used. If argv[1] is '-f',
 it behaves like "wish", otherwise it behaves like a GRASS module:
 G_gisinit(), G_parser(), then calls Tk_Main() with argv = {"nviz", "-f",
 ".../nviz2.2_script", NULL}. It appears to do the right thing for all
 cases (nviz, nviz -q, nviz --ui (then "Run"), nviz elevation.dem), at
 least on Linux (compiling on Windows takes a while).

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

Re: [GRASS-dev] Grass7 - Trunk Install from svn question

[Markus Neteler]

On Tue, Feb 9, 2010 at 12:48 AM, Casey Vandenberg
 wrote:
> I was trying to install grass7.0 through svn so I could do some testing and
> see some of the future development. I had no errors after typing in make,
> but when I make install I get the following:
>
> r...@silver:/usr/local/src/grass_trunk# make install
> echo /usr/local/src/grass_trunk/bin.x86_64-unknown-linux-gnu/grass70
> /usr/local/src/grass_trunk/bin.x86_64-unknown-linux-gnu/grass70    make[1]:
> Entering directory `/usr/local/src/grass_trunk'           test -d
> /usr/local/grass-7.0.svn || mkdir -p -m 755 /usr/local/grass-7.0.svn
> test -d  || mkdir -p -m 755
>  sed -e "s#^GISBASE.*#GISBASE=/usr/local/grass-7.0.svn#"
> /usr/local/src/grass_trunk/bin.x86_64-unknown-linux-gnu/grass70.sh >
> /grass70.sh
> sed -e 's#^gisbase = ".*"#gisbase = "/usr/local/grass-7.0.svn"#'
> /usr/local/src/grass_trunk/bin.x86_64-unknown-linux-gnu/grass70 > /grass70
> chmod a+x /grass70
>
> tar cBCf /usr/local/src/grass_trunk/dist.x86_64-unknown-linux-gnu - . | tar
> xBCf /usr/local/grass-7.0.svn - 2>/dev/null                   sed
> 's#'/usr/local/src/grass_trunk/dist.x86_64-unknown-linux-gnu'#'/usr/local/grass-7.0.svn'#g'
> /usr/local/src/grass_trunk/dist.x86_64-unknown-linux-gnu/etc/fontcap >
> /usr/local/grass-7.0.svn/etc/fontcap
> /usr/bin/install -c  config.status /usr/local/grass-7.0.svn/config.status
> chmod -R a+rX /usr/local/grass-7.0.svn 2>/dev/null
> tar cBf - gem/skeleton | tar xBCf /usr/local/grass-7.0.svn/etc - 2>/dev/null
> /usr/bin/install -c  gem/gem70  2>/dev/null
> make[1]: [real-install] Error 1 (ignored)
> make[1]: Leaving directory `/usr/local/src/grass_trunk'
>
> I can not seem to get the install made, any pointers on this one.

"Amusingly", I have opened a similar ticket in the same moment:
http://trac.osgeo.org/grass/ticket/916

Hint for now: no need to install GRASS, you can use it right away
from the compile directory (bin.ARCH/grass70).

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

[GRASS-dev] [GRASS GIS] #916: GRASS 7: make install fails with --prefix

[GRASS GIS]

#916: GRASS 7: make install fails with --prefix
-+--
 Reporter:  neteler  |   Owner:  grass-dev@lists.osgeo.org
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  default  | Version:  svn-trunk
 Keywords:   |Platform:  Linux
  Cpu:  Unspecified  |  
-+--
 When using
 {{{
 ./configure --prefix=/some/path
 }}}

 compiling and then running
 {{{
 make install
 }}}

 a series of bugs appear which indicate that the --prefix path
 was not properly propagated. The problem might be that the
 Makefile no longer has an "install" target (guessing).

 Markus

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

[GRASS-dev] Grass7 - Trunk Install from svn question

[Casey Vandenberg]

I was trying to install grass7.0 through svn so I could do some testing 
and see some of the future development. I had no errors after typing in 
make, but when I make install I get the following:


r...@silver:/usr/local/src/grass_trunk# make install
echo /usr/local/src/grass_trunk/bin.x86_64-unknown-linux-gnu/grass70
/usr/local/src/grass_trunk/bin.x86_64-unknown-linux-gnu/grass70
make[1]: Entering directory `/usr/local/src/grass_trunk'   
test -d /usr/local/grass-7.0.svn || mkdir -p -m 755 /usr/local/grass-7.0.svn
test -d  || mkdir -p -m 755
sed -e "s#^GISBASE.*#GISBASE=/usr/local/grass-7.0.svn#" 
/usr/local/src/grass_trunk/bin.x86_64-unknown-linux-gnu/grass70.sh > 
/grass70.sh
sed -e 's#^gisbase = ".*"#gisbase = "/usr/local/grass-7.0.svn"#' 
/usr/local/src/grass_trunk/bin.x86_64-unknown-linux-gnu/grass70 > /grass70
chmod a+x 
/grass70 

tar cBCf /usr/local/src/grass_trunk/dist.x86_64-unknown-linux-gnu - . | 
tar xBCf /usr/local/grass-7.0.svn - 2>/dev/null   
sed 
's#'/usr/local/src/grass_trunk/dist.x86_64-unknown-linux-gnu'#'/usr/local/grass-7.0.svn'#g' 
/usr/local/src/grass_trunk/dist.x86_64-unknown-linux-gnu/etc/fontcap > 
/usr/local/grass-7.0.svn/etc/fontcap

/usr/bin/install -c  config.status /usr/local/grass-7.0.svn/config.status
chmod -R a+rX /usr/local/grass-7.0.svn 2>/dev/null
tar cBf - gem/skeleton | tar xBCf /usr/local/grass-7.0.svn/etc - 2>/dev/null
/usr/bin/install -c  gem/gem70  2>/dev/null
make[1]: [real-install] Error 1 (ignored)
make[1]: Leaving directory `/usr/local/src/grass_trunk'

I can not seem to get the install made, any pointers on this one.

Thanks,

Casey

p.s Thanks to the user and dev groups for helping out with all previous 
questions.
p.p.s. I have really enjoyed using GRASS since the move away from tcl-tk 
towards wx-python. The interface is far more user friendly and I hope it 
will appeal to other GIS users out there.

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

[GRASS-dev] Re: [GRASS GIS] #908: No Font Definition File, windows xp

[GRASS GIS]

#908: No Font Definition File, windows xp
---+
  Reporter:  voncasec  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  critical  |   Milestone:  6.4.0
 Component:  Installation  | Version:  svn-releasebranch64  
Resolution:|Keywords:  v.label.sa, g.mkfontcap, wingrass
  Platform:  MSWindows XP  | Cpu:  Unspecified  
---+
Comment (by hellik):

 Replying to [comment:9 glynn]:
 > Replying to [comment:8 glynn]:
 >
 > > AFAICT, the simplest fix is to add:
 > {{{
 > G_set_gisrc_mode(G_GISRC_MODE_MEMORY);
 > }}}
 > > to `G_no_gisinit()`.
 >
 > Oops. It took me all of two minutes to realise that isn't going to work
 (it breaks >g.proj and g.gisenv). I've moved the code into g.mkfontcap and
 g.dirseps in r40856 >(7.0) and r40857 (6.5).

 what does this mean for running g.mkfontcap outside a Grass-session (and
 accordingly for the NSIS-installer)? which parameters have to be set for
 working g.mkfontcap outside a Grass-session?

 Helmut

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

[GRASS-dev] Re: [GRASS GIS] #827: standalone-installer: execution failed on g.proj.exe -p

[GRASS GIS]

#827: standalone-installer: execution failed on g.proj.exe -p
---+
  Reporter:  timmie|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  normal|   Milestone:  6.4.0
 Component:  Installation  | Version:  svn-releasebranch64  
Resolution:|Keywords:  wingrass 
  Platform:  MSWindows XP  | Cpu:  x86-32   
---+
Comment (by timmie):

 Hello,
 what can I do to help debugging this?

 I does not work neither with wxPython nor with TCLTK.

 All report that there is either a problem with g.region or g.proj.

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

[GRASS-dev] Re: [GRASS GIS] #914: Add multi-channel "import" to r.external (as in r.in.gdal)

[GRASS GIS]

#914: Add multi-channel "import" to r.external (as in r.in.gdal)
--+-
  Reporter:  neteler  |   Owner:  grass-dev@lists.osgeo.org
  Type:  enhancement  |  Status:  new  
  Priority:  normal   |   Milestone:  6.5.0
 Component:  Raster   | Version:  svn-trunk
Resolution:   |Keywords:   
  Platform:  All  | Cpu:  All  
--+-
Comment (by neteler):

 Replying to [comment:1 glynn]:
 > Replying to [ticket:914 neteler]:
 > > Currently, r.external "imports" only the first channel, not all
 > > available channels as r.in.gdal does:
 >
 > > The behaviour of r.in.gdal is more user-friendly, could r.external be
 improved?
 >
 > Try the attached patch (untested).

 As always, it works out of the box :) Also tested with appropriate
 modifications in 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] grass is a monad?

[Glynn Clements]

Radim Blazek wrote:

> > Also, what kind of fatal errors can occur while in the middle of
> > vector editing that could reasonably be recovered from?
> 
> Probably I don't understand the question, for any error I would prefer
> to give a decent message
> (in window box) and stop editing (even with corrupted vector) but
> don't crash the application.

The GRASS way to achieve this is to make the editor a separate
process.

> > I'm not particularly averse to libraries using status returns, so long
> > as this doesn't:
> >
> > 1. propagate up to the API used by modules,
> 
> So you would suggest a separate set of functions for modules and QGIS/vdigit?

Actually, I would suggest QGIS/vdigit isolating actions within a child
process, rather than complicating the rest of GRASS for the sake of
two programs, one of which isn't part of GRASS and the other was
designed incorrectly from the outset.

But if there are reasons for specific functions to have status
returns, then I would suggest also having a wrapper which signals a
fatal error.

Doing this wholesale would make too much of a mess, though.

> > 2. "infest" a large portion of the GRASS libraries, or
> > 3. mean that fatal errors end up being signalled at the highest levels
> > after most of the context has been lost.
> 
> What is wrong on calling G_fatal_error on each level from the first
> function where the error happened to the top and optionally  (i.e.
> modules wants exit, qgis/vdigit return value) either only print the
> message (call error routine) and return error code or exit (it means
> on the lowest level).

Exceptions would be nice, but implementing them in C is a mess and
re-writing GRASS in C++ isn't an option.

Removing the __attribute__((noreturn)) from G_fatal_error() requires a
substantial re-write, and isn't an option IMHO.

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

[GRASS-dev] Re: [GRASS GIS] #915: r.proj.seg: doesn't copy cats/ file

[GRASS GIS]

#915: r.proj.seg: doesn't copy cats/ file
-+--
  Reporter:  hamish  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect  |  Status:  new  
  Priority:  normal  |   Milestone:  6.4.0
 Component:  Raster  | Version:  svn-develbranch6 
Resolution:  |Keywords:  r.proj   
  Platform:  Linux   | Cpu:  x86-32   
-+--
Comment (by glynn):

 Replying to [ticket:915 hamish]:

 > it seems that r.proj.seg forgets to copy over the cats/ file to the new
 location, so the map title etc. are lost in translation.

 Also true of r.proj. Note that copying categories is only meaningful for
 method=nearest; interpolation will result in an FP map.

-- 
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 Scripts access to channel headers info

[Glynn Clements]

Massimo Di Stefano wrote:

> Hi, maybe the grass-python bindings can help you ?
> 
> from grass, starting python :
> 
> In [1]: import grass.script as grass
> 
> In [2]: dict_region_info = dict(x.split('=', 1) for x in
> grass.read_command('r.info', flags = 'rstgudmp', map =
> 'elevation.10m').strip().replace('"','').replace('(','').replace(')','').split('\n')
> if '=' in x)

raster_info() already does this; it also converts the bounds and range
to numbers:

> grass.raster_info('elevation.dem')
{'north': 4928000.0,
 'timestamp': '"none"',
 'min': 1066.0,
 'datatype': 'CELL',
 'max': 1840.0,
 'ewres': 30.0,
 'vertical_datum': '(none)',
 'west': 590010.0,
 'units': '(none)',
 'title': 'DEM (7.5 minute) (elevation)',
 'east': 609000.0,
 'nsres': 30.0,
 'south': 4914020.0}

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

Re: [GRASS-dev] Fixing r.li

[Markus Neteler]

On Wed, Jan 27, 2010 at 2:50 PM, Glynn Clements
 wrote:
>
> Glynn Clements wrote:
>
>> Is anyone familiar with r.li?
>>
>> How easy would it be to get rid of the (Unix-specific) client-server
>> framework so that the various r.li.* modules are just normal modules?
>
> I've done this, but I can't test that it still works as I don't have
> any idea how to use it.
>
> Also, r.li.setup is currently disabled (due to requiring Tcl/Tk) and
> there doesn't appear to be any documention on creating a configuration
> file without it.

Sorry for the delay. Attached a config file:
$HOME/.grass7/r.li/landclass96_conf

Usage (North Carolina data set [1]):
g.region rast=landclass96
r.li.shannon map=landclas...@permanent conf=landclass96_conf
output=landclass96_shannon --o

Markus

[1] http://grass.osgeo.org/download/data.php


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

[GRASS-dev] Re: [GRASS GIS] #914: Add multi-channel "import" to r.external (as in r.in.gdal)

[GRASS GIS]

#914: Add multi-channel "import" to r.external (as in r.in.gdal)
--+-
  Reporter:  neteler  |   Owner:  grass-dev@lists.osgeo.org
  Type:  enhancement  |  Status:  new  
  Priority:  normal   |   Milestone:  6.5.0
 Component:  Raster   | Version:  svn-trunk
Resolution:   |Keywords:   
  Platform:  All  | Cpu:  All  
--+-
Comment (by glynn):

 Replying to [ticket:914 neteler]:
 > Currently, r.external "imports" only the first channel, not all
 > available channels as r.in.gdal does:

 > The behaviour of r.in.gdal is more user-friendly, could r.external be
 improved?

 Try the attached patch (untested).

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

[GRASS-dev] Re: [GRASS GIS] #902: nviz (tcl) fails on wingrass

[GRASS GIS]

#902: nviz (tcl) fails on wingrass
---+
  Reporter:  hamish|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  critical  |   Milestone:  6.4.0
 Component:  NVIZ  | Version:  svn-trunk
Resolution:|Keywords:   
  Platform:  All   | Cpu:  All  
---+
Comment (by glynn):

 Replying to [comment:14 hamish]:
 > Ok, now it seems to work ok from the 6.5 command line and GUIs. So
 backported to 6.4.
 >
 > but still a weird problem in trunk:
 >
 >  * G7> nviz --ui
 >  * (module option gui opens)
 >  * select raster elevation: elevation@permanent
 >  * [Run]
 >  * a window flashes open then closes again and this is written to the
 module GUI output tab:

 Ugh. Try this:

 {{{
 --- visualization/nviz/src/nviz_init.c  (revision 40859)
 +++ visualization/nviz/src/nviz_init.c  (working copy)
 @@ -137,7 +137,7 @@
   * If left in it treats it as a elev arg and tries to open
   */
  argv2 = G_malloc((argc + 2) * sizeof(char *));
 -argv2[0] = (char *) cmd;
 +argv2[0] = "nviz";
  for (ii = 0; ii < argc; ii++)
 argv2[ii + 1] = (char *)argv[ii];
  argv2[argc + 1] = NULL;
 }}}

 No idea why it would work in 6.x without this.

 I think that it might be better to change the startup, moving the top of
 parse_command() (everything up to and including the G_parser() call) into
 main(), so that it's a normal "GRASS module" main(). If G_parser()
 indicates normal operation (i.e. not --help, --ui, etc), we call Tk_Main()
 with "fabricated" argc and argv (i.e. insert the "-f nviz2.2_script"). For
 --help, --ui etc, Tcl/Tk never gets involved.

 This doesn't allow the nviz binary to be used to run arbitrary scripts,
 but I'm not so sure that works anyhow.

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

Re: [GRASS-dev] lidar tools update in grass7

[Markus Neteler]

On Mon, Feb 8, 2010 at 5:18 AM, Hamish  wrote:
> Markus Metz wrote:
...
>> I forgot to mention, there is a problem with sqlite, it is much slower
>> than dbf, no idea if this is a problem of my system or of the grass
>> sqlite driver or of the way auxiliary tables are accessed by the lidar
>> tools.
>
> that sounds vaguely familiar, but as a general thing not necessarily
> to do with v.lidar. probably something about it in the archives?

I found some older conversation incl. patches and speed tests:

http://lists.osgeo.org/pipermail/grass-user/2009-June/051009.html
... perhaps useful?


On Mon, Feb 8, 2010 at 9:17 AM, Markus Metz
 wrote:
> I discovered two little tricks: first, create the table, close database and
> driver, open database and driver again, work with table, second, creating an
> index on the table if possible helps too. Tested with sqlite and dbf.

I wonder if sqlite is creating some index when creating/closing/opening again?

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

Re: [GRASS-dev] v.in.ogr - Buffer overflow error.v.in.ogr buffer overflow detected

[Markus Neteler]

On Mon, Feb 8, 2010 at 7:10 PM, Markus Metz
 wrote:
> Casey Vandenberg wrote:
>> I know this problem has crept up before for some people, but has anyone
>> encountered this, or resolved this problem using a 9.10 build of Ubuntu?

Besides the other suggestions, also
http://trac.osgeo.org/grass/ticket/402
(resolved) comes to mind.

In the ticket they say that GDAL 1.5 is causing problems on Ubuntu and an
update to 1.6 helped (you use  /usr/lib/gdal15plugins/).

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

Re: [GRASS-dev] grass is a monad?

[Radim Blazek]

On Mon, Jan 18, 2010 at 3:33 AM, Glynn Clements
 wrote:
>> Everything except vector editing. I don't see any reasonable
>> possibility to do interactive vector editing via a GRASS module. For
>> vector editing, I need immediate response which is visualized on
>> display (e.g. if a vertex was moved and area topology was broken it
>> must be displayed). It is impossible to open/close a vector for every
>> single operation, it would take too long time for larger vectors.
>
> For this specific case, is it possible to isolate a subset of the
> vector library such that it can be used reasonably by both GRASS and
> QGIS (and the wxGUI's vdigit module, which is just as bad in this
> regard)?

The subset would be almost the whole vector library (Vlib,diglib,rtree).

> Also, what kind of fatal errors can occur while in the middle of
> vector editing that could reasonably be recovered from?

Probably I don't understand the question, for any error I would prefer
to give a decent message
(in window box) and stop editing (even with corrupted vector) but
don't crash the application.

> I'm not particularly averse to libraries using status returns, so long
> as this doesn't:
>
> 1. propagate up to the API used by modules,

So you would suggest a separate set of functions for modules and QGIS/vdigit?

> 2. "infest" a large portion of the GRASS libraries, or
> 3. mean that fatal errors end up being signalled at the highest levels
> after most of the context has been lost.

What is wrong on calling G_fatal_error on each level from the first
function where the error happened to the top and optionally  (i.e.
modules wants exit, qgis/vdigit return value) either only print the
message (call error routine) and return error code or exit (it means
on the lowest level).


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

Re: [GRASS-dev] grass + matplotlib on mac osx snow leopard

[Massimo Di Stefano]

Hi William,

don't know if these note can help to know where is the problem :


The matplotlib freetype libs are build with both architecture : 


GRASS 6.5.svn (spearfish60):~ > file 
/Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/ft2font.so
/Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/ft2font.so:
 Mach-O universal binary with 2 architectures
/Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/ft2font.so
 (for architecture i386):   Mach-O bundle i386
/Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/ft2font.so
 (for architecture x86_64): Mach-O 64-bit bundle x86_64
GRASS 6.5.svn (spearfish60):~ > 


if i try to run matplotlib  "import ft2font" from a  grass shell, it fails if i 
use the standard python executable (python, python2.6, pythonw) 
while it  ("from matplotlib import ft2font") works  if i run it from 
"grass->ipython"

###

from grass
run python :

>>> from matplotlib import ft2font
Traceback (most recent call last):
  File "", line 1, in 
ImportError: 
dlopen(/Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/ft2font.so,
 2): Symbol not found: _FT_Attach_File
  Referenced from: 
/Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/ft2font.so
  Expected in: flat namespace
 in 
/Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/ft2font.so
>>> 


###

from grass 
run ipython :

GRASS 6.5.svn (spearfish60):~ > ipython
Python 2.6.1 (r261:67515, Jul  7 2009, 23:51:51) 
Type "copyright", "credits" or "license" for more information.

IPython 0.11.bzr.r1205 -- An enhanced Interactive Python.
? -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help  -> Python's own help system.
object?   -> Details about 'object'. ?object also works, ?? prints more.

In [1]: from matplotlib import ft2font

###

from bash
run python :

Last login: Mon Feb  8 19:13:21 on ttys000
MacBook-Pro-15-di-Massimo-Di-Stefano:~ sasha$ python
Python 2.6.1 (r261:67515, Jul  7 2009, 23:51:51) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from matplotlib import ft2font
>>> 

###

this the grass error tring to use the module, it is the same error i get from 
grass->python


GRASS 6.5.svn (spearfish60):~ > r.ipso.py Traceback (most recent call last):
  File "/Library/GRASS/6.5/Modules/bin/r.ipso.py", line 27, in 
import matplotlib.pyplot as plt
  File 
"/Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/pyplot.py",
 line 7, in 
from matplotlib.figure import Figure, figaspect
  File 
"/Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/figure.py",
 line 18, in 
from axes import Axes, SubplotBase, subplot_class_factory
  File 
"/Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/axes.py",
 line 12, in 
import matplotlib.axis as maxis
  File 
"/Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/axis.py",
 line 10, in 
import matplotlib.font_manager as font_manager
  File 
"/Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/font_manager.py",
 line 52, in 
from matplotlib import ft2font
ImportError: 
dlopen(/Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/ft2font.so,
 2): Symbol not found: _FT_Attach_File
  Referenced from: 
/Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/ft2font.so
  Expected in: flat namespace
 in 
/Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/ft2font.so




GRASS 6.5.svn (spearfish60):~ > file 
/Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/ft2font.so
/Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/ft2font.so:
 Mach-O universal binary with 2 architectures
/Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/ft2font.so
 (for architecture i386):   Mach-O bundle i386
/Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/ft2font.so
 (for architecture x86_64): Mach-O 64-bit bundle x86_64
GRASS 6.5.svn (spearfish60):~ > 


thanks for any suggestions to debug thisproblem.
ciao,

Massimo.



Il giorno 08/feb/2010, alle ore 16.05, William Kyngesbu

Re: [GRASS-dev] v.in.ogr - Buffer overflow error.v.in.ogr buffer overflow detected

[Markus Metz]

Casey Vandenberg wrote:

Hi,

I know this problem has crept up before for some people, but has 
anyone encountered this, or resolved this problem using a 9.10 build 
of Ubuntu?

Any advice would be appreciated,
It seems there are two versions of grass installed, you are using 
6.4.0svn, and gdal/ogr links against 6.4.0RC5. That could be a problem, see


GRASS 6.4.0svn (NewShoshoni):~ >

and
  
/usr/local/grass-6.4.0svn/bin/v.in.ogr

but
/usr/lib/grass64/lib/libgrass_I.6.4.0RC5.so   

and
/usr/lib/gdal15plugins/ogr_GRASS.so 

Maybe it helps to uninstall 6.4.0RC5, also removing the GDAL-GRASS plugin.

Just a guess,

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

[GRASS-dev] v.in.ogr - Buffer overflow error.v.in.ogr buffer overflow detected

[Casey Vandenberg]

Hi,

I know this problem has crept up before for some people, but has anyone 
encountered this, or resolved this problem using a 9.10 build of Ubuntu?

Any advice would be appreciated,

Casey


GRASS 6.4.0svn (NewShoshoni):~ > *** buffer overflow detected ***: 
v.in.ogr terminated
=== Backtrace: 
= 
/lib/libc.so.6(__fortify_fail+0x37)[0x7fe5714725f7]   

/lib/libc.so.6[0x7fe5714715a0]

/lib/libc.so.6[0x7fe571470c9b]

/lib/libc.so.6(__snprintf_chk+0x7a)[0x7fe571470b6a]   

/usr/lib/libgdal1.5.0.so.1(_ZN10OGRFeature16GetFieldAsStringEi+0x302)[0x7fe5721924d2] 

v.in.ogr(main+0x279b)[0x407237]   

/lib/libc.so.6(__libc_start_main+0xfd)[0x7fe571399abd]

v.in.ogr[0x4039d9]

=== Memory map: 
 
0040-0040a000 r-xp  08:01 17900  
/usr/local/grass-6.4.0svn/bin/v.in.ogr
00609000-0060a000 r--p 9000 08:01 17900  
/usr/local/grass-6.4.0svn/bin/v.in.ogr
0060a000-0060b000 rw-p a000 08:01 17900  
/usr/local/grass-6.4.0svn/bin/v.in.ogr
01346000-01367000 rw-p  00:00 0  
[heap]   
7fe5680ce000-7fe5680da000 r-xp  08:01 601
/lib/libnss_files-2.10.1.so  
7fe5680da000-7fe5682d9000 ---p c000 08:01 601
/lib/libnss_files-2.10.1.so  
7fe5682d9000-7fe5682da000 r--p b000 08:01 601
/lib/libnss_files-2.10.1.so  
7fe5682da000-7fe5682db000 rw-p c000 08:01 601
/lib/libnss_files-2.10.1.so  
7fe5682db000-7fe5682e5000 r-xp  08:01 611
/lib/libnss_nis-2.10.1.so
7fe5682e5000-7fe5684e4000 ---p a000 08:01 611
/lib/libnss_nis-2.10.1.so
7fe5684e4000-7fe5684e5000 r--p 9000 08:01 611
/lib/libnss_nis-2.10.1.so
7fe5684e5000-7fe5684e6000 rw-p a000 08:01 611
/lib/libnss_nis-2.10.1.so
7fe5684e6000-7fe5684ed000 r-xp  08:01 597
/lib/libnss_compat-2.10.1.so 
7fe5684ed000-7fe5686ed000 ---p 7000 08:01 597
/lib/libnss_compat-2.10.1.so 
7fe5686ed000-7fe5686ee000 r--p 7000 08:01 597
/lib/libnss_compat-2.10.1.so 
7fe5686ee000-7fe5686ef000 rw-p 8000 08:01 597
/lib/libnss_compat-2.10.1.so 
7fe5686ef000-7fe5687e3000 r-xp  08:01 16382  
/usr/lib/libfftw3.so.3.2.3   
7fe5687e3000-7fe5689e2000 ---p 000f4000 08:01 16382  
/usr/lib/libfftw3.so.3.2.3   
7fe5689e2000-7fe5689e9000 r--p 000f3000 08:01 16382  
/usr/lib/libfftw3.so.3.2.3   
7fe5689e9000-7fe5689ea000 rw-p 000fa000 08:01 16382  
/usr/lib/libfftw3.so.3.2.3   
7fe5689ea000-7fe568a28000 r-xp  08:01 592
/lib/libncurses.so.5.7   
7fe568a28000-7fe568c28000 ---p 0003e000 08:01 592
/lib/libncurses.so.5.7   
7fe568c28000-7fe568c2c000 r--p 0003e000 08:01 592
/lib/libncurses.so.5.7   
7fe568c2c000-7fe568c2d000 rw-p 00042000 08:01 592
/lib/libncurses.so.5.7   
7fe568c2d000-7fe568c33000 r-xp  08:01 789964 
/usr/lib/grass64/lib/libgrass_gmath.6.4.0RC5.so
7fe568c33000-7fe568e32000 ---p 6000 08:01 789964 
/usr/lib/grass64/lib/libgrass_gmath.6.4.0RC5.so
7fe568e32000-7fe568e33000 r--p 5000 08:01 789964 
/usr/lib/grass64/lib/libgrass_gmath.6.4.0RC5.so
7fe568e33000-7fe568e34000 rw-p 6000 08:01 789964 
/usr/lib/grass64/lib/libgrass_gmath.6.4.0RC5.so
7fe568e34000-7fe568e38000 r-xp  08:01 789978 
/usr/lib/grass64/lib/libgrass_vask.6.4.0RC5.so
7fe568e38000-7fe569037000 ---p 4000 08:01 789978 
/usr/lib/grass64/lib/libgrass_vask.6.4.0RC5.so
7fe569037000-7fe569038000 r--p 3000 08:01 789978 
/usr/lib/grass64/lib/libgrass_vask.6.4.0RC5.so
7fe569038000-7fe569039000 rw-p 4000 08:01 789978 
/usr/lib/grass64/lib/libgrass_vask.6.4.0RC5.so
7fe569039000-7fe56903a000 rw-p  00:00 
0
7fe56903a000-7fe569043000 r-xp  08:01 789982  

[GRASS-dev] [GRASS GIS] #915: r.proj.seg: doesn't copy cats/ file

[GRASS GIS]

#915: r.proj.seg: doesn't copy cats/ file
+---
 Reporter:  hamish  |   Owner:  grass-dev@lists.osgeo.org
 Type:  defect  |  Status:  new  
 Priority:  normal  |   Milestone:  6.4.0
Component:  Raster  | Version:  svn-develbranch6 
 Keywords:  r.proj  |Platform:  Linux
  Cpu:  x86-32  |  
+---
 Hi,

 it seems that r.proj.seg forgets to copy over the cats/ file to the new
 location, so the map title etc. are lost in translation.


 Hamish

-- 
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 + matplotlib on mac osx snow leopard

[William Kyngesburye]

I haven't built matplotlib before, but it looks like it linked FreeType 
statically into ft2font.so.

You normally get an error about a missing architecture if that's the problem.  
But in the case of a statically linked library, maybe ft2font.so (matplotlib) 
is the right arch, but the linked freetype was not.  Because of the way Python 
modules are linked, you don't get link errors so you don't know until you run 
it.

Try checking the archs on the freetype used when compiling matplotlib, and 
check the archs on ft2font.so.  They should have the same archs.

On Feb 8, 2010, at 5:11 AM, Massimo Di Stefano wrote:

> Hi All,
> 
> I'm working on a script to generate graph from grass using matplotlib
> the script works fine on linux , but on osx it works only by command line
> 
> the script is :
> 
> https://svn.osgeo.org/grass/grass-addons/raster/r.ipso
> 
> the error tring to run it on osx is :
> 
> GRASS 7.0.svn (spearfish60):~ > r.ipso.py 
> Traceback (most recent call last):
>  File "/Library/Application Support/GRASS/7.0/Modules/bin/r.ipso.py", line 
> 27, in 
>import matplotlib.pyplot as plt
>  File 
> "/Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/pyplot.py",
>  line 7, in 
>from matplotlib.figure import Figure, figaspect
>  File 
> "/Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/figure.py",
>  line 18, in 
>from axes import Axes, SubplotBase, subplot_class_factory
>  File 
> "/Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/axes.py",
>  line 12, in 
>import matplotlib.axis as maxis
>  File 
> "/Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/axis.py",
>  line 10, in 
>import matplotlib.font_manager as font_manager
>  File 
> "/Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/font_manager.py",
>  line 52, in 
>from matplotlib import ft2font
> ImportError: 
> dlopen(/Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/ft2font.so,
>  2): Symbol not found: _FT_Attach_File
>  Referenced from: 
> /Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/ft2font.so
>  Expected in: flat namespace
> in 
> /Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/ft2font.so
> GRASS 7.0.svn (spearfish60):~ > 
> 
> 
> i have the same error in grass64 and 65 too.
> have you any hints about ?
> 
> maybe matplotlib is build on my osx only in 64 bit mode .. and this generate 
> the problems, how to debug ? 
> 
> if (from grass) i start python and try yo import " from matplotlib import 
> ft2font " i have no errors.
> 
> thanks for any suggestion.
> 
> Massimo.___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev

-
William Kyngesburye 
http://www.kyngchaos.com/

[Trillian]  What are you supposed to do WITH a maniacally depressed robot?

[Marvin]  You think you have problems?  What are you supposed to do if you ARE 
a maniacally depressed robot?  No, don't try and answer, I'm 50,000 times more 
intelligent than you and even I don't know the answer...

- HitchHiker's Guide to the Galaxy


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

[GRASS-dev] Re: [GRASS GIS] #885: WinGrass: displaying r.external-linked raster data not working

[GRASS GIS]

#885: WinGrass: displaying r.external-linked raster data not working
--+-
  Reporter:  hellik   |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  critical |   Milestone:  6.4.0
 Component:  Display  | Version:  svn-releasebranch64  
Resolution:   |Keywords:  r.external, WinGrass, osgeo4w
  Platform:  MSWindows Vista  | Cpu:  x86-32   
--+-
Comment (by hellik):

 Replying to [comment:27 hellik]:
 > Grass65
 > =>"d.rast -o map=testrl...@user1" is working and the linked testRlink-
 data is displayed in the wx-gui!
 >
 > what is the difference between Grass64 and Grass65 in this case?
 >
 > maybe anyone else can test the nightly builts of Grass64 and Grass65 for
 this issue?

 tested with the nightly build WinGRASS-6.4.SVN-r40852-1-Setup.exe on a
  WinXP32, displaying the linked raster in the wxgui is working.

 Helmut

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

[GRASS-dev] Re: [GRASS GIS] #485: r.external crash

[GRASS GIS]

#485: r.external crash
--+-
  Reporter:  hellik   |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  closed   
  Priority:  major|   Milestone:  6.4.0
 Component:  Raster   | Version:  6.4.0 RCs
Resolution:  fixed|Keywords:  r.external   
  Platform:  MSWindows Vista  | Cpu:  Unspecified  
--+-
Changes (by hellik):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Replying to [comment:3 neteler]:
 > Is this now fixed? see also #885 - please close here if #885 reports the
 same.

 tested with the nightly build WinGRASS-6.4.SVN-r40852-1-Setup.exe on a
 WinXP32, displaying the linked raster in the wxgui is working. so closing
 this report, because #885 reports the same.

 Helmut

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

Re: [GRASS-dev] Re: [GRASS GIS] #908: No Font Definition File, windows xp

[Doug_Newcomb]

Hamish,
Many government organizations that use Windows are going to LUA,
http://technet.microsoft.com/en-us/library/cc700846.aspx Least-privileged
User Account environments for most users.  Having a normal user need to do
anything as an administrator to run a program is almost a show-stopper for
deployment in these environments.

  So, I wholeheartedly applaud anything that can be done to make GRASS run
well under Windows without any administrative access.

Doug

Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-

The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior.   Life is too short for undocumented, proprietary data formats.


-grass-dev-boun...@lists.osgeo.org wrote: -

To: undisclosed-recipients:;
From: "GRASS GIS"
Sent by: grass-dev-boun...@lists.osgeo.org
Date: 02/05/2010 03:41AM
Subject: [GRASS-dev] Re: [GRASS GIS] #908: No Font Definition File,
 windows xp

#908: No Font Definition File, windows xp
---+

  Reporter:  voncasec      |
Owner:  grass-...@lists.osgeo.org

Type:  defect        |      Status:  new
  Priority:  critical      |
Milestone:  6.4.0
 Component:  Installation  |
Version:  svn-releasebranch64
Resolution:                |    Keywords:  v.label.sa, g.mkfontcap,
wingrass
  Platform:  MSWindows XP  |
Cpu:  Unspecified
---+

Comment (by hamish):

 ... but for be benefit of users without admin rights on the system it
 should probably happen as part of the installer.

 maybe for GRASS 7 we should first check for it in ~/.grass7/fontcap, and
 if not found there look for it in $(ETC)/fontcap?


 Hamish

--
Ticket URL:
GRASS GIS
___
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

[GRASS-dev] Re: [GRASS GIS] #905: WinGrass: include patched msys.bat in the WinGrass-Installer

[GRASS GIS]

#905: WinGrass: include patched msys.bat in the WinGrass-Installer
--+-
  Reporter:  hellik   |   Owner:  grass-dev@lists.osgeo.org
  Type:  enhancement  |  Status:  closed   
  Priority:  normal   |   Milestone:  6.4.0
 Component:  Packaging| Version:  svn-develbranch6 
Resolution:  fixed|Keywords:  wingrass, msys   
  Platform:  MSWindows Vista  | Cpu:  Unspecified  
--+-
Comment (by hamish):

 Re: rxvt isatty(0) on Windows
 {{{
 Keith Marshall wrote:
 > This feature has been known for a long time.  Considerable futile effort
 > has been expended on trying to fix it; we will not pursue it further.
 >
 > Since the formal release of MSYS-1.0.11, IIRC, we have recommended
 against
 > using rxvt as a terminal emulator for MSYS; you should use a standard
 > Windows console, or Console2, (a separate SF hosted project), instead.
 The
 > maintainer of rxvt, (for both MSYS and Cygwin), is on record recently on
 > the MinGW-dvlpr list, stating that "rxvt *must* die" on both platforms.
 }}}

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

re [GRASS-dev] g.proj -p - units is : meters or metres ?

[Massimo Di Stefano]

Hi Glynn,

apologize the private mail, i can see your answer on the list archive, but no 
reply is sent to my mail box (mybe some problems with the mailng list :-/)

### ### ###
Massimo Di Stefano wrote:

> i've old scripts that i'm using to parse the "g.proj" output
> 
> in it i have units == meters
> 
> but form recent svn 6.5 version i can see it use :   metres
> 
> GRASS 6.5.svn (spearfish60):~/wxpython/data_catalog > g.proj -p

> -PROJ_UNITS
> unit   : metre
> units  : metres
> meters : 1
> 
> 
> 
> is it a typo, or need i to modify my scripts to use :metre / metres ?

g.proj outputs whatever is in the PROJ_UNITS file. The textual
description of the unit can be whatever the user chooses it to be, or
in the case of "g.proj -c", whatever is obtained from the source
specified by georef=. GRASS itself only the unit/units fields for
display to the user; calculations use the numeric value in the meters
field.

What do your scripts use the "unit" or "units" field for?
### ### ###

I'm working on a script to send data from grass to ossimplanet,
it is :

http://svn.osgeo.org/ossim/trunk/gsoc/OssimPlanetSasha/r.planet.py


there is a "projinfo()" function i'm using it to retrieve if the location use 
degrees or projected coordinates
what i need is to extract the "center of the map" and use it in the  "zoom to" 
action.

if the location is in degrees i use :

setCLL(map)
location ..
while if projected (meters) i use :

setCPRJ(map)


in the example i used the spearfish dataset.
but as you pint me ... the ceck on the "units" string .. is not a good idea :-( 
beacouse the "units value"  is "user - dependent" 
and maybe someone that did a typo error defining the location will go in an 
error during the script execution.

regards,

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

Re: [GRASS-dev] GRASS Scripts access to channel headers info

[Massimo Di Stefano]

Hi, maybe the grass-python bindings can help you ?

from grass, starting python :

In [1]: import grass.script as grass

In [2]: dict_region_info = dict(x.split('=', 1) for x in 
grass.read_command('r.info', flags = 'rstgudmp', map = 
'elevation.10m').strip().replace('"','').replace('(','').replace(')','').split('\n')
 if '=' in x)

In [3]: dict_region_info
Out[3]: 
{'datatype': 'DCELL',
 'east': '609000',
 'ewres': '10',
 'max': '1846.743408',
 'min': '1061.064087',
 'north': '4928000',
 'nsres': '10',
 'south': '4914020',
 'timestamp': 'none',
 'title': ' elevation.10m',
 'units': '(none)',
 'vertical_datum': 'none',
 'west': '590010'}

In [4]: dict_region_info['east']
Out[4]: '609000'

the code maybe needs little adjustmens,  but it can give you an idea.




Il giorno 08/feb/2010, alle ore 11.36, António Rocha ha scritto:

> Thank you Markus. I suppose, for now, it's enough to give me a clue about 
> managing LANDSAT images
> By the way, is there any specific command to retrieve a single information 
> from metadata? I mean, r.info gives me a lot of information in a string.

maybe the grass-python bindings can help you ?

from grass, start python :

In [1]: import grass.script as grass

In [2]: dict_region_info = dict(x.split('=', 1) for x in 
grass.read_command('r.info', flags = 'rstgudmp', map = 
'elevation.10m').strip().replace('"','').replace('(','').replace(')','').split('\n')
 if '=' in x)

In [3]: dict_region_info
Out[3]: 
{'datatype': 'DCELL',
 'east': '609000',
 'ewres': '10',
 'max': '1846.743408',
 'min': '1061.064087',
 'north': '4928000',
 'nsres': '10',
 'south': '4914020',
 'timestamp': 'none',
 'title': ' elevation.10m',
 'units': '(none)',
 'vertical_datum': 'none',
 'west': '590010'}

In [4]: dict_region_info['east']
Out[4]: '609000'

the code maybe needs little adjustmens,  but it can give you an idea.


> Best regards
> Antonio
>> 
>> Markus Neteler wrote:
>>> 2010/2/4 António Rocha :
>>> 
>>>> Greetings all
>>>> 
>>>> I'm doing a few scripts that requires accessing LANDSAT/or other satellite
>>>> images channel header information (e.g. Gain/Bias). Is it possible to acess
>>>> that information through a Script file? I mean, having a script that
>>>> processes what I want and in the meanwhile uses some channel header values?
>>>>
>>> 
>>> See
>>> http://www.grassbook.org/examples_menu3rd.php
>>> -> CHAPTER 8: Scripts to bulk import LANDSAT-TM5/LANDSAT-TM7 scenes
>>>from GLCF Maryland into GRASS
>>>* glcf_landsat7_for_NC_SPM_WAKE_process.sh (reproject, spatial
>>> subset with GDAL)
>>>* glcf_landsat5_for_NC_SPM_WAKE_import.sh (import into GRASS)
>>>* glcf_landsat7_2000_for_NC_SPM_WAKE_import.sh (import into GRASS)
>>>* glcf_landsat7_2002_for_NC_SPM_WAKE_import.sh (import into GRASS)
>>> 
>>> You can then use r.info to retrieve the metadata and use them for 
>>> processing.
>>> 
>>> Hope this helps,
>>> Markus
>> 
>> 
> 
> 
> 
> __ Information from ESET NOD32 Antivirus, version of virus signature 
> database 4847 (20100208) __
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.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

[GRASS-dev] [GRASS GIS] #914: Add multi-channel "import" to r.external (as in r.in.gdal)

[GRASS GIS]

#914: Add multi-channel "import" to r.external (as in r.in.gdal)
-+--
 Reporter:  neteler  |   Owner:  grass-dev@lists.osgeo.org
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  6.5.0
Component:  Raster   | Version:  svn-trunk
 Keywords:   |Platform:  All  
  Cpu:  All  |  
-+--
 Currently, r.external "imports" only the first channel, not all
 available channels as r.in.gdal does:

 {{{
 r.in.gdal 014_03.jpg out=mymap -o
 WARNING: Over-riding projection check
  100%
 r.in.gdal complete. Raster map  created.
  100%
 r.in.gdal complete. Raster map  created.
  100%
 r.in.gdal complete. Raster map  created.
 }}}

 The behaviour of r.in.gdal is more user-friendly, could r.external be
 improved?

 thanks,
 Markus

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

[GRASS-dev] Re: [GRASS GIS] #485: r.external crash

[GRASS GIS]

#485: r.external crash
--+-
  Reporter:  hellik   |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  major|   Milestone:  6.4.0
 Component:  Raster   | Version:  6.4.0 RCs
Resolution:   |Keywords:  r.external   
  Platform:  MSWindows Vista  | Cpu:  Unspecified  
--+-
Comment (by neteler):

 Is this now fixed? see also #885 - please close here if #885 reports the
 same.

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

[GRASS-dev] grass + matplotlib on mac osx snow leopard

[Massimo Di Stefano]

Hi All,

I'm working on a script to generate graph from grass using matplotlib
the script works fine on linux , but on osx it works only by command line

the script is :

https://svn.osgeo.org/grass/grass-addons/raster/r.ipso

the error tring to run it on osx is :

GRASS 7.0.svn (spearfish60):~ > r.ipso.py 
Traceback (most recent call last):
  File "/Library/Application Support/GRASS/7.0/Modules/bin/r.ipso.py", line 27, 
in 
import matplotlib.pyplot as plt
  File 
"/Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/pyplot.py",
 line 7, in 
from matplotlib.figure import Figure, figaspect
  File 
"/Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/figure.py",
 line 18, in 
from axes import Axes, SubplotBase, subplot_class_factory
  File 
"/Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/axes.py",
 line 12, in 
import matplotlib.axis as maxis
  File 
"/Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/axis.py",
 line 10, in 
import matplotlib.font_manager as font_manager
  File 
"/Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/font_manager.py",
 line 52, in 
from matplotlib import ft2font
ImportError: 
dlopen(/Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/ft2font.so,
 2): Symbol not found: _FT_Attach_File
  Referenced from: 
/Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/ft2font.so
  Expected in: flat namespace
 in 
/Library/Python/2.6/site-packages/matplotlib-1.0.svn_r7892-py2.6-macosx-10.6-universal.egg/matplotlib/ft2font.so
GRASS 7.0.svn (spearfish60):~ > 


i have the same error in grass64 and 65 too.
have you any hints about ?

maybe matplotlib is build on my osx only in 64 bit mode .. and this generate 
the problems, how to debug ? 

if (from grass) i start python and try yo import " from matplotlib import 
ft2font " i have no errors.

thanks for any suggestion.

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

Re: [GRASS-dev] GRASS Scripts access to channel headers info

[António Rocha]

Thank you Markus. I suppose, for now, it's enough to give me a clue 
about managing LANDSAT images
By the way, is there any specific command to retrieve a single 
information from metadata? I mean, r.info gives me a lot of information 
in a string.

Best regards
Antonio


Markus Neteler wrote:

2010/2/4 António Rocha :
 

Greetings all

I'm doing a few scripts that requires accessing LANDSAT/or other 
satellite
images channel header information (e.g. Gain/Bias). Is it possible 
to acess

that information through a Script file? I mean, having a script that
processes what I want and in the meanwhile uses some channel header 
values?



See
http://www.grassbook.org/examples_menu3rd.php
-> CHAPTER 8: Scripts to bulk import LANDSAT-TM5/LANDSAT-TM7 scenes
from GLCF Maryland into GRASS
* glcf_landsat7_for_NC_SPM_WAKE_process.sh (reproject, spatial
subset with GDAL)
* glcf_landsat5_for_NC_SPM_WAKE_import.sh (import into GRASS)
* glcf_landsat7_2000_for_NC_SPM_WAKE_import.sh (import into GRASS)
* glcf_landsat7_2002_for_NC_SPM_WAKE_import.sh (import into GRASS)

You can then use r.info to retrieve the metadata and use them for 
processing.


Hope this helps,
Markus







__ Information from ESET NOD32 Antivirus, version of virus signature 
database 4847 (20100208) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com


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

Re: [GRASS-dev] GRASS_ADDON_PATH in GRASS6.4 UbuntuOS

[Kim Besson]

Greetings all

ok but... I still can't run a script, through a wxpyhon frame, that is the
ADDON_PATH. And in this case, $GRASS_ADDDON_PATH is recognized inside GRASS
environment.
My question is: is it possible to run a script, located in GRASS_ADDON_PATH,
by using a wxpython frame? Because It seems that I'm not the only one...
Or is there a way do debug this in order to sent to the mailing list?

Thank you

Kim

The "auto-GUI" feature (i.e. --ui implied when run without arguments)

> only works when the program's stdin is a terminal, which isn't the
> case for the GUI's command prompt.
>
> Making it behave like a terminal (i.e. making isatty(0) return true in
> the child process) is non-trivial[1] on Unix and practically
> impossible on Windows.
>
> [1] It's possible via os.openpty(), where available; the documentation
> says:
>
>Availability: some flavors of Unix
>
> 
>
> -
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] lidar tools update in grass7

[Soeren Gebbert]

Hello,

2010/2/8 Hamish :
> Markus Metz wrote:
>> The core of the lidar tools is the lidarlib, that is AFAICT
>> robust and working. Bugs are most likely in modules, so I'll try
>> to add comments there. I have reorganized the code for v.surf.bspline
>> in the hope that it is now easier to read.
>
> Slightly off-topic, but while we are thinking about this code ...
>
> A while back I did some crude profiling of the v.lidar tools and found
> that it was spending lots and lots of time in the Tcholetsky decomposition
> loop (3-for loops deep).
>
> It seemed like a good & simple test case for using OpenMP to multi-thread
> it, but I got stuck with it segfaulting. AFAIR the problem was that OpenMP
> wanted you to malloc the entire thing before starting, and this could
> get big.

There is an OpenMP version of a bandwidth optimized cholesky
decomposition algorithm in gmathlib.
I will have a look on the lidarlib to evaluate if we can use the
existing OpenMP tuned
cholesky. Besides of that, i will move the lidar linear equation
solver and the inversion algorithm into
the gmath library, so more modules may benefit from it.

I have made some performance tests with the OpenMP tuned linear
equation solver (cholesky, gauss, lu) in gmathlib,
there is unfortunately not much speedup, which is related to the
design of the solver algorithms.
The solver benchmarks are available in the grass7 lib/gmath/tests directory.
I have had only measurable speedup with the intel compiler (which is
free for open source projects),
the speedup with the gcc OpenMP implementation is little.

Additionally it would be interesting to consider the use of the OpenMP
tuned conjugate gradient solver from gmath within the lidar tools.
This solver has an excellent linear speedup (related to the
parallelzied matrix-vector multiplication), is quite fast (non-linear
convergence)
and works with sparse matrices.

Best regards
Soeren

>
> if it interests you, see the attached patch and
>  https://trac.osgeo.org/grass/ticket/657
>  http://lists.osgeo.org/pipermail/grass-dev/2009-June/044709.html
>  http://lists.osgeo.org/pipermail/grass-dev/2009-June/044705.html
>  http://grass.osgeo.org/wiki/OpenMP
>
>
>> I forgot to mention, there is a problem with sqlite, it is much slower
>> than dbf, no idea if this is a problem of my system or of the grass
>> sqlite driver or of the way auxiliary tables are accessed by the lidar
>> tools.
>
> that sounds vaguely familiar, but as a general thing not necessarily
> to do with v.lidar. probably something about it in the archives?
>
>
> Hamish
>
>
>
>
> ___
> 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

[GRASS-dev] Re: [GRASS GIS] #587: svn versions should better reflect svn rev

[GRASS GIS]

#587: svn versions should better reflect svn rev
--+-
  Reporter:  hamish   |   Owner:  martinl  
  Type:  enhancement  |  Status:  reopened 
  Priority:  major|   Milestone:  6.5.0
 Component:  default  | Version:  svn-trunk
Resolution:   |Keywords:  g.version
  Platform:  All  | Cpu:  All  
--+-
Comment (by hamish):

 Glynn:
 > IMHO, the "a:" should be stripped; we're only interested in the
 > last revision, not the first.

 done in trunk, r40862.


 Hamish

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

Re: [GRASS-dev] lidar tools update in grass7

[Markus Metz]

more updates in r40860, mostly documentation

Hamish wrote:

Markus Metz wrote:
  

The core of the lidar tools is the lidarlib, that is AFAICT
robust and working. Bugs are most likely in modules, so I'll try
to add comments there. I have reorganized the code for v.surf.bspline
in the hope that it is now easier to read.



Slightly off-topic, but while we are thinking about this code ...

A while back I did some crude profiling of the v.lidar tools and found
that it was spending lots and lots of time in the Tcholetsky decomposition
loop (3-for loops deep).
  

That's better now because the matrix is a bit smaller.

It seemed like a good & simple test case for using OpenMP to multi-thread
it, but I got stuck with it segfaulting. AFAIR the problem was that OpenMP
wanted you to malloc the entire thing before starting, and this could
get big.

if it interests you, see the attached patch and
  https://trac.osgeo.org/grass/ticket/657
  http://lists.osgeo.org/pipermail/grass-dev/2009-June/044709.html
  http://lists.osgeo.org/pipermail/grass-dev/2009-June/044705.html
  http://grass.osgeo.org/wiki/OpenMP
  
Hmm, if I understand the code right, only the innermost for loop can be 
executed in parallel because the first two for-loops need results of 
previous runs (not possible to run i + 1 before i, same for j). But I 
don't know that parallel stuff, I would in any case first optimize the 
code without parallelization, only then add multithreading.


  

I forgot to mention, there is a problem with sqlite, it is much slower
than dbf, no idea if this is a problem of my system or of the grass 
sqlite driver or of the way auxiliary tables are accessed by the lidar

tools.



that sounds vaguely familiar, but as a general thing not necessarily
to do with v.lidar. probably something about it in the archives?
  
I discovered two little tricks: first, create the table, close database 
and driver, open database and driver again, work with table, second, 
creating an index on the table if possible helps too. Tested with sqlite 
and dbf.


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

[GRASS-dev] Re: [GRASS GIS] #902: nviz (tcl) fails on wingrass

[GRASS GIS]

#902: nviz (tcl) fails on wingrass
---+
  Reporter:  hamish|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  critical  |   Milestone:  6.4.0
 Component:  NVIZ  | Version:  svn-trunk
Resolution:|Keywords:   
  Platform:  All   | Cpu:  All  
---+
Comment (by hamish):

 > the authors text is written to the output tab ($Id$ seems broken)

 {{{
 Version: @(#) 7.0.svn (2010)
 }}}

 from nviz_init.c
 {{{
 G_verbose_message("Version: %s", GRASS_VERSION_STRING);
 }}}

 include/version.h:
 {{{
 #define GRASS_VERSION_STRING   "@(#) 7.0.svn (2010)"
 }}}

 include/version.h.in:
 {{{
 #define GRASS_VERSION_STRING   "@(#) @GRASS_VERSION_NUMBER@
 (@GRASS_VERSION_DATE@)"
 }}}


 same thing, all versions.  what's with the leading @(#)?


 Hamish

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

[GRASS-dev] Re: [GRASS GIS] #902: nviz (tcl) fails on wingrass

[GRASS GIS]

#902: nviz (tcl) fails on wingrass
---+
  Reporter:  hamish|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  critical  |   Milestone:  6.4.0
 Component:  NVIZ  | Version:  svn-trunk
Resolution:|Keywords:   
  Platform:  All   | Cpu:  All  
---+
Comment (by hamish):

 Ok, now it seems to work ok from the 6.5 command line and GUIs. So
 backported to 6.4.

 but still a weird problem in trunk:

  * G7> nviz --ui
  * (module option gui opens)
  * select raster elevation: elevation@permanent
  * [Run]
  * a window flashes open then closes again and this is written to the
 module GUI output tab:
 {{{
 (Mon Feb  8 21:00:20 2010)
 /usr/local/src/grass/svn/trunk/dist.x86_64-unknown-linux-
 gnu/etc/nviz2.2/nviz elevation=elevation@permanent
 Error in startup script: couldn't read file
 "elevation=elevation@permanent": no such file or
 directory
 (Mon Feb  8 21:00:20 2010) Command finished (0 sec)
 }}}


 If I try again, but with the --verbose flag turned on, the Please wait..
 and NVIZ wish windows open (and stay open); the authors text is written to
 the output tab ($Id$ seems broken); then it locks up after:
 {{{
 The papers are available at
 http://www2.gis.uiuc.edu:2280/modviz/
 Loading raster map ...
 Loading raster map ...
 Translating colors from raster map ...
 }}}

 Pressing the [Abort command] button writes the inconsistent stage warning
 (which isn't really needed here [s/stage/state/?]) and stops it.


 Hamish

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