[GRASSLIST:7889] r.proj takes a very long time / does not complete

I have a long-standing problem with r.proj. I have never been able to complete a successful re-projection of a raster file. For example, I am trying to pull in a raster file from a location that is lat-lon, WGS84 into a location that is state-plane meters, NAD83. The raster grid is relatively small, 1000 cols by 830 rows. I start r.proj like this:

r.proj input=KEWX20040710_025420 location=TX_ll_WGS84 mapset=PERMANENT output=proj1 method=nearest

Although my CPU stays pegged at close to 100% usage, the progress bar never moves forward and nothing happens, even if I leave it for many hours. Can anyone tell me what’s going on here?

Jason Horn

Boston University Department of Biology

5 Cumington Street Boston, MA 02215

jhorn@bu.edu

office: 617 353 6987

cell: 401 588 2766

Jason Horn wrote:

I have a long-standing problem with r.proj. I have never been able to complete a successful re-projection of a raster file. For example, I am trying to pull in a raster file from a location that is lat-lon, WGS84 into a location that is state-plane meters, NAD83. The raster grid is relatively small, 1000 cols by 830 rows. I start r.proj like this:

r.proj input=KEWX20040710_025420 location=TX_ll_WGS84 mapset=PERMANENT output=proj1 method=nearest

Although my CPU stays pegged at close to 100% usage, the progress bar never moves forward and nothing happens, even if I leave it for many hours. Can anyone tell me what's going on here?

In order to help you I would like to see:

1) The PROJ_INFO file for your latlon location
2) The cellhd file of the KEWX20040710_025420 map in the latlon location
3) The PROJ_INFO file for your NAD83 location
4) The WIND file for your NAD83 location

Morten,

Thanks for looking at this for me. Below are the files you asked for.

PROJ_INFO for the source lat-lon location:

name: Latitude-Longitude
datum: wgs84
towgs84: 0.000,0.000,0.000
proj: ll
ellps: wgs84

cellhd file for KEWX20040710_025420:

proj: 3
zone: 0
north: 34:00:17.832478N
south: 25:11:59.799175N
east: 92:43:25.599215W
west: 103:19:56.000785W
cols: 1000
rows: 830
e-w resol: 0:00:38.190402
n-s resol: 0:00:38.190402
format: -1
compressed: 1

PROJ_INFO file for the destination NAD83 location:

name: Lambert Conformal Conic
datum: nad83
towgs84: 0.000,0.000,0.000
proj: lcc
ellps: grs80
a: 6378137.0000000000
es: 0.0066943800
f: 298.2572221010
lat_0: 31.1666670000
lat_1: 27.4166670000
lat_2: 34.9166670000
lon_0: -100.0000000000
x_0: 1000000.0000000000
y_0: 1000000.0000000000

WIND file for the destination NAD83 location:

proj: 99
zone: 0
north: 1196061
south: 573534
east: 1563147
west: 715822
cols: 847325
rows: 622527
e-w resol: 1
n-s resol: 1
top: 1
bottom: 0
cols3: 847325
rows3: 622527
depths: 1
e-w resol3: 1
n-s resol3: 1
t-b resol: 1

Thanks again!

- Jason

On Aug 13, 2005, at 12:14 PM, Morten Hulden wrote:

Jason Horn wrote:

I have a long-standing problem with r.proj. I have never been able to complete a successful re-projection of a raster file. For example, I am trying to pull in a raster file from a location that is lat-lon, WGS84 into a location that is state-plane meters, NAD83. The raster grid is relatively small, 1000 cols by 830 rows. I start r.proj like this:
r.proj input=KEWX20040710_025420 location=TX_ll_WGS84 mapset=PERMANENT output=proj1 method=nearest Although my CPU stays pegged at close to 100% usage, the progress bar never moves forward and nothing happens, even if I leave it for many hours. Can anyone tell me what's going on here?

In order to help you I would like to see:

1) The PROJ_INFO file for your latlon location
2) The cellhd file of the KEWX20040710_025420 map in the latlon location
3) The PROJ_INFO file for your NAD83 location
4) The WIND file for your NAD83 location

No wonder it takes forever. Your output location has 527482690275 cells (847325 x 622527) to project.

You should adjust the boundaries or resolution of your NAD83 location to something more reasonable. Before running r.proj try to set a resolution value that roughly matches the resolution of your input map (g.region res= ), e.g. something like 1000 m.

Don't know about boundaries for your location (TX unknown area to me) but you may want to check those as well. No need to cover more than what is necessary.

rgds
Morten

Jason Horn wrote:

Morten,

Thanks for looking at this for me. Below are the files you asked for.

PROJ_INFO for the source lat-lon location:

name: Latitude-Longitude
datum: wgs84
towgs84: 0.000,0.000,0.000
proj: ll
ellps: wgs84

cellhd file for KEWX20040710_025420:

proj: 3
zone: 0
north: 34:00:17.832478N
south: 25:11:59.799175N
east: 92:43:25.599215W
west: 103:19:56.000785W
cols: 1000
rows: 830
e-w resol: 0:00:38.190402
n-s resol: 0:00:38.190402
format: -1
compressed: 1

PROJ_INFO file for the destination NAD83 location:

name: Lambert Conformal Conic
datum: nad83
towgs84: 0.000,0.000,0.000
proj: lcc
ellps: grs80
a: 6378137.0000000000
es: 0.0066943800
f: 298.2572221010
lat_0: 31.1666670000
lat_1: 27.4166670000
lat_2: 34.9166670000
lon_0: -100.0000000000
x_0: 1000000.0000000000
y_0: 1000000.0000000000

WIND file for the destination NAD83 location:

proj: 99
zone: 0
north: 1196061
south: 573534
east: 1563147
west: 715822
cols: 847325
rows: 622527
e-w resol: 1
n-s resol: 1
top: 1
bottom: 0
cols3: 847325
rows3: 622527
depths: 1
e-w resol3: 1
n-s resol3: 1
t-b resol: 1

Thanks again!

- Jason

On Aug 13, 2005, at 12:14 PM, Morten Hulden wrote:

Jason Horn wrote:

I have a long-standing problem with r.proj. I have never been able to complete a successful re-projection of a raster file. For example, I am trying to pull in a raster file from a location that is lat-lon, WGS84 into a location that is state-plane meters, NAD83. The raster grid is relatively small, 1000 cols by 830 rows. I start r.proj like this:
r.proj input=KEWX20040710_025420 location=TX_ll_WGS84 mapset=PERMANENT output=proj1 method=nearest Although my CPU stays pegged at close to 100% usage, the progress bar never moves forward and nothing happens, even if I leave it for many hours. Can anyone tell me what's going on here?

In order to help you I would like to see:

1) The PROJ_INFO file for your latlon location
2) The cellhd file of the KEWX20040710_025420 map in the latlon location
3) The PROJ_INFO file for your NAD83 location
4) The WIND file for your NAD83 location

A simple way to do this is to make a vector box of your region in the first location using v.in.region. Go to your new location, v.proj that vector in, and set your region to the new vector. Then use r.proj on the raster you want to project. You will still have to set the resolution on your own though. Hope this makes sense.

-Ian

On Aug 15, 2005, at 2:14 PM, Morten Hulden wrote:

No wonder it takes forever. Your output location has 527482690275 cells (847325 x 622527) to project.

You should adjust the boundaries or resolution of your NAD83 location to something more reasonable. Before running r.proj try to set a resolution value that roughly matches the resolution of your input map (g.region res= ), e.g. something like 1000 m.

Don't know about boundaries for your location (TX unknown area to me) but you may want to check those as well. No need to cover more than what is necessary.

rgds
Morten

Jason Horn wrote:

Morten,
Thanks for looking at this for me. Below are the files you asked for.
PROJ_INFO for the source lat-lon location:
name: Latitude-Longitude
datum: wgs84
towgs84: 0.000,0.000,0.000
proj: ll
ellps: wgs84
cellhd file for KEWX20040710_025420:
proj: 3
zone: 0
north: 34:00:17.832478N
south: 25:11:59.799175N
east: 92:43:25.599215W
west: 103:19:56.000785W
cols: 1000
rows: 830
e-w resol: 0:00:38.190402
n-s resol: 0:00:38.190402
format: -1
compressed: 1
PROJ_INFO file for the destination NAD83 location:
name: Lambert Conformal Conic
datum: nad83
towgs84: 0.000,0.000,0.000
proj: lcc
ellps: grs80
a: 6378137.0000000000
es: 0.0066943800
f: 298.2572221010
lat_0: 31.1666670000
lat_1: 27.4166670000
lat_2: 34.9166670000
lon_0: -100.0000000000
x_0: 1000000.0000000000
y_0: 1000000.0000000000
WIND file for the destination NAD83 location:
proj: 99
zone: 0
north: 1196061
south: 573534
east: 1563147
west: 715822
cols: 847325
rows: 622527
e-w resol: 1
n-s resol: 1
top: 1
bottom: 0
cols3: 847325
rows3: 622527
depths: 1
e-w resol3: 1
n-s resol3: 1
t-b resol: 1
Thanks again!
- Jason
On Aug 13, 2005, at 12:14 PM, Morten Hulden wrote:

Jason Horn wrote:

I have a long-standing problem with r.proj. I have never been able to complete a successful re-projection of a raster file. For example, I am trying to pull in a raster file from a location that is lat-lon, WGS84 into a location that is state-plane meters, NAD83. The raster grid is relatively small, 1000 cols by 830 rows. I start r.proj like this:
r.proj input=KEWX20040710_025420 location=TX_ll_WGS84 mapset=PERMANENT output=proj1 method=nearest Although my CPU stays pegged at close to 100% usage, the progress bar never moves forward and nothing happens, even if I leave it for many hours. Can anyone tell me what's going on here?

In order to help you I would like to see:

1) The PROJ_INFO file for your latlon location
2) The cellhd file of the KEWX20040710_025420 map in the latlon location
3) The PROJ_INFO file for your NAD83 location
4) The WIND file for your NAD83 location

Ian, Morten,

Thanks so much for pointing out the problem. I have seceded in projecting the raster layer, with the help of the v.in.region box trick. I have set the resolution to an approximation of what I think is right. However, how can I really match the resolution in the new state plane location to the resolution from the old lat-lon location?

- Jason

On Aug 15, 2005, at 5:25 PM, Ian MacMillan wrote:

A simple way to do this is to make a vector box of your region in the first location using v.in.region. Go to your new location, v.proj that vector in, and set your region to the new vector. Then use r.proj on the raster you want to project. You will still have to set the resolution on your own though. Hope this makes sense.

-Ian

