[cad-linux] Re: Design methodology for an open geometric data management standard

  • From: "Lee Harding" <lee.harding@xxxxxxxxxxxx>
  • To: <cad-linux@xxxxxxxxxxxxx>
  • Date: Mon, 8 Sep 2003 09:07:44 -0700

Oh my.  Are you really suggesting that a model of program (and user)
interaction developed for tty terminals be extended into the world of
hardware-accelerated, feature-based, parametric and variational solid

Are you also playing text-mode quake in you spare time?

-----Original Message-----
From: Eric Wilhelm [mailto:ewilhelm@xxxxxxxxxxxxx]=20
Sent: Sunday, September 07, 2003 9:38 AM
To: cad-linux@xxxxxxxxxxxxx
Subject: [cad-linux] Design methodology for an open geometric data
management standard

At some level, this is really just about a CAD file format.  Hopefully,
in the=20
end, a simple 2D drafting program can utilize the standard as a simply=20
accessible data set.  However, to be robust and expandable to handle all
the complexity of a large engineering project, the standard needs to be
more than a way of describing shapes.

I'd encourage every software developer to read this page:

I think that most of us are already thinking with "the Unix Philosophy"
this, but I think the parallel has to break when it comes to the format
the input/output streams (and the storage of the data.)

Most of the command-line programs for Unix/Linux are text-based/ text=20
processing programs (cat, sed, grep, awk, head, tail, etc.)  They all
together really well for processing text streams. =20

The question that I wish to answer is this:  How do we extend this
approach to geometric and engineering data?

While handling the data as simple entities accessible with very little
overhead allows for easy creation of simple programs, I think an
layer is needed to create robustness.

As an example, consider the arc forming the bottom edge of the
corner of the far-right sink (model 23, manufacturer X) in the men's
on the west end of the third floor in building five of project number

This is (as far as reading and displaying the data is concerned) simply
an arc=20
with a radius of 3.5" parallel to the world-xy plane at some x,y,z
location. =20
Accessing this data in read-only mode should be exactly that simple.
notice how I have described it.  It is obviously an entity in a=20
highly-parametric model and should remain linked in this way so that the

parametric program which created it is not broken or confused by=20
modifications to this data.

Now, how do we abstract all of this to a level that allows multiple=20
highly-parametric programs to utilize and modify this data in a
way?  And how do we make it simple enough to access the data so that
programs can use it to perform simple tasks without having to get over
all of=20
the complexity associated with maintaining (or even just parsing
through) the=20
parametric relationship?

I'm just trying to spark discussion with all of this, so please don't
it as trying to make a simple thing complicated.  My wish for this open=20
standard is to make simple things simple and hard things possible. =20


Other related posts: