2022/05,江端さんの技術メモ

OpenStreetMapから、鉄道情報(芳賀・宇都宮LRT)を引き出して、ダイクストラ計算やってみました。

この投稿の最後に書いた『経路が繋がっていないと、ダイクストラ計算はできないはずなので』を、JOSMを使ってなんとかできないか実験中しています。

JOSMについては、こちらを御参照下さい。

で、こちらの本で例題として出している街のデータを使って実験します(宇都宮のデータはデカすぎるので)。

https://github.com/TomoichiEbata/hirohakama/tree/main/hiro_db の hirohakama.osmを使って実験します。

まず、hirohakama.osm から hirohakama1.osmを複製して、さらに、このhirohakama1.osmを、JOSMにローディングして、ファイル → 保存をします。JOSMに入れるだけで、フォーマットの一部が変更されるからです。

こうしておいて、さらに、hirohakama1.osmのコピー、hirohakama2.osmを作成します。

以後、この2つのファイルを比較することで、作成状況を把握していきたいと思います。

まず、すでにあるノード(node)間を繋いで道路を作ってみます。(小さい□がnodeです)

をクリックして、

この2点間に線を引きます。

で、その後、このhirohakama2.osmをセーブして、hirohakama1.osmと比較してみました。

結果は以下の通り。way id='220736115' に、ref='3813457320'のノードが追加されています(この一行だけ)。

ちなみに、ref='3813457320'のノードの情報は、

<node id='3813457320' timestamp='2015-11-02T07:07:06Z' uid='3057995' user='oini' visible='true' version='1' changeset='35026994' lat='35.5957559' lon='139.4735283' />

となっています。

既存のノード同士をくっ付けるのであれば、結構簡単にできそうです。

では、ノード以外の道路を適当に繋げるとどうなるかを、調べてみます。

で、ノード番号 -101965, -101966 の座標は入っていませんでした(作られていませんでした)。多分ダイクストラやっても、無視されると思います。

見落していました。作られていました(ファイルの最初の方だったので)。

<node id='-101792' action='modify' visible='true' lat='35.59604489421' lon='139.47307912887' />
<node id='-101793' action='modify' visible='true' lat='35.59558383511' lon='139.47265061383' />

ノードを動かしたら、

ちゃんと、ノードの座標も動いていました。

ただ、ノードでない場所(×の部分)とかを動かしてノードを増やしても、先程のようにマイナスのノード番号が出てきて、座標も追加されませんでした。

しかし、ノードの追加はしたいなぁ(今後のことを考えると)

で、"JOSM" "ノードの追加" で検索したら、このページが出てきました。

しかし、ただノードを追加すれば良いってもんじゃない。既存のWAYに埋め込まなれば意味がない。さて、どうしようか。


今考えている、最も安直なアイデアは、

OSMファイルに、ノード番号 -101965, -101966 の座標を手で書き込む、です。

試してみて、上手くいったら、またご報告します。

不要です。座標(ノード)はできていました。現時点の問題は、QGISとかに表示されない、ということです。

私が、人工的に追加したノードの記述は、

<node id='-101792' action='modify' visible='true' lat='35.59604489421' lon='139.47307912887' />

ですが、オリジナルのノードは、

<node id='278288868' timestamp='2015-11-02T07:00:53Z' uid='3057995' user='oini' visible='true' version='4' changeset='35026937' lat='35.5997134' lon='139.4660138' />

と、だいぶ表示形式が違うようです。

JOSMでは表示されますが、QGISでは表示されません。

 

https://help.openstreetmap.org/questions/71446/how-to-get-changes-how-to-commit-only-changed-elements

に、

JOSMは、どの要素が変更されたかを正確に記録しています。アップロード時には、あなたが触っていないオブジェクトはすべて無視されます。タグを追加して後で削除した場合など、例外があるかもしれません。

この情報はOSM XMLファイルにも保存されます。action='modify' と action='delete' の要素だけが、OSM データベースにアップロードされます。

との記載がありました。つまり、本番情報として認識されないのかな、と思っています。

https://wiki.openstreetmap.org/wiki/JA:%E3%83%8E%E3%83%BC%E3%83%89

には、

名前 説明
id 整数(>=1) ノードのIDはノードの中でのみ一意となる。(同じIDを持つウェイが存在しても良い。)一般的なエディターでは、サーバーに保存される前のノードのIDに負数が用いられる。サーバー上のノードのIDは不変であり、既存のノードに割り当てられたIDは将来にわたって変更されない。削除されたノードのIDが最利用されることはない(削除を取り消した場合を除く)。

という記載があるので、少なくとも負数を使うのは、ダメみたい。

近くにある、このNodeとWayを参照してみる。

(0)<tag k='construction' v='tram'/>と記載されていましたので、これを、強制的に<tag k='railway' v='tram'/>に置換する

(1)node id, way idの負数から、マイナスを取って、強制的に正数にする(他のnodeやwayとぶつかっていないことを確認する)

(2)"action='modify'" を削除してみる

(2)<tag k='highway' v='residential' />を追加してみる。

<way id='102395' visible='true'>
<nd ref='101792' />
<nd ref='101793' />
     <tag k='highway' v='residential' />
</way>

で、これでQGISで表示したら、やっと出てきました。

この、手動で変更したhirohakama-21.osmが、postgreSQL+postGISに載るかやってみました。

詳しい手続は、このWebサイトから探していただくか、面倒なら、GISをDIYで作ろう―PostGISを使い倒すを手に入れて下さい。

root@abbab13a933e:/# psql -U postgres
psql (12.5 (Debian 12.5-1.pgdg100+1))
Type "help" for help.

postgres=# CREATE DATABASE hiro_db21;
CREATE DATABASE
postgres=# \c hiro_db21
You are now connected to database "hiro_db21" as user "postgres".
hiro_db21=# create extension postgis;
CREATE EXTENSION
hiro_db21=# create extension pgrouting;
CREATE EXTENSION

hiro_db21=# \dt
List of relations
Schema | Name | Type | Owner
--------+-----------------+-------+----------
public | spatial_ref_sys | table | postgres
(1 row)

hiro_db21=# exit
root@abbab13a933e:/# osm2pgrouting -f /hiro_db/hirohakama-21.osm -c /usr/local/share/osm2pgrouting/mapconfig_for_cars.xml -d hiro_db21 -U postgres

さて、ダイクストラがちゃんと働いているかを調べてみました。

hiro_db21=# SELECT seq, node, edge, cost FROM pgr_dijkstra('SELECT gid as id,
source, target,length as cost, reverse_cost FROM ways',31, 262);
seq | node | edge | cost
-----+------+------+------------------------
1 | 31 | 1 | 0.0002245334340526014
2 | 1 | 3 | 0.000629444702259577
3 | 2 | 356 | 0.00046326006156789223
4 | 262 | -1 | 0
(4 rows)

QGISで調べてみました。

新しい道路で、ダイクストラ計算ができていることが確認できました。

 


P.S. 調べていたら、駅の構成についての説明文を見つけました。後程、参考にさせて貰おうと思います。

 

2022/05,江端さんの技術メモ

JOSMのノードの追加は、「上級者モード」にならないと、メニューが出てきません。

とすると、メニューが見えるようになります。

この理由は、比較的、推測しやすいです。

もし間違って、このようなデタラメな地図が、OpenStreetMapの方に反映されるようなことになれば(アップロードされれば)、世界中の地図がメチャクチャになる、からです。

今、私がやっていることは、自分のシミュレータ用に都合よく地図を改竄(かいざん)していることですから、

ですから、間違っても、この改竄した地図をアップロードしないことに注意しなければなりません。

故に、「上級者モード」ということ ―― なんだろうなぁ、と思っています。

2022/05,江端さんの技術メモ

こんな感じになって、困っていました。

「セキュリティ保護なし」をクリックすると、次の画面が出てきます。

">"をクリックすると、

「証明のパス」を選ぶと、こんな感じになっています。

で、問題は、この「Cisco Umbrella Root CA」が、「信頼されたルート証明機関」に入っていないことらしいです。

ところが、これはインストールして使われるものでもないらしいとか、ネットでは色々書かれていましたが、私は、この「Cisco Umbrella Root CA」を力付くで、インストールしました。

