<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.comp.gis.grass.devel">
    <title>gmane.comp.gis.grass.devel</title>
    <link>http://blog.gmane.org/gmane.comp.gis.grass.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gis.grass.devel/53271"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gis.grass.devel/53268"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gis.grass.devel/53267"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gis.grass.devel/53263"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gis.grass.devel/53253"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gis.grass.devel/53249"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gis.grass.devel/53246"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gis.grass.devel/53237"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gis.grass.devel/53235"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gis.grass.devel/53210"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gis.grass.devel/53201"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gis.grass.devel/53188"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gis.grass.devel/53182"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gis.grass.devel/53178"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gis.grass.devel/53177"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gis.grass.devel/53169"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gis.grass.devel/53162"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gis.grass.devel/53158"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gis.grass.devel/53149"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gis.grass.devel/53148"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gis.grass.devel/53271">
    <title>Update manual for "i.oif"</title>
    <link>http://comments.gmane.org/gmane.comp.gis.grass.devel/53271</link>
    <description>&lt;pre&gt;The manual of i.oif refers to LANDSAT TM bands 1-5, &amp;amp; 7.  Why not for newer 
Landsat products, e.g. ETM+?

Can/should we update the manual?

&amp;lt;http://grass.osgeo.org/grass70/manuals/i.oif.html&amp;gt;

Thanks, Nikos
&lt;/pre&gt;</description>
    <dc:creator>Nikos Alexandris</dc:creator>
    <dc:date>2013-05-24T00:39:07</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gis.grass.devel/53268">
    <title>FTBFS: segmentation fault in lib/vector/diglib/test.c</title>
    <link>http://comments.gmane.org/gmane.comp.gis.grass.devel/53268</link>
    <description>&lt;pre&gt;Hi,

by chance I found this report in the Fedora 19 bugtracker:

FTBFS: segmentation fault in lib/vector/diglib/test.c
https://bugzilla.redhat.com/show_bug.cgi?id=961838

-&amp;gt; Segmentation fault, looks like integer overflow.
Does anybody see the issue?

Markus
&lt;/pre&gt;</description>
    <dc:creator>Markus Neteler</dc:creator>
    <dc:date>2013-05-23T20:53:23</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gis.grass.devel/53267">
    <title>Using the pygrass "Mapset.glist" method and a dictionary</title>
    <link>http://comments.gmane.org/gmane.comp.gis.grass.devel/53267</link>
    <description>&lt;pre&gt;Hi list.

In a Python script, I use the following pygrass method to retrieve a list of 
raster maps:

from grass.pygrass.gis import Mapset
..
landsat_imagery = dict()
..
landsat_imagery['Spectral Bands'] = Mapset().glist('rast', pattern = 
'B[123457]')

However, whenever the result is empty, i.e. there are no B1, B2 and so on 
named raster maps, running the script fails with the error:


landsat_imagery['Spectral Bands'] = Mapset().glist('rast', pattern = 
'B[123457]')
TypeError: 'str' object is not callable


Running the instructions step-wise, from within ipython, doesn't appear to be 
problematic.  What am I missing in this case?

Thank you for any hints, Nikos
&lt;/pre&gt;</description>
    <dc:creator>Nikos Alexandris</dc:creator>
    <dc:date>2013-05-23T19:50:10</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gis.grass.devel/53263">
    <title>GRASS 7: v.net.path and xml.etree.ElementTree ParseError</title>
    <link>http://comments.gmane.org/gmane.comp.gis.grass.devel/53263</link>
    <description>&lt;pre&gt;Hi,

trying out v.net.path on yesterday's GRASS 7 OSGeo4W, the command runs
through properly (correct result) but raises then an error:


echo 1 1 2 | v.net.path KAnet_HbfHs alayer=1 nlayer=2 out=shortpath_dist --o
WARNING: Il vettoriale &amp;lt;shortpath_dist&amp;gt; è già presente e sarà sovrascritto
Creando il grafico...
Registrando archi...
Flattening the graph...
Il grafico è stata creato
Si sta ricreando la topologia per il vettore &amp;lt;shortpath_dist&amp;lt; at &amp;gt;KA_net&amp;gt;...
Registrando primitive...
1 primitive registrate
140 vertici registrati
Costruendo aree...
0 aree create
0 isole create
Isole allegate...
Centroidi allegati...
Numero di nodi: 2
Numero di primitive:1
Numero di punti:0
Numero di linee:1
Numero di confini:0
Numero di centroidi:0
Numero di aree:0
Numero di isole:0
(Thu May 23 17:47:18 2013) Command finished (0 sec)
Traceback (most recent call last):
  File "C:\OSGeo4W\apps\grass\grass-7.0.svn\etc\gui\wxpython
