County vs Sub-county (ZIP code) model results

Comments

7 comments

  • Avatar
    jenny
    This does not happen frequently, but it is possible under a number of conditions. The more common ones are: 1. The manufacturing RPCs computed for the county model might be smaller than at the zip-code level. This is quite possible for sectors that are more concentrated at a zip-code level than for the county as a whole. RPCs of the direct effects are not the problem. It is the RPCs of the strongly-linked backward linkages (first round indirect) that cause this problem. Different RPCs are especially likely in your case if you are using the tradeflow RPC method in the county model and the econometric RPC method in the zip-code model. 2. The zip-code area construction sector may have higher Intermediate Expenditures per Output or higher Employee Compensation per Output, etc. When you use the county model, you are essentially impacting a different sector, since it is in effect an "average" of all the zip-codes in that county. In this case, you will want to edit the Study Area Data in the county model so that the main sectors involved look act like the zip-code level sectors (i.e., same Intermediate Expenditures per Output, Labor Income per Output, etc.). These edits can be made by going to Customize > Study Area Data. Note: to change Intermediate Expenditures you will need to first uncheck the "Lock" box. After you make any edits, you will need to click "Save" and then reconstruct the multipliers (Options > Construct > Multipliers).
    0
    Comment actions Permalink
  • Avatar
    tbanda
    I checked the Intermediate Expenditures per Output and Labor Income per Output for construction sectors and they're the same in the two models. So I compared the Industry Spending Patterns for Sector 37 from the two models. I found that the industry spending pattern from the ZIP-code model (City) had much larger LPCs for some industries than the County model. It seems this explains why the ZIP-code model generates higher indirect impacts because it assumes higher capture rates of intermediate expenditures. What's your advice in this case?
    0
    Comment actions Permalink
  • Avatar
    DougO
    I presume you used the default "trade flows" to create the county and the necessary econometrics to create the zip codes. They are different technologies, so they will generate contradictory results. If you need to compare zip code impacts to the county impacts, then create the county with the comparable econometric RPCs (File>User Preferences>Trade Flows). The econometrics are not guaranteed to be consistent either between the county and zips, so if it is still a problem, edit the RSCs (Customize>Trade Flows) in the zips to equal the county RSC for the cases where they exceed the county RSCs. If you are not actually making a comparison, just accept the zip econometric RPCs.
    0
    Comment actions Permalink
  • Avatar
    tbanda
    Yes I used the default "trade flows" for the County model. I will try re-building the model using econometric RPCs as you suggest. Our study will be comparing the results, and so it's important for the results to be consistent with the size of the economies being modeled. Thanks.
    0
    Comment actions Permalink
  • Avatar
    dberneman
    Hey Doug, I seem to be having a sub-county vs county problem myself. I am trying to create a model for the City of Detroit and seem to be getting some out of whack population and household figures. When I model the 27 ZIP codes that make up the City of Detroit, I get a population of approximately 903,000. The Census figures put Detroit at 714,000. I have a similar issue with the household counts as well. I tried eliminating two ZIP codes that, although mostly within the City have portions that are unincorporated, and the numbers came down but still not within a proper margin from the Census figures. I know there won't be an exact match, but we seem too far off. What do you think we can do to remedy the situation? Thanks.
    0
    Comment actions Permalink
  • Avatar
    DougO
    Zip codes do not follow city boundaries and as such are approximations. I know that my zip code 55082 is labelled "Stillwater, MN" but also includes Oak Park Heights and several surrounding townships. If you are trying to model impacts, I would leave it as is. The population itself does not enter into the modeling; however, the number of households by income class that will be associated with it do. The balancing (household spending, taxes paid, transfer payments) required to edit the study area data to bring down the population would be painful if not impossible to accomplish. If we were able to shrink the entire model (all industry production, institutional sales, transfer, demands) by a constant fraction (714,000/903,000), the resulting coefficients, ergo, the multipliers would be exactly the same. However, I realize that it would be more satisfying to get a more precise model, but we do not have industry data at the census block/city address level. All that we could do is reduce by a constant fraction as noted above which is based on population and may not reflect industry.
    0
    Comment actions Permalink
  • Avatar
    dberneman
    Thanks for the reply Doug. The interesting thing is that the City follows the ZIP codes quite well. There are really only two ZIP codes that have some questions as to their inclusion within the City. So I can't imagine there being that big of a difference because of improper ZIP code alignment. That being said, it could be that the IMPLAN data sources have not caught up with the 2010 Census figures which is why I am seeing such a difference, especially in a place like Detroit, where the latest Census may show some big differences as compared to the ACS and other sources. I think we will just be forced to leave it as is and footnote our results.
    0
    Comment actions Permalink

Please sign in to leave a comment.