Re: [GRASS-user] CHELSA climate data set

[Markus Metz]

On Fri, Feb 10, 2017 at 5:53 PM, Paulo van Breugel 
wrote:
>
>
>
> On 10-02-17 17:15, Markus Metz wrote:
>
>
>
> On Tue, Feb 7, 2017 at 3:43 PM, Markus Neteler  wrote:
> >
> > On Tue, Feb 7, 2017 at 3:32 PM, Markus Metz
> >  wrote:
> > [...]
> > > Unfortunately it changes East from 179.9998611 to 179.9998597 and
north
> > > from 83.9998611 to 83.9998604.
> > >
> > > The more serious problem is that GRASS can not handle ll coordinates
like
> > > 180:0:0.50W or 90:0:0.5S.
> > >
> > > I have relaxed the ll restrictions in my local copy and can now import
> > > CHELSA and other for GRASS problematic ll datasets without getting
e.g. a
> > > narrow N-S strip, or GRASS fixing a subtle rounding error that in
fact is
> > > not an error. That means after each import I have to manually check if
> > > resolution and extents make sense, and if in doubt fix them with
r.region.
> >
> > That's probably rather more a power user task than common user
> > knowledge...
>
> Why a power user task? r.region is an easy to use module, as long as you
know the correct grid geometry. And with my relaxed ll restrictions I get
less errors and more usable results, in fact I need to use r.region less
often than before.
>
>
> Not sure that is what Markus meant, but "relaxed the restriction in my
local copy" sounds definitely like a power user task to me. If this is
something that can, and will, be done at the libgis level, great.

Fixing most of the ll wrap issues can be done at the libgis level. When I
wrote "relaxed the restriction in my local copy", I meant I would like to
commit by local changes, but would also like to know if it is ok to relax
the -180, 180 restriction for W-E and the -90, 90 restriction for S-N in
GRASS.

Issues as reported e.g. in tickets #352 and #2757 could easily be fixed
with r.region, but it would be much more convenient if there would be no
need to use r.region.

Markus M

> Otherwise, I would be interested to know how to do this.
>
>
> > Is there anything we could do at libgis level like
> > relaxing the ll restrictions along with appropriate user messages?
>
> Yes. The first points would be ll_scan.c, ll_format.c and adj_cellhd.c.
That should also remove cryptic errors like "ERROR: Syntax error in cell
header".
>
> > More and more global datasets are getting published, so the issue will
> > likely come up more frequently. Just to make it a bit easier :-)
>
> For a start, it would be nice if you can create a full SRTM mosaik (not
so new data) in GRASS.
>
> Markus M
>
> >
> > markusN
>
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
>
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

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

[Paulo van Breugel]

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

Hi Raphael,

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

Hello Moritz,

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

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


Both are good to hear. Thanks for the feedback !




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


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


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




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


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




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


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


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


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


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


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


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


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



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


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

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

[Moritz Lennert]

Hi Raphael,

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

Hello Moritz,

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

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


Both are good to hear. Thanks for the feedback !




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


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


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




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


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




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


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


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


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


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


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


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


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

Re: [GRASS-user] CHELSA climate data set

[Paulo van Breugel]

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



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

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

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

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

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

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

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

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


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




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

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


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

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


Markus M

>
> markusN



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


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

[GRASS-user] ... getting rid of duplicate polygons ...

[Uwe Fischer]

Hello list,

 

I have a question about dealing with duplicate polygons (dp) coming into
GRASS from a polygon shapefile. The polygons are not overlapping or having
gaps, but there are a number of real duplicate ones (polygons show parcels
with owners, and if one parcel has two or more owners, e. g. wife and
husband, this situation in the shapefile is represented by two identical
polys with two database rows that only differ in the owners name).

 

My goal is to get rid of duplicates, having a result with only one
polygon/centroid at a given location with only one owner name. The name does
not matter, it can be chosen arbitrary by the system. This works fine when
using ESRI "clean"-command. The structure of the database table is
maintained while one (or many) of the dp is/are lost, leaving only one valid
polygon.

 

Now, I found an older thread called "unable to get rid of duplicate
polygons". Obviously, the problem/question is the same but I could not find
a solution for GRASS there. So I tried:

 

v.clean -c input=input@mapset output=output_clean tool=snap,rmdac,bpol
threshold=0.01,0,0

 

and

 

v.clean -c input=input@mapset output=output_clean
tool=break,snap,rmdupl,rmdac,bpol

 

Nothing did work. I get a map with tree layers, one showing the islands only
(layer 0), one showing the complete polygon set with duplicates (1), and one
showing only the duplicates (2). I also tried to delete layer 2, assuming
that this might remove the dp, but it only messed up the dataset.

 

What am I doing wrong?

 

Regards, Uwe

 

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

Re: [GRASS-user] CHELSA climate data set

[Markus Metz]

On Tue, Feb 7, 2017 at 3:43 PM, Markus Neteler  wrote:
>
> On Tue, Feb 7, 2017 at 3:32 PM, Markus Metz
>  wrote:
> [...]
> > Unfortunately it changes East from 179.9998611 to 179.9998597 and north
> > from 83.9998611 to 83.9998604.
> >
> > The more serious problem is that GRASS can not handle ll coordinates
like
> > 180:0:0.50W or 90:0:0.5S.
> >
> > I have relaxed the ll restrictions in my local copy and can now import
> > CHELSA and other for GRASS problematic ll datasets without getting e.g.
a
> > narrow N-S strip, or GRASS fixing a subtle rounding error that in fact
is
> > not an error. That means after each import I have to manually check if
> > resolution and extents make sense, and if in doubt fix them with
r.region.
>
> That's probably rather more a power user task than common user
> knowledge...

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

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

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

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

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

