Effects on Horizontal Coordinate System When Changing Vertical Coordinate System?

[KevinBoes]

I work for a wastewater utility in Nebraska, USA, and we are beginning to try to visualize our sewer network data in three dimensions. Our sewer data has historically been projected in the NAD 1983 StatePlane Nebraska FIPS 2600 (US Feet) horizontal coordinate system (WKID: 26852), and while we have used the NAVD88 height (m) vertical coordinate system (WKID: 5703) to store elevation information for this data, we have historically recorded our elevation data in the attribute table rather than updating z-values in the geometry. 

As we have been exploring different ways to visualize the sewer data in three dimensions, we have encountered issues publishing web scenes due to the difference in units between our horizontal and vertical coordinate systems. As a result, we would like to reproject the data into a different vertical coordinate system which uses the same datum as our horizontal coordinate system and records z-values in US Feet. 

Because our sewer data is used by several local entities to support construction and maintenance projects, we are hesitant to reproject our data unless we are sure that doing so will not compromise horizontal accuracy. Within ArcGIS Pro (Version 3.3.0), the horizontal and vertical coordinate systems appear to function as separate entities, where changing one does not affect values stored in the other. Does this appearance reflect what is actually occurring during projection, or might changing our vertical coordinate system impact values stored in our horizontal coordinate system?

[MErikReedAugusta]

Are you sure you need to reproject?  NAVD88 should be in Survey (US) Feet, last I checked.  We use the same here, as well.

I also see that you used to just use the attribute table, rather than the back-end Z-coordinates.  First dumb question: Are you actually using the back-end coordinates, now?

One quick way to check would be with an arcpy cursor:

Change lines 1 & 5 with the path to your FC and the name of your attribute table elevation field, respectively.

fc = 'path_to_your_feature_class'

max_features = 50 # This is just to run on a subset, rather than everything
count = 0         # Subset testing
with arcpy.da.SearchCursor(fc, ['OID@', 'SHAPE@', 'ElevationField']) as cursor:
  for oid, geo, elevAttr in cursor:
    count += 1    # Subset testing
    if count >= max_features: # Subset testing
      break       # Subset testing
    arcpy.AddMessage(f'{oid}\n  ({geo.firstPoint.X}, {geo.firstPoint.Y}, {geo.firstPoint.Z})\n  ({elevAttr})\n')

You should get something like the following:

(I ran this on a test dataset that doesn't have any elevation values populated, so the 0.0 is expected, in my case).
The first row is the actual X, Y, Z of a point in your feature class.  If it's a line or polygon, it'll be the first vertex.
The second row is the Z value in your elevation attribute field.

If that last value on row 1 doesn't match the number that's by itself, then that's your problem.  ArcGIS can only project things based on those hidden back-end coordinates.  Anything in the attribute table is just for show.

[KevinBoes]

Thank you for your quick response!

At this moment, we are not populating our features' z-values with data. While our dataset has z-values enabled, the z-values are populated with the default 0 values, as you show in your screenshot. We are gearing up to incorporate z-values into our systematic data maintenance, and I have created a python notebook designed to populate our existing features with z-values for each vertex based on the elevation data we've been storing in the attribute table.

Regarding the NAVD88 projection, it looks like there is a NAVD88 vertical projection using US Survey Feet (WKID: 6360). If I understand correctly, reprojecting to this would have minimal effects on what vertical information we do have because the datum would remain the same as our current projection (WKID: 5703) while the vertical units would change.

Having said that, would it be better to reproject to a vertical coordinate system with the same datum as our original vertical coordinate system (and the same datum as the data source where we are obtaining our elevation values) or to reproject to a vertical coordinate system which uses the same D North American 1983 datum as our horizontal coordinate system and has US Survey Feet as its units of measurement, if such a coordinate system exists?

[MErikReedAugusta]

NAVD88 is the equivalent vertical projection to NAD83's horizontal.

Worth noting, they're both in the process of being replaced, but not quickly: https://geodesy.noaa.gov/datums/newdatums/index.shtml

[BojanŠavrič · Accepted solution]

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.

[MErikReedAugusta]

I completely forgot that there's also a meter-based NAVD88, and my eyes skipped right over that part of the OP.  Nice catch, and great general information!

[KevinBoes]

@BojanŠavrič and @MErikReedAugusta Thank you both for your help! We feel much more confident now in reprojecting to NAVD88 Height (ftUS).