最初に行政境界リレーション処理について新しい方法を模索する。
最初は行政境界のメンバーwayのみ一つのファイルに出力して、大きさを確認する。リレーション処理も一時的に行政境界に 限定する。行政境界リレーション定義ファイルも一つのファイルとする。二つのファイルが十分に小さければ分割は要らない。
境界ボックスが小さい建物や住宅地内の各種道路などはこれまでと同様の分割管理がよいであろう。 境界ボックスが大きいものと小さいものでは管理方法を変える方がよいかも知れない。
レコードの読み込みはOK、出力は後で完成させる。
大幅に簡素化したい。一から作成しなおす。
レコード形式が変わった。Relation でサイズ計算を間違えているようだ。
二つ目の relation が次のようになった。 len=4981417 id=7679401525248 uid=404834 time=14 num=27182847
前のレコードのタグに type=route がない。Encoder では存在する。 タグ長にミスがあるか？
Encoderでrelationのメンバー数(4バイト)を length に入れていなかった。
これで Relation のパースはひとまず完了した。
Tabletの場合、幅が広すぎる。２，３倍になっている。スマホの場合、合っているようだ。 縮尺の書き方が昔と違っている。
スマホの場合、画面最下部の緯度に異状はない。タブレットの場合、0.06度ほど異なっている。
計算式は以下の通り。地図は正常に表示されるので、CY、H、PX、zoom に誤りがあるとは思えない。 厳密には 10 はタブレットとスマホでは少し異なる値であるが、結果に与える影響は小さい。
double latHere = Lib.Y2Lat((CY + H / 2.0 - 10) / PX, zoom);
Windows PC/Tablet版を継承するものであるが、現在のプログラムはスマホ専用になっている可能性が ある。原点に戻って一から作り直す方がいいだろう。
100, 200, 300, ... などの数値を表示した。
eleLeftが null になっている。
if (iBgn == 0) {
float[][] eleLeft = getElevations(x - 1, y);
for (int j = 0; j < jLen; j++) {//
ele[0][j+jDst] = eleLeft != null ? eleLeft[255][j+jSrc] : Integer.MIN_VALUE;
System.out.println(ele[0][j+jDst]);
}
}
getElevattionsの引数は zoom 15でのタイル座標にする必要があった。 x15 = x >> (zoom -15), y15 = y >> (zoom -15); float[][] eleLeft = getElevations(x15 - 1, y15);
まだ、改善の余地があるが、ひとまず、完成した。
現プログラムは非常に短い線分を描くことを繰り返して、一つの等高線を描いているので、 等高線に数値を書き込むのは面倒である。100ｍ、200ｍ、… の等高線の色を変える方が簡単である。
このまま絞り込むとプログラムが複雑になる。急がず、時間をかけて、プログラムをスリムにしたい。
renderDynamicをどうするか？パフォーマンス上はコンパクトな別ファイルとするのがよい。 しかし、プログラムが増える。まずは、Map4を踏襲する。
フェリシア高等学校でleisure=pitch の描画がタイルによって欠ける。日体大では、トラックが欠けたり、 pitchが完全に消えてしまうこともある。nature=wood の一部が消えることもある。
Map4 ではこのようなエラーは起きない。Map5ではway_area算出漏れがあるかもしれない。
元々の way_area の単位は ㎡ であるが、境界ボックスを代用し、 単位はレンダリングタイルの座標にしている。精度が十分であれば、ソートでは問題ないであろう。
計算式は (x1 - x0) * (y1 - y0) / Map.Scale / Map.Scale; としている。 座標は float なので、タイル(256x256)に比べてごく小さいエリアの面積は 0 になるが、 実際上描画されないので問題はないだろう。
ソートに異状はないことも確認した。同じ方法の Map4では問題なかった。
こんなとき、全レコードに osm_id を含めておれば、チェックしやすい。
どこかに設定ミスがある。leisure=pitchや natural=wood などに bbox が 0 のものが多くある。
【解決】境界ボックス x0, x1, y0, y1 をローカルから OSM のメンバーにコピーしていなかった。 この設定で、正常にレンダリングされるようになった。
OSMのメンバー変数は bw, bh, bbox とした。
osm.bw = (fx1 - fx0);
osm.bh = (fy1 - fy0);
osm.bbox = osm.bw * osm.bh / Map.Scale / Map.Scale;
GPS、歩数計関連は、Map4のプログラムをコピーした。２キロ弱歩いてみて正常に動作することを確認した。
今のところ、Map４のような不安定動作は起きていない。
アイコン描画条件を zoom >= 20 || osm.bbox >= 1000 としているが、bbox に値がセットされていなかった。
Map4では、不要なファイル読み込みを行っていた。これを直し、十分なパフォーマンスを確保できた。
座標値配列はレコード毎にもつように変えた。
バス時刻表の表示をサポートした。時刻表データは３秒後の遅延読み込みとした。
new Handler().postDelayed(new Runnable() {
@Override
public void run() {
Guide.loadGuides();// 遅らせて実行したい処理
}
}, 3000); // 遅らせたい時間(ミリ秒) 3000ミリ秒 -> 3秒
Map4より少し簡単化した。なお、簡単化できる余地があるが、 独立性が高いので、いつでも取り組みやすいので、まずは、これで先に進む。
スマホの方が高精細だが、メモリ使用量は変わらなかった。
やはりメニューが効かなくなることがある。
まずは、一番簡単な国土地理院地図の表示を確認した。 パフォーマンス、メモリ使用量（タブレットでは50MB前後）に問題なし。 急ぐと、同じことの繰り返しになるので、少しずつ先に進む。
国土地理院の航空地図の場合、zoom によっては山岳部などではタイル地図が存在しないことがある。 現在のプログラムでは、たまたま、タイルキャッシュに残っていた画像が表示される。 このような場合、タイルキャッシュの画像をクリアした方がいいだろう。
AndroidではUIスレッド(メインスレッド)では通信だけでなく、 ファイルI/Oも実行できないので、これまで同様に、タイル画像ファイル読み込み/レンダリング/ダウンロードは RenderThreadが担う。
Map4では、以前の sleep から wait/notify に変更した。 wait/notifyの方がパフォーマンスがいいはずだが、その効果は検証していない。 sleep の方が分かりやすい。レスポンスに問題がある場合、sleep に戻してみる。
Map5アプリは極力原点から開発する。
OSMバイナリレコード形式は少なくともスタート点では Map4のアップワードコンパチとする。