Stark Wong 的個人開發網站
 


 此頁面:更新於 2019 年 5 月 2 日 12 時 04 分 09 秒,頁面處理需時 0.001 秒
 網站內容版權所有(C)Stark Wong。頁面(不包括檔案)可自由連結。網站系統版本 1.90-AngularJSBase (2015/9/27)
 
網站地圖

再次失敗

還是關於上次的資料庫問題,這次的嘗試是用運輸署的資料庫,然後用新巴的建築物資料庫來取得區域名稱,如果成功的話至少可以建立一個有區域而沒有詳細地址的資料庫,至少可以用,不過結果還是不行....

其中一個站名:Eastern Street, Des Voeux Road West

配對後的結果超過一個,而且是不同區...

Array
(
    [0] => Central & Western District/Mid-levels (Bonham Road & Park Road)/Eastern Street (near Bonham Road)
    [1] => Central & Western District/Sai Ying Pun/Vicinity of Centre Street, Eastern Street & Wilmer Street
)

如果試圖把 Des Voeux Road West 也拿去配對,結果會出現第3個不同的區域...所以結論又是失敗。

還有其他辦法麼...


撰寫於:2020/3/14 22:51:49 / 回應已關閉
正在讀取回響內容...
流動巴士版圖 - 新巴/城巴資料現況

上一篇提到,由於新巴/城巴 API 變更導致無法更新資料庫。經過這兩天嘗試及評估後,問題遠比想像中複雜:

  • 原來使用的 API 直到現在已經過演化,現在的 syscode5 要能使用比較麻煩,而且要弄一個一直開啟的 Android 裝置用來產生 syscode5 才行,不傾向用這個方法
  • 至於改用 data.gov.hk 的公開資料,在開發當中發現多個嚴重問題
    • 新巴提供的公開 API 並沒有路線清單,故路線清單只能由運輸署提供的所有巴士路線 XML 中取得
    • 所有巴士路線 API 中有部份路線在新巴的路線 API 無法找到
    • 新巴的路線車站 API 並沒有每個站的車費資訊,需使用運輸署的巴士車資 XML (那個檔案116MB!) 進行對應
    • 無論使用運輸署還是新巴公開 API 都有兩個問題,其一是沒有地區資料,沒有地區資料就無法以分區進行路線搜尋;其二是只有站名而沒有街道資料
    • 以上兩個問題的資料目前是載於本地的資料檔案,而 ID 為新巴的站號,所以解決方法是要將運輸署的車站與新巴的站號關聯,那就可以在運輸署的車站中恢復該兩項資料。理論上只要同時取得運輸署及新巴公開 API 於同一路線及方向的路線車站資料然後作一對一的對應就可以,但是...
      • 新巴的 inbound 與 outbound 定義跟運輸署不符。運輸署的定義 inbound 是由終點站到起點站,而 outbound 則是相反,但新巴路線車站 API 有些 outbound 卻是終點站到起點站,有些卻不是,以致一對一對應時會因為方向錯誤而對應到不正確的站號
      • 即使方向相同,有些路線 (例如 103) 在運輸署的路線車站資料中,車站數量跟新巴 API 傳回的車站數量不同,這樣導致無法對應,因為無法知道缺少或多出來的是哪一個車站
    • 我亦嘗試以車站座標去搜尋本地資料檔案以找出對應的車站:
      • 運輸署資料使用 HK1980 座標系統,而新巴公開 API 則使用常用的 WGS84 (即經緯度) 座標系統
      • 將運輸署的座標轉換成 WGS84 座標後,發現就算經緯度誤差即使只有不多於 0.001 度時仍然會發生對應車站錯誤的問題,所以此方法不可行
    • 即使以上問題都順利解決,還是有兩個後續問題:
      • 本地資料中所用的 ID 是新巴站號,該編號對於特定車站是不變的;但是運輸署的車站編號由於是共通於所有巴士公司,故我懷疑只要站數有增減,特定車站的編號就會有變,這樣對於以後如何進行車站對應會有很大問題
      • 對於聯營線,目前有使用特別方法讓路線的九龍部份使用九巴資料而港島部份則使用新巴資料 (因為事實上聯營線的車站也有非聯營線,所以不應該出現兩個相同的車站),然而該方法依賴於九巴路線資料的車站數量與新巴資料相同,直到現在為止也只有一兩條路線會有出入,處理也比較簡單。但使用運輸署的資料時,只測試到第3條路線就已經發現車站數不同的問題,要是數量多起來根本無法處理

