Changing Global Origin in models effects??

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

Hello all

Damon, ..... I sympathise, ........ for me this relates to previous discussions about ACSs and the Floor Manager. The GO ....... should be irrelevant (as in reality it is, ...... for designing buildings)

When elements (floor slabs) are created they should be associated with a given FFL or SSL (structural slab level). This would be part of the 'Project Settings' (in your Floor Manager/Coordinate System Utility), so if you wanted to change all those slabs by 300 mm, you would make that change in the 'Floor Manager' and everything using those 'Floors' would move up/down accordingly.

Whilst I'm here, ....... surely by now we should have phased out this whole GO thing ( the centre of a 'file' ??????)

We are not dealing with a 'file', ....... it's a plot of land/building site.

The GO should be totally invisible to the users (and even CAD Managers), ..... we simply do not need this.

For the life of me why, if you are working on a project in the UK, when you open a 'file', at the start of a project, you should be looking at a OS (Ordnance Survey) Map (with a grid) of the UK. The you select the actual coordinates (OS Coordinates) where you're site is located, you would then automatically zoom to that location. The GO (for any file in that project) should then be relocated to the location of that site. What's happening on the other side of the 'design file world',  ( ...... infinite plane ???????? why do we need a design plane bigger than planet Earth?) is of no relevance.

When you go to get 'Info' about an object, you do not want, or need to know anything about where it's vertices' are relevant to the GO. Everything is relevant to the building plot in question, and then the main structural grid, then various 'building elements' (slabs, roof, front doors, stairs, .....)

I'm assuming you're all familiar with Google Earth ........ There is no Global Origin on Planet Earth! (it's a sphere). You just type in the Post Code/Zip Code, or the name of the city, river, town, ..... and then you 'zoom' to that location. If that's the location of your building plot, then you should just be able to fix that there (effectively anchoring the 'file' GO for that project at that location)

C'mon folks, ...... can we move on from this GO of the file thing, ....... it's a left over from the early days of CAD and the digital drawing board/graph paper approach

That's my 2p for today

Damon, for the record, I would agree with one or 2 of the other posts, ..... bit of a drag, but just moving the models manually would be a far safer/better option that moving the GO (what happens when other people later on create new files ...... and use the wrong seed file?)

All the best

I ended up not doing anything at all about it and just accepted that my model is 300mm out.

I just didnt have time to play around with it.

The RL's arn't generated automatically so It doesnt matter to the project at all as it's all manually entered. generally I always setup my models about 0,0 as It is frustrating when you have objects outside of the Solids working area.

Next time I will just move everything in my model.

I love the idea you have about the mstn drawing plane being the size of earth. It just makes so much sense to have this approach within the building industry.

As for mechanical plant people. They only deal with something less than 1km anyhow so why do we need an infinate plane?

It seems crazy to me to have the MicoStation drawing plane being the size of the Earth.  That seems to limit us from development.  Shouldn't we also make sure to include the moon and Mars at a minimum?

And just to add...    This - "They only deal with something less than 1km anyhow so why do we need an infinate plane?" - might take on an entirely different meaning for civil/geo folks who are running on the same platform.

I can certainly see an intuitive nature to some of the concepts described here.  However, comparing a vector based 3D modeling/CAD application to Google Earth seems a little off to me.  

Travis wants to do developments on the moon and mars now?? That is ambitious.. LOL.

I'm sure its a case of making the design plane relative to the planet we are working on I would hope.

Travis wants to do developments on the moon and mars now?? That is ambitious.. LOL.

I'm sure its a case of making the design plane relative to the planet we are working on I would hope.

Global origin is limiting.  From now on, G.O. shall stand for Galactic Origin.  :)  We will need to make sure that the structural analysis applications get certified for work on Mars and the Moon as well.  So much potential exists in these untapped markets.

Yes, zero-gravity trusses and joists are a must-have.  The only thing better are those hermetically sealed doors and windows, but you have to be very careful when placing them or the results will be, well, "interesting".   :)

Hello

