はてなブックマーク

はじめに https://maps.gsi.go.jp/development/siyou.html より引用、地図タイルのイメージ 地図タイルとは、ズームレベル（≒解像度）別にタイル状に分割された地図データのことです。例えば0/0/0という番地のタイルはhttps://cyberjapandata.gsi.go.jp/xyz/std/0/0/0.pngで得られます。整数値3つからタイルの領域が一意になるのが、地図タイルの利点です。 地図タイルサーバー 地図タイルの作成方法には、①巨大なデータを事前にタイルに分割しておく方法、②リクエストがあった際にそのタイルを作成する方法の、2つがあります。メジャーなのは前者です。立派なサーバーや難しい実装がなく簡単に作成・配信できるためです。 ①は静的タイルなどと呼ばれることがあり、作成方法は以下にまとまっています。 ②は動的タイルと呼ばれ、こちらもい

はじめに AWS LambdaのFunction URLs（関数URL）は、Lambda単体でHTTPSのURLを発行し、HTTPリクエストをトリガーにLambdaを実行出来るようになる、非常に便利な機能です。 API Gatewayと統合せずともLambdaのみでWebAPIを構築出来るようになり、プロトタイピングやマイクロサービスに有用です。 関数URLの制限 ところで、関数URLの実行の認可は、IAMを用いた方法しかありませんでした（IAMロールベースの認可か、認可なししか無かった）。 Cloudfrontをリバースプロキシ的に前段に配置し、関数URLと繋ぐことで、ドメインを当てたりキャッシュを活用したり、便利な訳ですが、その際に上記が問題となります。というのは、CloudfrontからIAMベースのリクエストを行うには、Lambda@Edgeを利用するしかありませんでした（オリジン

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

MapLibre User Group Japanの@Kanahiroです。今回はベクトルタイルサーバーMartinを紹介します。 TL;DR MartinでPostGISのテーブルをベクトルタイルとして高速に配信 glyph/sprteも動的に配信出来るぞ Martin MapLibre傘下の、PostGISバックエンドなタイルサーバーです。特徴は、ベクトルタイルをPostGISのテーブルから動的に作成して配信出来ることです。世はまさにdynamic tiling時代。 今をときめくPMTilesをはじめとして、あらかじめ全てのタイルを作り切っておくアプローチは、配信パフォーマンスの観点では最善です。しかしたとえば頑張って大きなタイルデータを作成したとして、その原典データが更新されてしまったらどうすればよいでしょうか？PMTilesなどのアプローチでは、再度タイルを作り直す必要があります

はじめに LambdaはVPCに配置することが出来る、いわゆる「VPC Lambda」である。Lambdaはせっかくサーバーレスなので、VPCのことはなるべく考えたくないが、RDSなどセキュアな接続が求められるVPC内リソースのことを考慮すると、VPCに配置したくなることがあるだろう（セキュリティグループによるアクセス制御の恩恵を受けられるため）。 ところでLambdaについては、①Lambda単体でHTTPSリクエストを受けられるようになったこと②HTTPを話す任意のコンテナがLambdaで動くことを、それぞれ試してきたところ。 特に①は**VPC Lambdaであっても有効である。LambdaをVPCに配置しても非VPCと遜色なく動けばすごく嬉しいので、試してみる。 VPC Lambda VPC Lambdaは当初、コールドスタートがやたら遅いという問題があったらしいが、2019年に解

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

はじめに 昨今のGIS界隈ではCloud Optimizedが重要なキーワードとなっています。Cloud Optimizedの概要については下記のリンクが詳しいです。 このタイプのデータ形式ではラスターデータのCloud Optimized GeoTIFF(COG)が既に広く使われていて、ベクター形式は群雄割拠という様相です（2023年1月現在）。ここで変わり種として、タイルデータ（ラスター・ベクター含む）に関するCloud Optimized形式としてPMTilesが台頭してきました。本記事ではPMTilesの概要・生成・消費を一貫して紹介します。 PMTilesとは 簡単に言うと、特別なサーバー実装なしに、必要最小限のタイルデータを配信することを可能とするファイル形式です。この説明で「？」となるのは正常です。 たとえばラスターデータのCloud Optimized形式であるCOGについ

はじめに 近年、一気にコモディティ化が進んだベクトルタイルですが、その作り方はエンジニアのノウハウに依るところが大きいのが現状です。ベクトルタイルの生成周りはOSSで構成されているので、ドキュメントを読めば使い方はわかります。ただそこに、経験上いろいろとコツがあることがわかっており、しかしそれが明文化されていない状況です。本記事は、ベクトルタイルの基本的な生成方法から、典型的な特殊ケースにどう対処すべきかなど、網羅的に整理することを目的とします。 ベクトルタイル生成に用いるツール ベクトルタイルは下記のツールを用いて生成できます。 tippecanoe GDAL/OGR PostgreSQL(PostGIS) 上記のうち、手持ちのGISデータをタイル化する際に最も優れているのはtippecanoeです。GDAL/OGRは地物の簡素化に難があります。PostgreSQLではST_AsMVT関

概要 通常、ベクトルタイルはGeoJSONなどから変換した静的なファイルとして配信されることが多いです（.pbfファイルの配信）。パフォーマンスやサーバーのコストの観点ではベストな方法と言えますが、いくつか典型的な問題があります。 変換に大きなコストがかかる（特にplanet級の、タイル数が膨大な場合に問題となる）。 データの追加・削除や更新が苦手 そんなわけで、データベースから動的にタイルを配信出来ることはとても重要です。しかしこのアプローチにもパフォーマンス面などで課題があるため、どの方法をなぜ採用するのか、よく検討する必要があります。 FOSS4Gの世界のデータベースといえばPostGISです。世間では、PostGISのテーブルからベクトルタイルを動的に配信するためのアプリケーションがいくつか実装されています。 t-rex(Rust) tegola(Go) martin(Rust)

はじめに GIS技術においては、GPS測定値をはじめとした一連の経緯度情報を、道路などに「フィットさせる」処理というものがあり、map matchingだとかroute matchingなどと呼ばれます。 最も単純には、ある点があったとしてその最近傍の地物に寄せるという処理になります。しかし下図のとおり、これだけでは「適切な経路」にはなり得ません。一連の点の順序や誤差を考慮したマッチングが必要です。 この問題に対応するには経路検索技術が必要です。調べると自前で経路検索サーバーを立てる方法が出てきたりしますが、これは一般のGISユーザーにとって（あるいは技術者であっても）容易ではありません。一方この処理は「一連の点を入力として、もっともらしい線分を返す処理」と言い換えることができ、これをWebAPIで提供しているサービスは複数あります。 HERE Route Matching Mapbox

2024-06-30追記 本記事の内容は上記リポジトリにて公開されているライブラリに統合されています。簡単に利用できます。 TL;DR MapLibre GL JSのv2.2.0-pre.2で3D-Terrainが実装された MapLibre GL JSのaddProtocol()を使う事で読み込んだタイルデータを加工できる addProtocol()で地理院標高タイルをTerrainRGBへ変換することで、標高タイルを使って3D-Terrainを表示できた MapLibre GL JSと3D-Terrain 3D-Terrainの実装はかなり長い時間がかけられており、早い段階からデモを触ったりしてワクワクしていたものでした。 それが最近マージされ、2.2.0-pre.2でプレリリースとして公開されました。 必要なデータ DEMタイルが必要で、TerrainRGB（もしくはTerrariu

TL;DR JavaScriptとWebAssemblyの間の値渡しには気を使おう（なるべく値のコピーを避けよう）。 JSはとても高速で、単純なループではWASM並の速度が出るので、WASMの使い所はよくよく考えるべき。 はじめに 1000^2級の画像の全ピクセルをループして、（簡単に言うと）RGBA値の最も大きい値を抽出する、という処理をブラウザ上で突然したくなりました。ピクセル数が1,000,000だと、RGBAなので配列長は4,000,000となります。ブラウザで扱いたくないサイズ感です。 ここで、①WASMで高速化、ダメなら②サーバーサイドで計算させる…という算段をして、とりあえずWASMを試してみました。色々チューニングした結果、ブラウザ上で現実的な速度が出ることがわかりました（数十msの世界）。 RGBA値の計算について 本記事では深く説明しませんが、今回やりたい処理は「下記式

日本語テキストを表示する必要がある場合の注意 v2.1.7で日本語フォントのレンダリングの問題が解消されました！ v2.1.6に日本語フォントのレンダリング位置ズレの問題があり、修正済みですがまだリリースされていません#1002。v2.1.7以降のリリースを待ちましょう v2.0.0からv2.1.1にかけて、日本語フォントのレンダリングにバグがあり一切表示されません。v2.1.2で修正される見込み(https://github.com/maplibre/maplibre-gl-js/issues/718) v1.15.2が、日本語フォントを表示出来る最新のバージョンです。日本語フォントが必要な場合は上記修正がリリースされるまではバージョンアップしないほうが賢明です はじめに 昨年にプロプライエタリとなったMapbox GL JSのオープンソースフォークであるMapLibre GL JSのv

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

お知らせ v2で運行頻度図の作成に対応しました はじめに GTFSとは？ General Transit Feed Specification / Wikipedia 正式名称を直訳するなら「交通情報全般の規格」でしょうか、その名のとおり、公共交通機関の時刻表や地理的情報に関するオープンフォーマットです。 昨今のオープンデータ界隈において、GTFSは最もホットな話題のひとつでしょう。GTFSを国内向けに拡張したGTFS-JPが定義されて以降、バス事業者をはじめとした多くの方々の手によりGTFSデータが整備され、オープンデータとして公開されています。 利用上の課題 GTFSデータは機械判読性は高いですが、可視化は容易ではなく使えるツールが限られています（ツール例：https://tshimada291.sakura.ne.jp/transport/gtfs-viewer/）。また、可視化出来

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

更新情報 2020/11/23 5mメッシュへの対応 別称は250, 125...から、250m, 125m...に変更 2020/09/04 以下の2点が修正されました。この事で、一部互換性が失われた箇所があります（コード規則、メッシュ番号）。詳しくはリポジトリのREADMEをご覧ください。 100m、10mメッシュへの対応 分割地域メッシュのコード割り振り規則の見直し（@warenashiさんありがとうございました） TL;DR 日本の標準地域メッシュを生成するPythonモジュールをOSSとして公開しました 50mまでのよく使われる単位のメッシュを生成出来ます 試験的に作成したRust版も含みます 標準地域メッシュとは？ 地域メッシュ（ちいきメッシュ）とは、統計に利用するために、緯度・経度に基づいて地域をほぼ同じ大きさの網の目（メッシュ）に分けたものである。メッシュを識別するためのコ

GSI-VTDownloader ※画像は開発中のものです 本プラグインについて QGIS3.14でネイティブ対応予定となっているなど普及期にあるベクタータイルですが、日本で最も価値あるデータのひとつである国土地理院の「地理院地図」も地理院地図Vector（仮称）提供実験としてベクタータイルが利用可能となっています。 以前紹介したVectorTilesReaderでもベクタータイルを読み込む事はできますが、シンプルなUIで簡単にベクターデータを取得出来るように地理院タイル専用のプラグイン「GSI-VTDownloader」を作成しました。 動作環境 QGIS3.10で開発 macOS、Windowsいずれでも動作します プラグインのインストール まだQGIS公式リポジトリに登載されていないので、上記GitHubリポジトリからzipファイルをダウンロードして手動インストールしてください。 使

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

もくじ COVID-19Hokkaidoデータ編①スクレイピングなどによる初期データ作成←この記事だよ！ COVID-19Hokkaidoデータ編②オープンデータ化＋自動更新 COVID-19Hokkaidoデータ編③完全自動化 はじめに 東京都とCode for Japanにより東京都公式コロナウイルス対策サイトがリリースされ、そのソースコードがなんとGitHubでMITライセンスで公開されました。つまり他の道府県でも「同様のデータを用意できれば」同じように可視化するウェブアプリケーションを作成出来るという事です（実際はサーバーのリソースなども必要になってきますが）。画期的な取組です。 さてそんな訳で、全国各地の動きも活発化し、北海道ではCode for Sapporoや道内IT企業、自治体職員など多彩なバックグラウンドをもつ有志によるJUST道ITというグループが結成され、3月6日に東

はじめに 国土地理院は、2019年7月から「ベクトルタイル提供実験」を実施しています。 gsi-cyberjapan/gsimaps-vector-experiment 地理院地図Vectorでのデータ配信が本旨でしょうが、自分のサイトのMapbox GL JSに表示してみたいなんて気持ちになったりもします。また、地理院のベクトルタイルには「道路中心線」データが含まれており、これは今までオープンデータになった事はないはずです（確か有償提供）。じゃあその道路中心線、ゲットしたいな、という事で本記事ではその過程を示します。 なお本記事ではベクトルタイルとはなんぞや、という説明は省きます。 目標 以下の画像のようにQGISで地理院ベクトルタイルを表示する事を目標とします。 こうなれば外部ファイルへの出力など、煮るなり焼くなり好きに出来ますね。 ベクトルタイル提供実験 データの使用条件などは以下の