Re: [GRASS-user] Create location fails in docker

[Margherita Di Leo]

[RESOLVED]

Simply the docker machine was deployed with changes I was unaware of. Sorry
for the noise and thank you so much for the brainstorming.

On Thu, Sep 30, 2021 at 2:34 PM Margherita Di Leo 
wrote:

> Hi Moritz,
>
> On Thu, Sep 30, 2021 at 10:49 AM Moritz Lennert <
> mlenn...@club.worldonline.be> wrote:
>
>> Hi Madi,
>>
>> Am 30.09.2021 09:46 schrieb Margherita Di Leo:
>> >
>> >> PermissionError: [Errno 13] Permission denied: '/.grass7'
>> >
>> > What does this error message mean? Why is it trying to write in the
>> > /.grass7 folder ?
>>
>> Whenever you launch GRASS GIS with the grass startup script, it writes
>> the chosen Gisdbase/Location/Mapset info into .grass7/rc. If you launch
>> GRASS GIS for the first time, it first creates the directory .grass7
>> which is the part that fails with a permission error.
>>
>> But isn't .grass7/rc folder supposed to be written in the home directory?
> In my docker image I set the user and a home directory is created for it...
>
>
>> I'm no Docker expert at all, but I think you have to explicitly run the
>> container with parameters indicating the devices one can access from
>> within.
>>
>
> I'm trying to figure... I set a workdir and give full permissions to the
> user to it, but still the .grass7 folder is not written there nor in the
> home. Is there a way to "force" the grass configuration files to be written
> somewhere else?
>
> Thanks,
>
>
> --
> Margherita Di Leo
>


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

Re: [GRASS-user] Create location fails in docker

[Margherita Di Leo]

Hi Moritz,

On Thu, Sep 30, 2021 at 10:49 AM Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

> Hi Madi,
>
> Am 30.09.2021 09:46 schrieb Margherita Di Leo:
> >
> >> PermissionError: [Errno 13] Permission denied: '/.grass7'
> >
> > What does this error message mean? Why is it trying to write in the
> > /.grass7 folder ?
>
> Whenever you launch GRASS GIS with the grass startup script, it writes
> the chosen Gisdbase/Location/Mapset info into .grass7/rc. If you launch
> GRASS GIS for the first time, it first creates the directory .grass7
> which is the part that fails with a permission error.
>
> But isn't .grass7/rc folder supposed to be written in the home directory?
In my docker image I set the user and a home directory is created for it...


> I'm no Docker expert at all, but I think you have to explicitly run the
> container with parameters indicating the devices one can access from
> within.
>

I'm trying to figure... I set a workdir and give full permissions to the
user to it, but still the .grass7 folder is not written there nor in the
home. Is there a way to "force" the grass configuration files to be written
somewhere else?

Thanks,


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

Re: [GRASS-user] Create location fails in docker

[Margherita Di Leo]

Hi again,

I try to reformulate my question:

On Wed, Sep 29, 2021 at 9:32 PM Margherita Di Leo 
wrote:

>
> grass --text -c EPSG:4326 $GRASSDATA\/france -e
>
> The error message:
>
> Traceback (most recent call last):
>   File "/usr/bin/grass", line 390, in get_grass_config_dir
> os.mkdir(directory)
> PermissionError: [Errno 13] Permission denied: '/.grass7'
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>   File "/usr/bin/grass", line 2218, in 
> main()
>   File "/usr/bin/grass", line 2001, in main
> grass_config_dir = get_grass_config_dir()
>   File "/usr/bin/grass", line 395, in get_grass_config_dir
> _("Failed to create configuration directory '%s' with error: %s")
> NameError: name '_' is not defined
> Traceback (most recent call last):
>   File "/usr/bin/grass", line 390, in get_grass_config_dir
> os.mkdir(directory)
> PermissionError: [Errno 13] Permission denied: '/.grass7'
>
> What does this error message mean? Why is it trying to write in the
/.grass7 folder ? And what does the name '_' refer to?

Thanks for any pointers

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

[GRASS-user] Create location fails in docker

[Margherita Di Leo]

Hi,

I need to run GRASS in a docker image but I have issues apparently about
permissions.

My docker image is built on a dockerfile:


FROM ubuntu:20.04

ENV DEBIAN_FRONTEND noninteractive

ENV DATA_DIR /data

RUN apt-get update \
&& apt-get install -y --no-install-recommends --no-install-suggests \
build-essential \
libblas-dev \
libbz2-dev \
libcairo2-dev \
libfftw3-dev \
libfreetype6-dev \
libgdal-dev \
libgeos-dev \
libglu1-mesa-dev \
libgsl0-dev \
libjpeg-dev \
liblapack-dev \
libncurses5-dev \
libnetcdf-dev \
libopenjp2-7 \
libopenjp2-7-dev \
libpdal-dev pdal \
libpdal-plugin-python \
libpng-dev \
libpq-dev \
libproj-dev \
libreadline-dev \
libsqlite3-dev \
libtiff-dev \
libxmu-dev \
libzstd-dev \
bison \
flex \
g++ \
gettext \
gdal-bin \
grass \
grass-core \
grass-dev \
libfftw3-bin \
make \
ncurses-bin \
netcdf-bin \
proj-bin \
proj-data \
python3 \
python3-dev \
python3-geopandas \
python3-numpy \
python3-pandas \
python3-pil \
python3-ply \
python3-six \
sqlite3 \
subversion \
unixodbc-dev \
zlib1g-dev \
&& apt-get autoremove \
&& apt-get clean && \
mkdir -p $DATA_DIR

ENV SHELL /bin/bash

# permissions
RUN chmod -R a+rwx $DATA_DIR

# create user
RUN useradd -m -U digitranscope

VOLUME $DATA_DIR
WORKDIR $DATA_DIR

# switch user
USER digitranscope

CMD ["grass", "--version"]



Then, from a bash script I try to create a location and exit, but it seems
to fail on this:

grass --text -c EPSG:4326 $GRASSDATA\/france -e

The error message:

Traceback (most recent call last):
  File "/usr/bin/grass", line 390, in get_grass_config_dir
os.mkdir(directory)
PermissionError: [Errno 13] Permission denied: '/.grass7'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/grass", line 2218, in 
main()
  File "/usr/bin/grass", line 2001, in main
grass_config_dir = get_grass_config_dir()
  File "/usr/bin/grass", line 395, in get_grass_config_dir
_("Failed to create configuration directory '%s' with error: %s")
NameError: name '_' is not defined
Traceback (most recent call last):
  File "/usr/bin/grass", line 390, in get_grass_config_dir
os.mkdir(directory)
PermissionError: [Errno 13] Permission denied: '/.grass7'

What could be the problem?

Thanks in advance

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

Re: [GRASS-user] Reclassify a vector adding a column

[Margherita Di Leo]

Super! Thank you both!

On Wed, Jun 17, 2020 at 9:12 PM Micha Silver  wrote:

>
> On 17/06/2020 19:38, Margherita Di Leo wrote:
>
> Dear Micha,
>
> On Wed, Jun 17, 2020 at 4:05 PM Micha Silver  wrote:
>
>>
>> On 17/06/2020 16:14, Margherita Di Leo wrote:
>>
>> Ciao Stefan,
>>
>> thank you, I tried and it didn't give me any error but didn't update the
>> column either...
>>
>>
>>
>> The sqlite CASE statement should be:
>>
>> CASE  WHEN '' THEN '' WHEN ''
>> THEN ''END;
>>
>>
>> Here's an example that worked for me. I have a "myroads" vector with
>> column 'TYPE'
>>
>>
>> # Add new column for road width as text
>>
>> v.db.addcolumn myroads column="width TEXT"
>>
>> # Run update with CASE
>>
>> db.execute sql="UPDATE myroads SET width=CASE TYPE WHEN 'Main' THEN
>> 'Wide' WHEN 'Local' THEN 'Narrow' ELSE 'Unknown' END;"
>>
>>
>> Best, Micha
>>
> This worked! Thank you so much! I have one last question. Does it also
> support an IS LIKE condition, and if yes, how can I express it?
>
>
> Yes, sqlite supports LIKE, for example:
>
>
> micha@tp480:scripts$ db.select sql='SELECT TYPE,LENGTH FROM roads WHERE
> TYPE LIKE "%Ma%";'
> TYPE|LENGTH
> Main|1.542641
> Main|4.346567
> Main|1.382557
> Main|1.120805
> Main|1.117633
> Main|0.13777
> 
>
>
> Thanks!
>
>
> --
> Margherita Di Leo
>
> --
> Micha Silver
> Ben Gurion Univ.
> Sde Boker, Remote Sensing Lab
> cell: +972-523-665918https://orcid.org/-0002-1128-1325
>
>

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

Re: [GRASS-user] Reclassify a vector adding a column

[Margherita Di Leo]

Dear Micha,

On Wed, Jun 17, 2020 at 4:05 PM Micha Silver  wrote:

>
> On 17/06/2020 16:14, Margherita Di Leo wrote:
>
> Ciao Stefan,
>
> thank you, I tried and it didn't give me any error but didn't update the
> column either...
>
>
>
> The sqlite CASE statement should be:
>
> CASE  WHEN '' THEN '' WHEN ''
> THEN ''END;
>
>
> Here's an example that worked for me. I have a "myroads" vector with
> column 'TYPE'
>
>
> # Add new column for road width as text
>
> v.db.addcolumn myroads column="width TEXT"
>
> # Run update with CASE
>
> db.execute sql="UPDATE myroads SET width=CASE TYPE WHEN 'Main' THEN 'Wide'
> WHEN 'Local' THEN 'Narrow' ELSE 'Unknown' END;"
>
>
> Best, Micha
>
This worked! Thank you so much! I have one last question. Does it also
support an IS LIKE condition, and if yes, how can I express it?

Thanks!


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

Re: [GRASS-user] Reclassify a vector adding a column

[Margherita Di Leo]

Ciao Stefan,

thank you, I tried and it didn't give me any error but didn't update the
column either...

On Wed, Jun 17, 2020 at 12:16 PM Stefan Blumentrath <
stefan.blumentr...@nina.no> wrote:

> Ciao Madi,
>
>
>
> You could use db.execute and do something like:
>
> db.execute sql="ALTER TABLE vectormap ADD COLUMN reclass_column TEXT;
>
> UPDATE vectormap SET reclass_column = CASE
>
>  WHEN old_column = ' old value 1' THEN ' new value 1'
>
>  WHEN old_column = ' old value 2' THEN ' new value 2'
>
>  WHEN old_column = ' old value 3' THEN ' new value 3'
>
>  ELSE ' new value 4'
>
> END; "
>
>
>
> Maybe worth adding as an (validated) example to the manual of db.execute (
> https://grass.osgeo.org/grass78/manuals/db.execute.html)…
>
>
>
> Cheers
>
> Stefan
>
>
>
> P.S.: I did not alidate the SQL syntax, but it should be roughly along
> those lines…
>
>
>
> *From:* grass-user  *On Behalf Of 
> *Margherita
> Di Leo
> *Sent:* onsdag 17. juni 2020 10:35
> *To:* GRASS user list 
> *Subject:* [GRASS-user] Reclassify a vector adding a column
>
>
>
> Hi,
>
>
>
> I need to reclassify a vector in the following way: based on a column of
> type string I have to create a new column of type string based on certain
> rules that I give upon the first column, and I thought it would be really
> handy if I could do it like  CASE WHEN... THEN ...
>
> I have tried to feed a similar rules file to v.reclass but this statement
> is not recognised. How can I translate it? Furthermore, I would like to be
> able to just add a reclass column rather than creating a new vector file,
> is that possible? How?
>
>
>
> Thank you in advance
>
>
>
> Kind regards,
>
>
> --
>
> Margherita Di Leo
>


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

[GRASS-user] Reclassify a vector adding a column

[Margherita Di Leo]

Hi,

I need to reclassify a vector in the following way: based on a column of
type string I have to create a new column of type string based on certain
rules that I give upon the first column, and I thought it would be really
handy if I could do it like  CASE WHEN... THEN ...
I have tried to feed a similar rules file to v.reclass but this statement
is not recognised. How can I translate it? Furthermore, I would like to be
able to just add a reclass column rather than creating a new vector file,
is that possible? How?

Thank you in advance

Kind regards,

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

Re: [GRASS-user] about r.threhold

[Margherita Di Leo]

Dear Rengifo Ortega,

On Thu, Jun 11, 2020 at 1:08 PM Rengifo Ortega  wrote:

> Dear Grass community
>
> First of all thanks for this great piece of  software such  as GRASS GIS!
> Recently I have been using  the  r.threshold module to extract a  river
> networks at different  DTM resolutions and different areal extent. I
> noticed that   r.threshold values varies widely as a function DEM
> resolution and extent of watershed (areal extent). So , I have some
> questions, and hope someone in the community can shed some light on them.
>
> Looking at the description of the module  it says : "This approach
> provides a *best guess *about what makes sense when looking only at the
> DEM"
>
>  Question 1: means   that the results of the r.threshold module will
> depend on the resolution and  the extent of the watershed?
>
> Looking  at the source code, I  realised that r.threshold used r.stats to
> generate a flowacc  text.file ordered in ascendent order and put into a
> matrix called  mappatella, with 3 columns defined as:
>
> *mappatella is a matrix, in the first column the value of upslope area is
> stored, *
>
>
> *in the second the number of cells, in the third the distance from origin
> is calculated*
>
> further in the script the distance is defined as :
>
>
> *calculating distance from origin of each point; origin of the plot is in
> low left point *
>
>
> Question 2 : which is the origin?  is the center  of  a cell  of the
> corner of a cell?
> Question 3: which plot? and why  the low left point of the plot?
>
>  Although I understand the general aspect  of the module I still struggle
> to understand its details. I would appreciate some explanation to crarify
> it further, since I  am using it as part of workflow within  GRASS GIS to
> produce inputs to a Distance Distribution Dynamics( DDD) model for urban
> enviroments.
> https://onlinelibrary.wiley.com/doi/full/10.1002/hyp.10315?casa_token=ETYV_ojgMb4A%3AMWgGgX_jqbylpF6pHLoafciVZrlmCBiLCmxb7gRpsCV1F3SY7QQmOkBOIrhLzhj5BFCDSLobabm7Xw
>
>
Thank you for your interest in r.threshold. It's been written some time ago
but the principle is the following: in order to find the point "where the
stream begins" you can look at where you have an abrupt change in the slope
and flow accumulation increases. In order to do that, you can plot slope
and flow accumulation in a graph and pick the point that is the closest to
the origin. This is a very naive and preliminary guess but somehow allows
to start from a plausible value in order to find a better threshold.

Hope this helps

Kind regards,




Any help would be appreciated.
>  Thanks in advance !
>
> Best regards
> Rengifo Ortega
>
>
>
>
>
>
>
>

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

Re: [GRASS-user] r.basin not running completely

[Margherita Di Leo]

On Sat, Apr 25, 2020 at 9:39 AM jomaljochan 
wrote:

> Hi,
> Thank you for your interest and time!
>
> I had created a whole new location and ran the code only once. And it is
> still showing the same. Moreover, the file in question is nowhere to be
> found.
>
> Is there any other possibility?
>

(sorry, again I had accidentally excluded the list from cc)
Maybe try giving it a different prefix and a different folder where to
write the output
Hope this helps

>
>
>
> margherita wrote
> > cc list
> >
> > On Sat, Apr 25, 2020 at 9:11 AM Margherita Di Leo 
>
> > diregola@
>
> > 
> > wrote:
> >
> >> Hi,
> >>
> >> On Sat, Apr 25, 2020 at 8:49 AM jomaljochan 
>
> > jochanjomal1998@
>
> > 
> >> wrote:
> >>
> >>> Hi, I am a new GRASS GIS User (using GRASS GIS 7.6.1) trying to get the
> >>> morphometric parameters of a watershed(Bhadra river basin, India).
> >>> Steps followed:
> >>> 1) Cropped and set the DEM file in UTM projection.
> >>> 2) Created a new location and used the georeferenced DEM file to set
> the
> >>> projection of GRASS Session.
> >>> 3) Ran the following lines of code:
> >>>
> >>>   g.region rast=elevation@PERMANENT -ap
> >>>
> >>>   r.watershed -a elevation=elevation@PERMANENT accumulation=accum
> >>>
> >>>   r.stream.extract elevation=elevation@PERMANENT accumulation=accum
> >>> threshold=1000
> >>>   stream_rast=stream_network stream_vect=streams --overwrite
> >>>   #(overwrite with different threshold until clear network)
> >>>
> >>>   #Find the coordinates of the outlet from network and input in r.basin
> >>> fn
> >>>
> >>>   r.basin map=elevation@PERMANENT prefix=out
> >>> coordinates=572957.585125,1547823.44718
> >>>   threshold=20 dir=tmp/my_basin
> >>>
> >>>
> >>>
> >>> The function stops running with the following error:
> >>>
> >>>   ERROR: option
> > 
> > : tmp/my_basin\out_elevation_outlet_coors.txt
> >>> exists. To overwrite, use the
> >>>   --overwrite flag
> >>>
> >>>   --------------
> >>>
> >>>   An ERROR occurred running r.basin
> >>>   Please check for error messages above or try with another pairs of
> >>> outlet
> >>> coordinates
> >>>   Removing region definition
> > 
> >>>
> >>> The command is telling you that an output with the same name is already
> >> there. You need to delete it* and run the command again.
> >>
> >> *Sorry r.basin doesn't handle overwrite, as written in the manual.
> >>
> >> Hope this helps.
> >>
> >> Kind regards,
> >>
> >>
> >> --
> >> Margherita Di Leo
> >>
> >
> >
> > --
> > Margherita Di Leo
> >
> > ___
> > grass-user mailing list
>
> > grass-user@.osgeo
>
> > https://lists.osgeo.org/mailman/listinfo/grass-user
>
>
>
>
>
> --
> 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



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

Re: [GRASS-user] r.basin not running completely

[Margherita Di Leo]

cc list

On Sat, Apr 25, 2020 at 9:11 AM Margherita Di Leo 
wrote:

> Hi,
>
> On Sat, Apr 25, 2020 at 8:49 AM jomaljochan 
> wrote:
>
>> Hi, I am a new GRASS GIS User (using GRASS GIS 7.6.1) trying to get the
>> morphometric parameters of a watershed(Bhadra river basin, India).
>> Steps followed:
>> 1) Cropped and set the DEM file in UTM projection.
>> 2) Created a new location and used the georeferenced DEM file to set the
>> projection of GRASS Session.
>> 3) Ran the following lines of code:
>>
>>   g.region rast=elevation@PERMANENT -ap
>>
>>   r.watershed -a elevation=elevation@PERMANENT accumulation=accum
>>
>>   r.stream.extract elevation=elevation@PERMANENT accumulation=accum
>> threshold=1000
>>   stream_rast=stream_network stream_vect=streams --overwrite
>>   #(overwrite with different threshold until clear network)
>>
>>   #Find the coordinates of the outlet from network and input in r.basin fn
>>
>>   r.basin map=elevation@PERMANENT prefix=out
>> coordinates=572957.585125,1547823.44718
>>   threshold=20 dir=tmp/my_basin
>>
>>
>>
>> The function stops running with the following error:
>>
>>   ERROR: option : 
>> exists. To overwrite, use the
>>   --overwrite flag
>>
>>   --
>>
>>   An ERROR occurred running r.basin
>>   Please check for error messages above or try with another pairs of
>> outlet
>> coordinates
>>   Removing region definition 
>>
>> The command is telling you that an output with the same name is already
> there. You need to delete it* and run the command again.
>
> *Sorry r.basin doesn't handle overwrite, as written in the manual.
>
> Hope this helps.
>
> Kind regards,
>
>
> --
> Margherita Di Leo
>


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

Re: [GRASS-user] Area between drainage networks

[Margherita Di Leo]

Hi Luis,

Not sure I understand, but What if you draw a large polygon that covers both 
rivers, then you clip against the rivers and calculate the area of the 
resulting polygon. Does that help?

Kind regards,

Inviato da iPhone

> Il giorno 20 dic 2019, alle ore 16:40, Luis Moreira  
> ha scritto:
> 
> Hello everyone, 
> 
> I'd like to obtain the area between two drainage networks. The difference
> between them is due to different calculation methods. 
> 
> 
>  
> The image above illustrates the methodology of mesuring the "error" between
> two drainage networks.
> 
> Each one of the drainage networks is in a shapefile, and I need the sum of
> all the areas between the segments of the drainage networks, so that I can
> mesure the difference between them.
> 
> How could I do that with GRASS?
> 
> Thanks in advance.
> 
> 
> 
> 
> 
> --
> 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] sample a strds at specific locations (areas)

[Margherita Di Leo]

OK it took me some time but I think I figured things out. The problem was
the weird topology of the input vector file (created outside grass by
another person). One record in the table would correspond to more than one
polygons, and this somehow created problems. I solved exporting the vector
to geopackage and then import again and I got a much longer table
associated, now one record per polygon.
Thanks

On Fri, Sep 6, 2019 at 10:53 AM Margherita Di Leo 
wrote:

> Please ignore my last email, this is not the case, I had vectors with
> similar names in the current mapset. Sorry for confusion. Still struggling
> on this.
>
> On Wed, Sep 4, 2019 at 12:01 PM Margherita Di Leo 
> wrote:
>
>> Hi,
>>
>> I have an update on this. It seems to work if the vector file resides in
>> the same mapset! I g.copied big_areas2@PERMANENT to current mapset and
>> the excluded polygons are much less. It surely needs further
>> investigation...
>>
>> Kind regards,
>>
>> On Fri, Aug 9, 2019 at 4:50 PM Margherita Di Leo 
>> wrote:
>>
>>> Hi,
>>>
>>> excuse me if I return on this. I have again the same problem, of v.strds
>>> .stats skipping lots of polygons. Now I'm using a brand new dataset -
>>> strds of Sentinel 1 and a brand now vector of polygons - and the skipped
>>> polygons are not narrow, I'm sure that there are cells centroids in it. See
>>> for example screenshot attached, depicting a polygon that was skipped. I
>>> also tried to run v.strds.stats on that polygon alone, like:
>>>
>>> v.strds.stats in=big_areas2@PERMANENT where="cat == '1'"
>>> strds=db_cross_pol@scaled out=test method=average
>>>
>>> v.info test
>>>
>>>  
>>> ++
>>>  | Name:test
>>>  |
>>>  | Mapset:  stats
>>>   |
>>>  | Location:S1
>>>  |
>>>  | Database:/media/madi/TOSHIBA EXT/S1/grassdata
>>>  |
>>>  | Title:   Output from v.patch
>>>   |
>>>  | Map scale:   1:1
>>>   |
>>>  | Name of creator: madi
>>>  |
>>>  | Organization:
>>>  |
>>>  | Source date: Fri Aug  9 12:12:49 2019
>>>  |
>>>  | Timestamp (first layer): none
>>>  |
>>>
>>>  
>>> ||
>>>  | Map format:  native
>>>  |
>>>
>>>  
>>> ||
>>>  |   Type of map: vector (level: 2)
>>>   |
>>>  |
>>>  |
>>>  |   Number of points:   0   Number of centroids:  0
>>>  |
>>>  |   Number of lines:0   Number of boundaries: 0
>>>  |
>>>  |   Number of areas:0   Number of islands:0
>>>  |
>>>  |
>>>  |
>>>  |   Map is 3D:  No
>>>   |
>>>  |   Number of dblinks:  0
>>>  |
>>>  |
>>>  |
>>>  |   Projection: UTM (zone 34)
>>>  |
>>>  |
>>>  |
>>>  |   N: 0S: 0
>>>   |
>>>  |   E: 0W: 0
>>>   |
>>>  |
>>>  |
>>>  |   Digitization threshold: 0
>>>  |
>>>  |   Comment:
>>>   |
>>>  |
>>>  |
>>>
>>>  
>>> ++
>>>
>>> I confess I hadn't look much further into it because I thought it was a
>>> problem with nodata, but this is not the case and I think it's  worth of
>>> further investigation. Thanks for any pointers.
>>>
>>> Regards,
>>>
>>>
>>> On Thu, Feb 7, 2019 at 4:10 PM Margherita Di Leo 
>>> wrote:
>>>
>>>> Thanks for testing, Vero. I assume it's due to a local problem then.
>>>>
>>>> Cheers,
>>>>
>>>> On Thu, Feb 7, 2019 at 3:29 PM Veronica Andreo 
>>>> wrote:
>>>>
>>>>> Hi Stefan and Madi,
>>>>>
>>>>> Thanks Stefan for the explanations :) Indeed I agree that a flag to
>>>>> avoid the alignment to input rasters (and ju

Re: [GRASS-user] sample a strds at specific locations (areas)

[Margherita Di Leo]

Please ignore my last email, this is not the case, I had vectors with
similar names in the current mapset. Sorry for confusion. Still struggling
on this.

On Wed, Sep 4, 2019 at 12:01 PM Margherita Di Leo 
wrote:

> Hi,
>
> I have an update on this. It seems to work if the vector file resides in
> the same mapset! I g.copied big_areas2@PERMANENT to current mapset and
> the excluded polygons are much less. It surely needs further
> investigation...
>
> Kind regards,
>
> On Fri, Aug 9, 2019 at 4:50 PM Margherita Di Leo 
> wrote:
>
>> Hi,
>>
>> excuse me if I return on this. I have again the same problem, of 
>> v.strds.stats
>> skipping lots of polygons. Now I'm using a brand new dataset - strds of
>> Sentinel 1 and a brand now vector of polygons - and the skipped polygons
>> are not narrow, I'm sure that there are cells centroids in it. See for
>> example screenshot attached, depicting a polygon that was skipped. I also
>> tried to run v.strds.stats on that polygon alone, like:
>>
>> v.strds.stats in=big_areas2@PERMANENT where="cat == '1'"
>> strds=db_cross_pol@scaled out=test method=average
>>
>> v.info test
>>
>>  
>> ++
>>  | Name:test
>>  |
>>  | Mapset:  stats
>> |
>>  | Location:S1
>>  |
>>  | Database:/media/madi/TOSHIBA EXT/S1/grassdata
>>  |
>>  | Title:   Output from v.patch
>> |
>>  | Map scale:   1:1
>> |
>>  | Name of creator: madi
>>  |
>>  | Organization:
>>  |
>>  | Source date: Fri Aug  9 12:12:49 2019
>>  |
>>  | Timestamp (first layer): none
>>  |
>>
>>  
>> ||
>>  | Map format:  native
>>  |
>>
>>  
>> ||
>>  |   Type of map: vector (level: 2)
>> |
>>  |
>>  |
>>  |   Number of points:   0   Number of centroids:  0
>>  |
>>  |   Number of lines:0   Number of boundaries: 0
>>  |
>>  |   Number of areas:0   Number of islands:0
>>  |
>>  |
>>  |
>>  |   Map is 3D:  No
>> |
>>  |   Number of dblinks:  0
>>  |
>>  |
>>  |
>>  |   Projection: UTM (zone 34)
>>  |
>>  |
>>  |
>>  |   N: 0S: 0
>> |
>>  |   E: 0W:     0
>>     |
>>  |
>>  |
>>  |   Digitization threshold: 0
>>  |
>>  |   Comment:
>> |
>>  |
>>  |
>>
>>  
>> ++
>>
>> I confess I hadn't look much further into it because I thought it was a
>> problem with nodata, but this is not the case and I think it's  worth of
>> further investigation. Thanks for any pointers.
>>
>> Regards,
>>
>>
>> On Thu, Feb 7, 2019 at 4:10 PM Margherita Di Leo 
>> wrote:
>>
>>> Thanks for testing, Vero. I assume it's due to a local problem then.
>>>
>>> Cheers,
>>>
>>> On Thu, Feb 7, 2019 at 3:29 PM Veronica Andreo 
>>> wrote:
>>>
>>>> Hi Stefan and Madi,
>>>>
>>>> Thanks Stefan for the explanations :) Indeed I agree that a flag to
>>>> avoid the alignment to input rasters (and just use region settings) sounds
>>>> good.
>>>> I tested what Madi said, but cannot reproduce in the climate NC
>>>> location [0]. This is the command I used:
>>>>
>>>> v.strds.stats in=boundary_county where="cat == '261'" strds=tempmean
>>>> t_where="start_time >= '2012-01-01'" out=test
>>>>
>>>> to make it faster (it feels indeed kinda slow for the whole vector and
>>>> full time series), I selected only one polygon and a range of dates. I get
>>>> the table as expected while leaving methods by default.
>>>>
>>>> best,
>>>> Vero
>>>>
>>>> [0]
>>>> http://courses.ncsu.edu/mea592/common/media/02/nc_climate_spm_2000_2012.zip
>>>>
>>>>
>>>>
>>>>
>>>> El jue., 7 feb. 2019 a las 1

Re: [GRASS-user] sample a strds at specific locations (areas)

[Margherita Di Leo]

Hi,

I have an update on this. It seems to work if the vector file resides in
the same mapset! I g.copied big_areas2@PERMANENT to current mapset and the
excluded polygons are much less. It surely needs further investigation...

Kind regards,

On Fri, Aug 9, 2019 at 4:50 PM Margherita Di Leo  wrote:

> Hi,
>
> excuse me if I return on this. I have again the same problem, of v.strds.stats
> skipping lots of polygons. Now I'm using a brand new dataset - strds of
> Sentinel 1 and a brand now vector of polygons - and the skipped polygons
> are not narrow, I'm sure that there are cells centroids in it. See for
> example screenshot attached, depicting a polygon that was skipped. I also
> tried to run v.strds.stats on that polygon alone, like:
>
> v.strds.stats in=big_areas2@PERMANENT where="cat == '1'"
> strds=db_cross_pol@scaled out=test method=average
>
> v.info test
>
>  
> ++
>  | Name:test
>|
>  | Mapset:  stats
> |
>  | Location:S1
>|
>  | Database:/media/madi/TOSHIBA EXT/S1/grassdata
>|
>  | Title:   Output from v.patch
> |
>  | Map scale:   1:1
> |
>  | Name of creator: madi
>|
>  | Organization:
>|
>  | Source date: Fri Aug  9 12:12:49 2019
>|
>  | Timestamp (first layer): none
>|
>
>  
> ||
>  | Map format:  native
>|
>
>  
> ||
>  |   Type of map: vector (level: 2)
> |
>  |
>|
>  |   Number of points:   0   Number of centroids:  0
>|
>  |   Number of lines:0   Number of boundaries: 0
>|
>  |   Number of areas:0   Number of islands:0
>|
>  |
>|
>  |   Map is 3D:  No
> |
>  |   Number of dblinks:  0
>|
>  |
>|
>  |   Projection: UTM (zone 34)
>|
>  |
>|
>  |   N: 0S: 0
> |
>  |   E: 0W: 0
> |
>  |
>|
>  |   Digitization threshold: 0
>|
>  |   Comment:
> |
>  |
>|
>
>  
> ++
>
> I confess I hadn't look much further into it because I thought it was a
> problem with nodata, but this is not the case and I think it's  worth of
> further investigation. Thanks for any pointers.
>
> Regards,
>
>
> On Thu, Feb 7, 2019 at 4:10 PM Margherita Di Leo 
> wrote:
>
>> Thanks for testing, Vero. I assume it's due to a local problem then.
>>
>> Cheers,
>>
>> On Thu, Feb 7, 2019 at 3:29 PM Veronica Andreo 
>> wrote:
>>
>>> Hi Stefan and Madi,
>>>
>>> Thanks Stefan for the explanations :) Indeed I agree that a flag to
>>> avoid the alignment to input rasters (and just use region settings) sounds
>>> good.
>>> I tested what Madi said, but cannot reproduce in the climate NC location
>>> [0]. This is the command I used:
>>>
>>> v.strds.stats in=boundary_county where="cat == '261'" strds=tempmean
>>> t_where="start_time >= '2012-01-01'" out=test
>>>
>>> to make it faster (it feels indeed kinda slow for the whole vector and
>>> full time series), I selected only one polygon and a range of dates. I get
>>> the table as expected while leaving methods by default.
>>>
>>> best,
>>> Vero
>>>
>>> [0]
>>> http://courses.ncsu.edu/mea592/common/media/02/nc_climate_spm_2000_2012.zip
>>>
>>>
>>>
>>>
>>> El jue., 7 feb. 2019 a las 14:39, Margherita Di Leo ()
>>> escribió:
>>>
>>>> Thank you Stefan for your help! I figured what happens. v.strds.stats
>>>> with default method produces in my case a corrupted output, topology is
>>>> there but there's no table associated to it. If I specify method=average, I
>>>> do obtain the table, and the mystery is solved: some of the polygons fall
>>>> into a nodata (due to cloud mask). If anyone else can reproduce the
>>>> corrupted table issue, I can file a ticket for that.
>>>>
>>>> Thanks for help!
>>>> Regards,
>>>>
>>>> On Thu, Feb 7, 2019 at 12:33 PM Stefan Blumentrath <
>>>> stefan.blumentr...@nina.no> wrote:
>>>>
>>&g

Re: [GRASS-user] sample a strds at specific locations (areas)

[Margherita Di Leo]

Ciao Stefan,

v.category input=big_areas2@PERMANENT option=report
Layer/table: 1/big_areas2
type   countminmax
point  0  0  0
line   0  0  0
boundary   0  0  0
centroid 280  2265
area   0  0  0
face   0  0  0
kernel 0  0  0
all  280  2265

v.info test -t
nodes=0
points=0
lines=0
boundaries=0
centroids=0
areas=0
islands=0
primitives=0
map3d=0

thanks

On Fri, Aug 9, 2019 at 9:29 PM Stefan Blumentrath <
stefan.blumentr...@nina.no> wrote:

> Ciao Margherita,
>
>
>
> This is strange. The area (I assume it is an area though your image just
> shows the boundary) should definitely get rasterized and thus analysed in
> v.strds.stats.
>
>
>
> Can you post the output of:
>
> v.category input=big_areas2@PERMANENT option=report
>
> and
>
> v.info test -t ?
>
>
>
> I double-checked, and the possibility to rasterize also centroids is
> unfortunately not handed down to v.rast.stats (and moduls build ontop of
> that, like v.strds.stats). This should be done for GRASS version >= 7.6
> (e.g. by adding centroids to the default selection of types to rasterize in
> v.to.rast) and is probably worth a ticket.
>
>
>
> Cheers
>
> Stefan
>
>
>
> *From:* Margherita Di Leo 
> *Sent:* fredag 9. august 2019 16:51
> *To:* Veronica Andreo 
> *Cc:* Stefan Blumentrath ; grass-user <
> grass-user@lists.osgeo.org>
> *Subject:* Re: [GRASS-user] sample a strds at specific locations (areas)
>
>
>
> Hi,
>
>
>
> excuse me if I return on this. I have again the same problem, of v.strds.stats
> skipping lots of polygons. Now I'm using a brand new dataset - strds of
> Sentinel 1 and a brand now vector of polygons - and the skipped polygons
> are not narrow, I'm sure that there are cells centroids in it. See for
> example screenshot attached, depicting a polygon that was skipped. I also
> tried to run v.strds.stats on that polygon alone, like:
>
>
>
> v.strds.stats in=big_areas2@PERMANENT where="cat == '1'"
> strds=db_cross_pol@scaled out=test method=average
>
>
>
> v.info test
>
>  
> ++
>  | Name:test
>|
>  | Mapset:  stats
> |
>  | Location:S1
>|
>  | Database:/media/madi/TOSHIBA EXT/S1/grassdata
>|
>  | Title:   Output from v.patch
> |
>  | Map scale:   1:1
> |
>  | Name of creator: madi
>|
>  | Organization:
>|
>  | Source date: Fri Aug  9 12:12:49 2019
>|
>  | Timestamp (first layer): none
>|
>
>  
> ||
>  | Map format:  native
>|
>
>  
> ||
>  |   Type of map: vector (level: 2)
> |
>  |
>|
>  |   Number of points:   0   Number of centroids:  0
>|
>  |   Number of lines:0   Number of boundaries: 0
>|
>  |   Number of areas:0   Number of islands:0
>|
>  |
>|
>  |   Map is 3D:  No
> |
>  |   Number of dblinks:  0
>|
>  |
>|
>  |   Projection: UTM (zone 34)
>|
>  |
>|
>  |   N: 0S: 0
> |
>  |   E: 0W: 0
> |
>  |
>|
>  |   Digitization threshold: 0
>|
>  |   Comment:
> |
>  |
>|
>
>  
> ++
>
> I confess I hadn't look much further into it because I thought it was a
> problem with nodata, but this is not the case and I think it's  worth of
> further investigation. Thanks for any pointers.
>
>
>
> Regards,
>
>
>
>
>
> On Thu, Feb 7, 2019 at 4:10 PM Margherita Di Leo 
> wrote:
>
> Thanks for testing, Vero. I assume it's due to a local problem then.
>
>
>
> Cheers,
>
>
>
> On Thu, Feb 7, 2019 at 3:29 PM Veronica Andreo 
> wrote:
>
> Hi Stefan and Madi,
>
>
>
> Thanks Stefan for the explanations :) Indeed I agree that a flag to avoid
> the alignment to input rasters (and just use region settings) sounds good.
>
> I tested what Madi said, but cannot reproduce in the climate NC location
> [0]. This is the command I used:
>
>
>
> v.strds.stats in=boundary_county where="cat == '261'" strds

Re: [GRASS-user] sample a strds at specific locations (areas)

[Margherita Di Leo]

Ciao Vero,
indeed that was my first guess about the cause, I double checked but the
region is properly set.
Sorry for late answer, I'm travelling these days with bad to none internet
connection.

Thanks

On Mon, Aug 12, 2019 at 4:23 PM Veronica Andreo 
wrote:

> Ciao Madi,
>
> is the region properly set?
>
> @Stefan in this case, if the centroid only is rasterized, then stats will
> also belong to that pixel only? AFAIU, we don't want that, but stats for
> the area. Or rasterization of centroid would have a different effect?
>
> best,
> Vero
>
> El vie., 9 ago. 2019 a las 21:29, Stefan Blumentrath (<
> stefan.blumentr...@nina.no>) escribió:
>
>> Ciao Margherita,
>>
>>
>>
>> This is strange. The area (I assume it is an area though your image just
>> shows the boundary) should definitely get rasterized and thus analysed in
>> v.strds.stats.
>>
>>
>>
>> Can you post the output of:
>>
>> v.category input=big_areas2@PERMANENT option=report
>>
>> and
>>
>> v.info test -t ?
>>
>>
>>
>> I double-checked, and the possibility to rasterize also centroids is
>> unfortunately not handed down to v.rast.stats (and moduls build ontop of
>> that, like v.strds.stats). This should be done for GRASS version >= 7.6
>> (e.g. by adding centroids to the default selection of types to rasterize in
>> v.to.rast) and is probably worth a ticket.
>>
>>
>>
>> Cheers
>>
>> Stefan
>>
>>
>>
>> *From:* Margherita Di Leo 
>> *Sent:* fredag 9. august 2019 16:51
>> *To:* Veronica Andreo 
>> *Cc:* Stefan Blumentrath ; grass-user <
>> grass-user@lists.osgeo.org>
>> *Subject:* Re: [GRASS-user] sample a strds at specific locations (areas)
>>
>>
>>
>> Hi,
>>
>>
>>
>> excuse me if I return on this. I have again the same problem, of 
>> v.strds.stats
>> skipping lots of polygons. Now I'm using a brand new dataset - strds of
>> Sentinel 1 and a brand now vector of polygons - and the skipped polygons
>> are not narrow, I'm sure that there are cells centroids in it. See for
>> example screenshot attached, depicting a polygon that was skipped. I also
>> tried to run v.strds.stats on that polygon alone, like:
>>
>>
>>
>> v.strds.stats in=big_areas2@PERMANENT where="cat == '1'"
>> strds=db_cross_pol@scaled out=test method=average
>>
>>
>>
>> v.info test
>>
>>  
>> ++
>>  | Name:test
>>  |
>>  | Mapset:  stats
>> |
>>  | Location:S1
>>  |
>>  | Database:/media/madi/TOSHIBA EXT/S1/grassdata
>>  |
>>  | Title:   Output from v.patch
>> |
>>  | Map scale:   1:1
>> |
>>  | Name of creator: madi
>>  |
>>  | Organization:
>>  |
>>  | Source date: Fri Aug  9 12:12:49 2019
>>  |
>>  | Timestamp (first layer): none
>>  |
>>
>>  
>> ||
>>  | Map format:  native
>>  |
>>
>>  
>> ||
>>  |   Type of map: vector (level: 2)
>> |
>>  |
>>  |
>>  |   Number of points:   0   Number of centroids:  0
>>  |
>>  |   Number of lines:0   Number of boundaries: 0
>>  |
>>  |   Number of areas:0   Number of islands:0
>>  |
>>  |
>>  |
>>  |   Map is 3D:  No
>> |
>>  |   Number of dblinks:      0
>>  |
>>  |
>>  |
>>  |   Projection: UTM (zone 34)
>>  |
>>  |
>>  |
>>  |   N: 0S: 0
>> |
>>  |   E: 0W: 0
>> |
>>  |
>>  |
>>  |   Digitization threshold: 0
>>  |
>>  |   Comment:
>> |
>>  |
>>  |
>>
>>  
>> ++
>>
>> I confess I hadn't look much further into it because I thought it was a
>> problem with nodata, but this is not the case and I think it's  worth of
>> further investigation. Thanks for any pointers.
>>
>>
>>
>> Regards,
>>
>>
>>
>>
>

Re: [GRASS-user] sample a strds at specific locations (areas)

[Margherita Di Leo]

Hi,

excuse me if I return on this. I have again the same problem, of v.strds.stats
skipping lots of polygons. Now I'm using a brand new dataset - strds of
Sentinel 1 and a brand now vector of polygons - and the skipped polygons
are not narrow, I'm sure that there are cells centroids in it. See for
example screenshot attached, depicting a polygon that was skipped. I also
tried to run v.strds.stats on that polygon alone, like:

v.strds.stats in=big_areas2@PERMANENT where="cat == '1'"
strds=db_cross_pol@scaled out=test method=average

v.info test
 ++
 | Name:test
   |
 | Mapset:  stats
  |
 | Location:S1
   |
 | Database:/media/madi/TOSHIBA EXT/S1/grassdata
   |
 | Title:   Output from v.patch
  |
 | Map scale:   1:1
  |
 | Name of creator: madi
   |
 | Organization:
   |
 | Source date: Fri Aug  9 12:12:49 2019
   |
 | Timestamp (first layer): none
   |
 ||
 | Map format:  native
   |
 ||
 |   Type of map: vector (level: 2)
  |
 |
   |
 |   Number of points:   0   Number of centroids:  0
   |
 |   Number of lines:0   Number of boundaries: 0
   |
 |   Number of areas:0   Number of islands:0
   |
 |
   |
 |   Map is 3D:  No
  |
 |   Number of dblinks:  0
   |
 |
   |
 |   Projection: UTM (zone 34)
   |
 |
   |
 |   N: 0S: 0
  |
 |   E: 0W: 0
  |
 |
   |
 |   Digitization threshold: 0
   |
 |   Comment:
  |
 |
   |
 ++

I confess I hadn't look much further into it because I thought it was a
problem with nodata, but this is not the case and I think it's  worth of
further investigation. Thanks for any pointers.

Regards,


On Thu, Feb 7, 2019 at 4:10 PM Margherita Di Leo  wrote:

> Thanks for testing, Vero. I assume it's due to a local problem then.
>
> Cheers,
>
> On Thu, Feb 7, 2019 at 3:29 PM Veronica Andreo 
> wrote:
>
>> Hi Stefan and Madi,
>>
>> Thanks Stefan for the explanations :) Indeed I agree that a flag to avoid
>> the alignment to input rasters (and just use region settings) sounds good.
>> I tested what Madi said, but cannot reproduce in the climate NC location
>> [0]. This is the command I used:
>>
>> v.strds.stats in=boundary_county where="cat == '261'" strds=tempmean
>> t_where="start_time >= '2012-01-01'" out=test
>>
>> to make it faster (it feels indeed kinda slow for the whole vector and
>> full time series), I selected only one polygon and a range of dates. I get
>> the table as expected while leaving methods by default.
>>
>> best,
>> Vero
>>
>> [0]
>> http://courses.ncsu.edu/mea592/common/media/02/nc_climate_spm_2000_2012.zip
>>
>>
>>
>>
>> El jue., 7 feb. 2019 a las 14:39, Margherita Di Leo ()
>> escribió:
>>
>>> Thank you Stefan for your help! I figured what happens. v.strds.stats
>>> with default method produces in my case a corrupted output, topology is
>>> there but there's no table associated to it. If I specify method=average, I
>>> do obtain the table, and the mystery is solved: some of the polygons fall
>>> into a nodata (due to cloud mask). If anyone else can reproduce the
>>> corrupted table issue, I can file a ticket for that.
>>>
>>> Thanks for help!
>>> Regards,
>>>
>>> On Thu, Feb 7, 2019 at 12:33 PM Stefan Blumentrath <
>>> stefan.blumentr...@nina.no> wrote:
>>>
>>>> Hi Madi,
>>>>
>>>>
>>>>
>>>> With this combination (polygon size vs. raster resolution), the shape
>>>> of the polygons can be an issue (narrow areas that do not cover the center
>>>> of any pixel).
>>>>
>>>>
>>>>
>>>> Debugging should be simple with v.db.select or v.extract.
>>>>
>>>>
>>>>
>>>> Areas that did not get rasterized should be NULL in the column with
>>>> statistics computed with v.rast.stats.
>>>>
>>>>
>>>>
>>>> In verbose mode v.rast.stats (or probably even v.to.rast) should
>>>> probably give a more informative Warning message (e.g. listing categories
>>>> not rasterized). It also would help if you can rasterize the areas yourself
>>>> and provide a raster with categories as

Re: [GRASS-user] r.hazard.flood extension

[Margherita Di Leo]

On Fri, Jun 7, 2019 at 12:16 AM Markus Neteler  wrote:

> On Fri, May 24, 2019 at 6:36 PM Martin Landa 
> wrote:
> >
> > Hi,
> >
> > pá 24. 5. 2019 v 15:48 odesílatel Margherita Di Leo 
> napsal:
> > > as far as I remember, it worked only in projected coordinate system.
> >
> > 1) should be mentioned in manual at least
>
> +1 - TODO
>

Done

>
> > >> Traceback (most recent call last):
> > >> File "/home/lara/.grass7/addons/scripts/r.hazard.flood", line 145, in
> 
> > >> sys.exit(main())
> > >> File "/home/lara/.grass7/addons/scripts/r.hazard.flood", line 78, in
> main
> > >> resolution = (float(dict_region['nsres']) +
> float(dict_region['ewres']))/2
> > >> ValueError: invalid literal for float(): 0:00:00.17656
> >
> > 2) should faill more gracefully. LL location is not supported.
>
> https://github.com/OSGeo/grass-addons/pull/4


Thank you Markus.

Cheers,


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

Re: [GRASS-user] Question about isnull() in map algebra

[Margherita Di Leo]

On Thu, Jun 6, 2019 at 6:28 PM Markus Metz 
wrote:

> Hi Madi,
>
> On Thu, Jun 6, 2019 at 4:13 PM Margherita Di Leo 
> wrote:
> >
> > Hi,
> >
> > reading the training material here:
> http://training.gismentors.eu/grass-gis-irsae-winter-course-2018/units/23.html
> > I have a doubt. When cloud mask is applied to calculate NDVI
> >
> > t.rast.mapcalc input=b4,b8,cloud output=ndvi_cloud \
> > expression="if(isnull(cloud), null(), float(b8 - b4) / ( b8 + b4 ))" \
> > basename=ndvi_cloud nproc=3
> >
> > what happens if there is no cloud mask at all for a certain map? In this
> case NDVI should be taken as is. Instead, to my understanding, what happens:
> >
> > if(isnull(cloud), null()
> >
> > If cloud map is not found (meaning there is no cloud detected),
> isnull(cloud)=True, so the NDVI resulting map is null too. Please correct
> me if I'm wrong.
>
> the cloud masks are apparently created with "sentinel-cloud-mask.py" which
> requires an AOI vector as input, and a cloud mask is always generated: if
> there are no clouds or no cloud mask, only the AOI is used as mask.
>
> from a quick glance at "sentinel-cloud-mask.py"
>
> Markus M
>
> Thank you Markus!

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

[GRASS-user] Question about isnull() in map algebra

[Margherita Di Leo]

Hi,

reading the training material here:
http://training.gismentors.eu/grass-gis-irsae-winter-course-2018/units/23.html
I have a doubt. When cloud mask is applied to calculate NDVI

t.rast.mapcalc input=b4,b8,cloud output=ndvi_cloud
\expression="if(isnull(cloud), null(), float(b8 - b4) / ( b8 + b4 ))"
\basename=ndvi_cloud nproc=3

what happens if there is no cloud mask at all for a certain map? In this
case NDVI should be taken as is. Instead, to my understanding, what
happens:

if(isnull(cloud), null()

If cloud map is not found (meaning there is no cloud detected),
isnull(cloud)=True, so the NDVI resulting map is null too. Please correct
me if I'm wrong.

Thanks

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

Re: [GRASS-user] r.hazard.flood extension

[Margherita Di Leo]

Hi Lara,

as far as I remember, it worked only in projected coordinate system.

Hope this helps,
Kind regards,

On Fri, May 24, 2019 at 3:41 PM Lara DC  wrote:

> Dear users
> I am new with Grass. I am trying to use the r.hazard.flood extension but I
> get the following error:
>
> Traceback (most recent call last):
> File "/home/lara/.grass7/addons/scripts/r.hazard.flood", line 145, in
> 
> sys.exit(main())
> File "/home/lara/.grass7/addons/scripts/r.hazard.flood", line 78, in main
> resolution = (float(dict_region['nsres']) +
> float(dict_region['ewres']))/2
> ValueError: invalid literal for float(): 0:00:00.17656
>
> Any idea of what can be wrong?  my dem file (named fmosaic) is type
> raster, FCELL, 5099 rows 7647 columns, resolution: 0:00:00.17656
>
> I thougth it was probably a problem with the dem resolution (5 m) but I
> tried with another DEM with different resolution and get the same error
> warning.
>
> Hope to solve this!
>
> Lara
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user



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

Re: [GRASS-user] importing and cleaning overlapping polygons that are supposed to overlap

[Margherita Di Leo]

Ciao Vero,

shapefile is not a good choice in this case for exporting such geometry
because is not apt to store topological information. You may want to export
your dataset in a different format, e.g. geopackage.

Hope this helps,

On Tue, May 14, 2019 at 11:47 PM Veronica Andreo 
wrote:

> Hi all,
>
> I was working today with a very simple vector map which corresponds to
> clusters (circular polygons) that overlap and it is just fine that they
> overlap. So, i received a shapefile with 3 of these clusters. Two of them
> overlaped. When I import them into GRASS with v.import I get an extra
> centroid and area where 2 of the polygons overlap.
>
> Problem arises when I want to query a raster map with those polygons since
> originally the attribute table contained only 3 polygons (which is just
> fine). However, v.what.rast will only upload values for 2 of those three
> polygons because it finds 2 centroids with the same category, AFAIU.
>
> I tried with
>
> v.clean input=clusters output=clusters_clean1 tool=break,rmdupl,rmsa,rmdac
>
> and
>
> v.clean input=clusters type=centroid output=clusters_clean2 tool=rmdupl
>
> but nothing seemed to do the kind of cleaning I wanted. I ended up using
> brute force and removing the extra centroid manually in the GUI. That
> helped with v.what.rast (all cats in the attr table were updated) but part
> of the original and correct geometry was clearly gone. I am sure that's not
> the right combination nor the right way either.
>
> In the wiki [0], I only found this piece of text: "If the *input polygons
> have logical errors* You can investigate overlapping areas in the
> imported vector with 'd.vect
> <https://grass.osgeo.org/grass76/manuals/d.vect.html> yourmap type=area
> layer=2' (only overlapping areas have a category in layer 2 after import).
> Additionally you may show the centroids of layer=2 to easier find tiny
> overlapping areas with 'd.vect
> <https://grass.osgeo.org/grass76/manuals/d.vect.html> yourmap
> type=centroid layer=2'"
>
> However, it says nothing about how to proceed further as to keep correctly
> overlapping polygons, each with its own centroid and remove the duplicated
> ones that are generated when importing.
>
> Can someone please share the set of steps that should be followed in these
> cases? Maybe it's a silly question, but I'm more a raster person so I am
> very easily lost with vector issues.
>
> Thanks much in advance!
> Vero
>
> [0] https://grasswiki.osgeo.org/wiki/Vector_topology_cleaning
> ___________
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user



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

Re: [GRASS-user] create basins of similar area

[Margherita Di Leo]

Hi Martin,

On Fri, Apr 26, 2019 at 3:35 PM Martin Landa  wrote:

> Hi,
>
> čt 25. 4. 2019 v 20:14 odesílatel Ken Mankoff  napsal:
> > Maybe make basins with threshold an order of magnitude smaller. Then
> merge small areas to get your 4-5 km2 areas. Still not totally sure how
> this makes sense hydrologically.
>
> right, it doesn't make sense probably from hydrologic point of view.
> Let me explain reasoning. My colleagues are working on developing
> distributed event-based model for surface and subsurface runoff and
> erosion. We are working on experimental version which enables
> computation parallelization. In initial phase AOI is split into tiles.
> Instead of regular grid of tiles a basin-based tiles are used. This is
> reason why basins (defining tiles) should be of similar area size.
> Martin
>
>
I understand this is case study involves a vast area and editing basins
manually (merging adjacent basins) is out of the question, isn't it? If
this is the case, I would propose to prototype a procedure based on similar
geomorphological characteristics to determine the 'optimal' threshold for
clusters, being optimal the threshold that gives you the desired (range of)
basin size. Just thinking out loud here. The threshold is the cutoff of
upslope area draining in the outlet cell. For a fixed threshold values, you
will obtain basins that are similar in size in areas that have similar
geomorphological characteristics, e.g. slope. I would cluster areas with
similar range of slope values and calibrate a suitable threshold that gives
the desired basin area for each cluster. This looks like a lot of
prototyping work, however, if you make a first run with a tentative
threshold value, display the resulting basins and visually compare with
slope map you should get a rough idea of what to do with the slope ranges
already.

Hope this helps,


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

Re: [GRASS-user] r.width.funct in correct version

[Margherita Di Leo]

It should be fixed in r74157. Testing welcome.

Regards,

On Tue, Mar 5, 2019 at 12:04 PM Helmut Kudrnovsky  wrote:

> margherita wrote
> > Hi,
> >
> > I could not reproduce the error. To me the example just works, there are
> > only some deprecation warnings.
> >
> > r.width.funct map=dist2out image=test
> >  100%
> > Tot. cells 88407.0
> > Tot. area 8840700.0
> > Max distance 7714.591101
> > /usr/lib64/python2.7/site-packages/matplotlib/cbook.py:136:
> > MatplotlibDeprecationWarning: The WX backend is deprecated. It's untested
> > and will be removed in Matplotlib 2.2. Use the WXAgg backend instead. See
> > Matplotlib usage FAQ for more info on backends.
> >   warnings.warn(message, mplDeprecation, stacklevel=1)
> > ===
> > Width Function | quantiles
> > ===
> > 883 | 0.05
> > 1756 | 0.15
> > 2763 | 0.3
> > 3218 | 0.4
> > 3661 | 0.5
> > 4218 | 0.6
> > 4893 | 0.7
> > 5926 | 0.85
> > 6984 | 0.95
> >
> >
> > Done!
> >
> > Kind regards,
>
> tested here with
>
> GRASS Version: 7.4.2
>
> GRASS SVN revision: r73591
>
> Build date: 2018-10-23
>
> Build platform: x86_64-w64-mingw32
>
> GDAL: 2.3.2
>
> PROJ.4: 5.2.0
>
> GEOS: 3.7.0
>
> SQLite: 3.17.0
>
> Python: 2.7.14
>
> wxPython: 2.8.12.1
>
> Platform: Windows-7-6.1.7601-SP1 (OSGeo4W)
>
> ++
> r.width.funct --verbose map=dist2out@user1 image=C:\temp\baer\test.png
>
> ('Tot. cells', 88407.0)
> ('Tot. area', 8840700.0)
> ('Max distance', 7714.591101)
> Traceback (most recent call last):
>   File "C:\Users\KUDRNOVSKY\AppData\Roaming\GRASS7\addons/sc
> ripts/r.width.funct.py", line 135, in 
> sys.exit(main())
>   File "C:\Users\KUDRNOVSKY\AppData\Roaming\GRASS7\addons/sc
> ripts/r.width.funct.py", line 84, in main
> prc[0,0] , prc[0,1] = findint(kl,0.05) , 0.05
>   File "C:\Users\KUDRNOVSKY\AppData\Roaming\GRASS7\addons/sc
> ripts/r.width.funct.py", line 128, in findint
> z1, z2, f1, f2 = kl[int(Xf[0])][0], kl[int(Xf[0]-1)][0],
> kl[int(Xf[0])][1], kl[int(Xf[0]-1)][1]
> IndexError: invalid index to scalar variable.
> +
>
> still the same error
>
>
>
> -
> 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



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

Re: [GRASS-user] r.width.funct in correct version

[Margherita Di Leo]

Hi,

I could not reproduce the error. To me the example just works, there are
only some deprecation warnings.

r.width.funct map=dist2out image=test
 100%
Tot. cells 88407.0
Tot. area 8840700.0
Max distance 7714.591101
/usr/lib64/python2.7/site-packages/matplotlib/cbook.py:136:
MatplotlibDeprecationWarning: The WX backend is deprecated. It's untested
and will be removed in Matplotlib 2.2. Use the WXAgg backend instead. See
Matplotlib usage FAQ for more info on backends.
  warnings.warn(message, mplDeprecation, stacklevel=1)
===
Width Function | quantiles
===
883 | 0.05
1756 | 0.15
2763 | 0.3
3218 | 0.4
3661 | 0.5
4218 | 0.6
4893 | 0.7
5926 | 0.85
6984 | 0.95


Done!

Kind regards,


On Thu, Feb 21, 2019 at 1:04 PM Veronica Andreo 
wrote:

> I get the same error that Juan gets, both with his commands and with those
> in the example in the manual page (and both in grass76 and trunk).
>
> [omitting the rest for brevity]
>
> r.width.funct map=dist2out image=/tmp/my_basin
>  100%
> Tot. cells 88407.0
> Tot. area 8840700.0
> Max distance 7714.591101
> Traceback (most recent call last):
>   File "/home/veroandreo/.grass7/addons/scripts/r.width.funct", line 135,
> in 
> sys.exit(main())
>   File "/home/veroandreo/.grass7/addons/scripts/r.width.funct", line 84,
> in main
> prc[0,0] , prc[0,1] = findint(kl,0.05) , 0.05
>   File "/home/veroandreo/.grass7/addons/scripts/r.width.funct", line 128,
> in findint
> z1, z2, f1, f2 = kl[int(Xf[0])][0], kl[int(Xf[0]-1)][0],
> kl[int(Xf[0])][1], kl[int(Xf[0]-1)][1]
> IndexError: invalid index to scalar variable.
>
> No idea...
>
> Maybe Madi can help us out here :)
>
> Vero
>
> El jue., 21 feb. 2019 a las 11:37, Helmut Kudrnovsky ()
> escribió:
>
>> [keep the discussion always on the ML!]
>>
>> >Gesendet: Donnerstag, 21. Februar 2019 um 11:25 Uhr
>> >
>> >Von: "Juan Lopez" 
>> >An:
>> >Betreff: Re: [GRASS-user] r.width.funct in correct version
>> >
>> >Dear Helmut.
>> >This is the output of g.region command:
>> >
>> >
>> >GRASS 7.6.0 (nc):/departamento/Test/nc_basic_spm > g.region -p
>> >projection: 99 (Lambert Conformal Conic)
>> >zone:   0
>> >datum:  nad83
>> >ellipsoid:  a=6378137 es=0.006694380022900787
>> >north:  228500
>> >south:  215000
>> >west:   63
>> >east:   645000
>> >nsres:  10
>> >ewres:  10
>> >rows:   1350
>> >cols:   1500
>> >cells:  2025000
>>
>> and what is the exact r.width.funct command you used?
>>
>> see
>>
>> https://grass.osgeo.org/grass74/manuals/addons/r.width.funct.html
>>
>> for an example:
>>
>> ###
>> g.region raster=elevation -p
>>
>> # Calculate flow direction
>> r.stream.extract elevation=elevation threshold=1000 \
>> direction=direction
>>
>> # Create outlet point
>> echo "637304.924954,218617.100523" | v.in.ascii input=- sep=',' out=outlet
>>
>> # Convert outlet point to raster
>> v.to.rast input=outlet type=point output=outlet use=cat
>>
>> # Calculate distance to outlet map
>> r.stream.distance -o stream_rast=outlet \
>> direction=direction distance=dist2out
>>
>> # Calculate width function
>> r.width.funct map=dist2out image=/tmp/my_basin
>> ###
>>
>>
>> kind regards
>> Helmut
>>
>>
>>
>> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-user
>
>

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

Re: [GRASS-user] does i.sentinel.mask only work with output from i.sentinel.preproc?

[Margherita Di Leo]

Ciao Roberta,

On Thu, Feb 21, 2019 at 6:55 PM roberta fagandini 
wrote:

>
> You can use i.sentinel.mask with the L2A products but you have to check
> the -s flag and set the scale factor equal to 1 (i.e. the
> quantification value for Sentinel 2).
>
> i.sentinel.mask does not require the use of i.sentinel.preproc, you can
> use bands corrected with any other software.
>
> hope this helps!
>

Thank you, it did help indeed! Maybe it's worth an additional line in the
documentation page, because it wasn't obvious for me.

Thanks again
Kind regards,

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

[GRASS-user] does i.sentinel.mask only work with output from i.sentinel.preproc?

[Margherita Di Leo]

Hi,

I'm trying to use i.sentinel.mask on a Sentinel2 L2A.

i.sentinel.mask -r input_file=input_cloud_mask.txt cloud_mask=cloud
shadow_mask=shadow cloud_threshold=25000 shadow_threshold=5000
mtd_file=MTD_TL.xml

The  input_cloud_mask.txt file:

blue=L2A_T34UGD_20161206T094402_B02_10m
green=L2A_T34UGD_20161206T094402_B03_10m
red=L2A_T34UGD_20161206T094402_B04_10m
swir11=L2A_T34UGD_20161206T094402_B11_20m
nir=L2A_T34UGD_20161206T094402_B08_10m
swir12=L2A_T34UGD_20161206T094402_B12_20m
nir8a=L2A_T34UGD_20161206T094402_B8A_20m

I get the following error:

WARNING: Any rescale factor has been applied
ERROR: Raster maps must be DCELL o FCELL

I didn't use i.sentinel.preproc because our colleagues already preprocess
L1C images and provide L2A, but AFAIU here I should start from a L1C image,
and preprocess it with i.sentinel.preproc otherwise I can't apply
i.sentinel.mask, is this correct?

Thanks for any pointers
Regards,

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

Re: [GRASS-user] r.width.funct in correct version

[Margherita Di Leo]

Hi,

On Thu, Feb 21, 2019 at 1:04 PM Veronica Andreo 
wrote:

> I get the same error that Juan gets, both with his commands and with those
> in the example in the manual page (and both in grass76 and trunk).
>
> [omitting the rest for brevity]
>
> r.width.funct map=dist2out image=/tmp/my_basin
>  100%
> Tot. cells 88407.0
> Tot. area 8840700.0
> Max distance 7714.591101
> Traceback (most recent call last):
>   File "/home/veroandreo/.grass7/addons/scripts/r.width.funct", line 135,
> in 
> sys.exit(main())
>   File "/home/veroandreo/.grass7/addons/scripts/r.width.funct", line 84,
> in main
> prc[0,0] , prc[0,1] = findint(kl,0.05) , 0.05
>   File "/home/veroandreo/.grass7/addons/scripts/r.width.funct", line 128,
> in findint
> z1, z2, f1, f2 = kl[int(Xf[0])][0], kl[int(Xf[0]-1)][0],
> kl[int(Xf[0])][1], kl[int(Xf[0]-1)][1]
> IndexError: invalid index to scalar variable.
>
> No idea...
>
> Maybe Madi can help us out here :)
>

 I wish :-) The fact is that I don't know what caused the error because it
was working fine previously. As soon as I have time I will look into it,
but if someone else has idea of what's causing the error, it's more than
welcome.

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

Re: [GRASS-user] sample a strds at specific locations (areas)

[Margherita Di Leo]

Thanks for testing, Vero. I assume it's due to a local problem then.

Cheers,

On Thu, Feb 7, 2019 at 3:29 PM Veronica Andreo  wrote:

> Hi Stefan and Madi,
>
> Thanks Stefan for the explanations :) Indeed I agree that a flag to avoid
> the alignment to input rasters (and just use region settings) sounds good.
> I tested what Madi said, but cannot reproduce in the climate NC location
> [0]. This is the command I used:
>
> v.strds.stats in=boundary_county where="cat == '261'" strds=tempmean
> t_where="start_time >= '2012-01-01'" out=test
>
> to make it faster (it feels indeed kinda slow for the whole vector and
> full time series), I selected only one polygon and a range of dates. I get
> the table as expected while leaving methods by default.
>
> best,
> Vero
>
> [0]
> http://courses.ncsu.edu/mea592/common/media/02/nc_climate_spm_2000_2012.zip
>
>
>
>
> El jue., 7 feb. 2019 a las 14:39, Margherita Di Leo ()
> escribió:
>
>> Thank you Stefan for your help! I figured what happens. v.strds.stats
>> with default method produces in my case a corrupted output, topology is
>> there but there's no table associated to it. If I specify method=average, I
>> do obtain the table, and the mystery is solved: some of the polygons fall
>> into a nodata (due to cloud mask). If anyone else can reproduce the
>> corrupted table issue, I can file a ticket for that.
>>
>> Thanks for help!
>> Regards,
>>
>> On Thu, Feb 7, 2019 at 12:33 PM Stefan Blumentrath <
>> stefan.blumentr...@nina.no> wrote:
>>
>>> Hi Madi,
>>>
>>>
>>>
>>> With this combination (polygon size vs. raster resolution), the shape of
>>> the polygons can be an issue (narrow areas that do not cover the center of
>>> any pixel).
>>>
>>>
>>>
>>> Debugging should be simple with v.db.select or v.extract.
>>>
>>>
>>>
>>> Areas that did not get rasterized should be NULL in the column with
>>> statistics computed with v.rast.stats.
>>>
>>>
>>>
>>> In verbose mode v.rast.stats (or probably even v.to.rast) should
>>> probably give a more informative Warning message (e.g. listing categories
>>> not rasterized). It also would help if you can rasterize the areas yourself
>>> and provide a raster with categories as (optional) input to v.rast.stats…
>>>
>>>
>>>
>>> For high resolution data like yours, the speed improvement of multiple
>>> raster input might help quite a bit esp. with many maps in the time series.
>>> Will see if I can come up with a patch rather soon…
>>>
>>>
>>>
>>> Cheers
>>>
>>> Stefan
>>>
>>>
>>>
>>> *From:* Margherita Di Leo 
>>> *Sent:* torsdag 7. februar 2019 10:37
>>> *To:* Stefan Blumentrath 
>>> *Cc:* Veronica Andreo ; grass-user <
>>> grass-user@lists.osgeo.org>
>>> *Subject:* Re: [GRASS-user] sample a strds at specific locations (areas)
>>>
>>>
>>>
>>> Hi,
>>>
>>>
>>>
>>> thank you for your replies. To give a little more context: I selected my
>>> polygon areas to be > 0.5 ha each (this would be 5 mq if I'm not
>>> mistaken) and I'm sampling NDVI maps at 10m resolution (the region being
>>> the same as NDVI maps). So I think I need an idea on how to debug the areas
>>> that were excluded to check them individually to see what could be the
>>> problem...
>>>
>>> Regarding the alignment problem, if I understand it correctly: if the
>>> polygon doesn't include the *center* of the raster beneath it, can't
>>> retrieve the value and the polygon is discarded? But a value exists, so it
>>> would be correct that it returned a value in any case. But I admit I don't
>>> have a full grasp of the problem.
>>>
>>>
>>>
>>> On Wed, Feb 6, 2019 at 10:52 PM Stefan Blumentrath <
>>> stefan.blumentr...@nina.no> wrote:
>>>
>>> Hi Vero,
>>>
>>>
>>>
>>> I think there is a little misunderstanding.
>>>
>>> v.rast.stats did not change it behaviour with regards to the
>>> computational region (at least not if only one raster map is used). The
>>> alignment to the input raster (resolution) has been around since the module
>>> got ported to Python (like 10 years ago):
>>>
>>>
>>> https://trac.osgeo.org/grass/browser/grass/trunk/scripts/v.rast.stats/v.

Re: [GRASS-user] sample a strds at specific locations (areas)

[Margherita Di Leo]

Thank you Stefan for your help! I figured what happens. v.strds.stats with
default method produces in my case a corrupted output, topology is there
but there's no table associated to it. If I specify method=average, I do
obtain the table, and the mystery is solved: some of the polygons fall into
a nodata (due to cloud mask). If anyone else can reproduce the corrupted
table issue, I can file a ticket for that.

Thanks for help!
Regards,

On Thu, Feb 7, 2019 at 12:33 PM Stefan Blumentrath <
stefan.blumentr...@nina.no> wrote:

> Hi Madi,
>
>
>
> With this combination (polygon size vs. raster resolution), the shape of
> the polygons can be an issue (narrow areas that do not cover the center of
> any pixel).
>
>
>
> Debugging should be simple with v.db.select or v.extract.
>
>
>
> Areas that did not get rasterized should be NULL in the column with
> statistics computed with v.rast.stats.
>
>
>
> In verbose mode v.rast.stats (or probably even v.to.rast) should probably
> give a more informative Warning message (e.g. listing categories not
> rasterized). It also would help if you can rasterize the areas yourself and
> provide a raster with categories as (optional) input to v.rast.stats…
>
>
>
> For high resolution data like yours, the speed improvement of multiple
> raster input might help quite a bit esp. with many maps in the time series.
> Will see if I can come up with a patch rather soon…
>
>
>
> Cheers
>
> Stefan
>
>
>
> *From:* Margherita Di Leo 
> *Sent:* torsdag 7. februar 2019 10:37
> *To:* Stefan Blumentrath 
> *Cc:* Veronica Andreo ; grass-user <
> grass-user@lists.osgeo.org>
> *Subject:* Re: [GRASS-user] sample a strds at specific locations (areas)
>
>
>
> Hi,
>
>
>
> thank you for your replies. To give a little more context: I selected my
> polygon areas to be > 0.5 ha each (this would be 5 mq if I'm not
> mistaken) and I'm sampling NDVI maps at 10m resolution (the region being
> the same as NDVI maps). So I think I need an idea on how to debug the areas
> that were excluded to check them individually to see what could be the
> problem...
>
> Regarding the alignment problem, if I understand it correctly: if the
> polygon doesn't include the *center* of the raster beneath it, can't
> retrieve the value and the polygon is discarded? But a value exists, so it
> would be correct that it returned a value in any case. But I admit I don't
> have a full grasp of the problem.
>
>
>
> On Wed, Feb 6, 2019 at 10:52 PM Stefan Blumentrath <
> stefan.blumentr...@nina.no> wrote:
>
> Hi Vero,
>
>
>
> I think there is a little misunderstanding.
>
> v.rast.stats did not change it behaviour with regards to the computational
> region (at least not if only one raster map is used). The alignment to the
> input raster (resolution) has been around since the module got ported to
> Python (like 10 years ago):
>
>
> https://trac.osgeo.org/grass/browser/grass/trunk/scripts/v.rast.stats/v.rast.stats.py?rev=33522#L148
>
>
>
> So, adding a flag for skipping the alignment was more an idea for an
> enhancement that allows the behaviour you seem to prefer (too).
>
>
>
> Cheers
>
> Stefan
>
>
>
> *From:* Veronica Andreo 
> *Sent:* onsdag 6. februar 2019 21:38
> *To:* Stefan Blumentrath 
> *Cc:* Margherita Di Leo ; grass-user <
> grass-user@lists.osgeo.org>
> *Subject:* Re: [GRASS-user] sample a strds at specific locations (areas)
>
>
>
> I had a similar problem some time ago, just that it was not raster
> resolution, but region resolution that I changed to solve my problem (see
> this thread and MM's answer:
> http://osgeo-org.1560.x6.nabble.com/v-to-rast-for-polygons-not-overlapping-center-of-raster-cell-td5355686.html#a5355729
> )
>
>
>
> IIUC, MM's proposed solution to my case then does not work anymore because
> v.to.rast call inside v.rast.stats is affected by the region alignment to
> the raster to be queried. So, the solution is indeed now, to change raster
> resolution... ? Then the region would be aligned to it (them)?
>
>
>
> If one has large areas or long time series and has to resample all rasters
> to get smallish polygons rasterized, I do not see the advantage of this new
> behavior... but maybe I'm missing something
>
>
>
> Cheers,
>
> Vero
>
>
>
> El mié., 6 feb. 2019 16:54, Stefan Blumentrath 
> escribió:
>
> Ciao Madi, Vero,
>
>
>
> Starting with GRASS 7.6, also centroids are used to get the raster
> representation of your area vector map. That increases the likelihood of
> smaller areas to be rasterized.
>
> Increasing the resolution of the current regio

Re: [GRASS-user] sample a strds at specific locations (areas)

[Margherita Di Leo]

Hi,

thank you for your replies. To give a little more context: I selected my
polygon areas to be > 0.5 ha each (this would be 5 mq if I'm not
mistaken) and I'm sampling NDVI maps at 10m resolution (the region being
the same as NDVI maps). So I think I need an idea on how to debug the areas
that were excluded to check them individually to see what could be the
problem...
Regarding the alignment problem, if I understand it correctly: if the
polygon doesn't include the *center* of the raster beneath it, can't
retrieve the value and the polygon is discarded? But a value exists, so it
would be correct that it returned a value in any case. But I admit I don't
have a full grasp of the problem.

On Wed, Feb 6, 2019 at 10:52 PM Stefan Blumentrath <
stefan.blumentr...@nina.no> wrote:

> Hi Vero,
>
>
>
> I think there is a little misunderstanding.
>
> v.rast.stats did not change it behaviour with regards to the computational
> region (at least not if only one raster map is used). The alignment to the
> input raster (resolution) has been around since the module got ported to
> Python (like 10 years ago):
>
>
> https://trac.osgeo.org/grass/browser/grass/trunk/scripts/v.rast.stats/v.rast.stats.py?rev=33522#L148
>
>
>
> So, adding a flag for skipping the alignment was more an idea for an
> enhancement that allows the behaviour you seem to prefer (too).
>
>
>
> Cheers
>
> Stefan
>
>
>
> *From:* Veronica Andreo 
> *Sent:* onsdag 6. februar 2019 21:38
> *To:* Stefan Blumentrath 
> *Cc:* Margherita Di Leo ; grass-user <
> grass-user@lists.osgeo.org>
> *Subject:* Re: [GRASS-user] sample a strds at specific locations (areas)
>
>
>
> I had a similar problem some time ago, just that it was not raster
> resolution, but region resolution that I changed to solve my problem (see
> this thread and MM's answer:
> http://osgeo-org.1560.x6.nabble.com/v-to-rast-for-polygons-not-overlapping-center-of-raster-cell-td5355686.html#a5355729
> )
>
>
>
> IIUC, MM's proposed solution to my case then does not work anymore because
> v.to.rast call inside v.rast.stats is affected by the region alignment to
> the raster to be queried. So, the solution is indeed now, to change raster
> resolution... ? Then the region would be aligned to it (them)?
>
>
>
> If one has large areas or long time series and has to resample all rasters
> to get smallish polygons rasterized, I do not see the advantage of this new
> behavior... but maybe I'm missing something
>
>
>
> Cheers,
>
> Vero
>
>
>
> El mié., 6 feb. 2019 16:54, Stefan Blumentrath 
> escribió:
>
> Ciao Madi, Vero,
>
>
>
> Starting with GRASS 7.6, also centroids are used to get the raster
> representation of your area vector map. That increases the likelihood of
> smaller areas to be rasterized.
>
> Increasing the resolution of the current region alone does not help,
> because v.rast.stats temporarily changes the computational region to align
> with the input raster map(s) (see also:
> https://trac.osgeo.org/grass/ticket/3523 and
> https://trac.osgeo.org/grass/ticket/3598 for discussion) Even if the
> first ticket is closed, comments are welcome.
>
> It might make sense to add a flag to v.rast.stats like in r.slope.aspect
> to not align the computational region.
>
>
>
> Furthermore, with regards to efficiency, v.strds.stats could gain some
> speed if multi-raster support in v.rast.stats - added in G 7.6 - would be
> handed down to the addon. Might almost double the speed for larger STRDS…
>
>
>
> Cheers
>
> Stefan
>
>
>
> *From:* grass-user  *On Behalf Of 
> *Veronica
> Andreo
> *Sent:* onsdag 6. februar 2019 17:20
> *To:* Margherita Di Leo 
> *Cc:* GRASS user list 
> *Subject:* Re: [GRASS-user] sample a strds at specific locations (areas)
>
>
>
> Hi Madi
>
>
>
> El mié., 6 feb. 2019 a las 16:31, Margherita Di Leo ()
> escribió:
>
> I have a question regarding v.strds.stats. I get the following warning
> message:
>
>
>
> WARNING: Not all vector categories converted to raster. Converted 120 of
> 265.
>
>
>
> What could be the reason for that?
>
>
>
> Some vector areas might not be converted because they are too small with
> respect to the pixel size that you try to query. Others will tell better
> but I think the polygon must overlap the center of the pixel in order to be
> converted into raster. One solution could be to resample your rasters to a
> higher resolution.
>
> HTH,
>
> Vero
>
>

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

Re: [GRASS-user] sample a strds at specific locations (areas)

[Margherita Di Leo]

I have a question regarding v.strds.stats. I get the following warning
message:

WARNING: Not all vector categories converted to raster. Converted 120 of
265.

What could be the reason for that?

Thanks,

On Tue, Feb 5, 2019 at 3:30 PM Margherita Di Leo  wrote:

> Grazie Vero!! Kudos to Luca (author) :-)
>
> On Tue, Feb 5, 2019 at 3:27 PM Veronica Andreo 
> wrote:
>
>> Hi Madi,
>>
>> check the add-on v.strds.stats (
>> https://grass.osgeo.org/grass74/manuals/addons/v.strds.stats.html) that
>> does exactly that :)
>>
>> cheers,
>> Vero
>>
>> El mar., 5 feb. 2019 a las 15:21, Margherita Di Leo ()
>> escribió:
>>
>>> Hi,
>>>
>>> I need to sample a strds at specific locations, but rather than point
>>> locations I need to pass a vector with areas. I need to know the average
>>> value within each area at each given time. How could I do this?
>>>
>>> Thanks in advance
>>>
>>> --
>>> Margherita Di Leo
>>> ___________________
>>> grass-user mailing list
>>> grass-user@lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/grass-user
>>
>>
>
> --
> Margherita Di Leo
>


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

Re: [GRASS-user] sample a strds at specific locations (areas)

[Margherita Di Leo]

Grazie Vero!! Kudos to Luca (author) :-)

On Tue, Feb 5, 2019 at 3:27 PM Veronica Andreo  wrote:

> Hi Madi,
>
> check the add-on v.strds.stats (
> https://grass.osgeo.org/grass74/manuals/addons/v.strds.stats.html) that
> does exactly that :)
>
> cheers,
> Vero
>
> El mar., 5 feb. 2019 a las 15:21, Margherita Di Leo ()
> escribió:
>
>> Hi,
>>
>> I need to sample a strds at specific locations, but rather than point
>> locations I need to pass a vector with areas. I need to know the average
>> value within each area at each given time. How could I do this?
>>
>> Thanks in advance
>>
>> --
>> Margherita Di Leo
>> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-user
>
>

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

[GRASS-user] sample a strds at specific locations (areas)

[Margherita Di Leo]

Hi,

I need to sample a strds at specific locations, but rather than point
locations I need to pass a vector with areas. I need to know the average
value within each area at each given time. How could I do this?

Thanks in advance

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

Re: [GRASS-user] Sentinel 1 in GRASS

[Margherita Di Leo]

Stefan,

I overlooked to mention that my aim is to explore the capabilities for
detecting areas of deforestation. Thanks for sharing your workflow! It will
surely be useful for me.

Kind regards,

On Mon, Nov 26, 2018 at 11:15 AM Stefan Blumentrath <
stefan.blumentr...@nina.no> wrote:

> Hi Margherita,
>
>
>
> There are a lot of very different possible workflows with S-1, depending
> on what you are aiming at...
>
>
>
> For terrestrial mapping applications, feel free to take inspiration from
> here (finishing off a report on the project right now):
>
>
> https://github.com/NINAnor/sentinel4nature/blob/master/Tree%20canopy%20cover/preprocessing/sentinel_1_pp.sh
>
> However, first parts of the pre-processing has to be done in SNAP / gpt as
> the relevant radar tools are to my knowledge not available in GRASS…
>
>
>
> Cheers
>
> Stefan
>
>
>
>
>
> *From:* grass-user  *On Behalf Of 
> *Margherita
> Di Leo
> *Sent:* mandag 26. november 2018 11:08
> *To:* GRASS user list 
> *Subject:* [GRASS-user] Sentinel 1 in GRASS
>
>
>
> Hi,
>
>
>
> has anyone worked with Sentinel 1 in GRASS and can share a nice tutorial?
>
>
>
> Thanks in advance
>
>
> --
>
> Margherita Di Leo
>


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

[GRASS-user] Sentinel 1 in GRASS

[Margherita Di Leo]

Hi,

has anyone worked with Sentinel 1 in GRASS and can share a nice tutorial?

Thanks in advance

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

Re: [GRASS-user] r.basin error

[Margherita Di Leo]

Jose,

could you try if r73602 makes some difference?

On Tue, Oct 23, 2018 at 8:25 AM Margherita Di Leo 
wrote:

> Hi Jose,
>
> Have you checked the cases where r.basin fails? Are they all cases of
> outlet falling in isolated pixels? R.basin can’t handle those, however it’s
> important to understand if there are other problems. Please check a sample
> of the failing cases. Try also to move the outlet of some pixels and run
> again. Note that it doesn’t handle overwrite, you have to delete the output
> manually.
>
> Hope this helps
>
> Il giorno lun 22 ott 2018 alle 21:30 pelempito 
> ha scritto:
>
>> Thanks Helmut for your reply.
>>
>> Certainly having two areas is not a desirable result, but I am not sure if
>> there is a problem with the DEM. One of the areas encompasses an isolated
>> pixel, which in fact is the basin outlet. This polygon is connected
>> diagonally with the other one, which is the main area of the basin. Is it
>> an
>> issue of the DEM? The picture below shows the DEM cropped in the basin
>> area,
>> as well as the polygons and the main channel:
>>
>> <http://osgeo-org.1560.x6.nabble.com/file/t368208/demcropped.jpg>
>>
>> Many of my basins have an outlet such as the one described above. Should I
>> move the outlets to the main area? Such a solution would be a bit
>> impractical. However, some basin outlets may fall on an isolated pixel,
>> which may not be considered as an error.
>>
>>
>>
>> --
>> 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
>
> --
> Margherita Di Leo
>


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

Re: [GRASS-user] r.basin error

[Margherita Di Leo]

Hi Jose,

Have you checked the cases where r.basin fails? Are they all cases of
outlet falling in isolated pixels? R.basin can’t handle those, however it’s
important to understand if there are other problems. Please check a sample
of the failing cases. Try also to move the outlet of some pixels and run
again. Note that it doesn’t handle overwrite, you have to delete the output
manually.

Hope this helps

Il giorno lun 22 ott 2018 alle 21:30 pelempito 
ha scritto:

> Thanks Helmut for your reply.
>
> Certainly having two areas is not a desirable result, but I am not sure if
> there is a problem with the DEM. One of the areas encompasses an isolated
> pixel, which in fact is the basin outlet. This polygon is connected
> diagonally with the other one, which is the main area of the basin. Is it
> an
> issue of the DEM? The picture below shows the DEM cropped in the basin
> area,
> as well as the polygons and the main channel:
>
> <http://osgeo-org.1560.x6.nabble.com/file/t368208/demcropped.jpg>
>
> Many of my basins have an outlet such as the one described above. Should I
> move the outlets to the main area? Such a solution would be a bit
> impractical. However, some basin outlets may fall on an isolated pixel,
> which may not be considered as an error.
>
>
>
> --
> 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

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

Re: [GRASS-user] Import Sentinel2 with timestamp

[Margherita Di Leo]

Hi Martin,

On Wed, Oct 17, 2018 at 1:05 PM Martin Landa  wrote:

> Hi,
>
> st 17. 10. 2018 v 13:00 odesílatel Veronica Andreo
>  napsal:
> > I was also answering Madi to see the example at IRSAE course and
> wondering if that example could be somehow integrated into i.sentinel. Big
> +1 for that! :)
> >
> > However, in theory satellite images would only represent a point in
> time, i.e., only start time should be provided. Why giving a one second
> interval? t.register is able to handle only start time.
>
> yes, this issue needs to be solved. I darkly remember that
> t.rast.mapcalc was failing with point in time data. Period data is
> just an ugly workaround. It needs more investigation. But for sure
> i.sentinel.import should do timestamp as point in time data.
>
>
If I can add a wish to be implemented in i.sentinel.import, is that it
could ingest a text file with list of granules (complete of pattern) to
import.  I'm not sure this is already possible..? I guess that the system
you have implemented works well if you use i.sentinel.download, I haven't
used it because we have the images already in house, but the system  to
archive them may be different.

Thanks again

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

Re: [GRASS-user] Import Sentinel2 with timestamp

[Margherita Di Leo]

Thank you both!

On Wed, Oct 17, 2018 at 1:05 PM Martin Landa  wrote:

> Hi,
>
> st 17. 10. 2018 v 13:00 odesílatel Veronica Andreo
>  napsal:
> > I was also answering Madi to see the example at IRSAE course and
> wondering if that example could be somehow integrated into i.sentinel. Big
> +1 for that! :)
> >
> > However, in theory satellite images would only represent a point in
> time, i.e., only start time should be provided. Why giving a one second
> interval? t.register is able to handle only start time.
>
> yes, this issue needs to be solved. I darkly remember that
> t.rast.mapcalc was failing with point in time data. Period data is
> just an ugly workaround. It needs more investigation. But for sure
> i.sentinel.import should do timestamp as point in time data.
>
> Martin
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
>


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

[GRASS-user] Import Sentinel2 with timestamp

[Margherita Di Leo]

Hi,

Is there an already implemented way to import sentinel images with
i.sentinel.import with timestamp information to be used with temporal
modules?

Thanks

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

[GRASS-user] g.gui.tplot opens plot when exporting csv from cli

[Margherita Di Leo]

Hi,

I'm trying to export in a csv the data used to plot a time series in a
given point, and I have to run it in a script passing a series of
coordinates, so the problem is that using g.gui.tplot from command line, it
opens the plot and needs to be closed manually. Perhaps there is another
tool more suitable for this purpose?

Thank you in advance

Regards,

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

Re: [GRASS-user] Wildfire Modeling with Grass GIS

[Margherita Di Leo]

Hi,

Il giorno sab 8 set 2018 alle 12:48 Vidura Dantanarayana 
ha scritto:

> Hi all,
>
> Currently, I'm using wildfire behavior modeling module for my research. So
> if there anyone who used GRASS for wildfire modeling I need a help. What I
> need to know is how to prepare the raster data to run r.ros and r.spread
> modules. For now, what I did was to get elevation file from USGS (United
> States Geological Survey) and create slope and aspect raster files. Now I
> need to know how to create fuel_model, live humidity, 1hr humidity, wind
> speed, wind direction raster files. I have the 1hr humidity, wind speed,
> wind direction numeric values. A detailed explanation is highly appreciated
> as I'm new to GIS and GRASS. Have a nice day!!
>

You can find some info here
https://grasswiki.osgeo.org/wiki/How_to_create_parameters_to_run_r.ros

Hope this helps

Regards

>
>
> BR,
> Vidura Dantanarayana
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user

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

[GRASS-user] Fwd: Wouldbe GSoC students, please read

[Margherita Di Leo]

-- Forwarded message --
From: Margherita Di Leo <direg...@gmail.com>
Date: Wed, Mar 21, 2018 at 10:47 AM
Subject: Wouldbe GSoC students, please read
To: OSGeo Discussions <disc...@lists.osgeo.org>, OSGeo-SoC <
s...@lists.osgeo.org>


Dear students,

this is a reminder that we will be accepting students proposals until March
27, that is only 1 week away from now. As a general remark, we know that
late submissions are not our best shot, as we usually find them incomplete,
so be aware that the sooner you submit your proposals, the better chances
you have to adjust them to mentors' requirements, and in the end, better
chances to be selected.
We have noticed some proposals have been submitted as final. We cannot
access them until deadline, so, unless you also share the google docs as
public, we don't have a way to give you feedback and we will be evaluating
your final proposal as it is, so you have less chances, or none at all if
your proposals hasn't been discussed anywhere in public channels.
Even if you have had some contact with a potential mentor, remember that
the proposals discussion must happen in public channels, as it is always
the case in open source communities.
Last but not least, remember that GSoC is a highly competitive program, we
prioritize quality over quantity, this means that we only accept excellent
proposals. So please read carefully and thoroughly our recommendations at
https://wiki.osgeo.org/wiki/Google_Summer_of_Code_
Recommendations_for_Students and don't forget to introduce yourself in SOC
mailing list.

Good luck everyone

@All: please forward to your software community mailing list


-- 
Margherita Di Leo



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

Re: [GRASS-user] Keeping GRASS/OTB/... algorithm in qgis processing

[Margherita Di Leo]

Il giorno lun 5 feb 2018 alle 12:40 Helmut Kudrnovsky <hel...@web.de> ha
scritto:

> Dear GRASS GIS community,
>
> herewith I may bring a discussion on QGIS dev ML about how to proceed with
> maintaining GRASS, OTB and other algorithms in qgis processing to your
> attention.
>
>
> http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-Keeping-OTB-algorithm-in-qgis-processing-td5352056.html
>
> it seems that a shared attempt may be needed for a long-term, sustainable
> solution.
>
> citing here my post in that thread:
> https://lists.osgeo.org/pipermail/qgis-developer/2018-February/051892.html
>
> ---
> >Otherwise if we don't care and just want to enable others to have QGIS
> >intgration, they'll have to adopt the plugins.  That might work better if
> there
> >is real interest.  But I think they usally prefer their tools to be used
> in
> >their own environment and don't care that much about whether it works in
> QGIS
>  >providers?  Otherwise I guess they'll sooner or later will die.
>
> quickly screened the GRASS MLs, I can't find any entry that the GRASS
> community was ever asked if there could be e.g. a shared attempt for an
> automatization to create/maintain the plugin code.
>
> Looking at the new OSGeo website:
>
> *Desktop Applications*
>
> -QGIS Desktop
> -GRASS GIS
>
> *Geospatial Libraries*
>
> -Orfeo ToolBox
> -GDAL/OGR
>
> *Meta CRS Initiative*
>
> -PROJ4
>
> Most of the software mentioned in this thread are projects under the common
> umbrella of OSGeo.
>
> An option may be to ask that OSGeo plays a more proactive role in helping
> to
> coordinate and supporting (technically/financally/...) such inter-project
> challenges.
>
> I will forward a short summary of this thread to the GRASS community.
> --
>
> contributions of ideas/support/technical solutions/... are very welcome.
>

Thank you Helli. I wonder if this could be suitable for a GSoC project?

>
>
>
>
>
> -
> 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

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

[GRASS-user] Fwd: Geospatial devroom at FOSDEM 2017 on Sunday 5/2/2017 in Brussels

[Margherita Di Leo]

*Apologies for cross posting!*

Call for Presentations

Please forward!

FOSDEM is a free and non-commercial event bringing together about 5000
developers in Brussels, Belgium. The goal is to provide open source
software developers and communities a place to meet and share thoughts. The
participation is free of charge, although donations are welcome. The next
edition will take place on 4 - 5 February 2017. For the third (!) time
there will be a Geospatial devroom and will be happening on Sunday 5/2/2017!

Geospatial technologies and mapping used to be specialist work, but
nowadays location and maps are becoming part of many projects/applications,
which usually use only a small subset of the possibilities the data and
software offer.

The geospatial devroom is the place to talk about open, geo-related data
and software and their ecosystem. This includes standards and tools, e.g.
for spatial databases, and online mapping, geospatial services, used for
collecting, storing, delivering, analysing, and visualizing purposes.

We welcome submissions about:

   -

   Web and desktop GIS applications;


   -

   Collaborative editing / versioning of geodata and metadata;
   -

   Interoperable geospatial web services and specifications;
   -

   Collection of data using sensors / UAVs / satellites;
   -

   Geo-analytic algorithms / libraries;
   -

   Geospatial extensions for classical databases (indexes, operations) and
   dedicated databases;
   -

   Big geodata, scalable GIS applications;
   -

   Volunteered Geographic information - Crowdsourced geodata.


HOW TO SUBMIT YOUR PROPOSAL FOR A TALK

Are you thrilled to present your work to other open source developers?
Would you like to run a discussion? Any other ideas?

Please submit your proposal at:

 https://fosdem.org/submit

Make sure to select the 'Geospatial devroom' as 'Track'. If you have an
account from previous years, you should be using the same.

Please specify in the notes if you prefer for your presentation either a
short timeslot (lightning talks ~10 minutes) or a long timeslot (20 minutes
presentation + discussion). However, note that time slots are indicative
and will be assigned according to the timing of the session.

The DEADLINE for submissions is Thursday **1st December 2016**.

Notification of acceptance will be sent to the Authors by 11/12/2016 at the
latest.

Should you have any questions, please do not hesitate to get in touch with
the organisers of the devroom at fosdem-geospatial at gisky.be!

Want to know what FOSDEM geospatial is like? Check out the videos and the
presentations of our previous two editions: [1,2]

The organizers

Johan Van de Wauw

Margherita Di Leo

Anne Ghisla

Martin Hammitzsch

[1] https://archive.fosdem.org/2015/schedule/track/geospatial/

[2] https://archive.fosdem.org/2016/schedule/track/geospatial/


-- 
Margherita Di Leo



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

Re: [GRASS-user] Problem in running r.basin

[Margherita Di Leo]

Silvia,

On Wed, Oct 19, 2016 at 4:52 PM, Silvia Isacco <isacco.sil...@gmail.com>
wrote:

> I lost to install one of the dependencies r.stream.*
> Now it run! Never take anything for granted.
>

Actually in this case the program tells you that you are missing a
dependency. Are you running an old version?

>
> It gives some warnings but I read they can be ignored
>
> WARNING: Width for column x set to 255 (was not specified by OGR), some
> strings may be truncated!
> .
> .
> .
> WARNING: Width for column Slope_ratio_Horton set to 255 (was not specified
> by OGR), some strings may be truncated!
>
> Last question: is it possible to save in an external file also the
> percentiles of hypsometric/hypsographic curve?
>

Currently no, and I have no time at present, but if you really need it
please fill a ticket.

Regards,


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

Re: [GRASS-user] Problem in running r.basin

[Margherita Di Leo]

On Wed, Oct 19, 2016 at 12:15 PM, Priscilla_I <isacco.sil...@gmail.com>
wrote:

> Hi Micha,
> thanks for you answer, as Margherita wrote "Silvia" is the directory in
> which I'd like to save my results, and use r.stream only to check that
> coordinates belongs to virtual stream network.
> I followed Margherita advices but I already removed all old files and
> grass kept in giving me error.
>

Yes, but it's a different error..


> So I thought it could be a problem related to the fact that I was using
> GRASS downloaded with Qgis and there were some warnings when I launched it.
>

> I dowloaded GRASS 7.0.5 and tried to run r.basin with the NC sample
> dataset as suggested in an old thread:
>
> I follow the following procedure
> - I create a new mapset in order to not have problems about old files and
> overwriting
> - I set the region
>  * g.region -a raster=elevation@PERMANENT align=elevation@PERMANENT*
> - I launch the command
>  * r.basin map=elevation@PERMANENT prefix=b coordinates=637304,218585
> dir=\tmp\test threshold=40*
>
> it breaks with the error
> *An ERROR occurred running r.basin*
> *Please check for error messages above or try with another pairs of outlet
> coordinates*
> *Removing region definition *
>

Can you try with the example in the manual?

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

g.region raster=elevation -p
r.basin map=elevation prefix=my_basin coord=637304.924954,218617.100523 \
 dir=/tmp/test threshold=1000


Regards,

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

Re: [GRASS-user] Problem in running r.basin

[Margherita Di Leo]

Micha,

On Fri, Oct 14, 2016 at 11:14 PM, Micha Silver <mi...@arava.co.il> wrote:

>
> Hi,
> Thanks for your answers, here the command line I run
> r.basin map=Ghiandone_DEM@Silvia prefix=out coordinates=368450.0,4954025.0
> dir=Silvia threshold=1000 --overwrite
>
>
> In your command line, is the raster map "Silvia" the flow direction raster,
> that was created from the DEM?
>
> The dir parameter in r.basin is used to specify an external directory
(folder) where to export the summary text file.




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

Re: [GRASS-user] Problem in running r.basin

[Margherita Di Leo]

On Fri, Oct 14, 2016 at 4:59 PM, Priscilla_I <isacco.sil...@gmail.com>
wrote:

> I removed the old output and launched the command but now it gets this
> error
>
> ERROR: option : <Silvia\out_Ghiandone_DEM_outlet_coors.txt>
> exists. To overwrite, use the --overwrite flag
>

Yes, this is the txt file that you have created with the previous run. You
have to remove that as well before running r.basin again.


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

Re: [GRASS-user] Problem in running r.basin

[Margherita Di Leo]

Hi,

On Fri, Oct 14, 2016 at 2:33 PM, Priscilla_I <isacco.sil...@gmail.com>
wrote:

> Hi,
> Thanks for your answers, here the command line I run
> r.basin map=Ghiandone_DEM@Silvia prefix=out
> coordinates=368450.0,4954025.0 dir=Silvia threshold=1000 --overwrite
>

I think the problem lies in the "overwrite", which is not handled by
r.basin. Try to remove all your output map, then set the region on the DEM
and then run r.basin, and let us know.


>
> and these are my input raster info
>
> +---
> -+
>  | Map:  Ghiandone_DEM@Silvia   Date: Fri Sep 02 12:32:06
> 2016|
>  | Mapset:   Silvia Login of Creator: Silvia
>|
>  | Location: Piemonte
> |
>  | DataBase: C:\Users\Silvia\Desktop\Grass
>|
>  | Title: ( Ghiandone_DEM )
> |
>  | Timestamp: none
>|
>  |--
> --|
>  |
>|
>  |   Type of Map:  raster   Number of Categories: 0
> |
>  |   Data Type:CELL
> |
>  |   Rows: 888
>|
>  |   Columns:  1047
> |
>  |   Total Cells:  929736
> |
>  |Projection: UTM (zone 32)
> |
>  |N: 4965768.6398801S: 4943886.74090327   Res: 24.64177813
>|
>  |E: 379279.66825865W: 353479.72655961   Res: 24.64177813
> |
>  |   Range of data:min = 0  max = 2550
>|
>  |
>|
>  |   Data Description:
>|
>  |generato da r.in.gdal
> |
>  |
>|
>  |   Comments:
>|
>  |r.in.gdal input="C:\Users\Silvia\Desktop\Grass\Piemonte\Silvia\Ghian\
>   |
>  |done_DEM.tif" output="Ghiandone_DEM" memory=300 offset=0
>|
>  |
>|
>  +--
> --+
> (Fri Oct 14 10:11:48 2016) Comando terminato (0 sec)
>
> I tried with Stefan's command line but unfortunately I didn't solve my
> problem.
>
> 2016-10-14 2:45 GMT+02:00 SBL [via OSGeo.org] <[hidden email]
> <http:///user/SendEmail.jtp?type=node=5290740=0>>:
>
>> Hi Priscilla,
>>
>>
>>
>> I guess the problem is that you run g.region both with the –a flag and
>> the align option.
>>
>> Se: https://grass.osgeo.org/grass70/manuals/g.region.html
>>
>>
>>
>> Please try:
>>
>> g.region -p raster=out_Ghiandone_DEM_strahler@Silvia
>> align=out_Ghiandone_DEM_strahler@Silvia
>>
>> or even just:
>>
>> g.region -p raster=out_Ghiandone_DEM_strahler@Silvia
>>
>> (both commands should give the same result).
>>
>>
>>
>> I have seen quite some confusion around the –a flag (e.g. it has been
>> used in Processing in QGIS in a unsuitable way for quite some time).
>>
>> Maybe the manual should be improved by:
>>
>> 1)  altering the flag description and
>>
>> 2)  adding examples for aligning the region to
>>
>> a.  another raster map
>>
>> b.  a user given resolution / map resolution
>>
>>
>>
>> Flag description could be e.g.:
>>
>> “Adjusted to be even multiples of the resolution in raster or res option”
>> instead of the current:
>>
>> “Align region to resolution (default = align to bounds, works only for 2D
>> resolution)”
>>
>>
>>
>> BTW, is there any case where it makes sense to specify both –a flag and
>> align option? If not, both could be made mutually exclusive in order to
>> avoid such confusion?
>>
>>
>>
>> Finally, two possible examples for the manual of g.region, which might
>> help to make that a bit more clear:
>>
>>
>>
>> # Set region extent to a vector map and align resolution to an existing
>> raster map
>>
>> g.region –p vector=soils align=elev_state_500m
>>
>>
>>
>> # Define region to  align resolution to be an even multiple of the
>> resolution specified by the user
>>
>> g.region –pa vector=soils res=100
>>
>>
>>
>>
>>
>> Kind regards,
>>
>> Stefan
>>
>>
>>
>> *From:* grass-user [mailto:[hidden email]
>> <http:///user/SendEmail.jtp?type=node=5290654=0>] *On Behalf Of 
>> *Margherita
>> Di Leo
>> *Sent:* 13. oktober 2016 18:18
>> *To:* Priscilla_I <[hidden email]
>> <http:///user/SendEmail.jtp?type=node=5290654=1>>
>> *Cc:* GRASS user list <[hidden email]
>> <http:///use

Re: [GRASS-user] Problem in running r.basin

[Margherita Di Leo]

Hi,

On Thu, Oct 13, 2016 at 4:51 PM, Priscilla_I <isacco.sil...@gmail.com>
wrote:

> Hi,
> I'm a new grass user, running "r.basin" module for Grass 7.0.4 on Windows
> 10, I get this error message "ERROR: Region resolution and raster map
>  resolution differs. Run 'g.region
> raster=out_Ghiandone_DEM_strahler' to set proper region resolution."
> I'm using a map in projected coordinates, and I align region with the
> raster
>
> g.region -p -a raster=out_Ghiandone_DEM_strahler@Silvia
> align=out_Ghiandone_DEM_strahler@Silvia
>
> projection: 1 (UTM)
> zone:   32
> datum:  wgs84
> ellipsoid:  wgs84
> north:  4965768.6398801
> south:  4943886.74090327
> west:   353479.72655961
> east:   379279.66825865
> nsres:  24.64177813
> ewres:  24.64177813
> rows:   888
> cols:   1047
> cells:  929736
>
>
> raster info are
>
> Map:  out_Ghiandone_DEM_strahler@Si  Date: Thu Oct 13 11:31:23 2016
>   |
>  | Mapset:   Silvia Login of Creator: Silvia
> |
>  | Location: Piemonte
> |
>  | DataBase: C:\Users\Silvia\Desktop\Grass
> |
>  | Title: ( out_Ghiandone_DEM_strahler )
> |
>  | Timestamp: none
> |
>
> |---
> -|
>  |
> |
>  |   Type of Map:  raster   Number of Categories: 0
> |
>  |   Data Type:CELL
> |
>  |   Rows: 888
> |
>  |   Columns:  1047
> |
>  |   Total Cells:  929736
> |
>  |Projection: UTM (zone 32)
> |
>  |N: 4965768.6398801S: 4943886.74090327   Res: 24.64177813
> |
>  |E: 379279.66825865W: 353479.72655961   Res: 24.64177813
> |
>  |   Range of data:min = 1  max = 4
> |
>  |
> |
>  |   Data Description:
> |
>  |generato da r.stream.order
> |
>  |
> |
>  |   Comments:
> |
>  |r.stream.order stream_rast="out_Ghiandone_DEM_stream_e"
> direction="o\
> |
>  |ut_Ghiandone_DEM_drainage_e" strahler="out_Ghiandone_DEM_strahler"
> h\
> |
>  |orton="out_Ghiandone_DEM_horton" shreve="out_Ghiandone_DEM_shreve"
> h\
> |
>  |ack="out_Ghiandone_DEM_hack" memory=300
> |
>  |
> |
>
> +---
> -+
>
> Any ideas? Thanks in advance!
>

What is the exact r.basin command line that you  run? Can you post also
r.info of the DEM that you use as input?



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

[GRASS-user] Next GRASS GIS meetup in Ispra (VA) on Tuesday 18 October

[Margherita Di Leo]

Dear All,

this is to let you know that after the success of the first one, the next
GRASS GIS meetup in Ispra (VA) will be happening on Tue 18 October. Join us
and bring your friends! Tweet about it and spread the word ;-)

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

Regards,

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

Re: [GRASS-user] g.extension not working behind proxy

[Margherita Di Leo]

Ciao Vero,

On Mon, Oct 10, 2016 at 6:47 PM, Veronica Andreo <veroand...@gmail.com>
wrote:

> Ciao Madi, Pietro
>
> Dunno if related or not at all, but I get the same error when trying to
> install db.join... No proxy involved, though. I just do:
>
> g.extension db.join
>
> However, I did install other add-on today without any problem
> (v.centerpoint).
>
> No idea
>
>>
>> Thanks, I don't know if related either, meanwhile I've opened a
ticket #3179
Hopefully someone else can shed some light?

Cheers,


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

Re: [GRASS-user] g.extension not working behind proxy

[Margherita Di Leo]

On Mon, Oct 10, 2016 at 2:28 PM, Margherita Di Leo <direg...@gmail.com>
wrote:

> Ciao Pietro,
>
> On Mon, Oct 10, 2016 at 12:19 PM, Pietro <peter.z...@gmail.com> wrote:
>
>>
>>
>> Looking at manual and the code here it seems that you have t specify:
>>
>> {{{
>> proxy="http=,ftp="
>> }}}
>>
>> so you should use:
>>
>> {{{
>> g.extension ext=i.segment.hierarchical proxy="http=http://xx.xxx.xxx.
>> xx:"
>> }}}
>>
>> Let us know.
>>
>
> Right, so now I get:
>
> Fetching  from GRASS GIS Addons repository (be
> patient)...
> ERROR: Extension  not found
>

Which is the same that I get if I don't use the proxy option. It seems to
me that the proxy in g.extension is not handled at all. If anyone can
confirm I will file a bug for this. Thanks

>


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

Re: [GRASS-user] g.extension not working behind proxy

[Margherita Di Leo]

Ciao Pietro,

On Mon, Oct 10, 2016 at 12:19 PM, Pietro <peter.z...@gmail.com> wrote:

>
>
> Looking at manual and the code here it seems that you have t specify:
>
> {{{
> proxy="http=,ftp="
> }}}
>
> so you should use:
>
> {{{
> g.extension ext=i.segment.hierarchical proxy="http=http://xx.xxx.xxx.
> xx:"
> }}}
>
> Let us know.
>

Right, so now I get:

Fetching  from GRASS GIS Addons repository (be
patient)...
ERROR: Extension  not found


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

[GRASS-user] g.extension not working behind proxy

[Margherita Di Leo]

Dear All,

when i try to use g.extension behind a proxy, it gives me the following
error:

g.extension ext=i.segment.hierarchical proxy="http://xx.xxx.xxx.xx:;
Traceback (most recent call last):
  File "/usr/local/grass-7.3.svn/scripts/g.extension", line 1730, in

sys.exit(main())
  File "/usr/local/grass-7.3.svn/scripts/g.extension", line 1675, in main
for ptype, purl in (p.split('=') for p in options['proxy'].split(',')):
ValueError: need more than 1 value to unpack

Does anybody have the same? Is that a bug or my misuse?

Thanks

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

[GRASS-user] GRASS GIS contributors meetup(s) in Ispra (VA) Italy

[Margherita Di Leo]

Hi,

this is just to let you know that we are planning to meetup in Ispra (VA)
on the lake Maggiore, Italy. I have created a page [1] that I will keep
updated with dates / time / participants / activities done. If you live in
the surroundings and want to join, you are welcome! The meetups are open to
newcomers as well. In this initial phase, just drop me an email saying that
you'e interested, and I'll get back to you as soon as we have details about
when / where.
I have to confess I have taken this initiative inspired by Yann Chemin, he
has recently joined at JRC, and made me realize once again that meeting in
person like-minded people boosts the enthusiasm in contributing to open
source! Which is more or less the scope of meetups... keeping the
enthusiasm high!!

Cheers!
madi


[1] https://grasswiki.osgeo.org/wiki/GRASS_GIS_Ispra_meetups_2016

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

Re: [GRASS-user] some questions on r.tile

[Margherita Di Leo]

Ciao Markus! Thanks for your answer,

On Wed, Aug 10, 2016 at 8:00 PM, Markus Neteler <nete...@osgeo.org> wrote:

> Hi
>
> On Aug 10, 2016 4:34 PM, "Margherita Di Leo" <direg...@gmail.com> wrote:
> >
> > ERROR: Illegal latitude for North
>
> Which projection are you using?
> I suspect latlong?
>
yes, correct.

> > How should I calculate my overlap and my tiles in order to avoid this
> problem?
>
> Please let us know more.. Perhaps also the command with parameters.
>
The data source I'm using is GMTED 2010 at 30 arc second spatial
resolution, global coverage --> created VRT --> linked via r.external -->
set g.region rast=

g.region rast=bln300_mosaic -ap
projection: 3 (Latitude-Longitude)
zone:   0
datum:  wgs84
ellipsoid:  wgs84
north:  89:59:59.5N
south:  70:00:00.5S
west:   179:59:59.5E
east:   179:59:59.5E
nsres:  0:00:30
ewres:  0:00:30
rows:   19200
cols:   43200
cells:  82944

I wanted to try create 6 large tiles as a first tentative, to see how
r.tile works.
Then i calculate them like this:
rows: 19200 / 2 = 9600
cols: 43200 / 3 = 14400

r.tile input=bln300_mosaic output=tiled width=14400 height=9600 overlap=4
--v
ERROR: Illegal latitude for North

hm..



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

[GRASS-user] some questions on r.tile

[Margherita Di Leo]

Hi,

I have a doubt about the use of r.tile with overlap. r.tile without overlap
works without problem, however when I set an overlap, no matter how large
(have tried 400, 40 and 4 with same outcome) it gives me the error:

ERROR: Illegal latitude for North

How should I calculate my overlap and my tiles in order to avoid this
problem?
Furthermore, is there a way to set a different rule for rows and columns?
say I want to generate vertical stripes that overlap each other for a
certain number of columns?

Thanks for any hints


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

Re: [GRASS-user] importing a vector, problem with duplicate column name: cat_

[Margherita Di Leo]

On Thu, Aug 4, 2016 at 10:29 AM, Markus Metz <markus.metz.gisw...@gmail.com>
wrote:

> On Thu, Aug 4, 2016 at 10:06 AM, Margherita Di Leo <direg...@gmail.com>
> wrote:
>
>
> > If in my work flow I have to import-process-export multiple
> > times, this will add a column every time unless I explicitly drop a
> column?
>
> Yes, or use the key option of v.in.ogr. With your vector you could use
> v.in.ogr key=cat, then drop the cat_ column. The next time you
> re-import the vector, use again the key option, this should avoid that
> "categories are generated as unique values and stored in [in a newly
> created] 'cat' column"
>
> Genau. Thank you
Cheers,


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

Re: [GRASS-user] importing a vector, problem with duplicate column name: cat_

[Margherita Di Leo]

Markus,

On Thu, Aug 4, 2016 at 9:48 AM, Markus Metz <markus.metz.gisw...@gmail.com>
wrote:

> On Thu, Aug 4, 2016 at 9:24 AM, Margherita Di Leo <direg...@gmail.com>
> wrote:
> > Hi,
> >
> > importing a vector either using v.import GUI or v.in.ogr, it tries to
> rename
> > the column  into , but both already exist and it throws out an
> > error.
> >
>
[...]

> >
> > Is there a way to overcome this?
>
> you can overcome this with the columns option of v.in.ogr.
>
> Thank you for your suggestion. Do I understand correctly that this will
add a third column? If in my work flow I have to import-process-export
multiple times, this will add a column every time unless I explicitly drop
a column?



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

[GRASS-user] importing a vector, problem with duplicate column name: cat_

[Margherita Di Leo]

Hi,

importing a vector either using v.import GUI or v.in.ogr, it tries to
rename the column  into , but both already exist and it throws
out an error.

[..]
Check if OGR layer  contains polygons...
Column name  renamed to 
DBMI-SQLite driver error:
Error in sqlite3_prepare():
duplicate column name: cat_
DBMI-SQLite driver error:
Error in sqlite3_prepare():
duplicate column name: cat_
ERROR: Unable to create table: 'create table pt599000_4414000_class1 (cat
integer, cat_ integer, cat_ integer, NDVI double precision)'
ERROR: Unable to import [..]

Is there a way to overcome this?

Thank you for any suggestion
Cheers,

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

Re: [GRASS-user] i.atcorr for GeoEye-1 and Worldview-3

[Margherita Di Leo]

Hi,

On Thu, Jun 4, 2015 at 2:19 PM, Moritz Lennert mlenn...@club.worldonline.be
 wrote:

 On 04/06/15 13:47, Nikos Alexandris wrote:

 * Moritz Lennert mlenn...@club.worldonline.be [2015-06-04 11:38:04
 +0200]:

  On 03/06/15 15:06, Markus Neteler wrote:

 On Wed, Jun 3, 2015 at 6:56 AM, Kamhul Camhol monk_pur...@yahoo.com
 wrote:

 Hello. I'm quite new with GRASS but I need to atmospherically process
 high-resolution imagery with i.atcorr. I have three images Quickbird,
 GeoEye-1 and Worldview-3 imagery of a single scene across three time
 periods. For Quickbird, I have all the data needed but basing from the
 following manual GRASS GIS manual: i.atcorr
 there appears to be no values for two required inputs for GeoEye-1 and
 Worldview-3.


 Yes, at time only Quickbird but not GeoEye-1 and Worldview-3 are
 supported.

  These are geometrical conditions and band. May I know if GRASS
 has updated the i.atcorr manual to include these sensors as well? Can
 I use
 the values of Worldview-2 for Worldview-3? Or is there any other way
 to do
 the atmospheric correction for these two sensors?


 We would be happy to add support for these sensors. We need the
 spectral filter curves for that, in order to integrate them in
 i.atcorr.


 Do I understand correctly that you would need the numbers behind the
 curves in this document:


 https://www.digitalglobe.com/sites/default/files/DigitalGlobe_Spectral_Response_1.pdf

 ?


 Yes Moritz, that is very relevant!  They updated the document I think (it
 wasn't
 there on Summer 2013 plus a few months later -- the properties of this
 file indicate October 2014).


 I don't have the time to do this now, but using something like [1], it
 should be easy to quickly get an approximate dataset from the graphs in
 that document.

 Moritz

 [1] http://arohatgi.info/WebPlotDigitizer/


For GeoEye-1 the curves are here:
https://apollomapping.com/wp-content/user_uploads/2013/08/GeoEye-1_Relative_Spectral_Response.xls
see https://apollomapping.com/about-us/whitepapers



-- 
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

Re: [GRASS-user] mountain ridges extraction from DEM

[Margherita Di Leo]

Hi Wolfgang,

On Tue, May 19, 2015 at 2:09 AM, Wolfgang wol...@gmx.net wrote:

 Hello,
 I would like to know if it is possible (and how) to generate the view to
 mountain ridges as shown in
 http://www.viewfinderpanoramas.org/panoramas.html
 There are also nowadys some apps for smartphones which does the same.
 I already found r.horizon but this is, at least as I understand, only the
 view of the horizon and not all ridges.
 I also found a paper on automatic ridge extraction, but it seems that this
 never was included to grass:

 http://www.ing.unitn.it/~grass/conferences/GRASS2002/proceedings/proceedings/pdfs/Frigeri_Alessandro_2.pdf


Just a wild, not tested idea. You could try reversing the DEM and using
the algorithm for stream extraction  ..?

cheers,
Margherita

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




-- 
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

Re: [GRASS-user] r.basin matplotlib error

[Margherita Di Leo]

Maning

On Thu, Apr 30, 2015 at 10:51 AM, maning sambale emmanuel.samb...@gmail.com
 wrote:

 Dear Margherita,

 Thanks!

 On Thu, Apr 30, 2015 at 4:35 PM, Margherita Di Leo direg...@gmail.com
 wrote:
  Matplotlib is a dependency needed for the graphic output, being the
  hypsographic curve and the width function. If you don't need those
 graphics,
  this error will not affect the result that you get. For what concerns the
  reason why this dependency is missing in windows, I don't know, perhaps
  packaging issue?

 This is what I suspect.  I'm sure I have matplotlib installed (might
 be some conflicting packages), will investigate further.
 Not a biggie for not getting the graphics (would be nice to have of
 course) as long as the results are OK.


Sorry reading again your email I realized that you are not on windows as I
mentioned. I don't have a clue of what KyngChaos is. However my reply still
applies, except for the windows part.

Cheers,
Margherita


-- 
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

Re: [GRASS-user] r.basin matplotlib error

[Margherita Di Leo]

Dear Maning,

On Thu, Apr 30, 2015 at 10:11 AM, maning sambale emmanuel.samb...@gmail.com
 wrote:

 Hi,

 I'm running r.basin using GRASS 6.4.4 from KyngChaos.

 r.basin map=dem_90_int@PERMANENT prefix=out easting=712026.954
 northing=1212651.537 threshold=40 --overwrite

 I get this error, but the process continues.

 out_dem_90_int_dist2out Done
 ##
 Traceback (most recent call last):
   File /Users/maning/Library/GRASS/6.4/Modules/bin/r.ipso, line 57,
 in module
 import matplotlib #required by windows
 ImportError: No module named matplotlib
 ##
 ##
 Traceback (most recent call last):
   File /Users/maning/Library/GRASS/6.4/Modules/bin/r.wf, line 48, in
 module
 import matplotlib #required by windows
 ImportError: No module named matplotlib
 ##
 Reading maps...

 I was able to generate the maps and the Morphometric parameters.
 What does this error mean and does it have any implication in the
 Morphometric parameters results?


Matplotlib is a dependency needed for the graphic output, being the
hypsographic curve and the width function. If you don't need those
graphics, this error will not affect the result that you get. For what
concerns the reason why this dependency is missing in windows, I don't
know, perhaps packaging issue?

Best,
Margherita




 --
 cheers,
 maning
 --
 Freedom is still the most radical idea of all -N.Branden
 https://epsg4253.wordpress.com/
 http://twitter.com/maningsambale
 --
 ___
 grass-user mailing list
 grass-user@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-user




-- 
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

Re: [GRASS-user] Large vector file processing

[Margherita Di Leo]

Hi again,

On Fri, Apr 24, 2015 at 11:03 AM, Margherita Di Leo direg...@gmail.com
wrote:

 Moritz,

 On Fri, Apr 24, 2015 at 10:09 AM, Moritz Lennert 
 mlenn...@club.worldonline.be wrote:

 On 24/04/15 09:54, Margherita Di Leo wrote:



 :~  r.to.vect input=raster_tty output=vector_tty type=area
 Extracting areas...
   100%
 Writing areas...
   100%
 Building topology for vector map vector_tty@assessment...
 Registering primitives...
 Killed

 what does this mean?

 :~  v.build vector_tty
 WARNING: Coor file of vector map vector_tty@assessment is larger than
 it
   should be (2403996039 bytes excess)
 Building topology for vector map vector_tty@assessment...
 Registering primitives...
 Killed

 Question about larger that it should be: What is this limitation? I
 guess is related to the specs of my laptop?


 This just means that topology has not been built correctly, which is
 probably due to some memory issues.

 See also https://trac.osgeo.org/grass/ticket/2045.

 One option mentioned in this report is to set GRASS_VECTOR_LOWMEM before
 running r.to.vect in order to limit memory usage.


 Thank you for the suggestion, digging deeper I've found also
 http://lists.osgeo.org/pipermail/grass-user/2011-January/059175.html
 Now trying this option.


Unfortunately, this did not work! It took longer, but eventually the
r.to.vect yielded again the Killed signal in the building topology
phase..


-- 
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

Re: [GRASS-user] Large vector file processing

[Margherita Di Leo]

On Fri, Apr 24, 2015 at 11:07 AM, Markus Neteler nete...@osgeo.org wrote:

 On Fri, Apr 24, 2015 at 11:03 AM, Margherita Di Leo direg...@gmail.com
 wrote:
  Thank you for the suggestion, digging deeper I've found also
  http://lists.osgeo.org/pipermail/grass-user/2011-January/059175.html
  Now trying this option. Meanwhile, would it be useful setting up a wiki
 page
  on Large vector data processing similarly to what is in place for
 raster
  files? Or is there already and I overlook it?

 Yes, it would be good to create it and then link here:


 http://grasswiki.osgeo.org/wiki/GRASS_GIS_Performance#Large_vector_data_processing


Done here: http://grasswiki.osgeo.org/wiki/Large_vector_data_processing
Please contribute.


-- 
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

Re: [GRASS-user] Large vector file processing

[Margherita Di Leo]

Moritz,

On Fri, Apr 24, 2015 at 10:09 AM, Moritz Lennert 
mlenn...@club.worldonline.be wrote:

 On 24/04/15 09:54, Margherita Di Leo wrote:



 :~  r.to.vect input=raster_tty output=vector_tty type=area
 Extracting areas...
   100%
 Writing areas...
   100%
 Building topology for vector map vector_tty@assessment...
 Registering primitives...
 Killed

 what does this mean?

 :~  v.build vector_tty
 WARNING: Coor file of vector map vector_tty@assessment is larger than
 it
   should be (2403996039 bytes excess)
 Building topology for vector map vector_tty@assessment...
 Registering primitives...
 Killed

 Question about larger that it should be: What is this limitation? I
 guess is related to the specs of my laptop?


 This just means that topology has not been built correctly, which is
 probably due to some memory issues.

 See also https://trac.osgeo.org/grass/ticket/2045.

 One option mentioned in this report is to set GRASS_VECTOR_LOWMEM before
 running r.to.vect in order to limit memory usage.


Thank you for the suggestion, digging deeper I've found also
http://lists.osgeo.org/pipermail/grass-user/2011-January/059175.html
Now trying this option. Meanwhile, would it be useful setting up a wiki
page on Large vector data processing similarly to what is in place for
raster files? Or is there already and I overlook it?

@Alexander Muriy : thanks for the suggestion. I ask you to please
contribute a section as soon as I create the page ;-)

Thanks

-- 
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] Large vector file processing

[Margherita Di Leo]

Hi,

I'm trying to vectorize a very large file

 |   Type of Map:  raster   Number of Categories: 255
  |
 |   Data Type:CELL
  |
 |   Rows: 88537
   |
 |   Columns:  54410
   |
 |   Total Cells:  4817298170
  |
 |Projection: Lambert Azimuthal Equal Area
   |
 |N:4239550S:2026125   Res:25
  |
 |E:4284650W:2924400   Res:25
  |
 |   Range of data:min = 11  max = 255

using GRASS 7.1.svn (r65027)

:~  r.to.vect input=raster_tty output=vector_tty type=area
Extracting areas...
 100%
Writing areas...
 100%
Building topology for vector map vector_tty@assessment...
Registering primitives...
Killed

what does this mean?

:~  v.build vector_tty
WARNING: Coor file of vector map vector_tty@assessment is larger than it
 should be (2403996039 bytes excess)
Building topology for vector map vector_tty@assessment...
Registering primitives...
Killed

Question about larger that it should be: What is this limitation? I guess
is related to the specs of my laptop?

Thanks,
-- 
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] default database grass 7.1?

[Margherita Di Leo]

Hi,

I run into this issue today:

r.to.vect input=tty output=tty type=area --o

Extracting areas...
Writing areas...
dbmi: Protocol error
ERROR: Cannot insert new row: insert into tty values (3968805, 12, '')
dbmi: Protocol error

Running db.connect -p I found out that my database was dbf. I'm
running GRASS 7.1.svn (r65027). Naive question: default database is not
sqlite?

db.connect --help

Description:

 Prints/sets general DB connection for current mapset.


Keywords:

 database, attribute table, connection settings


Usage:

 db.connect [-pgcd] [driver=name] [database=name] [schema=name]

   [group=string] [--help] [--verbose] [--quiet] [--ui]


Flags:

  -p   Print current connection parameters and exit

Substitute variables in database settings

  -g   Print current connection parameters using shell style and exit

  -c   Check connection parameters, set if uninitialized, and exit

  -d   Set from default settings and exit

Overwrite current settings if already initialized

 --h   Print usage summary

 --v   Verbose module output

 --q   Quiet module output

 --ui  Force launching GUI dialog


Parameters:

