Latest Contributions by MelitaKennedy

@GISAdminSHN wrote: -- I've added my responses in-line.   Data Frame: projected state plane coordinate system that uses the NAD 1983 2011 datum The Data: projected state plane "vanilla" NAD 1983   1) Where can I find more detailed information about the composite coordinate frame method transformation that shows up in the top of the list? I suspect you're seeing something like NAD_1983_To_WGS_1984 + WGS_1984_(ITRF08)_To_NAD_1983_2011. (I may not have the names 100% correct). You can find out more about our transformations (and other objects either through the PDFs that are installed with the software and are available via the documentation. See the bottom topic on this page or this ArcGIS Pro page. You can also check out the Esri projection engine's public Github page. Select the text folder and open the appropriate object type's file. You may have to expand the results.  In this particular case, if I got the 2 transformations correct, NAD_1983_To_WGS_1984 is a null transformation, defined when before these two coordinate systems were beginning to be refined via new realizations or re-adjustments. The two systems were assumed to be equivalent. The other transformation that includes ITRF in the name was originally based on a transformation between ITRF96 and NAD 1983 CORS96/HARN, and even though it's older, should get rid of most of the 1+ meters that now exist between ITRFxx/WGS84 and NAD 1983 (2011). Even though it was defined for a different realization.  The best way to convert between NAD 1983, assuming you really have original, 1986 version data is to use NADCON5 transformations, like are used in NCAT. You have to have the ArcGIS Coordinate Systems Data setup installed. The official steps, which convert between all the realizations, are:  NAD 1983 - NAD 1983 HARN - NAD 1983 FBN - NAD 1983 NSRS2007 - NAD 1983 (2011) Complicating this is that we currently allow only 2 transformation at a time, so you can't do this in ArcMap data frame or ArcGIS Pro map/scene.  Honestly, though, I think most people do not have original NAD 1983 data but, at best, have a mix of data that might have started out as NAD 1983 but is likely a mix of several realizations if any editing or updates occurred over the years. 2) Is a coordinate frame transformation inherently more accurate than a grid comparison transformation? (NADCON or NADCON5) On NGS's website they seem to stress that they are "interpolative", do you have any kind of qualitative analysis of ESRI's implementation of NADCON5 transformations versus the coordinate frame method above? No. Grid/file-based transformations can better model the differences over an area. An equation-based method like coordinate frame is a least squares best fit based on the control points. Grid/file-based methods take the closest points (it's like a raster) and interpolate between them to figure out the offset for a particular location. It doesn't guarantee that's what you would get if you went out and surveyed, but that's true for equation-based methods too. 3) What NADCON transformations would you do in ArcGIS to try to match the results from NGS NCAT? Look for NADCON5 in the name or check using the Github website where the transformation parameter for the file will include nadcon5 in the file name or for the method.  NADCON method is NADCON 2.0/2.1 and uses a different file format. It includes original NAD83 and NAD83 HARN only. There was a set of in-between transformations released for GEOCON and GEOCON11, but those have been replaced by the NADCON5 files.   Melita   ... View more

HI,  10-15 feet is a lot--more than I would expect if there was a geographic/datum transformation issue, and not enough for a serious problem with the coordinate system. Is the contractor data, Main GDB, and the map/data frame coordinate system all the same? Completely the same (units, parameter values, etc.)? Feel free to post screen grabs of each here or send them to me directly (mkennedy at esri dot com). Is there any transformation set in the map/data frame? Melita ... View more

The closest you can get is to use either an arbitrary definition, for instance based on transverse Mercator, set the central meridian and latitude of origin to zero with the units you want and go from there. Another projection that could work is the "Local" projection. It's still geographic coordinate-based, but you can set it anyway. It additionally supports rotation, scale factor, and false easting/northing parameters (the last two reset the center point's values to whatever you want).  Either one would still be based on a earth-based GCS like WGS84. There are some non-earth-based solar system GCS for the other planets and moons.  Melita ... View more

Hi,  We don't support the LOCAL_CS type, can even if we did, I don't feel like there's enough information there anyway. As it is, this data wouldn't be able to be aligned with anything else with a defined geographic or projected coordinate system. Do you have more information about what the coordinate system is?  You can take a look at WKT examples of our supported GCS/PCS at our public github site: Esri projection engine  Melita ... View more

