Przechowywanie danych (nierysunkowych) w rysunku

[kojacek]

Ja tam sobie myślę, że nie ma co się unosić - póki gadamy to się dogadujemy :)

@perlon - gwoli sprostowania: Nie stosuję tutaj XDATA. XDATA to dane dodatkowe, tutaj mówimy o danych niegraficznych. XDATA rzeczywiście są wykorzystywane, ale  w wątku obok (http://forum.cad.info.pl/topic/1114-wymiar-z-dodan%C4%85-sta%C5%82%C4%85-warto%C5%9Bci%C4%85/page-3#entry6547) dotyczącym wymiarów "skażonych". Na marginesie, tutejszy wątek "wyrósł" z tamtego. Ponadto pozwolę sobie zauważyć - dogadywanie się tam laików, zaowocowało całkiem zgrabnym narzędziem, mam nadzieję przydatnym.

Kto wie, może tutaj też się coś zrobi?

Edytowane 24 Czerwca 2014 przez kojacek

[perlon]

OK faktycznie zamiast XDATA powinienem wpisać XRECORD. Dla usera w zasadzie i tak to jest czarna skrzynka do której coś wrzuca i potem z niej coś wyciąga. Potrzebuje do tego klucza (jakiegoś programu obsługującego wejście/wyjście). W przypadku atrybutów może użyć wytrycha (edycja atrybutów narzędziami standardowymi) żeby podłubać wewnątrz czarnej skrzynki, ale żeby dostać jakieś sensowne wyniki i tak potrzebny jest oryginalny klucz a nie wytrych :D

[Martin_S]

Teraz rozumiem to o kluczu i wytrychu :D , ale tzw. "kuchni" jak to robi się/robicie ni czorta nie jarze :) ale chociaż algorytmami i plikami DWG wspieram rozwój nakładki e-cad - programisci to obrabiają i użytkownicy e-cad mogą z nowinek korzystać - a patche są darmowe. Coś w stylu open source. Ja na tym tez korzystam, bo są dodatkowe narzędzia np. do żelbetu i nie tylko, które ułatwiają kreślenie CAD.

Edytowane 24 Czerwca 2014 przez Martin_S

[kojacek]

No ale cała ta dyskusja wynika z tego że można coś ułatwić. W mojej opinii (i tu widzę też podobne głosy), całe to zestawienie, opisy stolarki (i co tam tego tyczy dookoła) można zrobić nieco inaczej, ale za to w konsekwencji, w sposób bardziej uporządkowany i logiczny. Przecież nie upieram się żem alfa i omega, niemniej kilka rzeczy można ulepszyć, zdejmując z użytkownika potrzeby weryfikowania, sprawdzania i korygowania błędów, jeśli wystąpią. 

Przy czym, z mojej strony, nie jest to jakieś wielkie programowanie, jeno hobbystyczne zastosowanie LISP-a.

[Martin_S]

Mam pytanko teraz takie, czy na obecnej wersji jest też możliwe zaprogramowanie czegoś takiego ulepszając polecenie S41_LJQM

 

Źródłem jest ścieżka (Polilinia, polilinia3D, linia )   przekrój: dowolny kształt,  obrys    ... domyslam sie, że diabeł tkwi właśnie w ogarnięciu geometrii 3D na poczatku i końcu ściezki.

Edytowane 25 Czerwca 2014 przez Martin_S

[perlon]

Obawiam się że to nie takie proste. Zapis obiektu typu PathSurface wygląda mniej więcej tak :

((-1 . <Entity name: 7ed78798>) (0 . "SWR_CURVEMESH") (330 . <Entity name: 
7ed76c10>) (5 . "273") (100 . "AcDbEntity") (67 . 0) (410 . "Model") (8 . "0") 
(100 . "SwrBaseEntity") (46 . 0.0) (47 . 100.0) (68 . 0) (69 . 0) (100 . 
"SwrPolyPathEnt") (375 . 1) (376 . 0) (100 . "SwrCurveMesh") (12 11399.2 
5786.87 0.0) (70 . 0) (71 . 0) (72 . 0) (210 0.0 0.0 1.0) (10 115705.0 10053.7 
11102.6) (50 . 0.0) (10 33514.1 -66699.7 11102.6) (50 . 0.0) (11 19941.3 
-10101.0 0.0) (51 . 0.0) (11 19941.3 11102.6 0.0) (51 . 0.0) (11 166.063 
11102.6 0.0) (51 . 0.0) (11 166.063 3109.24 0.0) (51 . 0.0) (11 8831.61 3109.24 
0.0) (51 . 0.0) (11 8831.61 7562.04 0.0) (51 . 0.0) (11 12386.7 7562.04 0.0) 
(51 . 0.0) (11 12386.7 2455.7 0.0) (51 . 0.0) (11 19941.3 -10101.0 0.0) (51 . 
0.0))

