POST
|
Hi Joshua and Dan, Thanks for your responses which prompted me to check things out a bit more. I think I may have figured out what is going on and you could say it is a result of my ignorance for how ArcMap handles the loading of a layer into a session with a different coordinate system - specifically geographic coordinate systems. In this case, I opened a new ArcMap session and loaded the point feature class using the NAD83 geographic coordinate system which becomes the default. I then loaded the point feature class with the NAD27 geographic coordinate system and up pops a window called "Geographic Coordinate Systems Warning". I knew this warning was appearing because I was now attempting to load a layer with a different coordinate system, but I mistakenly assumed that by closing this dialogue box without doing anything that ArcGIS would automatically take the second feature class (NAD27) and "project it on the fly" for display into the coordinate system (NAD83) of the first feature class. Not so, the points in the second layer lay exactly on top of those in the first layer. In the past when I have loaded two feature classes (one first followed by a second) into ArcGIS with two different projected coordinate systems, I would get this same warning and close it, but ArcGIS would project the second feature class on the fly into the coordinate system of the first feature class. This time, since I was dealing with geographic (un-projected) coordinate systems, it finally occurred to me that I should try clicking on the Transformations button which brings up a new window with a dropdown containing available transformation options. If I explicitly chose the correct transformation NAD_1927_To_NAD_1983_NADCON, then the layer be loaded was correctly "re-projected on the fly" for the on-screen display. At this point the points in the newly added NAD27 layer were displayed as I expected with a ~23.5m offset from those in the NAD83 layer. A few thoughts and observations. 1) I am not sure if this behaviour is consistent, but it appears that ArcMap (v 10.5.1) will take layers in different projected coordinate systems and re-project them on the fly without user intervention but will not do so (without the user intervening and specifying a transformation) between layers with geographic coordinate systems. 2) The above behaviour is particularly tricky if one is generating point event layers in different geographic coordinate systems. In this case, corresponding points in the different event layers (+ different geographic coordinates) will appear identical and the user is not given any kind of transformation warning. In other words, the user is blind to the fact that ArcGIS will not re-project the points appropriately based on the specified geographic coordinates for event layers. 3) When testing, I tried using different flavours of the NAD83 and NAD27 geographic coordinate systems and noticed that transformation options between some of them are not available or listed from the dropdown (in the Geographic Coordinate System Transformations dialogue which comes up after pressing the Transformations button from the Geographic Coordinate Systems Warning dialogue). Unless you have the parameters to create your own custom transformation, ArcGIS will not be able to transform and re-project on the fly between certain geographic coordinate systems. Not sure if this is common knowledge but something to be aware of when dealing with geographic coordinate systems. Thanks, Chris
... View more
12-17-2018
11:53 AM
|
1
|
0
|
643
|
POST
|
Hello, I have a table with 7000 records representing point locations spread over a 70 km east-west and 50 km north-south extent. The table has coordinates in decimal degrees for each record contained in 2 fields called Longitude and Latitude. Because the source data does not provide any indication of which geographic coordinate system the points use, I decided to try testing a few common ones to see which system seems to line up best with my other layers. I am using ArcGIS 10.5.1 and my tabular data is contained in a file geodatabase. Therefore I added the table as 3 separate point event layers and chose geographic coordinates using WGS84, NAD83 and NAD27 to test things out. However, I was surprised when I zoomed in as much as possible, that there was absolutely no difference in where the points were displayed between all three coordinate systems. The points are simply meant to fall within property polygons, and they do seem correctly located, but I was expecting to see differences between the geographic coordinate systems - but I do not. I saved each of the 3 point event layers to a separate point feature class within the file geodatabase just to be sure the even layers were written permanently to file in the 3 different geographic coordinate systems. There is also no variation in corresponding point locations in these 3 feature classes. I know there should be a significant difference between NAD83 and NAD27 datums - on the order of 10 to 30 metres in my map area, but the points have identical positions. Is this an error or is there something I am missing? Should there not be a difference in where the points are displayed when using different geographic coordinate systems for an event layer. Thanks in advance, Chris
... View more
12-17-2018
08:20 AM
|
0
|
3
|
841
|
POST
|
Hi George, The question has been reposted to the Esri Technical Support section Added that I am using ArcGIS 10.3.1 for desktop and the source files involved in the relates and joins are shapefiles and DBF tables. Also stressed that in my case, I re-set the data source because the source data file was re-named (not sure if this makes a difference compared to just a change in the location of the data source – without a name change - from one directory or geodatabase to another).
... View more
11-15-2017
12:07 PM
|
0
|
1
|
754
|
POST
|
Hi, Has anyone found a work around for changing the data source of a feature class, layer or table involved in one or more joins or relates such that the data source of the joins and relates are also updated automatically. From what I have encountered, there is a bug (bug number NIM058535) in which a repair to the data sources in a MXD is not reflected in any joins or relates with the affected tables, or feature classes. In my case, I have MXD workspaces that contain many joins and relates and the source data files involved have changed names, so by setting the data source to the data source with the changed name, I loose all my relates and joins. Other than manually re-creating any joins or relates lost after a data source has been changed, has anyone found a work around to update joins and relates automatically with the new data sources. Note, I am running ArcGIS 10.3.1 (desktop) and the source files in the relates and joins are shapefiles and DBF tables. Supposedly the bug NIM058535 I referred to was fixed at version 10.1 according to George Thompson who is with ESRI. I must stress, that the names of the source files have been renamed and that I have reset the data sources in my MXD to the re-named source files. By re-setting the data source to the renamed files, the source links in the MXD are repaired but the joins and relates that existed before hand do not follow through to the new source files. As a matter of fact, if the source files with the original names are still in their original directories, the joins or relates will still refer back to the old data source even though the old data source is no longer loaded into my table of contents in the updated MXD with "repaired" data source links. Thanks for any ideas Chris
... View more
11-15-2017
08:44 AM
|
0
|
4
|
1448
|
Title | Kudos | Posted |
---|---|---|
1 | 12-17-2018 11:53 AM |
Online Status |
Offline
|
Date Last Visited |
11-11-2020
02:25 AM
|