[GRASS-dev] v.in.ogr: how to force sqlite instead of dbf for output location ? SEG-Y input (Geology/Seismic Data)

["Peter Löwe"]

Hi list,

I'm using GRASS6.4.2 on a Suse-based HPC Cluster.

When trying to ingest SEG-Y data (geology/seismics) into a new location via v.in.ogr (GDAL 1.9.0) this error is thrown since the new location is set by default (?) to dbf:

GRASS 6.4.2 (startup_sqlite):~/geodata/petrel/SEG_Y_Demo > v.in.ogr dsn=demo20071121142735_CH1_35P.seg output=seg_y_test location=segy_sqlite
Layer: demo20071121142735_CH1_35P
WARNING: Default driver / database set to:
         driver: dbf
         database: $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/
WARNING: Column type not supported (SAMPLE_ARRAY)
WARNING: DBMI-DBF driver: column name 'TRACE_NUMBER_WITHIN_LINE' truncated
         to 'TRACE_NUMB'
WARNING: DBMI-DBF driver: column name 'TRACE_NUMBER_WITHIN_FILE' truncated
         to 'TRACE_NUMB'
DBMI-DBF driver error:
Column 'TRACE_NUMB' already exists (duplicate name)
Cannot create table.
Error in db_execute_immediate()

ERROR: Unable to create table: 'create table seg_y_test_1 (cat integer,
       TRACE_NUMBER_WITHIN_LINE integer, TRACE_NUMBER_WITHIN_FILE integer,
       ORIGINAL_FIELD_RECORD_NUMBER integer,
       TRACE_NUMBER_WITHIN_ORIGINAL_FIELD_RECORD integer,
       TRACE_IDENTIFICATION_CODE integer, ENSEMBLE_NUMBER integer,
       TRACE_NUMBER_WITHIN_ENSEMBLE integer, NUMBER_VERTICAL_SUMMED_TRACES
       integer, NUMBER_HORIZONTAL_STACKED_TRACES integer, DATA_USE integer,
       DISTANCE_SOURCE_GROUP integer, RECEIVER_GROUP_ELEVATION integer,
       SURFACE_ELEVATION_AT_SOURCE integer, SOURCE_DEPTH_BELOW_SURFACE
       integer, DATUM_ELEVATION_AT_RECEIVER_GROUP integer,
       DATUM_ELEVATION_AT_SOURCE integer, WATER_DEPTH_AT_SOURCE integer,
       WATER_DEPTH_AT_GROUP integer, VERTICAL_SCALAR integer,
       HORIZONTAL_SCALAR integer, SOURCE_X integer, SOURCE_Y integer,
       GROUP_X integer, GROUP_Y integer, COORDINATE_UNITS integer,
       WEATHERING_VELOCITY integer, SUB_WEATHERING_VELOCITY integer,
       UPHOLE_TIME_AT_SOURCE integer, UPHOLE_TIME_AT_GROUP integer,
       SOURCE_STATIC_CORRECTION integer, GROUP_STATIC_CORRECTION integer,
       TOTAL_STATIC_CORRECTION integer, LAG_TIME_A integer, LAG_TIME_B
       integer, DELAY_RECORDING_TIME integer, MUTE_TIME_START integer,
       MUTE_TIME_END integer, SAMPLES integer, SAMPLE_INTERVAL integer,
       GAIN_TYPE integer, INSTRUMENT_GAIN_CONSTANT integer,
       INSTRUMENT_INITIAL_GAIN integer, CORRELATED integer,
       SWEEP_FREQUENCY_AT_START integer, SWEEP_FREQUENCY_AT_END integer,
       SWEEP_LENGTH integer, SWEEP_TYPE integer,
       SWEEP_TRACE_TAPER_LENGTH_AT_START integer,
       SWEEP_TRACE_TAPER_LENGTH_AT_END integer, TAPER_TYPE integer,
       ALIAS_FILTER_FREQUENCY integer, ALIAS_FILTER_SLOPE integer,
       NOTCH_FILTER_FREQUENCY integer, NOTCH_FILTER_SLOPE integer,
       LOW_CUT_FREQUENCY integer, HIGH_CUT_FREQUENCY integer, LOW_CUT_SLOPE
       integer, HIGH_CUT_SLOPE integer, YEAR integer, DAY_OF_YEAR integer,
       HOUR integer, MINUTE integer, SECOND integer, TIME_BASIC_CODE
       integer, TRACE_WEIGHTING_FACTOR integer,
       GEOPHONE_GROUP_NUMBER_OF_ROLL_SWITH integer,
       GEOPHONE_GROUP_NUMBER_OF_TRACE_NUMBER_ONE integer,
       GEOPHONE_GROUP_NUMBER_OF_LAST_TRACE integer, GAP_SIZE integer,
       OVER_TRAVEL integer)'

The initial location from which v.in.ogr was invoked was already switched to a sqlite-backend. How can this issue be overcome ?

-> I'm no SEG Y guru, so having v.in.ogr infer the settings for the resulting target location would be required. 

Cheers,
Peter 

<peter.loewe at gmx.de>