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

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

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

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

　さらに設定変更を積極的に行わなければならない理由に、サーバ容量の不足がある。本ブログはBiglobeのウェブリブログを使用している。これはインターネットを開設した時に、あまり考えずに始めたものだ。もう少し拡張性等を検討していたならば違った選択もあったのかもしれない。このウェブリブログについては容量の制限がない。そのため心配なくエントリー数を増やしていける。しかし画像データを保管するウェブリアルバムについては３ＧＢの制限がある。８００ＫＢの画像データならば４０００枚程度しか保管できない。設定変更　その２でも書いたように、ウェブリブログのプレミアムオプションを購入し１３ＧＢまでの拡張を検討した。しかしウェブリアルバムについては、サーバにアップロードした画像データのＵＲＬをシステムが自動生成するという仕組みがあることが分かり拡張を断念した。これは画像データの公開についてのセキュリティを与えるための機能であろうが、ブログの更新作業の自動化の阻害要因となる。一度アップロードした画像データをブログで使用する際は全て画像の選択から手作業で行わなければならないからである。折角、画像データを Kyoto.fp7 で管理しているので、ブログで使用する写真をデータベースで選択したら、画像を表示するＨＴＭＬまで生成できるように省力化したいというのが当方の思惑である。それが出来ないために、画像データ全体を現在のレンタルサーバに引越し致しました。これは前回の 設定変更　その２ で、ほぼ行ったことであるが、やはり一部の画像データがウェブリアルバムに残っており、まだ画像データのURLに image.webryalbum.biglobe.ne.jp/ が残っているため、上記の５で上げたように今回の設定変更で全ての画像データのURLをvisual.information.jp に変更しました。
　同じような容量不足は画像データ以外のHTMLやXMLファイルにも当てはまった。ウェブリアルバムには画像データしか保管できないため、地図を表示するためのGoogle Map APIで記述したプログラムやマーカー等を配置するためのXMLファイルは個人に割り当てられたHome Pageの領域に保管することとなっている。これが１００ＭＢに設定されているため、いろいろな表示方法のXMLファイルを生成すると上限に達してしまう。これも 設定変更　その２ で既に懸念していたことだが僅か１年で現実化してしまった。今回、上記の３で上げたように画像データを含めた全てのデータを visual.information.jp に移しました。この作業は、FTPツールを使用してアップロードすればできるように思われるが、実際には地図を表示させるプログラムの置いてある場所を変更するため、Google Mapのライセンス変更を行わなければならなかった。かなり以前に１回行っただけの作業だったため、思っていた以上に手間取った。

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

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

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

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

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

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