date:20160610

[GRASS-dev] GSoC 2016 - PyQt GRASS - Report 3

2016-06-10 Thread Ondřej Pešek

Hi all!

Here is the third report of my GSoC project - PyQt based GUI of GRASS
automatically generated from XML

What did you get done this week?
* I have upgraded GUI - now it works also with the string and integer
types. (on the basic level)
* I also have made some changes - SqlQuery is now lineedit and when the
float isn't multiple, the GUI generates QDoubleSpinBox.
* The important thing is the first version of copyable/runable code. The
buttons don't work yet, but user can see it and it automatically reads the
code.
*And one elegant thing - all the widgets are now stretched upper.

What do you plan on doing next week?
* Main goal: Implement some other types/make more variable the current types
* Additional goals: Make the Run button working; recreate little bit the
code (not so many ifs)

Are you blocked on anything?
* Not yet

Have a nice weekend!
Ondrej
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #947: g.version: new flag for citation info

2016-06-10 Thread GRASS GIS

#947: g.version: new flag for citation info
--+-
  Reporter:  hamish   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  major|  Milestone:  7.2.0
 Component:  Default  |Version:  svn-trunk
Resolution:   |   Keywords:  g.version, citation
   CPU:  All  |   Platform:  All
--+-

Comment (by neteler):

 Citation text improved (Addons now mentioned); added CITING file to
 packaging in r68662.

 Backports
  * to relbranch72 in r68663 (bundle of r68657, r68658, r68659, r68662,
 with change to number 7.2),
  * to relbranch70 in r68664 (using r68663, with change to number 7.0).

--
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] #3060: Create location from command line using "r.in.gdal" and similar

2016-06-10 Thread GRASS GIS

#3060: Create location from command line using "r.in.gdal" and similar
--+-
  Reporter:  mankoff  |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  closed
  Priority:  normal   |  Milestone:  7.0.5
 Component:  Startup  |Version:  unspecified
Resolution:  worksforme   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by sbl):

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


Comment:

 See: http://grass.osgeo.org/grass70/manuals/grass7.html

 There is[[BR]]
 grass70 -c geofile

--
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] #3060: Create location from command line using "r.in.gdal" and similar

2016-06-10 Thread Blumentrath, Stefan

Already possible. See: https://grass.osgeo.org/grass70/manuals/grass7.html

Von: grass-dev [grass-dev-boun...@lists.osgeo.org] im Auftrag von GRASS GIS 
[t...@osgeo.org]
Gesendet: Freitag, 10. Juni 2016 19:40
Betreff: [GRASS-dev] [GRASS GIS] #3060: Create location from command line using 
"r.in.gdal" and similar

#3060: Create location from command line using "r.in.gdal" and similar
-+-
 Reporter:  mankoff  |  Owner:  grass-dev@…
 Type:  enhancement  | Status:  new
 Priority:  normal   |  Milestone:  7.0.5
Component:  Startup  |Version:  unspecified
 Keywords:   |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 I find that I am continually creating some new dummy location just so I
 can then create the actual location I want using {{{r.in.gdal}}}. I could
 maintain a global dummy location and use that, but it makes the code less
 portable when I share it with others. Therefore, I often do this:

 {{{
 rm -fR grass
 mkdir grass
 grass70 -c EPSG:4326 ./grass/latlon
 r.in.gdal -c input=/path/to/somefile.TIF location=foo output=tmp
 exit
 grass70 ./grass/foo/PERMANENT
 }}}

 I find it difficult to know what EPSG code I should use for somefile.TIF,
 because it reports many (see below), therefore it would be nice to create
 the location from outside of GRASS, but using GRASS. For example,

 {{{grass70 -c input=/path/to/somefile importer=r.in.gdal}}}

 {{{
 Coordinate System is:
 PROJCS["WGS 84 / UTM zone 33N",
 GEOGCS["WGS 84",
 DATUM["WGS_1984",
 SPHEROID["WGS 84",6378137,298.257223563,
 AUTHORITY["EPSG","7030"]],
 AUTHORITY["EPSG","6326"]],
 PRIMEM["Greenwich",0,
 AUTHORITY["EPSG","8901"]],
 UNIT["degree",0.0174532925199433,
 AUTHORITY["EPSG","9122"]],
 AUTHORITY["EPSG","4326"]],
 PROJECTION["Transverse_Mercator"],
 PARAMETER["latitude_of_origin",0],
 PARAMETER["central_meridian",15],
 PARAMETER["scale_factor",0.9996],
 PARAMETER["false_easting",50],
 PARAMETER["false_northing",0],
 UNIT["metre",1,
 AUTHORITY["EPSG","9001"]],
 AXIS["Easting",EAST],
 AXIS["Northing",NORTH],
 AUTHORITY["EPSG","32633"]]
 Origin = (444892.500,8690407.500)
 Pixel Size = (15.000,-15.000)
 }}}

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] GRASS 7.3 64bit SIP Enabled GRASS Error

