Ugly Bug in Carlson?

I can't even get the lines to join....

Never Mind

Tech support just called back and they said the reason it is doing this is that when you use Join Nearest, the line that is joined has been converted to a polyline.

That said, I think is is VERY dangerous for a line to be converted from a simple 2D line to a polyline and dimensioned as such without warning.

Rather than agree this this could cause a problem, support says that is how it is supposed to work. My own opinion is that no software should convert your lines to something else without warning. I can envision some major problems with this. They checked back to Carlson 2007, and it does the same thing, and they seem to want to justify it like that, but I say, that I am even more worried about it because of something in the past that I did not catch.

Never Mind

I was going to ask if that was the problem. My dialog box gives the option to convert it to a polyline. I couldn't get it to work though...

Would it be slightly less of a problem if both the components of the polyline were dimensioned and labeled?
If that were the case, i could understand the notion that it is a "feature" not a "bug", but to show only one of the dimensions of the two co-linear components, does seem like a bug.

All the more reason to utilize your coordinate file. I strongly suggest generating closure reports and drawing linework using point input. 2DP and 3DP will draw your linework using point input.

I do understand your concern and you are right to bring it up.

In what context are you using the join nearest command? I have never had the need for this command.

The routine apparently is intended to join lines that are not adjoining. It must alter the lengths or bearings to make the lines join. I would consider it risky to use this routine over the standard JOIN command, or the PEDIT>JOIN command. I also stay away from using standard lines, seems to cause problems with many commands. They all seem to require polylines.

I tried to replicate your bug using the standard join command and it appears to annotate correctly.

I used the join nearest command and told it to convert the segments to polylines (which it did). I then auto annotated the polyline and it correctly created 2 sets of bearing/distance labels (one for each segment). I'm using 2011 Autocad and 2011 Carlson Survey/Civil

That issue is in my version 2007. I have always worked around it. I always use the mapcheck routines before issuing a plan and that report will give two dimensions on that line.

Also I use "auto dimension" on my plans and that routine will also dimension both polylines and in that way a visual review will depict the two dimensions and I can take what action I want.

If the only requirement is to join two lines that are adjoining, I would steer clear of that command (since it has options to average endpoints and change bearings and distances).

I type J at the command line, hit the space bar, select my lines, hit the space bar.
JRL

Carlson Survey 2004 did not do what you are describing, but the 2006 version does. It seems that 2006 maintains the vertex at the join point, whereas the 2004 version didn’t.

Deed Descriptions around these parts often express two distances along the same course to incorporate a monument such as an iron pin set off the edge of the road. Carlson 2004 would eliminate any vertex falling on a course identical to the preceding call when the lines were joined to form a polyline, thus necessitating the recreation of the monument position.

Version 2006 maintains the vertex, eliminating the need to recreate the monument position.

I actually like the feature (or bug).

I agree. All our bearings and distances are derived from points, not linework. There are all sorts of wacky things that could be going on with the lines.

Fillet 0. Then do a separate compucheck (new drawing new crd file) for closure. It's worked for me for the last 20 odd years. Doesn't matter the software....just do a separate compucheck and print. Trusting too much in software is ...well...should I say more.

Tommy, I agree with that.

What we do is a product of our survey, period.

The linework is to show that on paper or other graphic representation and that linework is only artwork really.

It is true that the current cad programs generate mathmaticly correct placement of linework, yet it it dangerous to rely upon that completely as your only computation for location.

I agree with the suggestions about checking; that is why I found it in the first place. I get a bit worried when a software highlights an entire line when you click it to annotage it, yet the annotation only annotates part of it. Sort of like clicking a boundary poly line and seeing it highlight, but the area is not the area inside the highlighted polyline.

I should not have called it a bug. I should have said that I recommend that when the join nearest command is used that the software mention that the new line is a polyline. This issue won't catch me again, but what about the millions of lines that will get annotated in the future by people all over the world....or my drafter or something closer to home.

All said and done though, in my opinion Carlson is way out front and better than anything I have ever used--by far.

When you rejoin the two lines the vertex remains at the endpoints of the two lines at the join point. You can remove the vertex from this point, then you have a single line of the correct length.

I agree. The problem I have is that if the lines are collinear, I wish the software would make it simply one line. But now that I know it exists, I won't make same mistake. I use point to point usually anyway.

I'm not sure which version you are using, but in Survey 2010 you can uncheck a box that says "Convert lines and arcs to polylines" and you end up with only lines. IF you check "Average end points together" you will end up with two line segments of equal length.
The only way then to get one line is to indeed make the segments joined polylines and then label them .I think their use of the terms "Join Nearest" is the problem. They are extended to an intersection, but they are not actually "joined".