Thank you Terry for your response. Let me explain this by an example. If a field (length) is calculated using the calculate geometry function (R-click on the field heading), user will have to choose the unit (see attached). If I receive such data, how could I go back and find out whether the length is in meters, kilometers, feet�?�etc.
There is no way to know from the field itself, and even if the field were named MILES, nothing would prevent the user from calculating feet into all or part of it.
It is true that someone could calculate in other than the name of the field, but in our house, there are only a few that have write access to the field, so that limits the possibility of this being done incorrectly. The only people with write access are those who understand the goals for the data.
My comments are for out of the box configuration of ArcMap and data that is being shared outside of an organization's control to users with no knowledge of your business rules or how those rules are enforced. Organizational business rules can be implemented in house with various degrees of control, automation and difficulty through access control, custom interface design, edit event listeners, feature class extensions, scripts, etc. However, if you rely on the calculate geometry tool exclusively, you cannot be sure that the editors religiously used the tool after editing each and every feature's geometry unless they regularly recalculate every feature (and you know that they are actually doing that). This step is easy to miss and not easy to catch after it is missed except perhaps with SDE geometry field configurations that allow direct SQL access to the geometry through queries.Metadata is the means for documenting and publishing your business rules so everyone can know what they are and how they should be followed. If the original editors want to publish their data (especially outside of their organization), the Metadata helps the end user to determine what the data means so that they can intelligently apply it to solving their analysis needs. If you do not use Metadata, a field name of MILES is much better than LENGTH if those are the units that the business rules require and that will be applied (and frankly it is better even if you do use Metadata, but Metadata still assures the reader that it truly means what it says). Other things like accuracy of the data can be listed in Metadata also, since the use of the Miles derived from GIS data may only be appropriate for planning purposes and not engineering purposes. Use Metadata so that everyone can "understand the goals for the data", not just your trained editors.
You comments are very true. Bottom line then it seems, for the original poster's purposes, is that there is no reliable way to accurately determine the units of a particular length column for every feature in the table short of finding out from the original maintainer of the table what it should be (or metadata if it exists) and then recalculating all features to that unit measure. Correct?
Back form weekend Thank you both for your elaborate clarifications. What I normally do is to indicate the unit in the heading (e.g. �??Length(m)�?�). That�??s if I am the creator of the field. Wouldn�??t be justified if such info is added (by developer) to the Properties window of the field?
Retrieving data ...