雖然我還是會再進行測試一段時間,但老實說並不樂觀...


撰寫於:2020/3/2 00:03:54 / 回應已關閉
正在讀取回響內容...
流動巴士版圖 - 新巴/城巴資料限制

由於新巴/城巴 API 變動導致無法更新新巴/城巴的資料庫,目前資料庫中的新巴/城巴資料庫將維持 2020/2/14 的版本,直至有後續決定為止。

目前對應方法有三個:
1. 更新 API,但需要時間研究改變的部份,而且更新後對應時間不明
2. 將 API 改成 data.gov.hk,此方法一勞永逸,但需要時間可能很多,且牽涉離站時間很可能需一併更新
3. 放棄更新直至程式完全停止更新為止


撰寫於:2020/2/24 19:13:10 / 回應已關閉
正在讀取回響內容...
流動巴士版圖 NG Android 版本更新

這次更新的流動巴士版圖其實已經做好一段時間,不過因為一些個人原因一直未公開。直到今天有點時間再加少許功能就直接放出來了。

這次更新的內容包括:

  • 優化整個程式的混合定位處理:程式中本來除了自動離站通知外都是使用非 Play Services 的舊式混合定位方法,由於已無法在模擬器中配合模擬定位進行測試,所以一次過將所有舊混合定位的部份全部替換成新方法
  • 在 Android 10 支援夜間模式:使用 Android 10 時會自動配合系統的夜間模式切換成相同的模式,但注意這在三星的 Android 9 夜間模式下無效
  • 當選擇路線時會顯示鄰近車站的離站時間
  • 加入最愛分頁顯示所選車站的離站時間
  • 修正 OpenStreetMap 無法使用:這個是 Android 的網路安全功能預設拒絕在 Android 9 以上使用非 HTTP 資源所導致,現已將 OpenStreetMap 的資源換成 HTTPS
  • 在地圖中增加交通線路顯示選項:最近無意中找到可在 Google Maps SDK 中使用的交通線路覆蓋,不過由於看起來可能會比較亂,所以將這個功能做成選項,可於地圖版面中切換
  • 自動讀取內建資料庫日期:以往每次程式更新時都要手動更新 AndroidManifest.xml 中的資料庫日期,現在換成自動從資料庫中取得 ZIP 檔案更新日期
  • 特別事件通知:這個功能現在未啟用,如有突發交通情況時可提供通知及相關連結

不過流動巴士版圖已經維護了相當長的日子,也許是時候畢業了?


撰寫於:2020/1/26 15:56:49 / 回應已關閉
正在讀取回響內容...
流動巴士版圖NG緊急資料回溯

請注意,由於九巴自己的更新資料有問題 (於新安裝 APP1933 情況下更新到最新資料庫會發現部份路線不存在,例如 33 和 269S 等),以致流動巴士版圖 NG 於 2019/11/29 更新的資料庫亦出現同樣問題。流動巴士版圖的資料庫目前已回溯至 2019/11/25 的版本 (顯示的更新日期為 2019/11/30 但內容實為舊版) 並暫停處理任何更新,直至九巴修復資料庫為止。

更新:我在 APP1933 的更新 XML 看到這個

<br />
<b>Fatal error</b>:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 29374834 bytes) in <b>/home/webmaster/pda/kmb-ws/src/Mst/Model/XmlModel.php</b> on line <b>34</b><br />

似乎他們也沒料到那個 XML 會大到這個程度... (在出現這個問題前那個 XML 的大小已經達到 28.5MB,也就是說 APP1933 每次下載更新都要下載那麼大的檔案再與現存資料進行合併,相比之下流動巴士版圖下載的資料才4.7MB…)


撰寫於:2019/11/30 14:31:53 / 回應已關閉
正在讀取回響內容...
流動巴士版圖 NG iOS 版更新及新軟件開發失敗通告

這次更新的主題有兩個,第一是久違了的流動巴士版圖 NG iOS 版本終於迎來更新 (也很可能是最後一個更新)。本來這個更新是打算在四月當舊網頁托管商無法進行外送要求時發佈的,不過因為後來發現 iOS 的 CFNetworking 可自動處理網址轉向而取消了。直到現在由於 iOS13 發佈日期漸近,而我的 MacBook Air 無法安裝 MacOS 10.14 及 Xcode 12 (試過用 Mod 強制安裝但系統運行速度太慢而換回 10.13),所以趁蘋果未強制開發者使用 iOS 13 SDK 時先把程式更新會比較好。這次版本更新的內容包括:

  • 所有 UI 配置更新至支援 iPhone X
  • 套用 Firebase Remote Config (與 Android 相同),以支援基於伺服器設定的資料庫更新及程式版本更新通知
  • 其他第三方程式庫更新
  • 移除所有 WatchOS 相關的程式碼

在更新流動巴士版圖 NG iOS 版本後,下一個更新將會是舊版流動巴士版圖的功能更新至跟 NG 版接近。

-----

另一件事就是我本來打算發佈一個新的小工具,用來自動接收天文台天氣警告的推送 (因為我不太滿意天文台官方程式的背景耗電),可惜因為天文台公開 API 的各種問題,目前處於壽終正寢(撤回?)的狀態,如何處理尚未清楚。

首先說一下程式功能:

  • 當接收到天文台發出天氣警告時,會自動推送警告訊息予訂閱該類警告的用戶
  • 警告訊息的語言及類型訂閱完全以主題方式儲存於 FCM,我方伺服器完全不需要儲存任何資料 (包括 Push Token)
  • 當天文台取消警告時,會自動以取消訊息取代已推送的警告訊息
  • 當天文台的警告消息時,已推送而沒有手動抹去的訊息會自動消失

 

然後說一下開發時序:

  • 2019/6/13: 開始在 opendata.gov.hk 搜尋過去的天氣警告 xml 以取得各種資料變化
  • 2019/6/17: 完成伺服器端開發 (php7 + cron job) 並放在 AWS 上試行,然後開始 Android (Kotlin) 客戶端開發
  • 2019/6/21: Android 客戶端基本開發完成 (使用無伺服器式透過主題選擇性推送),開始內部測試
  • 2019/6/25: 發現推送訊息偶爾出現空白中文訊息,開始進行調查
  • 2019/7/4: 調查結論 - 天文台中文 xml 會出現空白檔案情況,暫時修改伺服器端以英文資料顯示
  • 2019/7/21: 發現天文台在六月底發佈了 JSON 版本的 API 且有參考文檔,即時決定轉用 JSON API
  • 2019/7/22: 再次以 JSON API 進行內部測試
  • 2019/7/27: 準備提交程式予 Play Store
  • 2019/7/28: 發現 JSON API 後並沒有推送取消通知,開始進行調查
  • 2019/7/31: 發現某些警告 (例如 WFIRE 火災危險警告) 的警告欄位名稱與參考文檔不符 (實際上應是 type 而不是 name),修改後繼續試行
  • 2019/8/8: 再次發現空白警告名稱,開始進行調查
  • 2019/8/11: 調查結論 - 天文台中文 JSON 會缺少應有警告資料 (*1)
  • 2019/8/12: 確定 JSON API 並不會顯示取消的警告 (與參考文檔第 8 頁 actionCode 所示不符) (*2)
  • 2019/8/13: 決定暫停開發

 

請問天文台可以專業一些麼? 簡直失望。

(*1) 於 2019/8/8 20:53:01 取得的資料