Zwykła linia tak

((-1 . <Entity name: 7ed787b8>) (0 . "LINE") (330 . <Entity name: 7ed76c10>) (5 
. "277") (100 . "AcDbEntity") (67 . 0) (410 . "Model") (8 . "0") (100 . 
"AcDbLine") (10 38035.6 101590.0 0.0) (11 160575.0 79701.6 0.0) (210 0.0 0.0 
1.0))

a solidowy prostopadłościan tak

{rn {mf {hh |") (1 . ",+->687+r<*-): {rn rn {rn rlhhggqfijmghjfkghk 
nnlhooqifjmmmmfihg flmjfqkgflmhkmhmll rn o o V V |") (1 . "<0:;8: {rn rn {rn 
{lo {km {lm {in -:):-,:; {nm {rn |") (1 . "):-+:' {rn rn {rn {jl {hg |") (1 . 
",+->687+r<*-): {rn rn {rn rlhhggqfijmghjfkghk kifjgqigohomhlmll 
flmjfqkgflmhkmhmll n o o V V |") (1 . ":;8: {rn rn {rn {lj rkiimfqhkkiilhnlini 
{jo kiimfqhkkiilhnlini {lm {hf 90-(>-; _h *1410(1 |") (1 . ":;8: {rn rn {rn {li 
rkiimfqhkkiilhnlini {kf kiimfqhkkiilhnlini {ll {go 90-(>-; _h *1410(1 |") (1 . 
"/061+ {rn rn {rn rlmogjqgjomomllnlil kifjgqigohomhlmll flmjfqkgflmhkmhmll |") 
(1 . "/061+ {rn rn {rn rlmogjqgjomomllnlil nnlhooqifjmmmmfihg 
flmjfqkgflmhkmhmll |") (1 . "/3>1:r,*-9><: {rn rn {rn rlmogjqgjomomllnlil 
golmfqighfimjnkjjm kiimfqhkkiilhnlini rn o o o o n 90-(>-;@) V V V V |") (1 . 
"<0:;8: {rn rn {rn {kl {kn {kj {ho -:):-,:; {mo {rn |") (1 . ":;8: {rn rn {rn 
{ji rkiimfqhkkiilhnlini {hm kiimfqhkkiilhnlini {jj {gn 90-(>-; _h *1410(1 |") 
(1 . "):-+:' {rn rn {rn {ho {gm |") (1 . ",+->687+r<*-): {rn rn {rn 
rklkfmqogolhmgjglgj kifjgqigohomhlmll kiimfqhkkiilhnlini o o rn V V |") (1 . 
":;8: {rn rn {rn {ig rlllhnqoohmjfhgmmmm {hm lllhnqoohmjfhgmmmf {ii {gl 90-(>-; 
_h *1410(1 |") (1 . ",+->687+r<*-): {rn rn {rn rlhhggqfijmghjfkghk 
kifjgqigohomhlmll o rn o o V V |") (1 . "):-+:' {rn rn {rn {kg {gk |") (1 . 
",+->687+r<*-): {rn rn {rn rlhhggqfijmghjfkghk nnlhooqifjmmmmfihg o n o o V V 
|") (1 . "/061+ {rn rn {rn rlmogjqgjomomllnlil nnlhooqifjmmmmfihg o |") (1 . 
"/061+ {rn rn {rn rlmogjqgjomomllnlil kifjgqigohomhlmll o |") (1 . 
",+->687+r<*-): {rn rn {rn rklkfmqogolhmgjglgj golmfqighfimjnkjjm 
flmjfqkgflmhkmhmll o rn o V V |") (1 . "/061+ {rn rn {rn rklkfmqogolhmgjglgj 
nnlhooqifjmmmmfihg flmjfqkgflmhkmhmll |") (1 . "/061+ {rn rn {rn 
rklkfmqogolhmgjglgj kifjgqigohomhlmll flmjfqkgflmhkmhmll |") (1 . 
",+->687+r<*-): {rn rn {rn rlmogjqgjomomllnlil kifjgqigohomhlmll 
kiimfqhkkiilhnlini o o rn V V |") (1 . ",+->687+r<*-): {rn rn {rn 
rlmogjqgjomomllnlil nnlhooqifjmmmmfihg kiimfqhkkiilhnlini o o rn V V |") (1 . 
",+->687+r<*-): {rn rn {rn rklkfmqogolhmgjglgj nnlhooqifjmmmmfihg 
kiimfqhkkiilhnlini o o rn V V |") (1 . "/061+ {rn rn {rn rklkfmqogolhmgjglgj 
kifjgqigohomhlmll o |") (1 . ",+->687+r<*-): {rn rn {rn rklkfmqogolhmgjglgj 
golmfqighfimjnkjjm o o n o V V |") (1 . "/061+ {rn rn {rn rklkfmqogolhmgjglgj 
nnlhooqifjmmmmfihg o |") (290 . 0) (2 . 
"{00000000-0000-0000-0000-000000000000}") (100 . "AcDb3dSolid") (350 . <Entity 
name: 0>))) (1 . "<0:;8: {rn rn {rn {mj {nh {jg {in 90-(>-; {lk {rn |") (1 . 
"<0:;8: {rn rn {rn {nh {mj {jk {im -:):-,:; {lk {rn |") (1 . "300/ {rn rn {rn 
{rn {lm {lg |") (1 . "):-+:' {rn rn {rn {ng {il |") (1 . "):-+:' {rn rn {rn {ng 
{ik |") (1 . ",+->687+r<*-): {rn rn {rn rlmogjqgjomomllnlil golmfqighfimjnkjjm 
flmjfqkgflmhkmhmll o n o V V |") (1 . "9><: {rn rn {rn {rn {lk {m {rn {ij 
-:):-,:; ,6183: |") (1 . "300/ {rn rn {rn {rn {jk {nf |") (1 . "/3>1:r,*-9><: 
{rn rn {rn rlhhggqfijmghjfkghk nnlhooqifjmmmmfihg kiimfqhkkiilhnlini o rn o o o 
rn 90-(>-;@) V V V V |") (1 . "<0:;8: {rn rn {rn {ii {jm {jj {ih 90-(>-; {mo 
{rn |") (1 . "<0:;8: {rn rn {rn {jg {mm {ml {ki -:):-,:; {nm {rn |") (1 . 
"<0:;8: {rn rn {rn {jm {ii {mm {kk -:):-,:; {mo {rn |") (1 . ":;8: {rn rn {rn 
{jf rkiimfqhkkiilhnlini {ig kiimfqhkkiilhnlini {kl {if 90-(>-; _h *1410(1 |") 
(1 . "<0:;8: {rn rn {rn {mk {ml {ii {ho 90-(>-; {g {rn |") (1 . ":;8: {rn rn 
{rn {jo rjholqnnjogjmiljnn {ig jholqnnjogjmiljnn {km {hn 90-(>-; _h *1410(1 |") 
(1 . "<0:;8: {rn rn {rn {jj {jk {mk {kg -:):-,:; {lf {rn |") (1 . ":;8: {rn rn 
{rn {hm rjholqnnjogjmiljnn {kf jholqnnjogjmiljnn {kh {hl 90-(>-; _h *1410(1 |") 
(1 . "):-+:' {rn rn {rn {mi {hk |") (1 . "):-+:' {rn rn {rn {in {hj |") (1 . 
",+->687+r<*-): {rn rn {rn rlmogjqgjomomllnlil golmfqighfimjnkjjm o o rn o V V 
|") (1 . "<0:;8: {rn rn {rn {kn {kl {mh {jl -:):-,:; {mo {rn |") (1 . ":;8: {rn 
rn {rn {ji rlllhnqoohmjfhgmmmf {jf lllhnqoohmjfhgmmmm {jm {hi 90-(>-; _h 
*1410(1 |") (1 . "<0:;8: {rn rn {rn {kh {mg {ll {im 90-(>-; {lf {rn |") (1 . 
"<0:;8: {rn rn {rn {mg {kh {kn {ih -:):-,:; {lf {rn |") (1 . "):-+:' {rn rn

Oczywiście dane o solidach są szyfrowane ale i tak powyższe pokazuje jak skomplikowane w zapisie są obiekty typu solid. W porównaniu do nich PathSurface bliżej jest do linii niż do solida. Kolejna sprawa. Skoro obiekt wymaga przekroju prostopadłego do kierunku ścieżki i początkowy odcinek musi być odcinkiem prostym to z założenia taki obiekt nie może mieć płaszczyzny czołowej inaczej jak tylko prostopadle do kierunku początkowego ścieżki. IMHO nie doczekasz się takiej funkcjonalności na bazie PathSurface.

[Martin_S]

A konwerter obiektu - Bryła powierzchniowa w wyniku tej komendy PATH SURFACE konwertowana na bryłę solidową to by było możliwe?

 

Bo obróbka końcówek na tzw. połaczenia doczołowe to na bryłach solidowych jest wygodniejsza bo są narzedzia jak SLICE, wycinanie otworów tez łatwiejsze w półkach lub srodniku na solidach.

 

Poza tym dokoptowanie blachy doczołowej jako obiektu SLAB z dynamicznym otworowaniem, z tym obecnie nie ma problemu.

 

Docelowo obiekt parametryczny 3D Slab z otworowaniem po wykonaniu polecenia 3DGroup stanie sie tez solidem , wiec ma objetość czyli tez masę.

 

Mam nadzieje że uda się ZWSOFT cos pokombinować w tym kierunku, bo spojrzcie tak, dach jako obiekt sparametryzowany 3D ma okap prostopadły do płaszczyzny globalnej XY więc także nie problem by byl z okapem "normalnym" do spadku dachu, a symulacja płaszczyzny prostopadłej do płaszczyzny globalnej XY nie jest obecnie problemem

praktycznie od wersji ZWCAD ARCHITECTURE 2012 beta

 

Idę dalej, jesli bedzie możliwa taki algorytm:

 

1. modelowanie za pomocą ścieżki (zmienna #1) + przekrój (zmienna #2)

2. Obiekt dynamiczny 3D skonwertowany na solid aby dalej ulec obróce programistycznej

3. Juz nie jest dynamiczny ale bryłą sztywną, która n apodstawie wprowadzonych parametrów dodatkowych,

ulega docinaniu do formy jak na w/w grafice

 

4. moge pogodzić się z utratą zalet tzw. "żywej ścieżki" byle uzyskać element półprefabrykat do połaczeń doczołowych.

 

 

Obecnie jest możliwe tworzenie za pomocą PATH SURFACE (S41_LJQM)  obiektów dynamicznych do połaczeń doczołowych

pod warunkiem gdy ścieżki są wzgledem siebie prostopadłe + odpowiednie odsunięcie początku ścieżki obiektu #1 względem #2.

Ale to wyjatek. Przykład dawałem abstrakcyjnej stalowej pergoli z blachami doczołowymi z otworowaniami

 

Edytowane 25 Czerwca 2014 przez Martin_S

[perlon]

PathSurface->3DSOLID to byłoby dobre :good:

[Martin_S]

Jesli zostanie ogarnięta problematyka PathSurface->3DSOLID to jako element "sztywne" będą mogły by być w dalszym etapie tak zaprogramowane i sparametryzowane by uzyskać dowolny element umozliwiajacy wykonanie połaczeń doczołowych jak na w/w grafikach bez zmartwienia o kształtach ścieżek , wtedy sciezki nie będą musiały by być prostopadłe wzgl. siebie w miiejscu połączenia. No to czekamy , sprawa jest bardzo dawno temu zgłoszona

[perlon]

Nie wiem o co chodzi >> jako elementy "sztywne" << ale jak przerobisz PathSurface na 3DSolid to już nie masz obiektu sparametryzowanego. Tracisz powiązanie ze ścieżką i figurą czołową. Ot zwykła bryła do obróbki standardowymi narzędziami do solidów (slide,extrude etc).

[Martin_S]

dokładnie o to mi chodziło,  klasyczna bryła solidowa gotowa do obróbki narzedziami SLICE itp. to dla mnie bryła sztywna jako skrót myślowy. Bo obiekt PATH SURPHACE przezywam jako dynamiczna 3D (zmiana ścieżki/przekroju zmienia bryłe "online") :)

[kojacek]

Jak rozumiem - dość gładko przeszliśmy od danych niegraficznych do brył?

[Martin_S]

To efekt programowania o którym nie mam pojęcia, a efekt działania robi wrażenie :) bo widzę szerokie zastosowanie w przyszłosci takiego narzędzia do konstrukcji, a jestem swiadomy że np. ogarniecie przekształcenia bryły powierzchniowej 3DSURFACE na 3DSOLID nie jest jakimś prostym problemem, bo odwrotne działanie już jest S41_STZM

[perlon]

Jak rozumiem - dość gładko przeszliśmy od danych niegraficznych do brył?

:-) Tak jakoś zeszło. Rekapitulując. Dodatkowe dane niegraficzne to bardzo interesujący temat ale dla programistów :)

[Martin_S]

Dane niegraficzne w pewien sposób mogą imitować pseudoBIM w ramach DWG - ale biblioteki takich obiektów powinny być w programie wbudowane z mozliwością dodawanie swoich danych.

[Martin_S]

Mam takie pytanie. Bryła solidowa jest w DWG konkretnie identyfikowana przez zmienną HANDLE. np.

Command: _list 1 found

                  3DSOLID   Layer: "e-cad_stal_kontur"
                            Space: Model space
                    Handle = 404F7

 

Na podstawie tej  zmiennej czy można programistycznie wydobyć zmenną Mass z obiektu Handle = 404F7

 

np. Command: _massprop
Select objects: 1 found

Select objects:

 ---- SOLIDS ----

Mass:                    57760741.9916

 

Jeśli byłoby to możliwe wtedy moznaby tworzyć solidowe obiekty pseudoBIM w oparciu o wbudowane biblioteki profili (zmienna XDATA lub XRECORD)

z masą takiego solida w zależności co to za materiał (drewno, stal, żelbet)

 

Czyli by utworzyć daną bryłę solidową pobieramy z biblioteki konkretny profil, gęstość (drewno, stal, żelbet)

Efektem takiego narzędzia jest solidowy obiekt 3D pseudoBIM, z informacją wbudowaną co to za profil, materiał, masa

To wystarczy do późniejszego narzędzia konwertującego taki obiekt na format *.ifc z podpiętymi zmiennymi niegraficznymi (nazwa profilu, materiał, masa)

Co Wy na to ? Zajmę się tym rysunkowo-algorytmicznie :)

[kojacek]

Zwyczajnym LISP-em:

(vl-load-com)
; ------------
(defun _Get3DSolid (Hand / e)
  (if
    (and
      (setq e (handent Hand))
      (= (cdr (assoc 0 (entget e))) "3DSOLID")
    )
    (vla-get-volume (vlax-ename->vla-object e))
  )
)

Potem wywołanie:

(_Get3DSolid "404f7")

i masz.

[Martin_S]

a stosujecie własną niezależną numerację kodową danego obiektu, o której użytkownik nie musi wiedzieć a Wam programistom ułatwia "życie"?

 

np. blacha czołowa 0001, HEA300 0002, blacha czołowa 0003 - i mamy np. pozycje wysyłkową z 0001+0002+0003

 

Czy mozna w taki element wkomponować na stałe takie zmienne:

 

np.

zmienne wyświetlane na życzenie z możliwością zmiany jakimś narzędziem:

Nr Pozycji: S01 (opcja dodatkowa)

Nazwa elementu: Słup

Nazwa: IPE500

Materiał: S235JRG2

 

zmienna ukryta dla uzytkownika, którą wprowadził z okna dialogowego

Gęstość kg/m3: 7850

Masa: liczba z wyniku mnożenia Gęstość*Volume/1000 000 000

 

zmienna z solida

Volume: Objętość w mm3

Edytowane 30 Czerwca 2014 przez Martin_S

[kojacek]

Nie rozumiem formy "stosujecie" - bowiem sugeruje ona jakieś konkretne rozwiązania. Funkcjonalność o której mowa, może być realizowana na co najmniej kilka różnych sposobów. Identyfikacja obiektu - tak samo, może polegać na typowych identyfikatorach rysunkowych, jak też własnych (np. przez dowiązanie XDATA czy ExtensionDictionary). To też może determinować sposób przechowywania innych danych, np. w samym obiekcie, lub w osobnym słowniku (-ach), a jedynie "adresowanie" do niego identyfikatora obiektu. Możliwych rozwiązań jest naprawdę wiele.

[Martin_S]

Przepraszam za formę "stosujecie", miało to zapytanie byc skierowane dla bezpośrednio do programistów CAD, bo ja takiej wiedzy i umiejętności nie mam, a szkoda :hi:

[kojacek]

Nie, nie ma za co przepraszać, po prostu zabrzmiało to mocno konkretnie, zatem zapytałem :) Na marginesie moją wiedzę "programistyczną" trzeba traktować raczej amatorsko i hobby-stycznie. Wynika ona jedynie z długowiecznego obcowania ( ;) ) z CAD-em...

Edytowane 30 Czerwca 2014 przez kojacek

[Martin_S]

Nie szkodzi, ale sporo mnie to "oświeciło" i otwiera mi droge do konkretnych przemyśleń z solidami :) w kierunku na razie pseudoBIM

Edytowane 30 Czerwca 2014 przez Martin_S

[perlon]

Większość systemów zarządzających informacją ( chyba się nie pomylę twierdząc, że każda relacyjna baza danych ) opartych jest na jakimś systemie identyfikatorów. Każdy obiekt w CAD'zie  w chwili utworzenia otrzymuje unikalny i możliwy do użycia tylko raz identyfikator ( w sensie jednorazowego przypisania do jednego obiektu w trakcie życia rysunku DWG ) .

Command: (setq a (entsel))
Select object: (<Entity name: 7ffff69ef00> (328333.0 124105.0 0.0))

można jego cechy odczytać następująco (przykład):

Command: (entget (car a))
((-1 . <Entity name: 7ffff69ef00>) (0 . "LINE") (330 . <Entity name:
7ffff6db9f0>) (5 . "2F8C8") (100 . "AcDbEntity") (67 . 0) (410 . "Model") (8 .
"wymiary") (100 . "AcDbLine") (10 328332.0 121751.0 0.0) (11 328332.0 124386.0
0.0) (210 0.0 0.0 1.0))

Zwróć uwagę że identyfikator 7ffff69ef00 jest wewnętrznym oznaczeniem, którego nie zobaczysz inaczej jak metodami programistycznymi. Identyfikuje on jednoznacznie element rysunkowy. Tymi identyfikatorami zarządza silnik bazy DWG.Takiemu obiektowi można "dołożyć" dane nierysunkowe takie jak, "Nr pozycji", "Nazwa profilu", "Masa" etc. lub odczytać jego rekord definiujący jak wyżej. Nakładka na CAD'a organizująca dane obiektów może wykorzystywać numer wewnętrzny ( ten "7ffff69ef00" ) tworząc własne listy takich identyfikatorów lub dopisywać i zarządzać własnymi identyfikatorami. Przeszukując elementy z bazy DWG pod kątem występowania cech nadanych przez siebie może "wyłowić" te własne i coś z nimi zrobić. To łowienie może odbywać się po elementach graficznych ( np. konkretny atrybut w bloku ) albo po niegraficznych jak to pokazał kojacek. System identyfikacji obiektów ukryty przed userem jest mniej podatny na zewnętrzną ingerencję. Np nadanie dwóm różnym elementom tego samego numeru. W przypadku atrybutów zmieniasz narzędziem podstawowym i już. W przypadku danych niegraficznych musisz się zdać na aplikację jeżeli takowa posiada taką funkcjonalność. W szczególności możesz dopisać solidowi cechę "materiał", zrobić sobie słownik z relacjami materiał->gęstość. Na podstawie cechy "materiał" przeszukać słownik i odnaleźć odpowiednią "gęstość". Mnożąc "gęstość" przez odczytaną cechę "massprop" dostaniesz ciężar. Zwróć uwagę, że trzymanie w obiekcie cechy "ciężar" jest pozbawione sensu gdyż cecha ta musiałaby być aktualizowana równocześnie ze zmianą "massprop" lub "materiał" a tak może być wyliczana wtedy kiedy jest potrzebna. Podobnie z cechą "gęstość". Nie musi być trzymana z obiektem równolegle z z cechą "materiał", bo może się okazać że ten sam "materiał" ma różną "gęstość" w różnych elementach.

Edytowane 30 Czerwca 2014 przez perlon

[kojacek]

To jest dokładnie taka sama zabawa jak już wcześniej wspominane nieszczęsne zestawienie stolarki (atrybutyzacja vs. xrecordowanie). Właściwie nie ma różnicy czy obiekt jest dwu czy trójwymiarowy. Problemy z zarządzaniem tymi danymi będą podobne.
W mojej opinii, najbardziej optymalnym rozwiązaniem jest przypisywanie do obiektu tylko tych danych które są dla niego unikalne (idntyfikatory), lub są konieczne (vide: wymiary stolarki w szpilce). Wszelkie inne, powinny być przechowywane, albo na zewnątrz (w osobnych plikach (tekstowych xls-ach, db-ach, mbd-ach itp.)), albo jako dane niegraficzne czyli słowniki + xrecordy + itp. w rysunku. Oczywiście - w zależności od potrzeb - możliwe rozwiązania mogą być również mieszane.

Edytowane 30 Czerwca 2014 przez kojacek