次期こちずぶらりのためのデータ構造： @kokogiko さんによるつぶやき

OHTSUKA Ko-hei @kokogiko

あかん…もう3週間くらい悩んでるが次バージョンアプリでの内部データ構造として適切なデータモデルが全く思いつかない。

OHTSUKA Ko-hei @kokogiko

データ構造変更時のデータマイグレーションに対する配慮やら、アプリ更新時の新規データ追加やら、ユーザによるオンデマンド／ダウンロードデータ追加、それも地図やランドマーク情報を個別リソースとして扱うのにリソース間でデータの相互リンクは可能、みたいなの全部考慮すると頭がパニック。

OHTSUKA Ko-hei @kokogiko

そもそもSpatialiteとの絡みで、CoreDataをこのまま使い続けるか、FMDBに切り替えるか辺りの決断も絡んでくるので、もうどうしよう。サーバサイドならダメなら変えればいいのでどうでもなるけど、アプリはダメだったからと変えればマイグレーションが悲惨なので…。

OHTSUKA Ko-hei @kokogiko

もうDBに展開するのやめて、内部にURLと同じ構造のディレクトリ構造再現して、kmlそのまま配置しようかなあ。kmlの解析は地図表示毎に毎回行って。レスポンス悪くなるか。

OHTSUKA Ko-hei @kokogiko

誰か相談に載って欲しい…

Masaki Ito @niyalist

@kokogiko 今度のGeoHex勉強会のあととかで，きっとそこに集まるだろう識者に相談してみるとか？念のため，私自身は問題意識を共有するくらいが精一杯で，自分はその何段階か前の実装で止まってる感じです．

OHTSUKA Ko-hei @kokogiko

@niyalist ありがとうございます…。

OHTSUKA Ko-hei @kokogiko

ちょっと頭を整理…アプリを公開する時は、KMLを展開済みのDBファイルを同梱する。CoreDataとSpatialite。KMLは同梱しない。全く新規の時は、両DBファイルをそのままコピーする。新規じゃないが追加データDLした記録がない時も、DB更新されてればそのままコピー。

OHTSUKA Ko-hei @kokogiko

GEOS: geos_c.h Source File http://htn.to/imUdyN

OHTSUKA Ko-hei @kokogiko

GEOS使えば必ずしもSpatialite使う必要もないのか。若干光明が見えてきたかな？

OHTSUKA Ko-hei @kokogiko

Spatialite使わずに直接GEOS使えば全部解決やんけ…今まで何を悩んでいたのか。@_hfu_ は空間DBをツールとして使うという私の案を褒めてくれたが、それに囚われ過ぎて新しい事に手を出そうという気概を無くしてた。恥ずかしい話だ。