Re: [GRASS-dev] SESSION_MANAGER environment variable not defined

[Andy Wickert]

Thanks Markus. Ubuntu 14.10. I agree that the core of this is not a GRASS
problem, and yet it appears only when starting GRASS GIS. On opening a
location, the GUI shows up, but no dialog windows (e.g., add layer) appear.

Andy

---
telephone email
On Jan 12, 2015 1:44 PM, "Markus Neteler"  wrote:

> On Mon, Jan 12, 2015 at 12:28 PM, Andy Wickert 
> wrote:
> > Dear GRASS-dev,
> >
> > I have started seeing this error:
> >
> > Error - Debug: Failed to connect to session manager: SESSION_MANAGER
> > environment variable not defined
> >
> > when starting GRASS GIS that I have compiled myself (both 6.4.x and
> > 7.1-svn), and do not know why. I am running Ubuntu 14.10. Never seen
> > anything like this before. Suggestions?
>
> Which operating system do you use? It doesn't seem to come directly
> from GRASS GIS.
>
> I found (random links)
> http://ubuntuforums.org/showthread.php?t=1874423
> http://trac.wxwidgets.org/ticket/16024
>
> Markus
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Unifing naming of 3D rasters

[Vaclav Petras]

On Sun, Jan 11, 2015 at 3:13 PM, Markus Neteler  wrote:

> > There are few things missing. For example, keyword link is dead because
> it
> > goes to "raster3d.html" but the family page is "raster3D.html". All
> > occurrences of "raster3D", including the one in PyGRASS, should be
> probably
> > replaced by "raster3d" or another appropriate form (3D raster or
> raster_3d).
>
> I suppose it should all become "raster_3d" for consistency.


I fixed the keyword link and unified the titles with "3D raster" in r64109.
I used "raster3d" because this is the keyword used in the modules. If there
is a will to change it to "raster_3d" it should be enough just to pick
proper places from r64109 for the build part, titles are now handled
separately, so this should be easier too. I fixed only HTML, hopefully man
but not reStructuredText.

I would change PyGRASS package/module name to "raster3d" the underscores
are allowed for modules, if it improves readability (not sure if our case
qualifies), and discouraged for packages.

http://trac.osgeo.org/grass/changeset/64109
https://www.python.org/dev/peps/pep-0008/#package-and-module-names
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2536: r.slope.aspect converts to meters

[GRASS GIS]

#2536: r.slope.aspect converts to meters
---+
 Reporter:  annakrat   |   Owner:  grass-dev@…  
 Type:  defect |  Status:  new  
 Priority:  critical   |   Milestone:  7.0.0
Component:  Projections/Datums | Version:  svn-trunk
 Keywords:  r.slope.aspect, units  |Platform:  All  
  Cpu:  Unspecified|  
---+

Comment(by annakrat):

 If no objections, I will commit it tomorrow.

-- 
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] #2532: TypeError: environment can only contain string when launching script on Windows

[GRASS GIS]

#2532: TypeError: environment can only contain string when launching script on
Windows
-+--
 Reporter:  annakrat |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  Default  | Version:  svn-trunk
 Keywords:  encoding |Platform:  MSWindows 8  
  Cpu:  Unspecified  |  
-+--

Comment(by annakrat):

 Replying to [comment:7 glynn]:
 > Replying to [comment:5 annakrat]:
 > > However, I failed to run the script when the name contained non-ascii
 characters present in cp1252 (á). I don't get any error, but in gui
 console I get:
 > >
 > {{{
 > Launching script 'C:\Users\akratoc\Desktop\test_workshopá.py'...
 > }}}
 > Is the "..." literal? I.e. does the GUI omit the arguments, or does it
 include details which have been omitted from the ticket?

 That comes from
 
[http://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/lmgr/frame.py#L906
 here], there are no details, it's ran without any arguments.
 >
 > >
 > {{{
 > ERROR: Required parameter  not set:
 > }}}
 >
 > Can you get any more debug output?
 Will try.

-- 
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] #2532: TypeError: environment can only contain string when launching script on Windows

[GRASS GIS]

#2532: TypeError: environment can only contain string when launching script on
Windows
-+--
 Reporter:  annakrat |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  Default  | Version:  svn-trunk
 Keywords:  encoding |Platform:  MSWindows 8  
  Cpu:  Unspecified  |  
-+--

Comment(by glynn):

 Replying to [comment:5 annakrat]:
 > However, I failed to run the script when the name contained non-ascii
 characters present in cp1252 (á). I don't get any error, but in gui
 console I get:
 >
 {{{
 Launching script 'C:\Users\akratoc\Desktop\test_workshopá.py'...
 }}}
 Is the "..." literal? I.e. does the GUI omit the arguments, or does it
 include details which have been omitted from the ticket?

 >
 {{{
 ERROR: Required parameter  not set:
 }}}

 Can you get any more debug output?

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] installing metadata addon fails

[Glynn Clements]

Moritz Lennert wrote:

> So I guess #2480 and #2534 have to be treated individually on a 
> case-by-case basis ?

What exactly is the issue there?

If building them manually works, that suggests a problem with
g.extension.

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

Re: [GRASS-dev] [GRASS-PSC] RFC4 discussion call

[Markus Neteler]

On Tue, Jan 13, 2015 at 12:02 AM, Martin Landa  wrote:
> Dear PSC,
>
> 2015-01-08 4:02 GMT+01:00 Helena Mitasova :
>
>> I made small language edits which did not change the meaning of the document 
>> and I agree with the document.
>
> thanks a lot! BTW, is there any open issue? If not, we could probably
> move on towards voting?

Yes I think so.
Following our new voting rules, after having called for vote
"Proposals are available for review for at least seven calendar days
before a vote can be closed" [1]

So, please take a last look at [2] so that we can eventually start
with the voting procedure.

Markus

[1] http://trac.osgeo.org/grass/wiki/RFC/3_PSCVotingProcedures
[2] http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure (draft)
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-PSC] RFC4 discussion call

[Martin Landa]

Dear PSC,

2015-01-08 4:02 GMT+01:00 Helena Mitasova :

> I made small language edits which did not change the meaning of the document 
> and I agree with the document.

thanks a lot! BTW, is there any open issue? If not, we could probably
move on towards voting?

Martin

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.eu/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2440: remove unused elements from g.list/g.remove

[GRASS GIS]

#2440: remove unused elements from g.list/g.remove
---+
  Reporter:  annakrat  |   Owner:  grass-dev@…  
  Type:  task  |  Status:  closed   
  Priority:  blocker   |   Milestone:  7.0.0
 Component:  LibGIS| Version:  svn-releasebranch70  
Resolution:  fixed |Keywords:  elements, g.remove   
  Platform:  All   | Cpu:  Unspecified  
---+
Changes (by annakrat):

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


Comment:

 Thanks! I think we can close it. The actual code for handling different
 vector formats is still there, but from what I remember when I was looking
 at it, it would be quite time consuming to clean it up.

-- 
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] #2440: remove unused elements from g.list/g.remove

[GRASS GIS]

#2440: remove unused elements from g.list/g.remove
+---
 Reporter:  annakrat|   Owner:  grass-dev@…  
 Type:  task|  Status:  new  
 Priority:  blocker |   Milestone:  7.0.0
Component:  LibGIS  | Version:  svn-releasebranch70  
 Keywords:  elements, g.remove  |Platform:  All  
  Cpu:  Unspecified |  
+---

Comment(by martinl):

 Currently the element list looks like:

 {{{
type   Data type(s)
   options: raster,raster_3d,vector,label,region,group,all
raster: raster map(s)
raster_3d: 3D raster map(s)
vector: vector map(s)
label: paint label file(s)
region: region definition(s)
group: imagery group(s)
all: all types
 }}}

 Is there any open issue?

-- 
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] #2440: remove unused elements from g.list/g.remove

[GRASS GIS]

#2440: remove unused elements from g.list/g.remove
+---
 Reporter:  annakrat|   Owner:  grass-dev@…  
 Type:  task|  Status:  new  
 Priority:  blocker |   Milestone:  7.0.0
Component:  LibGIS  | Version:  svn-releasebranch70  
 Keywords:  elements, g.remove  |Platform:  All  
  Cpu:  Unspecified |  
+---

Comment(by martinl):

 Replying to [comment:14 martinl]:

 > > I removed `ascii_vector` in trunk as r64004. Any objection to backport
 to `relbr70`?
 >
 > r64004:64005

 done in r64104

-- 
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] #2532: TypeError: environment can only contain string when launching script on Windows

[GRASS GIS]

#2532: TypeError: environment can only contain string when launching script on
Windows
-+--
 Reporter:  annakrat |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  Default  | Version:  svn-trunk
 Keywords:  encoding |Platform:  MSWindows 8  
  Cpu:  Unspecified  |  
-+--
Changes (by annakrat):

  * priority:  major => normal


Comment:

 I backported r63997, r63998 in r64102. Now it's working at least with
 ascii characters on the path.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] installing metadata addon fails

[Moritz Lennert]

On 10/01/15 22:28, Glynn Clements wrote:


Moritz Lennert wrote:


2015-01-08 16:37 GMT+01:00 Paulo van Breugel :

The installation of the metadata addon on GRASS 7 (trunk) fails, with the
message below. Any ideas?


I have fixed installation in r63999-64001.


Is there some documentation about how to write Makefiles for addons that
use several .py files ? Similar issues have come up with different
addons (cf #2480 and #2534) and it shouldn't be up to you to correct all
these issues. Maybe some clear doc could help ?


The "documentation" for writing Makefiles boils down to: try to find
something similar in the main GRASS tree and use its Makefile as a
reference; if there isn't one, or if that doesn't work, ask on the
developers' list.

Writing documentation for this will result in either wasted effort
(from describing situations which never actually happen) or inadequate
documentation (from failing to describe situations which actually
happen) or (most likely) both.

A couple of points about wx.metadata specifically:

1. Using "parsubdirs" won't work as, because mdlib (presumably) needs
to be built before any of the modules.

2. Files should not be installed using "cp"; use $(INSTALL) for
anything which should be installed with execute permission or
$(INSTALL_DATA) for anything without it.

3. Directories shouldn't be copied with "cp -r". Rather, the
individual destination files should be listed as pre-requisites, so
that "building" the target "builds" the destination files (typically
via pattern rules).

wx.metadata/Makefile should probably include "templates" and "config"
in $(SUBDIRS). These would have their own Makefiles; e.g. for
templates/Makefile, something like:

include $(MODULE_TOPDIR)/include/Make/Other.make

DSTDIR = $(ETC)/mdlib/templates

SRCFILES := $(wildcard *.xml)
DSTFILES := $(patsubst %.xml,$(DSTDIR)/%.xml,$(SRCFILES))

default: $(DSTFILES)

$(DSTDIR)/%.xml: %.xml:
$(INSTALL_DATA) $< $@

This should allow wx.metadata/Makefile to be a simple "directory"
Makefile (i.e. set SUBDIRS, include Dir.make, "default: subdirs").



So I guess #2480 and #2534 have to be treated individually on a 
case-by-case basis ?


Moritz

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

Re: [GRASS-dev] [GRASS GIS] #2539: v.in.ogr: error importing shapefiles: ValueError : too many values to unpack

[GRASS GIS]

#2539: v.in.ogr: error importing shapefiles: ValueError  :  too many values to
unpack
+---
 Reporter:  richardc|   Owner:  grass-dev@… 
 
 Type:  defect  |  Status:  new 
 
 Priority:  blocker |   Milestone:  7.0.0   
 
Component:  wxGUI   | Version:  svn-releasebranch70 
 
 Keywords:  wxgui vector import wizard  |Platform:  Linux   
 
  Cpu:  x86-32  |  
+---

Comment(by mlennert):

 I'm really losing the little that is left of my hair over this... ;-)

 I did a completely fresh checkout of relbr70 this morning and could
 confirm the issue. Now I did the same and the issue seems to have gone
 away. IIUC, the issue was fixed with r64041, changing


 {{{
 layerName, featureType, projection = map(lambda x: x.strip(),
 line.split(','))
 }}}

 to


 {{{
 layerName, featureType, projection, geometryColumn = map(lambda x:
 x.strip(), line.split(','))
 }}}

 in gui/wxpython/gui_core/gselect.py, thus solving the issue of only three
 variables, but four values.

 I don't understand why I still saw this error this morning, though.

 I'll check out, recompile and test tomorrow on other machines running with
 gdal 1.10. I'll keep it open until then.

 P.S. Could it be that certain gui files are not updated with 'make
 distclean; svn up; configure; make' ? I shouldn't have to do fresh
 checkouts everytime...

-- 
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] #2537: v.external wxgui wizard: ValueError : need more than 3 values to unpack

[GRASS GIS]

#2537: v.external wxgui wizard: ValueError : need more than 3 values to unpack
---+
  Reporter:  mlennert  |   Owner:  martinl 
  Type:  defect|  Status:  closed  
  Priority:  normal|   Milestone:  7.0.0   
 Component:  wxGUI | Version:  svn-trunk   
Resolution:  fixed |Keywords:  v.external postresql
  Platform:  Linux | Cpu:  Unspecified 
---+
Changes (by martinl):

  * status:  assigned => closed
  * 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] #2537: v.external wxgui wizard: ValueError : need more than 3 values to unpack

[GRASS GIS]

#2537: v.external wxgui wizard: ValueError : need more than 3 values to unpack
--+-
 Reporter:  mlennert  |   Owner:  martinl  
 Type:  defect|  Status:  assigned 
 Priority:  normal|   Milestone:  7.0.0
Component:  wxGUI | Version:  svn-trunk
 Keywords:  v.external postresql  |Platform:  Linux
  Cpu:  Unspecified   |  
--+-

Comment(by mlennert):

 Replying to [comment:8 martinl]:
 > I fixed v.external in r64098 and backported fix to relbr70 in r64099.
 Testing welcome before closing this ticket.

 Works for me now in trunk and relbr70. Thanks !

 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] [GRASS GIS] #2539: v.in.ogr: error importing shapefiles: ValueError : too many values to unpack

[GRASS GIS]

#2539: v.in.ogr: error importing shapefiles: ValueError  :  too many values to
unpack
+---
 Reporter:  richardc|   Owner:  grass-dev@… 
 
 Type:  defect  |  Status:  new 
 
 Priority:  blocker |   Milestone:  7.0.0   
 
Component:  wxGUI   | Version:  svn-releasebranch70 
 
 Keywords:  wxgui vector import wizard  |Platform:  Linux   
 
  Cpu:  x86-32  |  
+---

Comment(by martinl):

 Replying to [comment:4 mlennert]:

 > However, this would not explain the problem for RichardC as he seems to
 be working with gdal 1.11...

 I have tested GRASS with GDAL 1.11, no problem.

-- 
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] #2539: v.in.ogr: error importing shapefiles: ValueError : too many values to unpack

[GRASS GIS]

#2539: v.in.ogr: error importing shapefiles: ValueError  :  too many values to
unpack
+---
 Reporter:  richardc|   Owner:  grass-dev@… 
 
 Type:  defect  |  Status:  new 
 
 Priority:  blocker |   Milestone:  7.0.0   
 
Component:  wxGUI   | Version:  svn-releasebranch70 
 
 Keywords:  wxgui vector import wizard  |Platform:  Linux   
 
  Cpu:  x86-32  |  
+---

Comment(by martinl):

 Replying to [comment:7 mlennert]:

 > The "ValueError: too many values to unpack" error when trying to use the
 vector import wizard to import a shapefile. This is a different bug (but
 probably of similar origin) than #2537.

 As I already wrote, I cannot reproduce this bug. Are you sure that you
 have a fresh installation?

-- 
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] #2539: v.in.ogr: error importing shapefiles: ValueError : too many values to unpack

[GRASS GIS]

#2539: v.in.ogr: error importing shapefiles: ValueError  :  too many values to
unpack
+---
 Reporter:  richardc|   Owner:  grass-dev@… 
 
 Type:  defect  |  Status:  new 
 
 Priority:  blocker |   Milestone:  7.0.0   
 
Component:  wxGUI   | Version:  svn-releasebranch70 
 
 Keywords:  wxgui vector import wizard  |Platform:  Linux   
 
  Cpu:  x86-32  |  
+---

Comment(by mlennert):

 Replying to [comment:6 martinl]:
 > Replying to [comment:4 mlennert]:
 > > should the last comma really be there ? Erasing it away seems to solve
 the problem for me.
 >
 > sorry, what kind of problems?

 The "ValueError: too many values to unpack" error when trying to use the
 vector import wizard to import a shapefile. This is a different bug (but
 probably of similar origin) than #2537.

-- 
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] #2539: v.in.ogr: error importing shapefiles: ValueError : too many values to unpack

[GRASS GIS]

#2539: v.in.ogr: error importing shapefiles: ValueError  :  too many values to
unpack
+---
 Reporter:  richardc|   Owner:  grass-dev@… 
 
 Type:  defect  |  Status:  new 
 
 Priority:  blocker |   Milestone:  7.0.0   
 
Component:  wxGUI   | Version:  svn-releasebranch70 
 
 Keywords:  wxgui vector import wizard  |Platform:  Linux   
 
  Cpu:  x86-32  |  
+---

Comment(by martinl):

 Replying to [comment:4 mlennert]:
 > should the last comma really be there ? Erasing it away seems to solve
 the problem for me.

 sorry, what kind of problems?

-- 
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] #2539: v.in.ogr: error importing shapefiles: ValueError : too many values to unpack

[GRASS GIS]

#2539: v.in.ogr: error importing shapefiles: ValueError  :  too many values to
unpack
+---
 Reporter:  richardc|   Owner:  grass-dev@… 
 
 Type:  defect  |  Status:  new 
 
 Priority:  blocker |   Milestone:  7.0.0   
 
Component:  wxGUI   | Version:  svn-releasebranch70 
 
 Keywords:  wxgui vector import wizard  |Platform:  Linux   
 
  Cpu:  x86-32  |  
+---

Comment(by martinl):

 Replying to [comment:4 mlennert]:
 > Replying to [comment:3 martinl]:
 > > I cannot reproduce this bug. Please can you check it again with the
 fresh installation?
 >
 > I have trouble finding a clear logic in all this as sometimes it seems
 to work and sometimes not.

 I updated `v.external` to report also geometry columns, see (1). The bug
 was related to PostgreSQL format for which `v.external` is not using GDAL
 library by default, but it's own implementation. Now it should be fixed.

 (1) http://trac.osgeo.org/gdal/wiki/rfc41_multiple_geometry_fields

-- 
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] #2539: v.in.ogr: error importing shapefiles: ValueError : too many values to unpack

[GRASS GIS]

#2539: v.in.ogr: error importing shapefiles: ValueError  :  too many values to
unpack
+---
 Reporter:  richardc|   Owner:  grass-dev@… 
 
 Type:  defect  |  Status:  new 
 
 Priority:  blocker |   Milestone:  7.0.0   
 
Component:  wxGUI   | Version:  svn-releasebranch70 
 
 Keywords:  wxgui vector import wizard  |Platform:  Linux   
 
  Cpu:  x86-32  |  
+---

Comment(by mlennert):

 Replying to [comment:3 martinl]:
 > I cannot reproduce this bug. Please can you check it again with the
 fresh installation?

 I have trouble finding a clear logic in all this as sometimes it seems to
 work and sometimes not. But I think I found a candidate of what might
 explain it
 [http://trac.osgeo.org/grass/browser/grass/trunk/vector/v.external/list.c#L326
 1], but only with gdal < 1.11 :


 {{{
 312 #if GDAL_VERSION_NUM >= 111
 313 for (igeom = 0; igeom <
 OGR_FD_GetGeomFieldCount(Ogr_featuredefn); igeom++) {
 314 Ogr_geomdefn =
 OGR_FD_GetGeomFieldDefn(Ogr_featuredefn, igeom);
 315 if (!Ogr_geomdefn) {
 316 G_warning(_("Invalid geometry column %d"),
 igeom);
 317 continue;
 318 }
 319
 320 Ogr_geom_type =
 OGR_GFld_GetType(Ogr_geomdefn);
 321 fprintf(fd, "%s,%s,%d,%s\n", layer_name,
 322
 feature_type(OGRGeometryTypeToName(Ogr_geom_type)),
 323 proj_same,
 OGR_GFld_GetNameRef(Ogr_geomdefn));
 324 }
 325 #else
 326 fprintf(fd, "%s,%s,%d,\n", layer_name,
 327
 feature_type(OGRGeometryTypeToName(Ogr_geom_type)),
 328 proj_same);
 329 #endif
 }}}


 Line 326 reads:

 {{{
 fprintf(fd, "%s,%s,%d,\n"
 }}}

 should the last comma really be there ? Erasing it away seems to solve the
 problem for me.

 However, this would not explain the problem for RichardC as he seems to be
 working with gdal 1.11...

 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] [GRASS GIS] #2539: v.in.ogr: error importing shapefiles: ValueError : too many values to unpack

[GRASS GIS]

#2539: v.in.ogr: error importing shapefiles: ValueError  :  too many values to
unpack
+---
 Reporter:  richardc|   Owner:  grass-dev@… 
 
 Type:  defect  |  Status:  new 
 
 Priority:  blocker |   Milestone:  7.0.0   
 
Component:  wxGUI   | Version:  svn-releasebranch70 
 
 Keywords:  wxgui vector import wizard  |Platform:  Linux   
 
  Cpu:  x86-32  |  
+---

Comment(by martinl):

 I cannot reproduce this bug. Please can you check it again with the fresh
 installation?

-- 
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] #2537: v.external wxgui wizard: ValueError : need more than 3 values to unpack

[GRASS GIS]

#2537: v.external wxgui wizard: ValueError : need more than 3 values to unpack
--+-
 Reporter:  mlennert  |   Owner:  martinl  
 Type:  defect|  Status:  assigned 
 Priority:  normal|   Milestone:  7.0.0
Component:  wxGUI | Version:  svn-trunk
 Keywords:  v.external postresql  |Platform:  Linux
  Cpu:  Unspecified   |  
--+-

Comment(by martinl):

 I fixed v.external in r64098 and backported fix to relbr70 in r64099.
 Testing welcome before closing this ticket.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1

[Markus Metz]

On Mon, Jan 12, 2015 at 1:38 PM, Markus Neteler  wrote:
> On Mon, Jan 12, 2015 at 10:02 AM, Markus Metz
>  wrote:
>> On Sat, Jan 10, 2015 at 11:50 AM, Markus Neteler  wrote:
> ...
>>>  * checks for Vect_open_* return value to avoid potential segmentation
>>> fault: r60054 <<-- wasn't the idea to avoid these ugly tests in G7?
>>
>> The Vect_open_* return the open level when opening existing maps, not
>> just success or failure. Some modules, most importantly v.info, try to
>> open a map first with topology, if that fails, without topology.
>> Therefore it is up to the modules to decide if the return code is ok
>> or not.
>
> ok, backported in r64075.
> Also backported v.to.rast: (replace custom cell type with raster cell
> type; use size_t) and a few other things.
>
> Actual state:
>
> http://trac.osgeo.org/grass/wiki/Grass7Planning
> To be clarified:
> - v.distance: geodesic support

backported in r64094,5

> - v.kernel: Vect_net_shortest_path_coor2() usage

The API changed in G 7.1 because of new turntable support in network analysis.

> - v.out.ascii: return test in vector/v.out.ascii/main.c
backported in r64096

> - v.select: various differences
code optimization, no bug fix

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

Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation

[GRASS GIS]

#2409: last call for options keys consolidation
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  task  |  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  Default   | Version:  unspecified  
 Keywords:  standardized options  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-

Comment(by neteler):

 Replying to [comment:183 neteler]:
 >  * r.param.scale: param -> method?
 >  * r.walk; percent_memory -> memory?

 Done in r64088 + r64089.

 > {{{
 > v.lidar.correction
 >sce   Interpolation spline step value in east direction
 >  default: 25
 >scn   Interpolation spline step value in north direction
 >  default: 25
 > --> ew_step/ns_step (as in v.surf.bspline)
 >
 > v.lidar.edgedetection
 >see   Interpolation spline step value in east direction
 >  default: 4
 >sen   Interpolation spline step value in north direction
 >  default: 4
 > --> ew_step/ns_step (as in v.surf.bspline)
 >
 > No idea if the default values should be the same?
 > }}}

 Parameters renamed in r64083/r64085 + r64084/r64086.
 The default values I have still left as before.

 TODO: r.mapcalculator, r.reclass.area entry in lib/gis/renamed_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] element name labels --> label?

[Markus Neteler]

On Sat, Jan 10, 2015 at 1:19 PM, Markus Neteler  wrote:
> Hi,
>
> can we rename for consistency "labels" to "label"?
> The element name uses the plural form.
>
>raster: raster map(s)
>raster_3d: 3D raster map(s)
>vector: vector map(s)
>labels: paint label file(s)  <<--- why s?
>region: region definition(s)
>group: imagery group(s)
>
> In C, there is G_ELEMENT_LABEL (not G_ELEMENT_LABELS) used in include/gis.h.
>
> If no objections, I'll change that and also sync here:
> ./lib/python/pygrass/gis/__init__.py: 'labels': 
> libgis.G_ELEMENT_LABEL,

Done in trunk and relbranch7.

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

[GRASS-dev] [GRASS GIS] #2545: i.atcorr RapidEye band1

[GRASS GIS]

#2545: i.atcorr RapidEye band1
-+--
 Reporter:  chrisraa |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  6.4.5
Component:  Imagery  | Version:  unspecified  
 Keywords:  i.atcorr |Platform:  MSWindows 7  
  Cpu:  Unspecified  |  
-+--
 Dear grass gis team,
 actually I am working with several RapidEye (product Type L3A)
 acquisitions, in order to pre-process them for classification. It occurred
 to me that in some cases i.atcorr creates a results for the first band
 (blue), which seems to be “biased”. I applied i.atcorr on different
 machines and used different versions of Grass, but the issue is
 persistent.

 Grass versions I tried on a Windows7 Professional, 64-bit system:
 6.4.4, 7.0.0beta4 and 7.1svn

 Input text file values I used:

 13

 5 25 12.8 52.09413 -10.22328

 2

 2

 0

 0.161

 -0.253824

 -1000

 88

 For the input imagery and its range a used the min and max values of the
 radiance image. As input altitude raster map a 5m DEM was used and for
 rescale output the range 0,1.

 Please let me know if you need further information!
 Many thanks in advance!!
 Christoph

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #2544: v.surf.bspline fails when the difference between ew_step and ns_step increases .

[GRASS GIS]