On Aug 15, 2005, at 2:14 PM, Morten Hulden wrote:

No wonder it takes forever. Your output location has 527482690275 cells (847325 x 622527) to project.

You should adjust the boundaries or resolution of your NAD83 location to something more reasonable. Before running r.proj try to set a resolution value that roughly matches the resolution of your input map (g.region res= ), e.g. something like 1000 m.

Don't know about boundaries for your location (TX unknown area to me) but you may want to check those as well. No need to cover more than what is necessary.

rgds
Morten

Jason Horn wrote:

Morten,
Thanks for looking at this for me. Below are the files you asked for.
PROJ_INFO for the source lat-lon location:
name: Latitude-Longitude
datum: wgs84
towgs84: 0.000,0.000,0.000
proj: ll
ellps: wgs84
cellhd file for KEWX20040710_025420:
proj: 3
zone: 0
north: 34:00:17.832478N
south: 25:11:59.799175N
east: 92:43:25.599215W
west: 103:19:56.000785W
cols: 1000
rows: 830
e-w resol: 0:00:38.190402
n-s resol: 0:00:38.190402
format: -1
compressed: 1
PROJ_INFO file for the destination NAD83 location:
name: Lambert Conformal Conic
datum: nad83
towgs84: 0.000,0.000,0.000
proj: lcc
ellps: grs80
a: 6378137.0000000000
es: 0.0066943800
f: 298.2572221010
lat_0: 31.1666670000
lat_1: 27.4166670000
lat_2: 34.9166670000
lon_0: -100.0000000000
x_0: 1000000.0000000000
y_0: 1000000.0000000000
WIND file for the destination NAD83 location:
proj: 99
zone: 0
north: 1196061
south: 573534
east: 1563147
west: 715822
cols: 847325
rows: 622527
e-w resol: 1
n-s resol: 1
top: 1
bottom: 0
cols3: 847325
rows3: 622527
depths: 1
e-w resol3: 1
n-s resol3: 1
t-b resol: 1
Thanks again!
- Jason
On Aug 13, 2005, at 12:14 PM, Morten Hulden wrote:

Jason Horn wrote:

I have a long-standing problem with r.proj. I have never been able to complete a successful re-projection of a raster file. For example, I am trying to pull in a raster file from a location that is lat-lon, WGS84 into a location that is state-plane meters, NAD83. The raster grid is relatively small, 1000 cols by 830 rows. I start r.proj like this:
r.proj input=KEWX20040710_025420 location=TX_ll_WGS84 mapset=PERMANENT output=proj1 method=nearest Although my CPU stays pegged at close to 100% usage, the progress bar never moves forward and nothing happens, even if I leave it for many hours. Can anyone tell me what's going on here?

In order to help you I would like to see:

1) The PROJ_INFO file for your latlon location
2) The cellhd file of the KEWX20040710_025420 map in the latlon location
3) The PROJ_INFO file for your NAD83 location
4) The WIND file for your NAD83 location

A rule of thumb that I use is that 1 arc-second equals 30 meters. This is close enough for the work that I do. It varies away from the equator, and I am not sure if it is exactly 30 meters, it probably depend on the type of ellipsoid used for the earth. Hope this helps.

-Ian

On Aug 17, 2005, at 11:41 AM, Jason Horn wrote:

Ian, Morten,

Thanks so much for pointing out the problem. I have seceded in projecting the raster layer, with the help of the v.in.region box trick. I have set the resolution to an approximation of what I think is right. However, how can I really match the resolution in the new state plane location to the resolution from the old lat-lon location?

- Jason

On Aug 15, 2005, at 5:25 PM, Ian MacMillan wrote:

A simple way to do this is to make a vector box of your region in the first location using v.in.region. Go to your new location, v.proj that vector in, and set your region to the new vector. Then use r.proj on the raster you want to project. You will still have to set the resolution on your own though. Hope this makes sense.

-Ian

On Aug 15, 2005, at 2:14 PM, Morten Hulden wrote:

No wonder it takes forever. Your output location has 527482690275 cells (847325 x 622527) to project.

You should adjust the boundaries or resolution of your NAD83 location to something more reasonable. Before running r.proj try to set a resolution value that roughly matches the resolution of your input map (g.region res= ), e.g. something like 1000 m.

Don't know about boundaries for your location (TX unknown area to me) but you may want to check those as well. No need to cover more than what is necessary.

rgds
Morten

Jason Horn wrote:

Morten,
Thanks for looking at this for me. Below are the files you asked for.
PROJ_INFO for the source lat-lon location:
name: Latitude-Longitude
datum: wgs84
towgs84: 0.000,0.000,0.000
proj: ll
ellps: wgs84
cellhd file for KEWX20040710_025420:
proj: 3
zone: 0
north: 34:00:17.832478N
south: 25:11:59.799175N
east: 92:43:25.599215W
west: 103:19:56.000785W
cols: 1000
rows: 830
e-w resol: 0:00:38.190402
n-s resol: 0:00:38.190402
format: -1
compressed: 1
PROJ_INFO file for the destination NAD83 location:
name: Lambert Conformal Conic
datum: nad83
towgs84: 0.000,0.000,0.000
proj: lcc
ellps: grs80
a: 6378137.0000000000
es: 0.0066943800
f: 298.2572221010
lat_0: 31.1666670000
lat_1: 27.4166670000
lat_2: 34.9166670000
lon_0: -100.0000000000
x_0: 1000000.0000000000
y_0: 1000000.0000000000
WIND file for the destination NAD83 location:
proj: 99
zone: 0
north: 1196061
south: 573534
east: 1563147
west: 715822
cols: 847325
rows: 622527
e-w resol: 1
n-s resol: 1
top: 1
bottom: 0
cols3: 847325
rows3: 622527
depths: 1
e-w resol3: 1
n-s resol3: 1
t-b resol: 1
Thanks again!
- Jason
On Aug 13, 2005, at 12:14 PM, Morten Hulden wrote:

Jason Horn wrote:

I have a long-standing problem with r.proj. I have never been able to complete a successful re-projection of a raster file. For example, I am trying to pull in a raster file from a location that is lat-lon, WGS84 into a location that is state-plane meters, NAD83. The raster grid is relatively small, 1000 cols by 830 rows. I start r.proj like this:
r.proj input=KEWX20040710_025420 location=TX_ll_WGS84 mapset=PERMANENT output=proj1 method=nearest Although my CPU stays pegged at close to 100% usage, the progress bar never moves forward and nothing happens, even if I leave it for many hours. Can anyone tell me what's going on here?

In order to help you I would like to see:

1) The PROJ_INFO file for your latlon location
2) The cellhd file of the KEWX20040710_025420 map in the latlon location
3) The PROJ_INFO file for your NAD83 location
4) The WIND file for your NAD83 location

What happens if a big asteroid hits Earth? Judging from realistic simulations involving a sledge hammer and a common laboratory frog, we can assume it will be pretty bad.
  - Dave Barry

This message has been scanned by anti-virus software.

From: "Jason Horn" <jhorn@bu.edu>

<snip>

However, how can I really match the resolution in the new state plane
location to the resolution from the old lat-lon location?

gdalwarp your input not defining the -tr (output resolution). gdalwarp
should be able to estimate a resonable res. Maybe try -tps if your input is
particulary huge. Then r.proj with the same res and compare which output you like best.

That would be very handy if r.proj could estimate the best output resolution
as well. I remember there was some discussion about completely replacing
r.proj warper with gdal warper. Any news?

Maciek

Hello Maciek

On Wed, 17 Aug 2005, Maciek Sieczka wrote:

That would be very handy if r.proj could estimate the best output resolution
as well. I remember there was some discussion about completely replacing
r.proj warper with gdal warper. Any news?

The way I see it is that they perform two different, complementary functions. gdalwarp is useful if you have a whole map/image you want to convert to a new projection and not lose any of the data. r.proj is useful if you already have a region of interest you're working on in the GIS, and want to import only the portion of the larger map/image that covers this
region, at the same resolution and with the same boundaries etc. as your existing maps in your location.

Does that make sense?

Paul

Jason Horn wrote:

Thanks so much for pointing out the problem. I have seceded in projecting the raster layer, with the help of the v.in.region box trick. I have set the resolution to an approximation of what I think is right. However, how can I really match the resolution in the new state plane location to the resolution from the old lat-lon location?

Since latlon resolution is measured in degrees while most projections use meters unit you have to approximate. At the equator one degree = 40,000,000/360 meters for both longitude and latitude but further north or south the length of a one degree longitude arc decreases since meridians converge toward poles.

But assuming a fixed value 40,000,000/360 for a one degree arc then:
the resolution of your latlon map 0:00:38.190402 becomes:

40,000,000 / 360 / 60 / 60 * 38.190402 = 1178.7161111111 meters

You may of course use a more exact value for the earth's perimeter instad of 40,000,000 meters but since the projection involves resampling errors anyway I don't think it will make a big difference. 1000 meters resolution would probably be close enough.

On Aug 15, 2005, at 5:25 PM, Ian MacMillan wrote:

A simple way to do this is to make a vector box of your region in the first location using v.in.region. Go to your new location, v.proj that vector in, and set your region to the new vector. Then use r.proj on the raster you want to project.

On Aug 15, 2005, at 2:14 PM, Morten Hulden wrote:

You should adjust the boundaries or resolution of your NAD83 location to something more reasonable. Before running r.proj try to set a resolution value that roughly matches the resolution of your input map (g.region res= ), e.g. something like 1000 m.

Don't know about boundaries for your location (TX unknown area to me) but you may want to check those as well. No need to cover more than what is necessary.

I don't think this is necessary to use the v.in.region trick here because r.proj will trim down the map anyway to the area that is overlapping the current region. What I meant was that if you have a very large region in your location (847325 x 622527 cells) you probably do not want to have a small resolution of 1 meter. Either reduce the region to an area of interest or increase the resolution, or both.

My own preferrence is to use a rather coarse resolution for the default region within a location, say a utm zone within my country - 456 meters matches both landsat mosaics and 30-arcsec DEMs close enough. For selected areas of interest within the location I create regions with decreased coverage but increased resolution, 57, 28.5 (landsat5), and 14.25 meters (landsat7 visual band) and even less than that for my own house and back garden.

For maps with greater resolution than my default region's I create a region with matching resolution before projecting. I gain nothing by trying to project a coarse map into a finer grained region, I only lose disk space and time.

This way I can keep all maps I want to analyze together within a single location in Grass without wasting space and computation time on areas not relevant for the tasks I want to do.

rgds
Morten

Jason Horn wrote:

Morten,
Thanks for looking at this for me. Below are the files you asked for.
PROJ_INFO for the source lat-lon location:
name: Latitude-Longitude
datum: wgs84
towgs84: 0.000,0.000,0.000
proj: ll
ellps: wgs84
cellhd file for KEWX20040710_025420:
proj: 3
zone: 0
north: 34:00:17.832478N
south: 25:11:59.799175N
east: 92:43:25.599215W
west: 103:19:56.000785W
cols: 1000
rows: 830
e-w resol: 0:00:38.190402
n-s resol: 0:00:38.190402
format: -1
compressed: 1
PROJ_INFO file for the destination NAD83 location:
name: Lambert Conformal Conic
datum: nad83
towgs84: 0.000,0.000,0.000
proj: lcc
ellps: grs80
a: 6378137.0000000000
es: 0.0066943800
f: 298.2572221010
lat_0: 31.1666670000
lat_1: 27.4166670000
lat_2: 34.9166670000
lon_0: -100.0000000000
x_0: 1000000.0000000000
y_0: 1000000.0000000000
WIND file for the destination NAD83 location:
proj: 99
zone: 0
north: 1196061
south: 573534
east: 1563147
west: 715822
cols: 847325
rows: 622527
e-w resol: 1
n-s resol: 1
top: 1
bottom: 0
cols3: 847325
rows3: 622527
depths: 1
e-w resol3: 1
n-s resol3: 1
t-b resol: 1
Thanks again!
- Jason
On Aug 13, 2005, at 12:14 PM, Morten Hulden wrote:

Jason Horn wrote:

I have a long-standing problem with r.proj. I have never been able to complete a successful re-projection of a raster file. For example, I am trying to pull in a raster file from a location that is lat-lon, WGS84 into a location that is state- plane meters, NAD83. The raster grid is relatively small, 1000 cols by 830 rows. I start r.proj like this:
r.proj input=KEWX20040710_025420 location=TX_ll_WGS84 mapset=PERMANENT output=proj1 method=nearest Although my CPU stays pegged at close to 100% usage, the progress bar never moves forward and nothing happens, even if I leave it for many hours. Can anyone tell me what's going on here?

In order to help you I would like to see:

1) The PROJ_INFO file for your latlon location
2) The cellhd file of the KEWX20040710_025420 map in the latlon location
3) The PROJ_INFO file for your NAD83 location
4) The WIND file for your NAD83 location

I think that it is a conceptual mistake to consider a raster data set
in lat-long to have a "resolution" in the same sense as a projected
map. Degrees of latitude and longitude do not have constant spacing.
So a single resolution defined in meters (or whatnot) doesn't exist
(even on the globe) Now add to that, GIS can't work on ellipsoidal
surfaces and must project the globe onto a flat plane. So not only do
degrees have variable spacing to begin with, they must be warped to
get them into the flat-earth of the GIS.

I think it is best to consider lat-long grids a convenient storage
mechanism for variably spaced points because by the time you can
actually use them in a GIS (after projection and conversion to a
Cartesian coordinate system), that's what they will be. The point is
to remember that the conversion from geographic coordinates to
projected coordinates is a major transformation and not a simple
coordinate shift and resample problem.

As for how to estimate the resolution, I usually run the 4 corners of
my geographic data through proj to get the Cartesian coordinates
(State Plane, UTM, etc.). Now everything is on "flat-earth" and you
can calculate the appropriate resolution for your data with simple
arithmetic (after all, that's why we invented map projections!).

As a curiosity, if you want a spreadsheet that calculates the
ellipsoidal distance between any two points on the earth, send me an
email and I'll post it up on the web.

David

On 8/17/05, Jason Horn <jhorn@bu.edu> wrote:

Ian, Morten,

Thanks so much for pointing out the problem. I have seceded in
projecting the raster layer, with the help of the v.in.region box
trick. I have set the resolution to an approximation of what I think
is right. However, how can I really match the resolution in the new
state plane location to the resolution from the old lat-lon location?

- Jason

On Aug 15, 2005, at 5:25 PM, Ian MacMillan wrote:

> A simple way to do this is to make a vector box of your region in
> the first location using v.in.region. Go to your new location,
> v.proj that vector in, and set your region to the new vector. Then
> use r.proj on the raster you want to project. You will still have
> to set the resolution on your own though. Hope this makes sense.
>
> -Ian
>
> On Aug 15, 2005, at 2:14 PM, Morten Hulden wrote:
>
>
>>
>>
>> No wonder it takes forever. Your output location has 527482690275
>> cells (847325 x 622527) to project.
>>
>> You should adjust the boundaries or resolution of your NAD83
>> location to something more reasonable. Before running r.proj try
>> to set a resolution value that roughly matches the resolution of
>> your input map (g.region res= ), e.g. something like 1000 m.
>>
>> Don't know about boundaries for your location (TX unknown area to
>> me) but you may want to check those as well. No need to cover more
>> than what is necessary.
>>
>> rgds
>> Morten
>>
>>
>> Jason Horn wrote:
>>
>>> Morten,
>>> Thanks for looking at this for me. Below are the files you asked
>>> for.
>>> PROJ_INFO for the source lat-lon location:
>>> name: Latitude-Longitude
>>> datum: wgs84
>>> towgs84: 0.000,0.000,0.000
>>> proj: ll
>>> ellps: wgs84
>>> cellhd file for KEWX20040710_025420:
>>> proj: 3
>>> zone: 0
>>> north: 34:00:17.832478N
>>> south: 25:11:59.799175N
>>> east: 92:43:25.599215W
>>> west: 103:19:56.000785W
>>> cols: 1000
>>> rows: 830
>>> e-w resol: 0:00:38.190402
>>> n-s resol: 0:00:38.190402
>>> format: -1
>>> compressed: 1
>>> PROJ_INFO file for the destination NAD83 location:
>>> name: Lambert Conformal Conic
>>> datum: nad83
>>> towgs84: 0.000,0.000,0.000
>>> proj: lcc
>>> ellps: grs80
>>> a: 6378137.0000000000
>>> es: 0.0066943800
>>> f: 298.2572221010
>>> lat_0: 31.1666670000
>>> lat_1: 27.4166670000
>>> lat_2: 34.9166670000
>>> lon_0: -100.0000000000
>>> x_0: 1000000.0000000000
>>> y_0: 1000000.0000000000
>>> WIND file for the destination NAD83 location:
>>> proj: 99
>>> zone: 0
>>> north: 1196061
>>> south: 573534
>>> east: 1563147
>>> west: 715822
>>> cols: 847325
>>> rows: 622527
>>> e-w resol: 1
>>> n-s resol: 1
>>> top: 1
>>> bottom: 0
>>> cols3: 847325
>>> rows3: 622527
>>> depths: 1
>>> e-w resol3: 1
>>> n-s resol3: 1
>>> t-b resol: 1
>>> Thanks again!
>>> - Jason
>>> On Aug 13, 2005, at 12:14 PM, Morten Hulden wrote:
>>>
>>>> Jason Horn wrote:
>>>>
>>>>
>>>>> I have a long-standing problem with r.proj. I have never been
>>>>> able to complete a successful re-projection of a raster file.
>>>>> For example, I am trying to pull in a raster file from a
>>>>> location that is lat-lon, WGS84 into a location that is state-
>>>>> plane meters, NAD83. The raster grid is relatively small,
>>>>> 1000 cols by 830 rows. I start r.proj like this:
>>>>> r.proj input=KEWX20040710_025420 location=TX_ll_WGS84
>>>>> mapset=PERMANENT output=proj1 method=nearest Although my CPU
>>>>> stays pegged at close to 100% usage, the progress bar never
>>>>> moves forward and nothing happens, even if I leave it for many
>>>>> hours. Can anyone tell me what's going on here?
>>>>>
>>>>>
>>>>
>>>> In order to help you I would like to see:
>>>>
>>>> 1) The PROJ_INFO file for your latlon location
>>>> 2) The cellhd file of the KEWX20040710_025420 map in the latlon
>>>> location
>>>> 3) The PROJ_INFO file for your NAD83 location
>>>> 4) The WIND file for your NAD83 location
>>>>
>>>>
>>>>
>>>>
>>
>>
>
>
>

--
David Finlayson
Marine Geology & Geophysics
School of Oceanography
Box 357940
University of Washington
Seattle, WA 98195-7940
USA

Office: Marine Sciences Building, Room 112
Phone: (206) 616-9407
Web: http://students.washington.edu/dfinlays

The only reason to project the corners is to allow you to make a guess
at an appropriate resolution for your data before you run r.proj.
Another way would be to run r.proj on the data and deliberately use a
low-resolution setting (just to get the raster into projected space
quickly). You can then use d.measure to measure the length and width
of the data area (in meters or feet now instead of fractions of a
degree). Then run r.proj again at a better resolution for your data.

I'll get on my soap box...

Take a few examples, the National DEM of the United States (USGS) is
distributed in "geographic" projection, which is ESRI-speak for it has
no projection at all.

At 30N the length of 1 arc second is about 27 m, at 50N it is 20 m. So
the longitudinal "resolution" of the US Map narrows by about 25% from
the bottom of the US to the top. Why they chose to do this is beyond
me. But at least in the figures of the USA they show a beautiful
Lambert projection of the US. Clearly, THEY know you need to project
the data before you can use it. (http://ned.usgs.gov/)

The national coastal relief model does the same thing (storing data in
lat-long grids) with their bathymetric data. Only here, the maps they
produced used a Mercator projection (the default projection of all
oceanographers) which grossly distorts the shape of North America:

http://www.ngdc.noaa.gov/mgg/coastal/coastal.html

My favorite map is this one which manages to distort the longitudinal
distance of the Pacific Northwest by 156%:

http://www.ngdc.noaa.gov/mgg/coastal/grddas08/grddas08.htm

With cartography like this, what else lurks in these data?

OK, I'm standing down.

David

On 8/19/05, Jason Horn <jhorn@bu.edu> wrote:

David,

Thanks for your thoughtful comments. I think I understand what you
are saying about resolution not really existing in a lat-lon
coordinate system. I'll try your idea of projecting the 4 corners,
and then computing the resolution. One question, isn't this what
r.proj would do anyway?

I would like to see your spreadsheet. If you can, please email it to
jhorn@bu.edu.

Thanks

- Jason

On Aug 19, 2005, at 4:44 AM, David Finlayson wrote:

> I think that it is a conceptual mistake to consider a raster data set
> in lat-long to have a "resolution" in the same sense as a projected
> map. Degrees of latitude and longitude do not have constant spacing.
> So a single resolution defined in meters (or whatnot) doesn't exist
> (even on the globe) Now add to that, GIS can't work on ellipsoidal
> surfaces and must project the globe onto a flat plane. So not only do
> degrees have variable spacing to begin with, they must be warped to
> get them into the flat-earth of the GIS.
>
> I think it is best to consider lat-long grids a convenient storage
> mechanism for variably spaced points because by the time you can
> actually use them in a GIS (after projection and conversion to a
> Cartesian coordinate system), that's what they will be. The point is
> to remember that the conversion from geographic coordinates to
> projected coordinates is a major transformation and not a simple
> coordinate shift and resample problem.
>
> As for how to estimate the resolution, I usually run the 4 corners of
> my geographic data through proj to get the Cartesian coordinates
> (State Plane, UTM, etc.). Now everything is on "flat-earth" and you
> can calculate the appropriate resolution for your data with simple
> arithmetic (after all, that's why we invented map projections!).
>
> As a curiosity, if you want a spreadsheet that calculates the
> ellipsoidal distance between any two points on the earth, send me an
> email and I'll post it up on the web.
>
> David
>
> On 8/17/05, Jason Horn <jhorn@bu.edu> wrote:
>
>> Ian, Morten,
>>
>> Thanks so much for pointing out the problem. I have seceded in
>> projecting the raster layer, with the help of the v.in.region box
>> trick. I have set the resolution to an approximation of what I think
>> is right. However, how can I really match the resolution in the new
>> state plane location to the resolution from the old lat-lon location?
>>
>> - Jason
>>
>>
>> On Aug 15, 2005, at 5:25 PM, Ian MacMillan wrote:
>>
>>
>>> A simple way to do this is to make a vector box of your region in
>>> the first location using v.in.region. Go to your new location,
>>> v.proj that vector in, and set your region to the new vector. Then
>>> use r.proj on the raster you want to project. You will still have
>>> to set the resolution on your own though. Hope this makes sense.
>>>
>>> -Ian
>>>
>>> On Aug 15, 2005, at 2:14 PM, Morten Hulden wrote:
>>>
>>>
>>>
>>>>
>>>>
>>>> No wonder it takes forever. Your output location has 527482690275
>>>> cells (847325 x 622527) to project.
>>>>
>>>> You should adjust the boundaries or resolution of your NAD83
>>>> location to something more reasonable. Before running r.proj try
>>>> to set a resolution value that roughly matches the resolution of
>>>> your input map (g.region res= ), e.g. something like 1000 m.
>>>>
>>>> Don't know about boundaries for your location (TX unknown area to
>>>> me) but you may want to check those as well. No need to cover more
>>>> than what is necessary.
>>>>
>>>> rgds
>>>> Morten
>>>>
>>>>
>>>> Jason Horn wrote:
>>>>
>>>>
>>>>> Morten,
>>>>> Thanks for looking at this for me. Below are the files you asked
>>>>> for.
>>>>> PROJ_INFO for the source lat-lon location:
>>>>> name: Latitude-Longitude
>>>>> datum: wgs84
>>>>> towgs84: 0.000,0.000,0.000
>>>>> proj: ll
>>>>> ellps: wgs84
>>>>> cellhd file for KEWX20040710_025420:
>>>>> proj: 3
>>>>> zone: 0
>>>>> north: 34:00:17.832478N
>>>>> south: 25:11:59.799175N
>>>>> east: 92:43:25.599215W
>>>>> west: 103:19:56.000785W
>>>>> cols: 1000
>>>>> rows: 830
>>>>> e-w resol: 0:00:38.190402
>>>>> n-s resol: 0:00:38.190402
>>>>> format: -1
>>>>> compressed: 1
>>>>> PROJ_INFO file for the destination NAD83 location:
>>>>> name: Lambert Conformal Conic
>>>>> datum: nad83
>>>>> towgs84: 0.000,0.000,0.000
>>>>> proj: lcc
>>>>> ellps: grs80
>>>>> a: 6378137.0000000000
>>>>> es: 0.0066943800
>>>>> f: 298.2572221010
>>>>> lat_0: 31.1666670000
>>>>> lat_1: 27.4166670000
>>>>> lat_2: 34.9166670000
>>>>> lon_0: -100.0000000000
>>>>> x_0: 1000000.0000000000
>>>>> y_0: 1000000.0000000000
>>>>> WIND file for the destination NAD83 location:
>>>>> proj: 99
>>>>> zone: 0
>>>>> north: 1196061
>>>>> south: 573534
>>>>> east: 1563147
>>>>> west: 715822
>>>>> cols: 847325
>>>>> rows: 622527
>>>>> e-w resol: 1
>>>>> n-s resol: 1
>>>>> top: 1
>>>>> bottom: 0
>>>>> cols3: 847325
>>>>> rows3: 622527
>>>>> depths: 1
>>>>> e-w resol3: 1
>>>>> n-s resol3: 1
>>>>> t-b resol: 1
>>>>> Thanks again!
>>>>> - Jason
>>>>> On Aug 13, 2005, at 12:14 PM, Morten Hulden wrote:
>>>>>
>>>>>
>>>>>> Jason Horn wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> I have a long-standing problem with r.proj. I have never been
>>>>>>> able to complete a successful re-projection of a raster file.
>>>>>>> For example, I am trying to pull in a raster file from a
>>>>>>> location that is lat-lon, WGS84 into a location that is state-
>>>>>>> plane meters, NAD83. The raster grid is relatively small,
>>>>>>> 1000 cols by 830 rows. I start r.proj like this:
>>>>>>> r.proj input=KEWX20040710_025420 location=TX_ll_WGS84
>>>>>>> mapset=PERMANENT output=proj1 method=nearest Although my CPU
>>>>>>> stays pegged at close to 100% usage, the progress bar never
>>>>>>> moves forward and nothing happens, even if I leave it for many
>>>>>>> hours. Can anyone tell me what's going on here?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> In order to help you I would like to see:
>>>>>>
>>>>>> 1) The PROJ_INFO file for your latlon location
>>>>>> 2) The cellhd file of the KEWX20040710_025420 map in the latlon
>>>>>> location
>>>>>> 3) The PROJ_INFO file for your NAD83 location
>>>>>> 4) The WIND file for your NAD83 location
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
> --
> David Finlayson
> Marine Geology & Geophysics
> School of Oceanography
> Box 357940
> University of Washington
> Seattle, WA 98195-7940
> USA
>
> Office: Marine Sciences Building, Room 112
> Phone: (206) 616-9407
> Web: http://students.washington.edu/dfinlays
>
>
>

