On Wed 18-Aug-2004 at 22:39 -0500, Eric Wilhelm wrote: > > One thing which I'm not certain about right now is how 'layer', > 'object_style' > and other non-geometry entities should fit in terms of hierarchy. > > While it makes sense to not divide circles from lines, what about dividing > layers from circles? And what about dividing linetypes from layers? > > In terms of data structures, lines and arcs seem to have more in common than > linetypes and layers. These are my thoughts for different ways of doing layers: 1. Specify the layer of each element as an attribute. The 'layer list' could then be constructed by looking at all the elements and adding them up. 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? 2. Specify the layer of each element as an attribute and have a separate "layer" type of element that describes each layer. 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? 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 color: '#990000' linetype: solid elements: - 5.yml - 7.yml - 13.yml - 15.yml This has the advantage of being 'normalised' - There is no way to put an element in a non-existing layer and renaming a layer is straightforward. In this system it would be possible to have a 'layerless' element, though I understand that this is exactly what 'layer 0' is on an AutoCAD system. 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 would lean towards using (3) for layers and (2) for named colours and linetypes. -- Bruno