2022/05 | こぼれネット

pgr_dijkstra()で算出したノードの座標を得る方法

2022年7月1日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文で、ずっと悩んでいるわけにもいきませんので

------

その後、この本のことを思い出して、p.34の記載を参考にして、やってみました。

utsu_tram_db3=# SELECT seq, node, ST_AsText(b.the_geom) AS "Coordinates" FROM pgr_dijkstra('SELECT gid as id, source, target, cost FROM ways', 2, 59, directed:=false) a INNER JOIN ways b ON (a.node = b.gid) ORDER BY seq;

1 | 2 | LINESTRING(140.01202169824 36.57871025496,140.01210960589 36.57850940596)
2 | 3 | LINESTRING(140.01210960589 36.57850940596,140.0145021 36.5730429,140.0146136 36.5727757,140.0147074 36.5725284,140.01472847292 36.57242810487)
3 | 6 | LINESTRING(140.01472847292 36.57242810487,140.01474259746 36.57236088004)
4 | 7 | LINESTRING(140.01474259746 36.57236088004,140.0147498 36.5723266,140.01474930095 36.57229596036,140.0147445 36.5720012,140.0147357 36.5718519,140.0147215 36.5716942,140.0146525 36.5713687,140.0146383 36.5712934,140.0142569 36.5705335,140.0132318 36.5684315,140.0125081 36.5670258,140.0114588 36.5649136)
5 | 41995 | LINESTRING(140.0114588 36.5649136,140.0113901 36.5648283,140.0112966 36.5647907,140.0112113 36.5647891,140.0109652 36.5648276,140.01083814578 36.56486337469)
6 | 10 | LINESTRING(140.01083814578 36.56486337469,140.01068264711 36.56490715847)

(攻略)

というところまでできました。
で、これを参考にして、

utsu_tram_db3=# SELECT seq, source, edge, x1, y1 FROM pgr_dijkstra('SELECT gid as id, source, target, cost FROM ways', 2, 59, directed:=false) a INNER JOIN ways b ON (a.edge = b.gid) ORDER BY seq;
seq | source | edge | x1 | y1
-----+--------+-------+-----------------+----------------
1 | 2 | 39626 | 140.01202169824 | 36.57871025496
2 | 3 | 39627 | 140.01210960589 | 36.57850940596
3 | 6 | 42190 | 140.01472847292 | 36.57242810487
4 | 7 | 58678 | 140.01474259746 | 36.57236088004
5 | 41995 | 48370 | 140.0114588 | 36.5649136
6 | 10 | 42191 | 140.01083814578 | 36.56486337469
7 | 11 | 42192 | 140.01068264711 | 36.56490715847
8 | 14 | 39629 | 140.00672391747 | 36.56601660123
9 | 16 | 42193 | 140.00534360203 | 36.56639931881
10 | 18 | 39631 | 139.99881746427 | 36.56760356174
11 | 20 | 42194 | 139.99785322163 | 36.56762649318
12 | 22 | 42195 | 139.99322640365 | 36.56769789956
13 | 23 | 42197 | 139.99279862059 | 36.56770561742
14 | 26 | 39632 | 139.9873020073 | 36.56744076372
15 | 27 | 58694 | 139.98637655778 | 36.56719243017
16 | 42011 | 58693 | 139.9849076 | 36.5669615
17 | 42010 | 59395 | 139.9834987 | 36.5659784
18 | 42653 | 58677 | 139.9833653 | 36.5651397
19 | 41994 | 58676 | 139.9831305 | 36.5639836
20 | 41993 | 58675 | 139.9828407 | 36.5628279
21 | 41992 | 48369 | 139.9823791 | 36.5562514
22 | 30 | 58674 | 139.98257030036 | 36.55573422149
23 | 41991 | 48368 | 139.9826931 | 36.5551828
24 | 31 | 39646 | 139.98315132981 | 36.55393844125
25 | 62 | 39633 | 139.98318348014 | 36.55383009795
26 | 34 | 39634 | 139.98429467116 | 36.5475784165
27 | 36 | 44770 | 139.97637588623 | 36.54492018008
28 | 33441 | 59396 | 139.9758737 | 36.5448171
29 | 42654 | 58691 | 139.97571 | 36.5447853
30 | 42008 | 58673 | 139.9727346 | 36.5443785
31 | 41990 | 58692 | 139.9723398 | 36.5443964
32 | 42009 | 58689 | 139.9719943 | 36.5444584
33 | 42006 | 58690 | 139.9688728 | 36.5456984
34 | 42007 | 58683 | 139.9684653 | 36.5458879
35 | 42000 | 58682 | 139.9656822 | 36.5472156
36 | 41999 | 58688 | 139.9644358 | 36.5478259
37 | 42005 | 48960 | 139.9641365 | 36.5479761
38 | 33444 | 58681 | 139.96349045574 | 36.54828227973
39 | 41998 | 58672 | 139.9619295 | 36.5490366
40 | 41989 | 58671 | 139.9600165 | 36.5499581
41 | 41988 | 58846 | 139.9540272 | 36.5527689
42 | 42143 | 59676 | 139.9519912 | 36.5538036
43 | 42943 | 59406 | 139.9492115 | 36.5546546
44 | 42665 | 48588 | 139.9490753 | 36.5546663
45 | 38 | 58685 | 139.94481625362 | 36.5547848398
46 | 42002 | 58684 | 139.9412636 | 36.5548806
47 | 42001 | 58680 | 139.940733 | 36.5548939
48 | 41997 | 48373 | 139.9399581 | 36.5549218
49 | 39 | 58669 | 139.93905845231 | 36.55494655098
50 | 41986 | 59675 | 139.9384363 | 36.5549609
51 | 42942 | 59674 | 139.9380896 | 36.5549625
52 | 42941 | 58687 | 139.9368167 | 36.5558301
53 | 42004 | 58686 | 139.936282 | 36.5567211
54 | 42003 | 48374 | 139.9353468 | 36.5569036
55 | 41 | 39637 | 139.92919004082 | 36.55704773078
56 | 44 | 39639 | 139.92333810575 | 36.55725460701
57 | 46 | 44769 | 139.9223235539 | 36.55728625609
58 | 33440 | 39640 | 139.9182188 | 36.5574198
59 | 48 | 39641 | 139.91623289881 | 36.55749040041
60 | 49 | 60589 | 139.9150276012 | 36.55753526085
61 | 43716 | 60590 | 139.9137825 | 36.5575688
62 | 43717 | 48847 | 139.9092969 | 36.5578313
63 | 52 | 39643 | 139.90814263916 | 36.55792109617
64 | 54 | 39644 | 139.90721660195 | 36.55798632222
65 | 56 | 42199 | 139.90390213698 | 36.55824095683
66 | 57 | 39645 | 139.90305460077 | 36.55830618413
(66 rows)

