Tag:natural=shrubbery　のタグを知りました。

様々な施設にあるshrubbery(植込み植物)に使います。

OSMおける shrubberyは、管理されている植物（木や植物による区切り、庭園」）を示していると推測します。

日本語版の解説サイトは、まだありません。 EN Tag:natural=shrubbery

Geofabrik OSM Inspector

何年か前には、広域森林などがよく壊されていた。 エラーチェックにOSM Inspector をよく使った。 近年は OSM Inspector を使っていない。機能が豊富なので、使いこなすのは簡単ではない。

左上の選択は 「Areas」とする。目下、横浜市泉区をマッピングしているので、そのあたりを 表示してみた。

かなり多くのエラーがある。OSM Inspector でエラーを見つけ、relation とか way などの osm_id を JOSM に入れて、エラーオブジェクトを表示する。

二つのポリゴンで描かれた公園の接合部にエラーがあった。合体させて、一つのポリゴンにした。

boundary=administrativeの一部が欠けていた。このエラーは多くある。 とりあえず、簡単な２件のエラーを修正した。

農地をouter polygonとするマルチポリゴンのエラーも修正した。

OSM Inspector にエラー修正が反映されるのは確か数日後であったと記憶する。

今回、４つのエラーを修正したが、まだ多くのエラーが残っている。 境界線エラーが多いと思われる。

誤って消されたとは限らず、分かる範囲で境界線を描き、不明分が描き残されているのかもしれない。境界線が交差のない閉ループにならなければ、エラーとなる。

道路や河川の県境などは現地確認できるが、詳細な境界線の確認には手がかかる。 残りのエラーのいくつかは後日修正するが、修正できないものもあるだろう。

行政境界線を強調表示する[2024.11.15]

日本地図全体では無数のエラーがある。横浜市泉区では、特に、行政境界線のエラーが多かった。いくつかは修正したが、簡単には修正できないものもある。

エラーが多い場合、国土数値情報を使うことも考えたが、 日本地図全体としては行政境界線エラーは比較的小さい。 OSMデータを使う方が簡単である。

二重境界線の描き方[11月20日]

ポリゴンの境界線の少し内側(長さd)の閉曲線を求める方法として、現在は、 境界線の内側に平行な隣合う線分の交点をつなぎ合わせている。

凸多角形についてはこれでよい。しかし、隣り合う線分の角度が180度を超える と不都合が起きる。360度に近くなると、交点は元の交点とは遠く離れたところにうまれる。 元の交点との距離が長さd を超えるときは、 線分を二つ追加して、この追加線分の交点と元の交点との距離を長さd とすべきであろう。

もう少し簡単に境界線の少し(長さd)内側に、閉曲線を求める方法はないものだろうか。

はじめに

日記機能を使い始めてまもなく３か月、数回書いてみて、使い方がかなり分かってきた。

山歩きでは、しばしば、等高線がほしくなる。 これまではOSM地図を国土地理院地図に切り替えていた。 一度表示した国土地理院のタイル地図画像ファイルはSDカードに保存しているが、 全zoomが保存されているわけではなく、山歩きではスマホの電波も届かないことが多く、 実時間でのダウンロードができず、使い勝手が悪い。

国土地理院の標高タイルについても、事情は同じであるが、 ５ｍメッシュDEMの zoom 15 にあたるため、必要範囲を予めダウンロードしておくこと は容易である。

そこで dem5a を使って、OSM地図に等高線を付け加えることを考えた。

QGISなどを使って、オフラインで等高線を求める記事[3]は他にもあるが、 自分が欲しいのは、自作OSM地図アプリに組み込むプログラムである。 これに関するものは少なかった。

最初に試した簡易プログラム[5]

    void getContour(Bitmap bmp) {
        for (int j = 0; j < 255; j++) {
            for (int i = 0; i < 255; i++) {
                float c = ele[j][i];        // check pixel
                float r = ele[j][i+1];      // right pixel
                float d = ele[j+1][i];      // down
                float g = ele[j+1][i+1];    // diagonal
                int ic = (int)(c/20);
                int ir = (int)(r/20);
                int id = (int)(d/20);
                int ig = (int)(g/20);
                boolean flag = (ic != ir) || (ic != id) || (ic != ig);
                bmp.setPixel(j, i, flag ? 0xffff0000 : 0x00000000);
            }
        }
    }

