Re: [GRASS-dev] GRASS 7.0beta3 planning

[Helmut Kudrnovsky]

> what do you think about releasing beta3?

have look in
http://lists.osgeo.org/pipermail/grass-dev/2014-July/069983.html

"[GRASS-dev] GRASS 7: g.gui.rlisetup

[...]
Backport of r60219 is needed.
http://trac.osgeo.org/grass/changeset/60219";


g.gui.rlisetup isn't starting in winGRASS7.0



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/GRASS-7-0beta3-planning-tp5142434p5151655.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] [GRASS GIS] #1242: vector fills and line widths not displaying in latlon regions

[GRASS GIS]

#1242: vector fills and line widths not displaying in latlon regions
-+--
 Reporter:  cmbarton |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  critical |   Milestone:  7.0.0
Component:  Display  | Version:  svn-trunk
 Keywords:  vector, display, d.vect  |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by cmbarton):

 I just tested with GRASS 7.1 and it works fine on a set of points in a
 latlon region.

 There is still a problem with north arrows, but I don't know if that is
 related or not. The arrow now looks OK, but it is still double.

-- 
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 7.0beta3 planning

[Vaclav Petras]

Hi,

what do you think about releasing beta3? The problems mentioned in this
thread were fixed and fixes backported except for r60590 which is safe for
GRASS by itself and thus can be safely backported now.

Vaclav


r60590
Add G_fatal_longjmp() (needed for QGIS)
glynn
include/defs/gis.h, lib/gis/error.c
http://trac.osgeo.org/grass/changeset/60590


There is a lot of things in the tracker but they can be postponed I think:

long-term problem for non-ascii languages
http://trac.osgeo.org/grass/ticket/1681

remove ffmpeg from libogsf and configure.in
let's do it in trunk first, it does not have to be in beta
http://trac.osgeo.org/grass/ticket/2017

wxGUI vector digitizer passing unescaped text to database
security issue but not a real issue for most of the users I guess
http://trac.osgeo.org/grass/ticket/2252

missing documentation
bad but does not stop beta release
http://trac.osgeo.org/grass/ticket/2259

inconsistent random number generation
long-term problem, beta can live with it
http://trac.osgeo.org/grass/ticket/2272

insufficient error message when addons are mixed on MS Windows
To be honest, I'm not sure why this is a blocker
http://trac.osgeo.org/grass/ticket/2283

rename some imagery modules
should be done before release but not needed for beta
http://trac.osgeo.org/grass/ticket/2340

I'm not really familiar with these
http://trac.osgeo.org/grass/ticket/995
http://trac.osgeo.org/grass/ticket/1891

Python and MS Windows
there is a solution in 7.0 and some advances were made also in trunk
http://trac.osgeo.org/grass/ticket/580
http://trac.osgeo.org/grass/ticket/1871
http://trac.osgeo.org/grass/ticket/2150
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #1972: v.in.ogr wrapper fails with UnicodeEncodeError

[GRASS GIS]

#1972: v.in.ogr wrapper fails with UnicodeEncodeError
-+--
 Reporter:  marisn   |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  major|   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-trunk
 Keywords:   |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by annakrat):

 Replying to [comment:2 marisn]:
 > I still see the same error with any file in my system. Tested with:
 > {{{
 > /home/maris/geodata/gadm_v1_lev0_shp/gadm1_lev0.shp
 > /home/maris/Lejupielādes/estonia.shapefiles/Esti_towers.shp
 > }}}
 >
 > GRASS SVN Revision: 58952M
 > GNU/Linux with UTF-8 locale (lv_LV.UTF-8)

 The problem was with translatable string "Yes" or "No" which is inserted
 into the list to describe if projection is matching. I removed the str
 function in r61271. Needs testing also for English locale.

-- 
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] #2286: Duplicate calls to d.rast when using wx monitor and d.rast command line

[GRASS GIS]

#2286: Duplicate calls to d.rast when using wx monitor and d.rast command line
-+--
 Reporter:  hcho |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  major|   Milestone:  7.0.0
