Re: [GRASS-dev] [GRASS GIS] #2359: r.stream.distance with a large map

[GRASS GIS]

#2359: r.stream.distance with a large map
---+
 Reporter:  hcho   |   Owner:  grass-dev@…  
 Type:  defect |  Status:  new  
 Priority:  normal |   Milestone:  7.1.0
Component:  Raster | Version:  svn-trunk
 Keywords:  r.stream.distance  |Platform:  All  
  Cpu:  All|  
---+

Comment(by hcho):

 I took the liberty to change the type of output maps from FCELL to DCELL
 for a higher precision (r61206). The above code for calculating the
 longest flow path should work now.
 {{{
 r.stream.distance -o stream_rast=outlet direction=drain method=upstream
 distance=flus
 r.stream.distance -o stream_rast=outlet direction=drain method=downstream
 distance=flds
 r.mapcalc expression="flusds=flus+flds"
 eval `r.info -r flusds`
 r.mapcalc expression="lfp=if(flusds>=$max-0.1, flusds, null())"
 }}}

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] backport r60662 ? [was: Re: r.mapcalc - expression line to long]

[Glynn Clements]

Helmut Kudrnovsky wrote:

> any opinion about backporting r60662 [1] to releasebranch_7_0?

I recommend backporting.

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

Re: [GRASS-dev] [GRASS GIS] #2337: t.list hangs on newly created temporal DB

[GRASS GIS]

#2337: t.list hangs on newly created temporal DB
-+--
 Reporter:  neteler  |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  Temporal | Version:  svn-trunk
 Keywords:  t.list   |Platform:  Linux
  Cpu:  Unspecified  |  
-+--

Comment(by spareeth):

 Update:
 Looks like the issue is with the nfs system of the cluster where the
 mapset is stored. When the same mapset is copied to local machine, t.list
 works without any problem.

 Let me know of any more information required to debug this issue.

 Sajid

-- 
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] #2357: r3.info segfaults or reports incorrect values on Windows

[GRASS GIS]

#2357: r3.info segfaults or reports incorrect values on Windows
--+-
  Reporter:  annakrat |   Owner:  grass-dev@…  
  Type:  defect   |  Status:  closed   
  Priority:  normal   |   Milestone:  7.1.0
 Component:  Raster3D | Version:  svn-releasebranch70  
Resolution:  fixed|Keywords:  r3.info  
  Platform:  MSWindows 8  | Cpu:  Unspecified  
--+-
Changes (by annakrat):

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


Comment:

 Replying to [comment:2 annakrat]:
 > I removed the `l` from the function in !r3.info module to test if it
 makes difference (r61172).

 This fixed the problem. I applied it to r.info (r61189) and backported to
 releasebranch (r61190) .

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] grass71 and GDAL read

[Huidae Cho]

Jachym,

Can you try the attached configure.patch? It was missing -lgrass_raster.
Without -I/usr/include/postgresql, what errors did you get?

Huidae


On Tue, Jul 1, 2014 at 4:42 AM, Jachym Cepicky 
wrote:

