[GRASS-dev] [GRASS GIS] #2842: configure fails to detect missing HTMLParser

[GRASS GIS]

#2842: configure fails to detect missing HTMLParser
-+-
 Reporter:  marisn   |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:  7.1.0
Component:  Compiling|Version:  svn-trunk
 Keywords:   |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 Seems that Python module HTMLParser is a requirement to compile GRASS 7
 trunk. Still configure part will give no warning if it is missing. If it
 is required, it should be tested during configure phase. If it is
 optional, compilation should not fail in case of its absence.

 Example of failure message:
 {{{
 if [ "pngdriver" != "" -a -f "pngdriver".html ] ; then make html ; fi
 make[1]: Entering directory '/home/maris/soft/grass_trunk/lib/pngdriver'
 VERSION_NUMBER=7.1.svn /home/maris/soft/grass_trunk/dist.x86_64-pc-linux-
 gnu/tools/g.html2man.py /home/maris/soft/grass_trunk/dist.x86_64-pc-linux-
 gnu/docs/html/pngdriver.html /home/maris/soft/grass_trunk/dist.x86_64-pc-
 linux-gnu/docs/man/man1/pngdriver.1
 Traceback (most recent call last):
   File "/home/maris/soft/grass_trunk/dist.x86_64-pc-linux-
 gnu/tools/g.html2man.py", line 4, in 
 from html import HTMLParser, HTMLParseError
   File "/home/maris/soft/grass_trunk/dist.x86_64-pc-linux-
 gnu/tools/html.py", line 4, in 
 import HTMLParser as base
 ImportError: No module named 'HTMLParser'
 ../../include/Make/Html.make:11: recipe for target
 '/home/maris/soft/grass_trunk/dist.x86_64-pc-linux-
 gnu/docs/man/man1/pngdriver.1' failed
 make[1]: *** [/home/maris/soft/grass_trunk/dist.x86_64-pc-linux-
 gnu/docs/man/man1/pngdriver.1] Error 1
 make[1]: Leaving directory '/home/maris/soft/grass_trunk/lib/pngdriver'
 ../../include/Make/Lib.make:26: recipe for target 'lib' failed
 make: *** [lib] Error 2
 }}}

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] strange behavior of gselect.Select

[Anna Petrášová]

On Wed, Dec 30, 2015 at 9:54 AM, Luca Delucchi  wrote:

> Hi devs,
>
> working on g.gui.tplot I have problems with gselect.Select in the Vector
> panel.
> Right now there is a wx.EVT_TEXT event and it works well if the vector
> temporal dataset is selected by the scroll down menu but it return
> errors if the user try to write him self the name of the temporal
> dataset, because for each added character it run the connected
> function
>
> GRASS_INFO_MESSAGE(13258,1): ERROR: Space time vector dataset  not found
> GRASS_INFO_END(13258,1)
> Traceback (most recent call last):
>   File
> "/home/lucadelu/compilati/grass_trunk/dist.x86_64-unknown-linux-gnu/gui/wxpython/tplot/frame.py",
> line 842, in OnVectorSelected
> column='name')
>   File
> "/home/lucadelu/compilati/grass_trunk/dist.x86_64-unknown-linux-gnu/etc/python/grass/script/core.py",
> line 461, in read_command
> return handle_errors(returncode, stdout, args, kwargs)
>   File
> "/home/lucadelu/compilati/grass_trunk/dist.x86_64-unknown-linux-gnu/etc/python/grass/script/core.py",
> line 329, in handle_errors
> returncode=returncode)
> grass.exceptions.CalledModuleError: L'esecuzione del modulo None
> ['t.vect.list', '-s', 'column=name', 'input=p'] è terminata con errori
> Processo terminato con codice di return diverso da zero 1. Vedi gli
> errori nel (error) output.
>
> So I tried to change the event in wx.EVT_TEXT_ENTER this not working
> at all, no error and no call to the function.
>
> Instead if I use wx.EVT_COMBOBOX_CLOSEUP it works when I select the
> temporal dataset but no when the user types the name.
>
> My idea is to replace wx.EVT_TEXT with both wx.EVT_TEXT_ENTER and
> wx.EVT_COMBOBOX_CLOSEUP as suggested in the attached patch but I would
> like why wx.EVT_TEXT_ENTER is not working at all, do you have any
> idea?
>

The TextCtrl must have wx.TE_PROCESS_ENTER style set, that might be the
problem.

I was dealing with this by checking the existence of the typed map after
every typed letter. This can slow it down little bit during typing, so I am
not sure which solution is actually better. With the event bound to Enter,
users sometimes don't understand they have to press Enter.

Anna

>
> thanks
>
> --
> ciao
> Luca
>
> http://gis.cri.fmach.it/delucchi/
> www.lucadelu.org
>
> ___
> 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] Still Failing: GRASS-GIS/grass-ci#747 (master - 44ece6f)

[Travis CI]

Build Update for GRASS-GIS/grass-ci
-

Build: #747
Status: Still Failing

Duration: 5 minutes and 34 seconds
Commit: 44ece6f (master)
Author: Václav Petráš
Message: v.in.pdal: LiDAR import tool based on PDAL [news]

Contains most of the v.in.lidar filters/selection tools.
Supports two advaced PDAL filters.

Tests for basic functonality.

Doesn't build topology. Stores
return, class and color info in predefined
layers as categories.


Tests and other .c files are similar
to those in v.in.lidar.

See also #2732 and r67293.


git-svn-id: https://svn.osgeo.org/grass/grass/trunk@67436 
15284696-431f-4ddb-bdfa-cd5b030d7da7

View the changeset: 
https://github.com/GRASS-GIS/grass-ci/compare/97fdf331df2c...44ece6fdd5fb

View the full build log and details: 
https://travis-ci.org/GRASS-GIS/grass-ci/builds/99472759

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications


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

[GRASS-dev] Broken: GRASS-GIS/grass-ci#746 (master - 97fdf33)

[Travis CI]

Build Update for GRASS-GIS/grass-ci
-

Build: #746
Status: Broken

Duration: 5 minutes and 52 seconds
Commit: 97fdf33 (master)
Author: Yann Chemin
Message: Uploaded new ASTER 2 bands Albedo equation

git-svn-id: https://svn.osgeo.org/grass/grass/trunk@67435 
15284696-431f-4ddb-bdfa-cd5b030d7da7

View the changeset: 
https://github.com/GRASS-GIS/grass-ci/compare/dcfa12f91137...97fdf331df2c

View the full build log and details: 
https://travis-ci.org/GRASS-GIS/grass-ci/builds/99465725

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications

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

[GRASS-dev] Fixed: GRASS-GIS/grass-ci#748 (master - 9c3e366)

[Travis CI]

Build Update for GRASS-GIS/grass-ci
-

Build: #748
Status: Fixed

Duration: 5 minutes and 25 seconds
Commit: 9c3e366 (master)
Author: Yann Chemin
Message: corrected double definition for Aster problem

git-svn-id: https://svn.osgeo.org/grass/grass/trunk@67438 
15284696-431f-4ddb-bdfa-cd5b030d7da7

View the changeset: 
https://github.com/GRASS-GIS/grass-ci/compare/44ece6fdd5fb...9c3e3666947b

View the full build log and details: 
https://travis-ci.org/GRASS-GIS/grass-ci/builds/99475037

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications

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

Re: [GRASS-dev] [GRASS GIS] #2732: Read lidar data as vector points using PDAL

[GRASS GIS]

#2732: Read lidar data as vector points using PDAL
-+-
  Reporter:  wenzeslaus  |  Owner:  wenzeslaus
  Type:  | Status:  new
  enhancement|
  Priority:  major   |  Milestone:  7.1.0
 Component:  Vector  |Version:  svn-trunk
Resolution:  |   Keywords:  lidar, las, laz, v.in.lidar,
   CPU:  |  v.in.pointcloud, v.in.pdal
  Unspecified|   Platform:  Unspecified
-+-

Comment (by wenzeslaus):

 First version now available in trunk. PDAL compilation support added in
 r67293 and ''v.in.pdal'' in r67436. Configure GRASS with:

 {{{
 ./configure ... --with-pdal="/path/to/pdal-config"
 }}}

 PDAL can be compiled with or without LAZ (LAZlib) support and PCL support,
 so not all the functions may be available. If you compiled PDAL yourself
 you need to do also:

 {{{
 export LD_LIBRARY_PATH="/path/to/pdal/install/lib:$LD_LIBRARY_PATH"
 }}}

 I decided that the name ''v.in.pdal'' will be best because there are some
 PDAL-specific functions included. This includes also reprojection during
 import. However, the name can be changed, `v.in.points` sounds good as
 well.

 The next steps are:

 * add missing functions (implemented in GRASS) from libLAS-based
 ''v.in.lidar'' namely vector mask and count-based decimation
 * add more [http://www.pdal.io/stages/#filters PDAL-based filters] (please
 suggest!)
 * implement ''r.in.pdal'' similar to ''r.in.lidar'' (also needs list of
 filters to be implemented)
 * implement ''!r3.in.pdal''
 * implement ''v.out.pdal'' similar to ''v.out.lidar''
 * move some of the common functions to  `lib/lidar` (most of the common
 functionality was already re-factored out from ''r.in.lidar'' and
 ''v.in.lidar'' and used in ''v.in.pdal'' and ''v.decimate''

 Things like mask or various decimations have (or can have) GRASS
 implementation and have PDAL implementation as well. It would make sense
 to do these operations at the beginning and at the end of the import
 process. If it would be at the beginning, only PDAL implementations can be
 used.

 Note also that there are still some unresolved issues related to PDAL
 ability to handle large amounts of points although some solutions were
 proposed on the PDAL mailing list.

 Finally, note also that PDAL is a processing library, so it can be also
 used in a separate module which would process vector points.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] release plan for 7.0.3

[Martin Landa]

Hi,

2015-12-30 16:02 GMT+01:00 Markus Neteler :
> Seems we are now ok for 7.0.3RC1?
> https://trac.osgeo.org/grass/wiki/Grass7Planning#a7.0.3tobebackported

+1 for RC1. Martin

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

Re: [GRASS-dev] [GRASS GIS] #2732: Read lidar data as vector points using PDAL

[GRASS GIS]

#2732: Read lidar data as vector points using PDAL
-+-
  Reporter:  wenzeslaus  |  Owner:  wenzeslaus
  Type:  | Status:  new
  enhancement|
  Priority:  major   |  Milestone:  7.1.0
 Component:  Vector  |Version:  svn-trunk
Resolution:  |   Keywords:  lidar, las, laz, v.in.lidar,
   CPU:  |  v.in.pointcloud, v.in.pdal
  Unspecified|   Platform:  Unspecified
-+-

Comment (by wenzeslaus):

 Replying to [comment:6 neteler]:
 > Replying to [comment:5 wenzeslaus]:
 > > * add more [http://www.pdal.io/stages/#filters PDAL-based filters]
 (please suggest!)
 >
 > An idea could be to put an optional RGB point colorization here. It is a
 simple PDAL filter, hence v.in.pdal could read from an additionally
 specified RGB map retrieve the individual colors during import.

 Yes, this is actually on my list already. PDAL colorization could do a
 GeoTIFF while GRASS raster map would have to be done using native
 colorization implemented in GRASS. I think that this is exactly where
 [https://lists.osgeo.org/pipermail/grass-dev/2015-September/076552.html
 using layers and categories for something else than ID and class] will be
 necessary.

--
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 7.0.3: hard freeze started (RC1)

[Markus Neteler]

Hi devs,

just a quick heads-up on this: we are now in "hard freeze" [1] along
with the publication of 7.0.3RC1.
For the more detailed planning and discussions, please see the email
thread entitled

"release plan for 7.0.3"

Please don't reply to this email.

Markus

[1] https://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2732: Read lidar data as vector points using PDAL

[GRASS GIS]

#2732: Read lidar data as vector points using PDAL
-+-
  Reporter:  wenzeslaus  |  Owner:  wenzeslaus
  Type:  | Status:  new
  enhancement|
  Priority:  major   |  Milestone:  7.1.0
 Component:  Vector  |Version:  svn-trunk
Resolution:  |   Keywords:  lidar, las, laz, v.in.lidar,
   CPU:  |  v.in.pointcloud, v.in.pdal
  Unspecified|   Platform:  Unspecified
-+-

Comment (by neteler):

 Replying to [comment:5 wenzeslaus]:
 > * add more [http://www.pdal.io/stages/#filters PDAL-based filters]
 (please suggest!)

 An idea could be to put an optional RGB point colorization here. It is a
 simple PDAL filter, hence v.in.pdal could read from an additionally
 specified RGB map retrieve the individual colors during import.

--
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] #2841: Patch for spelling errors in 7.0.3RC1

[GRASS GIS]

#2841: Patch for spelling errors in 7.0.3RC1
--+-
 Reporter:  sebastic  |  Owner:  grass-dev@…
 Type:  defect| Status:  new
 Priority:  normal|  Milestone:  7.0.3
Component:  Default   |Version:  svn-trunk
 Keywords:|CPU:  All
 Platform:  All   |
--+-
 The lintian QA tool reported a couple of new spelling errors for 7.0.3RC1,
 the attached patches fixes the issues:
  * None the less -> Nonetheless
  * widht -> width
  * preferrable   -> preferable
  * interger  -> integer
  * unitialized   -> uninitialized
  * occured   -> occurred
  * propogate -> propagate

 The patch has been updated for trunk.

--
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] #2841: Patch for spelling errors in 7.0.3RC1

[GRASS GIS]

#2841: Patch for spelling errors in 7.0.3RC1
---+-
  Reporter:  sebastic  |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  normal|  Milestone:  7.0.3
 Component:  Default   |Version:  svn-trunk
Resolution:|   Keywords:
   CPU:  All   |   Platform:  All
---+-
Changes (by sebastic):

 * Attachment "various-typos-trunk.patch" added.


--
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] #2300: v.out.ogr: spatialite support not working

[GRASS GIS]

#2300: v.out.ogr: spatialite support not working
---+---
  Reporter:  hamish|  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  critical  |  Milestone:  7.0.3
 Component:  Vector|Version:  svn-trunk
Resolution:|   Keywords:  v.out.ogr, spatialite
   CPU:  x86-64|   Platform:  Linux
---+---

Comment (by neteler):

 I'd suggest to apply the change to trunk for easier testing.

 (otherwise:
 https://grasswiki.osgeo.org/wiki/Patches#Downloading_patches_from_SVN )

--
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:  critical|  Milestone:  7.0.3
 Component:  wxGUI   |Version:  svn-trunk
Resolution:  |   Keywords:  security, code injection, SQL
   CPU:  |  injection, data loss, v.db.update
  Unspecified|   Platform:  Unspecified
-+-
Changes (by neteler):

 * milestone:  7.0.0 => 7.0.3


--
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] #1662: Caching bug in 3D raster library with large data

[GRASS GIS]

#1662: Caching bug in 3D raster library with large data
---+-
  Reporter:  huhabla   |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  critical  |  Milestone:  7.0.3
 Component:  Raster3D  |Version:  svn-trunk
Resolution:|   Keywords:  3D raster, tiles, cache
   CPU:  x86-32|   Platform:  Linux
---+-
Changes (by neteler):

 * milestone:  7.0.0 => 7.0.3


--
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] #1329: 3D view silently crashes in pl_PL.UTF-8

[GRASS GIS]

#1329: 3D view silently crashes in pl_PL.UTF-8
---+--
  Reporter:  msieczka  |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  critical  |  Milestone:  6.4.6
 Component:  wxGUI |Version:  svn-develbranch6
Resolution:|   Keywords:  3d view
   CPU:  x86-64|   Platform:  Linux
---+--
Changes (by neteler):

 * milestone:  6.5.0 => 6.4.6


Comment:

 Is this still the case in G6.4? In G7 no such issue to my knowledge.

--
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] #909: FTBFS: r.mapcalc in trunk

[GRASS GIS]

#909: FTBFS: r.mapcalc in trunk
+-
  Reporter:  hamish |  Owner:  grass-dev@…
  Type:  defect | Status:  reopened
  Priority:  normal |  Milestone:  7.0.3
 Component:  Compiling  |Version:  svn-trunk
Resolution: |   Keywords:  r.mapcalc
   CPU:  x86-64 |   Platform:  Linux
+-
Changes (by neteler):

 * milestone:  7.0.0 => 7.0.3


Comment:

 What is the state of 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] [GRASS GIS] #729: v.to.rast fails to convert area in LL location when region spans equator

[GRASS GIS]

#729: v.to.rast fails to convert area in LL location when region spans equator
--+--
  Reporter:  marisn   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  major|  Milestone:  6.4.6
 Component:  Vector   |Version:  svn-develbranch6
Resolution:   |   Keywords:  v.to.rast
   CPU:  Unspecified  |   Platform:  Linux
--+--
Changes (by neteler):

 * milestone:  6.5.0 => 6.4.6


Comment:

 I tested with 7.0.3 and the result looks fine.

 Someone else may test with 6.4.svn and update the ticket or close 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] #599: v.out.ascii: new flag to output column headers

[GRASS GIS]

#599: v.out.ascii: new flag to output column headers
--+--
  Reporter:  hamish   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  closed
  Priority:  normal   |  Milestone:  7.0.0
 Component:  Vector   |Version:  svn-develbranch6
Resolution:  fixed|   Keywords:  v.out.ascii
   CPU:  All  |   Platform:  All
--+--
Changes (by neteler):

 * status:  new => closed
 * resolution:   => fixed
 * milestone:  6.5.0 => 7.0.0


Comment:

 Replying to [comment:1 lucadelu]:
 > This ticket should be close, in GRASS7 -c flag do this

 It was implemented in r45454.

 Closing as proposed.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] results in winGRASS7 32bit vs 64bit: should they be identical?

[Markus Neteler]

On Wed, Dec 30, 2015 at 11:48 AM, Helmut Kudrnovsky  wrote:
> hi,
>
> I've done some quick diff test with results of winGRASS7 32bit vs 64bit in
> the NC sample dataset:
>
> r.slope.aspect:
>
> r.mapcalc aspect32bit - aspect64bit => 0
> r.mapcalc slope32bit - slope64bit => 0
>
> they seems to be identical.
>
> r.watershed:
>
> r.mapcalc accum32bit - accum64bit
...

> the results between 32bit and 64bit winGRASS seems not to be identical.
>
> any ideas if they should be identical?

Testing like this will likely show differences due to CPU precision etc.

The test needs to be implemented in a different way, using an epsilon.
Essentially, something like this:

 if(abs(map_A - map_B) <= 1e-8,... )

Like this you check if the difference is very small and below the
acceptable threshold.
In C, we use GRASS_EPSILON for these comparisons.

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

Re: [GRASS-dev] [GRASS-SVN] r67418 - grass-addons/grass7/raster/r.meb

[Paulo van Breugel]

On 29-12-15 20:57, Vaclav Petras wrote:


On Tue, Dec 29, 2015 at 8:29 AM, Markus Neteler > wrote:

>
> > Modified:
> >grass-addons/grass7/raster/r.meb/r.meb.py 
> > Log:
> > bugfix
>
> please be so kind to write these log messages as
>
> r.meb addon: 

There is even a detailed guide here:

https://trac.osgeo.org/grass/wiki/Submitting/General#Commitmessages


OK, thanks, will do



___
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

Re: [GRASS-dev] results in winGRASS7 32bit vs 64bit: should they be identical?

[Helmut Kudrnovsky]

>> any ideas if they should be identical?
>
>Testing like this will likely show differences due to CPU precision etc. 

in this quick test it's the same machine, running 32bit and 64bit winGRASS
binaries ...

>The test needs to be implemented in a different way, using an epsilon.
>Essentially, something like this:
>
>if(abs(map_A - map_B) <= 1e-8,... )

thanks for the hint.



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/results-in-winGRASS7-32bit-vs-64bit-should-they-be-identical-tp5243280p5243283.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] results in winGRASS7 32bit vs 64bit: should they be identical?

[Helmut Kudrnovsky]

>Like this you check if the difference is very small and below the
>acceptable threshold.
>In C, we use GRASS_EPSILON for these comparisons. 

now done with GRASS_EPSILON   1.0e-15

r.mapcalc expression=difftestepsilon = if( abs( accum32bit@accumtest -
accum64bit@accumtest) <= 1.0e-15, 1 , 100 )

attached a screenshot of this map

accum_diff_wingrass32bitvs64bit.png

  



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/results-in-winGRASS7-32bit-vs-64bit-should-they-be-identical-tp5243280p5243286.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

[GRASS-dev] pygrass geometry on region

[Luca Delucchi]

Hi devs,

do you think could be useful to have a function in pygrass to check if
a geometry is contained into computational region?

I need it for g.gui.tplot, so before implement it I would like to know
your opinion, if you think it is useful it could be implemented into
Geo class (in this way every geometry element has this functionality )

-- 
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] results in winGRASS7 32bit vs 64bit: should they be identical?

[Helmut Kudrnovsky]

hi,

I've done some quick diff test with results of winGRASS7 32bit vs 64bit in
the NC sample dataset:

r.slope.aspect: 

r.mapcalc aspect32bit - aspect64bit => 0
r.mapcalc slope32bit - slope64bit => 0

they seems to be identical.

r.watershed:

r.mapcalc accum32bit - accum64bit

r.info map=diffaccum@accumtest  

++
 | Map:  diffaccum@accumtestDate: Wed Dec 30 11:50:35 2015   
|
 | Mapset:   accumtest  Login of Creator: myricaria  
|
 | Location: nc_spm_08_grass7
|
 | DataBase: C:\grassdata
|
 | Title: ( diffaccum )  
|
 | Timestamp: none   
|

||
 |   
|
 |   Type of Map:  raster   Number of Categories: 0  
|
 |   Data Type:DCELL 
|
 |   Rows: 1350  
|
 |   Columns:  1500  
|
 |   Total Cells:  2025000   
|
 |Projection: Lambert Conformal Conic
|
 |N: 228500S: 215000   Res:10
|
 |E: 645000W: 63   Res:10
|
 |   Range of data:min = -8.14907252788544e-010  max =
4.65661287307739e- |
 |   
|
 |   Data Description:   
|
 |generated by r.mapcalc 
|
 |   
|
 |   Comments:   
|
 |accum32bit@accumtest - accum64bit@accumtest
|
 |   
|

++

the results between 32bit and 64bit winGRASS seems not to be identical.