"Cisco_Umbrella_Root_CA.cer"を探し出して、そのファイルを適当なディレクトリにダウンロード。ファイルを右クリックして、「証明証のインストール」を選んで、以下を実行。

 

これで、現在のところ、問題は出てこなくなっているようです。
(セキュリティ的にどうかとも思うのですが、作業できないと困るので)

以上

2022/05,江端さんの技術メモ

「被災後に『購入しなっかったこと』を絶対に後悔するNo.1商品」

で注文した「手回し発電機」が届きました。(早く配達されたようです)

で、先程、動作検証を終えましたので、動画をYouTubeにアップしておきました。

ちなみに、今回は、テロップ作りに、Vrewというソフトウェアを試してみました。

さくっとテロップを入れることができました。

AviUtlより100倍はラクだったと思います。

2022/05,江端さんの技術メモ

(まとめ)地図DBの作り方

「OpenStreetMapから鉄道路線データを落とせない」と愚痴っていたら、社内の人から「OSMに鉄道データ入っていますよ」と言われて、愕然とした件

ところが、問題は、

/usr/share/osm2pgrouting/mapconfig_for_bicycles.xml(自転車)

/usr/share/osm2pgrouting/mapconfig_for_cars.xml(自動車)

/usr/share/osm2pgrouting/mapconfig_for_pedestrian.xml(歩行者)

の3つしか、準備されておらず、鉄道のテンプレートがありませんでした

本当に鉄道を使ったDBはつくれないのかな? と思い、ちょっと試してみました。

こちらに、mapconfig_for_cars.xml があるので、それを見てみました。

私の場合、芳賀・宇都宮LRT と、一般の道路を交えたダイクストラを実現することが目的でしたが、まずは、(道路のことは忘れて)芳賀・宇都宮LRTの情報だけを取り出すことに注力しました。

で、こんなの(mapconfig_for_train.xml)を作ってみました。

ちなみに、"tram"とは路上電車のことで、要するにLRTのことです。

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <tag_name name="railway" id="1">
    <tag_value name="tram"              id="101" priority="1.0" maxspeed="40" />
  </tag_name> 
</configuration>

id="1"> とか、 id="101" priority="1.0" maxspeed="40" /> は、適当に付けました(多分、この辺は適当で良いと思います)。

で、これで何が出てくるかを見ていたのですが、

<tag_name name="railway" id="1">
<tag_value name="tram" id="101" priority="1.0" maxspeed="40" />
</tag_name>
</configuration>

この結果、分かったことは、osmデータの中にある、<tag k="railway" v="tram"/> が含まれている、<way>のタグが取り出されることでした。

<way id="678320671" version="2" timestamp="2021-08-04T10:06:56Z" changeset="0">
		<nd ref="6351482006"/>
		<nd ref="5948014189"/>
		<nd ref="5558816378"/>
		<nd ref="5948014109"/>
		<tag k="bridge" v="yes"/>
		<tag k="railway" v="tram"/>
		<tag k="electrified" v="contact_line"/>
		<tag k="frequency" v="0"/>
		<tag k="gauge" v="1067"/>
		<tag k="maxspeed" v="40"/>
		<tag k="name" v="(仮称)宇都宮ライトレール"/>
		<tag k="railway" v="construction"/>
		<tag k="voltage" v="750"/>
	</way>

 

「OpenStreetMapのデータから鉄道だけを抽出してGeoJSONで出力する方法」を試してみた件

osm.pbfファイルを、osmファイルに変換する方法

で作った、utunomiya-railway-latest.osm を使って、テスト用のDB (test_db)を作っておいて、

osm2pgrouting -f utunomiya-railway-latest.osm -c mapconfig_for_train.xml -d test_db -U postgres

をやってみました(実は、芳賀・宇都宮LRTの情報は、工事中の情報が入っていて、utunomiya-railway-latest.osmには、<tag k="construction" v="tram"/>と記載されていましたので、これを、強制的に<tag k="railway" v="tram"/>に置換しました)。

test_dbをQGISで表示したら、こんな感じで出てきました。

出発点のid = 1 と、

終着点のid = 6 を使って、

ダイクストラ計算を実施してみました。

root@a2b2f7061d88:/tmp# psql -U postgres
psql (12.5 (Debian 12.5-1.pgdg100+1))
Type "help" for help.

postgres=# \c test_db
You are now connected to database "test_db" as user "postgres".
test_db=# SELECT seq, node, edge, cost, agg_cost FROM pgr_dijkstra('SELECT gid as id, source, target,length_m as cost FROM ways',1, 6, false);
 seq | node | edge |        cost        |      agg_cost
-----+------+------+--------------------+--------------------
   1 |    1 |  112 |  968.5677557470831 |                  0
   2 |  105 |    1 |  401.6831070639031 |  968.5677557470831
   3 |    2 |   40 | 1932.1157045557927 | 1370.2508628109863
   4 |   36 |   43 |  91.90138904387848 | 3302.3665673667792
   5 |   39 |   65 | 111.55679510881248 |  3394.267956410658
   6 |   63 |   67 | 159.06195161851494 | 3505.8247515194703
   7 |   65 |   10 | 45.988089536965845 |  3664.886703137985
   8 |    9 |   74 |  25.50249632394143 |  3710.874792674951
   9 |   71 |    8 |  83.08385331794597 | 3736.3772889988927
  10 |    7 |   12 | 27.274859434129702 | 3819.4611423168385
  11 |   10 |   36 |  55.83052462128617 |  3846.736001750968
  12 |   32 |   37 |  48.05528375189372 | 3902.5665263722544
  13 |   33 |    2 |    700.36313814633 |  3950.621810124148
  14 |    3 |   69 | 13.830090594515813 |  4650.984948270478
  15 |   67 |   57 |  269.7483878007764 |  4664.815038864994
  16 |   55 |   13 | 243.90865759717457 |   4934.56342666577
  17 |   11 |   14 |  592.4332460936212 |  5178.472084262944
  18 |   12 |   30 | 197.95743212114834 |  5770.905330356565
  19 |   26 |   44 | 230.11474397115853 |  5968.862762477714
  20 |   40 |   32 |  32.15748444428291 |  6198.977506448872
  21 |   28 |   34 | 128.30514459608628 |  6231.134990893155
  22 |   30 |   46 | 292.51977773825814 |  6359.440135489242
  23 |   42 |   47 |  42.00097102860326 |    6651.9599132275
  24 |   43 |   51 |  317.7487966492082 |  6693.960884256103
  25 |   48 |    3 | 24.366299209335182 |  7011.709680905311
  26 |    4 |    6 |  35.05578311994414 |  7036.075980114646
  27 |   46 |   62 |  269.6784973606185 |   7071.13176323459
  28 |   60 |   71 |  261.6741520558861 |  7340.810260595208
  29 |   69 |   20 | 1312.5430898908662 |  7602.484412651094
  30 |   18 |   72 |  86.31512692490578 |  8915.027502541961
  31 |   70 |    4 |  962.8503750491366 |  9001.342629466868
  32 |    5 |   60 | 131.65329169122384 |  9964.193004516004
  33 |   58 |   59 |  129.1237292961209 | 10095.846296207228
  34 |   57 |   53 |  93.77398873447196 |  10224.97002550335
  35 |   50 |   55 |  200.4322777934951 | 10318.744014237822
  36 |   52 |    7 |  4122.794957245806 | 10519.176292031318
  37 |    6 |   -1 |                  0 | 14641.971249277123
(37 rows)

芳賀・宇都宮LRTの全長は、15kmと聞いていましので、ほぼドンピシャ(14641.971249277123メートル)が算出されていることが分かります。

ただ、現在のnodeの位置は、駅の場所に対応していないので、鉄道情報のosmファイルを手動で作り直す必要はあります(nodeとgeomの変更等)が、その前に、とりあえず今のままの方式で、道路ー鉄道混在のダイクストラができるか、試してみます。

(2時間経過)

こんなのを作って試してみました。