\core\gconsole.py", line 647, in OnCmdDone

task = GUI(show=None).ParseCommand(event.cmd)
  File "C:\OSGeo4W\apps\grass\grass-7.0.svn\etc\gui\wxpython
\gui_core\forms.py", line 2188, in ParseCommand

blackList = _blackList)
  File "C:\OSGeo4W\apps\grass\grass-7.0.svn\etc\python\grass
\script\task.py", line 487, in parse_interface

tree = etree.fromstring(get_interface_description(name))
  File
"C:\OSGeo4W\apps\Python27\lib\xml\etree\ElementTree.py",
line 1300, in XML

parser.feed(text)
  File
"C:\OSGeo4W\apps\Python27\lib\xml\etree\ElementTree.py",
line 1642, in feed

self._raiseerror(v)
  File
"C:\OSGeo4W\apps\Python27\lib\xml\etree\ElementTree.py",
line 1506, in _raiseerror

raise err
xml.etree.ElementTree
.
ParseError
:
syntax error: line 1, column 0


Citing a related older wish:


On Wed, Jan 25, 2012 at 3:58 AM, Glynn Clements
&amp;lt;glynn&amp;lt; at &amp;gt;gclements.plus.com&amp;gt; wrote:

I wonder where the error comes from... happens on Linux as well. Perhaps
the pipe | is causing it?

Markus
&lt;/pre&gt;</description>
    <dc:creator>Markus Neteler</dc:creator>
    <dc:date>2013-05-23T16:34:59</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gis.grass.devel/53253">
    <title>[GRASS GIS] #1977: r.random.cells does not respect MASK</title>
    <link>http://comments.gmane.org/gmane.comp.gis.grass.devel/53253</link>
    <description>&lt;pre&gt;#1977: r.random.cells does not respect MASK
----------------------------------+-----------------------------------------
 Reporter:  pvanbosgeo            |       Owner:  grass-dev&amp;lt; at &amp;gt;…              
     Type:  defect                |      Status:  new                      
 Priority:  normal                |   Milestone:  6.4.3                    
Component:  Raster                |     Version:  unspecified              
 Keywords:  r.random.cells, mask  |    Platform:  Unspecified              
      Cpu:  Unspecified           |  
----------------------------------+-----------------------------------------
 In the helpfile of r.random.cells, it is mentioned that "Random cells will
 not be generated in areas masked off". However, in reality the function
 does not (seem to) respect the MASK.

&lt;/pre&gt;</description>
    <dc:creator>GRASS GIS</dc:creator>
    <dc:date>2013-05-23T06:43:05</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gis.grass.devel/53249">
    <title>r.random.cells does not respect mask</title>
    <link>http://comments.gmane.org/gmane.comp.gis.grass.devel/53249</link>
    <description>&lt;pre&gt;In the helpfile of r.random.cells, it is mentioned that "Random cells 
will not be generated in areas masked off". However, in reality the 
function does not (seem to) respect the MASK.

Running grass 7.0 on ubuntu 13.04

p.s. I was going to file a bug report, but the 
http://trac.osgeo.org/grass seems to be offline.

_______________________________________________
grass-dev mailing list
grass-dev&amp;lt; at &amp;gt;lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev&lt;/pre&gt;</description>
    <dc:creator>Paulo van Breugel</dc:creator>
    <dc:date>2013-05-22T07:20:46</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gis.grass.devel/53246">
    <title>SQL "where=" parameter for "v.proj" ?</title>
    <link>http://comments.gmane.org/gmane.comp.gis.grass.devel/53246</link>
    <description>&lt;pre&gt;Hi devs!

Another vector related question:

is it possible, and if yes, would it make sense, to have support for SQL 
condition statements (i.e. a "where=" parameter) in v.proj?

Thank you, Nikos
&lt;/pre&gt;</description>
    <dc:creator>Nikos Alexandris</dc:creator>
    <dc:date>2013-05-21T16:34:19</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gis.grass.devel/53237">
    <title>Backporting the start_rast option in r.walk</title>
    <link>http://comments.gmane.org/gmane.comp.gis.grass.devel/53237</link>
    <description>&lt;pre&gt;Hi,

I am a happy user the start_rast option in r.walk in GRASS 7,

Recently I realised that the option is not available on the stable
version of GRASS (6.4.2) when a student here tried one of my scripts.

Is there any plan to backport this, or should the student switch to GRASS 7?

Cheers,

Pierre

--
Scientist
Landcare Research, New Zealand
&lt;/pre&gt;</description>
    <dc:creator>Pierre Roudier</dc:creator>
    <dc:date>2013-05-21T05:39:33</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gis.grass.devel/53235">
    <title>Submission for Addons repository</title>
    <link>http://comments.gmane.org/gmane.comp.gis.grass.devel/53235</link>
    <description>&lt;pre&gt;
Hello,

I have a GRASS module that I'd like to submit to the Add-ons SVN repository so that users can install it via g.extension.

The module is currently hosted here:

https://github.com/selimnairb/r.findtheriver


I've followed the instructions here:

http://grass.osgeo.org/grass64/source/SUBMITTING

and think that I'm ready to submit the code.  What's the next step?


Thanks,

Brian Miles
Ph.D. candidate
Department of Geography
University of North Carolina at Chapel Hill

Saunders Hall
Campus Box 3220
Chapel Hill, NC 27599-3220




_______________________________________________
grass-dev mailing list
grass-dev&amp;lt; at &amp;gt;lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev&lt;/pre&gt;</description>
    <dc:creator>Brian Miles</dc:creator>
    <dc:date>2013-05-20T21:48:40</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gis.grass.devel/53210">
    <title>GRASS GIS Visual Studio build</title>
    <link>http://comments.gmane.org/gmane.comp.gis.grass.devel/53210</link>
    <description>&lt;pre&gt;Hi All,

Is there any visual studio build of GRASS GIS. If no why?

&lt;/pre&gt;</description>
    <dc:creator>Rashad M</dc:creator>
    <dc:date>2013-05-20T05:28:02</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gis.grass.devel/53201">
    <title>[GRASS GIS] #1976: Allow rounding of floating numbers</title>
    <link>http://comments.gmane.org/gmane.comp.gis.grass.devel/53201</link>
    <description>&lt;pre&gt;#1976: Allow rounding of floating numbers
-------------------------+--------------------------------------------------
 Reporter:  pvanbosgeo   |       Owner:  grass-dev&amp;lt; at &amp;gt;…              
     Type:  enhancement  |      Status:  new                      
 Priority:  normal       |   Milestone:  7.0.0                    
Component:  Default      |     Version:  unspecified              
 Keywords:               |    Platform:  Unspecified              
      Cpu:  Unspecified  |  
-------------------------+--------------------------------------------------
 The round() function in r.mapcalc always returns an integer, regardless of
 its argument types. Integers are always 32-bit, so the result is limited
 to the range +/- 2147483647 (2^31-1).

 Suggestion: extend the function to allow to round numbers outside the
 integer range, and to round with a specific number of decimal places, like
 e.g., the function round() in R.

 Various options have been discussed on the mailing list, see this
 [http://lists.osgeo.org/pipermail/grass-dev/2013-May/063827.html email
 thread]

&lt;/pre&gt;</description>
    <dc:creator>GRASS GIS</dc:creator>
    <dc:date>2013-05-17T21:24:46</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gis.grass.devel/53188">
    <title>In G7, v.category with option=transfer layer=1,2 doesn't seem to be effective</title>
    <link>http://comments.gmane.org/gmane.comp.gis.grass.devel/53188</link>
    <description>&lt;pre&gt;In G7

# transfer cats to new layers, as the manual describes [1]
v.category polygons option=transfer layer=1,2 out=polygons_tmp

# checking
v.db.select polygons_tmp
cat|id|cat_
1|1|

v.db.select polygons_tmp layer=2
cat

Shouldn't that work out-of-the box?

N

ps- Related: &amp;lt;http://gis.stackexchange.com/questions/17076/how-to-make-the-layer-2-use-the-same-vector-categories-from-layer-1&amp;gt;

