Re: [GRASS-dev] wxGUI import chain
Hi Markus, On Mon, Oct 6, 2014 at 9:15 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: Is there any reason why gui/wxpython/gis_set.py imports (eventually) etc/python/grass/pygrass/raster/buffer.py? Anyway, r62196 fails to start the GUI in trunk because of broken pygrass. I doubt if it is a good idea to make pygrass a dependency of the GUI. I'm not able to reproduce the problem, what kind of error did you get? Any way I will work in the __init__ file to isolate the ctypes stuff. All the best Pietro ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #2442: np.float128 does not always exist
#2442: np.float128 does not always exist
---+
Reporter: jradinger | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone:
Component: Default| Version: svn-trunk
Keywords: |Platform: Unspecified
Cpu: x86-32 |
---+
When compiling the latest SVN (62197) of GRASS7 trunk I run into following
error (first among the error list, mostly in the temporal dir):
{{{
Traceback (most recent call last):
File /usr/local/src/grass7_trunk/dist.i686-pc-linux-
gnu/scripts/t.vect.univar, line 66, in module
import grass.temporal as tgis
File /usr/local/src/grass7_trunk/dist.i686-pc-linux-
gnu/etc/python/grass/temporal/__init__.py, line 29, in module
from temporal_vector_algebra import *
File /usr/local/src/grass7_trunk/dist.i686-pc-linux-
gnu/etc/python/grass/temporal/temporal_vector_algebra.py, line 420, in
module
import grass.pygrass.modules as pygrass
File /usr/local/src/grass7_trunk/dist.i686-pc-linux-
gnu/etc/python/grass/pygrass/__init__.py, line 15, in module
from . import raster
File /usr/local/src/grass7_trunk/dist.i686-pc-linux-
gnu/etc/python/grass/pygrass/raster/__init__.py, line 35, in module
from grass.pygrass.raster.buffer import Buffer
File /usr/local/src/grass7_trunk/dist.i686-pc-linux-
gnu/etc/python/grass/pygrass/raster/buffer.py, line 14, in module
DCELL = (np.float64, np.float128)
AttributeError: 'module' object has no attribute 'float128'
make[1]: *** [t.vect.univar.tmp.html] Error 1
}}}
Here I am running Python 2.7.3 with numpy 1.9.0.
Here [http://stackoverflow.com/questions/9062562/what-is-the-internal-
precision-of-numpy-float128] it says that is is related to the
architecture. In my case I am on a 32 bit system.
Changing from np.float128() to np.longdouble() (which exists on my system)
should solve the problem.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2442
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r62150 - in grass/branches/releasebranch_7_0: . raster/r.random
Hi Markus, 2014-10-06 15:37 GMT+02:00 Martin Landa landa.mar...@gmail.com: I see that there are more commands where it should be added? right, I will check it hopefully today evening. Martin done in r62200. Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] weren't r.stream going to core? was: r.stream.* problems on Ubuntu when installed via g.extensions
Hi, back to the r.stream.* tools: On Mon, Jan 20, 2014 at 9:00 AM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Sun, Jan 19, 2014 at 9:08 PM, Helena Mitasova hmit...@ncsu.edu wrote: On Jan 19, 2014, at 3:01 PM, Martin Landa wrote: it's not only question of putting it here. The modules need some review (code, parameters, manuals). If that is the case, that is a completely different issue, I thought they are ready. I agree with Martin that the modules need some review. E.g. I encountered a bug in r.stream.order where some stream segments got order 0 (zero) which is invalid. I am also interested in having these modules in core and want to help with the review as soon as I find some time... Markus M Concerning the release branch of GRASS 7, in r59606 the r.stream.* modules got disabled. If they are not yet production ready, should we move them back to Addons? markusN ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2442: np.float128 does not always exist
#2442: np.float128 does not always exist ---+ Reporter: jradinger | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.1.0 Component: Python | Version: svn-trunk Keywords: |Platform: Unspecified Cpu: x86-32 | ---+ Comment(by zarch): Here [http://stackoverflow.com/questions/9062562/what-is-the-internal- precision-of-numpy-float128] it says that is is related to the architecture. In my case I am on a 32 bit system. Right, I didn't thought about it! Now should be fix in r62206. Moreover I've disconnected (r62205) and isolate the ctypes part of pygrass from the rest, this should make the whole pygrass more stable (I hope). -- Ticket URL: http://trac.osgeo.org/grass/ticket/2442#comment:2 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] weren't r.stream going to core? was: r.stream.* problems on Ubuntu when installed via g.extensions
Hi, 2014-10-07 17:32 GMT+02:00 Markus Neteler nete...@osgeo.org: [...] Concerning the release branch of GRASS 7, in r59606 the r.stream.* modules got disabled. If they are not yet production ready, should we move them back to Addons? MarkusM: Is there any chance to fix them before releasing G70? If not I would suggest to move them back to Addons... Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2421: Functions from CDHC lib have no prefix
#2421: Functions from CDHC lib have no prefix --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: closed Priority: blocker | Milestone: 7.0.0 Component: Default | Version: svn-trunk Resolution: fixed|Keywords: cdhclib, api, prefix Platform: Unspecified | Cpu: Unspecified --+- Changes (by martinl): * status: new = closed * resolution: = fixed Comment: Replying to [comment:7 neteler]: Updated in trunk in r62130. Please check. If ok, it can be backported. Seems to be OK to me. Thanks for solving this issue. I took liberty to backport it (r62207) and to close the ticket. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2421#comment:8 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2422: Functions from Segment lib have no prefix
#2422: Functions from Segment lib have no prefix
-+--
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: LibRaster| Version: unspecified
Keywords: segmentlib, api, prefix |Platform: Unspecified
Cpu: Unspecified |
-+--
Comment(by martinl):
Replying to [comment:4 mmetz]:
{{{
Segment_open()
}}}
So you mean to change the first letter of the prefix to upper case?
yes, it's consistent with prefixes from other GRASS libs which are upper-
case. If no objection I will do this change within the next days.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2422#comment:5
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] error v.what.rast
I am trying to upload raster values of the raster 'grid' to the attribute table of the gbif vector layer, as below: g.region rast=grid v.what.rast map=gbif raster=grid column=cell2arcm Reading features from vector map... 100% ERROR: Reading raster map grid@ request for row 1830 is outside region Any idea what the error message is about. I have done this done before without problems (same location/mapset and script), and I am really not sure what I am doing different now. Running GRASS 7.1 on Ubuntu ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] python2/3 and GRASS build on Arch
I don't know much but I will try to tell what I know. On Tue, Oct 7, 2014 at 4:57 PM, Maciej Sieczka msiec...@sieczka.org wrote: --with-wxwidgets=/usr/bin/wx-config-2.8 Per 2.8 wxWidgets specified, I don't get it why /usr/lib/python2.7/site-packages/wx-3.0-gtk2/ gets involved in iclass build. I would rather expect it to pick /usr/lib/python2.7/site-packages/wx-2.8-gtk2-unicode/. As far as I know, this does not select the Python packages but C++ library to link to for the C++ things which are using wxWidgets (no Python things which are using wxPython). What do you make of this? Like I said, all the other Python bits seem to build fine. Only iclass doesn't. I think it is only g.gui.iclass because just this module is importing something from wx which fails. The other g.gui.* modules (and a toolbox script) also import wx during compilation but this does not fail. This is an Arch box. I do have all the NumPy stuff installed. There is a problem on Arch that wx-3.0-gtk2/wx/lib/plot.py fails to import numpy.oldnumeric [1] leading to those NumPy not found errors, I hope that the upstream error gets fixed because the GRASS one is more mysterious. but that would not happen if iclass build referred to wx-2.8-gtk2-unicode/wx/lib/plot.py instead - like I guess all the other GRASS 7 Python modules do. Yes, there is this mysterious issue where wrong versions of wxPython or perhaps other things are used during compilation when something runs in fake GRASS session. The things usually run in the real GRASS session, you can try. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] sample vector temporal data
Hi, as you know we need to decide which data are we going to use for t.vect.* examples. One possibility is to use oceanfront shorelines of North Carolina, we can get this data easily from here: http://portal.ncdenr.org/web/cm/download-spatial-data-maps-oceanfront It includes these years, interval data in case of older data, and instance data from the past years: 1849 - 1873, 1925 - 1946, 1933 - 1952, 1940 - 1962, 1970 - 1988, 1997, 1998, 2003, 2004, 2009 The advantage is that the data is public and basically ready to use. If we decide to use it, should we include the entire NC shoreline or just some detail (look at the attachment)? In addition, we can also create a vector time-series where the geometry is not changing, just the attribute changes (derived from the climate data for example). Any thoughts on this? By the way, the climate dataset seems to be fine, we got the confirmation we can use it, it is not subject to the PRISM licence since it was interpolated at NC State Climate Office. Anna ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] sample vector temporal data
Anna, to put these data into context, the dataset should include also at least one ortho (probably for 2009) and perhaps also a lidar-based DEM for 2009. I think that the detail will work better - maybe you can show it on orthophoto or a DEM to make it easier to understand what the lines mean. To derive vector time series from the climate data where the geometry is changing just derive isolines for temperature or precipitation from the existing rasters. If the isolines are noisy we can smooth them out using v.generalize or reinterpolate some data. This may be a simpler solution because it will use the same data set. But the shoreline may be more interesting. Helena 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/ 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.” On Oct 7, 2014, at 9:21 PM, Anna Petrášová wrote: Hi, as you know we need to decide which data are we going to use for t.vect.* examples. One possibility is to use oceanfront shorelines of North Carolina, we can get this data easily from here: http://portal.ncdenr.org/web/cm/download-spatial-data-maps-oceanfront It includes these years, interval data in case of older data, and instance data from the past years: 1849 - 1873, 1925 - 1946, 1933 - 1952, 1940 - 1962, 1970 - 1988, 1997, 1998, 2003, 2004, 2009 The advantage is that the data is public and basically ready to use. If we decide to use it, should we include the entire NC shoreline or just some detail (look at the attachment)? In addition, we can also create a vector time-series where the geometry is not changing, just the attribute changes (derived from the climate data for example). Any thoughts on this? By the way, the climate dataset seems to be fine, we got the confirmation we can use it, it is not subject to the PRISM licence since it was interpolated at NC State Climate Office. Anna all.jpgdetail.jpg___ 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] [GRASS GIS] #2431: vector_what fails with multiple layer/cat
#2431: vector_what fails with multiple layer/cat ---+ Reporter: artegion | Owner: grass-dev@… Type: defect | Status: new Priority: major | Milestone: 7.0.0 Component: Vector | Version: svn-releasebranch70 Keywords: query, v.what |Platform: All Cpu: Unspecified| ---+ Changes (by annakrat): * keywords: = query, v.what * milestone: 6.4.5 = 7.0.0 Comment: I attached a patch which adds new flag to v.what to print json and simplifies vector_what to load json. I still need to test it more but I would welcome if anyone could test it too on different types of vector data with or without attributes. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2431#comment:2 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
