2024,江端さんの技術メモ

背景

現在、tomioka_db_cを中心にコーディングを展開していますが、とみおかーとのルートの入っていない(バスのルートだけが入っている)地図が必要となりました。

課題

JSONからとみおかーとのルートを取り除いて地図を作り直すこともできますが、ノード番号ずれが発生するという問題が生じます

課題を解決する手段

つまるところ、とみおかーとのルート情報だけを、tomioka_db_cから取り除ければいいのです。

実施例

まず、

ebata@DESKTOP-P6KREM0 MINGW64 ~
$ createdb -U postgres -h 192.168.0.23 -p 15432 tomioka_db_c_trial
Password:
ebata@DESKTOP-P6KREM0 MINGW64 ~
$ pg_dump -U postgres -h 192.168.0.23 -p 15432 -Ft tomioka_db_c | pg_restore -U postgres -h 192.168.0.23 -p 15432 -d tomioka_db_c_trial
Password:
Password:
で、実験用のtomioka_db_c_trialを作成しました。
QGISで除去手術の状況を把握する為に、tomioka_db_c_trialを見える状態にしました。

現時点で分かっていること

(1)とみおかーとルート用のnode番号は、1~181の連番である。

(2)とみおかーとルート用のwayには、"TomioCart"の属性情報が入っている

(3)これを、単に、

public | ways | table | postgres
public | ways_vertices_pgr | table | postgres
からDeleteすれば良いのかどうかは不明
ですが、やってみるしかない。

nodeの削除(最初のトライアル) →失敗

DELETE FROM ways_vertices_pgr WHERE id >= 1 AND id <= 181;

すると、こんなメッセージを受けて、失敗します。
tomioka_db_c_trial=# DELETE FROM ways_vertices_pgr WHERE id >= 1 AND id <= 181;
ERROR: update or delete on table "ways_vertices_pgr" violates foreign key constraint "ways_source_fkey" on table "ways"
DETAIL: Key (id)=(1) is still referenced from table "ways".
"エラーメッセージによると、"ways_vertices_pgr" テーブルの "id" 列が "ways" テーブルの "ways_source_fkey" 外部キー制約によって参照されていることが原因のようです。
削除操作を行う前に、この外部キー制約を解除する必要があります。"
とのことのようなので、最初はwaysの削除に変更をします。

wayの削除(最初のトライアル)

DELETE FROM ways WHERE name = 'TomioCart';
"DELETE 184"
とこちらはサクっと消えました。

あれ? TomioCartが消えていない?

QGISからエントリーを削除して、再度読み込みをしたら

ちゃんとwayが消えていました。

nodeの削除(2回目のトライアル) →やはり失敗

chatGPTに相談したら、以下のような指示を受けました。

ALTER TABLE ways DROP CONSTRAINT ways_source_fkey;

しかし、
tomioka_db_c_trial-# ALTER TABLE ways DROP CONSTRAINT ways_source_fkey; ERROR: syntax error at or near "ALTER" LINE 2: ALTER TABLE ways DROP CONSTRAINT ways_source_fkey; と言われました

SELECT constraint_name, table_name, column_name, referenced_table_name, referenced_column_name
FROM information_schema.key_column_usage
WHERE table_name = 'ways_vertices_pgr';

ここから手をやきました。
多分、まだ1~181のノードを参照しているwaysのエントリーが残っているので、消せないのだろうと推測しました。

で、まずは、sourceに21番を持っているwayのエントリーを探してみました。

tomioka_db_c_trial=# select * from ways where source = 21;
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
------+--------+--------+------------------------+-------------------+------+--------+--------+------------+------------+------------------------+------------------------+--------------------+--------------------+------+---------+---------+-----------------+----------------+-------------+------------+------------------+-------------------+----------+--------------------------------------------------------------------------------------------
1258 | 104020 | 112 | 3.9727662820583996e-05 | 3.612272689729353 | | 21 | 899 | 102079 | 2958989369 | 3.9727662820583996e-05 | 3.9727662820583996e-05 | 0.2600836336605134 | 0.2600836336605134 | | 0 | UNKNOWN | 139.62560711503 | 35.36760885871 | 139.6256468 | 35.3676107 | 50 | 50 | 2.5 | 0102000020E6100000020000005C6636F9047461408EF09CCE0DAF41401B1B704C0574614070140FDE0DAF4140
(1 row)

で、このエントリーを消去しました。

