徘徊の記憶

アクセスカウンタ

zoom RSS 設定変更について その6

<<   作成日時 : 2016/08/17 14:23   >>

ブログ気持玉 0 / トラックバック 0 / コメント 0

設定変更について(せっていへんこうについて)その6 2016年8月17日登録

画像
設定変更について Nikon社製 D7000 現在のメインカメラ


 設定変更について その5では、情報の一元化を図るために今まで作成してきたデータベースを壊し、必要な情報のみを残して新しいデータベースを作成することの背景を書いてみました。2008年より本ブログを書き始めた頃より、“こんなものがあったら楽になるだろう”という気持ちで各種のツールを作成してきました。そのため8年も経つとシステム全体に冗長性が目立ってくる。既に使わなくなっている機能も実装されたままで、何のために必要かも理解できなくなりつつある。ある程度、分かっている内に作り直したほうが楽だろうという気分で着手したものの結果的には結構大変な作業だった。

 今回行うこととした設定変更は下記のとおりです。

1 撮影対象及び地図表示の座標値を一元化管理する
2 スケジュール作成→地図作成→写真整理→ブログ作成のフローに合わせたシステムに改造する
3 Google Mapの表示プログラム及びXMLデータを全て visual.information.jp に移設する
4 画像データのファイ名称を簡略化する
5 全ての画像データを visual.information.jp に移設する
6 「徘徊の備忘録」に掲載している撮影情報を新設した「徘徊の蔵書棚」に移設する
7 「徘徊の蔵書棚」の更新作業を省力化する
8 「徘徊の記憶」「徘徊の蔵書棚」の地図表示を見易くする

 一番の目的はシステムの冗長化を防ぎシステムを簡略化することで、旅行の準備から写真の整理、撮影情報の更新そしてブログの執筆までを迅速に行えるようにすることである。例えば8の地図表示の更新は1日の撮影分についてのブログを書き終えた後に行ってきた。例えば2009年12月20日分については、最初に桂大橋を書いたのは2013年の11月23日であった。そしてこの日の訪問の最後となった嵯峨野の町並み その9を書き終えたのは2014年6月21日であった。この2009年の12月20日、僅か1日に撮影したものについてのブログを書き終えるのに7ヶ月を要している。さらにその次の2010年1月17日については2014年6月から書き始め、現在の2016年8月時点でも終わっていない。実に2年間の時間を費やし、105エントリーを書いても終われないのはやはり異常である。この回は京都御所とその周辺であったため、どうしても幕末史について書きたいことが多くなったという理由もある。
 ともかく、前回の地図更新から1年近く時間を経ると、自分で作成したツールでも更新作業の手順を忘れてしまう。そういうことが無いように作業手順の半自動化と明確化を図ることが大きな目的となった。

 さらに設定変更を積極的に行わなければならない理由に、サーバ容量の不足がある。本ブログはBiglobeのウェブリブログを使用している。これはインターネットを開設した時に、あまり考えずに選んだことによっている。もう少し拡張性等を検討していたならば違った選択もあったのかもしれない。このウェブリブログについては容量の制限がない。そのため心配なくエントリー数を増やしていけるようだ。しかし画像データを保管するウェブリアルバムについては3GBの制限がある。800KBの画像データならば4000枚程度しか保管できない。設定変更 その2でも書いたように、ウェブリブログのプレミアムオプションを購入し13GBまでの拡張を検討した。しかしウェブリアルバムについては、サーバにアップロードした画像データのURLをシステムが自動生成するという仕組みがあることが分かり採用を断念した。これは画像データの公開についてのセキュリティを与えるための機能であろうが、ブログの更新作業の自動化をそがいするものとなる。一度アップロードした画像データをブログで使用する際は全て画像の選択から手作業で行わなければならないからである。折角、画像データを Kyoto.fp7 で管理しているので、ブログで使用する写真をデータベースで選択したら、画像を表示するHTMLまで生成できるように省力かしたいというのが当方の思惑である。それが出来ないために、画像データ全体を現在のレンタルサーバに引越し致しました。これは前回の 設定変更 その2 で、ほぼ行ったことであるが、やはり一部の画像データがウェブリアルバムに残っており、まだ画像データのURLに image.webryalbum.biglobe.ne.jp/ が残っているため、上記の5で上げたように今回の設定変更で全ての画像データのURLをvisual.information.jp に変更しました。

 同じような容量不足は画像データ以外のHTMLやXMLファイルにも当てはまった。ウェブリアルバムには画像データしか保管できないため、地図を表示するためのGoogle Map APIで記述したプログラムやマーカー等を配置するためのXMLファイルは個人に割り当てられたHome Pageの領域に保管することとなっている。これが100MBに設定されているため、いろいろな表示方法のXMLファイルを生成すると上限に達してしまう。これも 設定変更 その2 で既に懸念していたことだが僅か1年で懸念が現実化してしまった。今回、上記の3で上げたように画像データを含めた全てのデータを visual.information.jp に移しました。この作業は、FTPツールを使用してアップロードすればできるように思われるが、実際には地図を表示させるプログラムの置いてある場所を変更するため、Google Mapのライセンス変更を行わなければならなかった。かなり以前に1回行っただけの作業だったため、思っていた以上に手間取った。

 さて上記のように全データをvisual.information.jp に移した後に行う作業が、エントリー全てのリンク先の変更である。これも前回の設定変更で学んだことだが、オプションで提供されているエクスポート、インポート機能を使えば比較的簡単に行える。つまりエクスポートした全エントリーの文字データを検索して必要な箇所の修正を行うプログラムを組めば作業の省力化が図れる。既に800エントリーに近づいているため、手作業での更新は避けたいところある。前回の設定変更では画像データ1ファイルずつファイル名称とURLの変更を行った。具体的には800エントリーの中にある平均5つの画像データの2箇所の変更するためにCUT & PASTEのショートカットを多用したため、左手が腱鞘炎になりかける程であった。折角用意されているインポート機能を用いればよいように思えるが、インポート機能はインサート機能であった既に存在しているエントリーを更新するために設けられたものではなかった。その上、エクスポート機能にアクセス数等を保存する機能が用意されていないため、今まで個々のエントリーにアクセスして頂いた情報を全て捨て去ることとなる。前回の設定変更も、アクセス数を残すために全てのエントリーを手作業で変更した。そして今回も同じように手作業で行った。ただし800×5×2=8000回の変更に対し、エントリー全文を1度に変更する方法を取ったため800回の手作業で終わった。事前にエントリー全文の中で修正しなければならない箇所を検索し、それぞれを新しいファイル名、URLに修正するプログラムを作ったことによって比較的短時間で作業が完了し、左手への負担を避けることとなった。

 前回の設定変更で画像データのファイル名称を定めたが、今回上記の手作業をもう一度行わなければならなかったことが分かった時点で、更なる名称変更の検討も行った。ファイル名称だけで、どの撮影対象を何時撮影したかが分かるようにしたいと、mmmmm_yyyymmdd_nnn _IMG_XXXX.jpgという長い名称になってしまった。最初の5桁数字のmmmmmmは撮影対象No、次のyyyymmddは撮影年月日そして3桁数字のnnnはその日の撮影対象の撮影順番を入れた。末尾のIMG_XXXX.jpgは撮影時にカメラが生成するファイル名を残している。IMG_XXXX.jpgは1万枚撮影すると同じファイル名が現われるので、撮影年月日を加えることでユニークな名称になった。
