Latest Contributions by BojanŠavrič

Hi @KevinBoes!  Yes, some ArcGIS systems do not allow horizontal and vertical coordinates to be in different units because the scale of tridimensional data is then inconstant. It is one of those “best-practice” rules. Tridimensional data should have the same units in all three directions. In general, when converting only heights and keeping horizontal positions in the same coordinate system, positions do not change. There are some rare cases when data needs to be converted to different positions in order to convert heights. In those, there could be minor differences depending on which transformation path is applied for the conversion. In your case, having data in the NAD 1983 StatePlane Nebraska FIPS 2600 (US Feet) (WKID: 26852) and converting NAVD88 height (m) (WKID: 5703) to NAVD88 height (ftUS) (WKID: 6360), it requires only unit conversion. Transformation NAVD88 Height (m) To USFT (WKID: 110026) would only change the units and your positions should stay the same as they are. So yes, there should be minimal effect or no effect at all with your conversion. Since you are writing a python script to populated height values, you could convert units yourself. If you do, just be careful you apply the correct conversion factor. 😅 If your heights are measured in NAVD88, you should use it. The alternative you talk about in your comment is the ellipsoidal-based vertical coordinate system called NAD 1983 (WKID: 115702). For all work that relies on gravitation and “correct water flow,” you should avoid using ellipsoidal-based systems since they are geometric, and they do not follow the gravitational forces. Best practice is to use some gravity-based system that is compatible with your horizontal positions. In your case, this is NAVD88 system. I hope this helps. ... View more

@JummaKhan: These projected coordinate appear to be in Web Mercator (3857):   ... View more

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

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

@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

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