Re: [GRASS-user] Query Related to i.landsat8.swlst

[Blumentrath, Stefan]

Hei Johnn,

The command you specified is (except for the n-flag) an example from the 
manual. You would have to replace the input to the options according to your 
data!

I used i.landsat8.swlst in a project in Oslo and was quite satisfied with the 
results. You can see them here:
http://urban.nina.no/layers/geonode%3Alc81980182015183lgn00_lst_const_lc#more

I documented the production here:
https://github.com/NINAnor/openness/blob/master/oslo_heatmap.sh

Maybe the shell script gives you some more hints on the usage of the module in 
a processing chain...

Some hints from my experience with the module:
I would NOT use a one of the rather outdated GLC maps (which for my study area 
in addition were full of NoData). If you have a good land cover map I would 
reclassify it according to the classes used in the GLC maps (see the manual of 
i.landsat8.swlst).

Kind regards,
Stefan


From: grass-user [mailto:grass-user-boun...@lists.osgeo.org] On Behalf Of Johnn 
Wani
Sent: 21. september 2016 15:06
To: grass-user@lists.osgeo.org
Subject: [GRASS-user] Query Related to i.landsat8.swlst

Dear all,

I am a student from India, and first time user of GRASS GIS and i am having 
basic knowledge of GIS.
My aim is to use i.landsat8.swlst add-on to calculate LST from Landsat8 data 
for my study area.
I want to know in the following command:

i.landsat8.swlst mtl=MTL prefix=B landcover=FROM_GLC -n

​Which Basename i am going to provide as prefix for landsat8 data ??

Also, my first query on grass-user's mail list.
Please help.

Regards
--
JOHN MOHD WANI
Ph.D Research Scholar
Department of Civil Engineering
IIT Roorkee, Uttarakhand, INDIA-247667
Mail: johnn.n...@gmail.com
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Topology built on demand

[Blumentrath, Stefan]

Hi Luiz,

It either very simple to answer your question or a quite difficult to answer 
based on the information your provided.

The simple answer would be: Yes, of course this is possible in GRASS, thanks to 
it\s topological vector model! But that is probably not the answer you are 
after ;-)

In order to give you suggestions on what to do however, we would need more 
information on what you actually want to achieve.

Furthermore, I am afraid not everybody is familiar with the terms you use (at 
least I am not):
What is you “spatial data structure”? Is that a set of thematic shape files? 
Several land cover types from one land cover dataset?
What are sfs layers?
What do you mean by “on demand” or “hierarchy”? Do you actually want to “snap” 
your hydrography data (and so on) to the vegetation data?
Is there any (spatial) relation between the layers in your “spatial data 
structure” at the moment?
Could you provide us with some examples?

Cheers
Stefan

From: grass-user [mailto:grass-user-boun...@lists.osgeo.org] On Behalf Of Luiz 
Andrade
Sent: 21. september 2016 14:44
To: grass-user@lists.osgeo.org
Subject: [GRASS-user] Topology built on demand

How can I build a topology in grass with priority order on demand?
I need to build a topology for my Spatial Data Structure. My structure has 
several sfs layers, but to validate my data I need to build a topology with 
several classes and according to a priority.
This means that I want to insert my sfs layers into one topology structure in 
grass on demand.
For instance, first I need to insert vegetation layers and later, insert 
hydrography layers and so on...

Is it possible to make this on grass?
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Analyzing level ground

[Thomas Adams]

Hi Laurent,

I had previously started playing with Itzï but reported problems; now, it
seems to work to a point. I have followed your tutorial here:
https://www.itzi.org/user-manual/ but when I do this I get:

GRASS 7.0.3 (nc_spm_08_grass7):/media/teaiii/development/grass > itzi run
param.file.txt
ERROR: Unable to execute sql statement. There is no temporal database
connection defined for mapset 
Traceback (most recent call last):
  File "/home/teaiii/.local/bin/itzi", line 11, in 
sys.exit(main())
  File "/home/teaiii/.local/lib/python2.7/site-packages/itzi/itzi.py", line
40, in main
args.func(args)
  File "/home/teaiii/.local/lib/python2.7/site-packages/itzi/itzi.py", line
93, in itzi_run
sim_param=conf.sim_param)
  File
"/home/teaiii/.local/lib/python2.7/site-packages/itzi/simulation.py", line
75, in __init__
self.gis.read(self.in_map_names)
  File "/home/teaiii/.local/lib/python2.7/site-packages/itzi/gis.py", line
189, in read
elif self.name_is_stds(self.format_id(map_name)):
  File "/home/teaiii/.local/lib/python2.7/site-packages/itzi/gis.py", line
138, in name_is_stds
if tgis.SpaceTimeRasterDataset(name).is_in_db():
  File
"/usr/local/grass-7.0.3/etc/python/grass/temporal/abstract_dataset.py",
line 370, in is_in_db
return self.base.is_in_db(dbif)
  File "/usr/local/grass-7.0.3/etc/python/grass/temporal/base.py", line
314, in is_in_db
dbif.execute(sql, mapset=self.mapset)
  File "/usr/local/grass-7.0.3/etc/python/grass/temporal/core.py", line
956, in execute
"mapset <%(mapset)s>" % {"mapset": mapset}))
  File
"/usr/local/grass-7.0.3/etc/python/grass/pygrass/messages/__init__.py",
line 269, in fatal
raise FatalError(message)
grass.exceptions.FatalError: Unable to execute sql statement. There is no
temporal database connection defined for mapset 
[Raster MASK present]

I'm using GRASS 7.0.3 and Itzï 16.8

Any thoughts?

Regards,
Tom

On Thu, Sep 22, 2016 at 2:27 PM, Laurent C.  wrote:

> Hello Rich,
>
> For the infiltration, if you can determine the soil texture, then you
> could estimate the Green-Ampt parameters using [1]
> What do you want to do in that area? Perform hydrological/overland
> flow analysis?
> If it is the case, you might give Itzï a try:
> https://www.itzi.org/
> Some of the parameters could be estimated (like friction coefficient).
>
> Regards,
> Laurent
>
> [1] Rawls, W., Brakensiek, D., and Miller, N. (1983). "Green‐ampt
> Infiltration Parameters from Soils Data." J. Hydraul. Eng.,
> 10.1061/(ASCE)0733-9429(1983)109:1(62), 62-70.
>
>
> 2016-09-22 13:09 GMT-05:00 Rich Shepard :
> >   The project area -- in farmland -- is small (< 20 ha) and  essentially
> > flat with elevation differences less than 1 meter. The LiDAR raster cells
> > (imported from ARC Grid format) have a cell size of 3x3 international
> feet;
> > elevation resolution is 0.013 feet.
> >
> >   While r.slope.aspect generates an aspect map, the slope map is blank.
> The
> > maps for dx, dy, and relief display variations.
> >
> >   While I have some soil data, it's sparse and I haven't (yet) found
> > infiltration rates; the rainfall data is very low and from a station
> several
> > miles away. I probably do not have all required input data for
> r.sim.water
> > or r.watershed.
> >
> >   Based on your much more extensive experiences applying GRASS to limited
> > areas please suggest approaches that might be appropriate for this
> project.
> > It might be that all I can do is create detailed contour maps of the area
> > and describe the situation qualitatively without robust quantitative
> > analyses.
> >
> > TIA,
> >
> > Rich
> >
> > ___
> > grass-user mailing list
> > grass-user@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/grass-user
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>



-- 
Thomas E Adams, III
1724 Sage Lane
Blacksburg, VA 24060

1 (513) 739-9512 (cell)
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Analyzing level ground

[Thomas Adams]

Rich,

What is your goal; what are you trying to accomplish?

Tom

On Thu, Sep 22, 2016 at 2:09 PM, Rich Shepard 
wrote:

