<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Hello all,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">MobilityDB [1] [2] will be using pgRouting to test using the benchmarks</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">mentioned on attached mail<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">[1] <a href="https://github.com/ULB-CoDE-WIT/MobilityDB">https://github.com/ULB-CoDE-WIT/MobilityDB</a></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">[2] <a href="https://docs.mobilitydb.com/nightly/">https://docs.mobilitydb.com/nightly/</a></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">The Agenda for monday meeting May 18, 2pm UTC = 9am in Mexico = 7:30pm in India will be:</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">- Review of work done to have travis working<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">- Understanding MobilityDB + pgRouting + problem description<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">- Discussion of a possible solution to the problem</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 16, 2020 at 1:53 AM Esteban Zimanyi <<a href="mailto:estebanzimanyi@gmail.com">estebanzimanyi@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Dear Vicky<div><br></div><div>In mobility applications we need to generate data according to a given scenario at various scale factors to make simulations. This requires to send thousands of requests to pgrouting and this number of requests increases with the scale factor used for the generation.</div><div><br></div><div>As a concrete example, the BerlinMOD data generator</div><div><a href="http://dna.fernuni-hagen.de/secondo/BerlinMOD/BerlinMOD.html" target="_blank">http://dna.fernuni-hagen.de/secondo/BerlinMOD/BerlinMOD.html</a> <br></div><div>uses a workweek scenario in which persons go in the morning to work, return back to home in the afternoon, and possibly do an extra trip after working hours for leisure. As another example, we described in</div><div><a href="https://www.mdpi.com/2220-9964/8/4/170/htm" target="_blank">https://www.mdpi.com/2220-9964/8/4/170/htm</a> </div><div>a scenario in which a home appliances shop needs to deliver the appliances to the customers and thus vehicles are loaded at a warehouse in the morning and spent the day delivering to the clients given a specified schedule to finally return back to the warehouse at the end of the day.<br></div><div><br></div><div>We have done a first profiling of these data generators and realized that 87% of the time is spent in pgrouting building the graph thousands of times, at each query sent to pgrouting. On the other hand, the real work of MobilityDB only accounts for 0.11%</div><div><br></div><div><div><img src="cid:ii_ka99pe4v0" alt="VirtualBox_mobilitydb-dev_13_05_2020_17_11_39 (1).png" width="452" height="232"><br></div><div><div dir="ltr"><div dir="ltr"><div><br></div><div>For this reason we would need an API in which we build the graph once at the beginning of the simulation, send to pgrouting thousands of calls to pgr_dijkstra, pgr_aStar, pgr_dijkstraVia, etc. and then delete the graph, free the memory and start the simulation.</div><div><br></div><div>Any idea how to achieve this ?</div><div><br></div><div>Many thanks for your valuable help.</div><div><br></div><div>Esteban</div><div><br></div><div>------------------------------------------------------------<br>Prof. Esteban Zimanyi<br>Department of Computer & Decision Engineering (CoDE) CP 165/15 <br>Universite Libre de Bruxelles <br>Avenue F. D. Roosevelt 50 <br>B-1050 Brussels, Belgium <br>fax: + 32.2.650.47.13<br>tel: + 32.2.650.31.85<br>e-mail: <a href="mailto:ezimanyi@ulb.ac.be" target="_blank">ezimanyi@ulb.ac.be</a><br>Internet: <a href="http://cs.ulb.ac.be/members/esteban/" target="_blank">http://cs.ulb.ac.be/members/esteban/</a><br>------------------------------------------------------------</div></div></div></div></div></div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><pre>Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44,
81739 München, Germany
Vicky Vergara
Operations Research
eMail: vicky@<a href="http://georepublic.de" target="_blank">georepublic.de</a>
Web: <a href="https://georepublic.info" target="_blank">https://georepublic.info</a>
Tel: +49 (089) 4161 7698-1
Fax: +49 (089) 4161 7698-9
Commercial register: Amtsgericht München, HRB 181428
CEO: Daniel Kastl
<span></span></pre></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>