Re: [GRASS-dev] geodesic distances for measuring and buffers, even when working in planar coordinate system ? [was: Re: [GRASS-user] What distance is being measured and used for buffers ?]

2012-09-07 Thread Markus Metz 
On Tue, Sep 4, 2012 at 6:57 PM, Moritz Lennert
 wrote:
> On 01/09/12 18:02, Moritz Lennert wrote:
>>
>> Leaving below mail as record of my original issue, I would to raise the
>> fundamental question of whether it would be feasible
>>
>> 1) to (optionally) provide geodesic instead of planar distances when
>> measuring, even if the location is in a projected coordinate system.
>> E.g. QGIS provides the possibility in distance measuring to check a box
>> to activate geodesic distance
>>
>> 2) to (optionally) allow the creation of buffers based on geodesic
>> distances, again in a projected location, which would imply non-circular
>> buffers.
>>
>
> Exploring my exploration of this in the hope that someone might share an
> interest:
>
> r.buffer actually provides the possibility of geodesic buffering when used
> in a lat-long location. Would it be difficult to implement the same in
> v.buffer ?

The short answer is yes, it will be difficult. The GRASS-internal
vector buffering algorithm has a number of bugs, the only vector
buffering method that is AFAICT bug-free is v.buffer in trunk with
GEOS support which uses the GEOS buffering algorithm which in turn
does not (yet?) support geodesic distances in latlong.

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

Re: [GRASS-dev] [GRASS GIS] #1629: v.in.db - odbc-driver - access-database: not working

2012-09-07 Thread GRASS GIS 
#1629: v.in.db - odbc-driver - access-database: not working
+---
 Reporter:  hellik  |   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  critical|   Milestone:  6.4.3
Component:  Database| Version:  svn-releasebranch64  
 Keywords:  wingrass, db, odbc  |Platform:  MSWindows Vista  
  Cpu:  x86-32  |  
+---

Comment(by mlennert):

 Replying to [ticket:1629 hellik]:
 > v.in.db driver=odbc database="C:\wd\access\testinput.mdb"
 table=grassinput key=ID x=xcoor y=ycoor output=mdbvector

 AFAIK, this is wrong usage of the odbc driver. database should not be the
 path of the mdb file, but rather the name you give to the database in the
 ODBC configuration.

 This is what the message in German actually says:

 "[Microsoft][ODBC Driver Manager] Der Datenquellenname wurde nicht
 gefunden", i.e. The name of the source of data could not be found. Note
 that it doesn't say that the _file_ hasn't been found, but the _name_.

 ODBC is an intermediate layer which allows clients to communicate with
 database in a standardized language. This means that clients do not
 connect to the database directly, but via ODBC. In order to be able to
 connect, you have to configure this connection using dedicated tools (IIUC
 in MS Windows the tool is currently called "ODBC Data Source
 Administrator") and give a name to that connection. You then use that name
 as database name when accessing from a client via odbc.

 I believe that unless there is more info about the ODBC access failing
 when used correctly, this bug should be closed as invalid.

 Moritz

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] geodesic distances for measuring and buffers, even when working in planar coordinate system ? [was: Re: [GRASS-user] What distance is being measured and used for buffers ?]

2012-09-07 Thread Moritz Lennert 

On 07/09/12 09:05, Markus Metz wrote:

On Tue, Sep 4, 2012 at 6:57 PM, Moritz Lennert
  wrote:

On 01/09/12 18:02, Moritz Lennert wrote:


Leaving below mail as record of my original issue, I would to raise the
fundamental question of whether it would be feasible

1) to (optionally) provide geodesic instead of planar distances when
measuring, even if the location is in a projected coordinate system.
E.g. QGIS provides the possibility in distance measuring to check a box
to activate geodesic distance

2) to (optionally) allow the creation of buffers based on geodesic
distances, again in a projected location, which would imply non-circular
buffers.



Exploring my exploration of this in the hope that someone might share an
interest:

r.buffer actually provides the possibility of geodesic buffering when used
in a lat-long location. Would it be difficult to implement the same in
v.buffer ?


The short answer is yes, it will be difficult. The GRASS-internal
vector buffering algorithm has a number of bugs, the only vector
buffering method that is AFAICT bug-free is v.buffer in trunk with
GEOS support which uses the GEOS buffering algorithm which in turn
does not (yet?) support geodesic distances in latlong.


Ok, thanks for the answer. This means that efforts should be put into 
including this into GEOS and in the mean time, maybe write a small 
script v.buffer.geodesic that uses r.buffer.


Since we're on it: any idea about question 1) ?

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

[GRASS-dev] New AddOns for Analyzing landscape connectivity based on graph-theory - the r.connectivity.*-toolchain

2012-09-07 Thread Blumentrath, Stefan 
Dear all,

Last week I presented a set of three new GRASS-AddOns for analyzing landscape 
connectivity based on graph-theory at the European Congress of Conservation 
Biology (ECCB, http://eccb2012.org/) in Glasgow . This set of tools applies 
methods documented (a.o.) in the following literature to the input data you 
might have.

Bunn, A. G., Urban, D. L. & Keitt, T. H. 2000: Landscape connectivity: A 
conservation application of graph theory. Journal of Environmental Management 
(2000) 59: 265-278. 
http://www.sciencedirect.com/science/article/pii/S0301479700903736
Calabrese, J. M. & Fagan, W. F. 2004: A comparison-shopper's guide to 
connectivity metrics. Front Ecol Environ 2 (10): 529-536 . 
http://dx.doi.org/10.1890/1540-9295(2004)002[0529:ACGTCM]2.0.CO;2
Minor, E. S. & Urban, D. L. 2008: A Graph-Theory Framework for Evaluating 
Landscape Connectivity and Conservation Planning. Conservation Biology 22 (2): 
297-307. http://www.uic.edu/labs/minor/minor&urban2008.pdf
Zetterberg, A.,  Mörtberg, U. M. & Balfors, B. 2010: Making graph theory 
operational for landscape ecological assessments, planning, and design. 
Landscape and Urban Planning (2010) 95: 181-191. 
http://www.sciencedirect.com/science/article/pii/S016920461204
Ranius, T. & Roberge, J.-M. 2011: Effects of intensified forestry on the 
landscape-scale extinction risk of dead wood dependent species. Biodiversity 
and Conservation 20 (13): 2867-2882. 
http://www.springerlink.com/content/ch9qtv2665h624q4

The input data the tools take are:

-  A polygon vector map containing habitat patches (of your species / 
habitat type in question) and a column for a population proxy (e.g. patch 
area). (required)

-  A cost raster map (for more information on that see the 
r.cost-manual) (optional; if no cost raster is provided Euclidean distance is 
used).

-  Dispersal information

o   A maximum (cost) distance threshold for assumed connectivity

o   A dispersal kernel (defined by three variables of a negative exponential 
decay function (see eg. Bunn et al. 2000)

The outputs are connectivity measures on vertex (=patch) level, edge (= the 
connection between two patches) level, and graph (the entire network) level. 
With r.connectivity.corridors you can also identify corridors for the 
connections (edges) you select, and you can weight their importance based on a 
column of your choice (e.g. connectivity measures from r.connectivity.network).

The tools (and documentation) can be found in the GRASS AddOns SVN repository 
(see: r.connectivity.distance, r.connectivity.network, r.connectivity.corridors 
in the http://grass.osgeo.org/wiki/GRASS_AddOns/). They are UNIX-shell (and one 
R-) scripts.

Required additional software is: Cran R with at least the packages "igraph" 
(version 0.6-2) and "nlme" installed. If you want to make use of parallel 
processing / multi-threading you need also the packages "doMC", "foreach", 
"iterators", "codetools", and "multicore". But multithreading is only supported 
on LINUX. The tools have not been tested on Windows yet, but this will be done 
in near future.

Any kind of feedback would be very much appreciated!

Cheers
Stefan

P.S.: What do you think, how helpful would an example based on the spearfish 
dataset be? If you think so, I will add that to the documentation, as soon as 
the projects which triggered the development of the r.connectivity.*-tools are 
published.

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

Re: [GRASS-dev] compiling relbrand64 fails on windows

2012-09-07 Thread Markus Neteler 
On Sun, Sep 2, 2012 at 10:23 PM, Glynn Clements
 wrote:
>
> Helmut Kudrnovsky wrote:
>
>> tested here in the osgeo4w-environment on a WinVista-32bit-box, svn-checkout
>> today:
>>
>> GRASS GIS compilation log
>> -
>> Started compilation: Fri Aug 31 15:48:36 GMT 2012
>> --
>> Errors in:
>> /osgeo4w/usr/src/grass643svn/lib/form
>> /osgeo4w/usr/src/grass643svn/lib/vector/diglib
>> /osgeo4w/usr/src/grass643svn/lib/init
>> [...]

I observe some differences, not sure if that's relevant here:

[neteler@north grass64]$ grep BINARY lib/gis/*
lib/gis/dllmain.c:  _fmode = O_BINARY;
lib/gis/fmode.c:int _fmode = _O_BINARY;

[neteler@north grass70]$ grep BINARY lib/gis/*
lib/gis/fmode.c:int _fmode = _O_BINARY;
lib/gis/gisinit.c:_fmode = O_BINARY;
lib/gis/popen.c:#define pipe(fds) _pipe(fds, 4096, O_BINARY|O_NOINHERIT)

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

Re: [GRASS-dev] [GRASS GIS] #854: g.extension does not work on a Mac (probably not on Windows either

2012-09-07 Thread GRASS GIS 
#854: g.extension does not work on a Mac (probably not on Windows either
-+--
 Reporter:  cmbarton |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  6.4.3
Component:  Installation | Version:  svn-releasebranch64  
 Keywords:  g.extension, addons  |Platform:  All  
  Cpu:  All  |  
-+--
Changes (by neteler):

  * version:  6.4.1 RCs => svn-releasebranch64
  * milestone:  6.4.2 => 6.4.3


Comment:

 Here a test on Ubuntu with GRASS 7, via the wxGUI extension manager:
 {{{
 (Fri Sep  7 04:01:24 2012)
 g.extension extension=r.houghtransform svnurl=http://svn.osgeo.org/grass
 /grass-addons/grass7
 Fetching  from GRASS-Addons SVN (be patient)...
 Compiling...
 ...
 linesegmentsextractor.cpp:133:37: warning: conversion to
 ‘int’ from ‘size_t {aka long unsigned int}’ may
 alter its value [-Wconversion]
 linesegmentsextractor.cpp:136:21: warning: conversion to
 ‘float’ from ‘double’ may alter its value
 [-Wconversion]
 /bin/sh: 1: /media/Proyectos/GISData_grass/South_america_cli
 mate_lonlat/Ortiz_j/.tmp/cito/4172.0/r.houghtransform/bin/r.
 houghtransform: Permission denied
 make: *** [r.houghtransform.tmp.html] Error 1
 ERROR: Compilation failed, sorry. Please check above error messages.
 (Fri Sep  7 04:01:33 2012) Command finished (8 sec)
 }}}

 I guess it should not run "/bin/sh" on a binary.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] build error against GCC 4.7

2012-09-07 Thread Glynn Clements 

Angelos Tzotsos wrote:

> After applying the patch, I now get this failure:

> /home/abuild/rpmbuild/BUILD/grass-6.4.2/dist.x86_64-unknown-linux-gnu/include/grass/iostream/minmaxheap.h:747:5:
>  
> note: declarations in dependent base 'BasicMinMaxHeap >' 
> are not found by unqualified lookup
> /home/abuild/rpmbuild/BUILD/grass-6.4.2/dist.x86_64-unknown-linux-gnu/include/grass/iostream/minmaxheap.h:747:5:
>  
> note: use 'this->insert' instead

> Perhaps this was fixed in another step?

Yes, r51633.

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

Re: [GRASS-dev] [GRASS GIS] #854: g.extension does not work on a Mac (probably not on Windows either

2012-09-07 Thread GRASS GIS 
#854: g.extension does not work on a Mac (probably not on Windows either
-+--
 Reporter:  cmbarton |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  6.4.3
Component:  Installation | Version:  svn-releasebranch64  
 Keywords:  g.extension, addons  |Platform:  All  
  Cpu:  All  |  
-+--

Comment(by neteler):

 Replying to [comment:20 neteler]:
 > Here a test on Ubuntu with GRASS 7, via the wxGUI extension manager:
 > {{{
 > (Fri Sep  7 04:01:24 2012)
 > g.extension extension=r.houghtransform svnurl=http://svn.osgeo.org/grass
 /grass-addons/grass7
 ...
 > linesegmentsextractor.cpp:136:21: warning: conversion to
 > ‘float’ from ‘double’ may alter its value
 > [-Wconversion]
 > /bin/sh: 1: /media/Proyectos/GISData_grass/South_america_cli
 > mate_lonlat/Ortiz_j/.tmp/cito/4172.0/r.houghtransform/bin/r.
 > houghtransform: Permission denied
 > make: *** [r.houghtransform.tmp.html] Error 1
 > ERROR: Compilation failed, sorry. Please check above error messages.
 > (Fri Sep  7 04:01:33 2012) Command finished (8 sec)
 > }}}
 >
 > I guess it should not run "/bin/sh" on a binary.

 The problem above seems to be Ubuntu related, it works ok on Fedora:

 {{{
 hough.cpp:111:10: warning: variable 'totsize' set but not
 used [-Wunused-but-set-variable]
 Installing...
 Updating metadata file...
 Installation of  successfully finished
 (Fri Sep  7 13:49:58 2012) Command finished (8 sec)
 }}}

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] adding volume layer in 6.4.3 and 7 binaries

2012-09-07 Thread Markus Neteler 
On Wed, Aug 29, 2012 at 12:15 PM, Hamish  wrote:
> Anna wrote:
>> Unable to fetch interface description for command
>> 'd.rast3d'.
>> Details: [Errno 2] No such file or directory
>>
>> So it cannot find the command. I couldn't find any solution,
>> maybe someone else knows what's going on?
>> I found related ticket here [1].
>> [1] http://trac.osgeo.org/grass/ticket/1515
>
> see also https://trac.osgeo.org/grass/ticket/1692 and friends.
>
>
> d.rast3d.py fails because it is not in the PATH.

This trick helps (for testing):

ln -s $HOME/grass64/gui/wxpython/scripts/d.rast3d.py $GISBASE/scripts/
chmod a+x $GISBASE/scripts/d.rast3d.py

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

Re: [GRASS-dev] [GRASS GIS] #1719: GRASS 7 Monitor command line support

2012-09-07 Thread GRASS GIS 
#1719: GRASS 7 Monitor command line support
-+--
 Reporter:  annalisapg   |   Owner:  grass-dev@…  
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-trunk
 Keywords:  d.mon|Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by wenzeslaus):

 In attachment png_rendering_pil_composition.diff you can see some changes
 which are necessary for rendering PNG (instead of PPM) and composing of
 images in Python using PIL (instead of g.pnmcomp).

 It is not completely working code. It is only experiment to see if this
 can be faster.

 The answer is no. I don't have any numbers but user experience is
 completely the same.

 Files are much smaller and there is one file less (thanks to composing in
 Python) but during zooming/panning the most of the time is spent with disk
 IO. (Tested on Ubuntu 10.04.)

 But we can output binary data to stdout and read them in Python directly.
 This would avoid disk IO. What do you think about using stdout instead of
 a file in case of d.* modules?

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] v.buffer doesn't respect region?

2012-09-07 Thread Eric Momsen 
>
>
> The short answer is yes, it will be difficult. The GRASS-internal
> vector buffering algorithm has a number of bugs, the only vector
> buffering method that is AFAICT bug-free is v.buffer in trunk with
> GEOS support which uses the GEOS buffering algorithm which in turn
> does not (yet?) support geodesic distances in latlong.
>
> Markus M
>
>
I was just using v.buffer yesterday, and found it was ignoring my region
settings, it processed the entire map instead of a small area.

I updated GRASS yesterday, and am compiled with GEOS.  Am I missing
something else, should v.buffer respect the region?

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

[GRASS-dev] language still broken for foreign Macs and x11 required - blockers

2012-09-07 Thread Michael Barton 
Sorry to be the bearer of bad news, but I've had a spanish student trying to 
use GRASS on a new Mac set to Spanish. It is completely unusable.

1. GRASS 6.4.3 and GRASS 7 refuse to start up in GUI mode to set initial 
location, GIS database, etc because X11 is not installed. But I did NOT compile 
this with X11. I started getting complaints about not having X11 installed very 
recently. It might be associated with the cartographic composer (I got this 
complaint when I tried to do a preview), but that could be a red herring I 
suppose. This is serious bug in at least some cases that keep GRASS from 
running on non-Linux systems. X11 does not come with either Mac or Windows.

2. The language issue is back in force--or perhaps never went away. When Salva 
tried to start up the gui, it created a python error that locale could not be 
set to es_AR. He has never set his computer to Argentinian Spanish and I have 
no idea where this is coming from. I was getting equally bogus errors from 
another Spanish colleague (who has been gone for a month, so I could not test). 
It is cool that we can set different languages in the GUI, but it should not 
keep the GUI from opening if something is not right about the computer's 
language setting. I've tried resetting in .bash_profile and will try in some 
other places to see if I can again come up with a workaround. But sadly, it is 
not working on GRASS 7 either, even after Maris' new fixes (unless something 
has happened to them in the past few days.

This is preventing GRASS from running on at least some Mac computers using 
non-english languages.

Hopefully these can be straightened out.

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

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

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

Re: [GRASS-dev] build error against GCC 4.7

2012-09-07 Thread Angelos Tzotsos 

On 09/07/2012 02:15 PM, Glynn Clements wrote:

Angelos Tzotsos wrote:


After applying the patch, I now get this failure:
/home/abuild/rpmbuild/BUILD/grass-6.4.2/dist.x86_64-unknown-linux-gnu/include/grass/iostream/minmaxheap.h:747:5:
note: declarations in dependent base 'BasicMinMaxHeap >'
are not found by unqualified lookup
/home/abuild/rpmbuild/BUILD/grass-6.4.2/dist.x86_64-unknown-linux-gnu/include/grass/iostream/minmaxheap.h:747:5:
note: use 'this->insert' instead
Perhaps this was fixed in another step?

Yes, r51633.

Thanks Glynn, I already used the latest svn snapshot for 6.4.3 to build 
and works fine.


Regards,
Angelos

--
Angelos Tzotsos
Remote Sensing Laboratory
National Technical University of Athens
http://users.ntua.gr/tzotsos

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

Re: [GRASS-dev] [GRASS GIS] #1721: Man pages not created for addons

2012-09-07 Thread GRASS GIS 
#1721: Man pages not created for addons
--+-
  Reporter:  micha|   Owner:  grass-dev@…  
  Type:  defect   |  Status:  closed   
  Priority:  normal   |   Milestone:  6.4.3
 Component:  Addons   | Version:  6.4.2
Resolution:  fixed|Keywords:  install, g.html2man  
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-
Changes (by micha):

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


Comment:

 I see what my problem was. I (mis)read the instructions from
 [http://grass.osgeo.org/wiki/Compile_and_Install#Addons] . I understood
 that MODULE_TOPDIR should refer to the top of the grass installation. Now,
 from you comments, I see it needs to be the directory where source is
 located. When I changed the procedure to:
 {{{
 make MODULE_TOPDIR=~/Downloads/grass-6.4.2/
 sudo make  MODULE_TOPDIR=~/Downloads/grass-6.4.2/ install
 }}}
 it worked fine.

 Maybe the compile and install wiki page should explicitly mention
 "/path/to/unpacked/grass/source"?


 Sorry for the noise, and thanks for the help.

-- 
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] #1721: Man pages not created for addons

2012-09-07 Thread GRASS GIS 
#1721: Man pages not created for addons
--+-
  Reporter:  micha|   Owner:  grass-dev@…  
  Type:  defect   |  Status:  reopened 
  Priority:  normal   |   Milestone:  6.4.3
 Component:  Addons   | Version:  6.4.2
Resolution:   |Keywords:  install, g.html2man  
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-
Changes (by martinl):

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


-- 
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] #1721: Man pages not created for addons

2012-09-07 Thread GRASS GIS 
#1721: Man pages not created for addons
--+-
  Reporter:  micha|   Owner:  grass-dev@…  
  Type:  defect   |  Status:  closed   
  Priority:  normal   |   Milestone:  6.4.3
 Component:  Addons   | Version:  6.4.2
Resolution:  invalid  |Keywords:  install, g.html2man  
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-
Changes (by martinl):

  * status:  reopened => closed
  * resolution:  => invalid


-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] v.buffer doesn't respect region?

2012-09-07 Thread Markus Neteler 
On Fri, Sep 7, 2012 at 5:00 PM, Eric Momsen  wrote:
> I was just using v.buffer yesterday, and found it was ignoring my region
> settings, it processed the entire map instead of a small area.
>
> I updated GRASS yesterday, and am compiled with GEOS.  Am I missing
> something else, should v.buffer respect the region?

To my knowledge no. As before, all vector modules work on full maps while
raster operations are done in the computational region (with a few exceptions).

To limit a vector area you need to clip it first (e.g., v.in.region +
v.overlay/v.select).

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

Re: [GRASS-dev] [GRASS GIS] #1619: v.krige won't load: ImportError: No module named globalvar

2012-09-07 Thread GRASS GIS 
#1619: v.krige won't load: ImportError: No module named globalvar
-+--
 Reporter:  momsen   |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  Default  | Version:  svn-trunk
 Keywords:  krige|Platform:  Linux
  Cpu:  x86-64   |  
-+--
Changes (by neteler):

 * cc: aghisla (added)


Comment:

 Startup problems fixed in r53127.

 Remaining issue: creating the variogram leads to
 {{{
 Traceback (most recent call last):
   File "/home/neteler/grass70/dist.x86_64-unknown-linux-
 gnu/etc/gui/wxpython/scripts/vkrige.py", line 444, in OnPlotButton
 if globals()["InputData"] is None:
 KeyError: 'InputData'
 Traceback (most recent call last):
   File "/home/neteler/grass70/dist.x86_64-unknown-linux-
 gnu/etc/gui/wxpython/scripts/vkrige.py", line 444, in OnPlotButton
 if globals()["InputData"] is None:
 KeyError: 'InputData'
 Traceback (most recent call last):
   File "/home/neteler/grass70/dist.x86_64-unknown-linux-
 gnu/etc/gui/wxpython/scripts/vkrige.py", line 256, in OnRunButton
 self.goutput.RunCmd(command, switchPage = True)
   File "/home/neteler/grass70/dist.x86_64-unknown-linux-
 gnu/etc/gui/wxpython/gui_core/goutput.py", line 604, in RunCmd
 self._notebook.SetSelectionByName('output')
 AttributeError: 'FlatNotebook' object has no attribute
 'SetSelectionByName'
 }}}

-- 
Ticket URL: 
GRASS GIS 

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