---
[1] &amp;lt;http://grass.fbk.eu/manuals/html70_user/v.category.html&amp;gt;

--%&amp;lt;---
Copy categories from layer 1 to layer 2,3,4,5,6,7 and 8
Existing layer will be overwritten, non-existing will be created.

v.category input=observer output=observer_new option=transfer 
layer=1,2,3,4,5,6,7,8
--&amp;gt;%---
&lt;/pre&gt;</description>
    <dc:creator>Nikos Alexandris</dc:creator>
    <dc:date>2013-05-17T13:33:48</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gis.grass.devel/53182">
    <title>wxgui (module dialog) one "Required" struct Option is necessary to create dialog box</title>
    <link>http://comments.gmane.org/gmane.comp.gis.grass.devel/53182</link>
    <description>&lt;pre&gt;Hi,

the auto creation of dialog box for modules has to have at least one
input-&amp;gt;required = YES; appearing in the "Required" Tab to build on the
fly.

Can somebody help me to remove this requirement.
I am building a module that does forward and inverse modeling,

(maybe that is why i.fft has a i.ifft sister module)

Cheers,
Yann

--
Yann Chemin
Researcher&amp;lt; at &amp;gt;IWMI
Skype/FB: yann.chemin
&lt;/pre&gt;</description>
    <dc:creator>Yann Chemin</dc:creator>
    <dc:date>2013-05-17T09:15:35</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gis.grass.devel/53178">
    <title>is there a grass limit on opening a number of files</title>
    <link>http://comments.gmane.org/gmane.comp.gis.grass.devel/53178</link>
    <description>&lt;pre&gt;Hi

I am testing a module that opens a large number of files as input,
large being in thousands.

the 513th file is doing well individually, however the module just
cannot read it (and subsequent ones).

----------------------------------------------
ERROR: Unable to open input file
       &amp;lt;/home/yann/GRASSDATA/RR/PERMANENT/cell_misc/rain_0512/f_format&amp;gt;
----------------------------------------------

is it a file limit for opening files in GRASS?
If yes, can it be enlarged to 10000+?

Thank you,
Yann

--
Yann Chemin
Researcher&amp;lt; at &amp;gt;IWMI
Skype/FB: yann.chemin
&lt;/pre&gt;</description>
    <dc:creator>Yann Chemin</dc:creator>
    <dc:date>2013-05-17T06:25:27</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gis.grass.devel/53177">
    <title>i.gensig limited to 255 signatures</title>
    <link>http://comments.gmane.org/gmane.comp.gis.grass.devel/53177</link>
    <description>&lt;pre&gt;Hi,

is there a reason for i.gensig being limited to 255 signatures, else
historical (i.e. 8-bit landsat)?

is there any possibility to move that limit to 16-bit?

Thank you,
Yann

--
Yann Chemin
Researcher&amp;lt; at &amp;gt;IWMI
Skype/FB: yann.chemin
&lt;/pre&gt;</description>
    <dc:creator>Yann Chemin</dc:creator>
    <dc:date>2013-05-17T03:45:44</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gis.grass.devel/53169">
    <title>Compiling of GRASS from source under ubuntu - why do Ineed two raisins?????</title>
    <link>http://comments.gmane.org/gmane.comp.gis.grass.devel/53169</link>
    <description>&lt;pre&gt;Hi

I wanted to compile GRASS from source, and ended up in the kitchen
looking for raisins:

on
http://grasswiki.osgeo.org/wiki/Compile_and_Install_Ubuntu#Dependencies

it says: 

