Polygons with arcs do not have the correct area

[DonnyVelazquez]

It appears there's a bug in the fgdapi when inserting polygons with arcs. It doesn't calculate the area correctly. It only calculates the straight sides and does not include the area the arc is creating. Once you run it through repair geometry, it fixes the calculation.

Anyone else run across this? Vince Angelo​

[DonnyVelazquez]

There is no public method for calculating area. But my assumption is that when a feature is added using the api that the area is calculated for it internally.

Is that true? I can't imagine that when you look at the area in ArcMap that the area for all features are calculated at that time.

[VinceAngelo]

I don't think that's a safe assumption at all!  There's two competing questions:

• Why waste time calculating area if it isn't needed?
• Why bother storing area if it can be calculated?

These are addressed differently by different formats -- area may be stored in SDEBINARY/SDELOB "Fn" tables, for example, but for others the value is calculated on the fly (the stored value may not be of any use, anyway, since if could be based on Cartesian degreees)

The fact remains that Desktop does not use the File Geodatabase API.  I suggest you take this over to the ArcObjects SDK place, posting a complete code sample to address your issue.

- V

[DanPatterson_Retired]

undone

[DonnyVelazquez]

So let me get this straight. Are you saying any data created using the File Geodatabase API is not guaranteed to work in ArcGIS Desktop correctly?

I thought the point of the API was to read and write official file geodatabase's.

[VinceAngelo]

I didn't make any claims about software functionality.

The File Geodatabase API is an open-licensed API library for simple feature access to Esri File Geodatabase data.  It is a subset of the capability of ArcObjects with respect to geodatabases, as documented.  It is most certainly not the reference implementation for File Geodatabase access.

Even though steps were taken to prevent it, there still exists a possibility that data generated via FGDBAPI.dll will have issues when accessed by ArcObjects, especially with respect to true curves (aka CAD objects).  This is more an issue of the arcane complexity inherent in CAD representation, where the same words mean different things in different CAD software.  If geometry "repair" corrects a CAD issue, then it wasn't encoded correctly (and if the area changes significantly, it may be due to the parallel shape vertex array not being populated correctly).

Again, in order to evaluate whether a defect exists, you need to provide Esri with a reproduction case.  If it's a FileGDBAPI issue, provide FileGDBAPI code; if it's an ArcObjects issue, create a new thread over in ArcObjects and provide ArcObjects code.

- V

[DanPatterson_Retired]

Polygon - Wikipedia, the free encyclopedia I had hoped for a chiliagon implementation at least, to allow for the link back to René Descartes and the cartesian coordinate system (ahem)

[VinceAngelo]

I came close, with the 720-side shape.  And don't forget that C in Cartesian, professor!

[TimHodson]

Hello Donny,

It sounds like this may be related to the code used to create the polygon. I suspect the code may not be using the simplify method prior to storing the row in the feature class? I wrote a function (adapted from old VB code) to try to reproduce your case. Though I was not seeing the specific problem you describe, I found that you can get odd results if you do not use the simplify method. In my case polylines oriented counter-clockwise, when converted to polygons, result in a negative Shape_area attribute in the stored polygon unless the Simplify method is called first.

IPolygon::SimplifyPreserveFromTo

Please see the attached code and comments for more info.

-Tim

[DonnyVelazquez]

This problem is with the File Geodatabase API not with Arcobjects.

[VinceAngelo]

In order to demonstrate that it's a problem with the FGDB API, you'll need to provide a code sample which exhibits the behavior.  There are a number of other possible explanations, and they all key on the exact contents of the geometry.  Without a code sample, there is no way to distinguish between options.