Civil 3D mapcheck error

[SDK_00]

I use mapcheck analysis to create a mapcheck closure selecting the labels from a polyline.  When I switch to the output view the radius' are all different and I can't figure out why.  I've double checked the labels, the radius of the original line and have even tried keying it in manually but civil 3d seems to have a mind of it's own on the output.  On larger radi it is affecting my area listed on the mapcheck.  Any help would be greatly appreciated.

[BrianHailey]

Can you share a sample where you are seeing the issue?

[SDK_00]

I've attached three images, the Line labels shows the polyline with labels, you can see that the radius of the first arc is 8332.26, the radius of the second arc is 4789.41.  The Mapcheck Input image shows the input of the mapcheck, radiuses are blank and I cannot key the correct radius in.  The Mapcheck output image shows what autocad comes up with, the first arc is 8332.00 (0.26' of difference) and the second 4789.39 (0.02' of difference).  Every mapcheck I do with a curve in it has this problem, it's never consistent they have varied from 0.02' to as much as 5'.  Thanks. 

[BrianHailey]

Can you wblock the linework and labels out and post up the file?

[SDK_00]

Here you go.

[BrianHailey]

I think the problem is that there is nothing in the label that specifies which way the curve turns. Does it turn to the left or to the right? If you create a polyline from the mapcheck, you can see which curves are going the "wrong" way in the mapcheck. You'll need to change the curve direction for those curves. When I did that, my mapcheck area is 1,964,984.27 sq ft and my original polyline area is 1,964,988.34 sq ft (a difference of 4.07 sq ft) whereas before reversing the direction of the appropriate curves, it was 1,965,441.74 sq ft (a difference of 453.4 sq ft).

Here is an exageration of what I'm talking about:

[tcorey]

Are you stuck with using the Label-selecting method of creating your mapcheck? If not, two options:

1. Make a parcel of the polyline and view its properties, analysis tab. This is way faster than what you're doing and you don't have to worry about flipping arcs to get it to read them correclty.

2. Use the Coordinate Geometry Editor (type COGO from the command prompt.) This will let you load the polyline as a traverse and it will show closure. I checked against your polyline and the curve data match.

Tim

[SDK_00]

Yes I'm stuck with using the label selection method, some municipalities require mapcheck closures with descriptions or plans.  A parcel needs to be a closed figure so you will not get and error of closure from it and the COGO command doesn't give you a closure error either attached is an image of the cogo closure report.  Closure error 0.000, if you measure from the pob of the polyline to the end of it there's 0.005' .   I tried it with a polyline that didn't close by a foot and it gives me the same 0.000.  I need to be able to plot a property line from a paper plan and get the error of closure mapcheck like I could in land desktop.  

[SDK_00]

Brian,

My issue isn't with the areas being off.  My issues is that this wonderful program decides to change the radiuses of the arcs when it outputs it through the mapcheck.  If you compare the mapcheck to the labels you will see every one is different from the original label.

[Jeff_M]

If you were open to 3rd party software to give you an easier way to select polylines and get a Mapcheck report, SincpacC3D's SPParcelInverse has a mapcheck option. This allows you to select a polyline and it displays the closure report which can be output to a file, clipboard, or printer. You can change the precision of the distances & angles to what you want (it defaults to using the drawing's defaults).

www.quuxsoft.com

[chrisdavis5201]

Has anyone had any luck with resolving this? I am running into the same situation where I need to generrate a mapcheck (math closure) for legal descriptions and the software is borking my radii. I know Jeff mentioned third party software, but we can't go the expense of 3rd party software company wide. There has to be a fix in C3D. Also is there any way of creating a mapcheck based on linework? I have legal descriptions with hundreds of courses along waterways and riparian areas and it seems silly to have to select each label individually to create a mapcheck.

Chris

[SDK_00]

Chris,

If you turn your precision for the arc lengths and chord bearings and distances as far as u can it will give you a closer radius. The program is using the chord and arc length to calculate the radius. I have found no way to change this and tell it to use the radius, because using a radius to build a curve just doesn't make sense!
I want to know that what is on the paper plan is exactly what is used for a map check so two decimal places is two decimal places.
I've been labeling my lines in civil 3d and then I still have land desktop 09 installed so I replot my lines and use that to do map checks.
We had a "cad expert" come to our office for training and I ran this by him and he had no clue how to fix it.

[peterfunkautodesk]

Two things about using the COGO Editor for a map check of a polyline

1. If you want to map check to 2 decimal places, you need to change the distance accuracy to 2 decimal places in the Coordinate Geometry Editor Settings.

2. If you map check a polyline, make sure that the POB and POC are the same. By default the POB and POC are the start and end of the polyline so you are going to get a very small closure error.

Cheers,

Peter Funk

Autodesk, Inc.

[BrianHailey]

Another option is to make the linework into a parcel and then go to the parcel properties and then the Analysis tab and change the Analysis type to "Mapcheck Analysis".

If you need to change the precision, go to your drawing settings -> ambient settings.

[peterfunkautodesk]

Brian,

The linework in this parcel doesn't close, the first and last lines overlap so making a parcel really isn't a great solution.

The problem is that the OP ran the map check as an open traverse, using the start and end points of the polyline as the POB and POC. The is a small error there if you go to 2 decimal places, but if you need to do a map check on a parcel, then you have to use a closed traverse: the POB and the POC need to be the same point. This will produce a larger closure error (just bigger than the distance from the start to the end of the polyline).

Cheers,

Peter Funk

Autodesk, Inc.

[telze33]

Has anyone figured out how to get around this error?  I find the parcels with the map check analysis to be problematic, thus using the actual labels produces a better final product on the closures - except it changes the radii value on the label! 

[tcorey]

What do you find problematic about Parcels with Mapcheck closure?

[telze33]

Parcels are fine some of the time, especially when creating new parcels (not from record maps). But when making a new map with record info (distances, bearings, arc lengths, etc), they can be problematic because they require a closed boundary.

So if you are going around a map, sometimes you have issues with the parcels modifying the record information of the entity to make it close. So you end up having to adjust lines by hundredths or thousands so that the rounding stays the same on the map but you keep the record information (hope that makes sense).

It comes down to maps having imperfections due to rounding, so nothing will close perfectly-but parcels force that to happen and sometimes it takes hours to adjust the parcel so that it closes properly and displays the same record information in the closure calcs that the map checker will want to see.

[cynthia.warner]

I know Survey is the ugly stepchild of Civil 3D but I'm having the same issue and also have to use mapcheck and not the COGO method.  We are also a large office and getting new software has it's own bureaucratic issues. Has anyone come up with a fix to this??

Thanks,

Cyn

Civil 3D 2018

[tharrigan.17665]

I discovered a workaround.  The mapcheck seems to use the chord bearing AND distance and lets the radius flop, so if you create a label with just Radius, Delta, Length and Chord Bearing(ONLY, no Chord length), it will then maintain the integrity of the radius.