Added Customization Script

[meetkaushal]

Pull Request Checklist

• 1. I have rebased the latest version of the main branch into my feature branch and all conflicts
  have been resolved.
• 2. I have added information about the change/addition to functionality to the CHANGELOG.md file under the
  [Unreleased] heading.
• 3. I have documented my code using JDocs tags.
• 4. I have removed unnecessary commented out code, imports and System.out.println statements.
• 5. I have written JUnit tests for any new methods/classes and ensured that they pass.
• 6. I have created API tests for any new functionality exposed to the API.
• 7. If changes/additions are made to the ors-config.json file, I have added these to the ors config documentation
  along with a short description of what it is for, and documented this in the Pull Request (below).
• 8. I have built graphs with my code of the Heidelberg.osm.gz file and run the api-tests with all test passing
• 9. I have referenced the Issue Number in the Pull Request (if the changes were from an issue).
• 10. For new features or changes involving building of graphs, I have tested on a larger dataset
  (at least Germany), and the graphs build without problems (i.e. no out-of-memory errors).
• 11. For new features or changes involving the graphbuilding process (i.e. changing encoders, updating the
  importer etc.), I have generated longer distance routes for the affected profiles with different options
  (avoid features, max weight etc.) and compared these with the routes of the same parameters and start/end
  points generated from the current live ORS.
  If there are differences then the reasoning for these MUST be documented in the pull request.
• 12. I have written in the Pull Request information about the changes made including their intended usage
  and why the change was needed.
• 13. For changes touching the API documentation, I have tested that the API playground renders correctly.

Fixes # .

Information about the changes

• Key functionality added: Added customization script so users can make minimal changes and successfully run openrouteservice on their systems
• Reason for change: To make customizations easy and simple

Examples and reasons for differences between live ORS routes, and those generated from this pull request

Required changes to ors config (if applicable)

[MichaelsJP]

@meetkaushal Thanks for opening this. The additions are pretty straightforward, but I'm not sure what the ultimate goal here is. Is the plan to have PBFs and config files downloaded from a remote location?
If so, I'm not sure if the variables should be initialized with URLs.

Could you briefly explain what the goal of this PR is?

[meetkaushal]

@MichaelsJP Thanks for getting back to me. I encountered a lot of problems getting openrouteservice to run in my cloud provider render.com. I also tried deploying this as a docker container in Google Cloud Run, but ran into several issues.

PBF files are large. Also sometimes, there is no direct way of accessing a container's file system in a Cloud Provider's runtime environment. So, having the script directly download it to the container while starting seemed to be the best way forward.

The build process/startup script is pretty complicated by default. It is not clear where to customize and what to customize. No matter how I tried, I always ended up running heidelberg graphs. So, it seemed that the best way forward is to let the default scripts do its thing and then just before startup, replace the config and the yml the way I did.

Now with the customization script, folks looking to customize the source file, no matter how large it could be, there is no need to fidget with the container file system once it boots up. Each time the deploy happens, it will make sure to download the file, and if it fails, we are back to heidelberg. :-)

If this PR makes sense to you, please go ahead and merge it and comment it out. Otherwise, I have my repo with these changes and this is how I made it work.

Thank you.

[MichaelsJP]

Understandable and interesting use-case. I can imagine having such a scenario covered in our docker setup.
Would you be interested in contributing this properly?

I guess we need to make a little plan in here, but I guess it would be worth it for you and the other users.

I could imagine it the following way:

1. Introduce a new variable

• "REBUILD_ON_PBF_CHANGES" (or similar) to trigger rebuilds if the PBF changes.
• Start hashing PBF files used after building graphs with it.
• If a PBF file changes and doesn't align with the latest hash, rebuild if "REBUILD_ON_PBF_CHANGES" is set to true.

3. Allow the ors.engine.source_file to be either a URL or a local file.

• If a local file, proceed as usual.
• If a remote file is configured (we need to have some sort of URI/URL check):
  • Check if a file with the name is present locally. If not, download from remote.
  • After download, continue with the usual functionality. -> Check hashes. Check "REBUILD_ON_PBF_CHANGES". Rebuild on demand, etc.

What do you think?

[MichaelsJP]

Closing due to inactivity.
See a first implementation try in this PR: #1841