Method to determine and return FID-colum in OGRLayer

[holl@…]

Hello Frank,

Due to the fact that different datasets can have different FID-columns, it would
be good to have a function in OGR which returns the FID-column-name. Currently
GRASS cycles through some defined names, which definetly is not a good solution.

So a method which returns the FID-column would be good, which then could be
picked up by v.external/v.in.ogr.

The driver with priority for us would be the OCI-driver.

Thank you
Stephan Holl

Some former discussions about this topic:

On 10/8/05, Markus Neteler <neteler@itc.it> wrote:
> Frank,
>
> let me disturb you again with below problem. We (GDF Hannover)
> currently try to get Oracle Spatial working with v.external which
> depends on the FID definition.
>
> We are still searching for a generic way (function) to
> find the name of FID, OGR_FID, OCI_FID etc since looping
> over all possible combinations isn't very elegant.
>
> Do you see a chance to help? Hopefully we are simply
> overlooking how to do it.

Markus,

There is no current mechanism in OGR to determine what column
might be used as the FID (if any).  In most drivers there is no distinct
FID column.  However, in RDBMS drivers we normally try to find
a column that could be used as the FID and if one is not found then
FIDs are assign sequentially as the table is read back.

In some of the RDBMS drivers, the columns are searched to
try and identify one that is the primary key (and is integer).  If
found this is used as the FID.  So iterating over names is never
going to work properly all the time.

If you think it necessary, I would be willing to add a method on the
OGRLayer that would return the name (or index?) of the FID column
if there is one in use.  Since the FID column is dropped from the
feature attributes by at least some drivers, I guess it would be best to
return the name.  Then appropriate drivers (postgres, ODBC, OCI, etc)
could be updated to implement a non-default version of this method.

So, are you confirmed this is what you need?  If so, submit a bug
entry for the issue and I will try to do it pretty soon.  Let me know
what drivers are priorities for you.

PS. I have to admit I am not overly keen on this addition because it
seems to break the isolation of the underlying datastore from the
OGR application.    So, if implemented it will be for immediate
practical purposes.

Best regards,

[warmerdam]

I have added GetFIDColumn() and GetGeometryColumn() methods on the
OGRLayer.  I have also implemented driver support in the MySQL and
PostgreSQL drivers. 

[neteler@…]

Frank,

thanks a lot!
May we ask you to also implement it in the Oracle driver?
This was the highly wanted one...

Best

 Markus

[warmerdam]

Markus,

I have committed support for this in the oracle driver, but I can't
test it without rebooting and a bunch of fiddling.  Could someone
else try this from CVS? 

[neteler@…]

Frank,

since this is only in GDAL CVS, upon which #ifdef we should
conditionalize the use of the new functions in GRASS? Use
a version macro or tweak GRASS configure for presence of
the OGR_L_GetFIDColumn() function?

thanks
Markus

[warmerdam]

If you include gdal_version.h (this is also included by gdal.h) you
can test the version and release date.  I think you would want a 
condition like:

#if GDAL_VERSION_NUM >= 1320

#endif

For testing you would need to update your local
gdal_version.h to 1.3.2.0.