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

[Uttam Kumar]

I could not reach the solution till now even after following the steps told
in previous posts. I know I am making a silly mistake.

This is the projection information of the target location:

+proj=laea +lat_0=30 +lon_0=-96 +x_0=0 +y_0=0 +datum=NAD83 +units=m +no_defs

*GRASS 7.1.svn (SanLuis_Reservoir_LAEA):~ >g.proj -p*

-PROJ_INFO-
name   : Lambert Azimuthal Equal Area
proj   : laea
datum  : nad83
ellps  : grs80
lat_0  : 30
lon_0  : -96
x_0: 0
y_0: 0
no_defs: defined
-PROJ_UNITS
unit   : Meter
units  : Meters
meters : 1



*GRASS 7.1.svn (SanLuis_Reservoir_LAEA):~ > g.proj -w*PROJCS["Lambert
Azimuthal Equal Area",
GEOGCS["grs80",
DATUM["North_American_Datum_1983",

SPHEROID["Geodetic_Reference_System_1980",6378137,298.257222101]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433]],
PROJECTION["Lambert_Azimuthal_Equal_Area"],
PARAMETER["latitude_of_center",30],
PARAMETER["longitude_of_center",-96],
PARAMETER["false_easting",0],
PARAMETER["false_northing",0],
UNIT["Meter",1]]

*GRASS 7.1.svn (SanLuis_Reservoir_LAEA):~ > v.info  -g
Image_boundary_box*

north=823262.924419209
south=652223.643294404
east=-167210.022680164
west=-518209.054236328
top=0.00
bottom=0.00










*I should have got this (This is
correct):north:1638674.575south:1481984.575east:1157941.598west:817651.598*

*Any clue, where am I wrong?*


On Tue, Oct 20, 2015 at 4:45 PM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

> On 20/10/15 19:08, Uttam Kumar wrote:
>
>>
>>
>> I have been trying for a long time. Something wrong is going on. I
>> appreciate if you can correct me.
>>
>>
>> I have all my source images in sinusoidal projection in a location
>> called "Landsat_sinu".
>>
>> My target locatoin is "Landsat_laea" I tried using the default option in
>> GRASS GUI as follows:
>>
>> 1.) *Select coordinate system parameters from a list*
>>
>> 2.) Projection code: *laea*
>>
>> 3.) Datum with associated ellipsoid:
>> Central parallel: *30*
>> Central Meridian: *-96*
>> False easting: *0*
>> False northing: *0*
>>
>> 4.) Datum code: *nad83*
>> 5.) Select from the list of datum transformation: *1 used in whole nad83
>> region*
>>
>> +proj=laea
>> +lat_0=30
>> +lon_0=-96
>> +x_0=0
>> +y_0=0
>> +no_defs
>> +a=6378137
>> +rf=298.257222101
>> +towgs84=0.000,0.000,0.000
>> to_meter=1
>> +datum=nad83
>>
>> Finish.
>>
>> Is everything ok with this for the below (required) target definition?
>>
>> **PROJ.4 : '+proj=laea +lat_0=30 +lon_0=-96 +x_0=0 +y_0=0 +datum=NAD83
>> +units=m +no_defs '**
>>
>> Looks like at some point I am making a small mistake. I must get this as
>> the projected coordinates.
>>
>> *north=1064601.38274499
>> south=830176.771464028
>> east=-1960125.15283348
>> west=-2265106.68066176*
>>
>
> And what is wrong with these coordinates ? Those are exactly the ones I
> get and they are very close to the ones you got from ENVI:
>
> > > Upper Left  (-2265106.681W, 1064601.383N)
> > > Lower Left  (-2265106.681W,  830181.383N)
> > > Upper Right (-1960126.681W, 1064601.383N)
> > > Lower Right (-1960126.681W,  830181.383N)
>
> i.e. 4.6m difference for South and 1.5m difference for East. You would
> have to check how the NAD83 conversion is done exactly to see if the
> difference could come from there.
>
> Moritz
>
>
>
>>
>> Any help is appreciated.
>>
>> Uttam.
>>
>>
>> On Wed, Oct 14, 2015 at 4:52 PM, Moritz Lennert
>> mailto:mlenn...@club.worldonline.be>>
>> wrote:
>>
>> [Please keep conversations on the list]
>>
>> On 14/10/15 23:19, Uttam Kumar wrote:
>>
>> _
>>
>> _
>> _*This information is for the original data (Source):*_
>>
>> *PROJ.4 : '+proj=sinu +lon_0=0 +x_0=0 +y_0=0 +a=6371007.181
>> +b=6371007.181 +units=m +no_defs '*
>>
>>
>> Coordinate System is:
>> PROJCS["Sinusoidal",
>>   GEOGCS["GCS_Unknown",
>>   DATUM["Unknown",
>>   SPHEROID["S_Unknown",6371007.181,0.0]],
>>   PRIMEM["Greenwich",0.0],
>>   UNIT["Degree",0.0174532925199433]],
>>   PROJECTION["Sinusoidal"],
>>   PARAMETER["False_Easting",0.0],
>>   PARAMETER["False_Northing",0.0],
>>   PARAMETER["longitude_of_center",0.0],
>>   UNIT["Meter",1]]
>> Origin = (-10801805.19769436736,4130102.07906977946)
>> Pixel Size = (30.000,-30.000)
>>
>> *
>> _This information is for the destination data (Target):_*
>>
>> *PROJ.4 : '+proj=laea +lat_0=30 +lon_0=-96 +x_0=0 +y_0=0
>> +datum=NAD83
>> +units=m +no_defs '*
>>
>>
>> In your first mail you said:
>>
>> Lambert Azimuthal Equal Area, Datum: WGS84
>>
>> but here the datum is NAD83.

