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?

Improve this question
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
    Commented Oct 31, 2016 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
    Commented Oct 31, 2016 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
    Commented Nov 1, 2016 at 20:25
  • esri__measure + [STA_START] STA_START being the attribute in the above screenshot.
    – policy_brain
    Commented Nov 1, 2016 at 22:29

0

Reset to default

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.