英文:
{"WHOT":{"name":"Very Hot Weather Warning","code":"WHOT","actionCode":"REISSUE","issueTime":"2019-08-07T12:40:00+08:00","updateTime":"2019-08-08T16:20:00+08:00"},"WTS":{"name":"Thunderstorm Warning","code":"WTS","actionCode":"ISSUE","issueTime":"2019-08-08T20:50:00+08:00","expireTime":"2019-08-08T22:00:00+08:00","updateTime":"2019-08-08T20:50:00+08:00"}}
中文:
{"WHOT":{"name":"酷熱天氣警告","code":"WHOT","actionCode":"REISSUE","issueTime":"2019-08-07T12:40:00+08:00","updateTime":"2019-08-08T16:20:00+08:00"}}

(*2) 於 2019/8/12 18:03:02 取得的資料

XML:
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="style_uc.xsl" type="text/xsl"?>
    <rss version="2.0">
        <channel>
            <title>天氣警告一覽</title>
            <description>由香港天文台提供的天氣警告一覽</description>
            <link>http://www.weather.gov.hk/textonly/warning/warnc.htm</link>
            <language>zh-tw</language>
            <webMaster>[email protected]</webMaster>
            <copyright>本檔案的內容,包括但不限於所有文本、平面圖像、圖畫、圖片、照片以及數據或其他資料的匯編,均受版權保障。香港特別行政區政府是本檔案內所有版權作品的擁有人。</copyright>
            <pubDate>Mon, 12 Aug 2019 18:01:09 +0800</pubDate>
            <image>
                <title>香港天文台</title>
                <url>http://rss.weather.gov.hk/img/logo_dblue.gif</url>
                <width>333</width>
                <height>65</height>
            </image>
            <item>
                <title><![CDATA[取消酷熱天氣警告 (18:00 HKT 12/08/2019) ]]></title>
                <link>http://www.weather.gov.hk/textonly/warning/warnc.htm</link>
                <description><![CDATA[酷熱天氣警告在18時00分取消( 2019年8月12日 )。 <br/><br/>]]></description>
                <author>香港天文台</author>
                <pubDate>Mon, 12 Aug 2019 18:00:00 +0800</pubDate>
                <guid isPermaLink="false">http://rss.weather.gov.hk/rss/201908121800/取消酷熱天氣警告</guid>
            </item>
            <item>
                <title><![CDATA[發出雷暴警告 (15:50 HKT 12/08/2019) ]]></title>
                <link>http://www.weather.gov.hk/textonly/warning/warnc.htm</link>
                <description><![CDATA[雷暴警告在15時50分發出( 2019年8月12日 )。 <br/><br/>]]></description>
                <author>香港天文台</author>
                <pubDate>Mon, 12 Aug 2019 15:50:00 +0800</pubDate>
                <guid isPermaLink="false">http://rss.weather.gov.hk/rss/201908121550/發出雷暴警告</guid>
            </item>
        </channel>
    </rss>

JSON:
{"WTS":{"name":"Thunderstorm Warning","code":"WTS","actionCode":"EXTEND","issueTime":"2019-08-12T15:50:00+08:00","expireTime":"2019-08-12T19:00:00+08:00","updateTime":"2019-08-12T17:00:00+08:00"}}


撰寫於:2019/8/26 23:45:59 / 回應已關閉
正在讀取回響內容...
MagicTV 串流播放器及桌面控制端停止支援

MagicTV 串流播放器及桌面控制端即日起停止支援,現有使用者可仍可繼續使用,但 Play Store 不再提供下載及不再處理桌面控制端的申請。原因?

站長的 Magic TV 7000D 突然燒了,由於並非壞電容那種簡單的問題,所以決定報廢。由於目前市面的 MagicTV 裝置均無法滿足站長的要求,所以不會再添置其他 Magic TV 裝置,故亦無法再對 Magiv TV 系的程式進行任何支援。


撰寫於:2019/5/12 13:29:09 / 回應已關閉
正在讀取回響內容...
網站遷移完成及一些經驗談

由於舊網站托管商3天前無預警掛掉,所以我把原來打算5月15日才開始的遷移工作提早進行。用了 3 天各約半小時就已經完成整個遷移工作,全賴在遷移前有先做好準備。

這次網站遷移跟一般的網站遷移不同,是由找網站托管商改為用 Amazon Lightsail 服務構建小型網站伺服器。在我決定使用 Amazon Lightsail 前,由於我已決定使用基於 Ubuntu Server 18.04 LTS 的 VPS,所以可以先去 Ubuntu Cloud Images 網站下載適用於各虛擬機器程式用的 ova 影像檔,然後我將它匯入到 VMWare 並設定成與 Lightsail 最低規格相同的配備 (512MB 記憶體及單處理器),以可以充份評估效能及系統資源是否足夠。這裡有一點要注意是將 ova 匯入時可以指定預設密碼,但該密碼會在第二次開機時才生效,所以第一次開機時無法登入時無需驚慌,只需重新開機就好。

根據我在舊托商時所用的功能,我要安裝的只需要網站伺服器﹑MySQL﹑FTP 伺服器 (因有自動遠端上傳工作) 及 php,全部都是經 apt 直接下載就可以。

- 網站伺服器:Apache 2.4 –> Nginx 1.14.0-0
- 資料庫伺服器:MySQL 5.1 –> MariaDB 10.1.38-0
- FTP 伺服器:PureFTPd –> PureFTPd
- php: php5 –> php7.2.17-0

除架設伺服器需要進行設定外,由於 php 版本新了不少,現存的腳本有部份需要修改(尤其是使用 mysql 函數的部份要改用 mysqli)。

整個網站複製到 VMWare Ubuntu Cloud 到完成修改約需 2 天假期時間,網站完全運作時才使用了約 50% 的記憶體,所以最低規格的 Lightsail 也應足夠有餘。

到 3 天前網站突然掛掉,立即申請使用 Lightsail,然後根據 Ubuntu Cloud 安裝過的套件立即安裝一次然後把設定複製過去,很快就把 Nginx + php7.2 架好,並把流動巴士版圖的離站報時 API 恢復運作,第 1 天目標完成。

到了昨天遷移資料庫,在用 mysql 客戶端建立好帳號後,通過建立 SSH Local Tunnel 將 Lightsail 上的 MariaDB 呈現在本地網路,然後透過安裝在本地的 phpMyAdmin 進行匯入操作。資料庫匯入完成後書籍掃瞄程式 API 恢復運行,第 2 天目標完成。

最後今天就是將 Ubuntu Cloud 裡的網站檔案打包 scp 到 Lightsail 解開,檢查好權限設定後將臨時頁面 index.html 刪除,整個網站遷移完成。

至於網站前台則不變,仍然有透過 CloudFlare 進行加速、緩存及保護,至此正式擺脫 WCHost 的控制。


撰寫於:2019/5/9 21:50:54 / 回應已關閉
正在讀取回響內容...
修正流動巴士版圖NG新巴/城巴離站時間不正確

前陣子由於托管商問題導致 API 需要暫時遷往臨時伺服器,當時並未發現原來臨時伺服器的 php 並不支援 hash() 函數,以致進行新巴/城巴查詢時會因為報錯而令程式使用另一方的不準確預估時間,現已使用半繞道的方法解決,離站時間恢復正常。另外由於發現 iOS 版本流動巴士版圖對於請求重新指向有完整支援,所以已於伺服器對 iOS 版本程式也開於重新指向,恢復離站時間功能而不需要更新程式。


撰寫於:2019/3/21 23:31:41 / 回應已關閉
正在讀取回響內容...
書籍掃瞄程式線上功能恢復

待流動巴士版圖的離站時間查詢功能恢復正常後,現在亦把書籍掃瞄程式的線上查詢功能暫時修好。由於該程式所使用的網路程式庫不同,該程式庫可支援網址轉向,也就是說不需要進行程式更新已經可以自動回復正常。

WCHost 在用了那麼多年後終於給我充足的不續期理由,該開始留意還有哪家好用的網站託管商了...


撰寫於:2019/3/7 22:02:21 / 回應已關閉
正在讀取回響內容...
其他較舊內容請移步至舊部落格版面