[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
modeling?
Are you also playing text-mode quake in you spare time?
http://webpages.mr.net/bobz/ttyquake/
-----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
of=20
the complexity of a large engineering project, the standard needs to be
much=20
more than a way of describing shapes.
I'd encourage every software developer to read this page:
http://www.catb.org/~esr/writings/taoup/html/ch01s06.html
I think that most of us are already thinking with "the Unix Philosophy"
about=20
this, but I think the parallel has to break when it comes to the format
of=20
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
work=20
together really well for processing text streams. =20
The question that I wish to answer is this: How do we extend this
toolbox=20
approach to geometric and engineering data?
While handling the data as simple entities accessible with very little
format=20
overhead allows for easy creation of simple programs, I think an
abstraction=20
layer is needed to create robustness.
As an example, consider the arc forming the bottom edge of the
front-left=20
corner of the far-right sink (model 23, manufacturer X) in the men's
bathroom=20
on the west end of the third floor in building five of project number
342.
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.
But=20
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
cooperative=20
way? And how do we make it simple enough to access the data so that
simple=20
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
dismiss=20
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
--Eric
Other related posts:
