|
POST
|
UPDATE, 14 June 2016: The 10.4.0 patches for Desktop, Server, Engine, Reader, Server (Linux), Background processing for Desktop and Server should be available later this week/early next week. Engine (Linux) is still being worked on. UPDATE, 16 June 2016: I've verified the 10.4.1 patches except for the Engine (Linux)--it's also still being worked on. We're currently waiting for someone to approve the website page's text, etc. We do not plan to wait for the Engine (Linux) patches before making the rest available. Melita
... View more
06-14-2016
11:27 AM
|
2
|
0
|
5074
|
|
POST
|
Thank you, Royce! I know you've sent me that image before, but I completely forgot about it.
... View more
06-09-2016
03:02 PM
|
0
|
0
|
6944
|
|
POST
|
Add the data (still with unknown/undefined coordinate system) to ArcMap. Add some base data that you know has a good coordinate system. Set the data frame's coordinate system to various "candidate" coordinate systems, like Texas state systems, state plane, etc. The base data will be projected to the new coordinate system. If the base data overlays the "unknown" data, you've found the coordinate system. Neither of those works, by the way, but I think it might be what we call BLM zone 12N (US feet). It could be based on NAD27 or NAD83. Projected coordinate systems, UTM, BLM (US Feet) Melita
... View more
06-08-2016
12:58 PM
|
1
|
1
|
2798
|
|
POST
|
What version are you using? I'm seeing that it was verified as fixed in February but that might have been too late to make the March 2016 2.0 release.
... View more
06-08-2016
12:26 PM
|
1
|
10
|
2937
|
|
POST
|
You can download an Access database of the EPSG dataset and/or various sql or other formats. You have to set up an account, but you'll only get emails about the dataset, nothing else. It's not 100% up-to-date as it's released twice a year (approximately April and October) whereas the online registry continually updates. http://www.epsg-registry.org : to export in GML, SQL, or WKT (WKT for CRS and transformations only) http://www.epsg.org : Access database Melita
... View more
06-08-2016
12:02 PM
|
1
|
1
|
3689
|
|
POST
|
If you don't want to change the coordinate values, use the Define Projection tool, or the data's property page in ArcCatalog. The offset will depend on which transformations were used. Did you set any? You also might have to do an actual conversion in steps like NAD 1983 to NAD 1983 HARN, HARN to NSRS2007, NSRS2007 to 2011. The latter ones may need 10.4 and the ArcGIS Coordinate Systems Data setup. What area(s) does this data cover? And I can suggest some transformations. Melita
... View more
06-07-2016
04:26 PM
|
1
|
5
|
3760
|
|
POST
|
Hey Matt, How are you doing? Well, this is interesting because my original answer was going to be along the lines of we don't normally check whether a WKID is deprecated or not beyond looking up the "current" WKID. However, when I check the EPSG registry, 2877 (NAD83(HARN) / Colorado Central (ftUS)) is still valid, not deprecated. I thought maybe the number had been marked deprecated by mistake but none of the Colorado zones have ever been deprecated. I looked quickly through the deprecation table, but the closest numbers that have been deprecated recently are 2857 and 2867. Both are areas, not coordinate reference systems. Melita
... View more
06-07-2016
03:18 PM
|
2
|
3
|
3689
|
|
POST
|
Royce Jones I'm tagging someone who works in the Honolulu regional office and who's helped me in the past with Hawaiian coordinate system issues. He may not be active on GeoNet though. GCS_Old_Hawaiian or GCS_Old_Hawaiian_Intl_1924 ? This is an odd case. Old Hawaiian uses the Clarke 1866 ellipsoid, which the US Coast and Geodetic Survey, now National Geodetic Survey, used for everything starting in the early 20th century (at least) up until the 1980s. In this case, from what I understand the US military used the International 1924 (aka Int'l 1909 aka Helmert 1909) as the ellipsoid for "Old Hawaiian". So the Int'l 1924 version is very rare, and I've only see data that used it once or twice in over 20 years. If you're using current data, you wouldn't choose either of these. That data would be on NAD 1983 HARN or NAD 1983 (PA11) or NAD 1983 (PACP00) or possibly NAD 1983. "NAD 1983" is getting more and more problematic because keep using it, but their data is really on a more recent realization/re-adjustment. NAD 1983 should be used for data referenced the original, released in 1986, GCS. But tons and tons of data is defined using it. Someone decides which geographic coordinate system to use based on a number of factors: 1. How much data already exists in a particular GCS 2. Customer/partner requests/usage 3. Law or statute 4. Accuracy requirements and/or data accuracy You might be compiling data or a map for a customer or an agency--they'll have chosen what coordinate system they want (hopefully). There are states or local areas which have mandated via statute or law the use of a particular coordinate system or systems. I know of a big federal agency in Alaska which refused to move from NAD27 because they didn't have the money to convert all the existing data. If you've got landuse data and its accuracy is around 1m, then it doesn't matter if which one of NAD 1983, HARN, PA11, PACP00 is used. If you're digitizing a old map, you can georeference it directly to a recent GCS-based PCS, but if you can georeference it to its native coordinate system, that's better. Or if you're using older data, perhaps for comparisons over time, over because it's the only data available, you may need to reproject data from or to the older coordinate system. Esri defined the Albers system, so it was not officially defined by the Hawaiian government. I think they decided to standardize on the zone 4 because the majority of the islands are within zone 4. The big island (Hawaii) is only out by 1.25 degrees. UTM is conformal so shapes are correct. Whether you went with Albers or UTM 5, or a custom transverse Mercator or oblique Mercator should depend more on what type of analysis or purpose that you're doing. Melita
... View more
06-07-2016
02:57 PM
|
2
|
3
|
6944
|
|
POST
|
Well, either the DEM's coordinate system was wrong to begin with--and it could have been simple as someone looking for a definition starting with "E" and not fully reading the name. OR, all your other data is wrong! But since you said that overlaying it with base maps worked fine, that pointed to the DEM having a problem. When data doesn't line up: Data off by less than a meter or so: could be scale / accuracy differs between the two layers AKA aerial photo versus 1:100000 or smaller data Data off by a few meters to a few hundred meters: likely a geographic/datum transformation problem Data off by lots/can't see both layers in ArcMap at the same time: one has missing or incorrect coordinate system 1. Is there a geographic/datum transformation set? Possibly try a different one if one is set but data is off by a meter or so. 2. What happens when I overlay the data with another "trusted" source (like a base map)? 3. Using (2), do the lat/lon coordinates look correct for the "bad" layer (for data in a projected coordinate system)? This check can help identify an incorrect coordinate system.
... View more
06-02-2016
04:21 PM
|
1
|
0
|
3742
|
|
POST
|
You could try changing the coordinate system, ED 1950 UTM Zone 30N, to the DEM, and set a transformation, ED_1950_To_WGS_1984_28 or ED_1950_To_WGS_1984_41_NTv2_Spain_v2 (accuracy is better with the second one). This assumes the DEM's coordinate system was defined incorrectly. ETRS 1989 and WGS 1984 should differ by more than a meter or so. Melita
... View more
06-02-2016
12:38 PM
|
1
|
2
|
3742
|
|
POST
|
You can also try the General Land Office, GIS Maps & Data .
... View more
06-01-2016
01:06 PM
|
0
|
0
|
2885
|
|
POST
|
Hi Shelby, Also posted (with picture) at GIS stackexchange. The Geonet post you mentioned was a specific case where there was a question about the "true" coordinate system of the DEM. Is your DEM from the same source? If you add the original DEM (with a definition of ETRS_1989_UTM_Zone_30N) does it look correctly positioned if you compare it with a base map or other data in "Web Mercator" or geographic coordinates (ETRS 1989 / WGS 1984)? What's the offset of the horizontal line in the polygon to the ridge? What's the coordinate system of the polygon. Specifically, what geographic coordinate system is it using? The offset could be a geographic coordinate system/datum offset. Melita
... View more
06-01-2016
12:51 PM
|
1
|
4
|
3742
|
|
POST
|
I think I understand now. Even though you changed the data frame to NAD 1983, you still need to specify a transformation from NAD 1927 to NAD 1983. ArcMap won't pick a transformation automatically. Any WGS 1984 layer (data) should be around 1 meter or less away from NAD 1983 data so setting a transformation for that pair is sometimes not necessary. Open up data frame properties, coordinate systems tab, Transformations dialog again. If the "Into" GCS is NAD 1983, select the GCS_North_American_1927 entry in the top box and make sure there's a transformation set. I hope this is useful. Melita
... View more
05-27-2016
12:05 PM
|
1
|
0
|
2187
|
|
POST
|
How do they have you changing the data from NAD27 to NAD83? Do you use the Project Tool or the Define Projection Tool or ArcCatalog, data's property page?
... View more
05-24-2016
04:18 PM
|
0
|
2
|
2187
|
|
POST
|
It looks like the transformation is working, but coordinates are not changed. Internally, the grid file's extent is messed up so points in Alaska (for instance) aren't found to be inside the grid file's extent. It affected Alaska because the grid file crosses the date line. Samoa and the Mariana grids were affected because of another check that's done for American Samoa. However, American Samoa's grid file is working (as is Hawaii's).
... View more
05-20-2016
10:51 AM
|
1
|
1
|
5074
|
| Title | Kudos | Posted |
|---|---|---|
| 3 | 2 weeks ago | |
| 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 |