ArcGIS Pro Testing: Documentation enhancement? Regarding Required/Non-nullable Domain values and Default values

[NCT911-DLindsey]

Hey Tom and Jason,

Maybe this was something already hashed out during the v1 working group, but I wanted to get your opinion on this. In summary, I think some expanded explanations in the documentation could be beneficial for novice Esri users.

Within ArcGIS Pro (tested with 3.0.3), some parts of the template file gdb appear to be dead-in-the-water until the end-user modifies the schema to include missing domains or "default" values for the required, non-nullable attributes. I was attempting to create new features for testing, then realized I could not add new RoadCenterline features because ArcGIS Pro was immediately rejecting the "null" attribute values created by the new feature (specifically "Value doesn't fall within Domain" errors).

I poured through the documentation on GitHub, and saw the pieces where agencies could modify the schema/domains to fit their organizational needs, but nothing specific about the schema requiring adjustments in order to function (Please correct me on that if I overlooked it somehow).

Example:

I'm able to fix this pretty quickly by going into the field properties and setting a default domain value. This is probably not going to be a problem for most ArcGIS Pro users.

However, the schema template also includes required domains that rightfully have no domain values to choose from due to jurisdictional differences (CountyOrEquivalentA2 domain is an example):

Getting around this was a bit trickier. I was unable to set a default value (because there was no coded list of values to choose from), the fix involved more effort to create actual values for that domain before proceeding with defaults or attribute rules.

Maybe it's just a matter of updating the dependencies documentation to explain what the ArcGIS Pro end-user needs to do before attempting to deploy the schema. I was able to get things sorted out pretty quickly, but I wouldn't expect this to be easy to figure out for the novice users.

-- David L.

[tomneer]

The domain errors for Country, State, and Parity seem to be working as intended. Those values must be attributed on record creation, however, the Country and State fields could be resolved by the usage of a default value.

County and honestly DiscrpAgID also do need to have those domains populated by the user, I agree that we should mock up some documentation to present to the working group for review.

One other item is that this data model is intended, as I understand, as a format of data transfer between organizations or submit to the SI. Typically, an internal dataset would use an ETL process to populate this standard. While the data model can be used as a template for organizations to internally structure their schema, it is not mandatory. Would it be helpful to maybe clarify this? Honestly, it is a bit confusing to me also.

[jasonhorning]

In our V1 readme document we had this:

Domain Use Within the templates there are some domains that have no entries. These domains include AdditionalCode, AgencyID, County, ESN, PostalCode, PostalCommunityName and ServiceURI. The entity is expected to populate these domains, in accordance with guidelines specified within the NG9-1-1 GIS Data Model standard, based on the needs within their jurisdiction.

For domains that have entries, but do not completely meet the entity's needs, the entity is encouraged to find the proper channel through which those domains can be extended. For example, in the case of the LegacyStreetNameType, the owner of those entries is the United States Postal Service; to extend that domain requires a change in USPS Publication 28 Appendix C1. In the case of the StreetNameType, StreetNamePreTypeSeparator and PlacementMethod domains, those entries are maintained by NENA through the NENA Registry System and new entries can be requested through that system. In the case of Country, PlaceType and ServiceURN the entity is encouraged to contact NENA to seek more direction for requesting new entries.

Lastly, there are some domains where extension is not anticipated. Those include domains such as MilePostIndicator, MilePostUnitOfMeasurement, LegacyStreetNameDirectional, StreetNameDirectional, OneWay, Parity, RoadClass, State and Validation. However, if an entity believes changes are needed for these domains the entity is encouraged to contact NENA to seek more direction for requesting new entries.

[NCT911-DLindsey]

Thank you both!

Jason, I like the idea of re-adding that Domain Use section to the v2 documentation. I'll admit, I didn't even think to unzip and examine the v1 documentation, so thanks for putting that on my radar.

From what I can tell, ArcGIS Pro is being far more aggressive with attribute enforcement than ArcMap (I can create features in ArcMap using the current schema template without domain errors populating, for example). What do you guys think about expanding that Domain Use section to include wording along the lines of: "Depending on the GIS software being used, you may need to ensure domains are populated and default values assigned for NENA required fields prior to deploying the schema. Otherwise, errors may be encountered."

[tomneer]

A new section was added to the top-level README.md discussing unpopulated domains and their usage.