Re: [GRASS-user] [GRASS-dev] wxGUI raster digitizer available

[Paulo van Breugel]

Hi Anna

This is great, thanks! This is going to be a real time saver.

I am having trouble however running it. I seems to work fine except that I
can't save the edits. To leave the editing session, I have to select no
when asked to save the work.

Not sure if the below helps, but in the terminal I get the message:
GRASS_INFO_ERROR(30864,1): Raster map 
not found
GRASS_INFO_END(30864,1)

>From the command console:

Exception in thread Thread-8:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 810, in
__bootstrap_inner
self.run()
  File "/usr/local/grass7/grass-7.1.svn/gui/wxpython/core/gt
hread.py", line 94, in run
ret = vars()['callable'](*args, **kwds)
  File "/usr/local/grass7/grass-7.1.svn/gui/wxpython/rdigit/
controller.py", line 467, in _exportRaster
output=self._editedRaster, overwrite=True, quiet=True)
  File "/usr/local/grass7/grass-7.1.svn/etc/python/grass/scr
ipt/core.py", line 373, in run_command
return handle_errors(returncode, returncode, args,
kwargs)
  File "/usr/local/grass7/grass-7.1.svn/etc/python/grass/scr
ipt/core.py", line 308, in handle_errors
returncode=returncode)
CalledModuleError: Module run None ['r.patch', '--o', '--q',
u'input=x47731795,pnv_malawi2_ag2_backupcopy_30725',
u'output=pnv_malawi2_ag2@vegetation'] ended with error
Process ended with non-zero return code 1. See errors in the
(error) output.



On Wed, Nov 19, 2014 at 11:56 PM, Anna Petrášová 
wrote:

>
>
> On Wed, Nov 19, 2014 at 3:31 PM, Markus Neteler  wrote:
>
>> Hi Anna,
>>
>> On Tue, Nov 18, 2014 at 5:19 AM, Anna Petrášová 
>> wrote:
>> > Hi all,
>> >
>> > I added raster digitizer in r62792 in trunk.
>>
>> what a great job!
>>
>> If you didn't find it: it is in the "Map Display" windows, then
>> selector on the right side (2D/3D/Vector digitizer/Raster digitizer).
>>
>
> Once everything works, I will probably make a short video tutorial.
>
>>
>> > You are welcome to test it and
>> > report bugs/enhancements.
>> > It currently allows to draw areas, lines and points and specify width to
>> > buffer individual features. We can discuss some changes in gui
>> interface and
>> > behavior if you find the current one intuitive.  There is still a lot to
>> > improve especially in the drawing part (needs some refactoring of the
>> old
>> > drawing code).
>>
>> One general thing I found (also valid for the vector digitizer): I
>> wonder where to put a message what the mouse buttons mean.
>> Maybe in the status bar at bottom of the display/digitizer window?
>>
>> > Features:
>> > - draw area, line, point
>>
>> ... works.
>>
>> > - specify buffer width for individual features to create for example
>> > circles, roads of certain width...
>>
>> ... maybe rename from "Width" to "Buffer width"? Otherwise it could be
>> confused with the drawing line width.
>>
>
> There is not much space in toolbar..., especially if we in the future add
> more items (settings, label editing for example). What about just 'Buffer'?
> Currently the width is the width of the buffered line/diameter of the point
> (circle), which means 2 x buffer distance, so if we change it to buffer,
> then the value should be half of the line width?
>
>>
>> > - specify background map
>>
>> ... works (maybe have a button to optionally take computational region
>> from that map?)
>>
>
> Yes possibly, I am not sure about the region in general, if there should
> be any special handling.
>
>>
>> > - simple undo
>> > - save button to save results during drawing
>>
>> here I got an issue somewhere:
>>
>> Exception in thread Thread-4:
>> Traceback (most recent call last):
>>   File "/usr/lib64/python2.7/threading.py", line 811, in
>> __bootstrap_inner
>> self.run()
>>   File "/home/neteler/software/grass71/dist.x86_64-unknown-
>> linux-gnu/gui/wxpython/core/gthread.py", line 94, in run
>> ret = vars()['callable'](*args, **kwds)
>>   File "/home/neteler/software/grass71/dist.x86_64-unknown-
>> linux-gnu/gui/wxpython/rdigit/controller.py", line 432, in
>> _exportRaster
>> if item.GetPropertyVal('widthValue') and \
>>   File "/home/neteler/software/grass71/dist.x86_64-unknown-
>> linux-gnu/gui/wxpython/mapwin/graphics.py", line 439, in
>> GetPropertyVal
>> raise KeyError(_("Property does not exist: %s") %
>> (propName))
>> KeyError: 'Property does not exist: widthValue'
>>
>>
>>
> it normally works... Does this happen every time?
>
>
>> > - keeps drawing order in the output raster map
>> > - change color of drawing
>> > - doesn't block gui when exporting raster (which can take some time)
>>
>> Nice!
>>
>> > Does not support (yet?):
>> > - adding labels
>> > - interactive setting color of raster cells (not planned, there are
>> other tools)
>> > - vector export/import
>> >
>> > Known issues:
>> > - r.in.poly supports only CELL (I just realized that, this must be
>> changed)
>>
>> (meanwhile you changed that already, thanks)
>>
>> > - various small drawing issues
>> > - slow when exporting features with buffers

Re: [GRASS-user] [GRASS-dev] wxGUI raster digitizer available

[Paulo van Breugel]

While trying to replicate the steps, I found out it worked this time.
Difference was that last time I edited a very large map so the process got
probably stuck. Sorry for the false alarm. And again, a great new feature!!

On Thu, Nov 20, 2014 at 7:31 PM, Anna Petrášová 
wrote:

>
>
> On Thu, Nov 20, 2014 at 4:37 AM, Paulo van Breugel  > wrote:
>
>> Hi Anna
>>
>> This is great, thanks! This is going to be a real time saver.
>>
>> I am having trouble however running it. I seems to work fine except that
>> I can't save the edits. To leave the editing session, I have to select no
>> when asked to save the work.
>>
>> Not sure if the below helps, but in the terminal I get the message:
>> GRASS_INFO_ERROR(30864,1): Raster map 
>> not found
>> GRASS_INFO_END(30864,1)
>>
>> From the command console:
>>
>> Exception in thread Thread-8:
>> Traceback (most recent call last):
>>   File "/usr/lib/python2.7/threading.py", line 810, in
>> __bootstrap_inner
>> self.run()
>>   File "/usr/local/grass7/grass-7.1.svn/gui/wxpython/core/gt
>> hread.py", line 94, in run
>> ret = vars()['callable'](*args, **kwds)
>>   File "/usr/local/grass7/grass-7.1.svn/gui/wxpython/rdigit/
>> controller.py", line 467, in _exportRaster
>> output=self._editedRaster, overwrite=True, quiet=True)
>>   File "/usr/local/grass7/grass-7.1.svn/etc/python/grass/scr
>> ipt/core.py", line 373, in run_command
>> return handle_errors(returncode, returncode, args,
>> kwargs)
>>   File "/usr/local/grass7/grass-7.1.svn/etc/python/grass/scr
>> ipt/core.py", line 308, in handle_errors
>> returncode=returncode)
>> CalledModuleError: Module run None ['r.patch', '--o', '--q',
>> u'input=x47731795,pnv_malawi2_ag2_backupcopy_30725',
>> u'output=pnv_malawi2_ag2@vegetation'] ended with error
>> Process ended with non-zero return code 1. See errors in the
>> (error) output.
>>
>
> Strange, could you describe the exact steps?
>
>
>
>>
>>
>>
>> On Wed, Nov 19, 2014 at 11:56 PM, Anna Petrášová 
>> wrote:
>>
>>>
>>>
>>> On Wed, Nov 19, 2014 at 3:31 PM, Markus Neteler 
>>> wrote:
>>>
>>>> Hi Anna,
>>>>
>>>> On Tue, Nov 18, 2014 at 5:19 AM, Anna Petrášová 
>>>> wrote:
>>>> > Hi all,
>>>> >
>>>> > I added raster digitizer in r62792 in trunk.
>>>>
>>>> what a great job!
>>>>
>>>> If you didn't find it: it is in the "Map Display" windows, then
>>>> selector on the right side (2D/3D/Vector digitizer/Raster digitizer).
>>>>
>>>
>>> Once everything works, I will probably make a short video tutorial.
>>>
>>>>
>>>> > You are welcome to test it and
>>>> > report bugs/enhancements.
>>>> > It currently allows to draw areas, lines and points and specify width
>>>> to
>>>> > buffer individual features. We can discuss some changes in gui
>>>> interface and
>>>> > behavior if you find the current one intuitive.  There is still a lot
>>>> to
>>>> > improve especially in the drawing part (needs some refactoring of the
>>>> old
>>>> > drawing code).
>>>>
>>>> One general thing I found (also valid for the vector digitizer): I
>>>> wonder where to put a message what the mouse buttons mean.
>>>> Maybe in the status bar at bottom of the display/digitizer window?
>>>>
>>>> > Features:
>>>> > - draw area, line, point
>>>>
>>>> ... works.
>>>>
>>>> > - specify buffer width for individual features to create for example
>>>> > circles, roads of certain width...
>>>>
>>>> ... maybe rename from "Width" to "Buffer width"? Otherwise it could be
>>>> confused with the drawing line width.
>>>>
>>>
>>> There is not much space in toolbar..., especially if we in the future
>>> add more items (settings, label editing for example). What about just
>>> 'Buffer'? Currently the width is the width of the buffered line/diameter of
>>> the point (circle), which means 2 x buffer distance, so if we change it to
>>> buffer, then the value should be half of the line width?
>>>
>>&g

[GRASS-user] ps.map and cartographic composer

[Paulo van Breugel]

I have created a .psmap file to create a map in ps format with the
cartographic composer. The ps file created is about 35MB.

When using the same .psmap file in in the ps.map function, the ps file
created is > 1GB (basically the size of the raster file used for the map.

Any idea what I am doing wrong?

The psmap file:

# timestamp: 2014-12-07 21:57
# location: latlon
# mapset: plantspecies
# page orientation: Portrait
# g.region rast=bvmeat_kg@CSIRO2005

maploc 0.2 0.2 11.8 4.9
border n

paper
width 11.2
height 4.5
left 0.1
right 0.1
bottom 0.1
top 0.1
end

vareas glbl0@PERMANENT
layer 1
masked n
color 0:0:0
width 0.2
fcolor none
label world_boundaries(PERMANENT)
lpos 1
end
raster bvmeat_kg@CSIRO2005
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] ps.map and cartographic composer

[Paulo van Breugel]

To answer my own question, to control the resolution of the output image
one need to set the region resolution (using g.region) to match the desired
image resolution. I guess the cartographic composer does this somehow
automatically (?).


On Sun, Dec 7, 2014 at 11:35 PM, Paulo van Breugel 
wrote:

> I have created a .psmap file to create a map in ps format with the
> cartographic composer. The ps file created is about 35MB.
>
> When using the same .psmap file in in the ps.map function, the ps file
> created is > 1GB (basically the size of the raster file used for the map.
>
> Any idea what I am doing wrong?
>
> The psmap file:
>
> # timestamp: 2014-12-07 21:57
> # location: latlon
> # mapset: plantspecies
> # page orientation: Portrait
> # g.region rast=bvmeat_kg@CSIRO2005
>
> maploc 0.2 0.2 11.8 4.9
> border n
>
> paper
> width 11.2
> height 4.5
> left 0.1
> right 0.1
> bottom 0.1
> top 0.1
> end
>
> vareas glbl0@PERMANENT
> layer 1
> masked n
> color 0:0:0
> width 0.2
> fcolor none
> label world_boundaries(PERMANENT)
> lpos 1
> end
> raster bvmeat_kg@CSIRO2005
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] problems with r.mapcalc

[Paulo van Breugel]

Not sure that will give you a solution, but an r.mapcalc expression in
grass 7.1 should look like:

r.mapcalc --overwrite expression="bla = NDVI_1_h11v11 - NDWI_1_h11v11"

In other words 1) the --o flag in grass 6.4 was changed to --overwrite in
grass 7 and higher, and 2) there should be a space before the first *=*
sign.

Check out: http://grass.osgeo.org/grass71/manuals/r.mapcalc.html

Paulo


On Mon, Dec 8, 2014 at 10:23 PM, Diana Brito  wrote:

> Hi list,
>
> first, i'm new with grass
>
> Im trying to do some math calculations with r.mapcalc, but my result
> allways is nan.
>
> When I display the image I can see different values, not only nan.
>
> Thanks
>
>
>
> GRASS 7.1.svn (sequia):/opt/grass_trunk/bin.x86_64-unknown-linux-gnu >
> r.info NDVI_1_h11v11
>
>
>  
> ++
>  | Map:  NDVI_1_h11v11  Date: Mon Dec  1 05:12:28 2014
>|
>  | Mapset:   sequia Login of Creator: polzader
>|
>  | Location: sequia
> |
>  | DataBase: /home/polzader/Documentos/grassdata_diana_bpr
>|
>  | Title: ( NDVI_1_h11v11 )
> |
>  | Timestamp: none
>|
>
>  
> ||
>  |
>|
>  |   Type of Map:  raster   Number of Categories: 0
> |
>  |   Data Type:DCELL
>|
>  |   Rows: 4409
> |
>  |   Columns:  7499
> |
>  |   Total Cells:  33063091
> |
>  |Projection: Latitud - Longitud.
> |
>  |N: 19:54:02.16SS: 30:01:58.200271S   Res: 0:00:08.273087
>|
>  |E: 63:35:44.521118WW: 80:49:44.4W   Res: 0:00:08.273087
> |
>  |   Range of data:min = -2000  max = 9090
>|
>  |
>|
>  |   Data Description:
>|
>  |generated by r.series
> |
>  |
>|
>  |   Comments:
>|
>  |r.series
> input="MOD13Q1.A2004001.h11v11.005.2007235231758.250m_16_da\   |
>  |   ys_NDVI,MOD13Q1.A2005001.h11v11.005.2007352072715.250m_16_days_NDVI,\
>   |
>  |
>  MOD13Q1.A2006001.h11v11.005.2008064055525.250m_16_days_NDVI,MOD13Q1.\   |
>  |
>  A2007001.h11v11.005.2007021105928.250m_16_days_NDVI,MOD13Q1.A2008001\   |
>  |
>  .h11v11.005.2008019102106.250m_16_days_NDVI,MOD13Q1.A2009001.h11v11.\   |
>  |
>  005.2009019230008.250m_16_days_NDVI,MOD13Q1.A2010001.h11v11.005.2010\   |
>  |
>  027061330.250m_16_days_NDVI,MOD13Q1.A2011001.h11v11.005.201102405534\   |
>  |
>  0.250m_16_days_NDVI,MOD13Q1.A2012001.h11v11.005.2012019103715.250m_1\   |
>  |
>  6_days_NDVI,MOD13Q1.A2013001.h11v11.005.2013018034332.250m_16_days_N\   |
>  |
>  DVI,MOD13Q1.A2014001.h11v11.005.2014018092301.250m_16_days_NDVI,MOD1\   |
>  |
>  3Q1.A2004017.h11v11.005.2008224113415.250m_16_days_NDVI,MOD13Q1.A200\   |
>  |
>  5017.h11v11.005.2007353093413.250m_16_days_NDVI,MOD13Q1.A2006017.h11\   |
>  |
>  v11.005.2008278011906.250m_16_days_NDVI,MOD13Q1.A2007017.h11v11.005.\   |
>  |
>  2007096165508.250m_16_days_NDVI,MOD13Q1.A2008017.h11v11.005.20080370\   |
>  |
>  54317.250m_16_days_NDVI,MOD13Q1.A2009017.h11v11.005.2009035200807.25\   |
>  |
>  0m_16_days_NDVI,MOD13Q1.A2010017.h11v11.005.2010036002816.250m_16_da\   |
>  |
>  ys_NDVI,MOD13Q1.A2011017.h11v11.005.2011039201212.250m_16_days_NDVI,\   |
>  |
>  MOD13Q1.A2012017.h11v11.005.2012046172118.250m_16_days_NDVI,MOD13Q1.\   |
>  |
>  A2013017.h11v11.005.2013039191638.250m_16_days_NDVI,MOD13Q1.A2014017\   |
>  |.h11v11.005.2014038143732.250m_16_days_NDVI" output="NDVI_1_h11v11"
> \   |
>  |method="average"
>|
>  |
>|
>
>  
> ++
>
> GRASS 7.1.svn (sequia):/opt/grass_trunk/bin.x86_64-unknown-linux-gnu >
> r.info NDWI_1_h11v11
>
>  
> ++
>  | Map:  NDWI_1_h11v11  Date: Mon Dec  1 05:49:38 2014
>|
>  | Mapset:   sequia Login of Creator: polzader
>|
>  | Location: sequia
> |
>  | DataBase: /home/polzader/Documentos/grassdata_diana_bpr
>|
>  | Title: ( NDWI_1_h11v11 )
> |
>  | Timestamp: none
>|
>
>  
> ||
>  |
>|
>  |   Type of Map:  raster   Number of Categories: 0
> |
>  |   Data Type:DCELL
>|
>  |   Rows: 4409
> |
>  |   Columns:  7499
> |
>  |   Total Cells:  33063091
> |
>  |Projection: Latitud - Longitud.
> |
>  |N: 19:54:02.16SS: 30:01:58.200271S   Res: 0:00:08.273087
>|
>  |E: 63:35:44.521118WW: 80:49:44.4W   Res: 0:00:08.273087
> |
>  |   Range of data:min = -9254.65838509317  max = 9247.07852234276
>|
>  |
>|
>  |   Data Description:
>|
>  |generated by r.mapcalc
>|
>  |
>|
>  |   Comments:
>|
>  |(NIR_reflectance_1_h11v11 - MIR_reflectance_1_h11v11) /
> |
>  |  

Re: [GRASS-user] randomize the position of a raster map

[Paulo van Breugel]

Nice suggestions Moritz. Another alternative to accomplish this is to
combine r.surf.random and r.recode (instead of recode, one can also use
r.reclass). I haven't tried it, but this might be faster for large maps or
with many categories?

r.surf.random flags=i, output=LUCrandom min=0 max=1
r.recode input=LUCrandom output=LUCrandom2 << EOF
0:2931:1
2932:3017:2
3018:4041:3
4042:4716:4
4717:9780:5
9781:9993:6
9994:1:7
EOF



On Tue, Dec 9, 2014 at 3:55 PM, Moritz Lennert  wrote:

> On 08/12/14 18:26, Milton Ribeiro wrote:
>
>> Hi all,
>>
>> I have a landcover maps, and I need to randomize the position of them,
>> keeping all the pixels on the new raster map.
>>
>
> IIUC, you actually want to randomize the categories of pixels where
> categories are land covers and there is a constraint that you want to keep
> the same number of pixels per category. Is that correct ?
>
>  Is there a command that can do this within GRASS?
>>
>
> You could use r.random following a procedure something like this:
>
> create a raster (mymask) where all cells are non-null
>
> for each category of land cover,
> get cat and percentage of cover of that cat (e.g. via r.stats)
> run r.random, using cover=mymask and n=percentage of cover
> modify mymask so that the cells attributed in the previous run of
> r.random get set to null to make them unavailable in the next run
>
> There is just one issue: the cover option in r.random provokes a check if
> the randomly selected cell is in the cover area or not. If not, it is not
> used, but no replacement is found, so if you use cover= the percentage
> value in n= is not respected... Ideally this should be corrected to while
> cell number X is not within the cover, find a new cell. See [1] for an old
> discussion about this.
>
> Attached is a bash script that tries to work around this issue and works
> more or less for me (at least with the "landuse dataset in the simplified
> NC dataset). Certainly not perfect, but maybe you can build on that.
>
> Another option might be something like this:
>
> Knowing that:
>
> r.stats -ncp landuse --quiet
> 1 73077 29.31%
> 2 2137 0.86%
> 3 25518 10.24%
> 4 16829 6.75%
> 5 126265 50.64%
> 6 5303 2.13%
> 7 194 0.08%
>
> use the random generator in r.mapcalc
>
> r.mapcalc "eval(random = rand(0.0,1.0)); landuse_randomized_mapcalc =
> if(random<=0.2931,1, if(random>0.2931 && random <=0.3017,2,if(random>0.3017
> && random <=0.4041, 3, if(random>0.4041 && random<=0.4716, 4, if(random >
> 0.4716 && random <=0.9780, 5, if(random>0.9780 && random <=0.9993, 5,
> 6))"  --o
>
> The result is not perfect in terms of cell counts, but close:
>
> r.stats -ncp landuse_randomized_mapcalc --quiet
> 1 73402 29.46%
> 2 2061 0.83%
> 3 25215 10.12%
> 4 16982 6.82%
> 5 131484 52.78%
> 6 180 0.07%
>
>
> Moritz
>
> [1] https://trac.osgeo.org/grass/ticket/1082
>
>
>
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] [GRASSLIST:270] Fwd: Developing a forest fragmentation index

[Paulo van Breugel]

Hi Anusheema

As I replied on your question on my blogpost, there are two versions of the
script; one for GRASS 6  and one for GRASS 7. In both cases you need to
install the script manually (I am planning to rewrite the script as a
python script, but that will take some time).

The script for GRASS 7 did indeed not work anymore for me due to syntax
changes in some of the functions used. An updated version should be
available on
http://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.forestfrag.
If you try out and it doesn't work, let me know (and if so, please indicate
whether you are running this on Linux or Windows).

Paulo


On Sat, Dec 27, 2014 at 2:38 PM, Markus Neteler  wrote:

> On Sat, Dec 27, 2014 at 12:53 PM, anusheema  wrote:
> > Dear list members,
> >
> > I am also interested in implementing Dr. Kurt Ritters forest
> fragmentation
> > model. I was, however, attempting this in R Statistical software,
> although I
> > am pretty new to both R and GRASS.
>
> Which GRASS version do you use?
>
> > While reading forums on this model, I came across this post. I see that
> Mr.
> > Maning Sambale and Mr. Stefan Sylla have developed an AddOn for GRASS:
> > r.forestfrag (http://grasswiki.osgeo.org/wiki/GRASS_AddOns#r.forestfrag
> ).
> > But while trying to attempt this model on GRASS, it keeps showing an
> error
> > (AddOn not found).
>
> If you are using GRASS 6: the script has been written for GRASS 7. You
> can install both 6 and 7 in parallel on the same computer. However, I
> see a link to a GRASS 6 version of the script in the Wiki page.
>
> If you are using GRASS 7: The reason is that it has not been
> implemented as Python script but as Shell script. To my knowledge
> g.extention (the extension manager) is not capable to deal with shell
> scripts.
>
> > If you could please share the script? I was trying to implement the
> script
> > mentioned in this post, but without much luck. In R, with the help of
> this
> > script, replicating Pf is easier, however, for Pff, implementing the
> code in
> > cardinal direction only, is more complex.
>
> You can simply download the script from here:
>
> http://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.forestfrag/r.forestfrag?format=txt
> and put it into the search path in your GRASS session. Be sure to set
> the "executable" flag.
>
> Please let us know how it goes.
>
> Markus
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] [GRASSLIST:270] Fwd: Developing a forest fragmentation index

[Paulo van Breugel]

Hi, there is an updated version for grass 7 which you can install using
g.extension.

On Sat, 27 Dec 2014 18:40 Anusheema Chakraborty  wrote:

> Thanks for the response!
>
> I was trying to use the shell script in GRASS 6. And I am working on a
> Windows system. I'll use the updated version of the Shell script with GRASS
> version 7, I suppose, and I would let you know how it goes.
>
> Thanks again!
>
> On 27 December 2014 at 19:25, Paulo van Breugel 
> wrote:
>
>> Hi Anusheema
>>
>> As I replied on your question on my blogpost, there are two versions of
>> the script; one for GRASS 6  and one for GRASS 7. In both cases you need to
>> install the script manually (I am planning to rewrite the script as a
>> python script, but that will take some time).
>>
>> The script for GRASS 7 did indeed not work anymore for me due to syntax
>> changes in some of the functions used. An updated version should be
>> available on
>> http://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.forestfrag.
>> If you try out and it doesn't work, let me know (and if so, please indicate
>> whether you are running this on Linux or Windows).
>>
>> Paulo
>>
>>
>> On Sat, Dec 27, 2014 at 2:38 PM, Markus Neteler 
>> wrote:
>>
>>> On Sat, Dec 27, 2014 at 12:53 PM, anusheema  wrote:
>>> > Dear list members,
>>> >
>>> > I am also interested in implementing Dr. Kurt Ritters forest
>>> fragmentation
>>> > model. I was, however, attempting this in R Statistical software,
>>> although I
>>> > am pretty new to both R and GRASS.
>>>
>>> Which GRASS version do you use?
>>>
>>> > While reading forums on this model, I came across this post. I see
>>> that Mr.
>>> > Maning Sambale and Mr. Stefan Sylla have developed an AddOn for GRASS:
>>> > r.forestfrag (
>>> http://grasswiki.osgeo.org/wiki/GRASS_AddOns#r.forestfrag).
>>> > But while trying to attempt this model on GRASS, it keeps showing an
>>> error
>>> > (AddOn not found).
>>>
>>> If you are using GRASS 6: the script has been written for GRASS 7. You
>>> can install both 6 and 7 in parallel on the same computer. However, I
>>> see a link to a GRASS 6 version of the script in the Wiki page.
>>>
>>> If you are using GRASS 7: The reason is that it has not been
>>> implemented as Python script but as Shell script. To my knowledge
>>> g.extention (the extension manager) is not capable to deal with shell
>>> scripts.
>>>
>>> > If you could please share the script? I was trying to implement the
>>> script
>>> > mentioned in this post, but without much luck. In R, with the help of
>>> this
>>> > script, replicating Pf is easier, however, for Pff, implementing the
>>> code in
>>> > cardinal direction only, is more complex.
>>>
>>> You can simply download the script from here:
>>>
>>> http://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.forestfrag/r.forestfrag?format=txt
>>> and put it into the search path in your GRASS session. Be sure to set
>>> the "executable" flag.
>>>
>>> Please let us know how it goes.
>>>
>>> Markus
>>> ___
>>> grass-user mailing list
>>> grass-user@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/grass-user
>>>
>>
>>
>
>
> --
>
> *Anusheema Chakraborty*
> PhD Scholar
> Department of Natural Resources
> TERI University
> 10, Institutional Area, Vasant Kunj, New Delhi - 110070 (India)
> Website: www.teriuniversity.ac.in
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] dilation & erosion (mathematical morphology)

