[pgrouting-dev] pgrouting in batch mode ?

[Vicky Vergara]

Forgot to mention place of the meeting:
https://meet.jit.si/pgrouting


---------- Forwarded message ---------
From: Vicky Vergara <vicky at georepublic.de>
Date: Sun, May 17, 2020 at 10:48 AM
Subject: Re: pgrouting in batch mode ?
To: pgRouting developers mailing list <pgrouting-dev at lists.osgeo.org>
Cc: Mahmoud Sakr <m_attia_sakr at yahoo.com>, Arthur Lesuisse <
alesuiss at gmail.com>, Esteban Zimanyi <estebanzimanyi at gmail.com>


Hello all,

MobilityDB [1] [2] will be using pgRouting to test using the benchmarks
mentioned on attached mail

[1] https://github.com/ULB-CoDE-WIT/MobilityDB
[2] https://docs.mobilitydb.com/nightly/

The Agenda for monday meeting May 18, 2pm UTC = 9am in Mexico = 7:30pm in
India will be:
- Review of work done to have travis working
- Understanding MobilityDB + pgRouting + problem description
- Discussion of a possible solution to the problem



On Sat, May 16, 2020 at 1:53 AM Esteban Zimanyi <estebanzimanyi at gmail.com>
wrote:

> Dear Vicky
>
> 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.
>
> As a concrete example, the BerlinMOD data generator
> http://dna.fernuni-hagen.de/secondo/BerlinMOD/BerlinMOD.html
> 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
> https://www.mdpi.com/2220-9964/8/4/170/htm
> 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.
>
> 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%
>
> [image: VirtualBox_mobilitydb-dev_13_05_2020_17_11_39 (1).png]
>
> 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.
>
> Any idea how to achieve this ?
>
> Many thanks for your valuable help.
>
> Esteban
>
> ------------------------------------------------------------
> Prof. Esteban Zimanyi
> Department of Computer & Decision Engineering  (CoDE) CP 165/15
> Universite Libre de Bruxelles
> Avenue F. D. Roosevelt 50
> B-1050 Brussels, Belgium
> fax: + 32.2.650.47.13
> tel: + 32.2.650.31.85
> e-mail: ezimanyi at ulb.ac.be
> Internet: http://cs.ulb.ac.be/members/esteban/
> ------------------------------------------------------------
>


-- 

Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44,
81739 München, Germany

Vicky Vergara
Operations Research

eMail: vicky at georepublic.de
Web: https://georepublic.info

Tel: +49 (089) 4161 7698-1
Fax: +49 (089) 4161 7698-9

Commercial register: Amtsgericht München, HRB 181428
CEO: Daniel Kastl




-- 

Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44,
81739 München, Germany

Vicky Vergara
Operations Research

eMail: vicky at georepublic.de
Web: https://georepublic.info

Tel: +49 (089) 4161 7698-1
Fax: +49 (089) 4161 7698-9

Commercial register: Amtsgericht München, HRB 181428
CEO: Daniel Kastl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pgrouting-dev/attachments/20200517/9246c661/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: VirtualBox_mobilitydb-dev_13_05_2020_17_11_39 (1).png
Type: image/png
Size: 199925 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/pgrouting-dev/attachments/20200517/9246c661/attachment-0001.png>