mapconfig_for_cars_tram.xml

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <tag_name name="highway" id="1">
    <tag_value name="motorway"          id="101" priority="1.0" maxspeed="130" />
    <tag_value name="motorway_link"     id="102" priority="1.0" maxspeed="130" />
    <tag_value name="motorway_junction" id="103" priority="1.0" maxspeed="130" />
    <tag_value name="trunk"             id="104" priority="1.05" maxspeed="110" />
    <tag_value name="trunk_link"        id="105" priority="1.05" maxspeed="110" />    
    <tag_value name="primary"           id="106" priority="1.15" maxspeed="90" />
    <tag_value name="primary_link"      id="107" priority="1.15" maxspeed="90" />    
    <tag_value name="secondary"         id="108" priority="1.5" maxspeed="90" />
    <tag_value name="secondary_link"    id="109" priority="1.5" maxspeed="90"/>  
    <tag_value name="tertiary"          id="110" priority="1.75" maxspeed="90" />
    <tag_value name="tertiary_link"     id="111" priority="1.75" maxspeed="90" />  
    <tag_value name="residential"       id="112" priority="2.5" maxspeed="50" />
    <tag_value name="living_street"     id="113" priority="3" maxspeed="20" />
    <tag_value name="service"           id="114" priority="2.5" maxspeed="50" />
    <tag_value name="unclassified"      id="117" priority="3" maxspeed="90"/>
    <tag_value name="road"              id="100" priority="5" maxspeed="50" />
  </tag_name> 
  <tag_name name="railway" id="1">
    <tag_value name="tram"              id="101" priority="1.0" maxspeed="40" />
  </tag_name> 
</configuration>

osm2pgrouting -f utsunomiya.osm -c mapconfig_for_cars_tram.xml -d test_db2 -U postgres

(<tag k="construction" v="tram"/>の<tag k="railway" v="tram"/>の強制置換を忘れずに)

QGISで表示してみたところ、ちゃんとLRTの架橋ができていました。

ただノード接続ができているか不明なので、これから調べてみます(経路が繋がっていないと、ダイクストラ計算はできないはずなので)。駅を手動で作るしかないかな・・・

2022/05,江端さんの技術メモ

pgRoutingのデータベース構成ファイル
/usr/share/osm2pgrouting/mapconfig_for_cars.xml(自動車)
で作った、DBのレコードの意味が混乱してきたので、ちょっと整理

utsu_db=# select * from ways limit 1;
gid | osm_id | tag_id | length | length_m | name | source | target | source_osm | target_osm | cost | reverse_cost | cost_s | reverse_cost_s | rule | one_way | oneway | x1 | y1 | x2 | y2 | maxspeed_forward | maxspeed_backward | priority | the_geom
30797 | 547468496 | 112 | 0.002103460902954004 | 194.17417410447345| | 23363 | 7527 | 5289963314 | 1937141869 | 0.002103460902954004 | 0.002103460902954004 | 13.980540535522088 | 13.980540535522088 | | 0 | UNKNOWN|139.9512784 | 36.5577371 | 139.9532349 | 36.5573415 | 50 | 50 | 2.5 | 0102000020E610000004000000852C66DF707E61400822E6ED6347424033EE17FD727E61403F41182E61474240AD2C76A0737E6140B41D537765474240FD1C7AE6807E61400F9A5DF756474240

sourceとtargetの違いが分からかなったけど、wayの両端の番号、ということで良さそう。

で、今度はnodeの方だけど

utsu_db=# select * from ways_vertices_pgr limit 1;
id | osm_id | eout | lon | lat | cnt | chk | ein | the_geom
----+-----------+------+--------------+-------------+-----+-----+-----+----------------------------------------------------
4 | 264184195 | | 139.95960820 | 36.60870170 | | | | 0101000020E6100000267F411CB57E61408242F3EFE94D4240

が、nodeの情報が書かれているものらしい。

で、ここが重要。

ways_vertices_pgr の"id"  は、waysの"source" または"targetに対応しています。

2022/05,江端さんの忘備録

業務連絡が、転送メールで送られてきます。

Sometimes, business orders come to us by forwarded mail.

普通に、サブジェクトの記載をコピペして、

Many people are support to copy and paste the message of mail subject, like

「今期、明細書執筆予定者への注意点を展開します」

"Please remained to people who plan to write patent application at this quarter"

とだけ記載して転載されてくるメールが多いです。

and they just forward the mail to us.

―― で、これらのメールは、ほとんどの人間にスルーされる、と

"As a result, these mails will be ignored by most readers"

-----

分かります。面倒くさいですからね。

I can understand it, because they are troublesome.

