[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 14:27:26 -0500
# The following was supposedly scribed by
# Bruno Postle
# on Thursday 19 August 2004 12:30 pm:
>> > =A0 The problem this raises is that it isn't 'normalised' in a
>> > =A0 database sense - What do you do with objects that refer to
>> > =A0 non-existing layers? =A0How do you rename a layer?
>>
>> How about using a 'name:' attribute in the layer entity? =A0The
>> geometric entities then refer to a layer by ID.
>
>That's like my 'description' attribute below, the ID (and presumably
>the filename also) should be the alphanumeric "name" of the layer:
Okay, but let's keep the ID numeric (as in: "the index in a list") and the=
=20
name textual.
The "description:" attribute that you are using here would not be supported=
in=20
most cad formats (and there would likely not be any place that it could be=
=20
preserved across and out->changed->in conversion.)
>> > =A0 =A0 ID: doors
>> > =A0 =A0 description: All the doors in my house
However, if you are going to connect an app to this hub, the hub is obliged=
to=20
support this element. So, the "description:" attribute would get dropped o=
n=20
some conversions, but I'm not saying that it can't exist.
With that said, we are still going to have to have a "name:" attribute (whi=
ch=20
will appear as the layer name in autocad, pythoncad, etc.) And, to be able=
=20
to rename layers without messing with the entities, we must use a numeric I=
D=20
for the layer (which, yes, is related to the layer filename) where that=20
numeric ID is stored in each entity.
The following are excerpts from the new styles2 directory on the examples=20
page.
Layer entity: layer.12.yml
--- #YAML:1.0
ID: 12
type: layer
name: doors
description: "All of the doors in my house."
thawed: 0
on: 1
parent: TopLevel
Geometry entity: geometry.6.yml
--- #YAML:1.0
ID: 6
closed: 0
color: '#ob_style'
layerID: 12
object_styleID: 0
linetype: '#ob_style'
points:
-
- 5.32543038982901
- 2.3611759300481
-
- 11.7757423601274
- -1.84952186448125
-
- 17.6779886045815
- 1.26639449326849
type: polyline
I'm also experimenting with taking these concepts further. But, I'm hoping=
=20
that this stops in some way before it gets out of hand:)
I think we need to establish a metric for this hub. Is it driven by the du=
mb=20
tool or the smart one? If it's the dumb tool, where does the layer entity=
=20
fit into the picture? (it's another file to be opened to find information)
Again, right now I'm just looking for balance. (also see: "hub-is-a-node=20
principle")
Looking at points as if they were layers might give us some insight. =20
Pythoncad uses a points table to track the points of all of the entities. =
=20
Why don't we have points objects (not the marks that are currently typed as=
=20
'points) and just have a list of pointIDs inside each object? If you do=20
this, it becomes dirt simple to move everything in a drawing, but much more=
=20
complicated to move one entity (especially if it shares a point with=20
another!) or to find entities based on their location (or (egad!) extents.)
=2D-Eric
=2D-=20
"The genius of you Americans is that you never make clear-cut=20
stupid moves, only complicated stupid moves which make us=20
wonder at the possibility that there may be something to them=20
which we are missing."=20
--Gamal Abdel Nasser
Other related posts:
