OT: CAD (was Re: [Twisted-Python] Re: In Defense of Taps)

Steve Waterbury waterbug at beeblebrox.gsfc.nasa.gov
Wed Feb 12 23:10:28 MST 2003


Moshe Zadka wrote:
> 
> On Wed, 12 Feb 2003, Steve Waterbury <waterbug at beeblebrox.gsfc.nasa.gov> wrote:
> 
> > An important piece of this puzzle is the STEP (ISO 10303) standard for
> > "Product Model Data", which is a set of information models of the various
> > types of data I mentioned above.  STEP itself is very complex (and not
> > pretty, but it's really the only game in town for multi-disciplinary
> > engineering data integration and it is taken very seriously by all large
> > manufacturing organizations ... the list of organizations using/developing
> > STEP is a who's who of manufacturers:  Ford, GM, Daimler-Chrysler, Boeing,
> > Lockheed-Martin, Northrup Grumman, Raytheon, etc.), so one of the constraints
> > on PGEF is to be able to map between STEP's information models and the PGEF
> > repository schema ... if you browse the comments in createPgerDbTables.sql,
> > many refer to how things map to/from STEP.
> 
> STEP pretty much sucks for data-exchange, for a number of reasons. The primary
> reason is that STEP loses the "design information", so that editing it is
> about as fun as debugging programs by fixing their .o representations.

I'm not sure which "design information" you are referring to.  
There are many, many types of design information.  
If you mean "construction history", that is being added to 
AP203 Ed. 2.  If you mean "parametrics", that is also to be 
added soon.  If you mean "manufacturing features", these 
are handled by AP224.  STEP has proven itself as the absolute 
best standard format for exchanging explicit 3D geometry between 
CAD systems, period.  In fact, during the past 10 years of 
STEP translator implementation, STEP has actually advanced 
the state of the art in handling differences between internal 
representations of geometric accuracy between CAD tools, which 
was quite a serious problem even for "point-to-point" solutions.  

The fact that you even refer to "editing it" (presumably you 
mean editing a STEP Part 21 file, which no one in their right 
mind would attempt, any more than you would try to edit a 
.o representation, as you say) suggests that you have quite 
missed the point:  STEP provides a set of information models 
and various ways of implementing them, one of which is file 
exchange (Part 21, "Clear Text Encoding"), and there are lots 
of tools for parsing, browsing, validating, mapping, 
visualizing, and *intelligently* editing STEP data.  For some 
examples, see:

http://www.lksoft.com

Lothar Klein's stuff is very cool.  Not open source, but very 
powerful, and very reasonably priced (probably much more 
reasonable than the proprietary solution you cite).

> I don't know of any free solution, but Proficiency
> (http://www.proficiency.com/products/product_overview.html) is working
> in this area -- and their very existence is a testimony to STEP suckage.

Not really.  It's just another proprietary solution, of which there 
will always be lots.  That's a bit like saying the existence of 
J2E proves that Twisted sucks.  ;^)  

BTW, you don't know of any "free solution" because there isn't 
one.  CAD software is complex, difficult stuff.  There *is* a free 
library for CAD, OpenCASCADE, which also has implemented some 
STEP translators ... and the fact that a powerful open source CAD 
package thinks STEP is worth implementing says a hell of a lot 
more about it than the existence of some over-hyped proprietary 
data exchange solutions.  

Believe me, having worked on STEP and STEP applications for the past 
10 years or so, I'd be the last person to claim that it's pretty.  
It has lots of warts.  But the reality is that it's the best game 
in town right now, and nothing else on the horizon comes close.  
It's like the old Defenders opening line, "STEP is a very bad form 
of data exchange ... but all the others are so much worse!"  

Cheers,
-- Steve.




More information about the Twisted-Python mailing list