2010/2/21 Bryan Bishop <kanz...@gmail.com>
> On Sun, Feb 21, 2010 at 1:59 PM, Thomas Paviot <tpav...@gmail.com> wrote:
> > Hi Bryan,
>
> Hey Thomas. Thanks for the quick reply.
>
> > *Very* intersting thread, thank you for opening it.
>
> had to be done
>
> > The topic you're talking about is still an open issue in CAD and
> > contributions from the open source community would certainly be a great
> > thing. However, it's not only a technical problem (in terms of
> > implementation), but rather a scientific one. As far as I know, a good
> > starting point is the second edition of the AP203 STEP application
> protocol,
> > especially the ISO10303-55 (‘Procedural and hybrid representation’).
> Being
> > able to implement this part of the standard in a scripting langage would
> > already be a huge step.
>
> Yes, absolutely. I do not have access to the ISO documentation on
> STEP. Maybe you can send a few files my way to help me out? There is
> one other resource that I am aware of- namely, the STEP export API in
> the OpenCASCADE source code. From this, it is possible to extract the
> valid entities that can be found in a STEP file in the EXPRESS
> language. But then you have the issue of adopting OCC's peculiar
> standard or peculiar implementation of STEP. Here's a skeleton of STEP
> features that I figured out by looking at the OCC source:
>
> http://designfiles.org/~bryan/step_importer.py
Hi Bryan,
Just browsed your proposal. It looks like you're starting to develop a STEP
parser. Please don't do that! It's a nightmare! I worked 2 full weeks on
trying to write a basic STEP parser, it was a mistake. Finally I moved to
Eclipse+JSDAI to parse EXPRESS files, it's much better.
When pointing out the STEP Procedural design representation, I was just
meaning that it could be a perfect template for a high level API on top of
pythonOCC. Let's take an example. In the AP203ed2.exp file, I can read the
following description for the 'surface_of_revolution' entity:
*ENTITY* surface_of_revolution
*SUBTYPE* *OF* *(*swept_surface <t_swept-01.html>*)**;*
axis_position *:* axis1_placement <t_axis1-01.html>*;*
*DERIVE*
axis_line *:* line <t_line.html> *:=* representation_item
<t_repre-01.html>*(*''*)**||*
geometric_representation_item
<t_geome-01.html>*(**)**||* curve <t_curve.html>*(**)**||*
line <t_line.html>*(*axis_position*.*location*,*
representation_item <t_repre-01.html>*(*''*)**||*
geometric_representation_item <t_geome-01.html>*(**)**||*
vector <t_vector.html>*(*axis_position*.*z*,* 1.0*)**)**;*
*END_ENTITY**;*
We could have something similar in Python:
class surface_of_revolution(swept_surface):
def blabla(self) etc.
The issue is then the mapping between AP203ed2 entities and OCC classes. The
AP203ed2 standard however doesn't specify any method about how to generate
the entities (ie the functions or class methods to use).
I see two ways to get done with implementation:
- use a set of functions, eg. create_surface_of_revolution(), create_line(),
create_vector() etc.
- use a 'Compute' method of each python class, this method being called over
all instances.
BTW, I'm not sure the link to the AP230ed2.exp is the 'official' one. It may
be the latest draft before the release. The only way to have the official
one is to buy the CD (the price is about 300€ in France).
Thomas
>
> > I think this approach would certainly be the easiest way to get started:
> the
> > STEP data model has been widely discussed and validated.
>
> Right now what we need most are the ISO 10303 documents. Otherwise I
> suspect nothing will happen. Whether or not this could be used to make
> an API is also another issue- I suspect so, but maybe we should forge
> ahead even if we can't get the ISO docs?
>
> - Bryan
> http://heybryan.org/
> 1 512 203 0507
>
_______________________________________________
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users
