Using lambda / registered callback function to dynamically calculate cost for edges
维护者通常 2 天内回复
还没有人认领这个 Issue。
评估
调研方向
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 小时
- 30 天内合并 PR
- 4
环境准备
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 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 一周以上 新手友好度 35/100
维护者通常 2 天内回复
查看 pgRouting/pgrouting 的全部 Issue
相似的 Issue
-
难度 1/5 1 小时以内 新手友好度 88/100
ROCm/FastFlowLM#887 ·
维护者通常 1 天内回复
-
bug medium priority openmp tokenizer wrong result
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复
-
good first issue invalid
难度 1/5 1 小时以内 新手友好度 72/100
DanielJerolm/gpcc#74 ·
-
难度 2/5 1-3 小时 新手友好度 76/100
patrick-hudson/put.gd-desktop#808 ·
维护者通常 1 天内回复
-
DPI change is not fully handled in the cascading window on Windows可能已有人在做 @yukawa 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 74/100
维护者通常 4 天内回复