2016-06-10 Thread Michael Barton

This is very frustrating if it is repeated for others.

The test version works fine with SIP disabled on El Capitan. But with it 
enabled, it gives the error below. It should have no links that touch system 
folders. And the error does not reference any file in a system folder. It is 
looking for a file on a path that references my machine that it was compiled 
on. But this is not a problem with SIP disabled. I could run install_tool on 
_core_.so of course. But I worry that this is not the only file with a problem, 
only the first one that stops the program.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

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















Begin forwarded message:

From: Sean Bergin >
Subject: SIP Enabled GRASS Error
Date: June 10, 2016 at 10:53:04 AM MST
To: Michael Barton >
Reply-To: >


mac:~ sbergin$ '/Applications/GRASS-7.3.app/Contents/MacOS/grass.sh'; exit

Rebuilding Addon HTML manual pages index...

Rebuilding Addon menu...

Python 2.7.10 found.

Cleaning up temporary files...

Starting GRASS GIS...

Traceback (most recent call last):

  File "/Applications/GRASS-7.3.app/Contents/MacOS/gui/wxpython/gis_set.py", 
line 31, in 

from core import globalvar

  File 
"/Applications/GRASS-7.3.app/Contents/MacOS/gui/wxpython/core/globalvar.py", 
line 96, in 

import wx

  File "/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/__init__.py", 
line 45, in 

from wx._core import *

  File "/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_core.py", 
line 4, in 

import _core_

ImportError: 
dlopen(/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_core_.so, 2): 
Library not loaded: 
/Users/cmbarton/grass_source/wxp3/usr/local/lib/libwx_osx_cocoau-3.0.0.2.0.dylib

  Referenced from: 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_core_.so

  Reason: image not found

ERROR: Error in GUI startup. See messages above (if any) and if necessary, 
please report this error to the GRASS developers.

On systems with package manager, make sure you have the right GUI package, 
probably named grass-gui, installed.

To run GRASS GIS in text mode use the -text flag.

Exiting...

logout

Saving session...

...copying shared history...

...saving history...truncating history files...

...completed.

Deleting expired sessions...10 completed.


[Process completed]

--
Sean Bergin
Ph.D. Candidate, Archaeology
Graduate Assistant
CoMSES & Mediterranean Landscape Dynamics Projects
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
sean.ber...@asu.edu



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

[GRASS-dev] [GRASS GIS] #3060: Create location from command line using "r.in.gdal" and similar

2016-06-10 Thread GRASS GIS

#3060: Create location from command line using "r.in.gdal" and similar
-+-
 Reporter:  mankoff  |  Owner:  grass-dev@…
 Type:  enhancement  | Status:  new
 Priority:  normal   |  Milestone:  7.0.5
Component:  Startup  |Version:  unspecified
 Keywords:   |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 I find that I am continually creating some new dummy location just so I
 can then create the actual location I want using {{{r.in.gdal}}}. I could
 maintain a global dummy location and use that, but it makes the code less
 portable when I share it with others. Therefore, I often do this:

 {{{
 rm -fR grass
 mkdir grass
 grass70 -c EPSG:4326 ./grass/latlon
 r.in.gdal -c input=/path/to/somefile.TIF location=foo output=tmp
 exit
 grass70 ./grass/foo/PERMANENT
 }}}

 I find it difficult to know what EPSG code I should use for somefile.TIF,
 because it reports many (see below), therefore it would be nice to create
 the location from outside of GRASS, but using GRASS. For example,

 {{{grass70 -c input=/path/to/somefile importer=r.in.gdal}}}

 {{{
 Coordinate System is:
 PROJCS["WGS 84 / UTM zone 33N",
 GEOGCS["WGS 84",
 DATUM["WGS_1984",
 SPHEROID["WGS 84",6378137,298.257223563,
 AUTHORITY["EPSG","7030"]],
 AUTHORITY["EPSG","6326"]],
 PRIMEM["Greenwich",0,
 AUTHORITY["EPSG","8901"]],
 UNIT["degree",0.0174532925199433,
 AUTHORITY["EPSG","9122"]],
 AUTHORITY["EPSG","4326"]],
 PROJECTION["Transverse_Mercator"],
 PARAMETER["latitude_of_origin",0],
 PARAMETER["central_meridian",15],
 PARAMETER["scale_factor",0.9996],
 PARAMETER["false_easting",50],
 PARAMETER["false_northing",0],
 UNIT["metre",1,
 AUTHORITY["EPSG","9001"]],
 AXIS["Easting",EAST],
 AXIS["Northing",NORTH],
 AUTHORITY["EPSG","32633"]]
 Origin = (444892.500,8690407.500)
 Pixel Size = (15.000,-15.000)
 }}}

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Online manual and compiled addons for different releases

