[cad-linux-dev] Re: uber-converter layers and styles
- From: Eric Wilhelm <ewilhelm@xxxxxxxxxxxxx>
- To: CAD linux development <cad-linux-dev@xxxxxxxxxxxxx>
- Date: Thu, 19 Aug 2004 10:36:55 -0500
# The following was supposedly scribed by
# Bruno Postle
# on Thursday 19 August 2004 08:53 am:
> The disadvantage is that it would
> be impossible to have empty layers or default colours/linetypes
> for particular layers. Also, how do you rename a layer globally?
NOTE: layers will not have default colors/linetypes/lineweights in the hub
database model. See the irc log for why. Pythoncad has a thing called
"layer", but also has a thing called a "style". In our discussion, we
determined that autocad was the more minimalist approach and that autocad
layer properties involving style have to be broken out of the layer object.
>2. Specify the layer of each element as an attribute and have a
> separate "layer" type of element that describes each layer.
Right, this is the current aim.
> The problem this raises is that it isn't 'normalised' in a
> database sense - What do you do with objects that refer to
> non-existing layers? How do you rename a layer?
How about using a 'name:' attribute in the layer entity? The geometric
entities then refer to a layer by ID.
>3. Specify the layer of all elements in the "layer" element itself
> and get rid of the 'layer' attribute altogether.
>
> A 'layer' element might look like this:
>
> --- #YAML:1.0
> ID: doors
> description: All the doors in my house
Again, there will be no colors and linetypes in the hub's layer entities.
> color: '#990000'
> linetype: solid
> elements:
> - 5.yml
> - 7.yml
> - 13.yml
> - 15.yml
I'm not sure about the elements list. In designing these data structures, I
always try to think in terms of partial loads (where only some entities are
loaded into the program.) But, I also like code to be as dumb as possible.
If I want to load all of the objects on a layer, I have to find the layer
entity and read the list of objects from it. In that situation, your above
suggestion makes things faster.
But, if I want to load all of the lines, then what? I can't open a "these are
lines" list, so my partial-load algorithm has to change here.
So, I refer back to the reason that lines are given equal importance to
circles in the flat structure. The layer property should be next to the type
property (which is next to the style property, and so forth.) Linetypes do
not contain objects, colors do not contain objects, etc. and therefore layers
do not contain objects.
> The disadvantage it that there is no way to prevent an element
> appearing in two layers simultaneously - Actually I'd quite like
> this functionality and there are probably CAD systems in
> existence that *do* allow elements in multiple layers.
I'm not sure if this would be a good thing or not. Note also that the layerID
attribute of each entity under model #2 could in fact be a list.
However, since layers are primarily used for visibility control, how would
this work? Layers can be on/off or frozen/thawed. If an entity is on three
layers which are "on, off, on" and "thawed, thawed, thawed", is it visible?
e.g. does one on mean on or does one off mean off? Either way, you are
putting yourself in the trap of looking for all of the layers to make the
entity visible or else to hide it ("now where's that sneaky second layer...")
Maybe this is better solved through parent layers.
Furthermore, with the below points in mind, isn't this the same as saying that
an entity can have multiple styles (some kind of boolean linetype operation?)
>I would lean towards using (3) for layers and (2) for named colours
>and linetypes.
When you look at the implications of keeping geometric entities in the same
(flat) structure, doesn't this preclude the use of different structures for
each kind of logical-property element? Consider the benefits of using the
same methods for layers, object styles, text styles, point styles, etc. They
all have properties of their own and are somehow connected to a set of
entities.
--Eric
--
"It is impossible to make anything foolproof because fools are so ingenious."
--Murphy's Second Corollary
Other related posts:
