SnakeGrid - How is OpenRail / ASD working with this?

Question

HS2 is kicking off and I imagine that OpenRail would need to work with SnakeGrid... but this type of projection is not included in the Ref tools, which include the ellipsoidal GCS transforms. 
 If I understand correctly, SnakeGrid is a transform that is based on a coordinate system that is aligned with a linear track like a rail/road way or tunnel, designed to reduce distortion along the 'chainage' axis. I imagine the 'track' or 'chainage' or 'y' axis will be very accurate, and the further away points are perpendicular to the track (x or z axis) the more distortion there will be. I suppose that this is pretty important and removes a lot of guesswork / back-calculating for anything to do with railway systems. 
 OTOH, there are a lot of other assets on the track alignment that will be based on 'cartesian' measurements based on local control points forming local coordinate systems that are 1:1 with surveyed measurements... and the way your CAD system typically stores and calculates distances. 
 So, if you are working in Bentley Map or some kind of GIS app, you will need to transform the ALL the geometric contents of the dgn file to a state or national projection system which is based on an ellipsoidal (GNSS) coordinate system... and accept that when you measure between two far flung points there will be some discrepancy between the two systems due to the way they are transformed/stretched to fit. 
 A train station platfom may be measured as 200m in the local coordinate system but measure slightly different in the other, which is a bit annoying.. if you are working on anything track-related. 
 
 1. How does this manifest itself for OpenRail or Bentley Map users? I imagine that the OR users would be working in SnakeGrid projection mode? All survey CAD files (based on local or GNSS coordinate systems) would have to be fed through something like SnakeGrid Transformer which would spit out the transformed geometry for use in OR. 
 
 They would place their rails and sleepers and OHE pylons and drainage using the regular Eastings and Northings and Mstn would not have to adjust/transform the readouts and lines would be straight and distances cartesian...? 
 Each file would have a limited SWA and limited to say 4.29km so as to avoid confusing Mstn's solids kernel / Dynamic Views engine. So, there would be an array of seed files provided along the track between London and Birmingham etc with the correct GO= coordinates etc? 
 No need to use a Custom GCS to reference the adjacent files in the mosiac. As long as the user does not try to measure anything outside of the SnakeGrid corridor, everything should be accurate enough? 
 Anything generated by the ABD or ProStructures users working on point assets would need to be transformed back into the SnakeGrid coordinate system before it can be Ref attached. 
 
 2. But for the users working on the point assets like stations, underpases/bridges etc, I imagine that the users on Aecosim Station/Building Designer etc would need to be working in a local coordinate system that is closely linked to locally surveyed information and point clouds etc. 
 
 They would place their building elements like walls and beams using Eastings and Northings based on the local coordinate system...? 
 Anything generated by the OpenRail or Bentley Map ( and ABD/ GC and PS for on track-related elements ) users would need to be transformed back into the local coordinate system before it can be Ref attached in ABD etc...? 
 Again, no need for a Custom GCS that would have to transform/warp the geometry every time a reference attachment is loaded; the next Ref file 4.29km or so up/down the track would also need to be transformed into SnakeGrid projection then re-projected to the local coordinate system so that all the geometry / vertices align properly at the boundaries between ref attachments? 
 
 It would seem that a lot of duplicate information is unavoidable and needs to be managed by ProjectWise. There is also the question of transforming all geometry types (especially solids) properly. The dhp11 mdl plugin only handles a subset of Mstn's elements. Not surprising since they are an external dev. Point clouds and Reality Meshes as well one day? Hopefully, this is currently being addressed. 
 It would be good to integrate the transform algoithm into Mstn's i.model / ISM publishing tool. 
 I also wonder if something like i.Model 2.0 would be a good platform for storing and managing all this 'duplicated' or 'proxy' information?

Jim Turner · Answer

There is a recent development which will enable the HS2 SnakeGrid to be available within the standard GCS library. This will initially be rolled out to Microstation and from there to further products. This will reduce the need for data duplication and enable, for example, web map services (WMS) to be re-projected on-the-fly to HS2 SnakeGrid and GCS transforms to the SWA. 
 This will be applicable to HS2 phase 1+2a; the GCS uses an NTv2 transform + Transverse Mercator projection. It will be available in Microstation update 13 however will require manual installation of the transformation files. MS CE Update 14 will have the files distributed. 
 Two GCS will be available: HS2_Snake_2002 and HS2_Snake_2015 . These are essentially the same GCS - the difference is the transformation used for conversions into other GCS: 
 
 Use HS2_Snake_2002 (HS2TN02) when converting to/from OSTN02 . BritishNatGrid 
 Use HS2_Snake_2015 (HS2TN15) when converting to/from OSTN15 . BritishNatGrid 
 Use HS2_Snake_2015 (HS2TN15) when converting to/from ETRS89 OS Net v2009 latitude/longitude (current OS Active Network)

Note that the HS2TN02 transform is equivalent to using the HS2P1+14 SnakeGrid parameter file. If converting into lat/lon using HS2TN02/HS2P1+14 then these coordinates are only compatible for use with the legacy OS Active Network (OS Net v2001).