Temporal data in separated tables ? Bug ?

322
0
06-09-2020 08:41 AM
AlbertoAloe
Occasional Contributor

Hi everybody.

I noticed a different behavior of ArcGIS Pro versus ArcMap when dealing with temporal data in separated tables with one to many relationship (Temporal data in separate tables—ArcGIS Pro | Documentation ).

Using a file geodatabase feature class of 17828 points joined with a time series table class with 142624 (17828 X 8 years)  in ArcGIS Pro:

  1. After the join the layer behaves much like a 'real inner/outer join' outputting  142624 features according to the cardinality of the table class . However, when opening the attribute table it complains through a warning of the duplicated ObjectIDs.
  2. When enabling time, the table does not honor it. It shows back 17828 distinct spatial objects for the initial time step (despite time filtering enabled). Playing with time filter does not change attribute table content (always first year shown)
  3. The map honors the time. As I play with the time slider only features relevant for the active time step are displayed
  4. The identify tool does not honor the time because clicking on a point displays all the duplications due to the temporal join.

Using the same feature and table class as described above  in ArcMap:

  1. After the join the layer does not behave like a 'real inner/outer join' outputting  17828 features linked to just a temporal step (the first year) . As a result no duplication of spatial objects occurs.
  2. When enabling time the table honors it displaying recs relevant for the selected time step in the time slider
  3. The map honors the time. As I play with the time slider only features relevant for the active time step are displayed
  4. The identify tool honors the time because clicking on a point displays the point for the relevant time step only

ArcGIS Pro behaves differently and in a way that prevents a correct management of temporal data. Is this a bug ?

Obviously:

  • Making a feature class with a geometry per time step fixes the issue but the point is that a better geodb design should go for the separated time series table
  • When using an enterprise geodb  is at least possible to do something at db level with a view fixing things in an elegant way

Thanks. Let me know what you think

Alberto

0 Kudos
0 Replies