r.proj: fixing a failure

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

r.proj: fixing a failure

Rich Shepard
   Trying to bring in the raster DEM to the project location, but r.proj
fails because of a difference in false eastings:

GRASS 6.4.0svn (beaver_lake):/usr4/grassbase > r.proj input=elevation10m
location=dem10m_northwest output=DEM method=cubic
Input Projection Parameters:  +proj=lcc +lat_1=43 +lat_2=45.5 +lat_0=41.75
+lon_0=-120.5 +x_0=1312336 +y_0=0 +no_defs +a=6378137 +rf=298.257222101
+nadgrids=/usr/local/grass-6.4.0svn/etc/nad/WO
Input Unit Factor: 1
Output Projection Parameters:  +proj=lcc +lat_1=43 +lat_2=45.5 +lat_0=41.75
+lon_0=-120.5 +x_0=399999.9999999999 +y_0=0 +no_defs +a=6378137
+rf=298.257222101 +nadgrids=/usr/local/grass-6.4.0svn/etc/nad/WO
Output Unit Factor: 1
ERROR: Input raster map is outside current region

   The input location's PROJ_INFO file contains:

name: Lambert Conformal Conic
proj: lcc
datum: nad83
ellps: grs80
lat_1: 43
lat_2: 45.5
lat_0: 41.75
lon_0: -120.5
x_0: 1312336
y_0: 0
no_defs: defined
nadgrids: WO

and the destination location's PROJ_INFO file contains:

name: Lambert Conformal Conic
proj: lcc
datum: nad83
ellps: grs80
lat_1: 43
lat_2: 45.5
lat_0: 41.75
lon_0: -120.5
x_0: 399999.9999999999
y_0: 0
no_defs: defined
nadgrids: WO

   Both have meters as PROJ_UNITS.

   The original metadata for the 10m DEM shows the following:

Spatial_Reference_Information:
   Horizontal_Coordinate_System_Definition:
     Planar:
       Map_Projection:
         Map_Projection_Name: Lambert Conformal Conic
  Lambert_Conformal_Conic:
   Standard_Parallel: 43.000000
           Standard_Parallel: 45.500000
           Longitude_of_Central_Meridian: -120.500000
   Latitude_of_Projection_Origin: 41.750000
   False_Easting: 1312336.000000
   False_Northing: 0.000000
       Planar_Coordinate_Information:
         Panar_Coordinate_Encoding_Method: row and column
         Coordinate_Representation:
           Abscissa_Resolution: 32.828670
   Ordinate_Resolution: 32.828670
   Planar_Distance_Units: User_Defined_Unit
  Geodetic_Model:
           Horizontal_Datum_Name: North American Datum of 1983
   Ellipsoid_Name: Geodetic Reference System 80
           Semi-major_Axis: 6378137.000000
     Denominator_of_Flattening_Ratio: 298.257222

   What do you folks recommend I do to reconcile the different false easting
for the DEM so it matches that of all the vector maps?

Rich

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: r.proj: fixing a failure

Maciej Sieczka
Rich Shepard pisze:

> r.proj fails because of a difference in false eastings:

Rather not.

> ERROR: Input raster map is outside current region

Set the output location's region to the extent of your to-be-reprojected
data, before running r.proj in the input location.

Maciek

--
Maciej Sieczka
http://www.sieczka.org

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: r.proj: fixing a failure

hamish-2
Maciej wrote:
> Set the output location's region to the extent of your to-be-reprojected
> data, before running r.proj in the input location.

tip:
v.proj'ing over a v.in.region box can help there. Then I usually try
to set the resolution to be a tiny bit better than the source rows x cols.
If there will bit a lot of rotation I try to set it even finer.


Hamish



     
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: r.proj: fixing a failure

Rich Shepard
On Tue, 22 Dec 2009, Hamish wrote:

> Maciej wrote:
>> Set the output location's region to the extent of your to-be-reprojected
>> data, before running r.proj in the input location.

   This message never arrived here.

   Can I assume that "output location" is the destination and "input
location" is the source?

   Then I will look in the WIND files for the boundaries of the two locations