で、やっとできました。soruceのところは、nodeだのedgeだの入れてみましたが、sourceが正解のようです。なお最後のnode 59は出てきません。edgeなので、終端は表示されない、ということでしょう。

エクセルで、x1,y1を表示してみました。

このSQL文の意味ですが、こんな感じです。

SELECT
seq, # ダイクストラの計算結果"a"から出てくる"seq" ("a.seq"と記載してもいい)
source, # ダイクストラの計算結果"a"から出てくる"source"("a.source"と記載してもいい)
edge, # ダイクストラの計算結果"a"から出てくる"edge"("a.edge"と記載してもいい)
x1, # ダイクストラの計算結果"a"から出てくる"x1"("a.x1"と記載してもいい)
y1, # ダイクストラの計算結果"a"から出てくる"y1"("a.y1"と記載してもいい)
# の4つを表示してね
FROM
pgr_dijkstra('SELECT gid as id, source, target, cost FROM ways', 2, 59) a
# ダイクストラの計算結果(テーブル扱い)を"a"とする
INNER JOIN ways b
# "ways"のテーブルを"b"とする
ON
(a.edge = b.gid)
# "a"の"node"の値と、"b"の"gid"の値が一緒の場合
ORDER BY
seq;
# 出力結果をseqの値でソートする

で、注意ですが、上記のedgeとnodeを取り違えると、こんな感じになってしまいますので、注意して下さい。

宇都宮ライトレールに優先的に乗車させるような、ダイクストラをどうやって作ろうか？

2022年6月1日2022/05,江端さんの技術メモ

wayを取るには、以下のコマンドを使う

utsu_tram_db=# select * from ways where name = '(仮称)宇都宮ライトレール';

で、宇都宮ライトレールのwayが取れることが分かったので(誰か知らないけど、コメント入れてくれた人、ありがとう)、あとは、updateコマンドで、costとreverse_costを、小さく(1/3くらい？)すればいけそう。

SQL文の書き方を調べよう。

いちいちDockerの中に入るのが面倒なので、windows10からpsqlでログインします。

C:\Users\ebata>psql -U postgres -p 15432
Password for user postgres:
psql (13.4, server 12.5 (Debian 12.5-1.pgdg100+1))
Type "help" for help.

で、江端が変態的改造した宇都宮ライトレールのテーブルにコネクションします。

さあ、道から乗って、LRTに乗って、橋を渡って、道に下りられるか？(道路と鉄道の強制マージの件)

postgres=# \c utsu_tram_db
psql (13.4, server 12.5 (Debian 12.5-1.pgdg100+1))
You are now connected to database "utsu_tram_db" as user "postgres".

utsu_tram_dbに直接改造を加えるのは怖いので、utsu_tram_db2 というレプリカを作っておきましょう。

Dockerの中にある、postgreSQLのpostGISのDBを、丸ごとコピーする方法

でも、できるのですけど、面倒なのでWindows10から直接できないか、試してみました。

【PostgreSQL】Windows に psql コマンドだけをインストールする手順

C:\Users\ebata>createdb -U postgres -p 15432 utsu_tram_db2
Password:

で、

utsu_tram_db=# \l
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges
---------------+----------+----------+------------+------------+-----------------------
utsu_tram_db | postgres | UTF8 | en_US.utf8 | en_US.utf8 |
utsu_tram_db2 | postgres | UTF8 | en_US.utf8 | en_US.utf8 |
(12 rows)

あ、できている。凄い。(というか、createdbが使えた、といのも驚いたが)

で、MinGWのシェルから、

$ pg_dump -U postgres -p 15432 -Ft utsu_tram_db | pg_restore -U postgres -p 15432 -d utsu_tram_db2

Password:
Password:

を実施したら、passwordを2回聞かれました(珍しい)。確認したらレプリカ(utsu_tram_db2)が、できていました。こっちで、色々テストします。ちなみに、command.comではパイプ"|"が使えないみたいです。(ちなみに、pg_dump, pg_restoreが使えたことにも驚いたが)

さて、utsu_tram_db2を使って、costと、reverse_costの値を変えてみます。

現在は、こんな感じ。

utsu_tram_db2=# select cost, reverse_cost from ways where name = '(仮称)宇都宮ライトレール';
cost | reverse_cost
------------------------+------------------------
0.007490415761689246 | 0.007490415761689246
0.00040536575640007835 | 0.00040536575640007835
0.01932049990115761 | 0.01932049990115761
0.008712540173673398 | 0.008712540173673398
0.007102267864215258 | 0.007102267864215258
0.00684623081981901 | 0.00684623081981901
0.004139533878435676 | 0.004139533878435676
0.005101717091578247 | 0.005101717091578247
0.004405341713757751 | 0.004405341713757751
0.004776545712421741 | 0.004776545712421741

コスト値を小さくすると、ダイクストラで宇都宮ライトレールが選ばれやすくなる(はず)だけど、いくつくらいがいいかなぁ。1/3か 1/5か。とりあえず、効果が見たいから、1/5くらいで書き換えやってみよう。

utsu_tram_db2=# update ways set cost = cost * 0.2 where name = '(仮称)宇都宮ライトレール';
UPDATE 129

さて、どうなっているかな

utsu_tram_db2=# select cost, reverse_cost from ways where name = '(仮称)宇都宮ライトレール';
cost | reverse_cost
------------------------+------------------------
0.0014980831523378492 | 0.007490415761689246
8.107315128001567e-05 | 0.00040536575640007835

まだ、reverse_costの方には手を出していないので比較ができるはず。

0.0014980831523378492 ÷ 0.007490415761689246 = 0.2

おお、できている。

では、reverse_costの方も変えてしまおう。

utsu_tram_db2=# update ways set reverse_cost = reverse_cost * 0.2 where name = '(仮称)宇都宮ライトレール';
UPDATE 129

よし、これにて、cost, reverse_costの強制変換処理を完了

ちょっと問題はあるようですが、動いているようです。

「自作の「金融商品自動売買ツール」をGo言語で作ってみる」のサンプルコード(その2)

2022年5月30日2022/05,江端さんの技術メモ

package main

import (
	"fmt"

	"github.com/PuerkitoBio/goquery"
)

func main() {

	q, err := goquery.NewDocument("https://kabutan.jp/stock/?code=6501")
	if err != nil {
		fmt.Println("get html NG")
	}

	name := q.Find("div.company_block > h3").Text()
	fmt.Println(name)

	code_short_name := q.Find("#stockinfo_i1 > div.si_i1_1 > h2").Text()
	fmt.Println(code_short_name)

	market := q.Find("span.market").Text()
	fmt.Println(market)

	unit_str := q.Find("#kobetsu_left > table:nth-child(4) > tbody > tr:nth-child(6) > td").Text()
	fmt.Println(unit_str)

	sector := q.Find("#stockinfo_i2 > div > a").Text()
	fmt.Println(sector)

}

「自作の「金融商品自動売買ツール」をGo言語で作ってみる」のサンプルコード(その1)

2022年5月30日2022/05,江端さんの技術メモ

package main

import (
	"fmt"
	"log"
	"net/http"

	"github.com/PuerkitoBio/goquery"
)

func main() {
	// Request the HTML page.
	res, err := http.Get("http://kobore.net")
	if err != nil {
		log.Fatal(err)
	}
	defer res.Body.Close()
	if res.StatusCode != 200 {
		log.Fatalf("status code error: %d %s", res.StatusCode, res.Status)
	}
	// Load the HTML document
	doc, err := goquery.NewDocumentFromReader(res.Body)
	if err != nil {
		log.Fatal(err)
	}
	doc.Find("input").Each(func(i int, s *goquery.Selection) {
		// For each item found, get the title
		title, _ := s.Attr("type")
		fmt.Printf("Review %d: %s\n", i, title)
	})
}

select * from ways where source =0

2022年5月29日2022/05,江端さんの技術メモ

source：始点ノードの識別子

target ：始点ノードの識別子

| source_osm | target_osm |

costcost ：エッジにかかる重み(負の重みは、エッジがグラフに挿入されるのを防ぎます)

reverse_cost：エッジの反対方向のためのコスト。

x1 ：エッジの始点のx座標

y1 ：エッジの始点のy座標

x2 ：エッジの終点のx座標

y2 ：エッジの終点のy座標

| maxspeed_forward | maxspeed_backward | priority
| the_geom

・id ：エッジの識別子 [int4] ・・・・source ：始点ノードの識別子 [int4] ・・・・ｔａｒｇｅｔ：終点ノードの識別子 [int4] ・・・・cost ：エッジにかかる重み(負の重みは、エッジがグラフに挿入されるのを防ぎます)。 [float8] ・・・・reverse_cost(オプション) ：エッジの反対方向のためのコスト。

さあ、道から乗って、LRTに乗って、橋を渡って、道に下りられるか？(道路と鉄道の強制マージの件)

2022年5月28日2022/05,江端さんの技術メモ

JSONで、芳賀・宇都宮LRTの路線と一般道を、停車駅の単位で接続して、LRTを道路扱いする方法にしてみました。

で、昨日の実験結果の方法

街の中に道路を作って、ダイクストラ計算ができるか試してみた件 ―― JOSMを使った道路追加の方法を試す

を使って、utsunomiya-lrt-latest-1-no_modify.osmを手動で作成しました。

そんで、もって、

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

を使って、道路とLRTのみのDBを作りました。

root@a2b2f7061d88:~# osm2pgrouting -f /utsu_db/utsunomiya-lrt-latest-1-no_modify.osm -c /utsu_db/mapconfig_for_cars_tram.xml -d utsu_tram_db -U postgres

これで、私は、LRTの架橋を使って、「さあ、道から乗って、LRTに乗って、橋を渡って、道に下りられるか？」を試してみます。

ターゲットとしたノードは、駅近くを選びました。

では始点の方を拡大します。

ダイクストラ計算の結果

postgres=# \c utsu_tram_db
You are now connected to database "utsu_tram_db" as user "postgres".
utsu_tram_db=# SELECT seq, node, edge, cost, agg_cost FROM pgr_dijkstra('SELECT gid as id, source, target,length_m as cost FROM ways',14779, 14266, false);
seq | node | edge | cost | agg_cost
-----+-------+-------+--------------------+--------------------
1 | 14779 | 42200 | 42.785394484227744 | 0
2 | 34 | 19785 | 7.618791492678159 | 42.785394484227744
3 | 35 | 48595 | 389.45546677917343 | 50.4041859769059
4 | 42701 | 59452 | 12.262652109536079 | 439.85965275607936
5 | 42982 | 59725 | 270.535671188774 | 452.12230486561543
6 | 42176 | 58890 | 215.43378099396782 | 722.6579760543895
7 | 42004 | 58695 | 620.3511502405348 | 938.0917570483573
8 | 42005 | 58696 | 199.48206530565716 | 1558.442907288892
9 | 42017 | 58710 | 162.9099908343982 | 1757.9249725945492
10 | 33448 | 48969 | 102.43865451629547 | 1920.8349634289475
11 | 14266 | -1 | 0 | 2023.273617945243
(11 rows)

QGISで書いてみたら、こうなった

あれ、LRTの架橋を通っていないぞ。これ前にも見たことがあるな。これかな

postGISのpgr_dijkstra()を試しているけど、理解できない現象が発生している件

revese_costを入れたら、ちゃんとLRT架橋を通過しました

よし、これで、道路と鉄道の強制マージに目処が付きました。

ちなみに、OpenStreetMapに実装されていなかった部分を、JSONで道路工事をした結果、ちゃんと開通していることを確認しました。

街の中に道路を作って、ダイクストラ計算ができるか試してみた件 ―― JOSMを使った道路追加の方法を試す

2022年5月27日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とかに表示されない、ということです。

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

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

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

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を参照してみる。

(宇都宮レールウェイの場合)<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で調べてみました。