Icontinue to have issues running mapchecks in Civil3D. When trying to go around radius it seems to do whatever it wants to do. I have attached an image of my most recent problem. The label for the radius is correct. You can look at the properties to the right of the image and compare the info. You can see the red arc where the mapcheck is trying to go. It seems like it is completely ignoring the arc length info, and strictly going along the bearing the given chord length. I have seen many other post about people having trouble with the mapcheck, but never a valid answer to the problem.
Rick Jackson
Survey CAD Technician VI
Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.
I'm not sure I understand? If I go around a 1' radius then I'm not going to the end of the curve/line. I have to go the actual bearing and distance down the line, and I have to go the actual curve data around the curve. If I fake in false information I'm not going to get a correct area or closure.
I think you have exceed the mapcheck functionality with this one. You will have to break the curve up into 2 parts for this to work within the base Civil3d progrem. I am sure the issue is happening due to the extreme nature of the curve(large delta and non-tangent)
For us surveyors this type of geometry is fairly standard. The Sincpac add on handles this mapcheck geometry just fine because it uses the pline (my preferred method) or other object types and not the label.
However, I'm not sure I understand what is so "extreme" about a cul-de-sac?? As you say, "For us surveyors this type of geometry is fairly standard". We work with cul-de-sac's on a daily basis. We pay thousands of dollars for a piece of software that can't handle going around a curve?? I did a thousand and one mapchecks with C & G 10 years ago and it did it with a breeze, but this latest and greatest, most wonderful software on the planet can't calculate around a curve?? I don't mean to come across as rude to you. I'm quite thankful for the help. I just don't understand why the greatest thing on the planet can't simply calculate around a curve.
The routine doesn't appear to like the non-tangent line and arc. Either add some tiny object or use a different routine. You can turn the area into a parcel and then do the mapcheck there, or use the COGO Editor to load a polyline and check its closure.
The issue is in your label. Your curve label must include delta. When the delta is present the mapcheck works just fine. You will need to ensure the curve is going the correct direction and that through radius is selected. I was able to do this successfully.
I thought i had done this before and admit that is does not work within your drawing. I created my own example really quick and it worked just fine. The only difference was the curve data included in the label.
@srousey74V5X I don't typically either, nor does your final plat have to include them (you can remove the delta from lables and tables after you run mapcheck) though I have seen many plats with the delta included. Civil 3D map check does apparently need it included to display and solve non-tangent, and compond curves correctly.
I have had similar issues with MapCheck as well. For closures it seems like you have to use a combination of Parcels & Mapcheck analysis and the MapCheck feature in Civil 3D. Arcs, however, always seem to cause problems. We recently had an issue where the Parcels approach wouldn't work because it has to be a closed polyline so it changes the figure slightly to get that (which screws up your map).
However, when you go the Mapcheck approach, even when we had the appropriate label styles so that it would pull the right information for "across chord" or "through radius" - we still had issues with the Mapcheck program changing the radius to the wrong radius. We sent our drawing to CADMasters, and I wasn't surprised to find that they couldn't get to the bottom of it either. They suggested using the Parcel mapcheck analysis segment report and pasting in the Survey Mapcheck closure error. Not an ideal solution. You would think after all these years, new add-ons in Civil 3D, etc....that they would create a functional program that could do these simple tasks.
It is just clunky to have the Parcel program and then a separate Mapcheck program, with no commonality between the two and also not much functionality to the user to complete the math in the way that makes the most sense. Frustrating from Civil3D!
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.
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.
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).
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.
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.
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.
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).
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!
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??
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.
Over my many years of reading the discussion groups, I constantly see posts on how to recreate a legal description in Civil 3D. Most of the time, the people answering suggest the line and curve tools or transparent commands or object snaps or some combination thereof. Well, how about using the tools in Civil 3D to recreate it directly? Keep reading to find out how.
3a8082e126