2022/07,江端さんの技術メモ

の後で、「一体、江端は何を考えているんだ」と思われるかもしれませんが、『宇都宮ライトレールの利用を拒否させるような、ダイクストラをどうやって作ろうか』と考えています ―― しかも、できるだけ手を抜いて。https://wp.kobore.net/%e6%b1%9f%e7%ab%af%e3%81%95%e3%82%93%e3%81%ae%e6%8a%80%e8%a1%93%e3%83%a1%e3%83%a2/post-6473/

ところで、今、いくつかDBを作っていますが、混乱しかけているので、メモを残しておきます。

utsu_tram_db  : 道路と鉄道の強制結合
utsu_tram_db2: 鉄道のコストを下げて、宇都宮ライトレールを優先的に選ばれるようにした
utsu_tram_db3: 宇都宮ライトレールを単線にして、取り扱いをラクにした

ただ、今、ここで、バスが宇都宮ライトレールの上を驀進するようになってきましたので、これを何とかしないといけなくなりました。

ここで逆転の発想で、

utsu_tram_db4: 宇都宮ライトレールを誰も使いたくなくなるくらいに、コストを爆上げしてやればいい

と気がつきました。

で、utsu_tram_db3と、utsu_tram_db4を併用してやれば良い、と気がつきました。


この続きを記載したのですが、反映に失敗したようです。

という訳で簡単に説明しますと、utsu_tram_db3のコスト(現在0.2倍)を、逆に100倍にしたものをutsu_tram_db4として作成しました。現在上手く動いています(色々失敗もしましたが、それを書き残す気力は、もうありません。この週末、20時間以上コーディングしていて、フラフラです)


ちなみに、上記の作業で作ったデータベースを、他の人に渡す為に、以下の作業を行いました。

# pg_dump -U postgres -p 15432 utsu_tram_db3 > utsu_tram_db3.sql
# pg_dump -U postgres -p 15432 utsu_tram_db4 > utsu_tram_db4.sql

で作った、2つのデータベースのダンプ(utsu_tram_db3.sqlと、utsu_tram_db4.sql)を圧縮したのが、こちら。

utsu_tram_db.zip

まず、
create database utsu_tram_db3;
\c utsu_tram_db3
create extension postgis;
create extension pgrouting;
(utsu_tram_db4についても同じ)

としておいてから

これをutsu_tram_db.zipを解凍して、

# psql -U postgres -p 15432 utsu_tram_db3 < utsu_tram_db3.sql
# psql -U postgres -p 15432 utsu_tram_db4 < utsu_tram_db4.sql

で、PostgreSQLにインポートできます(source番号なども完全一致する(はず))。

2022/07,江端さんの忘備録

我が家のトイレには、消し忘れ対策に、人感センサライトを使っています。

We use a motion sensor light in our restroom to prevent forgetting to turn of the light.

が、ここ数日、人感センサライトが全く反応しなくなりました。

However, the light has not worked well theses day..

ちょっと考えてみたのですが、多分、原因は、これです。

After thinking it a little, I noticed the reason.

人感センサライトは、体の移動による、赤外線放射の変化を検知して、ライトを付けいます。

The motion sensor light detect a changes in infrared radiation with moving human body, and turn on the light.

ならば、トイレの室温が体温以上であったとすれば ―― 当然、センサは赤外線を検知できません。

Then the tempterture of the restroom is higher than those of human-body, the sensor cannot detect any infrared radiation.

36度を越える気温が発生する場所と時間では、赤外線センサ付きの防犯ライト等は、完全に無力化します。

Therefore wherever and whenever the temperature is higher than 36 degrees Celsius, the effect of security lighting with infrared radiation sensors is missing perfectly.

-----

夜間に36度を越える熱帯夜 ―― 考えるだけで悪夢です。

Tropical nights with temperatures exceeding 36 degrees Celsius at night -- just thinking about it is a nightmare.

でも、数年前には『日中に40度を越える』という猛暑日の連続など、誰も想定していなかったはずです。

However we must remember that nobody could predict a series of extremely hot days (more than 40 degrees Celsius) a few years ago.

2022/06,江端さんの忘備録

私、高校での体育の授業がなくなってから、スポーツが好きになりました。

After graduation from high school and losing gym class, I came to life sports.

(ちなみに、私が、絶望的な運動音痴だったお話は、こちらです)

正直に言いますけどね、本当に『みじめ』でしたよ。

