JinYao
November 19, 2018, 8:44pm
1
Hi,
Why are isochrone areas of the same range different in different cities? For Beijing, Beijing Shi, China, area is 51.35 km2 for range 5 km. For Olathe, Kansas, USA, area is 92.78 km2. What is the definition of area here? Area of a circle with 5 km radius is 78.5 km2; how do you get 92.78 km2?
Below are two screen captures. I don’t know if they will be displayed.
Thanks.
Jin
nils
November 20, 2018, 3:36pm
2
It was actually a bug, see here:
GIScience:development
← GIScience:isochrones-area-crs
opened 01:26PM - 16 Oct 18 UTC
### Pull Request Checklist
- [x] 1. I have merged the latest version of the d… evelopment branch into my feature branch and all conflicts have been resolved.
- [x] 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.
- [x] 4. I have removed unecessary 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.
- [x] 6. I have created API tests for any new functionality exposed to the API.
- [ ] 7. If changes/additions are made to the app.config file, I have added these to the app.config.sample file along with a short description of what it is for, and documented this in the Pull Request (below).
- [x] 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.
Fixes # .
### Information about the changes
- Key functionality added: area_units
- Reason for change: units is a misleading name for isochrones which is either time or distance based
### Examples and reasons for differences between live ORS routes and those generated from this pull request
-
### Required changes to app.config (if applicable)
-
Basically, previously it used the wrong projection for area computation, WGS84. Now it uses an equal-area projection (I think Mollweide).
It’s not live on all servers yet, but will be very soon.
JinYao
November 20, 2018, 3:59pm
3
Thanks. I think you answered my second question, “how do you get 92.78 km2?”.
What is the definition of area here? An area covering accessible roads and their buffers at a certain distance?
nils
November 20, 2018, 5:56pm
4
The area of the isochrone’s geometry obviously… What you see in the map. It’s more or less the area covering accessible roads from the centre point.