2010/2/21 Henrik Rudstrom <hrudst...@googlemail.com>
>
> > Hi Bryan,
>>>
>>> Hey Thomas. Thanks for the quick reply.
>>>
>>> > *Very* intersting thread, thank you for opening it.
>>>
>>> had to be done
>>>
>>
> definetely!
>
>>
>> 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 <http://t_swept-01.html>*)**;*
>> axis_position *:* axis1_placement <http://t_axis1-01.html>*;*
>> *DERIVE*
>> axis_line *:* line <http://t_line.html> *:=* representation_item
>> <http://t_repre-01.html>*(*''*)**||*
>> geometric_representation_item
>> <http://t_geome-01.html>*(**)**||* curve <http://t_curve.html>*(**)**||*
>> line <http://t_line.html>*(*axis_position*.*location*,*
>> representation_item <http://t_repre-01.html>*(*''*)**||*
>> geometric_representation_item
>> <http://t_geome-01.html>*(**)**||*
>> vector <http://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.
>>
>> Is it possible to generate a skeleton python api based on the express
> file, tried googling python express, found a
> powerpoint<http://www.google.nl/url?sa=t&source=web&ct=res&cd=6&ved=0CCMQFjAF&url=http%3A%2F%2Fwww.mel.nist.gov%2Fmsid%2Fconferences%2Faerospace_workshop%2Fslides%2FWednesday%2Fdekoning1.ppt&ei=aqWBS9LOKJS7jAfnsdSlBA&usg=AFQjCNEFDP7x7kgorFmh5nAhC-fD5nMmhA&sig2=Rpq21z7BuUggcPPYlKDALA>to
> pyexpress (by Nasa/Esa) but no other info.
>
pyexpress is an EXPRESS library written in python. I contacted a few months
ago the author of this presentation, Hans-Peter Koning from the ESA, to
learn a bit more bout this project. The source code was planned to be
release under a free license, but this is delayed for a long time. I don't
have any further information, but I do not think that it's the main issue of
the topic we're talking about: EXPRESS libraries allow to parse/write STEP
files, parse EXPRESS schemas, generate STEP files according to the EXPRESS
schema, check the validity of rules defined for entities etc. Such libraries
are necessaries, however they don't tell anything about the way the data
model has to be understood and processed. For instance, the 10303-203
application protocol defines how to represent a cartesian point:
*ENTITY* cartesian_point
*SUBTYPE* *OF* *(*point <t_point.html>*)**;*
coordinates *:* *LIST* *[*1*:*3*]* *OF* length_measure <t_lengt-01.html>*;*
*END_ENTITY**;*
The EXPRESS library will know howto generate a STEP file (Part 21-Text or
Part 28-XML) to describe all instances of this entity. But that does not
mean your program will be able to represent this information. If you have
one cartesian point with the coordinates 10.0,10.0,20.0 , it can easily be
described in OCC with: gp_Pnt(10,10,20). That defines a mapping between the
cartesian_point entity and the gp_Pnt class.
The OpenCASCADE library (6.3.0) handles the first version of AP203. However,
the latest release of AP203 is quite recent (2005), and I'm almost certain
that the procedural modeling or representation of parameters is not
implemented yet.
In my opinion, if we ever develop a simplified or 'universal' API above the
OCC python wrapper, it has to be STEP based. The plan would be to:
1. Check if it's possible to map all express entities to occ classes. The
ideal is a one-to-one mapping (for instance the cartesian_point<->gp_Pnt).
But maybe it's not possible for all entities (semantic ambiguities),
2. try to port a simple procedural example from a STEP file to a pythonOCC
script,
3. Use an EXPRESS library to generate/read AP203 procedural files (the best
library I found for that is JSDAI: http://www.jsdai.net/ . It's GPL,
java-based, but can be accessed from Jython).
>
>> 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.
>>
>
>
> a set of functions looks much clearer for simpler entities, but might
> probably less readable when there are too many arguments.
>
> Thats an interesting question, my guess is that a 'compute' function is the
> most flexible, then you can pass the objects around add/modify its
> parameters before actually computing them, but on the other hand you have to
> keep track of whether they have been computed or not or automatically
> compute them when they the objects that reference them are computed (but
> thats probably a bit too much magic).
>
> A third option could be to use the class constructor, but im not sure what
> that would add compared to option 1.
>
I don't know either.
>
>
> One thing im curious about is how this relates to the previosu work on kbe,
> which seems to be very object oriented, wheras the following the step
> approach would result in a more functional-like api.
>
> curve.tangent(u) would become something like create_tangent(curve, u)... i
> have a slight preference for the first.
>
I agree, an object oriented approach is definitely better.
>
> does the step definition also contain defintions for traversing the
> topology of the shapes, and measurement functions?
>
I don't know enough the AP203 protocol to answer this question.
>
> Henrik Rudstrøm
>
Regards,
Thomas
>
_______________________________________________
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users
