[freearchitecture] An open CAD file format

[Steve Hall]

Bruno Postle wrote:
 > On Mon 17-Feb-2003 at 01:30:24AM -0500, Steve Hall wrote:
 > >
 > > If it lives in CVS, then file management from my hdd is
 > > irrelevant, I don't care about what it looks like there, I
 > > shouldn't even see it. But what if I want to mail it home to work
 > > on?
 >
 > You don't email it to yourself, that's the sort of versioning
 > nightmare that CVS is designed to avoid; you just go home and type
 > `cvs update` to synchronise your home copy with the work copy.

So the "file" lives in CVS. I'm trying to understand how it can still
have a singular identity on disk.

In many instances there's a need to deliver an individual physical
media with a complete representation of the information. We submit
drawings on CD-ROMs for proposals (like my proposal due in two weeks),
email them to and from consultants and owners, snap shot them into
archives, and carry them home on CDs to work in places that have
pathetic or non-existent bandwidths. It all practically occurs outside
CVS.

 > I shouldn't have mentioned that whole zip file thing :-).

I use genealogy software that maintains data in a file store. The
pointer file's MIME type associates with the app. The average user
could handle this if the structure was a single compressed file (like
OO). There has to be *some* way to hand the data off without
connection to CVS/db, I guess that's why I seized on the zip file
package notion. Perhaps a file out of the CVS system could be orphaned
somehow?

 > Of course, all this can be made non-scary with many free
 > pointy-clicky GUI tools.

The CAD/CVS part, yes. But it should look reasonable from the file
manager, too.

 > It may sound heretical, but XML is terrible in versioning systems.

I get the point about whitespace and re-formatting. Still imagining a
system where the drawing lives in a database and the file on disk is
just an export. The versioning happens at the db, the XML is just a
way to describe SQL queries to update it, in effect a diff file. We
also need to manage the checked out data chunks, XML could handle
that, too. Again, the XML isn't what's getting diffed, it's a
container referencing db or on-disk info.

 > > * Blocks, Xrefs, groups and symbols are all the same thing--yes,
 > >   in my mind, this it the one thing AutoCAD got right.
 >
 > Except that there is no polymorphism.
 >
   [snip]
 >
 > In this office we hardly use Xrefs at all for these sort of reasons.

Hmm... we use Xrefs for layering plan info, not for blocks. The
Architecture dept. maintains base plans (based on Structural plans)
and Electrical, Mechanical and Plumbing engineers xreference them.
When we update, they get the changes automatically.

 > > Although I believe our new generation CAD file is already
 > > abstracting the data still further to include rasters, spec data,
 > > schedule, bid, etc., really anything.
 >
 > This is what I can't stand about .dwg (and similarly .doc), crazy
 > stuff like embedding simple JPEGs into a proprietary file format
 > where I can't edit them without buying a copy of AutoCAD.

Certainly, by "file" I meant either the store or db idea. Embedded
data is ridiculous, but uniformity of file type for blocks, xrefs and
drawings is efficient.

Maybe I'll find time today to detail the db file format a little
further. We have 3" of sleet on the ground and everything's closed.


Steve Hall  [ digitec__pring.com (insert "t at minds") ]