This improvement was suggested by one of the extremely helpful reviewers of the paper titled "VeRoViz: A Vehicle Routing Visualization Toolkit" (https://dx.doi.org/10.2139/ssrn.3746037). See also #36, #37, #38, #39, and #40.

• Our code could benefit from a formatter, such as:

  • Black https://black.readthedocs.io/en/stable/
  • yapf https://github.com/google/yapf

• Also, take a look at https://realpython.com/python-code-quality/ for a discussion on Linters.

The original reviewer comment appears below:

This is personal preference, but standardising the Python formatting by the use of some formatter (e.g. black or yapf) makes the code more readable. Also, I had issues with the tabs/spacing when I was editing some snippets, this would be avoided with such formatting tools.

Bug Description
CESIUMDIR environment variable is not recognized in jupyter notebook even after describing its path

To Reproduce
Describe the path of CESIUMDIR in pico ~/.profile.
For e.g export CESIUMDIR="/Users/akhilsinghchauhan/Downloads/IE\ 670\ Dr.chase/Cesium-1.7$

Even after describing the full path of the CESIUMDIR environment variable, it is not recognized

Python Version:

• [] Python 3

VeRoViz Version:

It's a good idea to verify that you're working with the latest version of VeRoViz:

'Your current installed version of veroviz is 0.4.3. You are up-to-date with the latest available version.'

Operating System :

• Mac
• Windows
• Linux
• other

Browser [chrome, safari]

When I used the getShapepoints2D function, there was the expDurationSec parameter, which allows my vehicle to travel in the expected seconds on a road. However, when I wanted to do a similar thing in getShapepoints3D, there wasn't any 'expDurationSec'. I did not find any other parameter that can be replaced with the expDurationSec in this 3D function.

It would be nice to have 'expDurationSec' so any drone can travel slowly to its destination in the 3D model.

These are the documentation:
getShapepoints2D
getShapepoints3D

Please use the template below to submit your bug report.

Describe the bug
when using createArcsFromNodeSeq() function, it generates error. (see below screenshot)

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
Should create arcs based on node sequence

Screenshots

Python Version (please complete the following information):

• Python 2
• Python 3

VeRoViz Version:

# Paste the result of the following Python command:
myArcs = vrv.createArcsFromNodeSeq(initArcs = arcs,
                                   nodeSeq  = route['truck'], 
                                   nodes    = belgium_df, 
                                   objectID = 'Truck')

Operating System (please complete the following information):

• Mac
• Windows
• Linux
• other
• Browser [e.g. chrome, safari]
• Version [e.g., 16.04 or Windows 10]

Additional context
Add any other context about the problem here.

In an effort to increase VeRoViz adoption, it would be nice to include a functionality to import some of the popular/classical TSP/VRP benchmark instances.

Many of these use (x,y) coordinates, so we'll need to include an option for the user to provide a lat/lon reference point (and some measure of the distance scale for the (x,y) coordinates.

This was inspired by #38 .

Here are some places to start:

• cvrplib. Capacitated Vehicle Routing Problem Library, 2017. URL http://vrp.atd-lab.inf.puc-rio.br/index.php/en/
• tsplib. 2013. URL http://comopt.ifi.uni-heidelberg.de/software/TSPLIB95
• VRP-REP. 2017. URL http://www.vrp-rep.org/datasets.html.
• vrplib. VRPLIB Vehicle Routing Problem Library, 2020. URL http://or.dei.unibo.it/library/vrplib-vehicle-routing-problem-library.

This improvement was suggested by one of the extremely helpful reviewers of the paper titled "VeRoViz: A Vehicle Routing Visualization Toolkit" (https://dx.doi.org/10.2139/ssrn.3746037). See also #36, #37, #38, #39, and #40.

There are several places where performance can be improved. [We might want to split these into separate issues]

• API curl requests (e.g. in _queryOSRM.py) are inefficient.
  • Having a curl request for each pair of origin-destination coordinates is slow. Is this necessary? Different APIs already have this distance/duration-matrix functionality already available (e.g. for ORSM see http://project-osrm.org/docs/v5.22.0/api/#route-service). This would also resolve issue #16.
  • [Why did we have the single curl requests? Was there are reason for this?]
• getTimeDist2D (and hence getTimeDistFromLocs2D) is slow.
  • Need to implement numpy-based computations.
  • In getTimeDist2D, the coordinates are traversed twice in the inner functions; once for the loading of the distance / time from the chosen data-source (e.g. osrmGetTimeDist) and then again in getTimeDistFromLocs2D. Clearly, this can be simplified by querying the API and filling the matrix in a single for-loop.
• generateNodes is slow.
• Take a look at similar issues with all data providers (not just OSRM).

The original reviewer comment appears below:

... I have some comments relating to performance, mostly relating to the OSRM queries.
I understand this is not a focus of this library, however, if it is to be used for instance generation, I would suggest a revision of some functions.
Particularly, I'd like to see performance enhancements relating to the following:

• API curl requests (e.g. in _queryOSRM.py)
• getTimeDist2D (and hence getTimeDistFromLocs2D) where most of the time is spent.
• generateNodes

I'm not sure if this is just my machine, but it doesn't scale particularly well.
For 5 customers (as in the paper demo notebook) function 2. (getTimeDist2D) takes up to 16 seconds while with 100 customers I killed it after 30 minutes. This can be easily improved.

I think this is due to the following:

• Having a curl request for each pair of origin-destination coordinates. I'm not sure this is necessary as different APIs already have this distance/duration-matrix functionality already available (e.g. for ORSM see http://project-osrm.org/docs/v5.22.0/api/#route-service). This would also resolve issue #16.
• Matrix operations in pure Python: I've briefly looked at the functions and most of the matrix operations can be sped up. As numpy is an already declared dependency, I would suggest migrate some matrix operations (where possible) to use the numpy equivalent. For example, in the getTimeDist2D case, the coordinates are traversed twice in the inner functions; once for the loading of the distance / time from the chosen data-source (e.g. osrmGetTimeDist) and then again in getTimeDistFromLocs2D. Clearly, this can be simplified by querying the API and filling the matrix in a single for-loop.

It seems that the main issue is with the curl requests, as there's no problem with getTimeDist3D even for 100 nodes (faster than getTimeDist2D even for 5 nodes).

I have seen similar cases with some of the other data sources, so would suggest a revision of these.

This improvement was suggested by one of the extremely helpful reviewers of the paper titled "VeRoViz: A Vehicle Routing Visualization Toolkit" (https://dx.doi.org/10.2139/ssrn.3746037). See also #36, #37, #38, #39, and #40.

• Add information from https://veroviz.org/about.html
• Add a section describing how people can contribute.

The original reviewer comment appears below:

To aid with the contributing I suggest ... [a] more elaborate README file: most of the information is all already included in the webpages, however I think it helps to repeat it in the repository as well. Particularly,

• Contact details
• Contributing guidelines (how you'd want people to contribute to the project)

This improvement was suggested by one of the extremely helpful reviewers of the paper titled "VeRoViz: A Vehicle Routing Visualization Toolkit" (https://dx.doi.org/10.2139/ssrn.3746037). See also #36, #37, #38, #39, and #40.

• Add unit tests. The following links may help:

  • https://realpython.com/python-testing/
  • https://docs.python.org/3/library/unittest.html
  • https://docs.python-guide.org/writing/tests/
  • https://code.visualstudio.com/docs/python/testing

• Incorporate continuous integration suite to run unit tests. Check out the following:

  • https://lab.github.com/githubtraining/github-actions:-continuous-integration

The original reviewer comment appears below:

To match the quality of the work, I would suggest a series of unit tests to test the validity of the basic functionality. Along with this, I would like to see a continuous integration suite (GitHub workflows, travisci, ...) to run these unit tests (every time there is a commit to a certain branch, pull request, etc). This is very easy to set up and really helps.

This improvement was suggested by one of the extremely helpful reviewers of the paper titled "VeRoViz: A Vehicle Routing Visualization Toolkit" (https://dx.doi.org/10.2139/ssrn.3746037). See also #36, #37, #38, #39, and #40.

• There are several good VRP solvers that are available, including:

  • OR-Tools https://developers.google.com/optimization/routing/vrp)
  • VeRyPy (https://github.com/yorak/VeRyPy)
  • VRPy (https://github.com/Kuifje02/vrpy)
    It would be nice to provide a VeRoViz function that makes it easy for users to leverage those solvers.

• Make this an optional installation

  • Include the function(s) by default, but provide instructions to install the VRP solver software (which would be required by the VeRoViz function(s).

The original reviewer comment appears below:

... I would suggest to interface with an existing VRP solver.
With the existing work, I think adding a simple interface to an existing solver would complete the package quite nicely and will bring higher usage from the community already using the solver that need tools like VeRoViz.
Under certain assumptions, it should be straightforward.
There are many open-source solvers or heuristics for Python, for example, the well-known OR-Tools (https://developers.google.com/optimization/routing/vrp), VeRyPy (https://github.com/yorak/VeRyPy), or VRPy (https://github.com/Kuifje02/vrpy).

If the extra dependency is not wanted, this can be clearly stated as an optional feature in the
installation instructions (similarly as is done with Cesium).}

Please use the template below to submit your bug report.

Describe the bug
In my case study, there is a depot that has 4 vehicles on 4 different routes. The total no. of customers needs to be visited are around 22 and a depot. When I am assigning fewer customers to 1st 3 vehicles (around 1 or two), the 4th vehicle who has to cover all the remaining customers is giving me an error like Error Code 429: Too Many Requests (sometimes. not always). Secondly when I am combining the codes of all the 4 vehicles is a single "Spyder-Python" file, it fails to execute anything. Furthermore, I am unable to change the pin color of my depot through a loop, to distinguish it from the customers.

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
   4. See error

Expected behavior
I want to show all the routes of my vehicles on a single map with the different pin of my depot through "Spyder Environment". I am planning to run the code with Python's GUI platform.

Screenshots

Python Version (please complete the following information):

• Python 3

VeRoViz Version:

# Paste the result of the following Python command:
import veroviz as vrv
vrv.checkVersion()

'Your current installed version of veroviz is 0.3.1. You are up-to-date with the latest available version.'

Operating System (please complete the following information):

• Windows
• Browser [Opera]
• Version [
  VeRoViz Code.docx

VeRoViz Code.zip

Windows 10]

Additional context
Add any other context about the problem here.