2024,江端さんの忘備録

先日の学会発表では、散々な目にあってきた、というお話をしました。

At a recent academic conference, I talked about the terrible things that had happened to me.

―― ホテルの前に立った瞬間、ヤニの匂いが漂ってきた。

私は、CASIOの電波腕時計 WAVE CEPTORを愛用しています。

I use a CASIO WAVE CEPTOR radio-controlled watch.

この時計は1日1回、 福島または佐賀の２つの送信所から遅られてくる時刻情報の電波を受信して、時刻補正をしています。

This clock receives time correction signals from two transmission stations in Fukushima or Saga once a day.

逆に言えば、その電波が掴めなければ時刻補正ができません。

Conversely, if you can't catch that signal, this watch won't be able to adjust the time.

時刻補正ができないだけならいいのですが、 WAVE CEPTORは、時刻補正が行われないと、2001年1月1日にリセットしてしまうのです(仕様なのか寿命なのかは分かりませんが)。

If it were just a matter of being unable to correct the time, it would be fine, but WAVE CEPTOR resets to January 1st, 2001, if the time is not corrected (I don't know if this is a specification or a lifetime issue).

学会期間中、2001年1月1日の意味不明の時刻しか分からずに、いちいちスマホやPCで時間を確認せねばならず、ひどく難儀をしました(アナログ補正方式で対応していましたが)。

During the conference, I had to check the time on my smartphone or PC every time, as I only knew the time of January 1st, 2001. It was a huge hassle (although I was using an analog correction method).

GPSで補正する時計もありますが、まだまだ値段が高いです。

Some watches use GPS to make corrections but are still expensive.

てっとり早いのは無線LANですが、こちらはアクセスポイントのIDやパスワードの設定が必要になるようです。

The quickest way is to use wireless LAN, but you must set the access point ID and password.

壁掛け時計ならともかく、腕時計には使えないようです。

You can't use it as a wristwatch, even though you can use it as a wall clock.

-----

無線LANのビーコン信号(ブロードキャスト(常に周囲全体に向けて送信)されている)に、時刻情報を放り込んでおけばいいのに、と思うんですけどね。

I think it would be a good idea to throw time information into the beacon signal of wireless LAN (broadcast (always transmitted to the entire surrounding area))

ただ、それをやると、無線LANのアクセスポイント自体に時刻補正機能が必要となって、で、無線LANのアクセスポイントは上位サーバとの時刻同期が必要となって、そうなると、基幹のNTPサーバの負荷が重くなって ・・・ うん、滅茶苦茶に面倒が増える。

However, the wireless LAN access point will need a time correction function if you do that. The wireless LAN access point will need to synchronize its time with the upper-level server, and if that happens, the load on the core NTP server will increase... yeah, it will be a lot more troublesome.

つまるところ、『次女がダイソーで購入した900円の時計(私が電池を入れ替えたもの)を、私が持ち歩く』ということが、世界のために最もコストが安い(SDGsに貢献する)、という結論になりました。

Ultimately, I concluded that the most cost-effective (and SDG-friendly) thing for the world would be carrying around the 900 yen watch that my second daughter bought at Daiso (and I changed the battery).

「そこに怪我人がいれば、助けるのが医者だ」と「そこに動かない時計があれば、動かすのがエンジニアだ」というセリフが等価なのかは分かりませんが ――

そういえば、私、長女の結婚式の時に、この900円の時計をしていこうと思っていました。

I considered wearing this 900 yen watch to my eldest daughter's wedding.

『殆どの人は、900円の時計か9万円の時計か、見分けがつかない』とか、勝手に思い込んでいますか ―― 正直なところ、私は良く分からないです(少なくとも、私(江端)は見分けがつきません)。

I've decided that 'most people can't tell the difference between a 900 yen watch and a 90,000 yen watch'.I don't understand (at least, I (Ebata) can't tell the difference).

そもそも、私は「9万円の男」ではなく、「900円の男」である、という自負がありますから、全然構いませんでしたが。

To begin with, I am proud to say that I am not a “90,000 yen man”, but a “900 yen man”, so I was completely fine with it.

逆に驚いたのは、『家族から一人も反対意見がでなかった』ということです。

I was surprised that 'not a single family member had any objections.'

-----

『結婚式披露宴には、腕時計をしてはいけない』―― のだそうです。なんでも、『時間を気にすることがモラルに反する』のだそうです。

'You shouldn't wear a watch to a wedding reception' - that's what they say. Apparently, 'worrying about the time is against morals'.

私、そういうルール、全然知りませんでした。

I didn't know about those rules at all.

しかし、私、これまでの結婚式披露宴、100%腕時計してきました。

However, I wear a watch at 100% of all wedding receptions.

それに、結婚式披露宴の司会者している時に、「時計なし」で式進行するなど、不可能だったと思う。

Also, when I was the MC at a wedding reception, I didn't think it would have been possible to go through the ceremony without a watch.

2024,江端さんの忘備録

先日、長女が実家に帰省していたので、録画しておいた「“死の迎え方” ヒトの穏やかな死とは」を、無理矢理、視聴させました。

The other day, my eldest daughter was visiting her parents, so I forced her to watch the video I recorded for the program “How to Die: A Peaceful Death for Humans.”

長女が、チャンネルを変えないように、私が横でずっとつきっきりでした。

I stayed by her side to ensure she didn't change the channel.

この番組では、現代における人間の死生観と終末期医療の変化について探求していました。

This program explored the changing views of death, dying, and end-of-life care in modern times.

私は、「この私(江端)が、穏やかな最期を迎えるための身体的変化」について、長女の頭に叩き込んでおきたかったのです。

I wanted to make sure that my eldest daughter understood that I was going through physical changes to have a peaceful death.

この番組で、私が長女に教え込みたかったのは以下の2点。

There were two things I wanted to teach my eldest daughter through this program.

(1)死期5年前から、栄養を摂取していたとしても、BMI(ざっくり言えば体重)は減少する。それゆえ、無理に食べさせたり、飲ませたり、点滴させる意味はない。

(1) Even if the patient has been receiving nutrition for five years before death, their BMI (roughly speaking, their weight) will decrease. Therefore, there is no point in forcing them to eat, drink, or receive an IV drip.

(2)外部から見ると呼吸困難のように見えても、酸素が欠乏することによって脳内でエンドルフィンが分泌され、穏やかな気持ちになっている可能性が高い。それ故、延命処理を施すと苦痛を長引かせることになる。

(2) Even if it looks like the patient is having breathing difficulties from the outside, it is highly likely that the brain is secreting endorphins due to a lack of oxygen and that the patient is feeling calm. Therefore, administering life-prolonging treatment will only prolong their suffering.

-----

これ、私の経験にも合致するのです。

This also matches my own experience, as shown in the following.

- 食欲のない父に、介護士が、無理矢理スプーンを突っ込んでいた風景に、ショックを受けたこと

- I was shocked by the scene of the caregiver forcibly shoving a spoon into my father's mouth, who had no appetite.

- (姉に聞いた話ですが)、大量の点滴を打った後、父が苦しみでのたうち回っていたこと

- (I heard this from my older sister) After being given a large amount of intravenous fluids, my father was writhing in agony

などです。

-----

私は、長女にこの番組を見ながらお願いをしていたのです ―― 「私が『食べたくない』『飲みたくない』といったら、どうか放っておいてくれ」と。

While watching this program, I asked my eldest daughter, “If I say ‘I don't want to eat’ or ‘I don't want to drink,’ please leave me alone.”

加えて、『苦痛を長引かせるだけの延命処置も止めてくれ』、とも。

In addition, I also said, “Please stop life-prolonging treatment that only prolongs suffering.”

江端:「つまり、『自分の手で親を殺す』という後ろめたさから逃れるためだけに、そのツケ(苦痛)を私に払わせるな、と、頼んでいるんだ」

Ebata: “In other words, I ask you not to give me pain for escaping the guilt of ‘killing own parents with your own hands.’”

長女:「でも、『自分の手で親を殺す』という決断は重いなぁ。パパが、私をラクにさせるためだけに、その苦痛を我慢してれない？」

Eldest daughter: “But the decision to ‘my parents with my own hands’ is serious. Can't you bear the pain for my sake?”

江端:「ふざけるな」

Ebata: “Don't mess around.”

-----

皆さん。もう覚悟しましょう。

Everyone, let's get ready.

私たちの人生で最も苦しい親孝行とは、自分の判断で親を殺すことです。

