When adding features via the FGDB API (v1.1, Linux 64bit), table extents are not calculated correctly. The envelope returned has each value truncated to the nearest integer value, but returned as a double.From the attached sample code, which creates a FileGDB and populates it:
Inserted point 0 (x10000): 172.875856, -34.317553
Inserted point 1 (x10000): 173.938053, -34.969507
Inserted point 2 (x10000): 174.927365, -35.880395
Table envelope: xMin=172.000000 yMin=-35.000000 xMax=174.000000 yMax=-34.000000
Calculated envelope: xMin=172.875856 yMin=-35.880395 xMax=174.927365 yMax=-34.317553
This causes problems when a spatial index is calculated - if a feature falls outside the truncated extent values (ie. Point 2 above) it will not draw in ArcMap unless at least some of the truncated extent is visible. ie. zoom right in and the feature will disappear - zoom-to-layer or further out and it'll likely draw. To show all the points, you can delete the spatial index (in either ArcMap or via the FGDB API) but obviously this makes the layer painfully slow. Recalculating the spatial index in ArcMap, or deleting & recreating the index in ArcMap breaks it again. Note that spatial indexes won't necessarily be calculated by the API if there aren't very many features - this is why the attached sample adds each of the points 10,000x. Even on a very small layer which has no calculated spatial index on the result from the FGDB API - if you recalculate the spatial index in ArcMap it will break the layer.The issue is obvious on geographic coordinate systems (since entire layers may easily fit into a 1 degree square, and they just disappear) but happens on projected coordinate systems too, though users are unlikely to see it in ArcMap. It also occurs for Polygon/Line layers.This problem seems to have been identified in: http://forums.arcgis.com/threads/45187-Problems-displaying-feature-classes-created-via-API-in-ArcMap but never resolved.Thanks,Rob 🙂
