Archive for March, 2006

Donate your corrupted design files to science.

Tuesday, 7 March 2006

How Axiom researches emerging types of V8 file corruption

CLEARWATER, FLORIDA, USA — Regardless of the cause of design file damage a power fluctuation, a network glitch, an unreliable hard drive, an amateur software developer, an act of God or an act of Bill Gates customer reports to Axiom Technical Support confirm week after week that design file corruption does impact MicroStation projects, and no version of MicroStation is immune.

Some forms of design file corruption are immediately obvious and fatal (such the “Unable to open design file” dialog). Some categories of design file corruption are annoying time wasters (such as unselectable elements). There is also a class of design file corruption that lurks unnoticed in your project design files, not impacting production until the most inconvenient time for you, possibly long after the damage was done.

To solve these problems for the MicroStation community, Axiom continuously watches for long-term trends of design file misbehavior to identify new features that should be added to FileFixer. Axiom is particularly meticulous in its analysis of any file which is so badly mangled it cannot be opened by MicroStation the files which stop projects dead in their tracks. When MicroStation cannot open a file, that design asset is lost. Axiom takes this very seriously.

To assist the broadest possible number of MicroStation users, FileFixer enhancements provide solutions for recurring, long-term file corruption trends which have been identified by Axiom’s analysis of customer files over a long period of time – the most common problems CAD shops, like yours, have encountered or inevitably will.

V8-specific corruption
One of the most common problems that are found in customer V8 design files is a corrupted level table. When a V8 design file’s level table is damaged or missing, graphical elements become “stranded” on levels that aren’t defined. This problem is new to V8 and does not occur in V7 design files. FileFixer for V8 offers a quick remedy for damaged or missing level tables.

Other V8-specific problems discovered in many customer files involve elements that have at least one coordinate beyond the edge of the design plane. This type of error makes these elements hard to select, move or delete and cause MicroStation users a great deal of annoyance (and wasted time). FileFixer repairs these elements so that they can be manipulated as needed.

Running out of design file corruption to fix?
What about FileFixer’s future? The fizzing test tubes and bubbling beakers in Axiom’s design file laboratory are currently filled with specimens of “structured storage” corruption. Structured storage is the file structure used by Microsoft Word and Microsoft Excel. Bentley also selected this file structure for MicroStation V8 design files.

A structured storage file contains multiple sub-folders and sub-files. Analysis of multiple customer V8 design files has identified repeated instances where the internal pointers to sub-folders or sub-files are damaged causing the standard structured storage file reading and writing operations to fail. When such damage occurs, MicroStation cannot open the V8 file. Sound familiar? You may have been told nothing can be done to recover from this.

Fortunately for you, Axiom didn’t give up. Analysis of customer files revealed that in many cases of structured storage damage, the original design data is still intact, but is trapped within the mangled wreckage. If you need to free your V8 data from the surrounding structured storage wreckage, or if you’ve run into any project-stopping or annoying design file anomaly — V7 or V8 — contact Axiom. Your troublesome file could contribute to a new search or repair option that benefits the entire MicroStation community.

MicroStation Tip Corner — Survey Foot versus International Foot: What's the difference?

Tuesday, 7 March 2006

In a recent thread on the Bentley newsgroups, we came across some confusion about the differences between an International Foot and a U.S. Survey Foot. We thought it would be fun to shed some light on what these “feet” are and how much measurements would deviate due to the difference in unit length.

History
According to the National Institute of Standards and Technology’s Web site (an agency of the U.S. Commerce Department’s Technology Administration):

“The U.S. Metric Law of 1866 gave the relationship one meter = 39.37 inches. From 1893 until 1959, the yard was defined as being exactly equal to 3600/3937 meters, and thus the foot was defined as being exactly equal to 1200/3937 meters. [Editor's Note: This definition of a 'yard' and a 'foot' was set down in the 1893 document entitled 'Fundamental Standards of Length and Mass'.] On 25 June 1959, the definition of the yard was changed to bring the U.S. yard and the yard used in other countries into agreement (National Bureau of Standards made it official in a document called ‘Refinement of Values for the Yard and the Pound’). Since then, the yard has been defined as exactly equal to 0.9144 meters and thus the foot has been defined as exactly equal to 0.3048 meters. At the same time it was decided that any data expressed in feet derived from geodetic surveys within the United States would continue to bear the relationship as defined in 1893, namely, one foot = 1200/ 3937 meters. The name of this foot is ‘U.S. Survey Foot,’ while the name of the new foot defined in 1959 is ‘International Foot.’ One International Foot [equals] 0.999998 U.S. Survey Feet exactly.”

Per the U.S. National Oceanic and Atmospheric Administration’s National Geodetic Survey (defines and manages the U.S. national coordinate system), the following are the accepted calculations for each of the feet: The U.S. Survey Foot is defined as 0.30480060960125017024227597156924… meters. This calculation comes from the definition of a “foot” as established in 1893 (1200/3937 meters).

The International Foot is defined as exactly 0.3048 meters. This calculation is verified by the following definitions: one inch = 2.54 centimeters and 12 inches = one foot. Therefore one foot is made up of 30.48 centimeters. Divide that by 100 and you get 0.3048 meters.

National Geodetic Survey also states, “these two conversion factors produce results that differ by 2 parts per million; hence for most practical work it does not make any difference to the average surveyor which one is used since [surveyors rarely] encounter distances [large enough for this to be a factor]. Converting a distance of 304,800 meters to feet using the two conversion factors, these are the results: 304,800 meters = 999,998 U.S. Survey Feet and 304,800 meters = 1,000,000 International Feet. A difference of 2 feet in one million feet.” [Editor's Note: A million feet is approximately 189 miles.]


Added 22 March 2006 – Response from David P. Mild, PE, STVInc
As to the comments about the average surveyor not encountering distanceslarge enough to be a factor, please use appropriate caution when using State plane coordinate systems! USGS monument coordinates given in meters need to be converted to the “old survey foot” with the proper conversion factor (12″/39.37″), and on a computer calculator to as many decimal places as possible. Also, take great care in mixing the MicroStation conversion (by referencing by coincident world a metric drawing, for example) because it uses the international factor. The only reliable way to reference a metric drawing is to make sure it also lines-ups/snaps-to a similar point or alignment converted and displayed (in both the foot drawing and the metric drawing) by InRoads, because InRoads geometry transformation (feet-meters or meters-feet) employs the “old survey foot” factor.
Bentley does have a work-around for changing the settings in a MicroStation drawing, but it has to have been created by the surveyors or mapping company that way in the first place. Also, especially with the new 1983 datum, it is now even more important to “check in” at monuments after several miles, because the difference between the State plane coordinates and distances measured along the surface is more. The State plane coordinates now occur at elevations below 0 (zero) for most of the US. Many agencies employ “project grid factors” that more closely relate surface measurements to the coordinate system, but that’s a whole other discussion.

We have seen entire photogrammetric areas done wrong after everybody went back to feet from meters. USGS monument info was being given out only in meters for a while. It started with just the one error, using the wrong conversion for the starting coordinate. From there they coordinated the photo target points, and then generated miles of mapping. Rather than running to the State, we met with them (the consulting company), and showed them what we suspected happened. They agreed, fessed-up to the State themselves, and had to redo it on their own dime.

Added 28 March 2006 – Response from Joe Feyder, PLS, CH2MHILL, Sacramento Office
Please refer to a passage, in the referenced MicroStation Tip Corner, that says, “…for most practical work it does not make any difference to the average surveyor which one is used since [surveyors rarely] encounter distances [large enough for this to be a factor]. Converting a distance of 304,800 meters to feet using the two conversion factors, these are the results: 304,800 meters = 999,998 U.S. Survey Feet and 304,800 meters = 1,000,000 International
Feet. A difference of 2 feet in one million feet.” [Editor's Note: A million feet is approximately 189 miles.]”

While in one respect you are correct, surveyors using EDM’s can not measure a distance to a precision of 2ppm (or 0.002′ in 1000.00′), but that is not the issue. The REAL issue is when this 2ppm is applied to State Plane coordinates in the N2,000,000 and E6,000,000 range! This 2ppm literally moves a State Plane coordinate position 4 feet by 12 feet, using the coordinate values listed.

With more and more projects being based on State Plane coordinates, this issue is going to be more and more prevalent. Working on projects in many States, we are well aware of the problems presented when users mix Survey Foot and International Foot units. In nearly all cases it is simply user awareness, or a project that has not been setup correctly.

Imagine you complete a design in rural California, using State Plane coordinates based on International Foot units, which is subsequently passed on to a surveyor for staking. Surveyors are aware that California uses Survey Foot units.

Many survey software packages convert Foot units on the fly. Then imagine (or have a nightmare!) that your design is being constructed 4′ x 12′ out of position! You would quickly come to the realization that 2ppm matters!

In our practice, this is a HUGE issue, and I would find it hard to believe it has not affected others similarly. This topic is hot enough that, in my opinion, it deserves clarification in your printed material.

Thanks for taking the time to read and consider this response.

Professional Engineer at AZTEC uses Toolkit to keep costs down and production levels up.

Tuesday, 7 March 2006

PHOENIX, ARIZONA, USA — Recently, MicroStation Today had the opportunity to speak with Mark Chase from AZTEC in Phoenix, Arizona about how he and his group of talented engineers streamline their projects with MicroStation Productivity Toolkit. Here’s what Mark had to say about his career, some of the projects he has worked on and how he uses Axiom utilities to obtain maximum results for AZTEC and their clients.

Mark Chase, Professional Engineer for AZTEC Engineerin

MicroStation Today: Tell us a bit about yourself.
Mark: I am a registered Professional Civil Engineer in Arizona and California and I have been working in the transportation structures discipline for over eight years. Throughout my career, I have used CAD to produce a number of bridge designs ranging from small, single span canal crossings to large, multi-span freeway interchange overpasses.

MST: Tell us about your success with Axiom utilities.
Mark: AZTEC uses Axiom’s MicroStation Productivity Toolkit. The two products that get the most consistent use are FileFixer and Microsoft Office Importer. One of these two products is used nearly every week to some degree.

Our team has instituted a protocol that routinely executes FileFixer to maintain our working design files in top shape. FileFixer provides our team with the confidence that our working design files do not contain design file corruptions that will inhibit achieving our group’s focus efficient productivity. In the time-crunched project world, most schedules do not provide extra time to manually fix file corruptions, or worse yet, redraw corrupted files.

Our team has found two distinct uses for the Microsoft Office Importer: 1) fast presentation of screed and falsework plan sheets [Editors note: A "screed machine" is used to level and smooth the concrete surface of a bridge deck. "Falsework" is the temporary structure that is built to hold the wet bridge concrete in the air until it hardens and can stand by itself. The plan sheets contain the design calculations for these.] and 2) assurance of consistent table information between plan sheets and the quantity calculations that are prepared in a spreadsheet.

For people unfamiliar with bridge plans, many agencies or contractors require the inclusion of screed and falsework elevation tables in the contract documents. [Editor's Note: An "elevation table" is a spreadsheet that contains, among other things, the slope and height measurements of something ¾ in this case, of a bridge deck]. This information typically occupies multiple plan sheets and is contained in large tables full of numbers. Microsoft Office Importer allows the information, which is typically calculated in a spreadsheet, to be efficiently and accurately presented on the plan sheets without the need for hours of text editing or formatting. Similarly, bridge plans often contain a quantity summary table that restates the information that is contained in the bid schedule for the bridge. Preparing the information in a spreadsheet, and then using Microsoft Office Importer assures us that the information shown on the plan sheets matches the information presented in the other contract documents.

MST: What impact have Axiom tools had on your company?
Mark: FileFixer and Microsoft Office Importer have both benefited our company. These simple-to-operate tools provide tangible benefits in the form of saved time, money and resources. The benefit of using FileFixer is difficult to pinpoint because the fatal corruptions that lurk in the dark corners, waiting to pounce on us at the worst times, are handled before they attack. However, the time saved running FileFixer rather than manually operating EdG is significant. The benefit of using Microsoft Office Importer grows exponentially with the amount of data that is imported. The largest screed/falsework elevation tables that we import with Microsoft Office Importer contain nearly a thousand numbers per plan sheet and the plan set will often contain several of these sheets. The intangible savings of these benefits are re-invested by allowing our cutting-edge staff the opportunity to focus on what we do best designing innovative and complex projects while taking the time to find ways to add value for our clients and our company rather than fixing corrupt files or manually editing pages of tabular information.

MST: What do you do with your time outside of work?
Mark: My hobbies revolve around spending time outdoors in a wide range of activities. Though not as much as I’d like, I annually spend much of my free time either hunting, fishing or hiking. When free time is less prevalent, I enjoy spending time entertaining my four-year-old chocolate Labrador Retriever with a game of fetch.

MST: Thanks, Mark.

Managing cell libraries quickly and effortlessly

Tuesday, 7 March 2006

What do you do if your cell libraries do not comply with your client’s CAD submission standards? What do you do when your cell libraries become so bloated that it’s hard to find the cells you need? Instead of investing your time and resources in recreating or modifying cell libraries manually, why not save yourself hours of wasted production time by using CellManager to easily manage cell attributes in bulk?

In this article, I will illustrate how to use CellManager to review existing cell libraries, to export needed cells to a new cell library based on cell attributes and to modify cell attributes in bulk, without much effort.

Reviewing bloated cell libraries

One of two things may be the case: 1) by the end of a project, you have probably created lots of cells (and so have the other designers on your team), or 2) you have amassed a voluminous collection of cells over a couple of years. More than likely, in both cases, these cells are scattered throughout different cell libraries.