(Here is a story that I was hopeless klutz)

大学ではスキーにはまり、就職後はテニスを始めました。

I was enthusiastic about skiing in college, and I started playing tennis in company,

-----

私、TOEICや英検などのことを、意図的に忘れるようになってから、英語を使うことに抵抗がなくなりました。

After forgetting TOEIC and Eiken intentionally, I was no longer afraid to use English.

自分の好きなように英語をしゃべり、英文のコラムや論文を書きまくるようになりました。

I used to speak English in my way, and I came to write my columns and papers in English.

-----

訳あって、今、またTOEICの勉強をしているのですが ―― 今ならはっきり言えますが

With some private reasons, now I begin to study about TOEIC. And now I can say clearly,

「このテスト、心底下らない」

"This test is ridiculous and meaningless"

です。

例えば、TOEICでの単語の選択肢の問題ですが、『正解が2つ、下手すると3つある問題があります』。

For example, about the word choice questions, I know that some questions have more than two correct answers.

名詞は形容詞的に使ったって問題ないし、副詞なんぞ、文章のどこに出てきたって、意味は通じます。

Nouns can be used adjectivally without any problem, and adverbs can make sense wherever they appear in a sentence.

会話問題に至っては、「会話の目的をexplicitに語れないこいつらは、なんて低能なんだ」と思います(本当)。

About the conversation question, I really think that "how low they are that they can't EXPLICITLY talk about the purpose of the conversation" (I think it is true).

こんなものに費やす時間で、海外に行けますし、英語の論文も書けて、運がよければ論文賞を貰えます ―― 断言します。

With the time you spend on this ridiculous and meaningless test, you can go abroad and write a paper in English, and if you are lucky, you get an award. I assure you.

-----

英語を本気で使いたければ、TOEICなんぞは忘れてしまう ―― これが正解です。

If you want to use English seriously, you should forget the existence of TOEIC. This is a correct answer.

しかし、日本というシステムは、どうしても「ものさし」を求めるものです。

However, the system of called "Japan" needs a "measure" for your English ability.

英語力を評価できる人材がいないからです。悪循環です。

There are few people to judge your ability correctly, This is a typical negative feedback system.

それ故、我が国には、TOEICから逃げられないというシステム上の問題がありますが、これを、いくら批判しても仕方ありません。

Therefore, in Japan system, we cannot run away from English Test like TOEIC because of the defect of the system. It is no use to blame this system with loud voice.

-----

「TOEICは、人生の脇に置いて、不真面目に勉強する」が肝要です。

The conclusion is that "Don't study TOEIC seriously, and set it aside from your life".

真面目にやったら、本来の目的を失いかねません。

If you do it seriously, you might lose the purpose of your life.

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/06,江端さんの忘備録

本日は、コラムがリリースされた日なので、日記はお休みです。

Today, new my column is released, so I take a day off.

「お金に愛されないエンジニア」のための新行動論(4)

株価データベースを「Docker」で作ってみる

"A New Theory of Action for Engineers Who Are Not Loved by Money(4)"

Let's try to make a stock database by "docker"

------

後輩からのレビューを受けている時に、Dockerの概念の説明について、コンプライアンス的な観点から指摘を受けました。

When I got a review about this column from the junior colleagues, he pointed out the explanation of the concept of Docker, from the viewpoint of compliance.

昨今、「愛人」なる表現が問題になるのは、よく分かっていましたし、変な炎上を回避する観点からも、インモラルな表現は避けるべきです。

These day, the expression of "Mistress" might to be a problem, I know. And in order to avoid annoying flame, I should not use immoral expressions.

(ちなみに、オリジナルは「妾宅」でした)

(Incidentally, the original expression was "concubine house")

-----

で、その後輩の指摘を受けて、私、かなり考えたのですが ―― 良い表現が思いつきませんでした。

After getting the argue, I thought it again deeply, however, I could not come to a good one.

というか、Dockerを、もっと正確に表現しようとすると、

On the contrary, if I try to express it exactly,

『双子の姉妹を、同じマンションの別の戸に囲う』

"Twin sisters are enclosed in separate units in the same apartment building."

になってしまい ―― もっと印象が悪い。

I can agree that this expression become worse.

Dockerは、全く同じアプリケーションを小さなサービス(マイクロサービス)として、同じコンピュータに矛盾なく同居させれるもので、さらに言えば、

Docker works as a micro-service including same application at the same time with no contradiction. If I try to express these micro-services,

