---

Hallo,

hat sich mal jemand intensiver mit mit diesem Thema auseinandergesetzt? Würde mich gerne etwas austauschen über dieses Thema! Eventuell ist jemandem etwas aufgefallen, was ich übersehen habe.
Gerne auch über ObjARX Programmierung von FDO, wobei mir das net so ganz liegt.

Wenn Interesse besteht, könnte ich mal das posten, was ich bisher zu FDO zusammentragen konnte.

Gruß TP

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Guten morgen BloodyMess,

gerne würde ich dir helfen, gib doch mal ein was du schon weißt, vielleicht finden wir da eine Lösung. Denn vielleicht finden wir zusammen was heraus.

CU Norbert

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Norbert,

gerne schreibe ich hier rein, was ich bis jetzt habe.

Also FDO (Feature Data Objects), implementiert im neuen Autocad MAP. Seh es als Verbesserung zu OSE mit mehr Freiheiten und Möglichkeiten. Der gravierendste Unterschied ist, dass OSE direkt an Oracle angebunden wird und FDO, über einen eigenen Provider, theoretisch in jede Datenbank schreiben könnte, welche Geometrien aufnehmen kann. Bisher kenne ich nur den mit ausgelieferten Oracle Provider.

Eine weitere Verbesserung ist, dass man in FDO nachträglich noch die Elementtabellen, welche im Admin angelegt werden, umbiegen kann. Heisst das ich in der Lage bin noch zusätzlich Layer mit im Element aufzunehmen oder auch rausschmeissen kann um die Übersicht zu verfeinern.

Anlegen eines DataStores
------------------------
1. Als Superuser anmelden ( MAPLOGIN: superuser/SUPERUSER )
2. FDOSYSADMIN aufrufen und DataSource/Name/PW eingeben nun kann man mit 1 einen DataStore erzeugen (alles was man nicht braucht oder nicht weiss mit 'ENTER' bestätigen) und mit 5 einen dazugehörigen USER erstellen
bisher habe ich das DataStore und den User immer gleich benannt, da es so im Moment für mich übersichtlicher ist, man kann aber den User auch anders benennen und mit diesem dann auf das DataStroe zugreifen. mit 0 rausgehen
3. MAPFDOADMIN Verbindung zum DataStore herstellen, wenn man beim ersten Versuch eine Verbindung zum DataStore aufbaut und die Checkbox 'DataStore validieren' anklickt, kommt ein Fehler, danach nie wieder ... Warum??? (muss es erst eingerichtet sein um es validieren zu können?)
Um einen DataStore einrichten zu können, MÜSSEN die Elemente, welche exportiert werden sollen geladen sein. Sprich eine Zeichnung mit den zu exportierenden Elementen sollte geöffnet sein. Man kann auch im nachhinein den DataStore noch erweitern.
Nun auf einen leeren Eintrag unter 'Layer' klicken und rechts dann auf die drei Punkte. Es erscheint ein Menu, in der alle Layer der Zeichnung enthalten sind. Mit Shift+Klick oder Strg+Klick ist eine Auswahl mehrerer Layer möglich!!! Dem Element noch einen Namen zugewiesen und nun können die Attribute zugewiesen werden. Attribute sind nur Datenbankverbindungen von Elementen, Attributdaten von Blöcken und Objektdaten. Wenn keine vorhanden sind, dann werden auch keine angezeigt. Primäre Attribute werden in der Tabelle des Elementes mit abgespeichert, wobei sekundäre Elemente in einer extra Tabelle des Schemas landen. Ganz klar bringt das speichern der Attribute in der primären Tabelle einen Geschwindigkeitsvorteil, besonders beim importieren.
OK, nun noch die 'Metatabellen speichern', 'Grenzen aktualisieren' und einen 'Spatial-Index erstellen' und fertig ist man hier.

Nun kann man auch schon die ersten Elemente exportieren und importieren.

Abfragen
--------
Ganz klar ausbaufähig - eine Kombobox mit tausend Abfragen, nicht gerade übersichtlich. Abfragen speichern scheint in der deutschen Version nicht zu gehen, in der englischen aber schon ( BUG??? ). Der 'Filter' in den Abfragen ist/war für mich etwas gewöhnungsbedürftig. Ein gültiger Filter wäre 'Farbe<>2' nicht wie in der Hilfe beschrieben 'AcadColor=256'. Wir sind im deutschen Acad!

Sperren setzen
--------------
Das find ich nen bissle ungeschickt gemacht, da jeder User einmal angemeldet sein muss, der mit diesem DataStore arbeitet um in ihn in die Sperre aufnehmen zu können. Auch ist es nicht gerade von Vorteil, wenn man an zwei Rechnern mit dem selben Usernamen angemeldet ist und an dem selben Zeichenelement rummfummelt, dann wird die Sperre nicht aktiv, sonst funktioniert sie aber sehr zuverlässig.

Blöcke
------
Exportiert man Blöcke in einen DataStore und möchte diese dann wieder in eine leere Zeichnung einlesen, meckert Acad rum, das dieser Block nicht vorhanden sei. Gespeichert wird allerdings der Name des Blockes, sodass dieser vorher in die Zeichnung eingefügt werden sollte, damit er auch gesetzt werden kann. Man könnte ihn auch über die .dwt mit reinladen, das geht auch.
Eine andere Möglichkeit wäre hierbei allerdings ein ObjARX-Beispiel, welches einen Block als DXF im DataStore mit abspeichert und hier bräuchte ich Hilfe, da irgendetwas nicht ganz hinhaut. Ich bekomme ihn zwar über das Beispiel reingelesen - eine neue Tablle wird erstellt, ich glaube 'SampleBlock', da stehen dann auch eine ganze Menge an Infos drinnen, weiß aber nicht wie ich ihn da wieder rausbekomme. Kann gut sein, das es an meinem Compiler liegt, wenn das mal jemand ausprobieren könnte, wäre ich sehr dankbar! In der ReadMe wird auch nur beschrieben, wie man den Block in den DataStore bekommt, nicht aber wie sie sich das vorstellen, das er wieder geladen werden soll.

sonstiges
---------
Probleme habe ich bei der Performance des ganzen, weiß nicht woran es hängt. FDO ist einfach mal zu langsam. Export(81sec) Import(14sec) bei 8000 Elementen. Und OSE ist nur minimal langsamer. Warum sollte jemand eine neue  Technolgie auf den Markt werfen, die nicht viel schneller ist als die Alte, vielleicht könnt ihr das mal probieren und Zahlen zum Vergleich liefern!

Im Netz ist über FDO auch noch nichts zu finden - oder doch?

Das ist ein grober Umriß, von dem was ich bisher hab, wenn mir noch etwas wesentliches auffällt, was ich vergessen habe oder ich noch was finde werde ich es hier posten.

Vielleicht hilft es ja dem Einen oder Anderen und wenn dazu noch ein paar Anmerkungen kommen würden, dann wäre mir das sehr lieb.

Viele Grüße TP

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo,

ist das Thema zu uninteressant oder will/kann sich keiner damit beschäftigen? Gibt es bessere Alternativen, welche es kostenlos von Drittanbietern gibt?

Noch eine Ergänzung zu oben, man kann keine Elemente von Layern exportieren, die gefroren sind.
Ist ein Layer allerdings ausgeschalten, lassen sich die Elemente darauf zwar exportieren, aber der Layer wird beim import dieser Daten dann angschalten.
Die Farbe des Layers lässt sich ebenso nicht im DataStore speichern.

Gruß TP

------------------

Code:

---

For Each Person In This.Forum
    TP.Say "have a nice day!"
Next Person

---

