Open originalfoo opened 5 years ago
EDIT: Instead of hub/spoke buildings turning blue, maybe use those 'sun shaft' lines that 'shine' out of the ground? Like on education info view where they're used to highlight active/inactive buildings for the selected info view tab.
With Parking tool active, click a building to select it. The Traffic info view is activated. The clicked building turns blue indicating it's selected. Let's call this building a hub:
Once the user is done, they can right click to exit from the currently selected hub:
It's a bit like on lane connector tool where you right-click out of a junction and then you can select a different junction to work with.
If the hub is a station, the spokes can be car parks: Places where cims will prefer to park before they ride at that station. If cims find those car parks full, they'll return to usual 'search nearest' approach.
If the hub is a RICO, or unique, or monument, or park, or park entrance, spokes can be car parks and/or stations.
Essentially user is defining "preferred stations" and "preferred car parks" for a given destination.
Use cases 1: Observatory
I have an observatory at the top of a hill, there's not much parking. I click the observatory (hub) and connect it to nearby cable car station (spoke). Now cims going to the observatory will try and use the route associated with the cable car. At the bottom of the hill, I connect a cable car station (hub) to a large car park and a rail station.
A cim wanting to get to observatory checks if it's a hub: It is! So they want the cable car, which means they either park in the car park or arrive via the train station.
Use case 2: Train station
Cims are struggling to find parking for a station (hub) so I connect it to some nearby carparks that might otherwise be overlooked by cims. Now cims doing park and ride use the preferred car parks for that station, leaving smaller car parks free for shoppers or residents.
Park and ride cims could, ideally, drive straight to the car park. Currently they drive to station and then start looking for parking; with new system they know where preferred parking is and drive to nearest parking.
When I'm driving IRL, I head to general vicinity of station but I'm looking for parking garages (either via road signs or satnav) and head for those.
Can pedestrian route between spoke and hub be cached?
As pedestrians will be using the route more, could caching that part of the journey help reduce pathfinder load?
For example, taking the use cases above:
Not the only route
We wouldn't want all drivers to use the hub/spoke system.
For example, people living half way up the hill aren't going to drive to the bottom, they'll just drive up the hill or look for nearest cable car station.
So there needs to be some extra logic in there that increases the chance of using the hub/spoke system depending on, say, route length? Also, it has to factor in preference of cims: car vs. PT
Reckless drivers would always head straight to their destination (eg. observatory or train station) and try and park local.
Validity checking
Would need to check viable route between a hub and its spokes.
Eg. For observatory: Can cims walk or cycle between the cable car station and the observatory? For lower cable car, can cims walk from the train station or car park? For train station, can they walk from the car park? etc.
Regarding park & ride: What about an automated approach?
(*) the player could help with this, as you have suggested
Yes, automating good defaults would be desirable. However, as a player, I'd still want to be able to customise it (ie. it becomes a gameplay element).
Parking icons
When hovering an icon, associated lane should be highlighted. See #33.
Car parks
Update to Traffic info view: