I am reading a Bentley white paper titled "US Coordinate Systems in MicroStation v8i & Bentley Map v8i." At the top of page 5, it states "A Microstation design plane itself is a Cartesian coordinate system with the XY origin at the center of the design plane, except when the global origin has been shifted." I assume that the origin of the design plane corresponds to the projected origin of the map. However, I question if there could be an additional origin introduced to the design file; a global origin, and a map 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.
MicroStation user since 1990 Melbourne Australia.click link to PM me
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?
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.
Connect r14 10.14.00.109 self-employed
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.