Change request for Localisation

joelbladen · February 9, 2024, 9:10pm

A bit of background

Where I am, our jurisdiction functions between both GNSS/Grid and Terrestrial (for height) which makes (I think) the difference between Geoid Heights and Leveled heights deviate between each other (depending on their lineage). This is fine, but when a state control mark has already had a GNSS occupation updated on it, only the Ellipsoid height can be updated, not the leveled height (unless, I think, multiple occupations, minimum number of hours, processing, submission, acceptance, etc are performed over multiple days, not sure).

This is where I’d like an update (or warning maybe when doing so?) when it comes to using Global Points as part of Localisation and not just Local points. Using the Global input means I can input the published LLH of the mark (which is on the same datum, just different units) and the correct Geoid Height gets calculated for the mark. Otherwise I’d need to calculate this through another program which I couldn’t do in the field, to then do a Localisation.

Is this something that could get accepted? Does any one else have any feedback on this?

Joel

Current version 9.11 on iOS

michaelL · February 10, 2024, 2:01pm

Interesting localizing global. In my experience this is an oxymoron as we are using localization to turn global (geographic) data into a local (CAD) grid. Throwing a geographic point in there would completely destroy the network. What kind of work would this be for?

joelbladen · February 11, 2024, 10:16pm

After thinking about it some more, I suppose in my case it could be done one of two ways.

I am fortunate that my datum (at the time) matched WGS84, so inputting global parameters get converted into the local datum with the geoid height.

My issue mainly is not being able to input an ellipsoid height when entering in a point, so figured it might have been a way around it if you knew what you were doing, by allowing inputted global co-ordinates to be accepted through localisation.

The reason for this is for published survey control in my state (I call them PSM’s). Seeing it started from traditional methods, each mark had a recovery plan, some additional info and a height (through various orders from A to E). You know how it is, things evolve, information gets added, but some things get stuck in the past (right or wrong). In this case, the heights remain in the old system, but the mark now has an E/N/Z, IF, someone has statically observed long enough to get the errors down enough that it can be used as a datum. However, not all marks if they are a GPS Datum, correlate to the published height of the mark, so they are only really E/N accurate (usually <16mm @ 95%). They also allow the Ellipsoid Height of this observation to be published (same deal, usually <30mm @ 95%), but it does not override the local height that has been done using terrestrial methods in the past.

Last week I had a mark that the 95% Ellipsoid Height (when converted on geoid) was 40mm lower than the published height, but when I observed it, it was an additional 60-80mm lower.

I know Geoids aren’t perfect, but at least I could have then localised my surrounds to suit the site.

I should add, usually there are at least 1 or 2 PSM’s that are tied to each cadastral plan. So by the time you get a few of them, re-calc them in CAD (so Ground), then go out and establish your control.

This is where I feel being able to at least use the ellipsoid height for known objects would be useful (as an option to geoid height), otherwise accept the global coordinate as part of localisation.

Hope that makes sense?

ruth.bongon · February 19, 2024, 9:50am

Hi @joelbladen,

Apologies for the radio silence here.

We do not support points of global origin as control points in calibration. So, adding LLH points as control points is not possible. However, you can do the following as a workaround:

Add the LLH points to a temporary project with the correct target CS with the correct geoid applied.
Export the calculated local coordinates for those points as a custom CSV. The heights should be converted to orthometric height.
Import these local points (Easting, Northing, and Elevation) to the main project.
Use these points as control points for calibration. If the Easting and Northing of these new points differ from the official Easting and Northings of the marks, it is still possible to use the official points for the horizontal component and the converted points for the vertical component of calibration.