『双子の姉妹と同時にXXXX』は、さらに正確です。

"can do something with the twin sisters simultaneously" is more accurate.

Dockerのアクセスポート番号を変えれば、2つ以上のデータベースを同時に扱うことができ、で、実際、私、そういう使い方しています。

Using different port numbers of each Docker, you can use more than two database simultaneously. I really use docker containers like the way.

まあ、「総じて、江端の発想には品がない」と言われれば、私自身が率先して同意できるくらいです。

Well, even I can agree with you, if you say "Ebata's imagination is vulgar"

-----

「江端=下品」については、こちらの記事で、そのような指摘をしている人がいましたが、

According to the "Ebata's imagination is vulgar", a people said that in this column,

私としては、

However, I wanted to say,

―― それなら、この内容を「上品」に書いたものを、私に見せてくれ

"Rewrite it elegant and show me it"

と言いたかったです。

2022/06,江端さんの忘備録

エアコンが寒いです。

I feel cold by air-conditioned.

在宅勤務で、自室の温度は29~30度に設定しているのですが、それでも寒い。

while I work as a telecommunication worker, I set the temperature 29-30 degree. Celsius in my room, however, I feel cold.

まあ、下着同然で過していることや、高齢による体内の省エネモードが効いているのだと思います。

One of the reason is to work wearing only under wears, and another is my senior body, which work as economical mode.

しかし、エアコンをOFFにすると、いきなり室温が上がり始めます。

But truing the air-conditioned off, the temperature in the room begins to increase dynamically.

という訳で、1時間単位で、手動スイッチング制御を行っている感じです。

In the situation, I have to do a hand switching control every one hour by myself.

-----

「高齢者がエアコンの使用を忌避する」というのを、「もったいない精神」に因るものだと思っている人 ―― 私もその1人でしたが ―― 認識を改めて下さい。

Some people think that the reason why seniors avoid using air-conditioned, is based on "mottainai spirit", should change their recognition, including me.

高齢者にとって、エアコンは「本当に寒い」のです。

For elders, air-conditioned makes them really feel cold.

しかし、エアコンがないと、熱中症に一直線というのも事実です。

On the other hand, without air-conditioned, they are going to be heat stroke directly.

私、最近、2回のハンガーノックを体験しているのですが、私のハンガーノックは、その直前まで自覚症状がありませんでした。

高齢者が熱中症で倒れる ―― というのは、父が実家で一人で住んでいた時、現実的な恐怖でした。

Recently I have experienced twice hunger-knocks, however, I could not feel any signs just before them.

おそらく、熱中症も、同じプロセスを辿るのだと思います。

Maybe, a heatstroke occurs at the same approach too.

完全に無自覚のまま、いきなり「倒れる」「重症化」「死亡」に至ります ―― 本当に「喉が渇く」ということが『ない』のですから、手の打ちようがありません。

They are suddenly going to fall down, serious illness and death with no sign. It cannot be helped because they could not feel thirsty.

ぶっちゃけ、高齢者にとっての夏は、屋外も屋内も危険なのです。

To be honest, both inside and outside in summer are dangerous for elders.

-----

という訳で、私が、世界の電機メーカーに期待するのは、

Now I am expecting to world electric companies to R&D for a new products,

―― 寒くないエアコンの研究開発

"coldless (x cordless) air-conditioned"

です。

「何、訳の分からないことを・・・」と、今は、思われるかもしれませんが ――

You might think "What is Ebata saying this time?"

いずれ、誰でも、私の言っていることが、理解できるようになります。

Eventually everyone who read this, will understand what I am saying.

未分類

Amazon は、時々

という表示を出しつつ、「配送不可」といい、「キャンセル」し「返金を完了する」ということをします―― 理由の説明もなく、です。

普通に考えれば、「自宅の前まで来て、配送するのを思い留まった」と見えますよね?

これまで、この手の一方的な「キャンセル&返金」を2回ほど食っています。

で、今日も、自宅前まで来ている(のか?)荷物の配送日が、『7月1日までに届かなければ、キャンセルしていいよ』というメッセージに変わっていました。

なんだろう、Amazonから、江端家への高度な「嫌がらせ」なんだろうか?

しかし、もしそうだとすれば、費用対効果がダメダメの嫌がらせです。


2022/06/29追記

やっぱり、こうなった。

2022/06,江端さんの技術メモ

宇都宮ライトレールを単線にして分かりやすくしてみた件

の続編です

utsu_tram_db3(コスト値改ざん+LRT路線改ざんのデータベース)を使って、乗り換え地点を算出する、をやってみました。

utsu_tram_db3=# SELECT seq, node, edge FROM pgr_dijkstra('SELECT gid as id, source, target, cost FROM ways', 1200, 12000, directed:=false);
seq | node | edge
-----+-------+-------
1 | 1200 | 29995
2 | 1201 | 291
3 | 370 | 43579
4 | 18420 | 42387
5 | 1202 | 20089
6 | 1203 | 10026
7 | 1151 | 20094
8 | 1223 | 19060
9 | 30564 | 5625
10 | 18415 | 20069
11 | 1143 | 271
12 | 1141 | 9793
13 | 135 | 9794
14 | 1218 | 295
15 | 1221 | 297
16 | 18403 | 15478
17 | 18397 | 20191
18 | 1551 | 25527
19 | 18400 | 405
20 | 1531 | 418
21 | 1561 | 28006
22 | 26620 | 20199
23 | 1578 | 37996
24 | 26628 | 30131
25 | 1582 | 30133
26 | 1585 | 28213
27 | 27344 | 29873
28 | 733 | 58915
29 | 42213 | 48439
30 | 60 | 9780     最初の0より大きくて100より小さい正数が2つ連続で出てくる時 
31 | 59 | 39645   ← ここがLRTの乗車ノード
32 | 57 | 42199
33 | 56 | 39644
34 | 54 | 39643
35 | 52 | 48847
36 | 43717 | 60590
37 | 43716 | 60589
38 | 49 | 39641
39 | 48 | 39640
40 | 33440 | 44769
41 | 46 | 39639
42 | 44 | 39637
43 | 41 | 48374
44 | 42003 | 58686
45 | 42004 | 58687
46 | 42941 | 59674
47 | 42942 | 59675
48 | 41986 | 58669
49 | 39 | 48373
50 | 41997 | 58680
51 | 42001 | 58684
52 | 42002 | 58685
53 | 38 | 48588
54 | 42665 | 59406
55 | 42943 | 59676
56 | 42143 | 58846
57 | 41988 | 58671
58 | 41989 | 58672
59 | 41998 | 58681
60 | 33444 | 48960
61 | 42005 | 58688
62 | 41999 | 58682
63 | 42000 | 58683
64 | 42007 | 58690
65 | 42006 | 58689
66 | 42009 | 58692
67 | 41990 | 58673
68 | 42008 | 58691
69 | 42654 | 59396
70 | 33441 | 44770
71 | 36 | 39634
72 | 34 | 39633
73 | 62 | 39646
74 | 31 | 48368
75 | 41991 | 58674
76 | 30 | 48369
77 | 41992 | 58675
78 | 41993 | 58676
79 | 41994 | 58677
80 | 42653 | 59395
81 | 42010 | 58693
82 | 42011 | 58694
83 | 27 | 9777  ← ここがLRTの降車ノード
84 | 28 | 9776  最初の0より大きくて100より小さい正数が2つ連続で出てくる時 
85 | 20482 | 45133
86 | 33950 | 49670
87 | 13270 | 40742
88 | 13515 | 43318
89 | 11988 | 40674
90 | 12000 | -1
(90 rows)

さて、この乗車ポイントと降車ポイントをどうやって探すか(できるだけ手を抜いて)。

結局、こうなりました。

// go get github.com/lib/pq を忘れずに
// go run main10.go

/*
	経路の分離点を抽出してみる
*/

package main

import (
	"database/sql"
	"fmt"
	"log"

	_ "github.com/lib/pq"
)

func main() {
	// utsu_tram_db3をオープン
	db, err := sql.Open("postgres", "user=postgres password=password host=localhost port=15432 dbname=utsu_tram_db3 sslmode=disable")
	if err != nil {
		log.Fatal("OpenError: ", err)
	}
	defer db.Close()

	// node番号 1200 から 12000 までのダイクストラ計算を行う
	str := "SELECT seq, node, edge FROM pgr_dijkstra('SELECT gid as id, source, target, cost FROM ways', 1200, 12000, directed:=false)"
	rows, err := db.Query(str)

	if err != nil {
		log.Fatal(err)
	}
	defer rows.Close()

	var seq, node, edge int
	var add_node_num = []int{} // 可変長配列

	for rows.Next() {
		if err := rows.Scan(&seq, &node, &edge); err != nil {
			fmt.Println(err)
		}

		// ルート分離は、0<x<70の値が出てきたら、駅のノードである、とする。
		// 何しろ、私が地図を改ざんしたのだから間違いない
		// で、その値を全部格納する

		if node > 0 && node < 70 {
			add_node_num = append(add_node_num, node)
		}
	}

	if len(add_node_num) != 0 { // 見つけることができたら最初から2番目と、最後から2番目の番号(0 < X < 70)を取り出す
		first_node := add_node_num[1]
		last_node := add_node_num[len(add_node_num)-2]

		fmt.Println("first_node:", first_node, "last_node:", last_node)
	} else { // 見つけることができなかったら
		fmt.Println("No node")
	}
}

 結果
c:\Users\ebata\goga\1-9-9-1\others>go run main10.go
first_node: 59 last_node: 27

2022/06,江端さんの忘備録

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

をやっているのですが、宇都宮LRTは複線(つまり2本ある)、ダイクストラ計算する時に面倒くさいので、JOSM上で強制的に単線にしてしまいました。

で、まあ、結局、データベースを最初から作り直しとなり、週末が全部ふっとびました。

改ざんしたOSMファイルはこちらです →  utsunomiya-lrt-latest-3-no_modify.osm
(改ざん前)

(改ざん後)

加えて、LRTの登りと下りが同じ経路を通っていないみたいで、頭をかかえていました。

59、2は、LRTの端点のsourceです。

utsu_tram_db3=# SELECT node, edge, cost FROM pgr_dijkstra('SELECT gid as id,source, target,length as cost, reverse_cost FROM ways',59, 2);
node | edge | cost
-------+-------+------------------------
59 | 39645 | 0.000838932462205439
57 | 42199 | 0.00017001043575301866
56 | 39644 | 0.0006648489696234544
54 | 39643 | 0.0001856669446528486
52 | 48847 | 0.00023156077313171402
43717 | 60590 | 0.0008988270825760914
43716 | 60589 | 0.00024913429002363974
(中略)
6 | 39627 | 0.0013247287163596904
3 | 39626 | 4.3848865768758054e-05
2 | -1 | 0
(67 rows)

で、この、59, 2をひっくり返すと

utsu_tram_db3=# SELECT node, edge, cost FROM pgr_dijkstra('SELECT gid as id,source, target,length as cost, reverse_cost FROM ways',2, 59);
node | edge | cost
-------+-------+------------------------
2 | 6 | 0.00011771065375457692
1 | 41208 | 0.0006123344685235885
20511 | 26189 | 0.0023489322317445127
13446 | 33830 | 0.0006745722936052778
26440 | 8017 | 0.0017400311472012054
(中略)
54 | 39644 | 0.0033242448481172722
56 | 42199 | 0.0008500521787650932
57 | 39645 | 0.0041946623110271945
59 | -1 | 0

(117 rows)

数が合わない。 あれー、 reverser_costを入れれば、いいんじゃないの? と悩んでいました。

QGISで見ている限り、問題ないように見えます。

ちょっと調べてみたら、パスの方向を見られている可能性に気がついて、(1)reverse_costを抜いて、(2)length as cost を cost にして、(3)directed:=false を付けてみました。

utsu_tram_db3=# SELECT seq, node, edge FROM pgr_dijkstra('SELECT gid as id, source, target, cost FROM ways', 2, 59, directed:=false);
seq | node | edge
-----+-------+-------
1 | 2 | 39626
2 | 3 | 39627
3 | 6 | 42190
4 | 7 | 58678
5 | 41995 | 48370
6 | 10 | 42191
(中略)
62 | 43717 | 48847
63 | 52 | 39643
64 | 54 | 39644
65 | 56 | 42199
66 | 57 | 39645
67 | 59 | -1
(67 rows)

utsu_tram_db3=# SELECT seq, node, edge FROM pgr_dijkstra('SELECT gid as id, source, target, cost FROM ways', 59, 2, directed:=false);
seq | node | edge
-----+-------+-------
1 | 59 | 39645
2 | 57 | 42199
3 | 56 | 39644
4 | 54 | 39643
5 | 52 | 48847
6 | 43717 | 60590
(中略)
62 | 10 | 48370
63 | 41995 | 58678
64 | 7 | 42190
65 | 6 | 39627
66 | 3 | 39626
67 | 2 | -1
(67 rows)

同じ数(67 rows)になり,対称性も担保できているようです。