The most painful form of filial piety in our lives is to kill our parents on our judgment.

―― 父を『殺す』決断を下すこと

(↑クリックでコラムに飛びます)

(Click to go to the column)

2024,江端さんの忘備録

先日、「チ。-地球の運動について」に関してコメントを記載しました。

The other day, I commented on “Chi: About the Movement of the Earth.”

―― アニメ「チ。-地球の運動について」を、アメリカ合衆国で放送したら、何が起こるだろうか

この物語のテーゼである「天動説 v.s 地動説」の歴史については、私は、是非とも、サイモン・シンさんの著書『宇宙創成』（原題：Big Bang: The Origin of the Universe）をお勧めしたいのです。

As for the history of the thesis of this story, “Ptolemaic theory vs. Copernican theory,” I recommend Simon Singh's book “The Big Bang: The Origin of the Universe.”

この本は、以下にも記載していますが、

As mentioned below, I have already written about this book.

―― 自分が良いと思うものが、他人が良いと思うとは限らない

で、実はこの話、まだ、続きがあります。

And I also continued the story.

―― 「コンテンツエバンジェリスト(コンテンツ伝道者)」

このように、先生の『宇宙創成』という本に対する熱い思いは、娘には伝わらず、私に間接的に伝わったのみです。

In this way, my daughter did not understand her teacher's passion for the book “Big Bang: The Origin of the Universe" I only understood it indirectly.

先生、あきらめましょう。私たちの宇宙に対する熱い思いは、子どもたちには伝わらないんですよ。

Let's give up, Sensei. Our passion for space won't be conveyed to the children.

それはさておき

Leaving that aside

-----

最新の「チ。-地球の運動について」の第9話、『きっとそれが、何かを知るということだ』では、天動説の完成に至らなかった老天文学者がこう語る場面があります。

In the latest episode of “Chi: About the Movement of the Earth”, Episode 9, “I'm sure that's what it means to know something”, there is a scene where an astronomer who did not complete the geocentric theory says this.

―― 天動説が誤っていたとしたら、天動説に命を捧げてきた過去1000年間の天文学者達の挑戦は一体何だったのだ？ その挑戦には、何の意味もなかったのか？

If the geocentric theory was wrong, what was the point of the astronomers who had devoted their lives to it over the past 1000 years? Was their challenge meaningless?

私はこの問いに答えを持ち合わせていませんが、論理的に考えれば、『何の意味もなかった』という結論になるでしょう。血も涙もない絶対零度の解答ですが。

I don't have an answer to this question, but if you think about it logically, you'll probably conclude that it 'didn't mean anything.' It's a heartless, bloodless answer.

さて、ここから本題に入ります。

Now, let's get down to the main topic.

この『宇宙創成』には、天動説（※地動説ではなく天動説）を完成させるために様々な挑戦が行われてきた記録が数多く紹介されています。そして、これが本当に面白いのです。

This “Big Bang: The Origin of the Universe” introduces many records of the challenges to perfecting geocentric theory (not heliocentric theory). And this is interesting.

これだけの資料を目にすれば、『もしかすると、天動説って正しいのでは？』と思わせるほどの迫力と説得力を持ったロジックが次々と登場します。

When you see all this material, you can't help but think, “Maybe the geocentric theory is correct?” as the logic that appears one after another is so powerful and convincing.

しかし、限られた天文観測情報と絶対的価値観（キリスト教信仰）が支配していた時代において、命を懸けて「宇宙の真理を明らかにしようとした人たちの闘い」に思いを馳せると、たとえ『何の意味もなかった』という結論に達してしまうとしても、私は胸が熱くなるのです。

However, when I think about the struggles of those who risked their lives to “reveal the truth of the universe” in an era when limited astronomical observation information and absolute values (Christian beliefs) dominated, even if I conclude that “it was meaningless,” my heart still fills with emotion.

-----

私が現在進めている研究は、現時点では評価されていません。未来においても評価される可能性は低いでしょう。また、近い未来には、私のアプローチよりも簡単な方法が見つかるかもしれません。それは、私自身、既に理解していることです。

The research I am currently pursuing is not valued and is unlikely to be valued in the future. In addition, it is possible that a simpler method than my approach will be found soon. I already understand this.