>   The project area -- in farmland -- is small (< 20 ha) and  essentially
> flat with elevation differences less than 1 meter. The LiDAR raster cells
> (imported from ARC Grid format) have a cell size of 3x3 international feet;
> elevation resolution is 0.013 feet.
>
>   While r.slope.aspect generates an aspect map, the slope map is blank. The
> maps for dx, dy, and relief display variations.
>
>   While I have some soil data, it's sparse and I haven't (yet) found
> infiltration rates; the rainfall data is very low and from a station
> several
> miles away. I probably do not have all required input data for r.sim.water
> or r.watershed.
>
>   Based on your much more extensive experiences applying GRASS to limited
> areas please suggest approaches that might be appropriate for this project.
> It might be that all I can do is create detailed contour maps of the area
> and describe the situation qualitatively without robust quantitative
> analyses.
>
> TIA,
>
> Rich
>
>
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Analyzing level ground

[Laurent C.]

Hello Rich,

For the infiltration, if you can determine the soil texture, then you
could estimate the Green-Ampt parameters using [1]
What do you want to do in that area? Perform hydrological/overland
flow analysis?
If it is the case, you might give Itzï a try:
https://www.itzi.org/
Some of the parameters could be estimated (like friction coefficient).

Regards,
Laurent

[1] Rawls, W., Brakensiek, D., and Miller, N. (1983). "Green‐ampt
Infiltration Parameters from Soils Data." J. Hydraul. Eng.,
10.1061/(ASCE)0733-9429(1983)109:1(62), 62-70.


2016-09-22 13:09 GMT-05:00 Rich Shepard :
>   The project area -- in farmland -- is small (< 20 ha) and  essentially
> flat with elevation differences less than 1 meter. The LiDAR raster cells
> (imported from ARC Grid format) have a cell size of 3x3 international feet;
> elevation resolution is 0.013 feet.
>
>   While r.slope.aspect generates an aspect map, the slope map is blank. The
> maps for dx, dy, and relief display variations.
>
>   While I have some soil data, it's sparse and I haven't (yet) found
> infiltration rates; the rainfall data is very low and from a station several
> miles away. I probably do not have all required input data for r.sim.water
> or r.watershed.
>
>   Based on your much more extensive experiences applying GRASS to limited
> areas please suggest approaches that might be appropriate for this project.
> It might be that all I can do is create detailed contour maps of the area
> and describe the situation qualitatively without robust quantitative
> analyses.
>
> TIA,
>
> Rich
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Analyzing level ground

[Rich Shepard]

  The project area -- in farmland -- is small (< 20 ha) and  essentially
flat with elevation differences less than 1 meter. The LiDAR raster cells
(imported from ARC Grid format) have a cell size of 3x3 international feet;
elevation resolution is 0.013 feet.

  While r.slope.aspect generates an aspect map, the slope map is blank. The
maps for dx, dy, and relief display variations.

  While I have some soil data, it's sparse and I haven't (yet) found
infiltration rates; the rainfall data is very low and from a station several
miles away. I probably do not have all required input data for r.sim.water
or r.watershed.

  Based on your much more extensive experiences applying GRASS to limited
areas please suggest approaches that might be appropriate for this project.
It might be that all I can do is create detailed contour maps of the area
and describe the situation qualitatively without robust quantitative
analyses.

TIA,

Rich




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

[GRASS-user] Question on memory allocation and use

[Rich Shepard]

  A possible bug in ../diglib/cindex.c.

  This host has 4G RAM and 16G swap memory. With X running top shows 740M
RAM and 15.3G swap free. I'm trying to run a spatial analysis program which
fails after 2.5-4.7 hours (depending on the contour resolutions). This
morning after 2.5 hours it failed with this message:

ERROR: G_realloc: unable to allocate 5298 bytes of memory at
   lib/vector/diglib/cindex.c:113

which is approximately 52M.

  This is cindex.c (it's the same in the latest svn checkouts of 7.0, 7.2,
and 7.3):

/* Add new cat - line record */
ci = &(Plus->cidx[si]);
if (ci->n_cats == ci->a_cats) {
ci->a_cats += 5000;
ci->cat = G_realloc(ci->cat, ci->a_cats * 3 * sizeof(int));
}
lines 109-114.

  While waiting for an answer -- or a fix -- I'll kill X and try running
r.contour from a console and see if the extra memory does the job. My
project is stalled until I can create vector contours from the LiDAR raster
maps.

TIA,

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

Re: [GRASS-user] Different distances to outlet for r.stream.order and r.stream.distance

[Mira Kattwinkel]

Dear Markus, dear List

It is much better now but still not exactly the same. Close to the 
outlet, the difference in distance to the outlet is about 30 cm (Fig_1b) 
and in the middle of the network it's about 80 cm (Fig_2b). The upDist 
raster produced with r.stream.distance gives the exact length I would 
expect (for Fig_1b: 6 * sqrt(2 * 25.0235 ^2) = 212.33) while 
r.stream.order still results in slightly to high values. .


That's good enough for the task I am working on but I wonder why this is 
the case.


Btw, I checked and my dem really has a cell size of 25.0235. I do not 
know why this is the case.


Cheers,

Mira


On 21/09/16 14:33, Markus Metz wrote:

On Wed, Sep 21, 2016 at 1:26 PM, Mira Kattwinkel
  wrote:

Thanks a lot!

I saw that you uploaded a revision. Can you please give me a hint how I
upgrade to the revised version of r.stream.order? I am running Linux Mint
17.3 and Windows 7.


I have fixed another bug in r.stream.order (r69543): the stream
segment lengths are now identical to the lengths of the vector lines
and the out_dist value of r.stream.order matches now the output of
r.stream.distance. BTW, any reason why the resolution is 25.023 and
not exactly 25?

Markus M


I found that there are nightly pre-built Addon executables for Windows, so I
will try that tomorrow. What about Linux? Is it sufficient to just reinstall
the addon?


All the best,

Mira



Am 21.09.2016 um 11:08 schrieb Markus Metz:

On Tue, Sep 20, 2016 at 10:53 AM, Mira Kattwinkel
  wrote:

Dear List

r.stream.order gives, among other output, the distance of current the
stream
init from the outlet of the catchment ('out_dist'). So for the most
downstream segment this is identical to the length of the segment.
r.stream.distance calculates the distance to the outlet and results in a
raster file. Both are based on a stream raster and a direction raster.

When I compare the results, they are slightly different, although based
on
the same input files (see the attached Fig1). The raster value is 212.33
at
the junction, while the out_dist of the line is 237.69. The difference is
one cellsize (25.023 in may example), probably due to the horizontal bit
of
the line at the end (upper right of the figure).

Yes, this horizontal bit of the line is a bug in r.stream.order, the
stream vector is leaving the current region or going into a NULL cell.
All other r.stream.* modules place the outlet on a valid cell. Fixed
in r69542.


However, this difference is
not fixed. In the middle of the network (Fig2) it is larger (81028.9 -
81002.89 = 27).

What is the difference in the middle of the network now with r69542?

Markus M


What is the reason for this difference? Is this a bug or a wanted
behaviour?

I want to extract the position of points on the network (i.e. upstream of
a
junction on the lines). To this end, I planned to use the upstream
distance
of the points and the out_dist of the segments (length(segment) -
(out_dist(segment) - upDist(point)) = position(point)).
Has anybody another idea how to accomplish this?

Thanks a lot,
Mira


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

--
Dr. Mira Kattwinkel
Quantitative Landscape Ecology
Institute for Environmental Sciences
University of Koblenz-Landau
Fortstraße 7
76829 Landau
Germany
Fon: + 49 6341 280-31553



--
Dr. Mira Kattwinkel
Quantitative Landscape Ecology
Institute for Environmental Sciences
University of Koblenz-Landau
Fortstraße 7
76829 Landau
Germany
Phone: + 49 6341 280-31553
Office: Building I, Room 2.02

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