Re: [GRASS-user] Problems using i.worldview.toar

[William Hudspeth]

Nikos,

Thank you very much for your assistance. Changing the file names worked, 
as you suggested. I will now be able to move forward with my image 
processing.


Thanks again...William


On 09/09/2016 06:12 PM, Nikos Alexandris wrote:


William Hudspeth:

I am using i.worldview.toar with the latest version of GRASS 7.3. I 
was

able to successfully download and install this extension. I have tried
using the module with the following input and error. All of the input
files exist, and I get an error stating that "No data base element 
files

found". Help appreciated...

i.worldview.toar
band=worldview2_b1_RED@worldview2,worldview2_b2_GREEN@worldview2,worldview2_b3_BLUE@worldview2,worldview2_b4_NIR@worldview2 


outputsuffix=toar utc=2010-04-11T18:07:06.558405Z doy=101 sea=60.3


Nikos Alexandris:


Do you really need the 'worldview2' prefix for your band names? It's
identical to your Mapset's name. This is what a mapset is meant (or can
be used) for: a set of maps.  In this case, it's a set of 'worldview2'
"maps".

Would you rename your bands and try again?

i.worldview.toar band=b1_RED,b2_GREEN,b3_BLUE,b4_NIR outputsuffix=toar
utc=2010-04-11T18:07:06.558405Z doy=101 sea=60.3


William Hudspeth:


I have given the bands simpler names, have re-run i.worldview.toar, and
am getting the same error:

i.worldview.toar
band=b1_red@worldview2,b2_green@worldview2,b3_blue@worldview2,b4_nir@worldview2 


outputsuffix=toar utc=2010-04-11T18:07:06.558405Z doy=101 sea=60.3
|! Using Day of Year to calculate Earth-Sun distance.

|! Region matching the b1_red@worldview2 spectral band

|* Processing the b1_red@worldview2 band
Traceback (most recent call last):
  File
"/home/wilbur/.grass7/addons/scripts/i.worldview.toar", line
416, in 
sys.exit(main())
  File
"/home/wilbur/.grass7/addons/scripts/i.worldview.toar", line
320, in main
acf = float(CF_BW_ESUN[band][2])
KeyError: 'b1_red'
WARNING: No data base element files found


William,

apologies for the inconvenience. I now had a better look and remember 
what is

what. Comments from the code itself:

"""
Factors for Conversion to Top-of-Atmosphere Spectral Radiance
   (absolute radiometric calibration factors)

Structure of the dictionary:
- Key: Name of band
- Items in tupple(s):
   - 1st: Absolute Calibration Factors
   - 2nd: Spectral Band's Effective Bandwidth, Δλ
   - 3rd: Band-Averaged Solar Spectral Irradiance [W/sq.m./micro-m]

Retrieving values:
   band = 
   K[band][0]  # for Effective Bandwidth
   K[band][1]  # for Esun
   K[band][2]  # for Absolute Conversion Factor
"""

which are stored in the following python dictionary:

CF_BW_ESUN = {
   'Pan': (0.2846, 1580.8140, 0.056783450),
   'Coastal': (0.0473, 1758.2229, 0.009295654),
   'Blue':(0.0543, 1974.2416, 0.012608250),
   'Green':   (0.0630, 1856.4104, 0.009713071),
   'Yellow':  (0.0374, 1738.4791, 0.005829815),
   'Red': (0.0574, 1559.4555, 0.011036230),
   'RedEdge': (0.0393, 1342.0695, 0.005188136),
   'NIR1':(0.0989, 1069.7302, 0.012243800),
   'NIR2':(0.0996,  861.2866, 0.009042234)}


The module is flexible to request for any of the bands to be
converted. Yet, it has the disatvanage that requires the very name(s) 
of the

corresponding "key(s)" to access the respective calibration factors.

In short, rename your bands to exactly 'Red', 'Green', 'Blue', 'NIR'. 
Maybe this can be

changed, but I wouldn't have the time at the moment for it.

If you have any changes, already, please make a pull request in the 
github repository.


Nikos

Nikos


