Search our website

SGID policy

Documentation

Quick Links

The policies on this page govern the way we interact with data in the SGID. Many of these policies also apply to external data being submitted to the SGID.

We use the following terms intentionally on this page:

Must
This is as close to a hard and fast rule as we get (short of the legislative "thou shalt" language in our establishing laws).
Should
We generally follow this rule, but we allow for exceptions at our discretion.
May
We can apply this rule, but our policies don't necessarily require or encourage us to act.
Will
We will take the prescribed action if the specified conditions occur.

Datasets added to the SGID must meet the following criteria. We may remove any existing datasets that do not meet these criteria. All additions to the SGID should follow the appropriate sharing process and be tracked through Porter , opens in a new tab .

Three people sitting at a table creating policy

General qualifications

These criteria apply to all datasets added to the SGID, regardless of which part of the SGID they belong to.

  • Datasets must cover a state-wide geographic extent, be part of a state-wide project or initiative (such as roads, address points, and parcels), or be relevant to broader projects or mandates that have a state-wide interest (e.g. geologic hazard mapping or endangered species mapping).
  • The entity providing the dataset must be the authoritative or original source (for example, a dataset of geologic hazards as identified by the Utah Geological Survey must come from the UGS, not another organization).
  • Datasets should have a reasonable update schedule included in the metadata.
    • We may add datasets that result from a one-time project and won't be updated in the future, but this should be clearly stated in the metadata.
  • Datasets must not contain any information considered private, protected, or controlled under the Utah Government Records Access and Management Act (GRAMA) , opens in a new tab or any other personally identifiable information (PII).

SGID Index qualifications

These criteria apply to all datasets added only to the SGID Index and not anywhere else in the SGID (for example, download links for resources hosted on an entity's own server).

  • Datasets should be publicly available without requiring a login.
    • We may add references to datasets that are restricted due to safety or security concerns as a way to raise awareness that the datasets exist but are restricted.
  • Dataset links should be stable and maintained for the forseeable future. Frequently changing links are difficult to maintain, and dead or out-of-date links damage our collective credibility and the public's confidence in our data.

SGID on ArcGIS qualifications

These criteria apply to ArcGIS Online items shared through the SGID on ArcGIS site.

  • Datasets must be publicly available without an ArcGIS login.
  • Datasets should have a stable schema. Clients will be using the services directly, and deleting or renaming fields will break pop-ups, definition queries, and other schema-dependent actions.
    • Adding new fields is ok.
  • Datasets must have a stable layer id, preferably 0. Read about assigning layer IDs , opens in a new tab in the Esri documentation.
  • All datasets from a single entity must be shared from the same ArcGIS Online user OR have a custom and consistent organization name specified in the ArcGIS Online item metadata as described in the "Source" note in the SGID on ArcGIS sharing process.
  • Datasets must define the following metadata items in the ArcGIS Online item:
    • The title should include "Utah" if the rest of the title is not immediately and uniquely identifiable as a Utah dataset.
    • The description must include a summary of the dataset. The first line should include the date the dataset was last updated.
    • The tags should include the source entity's name and any other relevant words not found in the title (please refer to Esri's post about using tags effectively , opens in a new tab for more information).
  • Datasets should enable the "Allow others to export data to different formats" option in their ArcGIS Online settings to enable end users to download the dataset as a file geodatabase.

We strongly encourage dataset owners to follow these ArcGIS Online-specific guidelines, even though the SGID Open Data site does not use them directly:

  • An item's thumbnail appears when a user searches for the dataset on ArcGIS Online or in ArcGIS Pro. A branded thumbnail , opens in a new tab tells users that this is an authoritative dataset. For example, we use thumbnails that include the category logo for all the SGID data we share in ArcGIS Online.
  • Mark the item as authoritative in ArcGIS Online. This helps users decide which dataset to use when their search in ArcGIS Online returns several similar results.

Open SGID qualifications

These criteria apply to datasets delivered to UGRC for inclusion in the Open SGID.

  • Datasets should be useful to multiple agencies or organizations' daily activities or decision-making. Datasets primarily used internally by a single agency aren't great candidates for the Open SGID; instead, it would be great to have references to them in the SGID on ArcGIS site or the SGID Index.
  • The entity providing the dataset should lack the internal capability to publicly serve the data (such as through an existing ArcGIS Online organization).
    • We may chose to not include a dataset if an entity has the capability to share it but lacks server capacity or is trying to reduce data storage costs.
  • Datasets should be a core and vital GIS layer for the state (for example, land ownership category boundaries).
  • Datasets should have a stable schema. Clients may be using the datasets directly from the database and may be relying on the presence of specific fields.
  • Datasets should have accurate metadata that meets our minimum metadata standards.

Dataset deprecation and removal

Datasets being removed from the SGID must follow these policies.

General Removal Policies

  • We reserve the right to remove any dataset at any time.
  • Removals should be tracked in Porter , opens in a new tab .
  • The steward should give users at least two weeks prior notice to removal whenever possible.
  • Stewards of ArcGIS Online services should perform a brownout by marking the data as Deprecated in the item's settings and including "deprecated" in the item's title.
  • When possible, UGRC will change the sharing level of items being removed from our own ArcGIS Online organization from public to private two weeks before deleting the items completely to allow quick restoration if end users need time to find an alternative.
    • End users should not rely on this two-week brownout.
    • When possible, we encourage other stewards to adopt this same two-week sharing brownout as well.

Reasons for Removal

Many items were added to the SGID before we adopted these policies and guidelines. We may evaluate them from time to time for removal. In the spirit of continuity, we do not intend to do an immediate, wholesale trimming of the SGID.

While not comprehensive, the following list includes the most common reasons for removing datasets:

  • The dataset no longer meets the qualifications above.
  • The dataset's schema has substantially changed.
    • A new dataset with a new schema should be introduced instead of breaking the existing schema.
  • The dataset is out-of-date.
  • The dataset is no longer being updated by the steward.
  • The steward has requested removal of the dataset.
  • A more authoritative source for the dataset exists elsewhere.
  • A link has been abandoned and no longer returns a proper web page.

In addition, we may remove any ArcGIS Online items from SGID on ArcGIS that aren't shared through the sharing process. We may remove items from the staging group if the submitter fails to provide adequate information according to the guidelines in the sharing process.

"Static" Datasets

We anticipate some SGID datasets historically made available through the SDE connection or currently hosted in the Open SGID won't receive future updates, such as the boundary lines for adjacent counties in the surrounding states. We will remove these datasets from the Open SGID but leave in ArcGIS Online, where they will be tagged as static and remain members of a Utah SGID group.

"Shelved" Datasets

Over time, we will remove datasets from the Open SGID that are no longer current but continue to have historical value (e.g., Census/ACS data or previous tax district boundaries). Their associated ArcGIS Online items will be tagged as shelved and placed in the public UGRC Shelf , opens in a new tab ArcGIS Online group for future reference. Shelved datasets are not included in the SGID on ArcGIS site.

Miscellaneous policies

Dates in Dataset Names

We will include dates in the names of datasets in the census, political, or tax categories to identify datasets where the most current data may not reflect the current calendar year, such as the latest Census demographic data.

For all other categories, dates should only be used for datasets that are no longer effective/active or are soon-to-be effective/active. This implies that the most current and relevant data contains no date suffix. Historical or future data should contain a date suffix to help identification at a glance.

The best way to identify a dataset's vintage or time frame is to view the metadata on its data page.

Internal Database Standards

The SGID uses the ESRI default Resolution and Tolerance:

  • XY Resolution: 0.0001 Meter
  • XY Tolerance: 0.001 Meter

Any coded-value domain codes must match their values (for example, "Interstate Highway" - "Interstate Highway" instead of 1 - "Interstate Highway").

Editing Policies

No edits or updates should be made to the internal geodatabase from 7:00PM to 10:00AM MST to allow automated pipelines to make updates to ArcGIS Online and the Open SGID. UGRC should ensure that data are production-ready before the editing window ends.

All bulk data updates being pushed into the SGID should be run through Sweeper , opens in a new tab or another automated process to review and fix common data and metadata problems.

Whenever a dataset is updated, the Last update date must be updated in the following places:

UGRC should implement a unified metadata database and associated automated tools to capture the last update date in a single location.

Any time a schema change or update is performed, the editor should also update any coded-value domain descriptions that do not match the domain value. See this document , opens in a new tab for more on this effort.