You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ability to tweak walk score results. This would be useful for projects in pedestrian oriented cities, where there is a much higher expectation of walkability than the suburbs that walk score is typically calibrated for. This would also be extremely useful for using Urbano to model interior spaces like offices. That said, the raw data pertaining to the trips (their duration, the number of hits per street, etc.) is even more valuable, as we can build custom metrics related to interactions and overall network efficiency. I’ve added notes below re: how this data could be exposed for us.
Ability to force trips to all buildings of certain amenity/use type. For instance, if trying to calculate trips from residences to office buildings, there is no guarantee that people will work at the closest office, so trips should be proportionately distributed to all destinations.
Ability to specify certain trips from one origin type to one destination type, and whether one-way or two. Commuter trips to and from office happen in both directions daily, other trips happen less frequently and may be linked like errands, restaurants, parks, shopping, etc. Additionally, trips are currently generated from all buildings, but the types of trips taken from an office (i.e. to a restaurant or gym for lunch) are less varied than trips taken from a residence (i.e. to a park, to the movies, a library/museum, etc.), and trips don’t need to originate at amenities unless part of a multi-stop trip taken from a residence or office.
Ability to define population as an explicit input. It’s wonderful that Urbano knows larger buildings will generate more trips, but the number of street hits would be more interpretable if it could be related back to a specific population value, and high density master plans may make different assumptions about the number of people per square foot of residential area. There’s also quite a bit of interest in modeling trips taken within an office, so finding a way to specify origins and destinations as points instead of buildings could be great (maybe a point origin could be a separate component).
Ability to prioritize certain streets over others. Often times a master plan has a main boulevard that (it is hoped) pedestrians will prefer. I thought this might be achieved by labeling certain street segments as high speed, multi-lane highways, but these settings don’t seem to affect which routes are taken, the number of hits a given street segment receives, or the total travel time of all trips taken in the model. I guess this makes sense, since those features are related to cars and Urbano is calculating pedestrian activity, but it would be great to have similar settings for weighting pedestrian activity. This would also let designers add some amount of pedestrian logic to orthogonal street grids where all routes are equal length (and a LOT of master plans have orthogonal street grids…).
Understanding travel over time. The total number of hits per segment is aggregated over the entire day, whereas trips take place at different times (commuting vs. lunch vs. nightlife). Breaking these out would be a great feature (although personas could reasonably be constructed to represent times of day).
Additionally, it would be interesting to measure how social a given model is, meaning how many different routes overlap and create potential interactions between pedestrians. This would be a different calculation than measuring hits per street segment, returning a single increment of value for an intersection of routes, regardless of the length of the trip that is shared. Currently each trip corresponds to a value for how many people take that route, and this “interaction” metric would need to take the number of people into account.
Trip choice sensitivity to terrain. This is a relatively small issue of KPF master plans, but it’s worth considering the effect of hills on pedestrian route choice.
The text was updated successfully, but these errors were encountered:
Ability to tweak walk score results. This would be useful for projects in pedestrian oriented cities, where there is a much higher expectation of walkability than the suburbs that walk score is typically calibrated for. This would also be extremely useful for using Urbano to model interior spaces like offices. That said, the raw data pertaining to the trips (their duration, the number of hits per street, etc.) is even more valuable, as we can build custom metrics related to interactions and overall network efficiency. I’ve added notes below re: how this data could be exposed for us.
Ability to force trips to all buildings of certain amenity/use type. For instance, if trying to calculate trips from residences to office buildings, there is no guarantee that people will work at the closest office, so trips should be proportionately distributed to all destinations.
Ability to specify certain trips from one origin type to one destination type, and whether one-way or two. Commuter trips to and from office happen in both directions daily, other trips happen less frequently and may be linked like errands, restaurants, parks, shopping, etc. Additionally, trips are currently generated from all buildings, but the types of trips taken from an office (i.e. to a restaurant or gym for lunch) are less varied than trips taken from a residence (i.e. to a park, to the movies, a library/museum, etc.), and trips don’t need to originate at amenities unless part of a multi-stop trip taken from a residence or office.
Ability to define population as an explicit input. It’s wonderful that Urbano knows larger buildings will generate more trips, but the number of street hits would be more interpretable if it could be related back to a specific population value, and high density master plans may make different assumptions about the number of people per square foot of residential area. There’s also quite a bit of interest in modeling trips taken within an office, so finding a way to specify origins and destinations as points instead of buildings could be great (maybe a point origin could be a separate component).
Ability to prioritize certain streets over others. Often times a master plan has a main boulevard that (it is hoped) pedestrians will prefer. I thought this might be achieved by labeling certain street segments as high speed, multi-lane highways, but these settings don’t seem to affect which routes are taken, the number of hits a given street segment receives, or the total travel time of all trips taken in the model. I guess this makes sense, since those features are related to cars and Urbano is calculating pedestrian activity, but it would be great to have similar settings for weighting pedestrian activity. This would also let designers add some amount of pedestrian logic to orthogonal street grids where all routes are equal length (and a LOT of master plans have orthogonal street grids…).
Understanding travel over time. The total number of hits per segment is aggregated over the entire day, whereas trips take place at different times (commuting vs. lunch vs. nightlife). Breaking these out would be a great feature (although personas could reasonably be constructed to represent times of day).
Additionally, it would be interesting to measure how social a given model is, meaning how many different routes overlap and create potential interactions between pedestrians. This would be a different calculation than measuring hits per street segment, returning a single increment of value for an intersection of routes, regardless of the length of the trip that is shared. Currently each trip corresponds to a value for how many people take that route, and this “interaction” metric would need to take the number of people into account.
Trip choice sensitivity to terrain. This is a relatively small issue of KPF master plans, but it’s worth considering the effect of hills on pedestrian route choice.
The text was updated successfully, but these errors were encountered: