[GRASSLIST:5220] v.in.ogr advice needed

Kirk_R_Wythers · December 22, 2004, 10:43pm

I have some shape files that I want to import into 57 and need some v.in.ogr usage advice. The structure of the directory with the shape files is thus:

barbaloot:~/Desktop/shape_files kirkw$ ls
polys_t59_v1.dbf polys_t62_v1.sbn polys_t65_v1.dbf
polys_t59_v1.shp polys_t62_v1.sbx polys_t65_v1.shp
polys_t59_v1.shx polys_t62_v1.shp polys_t65_v1.shx
polys_t59_v2.dbf polys_t62_v1.shx polys_t65_v2.dbf
polys_t59_v2.shp polys_t62_v2.dbf polys_t65_v2.shp
polys_t59_v2.shx polys_t62_v2.shp polys_t65_v2.shx
polys_t59_v3.dbf polys_t62_v2.shx polys_t65_v3.dbf
polys_t59_v3.shp polys_t62_v3.dbf polys_t65_v3.shp
polys_t59_v3.shx polys_t62_v3.shp polys_t65_v3.shx

From my read of the help file each set of shape files would constitute a layer, and the command should be

v.in.shape dsn=~/Desktop/shape_files ouput=shape_files

However, I get the error that the projection does not match the current location

GRASS 5.7.cvs:~ > v.in.ogr dsn=Desktop/shape_files/ output=shapefiles
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)

        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.

So I tried importing into a new location thus:

GRASS 5.7.cvs:~ > v.in.ogr dsn=Desktop/shape_files/ output=shapefiles location=new_location
Layer: polys_t59_v1
WARNING: Default driver / database set to:
driver: dbf
database: $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/
*** malloc_zone_calloc[16817]: arguments too large: 3887818265,8
*** malloc_zone_calloc[16817]: arguments too large: 1096034345,4
Bus error

Can someone enlighten me as to what I'm doing wrong here? Thanks

Kirk R. Wythers
Dept. of Forest Resources
University of Minnesota
email: kwythers@umn.edu
tel: 612.625.2261
fax: 612.625.5212

Brent_Wood1 · December 22, 2004, 11:27pm

On Wed, 22 Dec 2004, Kirk R. Wythers wrote:

I have some shape files that I want to import into 57 and need some
v.in.ogr usage advice. The structure of the directory with the shape
files is thus:

So I tried importing into a new location thus:

I got the same error message when importing some lat/long shapefiles
despite the shapefiles lying within the GRASS region & the GRASS location
being lat/long.

I used the -o flag (via the gui) and it worked fine. I overlaid the GRASS
version of the data with the original shapefile in QGIS & they overlaid
fine, so I'm assuming the error message about projection mismatches is not
always correct (at least in this case).

I'm not sure why QGIS can plot a GRASS vector map in half the time GRASS
takes, but they both have their uses

If you believe you have set up your GRASS location with the correct
projection details, it could be worth seeing if -o works for you as well.

Brent Wood

Kirk_R_Wythers · December 22, 2004, 11:56pm

On Dec 22, 2004, at 5:27 PM, Brent Wood wrote:

On Wed, 22 Dec 2004, Kirk R. Wythers wrote:

I have some shape files that I want to import into 57 and need some
v.in.ogr usage advice. The structure of the directory with the shape
files is thus:

So I tried importing into a new location thus:

I got the same error message when importing some lat/long shapefiles
despite the shapefiles lying within the GRASS region & the GRASS location
being lat/long.

I used the -o flag (via the gui) and it worked fine. I overlaid the GRASS
version of the data with the original shapefile in QGIS & they overlaid
fine, so I'm assuming the error message about projection mismatches is not
always correct (at least in this case).

I'm not sure why QGIS can plot a GRASS vector map in half the time GRASS
takes, but they both have their uses

If you believe you have set up your GRASS location with the correct
projection details, it could be worth seeing if -o works for you as well.

I tried the -o flag before posting. It yielded the same error. While I didn't to the digitizing myself, the vectors were created from rasters in the same location that I am trying to import into, therefore the location and projection should be fine.

Kirk

Brent Wood

Kirk R. Wythers
Dept. of Forest Resources
University of Minnesota
email: kwythers@umn.edu
tel: 612.625.2261
fax: 612.625.5212

Tom_Russo · December 23, 2004, 1:17am

On Thu, Dec 23, 2004 at 12:27:50PM +1300, we recorded a bogon-computron collision of the <b.wood@niwa.co.nz> flavor, containing:

On Wed, 22 Dec 2004, Kirk R. Wythers wrote:

> I have some shape files that I want to import into 57 and need some
> v.in.ogr usage advice. The structure of the directory with the shape
> files is thus:

> So I tried importing into a new location thus:
>

I got the same error message when importing some lat/long shapefiles
despite the shapefiles lying within the GRASS region & the GRASS location
being lat/long.

I used the -o flag (via the gui) and it worked fine. I overlaid the GRASS
version of the data with the original shapefile in QGIS & they overlaid
fine, so I'm assuming the error message about projection mismatches is not
always correct (at least in this case).

Shapefiles do not have any way of storing the projection/datum information.
This is a deficiency of the shapefile format.

Some sets of shapefiles come with an auxilliary ".prj" file that v.in.ogr
can read to check the projection, but without that file it is impossible
for ogr to tell what projection is in use by the files. So in this case
unless v.in.ogr is given -o it assumes there is a projection mismatch.

Unfortunately .prj files are not part of the shapefile standard and different
programs produce and expect different contents. Output of Global Mapper, for
instance, has a format that is completely useless to OGR, and vice-versa.

If you are absolutely certain that the shapefiles are in the same projection
and datum as your GRASS area, then -o should work.

If you know for certain that your shapefiles are in UTM zone 15N with
NAD83 datum, then you can also create a .prj file for each shapefile that
reflects that. The format is a bit arcane, but the following information
(edited to be on one line) in the .prj file would take care of it.

---- pull the following lines into an editor and remove line breaks-----
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]]
-------end of .prj information

If you put this in a .prj file with the same basename as your shapefiles
v.in.ogr will recognize that it's in the same projection as your grass location.

Heaven help you if your shapefiles are not in fact in UTM zone 15/NAD83
(EPSG:26915) and you do this --- garbage will result.

Once you have .prj files for your shapefiles, you can not only use v.in.ogr
to import them into GRASS databases with the same projection and datum, but
you can use "ogr2ogr" that comes with GDAL to translate them to different
projections and data.

--
Tom Russo KM5VY SAR502 DM64ux http://www.swcp.com/~russo/
Tijeras, NM QRPL#1592 K2#398 SOC#236 AHTB#1 http://www.qsl.net/~km5vy/
"When life gives you lemons, find someone with a paper cut."