[Diese Nachricht wurde von BloodyMess am 08. Sep. 2004 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Norbert,

will ja net drängeln, aber was ist denn nun mit deinem Angebot?

Zitat:

---

.. Denn vielleicht finden wir zusammen was heraus. ..

---

Wäre für mich schon sehr wichtig, wenn das auch mal jemand probieren könnte, wie sieht es denn mit dem Moderator hier im Forum aus?

auf replay hoffender TP

------------------

Code:

---

For Each Person In This.Forum
    TP.Say "have a nice day!"
Next Person

---

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo BloodyMess,

entschuldige, daß ich momentan ein wenig mit Abwesenheit glänze. Leider muß ich auch zugeben, daß ich mich nur sehr beschränkt mit diesem Thema beschäftigt habe.
Bei Autodesk selbst findet man auch nicht viel und auf der Schulung wurde nicht viel darüber erzählt (ausser, daß es das gibt...)
Ich schau mirs heute mal an - kann aber nicht viel versprechen.

Viele Grüße
Heike

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo,

also langsam geht es vorwärts .. 

Der FDO Client und der Provider sind im Moment als Release 1 in Acad implementiert. Es wird daran weiterentwickelt! Die PerformanceProbleme scheinen Autodesk bekannt zu sein. Zumindest, warum es aller 4000 Elemente, die man nach FDO exportieren möchte, hängt. Das liegt an dem Cache, der in FDO eingestellt ist. Der User kann im Moment an dieser Schraube nicht drehen, aber das wird sich ändern.

Was mich schon immer gestört hat in der Datenbank, ist das es Spalten und Tabellen gibt, welche nie befüllt werden. Alles was mit LT* oder F_LT* beginnt. Autodesk hat da schon wieder etwas weitergedacht ... es sind 'Long Transaction' Tabellen. Diese Tabellen werden jetzt noch nicht unterstützt, werden aber schon mit angelegt. Damit sollen wohl irgendwelche 'was ist wenn' Aktionen erledigt werden können. Was das genau sein soll und wofür man sowas brauchen könnte, ist mir noch unklar.

Und wie siehtŽs bei Euch aus ..  .. ?

Schönes WE .. Gruß TP

------------------

Code:

---

For Each Person In This.Forum
    TP.Say "have a nice day!"
Next Person

---

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo,

ich hoffe es nützt wenigstens irgendwann mal jemanden, was ich hier zu FDO zusammentrage.

Ich weiß das es langsam nervt, aber hat es denn nun mal jemand ausprobiert???

Die Eigenschaften der Layer kann man nicht exportieren. Es ist so gewollt von Autodesk. Es wird vom User erwartet, dass er alle Layer mit den jeweiligen Eigenschaften als DWT in seiner AutoCADsitzung startet. Hängt wohl mit anderen GIS Systemen zusammen, die andere Layereigenschaften speichern könnten und dazu soll das DataStore ja kompatibel sein.

Zeichenreihenfolgen werden im Moment noch nicht unterstützt, aber es kommt in einer der nächsten Releases.

Im Moment gibt es den FDO Client wohl als Alpha Release in der zweiten Version. Sie tüddeln also dran.

Noch eine Frage in eigener Sache es gibt keine expliziten Beziehungen zwischen den Tabellen im Datastore. Vielleicht hat dazu ja jemand von Euch ein paar Gedanken. Hab wo anders schon gepostet, aber jeder sagt mir, das es ohne Beziehungen keinen Sinn macht - was ich ja genauso sehe, aber es muss ja einen Sinn ergeben, wenn man die Organisation der Beziehungen auf Programmebene macht. WürdŽs halt gern verstehen und Autodesk .. naja, da kommt leider net viel.

Schönen Abend und Gruß TP

------------------

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo,

FDO macht langsam Sinn, zumindest für mich, wenn man weiß wie Autodesk sich das denkt.
Man muss das nur mal aus einer anderen Sicht betrachten. Wenn man sich mal von der alt hergebrachten Vorstellung trennt, das jedes Element seine Eigenschaften angehangen hat und diese immer mit sich rumschleppt. Die reduziert auf die Geometrie - dann bleibt ein Element, welches einfach nur weiß, dass es eine Linie mit Start und Ende ist. Das ist ja auch das worauf OpenGIS ein Element beschränkt. Dann liegt diese Linie in einer Zeichnung einfach nur noch irgendwo mit anderen Elementen auf einem Layer. Also mehrere Geometrien, gruppiert auf Layern. Alle sehen gleich aus. Aber wir sind ja verwöhnt und wollen alles schön haben, sonst läßt sich ja nix verkaufen ..  .. deshalb gibt es in MAP 2005 den Darstellungsmanager .. der nimmt uns diese Arbeit ab. In dem beschriebenen Fall kann man global seine Elementen differenzieren und verschiedene Eigenschaften zuweisen und diese nach belieben ändern. Man kann geschlossenen Polygonen Schraffuren zuweisen, die zur Laufzeit erzeugt werden und es ist nicht mehr notwendig komplexe Objekte zu erzeugen. Das heißt, man kann seine Zeichnung auf Punkte, Texte und Polylinien reduzieren und kann über den Darstellungsmanager die Visualisierung regeln. Tolle Sache .. kann den Darstellungsmanager nur empfehlen.
Es ist nur ärgerlich, das man die Elementklassifizierung nicht mit speichern kann, weil das ist auch ein echt tolles Feature das ich sehr mag.

Zu den Long Transactions nochmal zu kommen. Es gibt da ein verständliches Beispiel. Hab das mal in eigene Worte gefaßt...
Man unterscheidet in einem GIS System zwischen ’short transactions’ und ’long transactions’. Ein einfaches Beispiel für kurze Transaktionen sind das Setzen von Sperren oder das Einfügen von Daten in die Datenbank. Dem gegenüber stehen lange Transaktionen, wobei das Beispiel eines Banktransfers dies sehr anschaulich erläutert. Bucht man von einem Konto Geld ab und transferiert dies auf ein anderes, sollte in der Regel das Geld dort auch verbucht werden (Abbuchen - Kontostand neu berechnen - auf anderem Konto zubuchen - Kontostand neu berechnen ... wahrscheinlich gibtŽs noch tausend andere Sachen die noch erledigt werden). Kann aber aus nicht vorhersehbaren Gründen, der gesamte Prozess (Long Transaction), welcher aus mehreren kleinen Aktionen besteht, nicht stattfinden, muss dieser wieder rückgängig gemacht werden. Eine Datenbank ist allerdings nur in der Lage kurze Transaktionen durch einen Rollback wieder herzustellen. Dafür sind die Tabellen LT* vorgesehen. Die API von FDO entscheidet dann, was zu geschehen hat. Es kann auch eine Aktion zeitweilig zurückgestellt werden und schon wird aus einer ST eine LT.
....
Erst wenn eine Transaktion commited wurde, also die Änderungen in die Datenbank gespeichert wurden, sind die Änderungen für andere Benutzer sichtbar. Greift ein zweiter Prozess während einer Transaktion auf die Daten zu, muss dem Prozess gesagt werden, dass hier eine Transaktion läuft und dieser zu warten hat, bis die laufende Transaktion erfolgreich abgeschlossen wurde oder der alte Zustand wieder hergestellt ist. Long Transactions sind Bestandteil eines jeden GIS!

Schönes WE und Gruß TP

------------------

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP