Annotative text rotation point when set to match orientation to layout

[mathew.neilson]

Hi,

I have looked everywhere and I cannot find a solution to this problem.

Apparently text will always rotate about the bottom left grip and not the justified grip.

This is a massive issue that makes this great feature virtually worthless.

If the text is going to rotate in multiple viewports you need it to stay in the same place!

[tcorey]

You're talking about when you do a Dview Twist? The text "rotates" about the center of the viewport, not either justification point. If it's out of position after the twist, you can move it in individual viewports.

[mathew.neilson]

Hi Tim,

No, I am talking about using annotative text so I don't have to do that.

My text is in a xref, so if I move or rotate it; it will affect all the other drawings it is xrefed in.

The whole point of annotative text is that you don't have to duplicate and modify the text for different viewport scales.

The match to layout orientation means it automatically rotates horizontal no matter what your viewport/dview rotation.

Here is an example someone else posted that has suffered the same issue:

http://www.cadtutor.net/forum/showthread.php?56989-Annotative-text-match-orientation

(hope im allowed to post a link to their site...)

[tcorey]

The whole point of annotative text is that you don't have to duplicate and modify the text for different viewport scales.

---

Well, not the whole point, but, yes, that is a major part of it. What I was saying is that you are able to move differently-scaled versions of an annotative object to different locations. If at 40 scale a Dview Twist of 15 degrees makes two pieces of text overlap, you can move one, without that affecting the same object in a 10 scale viewport. Maybe they don't overlap at 10 scale, so you don't need to move anything.

And I was wrong about how they rotate. While they do rotate about the center of the screen when Dview Twist is invoked, they also pivot, like you said, about the LL corner even if it is justified center, middle, etc. Wish list.

Best regards,

Tim

[rodney.page]

Hi Matthew,

To understand your issue better I have attached a sample drawing.

Let us know if this explains it accurately.

[rodney.page]

Hi Matthew,

Please refer to both layouts in the sample drawing to see the behaviour displayed.

Layout 1 is not rotated.

Layout 2 is rotated.

Thanks & Regards,

[mathew.neilson]

Hi,

Yes that is it.

[mathew.neilson]

Hi Tim,

Thanks for your reply, I did not know you could move the different scaled "anno" versions.

We don't use dview twist, we rotate ucs and plan it, but it should still be usefull when the scale is different.

My problem is the scale is the same. So its the same anno version that I need at multiple rotations.

So wish list it is I guess...

Thanks for you help.

[rodney.page]

Hi Matthew,

Could you please escalate this forum discussion to Product Support so we can lodge an enhancement request on your behalf.

[mathew.neilson]

Hi Rodney,

I'm sorry but I'm not sure how to do that?

[rodney.page]

Hi Matthew,

I will escalate it for you.

Regards,

[Sinc]

Be very careful when using a UCS in C3D.  It can work OK if you only change the UCS in paperspace, but it's a very bad idea to use a UCS in modelspace, except for maybe temporary changes to get Mtext or Mleaders or Dimensions placed correctly.  Then you should always switch modelspace back to WCS.

The problem is that placing Cogo Points, or importing/exporting data, or XREFing data, do not honor a UCS.  We recently got an airport taxiway that was designed with all linework near 0,0 in modelspace, with everything twisted so that the main taxiway was horizontal.  Then the Engineer applied a UCS to get "real world" coordinates.  And they created Alignments, Profiles, and Surfaces on their linework.  Unfortunately, all of this data is useless to us as Surveyors, since we can't place Cogo Points on it and get real-world coordinates, we can't import field shots and have them show up on the linework, we can't export the C3D entities via Trimble Link, etc., even though they think everything is OK because they can set the UCS and ID coordinates that work.  Everything in modelspace should be done on WCS, matching the real-world coordinates.  Otherwise you can create real nightmares for others.  Then feel free to use a UCS in paperspace viewports, should you choose (although I personally prefer DView TWist in both modelspace and paperspace viewports).

[mathew.neilson]

Hi Sinc,

I have only worked with two large civil & structural consultants in the last 10 years and they both use UCS rotated not dview twist.

All drafters are trained to always set the ucs to world when creating/bringing in xrefs; and it is a easy habit that rarely gets stuffed up unless, as you said, a engineer sets up the xref or a novice drafter... As such, it is picked up quickly by those aware of it, if it ever happens. Architects drawings seem to be the only ones we have trouble with in my experience.

The great thing is that you don't have the confusion of multiple view modifying commands. No dview or snap angle plus ucs for text, leaders & dims etc. Not to mention 3d drafting, where the ucs is the one you have to master control of?

I guess it's just what you are used to. But I don't think you should say it is bad idea, as is used successfully by alot of companies who have built their cad systems around that methodology over the last 30 years.

I appreciate your concern and advice and I can see that it is a fullproof method of avoiding a massive issue. I did not know the civil 3d issues it would create and thank you for making me aware of that, as we are just beginning to try and use its features fully rather than do the design in other packages.

[Sinc]

Civil 3D hasn't been around for 10 years yet, so I'm guessing you're new to it.

And while you can set a UCS in C3D modelspace and ID the coordinates you think are correct, setting Cogo Points, Importing field data, exporting field data, none of it honors a UCS.  So just because you can set a UCS in C3D, don't think you aren't creating loads of trouble for everyone else you work with.  This is a lesson we've learned the "hard way"..

[mathew.neilson]

Hi Sinc,

I meant we have been using UCS rotated for 10 years.

And yes I am new to C3D, we tried it a few years ago when it was no where near as good as it seems to be now.

We are trying to convince the engineers to move off their old design software and into C3D... but its a slow movement.

I will take your lesson though and let the drafters/surveyors/engineers know that we should be using dview, when we are setting up a project in C3D properly, not just importing linework as we are now...

Thanks for your help.

[Sinc]

We just got a runway project where the Engineers used a UCS to "force" data to the correct coordinates.  We couldn't use any of it, without moving all their Alignments, Profiles, and Surfaces to the Airport's "real-world" coordinates, matching all the project control.  Created quite a bit of extra work, that would have been completely unnecessary if they hadn't used a UCS.

It can be OK to use a UCS in paperspace viewports, but all your modelspace stuff in C3D should be done in WCS (except maybe for labeling Mtext, Mleaders, or Dimensions, which can be done in a UCS, but then modelspace should then be switched back to WCS).  Otherwise, you (or your collaborators) can find themselves falling down the rabbit hole into the other side of the looking glass...

[rodney.page]

Hi Matthew,

I have posted the solution below as discussed offline for the benefit of other users.

The reason annotative TEXT entitites rotate about the lower left in the viewport it is has been designed to behave this way, that is the main grip point is always at the lower left of the text.
 
Development suggests using annotative MTEXT instead of TEXT as the main grip point of an MTEXT entity depends on its justification setting, that is if the MTEXT is justfied in the centre the MTEXT will rotate about this centre grip point. 

In conclusion I would recommend in the future adopting this workflow of using Annotative MTEXT to ensure the MTEXT will rotate about the centre grip point, which coincides with the Justification.

As an alternative to MTEXT to label your parcels of land have you considered Labels in AutoCAD cIVIL 3D.
 
I have attached a link to a screencast video presentation without audio that steps through creating parcel labels.
 
http://screencast.com/t/giIViTDUVohy

In this example I have simply drawn a series of land parcels 10m x 5m using line command in AutoCAD Civil 3D.

I then convert these to parcels using Civil 3D vertical, but before doing this I ensure the Parcel Name behaviour has its Orientation Reference set to the Value "VIEW".
 
This orientates the Parcel Name to whatever angle the viewport is set to as demonstrated in the video.
 
I hope this is useful as an alternative workflow in the future.

Thank you