[GRASSLIST:10030] Re: projection problems

[Tom Russo]

On Fri, Jan 27, 2006 at 11:52:04AM -0600, we recorded a bogon-computron collision of the <kwythers at umn.edu> flavor, containing:
> It seems that I could use some very basic explanation concerning  
> locations and projections. I am trying to read several shape files  
> into a single location. However, I am getting a projection error on  
> some of them.
[...]
> 
> If I try and read another shape file into the location, I get the  
> projection error about not matching the current location:
> 
> GRASS 6.1.cvs (minnesota_utm):~ > v.in.ogr dsn=~/projects/mn_dnr/ 
> shape_files/pls_corners_btrees/county/cook/ output=cook_test
> ERROR: Projection of dataset does not appear to match current location.
> 
>        LOCATION PROJ_INFO is:
>        name: UTM
>        datum: nad83
>        towgs84: 0.000,0.000,0.000
>        proj: utm
>        ellps: grs80
>        a: 6378137.0000000000
>        es: 0.0066943800
>        f: 298.2572221010
>        zone: 15
> 
>        cellhd.proj = 0 (unreferenced/unknown)
> 
>        You can use the -o flag to v.in.ogr to override this check.
>        Consider to generate a new location with 'location' parameter  
> from
>        input data set.
> 
> 
> I asked one of our ARC/GIS folks downstairs to see if he could import  
> the shape files and lay them on top of each other and he did not have  
> any trouble. I am wondering if I have set something very basic up wrong.

Do your shapefiles have ".prj" files to go with them?  My guess is they do
not.

If not, there's no way for v.in.ogr to know what projection they're in, and it 
will always say that there's a projection mismatch.  .prj files hold "WKT" 
specifications of the coordinate system/projection of the associated shapefile. They are not always distributed along with shapefiles --- a fact that probably 
casts a dark shadow on the souls of members of GIS departments that distribute 
those files and leave folks to guess at what type of coordinates lie inside.

Odds are good that your ArcGIS friends are able to import them because ArcGIS
is simply reading in the shape file and *assuming* it's in the right projection
for the current view.  That's what "v.in.ogr -o" is supposed to do, too.
As long as that assumption's good, the data will lay on top of each other
properly.

> If I use the -o flag (or location=some_new_location) the file comes  
> in as projection (0) x,y

If you're sure the shapefile is in UTM zone 15 coordinates with NAD83 datum,
you should be able to use v.in.ogr with -o but without "location=newlocation"
and grass should ignore the projection mismatch and import the shapes
with the assumption that the coordinates in the shapefile match the coordinate
system of your location.  It should not be possible to get a "projection (0) 
x,y" when importing a shapefile into an existing UTM location, but if you use 
"location=newlocation" then that's just what it'll do because it has no 
information about what projection was used to create the shapefile.

> Any suggestions for diagnosing this problem and getting these shape  
> files to match up would be much appreciated.

If you *know for certain* that your shapefiles definitely contain shapes 
defined in terms of NAD83 UTM zone 15 coordinates, you should be able to
import them into your NAD83 UTM zone 15 GRASS location with v.in.ogr -o.
Or, you can give v.in.ogr a hand by providing it with a .prj file to go 
along with each of the shapefiles.  The WKT for UTM zone 15 NAD83 in the
northern hemisphere is:

PROJCS["NAD83 / UTM zone 15N",GEOGCS["NAD83",DATUM["North_American_Datum_1983",SPHEROID["GRS 1980",6378137,298.257222101]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",-93],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",0],UNIT["metre",1]]


If you put this single line of text in a file called "foo.prj" then it will
be used to define the coordinate system when you import foo.shp.  From then
on GRASS would be able to tell immediately whether the shapefile matched the
projection of the current location, and other ogr tools (like ogr2ogr) could
be used pretty simply to reproject or datum-shift the files.

It ought to be illegal to distribute shapefile sets without .prj files, but
many ESRI houses do just that.

Naturally, it would be wrong to use this .prj file with a shapefile that was 
defined in some other coordinates --- NAD27 UTM zone 15, for example.  But
that's another story.  

-- 
Tom Russo    KM5VY     SAR502  DM64ux         http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236 AHTB#1 
 "The only thing you can do easily is be wrong, and that's hardly
  worth the effort." -- Norton Juster