#2544: v.surf.bspline fails when the difference between ew_step and ns_step
increases .
+---
 Reporter:  martinyt|   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  normal  |   Milestone:  7.0.0
Component:  Vector  | Version:  unspecified  
 Keywords:  v.surf.bspline  |Platform:  Linux
  Cpu:  OSX/Intel   |  
+---
 First I run:

 GRASS 7.0.0 (nc_basic_spm_grass7):~/> v.surf.bspline input=elev_points
 raster_output=test_int  ew_step=100 ns_step=1000 column=value --o
 Reading values from attribute table...
 Initializing output...
  100%
 Processing subregion 1 of 6...
  100%
 Processing subregion 2 of 6...
  100%
 v.surf.bspline complete.

 No problem, but when running:
 GRASS 7.0.0 (nc_basic_spm_grass7):> v.surf.bspline input=elev_points
 raster_output=test_int  ew_step=90 ns_step=1000 column=value --o
 Reading values from attribute table...
 Initializing output...
  100%
  100%
  100%
  100%
  100%
  100%
  100%
 .
 .

 An does not seem to finish. It happen when working on my own data, but I
 have no used the North Carolina dataset to reproduce the effect.

-- 
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] #2539: v.in.ogr: error importing shapefiles: ValueError : too many values to unpack

[GRASS GIS]

#2539: v.in.ogr: error importing shapefiles: ValueError  :  too many values to
unpack
+---
 Reporter:  richardc|   Owner:  grass-dev@… 
 
 Type:  defect  |  Status:  new 
 
 Priority:  blocker |   Milestone:  7.0.0   
 
Component:  wxGUI   | Version:  svn-releasebranch70 
 
 Keywords:  wxgui vector import wizard  |Platform:  Linux   
 
  Cpu:  x86-32  |  
+---

Comment(by hellik):

 Replying to [comment:1 mlennert]:
 > I can confirm this error on a freshly checkouted and compiled
 grass70release tree.
 >
 > Bumping this up to blocker as this is fundamental functionality of the
 GUI.

 tested and ''not'' confirmed by

 {{{
 System Info
 GRASS Version: 7.1.svn
 GRASS SVN Revision: 64069
 Erstellungsdatum: 2015-01-12
 Build Platform: i686-pc-mingw32
 GDAL/OGR: 1.11.1
 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)
 }}}

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] SESSION_MANAGER environment variable not defined

[Markus Neteler]

On Mon, Jan 12, 2015 at 12:28 PM, Andy Wickert  wrote:
> Dear GRASS-dev,
>
> I have started seeing this error:
>
> Error - Debug: Failed to connect to session manager: SESSION_MANAGER
> environment variable not defined
>
> when starting GRASS GIS that I have compiled myself (both 6.4.x and
> 7.1-svn), and do not know why. I am running Ubuntu 14.10. Never seen
> anything like this before. Suggestions?

Which operating system do you use? It doesn't seem to come directly
from GRASS GIS.

I found (random links)
http://ubuntuforums.org/showthread.php?t=1874423
http://trac.wxwidgets.org/ticket/16024

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

Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1

[Markus Neteler]

On Mon, Jan 12, 2015 at 10:02 AM, Markus Metz
 wrote:
> On Sat, Jan 10, 2015 at 11:50 AM, Markus Neteler  wrote:
...
>>  * checks for Vect_open_* return value to avoid potential segmentation
>> fault: r60054 <<-- wasn't the idea to avoid these ugly tests in G7?
>
> The Vect_open_* return the open level when opening existing maps, not
> just success or failure. Some modules, most importantly v.info, try to
> open a map first with topology, if that fails, without topology.
> Therefore it is up to the modules to decide if the return code is ok
> or not.

ok, backported in r64075.
Also backported v.to.rast: (replace custom cell type with raster cell
type; use size_t) and a few other things.

Actual state:

http://trac.osgeo.org/grass/wiki/Grass7Planning
To be clarified:
- v.distance: geodesic support
- v.kernel: Vect_net_shortest_path_coor2() usage
- v.out.ascii: return test in vector/v.out.ascii/main.c
- v.select: various differences
?

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

[GRASS-dev] SESSION_MANAGER environment variable not defined

[Andy Wickert]

Dear GRASS-dev,

I have started seeing this error:

Error - Debug: Failed to connect to session manager: SESSION_MANAGER
environment variable not defined

when starting GRASS GIS that I have compiled myself (both 6.4.x and
7.1-svn), and do not know why. I am running Ubuntu 14.10. Never seen
anything like this before. Suggestions?

Thanks!

