Re: [GRASS-dev] [GRASS GIS] #2177: g.gui.animation fail to create gif

[GRASS GIS]

#2177: g.gui.animation fail to create gif
-+--
 Reporter:  lucadelu |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-trunk
 Keywords:  g.gui.animation  |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by lucadelu):

 Replying to [comment:8 annakrat]:

 >
 > Luca, are you sure you don't have Pillow on your computer? I have the
 same problem only when I install Pillow. When I uninstall it, it's working
 again. So it looks like it is a Pillow problem.

 Sorry Anna, I discovered that python-PIL install python-pillow. So I'm
 using Pillow, Debian Jessy not provide PIL, we should try to fix this
 problem or report this bug in Pillow.

-- 
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] #2143: d.legend: add option to output legend definition as text

[GRASS GIS]

#2143: d.legend: add option to output legend definition as text
---+
 Reporter:  wenzeslaus |   Owner:  grass-dev@…  
 Type:  enhancement|  Status:  new  
 Priority:  trivial|   Milestone:  7.0.0
Component:  Display| Version:  svn-trunk
 Keywords:  d.legend, text output  |Platform:  All  
  Cpu:  All|  
---+

Comment(by neteler):

 Replying to [comment:2 hamish]:
 > ps- since cpt-city (http://soliton.vm.bytemark.co.uk/pub/cpt-city/) was
 > mentioned, it is worth noting that without clear license we can't
 > distribute anything from the site directly.

 Perhaps take from QGIS then which is GPL 2:

 https://github.com/qgis/QGIS/tree/master/resources/cpt-city-qgis-min

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] GSoc Project on GRASS

[Markus Neteler]

On Thu, Feb 6, 2014 at 11:35 PM, Naveen Panwar  wrote:
> Hello all,
>
> I am a M.S. by research student from Lab for Spatial Informatics,
> International Institute of Information and Technology, Hyderabad, India.
>
> Last year I had proposed idea on "GRASS magic extension for the IPython
> Notebook" in GSOC-2013.
> But unfortunately the idea didn't get selected. Would it be a good idea to
> propose the same project this year also?
>
> OR if there is another idea based on python and better suited for me, I am
> willing to contribute.

Please add your ideas to

http://trac.osgeo.org/grass/wiki/GSoC/2014

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

Re: [GRASS-dev] problem bundling GRASS 6.5 and 6.4 RB

[Michael Barton]

Thanks. I'll try it again on Monday.

Michael Barton
School of Human Evolution &Social Change
Center for Social Dynamics & Complexity
Arizona State University

...Sent from my iPad

> On Feb 7, 2014, at 5:39 PM, "William Kyngesburye"  
> wrote:
> 
> Woops. I deleted too much when I killed the modbuild stuff a few weeks ago.  
> Should be working now.
> 
>> On Feb 7, 2014, at 6:19 PM, Michael Barton wrote:
>> 
>> William,
>> 
>> I just recompiled GRASS 7 and bundled it for distribution. It went fine. 
>> 
>> But when I went to do the same for GRASS 6.5 and 6.4 RB I ran into an odd 
>> error. 
>> 
>> Compilation went fine. No errors in either. But bundling bombed with the 
>> following error:
>> 
>> …
>> cp -Rf /Library/Python/2.7/site-packages/pyparsing.py 
>> /Users/cmbarton/Dropbox/GRASS_dropbox/source/grass64_rb/macosx/dist/GRASS-6.4.app/Contents/MacOS/etc/python
>> sed -i '' -e 's/^GRASS_WXBUNDLED=.*/GRASS_WXBUNDLED=1/' 
>> /Users/cmbarton/Dropbox/GRASS_dropbox/source/grass64_rb/macosx/dist/GRASS-6.4.app/Contents/MacOS/grass.sh
>> sed: 
>> /Users/cmbarton/Dropbox/GRASS_dropbox/source/grass64_rb/macosx/dist/GRASS-6.4.app/Contents/MacOS/grass.sh:
>>  No such file or directory
>> 
>> Is there no longer a grass.sh for GRASS 6.x? If not, what do we use to start 
>> it?
>> 
>> The same line does not cause an error for GRASS 7.
>> 
>> Michael
>> __
>> C. Michael Barton 
>> Director, Center for Social Dynamics & Complexity
>> Professor of Anthropology, School of Human Evolution & Social Change
>> Head, Graduate Faculty in Complex Adaptive Systems Science
>> Arizona State University
>> Tempe, AZ  85287-2402
>> USA
>> 
>> voice: 
>> 480-965-6262 (SHESC), 480-965-8130/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] Handling of Python scripts on MS Windows

