超現実的異世界「月本國」を創造するぶろぐ

　何はともあれ、画像の上に文字を表示させるためのテストを行わなければならない。だが、画像のスクロールと同時に文字も完璧にシンクロさせなければならないわけで、画像のスクロールのサンプルから用意するのは面倒である。結局既存のシステムを改造しながら、少しずつテストを進めるしかあるまい。
　まずは読み込んだ地図の上に文字を表示させようとしたが、予想通りにウンともスンとも言わなかった。画像を1枚1枚読み込みながら、同時に文字を表示させようとしても、画像読み込みに時間がかかるのでは、この方法では無理そうである。以前断念した画像を重ねるシステムで同様の事態は何度も食らったので、当然といえば当然の結果だろう。
　となると、改めて一般的なデジタル地図を動かしてみる。すると、文字は画像の読み込みやスクロールが終わった後で表示されるではないか…。一般的なシステムがそうなのだから、やはり文字表示のシステムは画像の表示とは完全に別物で、画像の読み込みを完全に待ってから制御する必要があるのだろう。

　並行して作業が行われている詳細図のテスト画像は、首都:大都周辺の東郷地方の範囲内でとりあえず収めておく予定である。どうせテスト用なのだから、無駄に増やし過ぎる必要もあるまい。
　試作ではTOPにアップされているように、かなり文字や記号を詰め込んでいる。だが、それらは今後画像ファイルの上から記載することになったので、画像ファイルとしての地図は道路や境界線までということになる。新版地図を拡大して、太くなった線を一通り引き直した後で、新たに追加するのは都道府県道と市町村道ということになる。だが、それだけでも市街地ではかなりの作業量になる。
　そもそも画像の上に文字を表記して、その状態でスクロールさせるシステムは構築可能なのか? 実際に一般的なデジタル地図で行われているわけだから、不可能であるはずがない。だが、既存のスクロールマップを流用して実現可能かどうかは、現時点では未知である。

　やはり一つのフォルダ内には、ファイルを詰め過ぎないことが現実的である。詳細図は親座標1つに対して最大100枚もの数になるので、親座標単位で1つのフォルダに収めるのが現実的ではないか…。とはいえ、100枚というのは最大数の話であって、最小は1枚になる可能性もある。1枚のファイルのためにフォルダを1個用意するのも贅沢な話だが、フォルダの総数は389個で決まるし、名前に法則性を持たせれば読み込みも迅速に行われるだろう。
　となると、そのしわ寄せとして、ディレクトリの階層が増えることになる。これは詳細図のみに起きることであり、広域図と新版地図では従来通りなので、そこでのギャップが円滑に制御できるかどうか…? 不可能なことは絶対に無いだろうが、面倒になるのは確実である。そこは逃げられないのでちまちま進めるしか無いだろう。
　詳細図の存在判定に関しては全然取り掛かっていないが、389個の親座標に対して、それぞれ配列を用いる案もある。例えば、ファイルが存在すれば1、無ければ0という簡単な識別で100個の数字を順番に並べておけば、それだけで最低限機能するだろう。

　プログラミング作業をビジュアル的に表現するならば、エディタ上に文字が羅列されているだけである。そんなものに毎日向き合っていたら、誰だって遅かれ早かれ飽きてくるだろう。よって、この作業ばかりを続けるのは、モチベーションを維持する上でも無理がある。他の作業と併用することで変化が必要だろう。
　さて、システムが完成したところで、現時点で詳細図は1枚も完成に至っていない。それでもテスト用に画像ファイルを用意する必要がある。てなわけで、とりあえず試作から首都:大都の親座標n00n00の地図を100分割して、pngにエクスポートしたのであった。
　この作業自体は、従来の新版地図の作成の流れと変わらない。だが、大きく変わるのは、ファイルの数である。新版地図は今後250pxから識別子を廃止して親座標のみの500pxへ移行する予定だが、そちらは1/4に減るとはいえ、詳細図は親座標の100倍の数になる。となると、従来のままでは、同一フォルダに約3万枚もの画像が無造作にぶち込まれることになるではないか…。さすがにこれでは管理するのに面倒なことになるし、読み込み速度にも支障が出るだろう。

