-
Notifications
You must be signed in to change notification settings - Fork 13
The Track
Yeah, it's "The Track". Get it??
Add map layers to show info about an area. There will be radio buttons to show/hide these additional layers.
- create a custom Mapbox layer to show population density/how built up an area is
- will probably use analyzed satellite imagery
- follow a pattern like this blog post
- topographic layer ✅
- satellite layer ✅
- POI layer ✅
- railways layer ✅
Re-imagine the "Density Score" and add a system-wide score, as well as a social score.
Dependent on:
- the to-be-built density layer which will be used to measure how built-up the area around the station is
- a calculation of the POIs nearby
- must be able to prioritize the POIs by significance (i.e. a large university > a small primary school)
- connections to lines (including walking connections)
Dependent on:
- distance between stations
- both average distance and standard deviation
- different distances will be preferred based on the line mode
- connections to other lines
- uniqueness of the line?
- score of stations on the line
- waypoints?
- elevation change per distance between stations/waypoints as negative
Dependent on:
- scores of stations
- scores of lines
- number of lines, stations, and waypoints
- should use diminishing returns (logarithmic) so more is not necessarily much better
- percentage of system that is interlined
- population coverage
- use to-be-built density layer
- within half mile of metro stations, quarter mile from bus stations, etc
- factor in percent population coverage within bounding box
- account for systems that have just one vertical or horizontal line by having minimum width/height
Sum of:
- number of stars (x 5)
- number of comments (fibonacci)
- number of other users who directly branched (x 5)
- number of other users who indirectly branched (x 3)
- number of direct descendants (x 2)
- number of indirect descendants (x 1)
Trending:
- same as above, but only counting actions in the past 24 hours
After the scoring system is implemented, the door is open to make Challenges. On a weekly/monthly/etc cadence, a new challenge will be advertised on the /explore page. A challenge will be to build a map for a particular place that obtains a high score. All maps submitted to the challenge will be private until the end of the challenge when they will be made public, and no further updates will be allowed. The owner of the highest scored map submitted will get a badge on their profile. Maps submitted to challenges will have an indication on the map preview - perhaps a checkered flag? While editing, the map could be prevented from zooming out too far or panning to other areas to ensure the maps are of the intended place.
Update server side API calls to account for the logged-in user's credentials. This would facilitate implementing features like blocking and /edit <-> /view redirects.
We curerntly only account for user permissions once a page is loaded. So things like saving map changes, starring, commenting, etc. are, of course, authenticated. However the initial load of a map is performed on the server and uses priveledged credentials. This is generally fine, but having the user-authenticated API calls would provide flexibility for future initiatives.
Try to follow a guide like this one to implement this.
Update: Potentially could use this next-firebase-auth package to do this!
As the site grows and inter-user interactions increase, there is more of a need to for a Block feature.
Provided the authenticated server side API calls is completed, this should be possible by adding a new subcollection users/[userId]/blockedUsers
where each document has an id that matches the blocked user's userId. We can then reference the existence of a signed in user's userId in order to block access via a security rule.
Add middleware to check if a request should be automatically 307 redirected between /view and /edit depending on a if a user is logged in and if that user owns said map.
Use GTFS data to vastly expand the default map options.
- query Transitland APIs
- transform the data into an MD-friendly format
- handle the different timetables and variations of lines
- update new map ui
- elevation change
- turning radius
- other mode-specific validations
- continuous water connection for ferries
- sufficiently large flat area for airports
- limited length of water crossings for land-based modes
- land use
- for cost of structures like airports requiring land cleared
- for regions/neighborhoods which impact the economic engine
- revenue/operating cost
- score increase for each line that satisfies validations
- score increase for balancing operation costs and revenue
- auto curve tool
- station entrances
- GTFS?
- three map promotions
- import/export
- station entrances
- line platforms
- re-certify MD on facebook
- ensure system subcollections are deleted after a system is archived
- issue with some lines that cross over antimeridian line (longitudes being set to >180 or <-180)
- minor visual issue when adding a line to a hidden group and then closing the focus
- not all interline segments appear in some circumstances
- do not fit map to station when switching map style
- lines in hidden groups should not be shown in shortcut
- calculate travel time between two stations
- would literally require Dijkstra's algorithm lol
- change line frequency
- perhaps a simple low, medium, and high per mode would suffice
- add client exception tracker
- paginate systems on user profiles
- import stations from CSV
- add CDN for preview images
- autosave
- search within system (stations/lines)
- draw box to select multiple stations/waypoints
- add trench grade option
- curvature tool
- on station/waypoint view there would be a button for "add curvature"
- this would open a modal similar to the interchange modal
- it would show a list of all adjacent stations/waypoints to the current station, excluding when one of the pair is at the end of the line
- for waypoints, it could show "Southwestern waypoint" for example
- when selected, it would calculate intermediary waypoints using a Bezier curve
- the anchor points would be calculated by finding the distance between the target stations, and then finding the point one third of that distance along the bearing coming into the start station and negative one third of that distance out of the end station
- it would add 5-20 waypoints depending on the radius of the curve
- it would then add these waypoints to all lines that have these adjacent stations