[Paulo van Breugel]

Check out the r.growth.shrink addon.

On Thu, Feb 5, 2015 at 1:59 PM, Robert Nuske  wrote:

> Hi there,
>
> looking at some noisy raster map, I would like to clean up the patches (map
> consists only of one class and NULL) using basic mathematical morphology
> (dilation & erosion) in GRASS 7.0.
>
>
> The dilation can easily be achieved with r.grow.
> But the erosion seems not to be as straight forward.
>
> Since the example about shrinking was removed from the help page of r.grow
> in
> GRASS 7.0 (http://grass.osgeo.org/grass70/manuals/r.grow.html), I hoped
> for an
> easier way to carry out the erosion. Looking in vain for a raster command
> named shrink or erode, I tried a negative distance in r.buffer (-> error)
> and
> negative radius in r.grow (treated as absolute value).
>
> The following produce identical output with grown patches.
>   r.grow in=mod_10_33 out=mod_10_33_1 radius=1.1
>   r.grow in=mod_10_33 out=mod_10_33_2 radius=-1.1
>
>
> Any suggestions for a quick erosion?
>
>
> thanks
>   Robert
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] trouble with addons - was: dilation & erosion (mathematical morphology)

[Paulo van Breugel]

you should be able to install the addon from within GRASS using g.extension
or via the menu (settings - addon extensions). If you mean with 'standard
user' an user without administrative privileges, then yes, I think you
should be able to install the addons, they are normally installed in a
hidden folder (.grass7) in the home folder.



On Thu, Feb 5, 2015 at 3:52 PM, Robert Nuske  wrote:

> Hi Paulo,
>
> thanks for the hint!
>
>
> Now I have some trouble to install the addon:
>
> As a standard user I am not allowed to create a directory under /usr/lib.
> A second try as root failed because HTML2MAN within "Grass.make" tries to
> call
> $(GISBASE)/tools/g.html2man.py. But the python script is called
> g.html2man.
> After linking g.html2man.py to g.html2man the built of the addon fails
> because
> of a missing python module (ImportError: No module named html).
>
>
> This was on ubuntu 14.04 with grass70 from the ppa:grass-devel.
> Version 7.0.0+1svn64464~ubuntu14.04.1 installed today.
>
>
>
> Are addons supposed to be installed by standard users?
>
>
> thanks
>   robert
>
>
>
> as standard user:
> ---
> GRASS 7.0.0 (wgs84):~ > g.extension extension=r.grow.shrink
> svnurl=http://svn.osgeo.org/grass/grass-addons/grass7 --verbose
> Fetching  from GRASS-Addons SVN repository (be patient)...
> Ar.grow.shrink/DEPRECATED
> Ar.grow.shrink/main.c
> Ar.grow.shrink/Makefile
> Ar.grow.shrink/r.grow.shrink.html
>  U   r.grow.shrink
> Checked out revision 64471.
> Compiling...
> mkdir -p /tmp/tmpGP17FI/r.grow.shrink/bin
> mkdir -p /tmp/tmpGP17FI/r.grow.shrink/etc
> mkdir -p /tmp/tmpGP17FI/r.grow.shrink/docs/html
> mkdir -p /usr/lib/grass70/docs/man
> mkdir: cannot create directory '/usr/lib/grass70/docs/man': Permission
> denied
> make: *** [/usr/lib/grass70/docs/man] Error 1
> ERROR: Compilation failed, sorry. Please check above error messages.
>
>
> as root (sudo -i):
> ---
> GRASS 7.0.0 (wgs84):~ > g.extension extension=r.grow.shrink
> svnurl=http://svn.osgeo.org/grass/grass-addons/grass7 --verbose
> Fetching  from GRASS-Addons SVN repository (be patient)...
> Ar.grow.shrink/DEPRECATED
> Ar.grow.shrink/main.c
> Ar.grow.shrink/Makefile
> Ar.grow.shrink/r.grow.shrink.html
>  U   r.grow.shrink
> Checked out revision 64471.
> Compiling...
> mkdir -p /tmp/tmpa27tYO/r.grow.shrink/bin
> mkdir -p /tmp/tmpa27tYO/r.grow.shrink/etc
> mkdir -p /tmp/tmpa27tYO/r.grow.shrink/docs/html
> mkdir -p /usr/lib/grass70/docs/man
> mkdir -p /tmp/tmpa27tYO/r.grow.shrink/docs/man/man1
> test -d OBJ.x86_64-pc-linux-gnu || mkdir -p OBJ.x86_64-pc-linux-gnu
> gcc  -Wall -g -O   -I/usr/lib/grass70/include -I/usr/lib/grass70/include
>   -
> DPACKAGE=\""grassmods"\"   -I/usr/lib/grass70/include -
> I/usr/lib/grass70/include -DRELDIR=\"/tmp/tmpa27tYO/r.grow.shrink\" -o
> OBJ.x86_64-pc-linux-gnu/main.o -c main.c
> : && gcc -L/usr/lib/grass70/lib -L/usr/lib/grass70/lib
> -Wl,--export-dynamic -
> Wl,-rpath-link,/usr/lib/grass70/lib  -o
> /tmp/tmpa27tYO/r.grow.shrink/bin/r.grow.shrink
> OBJ.x86_64-pc-linux-gnu/main.o
> -lgrass_gis.7.0.0svn -lgrass_raster.7.0.0svn  -lm
> if [ "/tmp/tmpa27tYO/r.grow.shrink/bin/r.grow.shrink" != "" ] ; then
> GISRC=/tmp/grass7-root-12200/gisrc GISBASE=/usr/lib/grass70
> PATH="/usr/lib/grass70/bin:/usr/lib/grass70/bin:/usr/lib/grass70/scripts:
> $PATH"
> PYTHONPATH="/usr/lib/grass70/etc/python:/usr/lib/grass70/gui/wxpython:
> $PYTHONPATH"
>
> LD_LIBRARY_PATH="/tmp/tmpa27tYO/r.grow.shrink/bin:/usr/lib/grass70/scripts:/usr/lib/grass70/lib:/usr/lib/grass70/lib:/usr/lib/grass70/lib"
> LC_ALL=C /tmp/tmpa27tYO/r.grow.shrink/bin/r.grow.shrink --html-description
> <
> /dev/null | grep -v '\|' > r.grow.shrink.tmp.html ; fi
> VERSION_NUMBER=7.0.0svn VERSION_DATE=2015 \
> python /usr/lib/grass70/tools/mkhtml.py r.grow.shrink >
> /tmp/tmpa27tYO/r.grow.shrink/docs/html/r.grow.shrink.html
> VERSION_NUMBER=7.0.0svn /usr/lib/grass70/tools/g.html2man.py
> /tmp/tmpa27tYO/r.grow.shrink/docs/html/r.grow.shrink.html
> /tmp/tmpa27tYO/r.grow.shrink/docs/man/man1/r.grow.shrink.1
> /bin/sh: 1: /usr/lib/grass70/tools/g.html2man.py: not found
> make: *** [/tmp/tmpa27tYO/r.grow.shrink/docs/man/man1/r.grow.shrink.1]
> Error
> 127
> rm r.grow.shrink.tmp.html
> ERROR: Compilation failed, sorry. Please check above error messages.
>
>
>
> Am Donnerstag, 5. Februar 2015, 14:53:05 schrieb Paulo van Breugel:
> > Check out the r.growth.shrink ad

Re: [GRASS-user] trouble with addons - was: dilation & erosion (mathematical morphology)

[Paulo van Breugel]

I have svn revision r64291, and for me it works fine

On Thu, Feb 5, 2015 at 4:46 PM, Robert Nuske  wrote:

> hmm, that's what I hoped and what doesn't work
>
> Which leaves the question open whether it is me, the ubuntu package or the
> svn
> version (at or before changeset 64464) who causes the problem.
>
>
> thanks
>   robert
>
> Am Donnerstag, 5. Februar 2015, 16:15:02 schrieb Paulo van Breugel:
> > you should be able to install the addon from within GRASS using
> g.extension
> > or via the menu (settings - addon extensions). If you mean with 'standard
> > user' an user without administrative privileges, then yes, I think you
> > should be able to install the addons, they are normally installed in a
> > hidden folder (.grass7) in the home folder.
> >
> > On Thu, Feb 5, 2015 at 3:52 PM, Robert Nuske  wrote:
> > > Hi Paulo,
> > >
> > > thanks for the hint!
> > >
> > >
> > > Now I have some trouble to install the addon:
> > >
> > > As a standard user I am not allowed to create a directory under
> /usr/lib.
> > > A second try as root failed because HTML2MAN within "Grass.make" tries
> to
> > > call
> > > $(GISBASE)/tools/g.html2man.py. But the python script is called
> > > g.html2man.
> > > After linking g.html2man.py to g.html2man the built of the addon fails
> > > because
> > > of a missing python module (ImportError: No module named html).
> > >
> > >
> > > This was on ubuntu 14.04 with grass70 from the ppa:grass-devel.
> > > Version 7.0.0+1svn64464~ubuntu14.04.1 installed today.
> > >
> > >
> > >
> > > Are addons supposed to be installed by standard users?
> > >
> > >
> > > thanks
> > >
> > >   robert
> > >
> > > as standard user:
> > > ---
> > > GRASS 7.0.0 (wgs84):~ > g.extension extension=r.grow.shrink
> > > svnurl=http://svn.osgeo.org/grass/grass-addons/grass7 --verbose
> > > Fetching  from GRASS-Addons SVN repository (be
> patient)...
> > > Ar.grow.shrink/DEPRECATED
> > > Ar.grow.shrink/main.c
> > > Ar.grow.shrink/Makefile
> > > Ar.grow.shrink/r.grow.shrink.html
> > >
> > >  U   r.grow.shrink
> > >
> > > Checked out revision 64471.
> > > Compiling...
> > > mkdir -p /tmp/tmpGP17FI/r.grow.shrink/bin
> > > mkdir -p /tmp/tmpGP17FI/r.grow.shrink/etc
> > > mkdir -p /tmp/tmpGP17FI/r.grow.shrink/docs/html
> > > mkdir -p /usr/lib/grass70/docs/man
> > > mkdir: cannot create directory '/usr/lib/grass70/docs/man': Permission
> > > denied
> > > make: *** [/usr/lib/grass70/docs/man] Error 1
> > > ERROR: Compilation failed, sorry. Please check above error messages.
> > >
> > >
> > > as root (sudo -i):
> > > ---
> > > GRASS 7.0.0 (wgs84):~ > g.extension extension=r.grow.shrink
> > > svnurl=http://svn.osgeo.org/grass/grass-addons/grass7 --verbose
> > > Fetching  from GRASS-Addons SVN repository (be
> patient)...
> > > Ar.grow.shrink/DEPRECATED
> > > Ar.grow.shrink/main.c
> > > Ar.grow.shrink/Makefile
> > > Ar.grow.shrink/r.grow.shrink.html
> > >
> > >  U   r.grow.shrink
> > >
> > > Checked out revision 64471.
> > > Compiling...
> > > mkdir -p /tmp/tmpa27tYO/r.grow.shrink/bin
> > > mkdir -p /tmp/tmpa27tYO/r.grow.shrink/etc
> > > mkdir -p /tmp/tmpa27tYO/r.grow.shrink/docs/html
> > > mkdir -p /usr/lib/grass70/docs/man
> > > mkdir -p /tmp/tmpa27tYO/r.grow.shrink/docs/man/man1
> > > test -d OBJ.x86_64-pc-linux-gnu || mkdir -p OBJ.x86_64-pc-linux-gnu
> > > gcc  -Wall -g -O   -I/usr/lib/grass70/include
> -I/usr/lib/grass70/include
> > >
> > >   -
> > >
> > > DPACKAGE=\""grassmods"\"   -I/usr/lib/grass70/include -
> > > I/usr/lib/grass70/include -DRELDIR=\"/tmp/tmpa27tYO/r.grow.shrink\" -o
> > > OBJ.x86_64-pc-linux-gnu/main.o -c main.c
> > >
> > > : && gcc -L/usr/lib/grass70/lib -L/usr/lib/grass70/lib
> > >
> > > -Wl,--export-dynamic -
> > > Wl,-rpath-link,/usr/lib/grass70/lib  -o
> > > /tmp/tmpa27tYO/r.grow.shrink/bin/r.grow.shrink
> > > OBJ.x86_64-pc-linux-gnu/main.o
> > > -lgrass_gis.7.0.0svn -lgrass_raster.7.0.0svn 

Re: [GRASS-user] new addon: v.ellipse

[Paulo van Breugel]

Great.. one small comment, the reference link in the manual page is not
working.

Somehow your link (which is correct in your source html file) is rendered
as:
http://grass.osgeo.org/grass70/manuals/https://www.cs.cornell.edu/cv/OtherPdf/Ellipse.pdf

Paulo


On Wed, Feb 11, 2015 at 10:18 AM, Martin Landa 
wrote:

> Dear GRASS users,
>
> I would like to announce a new addon module v.ellipse [1] to compute
> the best-fitting ellipse for given vector data. The module has been
> written by Tereza Fiedlerova (cc'ed) at the CTU in Prague.
>
> Enjoy! Regards, Martin
>
> [1] http://grass.osgeo.org/grass70/manuals/addons/v.ellipse.html
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.eu/mentors/landa
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] percentage of class in raster within polygons

[Paulo van Breugel]

I haven't tested it, but the fastest way could be to rasterize your polygon
layer (using the resolution of the input raster or higher resolution - make
sure to assign an unique id to each grid cell before) and then use r.stats

r.stats -a -p input=rasterized_polygon,raster

Rgds,

Paulo


On Wed, Feb 11, 2015 at 12:15 PM, Margherita Di Leo 
wrote:

> Hi,
>
> I have to calculate the percentage of given class of a raster within the
> polygons given in a vector (a regular grid). Since I'm dealing with large
> files and operations repeated in a chain, i should be focusing on what is
> the optimal (fastest) option to do that. I could vectorize the raster and
> use v.overlay and v.to.db, or using v.rast.stats i can count out the number
> of cells (should i use number for that or sum?) and then divide per  area
> of the grid. Any better idea?
>
> Thank you in advance
>
> --
> Best regards,
>
> Dr. Margherita DI LEO
> Scientific / technical project officer
>
> European Commission - DG JRC
> Institute for Environment and Sustainability (IES)
> Via Fermi, 2749
> I-21027 Ispra (VA) - Italy - TP 261
>
> Tel. +39 0332 78 3600
> margherita.di-...@jrc.ec.europa.eu
>
> Disclaimer: The views expressed are purely those of the writer and may not
> in any circumstance be regarded as stating an official position of the
> European Commission.
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] [GRASS-dev] New stable release: GRASS GIS 7.0.0

[Paulo van Breugel]

Congratulations to all developers!!

On Sun, Feb 22, 2015 at 10:51 PM, Markus Neteler  wrote:

> Press release
>
> The GRASS GIS Development team has announced the release of the new
> major version GRASS GIS 7.0.0. This version provides many new
> functionalities including spatio-temporal database support, image
> segmentation, estimation of evapotranspiration and emissivity from
> satellite imagery, automatic line vertex densification during
> reprojection, more LIDAR support and a strongly improved graphical
> user interface experience. GRASS GIS 7.0.0 also offers significantly
> improved performance for many raster and vector modules: "Many
> processes that would take hours now take less than a minute, even on
> my small laptop!" explains Markus Neteler, the coordinator of the
> development team composed of academics and GIS professionals from
> around the world. The software is available for Linux, MS-Windows, Mac
> OSX and other operating systems.
>
> Detailed announcement and software download:
>
> http://grass.osgeo.org/news/42/15/GRASS-GIS-7-0-0/
>
>
> About GRASS GIS
>
> The Geographic Resources Analysis Support System
> (http://grass.osgeo.org/), commonly referred to as GRASS GIS, is an
> Open Source Geographic Information System providing powerful raster,
> vector and geospatial processing capabilities in a single integrated
> software suite. GRASS GIS includes tools for spatial modeling,
> visualization of raster and vector data, management and analysis of
> geospatial data, and the processing of satellite and aerial imagery.
> It also provides the capability to produce sophisticated presentation
> graphics and hardcopy maps. GRASS GIS has been translated into about
> twenty languages and supports a huge array of data formats. It can be
> used either as a stand-alone application or as backend for other
> software packages such as QGIS and R geostatistics. It is distributed
> freely under the terms of the GNU General Public License (GPL). GRASS
> GIS is a founding member of the Open Source Geospatial Foundation
> (OSGeo).
> ___
> grass-dev mailing list
> grass-...@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] upload raster category labels to vector point laye

[Paulo van Breugel]

Is there an (easy) way to upload raster category labels to a point file,
equivalent to uploading category values with v.what.rast?
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] upload raster category labels to vector point laye

[Paulo van Breugel]

Thanks! Yes that would indeed be a nice addition. I'll create a ticket.

Op do 26 feb. 2015 16:45 schreef Moritz Lennert <
mlenn...@club.worldonline.be>:
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Linking multidimensional data to a single point

[Paulo van Breugel]

Rich Shepard  schreef op 15 maart 2015 23:49:06 CET:
>On Sun, 15 Mar 2015, Andy Wickert wrote:
>
>> So to boil it down to the simplest part of what you said, the key is
>just
>> to have an ID column in the GRASS table that links to a table in a
>> database structure outside of GRASS?
>
>Andy,
>
>Yes. You can keep all point attributes in SQLite (or other rdbms)
>tables
>rather than in GRASS. 

The attribute table is in a sqlite table already, unless you are still using 
dbf as database backend for grass. Just link your other tables to that 
attribute table?


It's been a while since I last did this so the
>specifics are not immediately available. I would link each point to a
>table
>which describes it; perhaps including geographic coordinates, name, and
>other information. Then your discharge and sediment data are in other
>tables
>that are related to each row in the main table. This also allows you to
>run
>SQL queries on the data (such as descriptice statistics) outside of
>GRASS.
>
>> Just to make sure that I was clear: the problem is how to include
>multiple
>> rows of data that all correspond to just one point in GIS (so "grain
>size"
>> with frequencies in each grain size class or "discharge" with
>discharges
>> at different times).
>
> Database design is a topic of itself. Separate attribute data from the
>spatial data; the former goes into a database (multiple tables), the
>latter
>in GRASS files.
>
>In your initial message you describe three different categories of data
>and each should be in its own table. Information about each data
>collection
>point (which is seen on the map) is in one table. This could include a
>site
>ID as the primary key, site name, perhaps the stream or drainage basin
>in
>which it is located, and other information about the location itself.
>
> Your second table contains hydaulic data: sample ID (the primary key),
>station ID (which relates that row to your point), collection date and
>time,
>discharge, channel width, and any other relevant information.
>
>Your third table contains sediment data: sample ID (primary key),
>station
>ID, date and time, each grain category (e.g., silt, clay, fine sand,
>coarse
>sand, gravel, cobble), and the percentage or proportion (dry weight?)
>of
>each.
>
>You could also have additional tables if you want to store more
>categories
>of data for each point.
>
>Hope this helps,
>
>Rich
>
>
>
>___
>grass-user mailing list
>grass-user@lists.osgeo.org
>http://lists.osgeo.org/mailman/listinfo/grass-user

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] get vector table with unique feature id

[Paulo van Breugel]

I have a shapefile with overlapping polygons. After importing I thus end up
with a vector layer with for each unique polygon (feature) one or more
category values (i.e., one to many relationship).

Now I want to create a second attribute table linked to layer 2 with a cat
column with for each polygon (for each internal feature id) an unique
category.

Next, I want to use this to count the number of categories linked to each
unique feature id.

I know this has been asked and answered before, but the solutions (copied
below) do not work for me.

This worked, I think, in GRASS 6, but it doesn't in G7 because a new vector
map needs to be defined
>* v.category op=add layer=2 type=centroid*
>* v.to.db type=centroid option=cat*

The below does not create an attribute table with unique attributes for
each unique feature.



*> v.in.ogr dsn=test_polygones.shp out=polygons > v.db.addtable polygons
layer=2 > v.category polygons option=add layer=2 type=centroid
out=polygons_tmp > v.to.db polygons_tmp type=centroid option=cat layer=2
col=cat*
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] get vector table with unique feature id

[Paulo van Breugel]

On Fri, Apr 3, 2015 at 3:11 PM, Moritz Lennert  wrote:

> On 03/04/15 14:42, Paulo van Breugel wrote:
>
>> I have a shapefile with overlapping polygons. After importing I thus
>> end up with a vector layer with for each unique polygon (feature) one
>> or more category values (i.e., one to many relationship).
>>
>> Now I want to create a second attribute table linked to layer 2 with
>> a cat column with for each polygon (for each internal feature id) an
>>  unique category.
>>
>> Next, I want to use this to count the number of categories linked to
>>  each unique feature id.
>>
>
> If you have overlapping polygons, after running v.in.ogr your map
> already has layer 2 categories which represent for each feature where
> there is overlap the number of overlapping polygons in that space. IIUC,
> this is what you are looking for, or ?
>

Yes, sorry, I was just about to write that this is indeed the case; you
were just ahead of me. In my initial attempt something went wrong, I should
have checked better, but was focused on getting a column with the unique
values per polygon (which as you write below does not seem to work?).


>
>
>> I know this has been asked and answered before, but the solutions
>> (copied below) do not work for me.
>>
>> This worked, I think, in GRASS 6, but it doesn't in G7 because a new
>>  vector map needs to be defined
>>
>>> /v.category op=add layer=2 type=centroid/ /v.to.db type=centroid
>>> option=cat/
>>>
>>
> And what is the problem with defining a new vector map. This new vector
> map will contain all existing layers plus the new layer. But in this
> case it should be:
>
> v.category map op=add layer=3 type=centroid out=map2
>
> You can then create a table for layer 3 with v.db.addtable:
>
> v.db.addtable map2 layer=3 columns="cat2 integer"
>
> and should be able to load the cat values of layer 2 into the table of
> layer 3 with v.to.db,


I knew (ok, I hoped) this should be simple. Thanks


> but this does not seem to work at the moment:
>
> v.to.db map22 layer=3 query_layer=2 op=cat columns=cat2
>
> (there seems to be confusion between map layers, but I don't have time to
> check. Definitely worth a bug report.)
>

I'll create one

>
>
>  The below does not create an attribute table with unique attributes
>> for each unique feature. /> v.in.ogr dsn=test_polygones.shp
>> out=polygons
>> v.db.addtable polygons layer=2
>>
> > v.category polygons option=add
>
>> layer=2 type=centroid out=polygons_tmp
>>>
>> v.to.db polygons_tmp
>>
>>> type=centroid option=cat layer=2 col=cat/
>>>
>>
> For those features where there is overlap, this will not create new
> categories, but upload to the table the existing category which is the
> number of overlapping features.
>

OK, I was confused here, thanks for the explanation

>
>
>
> Moritz
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] get vector table with unique feature id

[Paulo van Breugel]

On Fri, Apr 3, 2015 at 3:22 PM, Paulo van Breugel 
wrote:

>
>
> On Fri, Apr 3, 2015 at 3:11 PM, Moritz Lennert <
> mlenn...@club.worldonline.be> wrote:
>
>> On 03/04/15 14:42, Paulo van Breugel wrote:
>>
>>> I have a shapefile with overlapping polygons. After importing I thus
>>> end up with a vector layer with for each unique polygon (feature) one
>>> or more category values (i.e., one to many relationship).
>>>
>>> Now I want to create a second attribute table linked to layer 2 with
>>> a cat column with for each polygon (for each internal feature id) an
>>>  unique category.
>>>
>>> Next, I want to use this to count the number of categories linked to
>>>  each unique feature id.
>>>
>>
>> If you have overlapping polygons, after running v.in.ogr your map
>> already has layer 2 categories which represent for each feature where
>> there is overlap the number of overlapping polygons in that space. IIUC,
>> this is what you are looking for, or ?
>>
>
> Yes, sorry, I was just about to write that this is indeed the case; you
> were just ahead of me. In my initial attempt something went wrong, I should
> have checked better, but was focused on getting a column with the unique
> values per polygon (which as you write below does not seem to work?).
>
>
>>
>>
>>> I know this has been asked and answered before, but the solutions
>>> (copied below) do not work for me.
>>>
>>> This worked, I think, in GRASS 6, but it doesn't in G7 because a new
>>>  vector map needs to be defined
>>>
>>>> /v.category op=add layer=2 type=centroid/ /v.to.db type=centroid
>>>> option=cat/
>>>>
>>>
>> And what is the problem with defining a new vector map. This new vector
>> map will contain all existing layers plus the new layer. But in this
>> case it should be:
>>
>> v.category map op=add layer=3 type=centroid out=map2
>>
>> You can then create a table for layer 3 with v.db.addtable:
>>
>> v.db.addtable map2 layer=3 columns="cat2 integer"
>>
>> and should be able to load the cat values of layer 2 into the table of
>> layer 3 with v.to.db,
>
>
> I knew (ok, I hoped) this should be simple. Thanks
>
>
>> but this does not seem to work at the moment:
>>
>> v.to.db map22 layer=3 query_layer=2 op=cat columns=cat2
>>
>> (there seems to be confusion between map layers, but I don't have time to
>> check. Definitely worth a bug report.)
>>
>
> I'll create one
>

Created a ticket: Ticket #2641


>
>>
>>  The below does not create an attribute table with unique attributes
>>> for each unique feature. /> v.in.ogr dsn=test_polygones.shp
>>> out=polygons
>>> v.db.addtable polygons layer=2
>>>
>> > v.category polygons option=add
>>
>>> layer=2 type=centroid out=polygons_tmp
>>>>
>>> v.to.db polygons_tmp
>>>
>>>> type=centroid option=cat layer=2 col=cat/
>>>>
>>>
>> For those features where there is overlap, this will not create new
>> categories, but upload to the table the existing category which is the
>> number of overlapping features.
>>
>
> OK, I was confused here, thanks for the explanation
>
>>
>>
>>
>> Moritz
>>
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] region settings and wx display

[Paulo van Breugel]

On Wed, Apr 15, 2015 at 10:57 PM, Tyler Smith  wrote:

> On Wed, Apr 15, 2015, at 04:40 PM, Moritz Lennert wrote:
> >
> > Not to argue against such a popup, but note that this is not something
> > new since grass7. This behaviour is actually quite old and was already
> > present in the preceding GUI, gis.m.
>
> Did the gis.m and d.mon interface differ in grass6 then? I never used
> gis.m.



I am using GRASS GIS for quite a while, and I can't even remember it
(gis.m) behaving differently (might be my poor memory of course), and I am
also very happy it behaves like it does.


> Perhaps my use case (calling d.mon from grass-mode in emacs) is
> too unusual to warrant making an explicit pop-up/tool-tip.
>

If one would find such a popup useful (I don't), I would suggest to make it
more general, e.g., "zoom out - only affects display, region remains
unaffected", or just "zoom out - only affects display".



>
> Best,
>
> Tyler
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] 3 grass (v7) questions (make uninstall, r.surf.idw, copy button)

[Paulo van Breugel]

On Fri, May 8, 2015 at 5:14 PM, Robert Kuszinger 
wrote:

>  Hello!
>
> I'd like to ask the following.
>
> *fact)*  I've downloaded and compiled trunk (7.1 SVN). It was OK biut I
> don't need it anymore as I use 7.0 (SVN) instead.
> *Q)* How to remove the 7.1 installation? There is no *make uninstall*
> target 
>

Not sure it is the best way, but I would simply delete the grass folder.
E.g., if you compiled it in /usr/local/grass, remove that folder. Depending
on your setup, you may have made some further changes, e.g., making a link
in /usr/bin ((e.g., using sudo ln -s /usr/local/grass7/bin/grass71
/usr/bin/), or adding a config file with the grass lib path to
/etc/ld.so.conf.d. If so, you may want to remove those too.


>
> *fact)* I'd like to have a copy button into the d.rast and d.vect as it
> is on many other dialogs.
> *Q)* Is it complicated to develop it for myself? Where to start? I have
> programming background. Not python, actually, but who cares...
>
> *fact)* r.surf.idw in 7.0.1 and 7.1 makes no interpolation. Output raster
> is the same as input and it uses 10G of memory instead of the 2G used under
> 6.4.4 on the very same raster map..
> *Q) *Is it a known bug, or is there a workaround?
>
> thanks! :)
>
>
>
> --
> --
>
> *Kuszinger Róbert Giscom Kkt.*
> *+36 30 507 0031 <%2B36%2030%20507%200031>*
> *+36 30 22 11 787*
> kuszin...@giscom.hu
> 1078 Budapest, Hernád u. 43
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] [GRASS-dev] BIG QGIS problem

[Paulo van Breugel]

On Sat, Jun 13, 2015 at 9:17 PM, Anna Petrášová 
wrote:

>
>
> On Sat, Jun 13, 2015 at 3:08 PM, Michael Barton 
> wrote:
>
>>  I’ve been using QGIS to do basic data display for research data. It has
>> trashed the attribute tables on the last day.
>>
>>  I’m trying to recover the data with GRASS—where I want to analyze it
>> anyway. But when I try to import a non-trashed file, I exported to a shape
>> file from QGIS, I get an error of ‘inconsistent number of columns’.
>>
>>  Does anyone have any suggestion about how to fix this? I’m pretty
>> desperate right now.
>>
>
> Have you  looked what's in the .dbf file? For example with LibreOffice,
> but you have to specify right encoding (should be ISO8859-1). The message
> just says there is at least one row with different number of columns
> (values).
>

I have had similar problems. Some rows were detected to have different
number of columns, which as I remember well was cause by some strange
characters or carriage return in those rows.



> Best,
>
> Anna
>
>
>>  Michael
>>
>>  C. Michael Barton
>>  Director, Center for Social Dynamics & Complexity
>>  Professor of Anthropology, School of Human Evolution & Social Change
>> Head, Graduate Faculty in Complex Adaptive Systems Science
>>  Arizona State University
>>
>>  voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
>> fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
>>  www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ___
>> grass-dev mailing list
>> grass-...@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>>
>
>
> ___
> grass-dev mailing list
> grass-...@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.to.rast

[Paulo van Breugel]

Excellent example. As this is, as you mentioned, not an example of
v.to.rast, perhapsyou can mention in the first line that this task can not
be done directly with v.to.rast so this is a work-around?

+1 for enhancing v.to.rast to add such functionality

On Fri, Jul 24, 2015 at 4:13 AM, Markus Neteler  wrote:

> On Thu, Jul 23, 2015 at 11:00 AM, patrick s.  wrote:
> > Dear all
> >
> > I am puzzled on the behavior of v.to.rast. When several points fall into
> one
> > gridcell, the raster seems to get one value but not the sum of these. Is
> > there a way to sum these up instead?
>
> Yes. I have added a related example here:
>
>
> http://grass.osgeo.org/grass70/manuals/v.to.rast.html#convert-vector-points-to-raster-with-raster-cell-binning
>
> (while it does not really fit to that manual page it is expected
> there. Perhaps we need to really enhance v.to.rast to do such a job
> right away).
>
> HTH
> Markus
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.bioclim error

[Paulo van Breugel]

First thing to notice is that I think variables (e.g., list with tmin
variables) should be separated by comma only, not by comma + space.

Paulo

On Wed, Aug 5, 2015 at 12:53 PM, Albert Saribekyan <
albertsaribek...@rambler.ru> wrote:

>  I dont understand the sintax of r.bioclim
>
> r.bioclim tmin=tmin1_17@PERMANENT, tmin2_17@PERMANENT, tmin3_17@PERMANENT,
> tmin4_17@PERMANENT, tmin5_17@PERMANENT, tmin6_17@PERMANENT,
> tmin7_17@PERMANENT, tmin8_17@PERMANENT, tmin9_17@PERMANENT,
> tmin10_17@PERMANENT, tmin11_17@PERMANENT, tmin12_17@PERMANENT
> tmax=tmax1_17@PERMANENT, tmax2_17@PERMANENT , tmax3_17@PERMANENT ,
> tmax4_17@PERMANENT , tmax5_17@PERMANENT , tmax6_17@PERMANENT ,
> tmax7_17@PERMANENT , tmax8_17@PERMANENT , tmax9_17@PERMANENT ,
> tmax10_17@PERMANENT , tmax11_17@PERMANENT , tmax12_17@PERMANENT
> output=result
>
> error!!
>
> Unable to parse command 'r.bioclim tmin=tmin1_17@PERMANENT,
> tmin2_17@PERMANENT, tmin3_17@PERMANENT, tmin4_17@PERMANENT,
> tmin5_17@PERMANENT, tmin6_17@PERMANENT, tmin7_17@PERMANENT,
> tmin8_17@PERMANENT, tmin9_17@PERMANENT, tmin10_17@PERMANENT,
> tmin11_17@PERMANENT, tmin12_17@PERMANENT tmax=tmax1_17@PERMANENT,
> tmax2_17@PERMANENT , tmax3_17@PERMANENT , tmax4_17@PERMANENT ,
> tmax5_17@PERMANENT , tmax6_17@PERMANENT , tmax7_17@PERMANENT ,
> tmax8_17@PERMANENT , tmax9_17@PERMANENT , tmax10_17@PERMANENT ,
> tmax11_17@PERMANENT , tmax12_17@PERMANENT output=result'
>
> ask me how to run the module
>
> regards Albert Saribekyan.
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Label vector map

[Paulo van Breugel]

On Wed, Aug 26, 2015 at 2:17 PM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

> On 26/08/15 13:25, henk witte wrote:
>
>> Well, this is embarrassing – I cannot open my own pack!
>>
>> I created a new workspace with a default Cartesian projection but if I
>> try to unpack I get
>>
>> IOError: [Errno 2] No such file or directory: 'C:\\Users\\he
>>
>> nkwitte.GROENHOLLAND\\Documents\\grassdata/test/henkwitte/.t
>>
>> mp/unknown/8544.0\\PROJ_INFO'
>>
>> I have tries also with using the current-location-projection option, but
>> same error.
>>
>
> v.unpack uses a simple check to verify that the data you want to import is
> in the same projection system as the location. It does so by checking the
> PROJ_INFO file that sits in the PERMANENT mapset. But cartesian (i.e. un
> projected) locations do not have such a file, thus the error.
>
> This means that in its current state v.unpack cannot import data into a
> xy-location which I would consider a bug that should be reported in the bug
> tracker.
>

You can use the "override project check" option (-o) I guess, if you know
that both your data and the target location are both in xy-location. I use
that to importat latlon pack.


>
> Moritz
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] addon for a simplified GBIF data import

[Paulo van Breugel]

Great work, thanks!

One suggestion; I wonder if it would be difficult / desirable to use the 
(code from the) v.import add-on, to include an option (perhaps as an 
explicit choice) to import it with on-the-fly reprojection into a 
non-latlon location/mapset? For lazy persons like me who would love to 
be able to skip that step :-)


Cheers,

Paulo





On 28-08-15 15:15, Helmut Kudrnovsky wrote:

hi,

fyi, I've uploaded an addon for a simplified import of downloaded and
unzipped GBIF data:

http://grasswiki.osgeo.org/wiki/AddOns/GRASS7/vector#v.in.gbif



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/addon-for-a-simplified-GBIF-data-import-tp5221654.html
Sent from the Grass - Users mailing list archive at Nabble.com.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


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

Re: [GRASS-user] addon for a simplified GBIF data import

[Paulo van Breugel]

That's quick, great :-)

On 28 August 2015 18:13:41 CEST, Helmut Kudrnovsky  wrote:
>>I wonder if it would be difficult / desirable to use the
>>(code from the) v.import add-on, to include an option (perhaps as an
>>explicit choice) to import it with on-the-fly reprojection into a
>>non-latlon location/mapset? 
>
>on the-fly-reprojecting implemented by a new flag   :-)
>
>https://lists.osgeo.org/pipermail/grass-commit/2015-August/036954.html
>
>patches for reprojecting error handling, unsupported combination of
>option
>and projected locations, test if v.import exists are very welcome! :-)
>
>
>
>
>
>
>
>-
>best regards
>Helmut
>--
>View this message in context:
>http://osgeo-org.1560.x6.nabble.com/addon-for-a-simplified-GBIF-data-import-tp5221654p5221686.html
>Sent from the Grass - Users mailing list archive at Nabble.com.
>___
>grass-user mailing list
>grass-user@lists.osgeo.org
>http://lists.osgeo.org/mailman/listinfo/grass-user

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] trimming color table

[Paulo van Breugel]

When creating a new map based on an existing using r.mapcalc, the color 
table of the old map is used for the new map. However, if the new map 
only contains a subset of the values of the old map, how can I trim the 
color table so it only contains color definitions for the values present 
in the new map? Any easy (automatic) way to do this? Note, this is 
probably only useful for integer (category) maps.


Rgds.

Paulo


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

Re: [GRASS-user] trimming color table

[Paulo van Breugel]

On 18-09-15 10:06, Glynn Clements wrote:

Paulo van Breugel wrote:


When creating a new map based on an existing using r.mapcalc, the color
table of the old map is used for the new map. However, if the new map
only contains a subset of the values of the old map, how can I trim the
color table so it only contains color definitions for the values present
in the new map? Any easy (automatic) way to do this? Note, this is
probably only useful for integer (category) maps.

There isn't an automatic way to do this. The simplest way is probably
along the lines of

r.colors.out map | command | r.colors map rules=-

where "command" is a grep/sed/etc command which filters the rules.
Thanks. I wrote a small Python script which basically does that, so I 
can run something like 'trim(map)' with map being an integer / 
categorical map.




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

Re: [GRASS-user] new addon: v.in.redlist

[Paulo van Breugel]

Great, thanks that will come in handy.

On 23 September 2015 21:28:56 CEST, Helmut Kudrnovsky  wrote:
>hi,
>
>just fyi I've uploaded a new addon for an easier import of user defined
>species in the IUCN Red List Spatial Data:
>
>v.in.redlist:
>https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.in.redlist
>
>should be available by g.extension from now on.
>
>
>
>-
>best regards
>Helmut
>--
>View this message in context:
>http://osgeo-org.1560.x6.nabble.com/new-addon-v-in-redlist-tp5225761.html
>Sent from the Grass - Users mailing list archive at Nabble.com.
>___
>grass-user mailing list
>grass-user@lists.osgeo.org
>http://lists.osgeo.org/mailman/listinfo/grass-user

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] map algebra logical operators on DCELL rasters not admitted? maybe docs should outline it

[Paulo van Breugel]

On Mon, Oct 19, 2015 at 5:18 PM, G. Allegri  wrote:

> Doing a logical operation with a DCELL raster within an if(x,a) statement
> produces an error: "Incorrect argument types to function bitand()".
> This doesn't seem to be described inside the docs, is it?
>

That sounds like a bug to me. I just tried it out and it runs fine (using
GRASS 7.1). What GRASS version are you using?


>
> When the if() function is described it only states its behaviour in case
> of NULL, 0 or "otherwise" values.
> It works correctly if the maps are CELL (i.e. e value not eqaul 0 is
> treated correctly whatever it is) and it's quite confusing for users having
> a different behaviour, and sepcifically an error, in case of floating point
> rasters, don't you think?
>
> Regards,
> giovanni
>
> --
> Giovanni Allegri
> http://about.me/giovanniallegri
> Gis3W - http://gis3w.it
> Ikare - http://ikare.it
> Twitter: https://twitter.com/_giohappy_
> blog: http://blog.spaziogis.it
> GEO+ geomatica in Italia http://bit.ly/GEOplus
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] GRASS GIS on gis.stackexchange.com

[Paulo van Breugel]

Good initiative Markus. I added my vote and added a post on the Google+ 
GRASS GIS News community page for some extra exposure. The number of 
GRASS specific questions are now still relatively few, perhaps because 
of the very active and responsive GRASS email lists?


On 07-11-15 11:45, Markus Neteler wrote:

be shown on the main site:
http://meta.gis.stackexchange.com/a/4066/687


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

Re: [GRASS-user] How to categorize my areas

[Paulo van Breugel]

On Tue, Dec 15, 2015 at 9:15 AM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

> On 15/12/15 00:22, Martin Landa wrote:
>
>> Hi,
>>
>> 2015-12-15 0:18 GMT+01:00 Alec Ventura :
>>
>>> I run the v.buffer with the -t flag and everything is ok now
>>>
>>
>> I wonder if attributes should be copied by default (without need to
>> set up any flag).
>>
>
> v.buffer fusions the geometries of buffers by default. Keeping the
> attribute table does not make sens in that case as one buffer geometry can
> be the result of many different input geometries. This also means that you
> cannot retrieve the buffer of a specific input geometry.
>

> When you use the -t flag, buffers are cut up into separate parts and each
> one that is the result of several overlapping buffers has multiple
> categories. As the man page says: "The resulting buffer areas can have
> multiple categories, and multiple buffer areas can have the same category.
> The buffer for the input feature with category X can thus be retrieved by
> selecting all buffer areas with category X".
>



The above is actually a nice and more explicit explanation of what v.buffer
does, especially for (new) users that get confused by the consequences of
GRASS' topological vector format and handling. Why not add this to the
manual page, perhaps something along the line of:

"v.buffer fusions the geometries of buffers by default. Categories and
attribute table will not be transferred (this would not make sense as one
buffer geometry can be the result of many different input geometries). To
transfer the categories and attributes can be done with the *t* flag. This
will result in buffers being cut up where buffers of individual input
geometries overlap. Each part that is the result of overlapping buffers of
multiple geometries will have multiple categories corresponding to those
geometries. Multiple buffer areas can also have the same category. The
buffer for the input feature with category X can thus be retrieved by
selecting all buffer areas with category X (see example below). "

(this would replace: "Categories and attributes can be transferred with the
*t* flag. The resulting buffer areas can have multiple categories, and
multiple buffer areas can have the same category. The buffer for the input
feature with category X can thus be retrieved by selecting all buffer areas
with category X (see example below).")




>
> Keeping in mind GRASS' topological vector format the current behavior
> seems the most adequate to me.
>
> Moritz
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Uniform random raster

[Paulo van Breugel]

On 16-02-16 05:04, Thomas Adams wrote:

Giuseppe,

Unless I have misunderstood, in GRASS use r.mapcalc...

First set you region for your area of interest, for example:

g.region -dp e=2614612.5 w=1423987.5 n=-4624387.5 s=-5862637.5

Then:
r.mapcalc expression="outputMap=25.4"

where 25.4 is your value of interest, and finally:

r.out.gdal input=outputMap output=outputFileName format=GTiff

Best,
Tom

On Mon, Feb 15, 2016 at 9:33 PM, Giuseppe Amatulli 
mailto:giuseppe.amatu...@gmail.com>> wrote:


Hi,
I would like to create an uniform random raster, similar to what i
would obtain in R with the following code

raster=raster(matrix(runif(54210, max=50, min=-50, 139,390) ,
...)
writeRaster(raster,filename=random.tif",formats=GTiff,overwrite=TRUE)

I read the explanation of
https://grass.osgeo.org/grass7/manuals/r.random.surface.html
and also r.mapcalc - random (a,b)
but I'm not sure if one of them produce the same concept/result.



That function creates random surface(s) with spatial dependence (there 
is a small typo in the link, it should be grass70). What you want, I 
think, is the r.surf.random function 
(https://grass.osgeo.org/grass70/manuals/r.surf.random.html). The 
r.mapcalc - random(a,b) should also do what you want, it also gives a 
uniform distribution.


p.s. some of the brackets in your R code above are off, it should 
probably be something like raster=raster(matrix(runif(54210, max=50, 
min=-50), 139,390) , ...). Like Thomas wrote, in GRASS you first 
need to define your region and set your resolution (check out g.region 
for all settings, including the option to set number of rows and 
columns). Than you can run r.surf.random or r.mapcalc to generate your 
new random surface layer.




Any input? or better explanation

Thanks
Best
Giuseppe

-- 
Giuseppe Amatulli, Ph.D.


Department of Ecology and Evolutionary Biology, Yale University.
Jetz Lab, OML Room 405
P.O. Box 208106
165 PROSPECT ST
New Haven, CT 06520-8106
Teaching: spatial-ecology.net 
Work: http://sbsc.yale.edu/giuseppe-amatulli

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




--
Thomas E Adams, III
2330 Jack Warner PKWY, #334
Tuscaloosa, AL 35401

1 (513) 739-9512 (cell)



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


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

Re: [GRASS-user] dataset

[Paulo van Breugel]

On 22-03-16 13:57, Markus Neteler wrote:

On Tue, Mar 22, 2016 at 1:38 PM, Albert  Saribekyan
 wrote:

  Ask me please, where can I get data to run r.bioclim module?

For Europe, there is for example this dataset:
http://www.ecad.eu/download/ensembles/download.php#datafiles

For other continents, there might be similar ones (e.g. USA: PRISM)
Or you can use the global worldclim data set (http://worldclim.org), 
mentioned on the manual page or r.bioclim




Best
Markus



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

Re: [GRASS-user] First public release of Elevation, SRTM 30m global DEM easy management

[Paulo van Breugel]

Hi Alessandro,

Looks good. Following up on a suggestion on the QGIS mailing list for a
plugin based on this, it might also be useful to create an GRASS addon
using the Python API? An perhaps not that difficult either? Anybody :-) ?

Cheers,

Paulo




On Wed, Mar 30, 2016 at 3:44 PM, Alessandro Amici  wrote:

> Repost from python-announce-list as I think it is of interest to grass
> users.
>
> I am pleased to announce the first public beta release of Elevation, a
> tool for easy access to global terrain digital elevation models, SRTM 30m
> DEM and SRTM 90m DEM:
>
> http://elevation.bopen.eu/en/stable/quickstart.html
>
> Development effort is directed to fixing bugs and writing better
> documentation before the 1.0 release. Testing and contributions are highly
> welcomed and appreciated. Every little help counts, so do not hesitate!
>
> https://github.com/bopen/elevation
>
> User questions are best directed to
> https://stackoverflow.com/search?q=python+elevation
>
> The project is free and open source software distributed under the terms
> of the Apache License, Version 2.0. and the development has been sponsored
> by my employer B-Open Solutions http://bopen.eu
>
> Thanks,
> Alessandro
> --
> Alessandro Amici 
> CTO at B-Open Solutions - http://www.bopen.eu/
> Viale Palmiro Togliatti, 1639 - 00155 Roma - tel: +39 06 8370 8269
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] problem with python scripting

[Paulo van Breugel]

On 05-04-16 08:53, Leonardo Hardtke wrote:

Dear users,
I am writing a script and I'm having problems with the flags for mapcalc
gscript.mapcalc('endmember_rstr.1 = null()', flags="o")


If  you are using GRASS 7.+, the overwrite flag should be written in 
full, i.e.,


gscript.mapcalc('endmember_rstr.1 = null()', flags="overwrite")




ERROR: output map  exists. To overwrite, use the
   --overwrite flag
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/grass70/etc/python/grass/script/raster.py", line 103, 
in mapcalc

quiet=quiet, verbose=verbose, overwrite=overwrite)
  File "/usr/lib/grass70/etc/python/grass/script/core.py", line 516, 
in write_command

return handle_errors(returncode, returncode, args, kwargs)
  File "/usr/lib/grass70/etc/python/grass/script/core.py", line 312, 
in handle_errors

returncode=returncode)
  File "/usr/lib/grass70/etc/python/grass/exceptions/__init__.py", 
line 68, in __init__

msg = _("Module run %s %s ended with error") % (module, code)
TypeError: 'str' object is not callable

with other modules flags are working as I expect, like

gscript.run_command("g.region", flags="p")
projection: 1 (UTM)
zone:   -20
datum:  wgs84
ellipsoid:  wgs84
north:  5326556.02809
south:  5228355.32592
west: 290546.512535
east: 444008.446334
nsres:  30.00326984
ewres:  30.0081998
rows:   3273
cols:   5114
cells:  16738122

Am I missing something?

Thanks!
--
Dr. Leonardo A. Hardtke
Laboratorio de Teledetección y S.I.G.
Centro Nacional Patagónico (CONICET)
Bvd. Brown 2825, 9120
Puerto Madryn, Chubut, Argentina


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


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

Re: [GRASS-user] problem with python scripting

[Paulo van Breugel]

Ah, yes, sorry for my wrong answer.. too much in R mode (where one would
write it as I mentioned).

It is mentioned here:
https://grasswiki.osgeo.org/wiki/GRASS_Python_Scripting_Library , but not
in a very explicit way I have to say.



On Tue, Apr 5, 2016 at 9:11 AM, Leonardo Hardtke 
wrote:

> Thanks Paulo and Sören for helping!
> overwrite=True made the trick! Is this documented somewhere and I just
> missed it??? Or should I fill a ticket?
>
> Leo
>
>
>
> 2016-04-05 17:06 GMT+10:00 Sören Gebbert :
>
>> Please try gscript.mapcalc(expr... , overwrite=True)
>> Am 05.04.2016 09:02 schrieb "Leonardo Hardtke" :
>>
>>> Hi Paulo and thanks for the answer... but It gives me a very similar
>>> error if I write the full flag (The only difference is TypeError... str
>>> if I use 'o' and int if I use 'overwrite' )
>>>
>>>  gscript.mapcalc('endmember_rstr.1 = null()', flags="overwrite")
>>>
>>> ERROR: output map  exists. To overwrite, use the
>>>--overwrite flag
>>> Traceback (most recent call last):
>>>   File "", line 1, in 
>>>   File "/usr/lib/grass70/etc/python/grass/script/raster.py", line 103,
>>> in mapcalc
>>> quiet=quiet, verbose=verbose, overwrite=overwrite)
>>>   File "/usr/lib/grass70/etc/python/grass/script/core.py", line 516, in
>>> write_command
>>> return handle_errors(returncode, returncode, args, kwargs)
>>>   File "/usr/lib/grass70/etc/python/grass/script/core.py", line 312, in
>>> handle_errors
>>>     returncode=returncode)
>>>   File "/usr/lib/grass70/etc/python/grass/exceptions/__init__.py", line
>>> 68, in __init__
>>> msg = _("Module run %s %s ended with error") % (module, code)
>>> TypeError: 'int' object is not callable
>>>
>>> Thanks for your help!
>>>
>>> 2016-04-05 16:56 GMT+10:00 Paulo van Breugel :
>>>
>>>>
>>>>
>>>> On 05-04-16 08:53, Leonardo Hardtke wrote:
>>>>
>>>> Dear users,
>>>> I am writing a script and I'm having problems with the flags for mapcalc
>>>> gscript.mapcalc('endmember_rstr.1 = null()', flags="o")
>>>>
>>>>
>>>> If  you are using GRASS 7.+, the overwrite flag should be written in
>>>> full, i.e.,
>>>>
>>>> gscript.mapcalc('endmember_rstr.1 = null()', flags="overwrite")
>>>>
>>>>
>>>>
>>>> ERROR: output map  exists. To overwrite, use the
>>>>--overwrite flag
>>>> Traceback (most recent call last):
>>>>   File "", line 1, in 
>>>>   File "/usr/lib/grass70/etc/python/grass/script/raster.py", line 103,
>>>> in mapcalc
>>>> quiet=quiet, verbose=verbose, overwrite=overwrite)
>>>>   File "/usr/lib/grass70/etc/python/grass/script/core.py", line 516, in
>>>> write_command
>>>> return handle_errors(returncode, returncode, args, kwargs)
>>>>   File "/usr/lib/grass70/etc/python/grass/script/core.py", line 312, in
>>>> handle_errors
>>>> returncode=returncode)
>>>>   File "/usr/lib/grass70/etc/python/grass/exceptions/__init__.py", line
>>>> 68, in __init__
>>>> msg = _("Module run %s %s ended with error") % (module, code)
>>>> TypeError: 'str' object is not callable
>>>>
>>>> with other modules flags are working as I expect, like
>>>>
>>>> gscript.run_command("g.region", flags="p")
>>>> projection: 1 (UTM)
>>>> zone:   -20
>>>> datum:  wgs84
>>>> ellipsoid:  wgs84
>>>> north:  5326556.02809
>>>> south:  5228355.32592
>>>> west:   290546.512535
>>>> east:   444008.446334
>>>> nsres:  30.00326984
>>>> ewres:  30.0081998
>>>> rows:   3273
>>>> cols:   5114
>>>> cells:  16738122
>>>>
>>>> Am I missing something?
>>>>
>>>> Thanks!
>>>> --
>>>> Dr. Leonardo A. Hardtke
>>>> Laboratorio de Teledetección y S.I.G.
>>>> Centro Nacional Patagónico (CONICET)
>>>> Bvd. Brown 2825, 9120
>>>> Puerto Madryn, Chubut, Argentina
>>>>
>>>>
>>>> ___
>>>> grass-user mailing 
>>>> listgrass-user@lists.osgeo.orghttp://lists.osgeo.org/mailman/listinfo/grass-user
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Dr. Leonardo A. Hardtke
>>> Laboratorio de Teledetección y S.I.G.
>>> Centro Nacional Patagónico (CONICET)
>>> Bvd. Brown 2825, 9120
>>> Puerto Madryn, Chubut, Argentina
>>>
>>> ___
>>> grass-user mailing list
>>> grass-user@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/grass-user
>>>
>>
>
>
> --
> Dr. Leonardo A. Hardtke
> Laboratorio de Teledetección y S.I.G.
> Centro Nacional Patagónico (CONICET)
> Bvd. Brown 2825, 9120
> Puerto Madryn, Chubut, Argentina
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] seeking advice for additional scripts

[Paulo van Breugel]

On Tue, Apr 5, 2016 at 9:06 PM, Martin Landa  wrote:

> Hi,
>
> 2016-04-05 20:59 GMT+02:00 Ken Mankoff :
> > Where should this script go, and do you have advice on what language to
> use? My first thought was to make it a bash shell script and put it in
> ~/bin/ or ~/bin/grass/ and add that to GRASS_ADDON_PATH. Is there standard
> location for things like this?
>
> I would choose ~/bin/grass (~/bin is not good choice because than your
> scripts will be in default PATH, so visible also outside of GRASS).
>

If you are on Linux, I think you can copy your script to the same folder
that is used by g.extension to install addon scripts. For me that is
~/.grass7/addons/scripts , but I assume that is the same on most Linux
systems.


>
> > And should it be in Python or bash? Seems like either works right now,
> but will bash be phased out in the future?
>

>From what I understand, there are no plans to phase out bash, so you could
use that if that works best for you. For sharing with others python is
probably the better choice, especially because of compatibility issues on
Windows.


> For simple/quick stuff I would use Bash. For the rest (more complex
> stuff, anything you want to publish as addons) I would choose Python.
> Please note that GRASS 7 supports only Python for Addons.
>

That depends how you define addons. You cannot install shell scripts with
g.extension, but if you put them in ~/.grass7/addons/scripts they should
work fine. Having said that, Python would still be the better option.



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

Re: [GRASS-user] LST

[Paulo van Breugel]

Not sure, but it looks like the comma's separating the layer names are
followed by a space?



On Fri, Apr 8, 2016 at 1:06 PM, Albert Saribekyan <
albertsaribek...@rambler.ru> wrote:

> Hi dear all!!
>
> I want to run *r.bioclim* modul, for this I have get the data from
> http://www.ecad.eu/download/ensembles/download.php#datafiles
> 
>  site,
> inported them to my GRASS by r.in.gdal and run r.bioclim such as in
> attached file (screenshot).
>
> help me please to solve this probelem.
>
> reagards,
>
> Albert Saribekyan.
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] data catalog question

[Paulo van Breugel]

On 10-04-16 10:03, Martin Landa wrote:

Hi Anna,

2016-04-10 5:00 GMT+02:00 Anna Petrášová :

I was wondering what is the opinion about the new data catalog (in
trunk), specifically, whether users should be able to modify (copy,
rename, delete) maps from other mapsets and locations than the current
ones. I find it very useful to edit any mapsets, but it goes against
the traditional GRASS approach. I have this (edit anything behavior)
implemented locally, but wanted to know before committing if people
agree with that.
Could be a great new feature and I would be happy to test. I assume 
though that this functionality is strictly limited to the data catalog? 
I.e., in the layer view the traditional approach should be kept i.m.h.o.



I would suggest to keep traditional approach at least by default. What
about new option in preferences?

+1

In the same way I was thinking about
GUI option "Set up computational region automatically from input
data". Martin
Could be useful as well, but I certainly hope that would remain 
optional, as working with a region that is independent of the input 
layers is one of the really great strength of GRASS.




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

Re: [GRASS-user] fine to coarse resolution

[Paulo van Breugel]

You can use r.resamp.stats with aggregation method the sum

Paulo


On 15-04-16 09:02, Micha Silver wrote:

Hello all,
I have rasters in a fine resolution, with values of 1 and null. I need 
to create, in a coarser resolution, new rasters where each cell gets 
the total number of non-null pixels from the fine resolution raster 
that are within the coarse pixel.


The clunky method I worked out uses r.out.xyz and r.in.xyz. Starting 
in the fine resolution, I export all (non-null) cell locations with 
r.out.xyz. Then I switch to the coarse resolution and do r.in.xyz with 
method=n. Seems to work, but is there anything better, more elegant?


Thanks,
Micha

--
Micha Silver
Arava Drainage Authority
+972-523-665918


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


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

Re: [GRASS-user] Copy an existing location

[Paulo van Breugel]

There is also the r.pack function. But what I would probably do is to copy
the whole location folder, delete the layers you don't want to include, and
then zip / 7zip the whole folder (which is lossless) or any other suitable
format.


On Thu, Apr 28, 2016 at 9:44 AM, Bartolomei.Chris <
bartolomei.ch...@ensco.com> wrote:

> Hi Janet ... I was just thinking about the suggestion I sent ... you may
> be better off exporting the rasters and then having the user import them
> into a like-named mapset with the projection set to what the original
> rasters are in (and set the region and resolution correctly prior to
> import). The reason I say this is the file compression I suggested may
> cause some data loss ... look into lossless data compression algorithms and
> you'll see what I'm talking about.
> It may be irrelevent, but I'm not 100% sure... something to be aware of
> though.
>
> Chris Bartolomei P.E.
> Engineer/Scientist
> ENSCO, Inc.
> bartolomei.ch...@ensco.com
> 
> From: grass-user [grass-user-boun...@lists.osgeo.org] On Behalf Of Janet
> Choate [jsc@gmail.com]
> Sent: Wednesday, April 27, 2016 7:00 PM
> To: grass list
> Subject: [GRASS-user] Copy an existing location
>
> Hello GRASS community,
> Does anyone have advice on duplicating an existing GRASS location with
> only certain rasters maps?
> For example, I have an existing GRASS location with a PERMANENT mapset
> that contains 100 maps. I want to create a copy of this existing location
> (with it's current projection) to a new location, which will only contain
> 10 of the rater maps from the existing location.
> I want to be able to transfer a new 'cleaned-up' version of my GRASS
> location to another user.
> thank you,
> Janet
>
>
>
> The information contained in this email message is intended only for the
> use of the individual(s) to whom it is addressed and may contain
> information that is privileged and sensitive. If you are not the intended
> recipient, or otherwise have received this communication in error, please
> notify the sender immediately by email at the above referenced address and
> note that any further dissemination, distribution or copying of this
> communication is strictly prohibited.
>
> The U.S. Export Control Laws regulate the export and re-export of
> technology originating in the United States. This includes the electronic
> transmission of information and software to foreign countries and to
> certain foreign nationals. Recipient agrees to abide by these laws and
> their regulations -- including the U.S. Department of Commerce Export
> Administration Regulations and the U.S. Department of State International
> Traffic in Arms Regulations -- and not to transfer, by electronic
> transmission or otherwise, any content derived from this email to either a
> foreign national or a foreign destination in violation of such laws.
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] python grass script error

[Paulo van Breugel]

Shouldn't there be spaces around the first equal sign:

"{tmp_NDVI} = float 


On Fri, Jul 1, 2016 at 7:36 AM Vinay Elothunkal 
wrote:

> Hai Maxi,
>
> Sorry, I missed { when I write the mail, but while running I have used it
> correctly, still same error!
>
> regards,
> Vinay
>
> On Fri, Jul 1, 2016 at 1:51 PM, Massimiliano Cannata <
> massimiliano.cann...@supsi.ch> wrote:
>
>> Looks like you missed one { before of Red. Don't know...maybe isn't it
>> bur give a try.
>>
>> Maxi
>> Il 01/Lug/2016 06:15, "Vinay Elothunkal"  ha
>> scritto:
>>
>>> Hi all,
>>>
>>> Can anyone please help me to solve the error with '@' mark which comes
>>> along with mapset in python GRASS script.   I get the following error when
>>> I run "mapcal.py"
>>>
>>> *syntax error, unexpected '@', expecting '('*
>>>
>>> # mapcal.py
>>> import grass.script as g
>>> lis=['a@mapset','b@mapset']
>>> for i in lis:
>>>
>>>  
>>> g.mapcalc("{tmp_NDVI}=float({NIR}-Red})/float({NIR}+{Red})".format(tmp_NDVI='NDVI'+str(i),
>>> NIR='B5@mapset',Red='B4@mapset'),overwrite=True)
>>>
>>>
>>> Thanks,
>>>
>>> ___
>>> grass-user mailing list
>>> grass-user@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/grass-user
>>>
>>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Interpreting r.watershed accumulation map

[Paulo van Breugel]

On 23-10-16 19:18, Markus Neteler wrote:

On Sat, Oct 22, 2016 at 11:22 PM, Rich Shepard  wrote:

On Sat, 22 Oct 2016, Markus Neteler wrote:


Is is mentioned
https://trac.osgeo.org/grass/wiki/Release/7.2.0-News#GUIchanges
- cartography in Map Display:
   - new color tables which are perceptually uniform: viridis and grass
   - viridis color table is the new default replacing rainbow (manage
with G7:r.colors)


Markus,

   I should have checked before writing. My apologies to all.

Rich,

no problem and nothing to apologize for.

This information was kind of hidden (yesterday I made it bold), yet I
wonder how to better communicate such changes.
If you have suggestions (or anyone else), please let us know!
What about adding this as a note under 'Notes' in the manual page of 
r.colors. This is not strictly an output of r.colors, but people might 
look there first when noticing that the colours of their map differs 
from what they expect. Perhaps something like: "The default colour table 
is the viridis colour table. Note that this was changed in GRASS GIS 
version 7.2. In earlier versions the default colour table was 'rainbow'."




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


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

Re: [GRASS-user] Interpreting r.watershed accumulation map

[Paulo van Breugel]

On 23-10-16 19:47, Paulo van Breugel wrote:



On 23-10-16 19:18, Markus Neteler wrote:
On Sat, Oct 22, 2016 at 11:22 PM, Rich Shepard 
 wrote:

On Sat, 22 Oct 2016, Markus Neteler wrote:


Is is mentioned
https://trac.osgeo.org/grass/wiki/Release/7.2.0-News#GUIchanges
- cartography in Map Display:
   - new color tables which are perceptually uniform: viridis and 
grass

   - viridis color table is the new default replacing rainbow (manage
with G7:r.colors)
Just running i.pca and noticed that the output layers are not (all) 
colored using the viridis color table. In the example on the help page, 
the colors of the layers are grey scale. Does the i.pca module apply a 
color scheme explicitly, or how does this work?


Markus,

   I should have checked before writing. My apologies to all.

Rich,

no problem and nothing to apologize for.

This information was kind of hidden (yesterday I made it bold), yet I
wonder how to better communicate such changes.
If you have suggestions (or anyone else), please let us know!
What about adding this as a note under 'Notes' in the manual page of 
r.colors. This is not strictly an output of r.colors, but people might 
look there first when noticing that the colours of their map differs 
from what they expect. Perhaps something like: "The default colour 
table is the viridis colour table. Note that this was changed in GRASS 
GIS version 7.2. In earlier versions the default colour table was 
'rainbow'."




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




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

Re: [GRASS-user] Land cover change and forecasting

[Paulo van Breugel]

On 07-12-16 15:45, Anna Petrášová wrote:

On Wed, Dec 7, 2016 at 9:40 AM, Moritz Lennert
 wrote:

On 07/12/16 15:21, Micha Silver wrote:

I am looking for a FOSS GIS alternative to the IDRISI "Land Change
Modeler". The LCM both analyses change between two input land cover
classification maps, and forecasts land cover for a chosen future time
with various simulation models.
The GRASS addon r.change.info seems to have many options for
investigating land cover change between some input categorical rasters,
but I can't find any module or addon for predicting land cover at a
future time.

Are there some modules or addons that I have missed? Any other FOSS
image analysis software I should be looking at?


Have you had a look at the r.futures suite:

https://grass.osgeo.org/grass70/manuals/addons/r.futures.html

Yes, this one projects urban growth, so 2 classes. Then, there is an R package:
https://cran.r-project.org/web/packages/lulcc/lulcc.pdf

Anna


Also have a look at the r.randomforest addon for GRASS GIS



?

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

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


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

Re: [GRASS-user] CHELSA climate data set

[Paulo van Breugel]

On 10-02-17 17:15, Markus Metz wrote:



On Tue, Feb 7, 2017 at 3:43 PM, Markus Neteler > wrote:

>
> On Tue, Feb 7, 2017 at 3:32 PM, Markus Metz
> > wrote:

> [...]
> > Unfortunately it changes East from 179.9998611 to 179.9998597 and 
north

> > from 83.9998611 to 83.9998604.
> >
> > The more serious problem is that GRASS can not handle ll 
coordinates like

> > 180:0:0.50W or 90:0:0.5S.
> >
> > I have relaxed the ll restrictions in my local copy and can now import
> > CHELSA and other for GRASS problematic ll datasets without getting 
e.g. a
> > narrow N-S strip, or GRASS fixing a subtle rounding error that in 
fact is

> > not an error. That means after each import I have to manually check if
> > resolution and extents make sense, and if in doubt fix them with 
r.region.

>
> That's probably rather more a power user task than common user
> knowledge...

Why a power user task? r.region is an easy to use module, as long as 
you know the correct grid geometry. And with my relaxed ll 
restrictions I get less errors and more usable results, in fact I need 
to use r.region less often than before.


Not sure that is what Markus meant, but "relaxed the restriction in my 
local copy" sounds definitely like a power user task to me. If this is 
something that can, and will, be done at the libgis level, great. 
Otherwise, I would be interested to know how to do this.




> Is there anything we could do at libgis level like
> relaxing the ll restrictions along with appropriate user messages?

Yes. The first points would be ll_scan.c, ll_format.c and 
adj_cellhd.c. That should also remove cryptic errors like "ERROR: 
Syntax error in cell header".


> More and more global datasets are getting published, so the issue will
> likely come up more frequently. Just to make it a bit easier :-)

For a start, it would be nice if you can create a full SRTM mosaik 
(not so new data) in GRASS.


Markus M

>
> markusN



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


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

Re: [GRASS-user] Question to the input seed grid of i.segment

[Paulo van Breugel]

On 10-02-17 18:41, Moritz Lennert wrote:

Hi Raphael,

On 10/02/17 12:08, Raphael Knevels wrote:

Hello Moritz,

thank you for your help, and sorry for my late response to this
topic.

The slic algorithm works really great :-) for my image (... which is
a slope) it needs around 27 minutes (11 000 superpixels and 0.6
compactness) - compared to SAGA GIS 45 min and GRASS GIS 700 min. To
use SLIC as Seed in i.segment it reduced the processing time to ~ 250
min.


Both are good to hear. Thanks for the feedback !




Is there any prospect to add the SLIC algorithm to i.segment as an
option for "Segmentation method"?-  It would be very cool to do
multiscale/hierarchical segmentation with this algorithm.


The choice was to make this into a separate module, amongst others to 
follow the general principle in GRASS that each module should do one 
thing and only that (I know that with this logic, we probably should 
have created i.segment.regiongrowing and i.segment.meanshift, but 
there was sufficiently common code between the two to put them into 
one module). We felt that the superpixel approach was different enough 
from the other segmentation methods to warrant a separate modue.


When you speak of multiscale/hierarchical segmentation, what exactly 
are you missing in i.superpixels.slic ? Some sort of "seeds" map as in 
i.segment ?




For curiosity, I also tried out your suggestion to use the Saga Seeds
output modified by r.mapcalc "int_map = int(map)". However, during
i.segment I received following Error-message: " ERROR: Invalid region
id -3573".


That's weird. Does SAGA create negative segment ids ? Which outcome 
did you use from the SAGA seed module ? For me it worked.




Meanwhile, I also tested the i.segment.uspo add-on. It works fine -
just the green progress bar does not.


No, I never implemented a progress measure in the module. A ToDo...


Besides, manually, I calculated
Moran's I and Intrasegment Variance by i.segment with 8 instead of 4
neighbors (default). Even if the object looks kind of " pixelated" at
the border, I received smaller Moran's I and Intrasegment Variance
values with i.segment 8 NB in comparison to 4 NB (same settings for
minsize and threshold). Maybe the "-d" flag of i.segment could also
be added to i.segment.uspo...


That shouldn't be too difficult. Internally, i.segment.uspo uses the 
addon r.neighborhoodmatrix which has a '-d' flag. I just really do not 
have the time to implement this right now. You could try yourself by 
opening the i.segment.uspo (or on Windows i.segment.uspo.py) file and 
adding "flags='d'" to the call to r.neighborhoodmatrix (lines 535 and 
following):


res = gscript.read_command('r.neighborhoodmatrix',
   input_=mapname,
   output='-',
   sep='comma',
   flags='d',
   quiet=True)


This will always apply the flag. When I have time I can add this as a 
flag to i.segment.uspo.


A slightly larger project I have is to actually extract the code for 
the calculation of the spatial autocorrelation and create a 
"r.spatialautocorrelation" module. But not now... ;-)


+1 (or make that a double plus) that would be really great!



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


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

Re: [GRASS-user] Question to the input seed grid of i.segment

[Paulo van Breugel]

On 28-02-17 14:35, Moritz Lennert wrote:

Le Fri, 10 Feb 2017 19:15:25 +0100,
Paulo van Breugel  a écrit :


On 10-02-17 18:41, Moritz Lennert wrote:
  [...]
  [...]
  [...]
  [...]
  [...]
  [...]
  [...]
  [...]
  [...]

Besides, manually, I calculated
Moran's I and Intrasegment Variance by i.segment with 8 instead of
4 neighbors (default). Even if the object looks kind of "
pixelated" at the border, I received smaller Moran's I and
Intrasegment Variance values with i.segment 8 NB in comparison to
4 NB (same settings for minsize and threshold). Maybe the "-d"
flag of i.segment could also be added to i.segment.uspo...

That shouldn't be too difficult. Internally, i.segment.uspo uses
the addon r.neighborhoodmatrix which has a '-d' flag. I just really
do not have the time to implement this right now. You could try
yourself by opening the i.segment.uspo (or on Windows
i.segment.uspo.py) file and adding "flags='d'" to the call to
r.neighborhoodmatrix (lines 535 and following):

 res = gscript.read_command('r.neighborhoodmatrix',
input_=mapname,
output='-',
sep='comma',
flags='d',
quiet=True)


This will always apply the flag. When I have time I can add this as
a flag to i.segment.uspo.

A slightly larger project I have is to actually extract the code
for the calculation of the spatial autocorrelation and create a
"r.spatialautocorrelation" module. But not now... ;-)

+1 (or make that a double plus) that would be really great!


r70696: r.object.spatialautocor: new addon to calculate global spatial
autocorrelation for raster objects

Brilliant, will try it out a.sa.p.


Moritz


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

Re: [GRASS-user] log function for SQLite

[Paulo van Breugel]

On 12-03-17 11:50, Markus Neteler wrote:

On Wed, Mar 8, 2017 at 11:26 AM, Nikos Alexandris
 wrote:

NikosAlexandris wrote:


Dear list,

where is the extension for SQLite that contains the (mathematical) log
function available to download?  As referenced in
https://grass.osgeo.org/grass73/manuals/v.db.update.html.


Helmut Kudrnovsky:


I think the reference in the manual requires a source or a link to it.


just found something in the wiki:

https://grasswiki.osgeo.org/wiki/Build_SQLite_extension_on_windows


For Linux:

Now also here:

https://grasswiki.osgeo.org/wiki/Build_SQLite_extension_on_Linux


Very useful



1) there is still a "compile" warning for the code (no time to hunt)

This version contains three changes compared to the original version,
maybe useful?
https://raw.githubusercontent.com/seth/RSQLite.extfuns/master/src/extension-functions.c


2) The log() function does not like, naturally, 0 values. But this can
be workedaround with a where SQL clause.

To be added to the manual page.

...

(
I can't say I didn't search (20+ minutes). There is no related "log"
result that leads to that "contrib" page from within SQLite's page
search field itself!  And, in our wiki I admit I did not think about
Windows at all.
)

We need more volunteers to document stuff.
Concerning documenting stuff, I know there has been a discussion in the 
past about what should go to trac and what to the wiki. Was there any 
conclusion or document somewhere providing some guidelines on this? In 
addition, is there somewhere an overview of all pages in the wiki? That 
could helpful for the user, but also for those wanting to contribute / 
check if there is anything they can contribute to. If it doesn't exist, 
would it be something that could be generated (easily)?


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


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

Re: [GRASS-user] Issue with addon r.vif in MS Windows GUI installations (stand-alone v. 7.2.2 and 7.0.5)

[Paulo van Breugel]

On Thu, Feb 1, 2018 at 12:04 PM, Helmut Kudrnovsky  wrote:

> Dinarzarde Raheem wrote
> > I have been trying to run the addon r.vif using Grass for MS Windows
> > standalone v. 7.2.2 and v. 7.0.5 on three separate PCs (two have Windows
> 7
> > 32bit/64 bit, one runs Windows 10 Home 64 bit). I have been testing the
> > r.vif installation using the example on the r.vif page of the Grass 7
> > addons manual (i.e. this uses  the GRASS 7 Climatic data time series NC
> > location nc_climate_spm_2000_2012).
> >
> > With v. 7.2.2 (in both Windows 7 and 10) I can load the extension, and
> can
> > visualise Addons in the search modules tab, but the r.vif. tool is not
> > visible under Addons.
> >
> > With v. 7.0.5  (in both Windows 7 and 10), I can load r. vif, visualise
> it
> > under Addons in  the Search Modules tab and run it, but I get the
> > following error message:
> >
> >
> > (Wed Jan 31 15:06:21 2018)
> >
> > r.vif
> > maps=2011_01_precip@climate_1970_2012,2011_02_precip@climate
> _1970_2012,2011_03_precip@climate_1970_2012,2011_04_
> precip@climate_1970_2012,2011_05_precip@climate_1970_2012,
> 2011_06_precip@climate_1970_2012,2011_07_precip@climate_
> 1970_2012,2011_08_precip@climate_1970_2012,2011_09_
> precip@climate_1970_2012,2011_10_precip@climate_1970_2012,
> 2011_11_precip@climate_1970_2012,2011_12_precip@climate_1970_2012
> > maxvif=10 file=C:\grassworkspace\2011test
> >
> > Reading in the data ...
> >
> > Traceback (most recent call last):
> >
> >   File "C:\Users\dinr\AppData\Roaming\GRASS7\addons/scripts/
> >
> > r.vif.py", line 365, in
> > 
> > sys.exit(main(*gs.parser()))
> >
> >   File "C:\Users\dinr\AppData\Roaming\GRASS7\addons/scripts/
> >
> > r.vif.py", line 226, in main
> >
> > p = ReadData(IPF, n)
> >
> >   File "C:\Users\dinr\AppData\Roaming\GRASS7\addons/scripts/
> >
> > r.vif.py", line 156, in ReadData
> >
> > os.remove(tmpcov)
> >
> > WindowsError: [Error 32] The process cannot access the file
> >
> > because it is being used by another process:
> >
> > 'c:\\users\\dinr\\appdata\\local\\temp\\tmpsggohd'
> >
> > (Wed Jan 31 15:06:25 2018) Command finished (4 sec)
> >
> > Is there anything I can do to fix this issue?
>
> the reason for the error are these lines of code in the r.vif script:
>
> <-
> [...]
> 155# Clean up
> 156os.remove(tmpcov)
> -->
>
> the temporary file tmpcov isn't closed, therefore the temporary file can't
> be deleted.
>
> just for testing I changed locally here in the script
>
> <-
> [...]
> 155# Clean up
> 156# os.remove(tmpcov)
> -->
>
> now the script finishes with results.
>
> the reason is that handling of temporary files in python is different in
> linux and windows.
>
> ping the script author (mentioned in [1]) and ask him to adapt the script
> that it's also working in windows.
>
>
>
> [1] https://grass.osgeo.org/grass74/manuals/addons/r.vif.html
>
>
>
> Hi Dinarzard, I will have a look at it. Helmut, I see you commented out
the line that removes the temporary file. Any idea how I can do that in
such a way that it works on both Linux and Windows?


>
> -
> best regards
> Helmut
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Issue with addon r.vif in MS Windows GUI installations (stand-alone v. 7.2.2 and 7.0.5)

[Paulo van Breugel]

On February 2, 2018 8:52:03 PM Helmut Kudrnovsky  wrote:


Any idea how I can do that in such a way that it works on both Linux and

Windows?

in r.vif script I've changed the relevant lines:

<
# Get the raster values at sample points
fd, tmpcov = tempfile.mkstemp()
with open(tmpcov, "w") as text_file:
text_file.write(
gs.read_command("r.stats", flags="1n", input=raster,
quiet=True, separator="comma"))
p = np.loadtxt(tmpcov, skiprows=0, delimiter=",")

# Clean up
text_file.close()
os.close(fd)
os.remove(tmpcov)
if not n == "100%":
gs.run_command("r.mask", flags="r", quiet=True)
if exist_mask['fullname']:
gs.run_command("g.rename", raster=[mask_backup, "MASK"],
   quiet=True)
return(p)
>

and tested the script in winGRASS; it seems to work in windows; not tested
on linux and mac.



Ok, thanks Helmut, I'll see if that works in Linux too


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

Re: [GRASS-user] Issue with addon r.vif in MS Windows GUI installations (stand-alone v. 7.2.2 and 7.0.5)

[Paulo van Breugel]

On 2/3/18 1:33 PM, Stefan Blumentrath wrote:


Hi Paulo and Helmut,

Did you consider using cStringIO, if you need a file-object?

That would avoid the temporary file and thus should be more efficient 
too. See attached diff (it is probably not necessary to remove the 
last line break though).



Implemented your patch, thanks.  Dinarzarde, can you test?


Just a suggestion.

Yet, there might be even more efficient solutions. For example 
raster2numpy from pygrass…


https://grass.osgeo.org/grass74/manuals/libpython/pygrass.raster.html#pygrass.raster.raster2numpy

Here however, you would have to mask NULL and I am not sure how to 
(platform-independent) determine values that represent NULL in a 
raster map. This gives pointers but there are again issues with 
Windows it seems: 
https://grasswiki.osgeo.org/wiki/GRASS_Python_Scripting_Library#Interfacing_with_NumPy


And it leaves the question how to find out if a raster is Integer or not…

With pygrass you could do:

from grass.pygrass import raster as r

p = np.ma.masked_equal(r.raster2numpy(raster), np.nan)) # For floating 
point rasters on Linux


or

p = np.ma.masked_equal(r.raster2numpy(raster), -2147483648)) # For 
integer rasters


Hints from experienced Python/Numpy developers would be appreciated…

That makes me wonder if it would be worth to add/collect 
recommendations for how to solve such common operations (like e.g. 
parsing table output from grass commands) either e.g. here: 
https://trac.osgeo.org/grass/wiki/Submitting/Python 
<https://trac.osgeo.org/grass/wiki/Submitting/Python> or here: 
https://grasswiki.osgeo.org/wiki/GRASS_and_Python 
<https://grasswiki.osgeo.org/wiki/GRASS_and_Python> ?


Cheers

Stefan

*From:*grass-user [mailto:grass-user-boun...@lists.osgeo.org] *On 
Behalf Of *Paulo van Breugel

*Sent:* lørdag 3. februar 2018 09.14
*To:* Helmut Kudrnovsky ; grass-user@lists.osgeo.org
*Subject:* Re: [GRASS-user] Issue with addon r.vif in MS Windows GUI 
installations (stand-alone v. 7.2.2 and 7.0.5)


On February 2, 2018 8:52:03 PM Helmut Kudrnovsky <mailto:hel...@web.de>> wrote:


>>Any idea how I can do that in such a way that it works on both Linux and
> Windows?
>
> in r.vif script I've changed the relevant lines:
>
> <
> # Get the raster values at sample points
> fd, tmpcov = tempfile.mkstemp()
> with open(tmpcov, "w") as text_file:
> text_file.write(
> gs.read_command("r.stats", flags="1n", input=raster,
> quiet=True, separator="comma"))
> p = np.loadtxt(tmpcov, skiprows=0, delimiter=",")
>
> # Clean up
> text_file.close()
> os.close(fd)
> os.remove(tmpcov)
> if not n == "100%":
> gs.run_command("r.mask", flags="r", quiet=True)
> if exist_mask['fullname']:
> gs.run_command("g.rename", raster=[mask_backup, "MASK"],
>    quiet=True)
> return(p)
> >
>
> and tested the script in winGRASS; it seems to work in windows; not 
tested

> on linux and mac.
>
>
Ok, thanks Helmut, I'll see if that works in Linux too
>
> -
> best regards
> Helmut
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org <mailto:grass-user@lists.osgeo.org>
> https://lists.osgeo.org/mailman/listinfo/grass-user

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

Re: [GRASS-user] Issue with addon r.vif in MS Windows GUI installations (stand-alone v. 7.2.2 and 7.0.5)

[Paulo van Breugel]

Hi Dinarzarde and Helmut

I checked on Windows (grass 7.4.0 installed using osgeo4w), and 
installing r.vif using g.extension works fine, but after installing it 
does not appear in the addon list in the Modules tab. The same is true 
for a number of other addons I installed. There are, on the other hand, 
a number of addons that appear in the list (r.regression.series, 
r.series.lwr, v.kriging, and 6 others).


However, running these addons from the console (type in r.vif on the 
console) works.



Best wishes

Paulo


On 2/12/18 8:40 PM, Dinarzarde Raheem wrote:

Hi Helmut,

I have been installing r.vif as you have indicated (i.e. by downloading from 
the server using g.extension and opening the tree of installable raster 
addons), but can now confirm after installing both the new and old versions of 
r.vif on a Windows 10 (64 bit) machine, that r.vif isn't listed under the 
Addons in the module tab in both Grass standalone GUI versions 7.2.2 and 7.4.0 
(i.e. there is no plus sign in front of Addons, so there is no way of opening 
the tree of installed addons and selecting and running r.vif).

Best wishes,

Dinarzarde



From: Helmut Kudrnovsky [hel...@web.de]
Sent: 11 February 2018 16:13
To: Dinarzarde Raheem
Cc: grass-user@lists.osgeo.org; Paulo van Breugel
Subject: Aw: RE: [GRASS-user] Issue with addon r.vif in MS Windows GUI 
installations (stand-alone v. 7.2.2 and 7.0.5)


Gesendet: Sonntag, 11. Februar 2018 um 16:36 Uhr
Von: "Dinarzarde Raheem" 
I tried GRASS GIS versions 7.4.0 (current stable) and GRASS GIS 7.2.2 (old stable) 
but can't see r.vif listed under Addons in the Modules tab (see attached 
>screenshot).

you have to click on the + before "Raster" to open the tree of installable 
raster addons.




One thing I noticed is that when you re-install Grass and then install r.vif 
you get this message:
(Sun Feb 11 16:29:48 2018)
g.extension extension=r.vif url=
WARNING: Extension  already installed. Re-installing...
Downloading precompiled GRASS Addons ...
Updating addons metadata file...
Installation of  successfully finished
(Sun Feb 11 16:29:57 2018) Command finished (9 sec)

yes, it's an obvious message as you install the script from the server over the 
local copy.


I guess by tomorrow the new version of r.vif should be available via the server 
so will try again tomorrow.

the new version is already on the server and should be installable by 
g.extension, see

for winGRASS7.5.svn daily:
https://wingrass.fsv.cvut.cz/grass75/x86_64/addons/grass-7.5.svn/

for  winGRASS7.4.0:
https://wingrass.fsv.cvut.cz/grass74/x86_64/addons/grass-7.4.0/

etc

kind regards
Helmut


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

Re: [GRASS-user] Issue with addon r.vif in MS Windows GUI installations (stand-alone v. 7.2.2 and 7.0.5)

[Paulo van Breugel]

On Tue, Feb 13, 2018 at 5:15 PM, Markus Neteler  wrote:

> On Tue, Feb 13, 2018 at 12:45 AM, Paulo van Breugel
>  wrote:
> > Hi Dinarzarde and Helmut
> >
> > I checked on Windows (grass 7.4.0 installed using osgeo4w), and
> installing
> > r.vif using g.extension works fine, but after installing it does not
> appear
> > in the addon list in the Modules tab. The same is true for a number of
> other
> > addons I installed. There are, on the other hand, a number of addons that
> > appear in the list (r.regression.series, r.series.lwr, v.kriging, and 6
> > others).
>
>
> Could you please check if this depends on the programming language in
> which the respective module was written (Python, C, ...)?
>


Installed r.area (C) en r.bioclim (Python) and indeed, the former shows up
under the Modules tab in the addon group, the latter not.


>
> best,
> Markus
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] question to the community: winGRASS - still a need for 32bit versions?

[Paulo van Breugel]

On Wed, Dec 11, 2019 at 10:12 PM Helmut Kudrnovsky  wrote:
>
> Helmut Kudrnovsky wrote
> > Hi GRASS community,
> >
> > as stated e.g. in:
> >
> > 
> > [GRASS-dev] [release planning] GRASS GIS 7.8.2
> > https://lists.osgeo.org/pipermail/grass-dev/2019-December/093846.html
> > ##
> > ne 8. 12. 2019 v 0:33 odesílatel napsal:
> >> winGRASS 7.8.2RC2 64bit is available for testing in OSGeo4W 64bit when
> >> the
> >> experimental/testing tick is activated.
> >
> > also 32bit package available for testing and standalone installers [1].
> >
> > [1] https://grass.osgeo.org/grass78/binary/mswindows/native/
> > 
> >
> > we're providing winGRASS in 32bit and 64bit versions (OSGeo4W and
> > standalone).
> >
> > nowadays 64bit windows operating systems (e.g. win 10) are very common;
> > most
> > of the personal computer assembled after 2010 are 64bit systems. linux
> > distributions start to phase out 32bit support. [1] [2] [3] [4]
> >
> > a question to our winGRASS community: is there still a need for 32bit
> > versions of winGRASS?
> >
> > [1] https://itsfoss.com/end-of-32-bit-linux/
> > [2]
> > https://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-Drops-32-bit-x86
> > [3]
> > https://www.phoronix.com/scan.php?page=news_item&px=OpenMandriva-Dropping-32-Plans
> > [4]
> > https://www.pcworld.com/article/3089509/end-of-an-era-linux-distributions-will-soon-stop-supporting-32-bit-pcs.html
>
> nobody claims a need for a 32bit winGRASS? really?
>
> do we need winGRASS at all? ;-)

Yes!

>
> if no objections will pop up in the next days, I'll propose  to the GRASS
> PSC (project steering commitee):
>
> * phasing out winGRASS 32bit support by middle next year (2020 July 31)*
>
> reasoning for this proposal:
>
> - 64bit computer architecture and 64bit windows operating systems are very
> common
> - 32bit computer architecture and 32bit windows operating systems will find
> their EOL
>
> and the important reasons:
>
> - reduce the high maintenance burden to keep 2 build environments of
> winGRASS (32bit, 64bit) alive
> - facilitate to find possible (automatic) alternatives of winGRASS build
> environments beside the actual MSYS2/OSGeo4W workflow
>
> comments are welcome :-)

Not a developer, but I think this is a reasonable proposal

>
>
>
>
> -
> best regards
> Helmut
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] [GRASS-dev] 37 years of GRASS GIS: celebrating with a new GRASS GIS website!

[Paulo van Breugel]

Congratulations, absolutely looks great!

On July 29, 2020 4:04:09 PM Markus Neteler  wrote:

Wednesday, July 29, 2020
The new GRASS GIS website is out!
In occasion of its 37th birthday the GRASS GIS project is proud to present 
its new website! The site has been redesigned with modern tools to be 
responsive and also easier to maintain. Content is more discoverable now 
and easy to browse too.

What’s cool
The Learn page offers a curated list of tutorials in different languages 
and links to videos. The new Try online section provides links to Binder 
and rollApp online applications that allow testing GRASS GIS without 
installing it.
Our long standing and rich history in the GIS and open source world is now 
presented in a much more attractive layout. Have a look at the timeline of 
releases and websites!
The revamped gallery of screenshots shows some of GRASS GIS capabilities 
through visual examples.
Project resources easily reachable: mailing lists, wiki, RSS news feed, the 
various GitHub and docker repositories.

The technology
We chose a static format based on HUGO and all the code and content is 
hosted in a dedicated repo in GitHub. Nicolas Bozon designed the website 
theme and many others helped with content curation and creation. In detail, 
the page content is now written in markdown. Several times a day the 
website is automatically deployed from the GitHub repository to our 
internet server at https://grass.osgeo.org/ .

What’s next
With this new web technology and the availability of the code and content 
in a public repository, we want to encourage and simplify community 
members’ participation. If you want your GRASS GIS use cases, blog posts 
and cool screenshots to be part of if, you only need to create a pull 
request. No fear, we have a manual for contributions.
We thank all the contributors for their input and help to see this project 
finally realized! Special thanks to OSGeo as well as individuals for their 
financial support.

Stay tuned, there’s more yet to come!
___
grass-dev mailing list
grass-...@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev


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

Re: [GRASS-user] Creating a png file with multiple vector maps

[Paulo van Breugel]

Would this addon be useful? 
https://grass.osgeo.org/grass78/manuals/addons/m.printws.html


On February 11, 2021 6:55:24 PM Chris Bartolomei via grass-user 
 wrote:


Good morning Anna,
It took quite a while of trial and error but I worked out a method that 
kindof works:
First off - unless someone says otherwise, you can't use the PNG driver 
(d.mon) method to overlay more than one polygon vector. Sorry - it just 
doesn't work. You CAN use the ps.map method - that works really well 
generating the image however it by default assumes you are printing on an 
A4 piece of paper so there's all sorts of white space.  The image is 
centered at the top of this fictional piece of paper. In your postscript 
rules file you can use the "maploc" command to position the image elsewhere 
on the page. This is necessary because the next trick changes the paper 
dimensions but it assumes the origin is the lower left corner and therefore 
clips anything that is above the new dimensions. Back to postscript 
commands in the rules file first though ... the ps.map maploc command uses 
inches (why?? it should be points) so an A4 page is 8.27" x 11.69"  points 
are 1/72 of an inch thus 595p x 842p - it also has a default 36p margin 
(0.5 inch). You'll need those numbers later. maploc also lets you set the 
size of your image box:  maploc {x offset from left edge} {y offset from 
top} {width of box} {height of box} Note: this is all done via a BASH 
script with GRASS 7.4 on Linux (RHEL 7), not python. This is my postscript 
rules file:


maploc 0.1 6.815 6.5 4.875 #468p x 351p map box moved down towards the 
bottom of the page
# note that if you push it too far down to where the box would run off the 
bottom, the image is
# resized to fit on the page so do some testing to come up with the correct 
values
# also I found the computational region controls the aspect ratio so 
although I say

# 6.5 x 4.875 with the above maploc command, I got a 6.5 x 3.8 inch box.
border y # add a border to the map frame (box)
color 81:81:81 # shade of gray
end # end the border controls
vareas admin_area # top vector layer to display
layer 1 # attribute table to use
rgbcolumn area_color # name of column holding R:G:B values to fill the polygons
color 153:153:153 #boundary color
end # end the admin_area controls
vareas Country # this is the bottom vectors to display
color 210:210:210 #boundary color
fcolor 153:153:153 #fill color for all polygons
end # end the Country controls


Here's the command to run to generate the postscript file:


ps.map input=$HOME/ps_rules.txt out=$HOME/color_admin.ps --overwrite


To convert the postscript to PNG I had to use ghostscript - there are other 
tools you can use though.



gs -dSAFER -dBATCH -dNOPAUSE -sDEVICE=png16m -r300 -dTextAlphaBits=4 
-dGraphicsAlphaBits=4 -dDEVICEWIDTHPOINTS=473 -dDEVICEHEIGHTPOINTS=276 
-dFIXEDMEDIA -dPSFitPage -sOutputFile=$HOME/color_admin.png -c 
"<> setpagedevice" -f $HOME/color_admin.ps


So the above line needs some explaining 
(http://www.ghostscript.com/doc/9.27/Use.htm) but in a nutshell, the 
parameters to play with are first the Pageoffset [x y] values. They are in 
points not inches ... 1/72 inch = 1 point ... remember the 1/2" margins? 
the -34 gives me 2 points of white space to the left edge of the map frame, 
the 78 I had to play with to push the map frame down to the right spot.
Next is the DEVICEWIDTHPOINTS and DEVICEHEIGHTPOINTS ... again in points 
... this "trims" the paper to height and width ... set something then run 
it and view the results. Adjust and run again until you get it correct.


It's a royal pain but it seems to work this way. It would sure be nice to 
create a GRASS workspace file and just say "convert this workspace to an 
image" with everything all laid out nicely - like Arc does exporting their 
mxd map files...


I hope this helps someone !
:)

Chris


On Wednesday, February 10, 2021, 11:08:00 PM EST, Anna Petrášová 
 wrote:





On Tue, Feb 9, 2021 at 4:41 PM Chris Bartolomei  wrote:

Hi Anna - thank you for the suggestion - I tried it but alas, still it only 
outputs a single vector map (layer). I can get either the Country vector or 
the admin_areas vector, but not both overlaid.

:(
Chris

I realized you are using both environmental variables and d.mon, that might 
cause some issues, you use one or the other. So try to remove the lines 
starting with d.mon.


Hope that helps,
Anna


On Tuesday, February 9, 2021, 1:20:52 PM EST, Anna Petrášová 
 wrote:



Hi,

On Tue, Feb 9, 2021 at 10:25 AM Chris Bartolomei via grass-user 
 wrote:

Good morning :)
I'm using GRASS 7.4.1 on a Linux cluster so I only have command-line 
capability. I have two vector layers (a country boundary polygon and part 
of an administrative area map - also polygons). I am trying to automate 
creating a PNG file of the admin areas overlaying the country boundary 
therefore all work has to be command-line (in a bash script). I've tried 
this two ways - using the d.mon start=

Re: [GRASS-user] v.in.ogr ESRI fileGDB

[Paulo van Breugel]

And if it works, perhaps it is worth adding an example to the help page? Or
send a working code example that others can add to the help file of
v.in.ogr if you like.

On Fri, Sep 17, 2021 at 8:46 AM Maris Nartiss  wrote:

> Hello Rich,
> I don't have File GDB at hand to test it but it should be as simple as
> pointing "input" to the folder of FGDB and setting "layer" to the name
> of dataset in FGDB. You can get names of all layers in CLI with
> "ogrinfo -ro -so /path/to/FGDB".
>
> Good luck & let us know if you succeed.
> Māris.
>
> ceturtd., 2021. g. 16. sept., plkst. 20:08 — lietotājs Rich Shepard
> () rakstīja:
> >
> > I have an ESRI GDB directory of bathymetric and topographic coverage.
> I've
> > not before imported this type of file from the command line.
> >
> > Looking at the v.in.ogr manual page I'm not sure how to write the
> command;
> > there's not an example for a GDB.
> >
> > Please point me to a reference that will teach me how to import this file
> > type.
> >
> > TIA,
> >
> > Rich
> > ___
> > grass-user mailing list
> > grass-user@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/grass-user
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Display behavior of table attribute data

[Paulo van Breugel]

That is, I guess, because sqlite 'uses dynamic typing. It does not enforce 
data type constraints. Data of any type can (usually) be inserted into any 
column. '?


On October 6, 2021 5:25:47 PM Rich Shepard  wrote:


I learned something surprising this morning using a combination of the GUI
management window's map 'display table attributes' and db.execute.

The two adjacent bathymetric point files imported with a Z-int column with
type double precision for the integer depths. However, the depth values
displayed are in double precision format (ending in .00).

I added a new column, depth_int (type int), and copied (using SQL's 'alter
table') the Z-int double precision values to the depth_int column, then
deleted the Z-int column. The GUI's attribute table management dialog
confirmed that the depth_int is of type integer.

After re-displaying these maps the depth values are still double precision
while the column data type is integer. Oh well.

Rich

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


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

Re: [GRASS-user] v.in.csv available?

[Paulo van Breugel]

On Thu, Oct 28, 2021 at 11:38 AM Stefan Blumentrath <
stefan.blumentr...@nina.no> wrote:

> Hei Johannes,
>
> Sounds like v.in.csv is the right tool.
>
> The manual is build (
> https://grass.osgeo.org/grass78/manuals/addons/v.in.csv.html), also on MS
> Windows: https://wingrass.fsv.cvut.cz/grass78/x86_64/addons/latest/logs/
> It should be available via g.extension. You would need GRASS 7.8.6 (or
> 8.0) though du to recent restructuring of the addons repository...
>

Not all addons seem to be available through g.extension. Even though they
show up in the online overview, for me they do not appear in the list using
g.extension (using grass 7.8.6 on both Linux and Windows), see
https://github.com/OSGeo/grass/issues/1960


> Alternatively, you can clone the repo and install from local file-URL (on
> non-Windows systems).
>
> Cheers
> Stefan
>
> -Original Message-
> From: grass-user  On Behalf Of
> Johannes Radinger
> Sent: torsdag 28. oktober 2021 10:42
> To: GRASS user list 
> Subject: [GRASS-user] v.in.csv available?
>
> Hi all,
>
> I was wondering if the addon v.in.csv is available or not? I want to
> import a simple point file (*.csv) which is unfortunately in another
> projection then my location. So the tool v.in.csv looks handy.
>
> This tool is listed here
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrass.osgeo.org%2Fgrass78%2Fmanuals%2Faddons%2F&data=04%7C01%7CStefan.Blumentrath%40nina.no%7C1983499eb4f1445533b608d999eedfff%7C6cef373021314901831055b3abf02c73%7C0%7C0%7C637710074397800843%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=nE7Wfm6iA%2FSiLSkHq9bXa09PYDeNxb2wHYCIrQOWS0k%3D&reserved=0
>
> but not here
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrasswiki.osgeo.org%2Fwiki%2FAddOns%2FGRASS7%2Fvector&data=04%7C01%7CStefan.Blumentrath%40nina.no%7C1983499eb4f1445533b608d999eedfff%7C6cef373021314901831055b3abf02c73%7C0%7C0%7C637710074397810835%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=IAZc5CpQDMKkiPqlXSIIUX3G0T4IhtRYNvJGfHIeGXQ%3D&reserved=0
> and seems not be available via g.extension(?)
>
> Any suggestion? What would be the most convenient way to do such an import
> with coordinate transformation to match my current location?
>
> Cheers,
>
> Johannes
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.osgeo.org%2Fmailman%2Flistinfo%2Fgrass-user&data=04%7C01%7CStefan.Blumentrath%40nina.no%7C1983499eb4f1445533b608d999eedfff%7C6cef373021314901831055b3abf02c73%7C0%7C0%7C637710074397810835%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Sn%2FJqpmJUDP80ygS%2FT5BF2S3s7EHjFdl66Spqryu%2FpA%3D&reserved=0
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] [GRASS-dev] GRASS GIS 8.0.0 released

[Paulo van Breugel]

Congratulations on this milestone!

On February 3, 2022 6:28:47 PM Markus Neteler  wrote:

GRASS GIS 8.0.0 released

Overview of changes
After more than 3 year of development the first stable release GRASS GIS 
8.0.0 is available. Efforts have concentrated on making the user experience 
even better, providing many new useful additional functionalities to 
modules and further improving the graphical user interface.
Breaking news: new graphical user interface with entirely rewritten startup 
sequence!
This re-establishes user experience compatibility with QGIS and other 
connected software packages.
The GRASS GIS 8.0.0 release provides more than 1,400 fixes and improvements 
with respect to the release 7.8.6.
With the introduction of the semantic label raster metadata class, the 
temporal database was modified to version 3. Hence, to be able to read and 
process GRASS 7.x space-time datasets, users will be prompted to run 
t.upgrade. If users want to read newly created space-time datasets back in 
GRASS 7.x, they can run t.downgrade.

Launching the software
The user experience of the graphical user interface has been completely 
rewritten: no more clumsy selection screens - just enter the menu system 
directly!

And on command line, GRASS GIS now starts versionless, i.e. as grass.
Downloads
Source code (zip) | Source code (tar.gz)
https://grass.osgeo.org/grass80/source
Binaries: https://grass.osgeo.org/download/
Visit the release page for detailed release notes.
Thanks to all contributors!
___
grass-dev mailing list
grass-...@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev


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

Re: [GRASS-user] use pipe character in a script

[Paulo van Breugel]

On Wed, Mar 23, 2022 at 8:59 AM Uwe Fischer  wrote:

> Hello,
>
>
>
> I try to fill a certain attribute column with a variable plus a Pipe
> character (|) in a python script:
>
>
>
> value_to_fillin = myvariable + '|'
>
> grass.run_command(‘v.db.update‘, map='mymap', column='mycol',
> value=value_to_fillin)
>

This works for me:

import grass.script as gs
valuetofillin = "myvariable{}".format('a')
gs.run_command('v.db.update', map='aaa', column='aa',
value=valuetofillin)

Btw, make sure to use the right single quotation marks around v.db.update.
In your example, you are using pretty print quotation marks around
v.db.update, so perhaps that is the culprit?



>
>
>
> But it does not work. When I try to place there 'xx' instead of the pipe,
> it works.
>
>
>
> Does the pipe have special meaning in Python or GRASS and therefore is not
> available as normal character? Is there a workaround (because the pipe must
> be there to meet my data transfer requirements)
>
>
>
> Regards, Uwe
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] use pipe character in a script

[Paulo van Breugel]

On Fri, Apr 1, 2022 at 10:26 AM Paulo van Breugel 
wrote:

>
>
> On Wed, Mar 23, 2022 at 8:59 AM Uwe Fischer  wrote:
>
>> Hello,
>>
>>
>>
>> I try to fill a certain attribute column with a variable plus a Pipe
>> character (|) in a python script:
>>
>>
>>
>> value_to_fillin = myvariable + '|'
>>
>> grass.run_command(‘v.db.update‘, map='mymap', column='mycol',
>> value=value_to_fillin)
>>
>
> This works for me:
>
> import grass.script as gs
> valuetofillin = "myvariable{}".format('a')
> gs.run_command('v.db.update', map='aaa', column='aa',
> value=valuetofillin)
>

Sorry, that should have been:

valuetofillin = "myvariable{}".format('|')
gs.run_command('v.db.update', map='aaa', column='aa',
value=valuetofillin)


>
> Btw, make sure to use the right single quotation marks around v.db.update.
> In your example, you are using pretty print quotation marks around
> v.db.update, so perhaps that is the culprit?
>
>
>
>>
>>
>>
>> But it does not work. When I try to place there 'xx' instead of the pipe,
>> it works.
>>
>>
>>
>> Does the pipe have special meaning in Python or GRASS and therefore is
>> not available as normal character? Is there a workaround (because the pipe
>> must be there to meet my data transfer requirements)
>>
>>
>>
>> Regards, Uwe
>>
>>
>> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-user
>>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Ubuntu and Grass - which versions/combinations?

[Paulo van Breugel]

Hi Sharon,

GRASS version 6.4 rc6 is in the repository, so installing GRASS should be
very easy. Just open the Ubuntu software center and search for GRASS (you
probably want to install the optional packages listed too. (BTW, I would go
for the latest Ubuntu or alternatively for the latest long-term supported
version, check the Ubuntu page for more details).

I have compiled GRASS myself (6.4.1 and 7, which you can install both),
mainly because at the time I started to use it on Ubuntu, the GRASS version
in the repositories was rather old. Moreover, it allows greater control over
how GRASS is setup. And although initially a pain, when set up and all
dependencies are installed, subsequent updates are easy.

It is still not the most recent release, but if you want to use the latest
stable release (6.4.1), you don't have to compile it yourself. You can just
add a PPA, which makes installing the latest stable version fairly simple
too. I don't know how familiar you are with Ubuntu and the use of software
sources, but have a look at https://launchpad.net/~grass/+archive/grass
-stable .

Cheers,

Paulo


On Thu, Jul 14, 2011 at 9:39 AM, Sharon M  wrote:

> I currently use winGrass on Win XP - mainly importing shape files, data
> loads to dbf, various vector modules for analysis and ps.map.  I experience
> a few issues with winGrass, so would like to try Grass on Ubuntu - see if I
> can eliminate some Grass issues.  I'd be using Ubuntu installed via wubi
> (because it's a win XP laptop).
>
> Does anyone using Ubuntu/Grass have suggestions as to which version(s) of
> Ubuntu and versions of Grass are the most stable / reliable combinations?
> and importantly easiest to install and set up.
>
> Any links to help for setting up Grass on Ubuntu (or Linux generally) also
> appreciated.
>
> Thanks in advance.
>
> Sharon
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Changing/matching the coordinates

[Paulo van Breugel]

Hi,

Assuming the two layers come in different projections, you need to import
them in different locations in your GRASS database with corresponding
projections. If you do not already have locations in projections that match
those of your layers, you can create new locations when opening GRASS (check
'create new location'). Also note that when you are in GRASS and want to
import an layer that is in a projection different from the current location
/ mapset, r.in.gdal allows you to create a new location on the fly (check
r.in.gdal).

When you have both layers in two different locations, you should open e.g.,
the location and mapset with the raster layer. Then use v.proj (menu: vector
- develop vector map - reproject vector map)  to reproject the vector layer
into the current location. Or the other way around, when in the
location/mapset with the vector layer, use or r.proj (menu: raster - develop
raster map - reproject raster map) to reproject and copy the raster layer to
your current location/mapset.

Cheers,

Paulo



2011/7/13 giannis Nj 

>  Hi,
>
> i have one raster and one vector file and i want to match them at the
> diplay map. I want to change the coordinates of one of them, i guess
> specifying the right coordinate reference system can do the job. How can i
> do this at Grass? In Quantum is very easy, from the layer Properties, in
> Grass i can't find it.
>
> Thanks.
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Exporting labels of a raster

[Paulo van Breugel]

Just a slight off topic remark concerning the append text labels to your
grass raster layer. I think you might want to try out r.category. That way
you label your original raster rather then creating an additional (reclass)
layer with labels.

As for the question, I agree with previous comments, exporting the raster
and a separate text file with the legend is probably the best (only?) way to
go.


On Fri, Jul 1, 2011 at 2:20 PM, Rainer M Krug  wrote:

>
>
> On Fri, Jul 1, 2011 at 2:06 PM, Luisa Peña wrote:
>
>> Hello Rainer
>> I'm using reclass in order to have a raster with text lables (land use
>> land cover class names). I thought that r.reclass would be the only way to
>> have that.
>> and My reclass file is something like this:
>> 1 = 1 Urban
>> 2 = 2 Agriculture
>> 3 = 3 Irrigated Agriculture
>> 4 = 4 Forests
>> 5 = 5 Shrubland
>> * = NULL
>> Do you have any alternative suggestion to have labels in LULC?
>>
>
> It depends what you want to do with the raster.
>
> For labelling, this is the right approach.
>
> So when you use r.mapcalc "new_map=@existing_map"
>
> this will assume that the labels of your input map are numeric. Are your
> labels numeric or characters?
>
> From the help:
>
> ##
> RASTER MAP LAYER VALUES FROM THE CATEGORY FILE
>
> Sometimes it is desirable to use a value associated with a category's label
> instead of the category value itself. If a raster map layer name is preceded
> by the @ operator, then the labels in the category file for the raster map
> layer are used in the expression instead of the category value.
> For example, suppose that the raster map layer soil.ph (representing soil
> pH values) has a category file with labels as follows:
>
> cat label
> --
> 0 no data
> 1 1.4
> 2 2.4
> 3 3.5
> 4 5.8
> 5 7.2
> 6 8.8
> 7 9.4
> Then the expression:
>
> result = @soils.ph
> would produce a result with category values 0, 1.4, 2.4, 3.5, 5.8, 7.2, 8.8
> and 9.4.
>
> Note that this operator may only be applied to raster map layers and
> produces a floating point value in the expression. Therefore, the category
> label must start with a valid number. If the category label is integer, it
> will be represented by a floating point number. I the category label does
> not start with a number or is missing, it will be represented by NULL (no
> data) in the resulting raster map.
> ##
>
>
> Cheers,
>
> Rainer
>
>
>> THanks
>> Luisa
>>
>> 2011/7/1 Rainer M Krug 
>>
>>>
>>>
>>> On Fri, Jul 1, 2011 at 1:24 PM, Luisa Peña wrote:
>>>
 It didn't work. I get all full of NaNs map.
 I used this:
 input="LUlabel@Study"
 grass.run_command("g.region", rast = input)
 grass.mapcalc("$output= @$labels", labels=input, output="Giovanni2")

 What am I doing wrong on this?

>>>
>>> NaN means Not a Number - were your labels non-numeric?
>>> I *think* that raster can only have numeric cell values
>>>
>>> Rainer
>>>
>>>
>>>
  Luisa

 2011/7/1 Giovanni Manghi 

> Hi,
>
>
> >
> > I have a raster map to wich I have applied r.reclass to add labels to
> > raster classes.  When I try to export this raster with the classes I
> > loose the lablels I only stick with the values.
> > In a script how can edit this raster in order to be exported with the
> > labels?Thanks
>
>
> r.mapcalc "new_map=@existing_map"
>
> then export "new_map" to tiff as usual.
>
> Cheers
>
> -- Giovanni --
>
>
>

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


>>>
>>>
>>> --
>>> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
>>> Biology, UCT), Dipl. Phys. (Germany)
>>>
>>> Centre of Excellence for Invasion Biology
>>> Stellenbosch University
>>> South Africa
>>>
>>> Tel :   +33 - (0)9 53 10 27 44
>>> Cell:   +33 - (0)6 85 62 59 98
>>> Fax (F):   +33 - (0)9 58 10 27 44
>>>
>>> Fax (D):+49 - (0)3 21 21 25 22 44
>>>
>>> email:  rai...@krugs.de
>>>
>>> Skype:  RMkrug
>>>
>>>
>>
>
>
> --
> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
> UCT), Dipl. Phys. (Germany)
>
> Centre of Excellence for Invasion Biology
> Stellenbosch University
> South Africa
>
> Tel :   +33 - (0)9 53 10 27 44
> Cell:   +33 - (0)6 85 62 59 98
> Fax (F):   +33 - (0)9 58 10 27 44
>
> Fax (D):+49 - (0)3 21 21 25 22 44
>
> email:  rai...@krugs.de
>
> Skype:  RMkrug
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Re: raster stats within vector

[Paulo van Breugel]

v.rast.stats (menu: Vector-Update area attribute from raster) will 
calculate n, min, max, range, mean, stddev, variance, coeff_var, sum and 
optionally the 1st quartile, median, 3rd quartile, and given percentile. 
Columns will be created on the fly, you only have to give the 'base 
name' of the columns. I.e., no need to create a column yourself.



On 07/16/2011 10:14 PM, Milton Cezar Ribeiro wrote:

BTW,

my vector maps have polygons.

milton

2011/7/16 Milton Cezar Ribeiro >


Dear all,

I have a raster map with continuous values, and need to extract
some stats (like mean, std etc) assigning these "zonal" values as
a vector column.
I just added the empty columns on the my vector map using :
  v.db.addcol map=frag_ts columns="FLOW_STD DOUBLE PRECISION"

How can I do this on grass?

cheers

milton



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


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

Re: [GRASS-user] Cut Subscene

[Paulo van Breugel]

Hi Christian

Mask is only masking out areas, it doesn't change your extent. You need to
change your region bounds. You can set those is menu-Config-region-set
region (or g.region on the command line). Region is a very important concept
in GRASS GIS.If you are not familiar with regions, make sure to read a bit
more in the help files.

A quick way to change your region extend visually is in the map display
window, where you can set your region from the current display.

Cheers

Paulo



