Determining an unknown projection?

[MarkLeander]

I have two versions of data from the same set of points, however the points are not aligned with one another using the same projection system for both.  I have determined one set of data to be "correct" in the expected coordinate system.  I believe the problem is that the "errant" data results from the mishandling of the projection system.  Is it possible to take the two sets of x/y's and the correct projection system and determine what projection system must have been mistakenly used? If this can be determined, I might be able to re-project the errant data so that it aligns with what I believe to be the "correct" data.

[DanPatterson_Retired]

Do you have candidate projections that might have been used?

What is the format of the data? shapefile? file geodatabase?

Any history left with the project? and was PRO used exclusively?

[MarkLeander]

Dan,

Thanks for responding. The dataset is actually a 2D seismic survey acquired in 1981in onshore Portugal. A number of these old lines have been recently reprocessed and new versions created. The seismic processors are confident that the x/y points they supplied in the data headers are in the ED50/29N projection (EPSG 23029). For reasons difficult to explain, every 10th location is precise - in between they are interpolated locations (ie straight segments with inflection points every 10th).  I have determined that the original data are properly located because these inflection points fall on (or VERY near) roads - where the vibroseis trucks would have been positioned. I made this comparison in ArcPRO using the World_Topo_Map in a layer projected with ED50/29N (incidentally, I'm aware that (some) roads may have changed in the last 37 years - accommodating that with my logic). In the same view the reprocessed data are offset from the "correct location" by 150-170 meters (using simple trig) - at locations vibroseis trucks could not have reached.

In an attempt to figure out what may have happened (assuming that somewhere along the line someone miscoded the projection system), I've played around with the data loaded in my seismic interpretation platform (SeisWare) assuming a different original projection system transforming the locations to ED50/29N. Most result in locations so far afield that they are dismissed.  The closest I've gotten is calling the data WGS84/29N, but it still doesn't overlay what I think are the correct locations and are actually further offset than the reprocessed locations.

To your knowledge is there any kind of a widget that would allow me to input the correct x,y,crs and errant x,y to calculate what projection system might have been (mis-)used? Sort of a reverse transform that solves for projection system?

Unfortunately the seismic interpretation platform isn't that GIS-robust all around. The data loader allows me to define input and output projections (CRS's), but when I export the locations as a shape file, the CRS doesn't come with it (though I know it to be ED50/29N so imported "unprojected data" into an ED50/29N ArcMap project is OK.

I hope all of these details aren't overly confusing - I recognize that you are (apparently) a helpful GIS-guy, not a geophysicist. I am also aware that I'm working on the "back of an envelope", but am trying to get my arms around location uncertainty for my client, not producing an EXACT solution.

Thanks for trying to help,

Mark

[MarkLeander]

Dan,

Further to my earlier tome ... the fact that the original data were acquired in 1981 means that the original surveying would not have 'enjoyed' the WGS84 datum. If this were in North America, I might have assumed the NAD27 datum was used. However this being Portugal, a bit of quick research tells me the most likely candidate would be "Datum 73" or several slight permutations. None of these worked - not even close. I tried the WGS84 datum to cover the "simple mistaken assumption" someone in the processing center could have used.

Lastly it occurs to me that such relatively small-scale differences could arise out of the differences between different transformations that might have been applied by the surveyors or processors, or that are employed in the seismic or ESRI software. Because I have a (largely disused) geospatial gene, I'd prefer to think the ESRI transforms are most precise but I have no direct knowledge of the source of transformations used by others.

Could this last bit be the problem to your estimation?

Mark

[DanPatterson_Retired]

I will defer to Melita Kennedy‌ who is the resident expert in coordinate systems and transformations.  I suspect you may have to wait until you get a response since you have already investigated the datum issue.  Going back further than 1973 might be a possibility but I have no direct knowledge in that area.

[MelitaKennedy]

Hi Mark, 

There are some online tools which will take a point or extent and suggest what projected coordinate system it might be using, but I don't know of one that would try to figure out blunders. 

The amount that the points are offset does look like a GCS/datum issue. There is a chance there could have been DMS or degree decimal minute data was mistaken for decimal degree data (or vice versa). 

WGS72 could have been used rather than WGS84, but they differ only by a few meters. 

I took a random point in Portugal (40 -8) and transformed them using EPSG:6189 then projected both to 32629 (WGS84 UTM 29N) to get a feel for the offset assuming someone didn't correctly transform the data:

F:\arcgis\arcsde>forward 32629
Esri Projection Engine version 10.6.0.8000
-7.999086890966467 40.00081355417707
-8 40
^Z
585437.3925654054 4428327.238551771
585360.4618427715 4428236.064633091

They differ by around 119 m.

I then tried the same thing with ED50 and EPSG:15964

F:\arcgis\arcsde>forward 23029
Esri Projection Engine version 10.6.0.8000
-8 40
-8.001403182178615 39.99876783870072
^Z
585364.3213782879 4428311.984619451
585246.0698706302 4428173.876215876

These differ by around 181 m, so that does fit with the offsets you're seeing. A point (at that location) in ED50 moves southwest when converted to WGS84/ETRS89. You can look at your data to see which way it should move and that may help you figure out what happened. Assumed to be in WGS84 when it was really ED50 or opposite? Etc.

Hope this helps,

Melita

[MarkLeander]

Thank you Melita - that helps.  I've investigated further and find that I have two lines are possibly mis-located.  The map in the seismic application (Project CRS: ED50/29N) shows the new processing to be offset from the original. I have determined the original to be correctly located. One of the two errant lines provides an opportunity for more direct analysis. I find that the errant data is offset from the correct locations by an average 171m (northeast) ... in other words it would align better if it moved 171m to the southwest. Assuming, the locations in the headers of data to be loaded into the seismic mapping system (destination ED50/29N) are in another projection, can you guess what projection I could use as input to be transformed into the project CRS that would result in a move to the southwest by this order of magnitude? Everything even close to reasonable that I have tried moved things farther to the NE.

[MelitaKennedy]

(use a copy, of course!)

Unproject the points to ED50. Transform it to WGS84. Redefine it as ED50 and project to ED50/UTM 29N. That might do it.

[MarkLeander]

I thought your solution would work, but I wonder if I am executing it correctly?

   1) PROJECT original ED50/29N to GCS ED50

   2) PROJECT new GCS ED50 points to WGS84/29N

   3) DEFINE projected points in WGS84/29N to be GCS ED50

   4) PROJECT points redefined in GCS ED50 to ED50/29N

The first time I tried this, the resulting points had been corrected just a little too far to the SW (but a lot closer than they had been). I questioned whether or not I had followed your recipe correctly, deleted the created files and started in again. Ever since then, I've tried several times and while each steps executes without issue, the points don't move (or move to the other side of the moon!) I must be doing something wrong.