しかも、管理部門のメールは、『悪意でもあるのか』と思えるほど、文面が分かりにくです。

In addition, the mails from management departments are difficult to understand, as if they are malice.

「何をして欲しいのか、さっぱり分からん」という内容です。

The contents are "I don't know at all what on earth do they expect?"

まあ、管理部門の立場としては、そういう文面にならざるを得ないのも分かります。

Well, I might understand that they have to make the contents like that.

恣意的な内容を記載すると、業務内容を誤解されて、後でつっこまれる恐れがあるからです(面倒ごとになる)。

If they try to write the contents on their subjection, it might make the readers trouble.

-----

私も、面倒なので、基本的にはコピペ&スルーをしますが、例外があります。

I also copy, paste and forward the mail to avoid the troublesome, however I have an exception.

『これは、後で、自分に面倒が振りかかってくるな』と直感したものに関してだけは、丁寧に解説をします。

If I feel that "if I do that, another trouble comes to me", I will explain it by my words carefully.

概要を、江端の文言で解説し、該当者をby nameで指定し、締切の日時を強調して記載します。

I am going to write outline of the mail and explain it by my words and indicate the person by name, and emphasize the deadline.

こんな感じです。

As follows

====== メール文面例(ここから) ======

====== Example of the mail (From here) ======

知財部が激怒しています。

The IT department is furious.

『何度説明しても、書式を間違えて提出している』とのことです。

The reason is "we submit the patent application with wrong formats, even they have already had to explain it to us again and again".

本件に関しては、AさんとBさんが、この対象者のようです。

About this mail, I am afraid that Mr.A and Ms.B are objects.

「今月末までに修正を出せ」と言われています。

We have been ordered to re-submit the modification version.

ご希望があれば、私(江端)の方で、ざっくりレビューします

If you hope. I (ebata) will check it roughly.

レビューを希望しない人のことは知りません。その場合は「自力」で知財部と闘って下さい

I don't care people who don't want it. If so, fight the IT department on your own.

江端

Ebata

====== メール文面例(ここまで) ======

====== Example of the mail (To here) ======

まあ、こういう風に書いておけば、ほぼ100%の対応を得られます。

I know that I can get almost 100% responses, if I write the above.

2022/05,江端さんの技術メモ

私が知らないだけなのかもしれませんが(知っている人は教えて欲しいでです)、OpenStreetMapの鉄道のデータは、nodeとwayに変換できません ―― というか、変換する方法を、私には知りません(散々探したんだけど、見つからない)。

#でも、絶対にあると思うんだよなぁ。だって、鉄道と車を融合させる研究、腐るほどあるもん。これらの研究が全部、商用のGISシミュレータ使っているとは思えないんだけどな。

ちなみに私は、PostgreSQL + PostGISを使って、GISのシミュレータを作っています。

で、鉄道を路線の上で走らせたいのですが、鉄道の情報は、進行方向の順番通りには表示してくれません。

ですので、一路線を作る為には、geomをLINESTRINGで、座標単位にバラバラにする必要がありますが、問題は、geomが順番通りに表示れない、ということです。

なので、QGISとかを使って、始点・終点を探して、SQLの結果から、順番を探す、という面倒なことをやらざるを得ません。

QGIS弄っていたら、LINESTRINGの座標を得られる方法をたまたま見つけてしまったので、私の為に記録しておきます。

まず、前提はこの内容です。

「OpenStreetMapのデータから鉄道だけを抽出してGeoJSONで出力する方法」を試してみた件

OpenStreetMapのデータからosmiumを使って鉄道だけを抽出しPostGISに入力する方法(宇都宮周辺の鉄道データを使った例)を試してみた件

まず地物表示のボタンを押します。

次に、LRTの路線の最初の部分をクリックします。

次に、(派生した属性)を右クリックして、「地物をコピー」を選択します。

で、これをエディタなどに、コピペすると