any ideas if they should be identical?



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/results-in-winGRASS7-32bit-vs-64bit-should-they-be-identical-tp5243280.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] #2832: r.damflood return code

[GRASS GIS]

#2832: r.damflood return code
--+-
  Reporter:  pmav99   |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.0.3
 Component:  Addons   |Version:  unspecified
Resolution:  fixed|   Keywords:  r.damflood
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by pmav99):

 Just checked and it works as just fine.

--
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] #2611: add stream power index to GRASS GIS

[GRASS GIS]

#2611: add stream power index to GRASS GIS
--+-
  Reporter:  hellik   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.0.4
 Component:  Raster   |Version:  svn-releasebranch70
Resolution:   |   Keywords:
   CPU:  All  |   Platform:  All
--+-

Comment (by neteler):

 Why two tickets for the same thing?

--
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] #2531: v.parallel/v.segment: strange output

[GRASS GIS]

#2531: v.parallel/v.segment: strange output
--+---
  Reporter:  hellik   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  critical |  Milestone:  7.0.3
 Component:  Vector   |Version:  svn-trunk
Resolution:   |   Keywords:  v.parallel, v.segment
   CPU:  Unspecified  |   Platform:  MSWindows Vista
--+---
Changes (by neteler):

 * milestone:  7.0.0 => 7.0.3


--
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] #583: r.watershed: RUSLE factors are wrong for incomplete basins

[GRASS GIS]

#583: r.watershed: RUSLE factors are wrong for incomplete basins
--+-
  Reporter:  mmetz|  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.0.3
 Component:  Raster   |Version:  unspecified
Resolution:   |   Keywords:  r.watershed
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by neteler):

 * keywords:   => r.watershed
 * milestone:  7.0.0 => 7.0.3


Comment:

 What is the state of 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] [GRASS GIS] #2525: Unable to open sqlite database if path contains non-latin letters

[GRASS GIS]

#2525: Unable to open sqlite database if path contains non-latin letters
--+-
  Reporter:  marisn   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  major|  Milestone:  7.0.3
 Component:  wxGUI|Version:  svn-releasebranch70
Resolution:   |   Keywords:  attribute
   CPU:  Unspecified  |   Platform:  MSWindows Vista
--+-
Changes (by neteler):

 * keywords:   => attribute
 * milestone:  7.0.0 => 7.0.3


--
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.3
 Component:  wxGUI|Version:  svn-trunk
Resolution:   |   Keywords:  vector, display, d.vect
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by neteler):

 * component:  Display => wxGUI
 * milestone:  7.0.0 => 7.0.3


Comment:

 I just tested with today's trunk version and relbranch70, the problem of
 the "replicated" north arrow in LatLong locations is still there. However,
 setting the vector line width works.

 Tested on Fedora 23, with Python: 2.7.10 and wxPython: 3.0.2.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] #2839: r.watershed: calculating stream power index crashes

[GRASS GIS]

#2839: r.watershed: calculating stream power index crashes
-+-
  Reporter:  hellik  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.0.4
 Component:  Raster  |Version:  svn-trunk
Resolution:  |   Keywords:  r.watershed
   CPU:  x86-64  |   Platform:  MSWindows 7
-+-

Comment (by hellik):

 Replying to [comment:1 hellik]:
 >
 > also tested with winGRASS 64bit
 >
 > r.watershed also crashes here.

 some further test with -m flag:

 {{{
 GRASS version: 7.1.svn
 GRASS SVN revision: 67403
 Build date: 2015-12-29
 Build platform: x86_64-w64-mingw32
 }}}

 {{{
 r.watershed -m elevation=elevation@PERMANENT spi=spi_32bit_flagm
 SECTION 1 beginning: Initiating Variables. 4 sections total.
 SECTION 1a: Mark masked and NULL cells
 SECTION 1b: Determining Offmap Flow.
 SECTION 2: A* Search.
 SECTION 3a: Accumulating Surface Flow with MFD.
 SECTION 3b: Adjusting drainage directions.
 SECTION 4: Closing Maps.
 Closing SPI map
 (Wed Dec 30 11:10:31 2015) Command finished (1 min 17 sec)
 }}}

 {{{
 GRASS version: 7.1.svn
 GRASS SVN revision: 67403
 Build date: 2015-12-29
 Build platform: x86_64-w64-mingw32
 }}}


 {{{
 r.watershed -m elevation=elevation@PERMANENT spi=spi_64bit_flagm
 SECTION 1 beginning: Initiating Variables. 4 sections total.
 SECTION 1a: Mark masked and NULL cells
 SECTION 1b: Determining Offmap Flow.
 SECTION 2: A* Search.
 SECTION 3a: Accumulating Surface Flow with MFD.
 SECTION 3b: Adjusting drainage directions.
 SECTION 4: Closing Maps.
 Closing SPI map
 (Wed Dec 30 11:12:25 2015) Command finished (9 sec)
 }}}

 it seems stream power index calculation in r.watershed works with -m flag
 (Enable disk swap memory option) in both 32bit and 64bit winGRASS7trunk,
 but not in normal mode.

--
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] #2611: add stream power index to GRASS GIS

[GRASS GIS]

#2611: add stream power index to GRASS GIS
--+-
  Reporter:  hellik   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.0.4
 Component:  Raster   |Version:  svn-releasebranch70
Resolution:   |   Keywords:
   CPU:  All  |   Platform:  All
--+-

Comment (by hellik):

 Replying to [comment:7 neteler]:
 > Why two tickets for the same thing?

 mix of enhancement and defect?!

--
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] #2392: winGRASS GIS 6.4.5 svn r.li modules - issues with hard coded path to conf files

[GRASS GIS]

#2392: winGRASS GIS 6.4.5 svn r.li modules - issues with hard coded path to conf
files
---+-
  Reporter:  hellik|  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  critical  |  Milestone:  6.4.6
 Component:  Raster|Version:  svn-releasebranch64