Re: [GRASS-user] map algebra logical operators on DCELL rasters not admitted? maybe docs should outline it

[G. Allegri]

Thanks for the clear explanation Glynn. Maybe this behaviour could be
esplicited inside the docs...

giovanni
Il 22/ott/2015 23:35, "Glynn Clements"  ha
scritto:

>
> G. Allegri wrote:
>
> > If logical operator is applied to, sat, Byte data it gives true/false
> > results, e.g. if(A && B,1, 0) behaves correctly even with cell values
> > values greater then 1.
> > That's why I expected it to work with floats operands too.
> > >From a user perspective if it works for a cell with value 2 it should
> also
> > work for a cell with value 2.0.
> > That'all.
>
> r.mapcalc's interpretation of booleans is borrowed from C. Booleans
> are just integers where zero is false and non-zero is true.
>
> But that doesn't necessarily make much sense for floats; the
> conventional wisdom is that comparing a float for equality with zero
> is usually a mistake, as results which should mathematically be equal
> to zero often aren't actually equal to zero due to intermediate
> rounding errors. In some cases, simply subtracting a number from
> itself won't yield zero (e.g. due to the x87 FPU using 80 bits for
> floating-point registers while values stored in memory use 32 or 64
> bits).
>
> You can obtain C-like behaviour by converting to an integer with the
> int() function then using that; the result is that any value between
> -1.0 and 1.0 (excluding both endpoints) will be considered false while
> anything else is true. Or you can convert to an integer with the
> round() function and use that, in which case any value between -0.5
> and 0.5 (including both endpoints) will be false while anything else
> is true. Or you can compare for equality with 0.0, in which case -0.0
> and 0.0 will be false while anything else is true. Or you can compare
> the magnitude (obtained using abs()) to an "epsilon" value so that
> anything smaller than the expsilon is false while anything larger is
> true.
>
> That's four different possibilities, none of which is any more
> "correct" than any of the others. Choosing one of them would just mean
> that r.mapcalc was probably using the "wrong" one, and doing so
> silently. The current behaviour forces the user to be explicit.
>
> --
> Glynn Clements 
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] map algebra logical operators on DCELL rasters not admitted? maybe docs should outline it

[Glynn Clements]

G. Allegri wrote:

> If logical operator is applied to, sat, Byte data it gives true/false
> results, e.g. if(A && B,1, 0) behaves correctly even with cell values
> values greater then 1.
> That's why I expected it to work with floats operands too.
> >From a user perspective if it works for a cell with value 2 it should also
> work for a cell with value 2.0.
> That'all.

r.mapcalc's interpretation of booleans is borrowed from C. Booleans
are just integers where zero is false and non-zero is true.

