地鐵線路輔助繪圖設計---不做簡單的畫圖師

輔助繪圖工具的方案選擇過程是復雜的，從去年8月底就開始了初步的調用，也經過了種種碰壁，最終得出了基本的方案。

先說一些題外話：為什么需要輔助繪圖設計？加班的龐大工作量來自于哪里？

單位目前主營業務是地鐵信號系統工程總承包，包括地鐵新建及改造項目工程管理、系統設計、產品研發、系統集成、測試驗證等一整套解決方案和服務。未來的集成方案規劃為中心、地面、車載。不管哪個子系統都不可避免的需要設計繪圖工作，由繪圖生成各個子系統的元數據，根據這些元數據進行代碼的數據配置工作。不同的城市不同的線路分別進行不同的設計繪圖、數據生成、數據配置等等工作，由此可想象到里面的工作量。然而這種加班并沒有創造新的價值也沒有帶來新的利潤。

企業在未來要想更好的生存，就必須贏得更多的利潤，更少的加班成本。這樣一個良好的輔助繪圖工具設計，一個優秀的數據配置設計的需求就非常的強烈。開發更好用的設計、繪圖軟件，需求一變操作軟件馬上可以把成果弄出來。

話說輔助繪圖輔助數據配置工具如何設計呢？

輔助繪圖的關鍵在于：設計數據-圖元映射關系，因此所作的方案調研之中該方向就是核心訴求。最終的方案趨向于基于objectArx的二次開發。

基于objectArx的二次開發，該類庫為C#專用類庫。ObjectARX直接訪問AutoCAD的數據庫結構、圖形系統以及AutoCAD幾何構造核心，因此在運行期間能實時拓展CAD功能，也能復用CAD固有的命令來開發新命令。CaD數據庫的核心是BlockTable，BlockTable和所有Block具有一一映射關系。BlockTable此表含有兩個非常重要的記錄：模型空間和圖紙空間，所有的實體(可見對象)均放于塊表AcDbBlockTable中。

其它的設計方案并不具有如此完備的數據-圖元映射關系，所以在圖元生成數據和數據反向生成圖元方面先天不具備優勢。

Autolisp和VBA是初期的二次開發方案，因為不具備完備的面向對象特性而逐漸淘汰。
基于SDK類庫的C++語言開發并未進入主流方案，其主要原因可能是因為二者的兼容性問題，雖然C++在面向對象方面較為強大，但是和ObjecArx在操控各種blocktable方面開發效率不高，所以時至今日也未能進入主流。

其它的繪圖工具，僅僅就是繪圖工具，反向生成圖元不能說不可行而是得不償失地需要進行大量的圖元設計和數據設計工作。

ObjectArx能夠直接訪問CAD的圖形數據庫BLockTable的特性，使得通過ObjectARX類庫二次開發能夠獲得BlockTable與Block的強映射關系，這種強映射關系正好滿足了輔助繪圖工具的需求。

一副CAD圖形就是一個包含有多個表的數據庫，它規定了9個符號表，具體如下：

而網上對ObjectARX的學習資料少之又少，學起來是一個相當困難的挑戰，但是只要功夫深，鐵杵磨成針。