Re: [GRASS-dev] [release planning] 7.4.0

[Maris Nartiss]

2017-11-10 19:39 GMT+02:00 Moritz Lennert :
> Hi Maris,
>
> v.profile still uses the old buffering library methods which has quite
> a lot of issues.

The best question then is why we are still shipping library methods
that are *known* to be broken? If they are so broke, they must be
changed to fail all the time to prevent end-users from getting wrong
results.

> As an example, I attach the output map of the following example:
>
> v.profile input=geonames_NC@PERMANENT output=- separator=comma dp=3
> buffer=500 profile_map=roadsmajor@PERMANENT profile_where=cat=193
> map_output=test_profile
>
> I also attach the equivalent v.buffer output:
>
> v.buffer -c roadsmajor where=cat=193 dist=500 out=buff500
>
> Would it be possible for you, Maris, to change to the GEOS method used
> in v.buffer in order to get the same buffering output ?

I can take a look at v.buffer to see how GEOS is used. Still I don't
know how soon I'll have time for it :(

> This is not only formal as you can see when you use the following
> vector points as input:
>
> v.in.ascii in=- out=test_points << EOF
> 626382.68026139|228917.44816672|1
> 626643.91393428|228738.2879083|2
> 626907.14939778|228529.10079092|3
> EOF
>
> v.profile then misses out on point 2, even though it is within 500m:
>
> v.profile input=test_points output=- separator=comma dp=3 buffer=500
> profile_map=roadsmajor@PERMANENT profile_where=cat=193
> Number,Distance,cat,dbl_1,dbl_2,int_1
> 1,2102.114,3,626907.14939778,228529.10079092,3
> 2,2960.822,1,626382.68026139,228917.44816672,1

I see. I would +1 for setting current GRASS buffer functions to call
G_fatal_error till they get fixed or replaced by GEOS version. I also
would +1 to block 7.4.0 release till a final action is made (fatal
error or a fix). Quality (correctness) should be our priority.

> Moritz

Māris.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] QGIS-Developer] GRASS and SAGA providers in 3

[Markus Neteler]

On Sun, Nov 5, 2017 at 1:53 PM, Markus Neteler  wrote:
> Update: it is going on well!
> https://github.com/qgis/QGIS/pull/5426
>
> An open wish is this enhancement ticket (r.mapcalculator script):
> https://trac.osgeo.org/grass/ticket/3431

AFAIK it got merged! A huge work has been done:

https://github.com/qgis/QGIS/commit/cab807dc309067dcb72b6b052f0608c88755af91
"393 changed files with 4,324 additions and 3,545 deletions"

> Médéric will appreciate testing of the pull request.

Now testing will be easier.

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

[GRASS-dev] winGRASS not built/broken

[Helmut Kudrnovsky]

it seems there is an issue with winGRASS:

32 bit:

https://wingrass.fsv.cvut.cz/grass73/x86/logs/log-r71641-1/error.log

GRASS GIS 7.3.svn r71641 compilation log
--
Started compilation: Tue Nov  7 21:30:33 2017
--
Errors in:
/c/msys32/usr/src/grass_trunk/raster/r.in.gdal
--
In case of errors please change into the directory with error and run
'make'.
If you get multiple errors, you need to deal with them in the order they
appear in the error log. If you get an error building a library, you will
also get errors from anything which uses the library.
--
Finished compilation: Tue Nov  7 22:05:34 2017

64bit:

last build:

WinGRASS-7.3.svn-r71641-404-Setup-x86_64.exe08-Nov-2017 07:46   73M 





-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] winGRASS not built/broken

[Markus Metz]

On Sat, Nov 11, 2017 at 4:25 PM, Helmut Kudrnovsky  wrote:
>
> it seems there is an issue with winGRASS:
>
> 32 bit:
>
> https://wingrass.fsv.cvut.cz/grass73/x86/logs/log-r71641-1/error.log
>
> GRASS GIS 7.3.svn r71641 compilation log
> --
> Started compilation: Tue Nov  7 21:30:33 2017
> --
> Errors in:
> /c/msys32/usr/src/grass_trunk/raster/r.in.gdal

The error is:
main.c:345: undefined reference to `GDALSetCacheMax64@4'

strange, GDALSetCacheMax64 should exist on 32 bit Windows, even if "the
maximum amount of memory that can be addressed by a process might be 2 GB
or 3 GB, depending on the operating system capabilities."

Falling back to GDALSetCacheMax for MS Windows (including 64 bit Windows)
in r71677.

Markus M

> --
> In case of errors please change into the directory with error and run
> 'make'.
> If you get multiple errors, you need to deal with them in the order they
> appear in the error log. If you get an error building a library, you will
> also get errors from anything which uses the library.
> --
> Finished compilation: Tue Nov  7 22:05:34 2017
>
> 64bit:
>
> last build:
>
> WinGRASS-7.3.svn-r71641-404-Setup-x86_64.exe08-Nov-2017 07:46
73M
>
>
>
>
>
> -
> best regards
> Helmut
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Missing package "six" for Windows compilation

[Andy Wickert]

Hello GRASS developers,

The "six" python package, required by Matplotlib, seems to be missing on
the Windows side. As a result, all packages requiring it are throwing
errors. For example, as seen at
http://wingrass.fsv.cvut.cz/grass72/x86/addons/latest/logs/:

Traceback (most recent call last):
  File 
"C:/Users/landa/grass_packager/grass722/x86/addons/v.faultdirections/scripts/v.faultdirections.py",
line 50, in 
import matplotlib #required by windows
  File "C:\OSGeo4W32\apps\Python27\lib\site-packages\matplotlib\__init__.py",
line 105, in 
import six*ImportError: No module named six
*/c/msys32/usr/src/grass722/include/Make/Html.make:14: recipe for
target 'v.faultdirections.tmp.html' failed
make: *** [v.faultdirections.tmp.html] Error 1
rm v.faultdirections.tmp.html


Could someone with permissions please install this and test with an "import
matplotlib"?

Thank you!

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

Re: [GRASS-dev] Missing package "six" for Windows compilation

[Helmut Kudrnovsky]

Andy Wickert-2 wrote
> Hello GRASS developers,
> 
> The "six" python package, required by Matplotlib, seems to be missing on
> the Windows side. As a result, all packages requiring it are throwing
> errors. For example, as seen at
> http://wingrass.fsv.cvut.cz/grass72/x86/addons/latest/logs/:
> 
> Traceback (most recent call last):
>   File
> "C:/Users/landa/grass_packager/grass722/x86/addons/v.faultdirections/scripts/v.faultdirections.py",
> line 50, in 
> 
> import matplotlib #required by windows
>   File
> "C:\OSGeo4W32\apps\Python27\lib\site-packages\matplotlib\__init__.py",
> line 105, in 
> 
> import six*ImportError: No module named six
> */c/msys32/usr/src/grass722/include/Make/Html.make:14: recipe for
> target 'v.faultdirections.tmp.html' failed
> make: *** [v.faultdirections.tmp.html] Error 1
> rm v.faultdirections.tmp.html
> 
> 
> Could someone with permissions please install this and test with an
> "import
> matplotlib"?
> 
> Thank you!

it's interesting, as e.g. r.hypso which also uses matplotlip builds in
winGRASS64bit addon
https://wingrass.fsv.cvut.cz/grass73/x86_64/addons/grass-7.3.svn/logs/

but fails in winGRASS32bit addon:
https://wingrass.fsv.cvut.cz/grass73/x86/addons/grass-7.3.svn/logs/

the same for v.faultdirections, it builds in winGRASS64bit addon






-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] winGRASS not built/broken

[Even Rouault]

On samedi 11 novembre 2017 17:44:18 CET Markus Metz wrote:
> On Sat, Nov 11, 2017 at 4:25 PM, Helmut Kudrnovsky  wrote:
> > it seems there is an issue with winGRASS:
> > 
> > 32 bit:
> > 
> > https://wingrass.fsv.cvut.cz/grass73/x86/logs/log-r71641-1/error.log
> > 
> > GRASS GIS 7.3.svn r71641 compilation log
> > --
> > Started compilation: Tue Nov  7 21:30:33 2017
> > --
> > Errors in:
> > /c/msys32/usr/src/grass_trunk/raster/r.in.gdal
> 
> The error is:
> main.c:345: undefined reference to `GDALSetCacheMax64@4'
> 
> strange, GDALSetCacheMax64 should exist on 32 bit Windows, even if "the
> maximum amount of memory that can be addressed by a process might be 2 GB
> or 3 GB, depending on the operating system capabilities."
> 
> Falling back to GDALSetCacheMax for MS Windows (including 64 bit Windows)
> in r71677.

The issue is probably that this build uses GDAL from OSGeo4W, into which GDAL 
has been 
configured and compiled with MSVC. Thus HAVE_LONG_LONG is not defined in 
cpl_config.h, 
and the GDALSetCacheMax64( GIntBig ) must evaluate to GDALSetCacheMax64 ( int ) 
when 
including from GRASS. I guess defining HAVE_LONG_LONG would solve the issue .

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] winGRASS not built/broken

[Helmut Kudrnovsky]

 >that this build uses GDAL from OSGeo4W,

yes it uses OSGeo4W GDAL



-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] QGIS-Developer] GRASS and SAGA providers in 3

[Helmut Kudrnovsky]

Markus Neteler wrote
> On Sun, Nov 5, 2017 at 1:53 PM, Markus Neteler <

> neteler@

> > wrote:
>> Update: it is going on well!
>> https://github.com/qgis/QGIS/pull/5426
>>
>> An open wish is this enhancement ticket (r.mapcalculator script):
>> https://trac.osgeo.org/grass/ticket/3431
> 
> AFAIK it got merged! A huge work has been done:
> 
> https://github.com/qgis/QGIS/commit/cab807dc309067dcb72b6b052f0608c88755af91
> "393 changed files with 4,324 additions and 3,545 deletions"
> 
>> Médéric will appreciate testing of the pull request.
> 
> Now testing will be easier.

tested now in windows.

tested some raster commands (e.g. r.slope.aspect, r.contour, ...); seems to
work so far.

but the vector commands may need some tuning:

2017-11-11T18:19:56 INFOGRASS GIS 7 execution commands
g.proj -c proj4="+proj=lcc +lat_1=36.16
+lat_2=34.34 +lat_0=33.75 +lon_0=-79 +x_0=609601.22 +y_0=0
+ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs"
v.external input="D:\wd\qgistest\contour.sqlite" 
output="a5a07313c02ab18"
--overwrite -o
g.region n=228495.0 s=215005.0 e=644995.0 w=630005.0
v.buffer  input=a5a07313c02ab18 distance=100 
tolerance=0.01
output=output5db983361f3d4e40a36a8b40be12d7ca --overwrite
v.out.ogr -c type=auto  
input="output5db983361f3d4e40a36a8b40be12d7ca"
output="D:\wd\qgistest\buffer.shp" format=ESRI_Shapefile --overwrite
2017-11-11T18:19:57 INFOGRASS GIS 7 execution console output
Cleaning up temporary files...

Starting GRASS GIS...

WARNING: Concurrent mapset locking is not supported on 
Windows

Executing

...



C:\OSGeo4W64\bin>chcp 1252 1>NUL 



C:\OSGeo4W64\bin>g.proj -c proj4="+proj=lcc 
+lat_1=36.16
+lat_2=34.34 +lat_0=33.75 +lon_0=-79 +x_0=609601.22 +y_0=0
+ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs" 

Default region was updated to the new projection, but 
if you have
multiple mapsets `g.region -d` should be run in each to update the region
from the default

Projection information updated



C:\OSGeo4W64\bin>v.external 
input="D:\wd\qgistest\contour.sqlite"
output="a5a07313c02ab18" --overwrite -o 

Building topology for vector map 
...

Using external data format 'SQLite' (feature type 
'linestring')

Registering primitives...



110 primitives registered

32549 vertices registered

Number of nodes: 125

Number of primitives: 110

Number of points: 0

Number of lines: 110

Number of boundaries: 0

Number of centroids: 0

Number of areas: 0

Number of isles: 0

v.external complete. Link to vector map 
 created.



C:\OSGeo4W64\bin>g.region n=228495.0 s=215005.0 
e=644995.0 w=630005.0 



C:\OSGeo4W64\bin>v.buffer  input=a5a07313c02ab18 
distance=100
tolerance=0.01 output=output5db983361f3d4e40a36a8b40be12d7ca --overwrite 

Buffering features...

ERROR: Vect_read_line_geos(): only native format 
supported <= !!!



C:\OSGeo4W64\bin>v.out.ogr -c type=auto 
input="output5db983361f3d4e40a36a8b40be12d7ca"
output="D:\wd\qgistest\buffer.shp" format=ESRI_Shapefile --overwrite 

ERROR: Vector map 
 not found



C:\OSGeo4W64\bin>exit
  

Re: [GRASS-dev] QGIS-Developer] GRASS and SAGA providers in 3

[Helmut Kudrnovsky]

>it seems that some vector commands (e.g. v.buffer) doesn't work with
>v.external'ed vectors. 

ok, in the settings, following option can be set/unset:

"For vector layers, use v.external (faster) instead of v.in.ogr"

unsetting this option, also vector commands seems to work.



-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Missing package "six" for Windows compilation

[Andy Wickert]

Interesting. I noticed this while working on some codes for GSFLOW, the
USGS groundwater--surface water module, and found a *Tkinter* missing error
message in those for GRASS 7.3 64-bit:

Traceback (most recent call last):
  File 
"C:/Users/landa/grass_packager/grass73/x86_64/addons/v.gsflow.export/scripts/v.gsflow.export.py",
line 108, in 
from matplotlib import pyplot as plt
  File "C:\OSGeo4W64\apps\Python27\lib\site-packages\matplotlib\pyplot.py",
line 115, in 
_backend_mod, new_figure_manager, draw_if_interactive, _show = pylab_setup()
  File 
"C:\OSGeo4W64\apps\Python27\lib\site-packages\matplotlib\backends\__init__.py",
line 32, in pylab_setup
globals(),locals(),[backend_name],0)
  File 
"C:\OSGeo4W64\apps\Python27\lib\site-packages\matplotlib\backends\backend_tkagg.py",
line 6, in 
from six.moves import tkinter as Tk
  File "C:\OSGeo4W64\apps\Python27\lib\site-packages\six.py", line
203, in load_module
mod = mod._resolve()
  File "C:\OSGeo4W64\apps\Python27\lib\site-packages\six.py", line
115, in _resolve
return _import_module(self.mod)
  File "C:\OSGeo4W64\apps\Python27\lib\site-packages\six.py", line 82,
in _import_module
__import__(name)*ImportError: No module named Tkinter
*/c/msys64/usr/src/grass_trunk/include/Make/Html.make:14: recipe for
target 'v.gsflow.export.tmp.html' failed
make: *** [v.gsflow.export.tmp.html] Error 1
rm v.gsflow.export.tmp.html


Matplotlib wasn't needed for these modules (it's part of my standard set of
imports, which I copied/pasted), so I removed it and they should hopefully
compile fine the next time the server builds everything. But there is some
underlying package problem...

Andy

On Sat, Nov 11, 2017 at 10:57 AM, Helmut Kudrnovsky  wrote:

> Andy Wickert-2 wrote
> > Hello GRASS developers,
> >
> > The "six" python package, required by Matplotlib, seems to be missing on
> > the Windows side. As a result, all packages requiring it are throwing
> > errors. For example, as seen at
> > http://wingrass.fsv.cvut.cz/grass72/x86/addons/latest/logs/:
> >
> > Traceback (most recent call last):
> >   File
> > "C:/Users/landa/grass_packager/grass722/x86/addons/
> v.faultdirections/scripts/v.faultdirections.py",
> > line 50, in
> > 
> > import matplotlib #required by windows
> >   File
> > "C:\OSGeo4W32\apps\Python27\lib\site-packages\matplotlib\__init__.py",
> > line 105, in
> > 
> > import six*ImportError: No module named six
> > */c/msys32/usr/src/grass722/include/Make/Html.make:14: recipe for
> > target 'v.faultdirections.tmp.html' failed
> > make: *** [v.faultdirections.tmp.html] Error 1
> > rm v.faultdirections.tmp.html
> >
> >
> > Could someone with permissions please install this and test with an
> > "import
> > matplotlib"?
> >
> > Thank you!
>
> it's interesting, as e.g. r.hypso which also uses matplotlip builds in
> winGRASS64bit addon
> https://wingrass.fsv.cvut.cz/grass73/x86_64/addons/grass-7.3.svn/logs/
>
> but fails in winGRASS32bit addon:
> https://wingrass.fsv.cvut.cz/grass73/x86/addons/grass-7.3.svn/logs/
>
> the same for v.faultdirections, it builds in winGRASS64bit addon
>
>
>
>
>
>
> -
> best regards
> Helmut
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3066: g.gui.gcp not handling vectors

[GRASS GIS]

#3066: g.gui.gcp not handling vectors
-+
  Reporter:  madi|  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  major   |  Milestone:  7.4.0
 Component:  wxGUI   |Version:  svn-trunk
Resolution:  |   Keywords:  georeferencing, vector
   CPU:  x86-64  |   Platform:  Linux
-+

Comment (by mmetz):

 Replying to [ticket:3066 madi]:
 > I have a group of vectors to georeference, but can't create a group of
 vectors using g.gui.gcp.

 Fixed in trunk r71678

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Missing package "six" for Windows compilation

[Helmut Kudrnovsky]

>But there is some underlying package problem...