But that doesn't necessarily make much sense for floats; the
conventional wisdom is that comparing a float for equality with zero
is usually a mistake, as results which should mathematically be equal
to zero often aren't actually equal to zero due to intermediate
rounding errors. In some cases, simply subtracting a number from
itself won't yield zero (e.g. due to the x87 FPU using 80 bits for
floating-point registers while values stored in memory use 32 or 64
bits).

You can obtain C-like behaviour by converting to an integer with the
int() function then using that; the result is that any value between
-1.0 and 1.0 (excluding both endpoints) will be considered false while
anything else is true. Or you can convert to an integer with the
round() function and use that, in which case any value between -0.5
and 0.5 (including both endpoints) will be false while anything else
is true. Or you can compare for equality with 0.0, in which case -0.0
and 0.0 will be false while anything else is true. Or you can compare
the magnitude (obtained using abs()) to an "epsilon" value so that
anything smaller than the expsilon is false while anything larger is
true.

That's four different possibilities, none of which is any more
"correct" than any of the others. Choosing one of them would just mean
that r.mapcalc was probably using the "wrong" one, and doing so
silently. The current behaviour forces the user to be explicit.

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

Re: [GRASS-user] External raster from PostGIS

[Markus Neteler]

Hi Lorenzo,

On Thu, Oct 22, 2015 at 6:03 PM, Lorenzo Bottaccioli
 wrote:
> Hi Markus,
>
> How do I implement such command in GRASS GIS? I have tried with r.external
> because I have done the same thing with v.external. I'have tried as well
> with r.in.gdal but notthing. If i use v.in.ogr I can import vectors from
> PostGIS.

I would just like to the command to use. And the error message.
Perhaps we see why it fails.

Did you use "source=..." of r.external?

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

Re: [GRASS-user] External raster from PostGIS

[Lorenzo Bottaccioli]

Hi Markus,

How do I implement such command in GRASS GIS? I have tried with r.external
because I have done the same thing with v.external. I'have tried as well
with r.in.gdal but notthing. If i use v.in.ogr I can import vectors from
PostGIS.

Lorenzo

2015-10-22 17:55 GMT+02:00 Markus Neteler :

> On Thu, Oct 22, 2015 at 12:49 PM, Lorenzo Bottaccioli
>  wrote:
> > Hello,
> >
> > I'm tryng to import a raster file sotred in PostGIS with r.external but i
> > cannot select the db. If I try with r.in.gdal and i connect to the db I
> > can't see the table.
>
> Can you please post the full command? (omitting the password if given
> there)
> Is it similar to what's given in
>
> https://trac.osgeo.org/gdal/wiki/frmts_wtkraster.html#a3.2-Readingrasterdatafromthedatabase
> ?
>
> I would like to add an example to the manual page but do not have a PG
> installation containing a raster map.
>
> Markus
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] External raster from PostGIS

[Markus Neteler]

On Thu, Oct 22, 2015 at 12:49 PM, Lorenzo Bottaccioli
 wrote:
> Hello,
>
> I'm tryng to import a raster file sotred in PostGIS with r.external but i
> cannot select the db. If I try with r.in.gdal and i connect to the db I
> can't see the table.

Can you please post the full command? (omitting the password if given there)
Is it similar to what's given in
https://trac.osgeo.org/gdal/wiki/frmts_wtkraster.html#a3.2-Readingrasterdatafromthedatabase
?

I would like to add an example to the manual page but do not have a PG
installation containing a raster map.

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

[GRASS-user] Problems running g.gui.gcp

[Johannes Radinger]

Dear GRASS users,

