江端さんの技術メモ

背景

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

課題

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

課題を解決する手段

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

実施例

まず、

すると、こんなメッセージを受けて、失敗します。
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の削除に変更をします。

DELETE FROM ways WHERE name = 'TomioCart';

しかし、
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を消すこと)

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

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

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

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

江端家のカメラ監視サーバ(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だかららしいです。

普通はできません。

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

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

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

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

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

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

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

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

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

curl http://localhost:8000/getHeartbeatInfo

curl http://localhost:8000/getHeartbeatInfo/

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

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)

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

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

「設定」を押す。

以上

初期(工場)設定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

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で、以下のよう書き替える

まず、この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である。これは面倒くさい。多分デタラメな値を入れても大丈夫だとは思うが、念を入れておきたい。

/*
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に尋ねてみたところ、以下のように言われました。

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');

結線されたようです。

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