Using lambda / registered callback function to dynamically calculate cost for edges
メンテナーはふだん 2 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 25/100
調査の方向性
The issue is about modifying pgr_drivingDistance to support dynamic edge costs via a callback. Look at the pgr_drivingDistance source code in the pgRouting library to understand the current cost handling. The callback would need to accept edge details and accumulated cost, returning a calculated cost. This requires changes to the function signature and internal logic, and likely extending the SQL interface to accept a function reference or array column.
索引モデルが issue の本文から書いたものです。
説明
I am working on an interesting problem regarding the use of pgr_drivingDistance that I thought you might have some thoughts about.
It concerns calculating the correct cost over long distances with maps where the cost for each edge can differ depending on the time of day.
Example: I have a map where max. speed on the roads differs for every 15 minutes (like on the OSM) If I want to drive a long distance eg. 100 km, I can start at 09.00. Then after the first maybe 3 edges (eg. 15-20 km) the time is now 09.15 and the costs for the remaining edges could now differ substantially. After another few edges it's 09.30 and the same happens again and so on...
pgr_drivingDistance needs an sql that returns the entire graph with - at the time of querying - have a fixed cost on each edge. So from that point of view, the above example would not be possible to calculate correctly, since we will only be able to supply all edge-costs based on the time 09.00.
I have been bashing my mind to figure out a solution to this, and I've come up with something that also might not cost too much performance:
Instead of pgr_drivingDistance taking the edge cost directly from the sql result, it should run a callback function with the parameters
- edge structure (id, source, target, cost, reverse_cost)
- accumulated cost so far)
The callback should then return a calculated cost for the edge in question
For this to work, the structure sent to pg_drivingDistance might also need to be more lenient (ie. accept a "cost" column that is an array of floats instead of just a single float etc.)
Let me hear what you think of this.
- 主要言語
- C++
- スター
- 1.4k
- フォーク
- 397
- 平均マージ
- 2日 2時間
- マージ済み PR（30日）
- 4
環境構築
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
pgRouting/pgrouting のほかの issue
-
Boost broken links対応中かも @Nandan-Raichura-Dev が 1 日前に担当しました。 オープンEnhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
pgRouting/pgrouting#3176 · コメント 1 件 ·
メンテナーはふだん 2 日以内に返信
-
Administrative Enhancement
難易度 1/5 1時間未満 初心者へのやさしさ 80/100
メンテナーはふだん 2 日以内に返信
-
points_input Developers doc対応中かも @withaman69 が 85 日前に担当しました。 オープンC/C++ Developers Doc. good first issue
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
pgRouting/pgrouting#973 · コメント 10 件 ·
メンテナーはふだん 2 日以内に返信
-
get_check_data developers doc対応中かも @withaman69 が 87 日前に担当しました。 オープンC/C++ Developers Doc. good first issue
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
pgRouting/pgrouting#972 · コメント 7 件 ·
メンテナーはふだん 2 日以内に返信
-
circuits Functionality Request
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
メンテナーはふだん 2 日以内に返信
pgRouting/pgrouting の issue をすべて見る
似ている issue
-
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
ROCm/FastFlowLM#887 ·
メンテナーはふだん 1 日以内に返信
-
paraview 6.2.0 uses Abseil 20260526 symbols but does not pin libabseil (undefined symbol with libabseil 20260817)対応中かも @jschueller が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 64/100
-
bug medium priority openmp tokenizer wrong result
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 92/100
apache/casbin-cpp#277 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
iamaisim/ProjectAirSim#241 ·
メンテナーはふだん 1 日以内に返信