tomioka_db_c_trial=# DELETE FROM ways WHERE source = 21;
DELETE 1
tomioka_db_c_trial=# select * from ways where osm_id = 102058;
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
-----+--------+--------+--------+----------+------+--------+--------+------------+------------+------+--------------+--------+----------------+------+---------+--------+----+----+----+----+------------------+-------------------+----------+----------
(0 rows)

たしかに消えています。

で、今度は、ways_vertices_pgr の方を消してみました

tomioka_db_c_trial=# DELETE FROM ways_vertices_pgr WHERE id = 21;
DELETE 1
tomioka_db_c_trial=# SELECT * FROM ways_vertices_pgr;
id | osm_id | eout | lon | lat | cnt | chk | ein | the_geom
------+------------+------+--------------+-------------+-----+-----+-----+----------------------------------------------------
(前略)
20 | 102078 | | 139.62563228 | 35.36755641 | | | | 0101000020E6100000C1D1FD2D05746140C4EAA8160CAF4140
22 | 102080 | | 139.62561830 | 35.36767727 | | | | 0101000020E61000000979AB1005746140ABEC760C10AF4140
(後略)

あっさり消えていました。

 

ということは、source またはtargetが 1~181に関するwayを全部消せば、ways_vertices_pgr の方も消せるはず

ちょっと怖かったけどやってみることにしました。

tomioka_db_c_trial=# DELETE FROM ways WHERE source >= 1 and source <=181;
DELETE 96

tomioka_db_c_trial=# DELETE FROM ways WHERE target >= 1 and target <=181;
DELETE 81

おお! 完全にwayが消えました。

 

では、ふたたび
DELETE FROM ways_vertices_pgr WHERE id >= 1 AND id <= 181;
を実施します

tomioka_db_c_trial=# DELETE FROM ways_vertices_pgr WHERE id >= 1 AND id <= 181;
DELETE 180

やっと消えました

tomioka_db_c_trial=# SELECT * FROM ways_vertices_pgr;
id | osm_id | eout | lon | lat | cnt | chk | ein | the_geom
------+------------+------+--------------+-------------+-----+-----+-----+----------------------------------------------------
182 | 102254 | | 139.62956343 | 35.36605302 | | | | 0101000020E61000007690336225746140082C51D3DAAE4140
183 | 102255 | | 139.62952386 | 35.36602637 | | | | 0101000020E6100000F1EB3A0F257461401A07C7F3D9AE4140
184 | 102256 | | 139.62949515 | 35.36599335 | | | | 0101000020E6100000F65C05D3247461403A74BFDED8AE4140

総括

postgresqlのpostGISのDBから新規に作成したnodeとwayを削除するには、以下の手順を踏むこと
(Step.1) waysから、新規node,wayに関する全部エントリーを削除すること。今回の場合は、以下の3つ

DELETE FROM ways WHERE name = 'TomioCart';
DELETE FROM ways WHERE source >= 1 and source <=181;
DELETE FROM ways WHERE target >= 1 and target <=181;

(Step.2)
ways_vertices_pgrからターゲットのNode情報を削除すること。今回の場合は以下の1つ。

DELETE FROM ways_vertices_pgr WHERE id >= 1 AND id <= 181;

(Step.3)
最後に、tomioka_db_c_trial を、tomioka_db_d に変更する(コピーしてから、tomioka_db_c_trialを消すこと)

ebata@DESKTOP-P6KREM0 MINGW64 ~
$ createdb -U postgres -h 192.168.0.23 -p 15432 tomioka_db_d
Password:
ebata@DESKTOP-P6KREM0 MINGW64 ~
$ pg_dump -U postgres -h 192.168.0.23 -p 15432 -Ft tomioka_db_trial | pg_restore -U postgres -h 192.168.0.23 -p 15432 -d tomioka_db_d
Password:
Password:
drop database tomioka_db_c_trial;

2024,江端さんの技術メモ

滅茶苦茶びっくりしたのですが、GUIだけでUbuntu16.04 でラズパイをWiFi-AP化できるようです。

もっと早く知りたかった。今迄の苦労は何だったんだ。
https://tatanaideyo.hatenablog.com/entry/2017/07/16/072209

でも、IPアドレスの指定など、まだやり方分からないけど、インターネットにも繋がるし、理屈もよく分からんし、セキュリティホールにもなりそうだけど(間違いなくなるな)、もう、これ以上ルータ買うの嫌だから、これでいいかな。

