Latest Contributions by MelitaKennedy

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

Hi Aaron,  Your post may be moved to the coordinate reference systems 'place' as this one is for the Runtime SDK for Java rather than the Java Geometry API.  You're correct that you'll need to project the geometries to a projected coordinate reference system before buffering. I wouldn't suggest using 3857 (Web Mercator) as it's quite distorted except near the equator. There's not a good answer for you. Even for so-called 'equidistant' projections, they maintain distances from one or two points or along certain lines, like all north-south lines.  One intensive solution is to create a custom projected coordinate system for each geometry. If they're points, center an azimuthal equidistant projection, run the buffer, then reproject to whatever coordinate reference system you're using. If you don't need really accurate results and are instead okay with 1 part in 2500 accuracy at the worst AND working within 3 degrees of longitude, the local UTM zone would be okay. A shortcut for UTM zones are that the WGS 84 ones have well-known IDs that look like: 326 + zone number where zone number is 01 - 60 for the northern hemisphere and  327 + zone number for the southern hemisphere I'm not going to replicate the pseudo-code here, but there's a post on GIS stackexchange that shows how to calculate the UTM zone from a latitude-longitude point. Melita ... View more

Sorry, not yet!! My team hopes to concentrate on geoid models/vertical transformation grids in the next release. ... View more

You still need to convert between latitude-longitude and XYZ. See section 4.1.1 of IOGP / EPSG Guidance Note 7-2. It's available from https://www.epsg.org.  ... View more

Hi Xander,  Yes! And they need converted to XYZ. There is an abridged Molodensky method that uses decimal degrees directly--but accuracy is a little less. After converted through the conformal 3D equation, the output XYZ need to be converted back to lat-lnng-ellipsoid h. That conversion is usually iterative but I think there are some direct but less accurate conversions. Melita ... View more

Duh! mkennedy at esri dot com ... View more

Hi Lauren,  I'm very sorry for the late response. Can you post the equation/steps the surveyor gave you for the data? For CAD data it's sometimes possible to assign translation/rotation/scale values to a CAD layer. It's also sometimes possible to modify the projection parameters (scale factor, false easting, false northing) and create a custom coordinate system that gets the data to match up. I have two documents that discuss some of this. If you (or anyone else) sends me an email, I'll send them. They're pretty old now and written for ArcGIS Desktop so workflows may be different if you're using ArcGIS Pro. Melita ... View more

Are you converting the input coordinates to radians and converting to XYZ? The main equations look okay to me. ... View more