【WordPress】ダッシュボード上で注意書き等のアナウンスを表示する。

夏真っ盛りですね!システム部のヒライです。

システムが絡むウェブサイトを納品する場合、クライアントに対し使い方の説明を行いますよね。 口頭で説明後に説明書なんかをお渡しするケースがほとんどだと思います。

複雑な機能の説明は時間をとって行うべきではありますが、 基本的な使い方や、よくある質問のようなスタンダードな情報を何度も説明すると結構時間を食ってしまいますよね。

そんな時、WordPressを使っていれば、簡単に管理画面上で使い方説明を表示することが可能です。

管理画面ログイン後に表示される「ダッシュボード」上に使い方を乗せてみましょう。 functions.phpへ以下を書き込みます。

[php]
function dashboard_widget_function() {
// 説明文を記入
echo ‘新着情報一覧にお知らせを表示する場合は、<a href="/wp-admin/edit.php">左メニューの【投稿 > 新規追加】</a>から行って下さい。<br>’;
echo ‘説明文テキスト説明文テキスト説明文テキスト説明文テキスト<br>’;
}

function add_dashboard_widgets() {
// 説明文の見出し名
wp_add_dashboard_widget(‘dashboard_widget’, ‘管理画面の使い方’, ‘dashboard_widget_function’);
}

add_action(‘wp_dashboard_setup’, ‘add_dashboard_widgets’ );
[/php]

ダッシュボードを見てみる。

ダッシュボード

使い方が表示されましたね! 以上のようにダッシュボード上に表示しておくことで、クライアント様への使い方説明の時間を短縮できるのではないでしょうか。

現在地から半径○メートル以内の○○を抽出するSQL

システム部の鈴木です。

ポケモンGOの日本リリースからはや2週間、皆様は引き続き楽しまれてますでしょうか?

自分は既に飽き出しておりギャラドスへの進化を見る事無く、
わざわざ買った携帯バッテリーを使う事も無く引退が危ぶまれております。

さて、ポケモンGOでまた脚光を浴びた「位置ゲー」ですが、
ポケモンGOの場合は現在地点にプレーヤーのキャラがいて
周囲の○メートルくらいにあるポケストップではアイテムがもらえたりしますよね?

こういった「現在地から半径○メートル以内にある○○を探す」系の事をやるときの
データをどうやって探すのか?ってのをやってみたいと思います。

やりたいこと

map0

弊社のあるアークヒルズフロントタワーを中心としたとき、
色々ある座標データまでの直線距離を計算し、それが○メートルに収まるかどうか?
ということがやりたいことです。

そして今回は、様々な座標が登録されたMySQLのDBから一気に該当する座標を取りたいと思います。

データベース

今回は例としてこのようなテーブルを作成しました。

[sql]
CREATE TABLE IF NOT EXISTS `test` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`place` varchar(255) NOT NULL DEFAULT ”,
`lat` double NOT NULL DEFAULT ‘0’,
`lng` double NOT NULL DEFAULT ‘0’,
PRIMARY KEY (`id`),
KEY `lat` (`lat`,`lng`)
) ENGINE=InnoDB;
[/sql]

[sql]
INSERT INTO `test` (`id`, `place`, `lat`, `lng`) VALUES(1, ‘東京駅’, 35.68121, 139.765751);
INSERT INTO `test` (`id`, `place`, `lat`, `lng`) VALUES(2, ‘品川駅’, 35.62857, 139.738809);
INSERT INTO `test` (`id`, `place`, `lat`, `lng`) VALUES(3, ‘横浜駅’, 35.465365, 139.62209);
INSERT INTO `test` (`id`, `place`, `lat`, `lng`) VALUES(4, ‘二子玉川駅’, 35.611237, 139.626182);</pre>
<pre>
[/sql]

以下のような感じのテーブルから、弊社から半径10km以内にある駅を探してみたいと思います。

[sql]
+—-+————+———–+————+
| id | place | lat | lng |
+—-+————+———–+————+
| 1 | 東京駅 | 35.68121 | 139.765751 |
| 2 | 品川駅 | 35.62857 | 139.738809 |
| 3 | 横浜駅 | 35.465365 | 139.62209 |
| 4 | 二子玉川駅 | 35.611237 | 139.626182 |
+—-+————+———–+————+
[/sql]

ではこの中から半径10kmに収まる座標を取りだすにはどうすればよいでしょうか?

