1. Objective: Mapping scenic routes over standard A to B rather than focusing on the straightest or fastest path
a. Types of user search:
a1: A to B: using better roads and not just the fastest route
a2: A to A:Scenic route in a perimeter - Show me the best roads in a 10 km vicinity
2. Underlying assumption: Maps is a collection of images with information available through different layers - processing at different levels will help us determine what is a "good" road vs what isn't
Using 200m scale to determine twistiness
Using a higher scale to determine if we are actually getting from A to B
That's a ground up logic case scenario. For proof of concept stage, it is wiser to start with google maps or OSM as a base, get a few alternatives for the same route and then assign a custom score to choose one.
Correlation: For a journey chosen, there should be a set of parameters evaluated for feedback on what was suggested vs what actually happened.
1. Time predicted vs actual - broken down into sectors and sub-segments, especially in portions that were already predicted to take a lot of time. (NOTE: THIS NEEDS TO BE INCORPORATED INTO the original API call and data is pulled from google maps or OSM. Call needs to be taken whether it is to be a dynamic sector allocation or static based on distance or time.
3. Factors determining a good road (assigning a score to evaluate A vs B):
a. Road based : how many bends, nature of bend, elevation change,
b. Traffic based: Level of traffic, safety of road, does it have hard lane separation,
4. Logic:
a. Baseline starting point: Google maps/ OSM to determine different routes connecting A to B
b. For the radius outlined, identify all the "good" roads
c. Join them to determine the different options
d. Using traffic overlay to determine traffic
e. How to map hard lane separation and road safety?
f.
