Búsqueda masiva del tramo censal de direcciones y bloque

¿Existe una forma gratuita o barata de codificar una gran cantidad de direcciones y devolver o anexar la sección censal y bloquear los datos?

Hay varias formas de geocodificar una dirección y obtener el lat largo, pero realmente necesito obtener el tramo del censo y bloquear los datos.

Ok Ben, aquí están mis suposiciones:

1) Ya tiene sus datos (tenía algunos puntos de dirección en un archivo shape y descargué archivos censales del tramo censal y del bloque censal para Missouri).

2) Ya ha geocodificado sus puntos de dirección y se siente cómodo proyectando los datos.

3) Te sientes cómodo con una solución OGR / PostGIS (ambas gratis).

Aquí hay algunas notas de instalación si no tiene este software: Cómo instalar PostGRE con soporte PostGIS . (Por BostonGIS. Por favor, no se ofendan por su título, solo creo que es la mejor manera de hacerlo.) Además, aquí hay uno , dos y tres sitios que describen cómo instalar GDAL / OGR con enlaces de Python.

Advertencia : ¡Antes de realizar el análisis real (es decir, lasST_Containscosas a continuación), debe asegurarse de que todas sus capas estén en la misma proyección ! Si tiene archivos de forma, es fácil traducir de una proyección a otra utilizando Quantum GIS (QGIS) u OGR (o ArcGIS si lo tiene). Alternativamente, puede realizar la transformación de proyección en la base de datos utilizando las funciones de PostGIS. Básicamente elige tu veneno, o avísanos si este es un obstáculo.

Con esos datos, así es como agregué folletos y bloques atribuidos a algunos datos de puntos de dirección usando PostGIS:

Primero solía ogr2ogrimportar los tres shapefiles en PostGIS:

Importar direcciones usando ogr2ogr:

ogr2ogr -f "PostGreSQL" PG:"host=127.0.0.1 user=youruser dbname=yourdb password=yourpass" "E:\path_to\addresses.shp" -nln mcdon_addresses -nlt geometry

Importar secciones censales (Missouri) utilizando ogr2ogr: el spMoWestsufijo implica que ya he traducido mis datos a Missouri State Plane West Feet.

ogr2ogr -f "PostGreSQL" PG:"host=127.0.0.1 user=youruser dbname=yourdb password=yourpass" "E:\path_to\st_tract10_spMoWest.shp" -nln mo_tracts_2010 -nlt geometry

Importar datos de bloques (Missouri): Este tomó un tiempo. De hecho, mi computadora seguía fallando y tuve que ponerle un ventilador. Ah, también, ogr2ogrno daré ningún comentario, así que no seas agresivo; asegúrese de esperar y eventualmente terminará.

ogr2ogr -f "PostGreSQL" PG:"host=127.0.0.1 user=youruser dbname=yourdb password=yourpass" "E:\path_to\st_block10_spMoWest.shp" -nln mo_blocks_2010 -nlt geometry

Una vez que se realizan las importaciones de datos, inicie PgAdmin III (la GUI de PostGRE), explore su base de datos y ejecute algunos comandos de mantenimiento rápidos para que PostGREsql se ejecute más rápido utilizando estos nuevos datos:

vacuum mcdon_addresses;
vacuum mo_tracts_2010;
vacuum mo_blocks_2010;

Luego, tenía curiosidad sobre cuántos puntos de dirección sin procesar importé, así que hice un rápido COUNT(*). Por lo general, hago un recuento al comienzo de una tarea como esta para darme un punto de apoyo para "controles de cordura" más adelante ...

SELECT COUNT(*) FROM mcdon_addresses;
-- 11979

En la siguiente fase, creé dos nuevas tablas, agregando gradualmente los atributos de los tratados, y luego los atributos de los bloques, a mi tabla de puntos de dirección original. Como verá, la ST_Containsfunción PostGIS hizo el trabajo pesado, en cada caso creando una nueva tabla de puntos, cada uno ganando los atributos de los tractos y bloquea los polígonos en los que cayeron.

¡Nota! Por brevedad, solo estoy tomando un puñado de campos de cada tabla. Probablemente quieras casi todo. Digo casi porque porque necesitarás omitir el ogr_fidcampo (¿tal vez incluso otros?) De las tablas que estás combinando, de lo contrario, PostGRE se quejará de que ambos campos tienen el mismo nombre.

