I have downloaded several files from the ESRI TIGER/LINE database. The site
claims that the files are in lat/lon NAD83 format. Perfect! I assume this
would correspond to EPSG 4269 format.
I have tried creating a new location in all three ways: projection values
using lat/lon (using rounded values of the geographic area), georeferenced
file (the shape file), and by EPSG Code (3310 and 4269). In every case, when
I import the shape file using v.in.ogr and then display the vector map, it
is displayed in a region using some other format (huge numbers), and not in
the lat/lon format I expected. The projection even reads "x,y" even though I
selected lat/lon for the location:
-|
| Type of Map: vector (level: 2)
|
| Number of points: 0 Number of areas: 0
| Number of lines: 32493 Number of islands: 0
| Number of boundaries: 0 Number of faces: 0
| Number of centroids: 0 Number of kernels: 0
|
| Map is 3D: 0
| Number of dblinks: 1
|
| Projection: x,y
| N: -322776.48526848 S: -457156.35430172
| E: 51189.38422193 W: -59948.35401544
|
| Digitization threshold: 0
| Comments:
|
What is strange is that if I import this shape file into gvSIG, it reads the
map perfectly fine, with the correct coordinate system. Since the file is in
plain ol' lat/lon, it should display that way in GRASS. What am I missing??
What could I be doing wrong?
--
View this message in context: http://www.nabble.com/Trouble-with-ESRI-TIGER-LINE-Files-and-Coordinate-System-tp19506319p19506319.html
Sent from the Grass - Users mailing list archive at Nabble.com.
I have downloaded several files from the ESRI TIGER/LINE database. The
site claims that the files are in lat/lon NAD83 format. Perfect!
I assume this would correspond to EPSG 4269 format.
....
I import the shape file using v.in.ogr and then display the vector map,
it is displayed in a region using some other format (huge numbers), and
not in the lat/lon format I expected. The projection even reads "x,y"
even though I selected lat/lon for the location:
What is strange is that if I import this shape file into gvSIG, it reads
the map perfectly fine, with the correct coordinate system.
Since the file is in plain ol' lat/lon, it should display that way in
GRASS.
What am I missing??
What could I be doing wrong?
can you check with ogrinfo what's *really* in the shapefile?
ogrinfo -ro -al mapname.shp
That will dump a huge amount of stuff to the terminal (^C to kill it)
but you should see LINESTRING with a comma separated list of coordinates.
Are those raw coordinates in lat/lon or ...?
what does the shapefile.prj look like?
I am not too familiar with gvSIG's capabilities; will QGIS load it and
show correct projection info and mouse-over coords on the bottom status
line?
QGIS also uses the weird coordinates as well. gvSIG did as well, until I
changed the measurement unit to "degree." It's GUI for map display is very
similar to QGIS. Is there a such thing switching measurement units to
degrees in GRASS?
Unfortunately, there is no PRJ file with these shapefiles, which is really
frustrating. The website claims they are NAD83 lat/lon decimal degrees. My
region should be 119W to 121W and 34N to 36N. Could these be UTM
coordinates??
R.
hamish_b wrote:
can you check with ogrinfo what's *really* in the shapefile?
ogrinfo -ro -al mapname.shp
That will dump a huge amount of stuff to the terminal (^C to kill it)
but you should see LINESTRING with a comma separated list of coordinates.
Are those raw coordinates in lat/lon or ...?
what does the shapefile.prj look like?
I am not too familiar with gvSIG's capabilities; will QGIS load it and
show correct projection info and mouse-over coords on the bottom status
line?
*Blushes* Solved. It ended up being a dumb error on my part. Months ago, I
converted the shape files to EPSG 3310 (California Teale Albers) to match
another line file I was using but no longer need. That is why gvSIG was able
to convert the coordinates to lat/lon, because the view (location) was
projected as 3310. Using the original, untouched shape files, I have pure
lat/lon.
Which gets me to thinking... It would be great if GRASS had a similar
feature, where the user can select how the coordinates are displayed at the
bottom of the map output window (meters, feet, degrees) as a quick
reference.
R.
Ryan R. Rosario wrote:
Ugh. The LINESTRINGs contain the weird coordinates (in the 100000s), not
raw lat/lon.
QGIS also uses the weird coordinates as well. gvSIG did as well, until I
changed the measurement unit to "degree." It's GUI for map display is very
similar to QGIS. Is there a such thing switching measurement units to
degrees in GRASS?
Unfortunately, there is no PRJ file with these shapefiles, which is really
frustrating. The website claims they are NAD83 lat/lon decimal degrees. My
region should be 119W to 121W and 34N to 36N. Could these be UTM
coordinates??
R.
hamish_b wrote:
can you check with ogrinfo what's *really* in the shapefile?
ogrinfo -ro -al mapname.shp
That will dump a huge amount of stuff to the terminal (^C to kill it)
but you should see LINESTRING with a comma separated list of coordinates.
Are those raw coordinates in lat/lon or ...?
what does the shapefile.prj look like?
I am not too familiar with gvSIG's capabilities; will QGIS load it and
show correct projection info and mouse-over coords on the bottom status
line?
Which gets me to thinking... It would be great if GRASS had a similar
feature, where the user can select how the coordinates are displayed at
the bottom of the map output window (meters, feet, degrees) as
a quick reference.
see:
"g.proj -p" from the command line
"PROJ_UNITS" file in the location's PERMANENT mapset
G_database_unit_name(), G_database_units_to_meters_factor() in libgis
In my experience reprojection on-the-fly is nice in theory, a disaster
in practice. I would suggest to help QGIS (and Arc for that matter) get
that working correctly before thinking about doing so in GRASS.
(neither handle mixed datums well; real raster reproj is too expensive)