2016-06-10 Thread Vaclav Petras

Hi,

can we please compile manual for addons for 7.2 release, so that the URLs
already work?

On a more general note, we are now in a strange situation when 7.2 URLs for
addons don't work but you can't get new versions of addons for 7.0 if I
understand r68591 correctly. There was already one break in installation of
addons when we moved to 32+64 bit on MS Windows and the =<7.0.2 versions
were not able to get addons because of change of URLs. So, this makes me
wonder when we start and stop shipping addons to MS Windows and updating
online documentation. And if we should warn users about it.

Best,
Vaclav


wingrass: addons compilation for grass70_release disabled
https://trac.osgeo.org/grass/changeset/68591

https://wingrass.fsv.cvut.cz/grass70/x86/addons/

https://grass.osgeo.org/grass70/manuals/addons/
https://grass.osgeo.org/grass72/manuals/addons/
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3059: r.external.out does not write CRS information

2016-06-10 Thread GRASS GIS

#3059: r.external.out does not write CRS information
--+
  Reporter:  sbl  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  major|  Milestone:  7.0.5
 Component:  Raster   |Version:  7.0.4
Resolution:   |   Keywords:  r.external.out
   CPU:  Unspecified  |   Platform:  Unspecified
--+
Changes (by neteler):

 * priority:  normal => major
 * component:  Default => Raster


