自動構面演算法中拓撲網路建構的優化

我在《外掛程式式gis應用框架的設計與實現》一書的演算法章節介紹過基於「左轉演算法」的自動構面過程和具體**，如果仔細看過的讀者會發覺，我們的構面過程的套路是：1.尋找出建構拓撲網路的節點和路徑 2.建立拓撲網路 3.自動構面 4.剔除無效面和處理島與洞。

在這個過程中，自動構面的過程的效率其實是不低的，由於引入了「正向」和「反向」是否已經「走」過的標記判斷，這個基於「左轉演算法」的過程實際上會越走越快（因為越到後面，越多的點會發現自己的連通路徑已經被正反走過，它們也就無需再進行構面的搜尋過程），那麼效率出在什麼地方呢？就是拓撲網路的建立。

如果在第乙個過程中尋找出了10000條路徑和15000個節點，那麼下一步我們必須建立其它們的網路，讓每條路徑知道自己的首位節點是誰？讓每個節點知道自己的連通路徑是誰？這個過程有多麼費勁呢？

1. 根據路徑實體isegment建立clsedge物件，顯然，要計算10000次；2. 根據節點實體ipoint建立clsnode物件，也需要15000次。沒辦法，這個沒法避免掉。

下一步，遍歷每一條路徑clsedge物件，尋找它的起點和終點在clsnode集合中的位置，這是個雙重迴圈的過程，在我的書中，它需要計算10000×15000次，即1.5億次。而遍歷每個clsnode物件，尋找出與其連通的clsedge物件，顯然也是雙重迴圈，也是1.5億次。

也就是說，不改良的演算法，在這個過程中至少要執行3億多次的計算。

我最近正在用vb**重寫這個例子，遇到這個問題，肯定也要解決，要不然光是拓撲網的建立就夠讓人**了，這個演算法就是個大笑話。資料量稍微大一點，就徹底完蛋了。

我的兩個改進辦法是：

1. 在clsedge尋找它的起點clsnode和終點clsnode的id之前，先判斷其物件的id（我預設設定為-1，即兩個節點的id都沒找到）,如果兩個都已經找到了，則都不是-1了，顯然可以跳出內層迴圈。

2. 在clsedge尋找clsnode時候，也記錄每個clsnode出現的次數，如果乙個clsnode在被尋找的過程中出現了3次（即是路徑的起點或終點），那麼它的連通路徑數量也肯定是3。在每個clsnode尋找連通路徑時，也這麼先判斷下，如果累計的連通邊大於或等於3，顯然也可以跳出了。

雖然有這兩個改進辦法，但在大數量時，我個人仍然並不滿意，現在仍然在絞盡腦汁想，如何讓這兩個過程更快些，不知道大家有什麼好主意？