2016年12月12日

Google Maps Geocoding API が仕様変更



URL: https://cloud-ja.googleblog.com/2016/12/google-maps-apis.html

Geocoding API の精度上げるよ!
その代わり曖昧検索できなくするので、その場合は Places API を使ってね♪
とのこと。


おいおい曖昧検索でもろ使ってるよ。。。影響大丈夫か!?

どうやら新仕様 API を試せるらしいので、不安を募らせつつ試してみることにした。
(無償版は既に新仕様適用済み)


【試す方法】
APIキーを用意して、次のURLにウェブブラウザでアクセス

旧仕様API:
https://maps.googleapis.com/maps/api/geocode/json?new_forward_geocoder=false&key={APIキー}&address={検索文字列}

新仕様API:
https://maps.googleapis.com/maps/api/geocode/json?new_forward_geocoder=true&key={APIキー}&address={検索文字列}
※ new_forward_geocoder パラメータを使うには APIキーが必須の模様




ではパターン別に試した結果を貼っていく。
赤字が異なる結果となった箇所。

--完全住所編--

◇ 入力値: 東京都港区南青山6-1-3 コレッツィオーネB1・B2F
旧仕様API → 東京都港区南青山6丁目1−3、35.662522,139.7162523
新仕様API → 結果なし

◇ 入力値: 東京都港区南青山6-1-3
新旧仕様API → 東京都港区南青山6丁目1−3、35.662522,139.7162523

◇ 入力値: 東京都港区南青山6-1-3 コレッツィオーネ
新旧仕様API → 東京都港区南青山6丁目1−3 コレッツィオーネビル、35.6625369,139.7163094

--建物名編--

◇ 入力値: コレッツィオーネビル
新旧仕様API → 東京都港区南青山6丁目1−3 コレッツィオーネビル、35.6625369,139.7163094

◇ 入力値: 渋谷駅
旧仕様API → 東京都渋谷区渋谷2丁目 渋谷駅、35.6581003,139.7017417
新仕様API → 渋谷駅、35.6581003,139.7017417

◇ 入力値: 表参道ヒルズ
旧仕様API → 鹿児島県鹿児島市下竜尾町10−18 ヒルズ表参道、31.6052681,130.5605682
新仕様API → 結果なし

◇ 入力値: 渋谷109
旧仕様API → 東京都渋谷区道玄坂2丁目29−1 SHIBUYA 109、35.6595953,139.6987158
新仕様API → 結果なし

--地名単体編--

◇ 入力値: 埼玉
新旧仕様API → 埼玉県、35.8569991,139.6488487

◇ 入力値: 北青山
新旧仕様API → 東京都港区北青山、35.66433,139.7101972

--郵便番号編--

◇ 入力値: 150-0002
新旧仕様API → 東京都渋谷区渋谷、35.6591285,139.7077314

--番外編--

◇ 入力値: さんちゃ
旧仕様API → Southern Railway, Chattanooga, TN、35.0458782, -85.2929228
新仕様API → 東京都世田谷区三軒茶屋, 35.6429619, 139.6700376



・・・
なるほど完全な住所でないと使えなくなるかと錯覚していたが
そんなことはないようで、ひとまず安心。

今までは完全一致する検索結果がない場合、近い住所・地名で返していたが
今後は結果なしで返すようにした、といったところだろうか。

この度の仕様変更では 建物名単体および、建物名を含む住所で検索する場合に 大きな影響がありそうだ。


※ あくまで現時点(2016/12/12)での結果です。


続きを読む


ラベル:技術 Google Maps API
posted by きっちょむ at 16:01| Comment(0) | 技術 | このブログの読者になる | 更新情報をチェックする

2015年02月18日

IE8で max-width: calc(100%-100px); をCSSだけで実現する方法


「max-width calc IE8」でググると
ざっくり固定値で指定しろ(max-width: 95%;)としか出てきません(涙)

これで結構苦労した記憶があるので
私が見つけたやり方を記録しておきます。


ポイントは次の2つです。
  1. block要素の幅が最大化されること
  2. white-space: nowrap を使うとinline要素が改行されないこと
1 で max-width を指定したい要素を括ってmarginを指定します
#width:100%;とか指定してはだめ
隣に並べたい要素は 2 を使って配置します


【サンプルソースコード】
<div>
    <div style="margin-right: 100px;
                     display: block;
                     white-space: nowrap;">
        <div style="width: 2000px;  /* max-widthが効いているか確かめてます */
                         max-width: 100%;
                         white-space: normal;
                         display: inline-block;">可変領域</div>
        <div style="display: inline-block;
                         width: 100px;
                         white-space: normal;”>固定領域</div>
      </div>
</div>
※ソースがテキストで見難いと思いますが後で直しますのでご了承ください。


かなりトリッキーな手法ですが悪しからず。

ラベル:技術 IE CSS
posted by きっちょむ at 11:37| Comment(0) | 技術 | このブログの読者になる | 更新情報をチェックする

2014年10月17日

AWS各インスタンスで Super PI !? を走らせる (2)


前回の記事で AWS 各インスタンスのベンチを取ったが、
t2 インスタンスはバースト状態が前提であったので、
バースト状態でない場合はどうなのか気になったので追加で計測。

おまけとして、巷で流行っている (?) CPU limit を掛けて steal が発生しないよう調整した場合も載せている。

結果テーブル。(見難くてすみません。。。)
t2.
micro
t2.
small
t2.
medium
CPU limit-30%-30%-60%
スレッド数111212
10M桁 (s)51.0418.5929.9020.4316.2818.139.9110.04
100M桁 (s)740.5295.7401.3318.7191.2201.0155.4160.1


バースト時と比べて、さすがにかなり遅い。
t2.micro は約10倍、t2.smallは約5倍ほど時間が掛かっている。

この数字をみると、やはりt2は万能ではないと実感出来る。


CPU limitを掛けた場合、t2.micro と t2.small はほぼ同様の結果であった。
処理能力を平均化したい場合は、t2.small を利用する価値はなさそう。


※ t2.medium でスレッド数が少ない方が速いのは、各コアの使用率の合計に制限が掛かっているため(←少々ニュアンス違いますが)、このような結果になる。計測時、1スレッドだと、1CPUの使用率約60%、2スレッドだと1CPU使用率約30%であった。


それと、あれ? t2.medium …… m3.mediumに完勝してる希ガス?


それから一応、前回のベンチテーブルも。
t2.
micro
t2.
small
t2.
medium
m3.
medium
m3.
large
m3.
xlarge
m3.
2xlarge
スレッド数11121121418
10M桁 (s)6.316.195.593.6412.476.125.296.042.986.031.87
100M桁 (s)92.7291.5982.6951.93204.7690.8979.7789.8143.9489.7626.44
posted by きっちょむ at 01:55| Comment(0) | AWS | このブログの読者になる | 更新情報をチェックする
×

この広告は180日以上新しい記事の投稿がないブログに表示されております。