Clipped Project Base Point (2020.2)

[Anonymous]

Hi all,

I've recently updated to Revit 2020.2 and noticed there is no longer an option for a clipped Project Base Point. This is a major issue for issuing IFC files in Real-World Coordinates. For example if our agreed X/Y location is:

X: 402,950,000

Y: 295,800,000

In Revit 2019 we would enter the above values into the Project Base Point whilst it was clipped meaning that the IFC would be exported based on the values entered above. 

Screenshot below shows the model setup in Revit 2019:

If I place the corner of a column onto the Project Base Point, and export an IFC file the Coordinates are displayed in relation to the values entered into the Project Base Point which is perfect.

The solution mentioned here: https://knowledge.autodesk.com/support/revit-products/troubleshooting/caas/sfdcarticles/sfdcarticles... to use the re-locate project command doesn't work in this scenario because I cannot enter a value greater than the limit defined in Revit.

Therefore can I ask how I export to Real-World Coordinates now that the Clipped Project Base Point doesn't exist? Can we get the Clipped option back into Revit 2020?

[barthbradley]

Note: The project base point clip has been removed in Revit 2020.2. To move a clipped Project Base Point, click Manage Position Relocate Project.

[SteveKStafford]

Moving a clipped PBP was an alternate means of defining the Survey Coordinate System (Survey Point). Removing it merely reflects the reality of what was always true in the past.

If you look closely you find that the project does not export any differently after moving it clipped UNLESS you then export using the Shared Coordinate system instead. Moving the PBP unclipped provided a "local" coordinate system revealed with Spot annotation (coordinates/elevation). The PBP cannot now or ever (in the past either) be separated from the Internal Origin.

[Anonymous]

This doesn't work in the above workflow because I cannot enter a value greater than 9144000mm. Therefore how do I enter these X/Y values now? I can't enter it into the Project Base Point because there is a limit on that also, whereas in the past versions of Revit I could enter the values in the above example without any issues because the Project Base Point was in a Clipped state.

This change doesn't just affect IFC Files but it also affects DWG files also in which I cannot issue a DWG in Real-World Coordinates either.

[SteveKStafford · Accepted solution]

Manage ribbon tab > Coordinates > Specify Coordinates at Point (SPaC)

This assigns the coordinates you enter to the "point" you select. Move the Survey Point (not clipped) to a specific location in the model that you know what the coordinates are. I change the project units to match the kind of values I'm entering to avoid any rounding issues during the command. Use SPaC. Then I reset the Project Units to whatever we are actively using.

or

If you have a survey file you can link it, position it as required and then use Acquire Coordinates. This defines the Survey Coordinate System without knowing the coordinates. It moves the Survey Point to mark the origin of the survey files World Coordinate System.

Export to IFC using Coordinate Base: Shared Coordinates.

[Anonymous]

Hi Steve,

Thanks for the reply, followed your steps and this workflow works perfectly!

Cheers,

Marcus

[SteveKStafford]

Great, glad it helped. I must have been tired when I used the acronym SPaC...should have been SCaP 😉

[MelonieB]

Trying to wrap my brain around what I consider a disaster in removing the clipping for the PBP (and no, I did not know there is a beta forum where they asked about this - how is anyone to even find that such a thing exists?), and I am trying to follow your pointers (@steve_stafford). I appreciate the time you have put into answering many people's questions on it, by the way! 

As someone who understood the functions of the SP and PBP with their clips/unclips of days old, I don't even know where to start with this new process. One thing you said that didn't make sense to me is that the PBP can no longer be separated from the IO. In my screen shot, my PBP seems to be separated from the IO? What am I missing here? The screen shot below is just me testing out this new screwy process, so I have a few links in the file, hence the multiple IO's. 

I won't even get to my other questions (yet) about this whole thing. This one just really threw me off with your statement about the PBP relating to the IO. Would love to hear your feedback, it's likely just me misinterpreting things! 

[SteveKStafford]

