Re: [gdal-dev] OGR OVF has no identified FID column

[Brent Fraser]

Yeah I saw that after I sent the message.  Take out the  <SrcSQL>, it's really 
only useful if want to do "special" things, and it can kill spatial indexing on 
ODBC datasources.  Does this work any better:

<OGRVRTDataSource>
    <OGRVRTLayer name="UserPoint">
         <SrcDataSource>ODBC:un/p...@clo,PointData</SrcDataSource>
         <GeometryField encoding="WKB" field="Feature"/>
         <FID>PKey</FID>
    </OGRVRTLayer>
</OGRVRTDataSource>

Brent

David Lowther wrote:
Brent,

Thanks for the reply. On initial read I thought you had found my issue -
that I was trying so many things I finally messed it all up. But on closer
inspection I am aliasing the PKey column to FID in the SrcSQL (select PKey
as FID, Feature from PointData).

When <FID>FID</FID> ogrinfo returns:

ODBC: ExecuteSQL(select PKey as FID, Feature from PointData) called.
OGR_ODBC: Table SELECT has no identified FID column.
OGR: OGROpen(test.ovf/00ED7090) succeeded as VRT.
Had to open data source read-only.
INFO: Open of `test.ovf'
      using driver `VRT' successful.
OGR: GetLayerCount() = 1

1: UserPoint
OGR: ReleaseDataSource(ODBC:un/p...@clo/02719D10) dereferenced and now
destroying.
ODBC: SQLDisconnect()

When <FID>PKEY</FID> ogrinfo returns:

ODBC: ExecuteSQL(select PKey as FID, Feature from PointData) called.
OGR_ODBC: Table SELECT has no identified FID column.
ERROR 1: Unable to identify FID field 'PKey'.
OGR: ReleaseDataSource(ODBC:un/p...@clo/02C39D18) dereferenced and now
destroying.
ODBC: SQLDisconnect()
FAILURE:
Unable to open datasource `test.ovf' with the following drivers.
  -> ESRI Shapefile


David Lowther
 
Coordinate Solutions, Inc.
 

-----Original Message-----
From: Brent Fraser [mailto:bfra...@geoanalytic.com] 
Sent: Thursday, August 19, 2010 3:15 PM
To: David Lowther
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] OGR OVF has no identified FID column

How about using:
<FID>PKey</FID>

but that doesn't explain why it takes a long time...

Best Regards,
Brent Fraser


David Lowther wrote:
List,
        
I have an OVF layer defined as follows:

<OGRVRTDataSource>
        <OGRVRTLayer name="UserPoint">
         <SrcDataSource>ODBC:un/p...@clo</SrcDataSource>
         <SrcSQL>select PKey as FID, Feature from PointData</SrcSQL>
         <GeometryField encoding="WKB" field="Feature"/>
  <FID>FID</FID>
        </OGRVRTLayer>
</OGRVRTDataSource>

The ODBC connection is to a SQL Express 2008 database. The PointData table
is defined as follows:

CREATE TABLE [dbo].[PointData](
 [PKey] [int] IDENTITY(1,1) NOT NULL,
 [Feature] [geometry] NULL,
 CONSTRAINT [PK_PointData] PRIMARY KEY CLUSTERED 
(
 [PKey] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY =
OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

This query

select *, Feature.STAsText() from pointdata

yields

1 0x00000000010C0000000000C062400000000000C06240 POINT (150 150)

"ogrinfo test.ovf --debug on" runs for a very long time returning many
lines
of this sort of stuff:

ERROR 4: Update access not supported for VRT datasources.
OGR_ODBC: EstablishSession(DSN:"CLO", userid:"un", password:"pw")
ODBC: SQLConnect(CLO)
ODBC: CatalogNameL: (null)
Schema name: (null)

OGR_ODBC: Table PointData has no identified FID column.
OGR_ODBC: Table UserMapData has no identified FID column.
OGR_ODBC: Table CHECK_CONSTRAINTS has no identified FID column.

before finally saying:

OGR: OGROpen(ODBC:un/p...@clo/02C79D10) succeeded as ODBC.
ODBC: ExecuteSQL(select PKey as FID, Feature from PointData) called.
OGR_ODBC: Table SELECT has no identified FID column.
OGR: OGROpen(test.ovf/00E17090) succeeded as VRT.
Had to open data source read-only.
INFO: Open of `test.ovf'
      using driver `VRT' successful.
OGR: GetLayerCount() = 1

1: UserPoint
OGR: ReleaseDataSource(ODBC:un/p...@clo/02C79D10) dereferenced and now
destroying.
ODBC: SQLDisconnect()

GDAL version is 1.6.0.

I have tried using no FID tag and using SrcLayer instead of SrcSQL.
Anybody
know what I could do to make it see the FID? I'm guessing it would be a
lot
faster if it didn't check every table in the database for an FID...

Thanks in advance for your assistance,

Dave Lowther





_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev