[AI 創客]中小學的AI 素養 – 生活中用的智慧導航

1. Google地圖積累了多少數據?

結合衛星,航空和街道圖像,谷歌地圖擁有超過20 PB的數據,相當於大約21 million gigabytes,或大約20,500 terabytes。

2.圖像多久更新一次?

根據數據的可用性,航空和衛星圖像每兩週更新一次。 街景圖像會盡快更新,但Google無法提供具體的時間表,因為它依賴於天氣,駕駛條件等因素。

3. Google地圖如何監控街景視圖中捕獲的不當內容?

根據Google發言人的說法,用戶偶爾會報告Google地圖上捕獲的“奇怪或不愉快的時刻” - 通常是在街景視圖中。 如有必要,團隊可以快速審查並採取行動。 用戶可以通過單擊圖像底部的“報告問題”來報告圖像,這些請求會定期受到Google員工的監控和響應。

4.私人區域google map 如何處理?

擁有Google使用的衛星的人可能會選擇在衛星和航拍圖像到達Google之前模糊某些區域。 政府也可以請求衛星所有者模糊某些敏感的地理區域。

街景圖像僅適用於通過街景合作夥伴計劃的公共道路和私人場所。

5.圖像如何成為無縫的全景圖?

街景相機系統中的15個鏡頭可以向各個方向拍攝照片,並且車上的相鄰相機會拍攝重疊的照片。 然後,團隊將照片對齊並將它們拼接在一起以創建連續的360度全景圖像,使用成像技術來減少接縫。

From Ref:

我們想對以下三個問題作仔細地討論:

6. Google 的系統架構?

7. Google地圖App如何預測交通狀況

8. Google 前工程師揭密,為什麼 Google Maps 如何肯定你的到達時間?

Google Map Architecture (Google 地圖架構)


(ref)通過 Internet 發佈地圖的傳統方法是使用專門的地圖伺服器將 GIS 資料渲染為簡單圖像,然後將該單個圖像送達瀏覽器以進行顯示。每次使用者平移到不同位置或更改縮放級別時都會生成新地圖(因為地圖範圍和縮放級別的組合數不全,因此無法提前生成這些地圖)。這些地圖總是不太完美,因為每個顯示規則都必須針對整個地圖和每個可能的縮放級別進行預定義。在非常詳細的地圖的情況下,定義這些規則的複雜性往往超出了地圖建立者的能力。

Google 選擇了一種解決方案,可以提前生成地圖,並作為小瓷磚在使用者端組裝成一張大圖像。此方法的優點是地圖的外觀和圖形品質一致,而且可能更重要的是,可以實現巨大的可擴充性。無需伺服器端處理來生成地圖,並且單個地圖切片比使用者端顯示的整個地圖小得多,因此它們能夠更快地交付和顯示。權衡是一個很大的努力,預先生成漂亮的地圖和需要修復縮放水準,而不是允許連續縮放,如傳統方法的情況。

動態內容的限制:


(ref)在這種情況下,您可以討論服務平臺中可擴充性和彈性的需求。您可以比較預處理磁貼的優點和缺點,或動態呈現它們。

討論如何設計一個系統,根據發出請求的裝置類型來縮放磁貼大小(即 256px x 256px 磁貼可能在筆記本電腦/桌上型電腦上載入良好,但可能會帶來不連貫的移動消費體驗),這也是明智的做法。

相關交通感應器如何工作:


近年來,三種地面類型越來越普遍:雷達、主動紅外和雷射雷達。雷達交通感應器部署一個可測量的微波能量區域,當車輛通過時,微波能量會反射回設備。主動紅外和雷射雷達感應器以類似方式工作,使用低功耗紅外能量和紅外光束形成探測區域。在所有三種類型的設備中,將能量反彈回感應器所需的時間與在暢通無阻的欄位中收集的資料進行比較,以確定通過感應器的車輛的大小和速度。擦汗的小東西

ref: https://www.ncta.com/platform/broadband-internet/how-google-tracks-traffic/
ref: http://prismoskills.appspot.com/lessons/System_Design_and_Big_Data/Chapter_07_-_Designing_Google_Maps.jsp

Rendering(繪圖):


Ref: http://stackoverflow.com/questions/204644/how-does-google-maps-work

該技術可以一般地描述為地圖伺服器。地圖伺服器從覆蓋整個星球的大型預先生成的地圖切片圖像生成請求位置的地圖。映射伺服器可能會覆蓋來自其他資料庫的資料。地圖檢視器用戶端和地理資料庫的組合傳統上稱為地理資訊系統 (GIS)。

如前所述,Google 生成了所有這些 256x256 磁貼,並且只是提供相關的磁貼。

頁面上的 javascript 代碼和伺服器代碼使用連結中的數位來確定要查看的地圖的位置、縮放級別和查看視窗的大小,以確定要發送到瀏覽器的磁貼。

谷歌地圖和谷歌地球使用一種稱為KML,或"鑰匙孔標記語言",這是XML的特殊變體。

http://stackoverflow.com/questions/1204258/how-does-google-maps-render-the-map-etc-is-it-flash-a-java-applet

更詳細一點,谷歌地圖使用一個大的div元素,包含幾個img元素。每個 img 元素都是 256 圖元的正方形,並放置在常規網格上。從那裡,谷歌地圖javascript程式計算哪些網格圖像應該載入到每個img標籤,並使用週期性dom操作,以定位每個img在正確的地方。僅載入在 div 內可見的地圖的切片。當您從側面滾動時,javascript 庫將卸載圖像,並根據需要載入新圖像。其他元素(如縮放控制項、標記和線條)根據需要堆疊或繪製。

Ref: http://gis.stackexchange.com/questions/64248/google-maps-android-vector-rendering-how-do-they-make-it-that-fast

Ref: https://plus.google.com/+EvanParker/posts/cUYRzsn5nyN
Ref: http://alistapart.com/article/takecontrolofyourmaps


公路路段速度系统


現在某號公路某段某方向的堵不堵,是每個上路司機都想知道的問題。如果我來設計一個這樣的系統



信號的來源應該使用手機程式。給予手機機主一些好處作為獎勵,一定比硬體裝到車上面成本更低。
手機程式應該每10秒中采一次樣。采GEO的資訊(我只知道緯度和經度,懂行的人可以說說)。
這樣手機程式裡就有了10秒前和10秒後的資訊。很快可以算出這個機主的速度。
靜止速度為0的情況一般有兩種,最主要的一種是機主在辦公室。另一種是park車休息例如的士司機。
如果調用server的api,可以知道server是否感興趣我當前的位置。這樣我們的server方必須提供一個api,input是longitude和latitude的時候,返回true/false。
如果sever方返回的是false,則不要再往server送地點。除非速度超過10mph後就應該不停地報告地點。速度變成0mp就要調用server的api,(高速上和普通路紅綠燈有完全停車的情況)

另一種思路是不管怎樣,submit就是。server方會filter off不感興趣的submission。(說實在這點需要domain knowledge,判斷一個geolocation是否在我們這個系統所監控的高速和普通公路上,如果很便宜就應該採用這個思路,省卻了一個server的api)


給server送達的資訊應該包括如下:

  • 用戶的id (這樣和獎勵掛鉤)
  • 10秒前的geo location,和當前的geo location(一對)
  • 如果手機信號不行,最多保留最後5分鐘(50個location對)
  • 手機的絕對時間不重要,關鍵是相對時間。



到server方後,應該根據geo location(這點不知道是否可行)和地圖來判斷所在的公路和方向(向東還是向西),這樣就知道了一個關於某號公路某段某方向的速度的一個sample。
按照路段來sharding的話,通過軟體load balancing把這個sample送到相應路段的kafka裡
處理kafka裡的samples的service可以刨除極端的資料,然後計算5分鐘window的平均值,送給顯示方。
每個使用者的有效sample的submission記錄,並且最後寫入關係型數據庫。

這樣這個系統就可以顯示5分鐘某段某方向的道路的平均速度。如果沒有資料則可以不顯示或者採用同天同時間段的平均平均值來提出估計資料。

1:為什麼需要手機記錄歷史位置?既然手機已經發過之前位置了,伺服器端應該已經有了,而且應該是序列。近期的可以放在緩存裡。
2:假設使用app的人足夠多,應該可以根據geo和周圍其他人的位置資訊綜合出來是不是停車還是堵車。如果位置是商城裡,肯定不能用。或者其他人在這條線上都是快速飛奔。
3:可以根據資料量採用適當geohash level來分片計算以及緩存。
4:還可以同時使用其他資料來源來做比對,綜合

  • 手機會有掉線的情況,data用量高被暫時關掉。所以手機無法發送的時間段是存在的。
  • 是可以綜合同一路段的情況,我在樓頂提到了“刨除極端的數據”,和“平均值”。
  • 如何判斷用戶在某公路上,是一個我沒想好的點。用GEOHASH我不知道是不是更好仍然需要判斷一個點所在的路段,而用GEOHASH能省多少我不確定。如有細節,還請詳述

// STEAMCourses 課程介紹:

當AI 進入 Scratch

•生活 AI

•創意 AI

•Scratch

•Scratch 的智能語音

•Scratch 的智能翻譯

•做個 Scratch 多語系專家系統(智能導覽)

•視覺辨識

•人臉辨識

•車牌辨識

•文字辨識

// STEAMCourses 課程介紹 end


Google地圖App如何預測交通狀況

您開車的時候常用Google地圖App (Google Maps)來導航嗎?或者您是使用Android作業系統的智慧型手機嗎?

如果是,您也是Google交通資訊大數據分析團隊的一員喔!

您開車是不是也像我一樣非常依賴而且信任Google地圖App?

汽車導航軟體最基本的功能自然是導航,帶領駕駛人找路開到目的地,因此地圖資訊的建置是最基本的。到達目的地也許有好幾條路可以選擇,駕駛人通常期望的是避開塞車、最省時間的路徑,而不見得是最短的路徑,這時汽車導航軟體需要的便是交通資訊,即時的交通資訊。

Google地圖App導航功能上慣常看到行駛路徑標示成藍色(地圖層上是綠色)、黃色、紅色,代表這段路「交通順暢」、「有點兒慢」、或是「很塞車」。更重要的是從這些即時的交通資訊,軟體能夠進一步計算出到達目的地需要多久,為車主建議一條最省時間的路徑,甚至能夠依據即時交通狀況的變化,適時計算、更換新路徑。

Google地圖App到底是如何預測即時交通狀況的?

早期Google確實是和政府交通管理單位合作,透過裝置在路邊的各式交通感測器,使用雷達、紅外線、路面感應線圈、甚至雷射等技術,偵測行經車輛的尺寸與速度,然後將資料傳送到伺服器。不只是國內,各國都有由政府交通管理單位裝置的交通感測器,也有部分是由專門做交通流量資訊的私人公司裝置,再把蒐集到的交通資訊賣給Google或其他經營地圖服務的公司,電視或電台的路況報導節目等等。

Google有一類資訊是全世界其他公司所沒有的,他們有無數的Android作業系統智慧型手機隨著車主在道路上行駛,不斷將GPS訊號以匿名方式傳回,隨時回報自己的位置和速度,Google便能蒐集到最完整的即時交通資訊。

GPS定位系統已經是每一隻智慧型手機的標準配備,美國的FCC(相當於台灣的NCC)在2011年便規範每一隻智慧型手機都要裝置GPS。您新買的Android作業系統手機在設定時都會問您是否願意提供GPS資料,如果您回答願意,您便加入了Google交通資訊大數據分析團隊,互相幫忙傳送即時交通資訊。

2009年開始,Google便決定改以群眾做為資料來源,提升其提供即時交通資訊的能力,他們還把為「以群眾做為資料來源」的方法發明了一個新詞,叫做“crowd sourcing”。除了「即時」之外,Google也強調「預測」的能力,能夠準確提供車主行車預估時間才是功力。

Google的大數據分析演算法採用多種資訊,希望能預測幾個小時之內的交通變化,包括靜態資訊如該路段的時速限制或建議速度,歷史資訊如過去每週同一天、同一時段該路段的行車平均速度(Google已經累積了好幾年歷史資料),再加上目前在該路段行駛的智慧型手機回報的GPS資訊判讀的即時交通資訊,混合起來做行車時間的預測。

大數據時代,Google即時交通資訊的例子是大數據分析最好、最成功的應用之一。

Google 前工程師揭密:為什麼 Maps 如何肯定你的到達時間?

作為一款流行的地圖軟體,Google Maps 提供了路線規劃、周邊搜索、分類搜索等功能。在以 9.66 億美元收購了眾包地圖服務 Waze 以後,Google Maps 最近開始將其路況(用顏色表示交通擁堵情況:綠色表示暢通、黃色表示有點擁堵、紅色表示嚴重擁堵),及行程時間預測等功能也整合進來。

而 Google 的前工程師 Richard Russell 在線上知識市場《Quora》上 披露 了 Google Maps 是如何估算預計到達時間的。

跟其他類似產品一樣,Google maps 的 ETA(Estimated Time of Arrival,估計到達時間)要基於各種東西進行計算,還要取決於特定地區的現有資料情況。這些東西包括:法定限速及推薦速度、根據道路類型推斷的速度、特定時段的歷史平均速度資料(有時取平均,有時取特定時段的資料),以及之前使用者的實際用時情況。還需考慮即時的交通情況,然後綜合利用掌握的資料來源盡可能做出最佳預測。

大多數公司都會用即時交通跟預測進行比對,然後對演算法和資料來源做出調整。其結果很可能就是誰掌握了最好的使用資料(掌握的使用資料越多,越有能力對預測與現實進行比較),就能在中長期做出最好的預測。

Google 2009 年的這篇 博客 曾披露了如何利用眾包資料來説明 Google Maps 進行行程時間預測。

Google Maps 產品經理 Dave Barth 寫道,當我們將你的速度與任意時間在道路移動的成千上萬部其他手機的速度結合起來,就能描繪出一幅相當清晰的即時交通情況圖景。此外,Google 還會利用演算法排除某些異常的情況,如經常要停頓的郵差的資料就會被排除在外。

當然,就算收集的資料再多,要想完美預測出到達時間仍然是不可能的。正如 Russell 所述,計算 ETA 屬於預測未來型問題,而交通儘管遵循特定的模式,卻天生就是不可預測的。

Google 地圖的彩蛋 (From WiKi)

2012年4月1日愚人節,Google推出了水下搜尋及勇者鬥惡龍的「8位元探索地圖」(日版為「探究」),地圖右上方點選探究即可進入,而街景同樣是8bit。大城市以城堡表示(如上海北京廣州等),其他城市以村莊表示,眾多著名建築都有特別的繪圖,Google分部以兩名小童表示。

2013年4月1日愚人節,Google推出藏寶圖風格的地圖,褐色牛皮紙與濃濃古風讓你宛如置身大航海時代,讓使用者可以用相當復古的舊式紙本地圖外觀進行尋找。另外Google推出嗅覺搜尋功能,稱只要貼近螢幕就會聞到味道,結果這當然是場惡作劇。 地圖充滿濃厚復古風,以牛皮紙手繪風格亮相。只要點選藏寶圖選項,就可讓地圖變為藏寶圖,延續2012年的探索精神,只是2012年是由勇者探索大地,2013年顯然是由網友扮演寶藏獵人或海盜了。點選街景則可看到老相片風格的街景圖。

2014年4月1日愚人節,Google於智慧型手機Google Map APP推出「神奇寶貝訓練師專用地圖」,共150種不同類型的神奇寶貝,數以萬計地分布於世界各角落,供使用者抓取神奇寶貝,體驗一日神奇寶貝訓練師。除了延續傳統探險精神,更滿足了許許多多訓練師的蒐集慾望。

2015年4月1日愚人節,Google推出了「小精靈 (Pac-Man)地圖」,在地圖左下角即可進入。使用者可以選擇有足夠密度街道的區域,在真實的地圖下體驗吃豆人遊戲。

// STEAMCourses 課程介紹:

當AI 進入 Scratch

•生活 AI

•創意 AI

•Scratch

•Scratch 的智能語音

•Scratch 的智能翻譯

•做個 Scratch 多語系專家系統(智能導覽)

•視覺辨識

•人臉辨識

•車牌辨識

•文字辨識

// STEAMCourses 課程介紹 end

// STEAMKid 實體課程

【AI 創客】Scratch AI & Machine Learning

【文化創客】 博物館文物創客夏令營

// STEAMKid 實體課程


// 相關文章系列

中小學AI 素養 – AI 簡史(I)

中小學AI 素養 – AI 簡史(II)

中小學AI 素養 – 生活中用的人工智慧語音及翻譯系統(I)

中小學AI 素養 – 生活中用的人工智慧語音及翻譯系統(II)

中小學AI 素養 – 生活中用的智慧導航

中小學AI 素養 – 生活中用的智慧視訊偵測

// 相關文章系列