The problem begins when you realize that the levels and symbology of your cell libraries need to be changed to adhere to a client’s CAD standards.

The first order of business is to use CellManager to create cell library documentation to “see what you’ve got”. CellManager’s Draw Pages command can create notebook-like documentation of as many cell libraries and cells as you want, in the time it takes to get a cup of coffee.

By using the templates included with CellManager, you can generate professional-looking cell documentation in just minutes. CellManager’s documentation includes cell graphics, text descriptions, cell origin marker and any other cell attributes. CellManager also generates an alphabetized table of contents of the cells in the library.

Below are the steps for generating CellManager’s cell library documentation:

CellManager for V8′s Draw Pages command is simple to use: 1) Click on <Draw Pages>, 2) select the layout template you wish to use (Axiom provides these, or you can create your own) and 3) click on the <Draw Pages> button in the Draw Pages dialog box.

The Draw Pages output is stored in your cell library as a sheet model.

Exporting cells you need
Now that you have reviewed the cells available, it is time to export the cells you need into a project library. With the cell library selected, click on CellManager’s <Manage> button. From here, you can review and tag the cells you want to export.

In the Manage dialog box, you can tag cells for processing by clicking on <Tag>. To open the View window (to preview a cell without opening it), click on the <View> button.

Cells can be filtered by level, description (using wildcards), element types or any combination of these. If efficiency is what you crave, then there is an even faster way to select cells for processing. For example, if you wanted to select all the cells whose name starts with “ex”, all you would do is click on the <Select Cells> button on CellManager’s main dialog box and enter “ex*” in the Cell Name field of the Select Wildcards & Ranges section of the Select Cells dialog box.

