[GRASS-dev] Re: [GRASS-CVS] markus: grass6/lib/vector/Vlib field.c, 1.38, 1.39

Markus Neteler neteler at itc.it
Wed Jun 14 17:40:57 EDT 2006


On Wed, Jun 14, 2006 at 04:15:34PM -0500, Huidae Cho wrote:
> On Wed, Jun 14, 2006 at 10:59:35PM +0200, Markus Neteler wrote:
> > On Tue, Jun 13, 2006 at 11:41:05PM -0500, Huidae Cho wrote:
> > > On Wed, Jun 14, 2006 at 12:52:10AM +0200, grass at intevation.de wrote:
> > > > Author: markus
> > > > 
> > > > Update of /grassrepository/grass6/lib/vector/Vlib
> > > > In directory doto:/tmp/cvs-serv19408
> > > > 
> > > > Modified Files:
> > > > 	field.c 
> > > > Log Message:
> > > > GID search added; auto-search of FID fixed (still non-functional due to apparent OGR_L_GetFIDColumn() failure; auto-search disabled
> > > > 
> > > 
> > > Markus,
> > > 
> > > The FID auto-search works well with PostgreSQL:
> > > 
> > > GRASS 6.1.cvs (Bryan):~/tmp > v.external dsn="PG:host=localhost dbname=mydb user=me" layer=tmp output=tmp
> > > D0/0: Using FID column <ogc_fid> in OGR DB
> > > Building topology ...
> > > WARNING: Random read is not supported by OGR for this layer, cannot build
> > >          support.
> > > 
> > > It looks like not all the OGR formats support FID column
> > > (http://ogr.maptools.org/classOGRLayer.html#a26).  For example, shape files
> > > have no FID columns.
> > 
> > Here is the related wish report:
> > 
> > Subject: [Bug 1019] Method to determine and return FID-colum in OGRLayer
> > http://bugzilla.remotesensing.org/show_bug.cgi?id=1019
> > 
> > There seems to be support for
> > - PostgreSQL
> > - MySQL
> > - Oracle
> >  
> > > FYI, find attached the patch for gdal-1.3.2.
> > 
> > Could you tell me more about this patch? Needed to make
> > PG support functioning?
> > 
> >  thanks
> > 
> >  Markus
> 
> Markus,
> 
> I checked if v.info worked with a v.externaled PostgreSQL vector and,
> unfortunately, it didn't:
> 
> GRASS 6.1.cvs (Bryan):~/tmp > v.info tmp
> D1/3: Vect_open_old(): name = tmp mapset= PERMANENT update = 0
> D1/3: Vect_set_thresh(): thresh = 0.000000
> D3/3: dig_init_plus()
> D1/3: dig_spidx_init()
> D3/3: dig_cidx_init()
> D1/3: open format file: 'PERMANENT/vector/tmp/frmt'
> D3/3: dig_read_frmt_ascii()
> D1/3: Vector format: 1 (non-native)
> D1/3: Vect_set_thresh(): thresh = 0.000000
> D1/3: Vect__read_head(): vector = tmp at PERMANENT
> D1/3: Vect_set_thresh(): thresh = 0.000000
> D1/3: Level request = 2
> D1/3: Vect_open_topo(): name = tmp mapset= PERMANENT
> D1/3: Topo file for vector 'tmp at PERMANENT' not available.
> D2/3: G__home home = /home/hcho
> ERROR: Cannot open old vector tmp at PERMANENT on level 2
> GRASS 6.1.cvs (Bryan):~/tmp >

I had exactly the same problem. That's why I disabled the
auto-FID search (so, apparently unrelated, but the version
check should be set to 1330 if Frank applies the patch
for the next release).

 
> Without the attached patch, the resulting SQL query from v.out.ogr will look
> like (invalid SQL query):
> 
> INSERT INTO "table" (WKB_GEOMETRY ) VALUES (INSERT INTO "table" (WKB_GEOMETRY )
> VALUES ('\\001\\002....')
> 
> because osCommand already has "INSERT INTO 'table' (WKB_GEOMETRY ) VALUES (" in
> it and it's appended to itself again by "osCommand += osCommand ...", which I
> fixed.  Note "INSERT INTO" command after the first VALUES.  This bug has been
> reported to the gdal bugzilla.


http://bugzilla.remotesensing.org/show_bug.cgi?id=1203

Thanks for tracking that down, I have added myself in cc to watch the
bug.



Markus




More information about the grass-dev mailing list