How significant are the errors cause by coordinate system transformation. LEts Say we have System 1 and System 2.
Scenario 1. I measure a point based on System 1 benchmarks and get its location, i then performa a transformation and make it a System 2 point.
Scenario 2. I measure the same point this time using system 2 only benchmarks and get a true System 2 coordinates.
How should these reading differ and are they significant?
I would think it depends on which two systems if your talking 27 to 83 it could be a lot
Largely depends on method of transformation, if it isn't rigorous, all bets are off.
Transformation here is construed to mean two different datums, if you are just projecting NAD83 LLH for instance to any other geodetically defined grid system such as SPC, UTM, properly defined LDP, etc., then there is zero loss of accuracy.
SHG
It depends on how accurate each single system is, how accurately you can determine the location, and how accurate the transformation formulae are.
You could estimate quite easily IF you had a reasonable idea of the values of those error sources.
therock003, post: 407050, member: 12282 wrote: How significant are the errors cause by coordinate system transformation. LEts Say we have System 1 and System 2.
Scenario 1. I measure a point based on System 1 benchmarks and get its location, i then performa a transformation and make it a System 2 point.
Scenario 2. I measure the same point this time using system 2 only benchmarks and get a true System 2 coordinates.How should these reading differ and are they significant?
I know the following might look like a classroom lecturing, but I thought I would shed light on the topic.
There are three terms that many use interchangeably wrong:
A coordinate system, a mathematical surface, and a datum.
The coordinate system, as the name implies, has to do with how one expresses the coordinates of a point. In a 3-D space, for example, XYZ and Latitude/Longitude/Height are two different coordinate representations (systems), Cartesian for the earlier and curvilinear for the latter.
A mathematical surface is where calculations take place. For small areas, a flat Earth model suffices. In this case, planimetric trigonometry and geometry can be applied without introducing significant calculation inaccuracies. For larger area, however, one has to use a more precise representation of the Earth's surface; sphere, ellipsoid, and geoid are good candidates, with the latter being measurable only!
A datum is a way of creating a reference frame with physical monuments. To define a datum, one needs a mathematical surface and a coordinate system on top of the physical monuments. Datums are never exact; they can only be adjusted to fit measurements.
Now, people use transformation and conversion interchangeably wrong. Conversion happens between coordinate systems, e.g. to convert Cartesian coordinates to curvilinear coordinates. Transformations take place between datums, e.g. NAD27 and NAD83. While conversion between coordinate systems can be exact, transformation between datums can be precise at best. Transformation between datums is as good as the definition of the datums themselves.
Another topic that also needs to be clarified here is MAP coordinates through projection, which I will leave to another lecturing opportunity!!
Sent from my iPad using Tapatalk
Ok guys so let me be a little bit more Specific. I work in Greece and the local Projection System is GGRS87, with its 2 realisation named Hepos and Non-Hepos.
GGRS87 uses the GRS80 elipsoid (almost identical with the the WGS84).
-Non-Hepos are old benchmarks measured by the military back in 87, which means possibly lots of errors (tectonic plate movement, legacy surveying techniques, damage caused by external causes etc). So even if i do GNSS resection and localisations, the precision is unknown and i'm not sure i can trust it.
The datum transformation is a simple 3-parameter translation (DX,DY,DZ).
-Hepos is a VRS solution that implements the ETRS89 actualisation is more precise, uses a 7parameter (Dxyz,Rxyz,Ds) and a shift grid transformation and is current modern and up to date. But in order to use it you have to pay subscription fees and have mobile data plan or do post-processing on the office.
Since the Hepos realisation is more modern and precise i need to set up my base using its parameters but since i dont have the Hepos plan what i consider doing is this.
Set up my base using the Non-Hepos known benchmarks and establish non-Hepos coordinates and then apply a non-Hepos to Hepos transformation. And then having Hepos coordinates for my base and use the 7-parameter Hepos projection values on the data Collector.
therock003, post: 407124, member: 12282 wrote: Ok guys so let me be a little bit more Specific. I work in Greece and the local Projection System is GGRS87, with its 2 realisation named Hepos and Non-Hepos.
GGRS87 uses the GRS80 elipsoid (almost identical with the the WGS84).
-Non-Hepos are old benchmarks measured by the military back in 87, which means possibly lots of errors (tectonic plate movement, legacy surveying techniques, damage caused by external causes etc). So even if i do GNSS resection and localisations, the precision is unknown and i'm not sure i can trust it.
The datum transformation is a simple 3-parameter translation (DX,DY,DZ).
-Hepos is a VRS solution that implements the ETRS89 actualisation is more precise, uses a 7parameter (Dxyz,Rxyz,Ds) and a shift grid transformation and is current modern and up to date. But in order to use it you have to pay subscription fees and have mobile data plan or do post-processing on the office.
Since the Hepos realisation is more modern and precise i need to set up my base using its parameters but since i dont have the Hepos plan what i consider doing is this.
Set up my base using the Non-Hepos known benchmarks and establish non-Hepos coordinates and then apply a non-Hepos to Hepos transformation. And then having Hepos coordinates for my base and use the 7-parameter Hepos projection values on the data Collector.
Can you "get-on" the Hepos values without the plan using static?
That's how I would do it.
Rather than transforming from older control.
I would think there is some way to do that.
There arent any known physical benchmarks scattered that use Hepos-derived coords. I would have to locate a point near my location that was obtained by a surveyor, and if you take into account all of the errors associated with it (unknown origin RTK, static type of solution, etc) i would carry over the same amount of error i guess.
therock003, post: 407145, member: 12282 wrote: There arent any known physical benchmarks scattered that use Hepos-derived coords. I would have to locate a point near my location that was obtained by a surveyor, and if you take into account all of the errors associated with it (unknown origin RTK, static type of solution, etc) i would carry over the same amount of error i guess.
There must be a European version of CORS that can be accessed, that's the way I would go.