Move project to origin point

[Anonymous]

I am having issues with my template for few months and I can't find the cause of the problem.

I am coming from the thread below

https://forums.autodesk.com/t5/revit-architecture-forum/template-corrupted-with-graphic-issues/td-p/...

Today, I have learn that apart of the project base point, and survey point, the revit files have also a origin point hidden. I thought that the 20km rule was between the model and the project base point, but apparently it is between the origin point of the revit file, and the model (I don't know if it is different rule, I had just misunderstood the rule at the beginning).

I have seen the issue with the hatch contour is resolved once you move the hatch close to the origin point (It was already in the project base point, but the project base point was like 12km away of the origin point), so in order to make another test and see if that is the cause of all the problems in the template, I want to move the whole project, model, details, everything, close to the origin.

Does anybody know how to do it? how to move a model close the origin point??

Regards

[loboarch]

Nice video. Kind of analog throwback style with props. i guess this is one of those subjects that needs that sometimes.  I have the same cutting mats at my house.  

We are taking some of the points from this conversation to try and improve the help topics on this subject.

Clear as mud right?

[SteveKStafford]

---

@loboarch wrote:

Clear as mud right?

---

Yahshooeryoobetcha! Thanks for listening in Jeff.

[barthbradley]

Yes, @SteveKStafford, your video describes exactly how I have always thought of the relationship – but only flip-flopped (PCS moving; SCS stationary and anchored to IO). I saw a presenter use this same example your video shows, in a Revit Coordinates seminar back in 2009 at AU Vegas. Was that you?

Anyways, thanks again Steve. This has been great discussion. I know it was hair-pulling for you, but I’m glad you persevered and converted my thinking. Strange though; not until we started arm wrestling here, was I was ever stymied by thinking of it the other way around. 

I remain a big fan,

Barth

P.S. I suppose now you’re going to tell me that the Sun doesn’t revolve around the Earth. Arrgh!

[SteveKStafford]

---

@Anonymous wrote:

Yes, @SteveKStafford, your video describes exactly how I have always thought of the relationship – but only flip-flopped (PCS moving; SCS stationary and anchored to IO).

That's what I thought was going on and why I stuck with it.

I saw a presenter use this same example your video shows, in a Revit Coordinates seminar back in 2009 at AU Vegas. Was that you?

No, not me. I didn't use any props. It might have been Theresa Martin or Paul Aubin. I did a Virtual Class on the subject that year.

P.S. I suppose now you’re going to tell me that the Sun doesn’t revolve around the Earth. Arrgh!

I exercise my 5th Amendment right...

---

[loboarch]

---

@Anonymous wrote:

I saw a presenter use this same example your video shows, in a Revit Coordinates seminar back in 2009 at AU Vegas. Was that you?

No, not me. I didn't use any props. It might have been Theresa Martin or Paul Aubin. I did a Virtual Class on the subject that year.

---

 I think that presentation was David Baldacchino.

---

[timpy6]

I know this is an old thread. But, based upon what you’re saying is it possible that the Internal Origin point is simply (and always) the location of the origin of the Project Base Point coordinate system. They do move together when the PBP is clipped, and the panning effect observed when moving the clipped PBP could be due to that the viewer's "view" reference has shifted to the Survey point during that PBP clipped move. All moves need to be relative to something.

This is easy to test by moving the PBP while clipped and then right clicking and seeing if Move to Origin is available or not. If it’s not available then it’s another cue that the Internal origin is the same thing as as the origin of the PBP coordinate system origin. In that case there are not three coordinate systems in Revit, but only two. I temporarily don’t have access to an earlier Revit to test. 

thanks,

Tim

[timpy6]

Per my above comment ... Of course you'd have to unclip the PBP before right-clicking to try to move to origin.

[SteveKStafford]

The Internal Origin never changes and both coordinate system's origins start out aligned with the IO (stock templates). Beginning in Revit 2020 the PBP does not have a "clipped" state anymore, no paperclip icon. This is consistent with the fact that the PBP (while clipped in the past) did not really move the project away from the IO. People believed it did but what really moved is/was the SCS.

The only true and practical reason we've ever had to move the PBP is to enable a Local Coordinate System origin that Spot Coordinate annotation can reference, where the PBP icon is placed instead of the IO or SCS. Spot Coordinate and Elevation annotation can reference one of three coordinate systems: Project Base Point, Survey Point and Internal Origin.

Technically the Relocate Project tool was equivalent to moving the PBP (clipped state) manually (dragging) or with the Move tool. With the clip icon removed from the PBP we have to use Relocate Project since dragging (or using move) only behaves like the not clipped state used to.

[timpy6]

Thanks for the reply. But, (original question not answered) do you think that the Internal Origin is simply equal to the PBP coordinate system's origin point? Are they actually the same thing?

Thanks,

Tim

[SteveKStafford]

The PBP (Project Base Point) is an icon or annotation (so is the Survey Point). It is a marker, something we can see and touch. Neither the PBP or SP are their corresponding systems. They are annotation elements that are related to or tethered to the Project Coordinate and Survey Coordinate systems.

The PBP is not the actual Internal Origin. Since 2020.2 the Internal Origin (or IO) has its own icon which can be visible or not via Visibility/Graphics > Site category. Initially, the PBP and IO are at the same location, in stock templates, unless you move the PBP (>2020 or <2020 while not clipped). When the PBP is moved its location provides an alternate or localized origin that spot coordinate/elevation annotation can reference.

[timpy6]

Thanks again, but you're not reading my question literally. I knew everything you just stated. But, I just wanted to confirm my belief that the Internal Origin is equal to the PBP coordinate system origin. I believe that it is true. Whenever you used to be able to "move" the PBP clipped it appeared to take the Internal origin with it. Or, it appeared to move but actually just shifted the Survey point. Either way they seem welded together. That's one clue why they are permanently linked and thus the same entity. You're answering lots of beginner questions, but not the literal question I asked.

Thanks,

Tim

[ToanDN]

No. Pre 2020, when you move the clipped PBP, you just pan it on the screen, the only thing is moved is the SPC, to the opposite direction, of course.

[timpy6]

Ok thanks. I respect you’re opinion. I think that the fact that nether the Internal Origin nor the clipped PBP (in previous versions of Revit) could be moved, and that the the Internal Origin appeared stuck to the PBP coordinate system origin makes me think that there are only two coordinate systems in Revit. And, that the Internal Origin is equal to the PBP coordinate system origin. I’d be interested if you had any way to prove otherwise. The fact that you can’t move the Internal origin nor the origin of the PBP coordinate origin only seems to prove my theory. 

On another related note, maybe a new thread, I’m wondering if Revit actually stores any GIS information retrieved from a Civil 3D file (other than northings, eastings, elevation). Does Revit store and use what state plane coordinate system is being and what zone used? It doesn’t seem to show that information anywhere. In AutoCAD/ C3D you can choose that information and view it in drawing properties (HARN, SPS, NAD83). In Revit you only see numbers but no projection coordinate system name or zone that you acquired from the linked CAD file. 

I guess that if it can show up on the world map after acquiring coordinates then it must be recognizing the coordinate system and internally making the mathematical calculations for the global location. If that’s true then it’s surprising that you can’t see the information in Revit. 

[SteveKStafford]

I must be providing too much information then...

No, they are not the same thing.

One is the immovable fundamental origin for all element data stored in the model the other is a graphic symbol. There is an actual Internal Origin icon now in addition to the Project Base Point. If you move the PBP away from the IO it begins to identify the origin of a localized system (third coordinate system).

[SteveKStafford]

---

@timpy6 wrote:

...I’m wondering if Revit actually stores any GIS information retrieved from a Civil 3D file (other than northings, eastings, elevation). Does Revit store and use what state plane coordinate system is being and what zone used?

---

Revit's location feature is macro not micro design and related to latitude/longitude but it does not affect or define shared coordinates unless a source DWG is using the Geo Location features. Location is used by Revit for model analysis operations while shared coordinates are used for file sharing linking/exporting to other software.

Revit has no internal knowledge of state plane coordinate systems like AutoCAD does, perhaps in the future.

[timpy6]

I did some exercises with moving PBP and Survey while watching spot coordinates and I saw that PBP Coordinate origin seems to indeed be it's own entity separate from Internal Origin. What surprised me was that the PBP displays it's coordinates in reference to the site survey coordinate system rather than from its own coordinate system. What's the point of having a separate coordinate system if its point doesn't read from it. It's like a second unclipped survey point. That is a bit odd and seems unnecessarily confusing. It's too bad you can't edit its type to report its own coordinates. Thanks.

[barthbradley]

You may find this enlightening:

https://s3.us-east-2.amazonaws.com/pfacs.downloads/Conferences/Aubin_HAND_2015_RTC_Shared_Coordinate...

[timpy6]

Thanks for the link. It's funny that he starts calling the PBP coordinate system the "Internal Coordinate". Maybe it was before the Internal point was a big deal. But, other than that he has always been a very thoughtful and helpful teacher.

Some other new craziness that I just noticed is that Spot Coordinates are inconsistent. A spot coordinate set in Type Properties to origin of Survey Point does not actually measure from the Survey Point symbol, but it measures from the origin of the survey point coordinate system. That's fine. Yet, (in a thinking reversal) when a spot coordinate is set to a type with origin of Project Base Point the spot coordinate measures from the Project Base Point symbol itself and not it's origin. That kind of inconsistency is one part of why this stuff is unnecessarily difficult to figure out. I have to reverse my expectations when I'm adding the spot coordinates -- while I'm using them to figure out why the PBP is not displaying measurements from its own coordinate system. Simple tools that are adaptable and consistent are far more flexible and easy to understand than tools that incorrectly try to guess things but guess wrong. 

[SteveKStafford]

The Survey Point is also an annotation/marker that can be either attached (clipped) or detached (not clipped) to the survey coordinate system. The Survey Coordinate system origin is what the Spot Annotation references regardless of where the survey point is located relative to the survey coordinate system. That's because the origin of the survey coordinate system matters because it is matched/aligned with the source DWG or survey file's World Coordinate System origin.

Re your comment about the PBP displaying coordinates relative to the Survey Coordinate system...yes that is confusing. I've been asking them to change that to display the coordinates of the Project Coordinate System instead.