ORD CE 2021 R2 - Cross Sections - Grid Annotation & Annotation Units Trouble Shooting & Feature Requests

Hello,

I am looking for some specific help with a cross section grid annotation issue that my coworker and I are experiencing. We have both recently transitioned from V8i to ORD CE 2021 R2 and have been scouring the forum (and google) for specific information on cross sections and annotation. We have explored this helpful link:  Cross Section Point Annotation Troubleshooting  and watched all the youtube videos on ORD cross sections (I have some feature requests at the bottom - if anyone reads this post an knows how to execute the desired outcome in ORD CE please let me know)

- TLDR of the issues: The cross section grid is annotating itself above the minimum elevation of the data contained within the 3d- model and the units (and width / height) of the grid annotation is ~3x larger than it should be (along with the named boundary size being 3x large than specified)

(1) The "Cross Section Grid Annotation" issue:

- My coworker and I are on two separate projects but both are in imperial units. We're working from an ORD projectwise environment whose job is also in imperial units (TxDot based if matters). Our previous project was metric, so both of our guesses is that we're self inflicting the "id10t" error since no one else on the internet seems to have this issue.

- I experience this issue when cutting sections from a txdot seed file without using any corridors; my co-working has tried the generic bentley seed file using corridors and also experiences this issue. 

- I don't know if there is anything else i can add other than the civil labelling tool is also recognizing the elevation of the terrain differently from the 3d model as if it was in metres

(2) - We have checked the design file settings (linear units showing feet, slightly confused at why the advanced settings have meters)

- The best part of making this post is that i changed the advanced settings to read feet and doing that resolved the horizontal grid spacing not matching the dimensions (but the vertical spacing is still wrong)

However the elevations are still being scaled incorrectly. You'll notice that the civil labeller is showing an elevation of "6599.56'"  below the bottom grid axis which is showing 6530 feet.

(3)  The next issue is that the named boundary was set to +/- "30" in the setting and the named boundary that was output is measuring 98.452 on either site; meaning it converted from metres to feet. 

                * But wait! The grid annotation has taken that 98.452 named boundary offset and put the grid at a -300 offset (which is confusing because 98.452 m = 323 feet)

- Lastly, the correct elevation for this section should be in the 2150 to 2175 range which is being recognized correctly in the 2d and 3d views

We have also checked the models units and set them to feet

Any help on the units would be appreciated issue would be appreciated, I suspect there is something silly that we're both missing - we're just exhausted trying to find it.

Lastly, regarding some features of ORD CE;

- Is there a replacement tool for automatically labelling the depth? In V8i I had ~ 100 km of pipe depths to label from invert to a surface. I created a section label that would provide a nicely formatted depth label between two known features. Is there a way to utilize the civil labeller in this fashion? For example, reading the elevation of a profile and measuring the distance to another feature? In my case I had two alignments, one at the top of pipe and one draped over the surface. I just read the 2022 release notes, and it sounds like maybe this is a new feature

- Given that named boundaries have completely changed the section tools, is there a new way to incorporate sections that have deflections? I know they can be rotated for skewed sections and such, but is there a way? could this be logged as a feature request? This was one of the most powerful parts of sections from V8i in my opinion (being able to cut a single section over a large drainage network to understand interactions with other parts of the model)