Today I wanted to try the georectification tool g.gui.gcp in GRASS 7 for
the first time. I was basically following the description on the GRASS wiki
(https://grasswiki.osgeo.org/wiki/Georeferencing). In particular, I have a
photograph from my camera with known reference points which I load into an
unprojected XY location. My target location should also be a XY location as
the picture is taken from a "virtual" coordinate system. Inside my target
XY-location I try to open g.gui.gcp and select raster, and the location and
mapset where my photograph is stored. When I want to click next I get
following error/message: "You must select a valid location and mapset in
order to continue" and I can't proceed with the rectification. Just this
GUI message appears, no error/warning in the grass console etc. I am
puzzled how to interpret that? What is wrong with the location/mapset? The
mapset I've selected is existing (I can select it from the dropdown menu).
I tried to select any other location/mapset but receive always the same
message.

I am running GRASS 7.0.2 on Ubuntu:
GRASS version: 7.0.2svn

GRASS SVN Revision: 66568

Build Date: 2015-10-22

Build Platform: i686-pc-linux-gnu

GDAL/OGR: 1.10.0

PROJ.4: 4.8.0

GEOS: 3.4.2

SQLite: 3.7.9

Python: 2.7.3

wxPython: 2.9.4.1

Platform: Linux-3.2.0-92-generic-pae-i686-with-Ubuntu-12.04-precise

Any ideas?
Thanks!

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

[GRASS-user] r.colors

[Paul Shapley]

Hi All,

Just testing 7.0.2RC1 with some landsat 8 images. I've imported and changed
the DN values to TOAR values but when i try to use a 'Histogram Stretch'
using the 'grey' table the maps display no color (white display) whereas in
version 6 it worked. Also i need to increase the 'contrast' when displaying
the individual bands but dont know if there is a way to do this. I have
tried opening the 'i.fusion.hpf' script but it seems to hang.

Many Thanks,

-- 
*Paul J. Shapley *MSc CGeog (GIS) FRGS
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] External raster from PostGIS

[Lorenzo Bottaccioli]

Hello,

I'm tryng to import a raster file sotred in PostGIS with r.external but i
cannot select the db. If I try with r.in.gdal and i connect to the db I
can't see the table.

Any suggestion?

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

[GRASS-user] GRASS GIS 7.0.2 RC1 released

[Markus Neteler]

 * We are pleased to announce the first release candidate of the upcoming
GRASS GIS 7.0.2 version *

*What's new in a nutshell*

This upcoming stability release provides a series of stability fixes and
manual improvements. This first  release candidate GRASS GIS 7.0.2RC1
provides *160 fixes and improvements*.

*About GRASS GIS 7*: Its graphical user interface supports the user to make
complex GIS operations as simple as possible. A new Python interface to the
C library  permits
users to create new GRASS GIS-Python modules in a simple way while yet
obtaining powerful and fast modules. Furthermore, the libraries were
*significantly
improved for speed and efficiency*, along with support for huge files
. A lot of
effort has been invested to standardize parameter and flag names.
Finally, GRASS GIS 7 comes with a series of *new modules* to analyse raster
and vector data, along with a full temporal framework. For a detailed
overview, see the list of new features
. As a stable release
series, 7.0.x will enjoy *long-term support*.

*Source code download:*

   - http://grass.osgeo.org/grass70/source/
   
   - http://grass.osgeo.org/grass70/source/grass-7.0.2RC1.tar.gz
   
   - To get the GRASS GIS 7.0.2 RC1 source code directly from SVN, see here
   .

*Binaries download:*

   - winGRASS 7.0.2RC1 standalone installer
   

   - winGRASS 7.0.2RC1 in OSGeo4W installer
   
   - Ubuntu installer
   
   -


   - ... further binary packages for other Linux distributions and Mac OSX
   will follow shortly.

*More details:*

See also our detailed announcement:
  http://trac.osgeo.org/grass/wiki/Release/7.0.2-News
  http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures (overview of new 7.0
stable release series)

First time users may explore the first steps tutorial
 after installation.

*About GRASS GIS*

The Geographic Resources Analysis Support System (http://grass.osgeo.org/)
, commonly referred to as GRASS GIS, is an Open
Source Geographic Information System providing powerful raster, vector and
geospatial processing capabilities in a single integrated software suite.
GRASS GIS includes tools for spatial modeling, visualization of raster and
vector data, management and analysis of geospatial data, and the processing
of satellite and aerial imagery. It also provides the capability to produce
sophisticated presentation graphics and hardcopy maps. GRASS GIS has been
translated into about twenty languages and supports a huge array of data
formats. It can be used either as a stand-alone application or as backend
for other software packages such as QGIS and R geostatistics. It is
distributed freely under the terms of the GNU General Public License (GPL).
GRASS GIS is a founding member of the Open Source Geospatial Foundation
(OSGeo).

*The GRASS Development Team, October 2015*
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user