,----
|   libncurses5-dev \
|   zlib1g- [≈ Two raisins (approximately 1 gram)]dev gettext \
|   libtiff-dev libpnglite-dev \
`----

As I then did not manage to squeeze them into my USB port, I decided to
eat them.

Seriously:
I assume this is an innocent typo, or was it a hacker?

Cheers,

Rainer


&lt;/pre&gt;</description>
    <dc:creator>Rainer M. Krug</dc:creator>
    <dc:date>2013-05-16T14:47:18</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gis.grass.devel/53162">
    <title>[GRASS GIS] #1975: v.overlay.and gets "stuck"</title>
    <link>http://comments.gmane.org/gmane.comp.gis.grass.devel/53162</link>
    <description>&lt;pre&gt;#1975: v.overlay.and gets "stuck"
-------------------------+--------------------------------------------------
 Reporter:  kiarasky     |       Owner:  grass-dev&amp;lt; at &amp;gt;…              
     Type:  defect       |      Status:  new                      
 Priority:  normal       |   Milestone:  6.4.3                    
Component:  Default      |     Version:  unspecified              
 Keywords:               |    Platform:  Linux                    
      Cpu:  Unspecified  |  
-------------------------+--------------------------------------------------
 Hi all! It's Kiara. I am using a script to overlay two shapefiles,
 respectively line and polygon type. The overlay operation gets stuck at
 approximately 74%, and it happens in the script, by command line and also
 by using the grass toolbox in qgis. maybe the problem is the number of
 vertices?
 More info: (ALL_ROUTES_M1SO6 is the line map, prova_conc_grand_grass is a
 test polygon i'm using)
 ***
 GRASS 6.4.2 (Europe):~/Desktop/short-term/grass_CODE_NewData &amp;gt; v.overlay
 ainput=ALL_ROUTES_M1SO6&amp;lt; at &amp;gt;PERMANENT atype=line alayer=1
 binput=prova_conc_grand_grass&amp;lt; at &amp;gt;PERMANENT btype=area blayer=1
 output=routes_overlapped_test2 operator=and
 Copying vector objects from vector map &amp;lt;ALL_ROUTES_M1SO6&amp;lt; at &amp;gt;PERMANENT&amp;gt;...
  100%
 Collecting input attributes...
 Copying vector objects from vector map
 &amp;lt;prova_conc_grand_grass&amp;lt; at &amp;gt;PERMANENT&amp;gt;...
  100%
 Collecting input attributes...
 Building partial topology...
 Building topology for vector map &amp;lt;routes_overlapped_test2&amp;gt;...
 Registering primitives...
 869 primitives registered
 20203 vertices registered
 Number of nodes: 138
 Number of primitives: 869
 Number of points: 0
 Number of lines: 868
 Number of boundaries: 1
 Number of centroids: 0
 Number of areas: -
 Number of isles: -
 Breaking lines...
 ^C74%
 *** here I stopped the procedure, and after that I cannot open the map
 that has been created. My maximum wall time has been 20 minutes...is that
 normal?

 thanks a lot
 Kiara

&lt;/pre&gt;</description>
    <dc:creator>GRASS GIS</dc:creator>
    <dc:date>2013-05-16T09:24:32</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gis.grass.devel/53158">
    <title>v.db.* issues</title>
    <link>http://comments.gmane.org/gmane.comp.gis.grass.devel/53158</link>
    <description>&lt;pre&gt;Hi,

I encountered an issue with some database modules in WinGRASS 7 
(revision 56269). If I add a vector layer to the display, several v.db.* 
modules give me an error, such as:
Traceback (most recent call last):
   File "C:\OSGeo4W\apps\grass\grass-7.0.svn\etc\gui\wxpython
\lmgr\frame.py", line 737, in OnMenuCmd

cmd = self.GetMenuCmd(event)
   File "C:\OSGeo4W\apps\grass\grass-7.0.svn\etc\gui\wxpython
\lmgr\frame.py", line 722, in GetMenuCmd

input = GUI().GetCommandInputMapParamKey(cmdlist[0])
   File "C:\OSGeo4W\apps\grass\grass-7.0.svn\etc\gui\wxpython
\gui_core\forms.py", line 2306, in
GetCommandInputMapParamKey

tree =
etree.fromstring(gtask.get_interface_description(cmd))
   File "C:\OSGeo4W\apps\grass\grass-7.0.svn\etc\python\grass
\script\task.py", line 461, in get_interface_description

"\n\nDetails: %(det)s") % { 'cmd' : cmd, 'det' :
decode(cmderr) }
grass.script.core
.
ScriptError
:
Unable to fetch interface description for command
'v.db.addtable'.
Details: C:\OSGeo4W\bin\python.exe: can't open file
'v.db.addtable': [Errno 2] No such file or directory

However, when I remove the vector layer from display then I have no 
problem. It seems that this behaviour occurs only with those v.db.* 
modules that are in the menu Database&amp;gt;Vector Database connections, apart 
from the very last one there (v.db.connect).
I suspect this has also something to do with my other problem I only 
recently began to have. Namely, v.db.addtable doesn't work for me in 
Python scripts.

Not long ago I associated all .py and .pyc files in Windows to 
pythonw.exe in C:\OSGeo4W\bin\. That's the only bigger change I've been 
making and that should (I guess) have positive effects for GRASS.
Running Windows 7 (64bit).

Regards,
Allar
&lt;/pre&gt;</description>
    <dc:creator>Allar Haav</dc:creator>
    <dc:date>2013-05-16T07:48:48</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gis.grass.devel/53149">
    <title>null value in vector (v.in.ascii, v.surf.*)</title>
    <link>http://comments.gmane.org/gmane.comp.gis.grass.devel/53149</link>
    <description>&lt;pre&gt;Hi,

I am importing a large amount of ascii files as 3D vectors, some of
them have null values (currently set to an arbitrary high constant
value)

Is there a filter for v.in.ascii to set null values,
 and/or
in v.surf.* to avoid using those points with specific values?

Yann

--
Yann Chemin
Researcher&amp;lt; at &amp;gt;IWMI
Skype/FB: yann.chemin
&lt;/pre&gt;</description>
    <dc:creator>Yann Chemin</dc:creator>
    <dc:date>2013-05-16T05:42:34</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gis.grass.devel/53148">
    <title>new location wizard wxgui problem in trunk</title>
    <link>http://comments.gmane.org/gmane.comp.gis.grass.devel/53148</link>
    <description>&lt;pre&gt;Using the new location button in the wxgui, this happens

Traceback (most recent call last):
  File "/usr/local/grass-7.0.svn/etc/gui/wxpython/gis_set.py", line
408, in OnWizard
    grassdatabase = self.tgisdbase.GetValue())
  File "/usr/local/grass-7.0.svn/etc/gui/wxpython/location_wizard/wizard.py",
line 1804, in __init__
    self.__readData()
  File "/usr/local/grass-7.0.svn/etc/gui/wxpython/location_wizard/wizard.py",
line 2008, in __readData
    ellipse, rest = line.split(" ", 1)
ValueError: need more than 1 value to unpack
Traceback (most recent call last):
  File "/usr/local/grass-7.0.svn/etc/gui/wxpython/gis_set.py", line
408, in OnWizard
    grassdatabase = self.tgisdbase.GetValue())
  File "/usr/local/grass-7.0.svn/etc/gui/wxpython/location_wizard/wizard.py",
line 1804, in __init__
    self.__readData()
  File "/usr/local/grass-7.0.svn/etc/gui/wxpython/location_wizard/wizard.py",
line 2008, in __readData
    ellipse, rest = line.split(" ", 1)
ValueError: need more than 1 value to unpack
Received EXIT message from GUI.
GRASS is not started. Bye.


--
Yann Chemin
Researcher&amp;lt; at &amp;gt;IWMI
Skype/FB: yann.chemin
&lt;/pre&gt;</description>
    <dc:creator>Yann Chemin</dc:creator>
    <dc:date>2013-05-16T05:07:14</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gis.grass.devel/53144">
    <title>interp_type: cubic | bicubic</title>
    <link>http://comments.gmane.org/gmane.comp.gis.grass.devel/53144</link>
    <description>&lt;pre&gt;Hi,

recently I have added a standardized option for sampling interpolation
methods [1], based on lib/raster/sample.c and codes defined in
raster.h [2].

Some modules use 'bicubic' other 'cubic' value. What do you think that
is more preferable? It's bicubic interpolation [3] accomplished using
cubic convolution, right?

Martin

[1] http://trac.osgeo.org/grass/changeset/56211
[2] http://trac.osgeo.org/grass/browser/grass/trunk/include/raster.h#L21
[3] http://en.wikipedia.org/wiki/Bicubic_interpolation

--
Martin Landa &amp;lt;landa.martin gmail.com&amp;gt; * http://geo.fsv.cvut.cz/~landa
&lt;/pre&gt;</description>
    <dc:creator>Martin Landa</dc:creator>
    <dc:date>2013-05-15T20:03:13</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.gis.grass.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.gis.grass.devel</link>
  </textinput>
</rdf:RDF>