東京の高尾山の山頂を含む zoom 15 のタイルの等高線を描いた結果を下に示す。 その下に、国土地理院の標準地図タイルを載せた。

プログラムは非常に簡単であるが、ギザギザが目立つ。線の太さは１画素であり、 これより細く見える線は簡単に描けない。

4画素の比較で塗りつぶしは常に右上にしているのがギザギザの原因であろう。 ４画素中、等高線が一番近くを通る画素を塗りつぶすように変えれば、ギザギザは いくらか目立たなくなるかもしれない。

しかし、zoom 16以上をどうするか、簡単な方法を思いつかない。

CONREC A Contouring Subroutine[7]

これは、40年近く前に発表された古い技術である。デジタル地図用ではなく、 CAD(ワイヤーフレームモデル)用かもしれない。

元々はC、Basic、Fortran言語プログラムであったが、その後、多くの人が 色んな言語に移植しているので、実用性は高いと推察される。

文献[7]にアルゴリズムが述べられているが、自分はまだ十分には理解していない。

Java言語に移植したプログラムを Android OS上の自作OSM地図アプリに 組み込んだ。Android Javaと本家Javaでは特にUI回りで互換性がないが、 等高線を求めるアルゴリズムの部分については、何も修正する必要はなかった。

zoom 15

５ｍメッシュの標高タイルDEM5aは zoom 15 の256x256画素の中心点(多分)の 標高を表すものである。座標で言えば、0.5 から 255.5 までとなる。 下の図をよくよく見れば、タイル境界で等高線の途切れがある。 これはあるタイルの最終座標 255.5 と次のタイルの 0.5 の間に１画素分の間隙がある ためである。いずれ、両隣の標高タイルの値を使って、このタイル境界での途切れをなくしたい。

タイル境界での途切れをなくした[2024.10.6]

zoom 15で言えば、座標値 0.5 から 255.5 ではなく、前と後ろに１点を加えて、 座標値を -0.5 から 256.5 とした。

標高タイルはキャッシュするように変えた。 スマホの場合、１画面に最大３ｘ４タイルが表示される。周辺の標高タイルを使うために、 画面全体としては、最大で５ｘ６標高タイルの標高値を使って等高線を算出する。

ファイル読み込み時間は増えるが、等高線算出処理は 256x256配列が 258x258配列に変わるだけで、処理時間の増加は僅かである。

zoom 16以上

zoom 16の場合には、zoom 15の DEM5a を縦横２分割して、 128x128地点の標高データを使って等高線を描くことになる。

zoom 17の場合、DEM5aを縦横４分割して、64x64地点の標高データを使う。

zoom が大きくなるほど、使うデータが少なるため、誤差は大きくなるであろう。 下に、zoom 17、zoom 19 の例を載せた。等高線は乱れはない。

二つの図ではタイル境界での等高線のとぎれもない。 実は、zoom 17の場合、64x64個のデータで等高線を描いているのではなく、 66x66個のデータで等高線を描いている。 zoom 15で言えば、座標値 0.5 から 255.5 ではなく、前と後ろに１点を加えて、 座標値を -0.5 から 256.5 としている。 -0.5～0 および 256.0～256.5 の部分はタイルからはみ出すが、描画されないだけであり、 エラーが起きるわけではない。

zoom 17で言えば、 -1～64、63～128、127～192、191～256 とする。 -１は前の標高タイル、256は次の標高タイルとなる。中間のオーバラップは 同じ標高タイルからのデータ取り出しのため、サポートが簡単である。 したがって、ここでは等高線の途切れが起こらないようにしている。

zoom 17

zoom 19

山頂の標高

等高線とは関係ないが、DEM5a とOSMの natural=peak の ele と 比較するのは簡単である。 1ｍ以内の誤差はいいとして、ほんの少し調べただけでも、5ｍ前後の誤差が散見された。何故だろう。 著名な山では誤差が少ないが、無数の無名の山頂には誤差が含まれているのかもしれない。ただ、一般の人にとっては、数ｍの誤差は問題ではない。

