jasonhorning
commented
1 year ago Thanks for catching this.. after looking at the Esri documentation this seems accurate to me. Although, setting everything to NON_REQUIRED seems a bit risky from an official "NENA" template and script perspective. I can see that potentially leading to implementations that are missing one or more "required" attributes on individual records since users may delete virtually any field without issue.
That said, I suspect being unable to remove fields (e.g. ESN) when they are no longer relevant would be a tough pill to swallow for GIS folks. I don't know that there's a perfect solution but appreciate you bringing it forward for consideration. Is this something that can wait for a future version or is it important it be resolved now?
brudo
tomneer
In the NENA NG911 documentation, where it says a field is "required" it means that field does not allow null values, and if the field is not required, it means that the field does allow null values.
In the Python rendering of the NENA specification, i.e. schema_fgdb_v2.py, which is used when creating a Geodatabase, the properties NON_NULLABLE and REQUIRED are both specified for fields that are indicated as "required" in the NG911 documentation, and both NULLABLE and NON_REQUIRED for fields that are not indicated as "not required" in the NG911 documentation.
This appears to be a misinterpretation of what "REQUIRED" means in the Geodatabase. The "REQUIRED" property of a Geodatabase Field does not indicate anything about the values that can be stored in that field; rather, it indicates that the field is "permanent" and cannot be deleted from the schema via the UI or via Geoprocessing tools like DeleteField (Data Management). This is enforced even for File Geodatabases, and even for Enterprise Geodatabases where the connection is for the owner of the dataset, or a DBA.
Based on this, I suggest that either all fields in the NG911 spec should be REQUIRED, or perhaps better, that all should be the default, NON_REQUIRED, and that only NULLABLE vs. NON_NULLABLE should be indicated in the field specification, as this is the property that truly corresponds (inversely) to what "required" means in the NENA NG911 documentation.
It should not be that the non-nullable fields are required / permanent, while the nullable fields are not. It would be more consistent with the PostgreSQL schema if all of these fields are the default NON_REQUIRED, as there is no concept of making a field "required (permanent / impossible to delete)" outside of a Geodatabase. (This is also consistent with what you get if you copy a Feature Class or Table containing required / permanent fields - at least according to my test, they are not required / permanent in the copy.) Normally, unless there is some special reason to do otherwise, the only "required" fields in a Geodatabase are things like OBJECTID and SHAPE.