Latest Contributions by MelitaKennedy

Hi,  Thank you for prompting me to update this list!  Pro      Build #   EPSG version  Release Date 13.0.0   36056      10.054      June 23, 2022 13.1.0   41833      10.076      February 23, 2023 13.2.0   49743      10.094      November 07, 2023 13.3.0   52636      11.003      May 7, 2024 13.4.0   55405      11.015      November 7, 2024 13.5.0   57366      12.002      May 13, 2025 13.6.0   59527      12.018      November 13, 2025 Notes for myself (and others): Release Dates can be found on the ArcGIS Pro Life Cycle page (link will open in a new page). Corresponding EPSG version for a release can be found on our Esri projection engine db-doc GitHub repo in the README.md file. The link is for the 3.6.0 version and will open in a new page. To get another version, modify the link (v3.6.0 to v3.4.0 for example) OR, from the main repo page, click the pull-down on the left side above the folder list, switch to the 'tags' tab, and select the version you want. Currently, it includes ArcGIS Pro 2.1 through 3.6. Minor releases (#.#.x) practically never get new coordinate systems or transformations added which is why none are listed. I can remember one case where we included a handful of objects into a previous version's current 'dot release'. However, there's a discrepancy as of Jan 16, 2026 because the 3.6.0 README.md says 12.028, while another internal file says 12.018. I believe 12.018 is correct and will get the README.md file updated.  Melita ... View more

Hello,  My colleague, Kevin M. Kelly, asked me to post a reply because he's having trouble accessing Esri Community.  Currently, functionality does not yet exist in ArcGIS Pro or any other Esri product to perform a point motion operation to update coordinates over time. We are working hard to build this functionality but it is not there yet. It seems you want to update your CSRS Epoch 2017.50 (NAD83) projected coordinates (NAD 1983 StatePlane California V FIPS 0405 (US Feet)) at epoch 2017.50 to CSRN Epoch 2025.00 (NAD83 2011) State Plane coordinates at epoch 2025.0. Again, this is not yet possible in ArcGIS. The only tool available to correctly perform this point motion operation is the SOPAC Coordinate Interpolator Prompt (SCIP). Unfortunately, this tool does not handle GIS datasets but only single points or a list of points in CSV format. Be aware that the NGS HTDP tool will not yield the same results as the SOPAC Coordinate Interpolator Prompt (SCIP) tool. This is because NGS and SOPAC used different geophysical models and analysis methods to derive the California crustal motion models. This is clear from the comparison below between HTDP and SCIP for point motion from 2017.5 to 2025.0 at station 7ODM in Southern California (see values in bold text). Note for the SCIP calculation I used the online tool with a single point rather than a CSV file. HTDP Output **************************************** HTDP OUTPUT, VERSION 3.6.0   TRANSFORMING POSITIONS FROM NAD_83(2011/CORS96/2007) (EPOCH = 07-02-2017 (2017.5000))                          TO NAD_83(2011/CORS96/2007) (EPOCH = 01-01-2025 (2025.0000)) 70DM                      LATITUDE     34 06 59.05950 N     34 06 59.06426 N       18.64 mm/yr  north   LONGITUDE   117 05 35.45393 W    117 05 35.45786 W      -13.46 mm/yr  east   ELLIP. HT.             762.791             762.785 m     -1.22 mm/yr  up   X                 -2407750.342        -2407750.392 m     -6.76 mm/yr   Y                 -4706537.770        -4706537.646 m     16.34 mm/yr   Z                  3557571.660         3557571.778 m     14.75 mm/yr SOPAC Coordinate Interpolator Prompt T-in 2017.5000 (2017-07-02) T-out 2025.0000 (2025-01-01) Closest Input Date 20170705 Closest Output Date 20250106 Input Datum NAD83(2011) T-in Latitude (N) 34 6 59.0595 T-in Longitude (E) -117 5 35.4539 T-in Ellipsoidal /height (m) 762.7910 Output Datum NAD83(2011) T-out Latitude (N) 34 6 59.0641 T-out Longitude (E) -117 5 35.4581 T-out Ellipsoidal /height (m) 762.7980 East Diff. (mm) (t-out - t-in) -106.6 North Diff. (mm) (t-out - t-in)  140.5 Up Diff. (mm) (t-out - t-in)  7.0 East Unc. (mm) 2.4 North Unc. (mm) 2.7 Up Unc. (mm) 11.1 I hope this helps.  Kevin (and Melita)   ... View more

Hi,  My team (Esri projection engine) agrees with you that the reliance on EGM96 is...sub-optimal! We're working with Drone2Map and FieldMaps to try to change that. No timeline/release on when that may change yet. Melita ... View more

Geodatabase went to "high precision" in ArcGIS Desktop 9.2, so late 2006.  ... View more

Hi Bill,  I'm sorry for the delay in responding. Annette did ask me to answer last week, but I'm afraid I got distracted. Okay, we're going to go into some history here. The spatial reference contains several items:  coordinate system  xy/z/m domains xy/z/m resolutions (earlier called xyunits which was 1/xy_resolution) xy/z/m tolerances The latter three were originally defined because geodatabase feature classes (originally in ArcSDE) stored coordinate values as positive integers. In fact, they were originally had strict limits and were updated to "high precision" several years later. There was a maximum number of allowed integer values. A combination of the minimum x, minimum y, and EITHER the max x, max y OR the xyunits or xy resolution value controls the third thing. so if you set the min x/y and the xy resolution, the max integer values force how large the max x/y values can be. Or if you set the min/max x/y values, then the xy resolution (xyunits) value is then calculated. When we went to "high precision", that increased the maximum integer values by...a lot.  The default minimum x/y values are set based on what's allowed mathematically for a projected coordinate system rather than the area of use for that particular pcs. At the time, for a custom PCS, we would have no idea what the area of use would be so better to use the allowed mathematical limits of the map projection.  Resolution (1/xyunits) values determine the precision of stored coordinates. Our defaults for x/y are 1/10 mm or 0.0001 m. If you set xy domain to match the area of use, that usually forces the xy resolution to be really, really small which is unrealistic and can make handling and processing the data difficult. Instead, we usually set the minimum xy values and the resolution which instead makes the maximum xy values very, very large, much more than the area of use of the mathematical limits of the map projection.  Min values for z and m are arbitrarily set to -100000, similar resolution values. For GCS (degrees usually), we use corresponding values to the defaults of a pcs, but the minimum xy are set to -400 and resolution is around 10e-9, I believe.  Tolerance values have to be at least 2x the corresponding resolution value but our defaults set them to 10x, so 1 mm or its equivalent.  In case I didn't explicitly define these earlier, an area of use is the where a PCS should used, like California State Plane zone VI covers San Diego, Imperial, Riverside, and Orange counties, while the xy extent is the mathematically valid area of the map projection. California VI uses Lambert conformal conic so it's most of the world.  There is at least one white paper that discusses some of this. Here it is: Understanding Coordinate Management in the Geodatabase. I hope this helps. Melita ... View more

Hi Joseph,  The original idea is to clear the coordinate system from a map (or scene) in ArcGIS Pro to match the same functionality from ArcGIS Desktop. We have implemented that. The capability is designed to see how two or more layers display relative to each other. If one layer has a defined coordinate system but you think that it's incorrect, visualizing the offset can help you figure out what the correct coordinate system should be.  If you instead want to remove the coordinate system from a dataset itself permanently, yes, that is better handled by the Define Projection tool.  Do you want to temporarily set a layer's coordinate system to 'None', while within a map or scene? We did discuss that possible capability while working on clearing the map/scene coordinate system, but decided against implementing it for a few reasons. It wasn't possible in ArcGIS Desktop. It would be difficult to implement because so many different workflows interact with a data layer. Sometimes they're interacting with the actual data set rather than the 'copy' of the metadata in the map or scene so we would have to modify all these workflows/functionality. It gets complicated quickly.  Melita Kennedy ... View more

Hello,  This is going to hit a bunch of different questions that have come up over the years that I missed. Sorry! I don't know about any possible changes at the SQL level because I haven't worked with RDBMS for years. If your RDBMS has a 'spatial' component, there's likely a function like 'project' or 'projection' that should do the equivalent. It might even take WKID numbers. Ah, check out the Microsoft SQL Server Spatial Tools. Actually, from that topic there's a link in the Tip that takes you to a GitHub opensource set of Spatial Tools.  The IOGP (absorbed EPSG years ago; EPSG name was kept for recognition purposes) Guidance Notes related to coordinate reference systems, geodesy, coordinate transformations/operations are available or linked from this page. The one you want if you're going to implement the math of a map projection is 7-2. Currently, it's available from the IOGP bookstore, but it's free. You just need to fill out your email etc. You might get some emails from IOGP; but you can unsubscribe.  re: NAD27. NAD27 uses Clarke 1866 versus GRS80, so you would need to change the semimajor axis and the semiminor axis OR the flattening value, depending on what is being used. Unfortunately the conversion between NAD83 and NAD27 in the US uses a grid file and would be quite a bit to implement. I've never done it myself.  There are some 'equation-based' datum transformation methods but the ones between NAD27 and WGS84 (rather than NAD83) are not very accurate.  Melita ... View more

Thank you for adding this idea. We greatly appreciate it. We understand the urgency of  this issue. The Esri Projection Engine, and thus ArcGIS Pro and other Esri software, does not have all known transformation paths between NAD83 CSRS re-adjustments/realizations. For some provinces and earlier adjustments of NAD83 CSRS, we do support some transformations, but we are missing transformations for the latest versions. All National Resources Canada transformations that convert between later NAD83(CSRS) numbered re-adjustments use NTv2 format velocity grid files, which ArcGIS software does not support. We only became aware of the velocity-grid  transformations when EPSG added the definitions to their registry in March 2024. For example, two transformations are listed below. NAD83(CSRS)v3 to NAD83(CSRS)v6 (3)  NAD83(CSRS)v3 to NAD83(CSRS)v7 (2)  Proper support of velocity grid transformations is a significant development effort and we’re currently evaluating this work and timeline. ... View more

  @Fahad_Insprit wrote: Hii...   can anyone help me to convert the google map coordinates to UTM coordinates that are used in Civil drawings in  Dubai. I tried to convert but its not working. Please suggest how to do that. Thanks in advance   Hi,  Can you give examples of:  input Google coordinate values output UTM coordinates that you're getting (and what definition/parameters you are using) what are the expected values   Based on what Cliff Mugnier wrote in his column on the United Arab Emirates, Dubai is not using a standard UTM zone but a local transverse Mercator zone so you would need to create a custom projected coordinate system. The Dubai Local Transverse Mercator (DLTM) Grid is referenced to the WGS 84 ellipsoid, the Central Meridian λo = +55° 20’ E, and the False Easting = 500 km.  The Northings are presumably measured from the Equator.  ... View more

Hi Bud,  I'm sorry about the long delay in responding. We're going to open an official issue with the map authoring team (who owns that UI) and see if we can get the UI to list subfolders before the individual coordsys/prj entries. That way it acts more like a Windows file explorer window. If it turns out to be difficult for some reason, we could create an 'Other GCS' subfolder so that you no longer have to scroll down through the individual coordsys/prj entries to get to the subfolders.  As you mentioned, using the search or filter methods can help. If you're using the same coordinate systems consistently, you can Add to Favorites too. Note: Once we accumulate about 20 or more related entries in a folder, we usually put them into a subfolder.  Melita ... View more

@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