AWS 推出 Amazon Location

AWS 推出了 Amazon Location:「Amazon Location – Add Maps and Location Awareness to Your Applications」,目前是 Preview 階段,但開放給所有人使用,而且不收費。

目前合作的圖資是 EsriHERE Technologies

You can choose between maps and map styles provided by Esri and by HERE Technologies, with the potential for more maps & more styles from these and other partners in the future.

先比較了一下 Amazon Location 在 map 這塊預定收費的價錢與 Mapbox pricing 這邊列出來的價錢,看起來兩邊的算法不太一樣,AWS 這邊是照 tile 數量算錢,Mapbox 則是算 load 次數算錢,看起來 AWS 這邊服務的在大量互動的情況下會比較貴 (會拉很多 tile),但對於像是只是展示可能會便宜不少,像是 591 的那種用法。



Amazon Location is available in the US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), and Asia Pacific (Tokyo) Regions.

試著用 OsmAndMaps 的離線地圖

OsmAnd 是在「Why I quit using Google」這篇看到的東西,這篇文章在討論離開 Google 的 ecosystem 有哪些替代方案,裡面有提到其實這些轉移不是短時間轉完的,而是不斷嘗試,直到找到自己滿意的替代方案:

Migrating away from Google was not a fast or easy process. It took years to get where I am now and there are still several Google services that I depend on: YouTube and Google Home.


Google Maps → Bing Maps → OpenStreetMaps and OsmAnd

在 iOS 上面的應用程式叫做 OsmAndMaps,下載後內容大概是這樣:


GrabFood 用定位資料修正餐廳的資訊

Grab 的「How we harnessed the wisdom of crowds to improve restaurant location accuracy」這篇是他們的 data team 整理出來,如何使用既有的資料快速的修正餐廳資訊。裡面提到的方法不需要用到 machine learning,光是一些簡單的統計算法就可以快速修正現有的架構。

這些資訊其實是透過司機用的 driver app 蒐集來的,在 driver app 上有大量的資訊傳回伺服器 (像是定時回報的 GPS 位置,以及取餐狀態),而這些司機因為地緣關係,腦袋裡的資訊比地圖會準不少:

One of the biggest advantages we have is the huge driver-partner fleet we have on the ground in cities across Southeast Asia. They know the roads and cities like the back of their hand, and they are resourceful. As a result, they are often able to find the restaurants and complete orders even if the location was registered incorrectly.


Fraction of the orders where the pick-up location was not “at” the restaurant: This fraction indicates the number of orders with a pick-up location not near the registered restaurant location (with near being defined both spatially and temporally as above). A higher value indicates a higher likelihood of the restaurant not being in the registered location subject to order volume

Median distance between registered and estimated locations: This factor is used to rank restaurants by a notion of “importance”. A restaurant which is just outside the fixed radius from above can be addressed after another restaurant which is a kilometer away.

另外也有不少其他的改善 (像是必須在離餐聽某個距離內才能點「取餐」,這個「距離」會因為餐聽可能在室內商場而需要的調整),整個成果就會反應在訂單的取消率大幅下降:

整體看起來是系統產生清單後讓人工後續處理 (像是打電話去店家問?),但這個方式所提供的清單準確度應該很高 (因為司機不會沒事跟自己時間過不去,跑到奇怪地方按下取餐),用這些資料跑簡單的演算法就能夠快速修正不少問題...

用 CSS 貼 3D 場景的圖

看到一個 demo 展示瀏覽器內 CSS 的處理能力,看起來已經足夠到可以處理不少貼圖與光線效果的部分了:「CSS FPS」。

This is demo of a CSS powered 3D environment. Geometry is created with HTML elements and CSS transforms. Textures and lightmaps are composed by layering multiple background-images and colour is applied using CSS blend-modes.

不過遊戲應該會需要更多種類的效果,這部份目前應該還是得靠 javascript 來產生... (如果要在瀏覽器裡面跑)

把掃地機器人的資料轉成 DOOM 的地圖...

看到「DOOMBA」這篇文章,介紹了 Noesis 這個工具,然後拿這個工具把 Roomba 的軌跡資料轉成 DOOM 的地圖:

第一個想法是「XDDD」,但第二個想法是「咦,程式怎麼不是放在 GitHub 或是其他 Git Hosting 上面」...


Oalley 這個服務利用「交通時間」來評估地點,最簡單的應用像是給一個地點與時間,畫出範圍:


不過後面是用 OpenStreetMap 的資料,我丟了幾個中文測試好像都找不到,用英文倒是可以...


這個報導蠻有趣的:「A Map Showing How Much Time It Takes to Learn Foreign Languages: From Easiest to Hardest」。

文章裡分成這幾種:(扣除已經是母語的英語,Category 0)

  • Category I: 23-24 weeks (575-600 hours) Languages closely related to English
  • Category II: 30 weeks (750 hours) Languages similar to English
  • Category III: 36 weeks (900 hours) Languages with linguistic and/or cultural differences from English
  • Category IV: 44 weeks (1100 hours) Languages with significant linguistic and/or cultural differences from English
  • Category V: 88 weeks (2200 hours) Languages which are exceptionally difficult for native English speakers


Cantonese (Chinese)
Mandarin (Chinese)
* Usually more difficult than other languages in the same category.


在「Generating fantasy maps」這邊看到在講產生隨機地圖的方法,就像這樣細緻的地圖:

作者是依照「Polygonal Map Generation for Games」這篇的方法改善的,我之前看過但好像沒寫文章記錄下來...