GeoJSONやKMLの3つめの数字は標高？楕円体高？ — 仕様が決めている高さの基準と、日本でそろえる手順

答えはフォーマットごとに違います。GeoJSON は仕様が「WGS84 楕円体からの高さ」と明記、KML は altitudeMode 次第で、既定では高さを無視、GPX は基準を定めていない——同じ「標高っぽい数字」でも意味が別物です。日本ではこの取り違えが30〜40m のずれになって出ます。

結論を先に：3つの仕様は同じことを言っていない

フォーマット	3つめの値の基準	仕様の書きぶり
GeoJSON（RFC 7946）	WGS84 楕円体からの高さ（楕円体高）	明記されている
KML	`altitudeMode` で切り替わる。既定は `clampToGround`＝高さを捨てる	モードは定義されているが、「海面」がどのジオイドかは未指定
GPX 1.1	`<ele>` は「メートル単位の標高」としか定義されず、基準面の指定がない	別要素 `<geoidheight>` の存在から、海面基準（標高）を想定した設計と読める
CSV	何も決まっていない	列名（`ellH` / `H` / `elev`）と作成者に依存

この表の意味するところは単純です。ファイルの外側の情報（仕様書・作成ソフト・列名）を見ないと、その数字が何なのかは決まらない。

GeoJSON — 仕様は「楕円体高」と書いてある

RFC 7946 の position の定義は、3つめの要素をこう定めています。

An OPTIONAL third-position element SHALL be the height in meters above or below the WGS 84 reference ellipsoid.
（3つめの要素は、WGS84 基準楕円体からの高さをメートルで表すものとする）

つまり [139.7671, 35.6812, 40.0] の 40.0 は、仕様に従うかぎり楕円体高です。東京駅周辺のジオイド高はおよそ 36〜37m なので、これを標高として地図に載せると山でもないのに数十m浮いた点になります。

ただし実運用は仕様どおりとは限りません。RFC 7946 には「楕円体高では平均海面から離れすぎるので EGM2008 ジオイド基準にすべきだった」という趣旨の errata（正誤情報）が出ており、実装側も標高を入れているものが少なくありません。仕様は楕円体高、現物は標高のことがある——ここが実務でいちばん危ないところです。

KML — 既定では高さが消える

KML は <altitude> の解釈を <altitudeMode> で指定します。

altitudeMode	意味
`clampToGround`	既定値。高さの値を無視して地表に貼り付ける
`relativeToGround`	直下の地表面からの高さ
`absolute`	海面（sea level）からの高さ
`gx:clampToSeaFloor` / `gx:relativeToSeaFloor`	海底基準（拡張名前空間）

実務で効いてくるのは2点です。

altitudeMode を書き忘れると clampToGround になり、せっかくの高さが捨てられる。 座標に 3 つめの値を書いていても、表示上は地形に貼り付きます。「高さを入れたのに反映されない」の大半はこれです。
absolute の「海面」がどのジオイドモデルかは、仕様に書かれていない。 ビューア実装に委ねられているため、cm 級の高さを厳密に渡す用途には向きません。数十cm〜数mの違いは、受け手のソフト次第で出ます。

GPX — `<ele>` の基準は決まっていないが、設計意図は読める

GPX 1.1 のスキーマは <ele> を「Elevation (in meters) of the point」とだけ定義しており、どの面からの高さかを書いていません。一方で GPX には <geoidheight>（WGS84 楕円体面からジオイド面までの高さ）という別要素があり、これは NMEA の GGA センテンスの構成と同じ考え方です。

GGA は「標高」と「ジオイド高」を別々のフィールドに持ちます。GPX がそれを引き継いでいるということは、<ele> には標高（海面基準）が入る前提で設計されていると読むのが自然です。実際、多くの GPS ロガーは受信機がジオイド補正をかけたあとの値を <ele> に書きます。

NMEA 側の読み方はNMEAの緯度経度をどう直すかで整理しています。

日本では何メートルずれるのか

楕円体高と標高の関係はこの1本の式に尽きます。

標高 H ＝ 楕円体高 h − ジオイド高 N

楕円体高・ジオイド高・標高の関係

日本周辺のジオイド高 N はおおむね 30〜40m です。つまり取り違えると、常に数十m ぶん高く（あるいは低く）出ます。誤差ではなくオフセットなので、「なんとなく合っている」ことがありません。そこが救いでもあります。

N は場所によって連続的に変わります。下図は GeoConverter Pro のジオイド差分ヒートマップで、地域ごとの差を色で見たものです。

ジオイド高の地域差を示すヒートマップ

受け取ったファイルの高さを見分ける手順

地形図・標高APIの値と引き算する。 同じ地点の標高を国土地理院の値で引き、差が +30〜40m 付近なら楕円体高です。0 付近なら標高。
海の上の点を探す。 海面付近のはずの点が 30〜40m になっていれば楕円体高です。港湾・海岸線のデータで効きます。
KML は <altitudeMode> を grep する。 書かれていなければ、そのファイルの高さは表示上使われていません。
GeoJSON は作成ソフトを確認する。 仕様は楕円体高ですが、実装は標高のこともあります。仕様だけを信用しない。
列名・フィールド名を残す。 ellH と H を書き分けておけば、次に受け取る人が迷いません。

そろえるときの注意

水平（測地系）と垂直（高さの基準）は別の話です。 WGS84 に統一したからといって、高さがそろうわけではありません。GeoJSON・KML・GPX の水平側の測地系は、それはそれで固定されています。
どのジオイドモデルで引いたかを記録する。 2025年4月の全国標高成果改定で「日本及びその周辺のジオイド2024」が採用されました。同じ地点でも、旧モデルで引いた標高とは値が違います。
往復させない。 楕円体高→標高→楕円体高と戻すと、使ったモデルが違えばそのぶん残ります。元の値を消さずに列を増やすのが安全です。