Customizing Mobility Assumptions

The Amenities Profile

umi, by default, assumes a set of North America-centric travel priorities when performing mobility calculations, but this behavior can be customized. An umi project's assumptions about mobility requirements are controlled by the project's amenities profile. If umi is installed, the default profile is located at C:/umi/DefaultLibraries/SDL_Standard.uap. This profile is loaded into all new umi projects.

If you are performing mobility analyses in a region where North American assumptions about walking distances and destinations are not appropriate, it is a good idea to modify the amenities profile to better suit local needs. The current project's amenities profile can be exported, and a new one imported, from the Project Settings panel. Amenities profiles are JSON (text) files and can be edited with any standard text editor.

Profile settings

Each profile has four "top-level" settings: Name, MinDistanceInMeters, MaxDistanceInMeters, and Amenities. Name is self-explanatory, and is only used for identification by humans. MinDistanceInMeters and MaxDistanceInMeters control how walking trip distances affect scores. MinDistanceInMeters is the distance at which penalties begin to be applied; the default value of 400 means that walking trips of 400 meters or less receive perfect scores. If this value is set to zero, all trips will receive some degree of distance penalty. MaxDistanceInMeters specifies the maximum distance people are willing to walk at all; trips longer than this will be ignored by the simulator. Note that the score function is smooth, so trips with lengths close to this value will still receive very low scores - they just won't quite be zero.

Amenities is a JSON array of amenity categories to which people will try to walk. Each amenity in this list will have a layer generated in Rhino when the "Create Amenity Layers" button in the Mobility Simulation panel is clicked. Each amenity in the list has four parameters: Name, GlobalWeight, DestinationWeights, and UsesParks.

Name is the name of the Rhino layer on which amenities of this type should be placed. This must match the layer name exactly or else no amenities for the category will be found. A good way to ensure that the layer names match is to exclusively create destination layers using the "Create Amenity Layers" button in the Mobility Simulation panel. This button, when clicked, will create any missing amenity layers, using the names specified in the profile as a reference.

GlobalWeight controls how important an amenity category is relative to other categories. In the default profile, for example, "Grocery stores" has a GlobalWeight of 3, "Restaurants" has a GlobalWeight of 3, "Shopping" has a GlobalWeight of 2, and "Schools" has a GlobalWeight of 1. This means that the grocery store category is equally important as the restaurant category, 1.5 (3/2) times as important as the shopping category, and 3 times as important as the school category. It is important to remember that the values are all relative; if you, for example, doubled every GlobalWeight value in a profile, the resulting scores would remain unchanged (because the ratios between categories did not change). Also, the GlobalWeight parameter has nothing to do with calculating the score *within* each category; that is controlled by the DestinationWeights parameter described below. It is simply used to relatively scale each category score before they are summed for the final score.

DestinationWeights is a JSON array that controls both how many destinations are required for a perfect category score but how the distances to those destinations contribute to the category score. One destination is required for each value in the array, and the values are the relative weights of each destination. For example, the DestinationWeights of the "Coffee" category is [5, 3]. This means that for a perfect score, two coffee destinations are required, and the score for the trip to the nearer of the two is 5/3 as important as the score for the trip to the farther. Several of the categories in the default profile simply have [1] for their DestinationWeights; this means that only a single destination is required. As with global weights, the important information is the value ratios; changing Coffee's DestinationWeights to [10, 6] in the default profile would again leave scores unchanged.

While all the default profile categories have decreasing DestinationWeights, meaning that the distance to closer destinations are more important, this is not a requirement. You could create a profile with increasing weights, which would mean that distances to farther destinations are more important, or any other pattern you choose.

UsesParks is a boolean flag that controls how amenity destinations are located. If it is set to false, amenities will be located at Rhino point objects on their associated category layer. If it is set to true, amenties will be located at the corners and edge midpoints of objects on the umi Parks layer. Note that in this case each park can still only be traveled to once for each departure point.

Previous - Setting up a Rhino model                                           Next - Example model

In Short

Umi is a Rhino-based design environment for architects and urban planners interested in modeling the environmental performance of neighborhoods and cities with respect to operational and embodied energy use, walkability and daylighting potential. Since 2012, Umi has been  developed by the Sustainable Design Lab at the Massachusetts Institute of Technology with support from a National Science Foundation EFRI_SEED project, the MIT Energy Initiative, the Kuwait-MIT Center, the Center for Complex Engineering Systems (CCES) at KACST and MIT, Transsolar Climate Engineering and United Technologies Corporation. Further tool developed is now also being conducted at the Environmental Systems Lab at Cornell University.

A first public version of Umi was released during a public symposium on Sustainable Urban Design on May 6th 2013 at the Massachusetts Institute of Technology. Version 2.0, which also includes an embodied energy module, was released on November 7th 2014.

© 2017   Created by Christoph Reinhart.   Powered by

Badges  |  Report an Issue  |  Terms of Service