The action of moving the Project Base Point (PBP) now is equal to moving it not clipped before. We have never been able to alter the Internal Origin (IO) of a Revit project. People believed they could by moving the clipped state of the PBP. It is/was an illusion. The truth is that the Survey Point (SP)/ Survey Coordinate System (SCS) moved a corresponding distance to how we moved the clipped PBP.

Fundamentally the concepts/capabilities are all as they were before but now they are in lock step with what truly occurs when they are altered.

If you used to move the PBP clipped you actually altered the position of the Survey Coordinate System and Survey Point. If you did that after using Acquire Coordinates then the SCS would get altered and screw up your previous effort.

If you move the PBP now it does not alter the SCS or SP. It enables a localized coordinate system that Spot Coordinate/Elevation tags can reference...exactly the same way moving a not clipped PBP did in the past.

Hope that helps?

[MelonieB]

Yep, the IO can't be moved, I'm with you on that. Your reply makes sense with how I understood the process to be before, I just got thrown off with your comment: "The PBP cannot now or ever (in the past either) be separated from the Internal Origin". Maybe I'm just over-thinking things! 

In the past, I never had problems with moving a PBP while in a clipped state. Exporting to navis or IFC still lined up all links properly when exporting with SCs. I never had any issues with the part where you said "If you used to move the PBP clipped you actually altered the position of the Survey Coordinate System and Survey Point. If you did that after using Acquire Coordinates then the SCS would get altered and screw up your previous effort." Typically, I would set up the SCS, acquire coordinates in a new file, then set the elevation of the PBP to the proper geodetic while clipped. Sometimes, if the whole building needed to move on site, we would have to move the PBP clipped to the new location. If what you say is true, that moving it in a clipped state in the past (or using the "relocate project" now, since there is no clip) will screw things up, then how would you re-position a building if the conditions for it changes, or position additional buildings on a site? Also note, I use a separate file that contains my property lines and a civil survey, which is what all links acquire coordinates from. I fully get moving the PBP now is the same as if it was unclipped, and i'm fine with that. I just need to understand what I'm doing wrong/need to do when my whole building has to move, or I have to add new buildings, like in a "campus" situation. 

Again, thanks for your response! I did try to find documentation on this, but I suck at google. If you have any whitepaper on this (the AD knowledge network is severely lacking), just point me in the right direction 🙂 

[SteveKStafford]

I've written on the subject of Shared Coordinates many times over the years on my blog Revit OpEd.

With the recent changes I need to revisit the collection. I'll have to consider consolidating and retiring some stuff with the hope to simplify what I've shared there. I've been muddling along with a new post titled "Shared Coordinates for Busy People"...but I've been busy 🙂

As such I'm sorry, I understand why you are confused by my descriptions. Prior to Revit 2020 when the PBP is not clipped it CAN be moved away from the Internal Origin (IO). However, it turns on a local coordinate system (LCS) that spot annotation can see and show us. As such I don't regard that as truly being moved. The Project Coordinate System remains unaltered, just the marker PBP is moved. They removed the clip from the PBP because it can only be moved to enable the LCS. The Relocate Project Tool predates the PBP being visible. The clipped state made the Relocate Project tool tangible and in doing so created a support nightmare for many firms. If I dealt with one support issue before the PBP I had 20 afterward. In this situation a trade of more mouse clicks to do something (that we do very infrequently) instead of many more support requests and project harm seems a reasonable exchange, to me.

As for screwing up the shared coordinates after Acquiring Coordinates (AC), I wrote that with the assumption that the buildings are correct now and that someone moving the clipped PBP would alter their position undesirably. What I was imagining would be wrong is precisely what you were hoping to accomplish in the situation you described, a feature not a bug. In my situations the PBP getting moved clipped was normally done by accident or because they misunderstood the clip states.

AC defines the Shared Coordinate System (SCS) origin and rotation nicely. It does not deal with vertical adjustments. Before the PBP I routinely used Relocate Project to move a building up or down "on site" so I'd be able to show the ground floor elevation relative to sea level (usually when a site model wasn't used). When the PBP appeared, I continued to use the tool even though the PBP opened the door to that approach too...also opening the door to many more support issues. I rarely if ever used Relocate Project for changing a building position in plan because that was sorted out by my preference (see below) for a site model. Speaking of which, as for revising a building's location on site...

I prefer individual building models and a separate site model that I can link a survey to, leave Project and True North in the same orientation as the survey, North being "up" in the Survey WCS. I leave the contours, if any, at their actual elevation. I link buildings to the site model, move them into position, rotate them and then move them up to their intended ground floor elevation. I used to use Publish Coordinates to define their relationship to the site. BIM 360 doesn't support Publish Coordinates, so I've stopped using any strategy based on Publish Coordinates. As such I either use AC only or Specify Coordinates at Point (SCaP). The advantage of AC is that it defines a useful relationship between Revit models, allowing for positioning: By Shared Coordinates. That means buildings can be linked to each other or site can be linked to a building...linking in any combination all based on the same site relationship. If the goal is only focused on exporting to Navisworks or DWG then AC isn't necessary at all, SCaP will provide all that is required.

In light of BIM360 and Publish Coordinates, in the site model I use a 3D building marker (a survey tripod) family to mark the prime grid intersection of each building model. I have a dynamo graph that extracts the coordinates, rotation and elevation of each building marker (types). This gives me a spreadsheet of location information for each building. I link the site model into the building model and move it into position, using the visible 3D building marker, so I can use Acquire Coordinates. All the discipline models are linked to each other using Origin to Origin so they are aligned regardless of site considerations. Then each discipline can use Acquire Coordinates by selecting "my" model (architecture). When a building location is revised, I move it in the site model, place a new marker (type) and run the graph again. Then I can use the new location information and Specify Coordinates at Point in each discipline model to reposition them in the real world. I just pass the new data along to the other disciplines if they aren't in this office and a short description of the steps to sort it out. Since I don't have direct control over other disciplines files all the time it contends with all the variables I've encountered so far.

HTH

[jesse-springer]

Turning on the "local coordinate system (LCS) that spot annotation can see and show us." i.e. unclipping the BPB and moving it then flipping the switch back to clipped. It's useful tool in conjunction with spot annotations to identify something relative w/o moving the entire project.   This affects me whenever receiving files from design and having to reverse engineer how to get the project into a user friendly location and orientation. 

When does the rhetoric about this process move from whatever scattered version it is now to - if you need the project to have real world coordinates (survey) build a site model and place your "normal" project on the site?   Like you @SteveKStafford  said above.

Signed

time lost

[SteveKStafford]

---

@jesse-springer wrote:

When does the rhetoric about this process move from whatever scattered version it is now to - if you need the project to have real world coordinates (survey) build a site model and place your "normal" project on the site?   Like you @SteveKStafford  said above.

---

Revit is designed to contend with either approach; a separate site model or a single building model. I prefer the site model approach because I find it easier to contend with change and I encounter more multi building projects than single building projects. Shared Coordinate tools/concepts were built specifically to relate a building model to the site and survey.

[MelonieB]

Thanks for your explanation, it sounds like we are on the same page, although I don't use a marker (family) as you do, but it's an interesting approach. I think I'll look into this a bit 🙂 Usually we require control over coordinates with our consultants, so moving buildings isn't normally an issue. With everything on BIM 360, it's easy to have that access, and so it's just something we write into our BIM Execution Plan 🙂 Typically, consultants don't want to handle the positioning anyway, they would rather leave it up to the prime (in my experience). 

Thanks again for your responses. I have a fair bit to try out on my end, and get used to this. I still wish the clip wasn't removed, but I can see both sides (sort of!). Looking forward to an update to your post 🙂

[MelonieB]

