4 datasets found
  1. M

    Profile of Selected Economic Characteristics for Census Tracts: 2000

    • gisdata.mn.gov
    • data.wu.ac.at
    fgdb, html, shp
    Updated Jul 9, 2020
    Share
    FacebookFacebook
    TwitterTwitter
    Email
    Click to copy link
    Link copied
    Close
    Cite
    Metropolitan Council (2020). Profile of Selected Economic Characteristics for Census Tracts: 2000 [Dataset]. https://gisdata.mn.gov/dataset/us-mn-state-metc-society-census-econchar-trct2000
    Explore at:
    html, fgdb, shpAvailable download formats
    Dataset updated
    Jul 9, 2020
    Dataset provided by
    Metropolitan Council
    Description

    Summary File 3 Data Profile 3 (SF3 Table DP-3) for Minneapolis-St. Paul 7 County metropolitan area is a subset of the profile of selected economic characteristics for 2000 prepared by the U. S. Census Bureau.

    This table (DP-3) includes: Employment Status, Commuting to Work, Occupation, Industry, Class of Worker, Income in 1999, Median earnings, Number Below Poverty Level, Poverty Status in 1999, For Whom Poverty Status is Determined

    US Census 2000 Demographic Profiles: 100-percent and Sample Data

    The profile includes four tables (DP-1 thru DP-4) that provide various demographic, social, economic, and housing characteristics for the United States, states, counties, minor civil divisions in selected states, places, metropolitan areas, American Indian and Alaska Native areas, Hawaiian home lands and congressional districts (106th Congress). It includes 100-percent and sample data from Census 2000. The DP-1 table is available as part of the Summary File 1 (SF 1) dataset, and the other three tables are available as part of the Summary File 3 (SF 3) dataset.

    The US Census provides DP-1 thru DP-4 data at the Census tract level through their DataFinder search engine. However, since the Metropolitan Council and MetroGIS participants are interested in all Census tracts within the seven county metropolitan area, it was quicker to take the raw Census SF-1 and SF-3 data at tract levels and recreate the DP1-4 variables using the appropriate formula for each DP variable. This file lists the formulas used to create the DP variables.

  2. a

    2012 to 2018 Election Data with 2011 Wards

    • gis-ltsb.hub.arcgis.com
    • hub.arcgis.com
    Updated Sep 30, 2024
    Share
    FacebookFacebook
    TwitterTwitter
    Email
    Click to copy link
    Link copied
    Close
    Cite
    Wisconsin State Legislature (2024). 2012 to 2018 Election Data with 2011 Wards [Dataset]. https://gis-ltsb.hub.arcgis.com/maps/LTSB::2012-to-2018-election-data-with-2011-wards
    Explore at:
    Dataset updated
    Sep 30, 2024
    Dataset authored and provided by
    Wisconsin State Legislature
    Area covered
    Description

    These wards were produced by the Legislative Technology Services Bureau for the 2011 Legislative Redistricting Project. Election data from the current decade is included.Election Data Attribute Field Definitions | Wisconsin Cities, Towns, & Villages Data AttributesWard Data Overview: These municipal wards were created by grouping Census 2010 population collection blocks into municipal wards. This project started with the release of Census 2010 geography and population totals to all 72 Wisconsin counties on March 21, 2011, and were made available via the Legislative Technology Services Bureau (LTSB) GIS website and the WISE-LR web application. The 180 day statutory timeline for local redistricting ended on September 19, 2011. Wisconsin Legislative and Congressional redistricting plans were enacted in 2011 by Wisconsin Act 43 and Act 44. These new districts were created using Census 2010 block geography. Some municipal wards, created before the passing of Act 43 and 44, were required to be split between assembly, senate and congressional district boundaries. 2011 Wisconsin Act 39 allowed communities to divide wards, along census block boundaries, if they were divided by newly enacted boundaries. A number of wards created under Wisconsin Act 39 were named using alpha-numeric labels. An example would be where ward 1 divided by an assembly district would become ward 1A and ward 1B, and in other municipalities the next sequential ward number was used: ward 1 and ward 2. The process of dividing wards under Act 39 ended on April 10, 2012. On April 11, 2012, the United States Eastern District Federal Court ordered Assembly Districts 8 and 9 (both in the City of Milwaukee) be changed to follow the court’s description. On September 19, 2012, LTSB divided the few remaining municipal wards that were split by a 2011 Wisconsin Act 43 or 44 district line.Election Data Overview: Election data that is included in this file was collected by LTSB from the Government Accountability Board (GAB)/Wisconsin Elections Commission (WEC) after each general election. A disaggregation process was performed on this election data based on the municipal ward layer that was available at the time of the election. The ward data that is collected after each decennial census is made up of collections of whole and split census blocks. (Note: Split census blocks occur during local redistricting when municipalities include recently annexed property in their ward submissions to the legislature).Disaggregation of Election Data: Election data is first disaggregated from reporting units to wards, and then to census blocks. Next, the election data is aggregated back up to wards, municipalities, and counties. The disaggregation of election data to census blocks is done based on total population. Detailed Methodology:Data is disaggregated first from reporting unit (i.e. multiple wards) to the ward level proportionate to the population of that ward.The data then is distributed down to the block level, again based on total population.When data is disaggregated to block or ward, we restrain vote totals not to exceed population 18 numbers, unless absolutely required.This methodology results in the following: Election data totals reported to the GAB/WEC at the state, county, municipal and reporting unit level should match the disaggregated election data total at the same levels. Election data totals reported to the GAB at ward level may not match the ward totals in the disaggregated election data file.Some wards may have more election data allocated than voter age population. This will occur if a change to the geography results in more voters than the 2010 historical population limits.Other things of note… We use a static, official ward layer (in this case created in 2011) to disaggregate election data to blocks. Using this ward layer creates some challenges. New wards are created every year due to annexations and incorporations. When these new wards are reported with election data, an issue arises wherein election data is being reported for wards that do not exist in our official ward layer. For example, if "Cityville" has four wards in the official ward layer, the election data may be reported for five wards, including a new ward from an annexation. There are two different scenarios and courses of action to these issues: When a single new ward is present in the election data but there is no ward geometry present in the official ward layer, the votes attributed to this new ward are distributed to all the other wards in the municipality based on population percentage. Distributing based on population percentage means that the proportion of the population of the municipality will receive that same proportion of votes from the new ward. In the example of Cityville explained above, the fifth ward may have five votes reported, but since there is no corresponding fifth ward in the official layer, these five votes will be assigned to each of the other wards in Cityville according the percentage of population.Another case is when a new ward is reported, but its votes are part of reporting unit. In this case, the votes for the new ward are assigned to the other wards in the reporting unit by population percentage; and not to wards in the municipality as a whole. For example, Cityville’s ward five was given as a reporting unit together with wards 1, 4, and 5. In this case, the votes in ward five are assigned to wards one and four according to population percentage. Outline Ward-by-Ward Election Results: The process of collecting election data and disaggregating to municipal wards occurs after a general election, so disaggregation has occurred with different ward layers and different population totals. We have outlined (to the best of our knowledge) what layer and population totals were used to produce these ward-by-ward election results.Election data disaggregates from GAB/WEC Reporting Unit -> Ward [Variant year outlined below]Elections 1990 – 2000: Wards 1991 (Census 1990 totals used for disaggregation)Elections 2002 – 2010: Wards 2001 (Census 2000 totals used for disaggregation)Elections 2012: Wards 2011 (Census 2010 totals used for disaggregation)Elections 2014 – 2016: Wards spring 2017 (Census 2010 totals used for disaggregation)Blocks 2011 -> Centroid geometry and spatially joined with Wards [All Versions]Each Block has an assignment to each of the ward versions outlined aboveIn the event that a ward exists now in which no block exists (Occurred with spring 2017) due to annexations, a block centroid was created with a population 0, and encoded with the proper Census IDs.Wards [All Versions] disaggregate -> Blocks 2011This yields a block centroid layer that contains all elections from 1990 to 2016Blocks 2011 [with all election data] -> Wards 2011 (then MCD 2011, and County 2011) All election data (including later elections such as 2016) is aggregated to the Wards 2011 assignment of the blocksNotes:Population of municipal wards 1991, 2001 and 2011 used for disaggregation were determined by their respective Census.Population and Election data will be contained within a county boundary. This means that even though municipal and ward boundaries vary greatly between versions of the wards, county boundaries have stayed the same. Therefore, data totals within a county should be the same between 2011 wards and 2018 wards.Election data may be different for the same legislative district, for the same election, due to changes in the wards from 2011 and 2018. This is due to (a) boundary corrections in the data from 2011 to 2018, and (b) annexations, where a block may have been reassigned.

  3. a

    2002 to 2010 Election Data with 2011 Wards

    • gis-ltsb.hub.arcgis.com
    Updated Sep 30, 2024
    + more versions
    Share
    FacebookFacebook
    TwitterTwitter
    Email
    Click to copy link
    Link copied
    Close
    Cite
    Wisconsin State Legislature (2024). 2002 to 2010 Election Data with 2011 Wards [Dataset]. https://gis-ltsb.hub.arcgis.com/datasets/LTSB::2002-to-2010-election-data-with-2011-wards
    Explore at:
    Dataset updated
    Sep 30, 2024
    Dataset authored and provided by
    Wisconsin State Legislature
    Area covered
    Description

    Election Data Attribute Field Definitions | Wisconsin Cities, Towns, & Villages Data AttributesWard Data Overview: These municipal wards were created by grouping Census 2010 population collection blocks into municipal wards. This project started with the release of Census 2010 geography and population totals to all 72 Wisconsin counties on March 21, 2011, and were made available via the Legislative Technology Services Bureau (LTSB) GIS website and the WISE-LR web application. The 180 day statutory timeline for local redistricting ended on September 19, 2011. Wisconsin Legislative and Congressional redistricting plans were enacted in 2011 by Wisconsin Act 43 and Act 44. These new districts were created using Census 2010 block geography. Some municipal wards, created before the passing of Act 43 and 44, were required to be split between assembly, senate and congressional district boundaries. 2011 Wisconsin Act 39 allowed communities to divide wards, along census block boundaries, if they were divided by newly enacted boundaries. A number of wards created under Wisconsin Act 39 were named using alpha-numeric labels. An example would be where ward 1 divided by an assembly district would become ward 1A and ward 1B, and in other municipalities the next sequential ward number was used: ward 1 and ward 2. The process of dividing wards under Act 39 ended on April 10, 2012. On April 11, 2012, the United States Eastern District Federal Court ordered Assembly Districts 8 and 9 (both in the City of Milwaukee) be changed to follow the court’s description. On September 19, 2012, LTSB divided the few remaining municipal wards that were split by a 2011 Wisconsin Act 43 or 44 district line.Election Data Overview: Election data that is included in this file was collected by LTSB from the Government Accountability Board (GAB)/Wisconsin Elections Commission (WEC) after each general election. A disaggregation process was performed on this election data based on the municipal ward layer that was available at the time of the election. The ward data that is collected after each decennial census is made up of collections of whole and split census blocks. (Note: Split census blocks occur during local redistricting when municipalities include recently annexed property in their ward submissions to the legislature).Disaggregation of Election Data: Election data is first disaggregated from reporting units to wards, and then to census blocks. Next, the election data is aggregated back up to wards, municipalities, and counties. The disaggregation of election data to census blocks is done based on total population. Detailed Methodology:Data is disaggregated first from reporting unit (i.e. multiple wards) to the ward level proportionate to the population of that ward.The data then is distributed down to the block level, again based on total population.When data is disaggregated to block or ward, we restrain vote totals not to exceed population 18 numbers, unless absolutely required.This methodology results in the following: Election data totals reported to the GAB/WEC at the state, county, municipal and reporting unit level should match the disaggregated election data total at the same levels. Election data totals reported to the GAB at ward level may not match the ward totals in the disaggregated election data file.Some wards may have more election data allocated than voter age population. This will occur if a change to the geography results in more voters than the 2010 historical population limits.Other things of note… We use a static, official ward layer (in this case created in 2011) to disaggregate election data to blocks. Using this ward layer creates some challenges. New wards are created every year due to annexations and incorporations. When these new wards are reported with election data, an issue arises wherein election data is being reported for wards that do not exist in our official ward layer. For example, if "Cityville" has four wards in the official ward layer, the election data may be reported for five wards, including a new ward from an annexation. There are two different scenarios and courses of action to these issues: When a single new ward is present in the election data but there is no ward geometry present in the official ward layer, the votes attributed to this new ward are distributed to all the other wards in the municipality based on population percentage. Distributing based on population percentage means that the proportion of the population of the municipality will receive that same proportion of votes from the new ward. In the example of Cityville explained above, the fifth ward may have five votes reported, but since there is no corresponding fifth ward in the official layer, these five votes will be assigned to each of the other wards in Cityville according the percentage of population.Another case is when a new ward is reported, but its votes are part of reporting unit. In this case, the votes for the new ward are assigned to the other wards in the reporting unit by population percentage; and not to wards in the municipality as a whole. For example, Cityville’s ward five was given as a reporting unit together with wards 1, 4, and 5. In this case, the votes in ward five are assigned to wards one and four according to population percentage. Outline Ward-by-Ward Election Results: The process of collecting election data and disaggregating to municipal wards occurs after a general election, so disaggregation has occurred with different ward layers and different population totals. We have outlined (to the best of our knowledge) what layer and population totals were used to produce these ward-by-ward election results.Election data disaggregates from GAB/WEC Reporting Unit -> Ward [Variant year outlined below]Elections 1990 – 2000: Wards 1991 (Census 1990 totals used for disaggregation)Elections 2002 – 2010: Wards 2001 (Census 2000 totals used for disaggregation)Elections 2012: Wards 2011 (Census 2010 totals used for disaggregation)Elections 2014 – 2016: Wards spring 2017 (Census 2010 totals used for disaggregation)Blocks 2011 -> Centroid geometry and spatially joined with Wards [All Versions]Each Block has an assignment to each of the ward versions outlined aboveIn the event that a ward exists now in which no block exists (Occurred with spring 2017) due to annexations, a block centroid was created with a population 0, and encoded with the proper Census IDs.Wards [All Versions] disaggregate -> Blocks 2011This yields a block centroid layer that contains all elections from 1990 to 2016Blocks 2011 [with all election data] -> Wards 2011 (then MCD 2011, and County 2011) All election data (including later elections such as 2016) is aggregated to the Wards 2011 assignment of the blocksNotes:Population of municipal wards 1991, 2001 and 2011 used for disaggregation were determined by their respective Census.Population and Election data will be contained within a county boundary. This means that even though municipal and ward boundaries vary greatly between versions of the wards, county boundaries have stayed the same. Therefore, data totals within a county should be the same between 2011 wards and 2018 wards.Election data may be different for the same legislative district, for the same election, due to changes in the wards from 2011 and 2018. This is due to (a) boundary corrections in the data from 2011 to 2018, and (b) annexations, where a block may have been reassigned.

  4. i

    National Sample Survey 1993 (49th Round) - Schedule 0.21 - Particulars of...

    • catalog.ihsn.org
    • datacatalog.ihsn.org
    • +1more
    Updated Mar 29, 2019
    + more versions
    Share
    FacebookFacebook
    TwitterTwitter
    Email
    Click to copy link
    Link copied
    Close
    Cite
    National Sample Survey Office (2019). National Sample Survey 1993 (49th Round) - Schedule 0.21 - Particulars of Slum - India [Dataset]. http://catalog.ihsn.org/catalog/2628
    Explore at:
    Dataset updated
    Mar 29, 2019
    Dataset authored and provided by
    National Sample Survey Office
    Time period covered
    1993
    Area covered
    India
    Description

    Abstract

    A nationwide survey on "Particulars of Slums" was carried-out by the National Sample Survey Organisation (NSSO) during the period January-June, 1993 in its 49th round to ascertain the extent of civic facilities available in the slums. The 49th round survey among other objectives also collected data on the condition of slum dwellings as well as on some general particulars of slum areas. Apart from formulating the sampling design with an emphasis to obtain an adequate number of slum households for the survey on housing condition and migration, surveyed the slum areas and collected information on slums. The schedule 0.21 was canvassed in both the rural and urban areas. All the slums, both the declared ones as well as the others (undeclared), found in the selected first stage units were surveyed even if hamlet-group/sub-block selection was resorted to in some of then. To ascertain the extent of civic facilities available in the slums as well as the information regarding the improvement of slum condition during a period of last five years was also collected. Information was collected by contacting one or more knowledgeable persons in the FSU on the basis of predominant criterion in both declared and undeclared slums, and not through household approach.

    Geographic coverage

    The geographical coverage of the survey was the whole of the Indian Union except Ladakh & Kargil districts of Jammu & Kashmir, 768 interior villages of Nagaland and 172 villages in Andaman & Nicobar islands which remain inaccessible throughout the year. However, certain districts of Jammu & Kashmir viz. Doda, Anantanag, Pulwama, Srinagar, Badgam, Barmula & Kupwara, as well as Amritsar district in Punjab, had to be excluded from the survey coverage due to unfavourable field conditions.

    Sampling procedure

    Sample Design : The first stage units in the rural sector and urban sector were census villages and urban frame survey (UFS) blocks respectively. However for newly declared towns of the 1991 census,for which UFS frames were not available, census EBs were used as first stage units.

    Sampling frame for fsu's : In the rural sector, the sampling frame in most of the districts was the 1981 census list of villages. However, in Assam and in 8 districts of Madhya Pradesh, 1971 Census lists of villages were used. For Nagaland, the villages situated within 5 kms of a bus route constituted the sampling frame. For the Andaman & Nicobar islands the list of accessible villages was used as sampling frame. In the urban sector, the lists of NSS urban frame survey (UFS) blocks were the sampling frames used in most cases. However, 1991 Census house - listing enumeration blocks were considered as the sampling units for some of the newly declared towns of the 1991 population census, for which UFS frames were not available.

    Stratification : Each state/u.t. was divided into one or more agro-economic regions by grouping contiguous districts which are similar with respect to population density and crop pattern. In Gujarat, however, some districts were subdivided for the purpose of region formation on the basis of location of dry areas and the distribution of tribal population in the state. The total number of regions formed in the whole of India was 78.

    In the rural sector, within each region, each district with a rural population of less than 1.8 million according to the 1981 Census formed a single basic stratum. Districts with larger population were divided into two or more strata, depending on population, by grouping contiguous tehsils, similar as far as possible in respect of rural population density & crop pattern. In Gujarat, however, in the case of districts extending over more than one region, the portion of a district falling in each region constituted a separate stratum even if the rural population of the district as a whole was less than 1.8 million. Further, in Assam, the strata formed for the earlier NSS round on the basis of 1971 Census rural population exactly in the above manner, but with a cutoff point of 1.5 million population, were retained as the strata for rural sampling.

    In the urban sector, strata were formed, within NSS regions, on the basis of 1981 (1991 in some of the new towns) Census population. Each city with a population of 10 lakhs or more formed a separate stratum itself. The remaining towns of each region were grouped to form three different strata on the basis of 1981 (1991 in a few cases) census population.

    Sub stratification of urban strata : In order to be able to allocate a large proportion of the first stage sample to slum-dominated areas than would otherwise be possible, each stratum in the urban sector was divided into two "sub-strata" a s follows. Sub-stratum 1 was constituted of the UFS blocks in the stratum with a "slum area" indicated in the frame. Substratum 2 was constituted of the remaining blocks of the stratum.

    Allocation of sample : A total all-India sample of 8000 first stage units (5072 villages and 2928 urban blocks) determined on the basis of investigator strength in different state/u.t's and the expected workload per investigator was first allocated to the states/u.t's in proportion to Central Staff available. The sample thus obtained for each state/u.t. was then allocated to its rural & urban sectors considering the relative sizes of the rural & urban population with double weightage for the urban sector. Within each sector of a state/u.t., the allotted sample size was reallocated to the different strata in proportion to stratum population. Stratum-level allocations were adjusted so that the sample size for a stratum (rural or urban) was at least a multiple of 4. This was done in order to have equal sized samples in each sub-sample and sub-round.

    In the urban sector, stratum-level allocations were further allocated to the two sub-strata in proportion to the number of UFS blocks in the sub-strata, with double weightage to sub-stratum 1, with a minimum sample size of 4 blocks to sub-stratum 1 (2 if stratum allocation was only 4). Sub-stratum level allocations were made even in number.

    Selection of fsu's : Sample villages except in Arunachal Pradesh were selected by pps systematic sampling with population as the size variable and sample blocks by simple random sampling without replacement. In both sectors the sample of fsu's was drawn in the form of two independent sub-samples. (In Arunachal Pradesh the sample of villages was drawn by a cluster sampling procedure. The field staff were supplied with a list of sample "nucleus" villages and were advised to select cluster of villages building up each cluster around a nucleus village according to prescribed guidelines. The nucleus villages were selected circular-systematically with equal probability in the form of two ) independent sub-samples.

    Mode of data collection

    Face-to-face [f2f]

    Research instrument

    The questionnaire consisted of 6 blocks (including 0) as given below : Block - 0 : descriptive identification of sample village/block having slum Block - 1 : identification of sample village/block having slum. Block - 3 : Remarks by investigator. Block - 4 : Comments by Supervisory Officer(s). Block - 5 : Particulars about slum.

    Response rate

    1572 slums spread over 5072 villages and 2928 urban blocks in the sample have been surveyed.

  5. Not seeing a result you expected?
    Learn how you can add new datasets to our index.

