[GRASS-user] Reprojecting Vector Map

GRASS GRASS user
1

   From the US Census TIGER files I imported the 'edges' (streets) using
v.in.ogr and using the projection information in the *.prj file. This worked
well, except that 'g.region -p' shows lat/lon geographic coordinates:

GRASS 6.4.0svn (streets):/usr4/grassbase > g.region -p
projection: 3 (Latitude-Longitude)
zone: 0
datum: nad83
ellipsoid: grs80
north: 45:27:41.8788N
south: 44:53:05.766N
west: 122:52:05.2068W
east: 121:39:06.1704W
nsres: 0:34:36.1128
ewres: 1:12:59.0364
rows: 1
cols: 1
cells: 1

   I changed pwd to PERMANENT and ran g.setproj. Specified lcc as the
projection and entered all the relevant data, then changed back to my mapset
and ran 'g.region -p'. No change. Running 'g.proj -w' tells me that I've not
made any difference; it's still in degrees:

GRASS 6.4.0svn (streets):/usr4/grassbase > g.proj -w
PROJCS["Lambert Conformal Conic",
     GEOGCS["grs80",
         DATUM["North_American_Datum_1983",

SPHEROID["Geodetic_Reference_System_1980",6378137,298.257222101]],
         PRIMEM["Greenwich",0],
         UNIT["degree",0.0174532925199433]],
     PROJECTION["Lambert_Conformal_Conic_2SP"],
     PARAMETER["standard_parallel_1",43],
     PARAMETER["standard_parallel_2",45.5],
     PARAMETER["latitude_of_origin",41.75],
     PARAMETER["central_meridian",-120.5],
     PARAMETER["false_easting",1312336],
     PARAMETER["false_northing",0],
     UNIT["degree",1]]

   My other vector layers are in LCC with boundaries in, I believe, metres.
What step have I missed with this streets layer?

Rich

2

Hi,

2009/11/24 Rich Shepard <rshepard@appl-ecosys.com>:

From the US Census TIGER files I imported the 'edges' (streets) using
v.in.ogr and using the projection information in the *.prj file. This worked
well, except that 'g.region -p' shows lat/lon geographic coordinates:

GRASS 6.4.0svn (streets):/usr4/grassbase > g.region -p
projection: 3 (Latitude-Longitude)

I changed pwd to PERMANENT and ran g.setproj. Specified lcc as the
projection and entered all the relevant data, then changed back to my mapset
and ran 'g.region -p'. No change. Running 'g.proj -w' tells me that I've not
made any difference; it's still in degrees:

you cannot define a different spatial reference systems (SRS) for
mapsets in one location. Data in one location need to be in the same
SRS. This is fundamental feature of the GRASS database - "A LOCATION
is defined by its coordinate system, map projection and geographical
boundaries" [1].

Martin

[1] http://grass.osgeo.org/grass64/manuals/html64_user/helptext.html

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

3

On Tue, 24 Nov 2009, Martin Landa wrote:

you cannot define a different spatial reference systems (SRS) for mapsets
in one location. Data in one location need to be in the same SRS. This is
fundamental feature of the GRASS database - "A LOCATION is defined by its
coordinate system, map projection and geographical boundaries" [1].

Martin,

   True. I completely forgot about this. With a new location/mapset I can now
use v.proj to move it over.

Thanks,

Rich

4

On Tue, 24 Nov 2009, Rich Shepard wrote:

True. I completely forgot about this. With a new location/mapset I can
now use v.proj to move it over.

   I'm still missing something. Defined a new location (streetsLCC) and
mapset (rbs). Ran the following command successfully:

GRASS 6.4.0svn (streetsLCC):/usr4/grassbase > v.proj input=streets
location=streets mapset=rbs output=streets --verbose

   'g.region -p' still shows lat/long after specifying 'g.region
vect=streets':