今後の予定

前後の標高タイルに含まれる標高値も使い、タイル境界での等高線とぎれをなくする。 (10月7日に完了)

100ｍ、200ｍといった太い等高線には数値を書き込む(10月8日に完了)。

数値(label)は下図のような書き方は簡単、これでいいであろう。タイル毎、数値毎に、 １回だけ書き込んでいる。

リファレンス

[1] 基盤地図情報1m・5mメッシュDEM　標高データ（数値PNGタイル）
[2] 標高タイルの詳細仕様
[3] 【実習編】非専門家のためのQGIS ～DEMから等高線を描く～
[4] 等高線表示機能（試験公開）
[5] Leaflet で地理院標高タイルから等高線を描いてみる
[6] 地図情報の新たな整備・更新技術の開発－5m メッシュ DEM から地図情報レベル 25000 の等高線を作成する手法の検討（第 1 年次）－
[7] CONREC A Contouring Subroutine
[8] Conrec.java

放送大学の「地理空間情報の活用」第１回番組内で紹介されていました。 自分の生活圏内と出かけ先の地図を盛り立てていきたいです。 アップロード方法？などもわかりませんが…。

・この日記機能を使ってみて２か月半。公開の価値はともかく、自分の記録としては便利である。特に、後から編集できるのがありがたい。

・ゆかりの地(地方)を２か所チェックした。 登録時に正しかったが、今は変わっている情報が目に付く。 OSMの利用サイトでは、登録日を表示しているものがあった。 OSMを使うにはそういう配慮がいるかもしれない。 ポイント情報でいいので、もっと多くの人がこまめに登録、修正してくれる日が来ることを 期待している。

・地方でも、交通量が比較的多い幹線道路脇については、コンビニやガソリンスタンド、 人気の飲食店などはそこそこにマッピングされている。 しかし、今も正しい情報かどうかはチェックしていない。 また、Google Mapに比べれば桁違いに登録が少ない。

・医院などは都会でもGoogle Mapに登録されていないことは珍しくない。 自宅近くでは、歯医者はすぐにGoogle Mapに現れる。 これは歯医者は競争が激しく、自らが登録しているのであろう。 一般の医院はホームページを持つていることは多く、検索では現れるが、 当事者がGoogle Mapに登録することは少ないようである。 Google Mapには、悪い口コミも載るので、登録のメリットがないのであろうか。

以前は建物を追加登録して送信したら、すぐに地図に反映されたのに最近は反映されないように見える。反映に時間がかかっているだけかもしれない

2024年11月30日 日本全体

建物 23819544 / 全地物 41026345 ＝ 58.1％

2024年11月28日

関東

建物 5081819 / 全地物 9092712 ＝ 55.9％

建物 5096929 / 全地物 9116307 ＝ 55.9％[12/07]

2024年11月13日

日本全体

・japan.osm の全40,746,043レコード中、建物レコードは 23,696,293 (58.2%)であった。 ・2か月半前ではjapan.osm の全39,982,313レコード中、建物レコードは 23.230,411 であったので、全体では1.9%、建物は2.0%の増加となる。

建物 23696293 / 全地物 40746043 ＝ 58.2％
procRelation high 160991relations
Relation 出力レコード数＝123635 最大Outer数=2211

関東

・kanto.osmでは全 9,030,910レコード中、建物レコードは 5,054,325(56%)であった。 ２か月半前では、全8,871,868レコード中、建物レコードは 4,966,970(56%)であったので、 全体では1.79%、建物は1.76%の増加となる。

建物 5054325 / 全地物 9030910 ＝ 56.0％
procRelation high 47016relations
Relation 出力レコード数＝27980 最大Outer数=173

2024年9月25日

関西

昨晩までのOSMデータ kansai.osm について

レコード数=6410779, 建物数=3960770(62％), 最大レコード長=77900, 平均レコード長=123.3, 平均タグ長=11.6B, 最大タグ長=650B

