[GRASS-user] db.connect/db.in.ogr Questions
rshepard at appl-ecosys.com
Fri Mar 11 09:27:07 EST 2011
On Fri, 11 Mar 2011, Micha Silver wrote:
> Also make sure you're clear on the distinction in GRASS between the
> geography of vector layers and their attributes. GRASS always stores the
> vector geography in it's own internal format (enforcing topology, etc) and
> there's no need from GRASS's point of view to have the X-Y coordinates in
> the attribute table.
Yes, I know this difference. In some cases (such as the water well logs),
the geographic coordinates are part of the source data. GRASS can use those
for the points layer as soon as I learn how to tell it to do so.
> Attributes can be stored in any of several ways. But this is totally
> independent of the geography. So you can first set up the default
> database connection, as Hamish explained, to be postgres. Then whenever
> you import vector data, the geography will still be kept internally by
> GRASS, and the attribute columns will be pushed into Postgres. Whether or
> not the final Postgres database has X-Y columns is irrelevant to GRASS
> handling the vectors. You might want that data kept in the table for your
> own needs, but GRASS doesn't look there.
You're thinking in terms of spatial source data as .shp, .e00, .img and so
on. I'm also working with data from flat-files (such as Access),
spreadsheets (permit compliance monitoring), text files (biological survey
results), and so on. These data have no spatial structures, only (if I'm
really lucky) geographic coordinates from permits or reports. Those become
columns in the database and the map layer generated from those points.
Germane to this topic, I decided this morning to migrate all attribute
data from the internal dbf to postgres tables. Then I can set the driver and
location in an environment used each time I start GRASS.
More information about the grass-user