and ensure that the larger is used in both.

> tip: v.proj'ing over a v.in.region box can help there. Then I usually try
> to set the resolution to be a tiny bit better than the source rows x cols.
> If there will bit a lot of rotation I try to set it even finer.

   I'll read the v.in.region man page and figure out how to use it to help
resolve my problem.

   I saw the resolution option but have no idea how to determine what it is
or what it should be. This is the type of information I want to collect and
document so there's more extensive instructions than most man pages provide.

   Germane to that last point: the r.proj man page includes conceptual detail
toward the end but no examples. The v.proj man page is the opposite. IMNSHO,
the r.proj detail should be in the wiki or other instructional documentation
and examples of usage should be on the man page.

Rich

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: r.proj: fixing a failure

Eric Patton
Rich Shepard wrote:
>   Germane to that last point: the r.proj man page includes conceptual detail
> toward the end but no examples. The v.proj man page is the opposite. IMNSHO,
> the r.proj detail should be in the wiki or other instructional documentation
> and examples of usage should be on the man page.
>
> Rich

I've added an example to the r.proj man page in grass64_release, devbr6,
and trunk.

--
Eric Patton
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: r.proj: fixing a failure

Rich Shepard
On Tue, 22 Dec 2009, Eric Patton wrote:

> I've added an example to the r.proj man page in grass64_release, devbr6,
> and trunk.

   Thanks, Eric. That makes it consistent with other man pages.

Rich
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: r.proj: fixing a failure

Rich Shepard
In reply to this post by hamish-2
On Tue, 22 Dec 2009, Hamish wrote:

> Maciej wrote:
>> Set the output location's region to the extent of your to-be-reprojected
>> data, before running r.proj in the input location.
>
> tip:
> v.proj'ing over a v.in.region box can help there. Then I usually try
> to set the resolution to be a tiny bit better than the source rows x cols.
> If there will bit a lot of rotation I try to set it even finer.

   Advice from either or both of you will help me quickly understand what
needs to be done so I can avoid future problems.

   Here is the source (output?) location's WIND for the raster DEM:

proj:       99
zone:       0
north:      1735231.43724681
south:      1120657.1324816
east:       952979.22944945
west:       143667.18968253
cols:       24657
rows:       18724
e-w resol:  32.82281055
n-s resol:  32.82281055
top:        1
bottom:     0
cols3:      24657
rows3:      18724
depths:     1
e-w resol3: 32.82281055
n-s resol3: 32.82281055
t-b resol:  1

and here is the destination (input?) location's WIND for the state's area:

proj:       99
zone:       0
north:      1326000
south:      1278000
east:       817000
west:       766500
cols:       1538
rows:       1462
e-w resol:  32.83485046
n-s resol:  32.83173735
top:        1
bottom:     0
cols3:      50500
rows3:      48000
depths:     1
e-w resol3: 1
n-s resol3: 1
t-b resol:  1

   This is based on running v.proj on 10 vector maps from their original
locations.

TIA,

Rich
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: r.proj: fixing a failure

Rich Shepard
In reply to this post by hamish-2
On Tue, 22 Dec 2009, Hamish wrote:

> tip: v.proj'ing over a v.in.region box can help there. Then I usually try
> to set the resolution to be a tiny bit better than the source rows x cols.
> If there will bit a lot of rotation I try to set it even finer.

Hamish,

   I'm missing something important which is probably obvious to you and
others. The project location contains vector maps. My reading of the
v.in.region man page tells me its function is to "Create a new vector from
the current region." That suggests that the resulting output map is the same
as the displayed vector map but with a new name.

   If I then run v.proj on the display of the new map what have I changed?
More importantly, how does that help resolve my inability to run r.proj on a
DEM map and reproject it to the project's location?

   A clue stick would help.

Thanks,

Rich
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: r.proj: fixing a failure

DanielV
Hi Rich,

I'm no expert in projection or Grass for that matter but this is what
I understand about the way Grass projects rasters and vectors. Hope
not to be making things worse :)