driver   Name of database driver

 options: ogr,sqlite,dbf

 default: sqlite

  database   Name of database

 *default: $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/*

schema   Database schema

  Do not use this option if schemas are not supported by
driver/database server

 group   Default group of database users to which select privilege is
granted

I'm puzzled.

madi before massive morning coffee.

-- 
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

Re: [GRASS-user] count points within poly and update column

[Margherita Di Leo]

On Sun, Apr 19, 2015 at 9:05 AM, Markus Neteler nete...@osgeo.org wrote:


 On Apr 17, 2015 10:34 PM, Margherita Di Leo direg...@gmail.com wrote:
  I'm adding a FAQ in the wiki

 Note that there was already an entry at


 http://grasswiki.osgeo.org/wiki/Count_points_in_polygon#Geometry_based_solution


 Uops! Thank you Markus



-- 
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

Re: [GRASS-user] count points within poly and update column

[Margherita Di Leo]

On Sun, Apr 19, 2015 at 9:58 AM, Margherita Di Leo direg...@gmail.com
wrote:



 On Sun, Apr 19, 2015 at 9:05 AM, Markus Neteler nete...@osgeo.org wrote:


 On Apr 17, 2015 10:34 PM, Margherita Di Leo direg...@gmail.com wrote:
  I'm adding a FAQ in the wiki

 Note that there was already an entry at


 http://grasswiki.osgeo.org/wiki/Count_points_in_polygon#Geometry_based_solution


 Uops! Thank you Markus

 So this page
http://grasswiki.osgeo.org/wiki/Vector_count_points_within_polygon_and_update_column
should be removed. I think this operation should be performed by wiki
admins, right? I don't seem to have this option.

Thanks

-- 
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

Re: [GRASS-user] count points within poly and update column

[Margherita Di Leo]

Hey Nikos!

On Fri, Apr 17, 2015 at 10:22 PM, Nikos Alexandris n...@nikosalexandris.net
wrote:

 Margherita Di Leo:

  Hi,
 
  I need to count the number of points that falls within a set of polygons,
  and add this number as a column in the table associated with the
  polygon.How can I do that?

 Madi,

 that was a somewhat cumbersome task in the past. Not anymore though,
 please see: http://grass.osgeo.org/grass70/manuals/v.vect.stats.html.


Thank you very much! I have been looking here
http://grass.osgeo.org/grass71/manuals/vectorintro.html and
http://grass.osgeo.org/grass71/manuals/topic_statistics.html and in the
wiki but could find no reference. I'm adding a FAQ in the wiki and keywords
in the documentation pages.

Thanks again!
madi



-- 
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] digitize adjacent polygons

[Margherita Di Leo]

Hi,

is there a way to digitize polygons with the new vector digitizer tool,
using existing borders? I mean, if I have to digitize two adjacent
polygons, how can I start one exactly where the other finishes, using the
line shared by the two, without having to digitize it twice?

Thanks,
madi

-- 
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

Re: [GRASS-user] Stream power Index calculation?

[Margherita Di Leo]

Hey Helli,

On Wed, Mar 4, 2015 at 9:46 AM, Helmut Kudrnovsky hel...@web.de wrote:

  in the book SPI is defined as:
 
  SPI = A x tan(beta)


what about calculating A with r.watershed (flow accum) and tan(beta) with
r.slope.aspect (slope) and then using r.mapcalc to multiply them?

cheers,
madi

-- 
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

Re: [GRASS-user] sampling points in a grid

[Margherita Di Leo]

On Tue, Feb 17, 2015 at 5:30 PM, Markus Neteler nete...@osgeo.org wrote:

 On Tue, Feb 17, 2015 at 4:49 PM, Margherita Di Leo direg...@gmail.com
 wrote:
  Hi,
 
  I have a vector of points. According to a regular grid, I need to
 (randomly)
  sample a certain number n of these points in each cell of the grid. Such
  number n is given in a column of the attribute table of the grid. How
 would
  you do this?

 With a small script this should be doable:
 - generate the grid as polygons (v.mkgrid)
 - loop over each polygon
  - fetch category number or v.extract
  - fetch corresponding number of points to be created from DB
  - v.random, using the current grid polygon for restricted creation
 feature

 http://grass.osgeo.org/grass70/manuals/v.random.html#restriction-to-vector-areas


Here lies the problem. I need to randomly pick points that are already
existing. Example: for grid cell that has ID 42, I have 50 points, and have
to randomly pick 7 out of these 50.


  - save point map
 - patch all point maps into single resulting map
 - remove single point maps

 Something like this...

 Markus




-- 
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] sampling points in a grid

[Margherita Di Leo]

Hi,

I have a vector of points. According to a regular grid, I need to
(randomly) sample a certain number n of these points in each cell of the
grid. Such number n is given in a column of the attribute table of the
grid. How would you do this?
I have half idea to play with the coordinates and Monte Carlo, but I have
the feeling that I'm not thinking GIS and there must be a easier way.

Thank you for any hint

-- 
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

Re: [GRASS-user] difference between the sum and num options in v.rast.stats

[Margherita Di Leo]

Hi Nikos,

On Thu, Feb 12, 2015 at 11:31 AM, Nikos Alexandris n...@nikosalexandris.net
wrote:

 On 12.02.2015 11:43, Margherita Di Leo wrote:

 Hi,

 what is the difference between the sum and num options in v.rast.stats?
 comparing the results of the two columns they appear to be the same, but
 I'm sure I'm missing something.
 Thanks for any pointers



 Hello Madi.

 statistics are calculated per vector category (cat) from the raster
 map.  So, maybe there is nothing wrong in this very case of yours?


Sorry I was unclear. I don't think there is something wrong, I was just
wondering : what is the difference between the two options for method:
sum and num. Because they are two different options, but in my case
provide same result.



-- 
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] difference between the sum and num options in v.rast.stats

[Margherita Di Leo]

Hi,

what is the difference between the sum and num options in v.rast.stats?
comparing the results of the two columns they appear to be the same, but
I'm sure I'm missing something.
Thanks for any pointers

-- 
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

Re: [GRASS-user] difference between the sum and num options in v.rast.stats

[Margherita Di Leo]

Roy,

On Thu, Feb 12, 2015 at 12:01 PM, Roy royr...@outlook.com wrote:

  Hi, Margherita

what is the difference between the sum and num options in v.rast.stats?
 comparing the results of the two columns they appear to be the same, but
 I'm sure I'm missing something.
 Thanks for any pointers



  sum is the sum of values and num (n) is the number of cells,
 if you have all cells = 1,  in this case  sum = num
 if this is not the case (all cells = 1) maybe something is wrong ...


Thank you, now is clear. No error, the result is correct.




-- 
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] percentage of class in raster within polygons

[Margherita Di Leo]

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

Re: [GRASS-user] r.in.gdal and .raw files

[Margherita Di Leo]

Markus,

On Wed, Feb 4, 2015 at 10:30 AM, Markus Neteler nete...@osgeo.org wrote:

 On Wed, Feb 4, 2015 at 9:46 AM, Margherita Di Leo direg...@gmail.com
 wrote:
  On Tue, Feb 3, 2015 at 9:22 PM, Markus Metz
  On Tue, Feb 3, 2015 at 2:41 PM, Margherita Di Leo direg...@gmail.com
  wrote:
   anyone has experience with .raw files? I happen to have one to analyze
   (quite large indeed) and  r.in.gdal doesn't seem to support it.
 However,
   for some magics, qgis is able to open it and I'm now converting it to
 tif.

 ... are you using the same GDAL version in QGIS and GRASS GIS?


1.10.1 (2013/08/26)


   But it's taking kinda forever. Any better idea?
 
  A .raw file could be a raw data file from a digital camera, but it can
  also be anything else. Can QGIS tell you what kind of file this is?
 
  It is mosaic from digital camera (RGB).

 But if it is a mosaic, the camera file got already postprocessed?


Yes, sorry if I was unclear on this. It comes with its .hdr, in which I
read it's been postprocessed with ENVI. However my curiosity was about qgis
handling it and grass not, using the same version of gdal..


 If not, there are various formats:
 https://en.wikipedia.org/wiki/Raw_image_format#File_contents

 ciao
 markusN




-- 
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

Re: [GRASS-user] r.in.gdal and .raw files

[Margherita Di Leo]

Markus,

On Wed, Feb 4, 2015 at 10:51 AM, Markus Neteler nete...@osgeo.org wrote:

 On Wed, Feb 4, 2015 at 10:45 AM, Margherita Di Leo direg...@gmail.com
 wrote:
  On Wed, Feb 4, 2015 at 10:30 AM, Markus Neteler nete...@osgeo.org
 wrote:
 ...
  ... are you using the same GDAL version in QGIS and GRASS GIS?
 
  1.10.1 (2013/08/26)

 Not that new :-)


So am I :-P
(You're right)


  But if it is a mosaic, the camera file got already postprocessed?
 
  Yes, sorry if I was unclear on this. It comes with its .hdr, in which I
 read
  it's been postprocessed with ENVI.

 Aha, so it is an ENVI file.

  However my curiosity was about qgis
  handling it and grass not, using the same version of gdal..

 What does gdalinfo report on the file? If that works, r.in.gdal will work,
 too.


Says that it is not recognised as a supported file format.


 Important:

 http://www.gdal.org/frmt_various.html#ENVI
 To select an existing ENVI raster file select the binary file
 containing the data...

 Maybe you specified the hdr file?


Nope. I'm sure I specified the raw file.


 Markus




-- 
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

Re: [GRASS-user] r.in.gdal and .raw files

[Margherita Di Leo]

Hi Markus,

On Tue, Feb 3, 2015 at 9:22 PM, Markus Metz markus.metz.gisw...@gmail.com
wrote:

 On Tue, Feb 3, 2015 at 2:41 PM, Margherita Di Leo direg...@gmail.com
 wrote:
  Hi,
 
  anyone has experience with .raw files? I happen to have one to analyze
  (quite large indeed) and  r.in.gdal doesn't seem to support it. However,
 for
  some magics, qgis is able to open it and I'm now converting it to tif.
 But
  it's taking kinda forever. Any better idea?

 A .raw file could be a raw data file from a digital camera, but it can
 also be anything else. Can QGIS tell you what kind of file this is?


It is mosaic from digital camera (RGB).

Thanks,
madi


 Markus M

 --
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

Re: [GRASS-user] r.in.gdal and .raw files

[Margherita Di Leo]

On Wed, Feb 4, 2015 at 11:24 AM, Markus Neteler nete...@osgeo.org wrote:


 - copy-paste the command here


$ gdalinfo mosaic_RGB.raw
ERROR 4: `mosaic_RGB.raw' not recognised as a supported file format.

gdalinfo failed - unable to open 'mosaic_RGB.raw'.


 - run file thefilename and post the output?


$ file mosaic_RGB.raw
mosaic_RGB.raw: empty



 And which OS,


Lubuntu Osgeo-Live 8.0


 which GRASS version?


GRASS GIS 7.1.svn (r64388)

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

Re: [GRASS-user] r.in.gdal and .raw files

[Margherita Di Leo]

Mistery SOLVED.. the file got damaged during copy. The proper file is read
by gdal and obviously by grass. sorry for noise

madi

On Wed, Feb 4, 2015 at 11:54 AM, Margherita Di Leo direg...@gmail.com
wrote:



 On Wed, Feb 4, 2015 at 11:24 AM, Markus Neteler nete...@osgeo.org wrote:


 - copy-paste the command here


 $ gdalinfo mosaic_RGB.raw
 ERROR 4: `mosaic_RGB.raw' not recognised as a supported file format.

 gdalinfo failed - unable to open 'mosaic_RGB.raw'.


 - run file thefilename and post the output?


 $ file mosaic_RGB.raw
 mosaic_RGB.raw: empty



 And which OS,


 Lubuntu Osgeo-Live 8.0


 which GRASS version?


 GRASS GIS 7.1.svn (r64388)

 ciao madi




-- 
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] r.in.gdal and .raw files

[Margherita Di Leo]

Hi,

anyone has experience with .raw files? I happen to have one to analyze
(quite large indeed) and  r.in.gdal doesn't seem to support it. However,
for some magics, qgis is able to open it and I'm now converting it to tif.
But it's taking kinda forever. 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] v.out.ogr drops some columns with non informative error

[Margherita Di Leo]

Hi,

I'm experiencing this problem, exporting a vector file with a table
associated, several columns are exported but two of them are dropped, and
the error is not informative:

ERROR 6: Failed to add field named 'wetness_idx'
ERROR 6: Failed to add field named 'elevabovestr'

I'm struggling to ask it why, but it doesn't speak, even in verbose mode.
I'm on G 7.1.svn (r63559)

Any pointers please

-- 
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

Re: [GRASS-user] v.out.ogr drops some columns with non informative error

[Margherita Di Leo]

Hi Moritz,

On Wed, Dec 17, 2014 at 3:59 PM, Moritz Lennert 
mlenn...@club.worldonline.be wrote:


 Are you exporting to shapefile ?

 There is a 10-letter limit to column names and apparently also a 255
 columns limit:

 http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?
 TopicName=Geoprocessing%20considerations%20for%20shapefile%20output


Oops, thanks! that solved.  is there no way to get grass speak that, at
least in verbose mode?

Thank you again
Margherita


-- 
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] units used in r.stream.distance

[Margherita Di Leo]

Hi,

what are the units used to calculate distance with r.stream.distance in
geographic (latlon) locations?

Thanks,
madi

-- 
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

Re: [GRASS-user] units used in r.stream.distance

[Margherita Di Leo]

Hi,

On Tue, Dec 16, 2014 at 9:09 PM, Markus Neteler nete...@osgeo.org wrote:



 No it depends on the respective command. Eg:

 http://grass.osgeo.org/grass70/manuals/v.distance.html#notes
 In lat-long locations v.distance gives distances (dist, from_along,
 and to_along) not in degrees but in meters calculated as geodesic
 distances on a sphere. 

 Regarding r.stream.distance one would need to check the source code
 (and then document it).


Thank you. Jarek (the author of the module) confirmed that the distance is
in meters. I'm expanding the documentation accordingly,

Thanks,
madi





-- 
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

Re: [GRASS-user] Problem with r.basin in grass7

[Margherita Di Leo]

Hi Andrea,

On Tue, Nov 18, 2014 at 3:55 AM, Andrea Timmermann timmerm...@gmx.at
wrote:

 Hi Helmut,

 Thanks for your email.
 I set again the area and resolution with g.region before running r.basin.
 I also deleted all files except my DEM.

 Now I get a different error ...

 When I run
  *r.basin map=map@Elevation prefix=o
 coordinates=-71.10394196,43.9865230801 threshold=19005
 dir=C:\\Users\\Andrea\\Basins*

 I get:
 ...




















 *Building topology for vector map o_map_ord_1@Elevation... Registering
 primitives... 10 primitives registered 558 vertices registered Building
 areas... 0 areas built 0 isles built Attaching islands... Attaching
 centroids... Number of nodes: 20 Number of primitives: 10 Number of points:
 0 Number of lines: 10 Number of boundaries: 0 Number of centroids: 0 Number
 of areas: 0 Number of isles: 0 Updating attributes... r.to.vect complete.
 All in RAM calculation... ERROR: Region resolution and raster map
 o_map_strahler resolution differs. Run 'g.region rast=o_map_strahler' to
 set proper region resolution*

 I run *g.region rast=o_map_strahler, *but then I have to delete all files
 and start over again running r.basin.


Yes if you change the region you have to delete the files created in the
previous run (if they have same name) or allow overwrite.



-- 
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

Re: [GRASS-user] Problem with r.basin in grass7

[Margherita Di Leo]

Hi Andrea,

On Tue, Nov 18, 2014 at 4:06 PM, Andrea Timmermann timmerm...@gmx.at
wrote:

 Hi Margherita,

 Thanks for your answer. I am sorry I did not explain well what I meant.

 When I delete all files and start again, I get again stuck at that point.

 What I do is: delete all files, set region, run r.basin, get the error ...
 detele all files, set the region, run r.basin, get the error 

 I just tried it again ..


 Can you please post the result of:
r.info *map@Elevation*
and
g.region -p


-- 
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

Re: [GRASS-user] Problem with r.basin in grass7

[Margherita Di Leo]

Dear Andrea,

On Sun, Nov 2, 2014 at 6:26 PM, Markus Neteler nete...@osgeo.org wrote:

 HI Andrea,

 On Fri, Oct 31, 2014 at 3:18 PM, Andrea Timmermann timmerm...@gmx.at
 wrote:


  Reading features...
  Writing raster map...
  Converted points/lines: 1 of 1
  v.to.rast complete.
  ERROR: Module built against version $Revision: 62060 $ but trying to use
  version $Revision: 62364 $. You need to rebuild GRASS GIS or untangle
  multiple installations.

 Mhh, this should not happen issue. In a winGRASS installer there
 should not be any version mixture.
 Helli, Martin, any ideas?


Did you update G7 without updating the r.stream* perhaps? I'm not sure if
this would lead to the error above mentioned, but to give it a try, please
remove and then reistall the r.stream modules using g.extension


 [...]


  I also have two more questions:
  - Should I set the computational region to the whole raster map I am
 using
  or to the vector map defining my basin? (I tried both alternatives and
  r.basin writes something a bit different on the screen depending on what
 I
  use)

 This is a question for the author of r.basin, I don't know.


The vector map defining your basin is actually an output of the module. You
should set the computational region to include the closing section and the
area above it up to the ridges (the top of the mountains). This is the best
guess on where your basin is more or less contained. If your entire raster
is reasonably small, it is OK to set the computational region to the whole
raster, otherwhise, you should try to include the ridges that define your
basin of interest. If your selection is wrong, you'll be able anyway to
detect it because your basin will extend to the limits of your
computational region. In this case you will know that you should extend the
computational region.


  I am using a mask based on my vector map, so maybe the computations are
  anyways done only for the area covered by the basin?

 ... also here.


No, the module does not reduce the region automatically. My suggestion
would be to set the computational region reasonably larger than the vector
and not to use it as a mask. This is because it could prevent including
cells that drain into the basin. You can prove it running r.watershed on
the raster masked by the polygon representing the basin. Query the flow
accumulation that you obtain (you can use r.mapcalc) to see if there are
negative values. The negative values are conventionally used in r.watershed
to detect cels that are incomplete as sinks for other cells to drain
into.

Hope this helps,
madi



-- 
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] detecting olive trees from satellite imagery

[Margherita Di Leo]

Dear All,

I have to develop a classifier to detect olive tree canopies using Geoeye-1
images. I had thought of segmentation and indeed the segmentation is
capable of separating and detecting canopies. However I need now a
classifier that retains only the segments that represent olive trees. The
range of values assigned to canopies is quite high and doesn't follow a
particular order, hence i haven't found an obvious mapcalc rule so far.
However, I have been reasoning about the particular pattern that
characterise olive orchards: olive trees are obviously round, disposed on
regular grids, at constant distance to each other, and the canopies,
although having different sizes (within a certain range), are almost always
well separated from each other. I am now looking to a way to translate this
concept into operational rule. I'm sure that this is nothing new, so I was
wondering if you could point me relevant literature and existing tools to
put this in practice.

Thank you in advance for any hints

-- 
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

Re: [GRASS-user] detecting olive trees from satellite imagery

[Margherita Di Leo]

Rich,

On Wed, Oct 29, 2014 at 3:35 PM, Rich Shepard rshep...@appl-ecosys.com
wrote:



   Is the reflected color spectrum of olive trees different from vegetation
 that would normally be expected outside the orchards?

   If so, I would suggest a training set obtained by visiting a few olive
 orchards and recording the geographic coordinates of the center as well as
 an average radius (or the sides of a rectangular orchard). The satellite
 band values for those location can then be used to classify vegetation and
 find other olive orchards.

   Of course, you've probably already done this, and it's been about 30
 years
 since I last worked with satellite imagery so I'm not current on the
 technologies.


 Thank you very much for your hint. I should have mentioned that I made
tentatives also in this direction. Unfortunately, so far this approach
didn't allow me to tell olive trees from other vegetation types.


-- 
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

Re: [GRASS-user] Grass70 win7 r.basin

[Margherita Di Leo]

Hi Jose,

On Wed, Oct 1, 2014 at 11:09 PM, José Anderson 
joseandersonbati...@gmail.com wrote:

 Ok, César, Margherita,

 maybe another issue (remembering I'm on grass7/win7) is installation
 of dependences of r.basin: r.stream.stats r.stream.distance and
 r.stream.order are missing because g.extension returns File is not a
 zip file when trying to add them.

 The rest r.stream.basins and r.stream.extract are present.

 Could that be an issue?


That is definitely an issue. You need to have all the dependencies
installed in order to get r.basin working. What is the command line that
gives you that error?


-- 
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