The “ex*” tells CellManager to select all cells whose name starts with “ex”. The “*” is a wildcard character. Notice that at the top of the dialog box you can see how many cells were selected. When you return to the Manage dialog box, only the 31 cells selected with this filter will display.

Once you choose your cells, it is time to export them to a new library. You do this by clicking on the <Export> button in the Manage dialog box.

The Export command allows you to copy or move tagged cells to a new cell library or append them to an existing library.

Modifying cells in bulk
Now that you have reviewed and exported your cells, you are ready to modify the cells. Without CellManager, this process can be a tedious and monumental task. However, CellManager’s Modify command (similar to the “search and replace” function in a word processor) makes this very easy to do.

With the Modify command, you can change cell levels and symbology (color, line style and line weight) in your cells, in bulk. For this example, we are moving all the cells (which were scattered throughout different levels) to another level called “Doors”.

Using the Modify command to move all selected cells to one level.

When you are done selecting the criteria for your modification, click on <Process>. But don’t go anywhere, because it will be done in minutes, not the hours it would take to do it manually.

ByLevel symbology
If you are using ByLevel symbology in V8, modification tasks are even simpler. ByLevel symbology can be defined for each level in the V8 design file’s assigned level library (which can be modified using MicroStation’s Level Manager). When using ByLevel symbology, whenever you place an element on any particular level, the placed element will automatically adopt the ByLevel settings set in the level library, instead of having to define a color, weight and style for each element (or cell) in your design file.

One example of where this can be very helpful ¾ and save a lot of time ¾ is when migrating design files from MicroStation J (or other earlier versions) to V8, in cases where a different set of CAD standards will be used in V8. By setting all your cells’ symbology to ByLevel, your V7-to-V8 migration can be made simpler, due to not having to manually re-set symbology for each cell after the migration. You can use CellManager to set ByLevel symbology for weight, color and style, in batch, for all your cell libraries.

The values in the Element Selection Criteria are telling CellManager to change all possible symbology attributes to ByLevel symbology (as specified in the Element Modification Specifications).

Take control of your cell libraries!
Now you are equipped with this time-saving knowledge. These are just a few of the dozens of things you can do with CellManager. CellManager can save you time when managing any aspect of your cell libraries. Nobody wants bloated and disorganized cell libraries (especially your client). Make sure your cells are kept up to standard.