ブログでの表示速度を上げるため、1枚の写真に対してサイズの異なる2つの画像データを用意した。通常ブログに表示されている写真は640×427の小さなサイズの画像データだが、その写真をクリックすると1680×1120の画像データが開くように設定している。小さなサイズの画像データだけでは細部までは分からないと思い、比較的大きなサイズの画像データを用意した。しかしサーバのデータ容量も無限ではないのでやや圧縮率を高め、800KB程度としている。
 今まではこのおゆに生成した2つのファイルを”Large”と”Small”の2つのフォルダに分けておいた。また”Large”、”Small”のそれぞれのフォルダ内は、所在地毎に細かく分けたフォルダを作り、撮影対象毎に細分して保存した。所在地毎とは例えば京都市上京区の市町村コードは26102であるが、京都御所や仙洞御所で撮影した写真は枚数が多いため、26102_00101を京都御所、26102_00102を仙洞御所専用のフォルダとして割り当てた。それ程、枚数が多くない撮影対象については、26102_00201から26102_00203で保管した。以上はPC上でのディレクトリ配置であるが、管理を容易にするため公開サーバ上でも同じ構成とした。つまり、@画像データフォルダ:Images、Aサイズ別フォルダ:Large、B所在地別フォルダ:26102_00101の下に画像データを配置している。細かく分類ことにより、Bの所在地別フォルダ内では同じ撮影対象が撮影日順に並ぶようになり、非常に分かり易くなった。その反面、フォルダの階層が深くなりファイル名称も長いものとなった。

 このようなフォルダ構成とファイル名称を1年間運用してきたが、どうも画像データの登録や更新作業に手間がかかることが分かってきた。例えば一度決めた撮影対象No.を後で変更することが増えてきた。当初、東福寺で撮影したと考えていた写真も、よくよく調べてみたら泉涌寺のものであったという間違いも存在する。また最初は“東福寺”という撮影対象タグを付けた写真でも、後に“東福寺 防長忠魂碑”と新たな撮影対象に分類したくなることもままある。このように一度決めた撮影対象タグを後で変更すると、以下のような手続きが必要となる

1 ファイル名称の変更
2 ディレクトリの移動
3 既に記述したブログ内のURLとファイル名の変更
4 撮影順の変更

と非常に変更作業が煩雑になることが分かってきた。また、画像データを保管しているフォルダの階層が深いことによって、複数の異なった撮影対象の画像データをサーバにアップロードする際、何度もディレクトリの変更が必要になる。このようにアップロードの設定が煩雑になると誤ったアップロードや更新の未実施等が発生してくる。フォルダ内の並び順を美しくすることによって無駄な作業が増えたとも言える。

 そこで今回の設定変更の4で上げたように「画像データのファイ名称を簡略化する」を実行した。具体的には撮影対象を変更してもファイル名の変更の必要がないようにすることである。つまりファイル名に撮影対象No.と撮影順を入れず、撮影した時の情報だけでファイル名を決定するという方法である。繰り返しとなるがファイル名は撮影年月日とオリジナルのファイル名称でほぼユニークとなる。例えばカメラを複数台使用して撮影した場合、撮影年月日とオリジナルのファイル名称だけではユニークに成らない可能性もある。そこでどのカメラで撮影したかが分かる情報を加えることとした。新しいファイル名称の形式は、yyyymmdd_IMG_nXXXXL.jpg である。yyyymmddは撮影年月日、IMG_XXXX はオリジナルのファイル名称。nは撮影したカメラを判別するための記号、そして末尾のLはL(Large)かS(Small)を分けるものとした。LとSを一つのフォルダ内で保管することで階層を3段構成から2段構成に減らすことができた。また所在地別のフォルダ構成を撮影年毎に改めることで、例え撮影対象を変更してもディレクトリ間の移動を行わなくても良いようになった。これにより撮影対象については、撮影データを管理する Kyoto.fp7 の中だけの設定となった。 

テーマ

関連テーマ 一覧


月別リンク

ブログ気持玉

クリックして気持ちを伝えよう!
ログインしてクリックすれば、自分のブログへのリンクが付きます。
→ログインへ

トラックバック(0件)

タイトル (本文) ブログ名/日時

トラックバック用URL help


自分のブログにトラックバック記事作成(会員用) help

タイトル
本 文

コメント(0件)

内 容 ニックネーム/日時

コメントする help

ニックネーム
本 文
設定変更について その6 徘徊の記憶/BIGLOBEウェブリブログ
文字サイズ:       閉じる