見出し画像

GISを扱うときの座標参照系(CRS)ってなんだろう

こんにちわ。株式会社レスキューナウ システム部所属の細川です。
最近は業務でGIS(Geographic Information System)データを扱うことが多くなりました。

今回は座標参照系(Coordinate Reference System, 以下CRS)について触れてみようと思います。

QGISでGISデータを表示しようとしたときに、下のような画面が表示されたことはないでしょうか?

よくわからないからとりあえずOK押しがち

もしくは、フロントエンド実装で地図を表示するときのパラメーターにCRSがあるかもしれません。

GIS初心者にとって、おそらく最初に立ちはだかる壁のひとつがCRSじゃないかと思います。私がGISデータを扱い始めて約1年、未だにこのCRSには大いに悩まされています。
QGISのようなGISソフトでシェープファイルやGeoJSONを表示しようとしたときに、うまく表示されない場合はCRSの設定が原因かもしれません。

CRSって何ですか?

Webで検索するとCRSについて専門的で正確な説明がたくさん見つかるので、ぜひそちらに目を通していただきたいのですが、ざっくりと説明するなら「この位置情報はどのルールに基づいているか」という理解で良いと思います。

たとえば、位置の表し方として緯度・経度があります(地理座標系)。そして緯度・経度を決めるための基準はいくつか存在します(測地系)。このため、同じ位置でも基準が違えば緯度経度も変わってきます。
緯度・経度以外で位置を表す方法として、地球を2次元に投影し、ある地点を原点としたときの距離で表す方法もあります(投影座標系)。こちらの方法も、原点の場所や地球を2次元に投影する方法によって、同じ位置でも座標が変わってきます。

このような、位置の表し方や基準、方法の組み合わせを表しているのがCRSです。

実験1: 異なる2つの地理座標系で東京駅を表示してみる

WGS84とtokyoという異なる地理座標系のCRSで東京駅の緯度・経度を求めてみました。

2点の緯度・経度はほとんど同じに見えますが、このズレは実際どの程度のものなのでしょうか? GeoJSONに2つのポイントを追加して、QGISで表示してみます。 GeoJSONではCRSにtokyoを指定しました("urn:ogc:def:crs:EPSG::4301"の部分)。

{
    "type": "FeatureCollection",
    "name": "tokyo_station",
    "crs": {
        "type": "name",
        "properties": {
            "name": "urn:ogc:def:crs:EPSG::4301"
        }
    },
    "features": [
        {
            "type": "Feature",
            "properties": {
                "id": 1,
                "crs": "wgs84"
            },
            "geometry": {
                "type": "Point",
                "coordinates": [
                    139.767180531271634,
                    35.681052253647813
                ]
            }
        },
        {
            "type": "Feature",
            "properties": {
                "id": 2,
                "crs": "tokyo"
            },
            "geometry": {
                "type": "Point",
                "coordinates": [
                    139.770414664973885,
                    35.677812882188846
                ]
            }
        }
    ]
}

QGISでオープンストリートマップにGeoJSONを重ねてみました。赤い点がそれぞれのポイントです。GeoJSONはtokyoのCRSを指定しているので、tokyoで算出したポイントは東京駅上に表示されていますが、WGS84で算出したポイントは少しずれています。 QGIS上で2点間の距離を計測してみると456mと出ました。

GeoJSONで指定するCRSをWGS84に変更してみます("urn:ogc:def:crs:EPSG::wgs84"の部分)。2つのポイントの緯度・経度の値はそのままです。

{
    "type": "FeatureCollection",
    "name": "tokyo_station",
    "crs": {
        "type": "name",
        "properties": {
            "name": "urn:ogc:def:crs:EPSG::wgs84"
        }
    },
    "features": [
        {
            "type": "Feature",
            "properties": {
                "id": 1,
                "crs": "wgs84"
            },
            "geometry": {
                "type": "Point",
                "coordinates": [
                    139.767180531271634,
                    35.681052253647813
                ]
            }
        },
        {
            "type": "Feature",
            "properties": {
                "id": 2,
                "crs": "tokyo"
            },
            "geometry": {
                "type": "Point",
                "coordinates": [
                    139.770414664973885,
                    35.677812882188846
                ]
            }
        }
    ]
}

QGISで表示してみます。今回はGeoJSONのCRSがWGS84なので、WGS84で算出したポイントは東京駅上にありますが、tokyoで算出したポイントは少しずれています。

実験2: 投影座標系と地理座標系で東京駅を表示してみる

今度は緯度・経度(地理座標系)ではなく、Webメルカトルという投影座標系で東京駅の位置を求めてみます。

緯度・経度(35.681052253647813, 139.767180531271634)とは全く違う値です。
ちなみに、緯度・経度の場合の単位は度ですが、投影座標系は距離(メートルなど)です。

これもGeoJSONに追加して、CRSをWebメルカトル("urn:ogc:def:crs:EPSG::3857")で指定しました。

{
    "type": "FeatureCollection",
    "name": "tokyo_st_4301",
    "crs": {
        "type": "name",
        "properties": {
            "name": "urn:ogc:def:crs:EPSG::3857"
        }
    },
    "features": [
        {
            "type": "Feature",
            "properties": {
                "id": 1,
                "crs": "wgs84"
            },
            "geometry": {
                "type": "Point",
                "coordinates": [
                    139.767180531271634,
                    35.681052253647813
                ]
            }
        },
        {
            "type": "Feature",
            "properties": {
                "id": 2,
                "crs": "tokyo"
            },
            "geometry": {
                "type": "Point",
                "coordinates": [
                    139.770414664973885,
                    35.677812882188846
                ]
            }
        },
        {
            "type": "Feature",
            "properties": {
                "id": 3,
                "crs": "pseudo-mercator"
            },
            "geometry": {
                "type": "Point",
                "coordinates": [
                    15558811.366352697834373,
                    4256822.938431431539357
                ]
            }
        }
    ]
}

QGISで表示してみると、東京のあたりとアフリカのあたりにポイントが見えました。 Webメルカトルは原点(0,0)がアフリカのあたりなので、緯度・経度で座標を表した2点が原点のアフリカ付近で表示されたようです。

今回実験したように、GeoJSONやシェープファイルに記載されているCRSと実際のデータのCRSが一致していない場合は、正しい位置に地物が表示されません。

補足ですが、QGISはとても賢いのでCRSが異なる複数のGeoJSONやシェープファイルを内部で変換して重ねて表示してくれます。
例えば、実験1ではベースとなっているオープンストリートマップと、上に重ねたGeoJSONはCRSが異なりますが、ちゃんとオープンストリートマップ上の東京駅の上にポイントが表示されています。

CRSってどこを見ればわかるの?

大抵はGISデータの提供元に記載があると思います。よく使われている単語は座標系、測地系、CRS、Coordinateなどです。 例えば、国土数値情報のダウンロードサービスの場合はこのように記載されています。

まずはCRSを気にせずデータを表示してみよう

これまでの私の経験上、オープンデータをQGISなどで表示するだけであればCRSを神経質に気にする必要はないです。

今回実験1で用いたtokyoは2002年まで使われていた古いCRSなのですが、位置のズレがわかりやすいようにtokyoを使いました。最近作成されたデータはJGD2000・JGD2011が指定されていると思います。
例えば、国土数値情報で公開されているデータの座標系はJGD2000・ JGD2011が大半です。JGD2000・JGD2011はWGS84とほとんど同じなので、JGD2000のデータをWGS84で表示しても実験1ほど大きくずれないはずです。

データがうまく表示できないときにチェックすること

アフリカ付近にデータが表示されるようであれば、データの値をチェックしてみてください。緯度・経度(地理座標系)のデータを投影座標系で表示しようとしているかもしれません。
本来の位置からずれたところに表示されるようであれば、データのCRSとGeoJSONやシェープファイルで指定しているCRSが違っているかもしれません(今回の実験で作成したGeoJSONみたいな感じです)。
QGISなどでポイントやポリゴンを自作するときや、出典が異なる複数のデータをマージするときは要注意です。

まとめ

今回はGISを扱う上で避けては通れないCRSについて簡単にまとめてみました。私の経験上、QGISでデータがうまく表示されないときは大体CRSが原因なので、GISを扱うならCRSの存在くらいは知っておいたほうがいいかもしれません。
今回は触れていませんが、地図を描画するときに歪みを考慮しないといけない場合や、距離や面積の算出など高度な処理を行うときはCRSの変換が必要になってくる場合があります。
ここまでくると、GIS初心者の域を超えたと言ってもいいのではないでしょうか。

最後に

現在、レスキューナウでは、災害情報の提供、災害情報を活用した安否確認サービスなどのWebサービスの開発エンジニアを募集しています!
社員・フリーランスに関わらず、参画後に安心してご活躍できることを目指し、応募された方の特性・ご希望にマッチしたチームをご紹介します。
ちょっと話を聞いてみたい、ぜひ応募したい、など、当社にご興味を持っていただけましたら、お気軽にエントリーください!!