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
I'd like to improve the VE-State policy inputs, which differ from VE-RSPM because they are bzone level. In VE-State, since bzones are sythesized, a different input geography must be used. Currently the VE-State inputs use area type (center, inner, outer, fringe) for the following input files. The problem is that area type is not known until the bzones are synthesized, so it is hard to control how these inputs are applied.
Car Service coverage (marea_carsvc_availability.csv)
Group Quarters (azone_gq_pop-prop_by_area-type.csv)
One solution is to add a "control total" for these policies at the more aggregate MArea level. This could replace or add to the the existing area type inputs. If the area type inputs are retained, they may need to change to be a relative factor for applying the policies in different areas that are scaled up/down to match the new marea control total.
The text was updated successfully, but these errors were encountered:
I'd like to improve the VE-State policy inputs, which differ from VE-RSPM because they are bzone level. In VE-State, since bzones are sythesized, a different input geography must be used. Currently the VE-State inputs use area type (center, inner, outer, fringe) for the following input files. The problem is that area type is not known until the bzones are synthesized, so it is hard to control how these inputs are applied.
One solution is to add a "control total" for these policies at the more aggregate MArea level. This could replace or add to the the existing area type inputs. If the area type inputs are retained, they may need to change to be a relative factor for applying the policies in different areas that are scaled up/down to match the new marea control total.
The text was updated successfully, but these errors were encountered: