Currently, all COGO distances are stored in the units of the parcel fabric's projection. That's a good thing, and I don't suggest changing that.
However, there are plenty of boundaries that are defined as having different length units. I can use things like chains, rods, yards, and meters to enter my lines via the Traverse tool, but I have no way of retaining that kind of information.
On parcel features, there is a "Stated Area Unit" field, which is great, as some parcels are defined in terms of acres, and some in square feet. Reflecting the legal area as recorded in the associated document.
What I'd like is the same thing, but for line features. Then I could show that "this line's distance is measured in chains / rods / whatever".
Bonus points if an attribute rule could automatically populate the COGO field with the default unit equivalent multiplied out, but that's not strictly necessary.
We will always store the COGO dimensions in the units of the spatial reference. When a parcel fabric is projected, we account for any difference in the unit of the spatial reference.
Nothing prevents you from adding another field called 'DistanceUnit' and account for it as part of the label expression (Arcade).
I guess we need to see if this is important to many organizations.
I am planning to add the field myself as you describe. I just think it would be useful to have, similar to how we have "stated area" on the polygons in addition to the areal measurement from the spatial reference.
I can say that this is important to BLM. We have already added a record distance unit field and try to keep it populated. But if the field were able to be populated from the traverse tool, edit constraint windows, or even from the parcel record (this one could already be done using attribute rules) that would be nice to not have to micromanage it.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.