Reset Revit Origin?

[ron.sanpedro]

We have a project that was started long ago, actually the second Revit project in the office, and I am pretty sure that a civil plan with an origin far from the site was referenced in, and the Revit model thus build well away from the origin. Now we are having problems bringing in the final civil (different CE) and landscape work. We can move everything in the DWGs to 0,0, set BASE to 0,0, and still have the insert miles away. So I am wondering if there is any way, after the fact, to bring the Revit origin back to something rational.

Also, I am looking for a step by step reference for coordinating origins, with information about how to deal with the two most common scenarios, namely having a Civil plan to start from, and not. And potentially having a civil plan to start from where the origin is miles from the site, and/or the civil you will start from is not even the same firm as the final civil work. And what is the best way to push out a shared coordinate. Do you just export perhaps nothing but a rough building grid early, so everyone starts on the same page? The manual does a good job of describing the commands, but I am looking for a more in depth overview of the actual architectural process, with the logic behind it.

Thanks!
Gordon

[sbrown]

Unfortunately I know of no way to reset revits coordinate(0,0) for teh project coordinates. So all you can do is aquire the coordinates of the civil file, ie bring it in move it into place, then use tools>aquire coordinates. Or you can use specify coord at point and put a tick mark at the 0,0, of the civil then use spec. coord at point and pick the endpoint of a line at that same location.

[twiceroadsfool]

We have a similar situation, where one of our ogiginal pilot Revit projects is still ongoing. Weve also discovered that its actually miles off the Revit origin, and the file isnt very happy about it. It makes things not display/snap properly in wall sections. When you zoom in, and try to snap to elements (drafted or modeled) you discover that you actually have to select the "phantom object" sitting "near" the displayed object. Everytime you move the zoom wheel, the phantom object moves, too, its not uniform.

Ive discovered far away from the origin = unhappy Reviteer. LOL...

[ron.sanpedro]

Ive discovered far away from the origin = unhappy Reviteer. LOL...

So is this something that the Factory could fix? I would love to send a goofball file off and get a Revit Origin at Grid A1 back. Anyone know?

Thanks,
Gordon

[Wes Macaulay]

I believe the problem is with OpenGL's fixed-point precision. Revit might be able to work with distant objects using shared coordinates, but unless you hide them they cause all sorts of problems in your project. Display errors, printing errors, that sort of thing. We've heard that Revit with its own coordinates has floating-point precision, but the display system in Revit is not nearly so precise.

[archjake]

I don't think that I know enough about this, but wouldn't this tool work. you can set any point in your model to 0,0,0 or any other known value.

From the menu: Tools / Shared Coordinates / Specify coordinates at a point

[sbrown]

Yes that tool does that but it makes that the "shared" 0,0 not the project 0,0. so if you have a site true north set, then use that tool you lose the site true north.

[twiceroadsfool]

We sent our file to support once... Theyre the ones who pointed out that we were a few MILES off the origin, lol... BUT, we were working at a feverish pace that week, and naturally, we had done a couple of days work (times 5 people) when we got the answer back. Subsequently, we never asked if they had anyway to restore the origin...

[crarchitect]

Apologies if I missing the point here, but why can't you just relocate all of your Revit project data back closer to the Revit 0,0,0? I suppose you might break the current alignment to the imported civil data, but that could be easily reset. What is preventing you from doing this?

Tools>Project Position>Relocate this Project

This Import Origin vs. Revit Origin issue is a common challenge, so I would enjoy hearing your solution!

[Wes Macaulay]

The Project Coordinates origin can't be moved. This is not a problem unless you have more than one coordinate system that you need to work with on your project. When the project only needs one 0,0 point, you can locate Shared Coordinates to align with the coordinates in question (Revit is more cooperative in this regard than it was in the past).

Now: you need to know that Revit ignores the BASE command in AutoCAD and assumes that 0,0 is the origin. Here's the deal: import a 100' circle with a 150' line from 0,0 going straight up drawn in AutoCAD with center 0,0 with the origin-to-origin option into Revit. The center of the circle will give you the Project Coordinates origin for your Revit project. This origin cannot be moved or altered; it's just there. I get users to put this into all their office templates so they know where this is and can use it effectively.

Now draw a (exactly) 5280' circle around the Project Coordinates origin. If the insertion point of the DWG (remembering that Revit assumes 0,0 in Acad is the origin) is such so that the whole DWG fits inside this circle, you're good. Otherwise, you're manually moving DWGs into place. So Revit works fine, provided the DWGs fit inside this 2-mile-wide circle. Revit objects can be outside this circle without affecting the insertion of DWGs.

An upshot of this: if the Shared Coordinates origin and the Project Coordinates origins are more than 2 miles apart, importing by Shared Coordinates always fails -- it defaults to center-to-center. So if your DWG is a mile wide and 0,0 is in the middle of it, the Shared Coordinates origin must be less than 1.5 miles from the Project Coordinates origin for import by Shared Coordinates to work seamlessly.

And since Revit ignores the UCS and only works with the WCS, you actually have to move the entities in the Acad file if you want importing to work. Since DWG entity locations are sacrosanct, I'm not sure what we're supposed to do in these situations. In the past we've just documented offsets between the Shared Coordinates origins in Revit (because you can never count on anyone building a Revit project from the ground up in the right location in Project Coordinates) and their proper locations in the Acad world. It's a medium-priority matter, but I think this needs to be addressed so that Revit can work better with distant objects in Acad.

[dfriesen]

Thanks for that interesting explanation, Wes - that answers some of those questions that come up where my usual answer is a little Gallic shrug. This goes in my "useful info" folder.

[christo4robin]

It seems that the Tools > Shared Coordinates > Specify Coordinates at a point command will not find a point and does not allow the use of snaps. In order to affect this command, I need to pick a vertical line and set its e/w to 0,0, then pick a horizontal line and set its n/s to 0,0.

Am I missing something?

[kenmarcus]

Chris,

I was under the impression that if you place walls in your location instead of lines and change to a 3D view you can pick the corner intersection and set 0,0,0 for X,Y and Z.

[mibzim]

Just thought i might add a little note to the end of this thread...

The client we are working has an enormous campus (well, its an airport), and for some reason they set their origin for all their dgn files about 2000 km away. They needed all their files in their coordinate system, so we followed the normal procedure - import origin to origin - and this didn't work. Called our local support. They suggested turning off all categories and then importing, which worked. Great.

A month later we noticed a ghosting effect on the floor plans. Contacted Autodesk support in September last year and didn't get a resonable response for a month, but it didn't seem critical. Came to do the detailing for this project in December, and (apart from being unable to use our detali views at all due to ghosting) every time we saved to central the file crashed unrecoverably. Worst was 8 in a day for one user - he got 2 hours worth of work done the entire day. So, we urgently contacted support through subsciption centre and local reseller, but didn't get any valuable feedback. Surely these facts alone make it a HIGH priority issue? Evidently not, because six months, 50 plus emails, and 5 cancelled conference calls later, we still haven't had any response that has been worthwhile. They eventually called on Friday to apologise and re-schedule another conference call. Great - the project is now winding down and they want us to use our time to fix the problem for future releases. As much as i want to see the program advance, we don't feel tremendously obliged to offer our help after they were so lacking when we most needed their help. Of course we will, but...

So. We discovered that it is basically impossible to relocate a revit project closer to the revit origin, which never changes. Neither does the project north, which can be a real problem sometimes. It deletes half your model every time you try to move, copy, mirror etc, and somehow not even the developers have been able to fix the problem.

We also discovered that shared coordinates merely performs a translation on the actual revit coordinates in order to report desired position. This must be Autodesk's 'legitimate workaround' to this evidently difficult problem. Seems strange that so little is said about this tool, and that users are even given the option to import origin to origin if it works so badly.