GRASS 6.4.0svn (streetsLCC):/usr4/grassbase > g.region vect=streets GRASS 6.4.0svn (streetsLCC):/usr4/grassbase > g.region -p
projection: 99 (Lambert Conformal Conic)
zone: 0
datum: nad83
ellipsoid: grs80
north: 45.46163298
south: 44.88493498
west: -122.868113
east: -121.651714
nsres: 0.576698
ewres: 1.216399
rows: 1
cols: 1
cells: 1

   So I've not reprojected from LL to LCC at all.

Rich

5

Hi Rich,

I have a general theory that may help you:

Assumptions:
-Very well defined LOCATION parameters is the foundation to perfectly combine maps of different sources.
-The experience tells me that some data are even in the correct reference system, but sometimes the “info” that comes with it sometimes not.
-Each coutry has it’s adequated reference system.
-GIS and GPS comes with a lot of reference systems, but they follow an international standard.
-Those standards sometimes differ a little from the “real parameters”.

What I do:
-I always take control of my LOCATIONS by methodically defining all the parameters with proj.4 sentences before starting a job.
-Some location is a “receptacle” for data.
-One location is for the work.

Pablo Torres Carreira

Date: Tue, 24 Nov 2009 11:53:22 -0800
From: rshepard@appl-ecosys.com
To: grass-users@lists.osgeo.org
Subject: Re: [GRASS-user] Reprojecting Vector Map
CC:

On Tue, 24 Nov 2009, Rich Shepard wrote:

True. I completely forgot about this. With a new location/mapset I can
now use v.proj to move it over.

I’m still missing something. Defined a new location (streetsLCC) and
mapset (rbs). Ran the following command successfully:

GRASS 6.4.0svn (streetsLCC):/usr4/grassbase > v.proj input=streets
location=streets mapset=rbs output=streets --verbose

‘g.region -p’ still shows lat/long after specifying 'g.region
vect=streets

GRASS 6.4.0svn (streetsLCC):/usr4/grassbase > g.region vect=streets
GRASS 6.4.0svn (streetsLCC):/usr4/grassbase > g.region -p
projection: 99 (Lambert Conformal Conic)
zone: 0
datum: nad83
ellipsoid: grs80
north: 45.46163298
south: 44.88493498
west: -122.868113
east: -121.651714
nsres: 0.576698
ewres: 1.216399
rows: 1
cols: 1
cells: 1

So I’ve not reprojected from LL to LCC at all.

Rich

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

Chegou o Windows 7: Incrivelmente simples! Clique e conheça.

6

On Tue, 24 Nov 2009, Pablo Carreira wrote:

Assumptions:
-Very well defined LOCATION parameters is the foundation to perfectly combine maps of different sources.
-The experience tells me that some data are even in the correct reference system, but sometimes the "info" that comes with it sometimes not.
-Each coutry has it's adequated reference system.
-GIS and GPS comes with a lot of reference systems, but they follow an international standard.
-Those standards sometimes differ a little from the "real parameters".

Pablo,

   Thanks for your contributions. I think that I have this correctly handled
now.

   My raster (DEM) layer covers the northwest portion of the state, the
hydrologic unit boundaries (level 6) and dams are statewide. These three are
lcc projection. Soils and streets are for a specific county. The former is
UTM Zone 10, the latter lat/long.

   The soils data are in .e00 format, but without the projection/datum
information in the header.

   The wxPython GUI has a bug: when UTM is specified as the projection, we
cannot change the zone from the default 30. The Tcl/Tk GUI didn't ask me to
specify a projection. I commented out most lines in ~/.grassrc6 and worked
in the original, ugly, user-unfriendly VT100 interface. With numerous errors
and use of the arrow keys I was able to enter all relevant information
except for the e-w and n-s resolutions. The metadata file specifies those as
0 but GRASS64svn won't take that value. I had to use 1 instead. Shrug.

   Once I had the soils/PERMANENT location defined I exited grass, restored
the rc file, and restarted it. Using the wxPython UI I defined the mapset
and imported the mapping unit areas, line features, and point features.

   Then I created a new location and defined it as LCC. From within that new
location I ran v.proj and converted the three soils layers. 'g.region -p'
appears to display correct coordinates.

   Now I need to re-do the streets and see if I can get that layer
reprojected from LL to LCC. So far it's fighting me and winning.

Rich

7

The wxPython GUI has a bug: when UTM is specified as the projection, we
cannot change the zone from the default 30…

Today a have seen this bug in wx, it looks like the zone box is hidden.
You may create a custom proj.4 parameters to bypass this problem

Look at this site: http://spatialreference.org/

It has all the parameters ready for use.

Pablo Torres Carreira

Date: Tue, 24 Nov 2009 14:48:41 -0800
From: rshepard@appl-ecosys.com
To: grass-users@lists.osgeo.org
Subject: RE: [GRASS-user] Reprojecting Vector Map
CC:

On Tue, 24 Nov 2009, Pablo Carreira wrote:

Assumptions:
-Very well defined LOCATION parameters is the foundation to perfectly combine maps of different sources.
-The experience tells me that some data are even in the correct reference system, but sometimes the “info” that comes with it sometimes not.
-Each coutry has it’s adequated reference system.
-GIS and GPS comes with a lot of reference systems, but they follow an international standard.
-Those standards sometimes differ a little from the “real parameters”.

Pablo,

Thanks for your contributions. I think that I have this correctly handled
now.

My raster (DEM) layer covers the northwest portion of the state, the
hydrologic unit boundaries (level 6) and dams are statewide. These three are
lcc projection. Soils and streets are for a specific county. The former is
UTM Zone 10, the latter lat/long.

The soils data are in .e00 format, but without the projection/datum
information in the header.

The wxPython GUI has a bug: when UTM is specified as the projection, we
cannot change the zone from the default 30. The Tcl/Tk GUI didn’t ask me to
specify a projection. I commented out most lines in ~/.grassrc6 and worked
in the original, ugly, user-unfriendly VT100 interface. With numerous errors
and use of the arrow keys I was able to enter all relevant information
except for the e-w and n-s resolutions. The metadata file specifies those as
0 but GRASS64svn won’t take that value. I had to use 1 instead. Shrug.

Once I had the soils/PERMANENT location defined I exited grass, restored
the rc file, and restarted it. Using the wxPython UI I defined the mapset
and imported the mapping unit areas, line features, and point features.

Then I created a new location and defined it as LCC. From within that new
location I ran v.proj and converted the three soils layers. ‘g.region -p’
appears to display correct coordinates.

Now I need to re-do the streets and see if I can get that layer
reprojected from LL to LCC. So far it’s fighting me and winning.

Rich

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

Chegou o Windows 7: Incrivelmente simples! Clique e conheça.

8

Rich Shepard wrote:

> True. I completely forgot about this. With a new location/mapset I can
> now use v.proj to move it over.

   I'm still missing something. Defined a new location (streetsLCC) and
mapset (rbs). Ran the following command successfully:

GRASS 6.4.0svn (streetsLCC):/usr4/grassbase > v.proj input=streets
location=streets mapset=rbs output=streets --verbose

   'g.region -p' still shows lat/long after specifying 'g.region
vect=streets':

g.region will never change the projection. Ordinarily, the projection
never changes once the location has been created.

If you have lat/lon data and want to use LCC, you need to create two
locations: one in lat/lon, one in LCC. Import the lat/lon data to the
lat/lon location, switch to the LCC location, and re-project the data
with v.proj or r.proj.

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

9

On Wed, 25 Nov 2009, Glynn Clements wrote:

If you have lat/lon data and want to use LCC, you need to create two
locations: one in lat/lon, one in LCC. Import the lat/lon data to the
lat/lon location, switch to the LCC location, and re-project the data with
v.proj or r.proj.

Glynn,

   I had been using v.proj, but discovered what appeared to be the problem:
same name for location, input file, and output file. When I changed the
source (LL) location to TIGER, the input file name to 'edges', the output
location to streetsLCC, and the output file to 'streets' it worked just
fine.

   g.region was used only to set the region from the included map, not to
reproject it.

Thanks,

Rich