On Wed, Jul 20, 2011 at 5:32 PM, Christian Röttger <
chris.roett...@uni-muenster.de> wrote:

> Hello,
>
> i'm working with grass 6.4.1 and have a huge quickbird scene which i want
> to cut, so that i only work with a small sample area.
> i created a mask and performed all operations, working very well. but when
> i export the test area as geotiff it has the same extent as the huge base
> image.
> also tried to copy the masked area with mapcalc, same problem.
>
> what is the best way to cut huge images into pieces without loosing data
> information?
>
> thanks
> christian
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Comparing 2 large Corine Land Cover maps

[Paulo van Breugel]

Maybe r.cross can be of help. It creates a cross product of the category
variables of a layer, i.e., a map with separate categories for each unique
combination of the two CLC maps (the category labels gives you the
combination of input maps for each new category).

You can use this new map to create a reclass map with the new values from
your decision matrix. To do this, you could for example follow the following
steps:

1) Run r.category to get a list with the categories and category labels of
the cross product map you just created. You can output this as a text file
2) Use a spreadsheet or something like awk to create a textfile with three
columns, one with the new category, and two with the clc2000 and clc2006
categories
3) Find a way to link the CLC combinations in your text file to the new
classes given in your decision matrix (use e.g., spreadsheet or database)
4) Use this new table to create the reclassification rules you need in the
next step (again, if you know awk this will probably be very easy, but also
in R or in a spreadsheet this is easy to do).
5) Create a text file with reclassification rules (see r.reclass how these
should look like) and use r.reclass to reclassify the map you just created
with r.cross.

I guess there must be easier ways. But in any case, these steps are not very
difficult to implement. And in case you have to repeat this type of analysis
more often, once you have set up a workflow, it will be easy to repeat
(especially if you manage to implement all steps as a script).



On Fri, Jul 22, 2011 at 12:41 PM, Hermann Peifer  wrote:

> Hi,
>
> I have 2 Corine Land Cover (CLC) raster maps, from 2000 and 2006. Both maps
> have the same extent, the same resolution (100m) and use the same 44 CLC
> categories. The maps are pretty large: 67 000 cols x 58 000 rows = 3 886 000
> 000 cells.
>
> I'd like to categorise the changes between the 2 layers, according to a
> decision matrix which I pasted below [1]. Row headers indicate the clc2000
> category, column headers represent the clc2006 category. I only pasted the
> "left half" of the table in order to avoid ugly line breaks.
>
>
> Question:
> Is there a better (and faster) way than doing this comparison by using
> r.mapcalc with a (nearly) endless if/else chain [2] ?
>
> I also noted that in 99+ % of the cases, both maps are NULL or have an
> identical CLC category, so I wouldn't need the if/else chain at all. I guess
> I can use this fact to shortcut the comparison?
>
>
> Thanks in advance, Hermann
> (using GRASS 6.4 on 64-bit Debian Linux)
>
> [1]
>
> ##  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 ..
>  1 NA 12 31 32 33 34 35 36 37 13 38 56 56 56 56 56 56 56 56 56 56 56 ..
>  2 11 NA 31 32 33 34 35 36 37 13 38 56 56 56 56 56 56 56 56 56 56 56 ..
>  3 12 12 NA 32 33 34 35 36 37 13 38 56 56 56 56 56 56 56 56 56 56 56 ..
>  4 12 12 31 NA 33 34 35 36 37 13 38 56 56 56 56 56 56 56 56 56 56 56 ..
>  5 12 12 31 32 NA 34 35 36 37 13 38 56 56 56 56 56 56 56 56 56 56 56 ..
>  6 12 12 31 32 33 NA 35 36 37 13 38 56 56 56 56 56 56 56 56 56 56 56 ..
>  7 12 12 31 32 33 34 NA 36 37 13 38 56 56 56 56 56 56 56 56 56 56 56 ..
>  8 12 12 31 32 33 34 35 NA 37 13 38 56 56 56 56 56 56 56 56 56 56 56 ..
>  9 12 12 31 32 33 34 35 36 NA 13 38 56 56 56 56 56 56 56 56 56 56 56 ..
> 10 11 11 31 32 33 34 35 36 37 NA 38 56 56 56 56 56 56 56 56 56 56 56 ..
> 11 11 11 31 32 33 34 35 36 37 13 NA 56 56 56 56 56 56 56 56 56 56 56 ..
> 12 21 22 31 32 33 34 35 36 37 13 38 NA 45 43 42 42 42 41 42 41 83 61 ..
> 13 21 22 31 32 33 34 35 36 37 13 38 43 NA 43 42 42 42 41 42 41 83 61 ..
> 14 21 22 31 32 33 34 35 36 37 13 38 43 43 NA 42 42 42 41 42 41 83 61 ..
> 15 21 22 31 32 33 34 35 36 37 13 38 45 45 45 NA 44 44 41 45 45 83 61 ..
> 16 21 22 31 32 33 34 35 36 37 13 38 45 45 45 44 NA 44 41 45 45 83 61 ..
> 17 21 22 31 32 33 34 35 36 37 13 38 45 45 45 44 44 NA 41 45 45 83 61 ..
> 18 21 22 31 32 33 34 35 36 37 13 38 45 45 45 42 42 42 NA 45 45 83 61 ..
> 19 21 22 31 32 33 34 35 36 37 13 38 45 45 45 42 42 42 41 NA 41 83 61 ..
> 20 21 22 31 32 33 34 35 36 37 13 38 45 45 45 42 42 42 41 45 NA 83 61 ..
> 21 21 22 31 32 33 34 35 36 37 13 38 52 52 52 52 52 52 41 52 54 NA 54 ..
> 22 21 22 31 32 33 34 35 36 37 13 38 45 45 45 42 42 42 41 45 45 83 NA ..
> 23 21 22 31 32 33 34 35 36 37 13 38 51 51 51 51 51 51 53 51 53 53 53 ..
> 24 21 22 31 32 33 34 35 36 37 13 38 51 51 51 51 51 51 53 51 53 53 53 ..
> 25 21 22 31 32 33 34 35 36 37 13 38 51 51 51 51 51 51 53 51 53 53 53 ..
> 26 21 22 31 32 33 34 35 36 37 13 38 52 52 52 52 52 52 54 52 54 54 54 ..
> 27 21 22 31 32 33 34 35 36 37 13 38 52 52 52 52 52 52 54 52 54 54 54 ..
> 28 21 22 31 32 33 34 35 36 37 13 38 52 52 52 52 52 52 54 52 54 54 54 ..
> 29 21 22 31 32 33 34 35 36 37 13 38 52 52 52 52 52 52 54 52 54 54 54 ..
> 30 21 22 31 32 33 34 35 36 37 13 38 52 52 52 52 52 52 54 52 54 54 53 ..
> 31 21 22 31 32 33 34 35 36 37 13 38 52 52 52 52 52 52 54 52 54 54 53 ..
> 32 21 22 31 32 33 34 35 36 37 13 38 52 52 52 52 52 52 54 

Re: [GRASS-user] mapcalc

[Paulo van Breugel]

Unless there is a specific reason to use r.mapcalc I would suggest to 
use r.patch



On 07/25/2011 11:20 PM, Rebecca Bennett wrote:

Hello all,

I would like to use r.mapcalc to fill the null cells of one raster 
with the value of the same cells from in a second raster (while 
leaving all other cells as they are in the first raster).


Clearly I am having some kind of brain frizz because this should be 
simple but I can't get it right...


Sorry and thanks for reading,

Rebecca


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


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

Re: [GRASS-user] Set default cell type to FCELL?

[Paulo van Breugel]

When you include in any one of your multiplication a number with at least
one decimal your result should be a floating raster. Perhaps not as easy as
what you are asking for, but it shouldn't be too error prone, should it?

Paulo


On Tue, Jan 10, 2012 at 3:08 PM, Rainer M Krug  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/01/12 12:50, Massimiliano Cannata wrote:
> > Hi, not sure to have understood what you want to do but maybe
> > using r.mapcalc functions: - double(x)   --> convert x to
> > double-precision floating point - float(x)   -->convert x
> > to single-precision floating point
>
> Sorry for not being more clear.
>
> What you suggest is exactly what I am doing - but it is very error
> prone, as I have to put this into numerous calculations (this is part
> of a simulation model).
>
> What I would like to do is tho change the default type from CELL to
> FCELL - i.e. whenever a new raster is created, it will *always* and
> *automatically* be saved in a FCELL raster, even if it only contains
> integer values, and not in a CELL raster.
>
> Cheers,
>
> Rainer
>
>
> >
> > Maxi
> >
> > On 01/10/2012 09:21 AM, Rainer M Krug wrote: -BEGIN PGP SIGNED
> > MESSAGE- Hash: SHA1
> >
> > Hi
> >
> > I have huge values in my raster cells and I am manually always
> > setting thrm to FCELL. Is there a possibility to instruct GRASS to
> > use FCELL (or DCELL) as a default instead of CELL?
> >
> > Thanks
> >
> > Rainer
> >
> >
> > - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc
> > (Conservation Biology, UCT), Dipl. Phys. (Germany)
> >
> > Centre of Excellence for Invasion Biology Stellenbosch University
> > South Africa
> >
> > Tel :   +33 - (0)9 53 10 27 44 Cell:   +33 - (0)6 85 62 59
> > 98 Fax :   +33 - (0)9 58 10 27 44
> >
> > Fax (D):+49 - (0)3 21 21 25 22 44
> >
> > email:  rai...@krugs.de
> >
> > Skype:  RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG
> > v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla -
> > http://enigmail.mozdev.org/
> >
> > iEYEARECAAYFAk8LP5AACgkQoYgNqgF2egqIMwCfeWPRNyLlu9ZamOmLcECGoisV
> > 81cAn0TBNu2YW7ugZ2o5eq/9XW6lvyV9 =eGtL -END PGP SIGNATURE-
> >> ___ grass-user
> >> mailing list grass-user@lists.osgeo.org
> >> http://lists.osgeo.org/mailman/listinfo/grass-user
> >>
> >
> >
>
> - --
> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
> Biology, UCT), Dipl. Phys. (Germany)
>
> Centre of Excellence for Invasion Biology
> Stellenbosch University
> South Africa
>
> Tel :   +33 - (0)9 53 10 27 44
> Cell:   +33 - (0)6 85 62 59 98
> Fax :   +33 - (0)9 58 10 27 44
>
> Fax (D):+49 - (0)3 21 21 25 22 44
>
> email:  rai...@krugs.de
>
> Skype:  RMkrug
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk8MKiUACgkQoYgNqgF2egqmOQCfR0VP+5VYGRK0r6ePFxIZ+Oa1
> snQAnRLfyjq9JJFwZzAhDZuEoGA7x1s6
> =vCXE
> -END PGP SIGNATURE-
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Set default cell type to FCELL?

[Paulo van Breugel]

Yes, also check the manual for r.mapcalc (e.g.
http://grass.fbk.eu/gdp/html_grass64/r.mapcalc.html), it is described there
somewhere I think


On Tue, Jan 10, 2012 at 3:23 PM, Rainer M Krug  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/01/12 13:17, Paulo van Breugel wrote:
> > When you include in any one of your multiplication a number with
> > at least one decimal your result should be a floating raster.
> > Perhaps not
>
> so
>
> oldmap * 1
>
> results in a raster of the same type as oldmap,
>
> where
>
> oldmap * 1.0
>
> would result in a FCELL?
>
> > as easy as what you are asking for, but it shouldn't be too error
> > prone, should it?
>
> In principal not - but I have to check the whole simulation.
>
> Thanks,
>
> Rainer
>
>
> >
> > Paulo
> >
> >
> > On Tue, Jan 10, 2012 at 3:08 PM, Rainer M Krug  > <mailto:r.m.k...@gmail.com>> wrote:
> >
> > On 10/01/12 12:50, Massimiliano Cannata wrote:
> >> Hi, not sure to have understood what you want to do but maybe
> >> using r.mapcalc functions: - double(x)   --> convert x to
> >> double-precision floating point - float(x)   -->convert
> >> x to single-precision floating point
> >
> > Sorry for not being more clear.
> >
> > What you suggest is exactly what I am doing - but it is very error
> > prone, as I have to put this into numerous calculations (this is
> > part of a simulation model).
> >
> > What I would like to do is tho change the default type from CELL
> > to FCELL - i.e. whenever a new raster is created, it will *always*
> > and *automatically* be saved in a FCELL raster, even if it only
> > contains integer values, and not in a CELL raster.
> >
> > Cheers,
> >
> > Rainer
> >
> >
> >
> >> Maxi
> >
> >> On 01/10/2012 09:21 AM, Rainer M Krug wrote: -BEGIN PGP
> >> SIGNED MESSAGE- Hash: SHA1
> >
> >> Hi
> >
> >> I have huge values in my raster cells and I am manually always
> >> setting thrm to FCELL. Is there a possibility to instruct GRASS
> >> to use FCELL (or DCELL) as a default instead of CELL?
> >
> >> Thanks
> >
> >> Rainer
> >
> >
> >> - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc
> >> (Conservation Biology, UCT), Dipl. Phys. (Germany)
> >
> >> Centre of Excellence for Invasion Biology Stellenbosch
> >> University South Africa
> >
> >> Tel :   +33 - (0)9 53 10 27 44 Cell:   +33 - (0)6 85 62
> >> 59 98 Fax :   +33 - (0)9 58 10 27 44
> >
> >> Fax (D):+49 - (0)3 21 21 25 22 44
> >
> >> email:  rai...@krugs.de <mailto:rai...@krugs.de>
> >
> >> Skype:  RMkrug
>
> > ___ grass-user mailing
> > list grass-user@lists.osgeo.org
> > <mailto:grass-user@lists.osgeo.org>
> > http://lists.osgeo.org/mailman/listinfo/grass-user
> >
> >
>
> - --
> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
> Biology, UCT), Dipl. Phys. (Germany)
>
> Centre of Excellence for Invasion Biology
> Stellenbosch University
> South Africa
>
> Tel :   +33 - (0)9 53 10 27 44
> Cell:   +33 - (0)6 85 62 59 98
> Fax :   +33 - (0)9 58 10 27 44
>
> Fax (D):+49 - (0)3 21 21 25 22 44
>
> email:  rai...@krugs.de
>
> Skype:  RMkrug
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk8MLcIACgkQoYgNqgF2egoSMQCePKxF92PrrqiAwqo2OLmlthyf
> NkgAnjfdAf6dx1lz02Rnyu4g5gkPUZi3
> =HmpG
> -END PGP SIGNATURE-
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Voting for GRASS community promotion at gis.stackexchange.com

[Paulo van Breugel]

Six votes now :-)

On Sat, Mar 17, 2012 at 11:30 AM, Nikos Alexandris
wrote:

> Markus Neteler:
> ...
> > I have uploaded the GRASS Logo to get it advertised on this GOS forum:
> > http://gis.stackexchange.com/
> >
> > To make it visible, we need to obtain at least six "up" votes on the
> > GRASS logo at:
> >
> http://meta.gis.stackexchange.com/questions/540/community-promotion-ads-2012
>
> GRASSers,
>
> we need at least one more vote! Let's go for it :-)
>
> Greets, Nikos
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Unable to get rid of duplicate polygons

[Paulo van Breugel]

Keeping both attributes would make sense in many cases of overlapping 
polygons, which, I would guess, is more often about partly overlapping 
polygons due to sloppy digitizing. How is GRASS going to tell what 
feature is more important?


