Design Plane Origin

A lay GIS understanding for msnt

in v8i the global origin doesnt really do anything to the projection, its only if you save it  back to prev8i that the GO will change things...

Prior to v8i we had a  limited design plane 2^64 in x, y and z direction master units ( v8i basically has no limit unless you mapping  galaxies) so for some of us say here in australia, victoria  we could not  fit the entire state plane in meters and have the full range of our state datum coordinates, so in order to fix this and not end up with negative coordinates we created a False northing and set the go in the middle of the state plane... only problem was with referencing everyone had to use the same settings for the altered  GO in all their dgns or maps wouldnt line up, later when we were able to do datum transformations through other GIS type software preBentley map we just told the package what we wanted and it  remapped and datum trans formed...or allowed surveyors to do the transformation shifting

Today the global origin really is 0,0,0 and references are related by true  coordinated to where the real 0,0,0 is so things land ontop of eachother at the true coordinates, added to this we set the datum or gcs, geo coordiante system, this allows xrefs of different CGS to reproject on the fly...

The projection map origin is set by the CGS , ellipse and interrnational GEO mapping org setting or code this is all done via clever mathemantics and comes up with a true mapping  origin which we never change , touch or modify... msnt  knows what to do if you just define it and the code is in the header so most  GIS software can read it and determine the projection and datum and make the relative adjustments to display  or reproject...

There is also the ACS or auxillary coordiante system this allows you to make something relative to a new origin or temp origin, ie move 0,0,0 to the corner of a building and rotate the world so left and right are 0, and 180 degrees, architechs love to draw this way but the tend to move the world to 0,0 rather than move 0,0 to an arbitary corner.... when I get drawings or maps done correctly with the acs changed I just reset it  back to 0,0 and maps now realign with real survey again....the acs does make  drawing layouts easier but will drive surveyor mad as nothing is in true coordinates only relative local  but done right can easily  be reset to true..

So in  a nut shell dont worry about global origins and map origins  just use the seed files from bentley  set your CGS  in youre seed file and save it with the CGSnameas part of the seed name do this only with the most popular one you use  but remember you may need to tell mstn what the cgs in a dgn is  if its not the one you always use and let it trans form .. this is very important  for xref of survey or map data from differnt datums and sources... some data is only available in WGS84  Long/ Lat and your using  Eastings and Northings so msnt  should notice this and transform or reproject the xref to align with the active drg cgs...

The only time the GO will be a problem is if  you a have to export the dgn from V8i hardly anybody  uses the V7 format

Then you will need to make a copy of you v8i file change the GO to the V7 settings then export the copy v8i for to V7 and it will keep the changed go so other drgns of the the same go will overlay coordinate survey correctly and give the right xy values to coordiantes...

While not 100% correct from a GIS mapping perspective all the points above will help with getting things  correct automatically as much as possible

Hope I havent  waffled on too much and was informative and instructional.

Lorys,

Thank you for your response, very intense, nice job!  I believe what you are saying is the current v8i design file contains a Global Origin at 0,0,0 and an additional origin assigned to a projected map by the datum.  The auxiliary origin does not interest me, just the relationship between the design file global origin and the projection map origin being used.  It sounds like there are potentially two origins (global origin and map origin) and if there is no projection assigned, then only the global origin exists in the design file?

At the edge of my knowledge on this but yes. I believe you are correct.

Ok, thanks again for that feedback.  So if you adjust the global origin, then that is how to influence the coordinates showing in design file, since Microstation is reading from 0,0,0.

You *can* adjust the Global Origin and it *will* influence the coordinate readouts.You must make a distinction however. IF you are doing GIS/Mapping type work with a GCS (like a State Plane projection), then you have no reason to mess with the Global Origin. You assign a GCS to the file model and off you go. Without a defined GCS, then you're resorting to try and imitate one using an Auxiliary Coordinate System and/or twiddling with the global origin (not really recommended).

Yes, good answer. So there is just the one origin, unless you use an auxiliary. The GCS simply changes the way the coordinates are interpreted. If you have a drawing with stuff in it and you assign a GCS, it will ask if you want the elements re-projected or if they are correct as drawn. GCS is a real nice feature for anything you're drawing in real world positions. It allows interaction with things like Google Earth.

Thanks Bob for your feedback.  My question is more academic in nature, trying to understand the relationships between the origin(s) involved with files associated with coordinate reference frames.  It makes sense that a projected map origin would be different than the global origin (do not coincide).  Although I would be interested to learn what you  mean when you say "GCS simply changes the way the coordinates are interpreted"?  It seems to me that MicroStation always reads coordinate values from 0,0,0, and any coordinate correct data is simply positioned, scaled, rotated, in relation to the global origin, but the coordinate correct data also has its own origin?

Thanks Bob for your feedback.  My question is more academic in nature, trying to understand the relationships between the origin(s) involved with files associated with coordinate reference frames.  It makes sense that a projected map origin would be different than the global origin (do not coincide).  Although I would be interested to learn what you  mean when you say "GCS simply changes the way the coordinates are interpreted"?  It seems to me that MicroStation always reads coordinate values from 0,0,0, and any coordinate correct data is simply positioned, scaled, rotated, in relation to the global origin, but the coordinate correct data also has its own origin?

All cords are read from the go 0,0 then the algorithms for the CGS datums redisplays / moves the data to the true coodinates for that  datum... in the old days the surveyor would survey all the points  relative to established markers then back in the office use complex calculations to transform all the points to the desired datum, now days the total stations and gps does all this for them... but in mstn we now can do the transformations just like we were using a GIS package which essentially does the same  ie read the existing datum and origin and either show as is or reproject/ transform to new datum... before we had this in mstn I needed to import  the survey dgn in our old state plane datum with MapInfo then transform it to new state plane and export the new map to DGN ... now its a one stop shop with mstn so its the GCS software inside msnt that  does all GIS transform stuff so you don't need to know anything about GO  and map origins , ellipse setting etc as its already set for you from pull downs in the GCS tools... I love it! As you can no doubt tell.. only time you need to worry is when there isn't a GCS datum available in the list... then its a lot of work to find a compatable one that works close enough  or you have to get Bentley  Map expert to build one to import so you can keep using it over and over... not easy to get this... so we just use  GIS like QGIS or mapinfo to do it instead.. but rare now days   for most countries

Thanks again Lorys for your feedback, bangup job!  I have learned more from Bentley's white papers and our discussions in the last two days than from the past two years discussing this subject with the Autodesk forums.  If there are Bentley white papers that discuss the technical concepts of what happens to a file when the coordinate system is "engaged".  I do not see any change in a file just by setting the coordinate reference frame.  I believe, importing or exporting data, once the coordinate system is set, is when the data is acted on?  I realize you are in a different time zone, at your convenience is fine.

Now I 'm not sure what your driving at?

As I said before the only problem is if you export to v7 dgn format and other users need to xref that v7 dgn in their v7 dgn then the go for both files may be different and  in a laymans explanation V7 uses the GO  as a common mounting point to align the two files ie the xref and the active file  so if you  the exact same data in both  and different  go's then they would not land on top of eachother.. this was the old days problem because their was no way to define in plain mstn what the CGS was ... so for to days cad and GIS its not an issue any more  just dont change  any GO's use as out of the box , define your CGS in msnt and msnt  will do the rest ... if you export  or import into GIS  applications they detect that you set a CGS and handle the data correctly...

Even if you export to DWG the data will be in its correct CGS because all the object coords are relative to go =0,0 ...

The only time I've had trouble with export to dwg is if the view as rotated ( and I didnt notice) and didnt set the option about view rotation in the dwg export options... then that can drive you nuts...

Lorys said:

... if you export  or import into GIS  applications they detect that you set a CGS and handle the data correctly...

I see this as a key concept. Generically referred to as geographic referencing, even PDFs use it. We (North America) have a major coordinate system update coming in 2022. The we'll see how it all works

So forget about global origin, there are not 2 coordinate origins, Microstation is still just a giant electronic etcha-sketch.

In the old V7 days, where Mstn stored its basic coordinates as 32bit integers, we thought of the Design Cube as big array of points which a point or vertex could occupy. You then assigned a number of points or UOR's to equal a unit of measure like Meters and away you go.

The coordinate readout is based on the origin defined by GO=. Everytime a coordinate readout is generated, the UOR coordinates will need to be translated by referring to the Go= position and converted into the unit of measure (meters etc).

For mapping, you can define the GO= position to be outside the Design Cube to crease a mosaic of Design Cubes, thereby getting over the 32bit limitation without having to store coordinates in double precision floating point formats. Something that the old processors were weak at. So, say you needed ten Design Cubes arranged side by side in a row to get from one end of the state to another. My understanding is that you would just reference attach the .dgn's, measure from one Design Cube/dgn to another and as long as the all the Ref attachments had the right GO= position, things would work. But, you can not draw a line from one Design Cube to another beyond the active dgn's.

With V8 and GCS... not sure but I bet the situation is still the same. It is just that the transforms to get the coordinate readouts can now accommodate the hacks used to flatten out geospatial curvature embodied in all those GCS'.

The big thing that we worry about these days is the SWA that is required for the solid modeling tools to work properly. For applications like ABD, the recommended SWA is only 4.29km. Since we have to provide BIM deliverables, which usually means usings 3d solids, the level of precision is more demanding to avoid flaky math results and screwball drawing extractions.

So, yea... understanding and messing with GO=, GCS or hacks like SnakeGrid is still required.