--
*William Hudspeth, PhD, MPH*
Earth Data Analysis Center
MSC01 1110
1 University of New Mexico
Albuquerque, New Mexico 87131-0001
tel: 505-277-3622, ext. 249
email: bhudsp...@edac.unm.edu
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Problems using i.worldview.toar

[William Hudspeth]

Nikos.

On 09/09/2016 01:37 AM, Nikos Alexandris wrote:

William Hudspeth:


I am using i.worldview.toar with the latest version of GRASS 7.3. I was
able to successfully download and install this extension. I have tried
using the module with the following input and error. All of the input
files exist, and I get an error stating that "No data base element files
found". Help appreciated...

i.worldview.toar 
band=worldview2_b1_RED@worldview2,worldview2_b2_GREEN@worldview2,worldview2_b3_BLUE@worldview2,worldview2_b4_NIR@worldview2 
outputsuffix=toar utc=2010-04-11T18:07:06.558405Z doy=101 sea=60.3


Do you really need the 'worldview2' prefix for your band names? It's
identical to your Mapset's name. This is what a mapset is meant (or can
be used) for: a set of maps.  In this case, it's a set of 'worldview2'
"maps".


Would you rename your bands and try again?

i.worldview.toar band=b1_RED,b2_GREEN,b3_BLUE,b4_NIR outputsuffix=toar 
utc=2010-04-11T18:07:06.558405Z doy=101 sea=60.3


Nikos

[rest deleted]


I have given the bands simpler names, have re-run i.worldview.toar, and 
am getting the same error:


i.worldview.toar 
band=b1_red@worldview2,b2_green@worldview2,b3_blue@worldview2,b4_nir@worldview2 
outputsuffix=toar utc=2010-04-11T18:07:06.558405Z doy=101 sea=60.3

|! Using Day of Year to calculate Earth-Sun distance.

|! Region matching the b1_red@worldview2 spectral band

|* Processing the b1_red@worldview2 band
Traceback (most recent call last):
  File
"/home/wilbur/.grass7/addons/scripts/i.worldview.toar", line
416, in 
sys.exit(main())
  File
"/home/wilbur/.grass7/addons/scripts/i.worldview.toar", line
320, in main
acf = float(CF_BW_ESUN[band][2])
KeyError: 'b1_red'
WARNING: No data base element files found

Thank you

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

[GRASS-user] Problems using i.worldview.toar

[William Hudspeth]

I am using i.worldview.toar with the latest version of GRASS 7.3. I was 
able to successfully download and install this extension. I have tried 
using the module with the following input and error. All of the input 
files exist, and I get an error stating that "No data base element files 
found". Help appreciated...


Thanks

i.worldview.toar 
band=worldview2_b1_RED@worldview2,worldview2_b2_GREEN@worldview2,worldview2_b3_BLUE@worldview2,worldview2_b4_NIR@worldview2 



outputsuffix=toar utc=2010-04-11T18:07:06.558405Z doy=101 sea=60.3


|! Using Day of Year to calculate Earth-Sun distance.


|! Region matching the worldview2_b1_RED@worldview2 spectral band


|* Processing the worldview2_b1_RED@worldview2 band

Traceback (most recent call last):

File

"/home/wilbur/.grass7/addons/scripts/i.worldview.toar", line

416, in 

sys.exit(main())

File

"/home/wilbur/.grass7/addons/scripts/i.worldview.toar", line

320, in main

acf = float(CF_BW_ESUN[band][2])

KeyError: 'worldview2_b1_RED'

WARNING: No data base element files found


(Thu Sep 8 15:20:32 2016) Command finished (0 sec)





--
*William Hudspeth, PhD, MPH*
Earth Data Analysis Center
MSC01 1110
1 University of New Mexico
Albuquerque, New Mexico 87131-0001
tel: 505-277-3622, ext. 249
email: bhudsp...@edac.unm.edu
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Pan sharpen Worldview-2 imagery

[William Hudspeth]

On 08/16/2016 05:00 PM, Nikos Alexandris wrote:

William Hudspeth:


Hello Nikos,