Our last discovery is that Autodesk support is not all that it is cracked up to be. I am such a staunch supporter of this product and tell and teach everybody i can about it, but this experience has been disasterous. I will concede that had i known about the shared coordinates we might have avoided the problem, but the mere fact that autodesk's response has been so appalling really makes me wonder sometimes. I know you guys are listening in the factory, and i always try hard not to sound disparaging about the work that you do because revit really is a great product, but a little bit of PR goes a tremendously long way. Even if it was an e-mail or phone call to apologise and acknowledge that it is a problem, and suggest that it might not be fixed soon due to the technical difficulty would have been great.

Will it ever be fixed? Maybe not, but please make the shared coordinates tool more prominent, eficient and easy to use and understand, because it would have saved us a heck of a lot of hassle and downtime. And remember that the best salesman for any product is a happy customer.

[twiceroadsfool]

That "ghosting" in the wall sections is exactly why we contacted support about trying to fix the issue. When you go to grab a detail componenet or an object in a wall section, the actual snap to it isnt where its drawn on the screen... Its a ghosted line around it, and its not uniform. It changes everytime you zoom in or out a notch.

If we try to zoom in too close, it says "Ann error has occured while drawing the contents of this window. This window will now be closed." Ive heard all the arguments that its hardware acceleration related, and that its Open GL related. But our settings work perfectly in every single other Revit model we have... Except this one.

Sure, we can do a select everything and relocate our geometry 19 miles, but it would annihiliate all the annotating weve done already, and its just not feasible...

[mibzim]

Aaron

We gave up trying to move the model, and have just had to live with the ghosting and windows closing all the time. Just make sure you have a working plan view open all the time in case it tries to close the last window you have open.

Also, if it starts to crash when you save to central, open a simple plane view and close all others before you save. In our case it was crashing every time it tried to regen the open windows dring the save process, and by only leaving the floor plan open (which didn't have such a big problem with ghosting) it seemed to work.

Good luck!

Note to autodesk: seems this isn't a small problem any more, but fairly widespread. Have you released a white paper on the issue yet?

[mibzim]

Factory? Hmmm.... no response

[twiceroadsfool]

Interesting notes on the STC with a simple view opened. A lot of other people int he office are having trouble with STC, im going to give that a try today...

[David Conant]

Factory says: This is one place where you have to follow the rules.

Revit's internal calculations do not like very large coordinate numbers. There are many number systems used in an app like Revit, some for calculating values, some for driving the display, etc. In some cases these systems differ in the precision of the numbers they can use. When numeric values are small, these differences in precision are insignificant. When numbers get large, the differences while still small on a percentage basis become large enough to effect the reults of display and operations. Thus, it is important to keep your Revit project near Revit's origin. (near means within 1 mile/1.6km) Revit's origin is near the center of the space made by the elevation symbols in the default template.

The Rules

Always build your building near the starting point of the default template.
Model it with Project North pointing directly up. (lay it out as you would have it appear on sheets)
If you are using a dwg based site, Link your site file Center To Center.
Move or rotate the SITE under your project until it is correctly positioned relative to the building. (do not move or rotate the project itself).
Use the Acquire Coordinates tool and pick the site.
This will set your project's shared coordinated to those of the dwg's wcs. True North will be the dwg's Y axis. Now your building knows where the dwg 0,0 is, but it can still record its own information in well behaving small numbers. It knows and can orient to either True North, or Project North. Once the shared coordinates are set, subsequent imports can be made origin to origin using shared coordinates.

[twiceroadsfool]

Factory says: This is one place where you have to follow the rules.

Revit's internal calculations do not like very large coordinate numbers. There are many number systems used in an app like Revit, some for calculating values, some for driving the display, etc. In some cases these systems differ in the precision of the numbers they can use. When numeric values are small, these differences in precision are insignificant. When numbers get large, the differences while still small on a percentage basis become large enough to effect the reults of display and operations. Thus, it is important to keep your Revit project near Revit's origin. (near means within 1 mile/1.6km) Revit's origin is near the center of the space made by the elevation symbols in the default template.

The Rules

Always build your building near the starting point of the default template.
Model it with Project North pointing directly up. (lay it out as you would have it appear on sheets)
If you are using a dwg based site, Link your site file Center To Center.
Move or rotate the SITE under your project until it is correctly positioned relative to the building. (do not move or rotate the project itself).
Use the Acquire Coordinates tool and pick the site.
This will set your project's shared coordinated to those of the dwg's wcs. True North will be the dwg's Y axis. Now your building knows where the dwg 0,0 is, but it can still record its own information in well behaving small numbers. It knows and can orient to either True North, or Project North. Once the shared coordinates are set, subsequent imports can be made origin to origin using shared coordinates.

Lesson learned, and understood.

Does Factory know of anyway to relocate a whole truck load of geometry without losign all of our annotations?

And even if we did that, would it correct the problems? Or is this file permanently toasted from the distance?

[Wes Macaulay]

Wow, David. That's one more complaint against Revit put to rest. I only wish that the information contained in your post was in the help file as a entry under "large coordinate systems".

Thanks for that!!

[twiceroadsfool]

Just one thing im not clear on...

If i have a site in DWG from a consultant...

Link Center to Center, Adjust the site, and use Acquire Coordinates, selecting the site.

Im unclear on what that means the next time i export, or import. Ive largely avoided CTC because as my model changes, doesnt the center of it as well?

For coordinating with consultants, ive always used OTO...

DO you just used CTC the first time before acquirinf coords?

[sbrown]

in your export dialog box there is a choice to export using "internal" or "shared". Once you have acquired the coordinates of a DWG, if you export using "shared" your export will have the same 0,0,0 and rotation as the DWG.

[twiceroadsfool]

Wow, thats good to know, lol.

So:

Import CTC. Rotate And translate site to proper location. Acquire coordinates from site. Export using Shared.

Fascinating... Till now we were going to go with the import a DWG with the crosshair at the origin, for reference, and go from there always exporting OTO...

Thanks for the tips! :)

Its not all bad, even with it 19 miles off, were easily motoring through this project, and its one of our more complex projects, in terms of deno, renov, etc....

[jeffh]

Wow, David. That's one more complaint against Revit put to rest. I only wish that the information contained in your post was in the help file as a entry under "large coordinate systems".

Thanks for that!!

I have suggested to my team members this information be included in the help files as well. I have also forwarded this along to the support team so a Knowledge base article/White paper can be created from the information.

[Calvn_Swing]

Let me ask a more philosophical question to David Conant:

I know that Revit was not necessarily designed with large campuses, renovations, or other similar project types involved. However, in such cases the location of the Origin is rather important, and Revit currently has a "you don't need to know" policy about the project origin. And the tools to work with the origin (shared coordinates, etc...) are rather cryptic in their effects on the model and how you should use them. I know that in a product as complex as Revit is that you can't make everything a no-brainer, but this is one area where I fail to see a reason for the difficulty.

In some projects, I want to know where the origin is, and I want to set it to somewhere specific. I want to display it on drawings, and I want it to contain information so when I send it to consultants they can have that information.

Autodesk own AutoCAD, Civil3D, and Revit, these problems shouldn't even exist. There should perhaps be a "project origin" and a "true origin" much like with project and true north. The process of setting project vs. true north should be a lot simpler than it is, and the process of setting the "true origin" can be just as simple.

Project origin should have:
It's own VG category.
It's own relocation tool.
True origin should consist of giving the project origin it's actual coordinate values.

That's it.

Now, when I export to CAD I should be able to export with either setting - project at 0,0,0 in the CAD drawing, or use the true origin value to have the CAD drawing show up in the right place for civil drawings. The same should be true for import. When importing a CAD drawing I should be able to import it using the true settings, and have an option to adjust it based on the project origin's settings. Does that make sense?

It is sort of what you are describing in your process, but it isn't some magic tool called "acquire coordinates" which leaves me asking - from what am I acquiring coordinates? What coordinates? What is this doing to my model? What is this doing to my drawing? I don't know... You have a nomenclature for Project vs. True north that at least makes some sense, but the coordinates are different! Anyway, my two cents...

[mibzim]

Factory says: This is one place where you have to follow the rules.

