Posted on

Controlling Displayed Precision via Parameters in Visual Report Designer

Controlling Displayed Precision via Parameters in Visual Report Designer

When creating a report template using Visual Report Designer, it is sometimes impossible to know what precision an end user may want to use to display a particular value. In these situations, you can use report parameters to allow the user to select the desired precision. While it is not difficult to do this, it does require a little bit of extra effort.

First, let’s establish our goal here: We are attempting to format a numeric value (decimal) with a fixed number of decimal places in the range of 0 to 6. For example, if we have the value 1.23456789, we might want to display it with 2 fixed decimal places, resulting in the text ‘1.23’.

To accomplish this, we need to understand a little about ‘Format Strings’. Visual Report Designer uses .NET format strings for formatting values…Microsoft has given us a good description of how to form both standard and custom format strings on the MSDN website. Typically, when you are creating a report in Visual Report Designer, you will simply be using the format string editor built in to the application user interface:

Visual Report Designer Format String Editor

 

Selecting a value here will place a string (text) in the ‘Format String’ field of the Task Pane from which the dialog was launched:

Visual Report Designer - Sample Formatting String

This value may be copied and reused, however, the format string is static – i.e. we cannot change it as the report is running. To do this, we will need to take a different, less direct approach.

First, we’ll clear the format string above from our label properties as we do not want it to ‘stack’ on top of what we are about to do.

Visual Report Designer - Cleared Formatting String

Next, we need to create the parameter which will be used to specify the desired precision. To do this, we right-click on the ‘Parameters’ collection at the bottom of the field list and select the ‘Add Parameter’ context menu command:

Visual Report Designer - Add Parameter Context Menu

This will launch the ‘Add New Parameter’ dialog in which we will define our parameter:

Visual Report Designer - Add New Parameter

As shown, we have configured the parameter called ‘Precision’ to be an integer, and we set the parameter so that the user must choose a value from the pre-defined, static list as shown. This prevents the user from entering a value that is out of the allowable range.

Next, we need to use an expression (via a calculated field) in order to actually construct and apply the format string. To do this, we right-click on the entity that contains the field we want to format and select the option to ‘Add Calculated Field’:

Visual Report Designer - Add Calculated Field Context Menu

This creates a calculated field called ‘calculatedField1’ and sets the data binding so that this field will be able to access fields defined for the current entity type:

Visual Report Designer - Calculated Field in Field List

We can now right-click on this field and select ‘Edit Calculated Fields’:

Visual Report Designer - Edit Calculated Fields Context Menu

This will bring up the ‘Calculated Field Collection Editor’:

Visual Report Designer - Calculated Fields Collection Editor