(PD: husmeé por aquí mientras descubría esto: http://postgis.net/docs/manual-1.4/ch04.html )

Cree una nueva tabla de puntos de dirección con atributos de tratados: Tenga en cuenta que prefijo cada columna de salida con una pista que revela en qué tabla comenzó (explicaré por qué a continuación).

CREATE TABLE mcdon_addresses_wtract AS
SELECT 
  a.wkb_geometry,
  a.route AS addr_route, 
  a.box AS addr_box, 
  a.new_add AS addr_new_add, 
  a.prefix AS addr_prefix, 
  a.rdname AS addr_rdname, 
  a.road_name AS addr_road_name, 
  a.city AS addr_city, 
  a.state AS addr_state, 
  a.zip AS addr_zip,
  t.statefp10 AS tr_statefp10, 
  t.countyfp10 AS tr_countyfp10, 
  t.tractce10 AS tr_tractce10,  
  t.name10 AS tr_name10, 
  t.pop90 AS tr_pop90, 
  t.white90 AS tr_white90, 
  t.black90 AS tr_black90, 
  t.asian90 AS tr_asian90, 
  t.amind90 AS tr_amind90, 
  t.other90 AS tr_other90, 
  t.hisp90 AS tr_hisp90
FROM
  mcdon_addresses AS a,
  mo_tracts_2010 AS t
WHERE 
  ST_Contains(t.wkb_geometry, a.wkb_geometry);

Mantenga la tabla para que PostGRE continúe funcionando sin problemas:

vacuum mcdon_addresses_wtract;

Ahora tenía dos preguntas ...

¿Funcionó realmente el ST_Contains? ... y ... ¿Tiene sentido el número de direcciones devueltas dadas las entradas de datos que utilicé?

Pude responder a ambos usando la misma consulta:

select count(*) from mcdon_addresses_wtract;
-- returns 11848

Una reflexión rápida sobre las pérdidas: Primero, verifiqué en ArcGIS (también podría hacerlo en QGIS) y me devolvió el mismo recuento. Entonces, ¿por qué la diferencia? Primero, algunas direcciones cayeron fuera de Missouri, y solo comparé con un polígono de tratados de Missouri. En segundo lugar, en un análisis más detallado, parece que hubo algunos ejemplos de mala digitalización en los datos de las direcciones. Específicamente, muchos de los puntos no capturados ST_Containstenían campos de atributos vacíos, lo cual es una buena señal de que algo salió mal durante la digitalización; También significa que no eran datos utilizables de todos modos. En este punto, me siento cómodo con las diferencias, ya que podría volver razonablemente y mejorar los datos, lo que permite un análisis más limpio.

Continuando, el siguiente paso fue agregar la tabla de direcciones / tratados con atributos de los datos de los bloques. Del mismo modo, hice esto creando una nueva tabla, una vez más con el prefijo de cada campo de salida para indicar la tabla de la que proviene (el prefijo es bastante importante, verá):

CREATE TABLE mcdon_addr_trct_and_blk AS
SELECT 
  a.*,
  b.pop90 AS blk_pop90, 
  b.white90 AS blk_white90, 
  b.black90 AS blk_black90, 
  b.asian90 AS blk_asian90, 
  b.amind90 AS blk_amind90, 
  b.other90 AS blk_other90, 
  b.hisp90 AS blk_hisp90
FROM 
  mcdon_addresses_wtract AS a,
  mo_blocks_2010 AS b
WHERE
  ST_Contains(b.wkb_geometry, a.wkb_geometry);

Por supuesto, mantenga la tabla:

vacuum mcdon_addr_trct_and_blk;

La razón por la que prefije cada campo de salida fue porque si no lo tuviera, algunos campos tendrían los mismos nombres, y sería imposible distinguirlos entre sí en el producto final (también ... PostGRE puede haberse quejado a mitad de camino en esto, pero como estaba renombrando, no le di la oportunidad). Considere, por ejemplo, los siguientes dos campos de ambos pasos, arriba. Puedes ver por qué los renombré ...

t.pop90 AS tr_pop90   -- would have been simply pop90
b.pop90 AS blk_pop90  -- also would have been pop90 ! 

Ahora que tenemos direcciones con conjuntos de datos de tratados y bloques, ¿todavía tenemos el mismo número de puntos?

select count(*) from mcdon_addr_trct_and_blk;
-- 11848 (thumbs up!)

¡Sí! Si lo desea, puede seguir adelante y eliminar la primera tabla que hemos creado, mcdon_addresses_wtract. Ya no lo necesitamos para el análisis.

Como última acción, es posible que desee exportar sus datos de PostGRE a un archivo de forma ESRI para que pueda verlo con otros programas, como ArcGIS (es de destacar que QGIS puede leer los datos de PostGIS sin problemas). Si está interesado, así es como podría realizar la conversión usando ogr2ogr:

ogr2ogr -f "ESRI Shapefile" "E:\path_to\addr_trct_blk.shp" PG:"host=127.0.0.1 user=youruser dbname=yourdb password=yourpass" "mcdon_addr_trct_and_blk"

Finalmente, cuando ejecuta este comando, es probable que reciba algunas advertencias como esta:

Advertencia 6: Nombre de campo normalizado / lavado: 'tr_statefp10' a 'tr_statefp'

Esto solo significa que OGR tuvo que acortar ese nombre de campo, porque el nombre del campo en un archivo de forma solo puede ser tan largo.

Por supuesto, esta es solo una de las muchas formas de lograr este trabajo.

La FCC tiene una API: http://www.fcc.gov/developer/census-block-conversions-api