Re: [GRASS-dev] [GRASS GIS] #2936: v.net.distance: wrong directions in one-way streets

2016-03-01 Thread GRASS GIS 
#2936: v.net.distance: wrong directions in one-way streets
-+-
  Reporter:  mlennert|  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.0.4
 Component:  Vector  |Version:  svn-trunk
Resolution:  |   Keywords:  v.net.distance network one-way
   CPU:  |  direction
  Unspecified|   Platform:  Unspecified
-+-

Comment (by mmetz):

 Replying to [comment:2 mlennert]:
 > Replying to [comment:1 mmetz]:
 > > Manual:
 > >
 > > "Each path consist of several lines. If a line is on the shortest path
 from a point then the category of this point is assigned to the line. Note
 that every line may contain more than one category value since a single
 line may be on the shortest path for more than one from feature."
 > >
 > > That means lines are copied directly from input to output, line
 directions are not adjusted and lines are not merged to unique paths for
 each `from` category.
 > >
 > > Unfortunately, the paths as reported by v.net.distance (irrespective
 of the direction) are wrong: the shortest path from 7779 to 7780 should
 take the long route, and the shortest path from 7780 to 7779 should take
 the short route. Fixing this bug would require a new function in
 lib/vector/neta. Hopefully the dglib interface allows for an easy solution
 to provide an inverse to
 lib/vector/neta/path.c:NetA_distance_from_points().
 > >
 > > This ticket should be closed and a new ticket should be opened that
 v.net.distance calculates paths in reverse (from to to from instead of
 from from to to).
 >
 >
 > I don't understand why we need a new ticket. Maybe my formulation was a
 bit awkward, but the problem reported in the ticket is exactly that
 v.net.distance calculates paths in reverse...

 I understand. Just for emphasis, the output line directions are not wrong
 because they are not meant to be in accordance with the path directions.
 The paths themselves were wrong in case of one-way streets. Correct paths
 are created with trunk r67984,5. There is also a new -l flag that produces
 a single line for each path with appropriate line direction. The vector
 libs needed some modification in order to fix v.net.distance.

--
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] #2948: ps.map output to stdout

2016-03-01 Thread GRASS GIS 
#2948: ps.map output to stdout
--+-
  Reporter:  harrikoo |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.0.4
 Component:  Ps.map   |Version:  svn-releasebranch70
Resolution:   |   Keywords:  stdout
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by harrikoo):

 * Attachment "psmapstdout.diff" added.


--
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] #2948: ps.map output to stdout

2016-03-01 Thread GRASS GIS 
#2948: ps.map output to stdout
-+-
 Reporter:  harrikoo |  Owner:  grass-dev@…
 Type:  enhancement  | Status:  new
 Priority:  normal   |  Milestone:  7.0.4
Component:  Ps.map   |Version:  svn-releasebranch70
 Keywords:  stdout   |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 It would be nice to have `ps.map` optionally output to stdout. The
 attached patch achieves this.

 1. by changing the input and output argument handling to
 `G_open_option_file`;

 2. by moving the bounding box to the trailer of the produced postscript
 file;

 3. and additionally by closing the files using G_close_option_file. This
 changes moves the closing of output file `PS.fp` from `ps_map()` to
 `main()` where it is created.

 4. As a result, this removes all seeks from the ps.map.

 I'll attach the diff to r67951, but I have idea how to submit this.

 Best,

 Harri K.

--
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] #2947: g.gui.gmodeler - not possible to remove data from model

2016-03-01 Thread GRASS GIS 
#2947: g.gui.gmodeler - not possible to remove data from model
--+-
 Reporter:  lfurtkevicova |  Owner:  grass-dev@…
 Type:  enhancement   | Status:  new
 Priority:  normal|  Milestone:  7.0.4
Component:  wxGUI |Version:  svn-trunk
 Keywords:  g.region, gmodeler data deletion  |CPU:  x86-64
 Platform:  Linux |
--+-
 It is not possible to delete data from model, e.g. I set region according
 to vector layer ({{{g.region vector=area}}}). Then I change it and set
 region according to raster({{{g.region raster=dmt}}}). Vector input is
 still in model and it is not possible to remove it (also after reopening
 {{{*.gxm}}} file).

--
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] #2946: g.gui.gmodeler - raster with average values is deleted as intermediate data

