Match lines wrong after alignment edit

[rkmcswain]

We have created some sheets using the plan production tools, and everything was OK.

Later on, we had to edit the alignment, which changed its length slightly.

I expected the match lines to either stay put and the station numbers would change -or- the match lines would move to the new location based on their station value.

But instead, what happened was that the "diamond" grip (for the match line) moved to the new location, but the actual match line itself did not move. So now a match line that should be at station 139+00 is actually constructed at 138+85. If I were to move the grip to make up the difference, then the labels are wrong..

What is going on and how do I fix this? Thanks.

[sboon · Accepted solution]

I've seen similar behaviour - try this.

Grab one of the triangular grips at the end of the match line and change the length.  The position of that endpoint will jump to almost the correct location, relative to the station that the matchline should be at.  You may have to stretch both ends of the matchline several times but it seems to eventually move the line to the correct location on the alignment.

[rkmcswain]

I will give that a try and report back. Thanks.

[Joe-Bouza]

Hi R.K, I have been through this issue with a support request; the developers intent is that the Plans are produced once the design is complete, not for setting up sheets prior to designs commencement. I know sounds bassackwards to me too, but that is how it was explained to me. Their fix/ work-around is to recreate the sheets! God bless anyone that has 40 hrs of PS work invested.

Joe

[Lisa_Pohlmeyer]

I ran into this just last week, the match lines are associated based on the view frames, thence the previous post about recreating sheets.  I don't like it either.  In my case, I was lucky I shortened my alignment and I just accepted the unnecessary data at the beginning of the view.

[mnorton]

Happy Tuesday, Randy.

[rkmcswain]

---

@Joe-Bouza wrote:

Hi R.K, I have been through this issue with a support request; the developers intent is that the Plans are produced once the design is complete, not for setting up sheets prior to designs commencement. I know sounds bassackwards to me too, but that is how it was explained to me. Their fix/ work-around is to recreate the sheets! God bless anyone that has 40 hrs of PS work invested.

Joe

---

That is because the "developers" have never had to produce a set of plans themselves. We had to submit a 20% set of plans that had to include cut sheets, and part of the design change from 20% to 50% was the slightly alter the alignment.

So are you saying that Autodesk does not consider this a bug and therefore it is not being fixed?

[mjung]

With this topic recieving 440 views at the time of this post it seems like quite a few poeple have an issue with this. We have been dealing with this on quite a few of our project and have used the grip edit work around.

We are still on 2009, has this been fixed in the newer releases?

Just wondering as I get back to fixing 20+ matchlines on the current project....

[Joe-Bouza]

Hi RK, sorry I lost track of this thread. Yes the position of the Tech support for the SR was that the software is working as expected.

[Anonymous]

This should definitely be fixed by Autodesk. They make an effort to make everything dynamic due to chages that may come up, but when it comes to actually presenting that information, its a take it or leave it approach? At the least, it is misleading and should be clear that changes to the alignment are not tolerated. I am in the 11th hour of finalizing an 11-mile road alignment and we are just now realizing that we either have to recreate all our sheets or start doing it the old school way.

[Aaron_L]

wow.

What planet are these developers from?

Not only do I have to produce sheets for my clients long before the alignment is finalized, I have many engineers that expect to see paper to mark up in the earliest stages of design.

Re-cutting sheets is an absurd “solution”.

Bad code-monkey, no banana

[Sinc]

The problem is far worse than this.  If you have a full-blown corridor with FG Profile, offset aligments, and tons of Corridor Regions, a slight alteration of the Alignment can creaste a huge mess.

Autodesk definitely missed the ball on this one.  I have no idea how they ever got the idea that Alignments are frozen early in design.  It's a major problem.

[jmayo-EE]

Still an issue..........

[rkmcswain]

  jmayo wrote:

Still an issue..........

Good to know, although I have not touched the plan production tools since that experiment.

[Cadguru42]

---

@Anonymous wrote:

Still an issue..........

---

Even if Autodesk realized their idiotic mistake I doubt it'll ever be fixed. It seems like once the programmers add a feature it's left to rot the way it was introduced. I wonder if the original programmer(s) who did the Plan Production tools is even still with Autodesk anymore? That would explain why new features never truly get fixed or updated in later releases, such as pipe networks, alignments, profiles, etc. 

[mnorton]

John,

Funny you mention plan production.  I worked with one of the original programmers (Jules Brenner) on Plan Production. At first I was excited but that didn't last long.  Jules was very receptive and I thought we were making progress but my first beta test wasn't even close.  I never heard anything after that one and only test.  What a disappointment that turned out to be.

And I agree with you on the broken pieces.  There's nothing worse than being in the heat of production and run head on into yet one more obstacle from the software.  I've met many of the programmers but they're not to blame.  They program exactly what's given to them.  I blame the program managers.  

Autodesk was so intent on distancing Civil 3D from Land Desktop that they lost sight of the fact that after 25 years of development Land Desktop was a pretty good program.  I don't miss it but the first question for every Civil 3D function should be, "Can it do this faster and better than Land Desktop?"

[jmayo-EE]

I gotta tell you Mike I don't blame the PM's. I would bet that the direction of their limited recourses is firmly controlled by the mothership. 

[rkmcswain]

mnorton wrote:

.... they lost sight of the fact that after 25 years of development Land Desktop was a pretty good program.

The rest of your message rings true, but LDT was a "pretty good program"?? I guess that depends on your POV, but there certainly was not 25 years of development there. The last 1/2 of it's life was pretty static and it showed by the time they buried it. I'll take C3D with all it's holes, bugs, and half-baked features over LDT any day.

[jmayo-EE]

" I don't miss it but the first question for every Civil 3D function should be, "Can it do this faster and better than Land Desktop?"

Very true with this. I've seen many forms take the, "Make C3D do this just like I did in LDD" approach and it negates all of the improved function and kills production.

The only things I miss from LDD are a stable grading object and a quick daylight polyline....Yes I have been saying this for too long on this board...but I could NEVER go back to LDD. Static model and recreating them from the start with every revision...

[mnorton]

John,

How many resources does it take to simply tell a programmer, "Fewer keystrokes."?  They hear it at the gunslinger events.  They see it in the wish list. If the PMs aren't getting it done find new PMs.

Mike