それでも私は、自分の研究をやめるつもりはありません。

Even so, I have no intention of stopping my research.

では、私は何のために研究を続けているのか ――

So, what am I continuing my research for?

私は、世の中を1mmでも動かしたいとか、誰かの踏み台になれれば良い、といった野望があるわけではありません

I don't have any ambitions to move the world by even 1mm or to be someone's stepping stone.

私は、私の人生の中でやれることの最後をただ確認するためだけに、研究を続けているのです。

I continue my research to confirm the end of what I can do in my life.

未分類

GStreamerにおけるkeep-listeningの機能は、主にSRTプロトコルの特性に基づいて設計されています。SRTはストリーミング中のネットワーク障害や接続の一時的な切断に対して高い耐障害性を持ち、再接続をプロトコルレベルでサポートしています。このため、GStreamerのSRTプラグインにはkeep-listeningオプションが実装されており、再接続処理が標準で可能となっています。

一方で、RTSPプロトコルは再接続に対する標準的なメカニズムを持っておらず、ストリーミング接続が切断された場合にはアプリケーション側で再接続処理を実装する必要があります。この理由は以下の通りです：

  1. プロトコルの設計思想の違い
    SRTはリアルタイムのビデオ伝送を想定し、途切れた接続を回復するための仕組み（例：パケットの再送や接続の再試行）が組み込まれています。一方、RTSPは主にコントロールプロトコルとして設計されており、接続の維持や再接続は仕様の範囲外です。
  2. GStreamerプラグインの実装方針
    GStreamerのRTSPプラグイン（rtspsrc）は、RTSPプロトコルの標準に忠実であり、アプリケーション側で自由に再接続ロジックを実装できるよう設計されています。このため、keep-listeningのようなオプションはRTSPプラグインに含まれていません。
  3. 運用環境での要件
    RTSPストリームの中断や切断が発生する状況は、ネットワーク環境やストリーミングサーバーの設定に依存するため、再接続の実装はユーザーごとの要件に基づいてカスタマイズされることが一般的です。

これらの理由から、RTSPでkeep-listeningを実現するには、アプリケーション側でエラー検知と再接続処理を実装する必要があります。これは、RTSPの特性に起因する設計上の制約であり、プロトコルやGStreamerプラグインの動作仕様によるものです。

------

今回の質問は、
『GStreamerでSRTはKeep-listening が使えるのですが、RTSPではkeep-listeningが使えません。この理由を上司に説明できる文章として作成して下さい』
としました。

我ながら、色々なChatGPTの姑息な使い方ができるようになってきたものだと、自分に感心しています。

未分類

Amazon Primeで「深夜食堂」を流しながらコーディングしています。

「深夜食堂」について調べてみたら、原作本については世界中で翻訳されているみたいですが、ドラマのリメイクも、中国、台湾、韓国でされていて、放映されているようです。

舞台などにもなっているそうです ―― で、情報のウラは取れなかったのですが「フランス」でリメイクだか、舞台だかが、あったとかなかったとか。

「フランス版深夜食堂」。うん、なんか、凄く見たい。

「ドイツ版深夜食堂」「ロシア版深夜食堂」はイメージできる。

北欧もイメージできる。

西欧であれば、スペイン版とかイタリア版とかも見てみたい。

イスラム圏の深夜食堂 ―― アルコール抜きバージョンも、可能なら見てみたいです。

2024,江端さんの忘備録

『ダイクストラ計算を行った結果を、(1)'Dummy Rail Line'が連続するリスト、(2)(1)'Dummy Bus Line'が連続するリスト、(3)その他のリストに分割するプログラムに改造しつつ、(1)(2)(3)はその順番通りにリストを作成し、(1)(2)(3)が、2度以上出てくる場合は、別のリストとして取得するには、どうコーディングすれば良いのか？』(読まなくていいです)

'How should I code to create lists (1) 'Dummy Rail Line' in succession, (2) 'Dummy Bus Line' in succession, and (3) other lists while modifying the program to divide the results of the Dijkstra calculation into these three lists, and to obtain a separate list if (1), (2), or (3) appears more than once? (You don't need to read this.)

上記のコーディング方法について、今朝の深夜までもんもんと考え続けていました。

I kept thinking about the coding method above until late this morning.

