Field Precision - Regarding Lines 1022-1029 within schema_fgdb_v2.py

[NCT911-DLindsey]

Hey Tom and/or Jason,

I'm currently reviewing the RoadCenterline section within schema_fgdb_v2.py (lines 1022-1029 specifically).

Within the GIS Data Model, the field width is capped at 6 digits. However, the schema script does not have this limitation set.

FromAddr_L, ToAddr_L, FromAddr_R, and ToAddr_R all have the index 2 position set as empty strings. Should this field precision value at Index 2 be "6" instead of an empty string?

Link to the lines of code: https://github.com/NENA911/NG911GISDataModel/blob/986686da9ae68cdcadf9766cd5943f93969fbbf9/esri_geodatabase/NENA_NG911_Scripts/schema/schema_fgdb_v2.py#L1022-L1029

GIS Data Model specifications:

The current Index 2 values within the schema template for field precision:

Refresher on Field Precision (I won't lie, I had to look it up again...):

Just double checking,

David L.

[tomneer]

My experience is that field precision is not typically defined using INTEGER values and is managed by CONSTRAINT/DOMAIN checks to ensure the domain is enforced per lines 22 - 29 of the schema_fgdb_v2.py

    }, {
        "domain_name": "AddressNumber",
        "domain_description": "The numeric identifier of a location along a "
                              "thoroughfare or within a defined community.",
        "field_type": "LONG",
        "domain_type": "RANGE",
        "values": [0, 999999]
    }, {

This has also been verified in the PostgreSQL

    CONSTRAINT roadcenterline_esn_l_check CHECK (((esn_l)::text ~* '\w{3,5}'::text)),
    CONSTRAINT roadcenterline_esn_r_check CHECK (((esn_r)::text ~* '\w{3,5}'::text)),
    CONSTRAINT roadcenterline_fromaddr_l_check CHECK (((0 <= fromaddr_l) AND (fromaddr_l <= 999999))),
    CONSTRAINT roadcenterline_fromaddr_r_check CHECK (((0 <= fromaddr_r) AND (fromaddr_r <= 999999))),
    CONSTRAINT roadcenterline_nguid_key UNIQUE (nguid),
    CONSTRAINT roadcenterline_pkey PRIMARY KEY (id),
    CONSTRAINT roadcenterline_speedlimit_check CHECK (((1 <= speedlimit) AND (speedlimit <= 100))),
    CONSTRAINT roadcenterline_toaddr_l_check CHECK (((0 <= toaddr_l) AND (toaddr_l <= 999999))),
    CONSTRAINT roadcenterline_toaddr_r_check CHECK (((0 <= toaddr_r) AND (toaddr_r <= 999999))),
    CONSTRAINT roadcenterline_valid_l_check CHECK (((valid_l)::text = ANY ((ARRAY['Y'::character varying, 'N'::character varying])::text[]))),
    CONSTRAINT roadcenterline_valid_r_check CHECK (((valid_r)::text = ANY ((ARRAY['Y'::character varying, 'N'::character varying])::text[])))

If you believe that the integer precisions should be enforced, please bring it up at the next working group meeting. There are as many ways to implement databases as users.

Edit: Fixed bad markdown

[NCT911-DLindsey]

Hey Tom, thanks for the explanation. I hadn't made it to the Domain section yet when I sent that (my apologies).

However, now that you mention the domain constraints, I went in and did some testing with the Esri File GDB template in ArcMap. Turns out, those domain constraints are not being enforced (at least with 10.8.1). The domain constraints list the max value of 999999, but I was able to successfully add/save integer values up to 2,147,483,647 (long int max). It finally tossed an error at me when I exceeded that value. I'm unable to compare the behavior in PostgreSQL.

[tomneer]

Thank you for the check in ArcGIS Desktop. We will take a look at that.

I did run a check in QGIS and receive the following Commit Error, as expected:

[NCT911-DLindsey]

Tom, I did more testing with ArcGIS Pro 3.0.3. Quite the rabbit hole of discoveries for me!

So that specific Pro template domain range honors the 999999 max. It doesn't throw an error, but if a user tries to add a value above 999999, Pro will convert it to 999999. I find it interesting that ArcMap does not honor this the same way Pro does.

Before:

After:

Truth be told, I find that auto-conversion discomforting. I'd rather it yell at us like ArcMap does for having an invalid number. Ha.

I thought I would test this scenario again with precision added in order to study the behavior (we use precision within our Esri enterprise SDEs), but I was unaware that precision is not available for local file geodatabases. My original question about using precision in these templates won't work afterall.

[tomneer]

Thank you for the additional checks. It's always interesting finding the differences between ArcMap and ArcGIS Pro and agree that values should error instead of converting. Regarding rabbit holes, in ArcGIS Pro, this issue could be handled using Constraint or Validation Rules, which would provide a specific error code. However, Attribute Rules do not work with ArcMap.

One of our balancing acts will be determining how many "workarounds" are appropriate for vendor software issues versus just listing them under a Known Issues section. There is only so far back that we can support a software product that has been discontinued.

[jasonhorning]

I would consider this particular issue an Esri Bug. Nothing, as far as I can tell, we're doing wrong but it should be reported to Esri.

[tomneer]

This issue has been noted in the new Known Issues section.