|
POST
|
Hi @Esther_Morrow! Your difference in location is caused by using degrees-minutes-seconds format as they would be decimal degrees. 0 deg 18' S is not -0.18 deg, but -0.3 deg; and 130 deg 40' E is not 130.40 deg, but 130.66666667 deg. If I use correct decimal degrees in ArcGIS Pro, the point appears on the same location as on Google Earth. I hope this helps!
... View more
04-27-2023
02:09 PM
|
4
|
1
|
2046
|
|
POST
|
Thank you, @Bernd_Loigge, for your question! The image of the GCS on the slide 13 is correct and intentional. Let me explain it… A geographic coordinate system is defined on an ellipsoidal surface. The center of the ellipsoid is still where the polar axis intersects the equatorial plane. Latitude of the point P is measured between the equatorial plane and the normal on the ellipsoidal surface at the point P. In general, normals on an ellipsoidal surface do not go through the center of an ellipsoid. They intersect the polar axis below or above the center depending on whenever the latitude is positive or negative. Exceptions are points on the Equator and at the pole. Their normals go through the center. The distance between the point P and where the normal intersects the polar axis (Q) is called the transverse radius of curvature. If Earth’s model would be a sphere instead an ellipsoid, then all normals would go through the center of the sphere. I hope this helps, Bojan
... View more
09-05-2022
01:40 PM
|
1
|
0
|
994
|
|
BLOG
|
The latest information we have is that NSRS Modernization has been delayed and "the new estimated timeline for release of the modernized NSRS (data + limited tools) is mid-2025." NGS also has a set of instructions Get Prepared, which might help your users to start getting ready for the change. They may also explore and prepare their datasets in historic NAD realizations and see how much their data lines up in the current NAD 1983 (2011) realization. This way they could identify potential discrepancies, if any, in their datasets. NCAT tool allows to transform points/data via all NAD realizations, NAD27 -> NAD83 -> NAD83(HARN) -> NAD83(FBN) -> NAD83(NSRS2007) -> NAD83(2011). The same data conversions through the realizations can be done in multiple steps with NADCON5 transformations in ArcGIS. Those transformations become active once the ArcGIS Coordinate Systems Data is installed with the core software. I hope this helps.
... View more
08-29-2022
03:07 PM
|
0
|
0
|
606
|
|
POST
|
@N_W_S_E To see the difference between the two transformations you mentioned, you can select one and then click details (green link below selected transformation path): This will open you a transformation details window with all the transformation info including the areas of use and accuracy. As you can see in the details above, both transformations should be used to transform USA data. For suggestions and advice, I will let @MelitaKennedy to reply.
... View more
08-05-2022
09:51 AM
|
0
|
0
|
5200
|
|
POST
|
@Jaslam, We look at your workflow and I might be able to provide you with an explanation. These differences are caused by a resampling technique to source the projected rasters. In your case, this would be the Nearest Neighbor method. Since your USGS_1_n45w114_20130911 and ESRI_shape have different extents and raster grids, when they are projected to WGS84 Web Mercator, their projected grids aligned differently with the source raster grids and the Nearest Neighbor method picks different pixel to source its raster value. E.g. take your point with 3071.913 height from ESRI_shape_ProjectRaster layer and check all nearest 9 pixels round that point in USGS_1_n45w114_20130911. One of the pixels will have the height of 3032.042 as it is in USGS_Proj_NAD_1983_To_WGS_1984_5 layer. Differences vary based on the elevation changes in the point’s neighborhood. Some are higher, some lower, and some are exactly equal. Similar effect, but with a bit smaller differences happens with other resampling techniques for the same reason. Please note that the Nearest Neighbor method is inappropriate for elevation surfaces. For more details, please check Project Raster online documentation page. I hope this helps, Bojan
... View more
07-26-2022
11:41 AM
|
1
|
0
|
2324
|
|
POST
|
Please note that we added support for vertical transformations between CGVD28 and CGVD2013 in ArcGIS Pro 2.9. You will need to install supplementary coordinate system files, which include CGG2013 and CGG2013a geoid models and other conversion grid files. This allows you to convert heights between NAD83CSRS and CGVD2013. I hope this helps, Bojan
... View more
07-15-2022
01:14 PM
|
1
|
0
|
850
|
|
POST
|
Hi @Jaslam, I might have an answer for you, but I need a bit more information before I write a proper reply. In which Projected/Geographic and Vertical Coordinate Systems is your Raster exported from USGS and Raster exported from ESRI_layer data? I assume your target VCS for both datasets is WGS 1984, WKID::115700. Is this correct? Thanks, Bojan
... View more
07-15-2022
01:09 PM
|
1
|
2
|
2377
|
|
IDEA
|
Please note that we added support for vertical transformations between CGVD28 and CGVD2013 in ArcGIS Pro 2.9. You will need to install supplementary coordinate system files, which include CGG2013 and CGG2013a geoid models and other conversion grid files. 3D and raster data can be converted with Project and Project Raster tools. I hope this helps, Bojan
... View more
07-15-2022
12:20 PM
|
0
|
0
|
1575
|
|
POST
|
Please note that we added support for vertical transformations between CGVD28 and CGVD2013 in ArcGIS Pro 2.9. You will need to install supplementary coordinate system files, which include CGG2013 and CGG2013a geoid models and other conversion grid files. I hope this helps, Bojan
... View more
07-15-2022
12:17 PM
|
0
|
0
|
5620
|
|
POST
|
@GIScs Yes, we do support conversion of heights between CGVD28 and CGVD 2013 and CGVD 2013 (CGG2013a). You can use Project tool with Vertical option turned on, or you can do it on-the-fly in ArcGIS Pro. Please note, you will need to install supplementary coordinate system files, which include CGG2013 and CGG2013a geoid models and other conversion grid files. I hope this helps, Bojan
... View more
07-15-2022
12:09 PM
|
1
|
0
|
5620
|
|
IDEA
|
Hello @GrantHopkins1, I can imagine how difficult it is to know all little details about transformations and coordinate systems. Every country does this things a bit differently, which does not help GIS users. All that knowledge comes with experience and, with time, it gets easier. In cases when there is no transformation to desired GCS listed in the Geographic and Vertical Transformation Tables, I would suggest you reach out to your local Esri's distributor. I expect they would know any specifics for the country and have contacts to the local agencies. They can work with the agencies to obtain necessary information about possible transformations and clear any license restrictions. Once they obtain the information, they can contact us with details and we implement transformations. For the Ontario province, we do have definitions for transformations to NAD83 (CSRS) v3, WKID::8240, provided by NRCAN (I know this is not what your are looking for but it might help.): Due to license restrictions at the time we added these definitions into ArcGIS, we do not distribute the necessary NTv2 files with the ArcGIS Coordinate Systems Data software component. If you wish to try them out, you can download them from the NRCAN website or from here and add them to a specific CoordinateSystemsData\pedata subfolder on your machine. Files are sorted into folders by transformation method name, such as NTv2 or vertical\geoid. For these four transformations, you should add the NTv2 files to <System Drive>\Program Files (x86)\ArcGIS\CoordinateSystemsData\pedata\ntv2 folder. Please contact your local distributor if you have any troubles or need more detailed instructions. To comment on @MattCriel's suggestion above. ArcGIS Pro is limited to 2-step transformation paths when projecting data on-the-fly. Unfortunately, this results in transformation paths that might not be geodetically correct (aka transforming between Canadian GCS-es via world-wide WGS 1984 GCS). This happens often when country has several GCS-es in use and one needs to transform/project data in several steps via multiple GCS realizations. For some applications, transforming data via WGS 1984 works OK, but I would not recommend it in general. I hope this helps, Bojan
... View more
06-22-2022
11:52 AM
|
0
|
0
|
2093
|
|
IDEA
|
@MatthewCriel Thank you for submitting your idea. I believe ArcGIS Pro already supports several transformations between NAD 1983 (CSRS) and WGS 1984 geographic coordinate systems. If I set the map to NAD 1983 CSRS UTM Zone 16N (WKID::3160), I get the following possible transformation paths: In which coordinate system is your Canadian CSRS data? If it is using one of the NAD 1983 (CSRS) realizations (e.g. NAD83 (CSRS) v6, WKID::9644), we do not have any defined because none of the are registered with EPSG nor we can find them on Natural Resources Canada's website.
... View more
04-06-2022
11:00 AM
|
0
|
0
|
2194
|
|
IDEA
|
Hi @CarlinAndrus: This may not be the exact point of this thread, but one way to address this issue is also correcting geographic coordinate system (GCS) definition in which your dataset is defined, GCS_NAD83_1986. Original NAD 1983 GCS has many aliases that are used across the GIS community. One of them is probably also GCS_NAD83_1986, which is not in our database of synonyms. Therefore, software is treating this definition as a custom GCS, which does not have any predefined transformation to other GCS in the list of predefined GCS-es. The result is a missing transformation path and the warning. One way to fix this is to use Define Projection tool and correct GCS definition of your dataset to NAD 1983. This will resolve the conflict and transformation will no longer be required in your case. You can do this once on the dataset and it will fix it for every map in the project if that map is using "fixed" dataset. In case you cannot change GCS definition or you wish to keep it, you can also create a custom transformation between GCS_NAD83_1986 and NAD 1983. You can do this with Create Custom Geographic Transformation tool and providing appropriate transformation between your custom GCS of your data and GCS of your map. I hope this helps...
... View more
09-23-2021
05:29 PM
|
0
|
0
|
2151
|
|
POST
|
There are couple ways you can do this... I suggest the following workflow by customizing one of the existing projected coordinate systems designed for the world maps. Go to Map -> Properties -> Coordinate Systems In XY Coordinate Systems Available navigate to Projected Coordinate System -> World This is the list of predefined projected coordinate systems (PCS) that one can use to display whole world. Most of them are centered on Greenwich, but you can easily change that. Right click on, e.g. Natural Earth (world), and select Copy and Modify... Change the Name of your new PCS and adjust the Central Meridian value to something like 150 degrees. Save -> OK. Just a tip or two on map projections (PCS) that are good for the world maps... For thematic and general maps, select one with curved edges (pseudocylindricals), use cylindricals (aka "map in the box") for some rare phenomena that is based on longitude, and choose Mercator only if you are creating a sea navigation chart. Here is the list of Supported map projections. Each has Usage section, which gives you hints on appropriate usage. I hope this helps...
... View more
09-06-2021
11:10 AM
|
0
|
0
|
2536
|
|
POST
|
@Suedietrich wrote: When I use projection, the data doesn’t align perfectly with the orthoimagey which uses NAD 1983 (2011) StatePlane New York East FIPS 3101 (US Feet). If your data does not align perfectly, sounds to me that there was/is missing (or different) transformation path in your workflows. Add your GPS data and the orthoimagey to your map in ArcGIS Pro and set Map's coordinate system to NAD 1983 (2011) StatePlane New York East FIPS 3101 (US Feet). Go to Transformation tab and try the first three possible transformation paths (<None>, WGS 1984 (ITRF08) To NAD 1983 2011, WGS 1984 (ITRF00) To NAD 1983 2011) and see if any of them aligns your data perfectly. The one that does is probably the path that was used by the Collector when converting your data to WGS84 Web Mercator (auxiliary sphere). My guess would be that the Collector probably used WGS 1984 (ITRF00) To NAD 1983 2011 or <None>. Then use Project tool, as @DanPatterson suggested, to convert your GPS data back to NAD 1983 (2011) StatePlane New York East FIPS 3101 (US Feet) and use the same transformation path that the Collector used. I hope this helps, Bojan
... View more
08-25-2021
03:07 PM
|
1
|
1
|
10773
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 07-15-2022 12:09 PM | |
| 1 | 05-13-2025 08:22 AM | |
| 1 | 08-25-2021 02:30 PM | |
| 2 | 08-07-2024 09:22 AM | |
| 2 | 06-03-2024 12:50 PM |
| Online Status |
Offline
|
| Date Last Visited |
a week ago
|