[cad-linux-dev] Re: Drawing entity
- From: Eric Wilhelm <ewilhelm@xxxxxxxxxxxxx>
- To: CAD linux development <cad-linux-dev@xxxxxxxxxxxxx>
- Date: Thu, 19 Aug 2004 15:08:27 -0500
# The following was supposedly scribed by
# Bruno Postle
# on Thursday 19 August 2004 12:53 pm:
>On Thu 19-Aug-2004 at 13:22 -0400, Somerlot, Chris wrote:
>> One thing I forgot is that there should be an entity for the
>> drawing itself, that stores attributes like units, a timestamp,
>> and a version.
>
>Having to look-up an external file to discover the units of an
>element is an added complexity - It would actually be really useful
>to store the units at the element level and Eric just convinced me
>that this is how layers etc... should be treated.
Oh no! Did I do that? Now I just have to un-convince you piecemeal fashion.
>For instance, if your drawing has a base unit of metric inches, then
>the nominal diameter of an M10 bolt is .3937007874015748031496062992
>inches and is going to attract rounding errors - These errors would
>go away if you allow a 10mm circle to be 10 millimeters and a 2x4
>piece of timber to be 2x4 inches.
Okay, aside from the fact that it's going to be 1.5624"x3.6" on Tuesdays,
let's consider the implications of global vs. local units and weight it
against the likelyhood that it matters.
Primarily, the units property is just a matter of indicating the scale which
must be used to resolve drawings created in different units.
A drawing is almost always going to be drawn in one set of units. This argues
strongly for a global property. Possibly, entities could over-ride the
global units locally. If so, is this per-number? (e.g. the bolt is centered
at coordinate [0,5] inches, but has a radius of 5mm.)
However, where do round-off errors really matter? If I have to parse it at
5mm and display it in the context of inches, the errors will be there somehow
anyway. Technology will get better and we'll have fractions natively
supported. Until then, we'll all just accept that computers are stupid and
live with it.
>Timestamps can be retrieved from the file properties (or a CVS
>history for much finer resolution) and I'm still voting for a
>'file-format version' attribute in the elements themselves.
Timestamps: yes. History: yes. These come from the filesystem.
Version: global property
I don't think it's practical to design code around versions changing across
entities within a single database. I could see a base class and a toplevel
layer which checks the version and calls to the appropriate subclass. So,
the version would likely be in the "drawing.yml" file with things like
"units".
Items like "creation date", "project name", etc could be stored under a
'notes' hash in the drawing.yml structure. But, these things will likely
just be used where consensus and convention allows (e.g. "not in the spec".)
--Eric
--
"It ain't those parts of the Bible that I can't understand that
bother me, it's the parts that I do understand."
--Mark Twain
Other related posts:
