If you create a VRT file for your CSV file, then you should be able to
import it with v.in.ogr directly.
v.in.ogr dsn=/Users/Desktop/Data/
081211_Mitchell_plane_bores_list_V002.vrt out=mitchell_bores
You VRT file would look like:
<OGRVRTDataSource>
<OGRVRTLayer name="081211_Mitchell_plane_bores_list_V002">
<SrcDataSource>081211_Mitchell_plane_bores_list_V002.csv</
SrcDataSource>
<GeometryType>wkbPoint</GeometryType>
<LayerSRS>EPSG:26910</LayerSRS>
<GeometryField encoding="PointFromColumns" x="Easting"
y="Northing"/>
</OGRVRTLayer>
</OGRVRTDataSource>
Substitute the EPSG code 26910 (NAD83UTM10) for your appropriate
coordinate system and x= & y= to the appropriate column header names.
Mike
On 3-Feb-09, at 2:35 PM, Markus Neteler wrote:
On Tue, Feb 3, 2009 at 10:29 PM, Harald Hofmann
<[email protected]> wrote:
Sorry Hamish,
I replied a little to quickly, I should read the mails to the
end ... :-)
Yes, I have tried the option colums=. I just thought there is an
easier way
around.
There (potentially) is:
1. Import table with db.in.ogr (if CSV, create also .csvt file: define
appropriately
the types Real, String, Date, Time and/or DateTime):
http://grass.osgeo.org/grass64/manuals/html64_user/db.in.ogr.html
If needed, use the "key" parameter to auto-generate a unique key
column.
2. generate a map from the imported table:
v.in.db
http://grass.osgeo.org/grass64/manuals/html64_user/v.in.db.html
If you have many columns this may be quicker (slightly less precise
concerning
the column type definitions).
Markus
_______________________________________________
grass-user mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-user
_______________________________________________
grass-user mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-user
