Has anyone changed the global origin in model files before?
We have decided to lift the building 300mm during our design phase (OMG) But we have 6 dgn files and each dgn has a model to represent each floor, with 5 floors that's 30 files I have to go and move everything we have drawn so far. (hence the OMG)
I thought it could be easier to just change the GO in each model instead - lowered 300mm (as I could do this by a batch-command script) then my Z co-ordinates will read the correct RL?
How does this effect my Floor manager? Anyone have experience with this?
regards
Damon
Good question... The obvious result is that the Z elevation coordinates for those 30 models should read 300mm greater than they are now. However, I've never personally looked at how that interacts with the FloorMaster file. I would try backing up that file, then also changing the GO in the working copy to match up.
Of course, if anyone has first-hand experience in doing this that would be best. :)
I forwarded this on to a colleague that was just looking at a similar situation a couple weeks ago to get his thoughts on it. That experience would make him the one that has "first-hand experience". I think he is on-site this week, but I am hoping he might have an opportunity to chime in.
-travis
Steve, when you say change the GO to accomodate real world coordinates, I am unclear as to what you mean.
I thought moving the GO did NOT move the Solids Working Area or the Design Plane. If this is the case, then moving the GO away from the center of the SWA could generate problems in solid modeling especially if beyond the edges of the SWA... Or I would have to enlarge the SWA but loose some accuracy in the process... confusing as usual with Bentley. I am having this problem right now on a real project and I am looking increasingly at moving the geometry to 0,0,0 rather than use the GO which seems to solve nothing. (my survey is currently 32km away from the 0,0,0 - I have a units setting meters/mm/10000 per mm resolution so the SWA is 420m approx.)
For me, "moving the GO" simply means assigning specific coordinates to a designated location. So instead of the SWA center being 0,0,0 it could be something like 20000, 20000, 0. You would still be modeling within the SWA, but would also see real world coordinates based on the project's location.
Geo-referencing/coordination takes this a step further by aligning coordinates across multiple files/disciplines. It's certainly not something I work often with myself, but it seems to be the preferred workflow AFAIK. Further information can be found here:
http://communities.bentley.com/products/microstation/w/microstation_v8i__wiki/geographic-coordinate-systems-fundamentals.aspx
http://communities.bentley.com/products/microstation/w/microstation_v8i__wiki/geo_2d00_coordination-with-microstation.aspx
http://communities.bentley.com/products/microstation/w/microstation_v8i__wiki/georeferencing.aspx
This section covers the interaction between Geographic Coordinate Units and Model Storage Units so also may be of interest:
http://communities.bentley.com/products/microstation/w/microstation_v8i__wiki/5898.aspx
OK thanks Steve, also i am told there is a mdl "swa.ma" that highlights the SWA, but I haven't got this in either AECOsim or Microstation files... Any chance to get it for download? Cheers.
Please ignore, I found the mdl since posting thanks.
Yes, I totally forgot about that. It is a good visual indicator.
While we're busy making for of the situation, the reality is that, for some of us, the situation of the SWA DOES create real hassles. Many of our projects are over multiple locations or cover items that are 40-50km long and mean we are forced to manage multiple seed files depending on the location and run the gaunlet of probelms to be able to model itmes such as overland conveyors etc. AECOsim is NOT just used by building groups, though that seems to have been mostly forgotten.
Totally agree with you Bear, there is also an item that is not clear to me is what is the real impact of model being outside the SWA - I understand some elements have their own SWA which means they should not be affected... DO you happen to have any detail info on this?
Biggest issue has been in creating extractions, especially with any solids or forms modelled. Basically, we can't afford to be outside of the SWA. What does concern me though is being criticised by support for using seed files with too large a SWA. Most of my projects would fit inside of what they recommend as the 'ideal' SWA size.
I take it you mean "would NOT fit" right?
Yes.
So too large a SWA means you're loosing in Solids accuracy right?