Elevation feature #1095
Elevation feature #1095
Conversation
|
Tests are failing: cucumber -p verify features/elevation/elevation.feature:8 # Scenario: Route and retrieve elevation - match on elevations - short
cucumber -p verify features/elevation/elevation.feature:33 # Scenario: Route and retrieve elevation - match on elevations
cucumber -p verify features/elevation/elevation.feature:64 # Scenario: Route and retrieve elevation - match on decoded geometry
cucumber -p verify features/elevation/elevation.feature:95 # Scenario: Route and retrieve elevation - match encoded geometry
cucumber -p verify features/elevation/elevation.feature:132 # Scenario: Route with elevation without ele tags in osm data |
|
Is it possible to have conditional cucumber tests based on compilation Some elevation tests may only be run if the program has been compiled |
|
Not that I know, but lets hold any work here for now. At this point it is not clear if this can or will be merged. See #1090 |
|
Does anybody knows why Windows compilation is failing? |
|
shortcomings is very flattering to MSVC. |
| @@ -39,7 +39,7 @@ def test_routability_row i | |||
|
|
|||
| Then /^routability should be$/ do |table| | |||
| build_ways_from_table table | |||
| reprocess | |||
| reprocess elevation_data_enabled | |||
There was a problem hiding this comment.
i suggest just reading the option in reprocess() instead of passing it everywhere
|
i added a few comments to details of the implementation, but like dennis i suggest to wait a bit until we figure out if the current approach to elevation is atually the way forward (i have some doubts myself). |
- Import elevation from osm node tag 'ele'; - Optional elevation in JSON and GPX formats; - Phantom nodes elevation set early; - Elevation tests with cucumber -p elevation. The elevation is stored as an int. Using a smaller structure would lead to misalignement or no gain. The routing algorithm is unchanged. The elevation feature must be enabled at compile time with: cmake option -DOSRM_HAS_ELEVATION:BOOL=ON and each tool must be passed the '-e 1' parameter to activate it. Finally, the viaroute request may either include the 'elevation=true' parameter to get elevation, set it to false or skip it to get default behaviour. The elevation is read as meters from the osm data. Since we must store it as an int, we get a 1cm precision. It is then exported as 10^4 meters in JSON.
|
Closing this PR as it doesn't look to be merged any time soon. |
|
Thank you @TheMarex for pointing to this discussion. |
Since last pull request, lots of code was removed and tests reworked:
The pull request was split in two parts:
Regarding #1089 (comment),
an open discussion would certainly ease mutual understanding and lead to solutions.
The code looks good now and would probably be of use for others.
I found out these project which try to enhance OSM data using SRTM elevations:
Regards,