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.
Can you share a sample where you are seeing the issue?
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.
Can you wblock the linework and labels out and post up the file?
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:
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
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.
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.
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).
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
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.
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.
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.
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!
What do you find problematic about Parcels with Mapcheck closure?
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
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.