ところが、朝方、夢の中で、この方法が、天からの啓示のごとく突如閃きました。

However, this method suddenly flashed into my mind in the morning like a revelation from heaven.

『ChatGPTにプログラム作成してもらおう』

“Let's have ChatGPT create a program for us.”

-----

先程、ChatGPTが作ってくれたプログラムの稼動を確認しました。

I just checked to see if the program ChatGPT created is working.

ようやくホッとしていますが(今から少し寝ます)、同時に『問題を考えなくなっていく自分の頭が、どんどん悪くなっている』を痛感しています。

I'm finally feeling relieved (I'm going to sleep for a bit now), but at the same time, I'm acutely aware that 'my brain, which is no longer thinking about problems, is getting worse and worse.'

これは、これで、かなり恐しいことだと思っています。

I think this is quite a frightening thing.

-----

すでに、この業界では、この問題の弊害が出ているそうです ―― かなり広範囲に、しかも相当に深刻な弊害です。

I hear that the harmful effects of this problem are already being seen in the industry - quite severe and widespread.

ソフト外注に発注した人が、発注したプログラムの内容について開発者に質問しているうちに、

While the person who ordered the software was asking the developer questions about the content of the program they ordered, it turned out that -

- そのプログラム開発者が、プログラマとして働き始めて、1年のキャリアもないこと

- the program developer had only been working as a programmer for less than a year

- そのプログラム開発者が、"サブルーチン"とは何かを知らなかったこと(注: サブルーチンという概念を知らなかった)

- the program developer did not know what a “subroutine” was (Note: He did not know the concept of a subroutine)

ことが、分かったそうです。

今、世界中で、そういう開発者たちが作成するプログラムが、大量生産されていると考えて間違いないでしょう。

It might be possible to assume that such developers mass-produce programs worldwide.

これも、これで、かなり恐しいことだと思っています。

I think this is also quite a frightening thing.

何が言いたいのかというと、「こういうプログラムを組める『私』には、市場価値があるのか、それとも、ないのか」、です。

未分類

hakata_ex_cost_db=# \e 
 start_seq | end_seq | line_name
 -----------+---------+-----------------------------------
1 | 6 | Dummy Railway Line JR鹿児島本線
7 | 7 | Dummy Railway Line JR篠栗線
8 | 10 | Dummy Railway Line 地下鉄航空線
12 | 12 | Dummy Bus Line 天神エリア限定バス
という結果が出てきました。start_seq と end_seq が同じ番号になっているところがありますが、これは、どのように解釈すれば良いでしょうか

SELECT seq, node, edge, cost, agg_cost FROM pgr_dijkstra('SELECT gid as id, source, target,length_m as cost FROM ways',66619, 92554, false);

WITH path AS ( SELECT seq, node, edge, cost, agg_cost FROM pgr_dijkstra( 'SELECT gid as id, source, target, cost, reverse_cost FROM ways', 66619, 92554 ) ), full_path AS ( SELECT path.seq, path.node, path.edge, path.cost, path.agg_cost, ways.length_m AS length_m, ways.name AS line_name FROM path LEFT JOIN ways ON path.edge = ways.gid ) SELECT seq, node, edge, cost, agg_cost, length_m, line_name FROM full_path ORDER BY seq;

----- ダイクストラ66619, 92554 の結果の一覧表示

WITH path AS (
    SELECT 
        seq, 
        edge, 
        b.name AS line_name,
        b.the_geom
    FROM 
        pgr_dijkstra(
            'SELECT gid as id, source, target, cost, reverse_cost FROM ways',
            66619, 92554
        ) a
    INNER JOIN 
        ways b 
    ON 
        a.edge = b.gid
    ORDER BY seq
)
SELECT 
    MIN(seq) AS start_seq,
    MAX(seq) AS end_seq,
    line_name
FROM 
    path
WHERE 
    line_name LIKE '%Dummy Railway Line%'
    OR line_name LIKE '%Dummy Bus Line%'
GROUP BY 
    line_name
ORDER BY 
    start_seq;


以下のSQL文で、"Dummy Rail Line" と "Dummy Bus Line" に該当する start_seq と end_seq を取得できます。




SQL文






WITH path AS (
    SELECT 
        seq, 
        edge, 
        b.name AS line_name
    FROM 
        pgr_dijkstra(
            'SELECT gid as id, source, target, cost, reverse_cost FROM ways',
            66619, 92554
        ) a
    INNER JOIN 
        ways b 
    ON 
        a.edge = b.gid
    ORDER BY seq
)
SELECT 
    MIN(seq) AS start_seq,
    MAX(seq) AS end_seq,
    CASE 
        WHEN line_name LIKE '%Dummy Railway Line%' THEN 'Dummy Rail Line'
        WHEN line_name LIKE '%Dummy Bus Line%' THEN 'Dummy Bus Line'
    END AS line_type
FROM 
    path
WHERE 
    line_name LIKE '%Dummy Railway Line%'
    OR line_name LIKE '%Dummy Bus Line%'
GROUP BY 
    CASE 
        WHEN line_name LIKE '%Dummy Railway Line%' THEN 'Dummy Rail Line'
        WHEN line_name LIKE '%Dummy Bus Line%' THEN 'Dummy Bus Line'
    END
ORDER BY 
    start_seq;






 


SQL文のポイント


    

  1. WITH句で経路情報を取得:

      

    • pgr_dijkstra の結果に ways.name を結合して、全経路のエッジ情報を準備します。
      • 

    

    2. 

  2. CASE文で分類:

      

    • line_name に基づき、Dummy Rail Line と Dummy Bus Line の2種類に分類します。
      • 

    • この処理により、元の路線名が詳細でも、2つのカテゴリに整理されます。
      • 

    

    3. 

  3. MIN と MAX で開始と終了を取得:

      

    • 経路順序 (seq) の最小値 (start_seq) と最大値 (end_seq) を取得します。
      • 

    

    4. 

  4. グループ化:

      

    • CASE文で分類された路線タイプごとにグループ化 (GROUP BY) します。
      • 

    

    5. 

  5. ソート順序:

      

    • 結果は start_seq の順に並びます。
      • 

    

    6. 





結果例


以下のような結果が得られます：






start_seq
end_seq
line_type






1
10
Dummy Rail Line




12
15
Dummy Bus Line








注意事項


    

  • 必要に応じて、WHERE 条件や LIKE 演算子を調整してください。
    • 

  • 出力をさらに簡潔にしたい場合や、追加情報が必要な場合はお知らせください。適切に対応します。
    • 



 
















未分類


















未分類


select * from ways where name LIKE '%Dummy Railway Line%'; で選ばれたnode とwayを全部削除するにはどうしたら良いですか


ways テーブルにおける name 列の内容が '%Dummy Railway Line%' に一致する way と、それに関連する node を削除するには、以下の手順を実行します。ways テーブルと ways_vertices_pgr テーブルのリレーションを考慮した方法です。




手順


1. name 列が空か確認


name 列の値がすべて NULL または予期しない値かもしれません。以下のクエリで name 列の値を確認します。




SELECT
DISTINCT
name
FROM ways WHERE
name
IS
NOT
NULL;




 






2. 削除対象の gid を確認


対象となる gid を取得します。もし name が NULL である場合には以下のように NULL 対応を追加してください。




SELECT gid FROM ways WHERE
name
LIKE
'%Dummy Railway Line%'
AND
name
IS
NOT
NULL;




 




もし上記クエリに結果がない場合、代わりに以下を確認します。


    

  • tag_id や rule 列など他の列に対象の特徴があるか確認する。
    • 

  • 該当の値を直接確認する（例: IS NOT NULL を使う）。
    • 





3. 関連する node を特定


source や target のノードが ways_vertices_pgr テーブルに存在する場合、それを削除します。


以下のクエリで関連する source と target を確認します。




SELECT
source, target FROM ways WHERE
name
LIKE
'%Dummy Railway Line%'
AND
name
IS
NOT
NULL;




 




これにより、削除対象のノード source と target を特定できます。




4. 関連する ways_vertices_pgr の削除


取得した source および target に基づき、ways_vertices_pgr テーブルからノードを削除します。




DELETE
FROM ways_vertices_pgr WHERE
id
IN ( SELECT
source
FROM ways WHERE
name
LIKE
'%Dummy Railway Line%'
AND
name
IS
NOT
NULL
UNION
SELECT target FROM ways WHERE
name
LIKE
'%Dummy Railway Line%'
AND
name
IS
NOT
NULL );




 






5. ways テーブルの削除


最後に ways テーブルから該当する行を削除します。




DELETE
FROM ways WHERE
name
LIKE
'%Dummy Railway Line%'
AND
name
IS
NOT
NULL;




 






注意事項


    

  • バックアップを作成: データ削除は不可逆操作です。削除前にバックアップを必ず取得してください。
    • 

  • インデックスを活用: クエリ性能を向上させるため、適切なインデックスがあるか確認します（ways_pkey など）。
    • 

  • 依存関係: 外部キー制約があるため、削除の順序（ノード懼ウェイ）を守る必要があります。
    • 



これにより、name LIKE '%Dummy Railway Line%' に該当するデータを完全に削除できます。


この方法だと関連のあるnodeも消してしまうような気がします。wayだけ消せれば良いのです。


関連のある node を削除せずに、ways テーブルだけから特定の way を削除する場合、以下の手順で進めることができます。




方法


1. 削除対象の gid を確認


name に基づいて削除対象の way の gid を確認します。




SELECT gid FROM ways WHERE
name
LIKE
'%Dummy Railway Line%';




 






2. ways テーブルから対象の行を削除


特定した gid を使って ways テーブルから削除します。関連ノードは削除されません。




DELETE
FROM ways WHERE
name
LIKE
'%Dummy Railway Line%';




 






外部キー制約について


ways テーブルには外部キー制約が設定されていますが、ways テーブル自体からの削除では関連ノード（source や target）を削除する必要はありません。外部キー制約は、通常、ノードが削除される際に ways のデータが参照整合性を保つようにするためのものです。


この方法であれば、ways_vertices_pgr テーブルやその他の関連ノードはそのまま維持されます。




確認


削除後にデータが正しく削除されたかを確認するには、以下を実行してください。




SELECT * FROM ways WHERE
name
LIKE
'%Dummy Railway Line%';




 




結果が空であれば、対象の way が正しく削除されています。




コスト付き(hakata_ex_cost_db)とコストなし(hakata_no_dummy_db)の地図を2種類作れました。
















2024,江端さんの技術メモ


江端がずっとメンテナンスしているgetDijkstraPath関数は、costを変更することによって、ダイクストラ計算を引き曲げているので、距離が正確に出せない。


そこで、agg_costを使わずに、agg_length_mというものを作って、強制的に距離を作り出すようにコードを変更した。


 


func getDijkstraPath(dbMap *sql.DB, locInfoStart, locInfoGoal LocInfo) ([]LocInfo, float64) {

	var path []LocInfo // 経路　（返り値の一つ目）
	var totalDistanceKm float64

	// 例外処理 locInfoStart.source == locInfoGoal.source の場合
	if locInfoStart.Source == locInfoGoal.Source {
		source := locInfoStart.Source

		// SQLクエリの作成
		query := fmt.Sprintf(`
		SELECT x1, y1
		FROM ways
		WHERE source = %d;
	`, source)

		// SQLクエリの実行
		var x1, y1 float64
		err := dbMap.QueryRow(query).Scan(&x1, &y1)
		if err != nil {
			fmt.Println("tools.go line 204 error occures")
			//log.Fatal(err)  // ここで止めたらリターンしなくなる
		}

		var loc LocInfo
		loc.Source = source
		loc.Lon = x1
		loc.Lat = y1

		path = append(path, loc)

		totalDistanceKm = 0.0
		return path, totalDistanceKm
	}

	// こちらは、cost, reverse_cost を使っている
	query := `
	SELECT seq, source, target, x1, y1, x2, y2, agg_cost, length_m
	FROM pgr_dijkstra(
		'SELECT gid as id, source, target, cost, reverse_cost FROM ways', 
		$1::bigint, 
		$2::bigint, 
		directed:=false
	) a 
	INNER JOIN ways b ON (a.edge = b.gid) 
	ORDER BY seq
	`

	rowsDijkstra, errDijkstra := dbMap.Query(query, locInfoStart.Source, locInfoGoal.Source)
	if errDijkstra != nil {
		log.Fatal(errDijkstra)
		os.Exit(1)
	}
	defer rowsDijkstra.Close()

	var agg_cost float64
	var length_m float64
	agg_length_m := 0.0

	var loc LocInfo
	var x1, y1, x2, y2 float64
	var seq int
	var target int
	var source int

	isFirstCheck := true
	isSourceCheck := true

	count := 0

	for rowsDijkstra.Next() {
		// まずnodeを読む
		if err := rowsDijkstra.Scan(&seq, &source, &target, &x1, &y1, &x2, &y2, &agg_cost, &length_m); err != nil {
			fmt.Println(err)
		}

		agg_length_m += length_m
		// fmt.Println("length_m", length_m, "agg_length_m", agg_length_m)

		// 最初の1回だけチェックのために入る これについては、https://wp.kobore.net/江端さんの技術メモ/post-7668/を参照のこと
		// もし rowsDijkstra.Scanで最初のsource値を読みとり、locInfoStart.Source の値と同じであれば、x1,y1をベースとして、異なる値であれば、x2,y2をベースとする

		if isFirstCheck {
			if source == locInfoStart.Source {
				isSourceCheck = true // x1, y1をベースとする処理になる
			} else {
				isSourceCheck = false // x2,y2をベースとする処理になる
			}
			isFirstCheck = false // 最初の1回をチェックすることで、2回目はこのループには入らなくなる
		}

		//var loc LocInfo

		if isSourceCheck { // x1, y1をベースとする処理
			loc.Source = source
			loc.Lon = x1
			loc.Lat = y1
		} else { // x2,y2をベースとする処理
			loc.Source = target
			loc.Lon = x2
			loc.Lat = y2
		}
		path = append(path, loc)

		count++
	}

	// ラストノードだけは手入力 (ここは引っくり返す) (今、ここの部分は無視されている(いいのかな？))
	if isSourceCheck { // x1, y1をベースとする処理
		loc.Source = target
		loc.Lon = x2
		loc.Lat = y2
	} else { // x2,y2をベースとする処理
		loc.Source = source
		loc.Lon = x1
		loc.Lat = y1
	}

	// なんかprg_dijkstraが変な値を返す場合があるので、その対応(ロジカルではないが、パッチ的に対応)
	if loc.Source == locInfoGoal.Source {
		path = append(path, loc)
	}

	fmt.Println("count", count)

	if count == 0 { // 1行のみの場合、ヌルになるという問題に対応するため、
		loc.Source = locInfoGoal.Source
		loc.Lon = locInfoGoal.Lon
		loc.Lat = locInfoGoal.Lat

		// 入力値の指定
		source := locInfoStart.Source
		target := locInfoGoal.Source

		// SQLクエリの作成
		query := fmt.Sprintf(`
		SELECT length_m, x1, y1, x2, y2
		FROM ways
		WHERE source = %d AND target = %d;
	`, source, target)

		// SQLクエリの実行
		var length float64
		var x1, y1, x2, y2 float64
		err := dbMap.QueryRow(query).Scan(&length, &x1, &y1, &x2, &y2)
		if err != nil {
			log.Println("First attempt failed. Retrying with swapped source and target.")
			// 入れ替えたsourceとtargetの値でクエリを再実行
			query = fmt.Sprintf(`
			SELECT length_m, x1, y1, x2, y2
			FROM ways
			WHERE source = %d AND target = %d;
		`, target, source)
			err = dbMap.QueryRow(query).Scan(&length, &x1, &y1, &x2, &y2)
			if err != nil {
				//log.Fatal(err)  // 諦める。とりあえず、エラーを返す
				return nil, 0.0
			}
		}

		// 結果の出力
		fmt.Printf("length_m: %f\n", length)
		fmt.Printf("source: %d\n", source)
		fmt.Printf("target: %d\n", target)
		fmt.Printf("x1: %f\n", x1)
		fmt.Printf("y1: %f\n", y1)
		fmt.Printf("x2: %f\n", x2)
		fmt.Printf("y2: %f\n", y2)

		if source == locInfoGoal.Source {
			loc.Lon = x1
			loc.Lat = y1
		} else {
			loc.Lon = x2
			loc.Lat = y2
		}

		agg_cost = length

		fmt.Println("loc", loc)

		path = append(path, loc) // 354
	} // if count == 0

	//totalDistanceKm = agg_cost / 1000.0
	totalDistanceKm = agg_length_m / 1000.0
	return path, totalDistanceKm
}