という結果を得た。 １か月弱で、総レコード数は 48,467(＋0.76％)、建物レコード数は 37,939(＋0.97％)増えた。 自分の寄与度が大きいが、その数値は求めていない。 人口１万数千人の田舎町をマッピングしたが、田舎では建物数は人口よりも大きい。 農地、住宅内道路なども多く追加した。

2024年8月29日

日本全体

・2024.8.29 時点では、japan.osm の全39,982,313レコード中、建物レコードは 23.230,411 (58%)であった。

関西

・kansai.osmでは全6,362,312レコード中、建物レコードは 3,922,831(62%)であった。

関東

・kanto.osmでは全8,871,868レコード中、建物レコードは 4,966,970(56%)であった。

・関東地方の建物マッピングが若干遅れているというわけではなく、 首都圏はマンションの比率が高いことが影響しているのであろう。 また、農村では住居以外の建物が多く、人口の割には建物の数が多いことも関係しているであろう。

・全レコード数は自作OSM地図でレンダリング対象とするものに限定した値である。

https://youtube.com/playlist?list=PLNqIbmUyA3QfXxh5p2Pp27oc3xrcmvTvr&si=scBaOF2ENq4yXspT　 　 　最近はマイクラのゆっくり実況を見通しています。　 　こういったバーチャル空間でIngressできたら面白くないか？　 　佐山県とか楽しそう。佐山アノマリーとか。　　　VRChatもできたら面白そうですね。ぶいちゃは全く詳しくないので、、、最適なマップがあるかはさておき、バーチャル空間進出の未来とかないですかね。まあできると仮定してみます。 　マイクラとかだったら、、、掲示板死ぬほど作って死ぬほど多重作れそうですね。何が楽しいんだそれ。楽しそう。(どっち) 　舞倉地区第一掲示板から舞倉地区第百掲示板まで作って、舞倉郵便局と舞倉市立図書館を底辺にして百重タケノコ多重とか。楽しそうっすね。舞倉ネザーゲートとか舞倉エンドポータルとかもポータルにしたいですね。 　まあwayspotといえば掲示板の他に郵便局とか、なんかの像とか、神社とか東屋とか公園とか庚申塔とか公民館とか、たくさんあるじゃないですか。チョイスが田舎特有かもしれませんが、MODとかで実現しないですかね？　 　これ考えている人世界で何人居るんだろうか？そもそもIngress未だにやっている人なんかも少ないわけですし。　 　ゲームの中でゲームをやるって、なんかすごいっすね。　 　マイクラ内の道路をスキャナー(スマホ)内で描画しなければならないっていう地道な問題があるな。　 　Ingressとかポケモンgoって道路の描画何に頼ってるんでしたっけ？忘れましたね。　OpenStreetMapでしたっけ？

https://qiita.com/nyampire/items/716bd4bf66a092044c85

　2017/12/1にOpenStreetMapに切り替わったそうです。まずは、バーチャル空間のOpenStreetMapを作ることから始まりそうですね。　 　最近近所のOpenStreetMapが更新されてていいっすねえ。

2024/09/03

　https://note.com/choco__chipu/n/n43408998778c

投稿しました。

　どうも、去年は23kKmw”p”の名で活動してました。23kKmwqです。ingressは青陣営でレベル12です。前は狂ったように住居を追加していましたが、今はWayspotの申請をしまくっています。今のところ37か所申請して、32か所通りました。話はOSMに戻りまして、小字の追加ってどうやるんですかね。。。ここからここまで！という情報がありませんし、どうやってその情報を集めるのか。。。地元でingressやってる知識を使って、今後いろいろと編集していくつもりです。よろしくお願いします～。主に八戸市で活動する予定ですよろしく。

３年前には横浜市北部の青葉区、緑区、瀬谷区の建物を中心としたマッピングを行った。 今回は都筑区、旭区、港北区について行った。

・港北区は既に８、９割終わっており、 東急日吉駅近辺およびその北部など、取り残されていた地域について行った。

・都筑区は地下鉄駅周辺は終わっており、残りの７割程度を行った。

