[freearchitecture] Architectural information databases

[Steve Hall]

Steve Hall wrote:
 >
 > That's an interesting point to note for some future Free CAD app.
 > CVS-able data would be useful beyond just drawing vectors. Imagine an
 > SGML-type spec data, task lists, budgetary analysis, finish
 > schedules... all would benefit from versioning.

Sorry to self-reply, but can't help continuing to think about the
proper CAD file format.

I've always considered CAD essentially a database. I don't believe
most legacy apps started this way, given their ancient focus on the
final drawing export (as a print). Maybe they've evolved to work this
way now. But if you consider the vectors and other drawing entities
objects as a data store, extending them with text, rasters or any
other types of information is trivial. The hard part is the interface
to input and retrieve the data. I think this is the very problem we're
discussing with making DXF CVS-able.

Ok, now that the CAD data is resolved in some SQL back end, we're only
concerned with putting objects in and out of it. We can filter
selections however we want for printing, connectivity with other CAD
files, etc. Input method can be traditional CAD environment, text
entry, scanned values from a surface survey, pre-manufactured data
sets, GIS info... whatever.

The best part of this schematic is that any of the components can be
designed separately. Bottlenecks between these points (such as
converting a DXF file to some other format) is "only" a local problem.

It would be interesting to brainstorm about the types of data an
Architect needs to organize and how best to arrange them. We think of
drawing objects apart from most other data but it would be helpful to
explore relationships that might formulate a new method. I know I'm
always yelling around our office about the future of connections
between specs and drawings, but I wonder if we could find some more
obvious (or easily implemented) improvements.


Steve Hall  [ digitect___ring.com (insert "@mindsp") ]