POST
|
@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
a week ago
|
0
|
0
|
75
|
IDEA
|
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
08-02-2024
01:39 PM
|
0
|
0
|
115
|
POST
|
We modeled the Esri projection engine's coordinate system and transformation structures after EPSG's but didn't always agree with some of their decisions. Later, once ISO19111 codified the coordinate reference system data model (and in the last few years, coordinate operations/transformations), it was somewhat different. EPSG has updated their data model to more closely match ISO19111. Esri has generally remained unchanged. We have the EPSG names as synonyms so if we can identify the object, you should see the WKID if you look at its details. If it's listed as unknown, then for whatever reason, we could match the definition against our version. If you leave the coordinate system as-is, the only thing it will affect is if you need to transformation between NAD 1983 CSRS and another GCS. Because we don't 'recognize' the GCS, we won't be able to find any transformations for it. Melita
... View more
08-11-2023
10:21 AM
|
2
|
0
|
852
|
POST
|
@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
08-10-2023
03:17 PM
|
0
|
0
|
927
|
POST
|
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
06-26-2023
12:22 PM
|
0
|
1
|
468
|
POST
|
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
05-25-2023
01:43 PM
|
0
|
0
|
926
|
POST
|
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
05-25-2023
01:37 PM
|
0
|
0
|
843
|
POST
|
What is confusing the issue is because the coordinate system properties pages in ArcGIS Pro show the coordinate system names without underscores, but if you look at the actual definitions, the underscores are there. Internally, when we compare two coordinate systems, we usually ignore underscores/spaces so if everything else is the same, that type of difference in the names won't matter. We've also changed the UI so that doing a save as/defining a custom coordinate system usually won't allow you to use the same name as an existing coordinate system but that was a relatively late change. The well-known ID, 26911, is the ID for the meter version of UTM zone 11N. The closest we come to a US survey feet version for NAD 1983 zone 11N, is the "BLM" zones. EPSG:4431 is the equivalent, but the name differs: NAD_1983_BLM_Zone_11N In the coordinate system picker, if you're seeing all layers that use both definitions (meter-based and US foot-based) under the same coordinate system name under "Layers", then that could be a bug. We're probably sorting the layers into different "folders" based on their coordinate system's name. With both definitions using the same name, that would make it tricky to differentiate them. The software can easily reproject between the two definitions. You would likely only notice if you check attributes for the lengths or areas or did some analysis where the output values were in the layer's units and it wasn't what you expected. In the coordinate system picker, if you look under "projected coordinate systems", UTM, NAD 1983, and check its parameters, you'll see its unit of measure is meter. Melita
... View more
05-08-2023
12:09 PM
|
0
|
1
|
975
|
POST
|
Hi James, If you look at the files here: Github Esri projection-engine-db-doc objedit folder and I can send you a document that explains it. Please drop me an email at mkennedy at esri dot com. Melita
... View more
04-27-2023
07:24 AM
|
0
|
2
|
1142
|
POST
|
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
05-23-2022
01:36 PM
|
0
|
0
|
1191
|
POST
|
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
05-04-2022
12:21 PM
|
1
|
0
|
711
|
POST
|
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
04-04-2022
05:11 PM
|
0
|
0
|
1187
|
POST
|
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
04-04-2022
04:43 PM
|
0
|
0
|
2892
|
POST
|
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
04-04-2022
03:39 PM
|
0
|
1
|
2225
|
POST
|
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
10-14-2021
10:41 AM
|
0
|
1
|
1124
|
Title | Kudos | Posted |
---|---|---|
1 | 07-08-2013 01:27 PM | |
2 | 08-11-2023 10:21 AM | |
1 | 07-11-2011 09:31 AM | |
1 | 10-12-2012 09:49 AM | |
1 | 02-26-2016 12:07 PM |