Ok, so I hate to keep on this, but I need to ask: How do you input the "angle to true north" in the PBP if it's always in an "unclipped" state? Typically, I set my angle units to something crazy, like 10 decimal places, so that I can get a more accurate angle than doing the "align selected line or plane". Then, I type in my crazy 10 digit angle in the properties box. I have two issues now: the first is obvious, I can type anything in there, but it does nothing. Secondly, even if I want to go the less accurate route of aligning to a line, I get the message that the action could not be completed, even before I can select the option to align, or choose 90 degrees, etc. I must be doing something completely wrong, but typing in the angle to true north in the properties worked like a charm in the past. How do I indicate a 10-digit angle now, and actually have my project north rotate? Is that something that can only be done when I did my "SCAP"? If so, now that I have specified my coordinates, how do I fix this? The angle to true north in the Site tab (under location) is greyed out (although, I have never used that option before, anyway). Hopefully I managed to explain this properly, lol! 

 

[SteveKStafford]

If you're using Acquire Coordinates AC then True North is defined as part of that tool, assuming the source file has been rotated. For example, with the site model approach true and project North are the same but the buildings are rotated for their real world orientation. When I link the site model into a building model I move/rotate/elevate to put it in the correct location and then use AC. True North is defined for me via AC. While I don't use Publish Coordinates anymore it also defines True North.

Otherwise I use SCaP to define the coordinates, elevation and rotation. I change the units of the project for Length to match the units I want to enter so rounding doesn't alter them. Afterward I restore the units to their normal state for the project.

[MelonieB]

Ok, but how do you rotate the project north with typing in numbers, as opposed to selecting a line or doing a default 90 degrees, for example? Essentially, no matter what I do, I cannot rotate my project in any shape or form 😞 This really shouldn't be so hard. <insert image of desk-flipping>

[MelonieB]

Pretty much losing my Shi* on this one, lol. On a whim, I decided to save my cloud file to my desktop (take it off of BIM 360), and then "rotate project north". Of course, the only option I have is to select a line or choose a default degree, not type in the numbers to my PBP as I did of days past. That seemed to work fine on BIM 360 before. So, I am forced to setting up my PBP offline,  and will be screwed if we come to find that our building is actually skewed more than we thought, which would require a new rotation (when we talk about existing buildings, of course). That would mean I'll have to save my file offline again, change the project north, then overwrite the BIM 360 file, which has other problems in and of itself. W.T.H.

[SteveKStafford]

Rotate Project North is an entirely different sort of action compared to Rotate True North.

Revit was designed to start a project with Project North, make it easy to draw. Once a survey is completed and available then Rotate True North is used. Rotate Project North became a command many years later because people consistently ignore the original intention to make it easy to draw and sort out site orientation secondarily.

Rotate True North is designed as an exception for view orientation while Rotate Project North is changing the orientation of the model relative to project origin and its original orientation. It's for a situation where you start your rectangular building extending East to West in the longest direction but then decide you want it to be extending North to South. That means the entire model and all views/annotation must also rotate 90 degrees.

Rotate True North and the view parameter Orientation (True or Project North) is a view specific acknowledgement that the building is truly oriented this way on site. The building model doesn't change its orientation with respect to the internal origin and coordinate system. Rotate Project North IS a change with respect to the internal origin and coordinate system.

When you start a model oriented to site at 33.568 degrees but then want a project north orientation because its is hard to draw at that angle...enter Rotate Project North. In that instance the building form is thought to be useful to pick a side that defines the "up" orientation. If not, sketch a line that does and pick that instead.

[MelonieB]

Seems like we have a few variables that are not too typical, such as starting with a survey before modeling, etc. Roughly about 95% of the time we are starting with a true north and a survey file in what we call our "SharedCoordinates" revit file. That being said, I don't understand why Project North cannot be rotated once the file is on BIM 360, though. I haven't tried rotating True North in a file that is on BIM 360, and I'm curious if that will work (don't have time to try right now - I have been fighting too long with this one hahah). I am still screwed if my project north has to change, especially once we get our Building Scan and try to line things up more accurately.