In order to project a raster you have to "bring it in" your current
location from another location that has a different projection. That
is done using r.proj. The trick is that, when you bring your new
raster into the current location, it will respect you current region
settings, that is, limits and resolution. So, let's say you want to
project an Oregon map but you current region is set to Florida. This
will not work and your raster will not be projected.

So, in order to know where you projected raster will fall, you can use
the v.in.region trick. The command will create a bounding box in your
map and you can project the vector (using v.proj), and not wory about
the current region. Then you set your region to the recently projected
vector (g.region vect=box) and fix your resolution. Now you are ready
to project your raster and you know the current region matches the
region where your raster is coming from.

This is better explained in the r.proj manual page, in the notes section
http://www.ces.iisc.ernet.in/grass/grass62/manuals/html62_user/r.proj.html

Cheers
Daniel

On Tue, Dec 22, 2009 at 2:54 PM, Rich Shepard <[hidden email]> wrote:

> On Tue, 22 Dec 2009, Hamish wrote:
>
>> tip: v.proj'ing over a v.in.region box can help there. Then I usually try
>> to set the resolution to be a tiny bit better than the source rows x cols.
>> If there will bit a lot of rotation I try to set it even finer.
>
> Hamish,
>
>  I'm missing something important which is probably obvious to you and
> others. The project location contains vector maps. My reading of the
> v.in.region man page tells me its function is to "Create a new vector from
> the current region." That suggests that the resulting output map is the same
> as the displayed vector map but with a new name.
>
>  If I then run v.proj on the display of the new map what have I changed?
> More importantly, how does that help resolve my inability to run r.proj on a
> DEM map and reproject it to the project's location?
>
>  A clue stick would help.
>
> Thanks,
>
> Rich
> _______________________________________________
> grass-user mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: r.proj: fixing a failure

Rich Shepard
On Tue, 22 Dec 2009, Daniel Victoria wrote:

> So, in order to know where you projected raster will fall, you can use
> the v.in.region trick. The command will create a bounding box in your
> map and you can project the vector (using v.proj), and not wory about
> the current region. Then you set your region to the recently projected
> vector (g.region vect=box) and fix your resolution. Now you are ready
> to project your raster and you know the current region matches the
> region where your raster is coming from.

Daniel,

   Despite my reading the r.proj man page I missed the critical point that
you and Hamish tried pointing out: that v.in.region is run on the raster
location, not the target location.

   Working my way through the r.proj man page note (as you summarize above),
I end with screwy region results.

   v.in.region worked; I call the output area (it should be area and not
line, correct?) 'dembox.' Exiting grass and restarting to reset the location
to that of the project, I ran 'v.proj input=dembox
location=dem10m_northwest' without error. However, running 'g.region
vect=dembox' followed by 'g.region -p' shows:

projection: 99 (Lambert Conformal Conic)
zone:       0
datum:      nad83
ellipsoid:  grs80
north:      1735231.4372465
south:      1120657.13248051
west:       -768668.81031769
east:       40643.22944943
nsres:      32.8315778
ewres:      32.83479551
rows:       18719
cols:       24648
cells:      461385912

   Before running 'g.region vect=dembox' 'g.region -p' showed:

proj:       99
zone:       0
north:      1326000
south:      1278000
east:       817000
west:       766500
cols:       1538
rows:       1462
e-w resol:  32.83485046
n-s resol:  32.83173735
top:        1
bottom:     0
cols3:      50500
rows3:      48000
depths:     1
e-w resol3: 1
n-s resol3: 1
t-b resol:  1

   Both north and south were extended, but the east-west bounds seem totally
unrealistic.

   What might I have missed here? To what should I change the e-w and n-s
resolutions after fixing the first issue?

Thanks,

Rich
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: r.proj: fixing a failure

DanielV
Could it be that the vector created by v.in.region is messed up, or
it's covering a larger area that you are not interested in?

