docs: avoid_borders build

[merydian]

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 #2133 .

Information about the changes

• Key functionality added: Documentation on avoid_borders for bulding graphs.
• Reason for change:

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

Required changes to ors config (if applicable)

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[aoles]

Awesome job in digesting the information buried in the forum threads into a concise list of recommendations 💪

From a user's perspective I find a few points might be a bit confusing or unclear, please see my comments below 🙈

Also, please don't forget to update the CHANGELOG 😉

Cheers! 🚀

[aoles]

I think it would be really helpful to provide a few more details on how to split the country polygons. @rabidllama did a great job describing the process in the forum, and there is a page on confluence too. How about compiling a short description based on these sources, along with some pictures? 🙏

[aoles]

I don't think this is actually required. For example, this is how an example entry for one of the countries looks like across the files in production.

ids_iso.csv

"country_id","name","name:en","iso_cca2","iso_cca3"
...
"198","ประเทศไทย","Thailand","TH","THA"
...

boundaries.geojson

...
{ "type": "Feature", "properties": { "name": "ประเทศไทย", "hierarchy": 249 }, "geometry": { "type": "MultiPolygon", "coordinates": [ [ [ [ 98.99999, 16.875182 ], [ 99.99999, 16.875182 ], [ 99.99999, 14.875182 ], [ 98.99999, 14.875182 ], [ 98.99999, 15.875182 ], [ 98.99999, 16.875182 ] ] ] ] } },
...

[aoles]

Apparently countries in openborders.csv are identified by their English names, as suggested by the following entries.

ids_iso.csv

...
"117","Lëtzebuerg","Luxembourg","LU","LUX"
...

openborders.csv

...
"Luxembourg","Austria"
"Luxembourg","Belgium"
"Luxembourg","Czech Republic
...