　従来の二次元配列を全廃する案もあったが、地図上の親座標の位置が不規則である。よって、迅速に判定するために残すことになった。どの縮尺の地図も、親座標が存在さえすれば、そこに必ず陸地は存在する。逆に親座標の存在しない場所は全海域が確定する。大雑把な判定ながら、これは重要と判断した。
　かくして、親座標のみの二次元配列を新たに作成することになったが、従来の新版地図の二次元配列から、識別子の1が付く行列を撤去して、縦横の行列の数をそれぞれ半減させる方法で進めている。だがこいつが一筋縄ではいかない。横の行は一気に消すことはできるが、縦の列を半減させるためには、どんなに規則正しく記述が並んでいても、縦方向にまとめて範囲選択をすることができない。よって、1つ1つちまちまと消していくしかないのである。かれこれ昨日から作業に取り掛かってはいるが、まだ半分も終わらないではないか…。
　ところで、二次元配列を使わないならば、いかなる方法で画像ファイルを読み込むのか？それは読み込み時に指定したファイル名の画像の存在可否を判定して、無い場合は全海域を表示させるという方式である。二次元配列を用いるのは親座標のみなので、識別子の数の多い詳細図ではその方法を採用する予定である。

　スクロールマップのシステムは、既存のマップに詳細図を追加するだけとはいえ、既存のシステムを追加するだけでは収まり切れない。親座標1つに対して、500×500pxの面積のマップが10×10=100枚並ぶわけだが、従来はjsファイルに画像ファイルの"住所"とも言えるような名称を二次元配列にあらかじめ羅列しておいて、そこから一発読み込みで処理速度を上げていた。
　だが、今回はこの方法は使えそうにない。ファイル名の数が多過ぎて、二次元配列がオーバーフローする以前に、作者の脳味噌がオーバーフローしてしまいそうである。よって、別の方法を考えるしかない。
　代替案としては、親座標以下の100個のファイル名に付加される識別子が、00～99と規則正しく統一されている。そして親座標名は新版地図と共通なので、二次元配列の文字変数の合算で、ファイル名をつないで生成するという案が浮上した。従来よりも若干処理速度は落ちるかもしれないが、そこは人間の目に見えない誤差の範囲内だろう。

　スクロールマップにピンチイン・ピンチアウト機能がようやく搭載された。プロならば1時間もあればおつりが来るだろうが、当局の技術では1日以上かかっても、動作があやふやなシステムにしかならないのであった。それでも従来より少しは不便が解消されたが、取説に無い注意書きとしては、オーバーアクションは避けて、二本の指で同時に軽くスワイプさせる感じで操作して頂きたい。さもないとパンやタップ操作とみなされて照準が動いてしまうだろう。まあ左下のスライダーを操作するのが確実である…と言っておく。
　同時にスクロールマップ出入口のページもようやくレスポンシブ化された。下の方の文章も色々書き換えられたが、大きく変わったのは架空言語に関しての記述である。前回の学会でいつの間にか数が増えていたが、月本國の公用語である月本語についての当局の見解も、いい加減に明確にしておく必要があるだろう…ということで追記した。もっとも、月本語を0から完璧に設定する時間も財源も到底無いので悪しからず…。

　広域図が1段階、新版地図と詳細図が2段階で、縮尺は計5段階の切替ということでまとまった。外見上はスクロールマップ左下のスライダーの目盛りが増えるだけだし、内部的にも変数のMAXが3から5になるだけなので、さほど難しい作業ではなさそうである。
　だが、ここで重要なシステムを搭載しなければなるまい。ていうか今まで何でできなかったのか!? それはシステム開発をPCでやっているからである。PCの動作テストはできても、スマホに関しては実際にアップロードしてテストしないことには確かめられないので面倒である。
　…でそのシステムとは何か? スマホの画面を二本の指で縮めたり広げたりする、いわゆるピンチイン・ピンチアウト操作である。一般的な地図ではこれで拡大・縮小ができるはずだが、長い間月本國全図スクロールマップには搭載されていなくて、随分不便に思われていたことだろう。作者自身もイラついていたので、まずは新版地図搭載前に、プログラミングのブランクを解消する意味でもやってみるとするか…。

　システム開発といっても今回は0から始めるわけでなく、既存の広域図と新版地図を搭載したスクロールマップに、新たに詳細図を搭載すればよい。文字で示すとそれだけの話なのだが、単純にはいかないのは察しの通りである。まずはシステムの改造計画をざっと並べてみるとするか…。
　何はともあれ、優先すべきは縮尺の拡大・縮小機能だろう。必然的に広域図と新版地図の切り替えはこれで行われているが、現時点では新版地図で等倍と2倍の2段階になるので、計3段階の制御となっている。
　当初は詳細図の搭載後に新版地図の二段階切替は廃止する予定だったが、新版地図と詳細図の縮尺の間に10倍もの差があるので、ちょっと開き過ぎるのではないか? という疑問が生じた。てなわけでこれは残すことになり、単純に既存の3段階の上に詳細図を搭載することになった。
　デスクトップPCのモニタでは等倍だと小さ過ぎて見づらいので、詳細図の拡大表示は決定している。では縮尺を何段階にするか? 等倍はスマホならば読めるので決定、その上を2～5倍ぐらいで検討しているが、2倍では大差無いし、何段階も刻むとシステム的に複雑になりそうである。よって、等倍と4倍の2段階が検討されている。

　新版地図の方で大まかな自治体の位置や地形を示すとなれば、詳細図はそちらと目的をかぶらせる必要は無い。となると、下地は一般的な都市地図のスタイルで一元化して、文字表記を画像と別で制御すれば、最小限の画像ファイルで最大限の地図情報を盛り込むことは理論上可能である。かくして、今後の方針はこれでほぼ固まったと言える。
　後は作者の技術次第というわけだが、本音を言えば地図の描画作業の方に全集中したいものである。スクロールマップのシステム構築作業は、ざっと見積もっただけでプロ並の技術と仕事量を要する。誰かにボランティアで依頼してもらえるほど安くは済ませられないし、だからといって当局の財源では人を雇うこともできない。ネット上には出来合いの地図作成関連のAPIがいくつもあるようだが、当然ながら現実世界の地図を元にするのが前提らしい。そもそもその手のものを望み通りに完璧に使いこなすのは難しいのが相場である。
　改めて作者の意のままのシステムを得るためには、自作するより他に無いわけである。またしばらくの間、CSSとJSとの格闘が続くことになるだろう。架空地図のクリエーターでこれをやっている人は他に見当たらないようだし、身内にはプログラミングに詳しい人も誰一人居ない。またしてもネット上の情報を漁りながらの試行錯誤が続きそうである。

　画像の上の任意の場所に文字を表示させるには、javascriptを用いれば可能である。フォントの色やサイズも柔軟に対応できるだろう。路線番号のおにぎりやヘキサを用いる場合は、用意した画像を表示させてから、その上に文字を表示させることになる。地図記号も独自に用意した画像を扱う制御になるだろう。
　さて、スクロールマップとなると、これらを表示させた状態でスクロールさせる必要がある。結局のところ、この場合の文字列は、画像編集ファイルの文字列ツールや、ウディタのようなRPG開発ツールの文字列ピクチャーと同様、表示させた時点で画像として扱う必要があるだろう。その辺りの制御はまだ調査中である。
　実際問題、一般的な地図で用いられている方法なわけだから、自作するのは理論上不可能であるわけがない。とはいえ、難易度は高いし作業量も膨大になるのは確実だろう。日曜大工レベルの当局の技術でどこまでできるかは、やってみないことには不明である。尚、詳細図に取り掛かる前に画像レイヤーを複数重ねる開発を進めていたが、これ以上万枚単位で画像ファイルを増やしたくないので、事実上中止になりそうである。

　月本國全図スクロールマップ更新　地形陰影図のみ
p01n0411
p05n0311
p05n15[00,01] p06n1500
p06n0701
p06n1101 p07n1100 p07n1210

　かくして、いずれの地図も、縮尺に応じた複数の画像ファイルを同じ場所で拡大・縮小させているシステムというのは推測できる。ファイル形式は、やはり最も軽くて安定するpngだろうか…。
　これに関しては、当局でも現状維持で問題無いと思われる。とはいえ、容量とモチベーションの都合があるので、これ以上画像ファイルの種類は増やしたくない。現在の見積では、全国地図の詳細図の親座標が389で、1座標につきファイル数は100枚だから、全海域を端折ったとしても大体3万枚は用意しなければならない。なるだけ考えないようにしているので勘弁願いたい。
　よくよく考えると、いずれのデジタル地図でも全国隈なく閲覧しただけで、一体どれだけの容量のファイルを端末のストレージに読み込むことになるのやら!?実際必要に応じて閲覧する領域は微々たるものだとしても、出先でスマホのGPSを見ながら探索するだけで、それ相応の容量をDLしていることになる。まあ他のアプリはほとんど使ってないから問題無いか…。

