Writing Spatial Reference Coordinate System info using FileGDB_1.3_2010 C++ API

[ViksitAgarwal]

I am using FileGDB_1.3_2010 C++ API to create and write feature classes in FGDB data.  What is the best way to correctly write the Spatial Reference Coordinate System info for a feature class? I have full coordinate system information of my spatial data with me.  I know I can programmatically get the list of supported Coordinate System list (as documented in SupportedGCS_PCS.pdf) from the API.  But the biggest challenge for me is to find the matching WKID and Name from this huge list.  I tried to convert my coordinate system info to WKT string and use that to find the matching SRInfo, but unsuccessful.  Always writing SpatialReference tag as xsi:type="esri:UnknownCoordinateSystem" is the only solution or is there any better way?

Thanks in advance for the help.

Viksit

[LanceShipman]

The file geodatabase API does not support custom GCS or PCS. If you cannot find it in the list, it is likely that it is custom and not supported. If you post the projection information we will take a look.

[ViksitAgarwal]

Actually I am writing a software layer on the top of ESRI API to create and write FGDB data.  My question is not specific to any fixed coordinate system.  From source data I can create the .prj file or WKT string.  My question -  Is there any way in FGDB API, where I can give input as WKT string and get back the matching WKID from the supported CS if there is any?  Even if there is no direct API call available for this, what would be best algorithm to search through SpatialReferences class.  The WKT string or .prj contents format does not follow a fixed syntax, so it is difficult to construct srname or auth_srid that can be passed into FindSpatialReferenceBySRID or FindSpatialReferenceByName  functions.

[VinceAngelo · Accepted solution]

Since the API doesn't support it, it looks like you'll need to code your own comparison
function which is lenient on "name" text and flexible in numeric values (e.g., treating
"foo=25.0" as an equivalent of "FOO=25" and "Foo=25.00").

Yeah, I know, it's not attractive, but that's what would be necessary to merge non-standard
designators into the API.

- V