2022/06,江端さんの忘備録

一時期は、その強烈な毒性によって私たちを恐怖に陥れた新型コロナウイルスは、全世界的なワクチン接種によって抑え込まれました。

The new Corona Virus(COVID-19) with intense virulence, that be scared by people, has been suppressed by world wide vaccination.

その結果、弱い毒性の変異ウイルスとして生き残ることで、人類との共存戦略に切り替えました。

As a result, the virus changed to be weaker than the previous strains, and they has started to get a new strategy to live with human-being.

―― というのは、これまでの、人類のウイルスとワクチンの闘いの定番であり、特段珍しい話ではありません。

This is a typical way for virus to survive with human, not a special story.

ただ、その被害は大きかった。

However, the number of vivctim was tragedy.

我が国で3万人以上、全世界では500万人以上が死亡、というのは、人類史上でも未曾有の大災害だと思います。

More than 30 thousand persons in Japan, more than 5 million persons in the world was historical unprecedented disaster.

しかも、この災禍は、終了している訳でもありません。

In addition, this disaster is not finished.

とはいえ、ここらで一つの区切りとして、この新型コロナウィルスの災禍の総括をするのも良いのではないかな、と思っています。

Nevertheless, I think it would be a good idea to summarize this new coronavirus disaster as a break from the rest of the world.

ちょっと、今、検討中です。

I am thinking about it.

それはさておき。

Back to the board.

-----

今、「マスクを外さない人が問題になっている」そうです。

I heard that the people who don't stop using masks is a social problem now.

私、もっとも致死性の高かった、アルファ株、ベータ株が猛威を奮っていたときでも、1人で散歩している時には、マスクを外していました。

In my case, I didn't use a mask when I was walking alone, even while Alpha strains and Beta stock were raging in the world.

1人の部屋にいる時には、当然に外していました。

When I was alone in my room, of course, I didn't use it.

ネットで、『1人で部屋にいる時でも、マスクを付けていなければ、感染するかもしれない』と思っている人がいるのを知って、びっくりしたことがあります(嫁さんは『ウソかデマだろう』といっていました)。

When I know that there are some person who think to use a mask when they are alone in the room, I was really surprised. (my wife said that it was a lie or a demagogue)

-----

マスクは、近距離の飛沫によるウイルスの「被爆量」を少なくすることによって、感染リスク(数値)を下げるものです。

The effect of masks are deceasing the risk of infection by reducing the "exposure" to virtues from droplet at close range.

感染リスクは、(1)ウイルス株の毒性 x (2)他人からの飛沫量(= マスクによる飛沫量の減衰 x 他人との距離 x 他人との時間) x (3)感染者数の比率 、という非常に単純なかけ算で決まるものです。

The infection risk is decided by a simple multiplication of f (1) the virulence of the virus strain, (2) the amount of droplets from others (= attenuation of droplets by masks x distance from others x time spent with others), and (3) the radio of number of people infected.

現状、(1)の毒性が下がり、(3)の感染者数が減っていることから、(2)のソーシャルディスタンスを担保できる環境にいれば「マスクは必要ない」というのは、極めて当然の勧告です。

Therefore, now (1)virulence is going down, (3)the ratio is also going down, so, the advice of "No mask, no problem" under the keep social distance, is a natural result.

もちろん、「0.001より、0.0001は、1/10小さい数になる」という意味において、マスク着用に意味がない訳ではありませんが ―― それで、別のリスク(熱中症等)が、100倍になったら、意味ありません。

Of course, using mask is a significant from the viewpoint of "0.001 is bigger than 0.0001", however, even if it loaded another risk (Heat stroke, etc.), it should be nonsense.

ここ2年間は、このリスクは、バランスが取れていたのですが、今、このバランスは崩れています。

For this two years, the both risk are almost equal. however, now the balance is collapsed.

今は、熱中症の方がリスクが高いのです。

Now heat shocks are risker than the infections.

-----

私は、コロナ禍を、スタートから今に至るまで、ずっと「数字」と「確率」で、見続けてきました。

I have watched this COVID-19 disaster from the beginning, as "Math." and "Probability".

さっきの「総括」の話ですが、一つには『今回のコロナ禍を、数学と統計で観測し続けてきた人は、極めて少数だった』という事実が導き出せるのかもしれない、と思っています。

According to the above "summarization", I think that one of them might be "few people is watching disaster from the viewpoint of mathematics and statics".