Need for Sensible Map Closure WITHOUT labels

[briniker]

Look into Sincpac, its an add-on for civil 3d. Couldn’t imagine working without it. Quuxsoft makes it. quuxsoft.com

[skwyd]

I actually have the solution using only Civil3D. It involves adjusting the various settings in the drawing.

I start all of my drawings from a template that I’ve created. It has all of my layers named with the linetypes and colors the way I want them. It also has all of my Civil3D styles and settings and all of that. When I find I need a new layer or decide that I need to revise my standards, I do that in my template so that it will be setup for all of my future drawings. Anyway…

Here’s what I’ve done. Under Toolspace>Settings expand the Parcels section and then expand Commands. Right click on ExportParcelAnalysis and choose “Edit Command Settings…”

First, I open up “Parcel Analysis” and switch the value to “Mapcheck analysis” so that becomes the default. Civil3D defaults to “Inverse analysis” which isn’t what I want.

Under “Distance” set the Precision up to 8 (the maximum allowed). Do the same for “Angle” and “Direction”.

What this does is tells the Parcel Analysis to use a greater level of precision from each label. But, that will also cause your exported closures to show those values out to that level of precision as well. And this may be what you want. But if you only want it to show to the nearest hundredth (or thousandth) for distance and nearest second (or tenth of a second) in bearings and deltas, you’ll need to do the next step.

In the same place (Toolspace>Settings) right click on the drawing name and choose “Edit Drawing Settings…”

Under the last tab, “Ambient Settings”, change the Precision under “Distance”, “Angle”, and “Direction” to be whatever level of precision you want to see in your exported closure report.

So now, your closures are calculated using much more precise line data, but still only display to the level of precision that you want.

Now, I realize that in many cases, this will seem like cheating. A map only shows a particular level of precision (nearest second of arc and nearest hundredth of a foot in my area, typically). And one should be able to show courses on the face of the map that define mathematically closed figured. But I think everyone here knows that if you have a long and complex figure, with many courses, lots of curves (some even non-tangent), and many short segments with direction changes, the tiny bit of variance between the course as drawn and the course as labeled will grow to some very, very large misclosure errors.

This method will help address that. Hope it helps.

[a-harris]

That is the purpose of the original Dos COGO programs and why I keep Carlson Surveyor1 around.

Key Input is near exactly as SMI on HP48GX and can be as simple as:
1 Beginning Coord
2 Traverse or Sideshot
3 Bearing or Angle
4 Distance
5 Point Number
repeat 2 thru 5 until end or closure
with no boxes or popup windows to fill out

It is the same COGO routine that was included in Carlson CES that shelled out in a Dos window and was written to operate on a 16k system.

[jhframe]

skwyd, post: 353306, member: 6874 wrote: But I think everyone here knows that if you have a long and complex figure, with many courses, lots of curves (some even non-tangent), and many short segments with direction changes, the tiny bit of variance between the course as drawn and the course as labeled will grow to some very, very large misclosure errors.

I’d be interested in testing my closure process against a problematic polyline, if anyone has one they’re willing to put online. I haven’t run into any problems like this, but then I don’t usually deal with long curvy parcels.

[warren-smith]

Jim Frame, post: 353311, member: 10 wrote: I’d be interested in testing my closure process against a problematic polyline, if anyone has one they’re willing to put online. I haven’t run into any problems like this, but then I don’t usually deal with long curvy parcels.

I have encountered pseudo misclosures when working with very large radius curves. A second of central angle contributes quite a bit to the error budget.

[Dave Viera]

skwyd, post: 353306, member: 6874 wrote: So now, your closures are calculated using much more precise line data, but still only display to the level of precision that you want.

Now, I realize that in many cases, this will seem like cheating.

Quite frankly, while clever that pretty much is cheating. The purpose of a traverse closure is to represent the closure based on the actual dimensions shown on your map or as written in a legal description.

That said, we used to have an agency around here that insisted that all traverses, regardless of number of courses and total distance, closed within 0.007′. Obviously, whoever decided on that policy didn’t understand traverse closures. You had to “cheat” in certain situations to comply with their ridiculous policy.

[jhframe]

Dave Viera, post: 353315, member: 10839 wrote: That said, we used to have an agency around here that insisted that all traverses, regardless of number of courses and total distance, closed within 0.007′. Obviously, whoever decided on that policy didn’t understand traverse closures.

One of our local agencies used to do that. This is the note that I developed and, after much wrangling, got them to accept in the early 1990s :

[a-harris]

At least once a year after the project if complete I get a reply from someone from the chain of desks that the survey has crossed with a copy of their “deed plot” results showing how far the closure is out with the note “this does not close, correct and send new papers asap”.

Everyone of them share that they do not understand how to read a property description and will input the call, then input the witness calls by mistake and continue around the parcel to closure.

They have a drawing to compare their deed plot to and never understand their errors.

Problem I have is that each of them do it over and over and appear to point blame because their guy was not called to do the survey and that every time this happens it takes from a day to over a week to get this persons approval.

[sarcasm]I’ve thought of preparing a rather wordy legal response that basically tells them they entering into an area they are not qualified to give an opinion and all they are qualified for is being an idiot and are responsible for actions that have delayed the client’s closing and should immediately send $$$ to the client and $$$ to the surveyor for the billable time for clarifying and pointing out they are the ones in error.[/sarcasm]

:gammon:

[Dave]

A Harris, post: 353309, member: 81 wrote: That is the purpose of the original Dos COGO programs and why I keep Carlson Surveyor1 around.

Agreed! That is the purpose of the original DOS COGO programs and why I keep PacSoft around! The efficiency of true COGO took a hit when it had to be done in a drawing environment with GUI, pulldowns, windows, filli-in-the-boxes, a zillion icons etc..

[skwyd]

Dave Viera, post: 353315, member: 10839 wrote: Quite frankly, while clever that pretty much is cheating. The purpose of a traverse closure is to represent the closure based on the actual dimensions shown on your map or as written in a legal description.

That said, we used to have an agency around here that insisted that all traverses, regardless of number of courses and total distance, closed within 0.007′. Obviously, whoever decided on that policy didn’t understand traverse closures. You had to “cheat” in certain situations to comply with their ridiculous policy.

And this is exactly why I dug into Civil3D and learn this. There are a couple of agencies around here that insist that all map closures have an error of closure distance less than 0.01′ no matter what. They won’t consider the fact that I’ve had mis-closures of 0.025′ that are still under 1 part in 250000. This is typically because the person checking the closures against the map doesn’t understand what they are reading in the closure report.

I actually ran into an issue with someone checking a map of mine that had a problem with a mis-closure of 0.006′ in one parcel. He suggested that I change the length of one of my dimensions so that the closure would be smaller. But then I explained to him that if I did, then the sum of the lengths along that overall course (it was a subdivision map) would not match the length of the total. He said that I should then change my total. But then I explained that it would cause the closure that I ran for the whole block to mis-close by 0.013′ and this wasn’t acceptable. So, after a lengthy discussion about how my choice to allow a mis-closure of 0.006′ in one lot prevented a large scale change of many, many closures in the whole subdivision, he finally let it go.

It is always a challenge to take geometric figures, which may have directions that aren’t an even second of arc and lengths that aren’t exactly to the hundredth, and make nice, pretty closures for them. Rounding “error” has always been (and always will be) something that has to be addressed on a map.

So the short answer is, if all of the agencies that check my closures against my maps understood how rounding error works, and how a mis-closure of 0.011′ doesn’t mean that the figure isn’t “mathematically closed”, there wouldn’t be this problem. But they don’t, and so there is, and this is the solution I’ve found.

[dave-karoly]

skwyd, post: 353896, member: 6874 wrote: And this is exactly why I dug into Civil3D and learn this. There are a couple of agencies around here that insist that all map closures have an error of closure distance less than 0.01′ no matter what. They won’t consider the fact that I’ve had mis-closures of 0.025′ that are still under 1 part in 250000. This is typically because the person checking the closures against the map doesn’t understand what they are reading in the closure report.

I actually ran into an issue with someone checking a map of mine that had a problem with a mis-closure of 0.006′ in one parcel. He suggested that I change the length of one of my dimensions so that the closure would be smaller. But then I explained to him that if I did, then the sum of the lengths along that overall course (it was a subdivision map) would not match the length of the total. He said that I should then change my total. But then I explained that it would cause the closure that I ran for the whole block to mis-close by 0.013′ and this wasn’t acceptable. So, after a lengthy discussion about how my choice to allow a mis-closure of 0.006′ in one lot prevented a large scale change of many, many closures in the whole subdivision, he finally let it go.

It is always a challenge to take geometric figures, which may have directions that aren’t an even second of arc and lengths that aren’t exactly to the hundredth, and make nice, pretty closures for them. Rounding “error” has always been (and always will be) something that has to be addressed on a map.

So the short answer is, if all of the agencies that check my closures against my maps understood how rounding error works, and how a mis-closure of 0.011′ doesn’t mean that the figure isn’t “mathematically closed”, there wouldn’t be this problem. But they don’t, and so there is, and this is the solution I’ve found.

Holy heck, the danged thing is closed because you have monuments at the four corners. Do you use an electron microscope to analyze the dimple? 😉

To clarify: my comment is directed towards the theoretical mathematicians checking map closures, not Skwyd.

Edit2: fix all the things iPad helpfully “corrected” for me.

[Mapman]

Was thinking whether an Excel spreadsheet is able to do this.

Significant figures would also have to be considered. Would have to have a radial line input for non-tangent curves. The coords need to be truncated after computation to maybe 3 decimal places. The report at 2 decimal places. Then a precision ratio. Might be fun…..

[skwyd]

Dave Karoly, post: 353908, member: 94 wrote: Holy heck, the danged thing is closed because you have monuments at the four corners. Do you use an electron microscope to analyze the dimple? 😉

To clarify: my comment is directed towards the theoretical mathematicians checking map closures, not Skwyd.

Edit2: fix all the things iPad helpfully “corrected” for me.

I absolutely know what you mean! And this is the frustration I run into when a “technician” checks my maps.

On a related note, one of the County Surveyors around here (who I’ve known since I started surveying 20 years ago) has said that he can’t stand it when someone gets hung up on the minutiae of a mis-closure of a couple of hundredths but misses the fact that the survey is called a historical original monument off by a foot!