A quick post to mention this since I've already run into this issue with users several times. The latest update for Revit introduces a new icon to mark the location of the file's Internal Origin. This is what it looks like in the 3D view.
It's off in all views initially, in the stock templates. Reveal Elements will display it quickly in a view without having to use Visibility/Graphics to show it. It can't be selected, it's just visible to help understand where it is.
Edit: It seems existing projects that are opened in 2020.2 have this Internal Origin turned on in all views (many). That's a bug in my opinion. They should not be turning this on. Though, in my own testing it is not getting turned on with upgraded files. It seems to be existing 2020 files that get this turned after opening it with the 2020.2.
Project Base Point - You won't see the clip when you select it. Move it away from the internal origin and it is automatically behaving as if it isn't clipped. In other words, it isn't clipped anymore. We couldn't really move the project origin, only the Project Coordinate System could be adjusted to provide a local coordinate reference for the Spot Coordinate tool, for example.
The Survey Point remains much the same.
When dealing with linked files you'll find that the icons for each of these is also visible but halftone (gray) to differentiate from the host file's own icons. You can snap to the links icon's to help align the files, using the Move tool for example.
I'll have to return to the subject once we've gotten fully acquainted.
Edit: 11/24/2019
I traded a couple emails with Autodesk staff on this. My understanding (not a developer) is this is not merely something they overlooked. Consider when a 2020 file is opened in 2020.2 it is not going through an upgrade because the file format is compatible. This creates a scenario where they are not activating upgrade code to resolve the existing file's structure with a new version's structure.
Unfortunately this new subcategory gets enabled and its visible status is "on" at the outset. It's my understanding that "off" isn't an option...in this scenario...without also creating an upgrade scenario...which is conceptually a no-go...within a release year.
Upgraded files go through an upgrade process which imposes rules on that process...which includes a task that deliberately "turns off" this new subcategory. It's a quirk of the file open sequence/process.
I think they didn't expect it to be a significant issue. It doesn't print after all. It can negatively affect zooming behavior in many views though. User perceptions can't be ignored either. An unexpected "thing" encroaching on views is "bad"...similar to seeing a view's crop boundary when not intended.
To their credit, they asked if I agreed they should create a Dynamo solution to turn it off in all views. Naturally I encouraged them to DO IT! Hopefully we'll be able to say that such a solution exists soon.
It's off in all views initially, in the stock templates. Reveal Elements will display it quickly in a view without having to use Visibility/Graphics to show it. It can't be selected, it's just visible to help understand where it is.
Edit: It seems existing projects that are opened in 2020.2 have this Internal Origin turned on in all views (many). That's a bug in my opinion. They should not be turning this on. Though, in my own testing it is not getting turned on with upgraded files. It seems to be existing 2020 files that get this turned after opening it with the 2020.2.
Project Base Point - You won't see the clip when you select it. Move it away from the internal origin and it is automatically behaving as if it isn't clipped. In other words, it isn't clipped anymore. We couldn't really move the project origin, only the Project Coordinate System could be adjusted to provide a local coordinate reference for the Spot Coordinate tool, for example.
The Survey Point remains much the same.
When dealing with linked files you'll find that the icons for each of these is also visible but halftone (gray) to differentiate from the host file's own icons. You can snap to the links icon's to help align the files, using the Move tool for example.
I'll have to return to the subject once we've gotten fully acquainted.
Edit: 11/24/2019
I traded a couple emails with Autodesk staff on this. My understanding (not a developer) is this is not merely something they overlooked. Consider when a 2020 file is opened in 2020.2 it is not going through an upgrade because the file format is compatible. This creates a scenario where they are not activating upgrade code to resolve the existing file's structure with a new version's structure.
Unfortunately this new subcategory gets enabled and its visible status is "on" at the outset. It's my understanding that "off" isn't an option...in this scenario...without also creating an upgrade scenario...which is conceptually a no-go...within a release year.
Upgraded files go through an upgrade process which imposes rules on that process...which includes a task that deliberately "turns off" this new subcategory. It's a quirk of the file open sequence/process.
I think they didn't expect it to be a significant issue. It doesn't print after all. It can negatively affect zooming behavior in many views though. User perceptions can't be ignored either. An unexpected "thing" encroaching on views is "bad"...similar to seeing a view's crop boundary when not intended.
To their credit, they asked if I agreed they should create a Dynamo solution to turn it off in all views. Naturally I encouraged them to DO IT! Hopefully we'll be able to say that such a solution exists soon.
8 comments:
I am assuming you have not heard or seen anything in regards to a Dynamo script on this yet?
Yes, you missed my second post on this subject.
I just upgraded a 2019 project with a linked 2019 site file, both to 2020.2, and now I have gray marks all over all the views, which is making the sizes of views on sheets go all wonky. It's definitely affecting upgraded files.
If they are gray then that's linked files SP and PBP. Those do show up, not the internal origin of the host file that gets upgraded. The internal origin does not show up in the upgraded active file after upgrade.
It is the first time I came across this when setting up the project in shared coordinates today on the new Revit 2020.2 update.
It seems that internal origin is staying at the initial survey point location when moving project basepoint which was moving together with the project base point in the previous Revit versions including Revit 2020.0.
The solution seems to be moving the survey point opposite direction, but as we need to move it by around 530 km E/W and 180 km N/S (UK OS coordinate system) and Revit only allows a maximum move value of 9.144 km at a time this seems impossible.
I looked at the model I have set up in 2020.0 opening it with 2020.2 and the internal origin is at the project basepoint. My idea of how to get around this issue is to set up the project in Revit 2019 and upgrade it.
Have you come across a similar issue?
The Internal Origin will not, cannot be moved. Revit wants the model to be built "at/near" its internal origin (no farther than 10 miles in any direction). The Shared Coordinate System is designed to provide a way to reference site location (UK system) you're describing.
Your building/site (survey file) should have coordinates (benchmark) you can identify that relate to your UK benchmark. The easiest way is to link a survey that is drawn based on that UK system, move it so the portion of the site you're working on is at/near the Internal Origin and then use Acquire Coordinates. The Survey Point (while clipped) will move to mark the WCS origin of the source Survey.
Alternatively, I you can click on a specific location in the model and provide coordinates that relate to the UK system the use Specify Coordinates at Point, enter the coordinates in the dialog that appears.
DON'T build your model far from the internal origin. Check out my other posts about Shared Coordinates.
Hi, I have a question regarding the internal origin. Started to build my projects and levels without setting up correct distance from the sea level. Now I want to move entire project 90.3 meters above the sea level, I have used "relocate the project" and "specify coordinates at point" to move it up, but it only moved the survey point down by 90.3 m. Levels shows correct elevations but the problem starts when I want to create a toposurface which reference the internal orgin. It appears 90.3 meter above. Is there a way to move project 90.3m up from the orgin point ?
Unknown, Topo surface only reference the project's internal origin (zero). After creating the topo "move" it down by the same amount you used Relocate Project. If you need to edit the topo, move it back up and then back down afterward.
Post a Comment