Last time I used r.proj here is how I did it:
1) Go to source location and set the region to match the area I want to project
2) Create a bounding box (v.in.region)
3) Write down the resolution and number of columns, rows of the region
4) Exit grass and start over in new location
5) Bring in bounding box (v.proj)
6) Set region to bounding box (g.region vect=) and set resolution
(g.region res=xx). Here I follow Hamish advice and try to set the
number of col and row a bit higher then the number in the original
region.
7) Bring in raster (r.proj)

Cheers
Daniel

On Tue, Dec 22, 2009 at 3:59 PM, Rich Shepard <[hidden email]> wrote:

> On Tue, 22 Dec 2009, Daniel Victoria wrote:
>
>> So, in order to know where you projected raster will fall, you can use
>> the v.in.region trick. The command will create a bounding box in your
>> map and you can project the vector (using v.proj), and not wory about
>> the current region. Then you set your region to the recently projected
>> vector (g.region vect=box) and fix your resolution. Now you are ready
>> to project your raster and you know the current region matches the
>> region where your raster is coming from.
>
> Daniel,
>
>  Despite my reading the r.proj man page I missed the critical point that
> you and Hamish tried pointing out: that v.in.region is run on the raster
> location, not the target location.
>
>  Working my way through the r.proj man page note (as you summarize above),
> I end with screwy region results.
>
>  v.in.region worked; I call the output area (it should be area and not
> line, correct?) 'dembox.' Exiting grass and restarting to reset the location
> to that of the project, I ran 'v.proj input=dembox
> location=dem10m_northwest' without error. However, running 'g.region
> vect=dembox' followed by 'g.region -p' shows:
>
> projection: 99 (Lambert Conformal Conic)
> zone:       0
> datum:      nad83
> ellipsoid:  grs80
> north:      1735231.4372465
> south:      1120657.13248051
> west:       -768668.81031769
> east:       40643.22944943
> nsres:      32.8315778
> ewres:      32.83479551
> rows:       18719
> cols:       24648
> cells:      461385912
>
>  Before running 'g.region vect=dembox' 'g.region -p' showed:
>
> proj:       99
> zone:       0
> north:      1326000
> south:      1278000
> east:       817000
> west:       766500
> cols:       1538
> rows:       1462
> e-w resol:  32.83485046
> n-s resol:  32.83173735
> top:        1
> bottom:     0
> cols3:      50500
> rows3:      48000
> depths:     1
> e-w resol3: 1
> n-s resol3: 1
> t-b resol:  1
>
>  Both north and south were extended, but the east-west bounds seem totally
> unrealistic.
>
>  What might I have missed here? To what should I change the e-w and n-s
> resolutions after fixing the first issue?
>
> Thanks,
>
> Rich
> _______________________________________________
> grass-user mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: r.proj: fixing a failure

Rich Shepard
On Tue, 22 Dec 2009, Daniel Victoria wrote:

> Could it be that the vector created by v.in.region is messed up, or
> it's covering a larger area that you are not interested in?

Daniel,

   Anything's possible at this point. I've apparently trashed the target
location's projection; trying to set it to an existing vector map results in
negative values and an inability to display any of the reprojected vector
maps. I suppose I need to start over. Sigh. Can't bill the client for this
time.

> Last time I used r.proj here is how I did it:
> 1) Go to source location and set the region to match the area I want to project

   There are differences between the raster DEM location's region and that of
all the vector maps. The former is the northwest portion of the latter. I
would have thought that the smaller region would easily be accommodated by
the larger one, with (perhaps) the northern and western bounds adjusted to
match.

   I'll work on this part first.

Thanks,

Rich
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: r.proj: fixing a failure

Glynn Clements
In reply to this post by Rich Shepard

Rich Shepard wrote:

> >> Set the output location's region to the extent of your to-be-reprojected
> >> data, before running r.proj in the input location.
>
>    This message never arrived here.

You may want to check your mailman preferences:

        http://lists.osgeo.org/mailman/listinfo/grass-user

Ensure that the "Avoid duplicate copies of messages?" option is set to
"no".

