1

I'm working on hatching lines at 500 foot increments, but I've encountered a confusing error.

I have a start number for the stationing and a number that equals the difference between the start number and an even (effectively 0) point. This ensures the numbers that appear on the hatch labels are at the same 500 foot increments as-builts I am referencing. These numbers in the attribute tables all have a decimal digit value of 2, so they're rounded off as appears on the attribute table.

Linear referencing example

One of my routes is hatching just fine. The other route hatching seems to have a strange trailing digit error where it isn't going to the even 500 increment numbers. I have checked the attribute properties and decimal digits are 2. Why does it have more significant digits than what I've set it to?

4
  • The label expression ignores the decimal digit values set in the attribute table, using the actual value instead. (that's a guess, hence a comment) Use rounding function in the Label expression. – Jakub Sisak GeoGraphics Oct 31 '16 at 15:57
  • The ignoring the decimal digit values would make sense if both of the polylines came out with the trailing digit issue, but only the one is. Rounding the label expression works as an alternate solution in the interim. – policy_brain Oct 31 '16 at 17:43
  • There are a myriad of issues with using high precision floating point numbers (including Shape Area, Length, etc.). Can you post the original label expression? – Jakub Sisak GeoGraphics Nov 1 '16 at 20:25
  • esri__measure + [STA_START] STA_START being the attribute in the above screenshot. – policy_brain Nov 1 '16 at 22:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.