Component:  Display  | Version:  svn-trunk
 Keywords:  d.mon|Platform:  Linux
  Cpu:  x86-64   |  
-+--

Comment(by wenzeslaus):

 Replying to [ticket:2286 hcho]:
 > IMO, to avoid duplicate calls to d.rast, if we call d.rast from the
 command line and the selected monitor is wx, it should simply add d.rast
 commands to the command file and let the monitor handle actual drawing.

 Hm, I actually thought that this is how it was designed and what it is
 doing. I this is the case, then what you are saying is clear bug and you
 can safely fix it.

-- 
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] #1787: Profile Analysis Tool Problems

[GRASS GIS]

#1787: Profile Analysis Tool Problems
+---
 Reporter:  stu |   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  major   |   Milestone:  7.1.0
Component:  wxGUI   | Version:  svn-trunk
 Keywords:  profile tool r.profile  |Platform:  All  
  Cpu:  x86-64  |  
+---

Comment(by cmbarton):

 Yes. The proper place to fix this is in r.profile rather than a patch in
 the GUI, no matter how welcome.

-- 
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] #1065: v.in.mapgen fails to load coastline from NOAA's National Geophysical Data Center

[GRASS GIS]

#1065: v.in.mapgen fails to load coastline from NOAA's National Geophysical Data
Center
---+
 Reporter:  vesnikos   |   Owner:  grass-dev@…  
 Type:  defect |  Status:  new  
 Priority:  normal |   Milestone:  7.0.0
Component:  Vector | Version:  svn-trunk
 Keywords:  v.in.mapgen, mapgen, NOAA  |Platform:  Linux
  Cpu:  x86-32 |  
---+
Changes (by wenzeslaus):

  * priority:  major => normal


Comment:

 Replying to [comment:2 martinl]:
 > Replying to [ticket:1065 vesnikos]:
 >
 > > with the following command:
 > >
 > > v.in.mapgen -f input=/home/nikos/datagis/coastline/6888.dat
 output=coastline
 >
 > I will let this for someone who knows the input format.

 Is this still an issue? The file cannot be reached anymore. Is there some
 sample file or documentation if somebody would like to look at this?

 Downgrading priority for old inactive 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] [GRASS GIS] #2285: Repetitive d.rast calls for wx0 monitor from command line

[GRASS GIS]

#2285: Repetitive d.rast calls for wx0 monitor from command line
---+
  Reporter:  hcho  |   Owner:  grass-dev@…  
  Type:  defect|  Status:  reopened 
  Priority:  critical  |   Milestone:  7.0.0
 Component:  Display   | Version:  svn-trunk
Resolution:|Keywords:  d.mon
  Platform:  Linux | Cpu:  x86-64   
---+

Comment(by wenzeslaus):

 I don't understand the whole concept behind `d.mon wx*` and how this
 display architecture is supposed to work for GUI.

 I would say that no variables for rendering inside GUI (including `d.mon
 wx*`) should not use `os.environ` directly nor they should use `g.gisenv`
 without creating a local copy of it first. The `env` parameter of `Popen`
 object should be used for all environmental changes (custom GRASS GIS
 file-based environment (rc file path) should be passed there too).

 However, if you think you tested r60215 and that it make sense, you can
 backport it at some point but I must say that `d.mon wx*` never guarantied
 that it will work from a script and the fact that it works for you might
 be just luck. Also batch rendering in general is for anyway only for
 advanced users which may notice that they should not play with `d.mon` and
 `g.gui` at the same time, in other words I don't think this is so
 critical.

 But don't take me wrong, I'm annoyed by this too, and I want to use `d.mon
 wx*` from my scripts and with my scripts, so I'm happy to see r60215 and
 also r60376 (change environment only for subprocesses).

-- 
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] #1787: Profile Analysis Tool Problems

[GRASS GIS]

#1787: Profile Analysis Tool Problems
+---
 Reporter:  stu |   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  major   |   Milestone:  7.1.0
Component:  wxGUI   | Version:  svn-trunk
 Keywords:  profile tool r.profile  |Platform:  All  
  Cpu:  x86-64  |  
+---