Share
FacebookFacebook
TwitterTwitter
Email
Click to copy link
Link copied
Close
Cite
Metropolitan Council (2020). Profile of Selected Economic Characteristics for Census Tracts: 2000 [Dataset]. https://gisdata.mn.gov/dataset/us-mn-state-metc-society-census-econchar-trct2000

Profile of Selected Economic Characteristics for Census Tracts: 2000

Explore at:
html, fgdb, shpAvailable download formats
Dataset updated
Jul 9, 2020
Dataset provided by
Metropolitan Council
Description

Summary File 3 Data Profile 3 (SF3 Table DP-3) for Minneapolis-St. Paul 7 County metropolitan area is a subset of the profile of selected economic characteristics for 2000 prepared by the U. S. Census Bureau.

This table (DP-3) includes: Employment Status, Commuting to Work, Occupation, Industry, Class of Worker, Income in 1999, Median earnings, Number Below Poverty Level, Poverty Status in 1999, For Whom Poverty Status is Determined

US Census 2000 Demographic Profiles: 100-percent and Sample Data

The profile includes four tables (DP-1 thru DP-4) that provide various demographic, social, economic, and housing characteristics for the United States, states, counties, minor civil divisions in selected states, places, metropolitan areas, American Indian and Alaska Native areas, Hawaiian home lands and congressional districts (106th Congress). It includes 100-percent and sample data from Census 2000. The DP-1 table is available as part of the Summary File 1 (SF 1) dataset, and the other three tables are available as part of the Summary File 3 (SF 3) dataset.

The US Census provides DP-1 thru DP-4 data at the Census tract level through their DataFinder search engine. However, since the Metropolitan Council and MetroGIS participants are interested in all Census tracts within the seven county metropolitan area, it was quicker to take the raw Census SF-1 and SF-3 data at tract levels and recreate the DP1-4 variables using the appropriate formula for each DP variable. This file lists the formulas used to create the DP variables.

Search
Clear search
Close search
Google apps
Main menu