Data Management


This was planned to appear here many days ago. (hmm, that’s an understatement…) Well, the day has come… It follows the previous post as the real life example from the industry.

 I was in Coober Pedy for the whole of one week, many weeks ago. That’s the place where men, women and others dig in to find precious stones of Opal, the Australia’s famous gemstone. I didn’t say the most famous because there are apparently some that are becoming more famous. Such as Uranium for example. Not everyone would call that one a “gemstone”. Time will tell, and I hope we can revisit then.

This little town sits on the edge of civilization, some 700mi North-West from South Australia’s capital, Adelaide. You can call THIS one  – Outback. Walk up to the first hill and you will see the same old flatland, shrubbed to horizion. The landscape extends unchanged (and unchallenged) for hundreds of miles. Or maybe thousands – I didn’t feel like checking it out…

The local authorities here excel in optimizing their resources to sustain growth and continue to provide best service to the community so much in need for efficient roads and drainage.

Engineering is on the forefront of that game but resources are scarce – many opt to go and work on a Panama project for a major international. Money, fun and glory I guess…

Anyways, the need here is for efficient road network, overlaid on top of well battered dirt roads. No freezing – ever. Just a good, solid mixture of goodies to seal the dirt, not cost a fortune and allow heavy trucks and stiletto shoes to roam over in high seasons.

Noticed the comment about cost? Well ok, stilettos take the storm there. To minimize the cost of sealing dirt roads and provide the highest throughput of heavy traffic, Coober Pedy City Council employs the best practices in Civil 3D and some ingenuity on the forefront of our sweeping tsunami.

We were just cruising among Tool Palettes, Right-clicks and Styles when a Surveyor walked in: “Here, before you go too far, make sure we can read-in this data from my jigger.” And he was holding that Topcon total-station by the neck. Sure, a good cowboy never chickens out of any challenge so we tugged the cords to the right port and slapped a baud rate where it matters…

We used the usual, Topcons own pack but it only gave us NEZ of points file. I asked for  Topcon’s documentation and THERE (who would expect that) we found a few words about LandXML… After exporting the job from the jigger and importing it back in Civil 3D as Survey LandXML we hit the wall of a syntax error on line 1224…

Somehow this time, the crew was impressed just by the fact that we were able to display points and symbols in the correct layout. We left it at that and continued with the data set by learning about the best ways to define breaklines from selected point objects on the screen. So we made a Point File format to import points by Point Name:

 Topcon Point File Format and we arrived at the points in Prospector and on the screen. As far as everyone was concerned, this mission was accomplished:

Points in Prospector Points on screen 

But not to me, since that Survey LandXML import went part of the way but just shy of completion, some under the hood work was on the books.

The sample data, screen captures and the outcome was sent to Autodesk. Digested and disected, not sure about the order there, I had the advice of resolution come my way in the form of Service Pack, soon enough.

So now, we were able to watch (online session this time) Topcon generated Survey LandXML file produce some Survey content in the Survey database and it looked like this:

Survey LandXML in Survey Database The outcome is that now surveyors can explore the full potential of setting up multiple stations, defining Traverse loops, collecting figures etc. and significantly cut down the time spent in the office on processing those points to define breaklines, check and correct the data…

Meeting with strangers and then parting with friends a couple of days later is my perfect scenario but this one had to be extended well beyond Friday evening since flights from Coober Pedy resume on Sunday afternoons only. So, I had a choice to get out and about or stay and rust away in my room. Since no Dorothy with an oil can was in sight, I decided to go. 

It was all hip-to-hip that Friday night at the Main Pub in Coober Pedy when the travelling hoo-wee-hop of leaping lizzards show passed through the town. I too, was lining up at the bar for some digger’s mouth relief. I thought I was having fun until a local dealer of “fine Opal” from his pocket (that should have bought him a few more drinks that night) made me realize just how obvious I was. It was the time to call it quits and retreat to the confines of the mud hut room and a mellow sound of em-pee-threes streaming behind the barren screen of my mobile phone…

Blimey! This post sat in the draft unnoticed for days! Well, better late than never…