wkt_geom tags
LineString (139.89970149999999194 36.55948450000000349, 139.89955630000000042 36.55885789999999957, 139.8995482999999922 36.55877879999999891, 139.89956340000000523 36.55872629999999646, 139.8996118000000024 36.55866100000000074, 139.89968200000001275 36.55861320000000347, 139.8997737999999913 36.55858750000000157, 139.89987840000000574 36.55857249999999681, 139.90136459999999374 36.55845939999999672, 139.90222030000001041 36.55839509999999848, 139.90252409999999372 36.55837619999999788, 139.90541809999999145 36.55817369999999755, 139.90668009999998844 36.55808119999999661, 139.90870390000000612 36.55791560000000118, 139.90887219999999047 36.55789959999999894, 139.90931180000001177 36.55786609999999826)

てな感じで、geomに含まれる座標がでてきます。

これを、出発地から到着地まで、間断なく続ければ、路線の連続の座標が得られる、という訳です(そこそこ面倒ですが、selectのダンプから探すよりはマシです)。

まあ、それぞれのgeomの先頭と終端は、重複する座標となるので、これを消すなどの処理は必要ですが、取り敢えず、これで鉄道の連続する座標は得られます。

この後、これらの座標をDBに放り込むなり、プログラムにベタ書きするなり、煮るなり焼くなり、色々できると思います。

とりあえず、(emacs使い倒して)csvファイルにしました。

ここからpostgreSQLにインポートするのは ―― 多分、なんかの手段があるだろう、と思う。

ここにありました。

[付録B] 地図の上に100人ほど配置してみる(メモ)

私はPostgreSQLをdockerコンテナの中に作っているので、"docker cp"でコンテナ内にcsvファイルを送り込む必要がありました。

utsu_rail_db=# CREATE TABLE "lrt"(
utsu_rail_db(# seq integer,
utsu_rail_db(# x1 float,
utsu_rail_db(# y1 float,
utsu_rail_db(# distance_m float
utsu_rail_db(# );
CREATE TABLE
utsu_rail_db=# \dt
              List of relations
 Schema |      Name       | Type  |  Owner
--------+-----------------+-------+----------
 public | lrt             | table | postgres
 public | spatial_ref_sys | table | postgres
 public | utunomiya       | table | postgres
(3 rows)
utsu_rail_db=# \copy lrt from '/tmp/lrt.csv' with csv
COPY 286
utsu_rail_db=# select * from lrt;
 seq |     x1      |     y1      | distance_m
-----+-------------+-------------+-------------
   1 | 139.8997015 |  36.5594845 |           0
   2 | 139.8995563 |  36.5588579 | 55.68730112
   3 | 139.8995483 |  36.5587788 | 6.785051714
   4 | 139.8995634 |  36.5587263 | 4.769494948
   5 | 139.8996118 |   36.558661 | 7.734168448
   6 |  139.899682 |  36.5586132 | 8.800865673
   7 | 139.8997738 |  36.5585875 | 10.43856664
   8 | 139.8998784 |  36.5585725 | 11.70055883
285 | 140.0145241 | 36.572845 | 28.22469677
286 | 140.0117433 | 36.57920089 | 623.5656217
(286 rows)
以上

2022/05,江端さんの技術メモ

まず基本形

utsu_db=# SELECT seq, node, edge, cost, agg_cost FROM pgr_dijkstra('SELECT gid as id, source, target,length_m as cost FROM ways',100, 600, false);

seq | node | edge | cost | agg_cost
-----+-------+-------+--------------------+--------------------
1 | 100 | 41 | 27.7006591508524 | 0
2 | 18996 | 21479 | 63.36986127215735 | 27.7006591508524
3 | 6119 | 24518 | 17.68514641657604 | 91.07052042300975

"node"を、"source"というキーで扱えるようにする

utsu_db=# SELECT node as source FROM pgr_dijkstra('SELECT gid as id, source, target,length_m as cost FROM ways',100, 600, false);
source
--------
100
18996
6119

さらに、"source"を検索キーとして、座標x1, y1を出力する

utsu_db=# select x1,y1 from ways where source in (SELECT node as source FROM pgr_dijkstra('SELECT gid as id, source, target,length_m as cost FROM ways',100, 600, false));
x1 | y1
-------------+------------
139.8867509 | 36.5570485
139.8842018 | 36.5574191
139.9070779 | 36.5521857

と思ったけど、この最後のやつ、ダイクストラの順番が壊れることが分かりました。
今、修正の検討中です。


なんとかSQL1文で片付けたかったのですが、どうにも上手くいきませんので、こういうコードで対応するこにしました。

//rows, err = db.Query("select x1,y1 from ways where source in (SELECT node as source FROM pgr_dijkstra('SELECT gid as id, source, target,length_m as cost FROM ways', $1::bigint , $2::bigint , false))", o_source, d_source)
	rows, err = db.Query("SELECT node as source FROM pgr_dijkstra('SELECT gid as id, source, target,length_m as cost FROM ways', 100 , 600 , false)")
	if err != nil {
		log.Fatal(err)
	}
	defer rows.Close()

	x1, y1 := -1.0, -1.0

	for rows.Next() {

		if err := rows.Scan(&source); err != nil {
			fmt.Println(err)
		}
		// 同じ内容の緯度軽度が2行以上表示される場合があるので、"limit 1"で1行に制限
		rows2, err := db.Query("SELECT source, x1, y1 from ways where source = $1::bigint limit 1", source)
		if err != nil {
			log.Fatal(err)
		}

		for rows2.Next() {
			if err := rows2.Scan(&source, &x1, &y1); err != nil {
				fmt.Println(err)
			}
			fmt.Println(source, x1, y1)
		}

	}

まあ、これでダイクストラの順番は守られるようです。

100 139.9308613 36.5364704
18996 139.9305846 36.536582
6119 139.9299632 36.5368549
19331 139.9297872 36.5369272
18976 139.9287925 36.5373735
6120 139.9285284 36.5375426
2595 139.9284283 36.5376435
(中略)
13510 139.8719095 36.558477
13495 139.8713668 36.5586478
556 139.8699614 36.5584908
548 139.868783 36.5585636
600 139.8683731 36.5585918

不細工ですが、仕方ないですね。
(どなたか、"where in" "order by seq" 等で対処する方法を思いつかれた方は、ご連絡下さい) 

SQL文で、ずっと悩んでいるわけにもいきませんので

2022/05,江端さんの技術メモ

どうせ、また、いずれ、同じ内容で探し回ることになると思うので、今、記載しておきます

utsu_db=# SELECT seq, node, edge, cost, agg_cost FROM pgr_dijkstra('SELECT gid as id, source, target, length as cost FROM
ways',100, 600, false);
seq | node | edge | cost | agg_cost
-----+-------+-------+------------------------+-----------------------
1 | 100 | 41 | 0.0002983579226385357 | 0
2 | 18996 | 21479 | 0.0006788280602488493 | 0.0002983579226385357
3 | 6119 | 24518 | 0.00019027162164538517 | 0.000977185982887385
4 | 19331 | 6766 | 0.0010928248868793096 | 0.0011674576045327702
5 | 18976 | 21474 | 0.0003135978634977571 | 0.00226028249141208
6 | 6120 | 24519 | 0.00014212958875406848 | 0.0025738803549098374
7 | 2595 | 29737 | 0.00012339732574262452 | 0.002716009943663906
8 | 6137 | 30391 | 0.00016648675622455585 | 0.0028394072694065305

このcostの単位って何なの? 私は距離が知りたいだけなんだけど? と探し回ったら、なんのことはない、単に"length"→"length_m"にすればよかっただけでした。

utsu_db=# SELECT seq, node, edge, cost, agg_cost FROM pgr_dijkstra('SELECT gid as id, source, target, length_m as cost FROM ways',100, 600, false);
seq | node | edge | cost | agg_cost
-----+-------+-------+--------------------+--------------------
1 | 100 | 41 | 27.7006591508524 | 0
2 | 18996 | 21479 | 63.36986127215735 | 27.7006591508524
3 | 6119 | 24518 | 17.68514641657604 | 91.07052042300975
4 | 19331 | 6766 | 102.22241800670713 | 108.75566683958579
5 | 18976 | 21474 | 30.189796472672 | 210.97808484629292
6 | 6120 | 24519 | 14.342809731736027 | 241.16788131896493
7 | 2595 | 29737 | 13.438709335725413 | 255.51069105070096

ちなみに、agg_costは、距離の足し算の合計値を出してくれるので、便利です。

いちおう、GoogleマップとQGISつかって、大体の距離も合っていたので、大丈夫でしょう。