SSIDとパスワードは、ラズパイに張っておこう。

 

2024,江端さんの技術メモ

江端家のカメラ監視サーバ(16.04.7 LTS)が、こんな感じになってしまいました。

どうやら停電の影響を受けたようです。

ディスプレイに出力しないと分かりませんでした。

Welcome to emergency mode! After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, "systemctl default" to try again
to boot into default mode.
Give root password for maintenance
(or type Control-D to continue):

で、ここで、パスワードを入力。

まずは、fstabを確認。

# cat /etc/fstab
proc /proc proc defaults 0 0
/dev/mmcblk0p1 /boot vfat defaults 0 2
/dev/mmcblk0p2 / ext4 defaults,noatime 0 1

で、

# umount /dev/mmcblk0p2
# e2fsck /dev/mmcblk0p2

で直る。

"/" がumountできるのはemergency modeだかららしいです。

普通はできません。

# ちなみに、カーネルのバージョンアップは諦めています。

2024,江端さんの技術メモ

工場出荷時のIPアドレスは、192.168.0.10です。Webから設定できます

 

WS-S2130RJUXは、天井に固定するタイプのカメラですが、勿論、実験機材なのでそんなことはません。

20年以上前に、プロジェクタスクリーン用のアタッチメントを取りつけていたので、そこに結束バンドで仮固定しました。

といっても、地震で落ちてきたら、機材と私の両方が壊れるので、縛り方には工夫を施しています。

まあ、自分の映像を写しながら、コーディングやチューニングをする、ということですね。やり方としては明快です。

結束バンドの場合、ニッパーでカットするだけで簡単に取り外せるというメリットもあります。

これで、私の部屋には5台のカメラが設置されることになりました。

刑務所の独房でも、これだけのカメラが設置されることはないだろうなぁ、と思っています。

 

 

 

2024,江端さんの技術メモ

curl http://localhost:8000/getHeartbeatInfo

curl http://localhost:8000/getHeartbeatInfo/

のように、行末に”/"を入れたり、入れなかったりしてみる。

2024,江端さんの技術メモ

import os
import sys
import signal
import errno

def kill_parent_and_children(parent_pid):
    try:
        # 親プロセスとその子プロセスのPIDを取得
        parent_and_children_pids = [parent_pid] + get_child_processes(parent_pid)
        # 親プロセスとその子プロセスを終了させる
        for pid_to_terminate in parent_and_children_pids:
            if pid_to_terminate is not None:
                os.kill(pid_to_terminate, signal.SIGKILL)  # プロセスを終了させる
    except Exception as e:
        print(f"Error terminating processes: {str(e)}")

def get_child_processes(parent_pid):
    child_processes = []
    try:
        # /procディレクトリからプロセス情報を取得
        proc_dir = '/proc'
        for pid_entry in os.listdir(proc_dir):
            pid_path = os.path.join(proc_dir, pid_entry)
            if os.path.isdir(pid_path) and pid_entry.isdigit():
                # プロセスのステータスを読み取り
                with open(os.path.join(pid_path, 'status'), 'r') as status_file:
                    status_lines = status_file.readlines()
                    # PPid行から親プロセス番号を取得
                    for line in status_lines:
                        if line.startswith('PPid:'):
                            ppid = int(line.split()[1])
                            if ppid == parent_pid:
                                child_processes.append(int(pid_entry))
                            break
    except Exception as e:
        print(f"Error getting child processes: {str(e)}")
    return child_processes
if __name__ == "__main__":
    if len(sys.argv) != 2:
        print("Usage: python3 xxxx.py <parent_pid>")
        sys.exit(1)
    parent_pid = int(sys.argv[1])
    # 親プロセスとその子プロセスをすべて終了させる
    kill_parent_and_children(parent_pid)

2024,江端さんの技術メモ

出展はこちら→ https://content.connect.panasonic.com/jp-ja/fai/file/39018

admin/jvc で、 JVC HD IP Camera VN-H68 が出てくる

「設定」を押す。

以上

 

2024,江端さんの技術メモ

初期(工場)設定IPアドレスは192.168.0.10, ユーザ名 cam パスワードCam12345(最初は大文字)とした。

表示の様子

(天井の)ストリーム表示に成功したコマンド一覧

cam@cam-desktop:~$ ffplay -i rtsp://cam:Cam12345@192.168.0.10/Src/MediaInput/stream_1

cam@cam-desktop:~$ GST_DEBUG=3 gst-launch-1.0 -v rtspsrc location=rtsp://192.168.0.10/Src/MediaInput/stream_1 user-id="cam" user-pw="Cam12345" ! decodebin ! autovideosink

(天井の)静止画表示に成功したコマンド一覧

gst-play-1.0 rtsp://cam:Cam12345@192.168.0.10/Src/MediaInput/stream_1

現時点で、上手く動いていないコマンド

cam@cam-desktop:~$ gst-launch-1.0 rtspsrc location=rtsp://cam:Cam12345@192.168.0.10/Src/MediaInput/stream_1 ! rtph264depay ! h264parse ! queue ! autovideosink
(これは、これまでのカメラでは動いていたコマンド)

現時点で、上手く動いいたコマンド

gst-launch-1.0 rtspsrc location=rtsp://cam:Cam12345@192.168.0.10/Src/MediaInput/stream_1  latency=0 ! rtph264depay ! avdec_h264 ! videoconvert ! autovideosink

gst-launch-1.0 rtspsrc location=rtsp://cam:Cam12345@192.168.0.10/Src/MediaInput/stream_1 latency=0 ! rtph264depay ! avdec_h264 ! videoconvert ! videoscale ! video/x-raw,width=640,height=360 ! videorate ! video/x-raw,framerate=5/1 ! autovideosink

2024,江端さんの技術メモ

Keyword:USB LAN ehternet アダプタ ubuntu  etc netplan

(1)>ip addrで、
8: enx207bd2222d29: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 20:7b:d2:22:2d:29 brd ff:ff:ff:ff:ff:ff
みたいな奴をみつける

(2)/etc/netplan/99_config.yamlで、以下のよう書き替える

network:
  version: 2
renderer: networkd
ethernets:
eth0:
#      dhcp4: false
addresses:
192.168.101.30/24
routes:
- {to: default, via: 192.168.101.1}
#      addresses:
#        - 192.168.0.15/24
enx207bd2222d29:
dhcp4: false
addresses:
192.168.0.15/24
(3) sudo netplan apply でネットワーク再起動

TP-LINK / Archer C2300 を再度設定しなおす

2024,江端さんの技術メモ

まず、この2つの点は、どっちが、私(江端)が追加したノードだったのかを思い出すことにします。

上のノードは、こんな風

id番号が若いから、こっちが私が作った方で、まあ、間違いないでしょう。

念の為、もう一方も確認。

こちもID番号若いけど、以前管理した番号とは違うみたいだから、こっちが既存のノードであろう、とする。

これを私が結線した時に作った道路が、これ。

結線の情報は、source,target, source_osm, target_osmで入っているので、少なくともノード間の結線であれば、ここの加工だけで何とかなるんじゃないかな、と。

で、ここの部分のエントリーを見てみたら、こんな感じでした。(tomioka_db_c_trialの方で確認中)

gid、osm_id →新規の番号を適当に付ける
source, target, source_osm, target_osm は、これから結線するノード番号を記載する。(sourceが、江端が作成したNodeになっている)
と、まあ、ここまではいいとして、tag_idってなんだろう。あと、the_geomをどうしようかなぁ。

QGIS使ってtag_id = 112 だけを表示して調べてみたけど、私が手を入れたところに(も)出てきているようなので、何も分からないまま 112 を使うことにする。

さて、次に問題は、the_geomである。これは面倒くさい。多分デタラメな値を入れても大丈夫だとは思うが、念を入れておきたい。

tomioka_db_c=# select * from ways where gid = 506;
 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
-----+--------+--------+-----------------------+--------------------+------+--------+--------+------------+------------+-----------------------+-----------------------+--------------------+--------------------+------+---------+---------+-----------------+---------------+-----------------+----------------+------------------+-------------------+----------+--------------------------------------------------------------------------------------------
 506 | 105780 |    112 | 7.110994016919574e-06 | 0.7650124135935403 |      |    277 |    414 |     102352 |     102501 | 7.110994016919574e-06 | 7.110994016919574e-06 | 0.0550808937787349 | 0.0550808937787349 |      |       0 | UNKNOWN | 139.61725559089 | 35.3693678707 | 139.61725862094 | 35.36936143758 |               50 |                50 |      2.5 | 0102000020E610000002000000AA04CC8EC0736140C26C467247AF414090C32695C0736140A2674F3C47AF4140