Comment:

 I can reproduce it with the NC location:

 {{{
 # NC Location
 g.region raster=elevation -p

 g.proj -w
 PROJCS["Lambert Conformal Conic",
 GEOGCS["grs80",
 DATUM["North_American_Datum_1983",
 SPHEROID["Geodetic_Reference_System_1980",6378137,298.257222101]],
 PRIMEM["Greenwich",0],
 UNIT["degree",0.0174532925199433]],
 PROJECTION["Lambert_Conformal_Conic_2SP"],
 PARAMETER["standard_parallel_1",36.16],
 PARAMETER["standard_parallel_2",34.34],
 PARAMETER["latitude_of_origin",33.75],
 PARAMETER["central_meridian",-79],
 PARAMETER["false_easting",609601.22],
 PARAMETER["false_northing",0],
 UNIT["Meter",1]]

 mkdir -p $HOME/tmp
 r.external.out directory=$HOME/tmp extension=.tif format=GTiff
 options="COMPRESS=LZW,PREDICTOR=2"

 r.mapcalc expression="test = 1"

 gdalinfo $HOME/tmp/test.tif
 Driver: GTiff/GeoTIFF
 Files: test.tif
 Size is 1500, 1350
 Coordinate System is `'
 Origin = (63.000,228500.000)
 Pixel Size = (10.000,-10.000)
 Image Structure Metadata:
   COMPRESSION=LZW
   INTERLEAVE=BAND
 Corner Coordinates:
 ...
 }}}

 Apparently some GDAL part is not initialized completely. I see in

 https://trac.osgeo.org/grass/browser/grass/trunk/lib/raster/gdal.c#L431

 that the use of GPJ_grass_to_wkt() is commented. Maybe that part needs to
 be updated/completed?

--
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] #2940: Compiling Grass-7.0.3 under FreeBSD: tplot directory (with log)

2016-06-10 Thread GRASS GIS

#2940: Compiling Grass-7.0.3 under FreeBSD: tplot directory (with log)
--+-
  Reporter:  pieside  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.0.5
 Component:  Default  |Version:  7.0.3
Resolution:   |   Keywords:  FreeBSD
   CPU:  x86-64   |   Platform:  Other Unix
--+-

Comment (by pieside):

 I can continue compiling by editing /include/Make/Platform.make:

 {{{
 ICONVLIB = -liconv
 }}}


 But, as you said, others errors arise and I'm wondering if using the
 FreeBSD ports tree would not help us to compile Grass7 on this OS. In
 order to avoid duplicated work, I inform the GRASS community that I'm
 trying to do it. For now, I'm not pretty sure how, so I'm completely
 opened to suggestions.

 I've also opened a ticket on the FreeBSD forum:
 https://forums.freebsd.org/threads/56558/.

--
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] #3058: unexpected behavior/error message in r.diversity?

2016-06-10 Thread GRASS GIS

#3058: unexpected behavior/error message in r.diversity?
-+-
  Reporter:  veroandreo  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.2.0
 Component:  Addons  |Version:  svn-trunk
Resolution:  |   Keywords:
   CPU:  x86-64  |   Platform:  Linux
-+-

Comment (by veroandreo):

 Found another error that does not fit what manual page says. If I use
 "size=5-9" as it seems to be allowed according to
 [https://grass.osgeo.org/grass70/manuals/addons/r.diversity.html
 r.diversity] examples, I get the following error:

 {{{
 GRASS 7.3.svn (lat_long):~ > r.diversity input=my_classif prefix=diver
 size=5-9 method=simpson
 Traceback (most recent call last):
   File "/home/veroandreo/.grass7/addons/scripts/r.diversity", line 283, in
 
 sys.exit(main())
   File "/home/veroandreo/.grass7/addons/scripts/r.diversity", line 116, in
 main
 resolution = checkValues(res)
   File "/home/veroandreo/.grass7/addons/scripts/r.diversity", line 272, in
 checkValues
 reso = range(reso[0], reso[1] + 1, 2)
 TypeError: range() integer end argument expected, got float.
 }}}

 Is this an error or just that documentation is wrong or outdated?

--
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] #2369: Include map elements into GRASS workspaces

2016-06-10 Thread GRASS GIS

#2369: Include map elements into GRASS workspaces
--+--
  Reporter:  mastho   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.3.0
 Component:  wxGUI|Version:  unspecified
Resolution:   |   Keywords:  workspace, cartography, gsoc2016
   CPU:  Unspecified  |   Platform:  Unspecified
--+--
Changes (by lazaa):

 * Attachment "workspace4.diff" added.

 Save changes notofication 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] cProfile makes TypeError

2016-06-10 Thread Eva Stopková

Dear Glynn,

thank you for the answer.
It was picking another glob.py indeed (experimental one that I have
forgotten in my module folder). It works fine now.
Best regards,

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

Re: [GRASS-dev] [GRASS GIS] #3056: ]PATCH] r.patch: disable creation of support files

2016-06-10 Thread GRASS GIS

#3056: ]PATCH] r.patch: disable creation of support files
--+---
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.2.0
 Component:  Raster   |Version:  unspecified
Resolution:   |   Keywords:  r.patch categories colors
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by sbl):

 There might be a positive side effect from this patch: After patching a
 lot of CELL tiles using current r.patch in combination with
 r.external.out, resulting GeoTiffs are having interoperability issues (see
 also: #3059). When I export via r.out.gdal I get a warning message that
 Metadata exceeds 32000 bytes and cannot be written to GeoTiff?, and
 therefore will be transferred to PAM.

--
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] #3059: r.external.out does not write CRS information

2016-06-10 Thread GRASS GIS

#3059: r.external.out does not write CRS information
--+
  Reporter:  sbl  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.0.5
 Component:  Default  |Version:  7.0.4
Resolution:   |   Keywords:  r.external.out
   CPU:  Unspecified  |   Platform:  Unspecified
--+

Comment (by sbl):

 Some additional observations:
 A colleague and me are facing significant "interoperability problems" with
 GeoTiffs produced with r.external.out, which (after FTP transfer) could
 not be opened in ENVI.

 ENVI complains about broken corner coordinates and a corrupted LZW-table.

 The files are solar radiation grids (all integer) and are saved as Int32
 by r.external.out.
 They were results from a tiled processing which was merged using r.patch.
 When I export via r.out.gdal I get a warning message that Metadata exceeds
 32000 bytes and cannot be written to GeoTiff, and therefore will be
 transferred to PAM. So this is possibly related to #3056

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] GSoC 2016 - PyQt GRASS - Report 3

Re: [GRASS-dev] [GRASS GIS] #947: g.version: new flag for citation info

Re: [GRASS-dev] [GRASS GIS] #3060: Create location from command line using "r.in.gdal" and similar

Re: [GRASS-dev] [GRASS GIS] #3060: Create location from command line using "r.in.gdal" and similar

[GRASS-dev] GRASS 7.3 64bit SIP Enabled GRASS Error

[GRASS-dev] [GRASS GIS] #3060: Create location from command line using "r.in.gdal" and similar

[GRASS-dev] Online manual and compiled addons for different releases

Re: [GRASS-dev] [GRASS GIS] #3059: r.external.out does not write CRS information

Re: [GRASS-dev] [GRASS GIS] #2940: Compiling Grass-7.0.3 under FreeBSD: tplot directory (with log)

Re: [GRASS-dev] [GRASS GIS] #3058: unexpected behavior/error message in r.diversity?

Re: [GRASS-dev] [GRASS GIS] #2369: Include map elements into GRASS workspaces

Re: [GRASS-dev] cProfile makes TypeError

Re: [GRASS-dev] [GRASS GIS] #3056: ]PATCH] r.patch: disable creation of support files

Re: [GRASS-dev] [GRASS GIS] #3059: r.external.out does not write CRS information

14 matches

Site Navigation

Mail list logo

Footer information