マップデータをgeoJSONからcsvにgithubアップロードに変更した場合について
エンジニア目線からのコメントをまとめます。
【目次】
※非技術的な順番で一応まとめました。
・スプレッドシートの内容のエラーチェック、データの抽出なくそのまま公になる懸念
・コードの複雑化とfork元や一般的なものから異なる独自実装にならないかの懸念
・動作の効率や負荷の懸念
【スプレッドシートの内容のエラーチェック、データの抽出なくそのまま公になる懸念】
今回csvでというのはスプレッドシートのエクスポート操作だけで済むからという趣旨かと思いますので、スプレッドシートの内容のチェックは目視でということになるかと思います。
スプレッドシートは権限のないユーザのアクセス管理ができますが、githubはパブリックアカウントでかつ、クライアント端末(スマホ、PCなど)へはそのままダウンロードされますので、誰でもスプレッドシートの中身を見れることになります。
これまでのpythonツール、またappスクリプトではgeoJSON変換時点で必要なデータ以外は除外します。万が一、不要なデータを列外に記述していたり公開されないほうがよいデータが含まれた場合もより安心です。
またこれらツールではgeoJSON変換処理の中でエラー検知もできます。
座標データが浮動小数点型で扱えない場合(基本は桁ぞろえ)エラーを通知できます。
※ゆり姉さんはpythonで型エラーを経験したことがあるかと思います。
今後もう少し厳密なエラーチェックをしたい場合もツールに組み込むことで可能です。
csvのままgithub公開する場合、上述した処理はクライアント端末で実施されることになります。
※クライアント端末での処理については後述
またgithubはファイル拡張子を認識しますので、geoJSONであればgithub上でファイルを選択するだけでマップ表現でどのようになるか目視で確認することができます。
【コードの複雑化とfork元や一般的なものから異なる独自実装にならないかの懸念】
まず現在のコードの中身について整理です。
フレームワークとして利用してるopenlayersへのデータの渡し方はgeoJSONとしてのデータ構造に変換済みのjavascriptオブジェクトをプロパティとして指定する方法になります。
- 該当箇所：papamamap.js
※facilitiesDataはgeoJSONテキスト
～～～～～～～～～～～～
source: new ol.source.GeoJSON({
projection: 'EPSG:3857',
object: facilitiesData
}),
～～～～～～～～～～～～
渡すデータの取得はjQueryのgetJSONメソッド(papamamap.jsのloadNurseryFacilitiesJsonメソッドの中身)を使用してます。getJSONメソッドは内部でJSON形式のテキストをjavascriptオブジェクトへ勝手に変換してくれます。
ではcsvで取得する場合は、getJSONメソッドは使えなくなるので以下のような変更を伴います。
・jQueryで実装したい場合は追加のライブラリのダウンロードが必要
-> csv処理のライブラリはjQueryの標準ライブラリにはないようです。
・csvをhttp GETで取得してオブジェクト変換する内容を手書きする場合は十数行のコード追加が必要です。
・上記いずれの場合もopenlayersへ渡すためにgeoJSONのデータ構造への変換処理が必要です。
geoJSONへのデータ構造への変換のコードはそれなりに分量があります。
※どんな記述になるかはpythonツールまたは共有したAppツールを確認ください。
理由はcsv時点での以下のような状態に対処するためです。
・構造は各施設の情報は一次元の配列 -> geoJSONとしてのメタ情報が追加された階層的な木構造
・マップでは読み込まないデータ(列)も含みうる
・座標データ(X,Y)も他と区別なく含まれ任意の列にある -> geoJSONでは木構造内の他データと異なる階層に割り当て
・座標データが浮動小数点型で読めるよう処理されてない可能性
・一行目はラベル(項目名) -> geoJSONでは各データのキーとして割り当て
なお、上述したようにさらに厳密なエラーチェックを組み込みたいとなるとさらにコード記述量は増えます。
この時点でfork元の札幌や同様に札幌からforkした他プロジェクトと異なる記述になります。
openlayersの一般的な記述という意味ではここらへんの処理は外だしされてるので問題視されるほどではないと思いますが、初参加の人がこの記述を見たら「なぜgeoJSONで最初から取得しないんだ？？」となる可能性大です。
もちろん十分な理由があれば独自実装することは全然問題ありません。
今回csvにすることのメリット・デメリットを考慮して皆さんで相談が必要かと思います。
【動作の効率や負荷の懸念】
まず、前提としてgithubアップロード前にgeoJSONへ変換する場合は処理は一度実行されるだけで上述した追加の内容はクライアント端末では不要です。
csvにすることでクライアント端末で実行されるようになりますが、
以下の理由で繰り返し実行される率が増えます。
・まずブラウザのキャッシュに残るのはcsvの状態です。
つまり、キャッシュからの再読み込みが発生すると毎回geoJSONへの変換処理が必要になります。
・jQueryなどで多用されてるメモ化呼ばれる方法で一度処理したデータの不要な再処理を防ぐような記述もできなくはないかもですが、http GETやキャッシュで取得するデータは元データが更新されてる場合は使用しないなど考慮が必要です。
もちろんブラウザの再起動ではメモリの状態は消えるので必ずキャッシュからの取得が必要です。
では処理負荷はどれくらいなのかについてです。
Appスクリプトで測定してみました。
(※AppスクリプトではブラウザのPerformanceオブジェクトは利用できないようなのでDateオブジェクトで)
- 基本的な測定
～～～～～～～～～～～～
var start = new Date();
処理内容
->スプレッドシートを多重配列で読み込み済みの状態からgeoJSON文字列化まで
※スプレッドシートからの読み込みは単純なcsv読み込みより時間かかるかもなので除外。
つまり、測定値にはcsvデータの読み込みが含まれません（もちろん負荷はほぼないはずですが）
var end = new Date();
var time_past = (end - start) / 1000;
～～～～～～～～～～～～
※3回計測
0.534
0.549
0.624
但し、appスクリプトのサーバの性能ってどれくらいよ？ってのが問題だと思います。
実際に現在のcodeForKohokuのプログラムを修正してローカルでサーバ立てて動かすのはちょっと手間ですので、代わりにappスクリプトと自分のlaptopで同じ処理をして性能比較とさせてください。
＜性能比較の処理＞
配列に整数値を追加(push)する処理を100万回繰り返す処理
※appスクリプトでは4.000 ~ 7.000
※surface laptop intel core i5 4コア(物理2 x HyperThreding2), メモリ8GB 各ブラウザは現時点での最新
Chrome 0.02 ~ 0.06
FireFox 0.09 ~ 0.10
Edge 0.01 ~ 0.11 ※むらが結構ありました笑
つまり、appスクリプトは無料だけあって激遅です(笑)、おそらくメモリ512MBか1GBでシングルコアのVMですかね。もちろん、appスクリプトのjavascriptはブラウザ実装とは異なるので単純なマシン性能比較はできないかもですが。なのでクライアント端末が最近のlaptopなどであれば追加処理による遅延は体感ではないかもです。但し、古いスマートフォンやPCを使った場合は少し時間がかかる可能性あり、また実際にブラウザのレンダリングエンジンはシングルスレッドのシーケンシャルな処理(ここら辺の知識は未熟ですが)と思われるので処理待ち合わせによるプラスαがあるかもしれません。
次にcsvとgeoJSONでのファイルサイズについてですが、
「201804新規園追加データ」を参考とする限り今のことろcsv形式の方が小さいです。
201804新規園追加データ.csv -> 約44.6KB
201804新規園追加データ.geojson -> 約98KB
＜ポイント＞
- csv形式はデータ識別子は少ないが、geoJSONで不要データ(列)を含みうる
- geoJSONはメータ情報やJSONの識別子が付与されるが、不要データ(列)は除外できる
この比率はスプレッドシートでgeoJSONで使用しないデータが増えたりするこで変わります。
ネットワークの帯域への負荷に関してですが、まあこの程度のサイズであれば問題ではないかと思います。
標準的な転送サイズ(MTU)は1.5KBでPPPoEなどカプセル化が複数追加されて少し小さくなる場合、輻輳によるTCP再送などを考慮しても気になる量ではないかと思います。
マップデータをgeoJSONからcsvにgithubアップロードに変更した場合について
エンジニア目線からのコメントをまとめます。
【目次】
※非技術的な順番で一応まとめました。
・スプレッドシートの内容のエラーチェック、データの抽出なくそのまま公になる懸念
・コードの複雑化とfork元や一般的なものから異なる独自実装にならないかの懸念
・動作の効率や負荷の懸念
【スプレッドシートの内容のエラーチェック、データの抽出なくそのまま公になる懸念】
今回csvでというのはスプレッドシートのエクスポート操作だけで済むからという趣旨かと思いますので、スプレッドシートの内容のチェックは目視でということになるかと思います。
スプレッドシートは権限のないユーザのアクセス管理ができますが、githubはパブリックアカウントでかつ、クライアント端末(スマホ、PCなど)へはそのままダウンロードされますので、誰でもスプレッドシートの中身を見れることになります。
これまでのpythonツール、またappスクリプトではgeoJSON変換時点で必要なデータ以外は除外します。万が一、不要なデータを列外に記述していたり公開されないほうがよいデータが含まれた場合もより安心です。
またこれらツールではgeoJSON変換処理の中でエラー検知もできます。
座標データが浮動小数点型で扱えない場合(基本は桁ぞろえ)エラーを通知できます。
※ゆり姉さんはpythonで型エラーを経験したことがあるかと思います。
今後もう少し厳密なエラーチェックをしたい場合もツールに組み込むことで可能です。
csvのままgithub公開する場合、上述した処理はクライアント端末で実施されることになります。
※クライアント端末での処理については後述
またgithubはファイル拡張子を認識しますので、geoJSONであればgithub上でファイルを選択するだけでマップ表現でどのようになるか目視で確認することができます。
【コードの複雑化とfork元や一般的なものから異なる独自実装にならないかの懸念】
まず現在のコードの中身について整理です。
フレームワークとして利用してるopenlayersへのデータの渡し方はgeoJSONとしてのデータ構造に変換済みのjavascriptオブジェクトをプロパティとして指定する方法になります。
※facilitiesDataはgeoJSONテキスト
～～～～～～～～～～～～
source: new ol.source.GeoJSON({
projection: 'EPSG:3857',
object: facilitiesData
}),
～～～～～～～～～～～～
渡すデータの取得はjQueryのgetJSONメソッド(papamamap.jsのloadNurseryFacilitiesJsonメソッドの中身)を使用してます。getJSONメソッドは内部でJSON形式のテキストをjavascriptオブジェクトへ勝手に変換してくれます。
ではcsvで取得する場合は、getJSONメソッドは使えなくなるので以下のような変更を伴います。
・jQueryで実装したい場合は追加のライブラリのダウンロードが必要
-> csv処理のライブラリはjQueryの標準ライブラリにはないようです。
・csvをhttp GETで取得してオブジェクト変換する内容を手書きする場合は十数行のコード追加が必要です。
・上記いずれの場合もopenlayersへ渡すためにgeoJSONのデータ構造への変換処理が必要です。
geoJSONへのデータ構造への変換のコードはそれなりに分量があります。
※どんな記述になるかはpythonツールまたは共有したAppツールを確認ください。
理由はcsv時点での以下のような状態に対処するためです。
・構造は各施設の情報は一次元の配列 -> geoJSONとしてのメタ情報が追加された階層的な木構造
・マップでは読み込まないデータ(列)も含みうる
・座標データ(X,Y)も他と区別なく含まれ任意の列にある -> geoJSONでは木構造内の他データと異なる階層に割り当て
・座標データが浮動小数点型で読めるよう処理されてない可能性
・一行目はラベル(項目名) -> geoJSONでは各データのキーとして割り当て
なお、上述したようにさらに厳密なエラーチェックを組み込みたいとなるとさらにコード記述量は増えます。
この時点でfork元の札幌や同様に札幌からforkした他プロジェクトと異なる記述になります。
openlayersの一般的な記述という意味ではここらへんの処理は外だしされてるので問題視されるほどではないと思いますが、初参加の人がこの記述を見たら「なぜgeoJSONで最初から取得しないんだ？？」となる可能性大です。
もちろん十分な理由があれば独自実装することは全然問題ありません。
今回csvにすることのメリット・デメリットを考慮して皆さんで相談が必要かと思います。
【動作の効率や負荷の懸念】
まず、前提としてgithubアップロード前にgeoJSONへ変換する場合は処理は一度実行されるだけで上述した追加の内容はクライアント端末では不要です。
csvにすることでクライアント端末で実行されるようになりますが、
以下の理由で繰り返し実行される率が増えます。
・まずブラウザのキャッシュに残るのはcsvの状態です。
つまり、キャッシュからの再読み込みが発生すると毎回geoJSONへの変換処理が必要になります。
・jQueryなどで多用されてるメモ化呼ばれる方法で一度処理したデータの不要な再処理を防ぐような記述もできなくはないかもですが、http GETやキャッシュで取得するデータは元データが更新されてる場合は使用しないなど考慮が必要です。
もちろんブラウザの再起動ではメモリの状態は消えるので必ずキャッシュからの取得が必要です。
では処理負荷はどれくらいなのかについてです。
Appスクリプトで測定してみました。
(※AppスクリプトではブラウザのPerformanceオブジェクトは利用できないようなのでDateオブジェクトで)
～～～～～～～～～～～～
var start = new Date();
処理内容
->スプレッドシートを多重配列で読み込み済みの状態からgeoJSON文字列化まで
※スプレッドシートからの読み込みは単純なcsv読み込みより時間かかるかもなので除外。
つまり、測定値にはcsvデータの読み込みが含まれません（もちろん負荷はほぼないはずですが）
var end = new Date();
var time_past = (end - start) / 1000;
～～～～～～～～～～～～
※3回計測
0.534
0.549
0.624
但し、appスクリプトのサーバの性能ってどれくらいよ？ってのが問題だと思います。
実際に現在のcodeForKohokuのプログラムを修正してローカルでサーバ立てて動かすのはちょっと手間ですので、代わりにappスクリプトと自分のlaptopで同じ処理をして性能比較とさせてください。
＜性能比較の処理＞
配列に整数値を追加(push)する処理を100万回繰り返す処理
※appスクリプトでは4.000 ~ 7.000
※surface laptop intel core i5 4コア(物理2 x HyperThreding2), メモリ8GB 各ブラウザは現時点での最新
Chrome 0.02 ~ 0.06
FireFox 0.09 ~ 0.10
Edge 0.01 ~ 0.11 ※むらが結構ありました笑
つまり、appスクリプトは無料だけあって激遅です(笑)、おそらくメモリ512MBか1GBでシングルコアのVMですかね。もちろん、appスクリプトのjavascriptはブラウザ実装とは異なるので単純なマシン性能比較はできないかもですが。なのでクライアント端末が最近のlaptopなどであれば追加処理による遅延は体感ではないかもです。但し、古いスマートフォンやPCを使った場合は少し時間がかかる可能性あり、また実際にブラウザのレンダリングエンジンはシングルスレッドのシーケンシャルな処理(ここら辺の知識は未熟ですが)と思われるので処理待ち合わせによるプラスαがあるかもしれません。
次にcsvとgeoJSONでのファイルサイズについてですが、
「201804新規園追加データ」を参考とする限り今のことろcsv形式の方が小さいです。
201804新規園追加データ.csv -> 約44.6KB
201804新規園追加データ.geojson -> 約98KB
＜ポイント＞
この比率はスプレッドシートでgeoJSONで使用しないデータが増えたりするこで変わります。
ネットワークの帯域への負荷に関してですが、まあこの程度のサイズであれば問題ではないかと思います。
標準的な転送サイズ(MTU)は1.5KBでPPPoEなどカプセル化が複数追加されて少し小さくなる場合、輻輳によるTCP再送などを考慮しても気になる量ではないかと思います。