Hi Dave, Very interesting post.
Last year, I thought about a kind of 'modular' application built on top of pythonOCC. The idea was to develop a core of basic functions/classes extensible with user defined modules (or plugins) made available over the internet. The module dependency is clearly an issue, and I identified the Enthought Envisage Framework (http://code.enthought.com/projects/envisage/) as a good solution to manage the dependencies, as well as input/outputs of the modules. Two of my students worked on this idea to check whether or not it was feasible. Unfortunately, they didn't go as far as expected and I still don't have the answer. Regarding the STEP standard, there is not any real 'interface' as we usually understand it. STEP is mostly 'data centric' and there is still clearly a lack of API on top of it to create/remove/manage entity instances. I would like the pythonOCC High Level API to be as close as possible to the STEP semantics (for the geometric part), which would not be difficult to achieve since the OCC data model is very similar to STEP (edges, vertices, axis placements etc.). As a consequence, this HLA could be a contribution to the STEP community as an attempt to build an API over STEP. I'm convinced that, if we get through this HLA issue while staying tangent to the STEP AP203(ed.2), our work could become widely adopted around the CAD community. At last, you talk about a 'tree of entities' in a STEP file. I'm not sure that the topology of the relationship/instances is isomorphic to a tree graph. Thomas 2010/12/30 Cowdens <dave.cow...@gmail.com> > Hi, guys, > > I am thinking about the method-centric approach. > > In earlier discussions, it was noted ( and i think agreed by most ) that > the steps to create a particular object could be arbitrarily complex. I > think the only method-centric format that will not result in loss of > generality will be python code. ( Unless of course the file is a wrapper > with some header information and a python code additionally ). > > It would be conceivable to store objects as a python script that creates > the object without loss of generality, but I think there are several > challenges with this: > > - Performance would become a problem in larger models. i think there > is a real need in cad systems for 'opaque' objects-- ones you can include > and interact with, but cannot afford to rebuild every time. Examples would > be an assembly with 1000 or so nuts and bolts > - Dependency management comes into play. since python is a programming > language that can import dependencies,a script to create an object might > import libraries unavailable on another platform, or might use a different > version of python, etc. If a python script is the serialization > format,these dependencies must be considered. > - the interface is not well defined. If a object is in a set format, > for example STEP, the format defines a very specific 'interface'. in the > case of step, a single step file contains a tree of entities that exist in > a > well defined structure and notation. the format defines how to infer this > structure to learn what objects are in the file. A python script, though, > could produce an arbitrary number of objects in an arbitrary strcture, and > may not do it in a standard way. So, if a python script were used, it would > need to export well-defined functions that allow a caller to get this > information. > > Most of these challenges can be solved. Interestingly, I believe that > following the 'module-based' will result in cad models handled much the same > way as programming projects are. You wouldnt need a new type of repository, > you could just use svn becuse you just need to store source code. > assemblies are just python projects that import a bunch of python libraries > from others ( which happen to produce objects ). The biggest challenges, > too will be those programming projects face-- namely, dependency > management. > > I suspect we would end up needing to have a way for each 'module' to > describe not only what objects it exports, but also a way to enumerate its > dependencies both in terms of runtime ( eg python libraries and such ) as > well as other objects it is dependent on ( eg, others it has aggregated ) > > the apache maven project impements a very similar model for java code by > using a pom.xml file ( project object model) that allows a java project to > declare this type of information. Then, maven assembles the project by > automatically finding and resolving all of the dependencies ( including > transitive ones ) from repositories storing the dependencies > > ------------------------------ > *From:* pythonocc-users-boun...@gna.org [mailto: > pythonocc-users-boun...@gna.org] *On Behalf Of *Thomas Paviot > *Sent:* Thursday, December 30, 2010 4:00 AM > *To:* jelleferi...@gmail.com; pythonOCC users mailing list. > > *Subject:* Re: [Pythonocc-users] writing OCC data to a db > > Hi Jelle, > > Interesting topic, this going to be a long thread! > > The use of a python ORM is also the choice I would have done. In my mind, > there are two ways to model such a database: > - a "data centric" db: you store the result of the different operations you > ran (for instance a Point and a Cube); > - a "method centric" db: you store the functions that you called and the > parameters passed (for instance "create_point, 10,10,10" and "make_cube, > 20,30,40"). > > For the data centric method, the db size will be more important than the > second solution. For each object, I would only create a key and a "STRING" > field in which I would store the output of the serialization of the python > object (with the pickle module). > > The second method require less size but more computing time (since the > different operations has to be computed each time you load the model). > > I have the feeling that this discussion is very close to the thread related > to data model of the High Level API. That's something that could be an > additional constraint of the HLA: "All pythonOCC HLA objects must be > serializable to an XML file in order to be exchanged/shared through a > network or stored to a database". > > Cheers, > > Thomas > > 2010/12/29 jelle feringa <jelleferi...@gmail.com> > >> Hi, >> >> Recently I had enough of storing OCC's cad as files. >> Sometimes all you need is a database. >> Turns out that its really easy to do so. Perhaps its worth sharing how >> this can be done... >> Though this might be pretty trivial technically speaking, it can open up >> interesting ways of collaborating on projects. >> >> -jelle >> >> >> ================================================ >> from OCC.Utils.Topology import Topo >> >> __author__ = 'jdf' >> >> >> from sqlalchemy import * >> from sqlalchemy.ext.declarative import declarative_base >> from sqlalchemy.orm import sessionmaker, scoped_session >> >> from OCC.Utils.Construct import make_cube >> #from OCC.TopoDS import TopoDS_Shape >> # >> #TopoDS_Shape.__eq__ = lambda x: TopoDS_Shape.IsEqual(x) >> >> cube = make_cube(1,1,1) >> >> engine = create_engine('sqlite:///jelle.db') >> Base = declarative_base(bind=engine) >> Session = scoped_session(sessionmaker(engine)) >> >> def comp_brep(brepA, brepB): >> import ipdb; ipdb.set_trace() >> print 'jajajaj',brepB, brepA >> return brepA.IsEqual(brepB) >> >> class Individual(Base): >> '''used to store data about an individual >> a row forms a generation >> ''' >> __tablename__ = 'individual' >> >> id = Column(Integer, primary_key=True) >> #name = Column(String) >> #fullname = Column(String) >> #password = Column(String) >> generation = Column(Integer) >> ancestor_a = Column(PickleType()) >> ancestor_b = Column(PickleType()) >> brep = Column(PickleType(mutable=False)) #comparator=comp_brep)) #) ) >> fitness = Column(Float) >> >> Base.metadata.create_all() >> >> >> indy = Individual() >> indy.ancestor_a = 'parent_a' >> indy.fitness = 12. >> indy.ancestor_b = 'parent_a' >> indy.generation = 1 >> #indy.id = 0 >> indy.brep = cube >> >> ''' >> to INSERT many rows very quickly, use the "executemany" style of >> insertion: >> >> >> connection.execute(table.insert(), [{'foo':'row1'}, {'foo':'row2'}, >> {'foo':'row3'}, ...]) >> ''' >> >> s = Session() >> # s.begin() >> s.add(indy) >> s.commit() >> s.close() >> >> print('closed the previous db session\nlet\'s see if we can read back the >> objects, that be cool...') >> >> engine = create_engine('sqlite:///jelle.db', echo=True) >> Base = declarative_base(bind=engine) >> Session = scoped_session(sessionmaker(engine)) >> s = Session() >> >> from OCC.BRep import BRep_Tool >> bt = BRep_Tool().Pnt >> >> for indy in s.query(Individual): >> print indy.id >> for i in Topo(indy.brep).vertices(): >> print bt(i).Coord() >> ================================================ >> >> >> >> _______________________________________________ >> Pythonocc-users mailing list >> Pythonocc-users@gna.org >> https://mail.gna.org/listinfo/pythonocc-users >> >> > > _______________________________________________ > Pythonocc-users mailing list > Pythonocc-users@gna.org > https://mail.gna.org/listinfo/pythonocc-users > >
_______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users
