I'm working up a data sheet format for the network of passive marks I've established in my fair city. I'd like to hear your comments. Is there anything I haven't included that I should? Or vise versa?
That looks pretty good.
I could nitpick - the description and to-reach could be separated if you wish. Also, I think the NGS style for to-reach starts big picture (In Beaverton in the 2700 block of ....) and works down to the small details rather than the vice-versa in your example.
But that's just personal esthetics, not a functional issue.
Thanks, Bill. I'm thinking that in a world where I can be in Iowa, enter an address in Beaverton, Oregon into my phone, and get turn by turn directions with travel time estimates back in 5 seconds or less the old directions from the nearest federal building are unnecessary.
I can’t see the pdf. But I would in this day in time add the national grid designator or coords in a data sheet if yours does not have it. I see where that will become a very easy way to navigate by in the future my opinion. It could be better than an address.
Hey Mr. OK
I would reimagine your vertical datum statements. Personally, I would nix the NGVD but I know that Beaverton and Washington County, among others, are still enamored with it. But since in reality you are computing an NAVD88 orthometric heights and then subtracting 3.514 IFT to derive and approximate NGVD29 value that is how I would state it. Even within the confines of the City that relationship is not constant. I would list the NAVD88 elevation as determined by GNSS observation using GEOID ####. Then list the NGVD29 value listed as derived keeping your note #2. I would also use the NAVD88 values in computing the elevation and combined factors.
As for the description, I agree with your assertion that the big picture to reach is overkill in this day and age. I would suggest a couple of taped distances to hard features to help pinpoint the location once you use your phone to get you within a couple of meters.
Finally, I'd get the City to buy enough monuments to get them stamped with something like 'Beaverton CNTL'. I think anything over 25 gets it done for free.
I would reimagine your vertical datum statements.
My network is constrained by ties to several levelled monuments, and will include more such ties as my network of benchmarks expands. So I think that this is a little better on actual elevations that you may be thinking.
Your comment brings to mind a question - how do you determine an elevation, in whatever datum, on a particular point exactly? Via long duration OPUS observation? Via some other form of GPS observation? Via levelling? If so, what do you select as your "god" point? In my case my goal is not so much to determine NGVD29 values as to match up with the County values and with values of an old (but little known) City network - so as to conform to the elevations in the city library of as-built documents - while detecting and correcting any errors in the 50+ year old network of existing marks.
Conforming to a national datum is nice, but secondary. I really have no use for NAVD88. That statement is a mere courtesy. I expect to use NATRF2022 when it becomes available but early indications are that it will differ from NGVD29 by less than a tenth of a foot in my area.
To that end I selected one of the two NGS monuments with a levelled elevation on it that exists within the city and have held it in my benchmark levelling. When my benchmark levelling network reaches the second I may have to reevaluate. In the mean time I have levelled through about 10 county benchmarks and 20 or so old city benchmarks and have found the average difference between my new values and the record values to be less than 0.01' and the standard deviation to be about 0.06'. This includes 3 or 4 outliers which if tossed would cut that SD down to about half that. So I'm getting really good conformity to record benchmarks.
@norman-oklahoma In my opinion it doesn't matter what you deem to be the god (or gods) of your control network, so long as you thoroughly document it. To that extent it wouldn't be a bad idea to have an additional document that details the controlling elements of your network and how you fit with record control- vertical or otherwise.
Speaking of NATRF2022... Are you using time-dependent vector transformations?
Your datasheet is good, and I commend your use of pictures and the concise information you present. Assuming you expect this datasheet to be used by others in the future (otherwise why would you bother) I have recommendations to ensure the information will be used properly and be “updatable” into the future. I also agree that your use of a limited local definition of the station location is fine. While I had great fun writing the classical C&GS/NGS descriptions “back in the day” in today’s world as long as you have a relatively decent horizontal position and photos there’s no need for anything else. This is a very ambitious effort and I applaud your desire to provide good local control information.
Your position and heights show an excessive number of significant digits. Showing latitude and longitude to five decimal places resolves positional differences (precision) to the mm level. No need to go any further. Plane Coordinates and ellipsoid height should be realistically shown to two decimal places. That is perfectly legitimate as long as you also show and are very specific about the actual positional uncertainty (accuracy) of each component and show if that is at the 1 sigma (68%) or 2 sigma (95%) confidence level.
Plane Coordinates and heights should always be shown with their units of measure. I assume that since these data are in Oregon they are International Feet, but there should be no assumptions. Be specific. I stress this in virtually every workshop I give.
Your rationale for providing the NGVD 29 height is sound but as John-Putnam noted you should also show the NAVD 88 value, additionally since there has never been a geoid model related to NGVD you should specifically note how that value was determined. Were I creating this, I’d be inclined to give NAVD88 first, since there is a precedent for relating that vertical datum, via geoid model, to GPS techniques, and then to derive the NGVD29 from that, explaining it’s done by transformation.
Also noted by John-Putnam you should show the geoid model you used. In this case I’m assuming (never a good thing) its GEOID18 which would be -75.243 ft (-22.934) with a two sigma (95%) confidence of 0.11 ft (0.035 m) as provided by the NGS tool -- https://geodesy.noaa.gov/GEOID/GEOID18/computation.html . I see this station on the NGS OPUS Shared Solutions has a peak-to-peak uncertainty of 0.008 m (0.03 ft) so at the very least this would indicate a reasonable estimate of the NAVD 88 height of .036 m (0.12 ft) as an example. Additionally, the OPUS Shared solution shows an ellipsoid height of 181.79 ft (55.411 m) yet your datasheet clearly states that the ellipsoid height is NAD 83 (2011). If you believe you’ve computed an NAD 27 ellipsoid height (mind you C&GS/NGS never published any such elements) then you should clearly state what you’ve done on this product and what you expect its uncertainty would be.
Vertical Data – I have an issue with you NGVD 29 height. If your NAD 83 (2011) ellipsoid height is 178.277 ft (54.339 m) then the GEOID18 height is -75.243 ft (-22.934) and the corresponding NAVD 88 height would be 253.52 ft (77.273 m) +/- the combined uncertainty of the ellipsoid height and the geoid height. Using the NGS Coordinate Conversion and Transformation Tool (NCAT) I get a transformed NGVD 29 value of 250.013 ft (76.204 m). Are you absolutely sure the local bench marks you used are NGVD 29? It’s suspicious to me that my computation of the NAVD88 height exactly matches your 29 height.
Plane Coordinates and ellipsoid height should be realistically shown to two decimal places.
I routinely quote 4 decimal points in my coordinates so that inversed bearings between them will be consistent to the second, for the distances that are typical in lot boundary lines. I understand that 4 decimal points is absurd for point positioning precision. IMO the real absurdity is the common statutory requirement to quote lot line bearings to single second precision in Records of Survey. But point taken, I should modify my usual practice in this instance.
As for the ellipsoid height vis a vis NGVD29 - I'll be very happy when NATRF2022 is finally released and I can just use that. In my area the difference between '29 and '2022 orthometric is expected to be almost trivially small. My network is constrained to points with levelled elevations. The levelled elevation adjustment is minimally constrained to just one NGS monument which has both '29 and '88 elevations reported, so the difference between the two will remain equal throughout. The ellipsoid Ht I report is a function of the orthometric elevation and the Geoid18 separation - as opposed to the orthometric elev. being computed from ellipsoid ht and Geoid sep. I know that I could determine the NAD83 ellipsoid Ht, and the orthometric '29 elevations and compute custom Geoid Seperation values, but this would be strictly an academic exercise that I prefer to avoid. I have no call for NAVD88 elevations here - only the DOT uses them.
I appreciate your comments. See you at PLSO tomorrow!
Speaking of NATRF2022... Are you using time-dependent vector transformations?
I will recompute the measurements - presuming that is appropriate. If it isn't I'll remeasure the network. I'm sure that I'll check that vs. a transformation, but I won't rely on it.
I will recompute the measurements - presuming that is appropriate. If it isn't I'll remeasure the network. I'm sure that I'll check that vs. a transformation, but I won't rely on it.
For sure. I've run time-dependent transformations through TBC with a couple of my longer-spanning networks (~10-20 years on average), and have had fantastic results over and over. Your mileage may vary, but I wouldn't do anything else anymore. Tried it with the NSRS, CSRS epoch 2017.50 (cross-plate a couple times, too)... it simply works.
I can respect your needs to stay on NGVD, especially if you are planning to go to new system when it comes online next year. That being said, how did you develop the GEOID model relating NAD83(2011)[Epoch 2010] ellipsoidal heights to NGVD29 orthometric heights. Are the provided ellipsoidal heights truly on based on GNSS observations or were the manipulated to force a geoid developed for NAVD88 fit NGVD29. Back in the days before geoid models were readily available, you could create and massage them in TrimNet. I would definitely add a note describing your procedure. An easier way may be to record a control survey with the County describing your methodology in detail and then reference said survey narrative on future data sheets.
As for NAVD88, I would either leave any mention of it off the sheets or include the GNSS observed value along with the geoid model used.
See you in Salem.
As for NAVD88, I would either leave any mention of it off the sheets
That's the way I'm leaning right now. BTW, I believe that NAVD88 will disappear, around here at least, like a fart in a windstorm once tools to establish NATRF2022 elevation with GPS are available. No Oregon or Washington agency other than ODOT and WsDOT uses '88 AFAIK.
Geoid18 works well with NGVD29. Any Geoid model works very much same with 29 as with 18 when it's applied to the elevation, not the ellipsoid height.
If I want to use NGVD29 (doesn't happen much anymore) I set a base on the NGVD29 control and start it with that elevation and the Geoid model applied. It then calculates the ellipsoid height, which will be 2.5' lower than if the 88 elevation is used. As long as I stay within a few 10s of miles from that base I will hit NGVD29 as well as I would if I were surveying to the 88 number. Beyond 20 miles I might get 1/2 tenth of a foot because the difference between 28 and 88 will start to shrink or expand.
I don't use NGVD29 because FEMA "updated" to NAVD88 and it controls most everything elevation wise. I doubt we will get new flood maps anytime soon, so even if NGS changes to NATRF2022, NAVD88 will be predominantly the go to for most areas I work in.