Leica announces that their total stations have the onboard ability to convert 1200 Series jobs to Autodesk Fieldbook (FBK) files for use with LDT, Civil 3D and other software. This tool is part of their software suite onboard 1200 Series Instruments.

This component is called Field Data Extractor (FDE) and the latest version is 5.10. Civil 3D users with Leica jigger can download it from:

http://www.leica-geosystems.com/corporate/en/downloads/lgs_page_catalog.htm?cid=4503

Here is the extract from that page:

Field Data Extractor

So, what’s the big idea with this? Most surveying instruments support FBK format these days. Right? Well, that’s quite true, but it’s not always that simple to implement available software solutions from any instrument manufacturer. You see, total stations have become very smart these days. For example, you can use your Pocket PC, PDA or even your mobile phone with a Bluetooth as your jigger. And how do you achieve this? Very simple, you just need to install a piece of software that will connect with your total station.

Did you know about this? Do you own a PDA, a Pocket PC or a mobile phone that can do this? Do you know if such software is available from YOUR instrument vendor? Do you know where and how to get one?

Well that’s the catch, right there! You can only ever implement a piece of technology if you knew one existed to solve YOUR problem. And in different parts of this wonderful industry, information spreads in different ways. For example, you may still believe that recording sectional terrain data is THE only way to get the most accurate earthworks estimates. Or, you may still do this just because you were told to do so by a “trusted” adviser…

As a result, this software that MUST sit on your latest jigger was ported from the code that was written 20 years ago and now nests nastily over 200Mb of that memory reserved for programs on your instrument. That leaves it about 56Mb to install all the OTHER software that supports the latest and the greatest surveying methods that have emerged in the meantime.

Surveying instruments were never designed to host a very long list of software tools or surveying jobs (and thank God for that! says a support engineer).  There is a long list of extremely useful software tools developed by instrument vendors to optimize the use of their gear and make their products easy to implement and achieve the maximum productivity in no time. AND there are tools developed to run on the instrument to optimize its use with the most popular Surveying and Design software on the market such as Civil 3D. All one needs to do is ASK their vendor if those tools are available and to INCLUDE them with the software tools deployed onboard their total station.

The truth is, new total stations are delivered “blank” to your local reseller. They are then made to serve the local user by going through the workshop first, then to the Support Engineer’s desk to install the suite of software commonly used in that region. And that’s where this process breaks in many parts of the world. (Yes! Go on, blame the Support Engineer!) In most cases, you can’t do this software installation in your office – it has to be done by the instrument vendor. In many parts of the world LDT/Civil 3D have arrived just recently and the incumbent Surveying software tools were used for decades before that. And total stations from Leica, Topcon, Wild, Zeiss etc. for even longer than that. So, the software support engineers have the well defined and long time tested and proven set of software tools optimized for the common use that they install on your jigger and it fits within the constraints of the available memory. If we were to include a new software tool to talk specifically to Civil 3D then in many cases some other tools would have to be dropped  from the jigger to make space (What? Not the cross sections pickup!).  Now, do you think Support Engineers will make the decision to remove a part of the defined set of tools just to include a new one? And which component should they remove? Maybe there need to be more than one tool taken away to add the new one… Is it at all possible to do this since the set of tools may be wrapped in an install package?

There are number of reasons why many of the latest software tools that COULD be on your instrument don’t ever make it there.

Here is a list of some common tools that are often “best kept secrets”:

  1. Translators to Fieldbook file (FBK)
  2. Components enabling support for LandXML format
  3. Tools enabling support for GENIO format
  4. Components enabling direct display of field observations in an active AutoCAD drawing.

And there are more, but just to keep it SaS (Short and Sweet) we’ll leave it at this.

Here are some links to further explore this topic:

http://www.leica-geosystems.com/corporate/en/support/lgs_page_catalog.htm?cid=239

http://www.leica-geosystems.com/corporate/en/support/lgs_page_catalog.htm?cid=5111

http://www.trimble.com/link_ts.asp?Nav=Collection-27103

http://www.trimble.com/link.shtml

TRIMBLE TSC

Have fun!

Rad Lazic