Andy

---
Andrew D. Wickert
INSTAAR & Geological Sciences, University of Colorado Boulder
Now at:
Universität Potsdam
Institut für Erd- und Umweltwissenschaften
Haus 29, Rm. 1.53
Karl-Liebknecht-Str. 24-25
14476 Potsdam-Golm, Deutschland
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2539: v.in.ogr: error importing shapefiles: ValueError : too many values to unpack

[GRASS GIS]

#2539: v.in.ogr: error importing shapefiles: ValueError  :  too many values to
unpack
+---
 Reporter:  richardc|   Owner:  grass-dev@… 
 
 Type:  defect  |  Status:  new 
 
 Priority:  blocker |   Milestone:  7.0.0   
 
Component:  wxGUI   | Version:  svn-releasebranch70 
 
 Keywords:  wxgui vector import wizard  |Platform:  Linux   
 
  Cpu:  x86-32  |  
+---
Changes (by mlennert):

  * keywords:  v.in.ogr  vector import => wxgui vector import wizard
  * priority:  critical => blocker
  * component:  Vector => wxGUI


Comment:

 I can confirm this error on a freshly checkouted and compiled
 grass70release tree.

 Bumping this up to blocker as this is fundamental functionality of the
 GUI.

-- 
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] #2537: v.external wxgui wizard: ValueError : need more than 3 values to unpack

[GRASS GIS]

#2537: v.external wxgui wizard: ValueError : need more than 3 values to unpack
--+-
 Reporter:  mlennert  |   Owner:  martinl  
 Type:  defect|  Status:  assigned 
 Priority:  normal|   Milestone:  7.0.0
Component:  wxGUI | Version:  svn-trunk
 Keywords:  v.external postresql  |Platform:  Linux
  Cpu:  Unspecified   |  
--+-

Comment(by mlennert):

 Replying to [comment:6 mlennert]:
 > Replying to [comment:4 martinl]:
 > > Replying to [comment:3 annakrat]:
 > > > It's somehow related to http://trac.osgeo.org/grass/changeset/63610
 which hasn't been backported. v.external is running in the background and
 the code expects 4 columns (`layerName, featureType, projection,
 geometryColumn`) but you get only 3.
 > >
 > > I have backport it in r64041.
 >
 > FYI: it was working in release70 and not in trunk, so I guess by
 backporting it will now also not work in release70... I can't check right
 now, so this message is meant just to give you a heads up.


 I can confirm now that v.external does not work for PostgreSQL databases
 in trunk and grass70. v.external -t still gives me the same output.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1

[Markus Metz]

On Sat, Jan 10, 2015 at 11:50 AM, Markus Neteler  wrote:
> Hi devs,
>
> http://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing
>
> ...the TODO list got much shorter!
>
> Relevant differences - to be clarified:
[...]
>  * checks for Vect_open_* return value to avoid potential segmentation
> fault: r60054 <<-- wasn't the idea to avoid these ugly tests in G7?

The Vect_open_* return the open level when opening existing maps, not
just success or failure. Some modules, most importantly v.info, try to
open a map first with topology, if that fails, without topology.
Therefore it is up to the modules to decide if the return code is ok
or not.

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

Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation

[GRASS GIS]

#2409: last call for options keys consolidation
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  task  |  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  Default   | Version:  unspecified  
 Keywords:  standardized options  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-

Comment(by mlennert):

 Replying to [comment:189 glynn]:
 > Replying to [comment:187 wenzeslaus]:
 >
 > > `r.mapcalculator` may create some confusion because is not part of
 standard GRASS GIS distribution (compilation switched off by default). It
 is also not in the documentation. I don't know if the confusion is also on
 the QGIS site. Another issue is that it is in Shell, not Python, so it
 should not work in GRASS 7 on MS Windows as far as I understand. Finally,
 so revision of messages is needed, error message "Calculating
 $GIS_OPT_OUTFILE. Try expert mode." shown after `r.mapcalc` failed just
 caught my eye.
 >
 > r.mapcalculator was never converted to Python. It was deemed unnecessary
 now that r.mapcalc uses G_parser(). r.mapcalculator was created when
 r.mapcalc didn't use G_parser() which meant that it couldn't generate a
 GUI option dialog.
 >
 > If there's some situation where it's useful, it should be converted to
 Python. Otherwise, it should be removed from the 7.0 tree.

 +1 for removal. If there are any issues with using the grass7 r.mapcalc in
 other software (e.g. QGIS) then let's try to solve these issues.

 Moritz

-- 
Ticket URL: 
GRASS GIS 

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