When configuring the Network Analyst network - Directions>Setting Directions>Attribute Mappings, there is a list of possible road class values, hard coded values within the NA software. For example road segments are classified as: Local roads (1); Highways (2); Ramps (3); etc and it even includes values for stairs, elevators sailing lines... to assist with Directions text.
It would be really useful if user defined values could be added to this list, and returned as part of the directions when a trace is performed. This would allow features along the network to be returned directly from a trace without having to do additional geoprocessing. Specifically, what we would like to do is to integrate bridges into the network, and know (sequentially) along the route where the bridges occur. So, for example, if a trace was done between two waypoints, we could then filter the list of directions, on the directions trace, to get a list of all bridges along the route and at what distance (from the start) they are encountered. The direction text / instruction could be something generic like "continue straight at bridge" - similar to what happens at roundabouts, where it says "continue straight at roundabout".
Adding these "features" as user defined classifications in the underlying network would be really powerful, as users could add whatever they want into the network - bridges, culverts, signs, ... it could even be applied to water networks, where sailors might sail under a bridge or through a lock.
A workaround that we are currently using is to (1) do the trace, then (2) do a spatial query using the resultant trace geometry, and (3) locate the selected features along the trace polyline - to get the distance from start. This is inefficient, and introduces complexities where bridges spatially intersect a trace but may be on an overpass for example and don't actually get crossed for that trace (route).
We have looked into the use of parameters to perform network analysis but this approach to parametrise restrictions - is insufficient because having the ability determine restrictions when restrictions are 'dynamic' in an ESRI Network would prove groundbreaking.