[GRASSLIST:5228] Re: creating vector points layer from database coordinates

[Tom Russo]

On Sat, Dec 25, 2004 at 12:25:43PM -0600, we recorded a bogon-computron collision of the <fonnesbeck at gmail.com> flavor, containing:
> I am trying to create a coverage consisting of x,y points derived from
> a mysql data table. Unfortunately, I am running into problems using
> both the v.in.db and db.select solutions in the documentation. Using
> v.in.db ( v.in.db driver=mysql database=test table=mortality
> x=LONGITUDE y=LATITUDE key=recid out=mortality2), I get the following
> error:
> 
> Error in db_execute_immediate()
> 
> WARNING: Cannot create new table: 'create table mortality2 ( recid integer,
>          DATE varchar(6), FILEDBY varchar(20), FIELDID varchar(10), FMPCASE
>          varchar(5), FMPDIST varchar(2), SEX varchar(1), LENGTH double
> precision ... etc.

You have a varchar(6) field called "DATE" --- grass doesn't like that, as DATE 
is a reserved word for SQL.   

> However, when I cut and paste the sql code into the database directly,
> the table is created without any problem!

Perhaps MySQL's parser is able to tell the difference between a field called
DATE and a field with a type of DATE and accepts the create table command.

I had a similar problem that took a while to track down --- the USFS data
layers I had all had fields called DATE (the date the feature was last 
field checked, I think) and it took a while to realize why exactly grass
was refusing to import it.  In my case, using the "cnames" option to v.in.ogr
got me the workaround I needed.

Can't help you with your segfault, though.

-- 
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."