|
POST
|
The software doesn't like the definition of your data. Try redefining it as Arc 1950 UTM zone 36S (in the UTM, Africa folder). The ellipsoid parameters are slightly different, but enough that the software doesn't recognize it as Arc 1950. Melita
... View more
02-16-2018
10:33 AM
|
2
|
0
|
4441
|
|
POST
|
Misleading and overloaded terminology. I use "projection" as much as I can to mean converting between lattiude-longitude (referenced to a geographic coordinate system) and xy, 2D Cartesian coordinates referenced to a projected coordinate system. I use transformation or more liked a geographic/datum transformation to refer to when we're converting between two geographic coordinate systems like NAD83 and WGS84. The Project tool will also perform transformations if the input and output coordinate systems (geographic or projected) have different geographic coordinate systems. You don't need to perform them separately. Geographic/datum transformations, depending on the method type, either explicitly convert between the two ellipsoids as part of the algorithm, or it can be considered to be included into the method implicitly. An explicit method would include geocentric translation where you convert the latitude-longitude into 3D Cartesian, XYZ, using the input ellipsoid. offsets are applied to the XYZ values, then the XYZ values are converted back to latitude-longitude using the output ellipsoid. An implicit method would include any file-based method like NADCON/HARN or NTv2 where a grid file is used to calculate the offsets. The ellipsoid change is just included in the offsets. Maybe look at a presentation like Introducing Coordinate Systems and Transformations. Start here and search using 'coordinate' (without quotes). Melita
... View more
02-14-2018
11:59 AM
|
0
|
0
|
1475
|
|
POST
|
I must not have read the thread thoroughly. I'm sorry, Chuck! If you have data with a GCS of "GRS_1980", that means it wasn't fully defined as GRS_1980 is an ellipsoid, not a geodetic datum nor geographic coordinate system. We don't have any transformations to/from GRS 1980 so you really need to redefine is as one of the NAD 1983 realizations, if you know which one it is. Melita
... View more
02-13-2018
12:03 PM
|
0
|
5
|
4517
|
|
POST
|
Bradley, Note that the UTM grid lines will then be tilted slightly. Check out the images here (US Naval Academy site) to see what the latitude and longitude lines are doing when data is displayed in a UTM zone. Melita
... View more
02-12-2018
04:30 PM
|
1
|
1
|
1693
|
|
POST
|
Based on the attached picture, try deleting one of the two transformations. You're converting from WGS84 to NAD83. The first transformation converts from NAD83 to WGS84, while the 2nd converts from WGS84 to NAD83. Either one on its own is okay, together, they don't make up a valid path. Melita
... View more
02-12-2018
04:25 PM
|
1
|
7
|
4517
|
|
POST
|
Thank you very much for hanging on with our questions. I'm now going to ask a few questions to make sure I understand the workflow. 1. When you reset it from 3785 to 3857 and back, did you use Define Projection / data property page or the Project Tool? 2. You said that it's not lining up against Google maps data. Does it line up in either version against an Esri basemap in ArcMap or ArcGIS Pro? The WKT you posted is 3857, not 3785. Here's 3785: PROJCS{"WGS_1984_Web_Mercator",GEOGCS["GCS_WGS_1984_Major_Auxiliary_Sphere",DATUM["D_WGS_1984_Major_Auxiliary_Sphere",SPHEROID["WGS_1984_Major_Auxiliary_Sphere",6378137.0,0.0]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Mercator"],PARAMETER["False_Easting",0.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",0.0],PARAMETER["Standard_Parallel_1",0.0],UNIT["Meter",1.0]] Melita
... View more
02-08-2018
10:23 AM
|
1
|
0
|
2042
|
|
POST
|
Do me a favor and try to set it to 3395. That's World Mercator. A North-South offset when working with Web Mercator data is often because the layer is actually on an ellipsoidal Mercator version. Also, if you have any of the unchanged 3785 data (that is, has not been redefined yet), could you export the coordinate system / save as a .prj file and post the contents here? If it's a shapefile, there will already be a .prj file. Thank you, Melita
... View more
02-07-2018
11:29 AM
|
0
|
2
|
2042
|
|
POST
|
I haven't tried this: Viewing tool execution history—Help | ArcGIS Desktop
... View more
02-07-2018
11:14 AM
|
1
|
1
|
2364
|
|
POST
|
In general, there's no reason why you couldn't always store your data in latitude/longitude/height and only project it either on-the-fly for display or printing or make a copy that's in a projected coordinate reference system for analysis or whatever. The biggest issue right now is that many algorithms used for analysis either don't have a 3D version implemented (sometimes due to complexity) AND/OR they're slow, often really slow, much slower than the equivalent 2D algorithm. Even keeping all data in latitude/longitude/height, there's still a lot of different geographic and vertical coordinate reference systems out there so you would still need to reconcile these to use data layers together. Melita
... View more
02-06-2018
07:51 AM
|
0
|
1
|
1183
|
|
POST
|
Neil, It's true that an export from the data frame won't record what transformation was used, but geoprocessing tools do record that information in the history, and I think somewhere in the data's metadata, but yes, it's hard to get at. Melita
... View more
02-05-2018
01:35 PM
|
1
|
3
|
2364
|
|
POST
|
Thank you! I'm glad to hear that you've got it working. I wanted to clear up the EPSG well-known IDs issues. WKIDs are unique within an object type. For instance, coordinate reference systems (projected, geographic, and vertical) will have unique WKIDs. Geodetic datums (used to make GeoCRS) can have overlapping WKIDs with CRS as can units of measure, coordinate operations (geographic/datum transformations and "projections"), ellipsoids, etc. So--- 6318: NAD83 (2011): Geodetic CRS (2D) 4318: NGN: Geodetic CRS (2D) 6318: National Geodetic Network: Geodetic Datum 1116: NAD83 (NSRS 2011): Geodetic Datum 1116: Arc 1950 to WGS 84 (4): coordinate transformation 1116: Heard Island and McDonald Islands: area of use 4318: USA - Montana - Billings: area of use My guess is that they've cross-connected 6318--maybe assuming it was the datum rather than the GeoCRS. Melita
... View more
02-05-2018
01:33 PM
|
1
|
1
|
4845
|
|
POST
|
This is a bug. It's fixed in 2.1. Note the additional parameter that showed up: Scale Factor 0.0 Oops! Change this to 1.0, and the coordinate system will work properly. Melita tl;dr; AKA Geeky explanation: Esri's Lambert conformal conic (LCC) algorithm is "overloaded" to support two variants. One variant uses two standard parallels (plus a latitude of origin). The other variant uses a latitude of origin and scale factor plus one standard parallel. The latitude of origin and standard parallel 1 need to be equal. Similarly, if you end up with standard parallel 2 in the definition it also needs to equal SP1 and lat of origin in this second variant. For the already defined projected coordinate systems that use LCC, we only show the appropriate parameters. When you create a custom one from scratch or modify an exsting one, we don't know which variant you want so you get all the parameters. In this case, we weren't setting the scale factor parameter to the correct default of 1.0.
... View more
02-01-2018
04:11 PM
|
1
|
0
|
3283
|
|
POST
|
I just checked the definitions for all South Carolina state plane zones for NAD83 and later re-adjustments like 2011. They all have 31°50'0" for the latitude of origin (the definition has a macro identifying it as DMS). Because it's a raster, it might be a problem in the header, or how the header is being interpreted. So this may be a specific-to-raster problem. I thought I had a copy of listgeo available, but it was quite old so I might try to get a newer version or gdalinfo up-and-running again. Feel free to drop me an email (mkennedy at esri dot com) with the dropbox location and I'll try to repro and send it on to the raster team. When you redefine the coordinate system, do you modify the existing one or use the Esri definition? If the latter, that confirms that the Esri projection engine has the correct definition but there's something we're not reading correctly in the geotiff's header. Melita
... View more
02-01-2018
03:59 PM
|
1
|
1
|
4845
|
|
POST
|
If you're in ArcGIS Desktop, yes. In Desktop, transformations came in a release or two later than the first release and at that point, we had never set a particular "default" transformation for any pair of GCS. ArcGIS Pro does set a transformation by default but it's using the data extents to try to set a reasonable transformation, rather than the most generic one (generic AKA the one that covers the most area and usually has the worst accuracy). Those values are big enough that I would suspect that they're using a different or no transformation.
... View more
02-01-2018
03:47 PM
|
1
|
7
|
2364
|
|
POST
|
Did you use the Calculate Geometry option on the fields? Was it set to use the data frame's coordinate system? If so, did you set the transformation in ArcMap? If not, open data frame properties, select the coordinate systems tab and click the Transformations button. If the data frame is Arc 1960, in the top box, select WGS 1984. Click the pull-down at the bottom and select the same transformation that you used in the Project Tool.
... View more
01-30-2018
10:58 AM
|
1
|
11
|
5834
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 01-31-2014 09:23 AM | |
| 4 | 01-18-2026 04:30 PM | |
| 1 | 01-16-2026 10:03 AM | |
| 2 | 12-02-2025 08:06 AM | |
| 1 | 12-02-2025 08:00 AM |