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 has been entered as NIM077138. We are reviewing this and will post our findings.
Thanks Lance 🙂
I've discovered if you add a point (eg. 179.01, -39.01) then delete it, the extents don't seem to contract again. So I'm guessing we can use that to workaround the bug by adding some dummy features. Though is recalculating the spatial index or something else (eg. changing a lot more features) likely to reset the extent and break it again?
I pre-populate the envelopes of GEOGCS ArcSDE layers with {-180,-90,180,90}, just so I don't have to deal with envelope property updates changing the scale at which ArcGIS displays.
I pre-populate the envelopes of GEOGCS ArcSDE layers with {-180,-90,180,90}, just so I don't have to deal with envelope property updates changing the scale at which ArcGIS displays.
Is there an easier way to do that than by creating and removing dummy features? Rob 🙂
I don't generally work with FGDBs, but the table creation XML includes a data envelope property (look for "Extent" in the .xsd). You should be able to create featureclasses and featuredatasets with pre-defined extents.
... the table creation XML includes a data envelope property (look for "Extent" in the .xsd). You should be able to create featureclasses and featuredatasets with pre-defined extents.
Good idea 🙂 I changed <Extent xsi:nil="true"/> into the following in both the FeatureDataset & FeatureClass definitions:
It's accepted by the FileGDB API okay, but querying the Table via GetEnvelope() immediately after creation results in NaNs for each envelope value, and after inserting data I get the (broken) calculated values for the envelope. I also tried adding a SpatialReference definition to the Extent - made no difference. So I guess I haven't specified the envelope correctly, or the FileGDB API is ignoring it?
