Forum,[MS v8i Products]Ive read many posts on Global Origin and Solids Working Area, and am none the wiser. Do 3D Graphics still need to be Near Global Origin of a file so that they fall within Solids Working Areas [SWA]? or is this not the case now, on v8i products anyhowSom posts say yes,some say no. Others talk about GOs and moving them. Surely there is knowledge on this?If i have a Project in the London area then the Origin of the survey grid, 0, is a long way away. KIf my Seed has been set with a true 0, does this matter or should the seed file be set up to have a Global Origin in the centre of the Project?Additionally, I have played with moving the GO as a test but when i use GO=, Monument Point, Click a defined point, my GO changes for that session, but as soon as i exit an MS Session and reload that file, the GO is back to where it was. So i cant even test moving the GO!!
We always setup the project at the origin but redefine the origin using go= to be the real world OS coordinate. Programs like Revit, Rhino & Sketchup still need geometry to be near the origin.
i work on large infrastructure Porjects where the Seed is already set up, so i assume this is also theprocess for these, as were required to b aligned to Real World coordinates. Do does this compiund the 'distance from SWA' issue or is it not an issue?
Unknown said:I assume ... the Seed is already set up
Don't assume! Do you have absolute confidence that your colleagues who set up your seed files were fully aware of SWA in V8i and CONNECT?
Regards, Jon Summers LA Solutions
Absolute Confidence? Of course not @Jon :)
but id like to really try and understand this and SWA, as we have different issues on Rail projects are long linear Projects and could possibly be compounding problems such as this, I wonder how many could be linked ot this issue, and further issues of people not fully understanding Microstation in v8i and Connect.If i can understand it then i can at least help and guide.For Exaple we have complex Federated Models which range from 2km to 10km. We have terrain files between 2 and 10km also. We have complex existing infrastructure modelled which can be a km or more. These are all on Real World Coordinates.I am reading what i can on fourms, and with the knowledge of peole like yourselvs, but there is little guidance on settign up Project such as long linear ones as Rail Projects generally are
Unknown said:there is little guidance on settign up Project such as long linear ones as Rail Projects
FWIW the UK rail community sponsored development of SnakeGrid. It's not restricted to the UK — I see that the Irish are using it. You could become a hero in the New Zealand design community by championing SnakeGrid for your region!
Unknown said:you know im UK based?
Oops! I had you confused with another Hawes!
Yes we use SnakeGrid a lot, and that also has its challenges, especiaally the conversion it, to it and from it, but thats a whole other Forum in its own right.you know im UK based?
Unknown said:i work on large infrastructure Porjects where the Seed is already set up
Unfortunately, there are still a lot of large client CAD departments who do not set up their seed files correctly. We have been told by one client that if SWA is a problem with their seed file it is up to us to fix it.
I think that some of the confusion stems from the fact that the seed files tend to be based on Mstn work and not Aecosim / Dynamic View restrictions which require higher precision. The recommendation is to use georeferencing. See Marc Thomas' blog which has recently updated info on SWA.
Moving the GO does not help. Ideally the geometry needs to sit near the Design File Center.
I have also seen some Brien Bastings posts on some Mstn solids being designed to have their own localised SWA awhile back. This does not appear to apply to all solids or Aecosim / Triforma Solids or DVs or Building View unification engine restrictions.
Snakegrid is a separate thing, which I think you realise already. I don't really think is relevant for most users or applications. All building models will need to be in 'cartesian' space so that when you exchange/import survey info from those lasers etc it all coordinates... as a default. All that warping to generate a unified linewide coordinate system is only useful for the railway systems guys. Apparently, you can't even warp all of Mstn's 3d elements anyway so it's a bit of a distraction.