doc: Reformat doc using IntelliJ

.github/pull_request_template.md

@@ -1,41 +1,71 @@
 ## PR Instructions
-When creating a pull request, please follow the format below. For each section, *replace* the guidance text with your own text, keeping the section heading. If you have nothing to say in a particular section, you can completely delete the section including its heading to indicate that you have taken the requested steps. None of these instructions or the guidance text (non-heading text) should be present in the submitted PR. These sections serve as a checklist: when you have replaced or deleted all of them, the PR is considered complete. As of 2021, most regular OTP contributors participate in our twice-weekly conference calls. For all but the simplest and smallest PRs, participation in these discussions is necessary to facilitate the review and merge process. Other developers can ask questions and provide immediate feedback on technical design and code style, and resolve any concerns about long term maintenance and comprehension of new code.
+
+When creating a pull request, please follow the format below. For each section, *replace* the
+guidance text with your own text, keeping the section heading. If you have nothing to say in a
+particular section, you can completely delete the section including its heading to indicate that you
+have taken the requested steps. None of these instructions or the guidance text (non-heading text)
+should be present in the submitted PR. These sections serve as a checklist: when you have replaced
+or deleted all of them, the PR is considered complete. As of 2021, most regular OTP contributors
+participate in our twice-weekly conference calls. For all but the simplest and smallest PRs,
+participation in these discussions is necessary to facilitate the review and merge process. Other
+developers can ask questions and provide immediate feedback on technical design and code style, and
+resolve any concerns about long term maintenance and comprehension of new code.
 
 ### Summary
+
 Explain in one or two sentences what this PR achieves.
 
 ### Issue