[Glynn Clements]

Markus Neteler wrote:

> > The difference is that you don't "start" GRASS. You set the required
> > environment variables from e.g. ~/.profile so that GRASS commands work
> > in any shell (or via any other execution mechanism, e.g. M-! from
> > within Emacs).
> 
> This is hardly feasible for the majority of the users. Perhaps I don't
> understand the suggestion, at least for Windows OS users (nad most
> Linux/Mac newcomers).

It's not something users should need to concern themselves with.

Many packages require certain environment settings (which is why most
modern Linux systems have e.g. /etc/profile.d or /etc/env.d, with each
file belonging to a different package).

Most packages made up of command-line utilities don't require you to
"start" the package before you can use the commands which comprise it.

It would be quite straightforward for a GRASS package to install an
environment file which sets GISBASE and GISRC so that GRASS commands
just work anywhere.

Things get marginally more complex if you either need multiple
versions installed concurrently, or multiple concurrent sessions.

The former is seldom supported, particularly for packages consisting
of many distinct utilities (having python2 and python3 executables is
one thing, versioning dozens or hundreds of distinct commands is
another).

The latter is fairly trivial to implement on Unix (just use $$ in the
setting of GISRC), and could be implemented on Windows (which doesn't
have the equivalent of ~/.profile etc) with fairly minor changes to
lib/gis/env.c.

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

Re: [GRASS-dev] m.nviz.image - Bad server connection

[epi]

Markus, Hamish,

thank you so much!
starting my SSH session with:

ssh  -Y -C -C -l username my.server.host 

works perfect when i start grass from the SSH shell.
but my “real-use case" is a bit different

I’m used to run grass from inside an IPython notebook
to have grass loaded in the notebook session, i make a simple bash script :  ‘ 
ipython_GRASS.sh ‘
that looks like :


PREFIX=/home/$USER/Envs/env1

export 
LD_LIBRARY_PATH=$PREFIX/lib:$PREFIX/grass-7.0.svn/lib:$PREFIX/lib/R/lib/:$LD_LIBRARY_PATH
export PYTHONPATH=$PREFIX/grass-7.0.svn/etc/python:$PYTHONPATH
export GISBASE=$PREFIX/grass-7.0.svn/
export PATH=$PREFIX/bin/:$GISBASE/bin:$GISBASE/scripts:$PATH


export GIS_LOCK=$$

mkdir -p /home/$USER/Envs/grass7data
mkdir -p /home/$USER/Envs/.grass7

export GISRC=/home/$USER/Envs/.grass7/rc

export GISDBASE=/home/$USER/Envs/grass7data

export GRASS_TRANSPARENT=TRUE
export GRASS_TRUECOLOR=TRUE
export GRASS_PNG_COMPRESSION=9
export GRASS_PNG_AUTO_WRITE=TRUE


ipython notebook —ip=xxx.xxx.xxx



in this way i can start the notebook server from the SSH shell with :

nohup sh ipython_GRASS.sh &

and all works fine.

of course if i quit the SSH shell i will loose all the “ X support ” from my 
local machine.

Do you have any hints on how to export the X support inside the 
ipython_GRASS.sh  in order to tell grass to use the server X ?


I’m asking because i’m using the script in a crontab file that is loaded at 
each reboot :

@reboot nohup sh ipython_GRASS.sh &

so to have the notebook server always up and running without the needs to login 
into ssh all the time
It works .. but except for the bad server connection.

Thanks for any hints!

Massimo.



On Feb 7, 2014, at 10:11 PM, Hamish  wrote:

