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.
wow - sorry for the delay on this post.
Lets see - you imported your US Survey Feet data into an International foot design ?
Wellll - when you imported the data - how was it done ? Did you attach it as a reference ? and was the reference attached "true scale" ?
What if my seed file was set to International feet but all survey data imported was US Survey Feet? What would it take to get them right?
Hey Bryan,
Nice ta hear from ya.
So what you are saying is that your V7 file were all converted to international feet.
And you now have data that is in survey feet to be referenced to these files.
Questions:
Do you have survey feet defined in your units.def file ?
What expectation are you looking for when referencing the files ?
DWG decimal units is of no help - what specifically are the DWG file drawn in ? (IE:METERS)
Nice article Tim
How would you resolve a civil project converted from v7 to v8.0 with the default International ft in the v8.0 units.def?
Then referencing files setup as U.S. Survey Ft?
Throwing into the mix that Architect DWGs in decimal units will also be used.
Thanks for bringing-up this topic for consideration and offering some explanation. I think it is worth emphasizing that files with unit definitions different than the data added to them can wreak absolute havoc to users "down the line", often without the original creator of the file being aware of any problem because the coordinate values for data in that file appear correct, as you've explained.
While attachment options can be manipulated to cause this file to appear correct when referenced into a properly set-up file, I would say that would be akin to two wrongs appearing to make a right. Just like the addage that two moral wrongs do not make right, the reference file is in fact "wrong", as are the attachment settings used. This situation is much worse than just a "bad workflow" in my opinion.
As you point out, while these sorts of problems are often noticed when the incorrect unit type is significantly different, when the difference is smaller, like that between US survey feet and international feet, there is a greater chance of it not being noticed before real problems are created.
Thanks again for bringing this topic up so that more users are aware of the importance of units definitions of files with respect to data integrity.
~Matt Thompson