・旭区は駅周辺や相鉄本線以南はほぼ終わっており、残りの８割程度を行った。

・横浜市北部の前に、こどもの国の真北の三輪緑山の建物のマッピングを行った。 確か３年ほど前に誰か(ひょっとすると、自分自身？)が２、３割の建物のマッピングを行ったので、 先に進むことを期待していたが、その後、その気配がないため、残りのマッピングを行った。

2024.9.10

・ゆかりの地(富山県、兵庫県)を見た。５～８年前とあまり変わっていない。 正直なところ少しがっかりした。 日本全体では、OSMデータファイルのサイズは２倍以上に増えているだろう。 大都会のマッピングが進んだのだろう。

・人口１万数千人のゆかりの田舎町をマッピングしてみた。 時間がかかるのは、建物であるが、農地などのマッピングも行った。 住宅内道路はマッピングされていないものが多かった。 建物については近接して農業用小屋や駐車用小屋などがあると、 国土地理院地図では全体がひとつの大きな建物となっており、 オルト地図や Bingの航空地図でも精度が悪く、 ひと繋がりの建物か、分離した複数の建物か判然としないケースがよくある。 全体として都市部に比べると、人口１万人当たりのマッピング時間は、 ３～５倍かかるようだ。

良かった点

・複数の航空写真から吟味してマッピングした

・航空写真だけでもかなりの密度のマッピングが可能だと判明

　→　この結果、国内でも中々お目に掛かれない密度へ（しかも農村部で、おそらく私がマッピングしなければ100年は放置されていたであろう）

反省点

・比較的新しい航空写真を見つけることが思いの外難しかった

・やっぱり現地調査を行なってくれるユーザーが居ないと辛いところがある （コンビニっぽい建物にセブンイレブンのポイントを追加してくれるだけで謎の多幸感に襲われた）

・恐らく必要以上に水路をマッピングした地域がある （先日、青い森鉄道や東北新幹線から田んぼを凝視したが、明らかに田んぼである所を水路にしてそうだなと思った）

・was:buildingタグの建物の削除を行なってしまった （これは私の無知。しかし、首都圏などでこれを一々マッピングしてたらとんでもないことになりそうだと推測）

疑問点

・牧草地と耕作地の違い

→現地調査してくれるユーザーが登場するのを待つしかない（訓練された道民なら分かるのだろうが）

・耕作地はどの程度詳細に描くべきだろうか

→正直、クソデカ耕作地はもちろん、ブロック単位の耕作地もあまり好きではない。しかし、離農が相次ぐ現在では一反一反描画するのは現状をマッピングできているとは言えないとも考えられる。

しかし、災害時に使われることや将来的なことを考慮すると、現状のマッピング方法が好ましいと考えている。

・コンビニやガソリンスタンド、集合住宅っぽいものが航空写真に写っていたら、地図メモで残しておくのは有用か

→今後、現在マッピングしている上尾市で検証したい。

月形町でのノウハウは現在精力的にマッピングしている上尾市などで生かせればなあと思っている。

自分1人だったら正直、モチベーションが怪しかったので協力下さった皆さんには感謝しております。ありがとうございました。

Piebroさんが作成したOpenStreetMap Statisticsを知っていますか？

OSMのchangesetファイルを分析して、様々な角度からグラフを作成してくれるとても有益なツールです。

• https://piebro.github.io/openstreetmap-statistics/
• https://github.com/piebro/openstreetmap-statistics

プロジェクトのREADMEでも、それぞれの国や地域を対象に分析を実施することができる、と示されています。 私のローカル環境で、日本地域を対象にした分析を行うことができたので、手順をまとめておきます。

私の環境

• MacOS
• python 3.9

データの準備

piebroさんのgitリポジトリをローカルへクローンします。
$ git clone https://github.com/piebro/openstreetmap-statistics.git
$ cd openstreetmap-statistics

Homebrewを使って、osmium-toolをインストール
$ brew install osmium-tool

virtual environmentの準備
$ python3 -m venv .venv

必要な依存関係をインストール
$ pip3 install -r requirement.txt

OSM変更セットファイルの入手

pirbroさんのREADMEではtorrentを使っています。

torrentのほうがネットワーク負荷は低いはずなので、可能ならばそちらを使ったほうがよいでしょう。

$ rm $(ls *.osm.bz2)
$ wget -N https://planet.openstreetmap.org/planet/changesets-latest.osm.bz2

対象地域のpolyファイルを入手

Geofabrikのサイトから、対象地域のpolyファイルをダウンロードします。

$ wget -N https://download.geofabrik.de/asia/japan.poly

変更セットファイルの切り出し

polyファイルを利用して、changeset-latestファイルから対象地域を切り出します。

切り出しには以下のスクリプトを使ってください。（Claudeに書いてもらいました）

https://gist.github.com/nyampire/57360f29be2bff4d74d94e3c5bfa3237

shapely1.8.0のインストール。
最新版の 2.0以降だと、依存するソフトが対応しないようです。
$ pip3 install shapely 1.8.0
$ wget -N https://gist.githubusercontent.com/nyampire/57360f29be2bff4d74d94e3c5bfa3237/raw/1fa9ded4126b3282af273469225407847cb38ee7/parse-latest.py

$ python3 parse-latest.py [poly.filename] [input.filename] [output.filename]
$ (sample) python3 parse-latest.py japan.poly changesets-latest.osm.bz2 japan-chansegets.osm.bz2

スクリプトの処理の結果として、この例の場合であれば japan-changesets.osm.bz2 が出力されます。

Notebook用ファイルの生成

続く処理はPiebroさんの手順と同様です。

pvコマンドはあくまでも進捗状況の把握のために使われているため、私は省略しました。

$ rm -r -d temp
$ osmium cat --output-format opl output.osm.bz2 | python3 src/changeset_to_parquet.py temp
$ python3 src/parquet_to_json_stats.py temp

Notebookの更新

ターミナルで以下を実行します。

シェルスクリプトにしてKickしてもよいですが、シェルにそのまま貼り付けても動きます。

 for notebook in $(find src/questions -name calculations.ipynb); do
     jupyter nbconvert --to notebook --execute "$notebook" --output calculations.ipynb
 done

ローカルサーバの起動

ローカルでhttpサーバを起動して確認します。

httpサーバを起動しないと、CORSの関係でグラフが表示できません。

python -m http.server 1010

ブラウザから “https://localhost:1010” へアクセスすると、グラフが表示されます。

なお、httpサーバを起動する代わりに、gitの個人リポジトリ等にPushして、gh-pagesから確認することも可能のはずです。

ただし、これまでの手順だと、remoteがpiebroさんのリポジトリになっています。修正して自分のリポジトリにアップロードするようにしてください。

長らく使っていないため、slackにログインできなかった。（その後、ログインできた。） 記録用としては、日記の方がいいかも知れないので、少し、使ってみよう。 自分が初めてOSMに触れたのは、2015年２，３月である。 ほんの少し、非常勤講師などをやっていたが、余裕がたっぷりできた頃である。 ハイキングには地図がいる。オフライン地図を探し、OSMに出会った。 Google Mapなどに比べると、はるかに内容が乏しいが、オフラインで使えること、 自由にカスタマイズできることが魅力でOSMを使うことにした。 1、2か月で自作OSM地図が完成して、散歩やハイキングの友となった。 １年間10インチWindowsタブレットに自作OSM地図を載せた。 10インチは大きすぎ、１年で８インチWindowsタブレットに変えた。 ３年ほど前から Androidスマホに変えた。 デバッグや自宅利用は ８インチAndroidタブレットを使っている。

この９年間でOSMの情報量は増え、精度も向上している。 旅行、ハイキング、散歩では OSMでさほど不自由は感じない。 観光地に限れば、Google Mapよりも詳細なことがよくある。

ただ、全国均質ではなく、地方にはマッパーがいないため、内容に極端なかたよりがある。

HTMLタグは使えるか？

HTMLタグも使えるようだ。カスタマイズしたOSM地図に国土地理院の標高タイルから 得た標高データを使って等高線を重ねてみた。

参考資料
CONREC A Contouring Subroutine