-Link to or create an [issue](https://github.com/opentripplanner/OpenTripPlanner/issues) that describes the relevant feature or bug.
-You need not create an issue for small bugfixes and code cleanups, but in that case do describe the problem clearly and completely in the "summary" section above.
-In the linked issue (or summary section for smaller PRs) please describe:
+
+Link to or create an [issue](https://github.com/opentripplanner/OpenTripPlanner/issues) that
+describes the relevant feature or bug. You need not create an issue for small bugfixes and code
+cleanups, but in that case do describe the problem clearly and completely in the "summary" section
+above. In the linked issue (or summary section for smaller PRs) please describe:
+
 - Motivation (problem or need encountered)
 - How the code works
 - Technical approach and any design considerations or decisions
 
-Remember that the PR will be reviewed by another developer who may not be familiar with your use cases or the code you're modifying. It generally takes much less effort for the author of a PR to explain the background and technical details than for a reviewer to infer or deduce them. PRs may be closed if they or their linked issues do not contain sufficient information for a reviewer to proceed.
+Remember that the PR will be reviewed by another developer who may not be familiar with your use
+cases or the code you're modifying. It generally takes much less effort for the author of a PR to
+explain the background and technical details than for a reviewer to infer or deduce them. PRs may be
+closed if they or their linked issues do not contain sufficient information for a reviewer to
+proceed.
 
-Add [GitHub keywords](https://help.github.com/articles/closing-issues-using-keywords/) to this PR's description, for example:
+Add [GitHub keywords](https://help.github.com/articles/closing-issues-using-keywords/) to this PR's
+description, for example:
 
 `closes #45`
 
 ### Unit tests
+
 Write a few words on how the new code is tested.
+
 - Were unit tests added/updated?
 - Was any manual verification done?
 - Any observations on changes to performance?
 - Was the code designed so it is unit testable?
 - Were any tests applied to the smallest appropriate unit?
-- Do all tests pass [the continuous integration service](https://github.com/opentripplanner/OpenTripPlanner/blob/dev-2.x/docs/Developers-Guide.md#continuous-integration)?
+- Do all tests
+  pass [the continuous integration service](https://github.com/opentripplanner/OpenTripPlanner/blob/dev-2.x/docs/Developers-Guide.md#continuous-integration)
+  ?
 
 ### Code style
-Have you followed the [suggested code style](https://github.com/opentripplanner/OpenTripPlanner/blob/dev-2.x/docs/Codestyle.md)?
+
+Have you followed
+the [suggested code style](https://github.com/opentripplanner/OpenTripPlanner/blob/dev-2.x/docs/Codestyle.md)
+?
 
 ### Documentation
+
 - Have you added documentation in code covering design and rationale behind the code?
 - Were all non-trivial public classes and methods documented with Javadoc?
-- Were any new configuration options added? If so were the tables in the [configuration documentation](https://github.com/opentripplanner/OpenTripPlanner/blob/dev-2.x/docs/Configuration.md) updated?
+- Were any new configuration options added? If so were the tables in
+  the [configuration documentation](https://github.com/opentripplanner/OpenTripPlanner/blob/dev-2.x/docs/Configuration.md)
+  updated?
 
 ### Changelog
+
 The [changelog file](https://github.com/opentripplanner/OpenTripPlanner/blob/dev-2.x/docs/Changelog.md)
 is generated from the pull-request title, make sure the title describe the feature or issue fixed.
 To exclude the PR from the changelog add `[changelog skip]` in the title.

ARCHITECTURE.md

@@ -1,37 +1,36 @@
 # OTP Architecture
-OTP is developed over more than 10 years, and most of the design documentation is in the code 
-as comments and JavaDoc. Over the years the complexity have increased, and the natural developer 
-turnover creates a demand for more architecture and design documentation. The new OTP2 
-documentation is put together with the source; hopefully making it easier to maintain. Instead of
-documenting modules in old style _package-info.java_ files we use _package.md_ files. This document
-should serve as an index to all existing top-level documented components.
-
-This document is far from complete - hopefully it can evolve over time and become a good 
-introduction to OTP architecture. The OTP project GitHub issues are a good place to look for detailed 
-discussions on many design decisions.   
-
-Be sure to also read the [developer documentation](docs/Developers-Guide.md). 
-
+
+OTP is developed over more than 10 years, and most of the design documentation is in the code as
+comments and JavaDoc. Over the years the complexity have increased, and the natural developer
+turnover creates a demand for more architecture and design documentation. The new OTP2 documentation
+is put together with the source; hopefully making it easier to maintain. Instead of documenting
+modules in old style _package-info.java_ files we use _package.md_ files. This document should serve
+as an index to all existing top-level documented components.
+
+This document is far from complete - hopefully it can evolve over time and become a good
+introduction to OTP architecture. The OTP project GitHub issues are a good place to look for
+detailed discussions on many design decisions.
+
+Be sure to also read the [developer documentation](docs/Developers-Guide.md).
+
 ## Modules/Components
+
 Below is a list of documented components in OTP. Not every component is documented at a high level,
 but this is a start and we would like to expand this list in the future.
 
 ### [OTP Configuration design](src/main/java/org/opentripplanner/standalone/config/package.md)
 
-The Configuration module is responsible for loading and parsing OTP configuration files and map 
-them into Plan Old Java Objects (POJOs). These POJOs are injected into the other components.
-
+The Configuration module is responsible for loading and parsing OTP configuration files and map them
+into Plan Old Java Objects (POJOs). These POJOs are injected into the other components.
 
 ### [REST API](src/main/java/org/opentripplanner/api/package.md)
 
 Short introduction to the REST API.
 
-
 ### [GTFS import module](src/main/java/org/opentripplanner/gtfs/package.md)
 
 Used to import GTFS transit data files.
 
-
 ### [NeTEx import module](src/main/java/org/opentripplanner/netex/package.md)
 
 Used to import NeTEx transit data files.
@@ -41,35 +40,41 @@ Used to import NeTEx transit data files.
 #### [Raptor transit routing](src/main/java/org/opentripplanner/transit/raptor/package.md)
 
 This is the OTP2 new transit routing engine implemented using the Raptor algorithm. It explains how
-Raptor works, the important concepts and the design. It might be worth reading even if you are not
-a developer - just to understand how the transit routing works. 
+Raptor works, the important concepts and the design. It might be worth reading even if you are not a
+developer - just to understand how the transit routing works.
 
-The Raptor functionality is quite complex, so we want to isolate it from the remaining code. Therefore, the 
-raptor component is designed to have as few dependencies as possible. In fact there are _no_ 
+The Raptor functionality is quite complex, so we want to isolate it from the remaining code.
+Therefore, the raptor component is designed to have as few dependencies as possible. In fact there
+are _no_
 dependencies from Raptor to other parts of OTP code, only to utility classes not found in the JDK.
-Also, the code follows a stricter object-oriented design, than most other parts of OTP. The Raptor 
+Also, the code follows a stricter object-oriented design, than most other parts of OTP. The Raptor
 implementation is highly critical code, hence we set the bar higher with respect to code quality.
- 
-OTP provides transit data to Raptor by implementing the _raptor/api/transit_ model. The 
+
+OTP provides transit data to Raptor by implementing the _raptor/api/transit_ model. The
 [RoutingService](src/main/java/org/opentripplanner/routing/RoutingService.java)
-is responsible for mapping from the OTP context to a 
+is responsible for mapping from the OTP context to a
 [RaptorRequest](src/main/java/org/opentripplanner/transit/raptor/api/request/RaptorRequest.java)
-and then map the result, [Raptor Path](src/main/java/org/opentripplanner/transit/raptor/api/path/Path.java),
-back to the OTP internal domain. This might seem like a lot of unnecessary mapping, but 
-mapping is simple - routing is not. 
+and then map the
+result, [Raptor Path](src/main/java/org/opentripplanner/transit/raptor/api/path/Path.java), back to
+the OTP internal domain. This might seem like a lot of unnecessary mapping, but mapping is simple -
+routing is not.
 
 The performance of Raptor is important, and we care about every millisecond. All changes to the
-existing Raptor coded should be tested with the 
-[SpeedTest](src/test/java/org/opentripplanner/transit/raptor/speed_test/package.md) and 
-compared with an earlier version of the code to make sure the performance is NOT degraded. 
+existing Raptor coded should be tested with the
+[SpeedTest](src/test/java/org/opentripplanner/transit/raptor/speed_test/package.md) and compared
+with an earlier version of the code to make sure the performance is NOT degraded.
 
 #### [Transfer path optimization](src/main/java/org/opentripplanner/routing/algorithm/transferoptimization/package.md)
-Describes the transfer functionality, the design and the implementation. The logic for finding the best
-transfer is distributed to the Raptor and the [OptimizeTransferService](src/main/java/org/opentripplanner/routing/algorithm/transferoptimization/OptimizeTransferService.java).
+
+Describes the transfer functionality, the design and the implementation. The logic for finding the
+best transfer is distributed to the Raptor and
+the [OptimizeTransferService](src/main/java/org/opentripplanner/routing/algorithm/transferoptimization/OptimizeTransferService.java)
+.
 
 #### [Itinerary list filter chain](src/main/java/org/opentripplanner/routing/algorithm/filterchain/package.md)
-Describes the itinerary list filter chain, used to post-process the itineraries returned from the 
-routers in [RoutingWorker](src/main/java/org/opentripplanner/routing/algorithm/RoutingWorker.java), 
-in order to sort and reduce the number of returned itineraries. It can also be used to decorate the 
+
+Describes the itinerary list filter chain, used to post-process the itineraries returned from the
+routers in [RoutingWorker](src/main/java/org/opentripplanner/routing/algorithm/RoutingWorker.java),
+in order to sort and reduce the number of returned itineraries. It can also be used to decorate the
 returned itineraries, especially if it requires more complex calculations, which would be unfeasible
 to do during the routing process.