[GRASS-dev] NumPy: timeline for dropping Python 2 support
Dear devs, I've just find out this news on reddit [0], and I think it is relevant also for GRASS. Numy is planning to drop the python2 support [1]: The current plan is as follows. * Until *December 31, 2018*, all NumPy releases will fully support both Python2 and Python3. * Starting on *January 1, 2019*, any new feature releases will support only Python3. * The last Python2 supporting release will be designated as a long term support (LTS) release, [...], it will be supported by the community until *December 31, 2019*. * On *January 1, 2020* we will raise a toast to Python2, and community support for the last Python2 supporting release will come to an end. [0] https://www.reddit.com/r/Python/comments/7d128x/numpy_announces_timeline_for_dropping_python_2/ [1] https://github.com/numpy/numpy/blob/master/doc/neps/dropping-python2.7-proposal.rst ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Object-based image classification in GRASS
Dear all, Some news about the machine learning classification of image segments. The process described below has been used to classify some RGB images for two different regions with more than 1 billions of pixels, and more than 2.7 millions of segments. Working with such challenging figures requires to optimize/rewrite part of the pygrass library [r58622-r58628 and r58634/r58635] and to adapt/add new GRASS modules, below is briefly reported the sequence of modules used/developed: 1. i.segment.hierarchical [r58137] = extract the segments from the raster group splitting the domain in tiles (in grass-addons); 2. r.to.vect = convert the segments to a vector map; 3. v.category = to transfer the categories of the geometry features to the new layers, the module was not working for areas but know is fixed [r58202]. 3. v.stats [r58637] = Extract statistics from a vector map (statistics about shape and about raster maps). v.stats internally use (in grass-addons): - v.area.stats [r58636] = extract some statistics about the shape (in grass-addons); - v.to.rast = re-convert the vector to a raster map using the vector categories to be sure that there is a correspondence between vector and raster categories (zones). - r.univar2 [r58439] = extract some general statistics from raster using the zones (consume much less memory than r.univar, and compute more general statistics like: skewness, kurtosis, and mode (in grass-addons); 4. v.class.ml [r58638] = classify a vector map, at the moment only a supervisionate classification is tested/supported. To select the segment that must use for training the different machine-learning techniques you can define a training map using the g.gui.iclass. The v.class.ml module can: - extract the training, - balance and scale the training set; - optimize the training set; - test several machine learning techniques; - explore the SVC domain; - export the accuracy of different ML to a csv file; - find and export the optimum training set, - classify the vector map using several ML techniques and export to a new layer of the vector map with the results of the classification; - export the classification results to several raster maps, the vector map coming from a segment raster map is too big to be exported to a shape file (the limit for a shape file is 4Gb [0]). The module accept as input a python file with a list of custom classifiers defined by the user, and support both: scikit-learn[1] and mlpy[2] libraries. Known Issues: * not all the classifiers are working (but I hope to be able to fix this during the next weeks); * so far, only a supervised classification is supported. Best regards Pietro [0] http://www.gdal.org/ogr/drv_shapefile.html [1] http://scikit-learn.org/ [2] http://mlpy.sourceforge.net/ ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.univar, ERROR G_realloc:
On Sunday 08 Dec 2013 23:51:22 you wrote: It might be nice to define a threshold for large maps and issue in case a G_message()/G_warning() to inform the user about the other modules... Today I tried to reduce the memory footprint of the module and I added also: skewness, kurtosis and mode, and reduced some capabilities, I will test it in the next days. OK, I pushed in grass-addons, at the moment it works only with zones and with the flag -e (for extended statistics). On my test case r.univar consume more than 15 GB before to crash, now the module consume less than GB, and compute also some extra values. Pietro ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.univar, ERROR G_realloc:
On Sunday 08 Dec 2013 22:37:34 Markus Neteler wrote: On Sat, Dec 7, 2013 at 12:58 AM, Glynn Clements gl...@gclements.plus.com wrote: ... Don't use r.univar -e, particularly for large maps. r.quantile and r.statistics3 are far more efficient. It might be nice to define a threshold for large maps and issue in case a G_message()/G_warning() to inform the user about the other modules... Today I tried to reduce the memory footprint of the module and I added also: skewness, kurtosis and mode, and reduced some capabilities, I will test it in the next days. However r.statistics/2/3/r.quantile generate different results and are not directly substitutes of r.univar (IMHO). ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Aborted (core dumped), during v.build
Hi, I'm trying to convert a segment map into a vector map, I'm using GRASS7 (r58321), but I got: G70 r.to.vect --o --v input=seg_0.05_final@pietro output=seg005 type=area WARNING: Vector map seg005 already exists and will be overwritten Using native format Extracting areas... 100% Writing areas... 100% Building topology for vector map seg005@pietro... Registering primitives... Unexpected error. Aborted (core dumped) G70 v.info map=seg005 WARNING: Coor file of vector map seg005@pietro is larger than it should be (3198718980 bytes excess) ++ | Name:seg005| | Mapset: pietro| | Location:combabula | | Database:/home/pietro | | Title: | | Map scale: 1:1 | | Name of creator: pietro| | Organization: | | Source date: Thu Nov 28 20:55:18 2013 | | Timestamp (first layer): none | || | Map format: native| || | Type of map: vector (level: 1) | || | Number of points: 0 Number of centroids: 5970928| | Number of lines:0 Number of boundaries: 16325866 | | Number of areas:0 Number of islands:0 | || | Map is 3D: No | | Number of dblinks: 1| || | Projection: UTM (zone invalid) | || | N: 7104206.80119541S: 7089186.6842956 | | E:759827.4950082W: 745280.94984459 | || | Digitization threshold: 0| | Comment: | || ++ the problem raise when I try to build the topography, running v.build I got: G70 v.build map=seg005 --v WARNING: Coor file of vector map seg005@pietro is larger than it should be (3198718980 bytes excess) Building topology for vector map seg005@pietro... Registering primitives... 22296794 primitives registered 189966723 vertices registered Building areas... Unexpected error. Aborted (core dumped) What it is wrong and how to fix it? Any ideas? Best regards Pietro ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Aborted (core dumped), during v.build
On Friday 29 Nov 2013 06:54:59 you wrote: What it is wrong and how to fix it? Any ideas? Please try make distclean,I had similar problems some day ago I did, actually, so should be something else I guess... Pietro ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] modifying the dblink it require to re-build the topology
On Tuesday 12 Nov 2013 20:37:24 you wrote: I know that it can be annoying to have to create new maps, but at the same time it is a failsafe that makes sure that even if you make a mistake in the call to v.category, you still keep your original data. yes, it is particularly annoying, because the GRASS db driver is pretty slow copying data from one table to another. Maybe we should add a flag that skip to copy the attribute tables. That could be an option, yes. Ok, done in r58202 On the other hand, the tables are already there, we need only to link the geometry features to the existing table. No, if we have a new map it should use a different attribute table than the old map. I don't agree I prefer to avoid to have several copy of the same thing on my hard-disk, but I can understand your logic. :-) Anyone against this new flag/option? I'm not against the flag as it seems a reasonable option to me, but I think that the performance issue should be solved as well. From what I see in the code, I have the feeling that v.category might be bitten by the same bug/problem as the one Hamish just reported for v.what.rast [1], so possibly it is feasible to improve the performance. Yes, I think that we have a huge problem in the DB drivers, but I don't have time right now to understand where the problem is. In general I try to avoid to use the C API of the DB as much as possible, using directly the python API. I think that the Attribute table, could gain in usability too if avoid to use v.db.select, and start to use directly the python API... and I think should avoid to load the whole table and load only the first 250 rows [0]. Best regards Pietro [0] http://trac.osgeo.org/grass/ticket/2124 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2127: Python implementation of g.message
On Monday 11 Nov 2013 00:46:20 GRASS GIS wrote:
I would like to put the attached file {{{__init__.py}}} into a new
pygrass directory lib/python/pygrass/messenger, if there are no
objections against it.
Personally I have no objections! :-)
Well done.
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] modifying the dblink it require to re-build the topology
On Thursday 07 Nov 2013 09:25:21 you wrote: I'm doing something wrong or is it a bug? I thought that maybe you forgot to use the type parameter, but I just tried in the NC dataset and can confirm your issue. ok, the bug should be fixed in r58179, at the end it was much easier than I thought. Please test the v.category module, to be sure that I've not introduced new bugs. :-) I know that it can be annoying to have to create new maps, but at the same time it is a failsafe that makes sure that even if you make a mistake in the call to v.category, you still keep your original data. yes, it is particularly annoying, because the GRASS db driver is pretty slow copying data from one table to another. Maybe we should add a flag that skip to copy the attribute tables. On the other hand, the tables are already there, we need only to link the geometry features to the existing table. Anyone against this new flag/option? Best regards Pietro ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] env variable: GRASS_DEBUG_LEVEL
Dear devs, reading the manual of G_debug, I found miss leading the documentation: Print debugging message if environment variable GRASS_DEBUG_LEVEL is set to level equal or greater [0] So I try to set the environment variable with: export GRASS_DEBUG_LEVEL=5 but it didn't work. Is It a bug? Vaclav, tell me that I have to use: g.gisenv set=DEBUG=0 instead. Maybe we should improve the documentation string to make it more clear. What do you think? Best regards Pietro ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Object-based image classification in GRASS
On Thursday 31 Oct 2013 10:09:20 Moritz Lennert wrote: Great ! Then I won't continue on that and rather wait for your stuff. Do you have code, yet (except for i.segment.hierarchical) ? Don't hesitate to publish early. I did some stuff here: https://github.com/zarch/ml.class But I'm working to a main re-factoring to integrate my work with v.class.mlpy. It is still under development. I guess we should focus on getting the functionality, first and then think about optimisation for size... I agree, but I'm a phD student and I need the results now! :-) To speed-up the segmentation process I did the i.segment.hierarchical module [0]. that split the region in several tiles, compute the segment for each tile, patch all the tiles together and run a last time i segment using the patched map as a seed. Any reason other than preference for git over svn for not putting your module into grass-addons ? No, I was worry to add too much stuff on grass-addons, and moreover is still under development so maybe it is not ready for a production environment... But I think that now I can move i.segment.hierarchical to grass-addons. for a region of 24k row for 48k cols it required less than two hour to run and patch all the tiles, and more than 5 hours to run the final i.segment over the patched map (using only 3 iterations!). That's still only 7 hours for segmentation of a billion-cell size image. Not bad compared to other solutions out there... I never used other solutions, so I'm not able to compared the results, but I think that we have some chance to speed-up the process some parallelization, I've started to study the i.segment code, but I need time. From my experience I can say that the use v.to.db is terribly slow if you want to apply to a vector map with more than 2.7 Millions of areas. So I've develop a python function that compute the same values, but it is much faster that the v.to.db module, and should be possible to split the operation in several processes for further speed up... (It is still under testing). Does your python module load the values into an attribute table ? I would guess that that's the slow part in v.to.db. Generally, I think that's another field where optimization would be great (if possible): database interaction, notably writing to tables. IIUC, in v.to.db there is a seperate update operation for each feature. I imagine that there must be a faster way to do this... yes, this is the main problem GRASS is quite bad/slow writing to the db, I've skipped the GRASS API and use directly the python interface that is faster. Moreover the v.to.db create only a column per time, and if you are using the sqlite driver it mean that each time you have to create a new table and copy all the data. Even this module is not ready yet... it is just a python function. I'm extended to use tree/k-NN/SVM Machine learning from MLPY [1] (I've used also Parzen, but the results were not good enough) and to work also with the scikit [2] classifiers. You extended v.class.mlpy ? Is that code available somewhere ? No, I wrote ml.class and now I'm rewriting to integrate the things together. I'm working to add also a C function to the GRASS library to compute the barycentre and the a polar second moment of Area (or Moment of Inertia), that return a number that it is independent from the orientation and dimension. Great ! I guess the more the merrier ;-) See also [1]. Maybe its just a small additional step to add that at the same time ? I would love to have this too! :-) I use the i.gui.class to generate the training vector map, and then use this map to select the training areas, and export the final results into a file (at the moment only csv and npy formats are supported). How do you do that ? Do you generate training points (or small areas) and then select the areas these points fall into ? I thought it best to select training areas among the actual polygons coming out of i.segment. Yes I think so, I've generated some training areas using i.gui.class, then I've extract all the segments that overlap this areas and assign the category of the training vector map. I'm working on it (so no code ready yet!) So I can write here as soon as I have something to test... :-) Best regards Pietro ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Object-based image classification in GRASS
Hi Moritz, I'm writing some modules (in python) to basically do the same thing. I'm trying to apply a Object-based classification for a quite big area (the region is more than 14 billions of cells). At the moment I'm working with a smaller area with only ~1 billions of cells, but it is still quite challenging. To speed-up the segmentation process I did the i.segment.hierarchical module [0]. that split the region in several tiles, compute the segment for each tile, patch all the tiles together and run a last time i segment using the patched map as a seed. for a region of 24k row for 48k cols it required less than two hour to run and patch all the tiles, and more than 5 hours to run the final i.segment over the patched map (using only 3 iterations!). From my experience I can say that the use v.to.db is terribly slow if you want to apply to a vector map with more than 2.7 Millions of areas. So I've develop a python function that compute the same values, but it is much faster that the v.to.db module, and should be possible to split the operation in several processes for further speed up... (It is still under testing). On Wednesday 30 Oct 2013 21:04:22 Moritz Lennert wrote: - It uses the v.class.mlpy addon module for classification, so that needs to be installed. Kudos to Vaclav for that module ! It currently only uses the DLDA classifier. The mlpy library offers many more, and I think it should be quite easy to add them. Obviously, one could also simply export the attribute table of the segments and of the training areas to csv files and use R to do the classification. I'm extended to use tree/k-NN/SVM Machine learning from MLPY [1] (I've used also Parzen, but the results were not good enough) and to work also with the scikit [2] classifiers. Scikit it seems to have a larger community and should be easier to install than MLPY, and last but not least it seems generally faster [3]. - Many other variables could be calculated for the segments: other texture variables (possibly variables by segment, not as average of pixel-based variables, cf [1]), other shape variables (cf the new work of MarkusM on center lines and skeletons of polygons in v.voronoi), band indices, etc. It would be interesting to hear what most people find useful. I'm working to add also a C function to the GRASS library to compute the barycentre and the a polar second moment of Area (or Moment of Inertia), that return a number that it is independent from the orientation and dimension. - I do the step of digitizing training areas in the wxGUI digitizer using the attribute editing tool and filling in the 'class' attribute for those polygons I find representative. As already mentioned in previous discussions [2], I do think that it would be nice if we could have an attribute editing form that is independent of the vector digitizer. I use the i.gui.class to generate the training vector map, and then use this map to select the training areas, and export the final results into a file (at the moment only csv and npy formats are supported). More generally, it would be great to get feedback from interested people on this approach to object-based image classification to see what we can do to make it better. I'm definitely interested on the topic! :-) Some days ago I've discussed with MarkusM, that may be I could do a GSoC next year to modify the i.segment module to automatically split the domain in tiles, run as a multiprocess, and then patch only the segments that are on the border of the tiles, this solution should be much faster than my actual solution[0]. Moreover we should consider to skip to transform the segments into vector to extract the shape parameters and extract shape and others parameters (mean, median, skewness, std, etc.) directly as last step before to free the memory from the segments structures, writing a csv/npy file. All the best. Pietro [0] https://github.com/zarch/i.segment.hierarchical [1] http://mlpy.sourceforge.net/ [2] http://scikit-learn.org/ [3] http://scikit-learn.org/ml-benchmarks/ ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] g.remove rast prefered
Hi Martin, On Sunday 11 Aug 2013 11:05:44 Martin Landa wrote: Hi all, AFAR there was already discussion related to g.remove/g.copy/g.rename modules. Before we start releasing GRASS7 tech-preview I would prefer to change the current behaviour. g.remove x Removing raster x WARNING: Raster map x not found WARNING: x nothing removed to g.remove x ERROR: Invalid data element (valid options: rast,vect..) - g.remove rast=x What do you think? +1 I like the idea! Pietro ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [SoC] Weekly report #3 - GRASS Interactive Scatter Plot Tool
Hi Štěpán,
On Sunday 07 Jul 2013 13:55:15 Štěpán Turek wrote:
many thanks for big help. If I understand it correctly, the key, which will
solve my issue, is the multiprocessing module, which allows to define
region just in this process without affecting the others (as it is in the
modules). Thanks to that it will be possible to use raster library in the
backend and get rid of files produced by r.out.bin.
yes, you can just run your command giving the right environment variables...
{{{
import subprocess as sub
sub.Popen(['grasscmd', 'option', etc.], env={dictionary with your variables})
}}}
I've used it in the pygrass.modules.grid to split the grass operations in
several
independent processes running the same command in different mapsets with
different regions. You can have a look here:
http://trac.osgeo.org/grass/browser/grass/trunk/lib/python/pygrass/modules/grid/grid.py#L34
[snip]
Extending PyGRASS to provide access to the backend is good idea. I will do
so.
Please ask me if you have any doubts... I will be happy to help! :-)
Have a nice day!
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] module input (multiple type) in pyGRASS
Hi Yann,
On Friday 21 Jun 2013 10:48:14 Yann Chemin wrote:
Hi,
I am having trouble with multiple input in pyGRASS:
Example:
-
b_in=[b1,b2,b3,b4,b5,b7]
i.albedo(input=b_in, output=b_albedo, flags=lc, overwrite=OVR)
input has a multiple raster band names requirement (6 here),
using a list to define b_in does not work.
What kind of container should I use?
you should use a list as you do...
I don't have your map so I'm not able to reproduce the problem on my
machine...
I've try with:
{{{
from grass.pygrass.modules.shortcuts import imagery as i
alb = i.albedo
alb(input=['b1', 'b2', 'b3', 'b4', 'b5', 'b7'],
output='b_albedo', flags=lc, overwrite=True, run_=False)
alb.get_bash()
}}}
and return 'i.albedo input=b1,b2,b3,b4,b5,b7 output=b_albedo -l -c --o'
that it seems correct to me...
Can you provide some more details about b_in does not work? :-)
What kind of error do you have?
Best regards
Pietro
ps: thank you for testing!
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] pyGRASS send job to background
On Friday 21 Jun 2013 16:20:00 Yann Chemin wrote: I have several jobs that can be run together, in BASH we can add at the end of the module command, is there a pyGRASS option we can throw to the same effect? yes, the parameter is: finish_=False, in this way python will not wait the end of the module command... Sorry I have to add this in the documentation... Pietro ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] pyGRASS send job to background
On Friday 21 Jun 2013 13:08:48 Pietro Zambelli wrote:
Sorry I have to add this in the documentation...
False, it was already in the code... I forgot to activate the foot with the
special parameters... :-)
Now if you ask for the doc in an interactive shell with:
{{{
i.albedo?
}}}
You get:
{{{
Parameters
--
input: required, multistring
Name of input raster map
output: required, string
Name for output raster map
Flags
--
m: None
Modis (7 input bands:1,2,3,4,5,6,7)
n: None
NOAA AVHRR (2 input bands:1,2)
l: None
Landsat (6 input bands:1,2,3,4,5,7)
a: None
Aster (6 input bands:1,3,5,6,8,9)
c: None
Albedo dry run to calculate some water to beach/sand/desert
stretching, a kind of simple atmospheric correction
d: None
Albedo dry run to calculate some water to beach/sand/desert
stretching, a kind of simple atmospheric correction
overwrite: None
Allow output files to overwrite existing files
verbose: None
Verbose module output
quiet: None
Quiet module output
Special Parameters
--
The Module class have some optional parameters which are distinct using a
final underscore.
run_: True, optional
If True execute the module.
finish_: True, optional
If True wait untill the end of the module execution, and store the module
outputs into stdout, stderr attributes of the class.
stdin_: PIPE,
Set the standard input
env_: dictionary, optional
Set the evironment variables.
}}}
Thank you for the help.
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] G__getenv return different results from ctypes and from GRASS modules
On Saturday 01 Jun 2013 01:48:39 Glynn Clements wrote:
Nikos Alexandris wrote:
Why the ctypes version return 'PERMANENT' instead of 'user1'?
Glynn Clements wrote:
The $GISRC file is read the first time that an environment lookup is
made. There is no way to force it to be re-read.
This means that I can't use instructions like
[...]
in a function (pasted below) which I call from within a for loop to go
through Mapsets that potentially contain raster maps named differently?
You can modify the current process' environment with G_setenv().
Or use the method
current() = to set the mapset as current
I completely forgot that I've already implemented this functionalities... :-)
see this example:
{{{
In [1]: from grass.pygrass.gis import Mapset
In [2]: veg = Mapset()
In [3]: veg
Out[3]: Mapset('veg')
In [5]: perm = Mapset('PERMANENT')
In [6]: perm.is_current()
Out[6]: False
In [7]: veg.is_current()
Out[7]: True
In [8]: !g.mapset -p
veg
In [9]: perm.current()
In [10]: !g.mapset -p
PERMANENT
In [11]: perm.is_current()
Out[11]: True
In [12]: veg.is_current()
Out[12]: False
}}}
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Using the pygrass Mapset.glist method and a dictionary
Ciao Nikos,
On Thursday 23 May 2013 22:50:10 Nikos Alexandris wrote:
Hi list.
In a Python script, I use the following pygrass method to retrieve a list of
raster maps:
from grass.pygrass.gis import Mapset
..
landsat_imagery = dict()
..
landsat_imagery['Spectral Bands'] = Mapset().glist('rast', pattern =
'B[123457]')
However, whenever the result is empty, i.e. there are no B1, B2 and so on
named raster maps, running the script fails with the error:
landsat_imagery['Spectral Bands'] = Mapset().glist('rast', pattern =
'B[123457]')
TypeError: 'str' object is not callable
Running the instructions step-wise, from within ipython, doesn't appear to
be problematic. What am I missing in this case?
Mmh...
I've tried your code... and it is working on my machine. In both: python shell
and from file...
Python shell:
from grass.pygrass.gis import Mapset
Mapset().glist('rast', pattern = 'B[123457]')
['B4', 'B5', 'B1', 'B3', 'B2', 'B7']
From file:
cat nik.py
from grass.pygrass.gis import Mapset
landsat_imagery = dict()
landsat_imagery['Spectral Bands'] = Mapset().glist('rast',
pattern='B[123457]')
print landsat_imagery
%run nik.py
{'Spectral Bands': ['B4', 'B5', 'B1', 'B3', 'B2', 'B7']}
Therefore I think that the problem is not here...
can you send me or share/publish the whole code somewhere (gist.github, dpaste
or other).
Cheers
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] pyGRASS: Report #3
Hi all! This week I had the last course at university. I split the Raster class into: - RasterAbstractBase; - RasterRow; - RasterRowIO; - RasterSegment; - RasterNumpy; You can find the third weekly report here: http://grass.osgeo.org/wiki/GRASS_SoC_Ideas_2012/High_level_map_interaction#Report2_- _2012-06-08 Comments are welcome Best Regards, Pietro ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] pyGRASS: Report #2
Hi all! This week I had some classes, so I couldn't work full time on my project, but any way I add new functionalities as rename and remove maps, write row by row a new map. You can find the second weekly report here: http://grass.osgeo.org/wiki/GRASS_SoC_Ideas_2012/High_level_map_interaction#Report1_- _2012-06-01 And you can find the source and some examples of use here: http://code.google.com/p/pygrass/ Let me know if you have any suggestion. Best regards Pietro___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn: 41275 (Identation error in core.py?)
In data mercoledì 3 marzo 2010 21:05:31, hai scritto:
On Wed, Mar 3, 2010 at 12:58 PM, Pietro Zambelli peter.z...@gmail.com wrote:
Hi all!
I try to compile grass7 from svn I reach this error:
GRASS GIS compilation log
-
Started compilation: Wed Mar 3 12:34:18 CET 2010
--
Errors in:
/home/pietro/builds/grass70/src/grass70/lib/python
/home/pietro/builds/grass70/src/grass70/scripts/d.vect.thematic
/home/pietro/builds/grass70/src/grass70/scripts/r.in.srtm
/home/pietro/builds/grass70/src/grass70/scripts/v.db.update
--
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.
--
then I try to run 'make':
--
$ cd src/grass70/lib/python/
python $ make
python -m py_compile /home/pietro/builds/grass70/src/grass70/dist.x86_64-
unknown-linux-gnu/etc/python/grass/script/core.py
Sorry: IndentationError: ('expected an indented block',
('/home/pietro/builds/grass70/src/grass70/dist.x86_64-unknown-linux-
gnu/etc/python/grass/script/core.py', 71, 10, 'return val\n'))make:
*** [/home/pietro/builds/grass70/src/grass70/dist.x86_64-unknown-linux-
gnu/etc/python/grass/script/core.pyc] Error 1
I have tried with today's SVN - no such problem.
[nete...@north python]$ touch core.py
[nete...@north python]$ make
/usr/bin/install -c -m 644 core.py
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/etc/python/grass/script
/core.py python -m py_compile
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/etc/python/grass/script
/core.py [nete...@north python]$
Perhaps you have local modifications? Which python version do you use?
I use Python 2.6.4
I have removed lib/python directory and update and now I have this different
compilation error:
GRASS GIS compilation log
-
Started compilation: Thu Mar 4 08:59:03 CET 2010
--
Errors in:
/home/pietro/builds/grass70/src/grass70/scripts/v.colors
--
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: Thu Mar 4 08:59:46 CET 2010
make: *** [default] Error 1
== ERROR: Build Failed.
Aborting...
I try to remove and update but I still have this error
$ cd scripts/v.colors
$ make
/bin/install -c v.colors.py
/home/pietro/builds/grass70/src/grass70/dist.x86_64-unknown-linux-gnu/scripts/v.colors
if [
/home/pietro/builds/grass70/src/grass70/dist.x86_64-unknown-linux-gnu/scripts/v.colors
!= ] ; then
GISRC=/home/pietro/builds/grass70/src/grass70/dist.x86_64-unknown-linux-gnu/demolocation/.grassrc70
GISBASE=/home/pietro/builds/grass70/src/grass70/dist.x86_64-unknown-linux-gnu
PATH=/home/pietro/builds/grass70/src/grass70/dist.x86_64-unknown-linux-gnu/bin:$PATH
PYTHONPATH=/home/pietro/builds/grass70/src/grass70/dist.x86_64-unknown-linux-gnu/etc/python:$PYTHONPATH
LD_LIBRARY_PATH=/home/pietro/builds/grass70/src/grass70/dist.x86_64-unknown-linux-
gnu/bin:/home/pietro/builds/grass70/src/grass70/dist.x86_64-unknown-linux-
gnu/lib:/home/pietro/builds/grass70/src/grass70/dist.x86_64-unknown-linux-gnu/lib:
LC_ALL=C
/home/pietro/builds/grass70/src/grass70/dist.x86_64-unknown-linux-gnu/scripts/v.colors
--html-description
/dev/null | grep -v '/body\|/html' v.colors.tmp.html ; fi
File
/home/pietro/builds/grass70/src/grass70/dist.x86_64-unknown-linux-gnu/scripts/v.colors,
line 247
grass.run_command('r.colors', map = tmp_colr, flags = flip_flag,
**color_cmd, quiet = True)
^
SyntaxError: invalid syntax
make: *** [v.colors.tmp.html] Error 1
rm v.colors.tmp.html
Thank you Markus and Glynn for your replies!
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] svn: 41275 (Identation error in core.py?)
Hi all!
I try to compile grass7 from svn I reach this error:
GRASS GIS compilation log
-
Started compilation: Wed Mar 3 12:34:18 CET 2010
--
Errors in:
/home/pietro/builds/grass70/src/grass70/lib/python
/home/pietro/builds/grass70/src/grass70/scripts/d.vect.thematic
/home/pietro/builds/grass70/src/grass70/scripts/r.in.srtm
/home/pietro/builds/grass70/src/grass70/scripts/v.db.update
--
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.
--
then I try to run 'make':
--
$ cd src/grass70/lib/python/
python $ make
python -m py_compile /home/pietro/builds/grass70/src/grass70/dist.x86_64-
unknown-linux-gnu/etc/python/grass/script/core.py
Sorry: IndentationError: ('expected an indented block',
('/home/pietro/builds/grass70/src/grass70/dist.x86_64-unknown-linux-
gnu/etc/python/grass/script/core.py', 71, 10, 'return val\n'))make: ***
[/home/pietro/builds/grass70/src/grass70/dist.x86_64-unknown-linux-
gnu/etc/python/grass/script/core.pyc] Error 1
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Use Global variables at Scripts (Python)
In data giovedì 25 febbraio 2010 19:34:25, Luis Lisboa ha scritto:
: Hi
I'm programming a few Scripts and I would like to know How can I access
some global variables value such as GRASS_DIR, MAPSET; LOCATIOn or even
others that I defined (e.g. GRASS_TEMP). How can I load and access them?
(I'm working with Python scripts for GRASS 7)
You could do something like:
-
#!/usr/bin/python
import grass.script as grs
# get info about my location and mapset
env = grs.gisenv()
pathbase = env['GISDBASE']
location = env['LOCATION_NAME']
mapset = env['MAPSET']
# get absolut path to actually mapset
pathmapset=path.join(pathbase, location, mapset)
# get rasters
rasters=grs.list_grouped('rast')
# get vectors
vectors=grs.list_grouped('vect')
may be there are something better...
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Segmentation fault with r.cost in grass7.0
Hi all! I'm Pietro and this is my first message here! So be patient if my information is lacking in something. I try to run r.cost on grass70 from svn but I have this output message: GRASS GIS 7.0 svn:40557-40571 === $ r.cost -k input=dtm_d...@trentino output=provarcost70 start_rast=via...@trentino Will need at least 0.00 MB of disk space Will need at least 0.00 MB of memory WARNING: segment_setup: illegal segment file parameters Reading raster map dtm_d...@trentino, initializing output... Segmentation fault Grass6.4 work fine! And I get this: GRASS GIS 6.4.0RC5 $ r.cost -k input=dtm_d...@trentino output=provarcost start_rast=via...@trentino Reading raster map dtm_d...@trentino... 100% Initializing output... 100% Reading raster map viafor... 100% Finding cost path... 100% No data Writing raster map provarcost... 100% r.cost complete. Peak cost value: 132.490 More Details about my system: === OS: Linux Distribution: Archlinux kernel: 2.6.32-ARCH gcc: 4.4.2 20091208 (prerelease) (GCC) Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/usr --enable-shared --enable- languages=c,c++,fortran,objc,obj-c++,ada --enable-threads=posix -- mandir=/usr/share/man --infodir=/usr/share/info --enable-__cxa_atexit --disable- multilib --libdir=/usr/lib --libexecdir=/usr/lib --enable-clocale=gnu --disable- libstdcxx-pch --with-tune=generic Thread model: posix Architecture compile flags: CARCH=x86_64 CHOST=x86_64-unknown-linux-gnu CFLAGS=-march=core2 -O2 -pipe CXXFLAGS=-march=core2 -02 -pipe MAKEFLAGS=-j3 Compile grass with: ./configure --prefix=/opt --with-gdal=/usr/bin/gdal-config --with-sqlite -- with-python --with-wxwidgets=/usr/bin/wx-config --with-blas --with-lapack -- with-postgres --with-proj-libs=/usr/lib --with-proj-includes=/usr/include -- with-proj-share=/usr/share/proj --with-fftw --with-fftw- includes=/usr/include --with-fftw-libs=/usr/lib --with-freetype=yes --with- freetype-includes=/usr/include/freetype2/ --with-pthread Any hint? Pietro ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