--
David Finlayson
Marine Geology & Geophysics
School of Oceanography
Box 357940
University of Washington
Seattle, WA 98195-7940
USA

Office: Marine Sciences Building, Room 112
Phone: (206) 616-9407
Web: http://students.washington.edu/dfinlays

On 8/19/05, Jason Horn <jhorn@bu.edu> wrote:

I'll try your idea of projecting the 4 corners,
and then computing the resolution. One question, isn't this what
r.proj would do anyway?

Not really. r.proj is "region aware", i.e. will use the resolution of your current region no matter what the resolution of the input map is. That is why you should check that you really have the desired resolution set before running r.proj.

In the projection process the center of each cell in your current region will be projected onto the input map and the value of the nearest neighbor (if you use this default method) will be extracted. This value will then become the value of the corresponding cell(s) in the output map.

As a consequence the output map grid will be aligned with other maps in your location, which may be essential for further analysis and processing with some other Grass modules. The alternative, reprojecting with gdalwarp, does not as far as I know take the cell grid of your current region into account.

rgds
Morten

Morten Hulden wrote:

> On 8/19/05, Jason Horn <jhorn@bu.edu> wrote:

>>I'll try your idea of projecting the 4 corners,
>>and then computing the resolution. One question, isn't this what
>>r.proj would do anyway?

By default, r.proj projects the sampled boundary of the current region
to the source projection to determine the portion of the source map to
read into memory. If the actual projection operation requests cells
outside of this region, they will be read as nulls.

This behaviour can be disabled with the -n switch, in which case the
entire source map will be read into memory.

This optimisation should be acceptable for most cases, although there
are some extreme cases where projected interior points can fall
outside of the projected boundary (e.g. cylindrical to polar) where it
will fall down. Such cases tend not to occur in practice.

--
Glynn Clements <glynn@gclements.plus.com>

Hi Paul,

> That would be very handy if r.proj could estimate the best output
> resolution as well. I remember there was some discussion about
> completely replacing r.proj warper with gdal warper. Any news?

The way I see it is that they perform two different, complementary
functions. gdalwarp is useful if you have a whole map/image you want
to convert to a new projection and not lose any of the data. r.proj
is useful if you already have a region of interest you're working on
in the GIS, and want to import only the portion of the larger
map/image that covers this region, at the same resolution and with the
same boundaries etc. as your existing maps in your location.

Does that make sense?

(again, sorry for very late responses)

I don't know if this goes for r.proj method=nearest,bilinear,cubic as
well, but for i.rectify the idea was to use the GDAL warp *API*, not
the gdalwarp program.

GRASS and GDAL use the same base code for 1st,2nd,3rd order transforms
(AFAICT); both have the same bad bugs if you try 3rd order, e.g..

The difference is that the GDAL version is better maintained and
optimized, plus has nifty features like a thin plate spline option.

As we already depend on the gdal libraries, I think it's a good idea
to let someone else maintain that bit of the code.
see https://intevation.de/rt/webrt?serial_num=2952

Hamish

Hello Hamish

On Wed, 1 Mar 2006, Hamish wrote:

That would be very handy if r.proj could estimate the best output
resolution as well. I remember there was some discussion about
completely replacing r.proj warper with gdal warper. Any news?

The way I see it is that they perform two different, complementary
functions. gdalwarp is useful if you have a whole map/image you want
to convert to a new projection and not lose any of the data. r.proj
is useful if you already have a region of interest you're working on
in the GIS, and want to import only the portion of the larger
map/image that covers this region, at the same resolution and with the
same boundaries etc. as your existing maps in your location.

Does that make sense?

(again, sorry for very late responses)

I don't know if this goes for r.proj method=nearest,bilinear,cubic as
well, but for i.rectify the idea was to use the GDAL warp *API*, not
the gdalwarp program.

Hmm yes. I suppose my point may have been (can't remember too well as was long ago!) that in the usage scenario for r.proj that I suggested, the less advanced r.proj algorithm would tend to be adequate for what would likely be a smaller area to be re-projected etc. The limitations came more into play when you were re-projecting a whole map, which gdalwarp was better suited for anyway.

But yeah no technical argment at all against improving the r.proj warping by using GDAL functions.

Paul