The corrections depending in addition to temp c/r etc. are either geopotential and or the orthometric. For navd 88 at the surface. It boils down to gravity and elimination of systematic errors due to the gravity and your level runs not being parallel across the whole run in a simple way of stating. I think that link will help you understand that along with the publication. NOS 34. Now based on you running up and back theoretically if you turned in and set up in same place or close some might state that you eliminated that in a way. Balanced it out. I have heard that before. However what you are doing for a DOT might not require all of that. I have not met many DOT folks that went any further than differences in heights and closure for meeting specs. Probably the lack of understanding or knowledge or it’s was so minimal of change it really didn’t matter for the design and layout of a project. Very similar to say most DOT static surveys or any control surveys I have seen didn’t apply the deflection of the vertical nor there contractors consultants . For horizontal control. Doesn’t mean they are wrong it is just different requirements. I have to try and keep that in my mind often now being on the land surveying side of the house. It’s getting easier for me but when I first started back on private sector side it was difficult in planning surveys as I was trying to account for all of that. Most surveyors here utilize a grid bearing based on the nad 83 epoch whatever and the state plane zone. The accuracy of that coordinate is irrelevant to most. Many will set two pairs with network RTK occupying one BS another and just hold the azimuth or bearing not the distance and traverse along the surface. Others will scale about 0 others about a point on the site. All coordinates still looking like state plane. Is it wrong yes and no. It’s right for what they need on a boundary survey because it’s all relative. To that boundary. I try and make a happy medium. I like to know what my absolute uncertainties is relative to the datum and projection. Then my relative precision for the boundary. I dislike stating a state plane values on a plat that I know are not true state plane. But I am not the one stamping that. If I were I would have the truer state plane values on the few corners required and give the lat long ellipsoid height at a scaled to ground position. Which is usually the height I find is the best overall to make the combined factor work for all lines. Within reason. But this can cause ambiguity as the grid inverse would not match the ground and if another is following me and doesn’t know how to compute the ground to grid values from that information could cause issues. If everyone would say place a lat long ellipsoid height at those same corners then it would be much easier in my opinion vs state plane. It would be easy to compute the c/f along the route. To convert the ground plat distance to grid or ellipsoid and back again. Then any new datum could be re created from the lat longs ellipsoid height of a previous datum. And back to surface. But that’s a different way of seeing things. Grid coordinates are more familiar to work with than geographic coordinates and such. So stick to what the professionals in your area are dousing whoever follows your work can achieve repeat results.
I do not use TBC to process level data (or total station data or RTK for that matter, only for post processed static GNSS).
By the way, dini comes from DI (digital) and NI (Nivellierung, german for leveling).
I wrote a program that reads the dini file and outputs two files...first is a field book type listing:
Most of the points were sideshots in between turns. The i-man enters in the two letter code for each point, and the program adds the 24044 prefix (optional).
The other file created is an input file for Star*Net:
The last number in each line is the distance. I do not adjust between turns, just between points that I want an adjusted elevation on. However, that is an option, to include TP points numbered. Here is the interface for the program I wrote:
It has options for:
1) apply a C-factor if not already applied in the file
2) include the TP's to adjust all TP's (not usually done, see above)
3) rod corrections if using multi piece rods (computed by comparing against invar)
4) lookup point names by station name or GPSID from a points database
5) create an adjustment file for Geolab or Star*Net
6) output in meters (usual) or feet
etc.
I can take a dini data file and have an adjustment done in 1 to 2 minutes.
The above is fine for most projects. If have a larger area, for instance the 130 mile project i mentioned in a different post, then I would use the NGS programs to apply corrections and do the adjustment.