Thanks Even. It seems that just using the -sql options works nicely - you don't even need to do the column rename :)
-----Original Message----- From: Even Rouault [mailto:[email protected]] Sent: Friday, 14 December 2012 7:56 a.m. To: Jeremy Palmer Cc: [email protected] Subject: Re: [gdal-dev] FileGDB -preserve_fid Le jeudi 13 décembre 2012 09:56:14, Jeremy Palmer a écrit : > > At first sight, I would say it is a limitation of the FileGDB API. > > > > In FGdbLayer::CreateFeature( OGRFeature *poFeature ), > > > > you can see the following commented code : > > /* Cannot write to FID field - it is managed by GDB*/ > > > > //std::wstring wfield_name = StringToWString(m_strOIDFieldName); > > //hr = fgdb_row.SetInteger(wfield_name, poFeature->GetFID()); > > > > So there was an attempt made of preserving the FID, but apparently > > it doesn't work. > > > > Looking at Row.h in the FileGDB API include files, I can see that > > there's a public GetOID() method, but SetOID() is private. So it > > seems that the FileGDB API manages itself the OID. > > > > Even > > Thanks for the info. So what are the options to get the source FID > data into FileGDB? I found if I remove the primary key from the > Postgresql table that works. However this is a less than desirable option. Try with a SQL statement that will rename the primary key into another name, for example : -sql "select *, ogc_fid as the_fid from poly" This message contains information, which is confidential and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or [email protected]) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank You. _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
