皆さん、こんにちは、
Transit Network Analysisツールを見つけました。素晴らしい仕事で、本当に素晴らしいです。
都市全体の交通ネットワークでCalculate Travel Time Statisticsツールを使いたいと強く思っています。テストできる並列計算が可能なバージョンはありますか？
平均移動時間をhuff gravityモデルの入力として使いたいのですが、処理完了までに何時間も待つことになるのではと心配しています。
よろしくお願いします、
Michael
Hello Michael. It might be too late for you now, but I have implemented a parallelized version of Calculate Travel Time Statistics for OD Cost Matrix. You can get it on GitHub or download it here. The new version outputs the results to a CSV file, which is generally more efficient to write out to than the a file gdb table. However, I could add more output types if necessary.
Hello Michael. Thanks for your request.
Although I have parallelized the other tools in that toolbox, I haven't done this one yet. I honestly wasn't sure if anybody was using this tool, so thank you for confirming that it has at least some value.
I can add it to my to-do list to create a parallel version of this tool, although I can't commit to doing it in the immediate future (lots of other stuff on my plate right now).
Have you tested the current tool to determine if performance is really a problem? It definitely CAN be faster if I parallelize it, but it's possible that it isn't...completely terrible...as it is...maybe...
Hi Melinda,
Thanks for the quick response!
Honestly I'm at the crunch point of my honors thesis, so I just went ahead a ran with the tools I had available. I haven't done a lot of stuff at this kind of scale before, so I'm not really in a position to judge whether the performance was as expected. For some context, I'm doing an accessibility analysis for access to healthcare in my city, with:
With this setup, I found that the tool was taking about 10 - 15mins to solve each run, so about 6hrs compute time to solve each 'day' on the transit network. I repeated for four different days (to cover all variation in the transit schedule), so required 24hrs of compute time.
I would have loved to have simulated a much smaller interval (down at 10 or 5 mins perhaps), but that clearly wasn't an option here. If I'd done 5 min intervals, it would have required ( 10mins run time * 16.5 transit hours * 12 runs/hr * 4 days / 60 mins/hour) 132 of compute time?
So I don't think that is doable. However, I'm still very grateful that I didn't have to write the code from scratch. No urgency on further development, I've got the data I needed for this project. I'm hopeful I'll get the opportunity to continue with this line of inquiry after my thesis, so if you produce a parallel version down the track I'll certainly make good use of it.
Cheers,
Okay, I'm glad you got what you needed. My one caution about a 30-minute interval is that some transit service runs on a 30-minute interval, so you may get some weird effects where the system is effectively in the same state every 30 minutes, which is not representative of the state(s) it's in during the times between those 30 minutes. Like if person A lives right next to a bus stop with a bus coming every 30 minutes, and they've just missed that bus by 1 minute, then it shows them as perpetually unable to get to their doctor's appointment, even though there are some times of day (like 1 minute before each analysis time slice) when they actually can.
Yeah absolutely - thanks for the advice. I'll flag that as a limitation of my analysis for now, and re-run the models sometime down the track.
Just to add to the conversation, in a study I did recently I also had to deal with this same problem of balancing processing time with temporal coverage. I chose a time interval offset of 23 minutes. That way each iteration would start at a different minute of the hour over the course of the service day. I was trying to avoid that situation where the iteration start times and the transit trip times would sync up due to regular frequencies. If I remember correctly, I did 4 separate batches each with about 1,000 origins and between 30 - 80 destinations (they were different facility types, e.g., healthcare, education, etc.) and each run on my machine took between 4 and 10 hours and processed overnight. Also, on each run, the start times were offset by one minute (.e.g, 5:00 am, 5:01 am) so that over all the runs I would have even more diversity of trip start times. That may have been unsolicited information, but I thought it may help a little.
@MichaelVernon
A couple of follow-up questions for when I parallelize and update the Calculate Travel Time Statistics tool.
Not at all, thanks Philip.
Thanks! Michael
You are a wizard! It is too late for my thesis, but I'm sure I'll be coming back to this work and doing more analysis. I really appreciate you following through.
CSV doesn't bother me, its straight forward enough to just load that back to a file gdb table after the tool runs.
サインインしたメンバーは投稿、更新のフォローなどができます。初めてですか？無料アカウントを登録してください。
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.