Comment(by annakrat):

 Replying to [comment:9 annakrat]:
 > Replying to [comment:7 dadudeman]:
 > > Used r.profile interactively in GRASS 7.1 SVN.  Same problems
 described by stu.  If I use horizontal and vertical units of meters, the
 plot is perfect.  If I change to horizontal and vertical units of feet,
 the Y axis of elevations is displayed correctly, but the X axis is
 squished to stop at the unit value in meters rather than feet.  Example:
 I had a 800 meter transect, but when reprojected to feet and profiled, the
 graph stops at 800 feet rather than the approximate 2600.  The endpoint
 triangle, however, is placed around the 2600 distance.  It's as if it
 thinks the units are meters horizontal.
 >
 > Yes, it's meters because meters come from r.profile and the GUI
 profiling tool just takes the values as they are. I wonder if this should
 be changed in r.profile rather than in the GUI?

 I fixed this problem in GUI (r61269). Please test. Still it would be worth
 changing the behavior of r.profile (and then revert this commit).

-- 
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] #1288: g.dirseps breaks non-latin file/folder names on Windows

[GRASS GIS]

#1288: g.dirseps breaks non-latin file/folder names on Windows
--+-
 Reporter:  marisn|   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  critical  |   Milestone:  7.0.0
Component:  Default   | Version:  6.4.1 RCs
 Keywords:  wingrass, i18n, encoding  |Platform:  MSWindows Vista  
  Cpu:  Unspecified   |  
--+-

Comment(by wenzeslaus):

 Please, somebody, test this on some non-English MS Windows with as many
 version of GRASS as possible. Please close this ticket if it is not an
 issue for 7.0 (currently: beta1, beta2, nightly).

-- 
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] #1242: vector fills and line widths not displaying in latlon regions

[GRASS GIS]

#1242: vector fills and line widths not displaying in latlon regions
-+--
 Reporter:  cmbarton |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  critical |   Milestone:  7.0.0
Component:  Display  | Version:  svn-trunk
 Keywords:  vector, display, d.vect  |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by wenzeslaus):

 I would test that but I don't understand what to try and what should I
 look for. Line width for vectors works for me (`d.vect`'s `width` option).
 Running from GUI (with cairo driver I think).

-- 
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] #1787: Profile Analysis Tool Problems

[GRASS GIS]

#1787: Profile Analysis Tool Problems
+---
 Reporter:  stu |   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  major   |   Milestone:  7.1.0
Component:  wxGUI   | Version:  svn-trunk
 Keywords:  profile tool r.profile  |Platform:  All  
  Cpu:  x86-64  |  
+---

Comment(by annakrat):

 Replying to [comment:8 annakrat]:
 > Replying to [comment:7 dadudeman]:
 > > I get a seemingly related issue when I use the measure tool, as the
 distances are reported as units meters, but the values are reported
 correctly as feet.
 >
 > I actually fixed the measurement tool yesterday (r61132). The problem is
 I guess that the units are FootUSs which is not recognized  as feet. So
 now the original units are displayed as footuss which is still kind of
 weird but not wrong at least.
 >
 Backported in r61268.

-- 
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] #2283: wingrass: failure when loading addons

[GRASS GIS]

#2283: wingrass: failure when loading addons
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  task  |  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  Addons| Version:  svn-trunk
 Keywords:  wingrass, launch  |Platform:  MSWindows 2K 
  Cpu:  Unspecified   |  
--+-

Comment(by wenzeslaus):

 Can you please elaborate more on how the addons are handled and what
 actually went wrong? I tis not clear to me if this is something which
 happens all the time or just when there is error in the source code.

-- 
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] #2004: wxgui: ctrl-t to tile layer manager and map window full screen

[GRASS GIS]

#2004: wxgui: ctrl-t to tile layer manager and map window full screen
---+
 Reporter:  hamish |   Owner:  grass-dev@…  
 Type:  enhancement|  Status:  new  
 Priority:  normal |   Milestone:  7.1.0
Component:  wxGUI  | Version:  svn-trunk
 Keywords:  window layout  |Platform:  All  
  Cpu:  All|  
