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