Minor addition to README.

leehach · leehach · commit 624494f62cc5 · 2013-11-19T02:07:56.000-05:00
diff --git a/postgis_support/README.md b/postgis_support/README.md
@@ -4,4 +4,4 @@ The `geoheader` table is altered with the addition of a geometry column `geom` a
 
 It is assumed that the data manager is familiar with loading spatial data. Mapping demographic data the way the data has been released requires joining the spatial layer to `geoheader` and then joining to the sequences. Because the spatial data are of little interest without the associated demographic data, I feel that it is better to put the spatial data directly into `geoheader`. Then mapping the data can be accomplished with only one join.
 
-The way PostGIS support is implemented for census-postgres differs from the traditional GIS approach in that all geometries for all scales are inserted into one table. Normally, a GIS user will want to have states, counties, tracts, and other geographies in separate layers (tables). But Census releases these data mashed together into one or two files per sequence (only tracts and block groups are broken out into separate files for the 5-year estimates). In the future, I intend to test using partitioning to separate scales while maintaining consistent table structure.
+The way PostGIS support is implemented for census-postgres differs from the traditional GIS approach in that all geometries for all scales are inserted into one table. Normally, a GIS user will want to have states, counties, tracts, and other geographies in separate layers (tables). But Census releases these data mashed together into one or two files per sequence (only tracts and block groups are broken out into separate files for the 5-year estimates). In the future, I intend to test using partitioning to separate scales while maintaining consistent table structure. In the meantime, GIS users will have to filter manually, or the data manager will have to add spatial views restricting the data by geographic scale.

Original file line number	Diff line number	Diff line change
@@ -4,4 +4,4 @@ The `geoheader` table is altered with the addition of a geometry column `geom` a
`4`	`4`
`5`	`5`	It is assumed that the data manager is familiar with loading spatial data. Mapping demographic data the way the data has been released requires joining the spatial layer to `geoheader` and then joining to the sequences. Because the spatial data are of little interest without the associated demographic data, I feel that it is better to put the spatial data directly into `geoheader`. Then mapping the data can be accomplished with only one join.
`6`	`6`
`7`		-The way PostGIS support is implemented for census-postgres differs from the traditional GIS approach in that all geometries for all scales are inserted into one table. Normally, a GIS user will want to have states, counties, tracts, and other geographies in separate layers (tables). But Census releases these data mashed together into one or two files per sequence (only tracts and block groups are broken out into separate files for the 5-year estimates). In the future, I intend to test using partitioning to separate scales while maintaining consistent table structure.
	`7`	+The way PostGIS support is implemented for census-postgres differs from the traditional GIS approach in that all geometries for all scales are inserted into one table. Normally, a GIS user will want to have states, counties, tracts, and other geographies in separate layers (tables). But Census releases these data mashed together into one or two files per sequence (only tracts and block groups are broken out into separate files for the 5-year estimates). In the future, I intend to test using partitioning to separate scales while maintaining consistent table structure. In the meantime, GIS users will have to filter manually, or the data manager will have to add spatial views restricting the data by geographic scale.