Here we can rename the field, change the field type, define an expression, etc. First, let’s rename this field to ‘FormattedLength’, then define an expression to perform the actual formatting operation (click in the expression field and then on the button that appears to access the ‘Expression Editor’.

Visual Report Designer - Expression Editor

For our current purposes, we will be able to use a simple format string for ‘Fixed Decimal’. For 2 fixed decimal places, the format string would be ‘F2’; for 5, it would be ‘F5’. This pattern is advantageous in that we already have a numeric (integer) parameter that holds the precision value…all we need to do is append an ‘F’ in front of the parameter value to get the desired format string. The other portion of the expression that we will be adding is the part that actually retrieves the desired source value and then applies the format string – we do this using the ‘_FormattedValue’ function:

Visual Report Designer - Expession Editor - Formatted Value Function

Double click on this function to insert it into the expression editor box.

To reference the value source field, we set the cursor in the proper position (immediately after the ‘(‘ character in the ‘_FormattedValue’ function call) in the expression editor, then select the ‘Fields’ category and double-click on the desired field:

Visual Report Designer - Expression Editor - Polyline Loop Segment Length Field

After setting the value source, we next have to assemble the format string. We start by positioning the cursor immediately after the first single quote character following the ‘,’ in the ‘_FormattedValue’ function call. We then add the single character ‘F’. Next, we use the arrow keys or the mouse to relocate the cursor to the right of the second single quote character now encompassing the ‘F’…we can add a space if we like, and then a ‘+’ character (no quotes). We can optionally add another space and then the parameter reference. To reference the parameter, we select the ‘Parameters’ category and double click on the desired parameter (with the cursor in the correct position in the editor of course…).

Visual Report Designer - Expression Editor - Precision Parameter

The end result should look similar to this:

Visual Report Designer - Expression Editor - Expression

From here, we close the commit the changes and close the editor. We then must set the proper binding on our label in our report so that it calls the calculated field instead of the ‘Length’ field the label was previously bound to:

Visual Report Designer - Argumented Label Tasks - Bind to Calculated Field

We can now test our results. In your DWG, make sure you have an entity to test against…in this case any polyline with at least a few segments…then ‘preview’ your report. In the ‘Report Parameters’ tab of the ‘Edit Queries’ dialog, you will see the parameter which controls precision…set this to the desired value and click the ‘OK’ button…

Visual Report Designer - Edit Queries - Set Precision Parameter

The results in the generated report document will look similar to this:

Visual Report Designer - Generated Report Document Fragment - Formatted Values

If we repeat with a different setting for the parameter, we will see the results change accordingly:

Visual Report Designer - Generated Report Document Fragment - Formatted Values

Posted on

Creating a Slope Stake Notes Report Using Visual Report Designer (for AutoCAD Civil 3D)

Creating a Slope Stake Notes Report Using Visual Report Designer (for AutoCAD Civil 3D)

Visual Report Designer (for AutoCAD Civil 3D) includes several features that makes the process of creating a custom slope stake notes report very easy.

We’ll first start with a new report document:

C:\Users\adam\AppData\Local\Temp\SNAGHTML8b523735.PNG

From here, we will add the necessary ‘detail report bands’ to access the corridor section data we need:

C:\Users\adam\AppData\Local\Temp\SNAGHTML8b53928f.PNG

Ultimately we are looking for the ‘Aggregated Section Points’ entity. This is a special entity which organizes all points in a section (filtered by code) into collections that represent up to a fixed number of points on each ‘side’ of center, plus a center point (if available) in the first row only.

C:\Users\adam\AppData\Local\Temp\SNAGHTML8b656cdf.PNG

As you move away from the center point, the offset becomes increasingly larger in the direction you are moving. If too many points exist to contain in a row, another entity is created for the second row, and so forth, until all valid points are accounted for. Each row/entity is accessible as a single row in Visual Report Designer, and the fields of each point contained therein are accessible via the Aggregated Section Points entity fields (using an index to access a specific point/column). The number of columns in a row is controlled via a query extension property as we will later see.

The Aggregated Section Points entity contains several pertinent fields that we will want to access:

C:\Users\adam\AppData\Local\Temp\SNAGHTML8b5c4156.PNG

For most slope staking notes reports, we will need the point code(s), offset, elevation, and slope from previous point. There are a few nuances that must be accounted for here:

  1. If we simply use the ‘Codes’ field, we will get ALL of the codes on a specific point…typically we would just want to see only those codes which pass the point code filter check, so we will instead use the ‘FilteredCodes’ field.
  2. If we want the point elevations relative to the center of the section (relative to the baseline/profile grade line), we can use the ‘Elevation’ field; if instead we would like the absolute elevation in the project/DWG coordinates, then we use the ‘Elevation’ field located under the ‘Location’ composite entity field:
    C:\Users\adam\AppData\Local\Temp\SNAGHTML8b602a6f.PNG

Now that we have the necessary detail report bands and we know which entities we need to generate the report, we can start adding content to the appropriate band. This is done using a simple drag/drop operation – i.e. drag the desired fields/properties into the appropriate detail band in the report (we’ll do this once for each field to make a complete column):

C:\Users\adam\AppData\Local\Temp\SNAGHTML8b684b7d.PNG

Now that we have labels in the report which are bound to the desired fields, we must tell the labels specifically which point column we want to access. This is done via the ‘Arguments’ property of the labels, which is accessible via the task list (select the label and click on the ‘>’ icon in the upper-right corner), and also via the label properties if you have the ‘Property Grid’ window open and visible (with the label selected – this will be necessary if you dragged the ‘Location.Elevation’ field into the report as the Arguments property is not shown in the editor for the label associated with this field). For each label, we will add an ‘integer’ argument which represents the column index we want to access. For the center column, the index is zero (0) as shown below…indices on the right side are positive starting at one (1), and negative on the left starting at negative one (-1). Set this property for each of the labels:

C:\Users\adam\AppData\Local\Temp\SNAGHTML8b6bf0f6.PNG

Once the center column indices are set, we should also set the formatting for each label. The label bound to the ‘FilteredCodes’ field doesn’t require any special formatting (unless you want to change text style, background color, etc). The ‘Offset’ and ‘Location.Elevation’ values should be formatted to a fized number of decimal places, let’s say 3. To do this, set the ‘FormatString’ property of each associated label as shown below:

C:\Users\adam\AppData\Local\Temp\SNAGHTML8b78c61e.PNG

Last, we will want to set the ‘Slope From Previous Point’ to display as a percentage with a fixed number of decimal places (2). The proper format string is shown below:

C:\Users\adam\AppData\Local\Temp\SNAGHTML8b7b2c70.PNG

After setting up all of the fields for the center column, we will now copy the labels and repeatedly paste into the detail band to create the additional columns (we could also repeat the process of dragging the fields one at a time and then setting all of the properties). Let’s create 3 columns to each side of center:

C:\Users\adam\AppData\Local\Temp\SNAGHTML8b728682.PNG

Note that some resizing/repositioning of the labels in each column group will likely be necessary to get the labels to all fit within the margins.

Now that we have all of the labels in the detail band, we need to set the column indices to the appropriate values. Remember, if you used the ‘Location.Elevation’ field for the point elevation you will need to use the ‘Property Grid’ to set the value of the ‘Arguments’ property:

C:\Users\adam\AppData\Local\Temp\SNAGHTML8b82cc67.PNG

This method is actually a bit quicker for the other labels as well, but you are of course able to use the task pane for this task if you prefer… For our report, the column indices are (in order from the left side of the detail band to the right): {-3, -2, -1, 0, 1, 2, 3}

Now that we have the indices all set to the proper values, we will need to add a header to the ‘Sections’ detail band to indicate what stations we are looking at in the report. To do this, simply drag the ‘Station’ field from the ‘Sections’ entity in the field list and drop it somewhere in the middle of the ‘Sections’ detail band:

C:\Users\adam\AppData\Local\Temp\SNAGHTML8b875eb1.PNG

Once the label is created, we once again need to set the format string (otherwise the value will be shown as a decimal number, not a ‘station’):

C:\Users\adam\AppData\Local\Temp\SNAGHTML8b89e8e6.PNG

We can also resize the label using grip edits, and can change the font, text size, etc:

C:\Users\adam\AppData\Local\Temp\SNAGHTML8b8b7e2c.PNG

Last, we need to collapse any unused detail bands to prevent the creation of undesired whitespace in the generated report document:

C:\Users\adam\AppData\Local\Temp\SNAGHTML8b8cb92c.PNG

At this point we are ready to test the report against a corridor model. Before previewing the report, it is always a good idea to save… use the icons in the ribbon bar in the Visual Report Designer application window to do this.

To begin the ‘preview’ process, click on the ‘Print Preview’ tab at the top left side of the Visual Report Designer application window:

C:\Users\adam\AppData\Local\Temp\SNAGHTML8b8f0b79.PNG

When we initiate the ‘preview’ process, we will be shown a dialog in which we can set the query details to choose which entity (or entities) we want to run the report against, and where we can set certain key settings which will be necessary to properly generate the report:

To select which corridor to run the report on, we can use the ‘SelectionSet’ field…click on field to access a set of buttons which will allow you to either select the entity from a list or graphically from the drawing. To run on all corridors, you can skip this step and just leave the selection set empty.

Chances are, there are more point codes in your sections than you will want to show on your slope stakes report. To control which points are used, we must set a filter. To access the settings for this, first expand the ‘Aggregated Section Entities’ property group, and then click on the ‘Aggregated Section Points Entity Options’ property. A button will appear in the value field for this property…click on this to access the ‘Edit Aggregated Section Points Entity Options’ dialog:

C:\Users\adam\AppData\Local\Temp\SNAGHTML8b95c640.PNG

In this dialog, we will set the right and left filters independently. For our corridor, we have the following points:

The codes we want to use are highlighted. We will set these as a pipe character (‘|’) delimited list (no spaces), and will use the same filter list for each ‘side’:

The remaining two properties MUST be set to match the number of columns to each side of ‘center’ you designed your report to show. In this case the values are set correctly by default. A value which is too large will cause points to be ‘lost’ as the additional columns are not represented anywhere in the report; a value which is too small will leave columns in the report unused, wasting space in the generated report document.

Once the settings are properly configured, the report can be generated. The result will look similar to this:

C:\Users\adam\AppData\Local\Temp\SNAGHTML8b9d8921.PNG

From here we are able to export as a PDF, XLS/XLSX file, etc, as well as directly print the document.

Before closing the report, it would be a good idea to switch back to the ‘Report Designer’ tab (where we authored the report template) and save once more to commit the settings you configured while running the report, otherwise you will have to set these anew each time you run the report…

This is a no-frills slope stake notes report, and can form the basis for many variants.  You might want to extend this report by adding a title page, information about the corridor(s) and baseline(s), etc, or even add a cross-section view and forced page breaks.  This is all easily accomplished with Visual Report Designer for AutoCAD Civil 3D.

Posted on

Automatically Generated Legal Descriptions in AutoCAD Civil 3D

Automatically Generated Legal Descriptions in AutoCAD Civil 3D

Creating legal descriptions from parcel (or polyline) geometry can be quite a chore. Most people run a legal description report that generates some form of a legal description from the parcel geometry and then proceed to heavily modify the output text to fit their specific needs. To us, this always seemed to be a gross waste of precious resources.

Why waste time manually doing the same time consuming, repetitive work when it can be easily automated?

How can it be automated? With Visual Report Designer (for AutoCAD Civil 3D) of course! Let’s see how:

Requirements

We need an automatically generated legal description report that allows for customization of data such as Section, Township, etc, and that can automatically retrieve parcel data, metadata (such as tax ID and owner info), and geometry. The exported report should be able to be inserted in AutoCAD Civil 3D, or exported as a sharable and printable document (such as PDF). An image of the parcel(s) would be a bonus.

Solutions

There are several ways we might approach this. These approaches both share some common implementation (described at the end below)

First Approach – Use Calculated Fields/Custom Expressions

One approach is to use calculated fields/custom expressions in Visual Report Designer to construct fragments of the legal description text for each parcel segment, etc. This approach is relatively straightforward, but requires some advanced techniques such as nested expressions, etc. The advantage here is that you can easily do this yourself without any custom script programming.

C:\Users\adam\AppData\Local\Temp\SNAGHTML51f0645c.PNG

The only drawback to this method is that the text fragments for the parcel segments always start on a new line, as shown below. This means that some minor editing of the output is likely to be needed (i.e. removal of line breaks), however, this is still a major time-saving improvement over using the wrong report and editing large portions of the text, and for some users this may be sufficient as-is.

C:\Users\adam\AppData\Local\Temp\SNAGHTML5203991b.PNG

Second Approach – Use Scripting in the Report

There is another approach that will render a report that requires no post-run editing, however, it requires scripting. Basically we are doing something similar to what is done using expressions in the first report, however, instead of allowing the reporting engine to iterate over each parcel segment and generate a separate line, we replicate this process programmatically in a C# (or VB.NET) script embedded in the report template, collect and combine the results, and present the final combined result as a single field that is bound to the parcel entity. This is exactly what we have done in the ‘Basic’ Narcoosee legal description report available in our app store. When run, this report produces output similar to the following (note that the parcel image is intentionally omitted in this version of the report):

C:\Users\adam\AppData\Local\Temp\SNAGHTML5209fc4d.PNG

The exact output is easily modified/customized using the template developed for this report, so if you need a different format, we can generally accommodate quite easily.

Common Implementation Details

The remainders of the requirements are implemented in a similar fashion in both of these approaches. Values for Town, County, State, etc. are customizable as report parameters, which may be changed by the end user as the report is run:

C:\Users\adam\AppData\Local\Temp\SNAGHTML520edcf5.PNG

The parcel properties and metadata are taken directly from the parcel entity. We avoided the use of ‘User Defined Properties’ for parcels because of some issues in the way these are implemented by AutoCAD Civil 3D (unfortunately, the way we would need to access these items programmatically appears to be broken in all supported versions of AutoCAD Civil 3D). Instead, we opted to use the parcel description to hold all of the data (with fields delimited with a ‘\’ character), and then just parsed this data in Visual Report Designer using expressions/calculated fields (and ‘regular expressions’):

C:\Users\adam\AppData\Local\Temp\SNAGHTML5211dd25.PNG

The calculated field corresponding to this expression is inserted directly into the report as a label:

C:\Users\adam\AppData\Local\Temp\SNAGHTML52147e6c.PNG

We are of course not limited to just using a description as a source of metadata. We could read data from an attached table (AutoCAD Map 3D feature), XData, XRecords, a custom extended property field (from our Extended Entity Data app), from a record in an external database (using scripting), etc.

For the parcel image, all we need to do is drag an image field from the Field List in the Visual Report Designer Editor, drop it into the proper place in the report template, and size as desired.

C:\Users\adam\AppData\Local\Temp\SNAGHTML5226655f.PNG

Last, ALL Visual Report Designer generated report documents can be inserted to the source DWG, and can be easily exported to multiple forms of documents such as PDF, XLSX, etc.

C:\Users\adam\AppData\Local\Temp\SNAGHTML5229492d.PNG

Posted on

Subassembly Studio v. Subassembly Composer

Subassembly Studio v. Subassembly Composer

Inevitably the question arises ‘Why should I buy Subassembly Studio when I can get Subassembly Composer for free?’ The answer is simple – you get what you pay for. Very often a ‘free’ tool comes with hidden expenses such as lost productivity resulting from a lack of features/functionality, or just a generally difficult or awkward workflow. Subassembly Studio is exceptionally easy to use with minimal training, and with its extensive feature set an advanced user can produce most any subassembly imaginable.

Here’s a brief comparison of the features of the two applications:
Function/Feature SaS SaC
Basic geometric constructions (offset/elevation/slope) CheckMark CheckMark
Basic links CheckMark CheckMark
Basic shapes CheckMark CheckMark
Basic intersecting geometry (e.g. by slopes, etc) CheckMark CheckMark
Basic daylight slopes CheckMark CheckMark
Basic curved links CheckMark CheckMark
Basic logical constructs (if/then, etc) CheckMark CheckMark
Expressions/calculations[1] CheckMark CheckMark
Surface targeting/sampling/intersection CheckMark CheckMark
Customizable subassembly parameters CheckMark CheckMark
Support for offset, elevation, surface, etc. target parameters CheckMark CheckMark
Advanced curve layout (3-pt, tangents and length, etc) CheckMark Delete
Complex parametric curves CheckMark Delete
Support for X-records (store/retrieve data) CheckMark Delete
Advanced messaging system (event viewer, command line) CheckMark Delete
Subassembly debugging utilities CheckMark Delete
String (text) functions (replace, join list, concatenate, format) CheckMark Delete
Advanced intersecting geometry (lines/curves, multiple elements, etc) CheckMark Delete
Splitting/joining/sampling links CheckMark Delete
Intelligent pipe network components (auto-size, etc) CheckMark Delete
Target parameter collections (handle several targets as a group) CheckMark Delete
Automated target parameter acquisition (by layer, style name, etc) CheckMark Delete
Special structural components for railways CheckMark Delete
Special structural components for road design (structural layers, curbs, etc) CheckMark Delete
Automatically connecting components for rapid subassembly development CheckMark Delete
Ditch constructs CheckMark Delete
Advanced milling and overlay components CheckMark Delete
Real parallel offset of multiple links CheckMark Delete
Automatically calculated shapes (cut/fill or via earthwork/material table) CheckMark Delete
Conditional link components CheckMark Delete
Conditional shape components CheckMark Delete
Complex links CheckMark Delete
Advanced logical components (and/or/not, ‘rollback’, preconfigured ‘if’/’case’) CheckMark Delete
Shape clipping (against a link or complex link) CheckMark Delete
Write log file/export to CSV CheckMark Delete
Advanced superelevation calculations (SE rate from targeted alignment, etc) CheckMark Delete
Obtain information about the current station, start/end stations, etc CheckMark Delete
Transform point coordinates between ‘world’ and ‘local’ CheckMark Delete
Invoke other subassemblies (created with SaS) in single or repeated mode CheckMark Delete
Custom label notes and colors in the subassembly graphic in the designer CheckMark Delete
Support multiple versions of AutoCAD Civil 3D with one data file CheckMark Delete
Secure subassembly catalog files ensure your designs cannot be easily ‘leaked’ to a competitor CheckMark Delete

 
One feature in particular stands out – the ability to support multiple versions of AutoCAD Civil 3D with a single source subassembly catalog data file. To export to a new version of AutoCAD Civil 3D, you simply open the file in the Subassembly Studio Designer and export…during the export process simply select the proper version of AutoCAD Civil 3D from the supported version list. That’s it. It’s that simple.

In addition to all of the additional features Subassembly Studio offers, there is also a huge difference in usability. Subassembly Composer isolates the geometry from the logic of a subassembly by placing the logic in a flowchart, and the geometry in a ‘preview’ window; Subassembly Studio presents both the logic and the geometry in the same graphic, much like an exploded mechanical drawing. With Subassembly Studio, you can easily see both the logical flow of the subassembly and the geometry associated with each part of the logic. This makes it much easier to visualize precisely which components contribute to which parts of a complex subassembly.

Another very important consideration is that Subassembly Studio is still being actively developed and regularly updated with new and/or improved features.  If you need it to do something it currently cannot do (which isn’t much), we can almost certainly build in the required feature.

So when someone asks ‘Why should I buy Subassembly Studio when I can get Subassembly Composer for free?’ perhaps the question they should really be asking is ‘Why would I even consider getting Subassembly Composer when I can buy Subassembly Studio?’

 

 

  1. SaS uses a ‘Reverse Polish Notation’ based calculation system; SaC uses Visual Basic formatted expressions.

The web store has been temporarily placed in demo/test mode while we update and test some new features. If you see this message and wish to make a purchase please contact sales@civilplus.net. Thank you.