2019年12月5日(木)に開催された「MySQL Technology Cafe #6」での発表資料です。 https://oracle-code-tokyo-dev.connpass.com/event/147283/
こんにちは。@onunuです。本記事はMySQL casual AdventCalendar 17日目の記事です。 本記事ではMySQL8で大幅に強化されたGISデータ周りのtipsについて触れたいと思います。ある程度尽くされた話題ではありますが、主にアップデートされた機能について言及していこうと思います。みなさまの快適なMySQLライフの一助になれば幸いです。 なお、各所にある例や参考のクエリは以下の環境で確認しています。 また記事の内容に誤りがございましたら、コメント欄かTwitterなどのDMにてご教示いただけますと幸いです。 GISデータとMySQL MySQLにおけるGISデータ GIS(Geographic Information System)とは地理情報や空間に関するデータをコンピュータ上で取り扱うためのシステムをさします。MySQLはOGC(Open Geospatial
【MySQL】Geometry型で位置情報(座標)を扱うMySQLで位置情報(座標)を扱う場合には、Geometry型という便利な型があります。 Geometry型のカラムには、GeomFromTextでデータを作成して保存することになり、 以下の様な形式でSQLクエリを組み立てます。 INSERT INTO テーブル名 (カラム名) VALUES (GeomFromText('POINT(経度 緯度)')); ※経度と緯度の間は、半角スペースで区切ります。 例えば、 テーブル名「tbl_location」、カラム名「latlng」とすると、このようなSQLクエリを実行することになります。 INSERT INTO tbl_location (latlng) VALUES (GeomFromText('POINT(139.767125 35.681236)')); ここまでは問題ないですね。
今回から2回に分けて、位置情報をDatastoreに格納する方法をいくつか紹介します[1]。 数値型で保存する 緯度経度の情報をデータベースへ格納するときに、もっとも簡単な方法が数値型として保存する方法です。緯度経度がとりうる値の範囲は、以下の通りですので、システムに必要な小数点以下の数字を考慮して型を決めましょう。 はてなフォトライフでは、写真に緯度経度のメタ情報を設定することができますが、高精度な緯度経度情報は必要ないので、型を以下のように指定しています。 latitude decimal(7,4) longitude decimal(7,4) decimal(7,4)という指定は、10進数で7桁のデータで、小数点以下は4桁まで格納するというものです。 あるオブジェクトの緯度経度を保存し、表示するだけならこれだけで十分ですが、位置情報を中心に扱うサービスになると、格納したデータを緯度
このテーブルのように浮動小数点を扱える型でも緯度経度は管理でき、Geometry型を使って位置情報を管理する必要はない。 しかし、システムの要件によってはGeometry型の方がよい場合もあるため、使用用途を紹介しようかと思います。 メリット・デメリット ※使ってみての感想 メリット 地点間の距離を求めることができる これに尽きると思います。ただ距離を求めるだけではなく、「求めた距離内の〇〇を抽出」「自分の位置から最短の距離にある〇〇を探す」など応用が可能である。 デメリット 他の型と違って特殊な使い方になる 他の型のように単純なINSERTやSELECTは使用できないので、MySQL上で実行できる形式にSQLを作成する必要がある。 MySQL上で直接実行する場合は問題ないかもしれないが実際に運用するシステムでそんなことをするはずはない。 何らかの言語やフレームワークを使用して画面等を生成
はじめに MySQL8.0では位置情報に関する機能が充実した...という情報を見かけたので、試しにGeometry型というデータ型を使って、位置情報を格納するテーブルを作ってみることにしました。 ※GIS関連は全く詳しくないので、誤りがありましたらご指摘頂けると幸いです。 使用した環境 OS CentOS7.7(1908) RDBMS MySQL8.0.19 テーブルの作成 駅の位置を表すstationというテーブルをnkojimaデータベース内に作成しました。 位置情報はlocationというGeometry型のカラムに持たせています。 位置情報を表すデータ型はGeometry以外にも幾つか用意されており、以下に示したものは「OpenGIS クラスに対応するデータ型」となっています。 POINT:地点を表す。 LINESTRING:地点間を直線で結んだ線分を表す。 POLYGON:多辺の
最近、業務ではなく余暇に複数人で地図系開発をしているため、開発者の構築可能環境が揃えられずバックエンドが選べない状況でした。 なのでバックエンドを抽象化しないといけなかったのですが、その結果Web開発系の主要3空間DBでの空間検索記述差がわかったので簡単にまとめておきます。 座標値からのGeometryオブジェクトの作成 GeomFromTextで当然…と思ってましたが、PostGISだと通らなくなってます。 PostGISでは空間系関数は頭にSTをつけることで統一したよう。 頭にSTをつけた関数については、spatialiteも対応してますし、mysqlは最新の5.6でも未対応なものの、後述の通り関係性記述の関数では(既存関数との互換性のためとはいえ)ST_系を出してきているので、将来的にはST_系で統一されるものと思います。 蓄積済みデータに対する、検索クエリの差 蓄積済みデータに対し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く