The link you provided documents how to use g.extension for installing
python scripts in GRASS 7.3. In particular, it uses the 'url='
argument to specify a link to a zip file. I am using the stable version
of GRASS 7.0 that is installed with Ubuntu 16.01. In that version, the
'url=...' argument is not available. Is there an alternative way to
install your extension in GRASS 7.0?

Thanks much, William


Hi William. Please, try to keep some bottom-posting in the list.

Can you get GRASS' source code (any version 7.x) and follow steps in
https://svn.osgeo.org/grass/grass-addons/README?

Nikos 


On 16/08/16 19:56, William Hudspeth wrote:

/Hello Nikos, />//>/The link you provided documents how to use g.extension for installing 
/>/python scripts in GRASS 7.3. In particular, it uses the 'url=' />/argument to specify a 
link to a zip file. I am using the stable version />/of GRASS 7.0 that is installed with Ubuntu 
16.01. In that version, the />/'url=...' argument is not available. Is there an alternative way 
to />/install your extension in GRASS 7.0? /

Download the extension to your machine, unzip it, go into the directory
and then run
  make MODULE_TOPDIR=/path/to/your/grass/installation

You have to have the grass-dev package installed for it to work.

Moritz






I have tried installing from the unzipped directory using the following for 
grass installation
path, and with the following errors:



make MODULE_TOPDIR=/usr/lib/grass70

GISRC=/usr/lib/grass70/demolocation/.grassrc70 GISBASE=/usr/lib/grass70 
PATH="/usr/lib/grass70/bin:/usr/lib/grass70/bin:/usr/lib/grass70/scripts:$PATH" 
PYTHONPATH="/usr/lib/grass70/etc/python:/usr/lib/grass70/gui/wxpython:$PYTHONPATH" 
LD_LIBRARY_PATH="/usr/lib/grass70/bin:/usr/lib/grass70/bin:/usr/lib/grass70/scripts:/usr/lib/grass70/lib:/usr/lib/grass70/lib:" 
LC_ALL=C g.parser -t i.worldview.toar.py | sed s/\"/\"/g | sed 
's/.*/_("&")/' > 
/usr/lib/grass70/locale/scriptstrings/i.worldview.toar_to_translate.c
/bin/sh: 1: cannot create 
/usr/lib/grass70/locale/scriptstrings/i.worldview.toar_to_translate.c: 
Directory nonexistent

ERROR: Variable 'LOCATION_NAME' not set
/usr/lib/grass70/include/Make/ScriptRules.make:28: recipe for target 
'/usr/lib/grass70/locale/scriptstrings/i.worldview.toar_to_translate.c' 
failed
make: 
[/usr/lib/grass70/locale/scriptstrings/i.worldview.toar_to_translate.c] 
Error 2 (ignored)



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

Re: [GRASS-user] Pan sharpen Worldview-2 imagery

[William Hudspeth]

Hello Nikos,

The link you provided documents how to use g.extension for installing 
python scripts in GRASS 7.3. In particular, it uses the 'url=' 
argument to specify a link to a zip file. I am using the stable version 
of GRASS 7.0 that is installed with Ubuntu 16.01. In that version, the 
'url=...' argument is not available. Is there an alternative way to 
install your extension in GRASS 7.0?


Thanks much, William


On 08/13/2016 11:23 PM, Nikos Alexandris wrote:

William Hudspeth:


Hello,


Hello William,


I was wondering whether anyone has a workflow to pan sharpen Worldview-2
imagery (0.5 m pan, and 2.0 m MS) with 5 bands (panchromatic, red, blue,
green, NIR).



I am using grass 7.0.3 on ubuntu 16.01, but cannot find the
i.fusion.hbf command. I would also like information on any
pre-processing I might need to perform, such as converting digital
number to reflectance.


A simple workflow, would be to *first*, ortho-rectify your images
based on their own RPCs. You might want to read this à propos:
http://fwarmerdam.blogspot.ch/2013/09/exploring-rpcs.html

Next, you can create a Location based on the image's own reference
system, like:

grass70 -c WorldView2_Image.TIF /projects/grassdb/location_name

of course, you would (re-)name the above as it fits for you.

Now, inside GRASS,

1. import bands (pan and multispectral) in grass' data base using 
`r.in.gdal` -- bands will

