我是一個「自己動手」的傢伙，但我想確保我不會因爲嘗試咬下更多的東西而自責。WMS/WFS服務器：我瘋狂地寫我自己的？
我正在編寫一個基於瀏覽器的映射應用程序，它需要在最終用戶的機器上運行獨立（無互聯網連接）選項。也就是說，應用程序是某種服務器，在許多情況下，它將安裝在最終用戶的計算機上，瀏覽器將指向某個本地主機URL來訪問它。
我將在客戶端使用MapLayers，服務器端將有一堆特定於應用程序的自定義邏輯，例如以某些自定義方式處理地圖上的點擊事件，在地圖上創建各種自定義對象在某些時候，等等。
對於服務器的「業務邏輯」部分，我很高興在python中使用paste/webob。這是一個簡單的基礎結構，可以讓我輕鬆地完成所有這些自定義邏輯。
我一直在想客戶端會與兩臺服務器通信：這個粘貼/ webob業務邏輯服務器，以及一個服務於WMS和WFS地圖元素的服務器。所以我在尋找MapServer和GeoServer來處理地圖部分，並且...我不高興。
我不高興，因爲我不想安裝和擔心客戶機上的「野獸」。對於MapServer而言，我並不想安裝像Apache這樣的完整Web服務器，而必須處理CGI，PHP和MapScript。對於GeoServer，可能會安裝Java，並處理GeoServer設置和管理的各種複雜性。
這只是一個學習曲線問題。如果我能避免它，我對學習MapServer或GeoServer的複雜性不感興趣。我安裝了GeoServer，將其指向我的一些數據，並且能夠使用內置於GeoServer的漂亮網絡管理員中的MapLayers預覽來查看我的數據。但是當我試圖使用指向GeoServer的我自己的MapLayers網頁實際提供數據時，我崩潰了GeoServer。我可以使服務器崩潰，只是發送一些推測來自客戶端的畸形請求，這讓我感到非常驚訝。我可能會挖掘到GeoServer日誌，試圖找出我做錯了什麼，但是...我真的不想花很多時間在那。
所以，我正在考慮使用我已有的粘貼/ webob服務器自己實現WMS和WFS接口的一部分。事實上，我可能只需要WMS，因爲我可以通過一個簡單的自定義協議處理矢量對象，我可以將數據傳遞給客戶端，然後可以使用OpenLayer直接創建和操作對象。
我已經看過WMS的規格和示例消息（在WFS上少一點）。我自己實現這個協議似乎並不那麼困難，尤其是因爲在這種情況下我完全控制了客戶端 - 這不像我需要能夠充當通用的WMS或WFS服務器;我只需要讓我自己的OpenLayers客戶端開心。
我需要的WMS服務器有兩個主要的能力是：
從我創建的時間提前預渲染切片的商店即成磚（我會使用預渲染OpenStreetMap的瓷磚數據和mapnik作爲重排引擎;並且我將使用OpenLayers期望的普通谷歌地圖樣式平鋪命名方案來存儲和訪問它們）
有能力服務器修改版本的這些瓷磚，我存儲某些數據本地繪製在瓷磚頂部。例如，我可能在一個「圖層」上有10000個點，在另一個圖層上有10000個多邊形，並且當用戶激活這些圖層時，我將服務於相同的基本圖塊，但是當我服務這些圖塊時，這些額外的功能，並可能我會實施一個簡單的緩存方案，以保持這些過度渲染的瓷磚一段時間。
所以我的問題是：儘管我知道現在有一些工具，做這些事情（地圖服務器，GeoServer的，TileCache，和其他人），實際上，我感覺就像是較少的工作對我來說，只是迴應到一些簡單的WMS消息，並在python中對我自己的瓷磚進行額外的過度繪製，以確保所有內容都能正確投影等。我不需要爲這些覆蓋層繪製花哨的寬街道或任何東西，只需簡單的線條，圖標和可能的標籤。它確實聽起來很不錯，而且只有一個python-only解決方案。
我想，如果我需要擴展到支持更多的WMS/WFS協議，或者做更有趣的透支，那麼我可以在那時插入MapServer/GeoServer。
這裏有沒有缺陷我不考慮？
感謝您的支持。現在我確實得到了這個僅用python的解決方案。我最終使用CherryPy作爲服務器，因爲粘貼似乎遇到了太多的瓦片請求。是的，我可能會在未來嘗試Mapserver，但現在我很樂意從python中爲自己的瓷磚提供服務，並且目前我需要在這些瓷磚上進行的透支工作量非常小，因此我將手動完成。 – 2011-03-24 13:36:02
感謝您使用純OpenLayers解決方案的建議，但是我有太多的透支數據來實現這一點，而且我也無法保證本地計算機是服務於這些平鋪的計算機。 – 2011-03-24 13:37:01
如果你想使用CGI選項，你可以使用paste.cgiapp來打包。 – 2011-08-03 21:58:59