topic Re: BUG: Table extents truncated, breaking spatial indexes in File Geodatabase API Questions

BUG: Table extents truncated, breaking spatial indexes

RobertCoup — Sat, 11 Dec 2021 15:44:35 GMT

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 🙂

Re: BUG: Table extents truncated, breaking spatial indexes

LanceShipman — Wed, 18 Jan 2012 20:28:38 GMT

This has been entered as NIM077138. We are reviewing this and will post our findings.

We were never able to reproduce http://forums.arcgis.com/threads/451...-API-in-ArcMap.

Re: BUG: Table extents truncated, breaking spatial indexes

RobertCoup — Wed, 18 Jan 2012 21:54:10 GMT

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?

Cheers,

Rob 🙂

Re: BUG: Table extents truncated, breaking spatial indexes

VinceAngelo — Wed, 18 Jan 2012 22:54:06 GMT

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.

- V

Re: BUG: Table extents truncated, breaking spatial indexes

RobertCoup — Thu, 19 Jan 2012 00:02:10 GMT

Hi Vince,

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 🙂

Re: BUG: Table extents truncated, breaking spatial indexes

VinceAngelo — Thu, 19 Jan 2012 11:52:10 GMT

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.

- V

Re: BUG: Table extents truncated, breaking spatial indexes

RobertCoup — Sat, 11 Dec 2021 15:44:38 GMT

Hi Vince,

... 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:

<Extent xsi:type='esri:EnvelopeN'>
  <XMin>-180.0</XMin>
  <YMin>-90.0</YMin>
  <XMax>180.0</XMax>
  <YMax>90.0</YMax>
</Extent>

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?

Thanks,

Rob 🙂