Academic Facets: News and Views from Spatial's University Community

[#1]

On the flight back from the ICA Conference in Madrid I read Benji Wilson’s article in the airline magazine on the ‘office of future’. “Microsoft” he said  “believes that the glut of information that will become available at workers’ fingertips means visual real estate (e.g. vast screens) will dominate the office of the future”.  Not a particularly startling view of tomorrow since it is already true; most of us have had the information glut problem for sometime and big screens help. I’ve noticed the use of two screen desktops amongst my researchers and postgraduates has gone from novelty to standard over the last two years.

 But space for displaying information is not the whole solution, a glance out of the plane window at the sunny countryside of northern Spain is all that’s needed to recall that ‘master class’ in dealing with information gluts: Google Earth

 It is amazing (after the initial feeling of ‘slack jawed’ astonishment has worn-off) to reflect on all the heterogeneous data types that have been seamlessly merged into a single (no manual needed) interface. The satellite photographs can be overlaid with roadmaps and zooming in, the resolution of the images jumps up, eventually (in places like New York) revealing 3D models of the city buildings. And yet all this is simply a frame work to display local information about the whereabouts of, say, bicycle shops or links to photos and video related to specific landmarks or locations.

 The earth is one 3D object for which masses of data exist but many mechanical products (and even individual components) can be associated with similarly diverse mixtures of information. However unlike the earth there are no intuitive, unified interfaces.

 A manufacturer of mechanical products like, say, impeller blades, can’t zoom-in on an image and seamlessly reveal the surface textures captured by optical scanning data; they can’t overlay idealised representations such as CAD models, or system schematics, on captured images of the physical product. They can’t selectively display analysis results for, say, only the root of a blade (if you want to see the FEA data you have to use a dedicated viewer, no question of mixing physical metrology with numerical analysis).

In today’s PLM systems all this information is associated but a strict separation is enforced on its display. There is a ‘need to know argument’, why would anyone want to display cutter tool-paths in the same picture as inspection information? But today’s engineers are increasingly multi-skilled and often problems arise simply because the correlation between data is not recognised.  A graphical interface to product data does not have to only support CAD data, if video logs of engineering discussions were tagged directly onto a visual display of the components, their existence could be seen without painful searches of hard disks.

A Google Earth style visual navigator for PLM  is such a compelling idea that one wonders why it hasn’t been done? My guess is that it hasn’t happened because the Earth has one great advantage over mechanical parts; it has a universally recognised coordinate system (longitude and latitude): to which all national maps and postal addresses ultimately relate. 

Mechanical components, on the other hand, have part numbers and a plethora of 3D data, each, potentially, defined in different coordinate systems.  So an engineering document, or email, might mention a part number but there is no way to relate that component id to a location in a display; and so no way the information can be automatically tagged to a visual interface.

 To reference different data types to the surface of physical object you need a surface parameterisation (similar to those used to locate surface textures). But mapping a 2D grid onto an arbitrary 3D shape is well known as a difficult academic research topic (see Bruno Levy’s http://www.loria.fr/~levy/   web site).  Of course for display purposes the coordinate system does not have to be perfect, the earth’s certainly isn’t (a degree of longitude has different physical dimensions at pole and equator), but it does have to be universally accepted across all systems that generate information related to a particular part. So when, for example, manufacturing quotations are obtained, or the service department send back photographs of failed parts they are all related to a specific location on a part or assembly. 

 Maybe we need a STEP standard that defines a system independent surface parameterisation? Or perhaps product centred viewers for heterogeneous CAD data already exist? If so, I’d be keen to hear of even small steps in this direction (let me know). In the meantime I will continue to attempt to keep my mouth closed when using Google Earth (the picture resolution is so high over Edinburgh you can actually see my sister-in-law standing in her back garden, she is only a few pixels big but there really is no doubt)!

---