何ら目新しさも、便利さもないマップで、期待できない。

県内には砂浜が３つある。
１つは市内、もう１つは南の県境、最後１つは北の方。
この前市内のところに行ってきた。
結論から言うと、ちゃんと砂浜ではあったが、あまりおすすめできない場所であった。
数時間滞在すればそのうち出るだろうが、ポケストがないあそこに長時間滞在はしたくない。
なお、南の県境の方はゲット報告を見かけた。
自分はウミディグダはそのうちイベントでばらまかれるのを待とうと思う。

ウミディグダの実装に伴うバイオーム「砂浜」が話題になっている。
砂浜がちゃんと編集されているところは海なし県ではほとんどない。
かつての公園のように簡単にはいかず、難しいところ。

私たちが使っているGoogle mapなどにはかず多くのレイヤーを用いて作られていると学びました。自分でマッピングすることが、日本地図を測量して初めて作った伊能忠敬のようでワクワクしています。ちなみに彼の記念館や屋敷、昔の街並みは千葉県の香取市にあり、「佐原の町並み」として観光地になっています。

小林さんに魅力教えていただきました ありがとうございました 今日からコツコツ始めます

今年の話題と言えば、chatGPTですね。

日常生活では使おうと思うことはほとんどないですが、overpass-turboのクエリを作るのに使ってみたというどなたかの投稿を見て、「なるほどそういうところでも使えるのね」と思い使ってみることにしました。以来いろいろ使っていますので、簡単な紹介を。

overpass-turboのクエリを作る

簡単なものであれば、ウィザードなどを使えばすぐにできますが、ちょっと凝ったことをしようと思うと、よくわからなくなったりして。 chatGPTはoverpass-turboのクエリについても教えてくれました。

例えば、「値が日本語になっているタグを検索するにはどうしたら良いか？」 一回で望むような回答にならなくても、何回か聞き方を変えるなどして答えがわかりました。

例えば、’cuisine’の場合は nwr["cuisine"~"[ぁ-んァ-ン一-龯]"] と書きます。このカッコ内の文字の範囲が日本語の範囲だそうです。

これで値が日本語になっているオブジェクトを検索できました。 これで検索して、”cuisine:ja”に変更したり、”cuisine”の方は英字の値に書き換えたりしてみました。(とりあえず西日本のみ)

プログラムを書く

GTFSやGBFSのファイルをOSMにインポートするために、適切なデータ形式に変換する必要があるのですが、手作業ではとてもじゃないけど無理ですね。

普段はプログラミングに縁がなく素人の自分は、昨年まではネットをいろいろ検索してpythonやGoogle Colaboratoryの使い方を調べながらなんとか少しずつ書いていたのですが、今年からはだいぶん楽になりました。

「こういうデータでこういう処理をしたい」とchatGPTに聞けば、すぐにコードを提示してくれます。 途中までコードを書いてこの先の処理を作りたい時は、途中までのコードとそこから先にやりたいことを書けば、教えてくれます。 自分のデータに合わせてコードを提示してくれるので、非常にわかりやすいですね。

一通り動くコードができあがったら、コード全体をコピペして、「改善すべき箇所があれば教えて下さい」と問えば、より適切なモジュールを使った形や汎用的な書き方を教えてくれます。

これで、素人でも比較的簡単にコードを書くことができるようになりました。

英文作成

インポートの手順の中でwikiページを作成したり、import-MLやコミュニティフォーラムでアナウンスする必要があるので、どうしても英語がついて回ります。

今まではGoogle翻訳などで、日本文を英文に翻訳したりしてなんとか凌いできましたが、英文としてはどうしてもブツ切りで稚拙な感じがするけど仕方ないなと思っていました。

chatGPTを使えば、英文が一通りできた時にそれをコピペして「直すべきところがあれば教えて」と問えば、より自然で文法的にも修正された英文を提示してくれます。

もちろん全部を鵜呑みにすることはできなくて、ちょっと言い回しがおかしいなと思うところは採用しなかったりしますが、これで英文の作成もより良いものになります。

以上、簡単な使用例でした。

削除