中学で習ったアレを使います

2地点間の距離を出すには3平方の定理を使いましょう

map02

3平方の定理は aの二乗+bの二乗 = cの二乗 というものです。
この公式は文系出身の自分でも中学の時に聞いた覚えがあります。

現在地であるアークヒルズの座標を lat = x1, lng = y1 (35.668185, 139.739487 )
そして目標となるATTビルの座標を lat = x2, lng = y2

とすると、緯度の差が x1 – x2 = a
経度の差が y1 – y2 = b
ということです。

上の図の例だと、例えば赤い線の半径に収まる座標がどれかを探したいわけですが
要は斜辺の長さがその半径の長さに収まっているかどうかが分かればよいという事ですね。

さらに地球の丸みを考慮して正確に距離を出すためには
弧度法のラジアン(弧度)に変換し、3平方の定理に当てはめればよさそうです。
そして地球の一週の距離は約 6378km らしいので、それを使えばこんな感じで出来るようです。

 

 

[sql]
SELECT id, place, lng, lat, (6378 * acos(cos(radians(35.668185)) * cos(radians(lat)) * cos(radians(lng) – radians(139.739487)) + sin(radians(35.668185)) * sin(radians(lat)))) AS distance
FROM test HAVING distance < 10 ORDER BY distance
[/sql]

このSQLを実行した結果がこちらです。

[sql]
+—-+——–+————+———-+——————-+
| id | place | lng | lat | distance |
+—-+——–+————+———-+——————-+
| 1 | 東京駅 | 139.765751 | 35.68121 | 2.782586467919596 |
| 2 | 品川駅 | 139.738809 | 35.62857 | 4.410253359933821 |
+—-+——–+————+———-+——————-+
[/sql]

見事に近い順で絞り込むことに成功しました。
直線距離なので実際の道路で進んだ距離とは異なりますが、便利に使えそうですね。

IEの画像縮小がきれいに表示されない理由

システム部渋谷です。

このごろはレスポンシブデザインでのWeb制作が当たり前のようになってきました。
レスポンシブデザインでは閲覧環境に合わせて見え方を変える都合上、大きな画像を用意してそれをブラウザ上で縮小させて表示することになります。

「レスポンシブで縮小した画像がIEだけ汚い…」

古いIEが消えてだいぶましな描画がされるようになったほのぼのIEだったのですが、またしても問題に!

berry

この画像を各ブラウザで縮小してみてみると…

hikaku

あたかもニアレストネイバーで縮小したかのような汚さなのですが……。
(縮小したものをニアレストネイバーで2倍に拡大しています)

各ブラウザの画像補完について

どういう処理をしているのかを調べるために、画像を縮小拡大になんのアルゴリズムを使ってるのか見てみました。

kakudai

上の画像は、小さい画像を大きく表示させた場合どう表示されるかを表したものです。
8×8の小さな画像を256×256に引き延ばしています。
上段はPhotoshopで作った参考画像で、下段は各ブラウザでの表示結果。

もしかしたら画像によって、または縮小と拡大によって切り替えているかもしれませんが、
IE11:バイリニア
Edge:バイリニア
Chrome:バイキュービック
Firefox:バイリニア
という結果でした。
バイリニア以上を各ブラウザがデフォルトとして使ってることは確定のようなのでそんな汚くならないと思うんだけどなぁ…と。

今度は別な画像を使っての縮小テスト。
しましまな横512の画像を横63に縮小表示させています。
割り切れない微妙な数字にするのがポイント。

shukushou

IEとEdgeだけ妙な縞になってます。

バイリニアでは求める位置のピクセルと周囲の1ピクセルを線形的に補完するため、半分以下の大きさに縮小する場合一度半分の大きさにして、そこから再帰的に小さくしていかないときれいな画像になりません。
(無視して捨てられるピクセルがたくさん出てくる)

元の画像が大きければ大きいほどニアレストネイバーに表示結果が近づいていくことになります。
そのぶん処理は軽くなりますが。

上記結果からの推測になるのですが、おそらくIEは処理を軽くするために意図的に2回目以降の縮小処理を省いているのではないでしょうか?

……あくまで推測ですが。

ChromeとFirefoxでは画像が半分まではしましま、半分以下はどのサイズでもグレー1色になりました。

結局のところ対処法は…

元の画像の半分の大きさになるまではきれいに縮小されるので、半分以下の大きさにならないように気を付ける必要がありそうです。