[GRASSLIST:10044] Re: projection problems

[Kirk R. Wythers]

Thank you very much for the reply Tom. My responses are in line.

On Jan 27, 2006, at 1:58 PM, Tom Russo wrote:

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

You are correct.

>
> 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.

I went back and re-imported with v.in.ogr -o. That worked in that  
v.info output makes sense now for both the state outline and the  
vector points files (those were the troublesome ones). And d.vect can  
plot both the state outline and the points on top of each other, and  
the appearance... to my eye, makes sense. Which is a good thing.

However, I notice in the points file (I'm not sure what else to call  
it) which is a grass vector containing site information in a  
postgresql table, of which two columns 'x' and 'y' contain the  
coordinates for plotting each site, do not make sense for Minnesota  
UTM coordinates. For example, v.info on the file gives:

  Projection: UTM (zone 0)
|            N: 5470474.000    S: 4816355.500
|            E: 760498.938    W: 189916.844
|            B: 0.000         T: 0.000

As you can see the North and South dimension show UTM coordinates are  
in the 4 to 5 million range. However checking the 'x' and 'y' columns  
in the postgresql table the values are an order on magnitude too low.  
(ie x=441988 and y=508562).

Is this due to the use of the -o flag? In that you were saying that  
the use of -o allows v.in.ogr to assume that the projection is ok and  
forces the points to plot within the projection's dimensions?

If that is the case, then that explains why I could not plot the  
points file I created from a sql cross join command. The results of  
which pulled each of the 4 species out of a single row (in a 250k row  
file), and gave each species its own row (creating a 1 million row  
file). Then I read the new table back into grass with v.in.db (which  
has no -o option... that I am aware of). That new vector then would  
not plot with the other data in the region.

Now I have not re-done the sql cross join command on the vector  
points file yet. It is running right now (takes a while). If I  
understand your explanation Tom, I do not expect it to work any  
better than it did last time.

I guess the big question right now is why would the shape file I am  
trying to read have metadata describing UTM zone 15 nad83 bla...  
bla... bla..., and yet be full on point data that could not possible  
be UTM coordinates for Minnesota? Then what can I do about it? Would  
using your .prj info below solve this?

Thanks again for taking the time to write out such a lengthy  
explanation.

Kirk


> 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
>