2016-03-01 Thread GRASS GIS 
#2946: g.gui.gmodeler - raster with average values is deleted as intermediate 
data
---+---
  Reporter:|  Owner:  grass-dev@…
  lfurtkevicova|
  Type:  enhancement   | Status:  closed
  Priority:  minor |  Milestone:  7.0.4
 Component:  wxGUI |Version:  svn-trunk
Resolution:  fixed |   Keywords:  intermediate data, g.gui.gmodeler
   CPU:  x86-64|   Platform:  Linux
---+---
Changes (by lfurtkevicova):

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


Comment:

 Now I've noticed it is possible to set which of layers are intermediate ..
 sorry for the unnecessary alert

--
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] #2946: g.gui.gmodeler - raster with average values is deleted as intermediate data

2016-03-01 Thread GRASS GIS 
#2946: g.gui.gmodeler - raster with average values is deleted as intermediate 
data
---+-
 Reporter:  lfurtkevicova  |  Owner:  grass-dev@…
 Type:  enhancement| Status:  new
 Priority:  minor  |  Milestone:  7.0.4
Component:  wxGUI  |Version:  svn-trunk
 Keywords:  intermediate data, g.gui.gmodeler  |CPU:  x86-64
 Platform:  Linux  |
---+-
 When "delete intermediate data" option is set and e.g. modul v.db.univar
 and then v.to.rast are used in model, the result raster with average
 values is deleted after model process

--
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] #2945: MD5sum for WinGRASS-7.1.svn-r67975-87-Setup-x86_64.exe does not match md5sum file

2016-03-01 Thread GRASS GIS 
#2945: MD5sum for  WinGRASS-7.1.svn-r67975-87-Setup-x86_64.exe does not 
match
md5sum file
+-
  Reporter:  dnewcomb   |  Owner:  grass-dev@…
  Type:  defect | Status:  closed
  Priority:  major  |  Milestone:  7.1.0
 Component:  Packaging  |Version:  svn-trunk
Resolution:  invalid|   Keywords:  wingrass
   CPU:  x86-64 |   Platform:  MSWindows 7
+-
Changes (by dnewcomb):

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


Comment:

 You are correct.  I checked twice got something different the first time
 (before morning caffeine)  .  Just went back and checked again and the
 checksum is correct.  User error on md5sum. Sorry for the noise.

 Closing Ticket


 Doug

--
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] #2854: results in winGRASS7 32bit vs 64bit: should they be identical?

2016-03-01 Thread GRASS GIS 
#2854: results in winGRASS7 32bit vs 64bit: should they be identical?
-+-
  Reporter:  hellik  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.0.4
 Component:  Raster  |Version:  svn-releasebranch70
Resolution:  |   Keywords:
   CPU:  x86-64  |   Platform:  MSWindows 7
-+-

Comment (by glynn):

 Replying to [comment:12 mmetz]:

 > The results are thus as precise as requested per GCC compiler options
 for the given architecture. The same GCC compiler options can lead to
 different results under different architectures.

 There should be some set of options which produce the correct result on
 any architecture which uses IEEE-754.

 > Generally, with limited fp precision,
 >
 > (a * b) / c != a * (b / c)

 This shouldn't be relevant. The source code won't change between
 architectures, and gcc shouldn't perform such approximations unless
 specifically requested via -ffast-math or similar (apparently -Ofast
 enables this, but none of the numbered optimisation levels do).

 The main issue which occurs with the default options is excess precision.
 The x87 FPU uses 80 bits by default; you need to use e.g. -ffloat-store or
 -fexcess-precision=standard to force the result to be rounded to 64 bits.
 SSE always rounds to 64 bits.

 > In other words, the results obtained with WinGRASS 32bit and WinGRASS
 64bit are both correct, even if they differ from each other. The results
 are as precise as possible / as requested.

 The issue is how you test for correctness. You can either build for
 deterministic calculation so that exact equality comparisons will work, or
 you can use a tolerance. The latter option requires case-by-case analysis
 (see point 4 in comment:9).

--
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] #2945: MD5sum for WinGRASS-7.1.svn-r67975-87-Setup-x86_64.exe does not match md5sum file

2016-03-01 Thread GRASS GIS 
#2945: MD5sum for  WinGRASS-7.1.svn-r67975-87-Setup-x86_64.exe does not 
match
md5sum file
+-
  Reporter:  dnewcomb   |  Owner:  grass-dev@…
  Type:  defect | Status:  new
  Priority:  major  |  Milestone:  7.1.0
 Component:  Packaging  |Version:  svn-trunk
Resolution: |   Keywords:  wingrass
   CPU:  x86-64 |   Platform:  MSWindows 7
+-

Comment (by martinl):

 I don't see any difference

 {{{
 md5sum WinGRASS-7.1.svn-r67975-87-Setup-x86_64.exe
 4e44b7b8036d4a19000e4bb4ee188ff9  WinGRASS-7.1.svn-r67975-87-Setup-
 x86_64.exe
 }}}

 vs.

 {{{
 cat WinGRASS-7.1.svn-r67975-87-Setup-x86_64.exe.md5sum
 4e44b7b8036d4a19000e4bb4ee188ff9 *WinGRASS-7.1.svn-r67975-87-Setup-
 x86_64.exe
 }}}

 except of 'star' character. Are you reporting that or something else?

--
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-03-01 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.4
 Component:  Default  |Version:  7.0.3
Resolution:   |   Keywords:  FreeBSD
   CPU:  x86-64   |   Platform:  Other Unix
--+-

Comment (by glynn):

 Replying to [comment:2 pieside]:
 > The problems seems to be an old friend:
 >
 {{{
 /home/pierre/tmp/grass7/grass-7.0.3/dist.x86_64-unknown-
 freebsd10.2/lib/libgrass_gis.7.0.3.so: undefined reference to `libiconv'
 }}}

 This usually means that it's including  from libiconv but linking
 against the system iconv (which may be part of libc).

 One way to solve issues with multiple library versions is to create
 "include" and "lib" directories, populate them with symlinks to the
 desired versions of the headers and libraries, and use --with-includes=
 and --with-libs= to put those directories at the front of the search 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] [GRASS GIS] #2945: MD5sum for WinGRASS-7.1.svn-r67975-87-Setup-x86_64.exe does not match md5sum file

2016-03-01 Thread GRASS GIS 
#2945: MD5sum for  WinGRASS-7.1.svn-r67975-87-Setup-x86_64.exe does not 
match
md5sum file
+-
  Reporter:  dnewcomb   |  Owner:  grass-dev@…
  Type:  defect | Status:  new
  Priority:  major  |  Milestone:  7.1.0
 Component:  Packaging  |Version:  svn-trunk
Resolution: |   Keywords:  wingrass
   CPU:  x86-64 |   Platform:  MSWindows 7
+-
Changes (by martinl):

 * keywords:   => wingrass
 * component:  Default => Packaging


--
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] #2945: MD5sum for WinGRASS-7.1.svn-r67975-87-Setup-x86_64.exe does not match md5sum file

2016-03-01 Thread GRASS GIS 
#2945: MD5sum for  WinGRASS-7.1.svn-r67975-87-Setup-x86_64.exe does not 
match
md5sum file
-+-
 Reporter:  dnewcomb |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  major|  Milestone:  7.1.0
Component:  Default  |Version:  svn-trunk
 Keywords:   |CPU:  x86-64
 Platform:  MSWindows 7  |
-+-
 md5sum for WinGRASS-7.1.svn-r67975-87-Setup-x86_64.exe  does not match the
 md5sum file

--
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] #2917: r.mapcalc neighbour modifier uses wrong row

2016-03-01 Thread GRASS GIS 
#2917: r.mapcalc neighbour modifier uses wrong row
--+-
  Reporter:  marisn   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  blocker  |  Milestone:  7.0.4
 Component:  Raster   |Version:  svn-releasebranch70
Resolution:   |   Keywords:  r.mapcalc
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by glynn):

 Replying to [comment:6 marisn]:

 > If I understood correctly, the issue was triggered by any mapcalc
 expression containing two to eight references to same map (MAP[n,x] and
 MAP[m,x], ...) where n!=m.

 The row cache is contiguous, but limited to 8 rows. So it's used if the
 range of offsets (maximum row offset minus the minimum row offset plus
 one) is between 2 and 8 inclusive.

 So if an expression contained e.g. map[-10] and map[10], the cache
 wouldn't be used (because it would need to hold 21 rows, which is more
 than the maximum of 8 rows). In that case, each row would be read multiple
 times rather than being cached.

 Any expression using two or more distinct row offsets for a map (no offset
 is equivalent to an offset of zero) "might" trigger it. Scripts which use
 fixed offsets typically use small offsets, so the range being less than or
 equal to 8 is likely. Scripts which use larger row offsets typically do so
 by way of using variable row offsets, so it's likely that the cache will
 be used "sometimes".

--
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] #2944: g.gui.gmodeler - strange duplicity when setting comment

2016-03-01 Thread GRASS GIS 
#2944: g.gui.gmodeler - strange duplicity when setting comment
+-
  Reporter:  lfurtkevicova  |  Owner:  grass-dev@…
  Type:  enhancement| Status:  new
  Priority:  minor  |  Milestone:  7.0.4
 Component:  wxGUI  |Version:  svn-trunk
Resolution: |   Keywords:  g.gui.gmodeler, Set Comment
   CPU:  x86-64 |   Platform:  Linux
+-
Changes (by lfurtkevicova):

 * Attachment "set_comment_duplicity.png" added.


--
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] #2944: g.gui.gmodeler - strange duplicity when setting comment

2016-03-01 Thread GRASS GIS 
#2944: g.gui.gmodeler - strange duplicity when setting comment
-+-
 Reporter:  lfurtkevicova|  Owner:  grass-dev@…
 Type:  enhancement  | Status:  new
 Priority:  minor|  Milestone:  7.0.4
Component:  wxGUI|Version:  svn-trunk
 Keywords:  g.gui.gmodeler, Set Comment  |CPU:  x86-64
 Platform:  Linux|
-+-
 After comment setting in Graphical Modeler, there is strange duplicity,
 see attached screenshot.

--
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] #2943: Absolute path in TGIS connection can make db inaccessible in a (mixed) multi-user environment

2016-03-01 Thread GRASS GIS 
#2943: Absolute path in TGIS connection can make db inaccessible in a (mixed)
multi-user environment
-+-
 Reporter:  sbl  |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:  7.0.4
Component:  Temporal |Version:  unspecified
 Keywords:  t.connect|CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 It seems that the connection to the TGIS sqlite.db is defined for the
 mapset using an absolute paths.

 That makes it inaccessible in cases where mount points change, e.g. in a
 multi-user environment. In my particular case,
 /grassdata/ETRS_33N/precipitation_daily/tgis/sqlite.db (produced from
 within Linux) is (naturally) not readable from Windows where the
 equivalent path would be
 R:\grassdata\ETRS_33N\precipitation_daily\tgis\sqlite.db

 One can work around this issue using t.connect -d when starting to work,
 but this is only possible for "mapset owners".

 Would be nice if environment variables could be used
 ($GISDBASE/$LOCATION_NAME/$MAPSET) and first expand/evaluate at access
 time or relative path to the current mapset...

--
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] #2936: v.net.distance: wrong directions in one-way streets

2016-03-01 Thread GRASS GIS 
#2936: v.net.distance: wrong directions in one-way streets
-+-
  Reporter:  mlennert|  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.0.4
 Component:  Vector  |Version:  svn-trunk
Resolution:  |   Keywords:  v.net.distance network one-way
   CPU:  |  direction
  Unspecified|   Platform:  Unspecified
-+-

Comment (by mlennert):

 Replying to [comment:1 mmetz]:
 > Manual:
 >
 > "Each path consist of several lines. If a line is on the shortest path
 from a point then the category of this point is assigned to the line. Note
 that every line may contain more than one category value since a single
 line may be on the shortest path for more than one from feature."
 >
 > That means lines are copied directly from input to output, line
 directions are not adjusted and lines are not merged to unique paths for
 each `from` category.
 >
 > Unfortunately, the paths as reported by v.net.distance (irrespective of
 the direction) are wrong: the shortest path from 7779 to 7780 should take
 the long route, and the shortest path from 7780 to 7779 should take the
 short route. Fixing this bug would require a new function in
 lib/vector/neta. Hopefully the dglib interface allows for an easy solution
 to provide an inverse to
 lib/vector/neta/path.c:NetA_distance_from_points().
 >
 > This ticket should be closed and a new ticket should be opened that
 v.net.distance calculates paths in reverse (from to to from instead of
 from from to to).


 I don't understand why we need a new ticket. Maybe my formulation was a
 bit awkward, but the problem reported in the ticket is exactly that
 v.net.distance calculates paths in reverse...

--
Ticket URL: 
GRASS GIS 

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