(1 row)
で、以下のように実行して、 the_geom の内容を調べてみると
tomioka_db_c=# select ST_Astext(the_geom) from ways where gid = 506;
                                st_astext
--------------------------------------------------------------------------
 LINESTRING(139.61725559089 35.3693678707,139.61725862094 35.36936143758)
(1 row)

と、2点の座標を結ぶ直線であることが分かった。

そこで、以下のプログラムを作成してみた。

/*
c:\users\ebata\tomika3b\src\others\main31.go
go run main31.go


*/
package main

import (
	"encoding/hex"
	"fmt"

	"github.com/twpayne/go-geom"
	"github.com/twpayne/go-geom/encoding/wkb"
)

func main() {

	// 2つの緯度経度ポイント
	//coordinates := [][]float64{{139.6917, 35.6895}, {-74.006, 40.7128}}
	coordinates := [][]float64{{139.61725559089, 35.3693678707}, {139.61725862094, 35.36936143758}}
	//coordinates := [][]float64{{139.61725862094, 35.36936143758}, {139.61725559089, 35.3693678707}}

	// Geometryの作成
	lineString := geom.NewLineStringFlat(geom.XY, []float64{coordinates[0][0], coordinates[0][1], coordinates[1][0], coordinates[1][1]})

	// WKB形式に変換
	wkbBytes, err := wkb.Marshal(lineString, wkb.NDR)
	if err != nil {
		fmt.Println("Error:", err)
		return
	}

	// WKB形式を16進数文字列に変換
	wkbHex := hex.EncodeToString(wkbBytes)

	// 出力
	fmt.Println(wkbHex)
}

さて、このプログラムからから、
0102000020E610000002000000AA04CC8EC0736140C26C467247AF414090C32695C0736140A2674F3C47AF4140
を作れるかな?

coordinates := [][]float64{{139.61725559089, 35.3693678707}, {139.61725862094, 35.36936143758}}
としたら、
ベース: 0102000020E610000002000000AA04CC8EC0736140C26C467247AF414090C32695C0736140A2674F3C47AF4140
作成: 01020| |0000002000000aa04cc8ec0736140c26c467247af414090c32695c0736140a2674f3c47af4140
一部欠けているが、一致している。

では、逆転させてみよう。
coordinates := [][]float64{{139.61725862094, 35.36936143758}, {139.61725559089, 35.3693678707}}
としたら、
ベース: 0102000020E610000002000000AA04CC8EC0736140C26C467247AF414090C32695C0736140A2674F3C47AF4140
作成: 000000000200000002406173c08ecc04aa4041af4772466cc2406173c09526c3904041af473c4f67a2
こっちは、不一致が多いようです。

でも geomの長さが違うと思い、ChatGPTに尋ねてみたところ、以下のように言われました。

PostGISで生成されたWKB形式のデータは、ヘッダーを含んでいるため、より長いバイト列となります。一方、Go言語の標準ライブラリを使用して生成されたWKB形式のデータは、ヘッダーを省略しているため、より短いバイト列となります。

両方のWKB形式のデータが同じ構造と座標を持っている場合、データの内容は正しく解釈されます。しかし、データの長さには違いが生じることがあります。この違いは、WKB形式が異なる実装によって生成された場合に一般的です。

WKB形式のデータは、そのバイト列を解釈する際に、ヘッダーの情報を使用してジオメトリの種類と座標の次元を正しく読み取ります。そのため、データの長さの違いは問題ありません。

ということなので、長さについては無視することにしました。まあ、ダイクストラ計算をする分には問題ないでしょう

-----

では、本命。

この2点間を結線する、をやってみます。

    //source 305(×306) {139.62232489, 35.37185132}  target 1401  {139.62233160, 35.37184490} // これが今回のターゲット

    coordinates := [][]float64{{139.62232489, 35.37185132}, {139.62233160, 35.37184490}}

で計算したところ、

0102000000020000002d41e315ea736140ed2ff5d298af41408ea8f523ea7361409a571a9d98af4140
となったので、これはこのまま利用。

今回は、この2点間を繋ぐ、wayのオブジェクトを作れば良いだけなので、基本的にはwayのエントリーを一つ追加するだけで足りるはず。

#gid =506のエントリーがこんな感じなので、これをパクります。
tomioka_db_c=# select * from ways where gid = 506;
 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
-----+--------+--------+-----------------------+--------------------+------+--------+--------+------------+------------+-----------------------+-----------------------+--------------------+--------------------+------+---------+---------+-----------------+---------------+-----------------+----------------+------------------+-------------------+----------+--------------------------------------------------------------------------------------------
 506 | 105780 |    112 | 7.110994016919574e-06 | 0.7650124135935403 |      |    277 |    414 |     102352 |     102501 | 7.110994016919574e-06 | 7.110994016919574e-06 | 0.0550808937787349 | 0.0550808937787349 |      |       0 | UNKNOWN | 139.61725559089 | 35.3693678707 | 139.61725862094 | 35.36936143758 |               50 |                50 |      2.5 | 0102000020E610000002000000AA04CC8EC0736140C26C467247AF414090C32695C0736140A2674F3C47AF4140

(1 row)

空き番号となっているgidは1984
空き番号となっているosm_idは、現在104088(と同じ桁であれば)、104090あたりが良さそう

x1,y1,x2,y2も比較してみたところ、
source 139.61725559  35.36936787
target 139.61725862 35.36936144
X1 139.61725559089 Y1 35.3693678707
X2 139.61725862094  Y2 35.36936143758となっていたので、とりあえずx1、x1をsource に、x2、y2をtargetにしてみたでは作ってみますか
(他のところは、現在のノード(506)をパクッても大きな問題にはならないだろう、と予測)
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
1984| 104090 |    112 | 7.110994016919574e-06 | 0.7650124135935403 |      |    305 |    1401 |    102381 |    4095221163 | 7.110994016919574e-06 | 7.110994016919574e-06 | 0.0550808937787349 | 0.0550808937787349 |      |       0 | UNKNOWN | 139.61725559089 | 35.3693678707 | 139.61725862094 | 35.36936143758 |               50 |                50 |      2.5 | 0102000020E610000002000000AA04CC8EC0736140C26C467247AF414090C32695C0736140A2674F3C47AF4140

INSERT INTO ways (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)
VALUES (1984, 104090, 112, 7.110994016919574e-06, 0.7650124135935403,NULL, 305 , 1401, 102381, 4095221163, 7.110994016919574e-06, 7.110994016919574e-06, 0.0550808937787349, 0.0550808937787349, NULL, 0, 'UNKNOWN', 139.62232489, 35.37185132, 139.62233160, 35.37184490, 50, 50, 2.5, '0102000000020000002d41e315ea736140ed2ff5d298af41408ea8f523ea7361409a571a9d98af4140');

結線されたようです。

では、ちゃんとダイクストラで繋がるのかを確認してみます。

tomioka_db_c_trial=# SELECT seq, source, target, x1, y1, x2, y2 FROM pgr_dijkstra('SELECT gid as id, source, target, cost, reverse_cost FROM ways',699, 304, directed := false) a INNER JOIN ways b ON (a.edge = b.gid) ORDER BY seq;
 seq | source | target |       x1        |       y1       |       x2        |       y2
-----+--------+--------+-----------------+----------------+-----------------+----------------
   1 |    699 |   1401 |      139.622458 |     35.3721429 |     139.6223316 |     35.3718449
   2 |    305 |   1401 |    139.62232489 |    35.37185132 |     139.6223316 |     35.3718449
   3 |    304 |    305 | 139.62216476726 | 35.37185094304 | 139.62232488969 | 35.37185132369
(3 rows)
逆方向はどうかな?
tomioka_db_c_trial=# SELECT seq, source, target, x1, y1, x2, y2 FROM pgr_dijkstra('SELECT gid as id, source, target, cost, reverse_cost FROM ways',304, 699, directed := false) a INNER JOIN ways b ON (a.edge = b.gid) ORDER BY seq;
 seq | source | target |       x1        |       y1       |       x2        |       y2
-----+--------+--------+-----------------+----------------+-----------------+----------------
   1 |    304 |    305 | 139.62216476726 | 35.37185094304 | 139.62232488969 | 35.37185132369
   2 |    305 |   1401 |    139.62232489 |    35.37185132 |     139.6223316 |     35.3718449
   3 |    699 |   1401 |      139.622458 |     35.3721429 |     139.6223316 |     35.3718449
(3 rows)
繋っているを確認できました(ホッとしました)
# 正直、ダイクストラ計算の書式が気になるけど、結線に成功しているなら、まあいいや(もう疲れた)
tomioka_db_cにも、同じエントリをして、tomioka_db_c_trialを消去しました。