But, in case of duplicate rows in your attribute table, except for the 
cat, you might be able to remove the duplicate rows in the attribute 
table using a simple SQL statement (not sure this works if you use dbf 
as database backend), something along the lines of (google if this 
doesn't work).


DELETE FROM table WHERE cat NOT IN
(SELECT MIN(cat) FROM table GROUP BY XXX);

Whereby XXX would be column with unique values mapping unit (if there is 
not such column, you need to GROUP on a set of columns that together 
uniquely define each mapping unit). You can do this in the db.execute. 
Alternatively, you can use the SELECT statement in the advanced SQL 
query builder in the GRASS Attribute Table Manager to select the 
duplicates and delete them there.


If you use the dbf as database backend and the above doesn't work, you 
can open the dbf file (which you can find in the 'GRASS DB / LOCATION/ 
MAPSET /dbf' folder) in Libreoffice and select all duplicates and 
delete, e.g., using a pivot table. Do not use excel, in my experience 
that may mess up your dbf file.


In all cases, this is just to remove rows that are identical except for 
one column... you'll have to test whether the results make sense in your 
case and you are not messing up your polygon layer.





On 04/02/2012 09:09 PM, David J. Bakeman wrote:

Markus Metz wrote:
On Sun, Apr 1, 2012 at 11:45 PM, David J. 
Bakeman  wrote:

David J. Bakeman wrote:

Markus Neteler wrote:
On Sun, Apr 1, 2012 at 9:45 PM, David J. 
Bakeman

  wrote:

I didn't find an answer in the archives so.

I have a shapefile of polygons and some of the polygons are 
duplicated.

  I
thought I could use v.clean tool=rmdupl to get rid of these 
polygons.  I

use
v.in.ogr to read it in and I get the following:

WARNING: 8 areas represent more (overlapping) features, because 
polygons
  overlap in input layer(s). Such areas are linked to 
more than 1
  row in attribute table. The number of features for 
those areas

is
  stored as category in layer 2

That is correct in that there are 8 duplicate polygons but the only
different attribute is the cat which grass added?  What am I 
missing?  I
then tried v.clean tool=bpol,rmdupl and nothing changes it still 
has the

8
duplicates.  What am I doing wrong?

I think that you need to add the break tool for v.clean.

Correct that was actually what I was using:  v.clean tool=break,rmdupl

Looking closer I see that when I run v.clean it doesn't even report 
the
duplicates that v.in.ogr did but they are still there.  The only 
thing that
differs in coordinates or attributes is the cat attribute that 
grass added.

I am using grass 6.3.0 on fedora core 14 linux.

Please note that you can upgrade to grass-6.4.0-4.fc14:
http://koji.fedoraproject.org/koji/buildinfo?buildID=263115

Thanks I'll see if I can upgrade.
I upgraded to the 6.4.0 and the results are exactly the same.  The 
polygons
really are identical in every respect except for they have different 
values
in the cat column.  Is there some other grass tool for removing this 
kind of

duplicate?

After import with v.in.ogr, there are no duplicate geometries left in
the vector. What you have now is some areas with two categories
assigned to them. Removing the duplicates means in this case removing
one of the two categories, for example with one of the vector
digitizers.
I'm relatively new to grass but that doesn't make sense.  I started 
with a shapefile with duplicate features.  That is polygons with the 
exact same attributes and geometry (they are identical).  What I 
thought grass could do for me was to read it in and delete one of the 
duplicates without user intervention.  After all it identifies the 
duplicates so why can't it delete one?


Are you saying that the duplicate geometry was deleted but it kept 
both rows even though they were identical as well?  Is there a 
operation that would identify and delete rows that differ in only the 
cat attribute.

Markus M



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


You can use
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Unable to get rid of duplicate polygons

[Paulo van Breugel]

Ah, that is of course true. It would be nice if one had the option to 
remove the category value from the geometries when deleting the category 
value in the table (I guess there would be disadvantages too, perhaps 
the implementation).


But where I got confused is that when I import a vector layer with 
overlapping polygons, I indeed get the message that "The number of 
features for those areas is stored as category in layer 2" as you 
mention below. However, when in the attribute table manager I do not see 
a second layer. Am I overlooking something or is this some bug?



Paulo




On 04/04/2012 09:34 AM, Markus Metz wrote:

There seems to be some confusion here about what v.in.ogr does or does
not and the relation of attributes to geometries.

v.in.ogr does not remove duplicate polygons, it does not even check
for duplicate polygons, and most importantly it keeps (should keep)
all polygons present in the input layer(s) and represents them as
topological areas composed from boundaries. In case of overlapping
polygons, the overlapping parts are marked as such by assigning
multiple categories to them, one for each original polygon.
Additionally, The number of features for those areas is stored as
category in layer X, X being a number reported by v.in.ogr. In order
to get rid of duplicate polygons, one of the categories needs to be
removed from the corresponding area. AFAICT, this needs to be done
manually with one of the vector digitizers.

Deleting a row in the attribute table does not delete the
corresponding geometry or geometries, or to be more precise, the
corresponding category value from geometries. Likewise, deleting a
geometry does not necessarily delete the corresponding entry (entries)
in the attribute table.

Markus M


On Mon, Apr 2, 2012 at 10:11 PM, Paulo van Breugel
  wrote:

Keeping both attributes would make sense in many cases of overlapping
polygons, which, I would guess, is more often about partly overlapping
polygons due to sloppy digitizing. How is GRASS going to tell what feature
is more important?

But, in case of duplicate rows in your attribute table, except for the cat,
you might be able to remove the duplicate rows in the attribute table using
a simple SQL statement (not sure this works if you use dbf as database
backend), something along the lines of (google if this doesn't work).

DELETE FROM table WHERE cat NOT IN
(SELECT MIN(cat) FROM table GROUP BY XXX);

Whereby XXX would be column with unique values mapping unit (if there is not
such column, you need to GROUP on a set of columns that together uniquely
define each mapping unit). You can do this in the db.execute. Alternatively,
you can use the SELECT statement in the advanced SQL query builder in the
GRASS Attribute Table Manager to select the duplicates and delete them
there.

If you use the dbf as database backend and the above doesn't work, you can
open the dbf file (which you can find in the 'GRASS DB / LOCATION/ MAPSET
/dbf' folder) in Libreoffice and select all duplicates and delete, e.g.,
using a pivot table. Do not use excel, in my experience that may mess up
your dbf file.

In all cases, this is just to remove rows that are identical except for one
column... you'll have to test whether the results make sense in your case
and you are not messing up your polygon layer.





On 04/02/2012 09:09 PM, David J. Bakeman wrote:

Markus Metz wrote:

On Sun, Apr 1, 2012 at 11:45 PM, David J. Bakeman
wrote:


David J. Bakeman wrote:


Markus Neteler wrote:


On Sun, Apr 1, 2012 at 9:45 PM, David J. Bakeman
   wrote:


I didn't find an answer in the archives so.

I have a shapefile of polygons and some of the polygons are duplicated.
   I
thought I could use v.clean tool=rmdupl to get rid of these polygons.  I
use
v.in.ogr to read it in and I get the following:

WARNING: 8 areas represent more (overlapping) features, because polygons
   overlap in input layer(s). Such areas are linked to more than 1
   row in attribute table. The number of features for those areas
is
   stored as category in layer 2

That is correct in that there are 8 duplicate polygons but the only
different attribute is the cat which grass added?  What am I missing?  I
then tried v.clean tool=bpol,rmdupl and nothing changes it still has the
8
duplicates.  What am I doing wrong?


I think that you need to add the break tool for v.clean.


Correct that was actually what I was using:  v.clean tool=break,rmdupl

Looking closer I see that when I run v.clean it doesn't even report the
duplicates that v.in.ogr did but they are still there.  The only thing that
differs in coordinates or attributes is the cat attribute that grass added.


I am using grass 6.3.0 on fedora core 14 linux.


Please note that you can upgrade to grass-6.4.0-4.fc14:
http://koji.fedoraproject.org/koji/buildinfo?buildID=263115


Thanks I'll see if I can upgrade.


I upgraded to the 6.4.0 and the results are exact

Re: [GRASS-user] Re: [GRASS-dev] getting from DBF to SQLite

[Paulo van Breugel]

You can define the SQLite database yourself with db.connect. The 
database does only contain the attribute data, no geometric information, 
so you could define the same SQLite database for different mapsets and 
even locations. I tried this actually out some time ago, and it worked 
for me at the time. You can easily try out yourself, but see my next point.


Whether that is a smart thing to do is another point. Depending on how 
you set up your GRASS database, you might end up having layers with the 
same name in different mapsets or locations. In that case, you will run 
into trouble; you can't have more then one table with the same name in 
your SQLite database. I would therefore recommend having one SQLite 
database per mapset. There are also plans for a SQLite database per 
layer. I am not sure what would be the advantage of that though.


I am not sure about your second question, but GRASS 7 uses the SQLite 
database by default.


Paulo



On 04/09/2012 09:04 AM, Micha Silver wrote:

On 09/04/2012 09:47, RichardC wrote:

Hi,

I'm also planning to move from the DBF to SQLite database, and was wondering
if you might be able to help with the following.

Is it is possible to set a single SQLite database for the entire GRASS GIS
database or each mapset requires its own sqlite db file?


I'm pretty sure it's per mapset.
Have a look at this nice summary blog post about db connections (from 
2009, but still accurate)

http://casoilresource.lawr.ucdavis.edu/drupal/node/733

Currently, I'm using v6.4.2 which uses DBF by default. Is there a command
that can switch the installation to using SQLite as the default, so that
mapsets in subsequently created locations will use Sqlite? Or I need to
reconfigure the installation (i.e., the ./configure options prior to
make/make install)?

Thanks,
Richard

--
View this message in 
context:http://osgeo-org.1560.n6.nabble.com/getting-from-DBF-to-SQLite-tp4657601p4715248.html
Sent from the Grass - Users mailing list archive at Nabble.com.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

This mail was received via Mail-SeCure System.






--
Micha Silver
052-3665918


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


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

Re: [GRASS-user] v.to.rast in grass70

[Paulo van Breugel]

I can confirm there are issues in how GRASS 7 handles region settings. 
In my case, when using v.to.rast, the region settings are reset to the 
default, i.e., the raster is converted using the default region settings 
rather then the current. I am now at revision 51177. In a previous 
revision (51117)  I had a problem with region settings when using 
r.patch, see Ticket #1636  (http://trac.osgeo.org/grass/ticket/1636). 
These issues seem to be independend of the mapset (it happens in both 
PERMANENT and other mapsets).


Paulo



On 04/09/2012 08:44 AM, Pankaj Kr Sharma wrote:

Dear Grass users and developers,

I just noticed that in grass70 , the v.to.rast module changes 
computational region / current region

resolution to the display extent and resolution after finishing.

My maps are in "PERMANENT" mapset. And, I have tried a number of 
options , but cannot reset the resolution of raster thus created to 
the required resolution.


Thanks.


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


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

Re: [GRASS-user] help..

[Paulo van Breugel]

Some problem how gdal links to PROJ.4 I think? On Ubuntu, you should 
find the file in /usr/lib/, but this might be different in other OS. It 
might be useful to report What OS you are using, and how you did install 
gdal and proj4.




On 04/26/2012 06:34 PM, Albert Saribekyan wrote:






Albert Saribekyan.

I want to input a gif file in my GRASS location and there is a such error

GRASS 6.4.2RC2 (example):/ > r.in.gdal 
input=/home/albert.saribekyan/geo/geosample-02.gif output=raster 
location=example
r.in.gdal: error while loading shared libraries: libproj.so.0: cannot 
open shared object file: No such file or directory

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


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

Re: [GRASS-user] opening dbf tables

[Paulo van Breugel]

Why would you not want to open the dbh file in Libreoffice calc? It 
works fine for me. Unless you are working with datasets of over 1 
miljoen records, the maximum rows in Calc.


I have not clue about the error message, but what if you try to open it 
directly from the Open file menu in LibreOffice (or any other software 
you prefer)?


An alternative option might be opening the shapefile in QGIS. In QGIS it 
is easy to make changes in your attribute table (the dbf file). And if 
you need to change columns (delete, move, rename), you can use the Table 
manager plugin for QGIS. As a bonus, you can directly import the file 
afterwards in your GRASS database from within QGIS using the GRASS 
toolbox in QGIS.


Cheers,

Paulo




On 05/18/2012 06:12 PM, John Ortiz wrote:


Is your error produced by libreOffice?

I can guess that the problem is because you are trying to open a .dbf 
file with libreoffice calc, that is the default application in Ubuntu 
12.04 to open this sort of files.


To open .dbf files you should use libreoffice base. this application 
not is included in Ubuntu, you must to install the packages previously.


sudo apt-get install libreoffice-base

I hope this help you..  I had the same problem when I updated my 
Ubuntu version.


Regards,


John Ortiz
Smithsonian Tropical Research Institute
Panama





Date: Fri, 18 May 2012 17:07:46 +0200
From: rice...@palombini.net
To: grass-user@lists.osgeo.org
Subject: [GRASS-user] opening dbf tables


Dear all,
as i'm not very used used to work on vector files i don't know how to 
manage a (probably) simple problem.


i'm working on some shapefiles to be imported in Grass, but before 
doing so i should modify the dbf table. When trying to open it (Ubuntu 
12.04), i got the message

(in italian)
errore generale
errore generale di I/O
i wasn't able to pen the table even by command line (sudo) nor found 
any hidden lock file in the directory.

Any suggestion?

Thanks a lot
Augusto

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



This body part will be downloaded on demand.


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

[GRASS-user] GRASS GIS graphical modeller - use overwrite flag

[Paulo van Breugel]

Hi,

I am experimenting with the GRASS graphical modeller in GRASS 7.0 and I 
am wondering where / how to set the 'overwrite' flag in e.g. the r.mask 
function.


There does not seem to be an option to set this flag and adding 
'--overwrite' to the command line under the 'item' tab does not seem to 
do anything.


Any ideas?

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

[GRASS-user] GRASS Graphical Modeller - using loops

[Paulo van Breugel]

Hi,

I am experimenting with the GRASS graphical modeller in GRASS 7.0 (on 
Ubuntu 12.04). I would like to create a mask in a loop, whereby the 
input 'maskcats' is dynamic. I.e., I would like to do something similar 
to the script below:


for i in { 1 .. 5 }
do
  r.mask input=inputmap maskcats=$i
  other commands...
done

From the tutorials, I can see how to create dynamic loops with raster 
or vector layers as input, but I cannot find how to do this with integer 
values as input.


Cheers,

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

Re: [GRASS-user] r.cross problems when overlaying layers with no-data

[Paulo van Breugel]

I am submitting this as a bug report, as I probably should have done to 
start with




On 06/13/2012 10:59 AM, Paulo van Breugel wrote:

Hi

When overlaying two layers that contain large areas of 'no data', 
r.cross seems to run forever. Running an equally large areas without 
'no data' is no problem on the other hand.


I tried to run r.cross for a much smaller area and the problem seems 
to be that r.cross assigns some random value to areas with no-data, 
even when using the -z flag. See the output of r.what for a point 
where both input layers have no data:


/r.what --v -f -n input=wdpaPNV@ConsStat 
coordinates=1549281.412639,-1312241.263941

easting|northing|site_name|wdpaPNV@ConsStat|wdpaPNV@ConsStat_label
1549281.412639|-1312241.263941||_30114_|no data; no data/

Attached see also a screen shot, with the no-data area with seemingly 
random pattern of colors.


Paulo


I am using GRASS GIS 7.0 on Ubuntu 12.04


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

Re: [GRASS-user] Add up several maps, which hold different regions, with mapcalc

[Paulo van Breugel]

First set the region to fit all maps, like suggested by Marcello. Then, 
use r.patch to combine the maps.


Cheers,

Paulo



On 06/18/2012 01:36 PM, Marcello Gorini wrote:

Büro Seling said:


My problem begins, when I now try to add up all these single maps
into one larger map.
I searched for a solution and tried several things, but nothing
worked.

Any tipps or hinds?



Hey,

As always, there is probably a much more elegant solution to this 
problem, but this should get you going for now:


>  g.region 
rast=map1,map2   
# just to make sure your region encompass everything
> r.mapcalc 
"bigmap=if(isnull(map1),9,map1)+if(inull(map2),9,map2)"   
# replace nulls on the fly by a specific value that your data does not 
contain
> r.mapcalc 
"bigmap=if(bigmap==9,null(),bigmap)"
# put back the nulls


Well, ugly like all my codes, but it works.

Cheers,
Marcello.





This body part will be downloaded on demand.


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

Re: [GRASS-user] Set fixed seed for r.random?

[Paulo van Breugel]

+1 for that suggestion. In r.random.cells it is already possible to set 
a fixed seed.


Paulo


On 07/03/2012 02:13 PM, Johannes Radinger wrote:

Hi,

is it possible to set a fixed seed for r.random so that the output is 
reproducible? I am not familiar with the coding behind r.random but maybe it is 
possible to add that feature also to be set optionally by the user...

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



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

Re: [GRASS-user] change sqlite.db problems

[Paulo van Breugel]

If you go to the mapset directory itself, check the file 'VAR' (it is 
just a plain text file). Are the database path and name defined 
correctly  in that file?


Rgds,

Paulo


On 07/13/2012 04:12 PM, Johannes Radinger wrote:

Hi,

I just had to move some locations from one machine to another machine.
I was able to open the locations on the new computer (GRASS 6.4.3 and Ubuntu) 
and then I realized that I somehow set the database connection to a hardcoded 
directory on the old computer. Thus I just used db.connect to set a new link 
(sqlite) to: '$GISDBASE/$LOCATION_NAME/$MAPSET/sqlite.db'. But somehow that 
doesn't work.
I tried to use db.test (with test1) but it says that its not possible to open 
the database, although it is existing. I tried to see the attribute table in 
WXGUI but then all windows get closed (GRASS crash)...It seems that somehow the 
database can be connected properly after the move to the new machine...

any suggestions?

What Is the best way to reset the database without destroying it...?

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



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

Re: [GRASS-user] Fwd: Re: R + grass7

[Paulo van Breugel]

Hi,

You can find a list of changes in option settings and names here: 
http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures#Renamedoptions


Cheers,

Paulo



On 08/29/2012 02:50 PM, Helmut Kudrnovsky wrote:
fyi a question regarding an "translation" (flags,parameter) table 
between grass6x and grass7.


Helmut

 Original-Nachricht 
Datum: Wed, 29 Aug 2012 14:35:37 +0200 (CEST)
Von: Roger Bivand
An: Helmut Kudrnovsky
Betreff: Re: R + grass7

On Wed, 29 Aug 2012, Helmut Kudrnovsky wrote:

> Dear Roger,
>
> I'm trying to improve the GRASS GIS-R-coupling on windows
> (http://trac.osgeo.org/grass/ticket/1149). 


>
> May I ask you if spgrass6
> (http://cran.at.r-project.org/web/packages/spgrass6/index.html) 
 
is GRASS

> GIS 7-aware.

Yes, the description on:

http://cran.r-project.org/web/packages/spgrass6/index.html 



uses "6+" to signal that subsequent versions are intended to work. Since
the package only uses system(), it will work as long as
--interface-description returns an XML file. Plenty of examples and
scripts stop working because GRASS 6 and 7 modules have different flags
and/or parameter names, but in principle only for that reason. It's hard
for me to check - it would be useful to have a translation table for flag
and parameter names by module where changes have occurred.

Best wishes,

Roger

--
Roger Bivand
Department of Economics, NHH Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.



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


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

[GRASS-user] new wxGUI feature: Map Swipe

[Paulo van Breugel]

Hi Anna

This looks like a very useful tool, and it works perfectly (running 
grass 7 on Ubuntu 12.04), thanks!


If I may make a feature request. Would it be very difficult to implement 
an option where rather then splitting the area between the two maps, the 
same area is shown for both maps (i.e., mirrored maps). In that option, 
moving one map would move the other map too. This makes it easier to see 
changes between two maps in detail. In case my explanation isn't clear, 
a nice example is the MIrrorMap plug-in for QGIS.


Cheers,

Paulo




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

Re: [GRASS-user] new wxGUI feature: Map Swipe

[Paulo van Breugel]

Synchronized display sums it up nicely :-)



On 08/31/2012 11:27 AM, Anna Kratochvílová wrote:

Hi,

On Fri, Aug 31, 2012 at 11:07 AM, Paulo van Breugel
 wrote:

Hi Anna

This looks like a very useful tool, and it works perfectly (running grass 7
on Ubuntu 12.04), thanks!

If I may make a feature request. Would it be very difficult to implement an
option where rather then splitting the area between the two maps, the same
area is shown for both maps (i.e., mirrored maps). In that option, moving
one map would move the other map too. This makes it easier to see changes
between two maps in detail. In case my explanation isn't clear, a nice
example is the MIrrorMap plug-in for QGIS.


Seems clear to me. I added it to map swipe wiki page, you can edit it.
I remember someone on mailing list was asking about similar
functionality - synchronize display region extent of more Map Displays
- could it be what you mean?

Thanks for your interest,
Anna



Cheers,

Paulo






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

Re: [GRASS-user] new wxGUI feature: Map Swipe

[Paulo van Breugel]

I am also just asking... contributing code is unfortunately way out of 
my league.


I am somewhat indifferent to whether synchronized display of multiple 
maps would be a general feature of map display or part of the swipe 
tool. I can imagine that it would be easier to make it initially part of 
a separate tool, but I am no developer so I could be completely wrong.


Cheers

Paulo



On 08/31/2012 11:56 AM, Moritz Lennert wrote:

On 31/08/12 11:27, Anna Kratochvílová wrote:

Hi,

On Fri, Aug 31, 2012 at 11:07 AM, Paulo van Breugel
  wrote:

Hi Anna

This looks like a very useful tool, and it works perfectly (running 
grass 7

on Ubuntu 12.04), thanks!

If I may make a feature request. Would it be very difficult to 
implement an
option where rather then splitting the area between the two maps, 
the same
area is shown for both maps (i.e., mirrored maps). In that option, 
moving
one map would move the other map too. This makes it easier to see 
changes

between two maps in detail. In case my explanation isn't clear, a nice
example is the MIrrorMap plug-in for QGIS.


Seems clear to me. I added it to map swipe wiki page, you can edit it.
I remember someone on mailing list was asking about similar
functionality - synchronize display region extent of more Map Displays
- could it be what you mean?


http://trac.osgeo.org/grass/ticket/1669

I'm not sure that this should be part of the swipe tool. I'd rather 
see this as a general feature of Map Displays, i.e. the option to 
linked any number of Map Displays so that when you pan / zoom in one 
the other(s) adjust automagically. Then again, I'm only the one 
asking, not doing ... ;-)


Moritz


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

Re: [GRASS-user] v.distance anything to anything

[Paulo van Breugel]

+ Great improvement

On Sat, Oct 13, 2012 at 3:51 PM, Markus Metz
wrote:

> In GRASS7, v.distance can now calculate distances from
> point,line,boundary,centroid,area to
> point,line,boundary,centroid,area.
>
> In GRASS 6, v.distance can calculate distances only from
> point,centroid to point,line,boundary,centroid,area.
>
> Markus M
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] bigTIFF file input

[Paulo van Breugel]

Hi,

Did you build gdal from source? When you compile gdal with internal libtiff
or with libtiff >= 4.0, GDAL should supports reading and writing BigTIFF
files (evolution of the TIFF format to support files larger than 4 GB).

You should also enable big file support when compiling grass I think, which
you can set with ./configure --enable-largefile

If you use the default gdal install, it might not support big files. This
is for example the case in Ubuntu (I think, didn't check with 12.04
though). In that case you might want to compile gdal from source.

Cheers,

Paulo



On Tue, Oct 16, 2012 at 4:37 PM, Albert Saribekyan <
albertsaribek...@rambler.ru> wrote:

>
>
>
>
>
> Albert Saribekyan.
>
>>
>>  Hi all,
> I tryed to import a geotiff file with size of 6 GB and there are a
> following error
>   GRASS 7.0.svn (example):~ > r.in.gdal input=/localuser/albert/test_**1.tif
> output=test_1 location=test1
> ERROR 4: This is a BigTIFF file.  BigTIFF is not supported by this
> version of GDAL and libtiff.
>
> could you help me please..
> regards.
> __**_
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/**mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Grass-GIS 7 first impressions

[Paulo van Breugel]

Concerning the boundaries rendering too thick; under GUI settings (menu:
settings - preferences) under the tab 'Map display', you can set the
Display driver from Cairo (the default I think) to png. That will bring you
back to thinner lines.

I was going to answer that there was an option to disable anti-alias, but I
can't find that option. But I guess that is what Cairo display is doing;
anti-aliasing the lines.

As for the g.copy problem with selecting multiple maps, I can confirm that
doesn't work. Sounds like a bug to me, perhaps you can file a bug report?

Cheers,

Paulo


On Thu, Oct 18, 2012 at 11:02 AM, Richard Chirgwin  wrote:

>  I'm late coming to Grass-GIS 7.0. Partly, this is because I'm also not
> enthusiastic about migrating all my stuff to a new OS that I don't need.
>
> However, I decided to run up Debian in a VM and give it a spin.
>
> My very first observation relates to the Python interface: compared to
> either the old TCL-TK or the former d.mon X11, boundaries render too thick.
> It's an aesthetic issue only, but I've worked with people who are willing
> to fight for their desired "look" practically to the death. Examples are
> included and I hope they survived intact.
>
> TCL
>
>
> Python:
>
>
> Second, Python selection panels, for modules that should allow multiple
> selections, work badly.
>
> For example, g.copy. In the TCL-TK interface, I can use g.copy for
> multiple copies. OK, I usually use the command-line anyhow, but: If I
> attempt a second selection in the Python interface pane, it replaces the
> first selection instead of adding to it.
>
> I'll continue fooling around with 7.0 and hope nobody - particularly our
> ever-helpful Markus and the rest of the development team - think I'm being
> deliberately critical. I've been a user of Grass-GIS for six years now, and
> it's an indispensable part of my professional life. (I recently saw a
> company devote two weeks - I am not kidding - of ESRI temporary employee
> time doing stuff in the GUI that a competent Grass-GIS user would complete
> in hours, using v.distance and some database updates. The non-GIS manager
> simply didn't believe my time estimate, even after a demo. "No, we'll spend
> $4k on what we know.").
>
> Cheers,
> Richard C
>
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] use of grass 6.4 and 7 on the same location/mapsets

[Paulo van Breugel]

If you are in 6.4 and want to open a vector layer created in grass 7 (or
the other way around), you can use v.build.

Alternatively, you can also open the layer, and in the layer manager, right
click the layer and select 'rebuild topology'. Rebuilding is very quick in
my experience and hasn't give me any trouble, whether rebuilding  from 6.4
to 7 or the other way around.

Cheers,

Paulo



On Mon, Oct 29, 2012 at 12:24 PM, Nick Cahill  wrote:

> I found that once I'd converted my vectors to Grass 7, I couldn't go back.
> I ended up going back to 6.4 and having to restore old vectors from a
> backup. It was a pain. Is there an easy way to convert back?
>
> Thanks,
>
> Nick Cahill
>
>
> On Oct 29, 2012, at 11:59 AM, Maris Nartiss wrote:
>
> > If they are not accessed at a same time, then only problem will be
> > with vector data. GRASS 7 uses a bit different vector data storage
> > format and thus vector data can be used (displayed) only after a
> > v.build run. It's a bit annoying and I don't know if it can introduce
> > any problems (I mean when going G7->G6 vectors), still I haven't
> > observed any.
> >
> > In conclusion - for raster - doesn't matter; vectors - better stick to
> > one version.
> >
> > Maris.
> >
> > 2012/10/28 Laura Poggio :
> >> Dear list,
> >> are any problems in having mapsets accessed from different version of
> GRASS
> >> (6.4.2. and 7)?
> >>
> >> Thank you
> >>
> >> Laura
> >>
> >>
> >> ___
> >> grass-user mailing list
> >> grass-user@lists.osgeo.org
> >> http://lists.osgeo.org/mailman/listinfo/grass-user
> >>
> > ___
> > grass-user mailing list
> > grass-user@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/grass-user
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Calculate p value for regression slope in r.series

[Paulo van Breugel]

Hi,

I am using r.series to calculate linear regression slope, offset and
coefficient of determination. But any idea how I can get the standard
deviation t-value and p-value of the slope?

Cheers,

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

Re: [GRASS-user] Calculate p value for regression slope in r.series

[Paulo van Breugel]

OK, thanks for the info.


On Wed, Nov 7, 2012 at 9:45 AM, Markus Neteler  wrote:

> On Tue, Nov 6, 2012 at 9:55 AM, Paulo van Breugel
>  wrote:
> > Hi,
> >
> > I am using r.series to calculate linear regression slope, offset and
> > coefficient of determination. But any idea how I can get the standard
> > deviation t-value and p-value of the slope?
>
> It is not yet implemented... suggestions where to find an existing
> C implementation which could be "recycled" (i.e. be GPL compliant)
> are welcome.
>
> Markus
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Calculate p value for regression slope in r.series

[Paulo van Breugel]

I have not clue about C programming, but could there be anything in the Gnu
Scientific Library (GSL - http://www.gnu.org/software/gsl/)? See also this
question on StackOverflow:
http://stackoverflow.com/questions/5503733/getting-p-value-for-linear-regression-in-c-gsl-fit-linear-function-from-gsl-li

Cheers,

Paulo


On Wed, Nov 7, 2012 at 9:53 AM, Paulo van Breugel wrote:

> OK, thanks for the info.
>
>
> On Wed, Nov 7, 2012 at 9:45 AM, Markus Neteler  wrote:
>
>> On Tue, Nov 6, 2012 at 9:55 AM, Paulo van Breugel
>>  wrote:
>> > Hi,
>> >
>> > I am using r.series to calculate linear regression slope, offset and
>> > coefficient of determination. But any idea how I can get the standard
>> > deviation t-value and p-value of the slope?
>>
>> It is not yet implemented... suggestions where to find an existing
>> C implementation which could be "recycled" (i.e. be GPL compliant)
>> are welcome.
>>
>> Markus
>>
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Calculate p value for regression slope in r.series

[Paulo van Breugel]

Good suggestion, and coincidentally I was just looking at it. Am I correct
to assume that to mimic the calculation of slope etc in r.series, I would
need to create a second time series of 'dummy' maps with values 0 for first
time period, 1 for second time period, etc.? I did this in R and it gave
the same slope and offset as r.series.

Just wondering, if it is implemented in r.regression.series, would it be
very difficult to port to r.series? Or do the two things function different
internally?

Cheers,

Paulo



On Thu, Nov 8, 2012 at 10:55 AM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

> On 06/11/12 09:55, Paulo van Breugel wrote:
>
>> Hi,
>>
>> I am using r.series to calculate linear regression slope, offset and
>> coefficient of determination. But any idea how I can get the standard
>> deviation t-value and p-value of the slope?
>>
>
> Try MarkusN's r.regression.series in the addons for grass7. It allows the
> calculation of t and f values. IIRC, p-value can be calculated from t-value.
>
> Moritz
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user