Otherwise, if someone replies to one of your posts with "reply to all"
(which was the case for Maciej's reply), mailman won't send you a copy.
If the copy which was sent directly to you then gets dropped by a spam
filter, you won't see the message at all.

[Anyone at gmx.de with this "feature" enabled will never get a reply
from me, as gmx.de doesn't seem to like my IP address.]

--
Glynn Clements <[hidden email]>
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: r.proj: fixing a failure

Glynn Clements
In reply to this post by Rich Shepard

Rich Shepard wrote:

>    Trying to bring in the raster DEM to the project location, but r.proj
> fails because of a difference in false eastings:
>
> GRASS 6.4.0svn (beaver_lake):/usr4/grassbase > r.proj input=elevation10m
> location=dem10m_northwest output=DEM method=cubic
> Input Projection Parameters:  +proj=lcc +lat_1=43 +lat_2=45.5 +lat_0=41.75
> +lon_0=-120.5 +x_0=1312336 +y_0=0 +no_defs +a=6378137 +rf=298.257222101
> +nadgrids=/usr/local/grass-6.4.0svn/etc/nad/WO
> Input Unit Factor: 1
> Output Projection Parameters:  +proj=lcc +lat_1=43 +lat_2=45.5 +lat_0=41.75
> +lon_0=-120.5 +x_0=399999.9999999999 +y_0=0 +no_defs +a=6378137
> +rf=298.257222101 +nadgrids=/usr/local/grass-6.4.0svn/etc/nad/WO
> Output Unit Factor: 1
> ERROR: Input raster map is outside current region

>    The input location's PROJ_INFO file contains:

> x_0: 1312336

> and the destination location's PROJ_INFO file contains:

> x_0: 399999.9999999999

Note: 1312336 * 0.3048 = 400000.0128

>    Both have meters as PROJ_UNITS.
>
>    The original metadata for the 10m DEM shows the following:

>    Planar_Distance_Units: User_Defined_Unit

Have your investigated the possibility of a feet/metres mismatch?

I suggest using m.proj in both the source and target locations to
check that both projections are correct. If they aren't, the results
of v.proj and r.proj will be nonsense.

--
Glynn Clements <[hidden email]>
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: r.proj: fixing a failure

Rich Shepard
In reply to this post by Glynn Clements
On Tue, 22 Dec 2009, Glynn Clements wrote:

> You may want to check your mailman preferences:
>
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
> Ensure that the "Avoid duplicate copies of messages?" option is set to
> "no".

Glynn,

   That's interesting. I've never set that for any other mail list. Ergo, the
others must default to 'no.'

> Otherwise, if someone replies to one of your posts with "reply to all"
> (which was the case for Maciej's reply), mailman won't send you a copy. If
> the copy which was sent directly to you then gets dropped by a spam
> filter, you won't see the message at all.

   Well, if the duplicate copy block is set to 'yes,' but my address was
either the primary or in the cc field, shouldn't I get either the one To: me
or the one To: [hidden email]?

   Anywho, I changed the default 'yes' to 'no.'

Thank you,

Rich
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: r.proj: fixing a failure

Glynn Clements

Rich Shepard wrote:

> > Otherwise, if someone replies to one of your posts with "reply to all"
> > (which was the case for Maciej's reply), mailman won't send you a copy. If
> > the copy which was sent directly to you then gets dropped by a spam
> > filter, you won't see the message at all.
>
>    Well, if the duplicate copy block is set to 'yes,' but my address was
> either the primary or in the cc field, shouldn't I get either the one To: me

Provided that it wasn't blocked by a spam filter.

> or the one To: [hidden email]?

No; the anti-duplicates option prevents that from being sent when
you're listed in the To/CC headers.

Mailman only knows whether you were listed in the To/CC headers; it
doesn't know whether you actually received the email directly from the
sender.

--
Glynn Clements <[hidden email]>
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: r.proj: fixing a failure

Rich Shepard
On Wed, 23 Dec 2009, Glynn Clements wrote:

> Provided that it wasn't blocked by a spam filter.

   Shouldn't have been. I can grep the maillog, but I've changed the option
so this should be moot now.

   I'm still running majordomo; keep meaning to move to mailman but cannot
make the time.

Thanks,

Rich
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user