> > 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. > 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. 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. does the step definition also contain defintions for traversing the topology of the shapes, and measurement functions? Henrik Rudstrøm
_______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users
