Civil 3D limited automated annotation. Alignment name can not be mentioned for an axis in a Section View.

I tried to find a fully automated way to annotate alignment axies in section views. Bummer !

I did an internet search. Same problem for other users.

Profile Grade Line Marker Point is capable of using blocks containing whatever info. But all this must be made by hand, one by one !!!

So i used VB.net to create a custom app to solve this problem.

Reads the Civil database and gets all the axies (with or without profile).
Exposes them to the user to select which of them to work with using CheckedListBox.
Creates blocks with the Alignment names.
Assigns them to new MarkerPoint Styles.
Select PGL to create using those new MarkerPointStyles.

I could also create plain autocad points and text for each PGL but these objects do not belong to the section view and that is a disadvantage.

App soon to be completed and available for downloading for Civil 3D 2017.

Autocad custom apps : DBtext rotation angle

Well, always the same problem when it is time to code for angles.
Where is the zero, what direction, what units...

This is for the Autodesk.Autocad.Database.DBtext (single line text)
Here is the code for this case

        Dim AngleIs As Double
        AngleIs = CDbl(Me.tbAngle.Text) 'angle got in Gradians from a text box
        AngleIs -= 100 'Gradians i said
        AngleIs = -AngleIs
        AngleIs = AngleIs * math.PI/200 'Gradians i said

Units : radians
Direction : CounterClockWise
Zero : Positive X axis

Autocad custom apps : Block entities assignment cases

A block can add Entities using two methods.

block.AppendEntity(entity)
Entities created and added immediately in the block, not the BlockTable

block.AssumeOwnerShipOf(CollectionOfObjectIDs)
Entities are already created and exist in the BlockTable. If not copied then after commiting transaction they dissapear from the Model/Paper Space blocks and they "live" only in the block !

I had a hard time trying to configure how to do the second case. Adding existing entities to a block. All examples i found were for the first case.

SAC : strings, enums and math

In Subassembly Composer is possible to refer to the Math library of Microsoft Visual Basic.
But it is not possible to use simple functions such as CSTR or CDBL. No further library can have a reference.

Also Enum.value results to a string value. It can be used in Switch. But it can not be used as a string in a point code ! To do this you must DefineVariable (string) and finally assign the variable to the point Code !

Codes are capable of direct strings or direct string variables. 

VB net Serialization : ShouldSerialize boolean function (not in MSDN)

When serializing a property it is possible to include it or exclude it using the boolean function ShouldSerializeXXXX where XXXX is the exact name of the property !
In MSDN there is no straight reference to it.

eg

<SXS.XmlAttribute(AttributeName:="desc")> Public Property desc As String = String.Empty

Public Function ShouldSerializedesc() As Boolean
   If desc = String.Empty Then Return False Else Return True
End Function

FeatureLine based Corridor Baseline results to hidden Alignment & Profile exposed through API !!!

I develop a custom Civil 3D plugin to export alignments, profiles and corridor cross sections to LandXML.
I used a dwg with various cases for testing.
There was a case of a Corridor that uses a Feature Line for Baseline.
When getting Alignments and Profiles i found out that Civil 3D creates a hidden Alignment and Profile for this Feature Line !!!
The Profile type although unnamed has an enum value of 5 !!!

Civil 3D road corridor with multiple shoulders. One corridor. Two baselines one for each side vs one baseline using conditional subassemblies. Trimble Link Roads export. Leica Infrastructure Link export.

In a road corridor a common case is the existing of both sides different kind shoulders.

A way to deal with it is creating a single corridor with two baselines refering to the same alignment
and profile, one for each side.
Breaking the baselines into multiple regions each one ending to a different shoulder.
So subassemblies are created for one side at a time.
Final count of them is significant less as also regions needed, than if a single baseline would exist for both sides. Also much simpler and understandable.
BUT exporting to a Trimble sensor is a problem. Although user creates a single surface with both sides, Trimble Link exports a seperate RXL for each side.
Also Leica HeXML export breaks apart corridor into two layers, one for each side.

Another way to deal with it is to create a single corridor with one baseline and only one region.
Assembly is based on conditional offset assemblies for different shoulders. So if user declares a target then the correspondent subassembly is applied !
Conditional target needs not to be drawn on the exact trail. Just joining start to end of the certain kind of shoulder.
Caution ! A good practice is to create Targets as properly named Feature Lines and even better in properly named Layers. This approach is time consuming but leads to less mistakes and it is easier to examine and make changes.
Also it is crucial that Sections are added for each start and end of each Conditional Offset Target for each side.
Obviously there is no problem exporting to either sensor.
BUT there is a huge "bug".
In the first case shoulder always changes at the start and end of each region.
But in this case shoulder does not change at the exact station a conditional target is apllied !!!
There is a tolerance which is not user accessible.
I have found that this tolerance is a 0.042m delta East from the edge of the declared target of the Conditional Offset Assembly that has the priority.
This is equivalent to the first case (of two baselines multiple regions) using 4.2cm (East to West) gaps among regions.

So, Conditional Offset Subassemblies is not a solution when strict accuracy is expected regarding stationing performed.

My preffered approach is...
...the first case of Corridor creation
...exporting corridor sections as two LandXML files containing only sections, one for each side, through my custom Civil 3D plugin
...join those two sided sections into a single one, based on stationing using another custom desktop NET software of mine
...finally attaching them to the Civil 3D alignment (and profile) export using my previously mentioned custom software or MS XML editor (not preffered-time consuming) or a Text editor (need to be carefull where to do the join).

But this is also not the best solution if there is a need for ovelapping conditional subassemblies. Leica import for LandXML does not assign C3D point names but custom names based on side and ascending offset position. If names were used points would be joined correct. But in this case sections are totally a mess.
Why overlapping conditional subassemblies ? It is very simple. GOMACO cable extensions !

Worst of all.
Leica Infrastructure Link exporting to HeXML is a perfect LandXML enhancement since points are named -even though using a weird manner- and is LandXML and HeXML schema error free
But in some cases finally unexplained error stops the transformation to RoadRunner job. eg "error found at position 1469"