[GRASSLIST:10052] Re: projection problems

[Tom Russo]

On Mon, Jan 30, 2006 at 11:40:06AM -0600, we recorded a bogon-computron collision of the <kwythers at umn.edu> flavor, containing:
> Tom, before you spend too much time on this...
> 
> I think DNR data came with a screwy  y value in their table. I opened  
> the original DNR table, and as I've said before, the values are there  
> that are all less than 1 million - which can't be correct. I added  x  
> and y coords, named something like xadded, yadded (bad short term  
> memory), and then calculated the difference, saved in ydiff. It is a  
> number that is something like 4,700,206, plus or minus 0.5.

Yes, it does sound like your DNR table is not in the same coordinates as 
your other data.  Without more information, of course, I couldn't do more
than guess at what's going on.  It could even be that your DNR table is in
Minnesota state plane coordinate system rather than UTM.  I think that
in any of the three Minnesota SPCS coordinate systems the northing would 
be an order of magnitude smaller than they'd be in UTM.  The only way to 
resolve that question would be to check, double check, and triple check with 
the office that provided the data.

> I have no idea why MN DNR did this. Do you see the same thing? But I  
> am beginning to think it is a not grass or postgresql issue...

It does sound that way.

You might try using ogr tools like "ogrinfo" to probe your original shapefiles
to see what the extents are before they're imported into grass.  The 
DNR data might not be in UTM coordinates or something, even if the rest of your
data is.

By the way, in an earlier email you said this this:

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

v.in.ogr -o doesn't force anything about plotting, per se.  By default v.in.ogr
checks to see if the input data is in the same coordinate 
system/datum/projection as the current location, and refuses to import the 
ogr data source into a grass vector if it isn't.  Your data has no 
projection/coordinate system stored with it, so v.in.ogr assumes it's in the 
wrong coordinates.  But you *know* that the coordinates in your shapefile are 
indeed in Zone 15 UTM coordinates, NAD83 datum, so you use "-o" to tell 
v.in.ogr to skip the check and just import the data.  No forcing involved --- 
you're just telling v.in.ogr "it's OK, I know the coordinates in my input 
files are in the right system, just read them, trust me." If, in fact, your 
file is full of coordinates that are NOT in the right system and you use 
v.in.ogr with "-o", well, then, you're on your own :).  It sounds like you've 
got a collection of data some of which is in UTM zone 15 NAD83, and some of 
which might not be.

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