最近在內部討論到資料和功能的一些問題，今天突然想到kiwi資料規格的好，並由此感覺在國內對導航的使用存在誤導，包括開發者和消費者，當然這也是不可扭轉的現狀，消費教育、消費引導都不是隨便就能改變的。
說兩件事情吧。
1、關於動態標註和靜態標註的問題。
雖然這是地圖表現層的技術實現，和kiwi資料沒有關係，但若想要有乙個好的地圖顯示，就有很大的關係。
標註的重點、標註的層級，如何區分顯示？kiwi資料中的landmark應該就是用來做這樣事情的。但我們往往的做法是，將landmark也作為可引導資料，即同poi混為同乙個概念。這一做法的優缺點如下：
缺點：landmark本身不具備引導屬性，強制引導所帶來的準確性問題；本來landmark是用來顯示標註的，結果用poi資料動態判斷顯示標註，導致重點和層級不明，標註顯示產生混亂。
當我突然回頭尋求地圖美觀的時候(其實也不僅僅美觀，實用性也是不錯的，能夠了解自己所處的周邊地標)，發現landmark是多麼的重要，不然landmark也就不需要人為處理生成了。
順便衍生一下：道路名的標註，kiwi也應該有自己的考量。
2、關鍵字的使用。
我們做查詢的時候，往往追求的是全而快，在同消費者的教育中，也同樣存在此問題，往往比較的就是資料的找得到和找不到、資料找的快和慢，但回過頭來看，我們真的有這樣的必要嗎？
舉例來說吧，假設「七天快捷酒店田林店」，如果使用者輸入「天快」或「店田」的關鍵字，找到這個酒店，是否存在意義？難道不可能使用者是需要找快遞公司或乙個小吃店？若是此，結果不是與使用者背道而馳？這種找到的結果為非使用者期望結果，是否真的存在意義？
在資料中，有這樣的乙個屬性字段，叫做查詢關鍵字，裡面的關鍵字不多，可能就是「七天」、「酒店」、「快捷」、「田林」等等這樣的字眼，使用者只有輸入這些關鍵字才能找到該結果，上述的「天快」和「店田」是不能找到的，那結果是否更接近使用者預期？
再說查詢速度，查詢速度和資料量是成反比的，比如全國範圍內查詢的速度原則上一定比省內或城市內查詢的速度慢，所以一般情況下，大部分的公司都是無法做到全國範圍內查詢的，做省內或城市內的資料查詢也主要是因為查詢資料量的考慮(當然也有可能同地圖分塊有關)，假設，在上海查詢「海洋館」，即便速度再快，但結果**現「北京海洋館」，這是你需要的結果嗎？而你不需要「上海長風海洋世界」或「上海海洋水族館」？
同時查詢速度和查詢範圍也同cpu消耗以及記憶體有關，特別是瞬間記憶體，如果cpu和記憶體的消耗有損整個軟體的穩定性，那是否有必要作出範圍廣、速度快的查詢？
我們似乎用一些表面的東西去**了使用者內心最真實的訴求。
由資料儲存想到的
突然看到自己寫的一段 於是想到了當初糾結的經歷。正巧和一些東西聯絡起來。對於乙個無符號型16位的數來說，它能表達的最小數字為0即2 0 1，最大數字為2 16 1.同理32位，64位等。在運算子中存在 這樣的操作。以下便是我在設計中的乙個 大體框架 uint16a uint16b uint16c 後...
由記憶體的使用聯想到的
這兩天自己湖南dvb c的程式經常會在操作時莫名的宕機。由於沒有規律，所以不知道是哪個地方出 錯了，自己也為此苦惱了一天，把程式看了又看也不知道出了什麼問題。不過由於是在密碼輸入時候出現的宕機，而且是操作一會兒後才有不規律的宕機，我猜想記憶體可能出問題了，因為在密碼輸入由於要備份介面上的東西，所以會...
每日N題 由海量資料去重所想到的，面試思維慣式
今天在同事的桌子上看到乙份簡歷，看了看。在簡歷的後面寫了幾道題，應該是給他準備的面試題。看了下，有點感觸，就隨便寫寫吧。下週，我要和公司簽合同，要是不理想可能也得找工作。看到那幾道面試題，我自然而然地想到，如果我是應聘者，我該會怎麼回答。而我在看這個題目的時候，突然意識到乙個問題 我們經常按面試思路...