　ふと疑問に思ったのだが、一般的なデジタル地図は、拡大・縮小が自在にできるのは当たり前として、下地となる画像と記号や文字の表記はどういう構造になっているのか?
　地理院地図は、拡大・縮小による縮尺表示が固定のようである。それに応じて、下地も文字も一体化された画像が用意されていると考えられる。元々紙の地図をデジタル化したので、基本構造は当局のスクロールマップに近いだろう。
　それに対して、Windows標準搭載の地図やサーチエンジンの地図はどうか? ある程度コマ送りになるとはいえ、かなり柔軟な縮尺表示が可能である。にもかかわらず、地図上の記号や文字表記は、フォントサイズが維持された状態で変化しないではないか…。
　これはもはや、画像と文字表記のシステムが別々になっていると考えるべきだろう。画像ファイルに関しては、最初は自在に拡大・縮小が可能なのでpdfを予測したが、これは否定されるだろう。何より容量が大きくて扱うのが難しいだろうし、文字表記が変化しないのを見れば明確である。

　もう一枚の詳細図も早々に復活させて、これで試作はとりあえず一段落といったところか…。2枚の地図を比べると密度の差がかなり大きいが、高密度領域ではこれで飽和状態になってしまう。地図表記の法則を全国共通で整合させるとなると、低密度領域も高密度の方に合わせなければならなくなる。そして何より、今後こいつの全国版をワンオペで描き続けることを考えると、これ以上情報を盛り込むのは限界である。
　所詮しがない自主制作の創作なので、金も時間も無い貧乏クリエーターの範疇ではどうにもならない。それでもこいつにせめて1円でも市場価値を付けることはできないものか? そのためには、最低でも地理院地図や一般のデジタル地図に比べて、見劣りしない程度の完成度は要求されるだろう。
　となると、縮尺に応じた画像ファイルを用意するだけでなく、地図に記す情報量の差を何とかするのは不可欠だろう。だが現状のシステムでは、拡大・縮小させることで、地図上のすべてのオブジェクトが拡大・縮小してしまう。それは当たり前のことなのだが、拡大させるのは下地の画像だけで事足りる。記号や文字のフォントサイズは読める程度で維持できればよいのではないか!?

　TOPの詳細図試作を更新。もう一枚はセーブミスで飛んでしまったのでしばらく休みだが、首都:大都の中でも月本の中枢を担う領域は、大体これくらいで最終形態となったか…。地名表記を追加したことで、網目の道路は完全に下地なので、文字が重なるのが前提として少し薄くする必要があった。駅名からルビを全部消した影響は何とも言えないが、地名表記が隣接していれば問題無いか…。高速道路の出入口でも名称表記が加わったので、同じ場所に同じ地名が3つ以上重なる事態も起きるが、そこはやむを得ない。
　これで開国当初から設定の歴史がある津倉島もほぼ完成だが、この範囲で地味に悩んだ箇所が会院市場であった。現実世界の築地に相当するが、あちらは手狭になって丸ごと豊洲へ移転したのに対して、こちらも既存の面積からするとやはり手狭であった。別の場所へ完全移転するにも候補地は思い当たらず、運河の向こう側の工場跡地へ土地を広げるということになり、既存の場所は維持されることになった。かくして、国道と運河をまたぐ広大な領域となったが、連絡通路はちゃんと整備されているはずである。

　月本國全図スクロールマップ更新　地形陰影図のみ
p05n08[01,11]
p06n07[00,10,11] p06n08[00,10] p06n09* p06n10[01,11] p06n1111
p07n09* p07n1010 p07n11[00,10,11] p07n12[01,10,11] p07n13[00,01,11] p07n14[00,01,10]
p08n08[01,11] p08n09[01,10,11] p08n10[01,11] p08n11* p08n12[01,10,11] p08n13[01,11] p08n14[00,10,11]p08n1510
p09n0801 p09n09* p09n10[10,11] p09n11[00,01,11] p09n12[00,01] p09n1300 p09n1410
p10n0700 p10n0810 p10n1200