Markus M

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

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

[Raphael Knevels]

Hello Moritz,

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

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

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

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

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

Best regards


-Ursprüngliche Nachricht-
Von: Moritz Lennert [mailto:mlenn...@club.worldonline.be] 
Gesendet: Mittwoch, 25. Januar 2017 12:11
An: Raphael Knevels; grass-user@lists.osgeo.org
Betreff: Re: [GRASS-user] Question to the input seed grid of i.segment

Out of curiosity, I did some testing myself, using the ortho photo available in 
the GRASS North Carolina demo data set [1]. Several conclusions (based on 
default parameter settings in SAGA and GRASS):

- Actually the seed map coming out of SAGA is not floating point. The created 
tiff is Float32, but in fact pixel values are integer. So, in GRASS you can 
just run r.mapcalc "int_map = int(map)" and then use it as seed input to 
i.segment.

- The SAGA seeded region algorithm as AFAIU is more similar to the 
i.superpixels.SLIC algorithm than to our region-growing algorithm. That 
explains the different execution times. See [2] (grass segmentation with 
threshold 0.1), [3] (saga segmentation), [4] (grass superpixels).

- Providing the seeds coming from SAGA as input to i.segment does not change 
neither the execution time, nor the result.

So: I would suggest you try segmenting with a lower threshold. In order to not 
loose time by segmenting the whole image at each try, you can either create a 
few small named regions and use the i.segment.uspo addon to try to 
automagically determine the best threshold, or you just define a small 
computational region and test manually before applying the result to the entire 
image.

Moritz

[1] http://tomahawk.ulb.ac.be/moritz/ortho_photo.png
[2]
http://tomahawk.ulb.ac.be/moritz/segmentation_grass_noseeds_thresh_01.png
[3] http://tomahawk.ulb.ac.be/moritz/segmentation_saga.png
[4] http://tomahawk.ulb.ac.be/moritz/grass_superpixels.png


On 25/01/17 11:22, Moritz Lennert wrote:
> On 24/01/17 20:40, Raphael Knevels wrote:
>> Thanks for the quick response :-)
>>
>> The extent of my region is also the extent of my imagery-group. For 
>> i.segment I used as memory 10240 MB with a threshold of 0.25.
>
> That's a pretty large threshold which generally leads to
> under-segmentation. You might want to start with a value closer to 0.01.
>
>>
>> In SAGA I used at first Seed Generation (Band Width of 18, but I
>> also
>> varied this parameter) for producing the Seed Output. The Seed Output is
>> a raster with floating point values. Moreover, the Seed Output contains
>> single pixels distributed over the hole area. The "space" between those
>> pixels is "no data". The segmentation is then computed by Seeded Region
>> Growing with the seed grid as input.
>>
>> "Seeds in i.segment have to be polygons not points. These polygons
>> are
>> represented by identical positive integer values (= IDs) in adjacent
>> pixels, and they have to cover the entire region. When used as seeds for
>> a segmentation, these polygons are the further merged."
>
> Sorry, but this was actually wrong information from my part: i.segment
> also supports seed pixels. From the man page:
>
> "The seeds map can be used to provide either seed pixels (random or
> selected points from which to start the segmentation process) or seed
> segments. If the seeds are the results of a previous segmentation with
> lower threshold, hierarchical segmentation can be performed. The
> different approaches are automatically detected by the program: any
> pixels that have identical seed values and are contiguous will be
> assigned a unique segment ID. "
>
>
> However, the seed map has to have integer values. To get that from you
> SAGA output (floating-point) seed map, just run r.clump.
>
>> -> alright. That means

Re: [GRASS-user] zooming raster before rendering image to png

[Martin Landa]

Hi,

2017-02-10 11:18 GMT+01:00 Ang Sherpa :
> Thanks Martin for the attention,

please keep discussion on ML.

> Even after setting the region to basin produced after running
> "r.water.outlet", the rendered image has no change in size.
>
>
> d.mon start=cairo output='path'
> g.region raster=basin_produced_by_r.water.outlet

You set up computation region based on you raster (extent, resolution).

You need to set up extent of your zoom window manully.

g.region n= s= w= e=

Or you cold zoom to your area by `zoom` option (skip all NULL values)
if it's OK for you. See g.region manual for details.

Ma

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

Re: [GRASS-user] zooming raster before rendering image to png

[Martin Landa]

Hi,

2017-02-10 10:44 GMT+01:00 Ang Sherpa :
> d.mon start='cairo' output=/path/

you need to run g.region to set up computational region based on your request.

> d.rast  map='basin_54'
> d.mon stop='cairo'

Ma

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

[GRASS-user] zooming raster before rendering image to png

[Ang Sherpa]

Hi, all.

Is it possible to zoom the watershed before rendering into png format. The
one that I got is too small to view and use for analysis.

d.mon start='cairo' output=/path/
d.rast  map='basin_54'
d.mon stop='cairo'

Thanks,
*Ang Dawa Sherpa*
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user