GeoHex3D化に向けての議論まとめ
-
- いいね！0
Taichi Furuhashi 🇺🇦
@mapconcierge
あとGeoHexの３D化みたいな話って、既に議論されてます？例えば航空機の当たり判定で高度による差を扱うとか、建物のフロア表現のようなこと興味あり。 @sa2da #geohex
2010-10-08 10:52:32
sa2da
@sa2da
議論はまだしてないです。高さ方向をGoogleメルカトル上で扱うのがいいかは検討しないといけませんが、狭域には向いているので屋内ナビゲーションは是非試してみたいですね。 @mapconcierge #geohex
2010-10-08 11:27:19
Taichi Furuhashi 🇺🇦
@mapconcierge
では、たたき台を勉強会までに提案しまーす！ @sa2da: 議論はまだしてないです。高さ方向をGoogleメルカトル上で扱うのがいいかは検討しないといけませんが、狭域には向いているので屋内ナビゲーションは是非試してみたいですね。 @mapconcierge #geohex
2010-10-08 11:34:07
OHTSUKA Ko-hei
@kokogiko
X,Y座標と同じスケールが使えるように、高緯度になる程Z座標間隔を大きくするライフハック(嘘TM) RT @sa2da @mapconcierge 高さ方向をGoogleメルカトル上で扱うのがいいかは検討 #geohex
2010-10-08 15:55:59
Taichi Furuhashi 🇺🇦
@mapconcierge
う、そうくるか…乗った(嘘)！ @kokogiko: X,Y座標と同じスケールが使えるように、高緯度になる程Z座標間隔を大きくするライフハック(嘘TM) RT @sa2da @mapconcierge 高さ方向をGoogleメルカトル上で扱うのがいいかは検討 #geohex
2010-10-10 06:40:43
Taichi Furuhashi 🇺🇦
@mapconcierge
真面目に考えると、高さ属性なしの場合地表面(ジオイド高＋ヘックス中心標高)での水平ヘックス面が前提。且つ、ビルの同一フロア判定や地下レイヤ判定、空中すれちがい判定がしやすい絶対＆相対ハイブリット表記かなぁ…と妄想。 @kokogiko @sa2da #geohex
2010-10-10 06:47:30
OHTSUKA Ko-hei
@kokogiko
高さ仕様の件、仕様として考えるなら、世界中のジオイドと標高データをこちらで提供できるのでもない限り、その辺のデータが必要な項を仕様に加えない方が無難かなあと。仕様化するなら楕円体高でいいのではないでしょうか @mapconcierge @sa2da #geohex
2010-10-10 11:22:39
OHTSUKA Ko-hei
@kokogiko
楕円体高で仕様決めて、ジオイドや標高の効果はアプリ側で必要なものを用意して吸収がいいのかなと。アプリで必要となる高度は、地表高ばかりとは限らず海抜高度の場合もあるし、ならば何とでもできるよう楕円体高のままがいいのではと @mapconcierge @sa2da #geohex
2010-10-10 11:28:39
sa2da
@sa2da
.@mapconcierge @kokogiko 標高の議論についていってないんですが、 Twitter上の議論は僕の方で定期的にTogetterにまとめてMLに流そうと思います。 #geohex
2010-10-10 12:06:27
Kozo Kamada
@geo80k
@kokogiko @mapconcierge @sa2da 横からですが、kokogiko さんの考えに賛同します。公式に使用される高さは、標高と海抜でも厳密には違いますし、船の立場だとマストが絶対に届かない、船底を絶対にこすらないという観点から、さらに２通りの高さがあります。
2010-10-10 12:11:36
sa2da
@sa2da
@mapconcierge @kokogiko 標高の件、目を通せました。GoogleMapsに最適化をしているという意味で、標高は標高API(Elevation API)仕様に合わせるとして、フロア高は相対的に扱うほうがいいかなーと。単位をどうするか。 #geohex
2010-10-10 12:24:01
sa2da
@sa2da
それは確かに。地表面海抜高度との差分をどうエンコードするのか、ということを考えてました。 RT @kokogiko @mapconcierge @geo80k それに、地表面海抜高度はGMaps 標高APIを標準とすると仮にしても、もひとつジオイドデータに標準が… #geohex
2010-10-10 13:42:41
OHTSUKA Ko-hei
@kokogiko
GeoHex高度議論は、一意性を持つべきコードをどう定義するか議論と、それの適用例のショーケースに関する議論が混ざっている気がする。コードだけの議論に絞るなら、標準データを定義しないといけない地表高定義より、GPSから計算だけでできる楕円体高定義の方がいい。#geohex
2010-10-10 14:31:06
OHTSUKA Ko-hei
@kokogiko
でも、楕円体高だと、地表高でも海抜高でもないので、一般ユーザになじみが薄いのは事実。なので、ユースケースに合わせてこういうデータを揃えてこう扱えばいいんだよ、という適用例のショーケースを準備してやった方がいい。が、それはコード定義とは別議論と思う。 #geohex
2010-10-10 14:34:07
Kozo Kamada
@geo80k
@kokogiko 標高と楕円体高の差は、ジオイド面の傾きによっては楕円体高の低い方に水が流れる場合があるということですね。局所的な指標の方が直感的には分かりやすいけど、当然グローバルには使えない。皆悩むんですよね。
2010-10-10 15:18:27
sa2da
@sa2da
ですよね。もひとつヘックスと標高mを組み合わせて使うユースケースがイメージ出来てなくて議論に乗り切れてない感じあります。 RT @kokogiko …という適用例のショーケースを準備してやった方がいい。が、それはコード定義とは別議論と思う。 #geohex
2010-10-10 17:49:39
boiledorange73
@boiledorange73
横から入って即逃走しますが、気象とか、炭素の出入りとかは鉛直方向を扱うと思うです。 RT @sa2da: …ヘックスと標高mを組み合わせて使うユースケース… #geohex
2010-10-10 18:02:15
Taichi Furuhashi 🇺🇦
@mapconcierge
Z座標なしの場合は地表面hexを意識したけれど、そうではなくhex柱状の領域とみなせば、楕円体高として対応は可能と思う。回転楕円体はGoogle SphereよりもGRS80が妥当か。 @kokogiko @mapconcierge @geo80k #geohex
2010-10-11 04:59:28
Kozo Kamada
@geo80k
関東平野くらいのエリアなら柱状でよいけど、日本全域とかだったら錐状かも。この切り替えはちょっと面倒かも。「法バンドル」なんて難解だし。 @mapconcierge @kokogiko @sa2da hex柱状 #geohex
2010-10-11 08:09:05
Taichi Furuhashi 🇺🇦
@mapconcierge
楕円体中心に対して、Google Sphere表面上hexで交わる逆hex錐と考えると、それなりに複雑か... とするとGRS80よりGoogle Sphereを優先すべき？？？ @geo80k @kokogiko @sa2da #geohex
2010-10-11 10:19:01
SATO Yozo
@yoozoosato
標高の扱いが問題。日本だと東京湾の年平均海水面。世界平均のジオイドという概念がある。富士山の3776mはジオイドからの高さ。最大の問題はジオイドが平面じゃぁないこと。結構いびつ。#geohex
2010-10-22 20:18:54