[cad-linux-dev] Re: units as an attribute or a global setting

  • From: Steve Hall <digitect@xxxxxxxxxxxxxx>
  • To: cad-linux-dev@xxxxxxxxxxxxx
  • Date: Fri, 20 Aug 2004 17:20:59 -0400

On Fri, 2004-08-20 at 13:12, Bruno Postle wrote:
> On Thu 19-Aug-2004 at 15:08 -0500, Eric Wilhelm wrote:
> > 
> > A drawing is almost always going to be drawn in one set of units.
> > This argues strongly for a global property.
> 
> It may seem like this from your side of the atlantic, but in this
> country we measure road distances in miles, beer and milk in pints,
> orange juice in litres, cricket pitches in yards, bricks in
> millimeters and computer monitors in inches :-(
> 
> The UK building industry generally uses millimeters for everything,
> though decimeters and centimetres are more common in the rest of
> Europe - and of course structural engineers use meters.
> 
> > Possibly, entities could over-ride the global units locally.
> 
> That could work.  It would be neat to make this a general case - For
> example an element that doesn't specify a colour attribute inherits
> the default from the drawing - If the default drawing colour isn't
> defined, then it is picked-up from a system fallback value.
> 
> > 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.
> 
> ..but only in the display, unmodified elements will stay unmodified
> on the filesystem.

If I can be so bold as to interject here--the AutoCAD implementation
of units is, IMO, totally broken; I certainly hope nothing similar is
implemented here. 

There is nothing more complicated than having three drawings, one each
done in metric, feet, and inches, and trying to overlay them all at
the correct scales. I had this very problem a year ago: the US COE
drew a base plan in metric, our architectural overlay was in inches,
and our site plan was in decimal feet.

The user needs to select which unit format he wishes to use *at
input*. But the information must be recorded at some common "real
world" scale so that all the data references itself. Yes, a solution
needs to be created that can store data to avoid rounding errors, but
this is programming problem, not something the user should have to
hack around.

Off the top of my head, it seems like a more-than-16-bit (AutoCAD's)
coordinate system should be able to handle this. The range of error
could be floated so that in a drawing with entities and dimensions
near each other, the precision could be very high. Or in cases where
there is a great range of coordinate data (an animation of a satellite
orbiting earth maybe?) less precision would be available.

Or maybe the user selects the amount of data precision?

Anyway, I'd like to hear arguments against hiding the internal units
from the user. DataCAD behaves in this manner and it is nice knowing
that everything is always in real scale. Never had a problem with
multiple input methods creating rounding errors either.


-- 
Steve Hall  [ digitect@xxxxxxxxxxxxxx ]



Other related posts: