After a few experiments, it appears that Carlson Survey (I'm using 2023) exports KML/KMZ files from my drawings with NAD83 lat/lon coordinates, and this because I work in NAD83-based state plane coordinates.
My drawing and coordinate files in Carlson Survey are in NAD83 SPC coordinates (various states & various zones). My state plane coordinates are based either on OPUS solutions [recently using NAD83(2011)(Epoch 2010.0)] or RTN off the local CORS network [using the realization of NAD83 the CORS stations are using I presume.]
It's my understanding that KML files use coordinates in some recent realization of WGS84, and apps that read the KML files assume the coordinates are WGS84 (again, a recent realization) and not NAD83. So there's a slight discrepancy between what Carlson Survey is exporting and what the apps using the KML files expect. The apps that I use with the KML files are not survey-grade, so I'm not complaining, I simply want to confirm my understanding here.
I primarily use the KML files to give to non-surveyor users to roughly find things in Google Earth and other apps on their phones. (Land conservancy preserve managers are tasked to go check on fences, gates, trail cams, etc.) I also use the KML files exported from deed plots to go scouting for monuments.
Yes, none of this really matters, as NAD83 and WGS84 (recent realizations) are only a few feet apart, which is well within phone GPS errors and probably Google Earth image registration errors.
I want to be sure I understand things somewhat correctly. If I'm approximating things, that's fine, though I do want to know what I'm approximating.
---
It also appears that when I use Points->Adjust Points->Coordinate Transformation, Lat/Lon to Lat/Lon, NAD83 to WGS84, that no transformation is applied, the Lat and Lon in decimal degrees are identical to 8 decimal places (well 10 and 11 places counting the whole degrees) in NAD83 and WGS84.
As far as I can tell, there is no setting in Carlson Survey to specify the realizations of NAD83 and WGS84 used for the conversion, so perhaps Carlson is using the 'original' realizations when the datums were virtually identical?
For all of the above (KML export and Coordinate Transformation), in Drawing Setup I have "Grid" chosen for System, Projection set to "State Plane 83", and Zone set appropriately for the state and location I'm working in for that project. I use reasonable elevations and GEIOD18. I've tried setting the "Lat/Lon Datum" to both NAD83 and WGS84 with no change in results.
Cheers,
Tony.
It is my understanding that Google Earth does NOT use WGS84.
It uses a bastardised version thereof called Spherical Mercator - the EPSG code is 3857. You can check the details at epsg.io https://epsg.io/?q=3857
They are very close to the same thing, especially near the equator, but the distortions become more obvious as you move further North or South.
As far as I can tell, there is no setting in Carlson Survey to specify the realizations of NAD83 and WGS84 used for the conversion, so perhaps Carlson is using the 'original' realizations when the datums were virtually identical?
Null transformations are usually the default because it's customary to enter a base position, or a control point position, in NAD83.
I can't speak for Carlson, but some packages will allow for transformations.
For instance, Trimble designates Global and Local geodetic values. The default NAD83 projections utilize the null transformation so that Global = Local, but there are datum options that allow you to enter ITRF/WGS84 coordinates for the Global and transform them to NAD83 ("Local" values in Trimble-speak) before projecting them.
They have also implemented the NGS datum grids for NAD83, so if the user picks "NAD83(HARN)", one can enter NAD83(2011)[2010.00] values into the Global coordinate and obtain HARN from the Local and Grid (projected) values.
Of course, there are little nuances with every software package. Trimble has "NAD83(2011)" and "NAD(CORS96)" datums, but they are both null transformations, and have different names mostly for the purposes of being able to export GIS data with the appropriate EPSG code.
If you pick "ITRF to NAD83(2011)", it will apply the conversion to go from IGS08 to NAD83, not the most recent ITRF2014 to NAD83(2011) that the NGS currently uses...so there will be a cm or two of difference if you compare NGS-generated values to TBC-generated values. Depending on the work you're doing it might or might not be an issue.
If I actually do really need a KML/KMZ in WGS84/ITRF, I can import grid points or CAD linework to an "ITRF to NAD83" project, and then when I go to export, the global ITRF values are written to the KMZ rather than the local NAD83.
It is my understanding that Google Earth does NOT use WGS84.
It uses a bastardised version thereof called Spherical Mercator - the EPSG code is 3857.
That's my understanding as well. We will sometimes use pin drops or KMZs for approximate searches, but since we have background maps in our collectors it's easier to simply have everything in there, and in the correct non-bastardized datum...
Tony,
What you have described matches my understanding as well. In my area (northeastern Colorado), the WGS84 (or EPSG3857) coordinates are about 4.5 feet northwest of the NAD83 coordinates. Some years ago, after rummaging around in all of the Carlson settings (as I imagine you have done), I gave up trying to get Carlson to properly transform coordinates between WGS84 and NAD83 and I developed a workaround: I made a new projection. So now in addition to "USA/NAD83/Colorado (North)", I also have one called "USA/NAD83/Colorado (North) WGS". It has the same parameters as the original except it has Dx=1m, Dy=0 and Dz=-1m Helmert parameters, which I found by trial and error. Maybe I got lucky, but it didn't take long to find numbers that worked. By "worked", I mean the exported kml points and linework match the Google Earth photos acceptably. In the projection list, I selected the projection, clicked Edit, changed the name and the Helmert parameters, and clicked OK. Then clicked Add Pre-Defined and re-load the original NAD83 projection so both are in the list. Now when I'm going to import or export kml or use the google_image command, I use the "WGS" projection. If for some reason I want to convert Northing/Easting coordinates to NAD83 Lat/Lon, e.g. with the lablat command, I use the NAD83 projection. Works for me.
Hey thanks @jim.cox, that's good information about ESPG:3857. I didn't realize that there is a "Web Mercator" projection that Google, Bing, etc. use to display maps on a web page.
So I now understand that Google Maps and Google Earth uses ESPG:3857 to project from geodetic coordinates to a flat display screen. Cool. As far as I can tell, ESPG:3857 takes WGS84 coordinates and projects them onto an x,y plane to display on a web page. I still believe that the coordinates in a KML file are WGS84 (some realization). At least that's my read from the KML standard ( https://docs.ogc.org/is/12-007r2/12-007r2.html).
@Rover83, That's pretty cool that Trimble (TBC) has the concept of Global and Local geodetic values. I appreciate all that info. I'm not a TBC user, but understanding how other software packages do things helps me understand the s/w I use.
And thank you for the proper terminology "null transformation" to explain what took me a long sentence to convey.
@John Thompson thanks for the great info on Carlson. I do believe I tried all the relevant settings. I'm glad to know I'm not crazy. (Or at least if I'm crazy I'm not alone.)
Your approach to create a custom projection is just brilliant. I'm already experimenting with your approach. I got starting values for my DX, DY, DZ Helmert parameters by looking at an OPUS solution for a local point and comparing the XYZ NAD83 and XYZ ITRF2014 in the OPUS report. Still working on this.
This site is great.
Cheers,
Tony.
I got starting values for my DX, DY, DZ Helmert parameters by looking at an OPUS solution for a local point and comparing the XYZ NAD83 and XYZ ITRF2014 in the OPUS report. Still working on this.
No need to try and guess at the values. Those Dx/Rx values are for translations and rotations in ECEF to go from WGS84/ITRF to NAD83. There is a very tiny value for scale as well.
NGS publishes the exact parameters here:
https://geodesy.noaa.gov/CORS/news/mycs2/mycs2.shtml#htdp_params
If you plug those into the correct fields (make sure the units are correct), you'll be on the money when you run a transformation.
I would suggest contacting Carlson Tech Support to see if you can achieve what you want to. KML files are in some form of WGS 84 but converting that to State Plane could be dicey, depending on which system your state uses and the zone.
I work in NJ and they publish aerial photos based on NAD 83and they drop in pretty tightly and never use KML files for more than presentations.
@rover83 Thanks, based on your post I’m already trying those parameters. Appreciate that.
@chris-bouffard Yes, good idea. I will do so.
Carlson support confirmed that they are not converting to IRTF when exporting to KML/KMZ (File->Export->Google Earth). And likewise they are not converting from IRTF when importing from KML/KMZ files.