---+

Comment(by annakrat):

 Replying to [comment:3 annakrat]:
 > Try r60971 for fullscreen map display. Works also for
 g.gui.mapswipe/iclass/gcp. I am not sure if we want to keep the toolbars
 or not. Showing them would be more consistent with other applications but
 I don't think they are necessary when we can move the map view with mouse
 only.

 r61267 fixes fullscreen on Windows.

-- 
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] #2252: wxGUI vector digitizer passing unescaped text to database

[GRASS GIS]

#2252: wxGUI vector digitizer passing unescaped text to database
-+
 Reporter:  marisn   |  
 Owner:  grass-dev@…  
 Type:  defect   |  
Status:  new  
 Priority:  blocker  |  
 Milestone:  7.0.0
Component:  wxGUI|  
   Version:  svn-trunk
 Keywords:  security, code injection, SQL injection, data loss, v.db.update  |  
  Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+
Changes (by wenzeslaus):

  * keywords:  => security, code injection, SQL injection, data loss,
   v.db.update


Comment:

 I don't know (and quick look into source code haven't told me) what is
 used in digitizer as a backend. Library, Python SQLite API or modules?

 I've tried `v.db.update` with map `bridges` copied from `PERMANENT` and
 this was OK:
 {{{
 v.db.update map=bridges column=LOCATION value="; drop database
 important_data;" where=cat=1
 }}}
 String "; drop database important_data;" saved to the database.

 But this:
 {{{
 v.db.update map=bridges column=LOCATION value="'; drop database
 important_data; SELECT 1='1" where=cat=1
 }}}
 removed all the values from the column `LOCATION`. I'm not getting any
 error messages.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] starting GRASS 7.1

[Anna Petrášová]

On Tue, Jul 15, 2014 at 5:44 PM, Michael Barton 
wrote:

>  I just recompiled GRASS 7.1 and posted it to my website (7.0 beta and 6.4
> beta coming soon). Here is something I noticed when I last compiled GRASS
> 7.1 in May and which is still happening.
>
>  The first time I launch 7.1 and try to view a map (e.g., elevation from
> the NC demo data) it takes a REALLY long time…many minutes. Then it takes
> almost as long if I want to render it in 3D. When I switch back to 2D, a
> couple of the 3D buttons (rotate 3D scene and fly through mode) remain on
> the button bar.
>
>  If I then quit GRASS and start it again, everything renders at normally
> fast speed and the button bar is OK. It seems to run fine from that point
> on. so it is is just the very first time that GRASS is launched.
>
>  Others might want to check to see if this happens to them when they
> install the Mac (or other) 7.1 binaries and try to start them for the first
> time. I don’t know what is going on. Is Python trying to compile ALL of its
> source wxPython files while rendering a map for the first time? I don’t
> know. Something to look out for, especially with new users.
>

I haven't experienced these problems, I tried your grass 71 binary and
self-compiled grass. So hopefully, it's nothing serious.

Anna



>
>  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
>  Tempe, AZ  85287-2402
>  USA
>
>  voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
>  fax:  480-965-7671(SHESC), 480-727-0709 (CSDC)
>  www:  http://csdc.asu.edu, http://shesc.asu.edu
>  http://www.public.asu.edu/~cmbarton
>
>
___
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

[GRASS GIS]

#2369: Include map elements into GRASS workspaces
-+--
 Reporter:  mastho   |   Owner:  grass-dev@…  
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  wxGUI| Version:  unspecified  
 Keywords:  workspace|Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--
Changes (by martinl):

  * milestone:  => 7.0.0


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

[GRASS GIS]

#2369: Include map elements into GRASS workspaces
-+--
 Reporter:  mastho   |   Owner:  grass-dev@…  
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:   
Component:  wxGUI| Version:  unspecified  
 Keywords:  workspace|Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--
 Map elements like raster map legends or north arrows are not included into
 a GRASS workspace. An integration of position and size of map elements
 into a saved workspace would help to restore complete map display settings
 for reproduction and further reuse in image export e.g.

-- 
Ticket URL: 
GRASS GIS 

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