Working units and resolution
Anyone reading this article should realize that a survey foot does not equal an international foot. Laugh if you want but there are many users out there that have this difficulty. Just to clarify things, One International foot equals 0.999998 U.S. Survey feet. OR One U.S. Survey foot equals 1.000002 International feet. It might not seem like much, but over a distance of miles this adds up.
There are a couple of scenarios I would like to discus and a few misconceptions I would like to enlighten.
First I would like to get into some basics with the core at which you place elements in a design/model. Lets say we are in a design file and the working units are set up (‘) for the master unit label and (") for the sub unit label and 1000 per foot (international) for the resolution. If a line is drawn from a point of 0,0 an "x" distance of 1 master unit (which would be 1 foot-international), it would end at 1,0 for its coordinate value.
If you are confused already this is going to be a long article for you.
Now, lets get into another design file, and its working units are set to (m) for the master unit label and (mm) for the sub unit label and 1000 per meter for the resolution. If a line drawn from a point of 0,0 in an "x" distance of 1 master unit, it would end at 1,0 for its coordinate value.
So if we reference the first file (feet-international) to the metric file using MicroStation V8 (2004 or XM) and true scale is used the two lines are not the same distance, and they are not the same length. Yet if you look at the coordinate values, they are the same (0,0 and 1,0). These coordinate values in each file represent different units of measurement. Everyone seems to get this setup and function.
A similar setup would be to draw a block starting at 0,0 and making it one master unit high and one master unit wide - so the end result would have a corner on the following coordinates: 0,0 0,1 1,0 and 1,1. Now referencing one file to the other would have an end result of the blocks both starting at the same point (0,0) and having the same coordinate values on each of its corners, yet the blocks would not line up (one is larger than the other). Again - everyone seems to understand this when it comes to a metric file versus and international foot file.
Where the knowledge seems to break down is when we compare International Feet to Survey Feet. I don't know why, but I have had sooooo many users that are referencing an International Foot drawing to their Survey Foot drawing and wondering why they are not lining up. I ask for the files, and in looking at them, I find that they are indeed lining up and scaling properly. What the user is expecting is the International foot file coordinates to line up with their Survey foot coordinates. Sorry - this will not happen - again these are two different coordinate values represented by the working units defined in the design file the elements exist in. For us to line up the coordinates rather than the actual size or value they were drawn at would be showing you a FALSE reading or representation of the data that has been drawn. If you wanted the coordinate values to line up then both files should have been drawn in the same working units.
The next argument is that the user states that it use to work this way in V7. Actually we did not use to work in this manner. In actuality all we did when referencing was to line up the resolutions. So if you were to open your international foot drawing and attached both the survey foot file and the metric file, all three blocks would line up, there would be no scaling and technically the representation of the data at this point in time would be false/incorrect. Most people understood the metric situation and scaled the metric reference by 3.28 and the file then appeared correct (true representation of the data compared to the actual file). But no-one scaled the survey data, they would just leave it as it was and the coordinate values lined up (false representation) and the users were happy to leave it this way. The survey file SHOULD have been scaled by 1.000002 to truly represent the survey data being referenced.
With the V8 format taking care of the scaling issue (attaching "true scale") we have exposed a bad workflow on the users part. What had been a misrepresentation previously is now being correctly shown.
Another argument is to use just one foot measurement by default (survey foot). This might be nice in the Bridgework or RoadDesign world, but I don't know of to many buildings being designed in survey feet. So there will always be the situation where both units of measurement are being used. Even cases where both these units will be used on the same project (very similar to Metric and International Feet).
Unit definition file
This next area of discussion has to do with the UNITS.DEF file and its functionality in MicroStation V8. Again there are some misunderstandings as to what this file actually does.
There is a hardcoded list of unit definitions along with their names delivered with MicroStation, similar, but not the ones used/listed in the units.def file. When a custom unit is created and used, it is stored in the design file (units.def has nothing to do with this). If another user opens this file, the unit is still known and can be used (again - without the units.def file). In this case if the units.def file was not edited to include this new/custom unit the end user in the design file would see "custom" listed in the working units. The actual size/units will still be correct in the file, we just do not know what to call it or label it. Also if this file was to be referenced by another file it would scale properly (again - without the units.def file) no matter what the working units were of the active file. However - if the new/custom unit was added to the units.def file, the ONLY thing that would change with this scenario is the the end user would actually see the unit name listed in the working units dialog rather than "custom" being listed - that's it.
The only other time the UNITS.DEF file comes into play is when using a V7 file. Whether you are converting it to V8, or referencing it. The V7 format does not provide enough information for V8 to determine the correct mathematical definition of the unit used in the V7 file. So the units.def file is needed to calculate which label in the V7 file represents what unit of measurement.
More regarding this is in The difference between US Survey Foot and International Foot wiki article.
Also If I'm reprojecting the Survey Feet file into the International Feet File, will having true scale on do the conversion and scale the Survey Feet file down 1.000002?
I know this is an old article. But to get a bit more clarity. are you saying that with V8 using "true Scale" does the conversion factor for you? whereas I have a Feet and inches files and I'm referencing a Survey Feet file that the survey feet file will be scaled down to the 1.000002?
In the Md SHA's V8 Workspace is a series of mvba macros that are by default configured to open an alert dialog box if any file is opened where the units are not US Survey Feet or Metric. It then offers to run another mvba macro that will correct the units from international feet to survey feet without changing the coordinates of the file. The workspace can be freely downloaded and setup, or you might be able to pull out any mvba files from it to get the parts you need. However, the mvba files are password protected, so it might take some good detective work to determine which files contain which macro.
us feet diffrent international feet
Our organization is transitioning from V7 to V8i and has many V7 files defined in International feet though they should be US Survey feet. U.S. State Plane coordinate values are up in the 2,000,000's of US Survey feet, so confusing the units produces as much as 4 feet of shift. The solution for the site config was to define both feet the same in the units.def file, but then there is the risk of shifts if a file is opened outside of the site config.
The safest thing is to turn True Scale off in the default reference attachment config variable (MS_REF_DEFAULTSETTINGS = trueScale=0).
Here is a test to show why:
(ft = International foot, sf = US Survey foot):
New V8i settings (for active file):
Global Origin = 0,0 ft from design plane center
Resolution = 1000 per US Survey foot
Master Unit = US Survey foot (label = sf)
Sub Unit = custom (1000 unlabeled per 12 US Survey Inch)
I created 2 reference files with units of International feet instead of US Survey feet.
In each I drew a box from XY=2000000,400000 to XY=2001000,401000 (typical coordinate values).
V7 (J) Reference
Global Origin = 0,0 from lower left corner design cube (different than our new GO)
Resolution = 1000 per ft, 1 positional units per (blank sub unit)
Master Unit = ft
Sub Unit = blank
Resolution = 1000 per foot
Master Unit = Feet (label = ft)
Sub Unit = custom (1000 unlabeled per 12 Inch)
I opened the active V8i file (sf) in the site config, which uses a units.def that defines international feet as equal to US Survey feet. Then I referenced each file Coincident World (to account for the different Global Origin in the V7 file), once each with True Scale on and off.
Results (site config):
Ref TrueScale Result
V7 on OK (not shifted) – units definition file took care of units inconsistency
V7 off OK (not shifted)
V8i on Scaled 1/1.000002 (shifted SSW ~ 4 ft); Apparently units.def doesn’t apply to resolution?
V8i off OK (not shifted)
Then I opened the same active file outside of the site config. The default config uses the default units definition file, which doesn’t define International feet as equal to US Survey feet
Results (default config):
Ref TrueScale Result
V7 on Scaled 1/1.000002 (shifted SSW ~ 4 ft) – became a problem when custom units def file wasn’t used.
V7 off OK (not shifted)
V8i on Scaled 1/1.000002 (shifted SSW ~ 4 ft)
V8i off OK (not shifted)
The upshot for me is that there is never an unintended scaling, and resulting 4 foot shift, if True Scale is off. This is especially important considering many of our users aren't Microstation experts, and files (with references) may be opened accidentally outside of our site config. For the few times we need to scale a reference from meters or inches, we can set that manually in the reference manager rather than rely on True Scale, or even toggle itsTrue Scale button after referencing to see what scale factor would be applied. Users should always verify reference orientation parameters anyways.
Again, if you're in a similar situation, I recommend the following:
1. Teach everyone about International feet and U.S. Survey feet!
2. Turn off True Scale off in the default reference attachment config variable (MS_REF_DEFAULTSETTINGS = trueScale=0)
3. When referencing, select "Interative" mode and make sure True Scale button is off in reference options.
4. After referenced, verify orientation parameters (scale, rotation, offsets), and toggle the True Scale button on/off to see what scale it would have applied.