Re: [GRASS-user] External Database and projections

[Blumentrath, Stefan]

Hi Dylan,

Yes, r.external and r.external.out works pretty well with TGIS. Here is a 
discussion in this regards I had mainly with Sören…
https://lists.osgeo.org/pipermail/grass-user/2013-December/069377.html

I have used r.external/r.external.out in TGIS for a while (with compressed 
GeoTiffs, btw you should not pre-define the predictor for LZW-compression as 
long as you are not sure that all raster maps are of the same type 
(CELL/FCELL/DCELL)), but went back to using internal GRASS format, because 
external links are a bit tricky to use on NFS and from different OS (or if data 
is moved):
https://trac.osgeo.org/grass/ticket/2660

Another minor (and often neglectable) drawback of using r.external is that file 
names and map names get out of sync if you rename maps. g.rename renames only 
the GRASS internal map name (modifies the link) the underlying data file is not 
touched and stays with the old name…

Cheers
Stefan


From: Dylan Beaudette [mailto:dylan.beaude...@gmail.com]
Sent: 8. oktober 2015 00:17
To: Markus Neteler 
Cc: Blumentrath, Stefan ; GRASS user list 

Subject: Re: [GRASS-user] External Database and projections

The use of r.external makes a lot of sense when dealing with very large files. 
Does the use of "external" files work as expected in all of the new t.* modules?

Thanks,
Dylan

On Wed, Oct 7, 2015 at 12:09 PM, Markus Neteler 
> wrote:
On Wed, Oct 7, 2015 at 12:55 PM, Blumentrath, Stefan
> wrote:
...
> My suggestion is to not use PostGIS for big rasters, unless you have to,
> because you want to use the data in a specific application for example.

Note r.external and r.external.out of GRASS GIS 7 for avoiding data duplication:

https://grass.osgeo.org/grass70/manuals/r.external.html
https://grass.osgeo.org/grass70/manuals/r.external.out.html

Here an example:

# register (rather than import) a GeoTIFF file in GRASS GIS:
r.external input=terra_lst1km20030314.LST_Day.tif output=modis_celsius

# define output directory for files resulting from subsequent calculations:
r.external.out directory=$HOME/gisoutput/ format="GTiff"

# perform calculations (here: extract pixels > 20 deg C)
# store output directly as GeoTIFF file, hence add the .tif extension:
r.mapcalc "warm.tif = if(modis_celsius > 20.0, modis_celsius, null() )"

# cease GDAL output connection and turn back to write standard GRASS
raster files:
r.external.out -r

# use the result elsewhere
qgis $HOME/gisoutput/warm.tif

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

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

Re: [GRASS-user] Splitting a location across several disks

[Blumentrath, Stefan]

See also: https://grasswiki.osgeo.org/wiki/Location_and_Mapsets
There you find a detailed description of how to link mapsets...

-Original Message-
From: grass-user-boun...@lists.osgeo.org 
[mailto:grass-user-boun...@lists.osgeo.org] On Behalf Of Dylan Beaudette
Sent: 8. oktober 2015 00:50
To: Glynn Clements 
Cc: grass list 
Subject: Re: [GRASS-user] Splitting a location across several disks

On Wed, Oct 7, 2015 at 3:39 PM, Glynn Clements  wrote:
>
>
> Dylan Beaudette wrote:
>
> > It has been a while, but glad to be back on GRASS-user.
> >
> > I am working on a project that involves a significant storage 
> > dilemma: try and fit most of the files into a 500 Gb SSD for 
> > blazing-fast I/O, or fall back to a standard but higher capacity disk drive.
> >
> > Would it be possible to store "derived" data into a mapset that is 
> > on standard disk, while the "source" data reside in another mapset, 
> > stored on the SSD?
> >
> > In other words, is it OK for a location to contain several mapsets 
> > that don't "live" on the same physical disk. It seems like it should 
> > work (via symlink), but I would like to see if there are any caveats 
> > that I should be aware of.
>
> If symlinks don't work, Linux supports "mount --bind ...", which lets 
> you mount a directory from an already-mounted filesystem at another 
> location. Windows has similar features (e.g. reparse points), although 
> I'm not that familiar with the specifics.
>

Excellent! This is the answer that I was looking for. I will try symlinks 
first, otherwise the "mount --bind" strategy is simple enough. Fortunately this 
work will be done on linux so just about anything is possible.

>
> The main constraint is that you can't split a single mapset across 
> devices, as it must be possible to rename() files in the .tmp 
> subdirectory to other directories withing the mapset, which requires 
> that they are on the same physical partition (rename() only 
> manipulates directory entries, it won't move the file's data blocks).

OK, good to know.

Is there any reason to think that reading lots of raster files will be 
noticeably faster on the SSD?

Thanks,
Dylan

> --
> Glynn Clements 
___
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] Performing a Maximum Likelihood Supervised classification with a single band

[umberto.minora]

I'd like to use i.class and i.maxlik to perform a supervised classification
of my image. However, it seems i.class only accepts image gropous with more
than one band. Is there a way or an alternative I can perform such analysis
with a single band? Thanks in advance.



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Performing-a-Maximum-Likelihood-Supervised-classification-with-a-single-band-tp5228777.html
Sent from the Grass - Users mailing list archive at Nabble.com.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Splitting a location across several disks

[Dylan Beaudette]

Thanks, this is quite helpful. I'll report back with my strategy and
any limitations of this approach.

On Wed, Oct 7, 2015 at 11:43 PM, Blumentrath, Stefan
 wrote:
> See also: https://grasswiki.osgeo.org/wiki/Location_and_Mapsets
> There you find a detailed description of how to link mapsets...
>
> -Original Message-
> From: grass-user-boun...@lists.osgeo.org 
> [mailto:grass-user-boun...@lists.osgeo.org] On Behalf Of Dylan Beaudette
> Sent: 8. oktober 2015 00:50
> To: Glynn Clements 
> Cc: grass list 
> Subject: Re: [GRASS-user] Splitting a location across several disks
>
> On Wed, Oct 7, 2015 at 3:39 PM, Glynn Clements  
> wrote:
>>
>>
>> Dylan Beaudette wrote:
>>
>> > It has been a while, but glad to be back on GRASS-user.
>> >
>> > I am working on a project that involves a significant storage
>> > dilemma: try and fit most of the files into a 500 Gb SSD for
>> > blazing-fast I/O, or fall back to a standard but higher capacity disk 
>> > drive.
>> >
>> > Would it be possible to store "derived" data into a mapset that is
>> > on standard disk, while the "source" data reside in another mapset,
>> > stored on the SSD?
>> >
>> > In other words, is it OK for a location to contain several mapsets
>> > that don't "live" on the same physical disk. It seems like it should
>> > work (via symlink), but I would like to see if there are any caveats
>> > that I should be aware of.
>>
>> If symlinks don't work, Linux supports "mount --bind ...", which lets
>> you mount a directory from an already-mounted filesystem at another
>> location. Windows has similar features (e.g. reparse points), although
>> I'm not that familiar with the specifics.
>>
>
> Excellent! This is the answer that I was looking for. I will try symlinks 
> first, otherwise the "mount --bind" strategy is simple enough. Fortunately 
> this work will be done on linux so just about anything is possible.
>
>>
>> The main constraint is that you can't split a single mapset across
>> devices, as it must be possible to rename() files in the .tmp
>> subdirectory to other directories withing the mapset, which requires
>> that they are on the same physical partition (rename() only
>> manipulates directory entries, it won't move the file's data blocks).
>
> OK, good to know.
>
> Is there any reason to think that reading lots of raster files will be 
> noticeably faster on the SSD?
>
> Thanks,
> Dylan
>
>> --
>> Glynn Clements 
> ___
> 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] Performing a Maximum Likelihood Supervised classification with a single band

[Veronica Andreo]

Ciao Nikos :)

Yes, you are right! I missed that one!

There's ISODATA unsupervised classification algorithm (not in GRASS that I
know) and it allows for just one band input.

Cheers,
Vero

2015-10-08 16:52 GMT-03:00 Nikos Alexandris :

> * Veronica Andreo:
>
> > Ciao Umberto,
> >
> > AFAIK, classification is multivariate on its statistical basis, so that's
> > why it will only take a group as input. If you only have one band, you
> may
> > want to extract some information from it, for example by using r.texture
> > module [1]. With those resulting new bands and the original one you can
> > create then a group and perform the classification you prefer.
> > [1] https://grass.osgeo.org/grass71/manuals/r.texture.html
>
>
> Ciao Vero.  There is, for example, the ISODATA algorithm out there.
> Just not in GRASS (yet?).
>
> Nikos
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] WARNING TO MAC USERS - WAIT UPDATING TO EL CAPITAN (OS X 10.11)

[Michael Barton]

I've had reports of GRASS not running for users updating to El Capitan. There 
is a possible workaround, but it is cumbersome and not guaranteed to work. I 
recommend that you do wait to update while we try to solve this.

I've also heard that El Capitan breaks R.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu















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

Re: [GRASS-user] Performing a Maximum Likelihood Supervised classification with a single band

[Veronica Andreo]

Ciao Umberto,

AFAIK, classification is multivariate on its statistical basis, so that's
why it will only take a group as input. If you only have one band, you may
want to extract some information from it, for example by using r.texture
module [1]. With those resulting new bands and the original one you can
create then a group and perform the classification you prefer.

HTH! Cheers,

Vero

[1] https://grass.osgeo.org/grass71/manuals/r.texture.html

2015-10-08 10:53 GMT-03:00 umberto.minora :

> I'd like to use i.class and i.maxlik to perform a supervised classification
> of my image. However, it seems i.class only accepts image gropous with more
> than one band. Is there a way or an alternative I can perform such analysis
> with a single band? Thanks in advance.
>
>
>
> --
> View this message in context:
> http://osgeo-org.1560.x6.nabble.com/Performing-a-Maximum-Likelihood-Supervised-classification-with-a-single-band-tp5228777.html
> Sent from the Grass - Users mailing list archive at Nabble.com.
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Reprojection of raster maps in various platforms: projected coordinates are different

[Uttam Kumar]

Hi All,

This is the projection information of a single Landsat scene in ENVI, GRASS
and using gdalwarp. GRASS and gdalwarp gave somewhat similar output but
ENVI is totally different. I have been informed that the projected image
from ENVI is correct as verified from the earlier work.

Original data (in Sinusoidal Projection)
--
Corner Coordinates:
Upper Left  (-10801805.198W, 4130102.079N)
Lower Left  (-10801805.198W, 3971252.079N)
Upper Right (-10642955.198W, 4130102.079N)
Lower Right (-10642955.198W, 3971252.079N)


Reprojected in GRASS GIS (Lambert Azimuthal Equal Area, Datum: WGS84)
--
N:5564460
S:5185590|
E:   -5451390
W:  -5762490

Reprojected in ENVI (Lambert Azimuthal Equal Area, Datum: WGS84)
-
Corner Coordinates:

Upper Left  (-2265106.681W, 1064601.383N)
Lower Left  (-2265106.681W,  830181.383N)
Upper Right (-1960126.681W, 1064601.383N)
Lower Right (-1960126.681W,  830181.383N)

Reprojected using gdalwarp (Lambert Azimuthal Equal Area, Datum: WGS84)
--
Corner Coordinates:
Upper Left  (-5148766.236W, 3000477.570N)
Lower Left  (-5148766.236W, 2724274.973N)
Upper Right (-4826973.503W, 3000477.570N)
Lower Right (-4826973.503W, 2724274.973N)

Any comment is appreciated.

Uttam.


On Sun, Sep 27, 2015 at 1:48 AM, Markus Neteler  wrote:

>
> On Sep 26, 2015 1:00 AM, "Uttam Kumar"  wrote:
> >
> > Thank you all. It worked.
> >
> > However I noticed that the projected boundary values of N, S, W and E in
> GRASS are not same as the values obtained from projecting the same image in
> ENVI image processing software and in gdalwarp.
> >
> > Projection of the scene in Lambert Azimuthal Equal Area is similar (but
> not exactly equal) in GRASS and gdal, but in ENVI it is totally different.
> I just did the comparison to see if things are similar from different
> softwares in case they have to be ported to other platforms.
>
> Can you print the projection information in both GRASS (g.proj -p or -w)
> and ENVI? Are they really the same?
>
> Markus
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user