Without knowing the details of your data, this is a guess at what is going on: GeomLength measures using whatever projection you are using, which can lead to strange results if the projection does not provide accurate lengths in your area of interest. If you want to measure accurate lengths regardless of what projection is being used, use GeomLengthGeo, which does full geodetic computations, just like the tracker tool. See the Geom SQL Functions topic for documentation on GeomLengthGeo. See also the discussion and the cautions in the Computed Fields topic. 250m on the tracker is being calculated by that code as 316, I assume meters, as the units of the projection are also meters
Yes, correct. As stated in the Tracker topic: The tracker tool reports total length is reported in the units (for example, feet or meters) used by the coordinate system of the active window, except for Latitude / Longitude coordinate systems, for which distances are reported in meters and not degrees. Bearings are reported in degrees.
The tracker also reports geodetic distances regardless of what projection is used, and not planar/Euclidean distances that are tied to the projection in use: The tracker tool computes distances and bearings using Vincenty algorithms to compute the distance over the surface over the actual ellipsoid used in the datum for the active component. That provides significantly greater accuracy than computing distance over a generic sphere or planar computations. Whatever coordinate system is used for the active component is automatically reckoned as part of the computations.
That's super. The tracker is reporting geodetic distances, that is, real distances over the actual ellipsoid of the Earth, while the GeomLength function reports distances within the plane of the PseudoMercator projection. Lengths measured within PseudoMercator become wildly wrong as you get farther from the Equator, so as you get farther from the Equator there will be a greater difference in lengths reported by the tracker tool and by GeomLength. At latitude 39, as indicated by the status bar in your illustration, the difference is already very significant. If you want to get a calculated field that matches what the tracker reports, that is, accurate distances no matter what the projection you are using or where on Earth you are measuring, then use GeomLengthGeo instead of GeomLength. In MFD 8 I would have just grabbed the intrinsic length field and called it a day...
Ah, but if you wanted accurate lengths for your area of interest you would have called it a day without realizing that you had made an error. Intrinsic fields in 8 are nice, but they depend upon the user using a projection that provides accurate length measurements in the area of interest. If you use a projection that is a poor choice for length measurements in your area of interest, then the Length (I) intrinsic field value reported in 8 won't be the same length you'd measure in real life by surveying. If you use a projection that is a good choice for the AOI, then the intrinsic field value will be accurate. With 9 you can either do it 8style, using GeomLength, for those cases where you want to match something that was done in software that does only Euclidean/planar measurements, or you can do it with actual accuracy, using GeomLengthGeo to get a precise geodetic measurement. Having both is important because there is a lot of software that can't do geodetic measurements and a lot of data out there that was computed sort of accurately using planar computations but with a reasonably good coordinate system for the area of interest.
