Data Catalog | Comparison Areas and Relationships

Comparison areas are a key part of InstantAtlas outputs, easily enabling areas to be placed in context with others, for example, a ward value is displayed alongside that of the local authority, region and country.

InstantAtlas apps and tools enable you to make use of data pulled from several different feature services if you want. This allows you to manage your data in discrete services and provides access to more data than can be stored in a single feature class.

In data referenced via a Data Catalog comparison values are implemented using relationship classes defined between feature classes within a feature service. For users of the InstantAtlas National Data Services these relationships are created as part of the data supply process. This note describes the considerations for setting these up independently or for data you wish to add to an existing data catalog.

Relationship classes cannot currently be created in ArcGIS Online – feature services with relationships are created by defining the relationship classes in ArcMap or ArcGIS Pro. Note that this requires either the standard or advanced levels of the ESRI software.

For an overview see:

ArcGIS imposes a restriction that relationships may only be created between feature classes within a feature service. To load data onto ArcGIS Online we create one file geodatabase per feature service we want to create (loading data into an existing catalog is covered in more detail in this blog post).  Within this feature service we will have one feature layer per geography. A feature layer can have a mix of indicators in it. 

In order to participate in relationship classes each lower level feature class (termed the destination table by ESRI) must contain a field containing the IDs from the higher-level feature class (termed the origin table by ESRI). For example, a LSOA feature class requires a MSOACode field containing the MSOA ID if MSOAs are to be available as a comparison for LSOAs.

This discussion assumes that relationships are one to many – for many to many see the ESRI documentation. These require an additional table within the feature service. The InstantAtlas tools support these relationships but careful consideration of the effects is recommended before using.

Experienced users may wish to use Python scripts to create the relationships. The geoprocessing toolkit is easy to use for a few relationships.

When integrating your data and relationships with the Data Catalog there are some rules that must be followed.

 Relationship Class Naming

The relationships that will be used in reports and dashboards are defined based on the relationships available from the core feature service – the one used in the web map that is the starting point for the report. When using a Data Catalog, that means the core layer(s). The relationship class names must have a fixed pattern:

[destination geography feature class name]_[origin geography feature class name]{<optionally>_[featureservice identifier]}.

Thus for a relationship between LSOA  (feature class name LSOA), and Region (feature class name Rgn) the relationship class name is LSOA_Rgn in the core layer. Any data layers using relationships must then follow the pattern – so a service containing economic indicators from the 2011 census should have a relationship named LSOA_Rgn_EconC2011. For a Ward to District relationship the names would be Ward_LTLA and Ward_LTLA_EconC2011.

Relationship Class Ordering

The order in which comparison areas will be shown (for example in a table in a report) table is determined by the order in which they appear within the feature service. This order is determined by the order in which they were created. Thus if you have comparison areas for wards at local authority, region and country level and wish to see them in that order you must create the relationship classes in the same order (this is true for both the base map and any additional data feature services).

Feature Class Field Names

The final rule that must be followed for a comparison value to be obtained is that the data field name must be the same in both feature classes. So, for an unemployment rate for May 2014 at ward and district level the field name in each feature layer might be UNEMRATE_201405. Fields with different names (e.g. UNEM_2014_MAY_WD and UNEM_2014_MAY_DIS) are not supported.