1) Calculate the distance matrix using pyvalhalla and AWS lambda function as the job geocoding is triggered, store this in S3 and retrieve with the normal file info. This will speed-up the process significantly. But will create issues when there are changes in inputs.
2) Calculate the distance matrix using a local pyvalhalla and network file when uploading new data, this will slow-down the initial app loading but the results can be stored locally in a session. It's more robust.
The best workflow is to store a the latest pyvalhalla network file in the s3 folder bucket, and then update it weekly. The app will then retrieve and store it locally if not available. But, it will require an "overwrite" flag to check for updates.
Another option is to include it directly in the repo. It will result in an automatic update of the app and a quicker launch.
This will remove the need for a continuously running EC2 instance, reducing cloud costs significantly.
Server-less valhalla for distance matrix and path retrieval.
See https://pypi.org/project/pyvalhalla/
Two options:
1) Calculate the distance matrix using pyvalhalla and AWS lambda function as the job geocoding is triggered, store this in S3 and retrieve with the normal file info. This will speed-up the process significantly. But will create issues when there are changes in inputs.
2) Calculate the distance matrix using a local pyvalhalla and network file when uploading new data, this will slow-down the initial app loading but the results can be stored locally in a session. It's more robust.
The best workflow is to store a the latest pyvalhalla network file in the s3 folder bucket, and then update it weekly. The app will then retrieve and store it locally if not available. But, it will require an "overwrite" flag to check for updates.
Another option is to include it directly in the repo. It will result in an automatic update of the app and a quicker launch.
This will remove the need for a continuously running EC2 instance, reducing cloud costs significantly.