David
Thank you for replying. A part of me feels relieved to know that the factory has FINALLY responded. Knowing that you have listened and will include this in the help file means a lot to me - it is hugely important, and i can finally put the issue to rest after having it torment me for six... no seven.. months. It's a little disapointing though, that it had to get tothis stage before anybody would clearly state "THE RULES"... i had to learn the hard way and our office has certainly suffered because of it. How many more are there that have had the same experience?

A couple more points, and please correct me if i am wrong:


Model it with Project North pointing directly up. (lay it out as you would have it appear on sheets)
If a project changes half way through - say the site gets bigger / smaller - and it becomes more logical to rotate project North, there is no easy way to do this. I understand the technical reasons as to why this is difficult to do in revit, but this is still a limitation of the program.


Once the shared coordinates are set, subsequent imports can be made origin to origin using shared coordinates.
Please, please tell me i am wrong here, BUT, after having imported a DWG, moved it, rotated it and acquired shared coordinates, subsequent different DWG's will not import in this modified coordinate system. They too will have to be moved and rotated after being imported by shared coordinates, despite the message: "The project and linked file do not share coordinates. The links world coordinates will be aligned with the project's shared coordinates" Please confirm that I am not missing something here?

[mibzim]

Does Factory know of anyway to relocate a whole truck load of geometry without losign all of our annotations?

I might take the liberty in replying to your question here.

From my experience, there is very little chance of you re-locating your entire geometry in the first place. Autodesk have tried, and apparently they have not had much luck either. We had to get on and document our building despite the file being "toasted". (i like your terminology by the way!)

When exporting DWG's for consultants, you MUST remember to select "by shared coordinates" under the options settings of the export dialogue. You can only export VIEWS by shared coordinates, sheets will not work. We got around this by using a Coordination Plan for coordination with all consultants. Obviously they wont get all the annotation with this view, but they can refer to PDF's to get that.

[Steve_Stafford]

Living within the rules and planning for change and for flexibility as you move through design I prefer to always put the site in its own Revit project and link the building project(s) into that site project. This permits me to easily change the location of the building, the rotation of the building and the elevation of the building at any time. The site file is coordinated with the civil dwg file and the building is coordinated with the site file. I never have to worry about changing true North, just the positioning of the building on the site.

[sbrown]

Please, please tell me i am wrong here, BUT, after having imported a DWG, moved it, rotated it and acquired shared coordinates, subsequent different DWG's will not import in this modified coordinate system. They too will have to be moved and rotated after being imported by shared coordinates, despite the message: "The project and linked file do not share coordinates. The links world coordinates will be aligned with the project's shared coordinates" Please confirm that I am not missing something here?[/QUOTE]


The "should" come in. however there is a trick, you can't import them "current view only" and have them link into the right spot. I think its a view specific thing, they aren't model objects like when you link them without the current view only checked. So my solution is to link onto a DWG Links workset that is set to OFF by default. Note when you link, check the shared coordinate box it will still say they don't share the same but it "should" pop into the right place.

[mibzim]

Aaaahhh, another little trick to add to the help file!? Thanks scott, that works just fine...

Just one question on this point... One of my work mates that recently moved from another office is used to using the method you have described - linking in to all views (model) and placing in a workset that is off by default. My feeling is that this might increase the file size tremendously, especially when linking in large civil drawing files? It also just adds that additional place to look if something isn't showing up... I suppose though that if this is the only way to get the shared coordinates import to work then i can't argue too much with that option. Thanks again scott.

[sbrown]

Once a file is linked, you can copy/paste align it to other views, this has the benefit of then allowing you to bring it to the front or send it to the back, something you can't do when its linked.

As for file size, its really not an issue. The issue is drawing with dwgs, you will need to turn off complex dwgs or you will see very poor performance while trying to draw walls, etc.

[jtobin.68416]

I find this thread interesting because, while I already know that Revit likes to keep project data close to it's (mysteriously invisible) origin for precision reasons, I can't say I know where the 'safe zone' begins and ends.

Just yesterday, I was starting to link a site file to a linked building file, so I instinctively (actually through bitter experience) checked where the origin of the civil dwg was, and it was some unbelievably humongous distance from 0,0 in AutoCAD. - 13 million feet in the X; 300,000 feet in the Y axis.
I created a new DWG with everything moved (13 million, etc.) so I could track known points in relation to real-world civil data, and I noted the move distances on defpoints.
I know this will help me it long run, but I can't say exactly why from a Revit precision viewpoint.
My first test is, if you use the 'origin-to-origin' import command and Revit defaults to the 'center-to-center' option, there's a problem.


I guess, bottom line for my post: could Revit create a view boundary feature beyond which a user is alerted that the 'Twilight Zone' begins, so that users could know when they are entering a zone of potentially dangerous lack of precision?


John Tobin


PS: (One interesting fact for me is that way back when Revit was 'Revit 1.0', I remember sending an email to Revit Support saying 'great product, but can you make it so that we can know where the origin is located within Revit'. It;s interesting that we still can't do that without importing an ACAD file.)

[sonya]

if the dwg has an origin a long way away from the geometry it also appears "jagged" eg. circles aren't circular etc. which is most likely linked to this.

[thoellering]

In our office, architecture is taking the lead with Revit. Exporting Revit to Cad seems to work just fine, when the user remembers to set the X and the Y to the 0,0 alignment. But the Grid used to generate the ceiling tiles seems to re-locate and change when we export the model to cad, which requires us to move the ceiling tiles manually - a real hassle. Any thoughts on why this happens when we export using the shared coordinate selection and set the origins per the X and Y?

Thanks, this post has been very enlightening...

Thomas

[mibzim]

could Revit create a view boundary feature beyond which a user is alerted that the 'Twilight Zone' begins, so that users could know when they are entering a zone of potentially dangerous lack of precision?

WARNING!!! Error cannot be ignored. You are not playing by 'THE RULES' and cannot proceed. You have entered the 'TWILIGHT ZONE' and it is likely that your file will end up 'TOASTED'.

(OPTIONS)

Delete elements (entire model becomes highlighted)
Continue (followed by warning "Maybe you don't understand "THE RULES". Do you wish to continue (and eat toast for the entirety of your project) or consult the help files to understand THE RULES?)
HELP! (followed by message "THE RULES have not yet been defined, are not yet public knowledge, or have not been included in the help files. Please contact Autodesk Support for more information")
File Support Request (followed by message "Thank you for your enquiry. We are currently attending to many other support requests and are experiencing long delays. Your expected waiting time is (apply digital numeric recording here) 'six months'. Please hold the line.")

[mibzim]

But the Grid used to generate the ceiling tiles seems to re-locate and change when we export the model to cad, which requires us to move the ceiling tiles manually - a real hassle.

Thomas
This is a known issue, and beyond manually fixing it up in ACAD after the export i'm not sure if there is a real solution yet. Maybe Revit Architecture 2008?

[kenmarcus]

We ran into the issue with the ceiling grids moving as well but we discovered that it only happened if we exported all of our views using selected views/sheets. If we exported the ceiling plans individually using current view then the ceiling grids did not move.

[sbarnecut]

The fact that you can't move the Revit project origin is frustrating. I have a project where I have set the main floor to a project elevation of 0'-0", and a shared elevation that corresponds to it's elevation above mean sea level. Now, our structural engineers want to refer to the main floor elevation as 100'-0". Of course the shared elevation shouldn't change; it's in the same place in the world. I simply want to change the project origin down 100'. And everything I've read suggests that it can't be done.
Frustrating.

[sbrown]

The fact that you can't move the Revit project origin is frustrating. I have a project where I have set the main floor to a project elevation of 0'-0", and a shared elevation that corresponds to it's elevation above mean sea level. Now, our structural engineers want to refer to the main floor elevation as 100'-0". Of course the shared elevation shouldn't change; it's in the same place in the world. I simply want to change the project origin down 100'. And everything I've read suggests that it can't be done.
Frustrating.

You shouldn't have a problem actually moving your entire model up 100'. When I worked in colorado our template had the level 1 at 100'-0" and revit worked fine with that as its Project coordinate. Its onlyhard to move a model left or right, not up and down.

[Wes Macaulay]

And everything I've read suggests that it can't be done.
Frustrating.

It is simple -- select all your level datums and move them down 100'. Any 2D stuff in elevations and sections will also need to be moved down as a separate task.

[sbarnecut]

It should be easy to move the project up by moving all the level lines up. However, moving my model up results in 286 errors and 388 warnings. In my experience, moving models up by their level lines works well with new models only. I'm adding Move Revit Project Origin onto the wishlist...

[chodosh]

Possible solution: create multiple locations in your file for the various elevations required, create a new file, link your file into that and position at the various elevations in separate instances and then publish to each location. Once done, you can make each location current depending on what you need to show at that time? Not as elegant as being able to actually fix the Revit Origin, but allows you the flexibility if required to have both settings...
Just a Thought,
LC

[mruehr]

You don't have to Link for changing your shared level or location

go to Settings - Manage Places and Location
create an new location make it current
in Tools/Project Position use the Relocation Tool and move the Project Up or Down as you wish
make sure your Level Type is set to shared (best do it before)
now you can go back and forth between as many Elevation datums as you wish

It is a very often missed option and not very good explained
i think the naming of this tools is part of the problem
as for me i don't really see the need for moving the revit origin
as most of our life situation are relative

[sbarnecut]

You don't have to Link for changing your shared level or location

The issue isn't changing the shared location. That's fairly straighforward. I need to keep the shared location where it is (it represents elevation above mean sea level) and change the relative (project) location. Currently the only way to do that is to actually move your model relative to the origin, but when your model gets complicated, this can be tricky. And in any case, it involves independantly moving any drafted elements in sections and elevations—an arduous task when you have 12 building sections, many more wall sections, and and untold number of details.

[mruehr]

sorry guess i am a bit slow
don't you want to show a different value as your base level
call it project shared whatever why cant you use a 2nt shared location as your changed
Project Base Point

[chodosh]

You don't have to Link for changing your shared level or location
Very true, however, linking eliminates the relativity and allows the freedom to move your entire project as an instance of itself as a link. Thus, eliminating the push and pull effect that so many have been confused about when relocating a project and working with topography, etc. Yes, you can do this internally, but sometimes taking the thousand-foot-away approach is also successful. User discretion. I prefer to link since it is faster and I can check the accuracy before publishing. We also have too many files on our campus project to keep track of internally, but we may be in the minority. However, it has proved a best practice to manage shared coordinates from one file only, therefore everything is linked into that single file for resetting origins, etc. You can get snarled in a mathematical nightmare fast if you try to manage shared coordinates from more than one location, trust me.

i think the naming of this tools is part of the problem
Agreed, wholeheartedly.

Best,
LC

[mruehr]

Very true, however, linking eliminates the relativity and allows the freedom to move your entire project as an instance of itself as a link. Thus, eliminating the push and pull effect that so many have been confused about when relocating a project and working with topography, etc. Yes, you can do this internally, but sometimes taking the thousand-foot-away approach is also successful. User discretion. I prefer to link since it is faster and I can check the accuracy before publishing. We also have too many files on our campus project to keep track of internally, but we may be in the minority. However, it has proved a best practice to manage shared coordinates from one file only, therefore everything is linked into that single file for resetting origins, etc. You can get snarled in a mathematical nightmare fast if you try to manage shared coordinates from more than one location, trust me.

Agreed, wholeheartedly.

Best,
LC

Yes i totally agree for anything more complex linking it the way
internally changing the shared location is just a simple way of changing elevation base point
as long you don't have a 3D topography in the Project file
if you have just a cad file linked into the project i had no trouble relocating the shared project position
for topography i always use a linked project file

[sbarnecut]

...2nt shared location as your changed Project Base Point

I don't understand. I thought you could only have one shared location in a project file. Can you clarify?

[mruehr]

You can have as many shared locations as you want
think of it you have designed the best building ever and you sell the design
to 50 People to 50 different locatons (you don't want to draw it 50 times)
each location can have its own Level Location True North
you can set this in 2 ways

link your model into a site Project and move the Building around to the right location
then publish the shared coordinates to your building Project you can do this as often as you want and give each Location a name. you can find this different locations in Settings-Manage Places And Locations now you can select a location in your Building Project set it to current
and you will see the change in levels north etc.

you can do the same within the Project make a new location in Settings-Manage Places And Locations make the new location current use the relocation and change north tools
to change your Shared coordinates.so now you can change back and forth between your different Levels Coordinates pretty much like UCS in Auto cad

so instead of changing you project datums from Project to Shared
leave them in shared and make a different location current.

hope this made some sense English is not my first language

[sbarnecut]

Thanks! This is helpful and does make sense. However, I can't report more than one shared location at a time, which means it won't work as well as having the Project Origin in the right place. My level lines should report relative elevations whereas my spot elevations should be shared.

[mruehr]

Glad i wasn't totally of the track

Hmm just for my curiosity why would one have 2 different datum systems in a drawing set
does that not invite confusion ?

but i think you can still do it without moving the Revit Origin
Spot Elevations can be set to use Project, Shared or Relative Origin
when you set them to Relative you can chose a Relative Base from where to measure
so you can make a dummy Level /Elevation lets say -100 so your Spot Elevation reads
100 at your 0 Datum(or Shared Base Datum)
you can hide this level with a scope box.

i my mind less trouble then moving the origin
cheers

[mmodernc]

Is this a 32 bit versus 64 bit issue?

[sbarnecut]

Is this a 32 bit versus 64 bit issue?
I can't imagine how it would be.

[chodosh]

From the front lines of the 32/64 debate/debacle/experiment/reality, I can say I don't think so at all. Coordinates shouldn't be related to this, it's all in how you use Manage Place and Locations and the Relocate This Project commands.

One word to the wise, and I said it before, but here we go again with me echoing myself: one file should be the point of control for coordinates and if so, multiple locations are not a problem.

We currently have a scenario where we have a benchmark out in space and another location closer to Revit "home" (I say home because where [exactly, not conceptually, and not in an out-of-the-box template, for example] is 0,0 again... Bueller, ...Bueller...?...? [mathematically between multiple files]...?). We can switch between locations for specific purposes, specifically when coordinating coordinates with site/civil for some weird landscape/building connections like curvy nurby spliny things that creep inside-out and vice versa, but generally since accuracy is a concern the further away you are from "home" we keep it set to "home" as the Current Location.

mruehr described the processes very well. And sbarnecut, you are correct, you cannot be in more than two places at once in Revit (Project Internal and whatever else you choose to make current), sorry. Two is better than one, right?

Shared Coordinates in general still needs some improvement IMHO and I would love more information from anyone else trying these things. If anyone knows of a master class on this, shoot me an email, please? Thx.

All the best,
LC

[iandidesign]

Stupid noob question, why isn't the project origin displayed within the Revit interface? Seems like that alone would save considerable grief without any changes to the underlying code. Or am I missing some reason that this important coordinate needs to remain hidden.

[Wes Macaulay]

It's not a stupid question, really -- this should be displayed somewhere. We need a coordinate display I think, for both Shared and Project coordinates. We can get the Shared Coords of a point (Tools menu) but we need to do it for Project Coords too.

[chodosh]

We can get the Shared Coords of a point (Tools menu) but we need to do it for Project Coords too.
Yes, we do. It would be a big benefit.

I also find it weird that when you want to report coords of a second location in a single, isolated file that you have to report "Shared" coordinates. It's funky conceptually to explain this to staff since it is only sharing with... well... the internal database?

I want to report values based on the actual fact that in this file, right now my Current location at any given point is X, Y, or elevation Z.

So, maybe it should be simply "Coordinates" and then "Report Current Coordinates" and additionally "Report Project Coordinates." And, instead of the Elevation Base being Project or Shared, it should be "Project" or "Current?"

Or, just let us choose to report by the Named Location itself...? Whether that be Internal, New Project Location, My Location, Out In Space, etc.

Just thinking out loud,
LC