Hi Janel,  A feature dataset and/or feature classes use a spatial reference. A spatial reference includes the coordinate system and xy/z/m extents and resolutions (also tolerances but those are less problematic). The extents and resolutions are extremely different if the coordinate systems are geographic versus projected. You can't really set it for one type and have it work for the other type. PCS can also be pretty different, particularly in the US where you may have feet versus meters which messes up the storage precision (resolutions) and the tolerances.  I remember we discussed but I can't remember what you ended up doing! Melita ... View more

The (partial) definition is there in the Coordinates header: Lo 31. That's a South African coordinate reference system (CRS). It might be based on the Cape datum/geographic CRS or the current Hartebeesthoek94 CRS. We do a weird workaround to support these coordinates because the axes are south-west (or maybe west-south order) rather than our default of east-north.  Try entering them as they are using projected coordinate systems-national grids-south africa-Hartebeesthoek94 Lo31 and see how they work. If they  appear to be flipped, try the (E-N) version instead. Melita ... View more

Hi Juraj,  I'm sorry for the delay in responding. We switched from using the v10 (Desktop) numbers to v11&12 (Pro) around 10.8.1 as ArcGIS Pro became our primary release and the one that we actively work with.  Pro      Build #   EPSG version  Release Date  ArcMap Release 12.6.0   24783     9.8.6         07/13/20      10.8.1 12.7.0   28628     9.8.6         12/11/20  12.8.0   29751     10.14         05/07/21      10.9.0 12.9.0   32739     10.32         11/02/21      10.8.2 Melita ... View more

Hello!  I'm sorry for the delay in answering. NOTE: This answer also generally applies to the US for WGS 84 versus later NAD83 realizations. Part of the answer depends on what the WGS 1984 Web Mercator base map is really using. Truly accurate WGS 84 coordinates are reserved for military and military-adjacent users. Everyone else, if you're performing RTK or otherwise improving the civilian GPS signals are really getting data on NAD83 (CSRS) or ITRFxx. So data that's turned into a base map, depends on what transformation may have been used to convert to WGS 84.  In general, NAD83 (CSRS) is about 1 m / 3 ft (either one) away from WGS 84 / ITRFxx. So if someone says they have data and it's about that much offset, my first thought is that it's a transformation issue, and specifically WGS 84/ITRFxx vs. NAD83. Several transformations are really NAD83 and ITRFxx but have a 'duplicate' or 'equivalent' transformation that's to WGS 84 instead because we know that's what customers need for base maps and ArcGIS Online.  The ArcGIS Pro default is two steps: your custom transformation between NAD83 CSRS and NAD83, and WGS84 (ITRF00) and NAD83. Basically, this ends up almost a null transformation. You convert from CSRS to to NAD83 then to WGS84 (ITRF00), so the data's almost back where it was. Not exactly of course, because the custom transformation is using an NTv2 grid file and can be more precise with its offsets.  The second workflow using NAD83 CSRS to WGS 84 2 is very similar to but not exactly the WGS84 (ITRF00) to NAD83 transformation so you see some offset, but not the same.  Sometimes the software requires a transformation because it knows the input and output CRS are different and won't let a process go farther unless they're reconciled.  You can look at the transformation parameter values in our public GitHub repo or in the transformation PDF file. Melita ... View more

Hello!  There are a couple of things that could be going on.  1. Make sure that the map in Desktop or Pro is using the same transformation that was used in the Project tool to convert the points.  2. You may need to break down each step between frames and compare it against the results of NCAT so we can narrow down where the differences are occurring. It's possible that the same transformations aren't being used in one or more of the processes. The transformations should say NADCON5 in the name and you should have the ArcGIS Coordinate Systems Data setup installed to access those transformations. Melita ... View more

Berndt,  Are you finding that the custom transformation isn't showing up / cannot be chosen when it needs to be applied in the opposite direction? We do only define transformation in one direction, but the code knows to apply them in either direction. We didn't want to spend the time to flip the transformation name in the UI.  Melita ... View more

My colleague, Kevin M. Kelly, pointed out that I should clarify that epoch information is connected to the data rather than a geographic coordinate system. That was a long discussion in the ISO 19111 (coordinate reference system and transformations/operations data models) committee on the last revision. It would be easier for me if it was on the CRS, but it is really a data attribute. That complicates implementation for us a bit. ... View more

Hi Matt,  We've been debating how to implement time-based transformations which would include the ability to persist epoch (date-of-collection) information as well. The ISO metadata standard has now been updated so that information can be stored there. That still can cause some issues in the projection engine because that library sits so low in the software stack that we would have to figure out how to access the metadata files!    We've been adding the transformations and some supporting functionality to the projection engine but we still need to get it exposed above in the software stack.  Melita ... View more