In the last few Parcel posts we learned about the Site Parcel Feature’s topology engine. We unwrapped this planar and nodal based topology model that underlies how Parcels work. This unique engine powers the design functionality we get out of Site Parcel’s dynamic model in AutoCAD Civil 3D.
The Parcel Posts - a study guide to Read and Test in AutoCAD Civil 3D
Site Parcel Essentials – Part 1 | It’s Not Yo’ Daddy’s Parcel – Part 2 | To Edit Parcels is to Create? – Part 3 | Parcels Have Priorities - Part 4 | A Strange Universe of Parcel Inverses and Mapchecks – Part 5 | Dances with Parcels – Part 6 | Pack Dances with Parcels – Part 7 | Cycle Manipulations of Segments – Part 8 | Select Manipulations of Segments – Part 9 | Visual Manipulations and Many Segments – Part 10
We learned that a Parcel in Civil 3D is a Resolved Feature. Saying Parcels have to be “closed” to be created in Civil 3D is incorrect. It can be downright misleading. What is happening in the Site Parcel is also nothing like “closing” a polyline or a Survey Figure. “Closure” is an analysis of traverse geometry. What the topology engine is doing is nothing like that. Read the previous posts in this series to understand why.
Totally Planar, Dude
The Site Parcel topology also allows us to Inverse (or Mapcheck) the resolved Parcel. These are an Analytic property of a resolved Parcel.
Remember the Parcel Analysis is potentially a changing product (an output) of the dynamic and planar Site Parcel topology model.
Why do we even need these Inverse and Mapcheck properties aside from the basic reporting you might expect for something we call a “parcel”? It’s all about the QAQC process.
Stuff In and Results Out
One issue is the Point of Beginning (POB) property. We typically want to assign POB since Civil 3D employs a default “first in” rule for the Parcel Segments. This doesn’t often agree with how we want to see (or report) the Analysis information.
There is also no rule against us loading multiple overlapping (or partially overlapping) linear segments into a Site Parcel topology. Last time you were encouraged to employ MAPCLEAN on your input Parcel geometry.
The Site Parcel’s dynamic planar and nodal model ”automatically” weeds out some of the potential geometric confusion duplicate segments might produce in the Analytics. How the Site Parcel’s planar 2D model works produces anti-duplication “rules” for the output. That model resolution process does NOT affect the segment data we input.
Here’s some geometry in a Site that resolves a “valid” Parcel.
The underlying polyline geometry converted into Parcel Segments contained partially overlapping segments in the first course. We can still see these overlapping segments the Parcel Elevation Editor. Note the differently displayed status of two of the nodes in the list and the distances between them.
The topology engine ignores the underlying “overlap errors” and resolves something else.
The Inverse for the Parcel shows the engine’s result. Note that three geometry segments we see above become two segments in the resolved 2D Parcel’s Inverse analysis.
The Site Parcel topology rules here are very simple:
- No two nodes occupy the same location
- Only one segment of a type (tangent or curve) may connect nodes
That last bit does mean we can have both a curve and a tangent between two nodes.
In the above example, we used a multi-segment polyline (a common CAD input). You should also consider the common real world occurrences of overlapping Survey Figures (a Lot line and a fence) as another duplicate segment case in point.
Parcel World Duality
We get the best (or the worst) of both worlds depending on your perspective. We don’t lose the original geometric data input (unless we edit it out of the data). We will get a “valid” resolved Parcel result.
The Duality of Parcel Annotation
The Site Parcel model and its relationship to the various types of Labels may produce some interesting annotative “side effects”. You can either employ these differences to your advantage and/or pull your hair out in confusion and frustration.
If we employ a General Line and Curve Label to annotate the geometry with the overlapping segments we get different results than if we employ Parcel Line and Curve labels.
- General labels get their data from the underlying geometry – they read the input data.
- Parcel Labels annotate the resolved Site Parcel topology – they read the resolved model data.They also recognize all the nodes (generated by any Feature segment) in the Site Parcel.
The Parcel Labels used here display the lengths of the resolved segments in the Site Parcel topology.
The General Line label employed here displays the length of the entire underlying polyline that was submitted to the engine. What is displayed is a matter of Label Style. Maybe you want Grades?
The Nodes Unseen Do Matter
Remember the duality -Keep Grading Sites separated from Land chop (subdivision) Sites.
It is important to recognize the model result includes all nodes in the Site Parcel.
While a Feature Line won’t typically subdivide a Parcel, all Feature Line nodes DO appear in the model. We don’t necessarily want those in the Analytics for our subdivision.
If segments between nodes show up in the Analytics, they produce Parcel Line and Curve Labels.
Think better QAQC.
The relationship between that Feature Line and the other segments often matters a lot in the real world.
Union Powers
You can in effect employ the Parcel Union command (available in the Parcel Layout toolbar) to Group Parcels together temporarily or permanently for whatever purposes you require. For example - you want the area sum of all these selected areas. The Parcels you select to Union do not need to share segments.
The Parcel Union command effectively resolves a new Parcel by partially ignoring any “shared” dividing segments between the selected Parcels to construct a new “outer” boundary. The input segment data isn’t destroyed by Union. It is only partially “ignored” for the boundary creation. The nodes of the segment(s) still continue to exist in the Parcel model. The segments affect both the resolved Analytics and the Parcel Label annotation.
I think a Union and Dissolve Union command option of by ”Parcel Style(s)” would be pretty useful.
How about by area range?
Oh! Did you forget that you can create dynamic or static Tables from the resolved Parcel data?
Copy to Site coupled with Parcel Union may get you what you need to deliver, present, or publish faster for many 2D area problems. You might also consider that process as a way to validate the end result of lots of design changes against the start condition. In other words, is there still a match? Where is the difference?
Survey Mapcheck
In the Survey Ribbon there another different version of Mapcheck that allows you to pull values from existing Line and Curve, Alignment, Parcel, and Alignment Labels and thereby control both the precision inputs to the Mapcheck and/or avoid the use of a Site Parcel’s topology output all together.
Why would we want to do that?
Sometimes an ax comes in handy even when you have a chainsaw.
The Survey Mapcheck also allows you to enter the course or “Side” values manually much like its more complex cousin the COGO Editor. You can find COGO Editor tool in the Survey Ribbon in 2012-13 in the Analyze Ribbon on the far left. It’s radical Dudes. Check out this post to understand and employ the COGO Editor tool better.
As I mentioned earlier a Survey Mapcheck doesn’t formally need a resolved Parcel. Therefore, you can Mapcheck raw linework, open traverses, alignments, Figures etc. Technically, Survey Mapcheck doesn’t actually require anything from a drawing at all nor does in maintain a dependency on the Label data you pump in.
The Survey Mapchecks collector is a General Feature in a drawing. The Mapchecks collector is not listed in the Civil 3D Toolspace. There is ONLY ONE Mapchecks collector and it must contain one named Mapcheck with a POB. A Named Mapcheck stores what it gathers in the drawing. This is different from the independent external files used by the COGO Editor tool.
You can only export Survey Mapchecks from either from the input or output sides via copy to the Windows Clipboard as raw text data.
Survey Mapcheck's are a way to compare geometry changes, produce annotation, and create polyline data.
Create some Horizontal Control
Unfortunately, neither Survey Mapcheck or the COGO Editor will feed (or create) Parcel Segments to a Site Parcel directly. You must generate dumb CAD polylines from the tools and feed those primitives (or Alignment Features built from them) to a Site Parcel topology.
CAD primitives like this have no built in design rules, tangency constraints, etc. - Why it often pays to employ Alignments and particularly Data referenced (DREF) Alignments during Parcel construction. Hint…Where do you want the data from multiple copies of an Alignment to come from?
Currently, the Parcel Segment Feature does not directly support either horizontal control design rules or tangency constraints either. Last post we learned a couple of ways around that limitation, didn’t we?
Add and delete (replace) strategies tend to often work better for Parcel Segments than direct edits. This is especially true for curve segments and especially true for those nastier non-tangent curves we stumble upon.
You’ll also note that the tools in the Parcel Layout toolbar will only create “Fixed” tangents and “Fixed” curved Parcel Segments at this point in Civil 3D time.
Perhaps, Autodesk will implement Parcel segments types that are like Alignment segment types in the near future. Hey. We can dream. Maybe we’ll just be happy to know we can use real Alignments Features anyway.
More Coming Attractions?
If you are using AutoCAD Civil 3D 2013, you’ll notice there are now Tangency Constraints “exposed” in the Parcel Sub Entity Editor found in the Parcel Layout toolbar. However, they don’t work for Parcel Segments yet the way the similar tools work for Feature Line segments. Arrrgh.
In effect, horizontal and vertical control edits of Parcel Segments is pretty primitive unless you employ Alignment/Profile Features.
Alignments never become Parcel Segments at all, but will still interact with a Site Parcel topology. The Alignment Feature begins to look pretty significant to Parcel creation and editing. That makes a lot of real world sense. We’ll return to more stuff about Alignment usage in the Site Parcels in a later post.
Next time we take a Long Strange trip to the Parcel Create and Edit tools in the Parce Layout Toolbar.