> epi wrote:
> 
>>> i'm tring to generate a 3d image with m.nviz.image,
>>> the following command works fine form a 'standard'
>>> GRASS session in text mode on my laptop but if try
>>> to run the same command on a sever while i'm connected
>>> via SSH i got the error : Bad server connection
> 
> MarkusN:
>> Many grass power users work like this, so that's well
>> tested in general.
> 
> I was doing it with m.nviz.image last weekend actually.
> 
> Note wrt running remotely on a server, m.nviz.image is special.
> 
> 
>>> Have you any clue on how to fix this ?
>>> is there any environment var that needs to be exported
>>> in order to have m.nviz.image running during an SSH session ?
>>> 
>>> GRASS 7.0.svn (nc_spm_08_grass7):~ > m.nviz.image \
>>> elevation_map=elevation \
>>> output=elevation_3d \
>>> perspective=15 \
>>> height=2000 \
>>> color_map=elevation \
>>> resolution_fine=1 \
>>> resolution_coarse=1 \
>>> format=tif
>>> 
>>> 
>>> ERROR: Bad server connection
>> 
>> 
>> Did you redirect the Display stream?
>> 
>> ssh -Y yourserver
>> 
>> Perhaps that solving the issue.
> 
> Depending on if it's a local gigabit network or if you are calling in from 
> home, I'd strongly suggest to use 'ssh -C' as well, since m.nviz.image will 
> want to do about half of its processing on the *local* X server, not the 
> remote computer, and that's a lot of network traffic!
> 
> Last weekend's task was running m.nviz.image many times in a loop for an 
> animation, and trying to do it remotely from my netbook via a GNU Screen 
> session. But the network connection out at the farm wasn't that good and the 
> several years old netbook's graphics hardware is pretty poor compared to the 
> graphics card in the remote workstation. It took ~10 times as long running it 
> remotely, but it did get there.
> 
> m.nviz.image didn't work (entirely from the command line) when the DISPLAY 
> enviro var wasn't set correctly in GNU Screen though, I had to reestablish 
> the session to fix that first.
> 
> 
> good luck,
> Hamish
> 

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

Re: [GRASS-dev] Handling of Python scripts on MS Windows

[Benjamin Ducke]

On 08/02/14 20:41, Glynn Clements wrote:
> 
> Markus Neteler wrote:
> 
>>> The difference is that you don't "start" GRASS. You set the required
>>> environment variables from e.g. ~/.profile so that GRASS commands work
>>> in any shell (or via any other execution mechanism, e.g. M-! from
>>> within Emacs).
>>
>> This is hardly feasible for the majority of the users. Perhaps I don't
>> understand the suggestion, at least for Windows OS users (nad most
>> Linux/Mac newcomers).
> 
> It's not something users should need to concern themselves with.
> 
> Many packages require certain environment settings (which is why most
> modern Linux systems have e.g. /etc/profile.d or /etc/env.d, with each
> file belonging to a different package).
> 
> Most packages made up of command-line utilities don't require you to
> "start" the package before you can use the commands which comprise it.
> 
> It would be quite straightforward for a GRASS package to install an
> environment file which sets GISBASE and GISRC so that GRASS commands
> just work anywhere.
> 

I have been trying to wrap my head around this.
Please tell me if I still misunderstand something,
but this is what I think you are suggesting:

Instead of having to log into a GRASS session
explicitely, the GRASS environment gets configured
with the login (shell) and then the user can just run
e.g. "g.list" and it will just work.

How would users choose mapsets or create new ones in this
scenario? Wouldn't that require new user level software?

> Things get marginally more complex if you either need multiple
> versions installed concurrently, or multiple concurrent sessions.
> 
> The former is seldom supported, particularly for packages consisting
> of many distinct utilities (having python2 and python3 executables is
> one thing, versioning dozens or hundreds of distinct commands is
> another).
> 

Well, at this point I have several versions of GRASS 6.4 and
a version of GRASS 7 installed. I need them all, because they
run as testing versions or to provide processing functionality
for another "host" GIS.

How would I switch between them?

The same situation arises with different Java versions on the
same system. It is a very frequent situation and IMHO there
is no really good, convenient solution for this. Every Linux
distribution seems to use its own frontend for switching and
let's not even get started about Windows.

The alternatives here are to either manipulate PATH etc.
directly or to provide some more user-friendly software that
take care of this. I find neither ideal.

> The latter is fairly trivial to implement on Unix (just use $$ in the
> setting of GISRC), and could be implemented on Windows (which doesn't
> have the equivalent of ~/.profile etc) with fairly minor changes to
> lib/gis/env.c.
> 

But that would again require some user-friendly software, unless
people are supposed to start editing configuration files, right?

I understand the benefits of tighter system integration that (I think)
you are aiming for. It would make everything more seamless.
But there are also downsides to this: We would need to think about
different mechanisms for each supported OS; we could get tangled up in
all sorts of flawed decisions by the OS designers; we would depend on
3rd party dependencies to work with GRASS. Surely, all of these issues
could be worked around, but are the potential benefits worth it?

Whatever the decision may be: Please make sure that it will always be
possible to bundle a completely independent distribution of GRASS
with 3rd party GIS. Otherwise, this project will no longer be able to
benefit from the growing user base that projects such as QGIS have
recently attracted.

Best,

Ben

-- 
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

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

Re: [GRASS-dev] [GRASS GIS] #1214: r.li.edgedensity: segmentation fault

[GRASS GIS]

#1214: r.li.edgedensity: segmentation fault
--+-
 Reporter:  neteler   |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  6.4.4
Component:  Raster| Version:  svn-releasebranch64  
 Keywords:  r.li.edgedensity  |Platform:  Linux
  Cpu:  x86-64|  
--+-
Changes (by neteler):

  * keywords:  => r.li.edgedensity
  * milestone:  6.4.1 => 6.4.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] Handling of Python scripts on MS Windows

[Helmut Kudrnovsky]

hi,

> But there are also downsides to this: We would need to think about
> different mechanisms for each supported OS; we could get tangled up in
> all sorts of flawed decisions by the OS designers;

I think we are already there regarding MS windos OS and python ...

>Whatever the decision may be: Please make sure that it will always be
>possible to bundle a completely independent distribution of GRASS
>with 3rd party GIS. Otherwise, this project will no longer be able to
>benefit from the growing user base that projects such as QGIS have
>recently attracted. 

I second this.



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Handling-of-Python-scripts-on-MS-Windows-tp5081335p5102711.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2024: r.li.setup generates incomplete r.li conf file

[GRASS GIS]

#2024: r.li.setup generates incomplete r.li conf file
+---
 Reporter:  matmar  |   Owner:  rashadkm   
 Type:  defect  |  Status:  assigned   
 Priority:  normal  |   Milestone:  6.4.4  
Component:  Raster  | Version:  svn-releasebranch64
 Keywords:  r.li.setup  |Platform:  Linux  
  Cpu:  x86-64  |  
+---

Comment(by hamish):

 Hi,

 I'd like to settle on a common naming scheme for the sample unit raster
 mask maps which r.li.setup produces.

 any comments on:
   rli_sample._[_]


 I had used the sampled raster name, but maybe the config file is less
 likely to have a name-space conflict. (as config files seem locked to a
 single sampled raster).  The G7 wx version already uses the config file in
 the name.

 ?



 Markus:
 > Yes, that would be very important. Imagine to manually cycle
 > through a vector layer with 1000 polygons, then you have to
 > insert 1000 filenames manually which could simply be the category
 > plus unique number.

 It would be pretty easy to add an "auto" button to the "is this area ok?
 [y/n]" dialog to accept the rest as ok, if that is a reasonable thing that
 makes sense for the analysis methodology.

 So far I just added a warning if there were more than 30 areas to
 consider. Once the d.menu garbage from X-buffer bug is fixed I'd put an
 on-screen "this looks like it will take a very long time, are you sure?"
 chance to abort.

 I notice with NC08's zipcodes_wake and landuse96_28m that many areas are
 outside of the raster-to-analyze's bounding box. Is it ok to add a
 'v.select op=overlap' step to only consider vector areas with data in
 them? How to deal with areas which are half in out-of-bbox null-space?
 Crop them (v.overlay instead of v.select) or leave them to be handled in
 the same way that a null hole in the middle of the raster would be?


 Hamish

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Is `typedef struct` considered as a bad practice?

[Vaclav Petras]

Hi C devs,

is following considered wrong in GRASS code?

typedef struct Point {
   int x;
   int y;
} Point;

/* alternatively */
typedef struct {
   int x;
   int y;
} Point;


I just saw r58957 and r49886 but till now I thought that typedefs (at the
same time as struct definition) are allowed or even preferred since they
are shorter. From C++ point of view `struct Point` is obsolete syntax which
does not help anybody, both compiler and programmer knows what is Point.

There is nothing about this is SUBMITTING or referred GNU Coding Standards
(at least I don't see anything).

Vaclav


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

Re: [GRASS-dev] [GRASS GIS] #2024: r.li.setup generates incomplete r.li conf file

[GRASS GIS]

#2024: r.li.setup generates incomplete r.li conf file
+---
 Reporter:  matmar  |   Owner:  rashadkm   
 Type:  defect  |  Status:  assigned   
 Priority:  normal  |   Milestone:  6.4.4  
Component:  Raster  | Version:  svn-releasebranch64
 Keywords:  r.li.setup  |Platform:  Linux  
  Cpu:  x86-64  |  
+---

Comment(by hamish):

 Replying to [comment:12 neteler]:
 > The fixes attached to this ticket are not yet forward-ported to G7.

 done in r58961 (with some slight modifications), note included in the
 patch is a bugifx by Rashad in daemon.c: m.f.f_ma.x and m.f.f_ma.y were
 reversed in older versions of the code.

 it compiles ok, but I haven't checked the results.

 Currently I'm sync'ing changes from devbr6 into trunk; if there are no
 objections I will remove the r.li.setup Tcl/shell script/Xmonitor stuff
 completely in trunk.


 Since the WORKERS and server/client framework has been dropped in trunk,
 it will be interesting to test if the segfaults go away there too. If they
 do, the best approach for power users who can't wait would be to run
 r.li.setup in G6, then symlink the ~./r.li/ user dir into the right place
 for G7 and run the r.li.* modules from G7.


 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 GIS] #1214: r.li.edgedensity: segmentation fault

[GRASS GIS]

#1214: r.li.edgedensity: segmentation fault
--+-
 Reporter:  neteler   |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  6.4.4
Component:  Raster| Version:  svn-releasebranch64  
 Keywords:  r.li.edgedensity  |Platform:  Linux
  Cpu:  x86-64|  
--+-

Comment(by hamish):

 Hi,

 you might test in grass7 where the server/client stuff has been removed so
 r.li.daemon is simpler. If that works and 6.x doesn't, it narrows down
 where to look.

 Also, to help with reproducibility it would be good if we could all test
 with the same data and commands- see the r.li module help page examples or
 the r.li/TODO which has a number of usage examples using the standard
 sample datasets.


 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 GIS] #721: r.li.setup: don't modify the WIND file

[GRASS GIS]

#721: r.li.setup: don't modify the WIND file
+---
 Reporter:  hamish  |   Owner:  grass-dev@… 
 
 Type:  defect  |  Status:  new 
 
 Priority:  normal  |   Milestone:  6.4.4   
 
Component:  Raster  | Version:  6.4.0 RCs   
 
 Keywords:  r.li, g.region, r.li.setup  |Platform:  All 
 
  Cpu:  All |  
+---
Changes (by hamish):

  * milestone:  6.4.3 => 6.4.4


Comment:

 Hi, this is now complete in devbr6.

 trunk is continued in #421. backport to relbr64 is todo.

 One remaining thing to check for G6 r.li.setup is if there are places in
 the tcl code which need "quoting" around filename variables which may
 contain spaces. (e.g. path to temp files)
 If regular tcl variables are ok(?) there are still some `exec` statements
 which could need checking.

 (Another thing to check is that temp files in the r.li.setup tcl code
 always get written into a temp dir instead of the `pwd`)


 Hamish

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #2194: type out formulas in TeX format

[GRASS GIS]

#2194: type out formulas in TeX format
---+
 Reporter:  hamish |   Owner:  grass-dev@…  
 Type:  task   |  Status:  new  
 Priority:  trivial|   Milestone:  7.0.0
Component:  Docs   | Version:  svn-trunk
 Keywords:  TeX, formulae  |Platform:  All  
  Cpu:  All|  
---+
 Hi, a rainy day project for someone:

 many modules' help pages include images used in them, and just about all
 of those use a different font, style, etc.

 it would be nice wherever these appeared there was also a .tex file in the
 module dir which the build process could use to auto-generate the embedded
 png image, so that all math rendering was consistent in the docs.


 thanks,
 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 GIS] #2194: type out formulas in TeX format

[GRASS GIS]

#2194: type out formulas in TeX format
---+
 Reporter:  hamish |   Owner:  grass-dev@…  
 Type:  task   |  Status:  new  
 Priority:  trivial|   Milestone:  7.0.0
Component:  Docs   | Version:  svn-trunk
 Keywords:  TeX, formulae  |Platform:  All  
  Cpu:  All|  
---+
Description changed by hamish:

Old description:

> Hi, a rainy day project for someone:
>
> many modules' help pages include images used in them, and just about all
> of those use a different font, style, etc.
>
> it would be nice wherever these appeared there was also a .tex file in
> the module dir which the build process could use to auto-generate the
> embedded png image, so that all math rendering was consistent in the
> docs.
>

> thanks,
> Hamish

New description:

 Hi, a rainy day project for someone:

 many modules' help pages include images showing the formulas used in them,
 and just about all of those use a different font, style, etc.

 it would be nice wherever these appeared there was also a .tex file in the
 module dir which the build process could use to auto-generate the embedded
 png image, so that all math rendering was consistent in the docs.


 thanks,
 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 GIS] #1797: r.li.padcv broken

[GRASS GIS]

#1797: r.li.padcv broken
---+
 Reporter:  cmbarton   |   Owner:  grass-dev@…  

 Type:  defect |  Status:  new  

 Priority:  major  |   Milestone:  6.4.4

Component:  Raster | Version:  6.4.3 RCs

 Keywords:  r.li, r.li.padcv, broken pipe  |Platform:  MacOSX   

  Cpu:  Unspecified|  
---+
Changes (by hamish):

  * keywords:  r.li, r.li.padcv => r.li, r.li.padcv, broken pipe


-- 
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] #722: r.li.daemon: respect for WORKERS enviro var

[GRASS GIS]

#722: r.li.daemon: respect for WORKERS enviro var
-+--
 Reporter:  hamish   |   Owner:  grass-dev@…  
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  6.4.4
Component:  Raster   | Version:  svn-develbranch6 
 Keywords:  r.li, smp|Platform:  All  
  Cpu:  All  |  
-+--
Changes (by hamish):

  * version:  svn-trunk => svn-develbranch6
  * milestone:  7.0.0 => 6.4.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 GIS] #1451: r.li.mps (mean patch size): SIGPIPE at ipc.c:31

[GRASS GIS]

#1451: r.li.mps (mean patch size): SIGPIPE at ipc.c:31
---+
 Reporter:  hamish |   Owner:  grass-dev@…  
 Type:  defect |  Status:  new  
 Priority:  normal |   Milestone:  6.4.4
Component:  Raster | Version:  svn-develbranch6 
 Keywords:  r.li.mps, r.li.daemon  |Platform:  Linux
  Cpu:  x86-64 |  
---+
Changes (by hamish):

  * keywords:  r.li.mps => r.li.mps, r.li.daemon
  * milestone:  6.4.2 => 6.4.4


Comment:

 see also comment 27 in #2024, same crash in the same place but set off by
 r.li.edgedensity. Includes backtrace and valgrind analysis.

-- 
Ticket URL: 
GRASS GIS 

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