#718: r.li forgets mask/illegal filename
+---
Reporter: kyngchaos | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
For those who need to run both ArcGIS and GRASS with Python (common
situation in GIS labs),
here is the solution for the reported problem from our technical
support:
I found there are different builds of winpython 2.5 . The version
that works for both is build is 212. I found it here...
ht
#718: r.li forgets mask/illegal filename
+---
Reporter: kyngchaos | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
#718: r.li forgets mask/illegal filename
+---
Reporter: kyngchaos | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
Hamish wrote:
> I take it the wxGUI use of 'v.db.connect -g' still should explicitly
> set the fs='|' and split() on that instead of space?
Yes.
> Also Tcl/Tk versions of same still need attention / testing /
> backporting:
>
> https://trac.osgeo.org/grass/log/grass/branches/develbranch_6/gui
Hamish wrote:
> "i.e. can we always assume DCELL|double to be the same bit depth,
> and %.15g the most we'll ever be able to squeeze from it?"
>
> perhaps that's poorly worded: not that DCELL == double, but that
> size(double) in one place == size(double) in another.
We can assume that it alway
Hamish wrote:
> As for including LGPL code in the main trunk I personally don't have a
> problem with that as it reflects the upstream license/author's wishes,
> is new code, and is used as a library. By my reading the RFC2 doc nor
> 'g.version -c' & the COPYING file need any adjustment to cover
Peter Brooks wrote:
> No, I think it is whitespace... I'm trying to use the 'cmd >' field
> in the 'GRASS GIS Layer Manager' (the new wxPython GUI). I guess
> this is what a Windows user would try to do :-)
>
> I tried adding a space to the folder name (= 'c:\nc external'),
> forward slashes d
> [r.in.poly fails to read text input file on Windows/CMD line]
I have checked at the r.in.poly source code, the problem does
not seem to be there. The path is passed to fopen() verbatim.
what version/revision of 6.4.0svn is this? is it the latest?
ISTR that Martin&Glynn had fixed this -- wxGUI n
That did the trick, thanks for the quick update!
- Jamie
On Fri, Aug 14, 2009 at 9:56 AM, Markus Metz <
markus.metz.gisw...@googlemail.com> wrote:
> Hi,
>
> I've updated v.in.gshhs, it supports now GSHHS data versions 1.4 through to
> 2.0, and issues an error if a version is not supported, telli
Hi,
I've updated v.in.gshhs, it supports now GSHHS data versions 1.4 through
to 2.0, and issues an error if a version is not supported, telling
exactly that, no more non-descript error reading data.
v.in.gshhs imports exported as shapefiles display now properly in QGIS,
no more strange horiz
2009/8/14 :
> Author: neteler
> Date: 2009-08-14 12:56:13 -0400 (Fri, 14 Aug 2009)
> New Revision: 38731
>
> Removed:
> grass/branches/develbranch_6/scripts/v.db.droprow/
> Log:
> v.db.droprow apparently undesired
should be v.db.droprow also removed from trunk?
Martin
--
Martin Landa * http
On Fri, Aug 14, 2009 at 3:30 PM, Moritz
Lennert wrote:
> On 14/08/09 10:43, Markus Neteler wrote:
>> On Fri, Aug 14, 2009 at 10:15 AM, Martin Landa
>> wrote:
>>>
>>> 2009/8/11 Markus Neteler :
It removes vector objects (point, line, area, face etc.) from a vector
map through attribut
#719: v.edit tool=break: breaking more then 6 coords and producing of an
unexpected line
---+
Reporter: achim | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
(cc grass-dev)
[r.in.poly fails to read text input file on Windows/CMD line]
On Fri, Aug 14, 2009 at 3:52 PM, Peter Brooks wrote:
> No, I think it is whitespace... I'm trying to use the 'cmd >' field
> in the 'GRASS GIS Layer Manager' (the new wxPython GUI). I guess
> this is what a Windows use
#718: r.li forgets mask/illegal filename
+---
Reporter: kyngchaos | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello all and sorry for cross-posting,
this is last SoC report - bringing variogram plotting into v.krige!
After a long time searching for the lightest and cleanest
implementation, R plotting raised as the best solution. On user demand,
a R graphics w
On 14/08/09 10:43, Markus Neteler wrote:
On Fri, Aug 14, 2009 at 10:15 AM, Martin Landa wrote:
2009/8/11 Markus Neteler :
It removes vector objects (point, line, area, face etc.) from a vector
map through attribute selection in the table.
Also not sure if we need this script.
How would you d
#718: r.li forgets mask/illegal filename
+---
Reporter: kyngchaos | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
On Fri, Aug 14, 2009 at 12:16 PM, Martin Landa wrote:
> Hi,
>
> 2009/8/14 Martin Landa :
* are these extra checks needed (it's done by v.extract) [1,2]
>>>
>>> Yes, I think so: if you create a map with v.random it won't have
>>> a connected table, so better don't badly crash. Likewise with
>>>
Hi,
2009/8/6 Glynn Clements :
> The correct approach is to revert the portion of r38552 which applies
> to lib/gis/find_vect.c, lib/gis/find_file.c, and lib/gis/Makefile.
>
> lib/gis has no business calling OGR functions, or even linking against
> OGR. If it's impossible to "find" a vector without
Hi,
2009/8/14 Martin Landa :
>>> * are these extra checks needed (it's done by v.extract) [1,2]
>>
>> Yes, I think so: if you create a map with v.random it won't have
>> a connected table, so better don't badly crash. Likewise with
>> a non-existing map. I used existing msg strings (for translatio
Hi,
2009/8/14 Markus Neteler :
>> * are these extra checks needed (it's done by v.extract) [1,2]
>
> Yes, I think so: if you create a map with v.random it won't have
> a connected table, so better don't badly crash. Likewise with
> a non-existing map. I used existing msg strings (for translation).
#718: r.li forgets mask/illegal filename
+---
Reporter: kyngchaos | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
#718: r.li forgets mask/illegal filename
+---
Reporter: kyngchaos | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
#129: a fix for NVIZ site's dependency: elimination of sites lib dependency
--+-
Reporter: neteler | Owner: neteler
Type: defect | Status: assigned
Priority: major| Mileston
#718: r.li forgets mask/illegal filename
+---
Reporter: kyngchaos | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
Hi,
re. stalled bug #637,
https://trac.osgeo.org/grass/ticket/637#comment:11
I take it the wxGUI use of 'v.db.connect -g' still should explicitly
set the fs='|' and split() on that instead of space?
Also Tcl/Tk versions of same still need attention / testing /
backporting:
https://trac.osge
unanswered from trac bug #355, reproduced here to gain eyeballs.
https://trac.osgeo.org/grass/ticket/335
(just 13 remaining RC bugs for 6.4.0:
https://trac.osgeo.org/grass/report/13 )
"i.e. can we always assume DCELL|double to be the same bit depth,
and %.15g the most we'll ever be able to sq
On Fri, Aug 14, 2009 at 10:15 AM, Martin Landa wrote:
> 2009/8/11 Markus Neteler :
>> It removes vector objects (point, line, area, face etc.) from a vector
>> map through attribute selection in the table.
>
> Also not sure if we need this script.
How would you do vector removal based on attribute
Soeren wrote:
> if there are no objections against the changes and the new
> LGPL'd ccmath library?
I have no comment either way on the technical side of the library changes
beyond wondering if it will peacefully interact with the (mostly unused)
existing --with-blas --with-lapack ./configure swit
Hi,
2009/8/11 Markus Neteler :
> to be able to easily filter vector maps geometrically (i.e. remove
> vectors) I have
> written the v.db.droprow script (G6.5; needs a Python port for GRASS 7).
Done in r38716.
> It removes vector objects (point, line, area, face etc.) from a vector
> map throug
32 matches
Mail list logo