Apologies for the delayed response, I've been out of our solar system for a few days, only just for back. It's a bit of a hush, hush job, ..... can't really discuss the details here in this forum (I'm sure you understand!).

Anyway, back to more earthly matters

'I can certainly see an intuitive nature to some of the concepts described here.  However, comparing a vector based 3D modelling/CAD application to Google Earth seems a little off to me. '

Sorry if you though that was a little 'off'. I wasn't comparing to 2 different software apps per say. I didn't think that was being implied. The point was that locating yourself, and your site/project should be as straight forward as it is in Google Earth. Bentley Systems would seem to already have most/all of the necessary information. If you look in the 'Geographic' toolbar, it's all there. Plus integration/links to Google Earth and GPS capabilities.

It seems unclear to me how you go about 'geo-locating' your project files/models. It seems you can select a geographic coordination system for the file/model, and also apply it to the ref files. Short of ensuring that the project level seed files (there may be several) are geo-coordinated, how go you locate your whole project/site?

There are certainly other' advanced CAD' packages, that have a very straight forward dialog box, where you locate your building. Mainly the energy analysis projects ...... some of which are part of the Bentley portfolio!

You simply fill in the dialog box, this then relates your site to a weather data file and various climate metrics. ..... BIM

Why are the 'building' applications not making use of these capabilities.

Here in the UK, most projects use the OS (Ordnance Survey) Co-ordinate System. When I create some objects in 3D, where then is Z = 0 (Microstation Global Co-ordinates System) relative to the OS System? Is Z = 0 then equal to 'Ordnance Data Level' = 0 (which is sea level in the UK system)

Perhaps a bit of an arcane approach, but here in the UK, everything is related back to sea level (in the OS System), ..... Fortunately here in London, pretty much all of it is only several tens of metres above see level (not hundreds), so most of the time you are dealing with figures around 100 m AOD (Above Ordnance Data)

I've tried on a couple of occasions, developing my models at their real height locations (in the OS System). This is usually not very practical, and will throw a lot of other people out.

More often, I'll pick a level that's a round number just below the lowest point of the site (say it's 84.500, then I would use 80.000) and use the Microstation Z = 0 as that.

The big danger with changing the GO, is if you have a large team, say 20 people, and they are importing/exporting things all the time, ....... there will soon be problems (used the wrong seed file, importing a file from another system, ....)

Relating to the original question about re-locating the GO, ...... ..... one would have hoped that by now we would not have to be concerning ourselves with any GO. Just with locating your site, .... once you have done that, the GO should have then already have been moved to an appropriate location, so that the solids accuracy remains intact, and if you import a 3D elevation file from one of the 3D mapping companies, then your building should already be at more or less the correct height/elevation, ......

Over and out ..... (excuse me for a moment, ..... need to just go and check my hyperdrive unit, ..... seems to be smelling of smoke, ...... not a good sign)

I guess when comparing Google Earth with vector based 3D modeling applications such as MicroStation, I was looking more at the accuracy/precision aspect.  I don't know if Google Earth has a similar concept, but since it's not a design application per se the ability to select a random point holds an entirely different meaning than in MicroStation (and the Parasolid modeling engine), where its floating point math dictates that closer to the design cube center gives better solids modeling accuracy.  From that aspect the modeling coordinates can make a big difference, hence the ability (and need) to change the GO to accomodate real world coordinates.

However... when I commented about some of the concepts outlined in this thread, I was thinking more of the front end for this process.  I certainly can't see a simpler/more streamlined method of assigning coordinates as a bad thing!  But I'm not a developer so I have no idea what this really means from a coding perspective.  Not to mention taking into account the many different workflows our users have, across many disciplines.  

Anyhow...  Good luck with the hyperdrive unit.  Smelling smoke is never a good sign.  You may want to consider one of those liquid nitrogen cold packs.  They work pretty well on ailing hyperdrive units and they're not bad for aching muscles either.  Thitry minutes and you'll forget all about those aches...   ;-)

maybe check out this video:

relevant to our discussion and to everyone's need