3

Is there a way to transform a shapefile's datum from WGS 1984 to NAD 1983 in QGIS 2.18.0?

In the picture I have attached, the green dots are points that were collected in the field using a Trimble R2 receiver, which by default, collects coordinates in WGS 1984. The red dot is a benchmark with known GPS coordinates and is projected, along with the rest of my shapefiles in NAD 1983 StatePlane Virginia North FIPS 4501 Feet. Optimally, those green points would fall directly on top of my benchmark, but those points fall about 3.5 ft north of my benchmark. I believe this is due to the fact that they are projected in WGS 1984, while the rest of my shapefiles are in NAD 1983.

So far, all I can find in QGIS is ways of re-projecting the CRS. I believe what I need is a datum transformation. I am aware of the "Default datum transformations" tab within the QGIS settings, but if this is the solution to my problem, I cannot figure out how to use it.

enter image description here

  • 1
    I have recently dealt with a very similar problem, and something that you need to get straight is that "For surveying purposes, original WGS84 is identical to NAD83 (1986)." confluence.qps.nl/pages/viewpage.action?pageId=29855173. The only transformation between WGS84 and NAD83 that will have any significance is if you are working with really old GPS data and you want to see where the point should be now because of tectonic plate movement, which if you are looking at data from 1994 that's only a 0.7m shift which is well beyond the accuracy of GPS data from then. – TJ Rockefeller Mar 23 '17 at 19:57
  • Maybe related: gis.stackexchange.com/questions/122630/… and the comments by @mkennedy. – AndreJ Dec 4 '17 at 7:08
3

You may try to perform these steps:

  1. Create new QGIS blank project;
  2. Only load the shapefile which has the WGS84 as CRS;
  3. Right-click on the loaded layer from the Layers Panel and click on Save As...
  4. From the dialog, choose a name for the output layer and set the desired CRS;
  5. Create a new QGIS blank project and load both layers: they should be aligned.

I tested this procedure and it works well when dealing with projected CRS, but it could work also for different datums (I hope not being treated as a heretic after this assertion!)

  • 1
    I tried this method and got the same result as the pic in my original post--3.5 feet north of the benchmark. Thanks for your response! – Cayden Mar 27 '17 at 20:21
3

As long as everything is configured correctly on your GPS receiver, and it was clear skies, and there weren't any buildings obstructing your receiver, then I would say that the points you collected from your receiver are most likely in the correct spot. I am curious where you got this benchmark location from. Is it something you collected earlier? Is it data from some government agency? Is this benchmark data rounded at all? Is there a margin of accuracy for the benchmark data?

If the benchmark data is definitely correct, then I would ask when was it collected? If it was prior to about 2010, then maybe you do need to do an epoch transformation on your benchmark location to correct it to current GPS readings. Epoch transformations are a lot more complicated than a regular CRS transformation and is something I admit to know nothing about. Very few people really need to be concerned about it because the shifts are so small (usually less than a meter and only for really old data). Below is my best explanation as to why it is necessary.

When you collect in WGS84 it is the CRS defined by http://epsg.io/4326, and that never changes. This CRS is practically identical to NAD83 http://epsg.io/4269. If you do a transformation between 4326 and 4269 or any projections based on 4326 or 4269 (The StatePlane mentioned in your question is based on NAD83 or 4269) you will see no difference in your coordinates.

Where there is a difference is when you start talking about realizations of WGS84 or NAD83 which you can think of like snapshots. The realizations of WGS84 are defined by names like G730 or G1762 which stands for GPS and the number is the week number after GPS went into service, so G1762 is a snapshot to define transformations for GPS data collected around 1762 weeks after GPS went into service, so G1762 has transformations that apply to GPS data collected around 2005.

The reason they take these snapshots is because WGS84 is a theoretical datum defined around the earth based on center of mass (that's what defines the orbit of the GPS satellite array), but stuff on earth is slowly shifting around on tectonic plates. They take snapshots and define transformations so you can take GPS data recorded around those epochs and correct them to current WGS84/NAD83 readings. NAD83 realizations can be more useful for data collected in the US because it is corrected for movement of the tectonic plates affecting North America using CORS whereas the WGS84 realizations are corrected to points in space where the GPS satellite array is located relative to Earth.

Sorry for the really long post, but the main point is that you are most likely chasing your tail if you think the difference is because of WGS84 vs NAD83. I would focus more on conditions and configuration of the GPS receiver and details on the benchmark GPS data.

  • The benchmark data we are using was taken directly from NOAA. We are using the GEOID12B benchmarks for the whole US. Here is a link to the GEOID12B homepage: beta.ngs.noaa.gov/GEOID/GEOID12B And here is a link to the readme file for it: beta.ngs.noaa.gov/GEOID/GEOID12B/g2012Brme.txt – Cayden Mar 27 '17 at 20:34
  • The benchmark in my QGIS map shows it being about 5 feet from the curbside, which is the gray triangle in the original image on my post. I know this roadside measurements should be taken with a gain of salt, but 5 is about right for where the benchmark is actually located in the field. The benchmark is certainly not 1 foot away from the road as the Trimble data would lead me to believe. So I have a case where everything in my QGIS map, which contains shapefiles from at least 3 different websites, lines up very well--all except for the Trimble data. This leads me to believe it is a datum issue. – Cayden Mar 27 '17 at 20:40
  • 1
    @Cayden I'm not familiar with GEOID12B data and how to use it, so I will assume that everything was extracted correctly, and based on what you are saying you sound fairly confident in all of your data except for the Trimble data, so what I originally said I think still applies. If everything is lining up except for the Trimble data, then I would look into ambient conditions and configuration of the GPS receiver. Have you collected this same point on different days or with different receivers? – TJ Rockefeller Mar 27 '17 at 21:21
  • @Cayden I had another thought about this issue. How are you determining the location of the benchmark data? is there some physical marker on the ground that indicates the location, or are you basing the location on satellite imagery? If you are basing the benchmark location on satellite imagery you need to take into account the horizontal accuracy of satellite images. satimagingcorp.com/satellite-sensors/pleiades-1 Pleiades currently one of the most accurate, and it only claims a 1 meter accuracy IF corrected with ground control points. – TJ Rockefeller Apr 12 '17 at 13:10
1

You can re-project your Data or layer by selecting processing from the toolbar of QGIS, then select "tools", It will give you new window in your right hand side.. Now here you may decide either to use the searching box by typing "reproject" or Go direct to QGIS geoalgorithms>Vector General tools>Reproject....

  • I was unaware of the reproject tool--I had always just done a save as to reproject my files. Thank you for your response and opening my eyes to this. This method returned the same result as what I had before. – Cayden Mar 27 '17 at 20:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.