MapCheck Analysis - Legal Description Closure

[_Hathaway]

Civil3d 2012

We are looking at the best practice for checking closures on over 100 legal description, each requires a closure report.  I am familiar with the Mapcheck routine that requires all lines and curves to be labeled but find this to be an excessive amount of work.  I mean why would we want to label the lines when there is no need to...besides the software need to have it.  In LDD we cogo up a legal description, make it a pline and go through the analsis/figure menu and voila' a mapcheck report is created.  In civil3d we seem to be forced to label the lines first and then you have to manually pick each of them.  This is excessive and overly cumbersome.

We have even tried toggling the command line window in the map check analysis and hand entering the bearing and distance for each side.  While this works the brg and distance input is different i.e. you have to type N45-45-23 W then mouse down to the distance input and enter the distance.  We quickly canned that method due to the data entry procedure.

Parcels won't work because nothing ever created based on a metes and bounds legal, with the excpetion of a square or rectangle, will close flat.

There has to be a better way!

[Jorge]

Mike, thanks for understanding. I guess you have to be a surveyor to understand that these other methods just don't work for us. I've put the word out for a work around or some kind of patch and if we come up with anything I will let you know. I only hope you would extend me the same courtesy. Take care amigo, Jorge.

[bcsurvey]

This might be a bit off topic, but I work for a municipal survey department and what I don't see mentioned in these recent posts is LEAST SQUARES ANALYSIS.   

This is what I've started doing:

- Once you have a polyline of your traverse from beginning point to closing point (with no line connecting the two), go into Mapcheck (Survey Ribbon tab).

- After you choose your point of beginning, turn the polyline layer off, but DO NOT REGEN!  This makes it much easier to select the line labels (and BTW, I use a label style that includes distance precision to 4 decimal places and bearing precision to the hundredth of a second).  Then choose New Segment from Mapcheck (might need to click on the POB line in Mapcheck) and you should be able to click line lables one after the other.  The only lag you'll experience at this point is the time it takes your cpu/gpu to insert the mapcheck's graphical vector component.

- Once you've entered all segments, right-click to finish it and click on the Output view at the top of the Mapcheck window.  This will give you a nice pretty closure report. 

- For adjustment, go to Input view, right-click on Mapcheck name and choose Adjust Mapcheck.  Here you can choose Least Squares and the subsequent settings/parameters you'd like.  Judging by the .lso, .lsi, and .trv text files that are output from this point, I would presume that this process is using the interior angle total and segment lengths in running it's analysis.  At this point, you can insert a polyline of the adjusted traverse, which can then be brought into the Cogo Editor for outputting a nice pretty report (Choose No Adjustment at the top of Cogo editor since it's already been done).  You will still get very small errors, but this is due to the precision settings of your labels from the Mapcheck portion. 

I have not yet compared this to the Least Squares function in the Survey Toolspace, but we've not had much success in streamlining that part of the Toolspace.  It would be nice ultimately to verify these two separate operations are doing the same thing (i.e. getting same results), but as of now, we haven't done that.

I know the clicking on each label or tag is cumbersome, but by turning off the polyline layer, it makes it much easier as you can be zoomed way out and not have to worry about the polyline getting in the way of your pick box.  Just make sure your annotative scale and zoom factor are such that you don't get the labels confused, i.e. out of order.

HTH

[peterfunkautodesk]

There is an option in the COGO Editor "Load Traverse from Polyline" that will load a polyline into the COGO Editor. The POB and POC will be the start and end of the polyline. If you are going for a close, set the POC to the POB and then run the report. The error report will be based on the values that are in the COGO Editor and not the values from the polyline (4 decimal by default). Arcs will be described by chords.

Regards,

Peter Funk

Autodesk, Inc.

[IanMcClain]

That's realy cool. I never knew that was there. Type in COGO or go to the Anylyze tab > Survey > Coordinate Geometry Editor.

Thanks Peter!

PS, ask the powers that be to stick that command in the survey pulldown menu!

[bcsurvey]

Heck yeah!  Since the COGO editor doesn't do least squares analysis, I only use it to output the Civil 3D report.  As I described above, you can do least squares in Mapcheck, then insert a polyline of this adjusted traverse, and now you have 2 polylines - unadjusted and adjusted.  Then in COGO editor, you can import each one and get a nice course description in the C3D-style report for each.  Mapcheck can export text, but it's not the pretty report, so you'd have to insert it into Word or even customize it as Mtext.

[Jorge]

Peter, at first I thought we were on to something but I quickly realized that this will never work due to the fact that since it is running along the chords and not recognizing the "segment" portion of curves you will never get an accurate closure report or an accurate perimeter distance, which in turn will result in an inaccurate acreage. Surveys of 50,000 acres are not uncommon for us, and you can bet they are going to have curves due to roads, adjoining parcels, etc. Can you imagine the size of the error this would cause? Acreage is money and I don't have to tell you how important it is for us to report accurate acreage when we are using the taxpayers monies to purchase or sell land. It is beyond me why this command has been changed from the way it used to be, you are really alienating a lot of your users but apparently surveyors are not your priority. I appreciate your assistance but unless the "Old" mapcheck comes back we will have to start exploring other options in the software we use and we aren't the only ones as many of the private surveyors I have spoken to about this issue are very upset. Regards, Jorge. 

[_Hathaway]

While some of the recent posts have identified some potentially useful tools that some may not have been aware of, it still doesn't address the main issues. Again, Jorge hit the nail on the head. For our needs we simply had to go outside Autodesk to find the simple mapcheck functionality that it used to have and bought Sincpac.

I'm still confused why this function was changed to it's current form.

[peterfunkautodesk]

Here is another way to do a MapCheck on a polyline:

1. Open up a survey database

2. Use the "Create Figure from Object" command to create a survey figure from the polyline (open or closed it doesn't matter)

3. Right click on the figure in the figure list and "Display Mapcheck..." The Map Check will be displayed in the Panorama dialog box.

One of the reasons that we modified Mapcheck was because the surveyor that designed the feature said that he needed to check the labels on his plans to make sure that they closed and that he didn't miss any labels.

FYI, with the COGO Editor you can also add close using one of the 3 traverse adjustment methods and then add a new polyline to the drawing.

Regards,

Peter Funk

Autodesk, Inc.

[_Hathaway]

Now that's something I didn't know Peter. The interface is bit clunky and there is no fancy reporting/feature but it does appear to work. (still not as efficient as the old way...but close).

I do agree that it is nice to have the ability to cogo-check your labels as your surveyor has indicated but it's also nice to not have to label your data as there are numerous instances in my line of work where I never need to actually label the linework, I simply want to check the closure.

[bcsurvey]

Peter, thanks for that info.  I've incorporated it into my write-up below, which I was just about to send.  Sorry for being long-winded, just trying to be thorough so that others can get all the info in one place . . ..

Jorge and Mike . . .

I've been griping about the lack of survey-friendly functionality in C3D for years, as have others (check my posts from the past and you'll see plenty).  It is unfortunate that surveyors obviously don't have the clout that Eng. Design and Graphics-based segments of Autodesk's market seem to have in where they devote their energy, even though the proper placement of where most eng. design projects start - property lines - is dependent on competent surveyors.

Having said that, it is fortunate that there are add-ons like Sincpac out there, and as I see that you've fit it into your budget, I'd imagine that the demand justifies the price, at least in your organization (I can't speak for all).

For anybody going with Sincpac the following is irrelevant, but for those who don't/can't go that route, read on . . .

We've been talking about 2 different sets of data.  One has been a "traverse" which won't include arcs, curves, or cusps.  The other has been "descriptions" which may include arcs, curves, and cusps.

From my experience, there are 4 tools to be used in C3D for the purposes described herein:

Mapcheck (Under Survey Ribbon Tab) - for Traverses or Descriptions

PROS:  Only simple way of running a least squares analysis that I know of (we steer clear of the Survey Toolspace) and gives good closure information and parcel area in output.  Polyline of adjusted traverse can be generated.

CONS:  very cumbersome to enter data into since you must label all legs of a description and click on each one instead of it just recognizing polyline.

Mapcheck (After creating a figure from polyline - must have active survey database) - for Traverses or Descriptions

PROS:  Quickest way to get full closure data on a polyline, closed or open, along with precision.  I assume the area output assumes a closing segment

CONS:  Can't do adjustments to tranverses.

NOTE:  See attached file for comparisons of the same polyline analyzed by each mapcheck method along with the area and perimeter of the same polyline made into a parcel shown here in model space (includes closing segment).  Pay special attention to the variation in closure distance and direction as well as the area.  Also, examine the properties of Segment #2, which is the same segment in both mapchecks. 

COGO Editor (Survey Ribbon Tab) - for Traverses only

PROS:  Nice pretty output reports, and has the ability to import a polyline or click on COGO points.

CONS:  Can't do true Least Squares Adjustment, also difficult to enter new course information individually (for most instances)

Parcel creation - for Traverses or Descriptions

PROS:  Can be made in a couple of clicks after creating polyline of traverse or description, can be setup with label to immediately give good area and perimeter.

CONS:  Must close graphically, which for the purposes of getting the most accurate area of an unadjusted and non-closing polyline, probably gives the best results as it's not based on label information but the true location of the segments.

The reason I wanted to get into the nuts and bolts was to make the point that while there may not be one silver bullet as what older CAD versions offered, there are ways to get good analysis results from what C3D gives you out of the box.  No, I don't work for C3D.

-KERPLUNK-

[bcsurvey]

Instead of deleting my post above and re-responding with a very minor correction,, I'll just say that I DO in fact work for C3D . . .

but I DON'T work for Autodesk.

😃

[IanMcClain]

Mike,

I agree with your sentiment that C3D should be able to perfrom the task at least as well as LDD did. It is obvious from this thread that the tools available in C3D are not completely satisfactory for your task.  Unfortunatly, this forum is only good at sharing knowleged of what the program is capable of, and not good as far as a means of feedback for Autodesk to enhance their product. Fortunately there is another channel for feedback.

Since you are the OP and you know what you would like to see out of C3D as a result: have you considered submitting your ideal solution to the subscription center (assuming you have a subscription)?

http://subscription.autodesk.com/sp/servlet/public/index?siteID=11564774&id=11607975

Respectfully,

[bcsurvey]

Peter, when you said

"One of the reasons that we modified Mapcheck was because the surveyor that designed the feature said that he needed to check the labels on his plans to make sure that they closed and that he didn't miss any labels."

surely you meant SURVEYORS and not SURVEYOR . . . . If it was a single person, I hope he had ample imput from several other PLS's as well as survey technicians on what this change would mean to the industry.

Personally, I think that the OOTB methods described herein can get the job done, but those firms that routinely deal with a large number of parcels needing closures checked or even other firms that need to do the same less often will surely be at a disadvantage time-wise, especially if the project's a hot potato!

[_Hathaway]

I seen that too bcsurvey and thought the same thing. It seems to me that it was just 'a' surveyor and if true that would be a shame. Its the classic case of trying to fix something that wasn't broke and in doing so eliminating the feature that used to work just fine.

While the multitude of options 'can' get the job done it is not as efficient as previous methods. This is the main reason we purchased sincpac, the parcel inverse routine they created took the LDD version, kept it's functionality and added to it without breaking it.

[pcchenard]

Am I missing something here?  The "Parcel Map Check Report" in Civil 3D seems to work just fine for me.  Here is the output for a single parcel.

Parcel Map Check ReportParcel Name: Survey Site - Boundary : 1
Description:
Process segment order counterclockwise: False
Enable mapcheck across chord: False
North:473,655.1870' East:19,299,359.8186'

Segment# 1: Line
Course: N31°46'30"W Length: 41,176.61'
North: 508,660.3512' East: 19,277,676.8372'

Segment# 2: Line
Course: N52°50'00"E Length: 98,638.75'
North: 568,251.5327' East: 19,356,280.2347'

Segment# 3: Line
Course: S18°06'00"E Length: 76,504.15'
North: 495,533.1346' East: 19,380,048.2708'

Segment# 4: Line
Course: S74°49'50"W Length: 83,601.59'
North: 473,656.7301' East: 19,299,359.6795'

Perimeter: 299,921.10' Area: 119,731.04Acre
Error Closure: 1.5494 Course: N5°09'10"W
Error North : 1.54309 East: -0.13915

Precision 1: 193,572.42

What am I missing?  This report clearly states the precision of the closure, and that precision changes with the change of the "Direction" value of the drawing.

[Civil3DReminders_com]

They want the ability to run check without having to create a parcel. A parcel has to be closed in order to be a parcel and there are situations where you need that non-closing parcel to check the values shown, hence the request to do it on a Polyline. 

Writing a program in .NET to do a Map Check analysis on a polyline that outputs to a Word document that gets formated exactly as a pserson wants takes about 8-24 hours to create. Most of the code is already available in the Civil 3D Reports code that comes with the program, although it needs to be modified for polylines instead of Civil 3D objects.

I guess the sad part is Autodesk has the code already written but doesn't want to convert it to work on polylines which shouldn't take that much time. They could even make it an open source project and they wouldn't have to do anything other then share it. I'm sure there would be some in the community that would make modifications to get it to work.

[pcchenard]

I see that in later discussion in the thread.  But the original post suggest that the Map Check report doesn't work, and it works perfectly. 

[bcsurvey]

The last word of the last post above is the difference in the OPs point of view and those saying there's "nothing wrong".  I'd be surprised if anybody saying the latter has any field survey experience, or experience with checking closures on other agencies' descriptions.

A real-world "parcel", as inconvenient as it may be to strictly office-bound C3D users, is NOT a closed region in a digital environment.  A parcel, in the civil/land development context, is a peice of land.  Descriptions on peices of land are often errant due to our imperfect nature.  If you're strictly going by dynamic labels in CAD for your mapcheck report on parcel that you know is closed (snapped end points), then you will have very small error, caused ONLY by the rounding of distances, and to a much lesser degree, rounding of angles.

What the OP was after was a way to check descriptions of land that may not have been created by dynamic vector-based labels.  When these courses are entered in from the point of beginning, they will usually NOT close, thus no parcel is created and THUS . . . map check will not work.

Have a great weekend.

[peterfunkautodesk]

The tool on the Survey tab "Mapcheck" should be used to create a map check of a polyline. The simplest way to use the command would be to add bearing/distance labels to the polyline (or series of lines, arcs and polylines) and then run the map check. You will be prompted for a point of beginning and then to select the labels. The values in the labels will be used inside the map check to set the bearing and distance and the percision will match that of the label.

Regards,

Peter Funk

Autodesk, Inc.

[johngordon6189]

It would be real nice if the cogo editor would actually print a report when you hit the print button instead of putting an oddly named html file in the temp folder.  It would also be really nice if the cogo editor would actually move the points associated to an adjustment, especially when the traverse was input by point numbers...