2024,江端さんの技術メモ

作業中のプロジェクト: ないしょ
番号: ないしょ
ID: ないしょ
自分のAPIキー AXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXE

困っていたこと

Google MAP Directions APIを使いたいのですが、自分のAPIキーを使っても、以下のようになります。
https://maps.googleapis.com/maps/api/directions/json?origin=Disneyland&destination=Universal+Studios+Hollywood&key=AXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXE
{
   "error_message" : "This API project is not authorized to use this API.",
   "routes" : [],
   "status" : "REQUEST_DENIED"
}
対策を教えて下さい。
意外なところで解決しました。

で、再度実行したら、こうなりました。

ところが、鉄道の情報が出てこない。

 

うまくいっていない理由確定

 

Google Maps Platform FAQ  |  Google for Developers

https://developers.google.com

Google マップのルートサービスでは、交通機関の対象リストに記載されているすべての交通機関(日本を除く)をサポートしています。

ということで、日本で使用できるのは walking と driving の2モードのみのようです。

あかんやんか・・・

2024,江端さんの技術メモ

SSHキーペアは、通常はローカルマシンで生成され、その後、公開鍵がリモートサーバーに配置されます。以下が一般的な手順です:

  1. id_rsa.pub (公開鍵):
    • ローカルマシンで生成されます
    • ssh-keygenなどのツールを使用して、ローカルマシン上でSSHキーペアを生成すると、id_rsa.pubという名前のファイルが生成されます。このファイルが公開鍵であり、リモートサーバーに登録されます。
  2. id_rsa (秘密鍵):
    • ローカルマシンで生成されます
    • 同様に、SSHキーペアを生成すると、id_rsaという名前のファイルが生成されます。このファイルが秘密鍵であり、クライアント側で認証に使用されます。この秘密鍵は、厳重に保管される必要があります。
  3. authorized_keys:
    • リモートサーバーに配置されます
    • リモートサーバーには、認証を許可する公開鍵が含まれるauthorized_keysファイルが存在します。このファイルには、リモートサーバーにアクセスを許可するために、クライアント側から送信された公開鍵が追加されます。

したがって、SSHキーペアの生成と配置の一般的なパターンは、ローカルマシンで生成された公開鍵がリモートサーバーに配置され、秘密鍵はクライアント側のローカルマシンに残されることです。

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