likely get a basename (the one given for `output=`, and a number as a
suffix if the number of bands is more than 3, I think).

2. optionally, rename for the imported multispectral bands their names 
to easier

know which is which (like instead of ".1" , "blue" or whatsoever fits).

3. you may want to use
https://github.com/NikosAlexandris/i.worldview.toar to convert digital
numbers to radiance or reflectance. An example command:

i.worldview.toar
band=11APR03001446-M2AS_R1C1.Blue,11APR03001446-M2AS_R1C1.Green,11APR03001446-M2AS_R1C1.Red,11APR03001446-M2AS_R1C1.NIR 


outputsuffix=Rad utc=2011-04-03T00:14:46.590888Z sea=44.1

4. Then you can use i.fusion.hpf to sharpen all multispectral bands in
one go like:

i.fusion.hpf pan=Panchromatic msx=msRed,msBlue,msGreen,msNIR

given, of course, the appropriate band names.


Any assistance is much appreciated...
Thanks


You might want to have a look at
https://grasswiki.osgeo.org/wiki/WorldView and assist in cleaning it up
and improving it.

Nikos


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

Re: [GRASS-user] Pan sharpen Worldview-2 imagery

[William Hudspeth]

Nikos,

Thank you for your help. I was able to easily install the i.fusion.hpf, 
but have had considerable trouble understanding how to install 
i.worldview.toar as a python script. Any help appreciated...



Thanks, William


On 08/13/2016 11:23 PM, Nikos Alexandris wrote:

William Hudspeth:


Hello,


Hello William,


I was wondering whether anyone has a workflow to pan sharpen Worldview-2
imagery (0.5 m pan, and 2.0 m MS) with 5 bands (panchromatic, red, blue,
green, NIR).



I am using grass 7.0.3 on ubuntu 16.01, but cannot find the
i.fusion.hbf command. I would also like information on any
pre-processing I might need to perform, such as converting digital
number to reflectance.


A simple workflow, would be to *first*, ortho-rectify your images
based on their own RPCs. You might want to read this à propos:
http://fwarmerdam.blogspot.ch/2013/09/exploring-rpcs.html

Next, you can create a Location based on the image's own reference
system, like:

grass70 -c WorldView2_Image.TIF /projects/grassdb/location_name

of course, you would (re-)name the above as it fits for you.

Now, inside GRASS,

1. import bands (pan and multispectral) in grass' data base using 
`r.in.gdal` -- bands will

likely get a basename (the one given for `output=`, and a number as a
suffix if the number of bands is more than 3, I think).

2. optionally, rename for the imported multispectral bands their names 
to easier

know which is which (like instead of ".1" , "blue" or whatsoever fits).

3. you may want to use
https://github.com/NikosAlexandris/i.worldview.toar to convert digital
numbers to radiance or reflectance. An example command:

i.worldview.toar
band=11APR03001446-M2AS_R1C1.Blue,11APR03001446-M2AS_R1C1.Green,11APR03001446-M2AS_R1C1.Red,11APR03001446-M2AS_R1C1.NIR 


outputsuffix=Rad utc=2011-04-03T00:14:46.590888Z sea=44.1

4. Then you can use i.fusion.hpf to sharpen all multispectral bands in
one go like:

i.fusion.hpf pan=Panchromatic msx=msRed,msBlue,msGreen,msNIR

given, of course, the appropriate band names.


Any assistance is much appreciated...
Thanks


You might want to have a look at
https://grasswiki.osgeo.org/wiki/WorldView and assist in cleaning it up
and improving it.

Nikos


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

[GRASS-user] Pan sharpen Worldview-2 imagery

[William Hudspeth]

Hello,

I was wondering whether anyone has a workflow to pan sharpen Worldview-2 
imagery (0.5 m pan, and 2.0 m MS) with 5 bands (panchromatic, red, blue, 
green, NIR). I am using grass 7.0.3 on ubuntu 16.01, but cannot find the 
i.fusion.hbf command. I would also like information on any 
pre-processing I might need to perform, such as converting digital 
number to reflectance.


Any assistance is much appreciated...

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

Re: [GRASS-user] Data ranges of geotiff not preserved after import to GRASS

[William Hudspeth]

Thank you. That solution worked


On 08/11/2016 01:34 AM, Markus Metz wrote:

On Wed, Aug 10, 2016 at 10:29 PM, Bill Hudspeth  wrote:

Hello

I am trying to import a multiband geotiff into GRASS 7.0.3 (running on Ubuntu 
16.01). The gdalinfo output shows the 4 bands, and their data ranges. Both my 
geotiff and my GRASS location are in the projection UTM Zone 13N, WGS84 
(epsg:32613). My GRASS region is 0.5 meters to import a panchromatic band, but 
the 4 bands in the multiband file are 2.0 m resolution. After I import, the 
data ranges of the 4 new grass rasters are very different from those listed in 
the gdalinfo output below.

The data ranges reported by GRASS exceed those reported by GDAL. Most
probably the data ranges reported by GDAL are approximations and thus
a subset of the real ranges. Try gdalinfo -mm
o10APR11180709-M2AS-02078010_01_P001.tif and check if min/max
values change.

Markus M


gdalinfo o10APR11180709-M2AS-02078010_01_P001.tif
Driver: GTiff/GeoTIFF
Files: o10APR11180709-M2AS-02078010_01_P001.tif
o10APR11180709-M2AS-02078010_01_P001.tif.aux.xml
Size is 3534, 2684
Coordinate System is:
PROJCS["WGS 84 / UTM zone 13N",
 GEOGCS["WGS 84",
 DATUM["WGS_1984",
 SPHEROID["WGS 84",6378137,298.257223563,
 AUTHORITY["EPSG","7030"]],
 AUTHORITY["EPSG","6326"]],
 PRIMEM["Greenwich",0],
 UNIT["degree",0.0174532925199433],
 AUTHORITY["EPSG","4326"]],
 PROJECTION["Transverse_Mercator"],
 PARAMETER["latitude_of_origin",0],
 PARAMETER["central_meridian",-105],
 PARAMETER["scale_factor",0.9996],
 PARAMETER["false_easting",50],
 PARAMETER["false_northing",0],
 UNIT["metre",1,
 AUTHORITY["EPSG","9001"]],
 AUTHORITY["EPSG","32613"]]
Origin = (318626.000,3848648.000)
Pixel Size = (2.000,-2.000)
Metadata:
   AREA_OR_POINT=Area
   TIFFTAG_ARTIST=PCI
   TIFFTAG_DATETIME=2010:04:11 18:07:09
   TIFFTAG_SOFTWARE=PCI Geomatica