> Hi Huidae,
>
> let me give you short progress report I have. I managed to configure,
> make and make install the grass-gdal plugin with the patch you
> provided in your last mail without problems:
>
> ./configure --with-gdal=/usr/local/bin/gdal-config
> --with-grass=/usr/local/grass-7.1.svn/
>
> make
> g++ -shared  grass57dataset.o -L/usr/local/grass-7.1.svn//lib
> -lgrass_gmath -lgrass_gis -lgrass_datetime -lgrass_gproj
> -lgrass_vector -lgrass_dbmibase -lgrass_dbmiclient -lgrass_dgl
> -lgrass_dig2 -lgrass_rtree -lgrass_linkm -L/usr/local/lib -lgdal  -o
> gdal_GRASS.so
> g++ -shared  ogrgrassdriver.o ogrgrassdatasource.o ogrgrasslayer.o
> -L/usr/local/grass-7.1.svn//lib -lgrass_gmath -lgrass_gis
> -lgrass_datetime -lgrass_gproj -lgrass_vector -lgrass_dbmibase
> -lgrass_dbmiclient -lgrass_dgl -lgrass_dig2 -lgrass_rtree
> -lgrass_linkm -L/usr/local/lib -lgdal  -o ogr_GRASS.so
>
> sudo make install
> install -d /usr/local/lib/gdalplugins
> cp gdal_GRASS.so /usr/local/lib/gdalplugins
> cp ogr_GRASS.so /usr/local/lib/gdalplugins
>
> testing:
>
> gdalinfo --formats|grep GRASS
>   GRASS (ro): GRASS Database Rasters (5.7+)
>   GRASSASCIIGrid (rov): GRASS ASCII Grid
>
> ogrinfo --formats|grep GRASS
>   -> "GRASS" (readonly)
>
> So it seems to be working. However, runing gdalinfo on certain raster
> file produces following error :-(
>
> gdalinfo /home/grass/grassdata/prg/interpolations/cellhd/dmt
> gdalinfo: symbol lookup error:
> /usr/local/lib/gdalplugins/gdal_GRASS.so: undefined symbol:
> Rast_get_cellhd
>
> Strange thing: vectors (ogr2ogr, ogrinfo) on GRASS vectors works perfectly
>
> I would say, that it's related to dynamic linker, thought, I have
>
> $ cat /etc/ld.so.conf.d/grass-7.1.conf
> /usr/local/grass-7.1.svn/lib/
>
> and ldconfig -p |grep grass_raster gives
>
> libgrass_raster.7.1.svn.so (libc6,x86-64) =>
> /usr/local/grass-7.1.svn/lib/libgrass_raster.7.1.svn.so
> libgrass_raster.so (libc6,x86-64) =>
> /usr/local/grass-7.1.svn/lib/libgrass_raster.so
>
> Any hint?
>
> Thank you
>
>
> 2014-06-30 10:12 GMT+02:00 Jachym Cepicky :
> > Worked, but had to add -I/usr/include/postgresql/ to CPPFLAGS
> >
> > seems to be compiled and in gdal
> >
> > thank you
> >
> > 2014-06-27 12:13 GMT+02:00 Huidae Cho :
> >> Try the attached patches. The GRASS plugin works for me.
> >>
> >> ./configure --with-autoload=/usr/lib/gdalplugins
> >> --with-grass=/your/grass/path
> >>
> >> Huidae
> >>
> >>
> >> On Fri, Jun 27, 2014 at 3:11 AM, Jachym Cepicky <
> jachym.cepi...@gmail.com>
> >> wrote:
> >>>
> >>> Hi Martin,
> >>>
> >>> ok, sorry, but I'm a bit confused from amount of patches, which are
> >>> attached to the ticket and none of them seems to be working on
> >>> gdal-grass-1.4.3.
> >>>
> >>> I'm using GRASS 7.1 btw, so I hope, that is ok in general.
> >>>
> >>> Could you point me please to patches, which should work with
> >>> http://download.osgeo.org/gdal/gdal-grass-1.4.3.tar.gz ?
> >>>
> >>> Thanks
> >>>
> >>> 2014-06-24 22:27 GMT+02:00 Martin Landa :
> >>> > Hi,
> >>> >
> >>> > 2014-06-24 22:09 GMT+02:00 Jachym Cepicky  >:
> >>> >
> >>> >> I wanted to publish some maps via MapServer, using GDAL, like the
> old
> >>> >> days. But I did not succeed to get it compiled with GRASS (at first
> >>> >> try). What is the best way you would propose to approach?
> >>> >>
> >>> >> 1 - compile gdal withnout grass
> >>> >> 2 - compile grass 7.1 with gdal support
> >>> >> 3 - compile gdal again with grass support?
> >>> >>
> >>> >> It worked some years back, but does it still apply?
> >>> >
> >>> > best is to compile GRASS driver as a plugin, anyway GRASS 7 support
> in
> >>> > GDAL is still open issue [1].
> >>> >
> >>> > Martin
> >>> >
> >>> > [1] http://trac.osgeo.org/gdal/ticket/2953
> >>> >
> >>> > --
> >>> > Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
> >>>
> >>>
> >>>
> >>> --
> >>> Jachym Cepicky
> >>> e-mail: jachym.cepicky gmail com
> >>> URL: http://les-ejk.cz
> >>> GPG: http://les-ejk.cz/pgp/JachymCepicky.pgp
> >>> ___
> >>> grass-dev mailing list
> >>> grass-dev@lists.osgeo.org
> >>> http://lists.osgeo.org/mailman/listinfo/grass-dev
> >>
> >>
> >
> >
> >
> > --
> > Jachym Cepicky
> > e-mail: jachym.cepicky gmail com
> > URL: http://les-ejk.cz
> > GPG: http://les-ejk.cz/pgp/JachymCepicky.pgp
>
>
>
> --
> Jachym Cepicky
> e-mail: jachym.cepicky gmail com
> URL: http://les-ejk.cz
> GPG: http://les-ejk.cz/pgp/JachymCepicky.pgp
>


configure.patch
Description: Binary data


configure.in.patch
Description: Binary data
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #1860: v.extract should support 'group by' sql statement

[GRASS GIS]

#1860: v.extract should support 'group by' sql statement
---+
 Reporter:  lucadelu   |   Owner:  grass-dev@…  
 Type:  enhancement|  Status:  new  
 Priority:  normal |   Milestone:  7.0.0
Component:  Vector | Version:  svn-trunk
 Keywords:  v.extract, v.hull  |Platform:  All  
  Cpu:  All|  
---+
Changes (by lucadelu):

  * keywords:  v.extract => v.extract, v.hull


Comment:

 Also v.hull should support SQL statement 'group by'.

 Probably also other modules could take advantage of this option

-- 
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 6.4.4 r.li modules

[Hamish]

Hamish wrote:
> > yes, the old r.li.* daemon/worker system required unix sockets, and
> > so would only work in the cygwin build. We never figured out how to
> > properly support those natively on MS Windows.

Martin:
> r.li modules enabled in grass64 in r61153. Please test next build of
> grass64-dev (no.13).

Thanks. I am unable to test for the next weeks, but would appreciate if
someone else could try it.


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

Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script

[Helmut Kudrnovsky]

Anna Petrášová wrote
> On Sun, Jul 6, 2014 at 3:59 AM, Helmut Kudrnovsky <

> hellik@

> > wrote:
> 
>> "C:\OSGeo4W\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py", li
>> ne 58, in __init__
>> raise OSError
>> OSError
>>
>>
>>
> 
> It's because gui doesn't reflect recent changes by Martin.  I temporarily
> fixed it in r61171 but I don't really understand current status, is it
> still work in progress? By the way the Popen class should be changed
> according two Glynn's suggestions to let Popen throw the error.
> 
> Anna

tested with:

System Info 
GRASS Version: 7.1.svn  
GRASS SVN Revision: 61180   
Erstellungsdatum: 2014-07-08
Build Platform: i686-pc-mingw32 
GDAL/OGR: 1.11.0
PROJ.4: 4.8.0   
GEOS: 3.4.2 
SQLite: 3.7.17  
Python: 2.7.4   
wxPython: 2.8.12.1  
Platform: Windows-7-6.1.7601-SP1 (OSGeo4W) 

the GUI starts now, thanks.



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Re-GRASS-SVN-r60679-grass-trunk-lib-python-script-tp5143645p5150047.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] Unify python GRASS defined exception in one common file

[Pietro]

Hi Vaclav,

On Mon, Jul 7, 2014 at 2:57 PM, Vaclav Petras  wrote:
> On Thu, Jul 3, 2014 at 11:35 AM, Pietro  wrote:
>> What do you think if we unify all our custom exceptions in one common
>> file? [snip]
>> Looking into the code I found the following custom exceptions:
>>
>> {{{
>> $ grep --color=auto
>> --exclude-dir={.svn,.git,.OBJ,locale,dist.x86_64-unknown-linux-gnu}
>> -IrnE "class\s\w+\(Exception\)\:"
>> lib/python/pygrass/messages/__init__.py:21:class FatalError(Exception):
>> lib/python/pygrass/errors.py:11:class AbstractError(Exception):
>> lib/python/pygrass/errors.py:19:class ParameterError(Exception):
>> lib/python/pygrass/errors.py:23:class FlagError(Exception):
>> lib/python/pydispatch/errors.py:4:class DispatcherError(Exception):
>> lib/python/temporal/abstract_dataset.py:26:class
>> ImplementationError(Exception):
>> lib/python/temporal/temporal_algebra.py:655:class FatalError(Exception):
>> lib/python/ctypes/ctypesgencore/parser/lex.py:46:class
>> LexError(Exception):
>> lib/python/ctypes/ctypesgencore/parser/yacc.py:87:class
>> YaccError(Exception):   pass
>> lib/python/script/core.py:50:class ScriptError(Exception):
>> gui/wxpython/core/gcmd.py:156:class GException(Exception):
>> gui/wxpython/wxgui.py:86:class Usage(Exception):
>> }}}
>>

> However, some of them should stay where they are. [snip]

ok, so I'm going to move to grass.exceptions the following definitions:

- lib/python/pygrass/messages/__init__.py:21:class FatalError(Exception):
- lib/python/pygrass/errors.py:19:class ParameterError(Exception):
- lib/python/pygrass/errors.py:23:class FlagError(Exception):
- lib/python/temporal/abstract_dataset.py:26:class
ImplementationError(Exception):
- lib/python/temporal/temporal_algebra.py:655:class FatalError(Exception):
- lib/python/script/core.py:50:class ScriptError(Exception):
- gui/wxpython/wxgui.py:86:class Usage(Exception):

so these exceptions will stay where they are:

- lib/python/pydispatch/errors.py:4:class DispatcherError(Exception):
- lib/python/ctypes/ctypesgencore/parser/lex.py:46:class LexError(Exception):
- lib/python/ctypes/ctypesgencore/parser/yacc.py:87:class YaccError(Exception):
- gui/wxpython/core/gcmd.py:156:class GException(Exception):


Any concern?

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