it seems six is in the winGRASS 64bit build environment, but not in the
winGRASS 32bit build environment.



-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3429: g.gui.iclass: segfault when loading vector layer

[GRASS GIS]

#3429: g.gui.iclass: segfault when loading vector layer
--+--
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.4.0
 Component:  wxGUI|Version:  svn-trunk
Resolution:   |   Keywords:  g.gui.iclass import segfault
   CPU:  Unspecified  |   Platform:  Unspecified
--+--

Comment (by mlennert):

 Replying to [comment:2 annakrat]:
 > Replying to [comment:1 mlennert]:
 > > Replying to [ticket:3429 mlennert]:
 > > > * define group
 > > > * define classes
 > > > * digitize a few training areas
 > > > * save training areas to vector map
 > > > * close g.gui.iclass
 > > > * reopen g.gui.iclass
 > > > * import saved vector maps
 > > > => segfault
 > >
 > > I still have this problem. Can anyone reproduce ? Does anyone have a
 hint on how to debug this ?
 >
 > Yes, I looked at it couple days ago, and I could see where the problem
 is, but I didn't have time to fix it. The problem is somewhere in
 iclass/frame, how it calls the C functions, but I need to explore it more.
 The simplest way to debug this (for me) is using debugger integrated into
 qtcreator (you need to import grass as a project there). First you run
 g.gui.iclass, then in qtcreator you attach this external process and then
 do the actions in gui and the debugger shows you the place where it
 crashes.
 >

 Thanks for the hint, but I have been pulling my hair out trying to make
 this work. On my machine, as soon as I attach to the process, the
 g.gui.iclass window blanks out completely and I cannot do anything. As
 soon as I detach the debugger from the process, I can again see the GUI
 window as expected and work with it. This makes it difficult to "do the
 action"...

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Missing package "six" for Windows compilation

[Andy Wickert]

How about tkinter on Win64?

*ImportError: No module named Tkinter*


On Sat, Nov 11, 2017 at 12:19 PM, Helmut Kudrnovsky  wrote:

> >But there is some underlying package problem...
>
> it seems six is in the winGRASS 64bit build environment, but not in the
> winGRASS 32bit build environment.
>
>
>
> -
> best regards
> Helmut
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] winGRASS not built/broken

[Markus Metz]

On Sat, Nov 11, 2017 at 6:01 PM, Even Rouault 
wrote:
>
> On samedi 11 novembre 2017 17:44:18 CET Markus Metz wrote:
>
> > On Sat, Nov 11, 2017 at 4:25 PM, Helmut Kudrnovsky 
wrote:
>
> > > it seems there is an issue with winGRASS:
>
> > >
>
> > > 32 bit:
>
> > >
>
> > > https://wingrass.fsv.cvut.cz/grass73/x86/logs/log-r71641-1/error.log
>
> > >
>
> > > GRASS GIS 7.3.svn r71641 compilation log
>
> > > --
>
> > > Started compilation: Tue Nov 7 21:30:33 2017
>
> > > --
>
> > > Errors in:
>
> > > /c/msys32/usr/src/grass_trunk/raster/r.in.gdal
>
> >
>
> > The error is:
>
> > main.c:345: undefined reference to `GDALSetCacheMax64@4'
>
> >
>
> > strange, GDALSetCacheMax64 should exist on 32 bit Windows, even if "the
>
> > maximum amount of memory that can be addressed by a process might be 2
GB
>
> > or 3 GB, depending on the operating system capabilities."
>
> >
>
> > Falling back to GDALSetCacheMax for MS Windows (including 64 bit
Windows)
>
> > in r71677.
>
>
>
> The issue is probably that this build uses GDAL from OSGeo4W, into which
GDAL has been configured and compiled with MSVC. Thus HAVE_LONG_LONG is not
defined in cpl_config.h, and the GDALSetCacheMax64( GIntBig ) must evaluate
to GDALSetCacheMax64 ( int ) when including from GRASS. I guess defining
HAVE_LONG_LONG would solve the issue .

If GDALSetCacheMax64 must evaluate to GDALSetCacheMax64 ( int ), we can
just as well use GDALSetCacheMax( int), the argument is the same ( int ).

Markus M
>
>
>
> --
>
> Spatialys - Geospatial professional services
>
> http://www.spatialys.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #1902: g.tempfile -d: make a directory not a filename

[GRASS GIS]

#1902: g.tempfile -d: make a directory not a filename
--+---
  Reporter:  hamish   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  8.0.0
 Component:  Default  |Version:  svn-trunk
Resolution:   |   Keywords:  g.tempfile, scripting, mktemp
   CPU:  All  |   Platform:  All
--+---
Changes (by mmetz):

 * milestone:  7.4.0 => 8.0.0


Comment:

 The behaviour of a flag should not be changed within minor releases,
 bumping up to GRASS 8.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Missing package "six" for Windows compilation

[Helmut Kudrnovsky]

Andy Wickert-2 wrote
> How about tkinter on Win64?
> 
> *ImportError: No module named Tkinter*

which addon?

https://wingrass.fsv.cvut.cz/grass73/x86_64/addons/grass-7.3.svn/logs/v.faultdirections.log

v.faultdirections builds on 64 bit






-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Missing package "six" for Windows compilation

[Helmut Kudrnovsky]

Helmut Kudrnovsky wrote
> Andy Wickert-2 wrote
>> How about tkinter on Win64?
>> 
>> *ImportError: No module named Tkinter*
> 
> which addon?
> 
> https://wingrass.fsv.cvut.cz/grass73/x86_64/addons/grass-7.3.svn/logs/v.faultdirections.log
> 
> v.faultdirections builds on 64 bit

tested in OSGeo4W's python 64bit:

C:\>python
Python 2.7.5 (default, May 15 2013, 22:44:16) [MSC v.1500 64 bit (AMD64)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from Tkinter import *
>>>





-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] winGRASS not built/broken

[Even Rouault]

> If GDALSetCacheMax64 must evaluate to GDALSetCacheMax64 ( int ), 

My hypothesis might be wrong, but if it is true, then it *wrongly* evaluates to 
GDALSetCacheMax64 ( int ) when currently called by GRASS. If you define 
HAVE_LONG_LONG before including cpl_port.h or any other GDAL include files, 
that should 
work fine.
Similar issue, or more subtle ones, could also arise with other GDAL/OGR 
functions that use 
GIntBig (*). I guess the issue is only detected with GDALSetCacheMax64 since it 
uses 
CPL_STDCALL convention which apparently embeds the argument size in the symbol 
name, 
whereas C decl doesn't do it.

I'm not sure why this would only occur with 32 bit builds, though. But this 
situation of using 
cpl_config.h generated for MSVC is kind of dangerous

Even

(*)

$ grep GIntBig ogr/ogr_api*.h
GIntBig CPL_DLL OGR_F_GetFieldAsInteger64( OGRFeatureH, int );
const GIntBig CPL_DLL *OGR_F_GetFieldAsInteger64List( OGRFeatureH, int, int * );
void   CPL_DLL OGR_F_SetFieldInteger64( OGRFeatureH, int, GIntBig );
void   CPL_DLL OGR_F_SetFieldInteger64List( OGRFeatureH, int, int, const 
GIntBig * );
GIntBig CPL_DLL OGR_F_GetFID( OGRFeatureH );
OGRErr CPL_DLL OGR_F_SetFID( OGRFeatureH, GIntBig );
OGRErr CPL_DLL OGR_L_SetNextByIndex( OGRLayerH, GIntBig );
OGRFeatureH CPL_DLL OGR_L_GetFeature( OGRLayerH, GIntBig )  
CPL_WARN_UNUSED_RESULT;
OGRErr CPL_DLL OGR_L_DeleteFeature( OGRLayerH, GIntBig ) CPL_WARN_UNUSED_RESULT;
GIntBig CPL_DLL OGR_L_GetFeatureCount( OGRLayerH, int );
GIntBig CPL_DLL OGR_L_GetFeaturesRead( OGRLayerH );



-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Different CRS matching in 7.2 and trunk

[Helena Mitasova]

> On Nov 10, 2017, at 7:20 PM, Markus Metz  
> wrote:
> 
> 
> 
> On Sat, Nov 11, 2017 at 12:22 AM, Helena Mitasova  > wrote:
> >
> > Please note, that  in spite of the fact that the datum.table shows same 
> > transformation parameters,
> > different nad83 datums are different (it is not just a different name for 
> > the same datum) and there are different EPSG codes associated
> > with the relevant CRS.
> > You can find more about it here (or just google it)
> > https://confluence.qps.nl/pages/viewpage.action?pageId=29855153 
> > 
> >
> > Supposedly, the shift from NAD83(86) to NAD83(HARN) can be done with the 
> > NGS NADCON program (I have not checked it out)
> > (http://www.ngs.noaa.gov/TOOLS/Nadcon/Nadcon.shtml 
> > ).
> 
> There are 12 (!) different definitions for NAD83. What to do about this? 
> Regard these 12 definitions as different datums? In this case I would need to 
> reinstate the datum check and we need to add more entries to datum.table.

Markus, we absolutely need to have a datum check - although the differences 
between different NAD83 datums are less than a meter, differences between NAD27 
and NAD83 are over hundred meters in some areas. Anything that has a different 
EPSG should be treated as different CRS exactly for the reasons you mentioned 
in your answer to Vasek.

Helena

> 
> Markus M
> 
> >
> > Helena
> >
> > On Nov 10, 2017, at 5:30 PM, Markus Metz  > > wrote:
> >
> >
> >
> > On Fri, Nov 10, 2017 at 8:46 PM, Vaclav Petras  > > wrote:
> > >
> > > On Fri, Nov 10, 2017 at 2:21 PM, Markus Metz 
> > > mailto:markus.metz.gisw...@gmail.com>> 
> > > wrote:
> > > >
> > > > > >
> > > > > > 7.2 considers this OK while trunk considers this different. I'm not 
> > > > > > sure which one is correct.
> > > > >
> > > > > In this case, 7.2 is correct, but 7.2 does not compare datums, i.e. 
> > > > > projections would be regarded as matching even with e.g. nad27 and 
> > > > > nad83.
> > > > > The comparison of datums is new in 7.3 and needs some refinement.
> > > > >
> > > > > I will fix the comparison of swapped lat_1 and lat_2.
> > > >
> > > > Fixed in trunk r71656.
> > > >
> > > > The test for different datum names has been disabled again in trunk 
> > > > r71657. There are several different datum names in lib/gis/datum.table 
> > > > that apparently mean the same: same ellipsoid and same transformation 
> > > > parameters. Apparently, GRASS does not provide a datum name when 
> > > > converting projection information from GRASS to proj4 for reprojecting 
> > > > data.
> > >
> > >
> > > Thank you so much, Markus. This saves me a lot of trouble.
> >
> > About avoiding trouble, the motivation of the stricter CRS comparison is to 
> > avoid subsequent geolocation errors. If data have been imported and 
> > differences in the CRS were not detected, it can become very difficult 
> > later on in the processing to figure out the reason for geolocation errors 
> > (different data not matching each other spatially). I'm not sure what to do 
> > about different datum names. The current check relies on the test for 
> > differences in ellipsoids.
> >
> > Markus M
> >
> > >
> > > (I'm working on a Jupyter Notebook where I need trunk.)
> > > https://github.com/wenzeslaus/Notebook-for-processing-point-clouds-in-GRASS-GIS
> > >  
> > > 
> > >
> > > >
> > > >
> > > > Markus M
> > > >
> >
> > ___
> > grass-dev mailing list
> > grass-dev@lists.osgeo.org 
> > https://lists.osgeo.org/mailman/listinfo/grass-dev 
> > 
> >
> >
> > Helena Mitasova
> > Professor at the Department of Marine, 
> > Earth, and Atmospheric Sciences
> > and Center for Geospatial Analytics
> > North Carolina State University
> > Raleigh, NC 27695-8208
> > hmit...@ncsu.edu 
> > http://geospatial.ncsu.edu/osgeorel/publications.html 
> > 
> >
> > "All electronic mail messages in connection with State business which are 
> > sent to or received by this account are subject to the NC Public Records 
> > Law and may be disclosed to third parties.” 
> >

Helena Mitasova
Professor at the Department of Marine, 
Earth, and Atmospheric Sciences
and Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu
http://geospatial.ncsu.edu/osgeorel/publications.html 


"All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

_

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Neteler]

Hi,

we got quite some stuff done today at the sprint and if there are no
objections we'll prepare the release 1 by tomorrow.

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

Re: [GRASS-dev] [GRASS GIS] #3429: g.gui.iclass: segfault when loading vector layer

[GRASS GIS]

#3429: g.gui.iclass: segfault when loading vector layer
--+--
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.4.0
 Component:  wxGUI|Version:  svn-trunk
Resolution:   |   Keywords:  g.gui.iclass import segfault
   CPU:  Unspecified  |   Platform:  Unspecified
--+--

Comment (by annakrat):

 I have just been looking at this, but since I have to leave right now,
 this is where I got. I don't understand how the temporary maps work, so
 it's hard to say what consequences this has, but please test.

 {{{
 Index: Vlib/open.c
 ===
 --- Vlib/open.c (revision 71523)
 +++ Vlib/open.c (working copy)
 @@ -960,7 +960,7 @@
  }
  G_debug(1, "Vect_open_tmp_new(): name = '%s' with_z = %d", name,
 with_z);

 -return open_new(Map, tmp_name, with_z, TEMPORARY_MAP); /* temporary
 map */
 +return open_new(Map, tmp_name, with_z, TEMPORARY_MAP_ENV); /*
 temporary map */
  }

 }}}
 {{{
 Index: gui/wxpython/iclass/frame.py
 ===
 --- gui/wxpython/iclass/frame.py(revision 71523)
 +++ gui/wxpython/iclass/frame.py(working copy)
 @@ -624,7 +624,8 @@
  return

  # copy features to the temporary map
 -vname = self._getTempVectorName()
 +#vname = self._getTempVectorName()
 +vname = self.trainingAreaVector
  # avoid deleting temporary map
  os.environ['GRASS_VECTOR_TEMPORARY'] = '1'
  if digitClass.CopyMap(vname, tmp=True) == -1:
 }}}

 For the debugging, you need to (after attaching the process) press
 Continue to release the gui, then do things in gui and it then jumps in
 qtcreator to segfaults or breakpoints.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [release planning] 7.4.0

[Martin Landa]

Hi,

2017-11-11 20:12 GMT+01:00 Markus Neteler :
> we got quite some stuff done today at the sprint and if there are no
> objections we'll prepare the release 1 by tomorrow.

cool, but what do you mean by release 1, RC1, beta1?

And what about creating a new branch?

Ma

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

Re: [GRASS-dev] [release planning] 7.4.0

[Markus Neteler]

On Nov 11, 2017 9:03 PM, "Martin Landa"  wrote:
>
> Hi,
>
> 2017-11-11 20:12 GMT+01:00 Markus Neteler :
> > we got quite some stuff done today at the sprint and if there are no
> > objections we'll prepare the release 1 by tomorrow.
>
> cool, but what do you mean by release 1, RC1, beta1?

RC1!

> And what about creating a new branch?

Sure, that I'll do tomorrow or later tonight.

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

Re: [GRASS-dev] [release planning] 7.4.0

[Martin Landa]

Hi,

2017-11-11 22:08 GMT+01:00 Markus Neteler :

>> cool, but what do you mean by release 1, RC1, beta1?
>
> RC1!
>
>> And what about creating a new branch?
>
> Sure, that I'll do tomorrow or later tonight.

OK, sounds reasonable. Martin

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

Re: [GRASS-dev] winGRASS not built/broken

[Markus Metz]

On Sat, Nov 11, 2017 at 7:45 PM, Even Rouault 
wrote:
>
>
>
> > If GDALSetCacheMax64 must evaluate to GDALSetCacheMax64 ( int ),
>
>
>
> My hypothesis might be wrong, but if it is true, then it *wrongly*
evaluates to GDALSetCacheMax64 ( int ) when currently called by GRASS. If
you define HAVE_LONG_LONG before including cpl_port.h or any other GDAL
include files, that should work fine.

Stupid question: such a #define has only effect on compile time. If GDAL
has been compiled without HAVE_LONG_LONG being defined, and then we define
HAVE_LONG_LONG when compiling against GDAL, is this creating a big mess?
GRASS might then use a different GIntBig than GDAL.

Markus M

>
> Similar issue, or more subtle ones, could also arise with other GDAL/OGR
functions that use GIntBig (*). I guess the issue is only detected with
GDALSetCacheMax64 since it uses CPL_STDCALL convention which apparently
embeds the argument size in the symbol name, whereas C decl doesn't do it.
>
>
>
> I'm not sure why this would only occur with 32 bit builds, though. But
this situation of using cpl_config.h generated for MSVC is kind of dangerous
>
>
>
> Even
>
>
>
> (*)
>
>
>
> $ grep GIntBig ogr/ogr_api*.h
>
> GIntBig CPL_DLL OGR_F_GetFieldAsInteger64( OGRFeatureH, int );
>
> const GIntBig CPL_DLL *OGR_F_GetFieldAsInteger64List( OGRFeatureH, int,
int * );
>
> void CPL_DLL OGR_F_SetFieldInteger64( OGRFeatureH, int, GIntBig );
>
> void CPL_DLL OGR_F_SetFieldInteger64List( OGRFeatureH, int, int, const
GIntBig * );
>
> GIntBig CPL_DLL OGR_F_GetFID( OGRFeatureH );
>
> OGRErr CPL_DLL OGR_F_SetFID( OGRFeatureH, GIntBig );
>
> OGRErr CPL_DLL OGR_L_SetNextByIndex( OGRLayerH, GIntBig );
>
> OGRFeatureH CPL_DLL OGR_L_GetFeature( OGRLayerH, GIntBig )
CPL_WARN_UNUSED_RESULT;
>
> OGRErr CPL_DLL OGR_L_DeleteFeature( OGRLayerH, GIntBig )
CPL_WARN_UNUSED_RESULT;
>
> GIntBig CPL_DLL OGR_L_GetFeatureCount( OGRLayerH, int );
>
> GIntBig CPL_DLL OGR_L_GetFeaturesRead( OGRLayerH );
>
>
>
>
>
>
>
> --
>
> Spatialys - Geospatial professional services
>
> http://www.spatialys.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] winGRASS not built/broken

[Even Rouault]

On dimanche 12 novembre 2017 00:07:49 CET Markus Metz wrote:
> Stupid question: such a #define has only effect on compile time. If 
GDAL
> has been compiled without HAVE_LONG_LONG being defined, and then 
we define
> HAVE_LONG_LONG when compiling against GDAL, is this creating a big 
mess?

With MSVC, GIntBig expands to __int64 , which is equivalent in practice 
to long long.

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Different CRS matching in 7.2 and trunk

[Markus Metz]

On Sat, Nov 11, 2017 at 8:05 PM, Helena Mitasova  wrote:
>
>
> On Nov 10, 2017, at 7:20 PM, Markus Metz 
wrote:
>
>
>
> On Sat, Nov 11, 2017 at 12:22 AM, Helena Mitasova 
wrote:
> >
> > Please note, that  in spite of the fact that the datum.table shows same
transformation parameters,
> > different nad83 datums are different (it is not just a different name
for the same datum) and there are different EPSG codes associated
> > with the relevant CRS.
> > You can find more about it here (or just google it)
> > https://confluence.qps.nl/pages/viewpage.action?pageId=29855153
> >
> > Supposedly, the shift from NAD83(86) to NAD83(HARN) can be done with
the NGS NADCON program (I have not checked it out)
> > (http://www.ngs.noaa.gov/TOOLS/Nadcon/Nadcon.shtml).
>
> There are 12 (!) different definitions for NAD83. What to do about this?
Regard these 12 definitions as different datums? In this case I would need
to reinstate the datum check and we need to add more entries to datum.table.
>
>
> Markus, we absolutely need to have a datum check

This datum check has been first added in Oct 2003 and has been quickly
removed again in Jan 2004. As long as we do not have proj-style definitions
reflecting the differences in the various nad83 datums, it does not make
sense to differentiate between say nad83 and nad83harn.

> - although the differences between different NAD83 datums are less than a
meter, differences between NAD27 and NAD83 are over hundred meters in some
areas. Anything that has a different EPSG should be treated as different
CRS exactly for the reasons you mentioned in your answer to Vasek.

GRASS does not use EPSG to construct proj-style definitions.

Markus M

>
> Helena
>
>
> Markus M
>
> >
> > Helena
> >
> > On Nov 10, 2017, at 5:30 PM, Markus Metz 
wrote:
> >
> >
> >
> > On Fri, Nov 10, 2017 at 8:46 PM, Vaclav Petras 
wrote:
> > >
> > > On Fri, Nov 10, 2017 at 2:21 PM, Markus Metz <
markus.metz.gisw...@gmail.com> wrote:
> > > >
> > > > > >
> > > > > > 7.2 considers this OK while trunk considers this different. I'm
not sure which one is correct.
> > > > >
> > > > > In this case, 7.2 is correct, but 7.2 does not compare datums,
i.e. projections would be regarded as matching even with e.g. nad27 and
nad83.
> > > > > The comparison of datums is new in 7.3 and needs some refinement.
> > > > >
> > > > > I will fix the comparison of swapped lat_1 and lat_2.
> > > >
> > > > Fixed in trunk r71656.
> > > >
> > > > The test for different datum names has been disabled again in trunk
r71657. There are several different datum names in lib/gis/datum.table that
apparently mean the same: same ellipsoid and same transformation
parameters. Apparently, GRASS does not provide a datum name when converting
projection information from GRASS to proj4 for reprojecting data.
> > >
> > >
> > > Thank you so much, Markus. This saves me a lot of trouble.
> >
> > About avoiding trouble, the motivation of the stricter CRS comparison
is to avoid subsequent geolocation errors. If data have been imported and
differences in the CRS were not detected, it can become very difficult
later on in the processing to figure out the reason for geolocation errors
(different data not matching each other spatially). I'm not sure what to do
about different datum names. The current check relies on the test for
differences in ellipsoids.
> >
> > Markus M
> >
> > >
> > > (I'm working on a Jupyter Notebook where I need trunk.)
> > >
https://github.com/wenzeslaus/Notebook-for-processing-point-clouds-in-GRASS-GIS
> > >
> > > >
> > > >
> > > > Markus M
> > > >
> >
> > ___
> > grass-dev mailing list
> > grass-dev@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/grass-dev
> >
> >
> > Helena Mitasova
> > Professor at the Department of Marine,
> > Earth, and Atmospheric Sciences
> > and Center for Geospatial Analytics
> > North Carolina State University
> > Raleigh, NC 27695-8208
> > hmit...@ncsu.edu
> > http://geospatial.ncsu.edu/osgeorel/publications.html
> >
> > "All electronic mail messages in connection with State business which
are sent to or received by this account are subject to the NC Public
Records Law and may be disclosed to third parties.”
> >
>
>
> Helena Mitasova
> Professor at the Department of Marine,
> Earth, and Atmospheric Sciences
> and Center for Geospatial Analytics
> North Carolina State University
> Raleigh, NC 27695-8208
> hmit...@ncsu.edu
> http://geospatial.ncsu.edu/osgeorel/publications.html
>
> "All electronic mail messages in connection with State business which are
sent to or received by this account are subject to the NC Public Records
Law and may be disclosed to third parties.”
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3429: g.gui.iclass: segfault when loading vector layer

[GRASS GIS]

#3429: g.gui.iclass: segfault when loading vector layer
--+--
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.4.0
 Component:  wxGUI|Version:  svn-trunk
Resolution:   |   Keywords:  g.gui.iclass import segfault
   CPU:  Unspecified  |   Platform:  Unspecified
--+--

Comment (by mlennert):

 Replying to [comment:4 annakrat]:
 > I have just been looking at this, but since I have to leave right now,
 this is where I got. I don't understand how the temporary maps work, so
 it's hard to say what consequences this has, but please test.

 Martin: as you introduced the whole notion of temporary vector maps, maybe
 you can explain ?


 >
 > {{{
 > Index: Vlib/open.c
 > ===
 > --- Vlib/open.c   (revision 71523)
 > +++ Vlib/open.c   (working copy)
 > @@ -960,7 +960,7 @@
 >  }
 >  G_debug(1, "Vect_open_tmp_new(): name = '%s' with_z = %d", name,
 with_z);
 >
 > -return open_new(Map, tmp_name, with_z, TEMPORARY_MAP); /* temporary
 map */
 > +return open_new(Map, tmp_name, with_z, TEMPORARY_MAP_ENV); /*
 temporary map */
 >  }
 >
 > }}}
 > {{{
 > Index: gui/wxpython/iclass/frame.py
 > ===
 > --- gui/wxpython/iclass/frame.py  (revision 71523)
 > +++ gui/wxpython/iclass/frame.py  (working copy)
 > @@ -624,7 +624,8 @@
 >  return
 >
 >  # copy features to the temporary map
 > -vname = self._getTempVectorName()
 > +#vname = self._getTempVectorName()
 > +vname = self.trainingAreaVector
 >  # avoid deleting temporary map
 >  os.environ['GRASS_VECTOR_TEMPORARY'] = '1'
 >  if digitClass.CopyMap(vname, tmp=True) == -1:
 > }}}
 >

 This allows me to open the vector file with the stored polygons. Thanks !
 In the terminal, I get messages such as:

 {{{
 G__open(read): Unable to open
 '/home/mlennert/GRASSDATA/nc_spm_08_grass7/user1/.tmp/moritz-
 ulb/vector/trAreas325320/frmt': No such file or directory
 }}}


 > For the debugging, you need to (after attaching the process) press
 Continue to release the gui, then do things in gui and it then jumps in
 qtcreator to segfaults or breakpoints.

 Thanks for the hint ! Now I can get the module to crash, but the debugger
 indicates some completely different place in the code. But probably I
 don't understand the debugging in qtcreator enough, yet.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Missing package "six" for Windows compilation

[Andy Wickert]

Module: v.gsflow.export.py


See:
https://wingrass.fsv.cvut.cz/grass73/x86_64/addons/grass-7.3.svn/logs/v.gsflow.export.log

But I have removed the matplotlib import, so this may disappear upon the
next build.

Andy

On Sat, Nov 11, 2017 at 12:42 PM, Helmut Kudrnovsky  wrote:

> Helmut Kudrnovsky wrote
> > Andy Wickert-2 wrote
> >> How about tkinter on Win64?
> >>
> >> *ImportError: No module named Tkinter*
> >
> > which addon?
> >
> > https://wingrass.fsv.cvut.cz/grass73/x86_64/addons/grass-7.
> 3.svn/logs/v.faultdirections.log
> >
> > v.faultdirections builds on 64 bit
>
> tested in OSGeo4W's python 64bit:
>
> C:\>python
> Python 2.7.5 (default, May 15 2013, 22:44:16) [MSC v.1500 64 bit (AMD64)]
> on
> win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from Tkinter import *
> >>>
>
>
>
>
>
> -
> best regards
> Helmut
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3429: g.gui.iclass: segfault when loading vector layer

[GRASS GIS]

#3429: g.gui.iclass: segfault when loading vector layer
--+--
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.4.0
 Component:  wxGUI|Version:  svn-trunk
Resolution:   |   Keywords:  g.gui.iclass import segfault
   CPU:  Unspecified  |   Platform:  Unspecified
--+--

Comment (by annakrat):

 Replying to [comment:5 mlennert]:
 > This allows me to open the vector file with the stored polygons. Thanks
 !
 > In the terminal, I get messages such as:
 >
 > {{{
 > G__open(read): Unable to open
 '/home/mlennert/GRASSDATA/nc_spm_08_grass7/user1/.tmp/moritz-
 ulb/vector/trAreas325320/frmt': No such file or directory
 > }}}
 >

 I noticed, but they don't seem to actually cause anything so I ignored it
 so far, but we should look at it too.

 >
 > > For the debugging, you need to (after attaching the process) press
 Continue to release the gui, then do things in gui and it then jumps in
 qtcreator to segfaults or breakpoints.
 >
 > Thanks for the hint ! Now I can get the module to crash, but the
 debugger indicates some completely different place in the code. But
 probably I don't understand the debugging in qtcreator enough, yet.

 This is more complicated case for debugging than normally since the C
 calls are made from the GUI. I think the actual crash happened elsewhere,
 but that is just a consequence of a problem happening before. The specific
 problem I found was that in function CopyMap in iclass/digit.py the
 Vect_close function was deleting the temporary vector (which causes
 segfault later on). At this point I don't understand the temporary vectors
 enough to fix it properly...

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3423: UnicodeDecodeError in r.category in wxGUI when category labels contain special characters

[GRASS GIS]

#3423: UnicodeDecodeError in r.category in wxGUI when category labels contain
special characters
--+-
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.4.0
 Component:  wxGUI|Version:  svn-trunk
Resolution:   |   Keywords:  r.category encoding
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by annakrat):

 Hmm, I can't reproduce it on linux. Could you test if it is still the
 problem?

--
Ticket URL: 
GRASS GIS 

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