[cad-linux] Re: Design methodology for an open geometric data management standard
- From: Janek Kozicki <janek_listy@xxxxx>
- To: cad-linux@xxxxxxxxxxxxx
- Date: Sun, 7 Sep 2003 23:30:50 +0200
Bruno Postle said: (by the date of Sun, 7 Sep 2003 21:18:11 +0100)
> On Sun 07-Sep-2003 at 09:47:41PM +0200, Janek Kozicki wrote:
> >
> > > > Any items not listed in a layer table would simply not have
> > > > an assigned layer.
> >
> > one thing I have doubts about:
> >
> > one object has its name placed in two places. - the file
> > describing that object, and the table of layers. I don't like it.
>
> I had doubts about this and didn't implement it. Keeping attributes
> in a separate table is just usual database normalisation - The
> question is really this:
>
> If an object is copied/moved/linked from one drawing to another,
> does it take it's attributes with it?
>
> I would say that a layer is a 'place' rather than a fundamental
> property of an object and shouldn't be carried around - Unlike the
> radius of a circle for example - The radius should by 'sticky'.
hmm.. if layer is a 'place' then maybe the top level directory of a
project should consist of directories that are layers? hmm.. no. that
prevents eg. creatng a block that consist ob objects belonging to
different layers. what we need is some kind of two-dimensional
data-storege (filesystem) perhaps some _smart_ (and very logical) use of
symliks can do that?
> Things like 'colour' or 'material' are less obvious - I suppose any
> file format should be flexible about such attributes.
same with this... but symliks are symlinked to a file with specified
name, what if we change the object name? (I assume that object's name is
reflected by filename somehow)
ext2 filesystem, (and reiserfs if I'm correct) are based on inodes,
where each inode represents a file. The inode's numer is a file in fact.
Not it's name. It's a way of indexing them. I think that we need to find
a way of multidimensional indexing files.
You asked if the attributes should be carried around with an object.
I think that the best solution is to give an option to the user. If he
wants to copy his blocks from one drawing to another while preserving
material, color and layers - it should be easy. If he wants only
geometry - it should be easy too...
just one (perhaps stupid?) thing sparked my mind. If a filename is an
attribute. And layer/color/material/whatever is an attribute, we could
store this information in a filename?
imagine object
0: 345.678
0: 9876.543
0: 0.0
Radius: 246.8
Transform: 1, 0, 0, 0, 1, 0, 0, 0, 1
Units: millimetres
placed in a filename called:
<layer>-<color>-<material>-<name...>
road-red-wood-celery-1045317918-1278-225423.circle
or better:
l#road-c#red-m#wood-celery-1045317918-1278-225423.circle
(choose any other delimeter instead of `#`, maybe `:` ?)
and then give a tool that will very easily deal with such filenames?
It will allow to strip those attributes, add different ones, change
them.. File without attributes simply does not have them. (so belong for
example to layer 0)
and then. each layer (or any other custom attribute) will become another
object.
so in file called ./road we will store all information about this layer
(color, linetype, material, width, and so on) if certain filename lacks
an attribute c# (color) then a color of that layer is used (of course).
If ceratin filename belongs to a layer that does not exist (no filename
that defines this layer) (It may happen if someone decided to copy part
of his drawing to a differnt one, and decided not to carry layer
definitions with it) - a warning should be given to the user. And a
(layer 0) will be used.
And then the user can use the aforementioned tool to strip attribute
l#(layer) from all files that use non-existing layer. Or he can create
this layer. Or even make a symlink (!) that points to another layer, and
has a correct name.
the more I think about it, the more I like the idea.
--
# Janek Kozicki
Other related posts:
