[by the way, I'd love to hear feedback from Mac users about how well
g.extension(.sh) and the wxGUI extension manager performs in the latest
6.x.svn]
Michael wrote:
> The way that William had it set is
> that the default locations for addons were defined as
> /Library/GRASS/6.4 or /Library/GRASS/6
Hamish wrote:
> > it doesn't work to put GRASS_ADDON_PATH into .grass.bashrc,
> > you need to export it from your ~/.bashrc or ~/.profile.
> > (and it is too invasive to start appending to those automatically)
Martin:
> hm, and what's the purpose or `.grass.bashrc` I thought it should be a
> place
OK. That all sounds fine. Thanks.
Michael
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965
2011/12/15 Martin Landa :
>> All this is fine. However, GRASS_ADDON_BASE should not be a hidden file on a
>> Mac. It is problem enough that preferences are there if you ever have to
>> mess with them outside of the GRASS GUI.
>
> There is no GRASS_ADDON_BASE. Anyway it should be controlled only b
2011/12/15 Michael Barton :
>> it doesn't work to put GRASS_ADDON_PATH into .grass.bashrc,
>> you need to export it from your ~/.bashrc or ~/.profile.
>> (and it is too invasive to start appending to those automatically)
>
> It is not good to mess with these on the Mac unless you know what you are
2011/12/15 Hamish :
> Martin wrote:
>> * if not ask user whether he/she wants to add this
>> directory to GRASS_ADDON_PATH (.grass.bashrc for G6 or
>> .grass7/bashrc for G7)
>
> it doesn't work to put GRASS_ADDON_PATH into .grass.bashrc,
> you need to export it from your ~/.bashrc or ~/.profile.
>
On Dec 14, 2011, at 5:48 PM, Hamish wrote:
> Martin wrote:
>> * if not ask user whether he/she wants to add this
>> directory to GRASS_ADDON_PATH (.grass.bashrc for G6 or
>> .grass7/bashrc for G7)
>
> it doesn't work to put GRASS_ADDON_PATH into .grass.bashrc,
> you need to export it from your
The way that William had it set is that the default locations for addons were
defined as /Library/GRASS/6.4 or /Library/GRASS/6.5 etc. The system and/or user
/Library folder is the normal place for preferences, plugins, and other such
files on a Mac. While the Mac is Unix at heart, people don't
Martin wrote:
> * if not ask user whether he/she wants to add this
> directory to GRASS_ADDON_PATH (.grass.bashrc for G6 or
> .grass7/bashrc for G7)
it doesn't work to put GRASS_ADDON_PATH into .grass.bashrc,
you need to export it from your ~/.bashrc or ~/.profile.
(and it is too invasive to start
2011/12/15 Michael Barton :
> OK. Then perhaps I misunderstood the discussion here.
I was speaking about situation when you have more GRASS versions
installed (let's say 6.4.2 and 6.5) and you are installing extension
using `g.extension`. Currently it's installed to the same directory
(if not defi
OK. Then perhaps I misunderstood the discussion here.
Michael
__
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ 85287-2402
USA
voice: 480-965
2011/12/14 Martin Landa :
>> My rationale is that I and others use the addons directory as a place to
>> store our own bash/python scripts. These are not installed by g.extension.
>> It is a royal pain putting them into a hidden directory and managing them
>> there. Many Mac users do not know ho
Hi,
2011/12/14 Michael Barton :
> My rationale is that I and others use the addons directory as a place to
> store our own bash/python scripts. These are not installed by g.extension. It
> is a royal pain putting them into a hidden directory and managing them there.
> Many Mac users do not know
My rationale is that I and others use the addons directory as a place to store
our own bash/python scripts. These are not installed by g.extension. It is a
royal pain putting them into a hidden directory and managing them there. Many
Mac users do not know how to access such hidden directories. E
Hi,
2011/12/14 Michael Barton :
> All directories that begin with a "." are by default hidden from Mac users.
> Since permissions and settings can be accessed in other ways, this is not a
> big problem.
it's same for GNU/Linux, bear in mind that Mac OS has the roots in Unix :-)
> But if we ar
There is another issue for Mac users--and this affects the overall
permissions/settings files too.
All directories that begin with a "." are by default hidden from Mac users.
Since permissions and settings can be accessed in other ways, this is not a big
problem.
But if we are putting addons
#1507: r.in.gdal & others: -e must only modify the current mapset's WIND file
-+--
Reporter: hamish | Owner: grass-dev@…
Type: defect | Stat
Hi All,
How to run grass module from C++ code.I am coding a small application
using C++ I want to call grass commands from the application (g.gisenv)
this can be done in different ways
1. python using gcmd.RunCommand(..)
2. setup grass environment and execute from c++ code using system command
s
#1507: r.in.gdal & others: -e must only modify the current mapset's WIND file
-+--
Reporter: hamish | Owner: grass-dev@…
Type: defect | Stat
#1507: r.in.gdal & others: -e must only modify the current mapset's WIND file
-+--
Reporter: hamish | Owner: grass-dev@…
Type: defect | Stat
Hi,
2011/12/14 Hamish :
>> $HOME/.grass/addons
>>
>> and on Windows to
>>
>> $AppData\GRASS\addons
>
> (i.e. if you didn't already have GRASS_ADDON_PATH set to something
> custom and you let the defaults make the choice for you)
right, I am speaking about the normal situation, bearing in mind tha
#1507: r.in.gdal & others: -e must only modify the current mapset's WIND file
-+--
Reporter: hamish | Owner: grass-dev@…
Type: defect | Stat
#1507: r.in.gdal & others: -e must only modify the current mapset's WIND file
-+--
Reporter: hamish | Owner: grass-dev@…
Type: defect | Stat
#1507: r.in.gdal & others: -e must only modify the current mapset's WIND file
-+--
Reporter: hamish | Owner: grass-dev@…
Type: defect | Stat
Hamish wrote:
> I'm a bit confused about how lib/gis/element_list deals with raster3d
> stuff.
>
> the source code path is ./raster3d/r3.*/main.c ...
>
> the human-readable alias in the help pages is "raster3D"
>
> MAPSETs in the past used g3dcell/ but now seem to use grid3/
> but there are s
I created a wish item in the tracker where I described how such module
could work.
What to do if attributes differ is a good question.
Maris.
2011/12/14 Hamish :
> Markus Metz wrote:
>> But back to the original problem: how about a new option to
>> v.category to reduce the number of categories f
#1509: A vector module to convert duplicate attribute features to multifeature
-+--
Reporter: marisn | Owner: grass-dev@…
Type: enhancement | Status: new
Priority
Martin wrote:
> currently the GRASS AddOns extensions are installed on
> GNU/Linux to
>
> $HOME/.grass/addons
>
> and on Windows to
>
> $AppData\GRASS\addons
(i.e. if you didn't already have GRASS_ADDON_PATH set to something
custom and you let the defaults make the choice for you)
> This layo
#1150: Cannot open vector for editing in digitize toolbar in GRASS 7.0
--+-
Reporter: PvB | Owner: martinl
Type: defect| Status: new
Priority: normal| Milestone: 6.5.0
C
Johannes Radinger wrote:
> I tried no to put 'set PYTHONPATH=%GISBASE%\etc\python;%PYTHONPATH%'
> into the env.bat file of my selfcompiled GRASS6.5SVN on Windows.
> Anyway it took me a while to get the 'real' correct line I think (as
> mentioned in the wiki)
>
> In the env.bat file (C:\\OSGeo4W
here is my make command
c++ -O2 -w -g -DUSE_OGR -DUSE_PROJ -I/usr/lib/grass64/include grass.o
-L/usr/lib/grass64/lib -lgrass_I -lgrass_Iortho -lgrass_arraystats
-lgrass_bitmap -lgrass_btree -lgrass_cairodriver -lgrass_cdhc
-lgrass_cluster -lgrass_datetime -lgrass_dbmibase -lgrass_dbmiclient
-lg
Markus Metz wrote:
> But back to the original problem: how about a new option to
> v.category to reduce the number of categories for a given object
> and layer to 1?
but from among the choices which of the categories wins? v.buffer deals
with this by not letting any of them win, at least the resul
#1507: r.in.gdal & others: -e must only modify the current mapset's WIND file
-+--
Reporter: hamish | Owner: grass-dev@…
Type: defect | Stat
Hi all,
currently the GRASS AddOns extensions are installed on GNU/Linux to
$HOME/.grass/addons
and on Windows to
$AppData\GRASS\addons
This layout doesn't allow to install extensions for more installed
versions of GRASS. In other words, addons for GRASS 6.4.2 and GRASS
6.5 are installed on th
#1507: r.in.gdal & others: -e must only modify the current mapset's WIND file
-+--
Reporter: hamish | Owner: grass-dev@…
Type: defect | Stat
On Wed, Dec 14, 2011 at 8:28 AM, Mohammed Rashad
wrote:
>
> Hi All,
> I am using C code of grass to execute a grass command
> start_command()
> how to get percentage of process when running a grass command
http://grass.osgeo.org/wiki/GRASS_and_Python#Percentage_output_for_progress_of_computat
On Wed, Dec 14, 2011 at 8:16 AM, Maris Nartiss wrote:
> OK. When creating a new test dataset I understood where's the problem:
> v.clean rmdupl will remove duplicate geometries and will merge
> categories resulting in single geometry, multiple categories
> (acceptable in GRASS)
> v.out.ogr can not
#1507: r.in.gdal & others: -e must only modify the current mapset's WIND file
-+--
Reporter: hamish | Owner: grass-dev@…
Type: defect | Stat
#1507: r.in.gdal & others: -e must only modify the current mapset's WIND file
-+--
Reporter: hamish | Owner: grass-dev@…
Type: defect | Stat
#1152: d.out.file + cairo: errors writing the image
--+-
Reporter: hamish | Owner: grass-dev@…
Type: defect | Status: closed
Priority: major| Milestone: 6.4.
40 matches
Mail list logo