Image Structure Metadata:
   INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left  (  318626.000, 3848648.000) (106d58'54.51"W, 34d45'49.98"N)
Lower Left  (  318626.000, 3843280.000) (106d58'50.35"W, 34d42'55.81"N)
Upper Right (  325694.000, 3848648.000) (106d54'16.62"W, 34d45'54.41"N)
Lower Right (  325694.000, 3843280.000) (106d54'12.63"W, 34d43' 0.24"N)
Center  (  322160.000, 3845964.000) (106d56'33.53"W, 34d44'25.13"N)
Band 1 Block=3534x2 Type=UInt16, ColorInterp=Red
   Min=145.000 Max=473.000
   Minimum=145.000, Maximum=473.000, Mean=286.443, StdDev=29.355
   NoData Value=0
   Metadata:
 STATISTICS_MAXIMUM=473
 STATISTICS_MEAN=286.44285428343
 STATISTICS_MINIMUM=145
 STATISTICS_STDDEV=29.354503358529
Band 2 Block=3534x2 Type=UInt16, ColorInterp=Green
   Min=150.000 Max=771.000
   Minimum=150.000, Maximum=771.000, Mean=447.144, StdDev=61.481
   NoData Value=0
   Metadata:
 STATISTICS_MAXIMUM=771
 STATISTICS_MEAN=447.14438693812
 STATISTICS_MINIMUM=150
 STATISTICS_STDDEV=61.481469436348
Band 3 Block=3534x2 Type=UInt16, ColorInterp=Blue
   Min=116.000 Max=940.000
   Minimum=116.000, Maximum=940.000, Mean=566.192, StdDev=92.234
   NoData Value=0
   Metadata:
 STATISTICS_MAXIMUM=940
 STATISTICS_MEAN=566.19172957414
 STATISTICS_MINIMUM=116
 STATISTICS_STDDEV=92.234459276031
Band 4 Block=3534x2 Type=UInt16, ColorInterp=Undefined
   NoData Value=0


My outputs from r.info for the 4 imported bands are below...Why are the data 
ranges not correct??

++
  | Map:  o10APR11180709_M2AS_02078  Date: Wed Aug 10 14:21:20 2016|
  | Mapset:   worldview2 Login of Creator: wilbur  |
  | Location: PotteryMound |
  | DataBase: /home/wilbur/grass_data  |
  | Title: ( o10APR11180709_M2AS_02078010_01_P001.1 )  |
  | Timestamp: none|
  ||
  ||
  |   Type of Map:  raster   Number of Categories: 0   |
  |   Data Type:CELL   |
  |   Rows: 2684   |
  |   Columns:  3534   |
  |   Total Cells:  9485256|
  |Projection: UTM (zone 13)   |
  |N:3848648S:3843280   Res: 2 |
  |E: 325694W: 318626   Res: 2 |
  |   Range of data:min = 133  

[GRASS-user] r.average and r.info

[William Hudspeth]

Hello,

I am using r.average to calculate the mean pixel value in a base map
aggregating pixels in a cover map with the same value. I know that I
have 54 different categories (e.g. parcels) in the cover map, but when I
run r.info, it only outputs 47 of them, with a  on the final line.
Where are the rest of the results?

Thanks, Bill

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

[GRASS-user] Problems getting gdawarp to recognize an AAIGrid output by r.out.gdal

[William Hudspeth]

Hello,

I am using an older version of GRASS (v. 6.0) and r.out.gdal to export
an ArcAscii file. This works with no problem. However, when I try to
project the ArcAscii file (with file extension *.asc) into a different
projection, I get an error. The gdalinfo --formats (GDAL 1.3.1) command
shows that AAIGrid is supported. Yet when I run gdalwarp, as below

gdalwarp -of VRT -s_srs EPSG:4326 -t_srs '+proj=lcc +lat__1=33n
+lat_2=45n +lon_0=97w' f48.asc f48_lambert.vrt

I get the following error:

ERROR 4: `f48.asc' not recognised as a supported file format.

I realize that these are older versions of GRASS and GDAL, but I can't
easily change them at this time.

Thanks, Bill


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

Re: [GRASS-user] No color for geotiffs exported with r.out.gdal

[William Hudspeth]

Markus, 

Thanks for your assistance and explanation. I ended up adding +1 and
multiplying by 100 the source raster

e.g.

r.mapcalc new_raster=(old_raster+1.0)*100

I also transformed the ndvi color table accordingly, and post it here if
anyone should wish to use it...

0.00   5  24  82
70.0   5  24  82
82.0 255 255 255
100.0 255 255 255
102.5 206 197 180
107.5 191 163 124
112.5 179 174  96
115 163 181  80
117.5 144 170  60
123.3 166 195  29
126.6 135 183   3
133.3 121 175   1
136.6 101 163   0
143.3  78 151   0
146.6  43 132   4
155.0   0 114   0
165.0   0  90   1
175.0   0  73   0
185.0   0  56   0
195.0   0  31   0
200.0   0   0   0


Thanks, Bill



















On Fri, 2010-04-02 at 23:10 +0200, Markus Neteler wrote:
 grass-user@lists.osgeo.org

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

[GRASS-user] No color for geotiffs exported with r.out.gdal

[William Hudspeth]

Hello,

I am using GRASS 6.4~rc5-2 on Ubuntu 9.10. I am trying to export a DCELL
raster map to both a byte formatted and a UInt16 formatted Geotiff file.
The UInt16 formatted file shows nothing when I try to open the file, and
the byte formatted file is in black and white only. I can't seem to get
color. The original GRASS raster uses the ndvi color scheme.

Thanks, Bill

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

Re: [GRASS-user] No color for geotiffs exported with r.out.gdal

[William Hudspeth]

I have tried that too with the same results...

Thanks though,

Bill

On Fri, 2010-04-02 at 12:59 -0400, M S wrote:
 How about r.out.tiff?   
 
 Mark
 
 On Fri, Apr 2, 2010 at 11:00 AM, William Hudspeth
 bhudsp...@edac.unm.edu wrote:
 Hello,
 
 I am using GRASS 6.4~rc5-2 on Ubuntu 9.10. I am trying to
 export a DCELL
 raster map to both a byte formatted and a UInt16 formatted
 Geotiff file.
 The UInt16 formatted file shows nothing when I try to open the
 file, and
 the byte formatted file is in black and white only. I can't
 seem to get
 color. The original GRASS raster uses the ndvi color scheme.
 
 Thanks, Bill
 
 ___
 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] Help with i.pca output

[William Hudspeth]

Hello,

I have been employing GRASS 6.2 to do Principal Components Analysis
(PCA) on a series of images using the i.pca command. The output of
eigenvectors looks like the following:

( 0.55 0.78 0.28 ) 
( -0.17 -0.22 0.96 ) 
( 0.82 -0.58 0.01 ) 

However, lacking training in matrix algebra, I am unsure about how to
generate eigen values and percent variance explained by the different
principal components from the eigen vectors. The GRASS 6.4 documentation
for i.pca indicates that this alternative information is included in the
new output (see the documentation example below):

r.info -h spot_pca.1
   Eigen values, (vectors), and [percent importance]:
   PC1   1170.12 ( -0.63 -0.65 -0.43 ) [ 88.07% ]
   PC2152.49 (  0.23  0.37 -0.90 ) [ 11.48% ]
   PC3  6.01 (  0.75 -0.66 -0.08 ) [  0.45% ]

After installing GRASS 6.4, however, the output claims to be eigen values, 
but looks more like eigen vectors as for GRASS 6.2:

( 0.37 0.46 0.81 ) 
( -0.50 -0.63 0.59 ) 
( 0.78 -0.63 -0.01 )

I would appreciate any help on interpreting these values, or knowing why
the output of i.pca in GRASS 6.4 doesn't match what is in the
documentation. Ultimately, I am only trying to get at the percent
variance for each principal component so that I can proceed with
supervised and unsupervised classification of my images.

Thanks much,

William


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

[GRASS-user] Need help with figuring out how to use category values and labels with r.statistics

[William Hudspeth]

Hello,

I am having a bit of a problem figuring out how to solve a processing
flow:

I am starting out with a raster with a continuous distribution of float
values. I want to calculate some basic descriptive statistics using
r.statistics, but do not want to lose the important numeric information
following the decimal point in the cell values. Because r.statistics
only works on integer raster maps, I have first multiplied the float
maps by a constant (e.g. 10,000), with the hopes that I can later divide
by that constant to retain the figures following the decimal point.

e.g.

r.mapcalc integer_map=int(float_map*1)

I have a raster map of state county id numbers that I use in the
r.statistics calculation - the aim is to generate basic summary stats
(e.g. mean) for each county

e.g.

r.statistics base=county_ids cover=integer_map output=mean_by_county
method=average

The output map has category values set to the county IDs, and category
labels set to the means by county (multiplied by the constant 1). So
far, so good.

To get back to a mean of the original values, I would like to divide
these output maps by the constant (1.00) using r.mapcalc, but doing
so yields the category values (county IDs) divided by 1, with empty
category labels (losing the statistical information). If I use the -c
argument in r.statistics (which uses the category labels in the
calculation), I end up with the correct category labels (county IDs),
but I will have lost all of the statistical information.

How do I get back to my original values (dividing by the constant of
1) without losing the county id category labels with which they are
associated?

Thanks, Bill

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

[GRASS-user] r.out.gdal aborts writing out Geotiff

[William Hudspeth]

Hello, I am trying to write a GRASS raster to a Geotiff using
r.out.gdal, but get the following error:

Writing format: GTiff
Writing type:   Int16
Input file size is 1215, 1499
/usr/grass-6.1.0/scripts/r.out.gdal: line 135: 10683 Aborted
gdal_translate -of $FORMAT -ot $TYPE $CREATEKEY $METAKEY $CELLHD $OUTPUT

Any help much appreciated,

William


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

[GRASS-user] Importing Eosat landsat imagery - errors

[William Hudspeth]

Hello,

I am trying to r.in.gdal to import an Eosat Fast formatted Landsat image
into GRASS 6.1 (running on SUSE Linux 10.1). It requires pointing to the
dataset header file as input, and specification of the band that is to
be imported. I get the error message:

Input map is rotated - cannot import. You may use 'gdalwarp' to
transform the map to North-up.

I have looked into the documentation of gdalwarp, but it is not clear to
me how I go about rotating the image to North-up. Does anyone have
experience with the parameters/arguments necessary to transform the
image using gdalwarp before import into GRASS?

Thanks, Bill

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

[GRASS-user] Copy raster from xy location to latlong

[William Hudspeth]

Hello,

I have imported a remote sensing product from an HDF file into an XY
location. It is stored as a 1/4 degree pixel grid with 720 rows and 1440
columns. I would like to copy this raster to a new GRASS lat-long
(WGS84) location with a 1/4 degree resolution (90N, 90S, 180W, 180E).
Can someone please explain the best way to go about doing this?

Thanks much,

William

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

[GRASS-user] Copy raster from xy location to latlong

[William Hudspeth]

Thanks for responding.

I think I was a little unclear in my original description. My
xy-location raster is stored as pixel values (720 rows and 1440
columns, with the origin  (0, 0) at the bottom left corner), 
such that an individual pixel might have a coordinate of 125, 256.
I need to somehow project this xy location raster into a lat long location 
where
the coordinate values to each pixel are in lat-long coordinates (e.g.
0 degrees longitude, 0 degrees latitude is the center of the grid,
the left edge is at -180 degrees (West), and the north edge is at 90
degrees (North)). Since there are 720 rows, it is clear that each pixel
represents 1/4 of a degree (the satellite product has a global extent), 
and the re-projected copy in the lat long location will have a resolution
of 1/4 degree. In essence, I need to somehow reassign coordinate values to each
pixel so they are in lat-long rather that pixel coordinates.

Thanks!

Bill

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

[GRASS-user] where are multispectral classification signature files written to?

[William Hudspeth]

Hello,

I am trying to do a multispectral reclassification with ASTER data.
While the i.cluster and i.class modules seem to run to completion, I
cannot find the signature files to use with i.maxlik. Does anyone know
where the are written to?

Also, when I run i.cluster, I have tried changing many of the
parameters, but find it difficult to get a reasonable number of classes
when the convergence is set to the default 0.98. Are there any
guidelines for working with i.cluster?

It is probably worth noting that I am trying to run i.cluster and
i.class on the output from i.pca...

Thanks,

William

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

[GRASS-user] Writing recode rules into a Postgres Database

[William Hudspeth]

Hello,

I would like to explain the problem I am trying to solve. I begin with
importing a shapefile of county boundaries into a GRASS vector map. I
then convert the vector map into a raster map using a county ID code in
the vector map attributes. What I get is a raster map with pixels coded
into some 30 different county ID categories. I also have a second raster
map whose pixels are assigned one of a continuous range of floating
point values (i.e. dust concentration).

I then use r.average to recode the county map IDs into a new map that
has counties coded by average dust concentration. When I run r.info I
get something like this:

***
raster file fips_county2

generated by r.recode
recode of raster file fips_county2
0:0:0.00
35001:35001:5.4066317414
35003:35003:5.9971417728
35005:35005:3.9597935272
35006:35006:7.5931687376
35007:35007:5.3254945193
35009:35009:0.9088373997
35011:35011:2.3610553445
35013:35013:21.1810002482



The recode rules on each line show that the county ID numbers (e.g.
35001) are recoded into average dust concentration values (e.g.
5.4066317414).

I am interested in taking these two pieces of information, county ID and
average dust concentration, and for each county, appending them as a row
to a PostgreSQL database table. I have thought of parsing the recode
files in the hist directories using a scripting language, but would like
to try something more straightforward. Any ideas?

Thanks very much, Bill

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