Resolution:|   Keywords:  wingrass, r.li
   CPU:  x86-32|   Platform:  MSWindows 7
---+-

Comment (by neteler):

 A lot of love has been given to r.li in GRASS GIS 7.
 Maybe we can close this ticket as "fixed in new stable release"?

--
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] #2393: winGRASS GIS 6.4.5 svn r.li.setup not working

[GRASS GIS]

#2393: winGRASS GIS 6.4.5 svn r.li.setup not working
---+-
  Reporter:  hellik|  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  critical  |  Milestone:  6.4.6
 Component:  Raster|Version:  svn-releasebranch64
Resolution:|   Keywords:  wingrass, r.li
   CPU:  x86-32|   Platform:  MSWindows 7
---+-

Comment (by neteler):

 A lot of love has been given to r.li in GRASS GIS 7.

 There is `g.gui.rlisetup` - Configuration tool for r.li modules:
 https://grass.osgeo.org/grass70/manuals/g.gui.rlisetup.html

 Maybe we can close this ticket as "fixed in new stable release"?

--
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] #2477: r.out.gdal installed from 64bit OSGeo4W doesn't work

[GRASS GIS]

#2477: r.out.gdal installed from 64bit OSGeo4W doesn't work
+-
  Reporter:  tmizu23|  Owner:  grass-dev@…
  Type:  defect | Status:  closed
  Priority:  critical   |  Milestone:  6.4.6
 Component:  Raster |Version:  6.4.3
Resolution:  duplicate  |   Keywords:
   CPU:  x86-64 |   Platform:  MSWindows 7
+-
Changes (by neteler):

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


Comment:

 There are new efforts ongoing for wingrass7 64bit branch, see #1213 -
 please try that:

 https://grass.osgeo.org/download/software/ms-windows/

 Since there will be unlikely a wingrass6 64bit package, I take liberty to
 close this ticket.
 Please report any wingrass7 64bit related issues in #1213.

--
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] #1468: i.vi only produces 0 value maps

[GRASS GIS]

#1468: i.vi only produces 0 value maps
--+-
  Reporter:  cmbarton |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.0.3
 Component:  Default  |Version:  svn-trunk
Resolution:  fixed|   Keywords:  i.vi
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by neteler):

 * status:  new => closed
 * resolution:   => fixed
 * milestone:  7.0.0 => 7.0.3


Comment:

 I have added working examples in r67425 (and r67426).

 i.vi produces output, it is needed to use reflectance values as per
 manual.

 Closing.

--
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] #906: r.out.gdal (VRT) broken output

[GRASS GIS]

#906: r.out.gdal (VRT) broken output
---+--
  Reporter:  epifanio  |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  normal|  Milestone:  6.4.6
 Component:  Raster|Version:  svn-develbranch6
Resolution:|   Keywords:  r.out.gdal, VRT
   CPU:  x86-64|   Platform:  MacOSX
---+--
Changes (by neteler):

 * milestone:  6.5.0 => 6.4.6


Old description:

> tring to generate a VRT file using r.out.gdal i get a broken file (not
> loadable in ossim and qgis)
> using gdal_translate i get a different results.
>

> using  r.out.gdal
>
> r.out.gdal input=geology at PERMANENT format=VRT type=Byte
> output=name.vrt
>
> r.out.gdal input=geology at PERMANENT format=VRT type=Byte
> output=name.vrt
> Exporting to GDAL data type: Byte
> Checking GDAl data type and nodata value
> Input raster map contains cells with NULL-value (no-data). The value 255
> will be used to represent no-data values in the input map. You can
> specify a nodata value with the nodata option.
> Exporting to GDAL raster
> ERROR 1: Writing through VRTSourcedRasterBand is not
> supported.
> Unable to write GDAL raster file
> Unable to export raster map 
> r.out.gdal complete.
> (Thu Feb  4 00:53:22 2010) Command finished (0 sec)
>
> i get this output :
>

> #
>
> 
>   PROJCS[UTM Zone 13, Northern
> Hemisphere,GEOGCS[clark66,DATUM[North_American_Datum_1927,SPHEROID[Clarke_1866,6378206.4,294.9786982]],PRIMEM[Greenwich,0],UNIT[degree,0.0174532925199433]],PROJECTION[Transverse_Mercator],PARAMETER[latitude_of_origin,0],PARAMETER[central_meridian,-105],PARAMETER[scale_factor,0.9996],PARAMETER[false_easting,50],PARAMETER[false_northing,0],UNIT[meter,1]]
> 5.9001e+05,  1.e+01,
> 0.e+00,  4.9280e+06,  0.e+00,
> -1.e+01
>   
> 2.55E+02
> Palette
> 
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
> 
>   
> 
>
> #
>

> this output is different from the gdal output :
>
> gdal_translate -of VRT
> /Users/sasha/Downloads/spearfish60/PERMANENT/cellhd/geology
> /Users/sasha/Desktop/geology.vrt
>
> #
>
> 
>   PROJCS[UTM Zone 13, Northern
> Hemisphere,GEOGCS[clark66,DATUM[North_American_Datum_1927,SPHEROID[Clarke_1866,6378206.4,294.9786982]],PRIMEM[Greenwich,0],UNIT[degree,0.0174532925199433]],PROJECTION[Transverse_Mercator],PARAMETER[latitude_of_origin,0],PARAMETER[central_meridian,-105],PARAMETER[scale_factor,0.9996],PARAMETER[false_easting,50],PARAMETER[false_northing,0],UNIT[meter,1]]
> 5.9000e+05,  1.e+02,
> 0.e+00,  4.9280e+06,  0.e+00,
> -1.e+02
>   
>   
> 
>   0
> 
> 0.00E+00
> Palette
> 
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
> 
> 
>relativeToVRT="0">/Users/sasha/Downloads/spearfish60/PERMANENT/cellhd/geology
>   1
>DataType="Byte" BlockXSize="190" BlockYSize="1"/>
>   
>   
> 
>   
> 
>
> #
>

> the grass output doesn't include :
>
> 
> ...
> 
>
> it is missed and tring to load the output in ossim or qgis it is not
> displayed.
>
> from a chat on #gdal seems the problem is related to the "create_copy()"
> usage .. but i'm not able to debug it.
>
> thanks!
>
> Massimo.

New description:

 tring to generate a VRT file using r.out.gdal i get a broken file (not
 loadable in ossim and qgis)
 using gdal_translate i get a different results.


 using  r.out.gdal

 {{{

 r.out.gdal input=geology@PERMANENT format=VRT type=Byte output=name.vrt

 r.out.gdal input=geology@PERMANENT format=VRT type=Byte output=name.vrt
 Exporting to GDAL data type: Byte
 Checking GDAl data type and nodata value
 Input raster map contains cells with NULL-value (no-data). The value 255
 will be used to represent no-data values in the input map. You can specify
 a nodata value with the nodata option.
 Exporting to GDAL raster
 ERROR 1: Writing through VRTSourcedRasterBand is not
 supported.
 Unable to write GDAL raster file
 Unable to export raster map 
 r.out.gdal complete.
 (Thu Feb  4 00:53:22 2010) Command finished (0 sec)
 }}}

 i get this output :


 {{{

 #

 
   PROJCS[UTM Zone 13, Northern
 

Re: [GRASS-dev] [GRASS GIS] #906: r.out.gdal (VRT) broken output

[GRASS GIS]

#906: r.out.gdal (VRT) broken output
---+--
  Reporter:  epifanio  |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  normal|  Milestone:  6.4.6
 Component:  Raster|Version:  svn-develbranch6
Resolution:|   Keywords:  r.out.gdal, VRT
   CPU:  x86-64|   Platform:  MacOSX
---+--

Comment (by neteler):

 I have tried in 6.4.svn:

 {{{
 GRASS 6.4.6svn (nc_spm_08):~ > r.out.gdal input=geology_30m format=VRT
 type=UInt16 output=name.vrt
 Exporting to GDAL data type: UInt16
 Checking GDAL data type and nodata value
  100%
 Exporting to GDAL raster
 ERROR 1: Writing through VRTSourcedRasterBand is not supported.
 WARNING: Unable to write GDAL raster file
 WARNING: Unable to export raster map 
 r.out.gdal complete.
 }}}

 Indeed, the VRT file is generated but without reference to the
 "geology_30m" map.

 Same thing in GRASS GIS 7.0.3svn. I suppose that it is simply not
 supported.

--
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] #964: r.timestamp: add a flag to use current date and time for timestamp

[GRASS GIS]

#964: r.timestamp: add a flag to use current date and time for timestamp
--+--
  Reporter:  epatton  |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  trivial  |  Milestone:  7.0.4
 Component:  Raster   |Version:  svn-develbranch6
Resolution:   |   Keywords:  r.timestamp
   CPU:  x86-64   |   Platform:  Linux
--+--
Changes (by neteler):

 * keywords:  timestamp, insert => r.timestamp
 * milestone:  6.5.0 => 7.0.4


Comment:

 See also #2346

--
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] #2346: r.timestamp: support also YYYY-DOY

[GRASS GIS]

#2346: r.timestamp: support also -DOY
-+-
  Reporter:  neteler |  Owner:  grass-dev@…
  Type:  | Status:  new
  enhancement|
  Priority:  normal  |  Milestone:  7.0.4
 Component:  LibGIS  |Version:  svn-releasebranch70
Resolution:  |   Keywords:  r.timestamp, t.register, temporal,
   CPU:  |  doy
  Unspecified|   Platform:  All
-+-
Changes (by neteler):

 * milestone:  7.0.0 => 7.0.4


Comment:

 See also #964

--
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] #774: i.rgb.his, i.his.rgb, d.his support for >8 bit

[GRASS GIS]

#774: i.rgb.his, i.his.rgb, d.his support for >8 bit
--+-
  Reporter:  hamish   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.0.4
 Component:  Raster   |Version:  svn-develbranch6
Resolution:   |   Keywords:  i.rgb.his, i.his.rgb, d.his
   CPU:  All  |   Platform:  All
--+-
Changes (by neteler):

 * milestone:  6.5.0 => 7.0.4


Comment:

 See also #2048

--
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] #2048: i.pansharpen limited to 8-bit imagery

[GRASS GIS]

#2048: i.pansharpen limited to 8-bit imagery
-+-
  Reporter:  nikosa  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.0.4
 Component:  Imagery |Version:  svn-trunk
Resolution:  |   Keywords:  i.pansharpen, sharpening, fusion,
 |  brovey, ihs, pca, 8-bit
   CPU:  All |   Platform:  Unspecified
-+-
Changes (by neteler):

 * milestone:  7.0.0 => 7.0.4


Comment:

 See also #774

--
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] #863: set_env/unset_env should release memory

[GRASS GIS]

#863: set_env/unset_env should release memory
--+-
  Reporter:  rblazek  |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  6.5.0
 Component:  LibGIS   |Version:  svn-trunk
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  All
--+-

Comment (by neteler):

 See also #864

--
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] #1148: bug in v.net

[GRASS GIS]

#1148: bug in v.net
---+-
  Reporter:  Risharky  |  Owner:  grass-dev@…
  Type:  defect| Status:  closed
  Priority:  normal|  Milestone:  6.5.0
 Component:  Vector|Version:  svn-trunk
Resolution:  fixed |   Keywords:  v.net
   CPU:  x86-64|   Platform:  Linux
---+-
Changes (by neteler):

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


Comment:

 A lot of improvements have been implemented in GRASS GIS 7. Please update
 in case you haven't.

 Since the ticket is very old, I take liberty to close it. If issues still
 occur in G7, please reopen with a new milestone.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] config.guess update

[Markus Neteler]

On Fri, Dec 18, 2015 at 3:50 PM, Martin Landa  wrote:
> Hi,
>
> 2015-12-18 8:49 GMT+01:00 Markus Neteler :
>> If there are no objections, I would update these two files soon (like
>> in the past 10+ years).
>
> no objection, Martin

done in r67431 and r67432.

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

[GRASS-dev] strange behavior of gselect.Select

[Luca Delucchi]

Hi devs,

working on g.gui.tplot I have problems with gselect.Select in the Vector panel.
Right now there is a wx.EVT_TEXT event and it works well if the vector
temporal dataset is selected by the scroll down menu but it return
errors if the user try to write him self the name of the temporal
dataset, because for each added character it run the connected
function

GRASS_INFO_MESSAGE(13258,1): ERROR: Space time vector dataset  not found
GRASS_INFO_END(13258,1)
Traceback (most recent call last):
  File 
"/home/lucadelu/compilati/grass_trunk/dist.x86_64-unknown-linux-gnu/gui/wxpython/tplot/frame.py",
line 842, in OnVectorSelected
column='name')
  File 
"/home/lucadelu/compilati/grass_trunk/dist.x86_64-unknown-linux-gnu/etc/python/grass/script/core.py",
line 461, in read_command
return handle_errors(returncode, stdout, args, kwargs)
  File 
"/home/lucadelu/compilati/grass_trunk/dist.x86_64-unknown-linux-gnu/etc/python/grass/script/core.py",
line 329, in handle_errors
returncode=returncode)
grass.exceptions.CalledModuleError: L'esecuzione del modulo None
['t.vect.list', '-s', 'column=name', 'input=p'] è terminata con errori
Processo terminato con codice di return diverso da zero 1. Vedi gli
errori nel (error) output.

So I tried to change the event in wx.EVT_TEXT_ENTER this not working
at all, no error and no call to the function.

Instead if I use wx.EVT_COMBOBOX_CLOSEUP it works when I select the
temporal dataset but no when the user types the name.

My idea is to replace wx.EVT_TEXT with both wx.EVT_TEXT_ENTER and
wx.EVT_COMBOBOX_CLOSEUP as suggested in the attached patch but I would
like why wx.EVT_TEXT_ENTER is not working at all, do you have any
idea?

thanks

-- 
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
Index: gui/wxpython/tplot/frame.py
===
--- gui/wxpython/tplot/frame.py (revision 67424)
+++ gui/wxpython/tplot/frame.py (working copy)
@@ -219,7 +219,9 @@
  id=wx.ID_ANY,
  
size=globalvar.DIALOG_GSELECT_SIZE,
  type='stvds', multiple=True)
-self.datasetSelectV.Bind(wx.EVT_TEXT, self.OnVectorSelected)
+self.datasetSelectV.Bind(wx.EVT_TEXT_ENTER, self.OnVectorSelected)
+self.datasetSelectV.Bind(wx.EVT_COMBOBOX_CLOSEUP,
+ self.OnVectorSelected)
 
 self.attribute = gselect.ColumnSelect(parent=self.controlPanelVector)
 self.attributeLabel = wx.StaticText(parent=self.controlPanelVector,
@@ -838,8 +840,14 @@
 def OnVectorSelected(self, event):
 """Update the controlbox related to stvds"""
 dataset = self.datasetSelectV.GetValue().strip()
-vect_list = grass.read_command('t.vect.list', flags='s', input=dataset,
-   col='name')
+try:
+vect_list = grass.read_command('t.vect.list', flags='s',
+   input=dataset, column='name')
+except Exception:
+self.attribute.Clear()
+GError(parent=self, message=_("Invalid input temporal dataset"),
+   showTraceback=False)
+return
 vect_list = list(set(sorted(vect_list.split(
 for vec in vect_list:
 self.attribute.InsertColumns(vec, 1)
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] release plan for 7.0.3

[Markus Neteler]

Hi devs,

as you may have noted, I made some further trac ticket cleanup.

Seems we are now ok for 7.0.3RC1?
https://trac.osgeo.org/grass/wiki/Grass7Planning#a7.0.3tobebackported

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

[GRASS-dev] r.mapcalc: warning: field width should have type 'int', but argument has type 'yy_size_t'

[Markus Neteler]

Hi,

compiling relbranch70 (likely the same on trunk), I got

mapcalc.tab.c:1995:18: warning: passing 'const char *' to parameter of
type 'char *' discards qualifiers
[-Wincompatible-pointer-types-discards-qualifiers]
yyerror (yymsgp);
 ^~
mapcalc.y:78:20: note: passing argument to parameter 's' here
void yyerror(char *s);
   ^
mapcalc.l:218:38: warning: field width should have type 'int', but
argument has type 'yy_size_t' (aka 'unsigned long') [-Wformat]
fprintf(stderr, "syntax error: '%*s'\n",
yyleng, yytext);
~~^  ~~
1 warning generated.
1 warning generated.

Not sure if and how to fix that.

Markus
___
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.3
 Component:  Display |Version:  svn-trunk
Resolution:  |   Keywords:  vector, display, d.vect,
   CPU:  |  d.northarrow
  Unspecified|   Platform:  Unspecified
-+-
Changes (by annakrat):

 * keywords:  vector, display, d.vect => vector, display, d.vect,
   d.northarrow
 * component:  wxGUI => Display


--
Ticket URL: 
GRASS GIS 

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