Ricerca in blocco del tratto e del blocco del censimento degli indirizzi


16

Esiste un modo gratuito o economico per codificare un gran numero di indirizzi e restituire o aggiungere il censimento e bloccare i dati?

Esistono diversi modi per geocodificare un indirizzo e ottenere il lat long, ma ho davvero bisogno di ottenere il censimento e bloccare i dati.

Risposte:


16

Ok Ben, ecco i miei presupposti:

1) Hai già ottenuto i tuoi dati (avevo alcuni punti di indirizzo in un file di forma e ho scaricato il file di censimento e gli shapefile del blocco di censimento per il Missouri).

2) Hai già geocodificato i tuoi punti di indirizzo e ti senti a tuo agio nel proiettare i dati.

3) Sei a tuo agio con una soluzione OGR / PostGIS (entrambi gratuiti).

Ecco alcune note di installazione se non si dispone di questi software: Come installare PostGREs con supporto PostGIS . (Di BostonGIS. Per favore, non offenderti per il loro titolo, penso solo che sia il miglior how-to là fuori.) Inoltre, ecco uno , due e tre siti che descrivono come installare GDAL / OGR con i collegamenti Python.

Avvertenza : prima di eseguire l'analisi effettiva (ad es.ST_ContainsRoba, di seguito) è necessario assicurarsi che tutti i livelli siano nella stessa proiezione ! Se disponi di shapefile, è facile tradurre da una proiezione all'altra usando Quantum GIS (QGIS) o OGR (o ArcGIS se ce l'hai). In alternativa, è possibile eseguire la trasformazione della proiezione nel database utilizzando le funzioni PostGIS. Praticamente scegli il tuo veleno o facci sapere se si tratta di un ostacolo.

Con questi dati, è così che ho aggiunto tratto e blocco degli attributi ad alcuni dati dei punti indirizzo usando PostGIS:

Prima ho usato ogr2ogrper importare i tre shapefile in PostGIS:

Importa indirizzi 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

Importa i trattati censuari (Missouri) usando ogr2ogr: il spMoWestsuffisso implica che ho già tradotto i miei dati in 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

Importazione di blocchi di dati (Missouri): questa operazione ha richiesto del tempo. In effetti, il mio computer ha continuato a bloccarsi e ho dovuto installare un fan! Oh, anche, ogr2ogrnon darà alcun feedback, quindi non essere incisivo; assicurati di aspettare e alla fine finirà.

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 volta completata l'importazione dei dati, avvia PgAdmin III (la GUI di PostGREs), naviga nel tuo database e lancia alcuni comandi di manutenzione rapida in modo che PostGREsql funzionerà più velocemente usando questi nuovi dati:

vacuum mcdon_addresses;
vacuum mo_tracts_2010;
vacuum mo_blocks_2010;

Successivamente, ero curioso di sapere quanti punti indirizzo grezzi ho importato, quindi ho fatto un rapido COUNT(*). Di solito faccio un conteggio all'inizio di un'attività come questa per darmi un punto d'appoggio per i "controlli di integrità" in seguito ...

SELECT COUNT(*) FROM mcdon_addresses;
-- 11979

Nella fase successiva, ho creato due nuove tabelle, aggiungendo gradualmente gli attributi dei tratti, e quindi gli attributi dei blocchi, alla mia tabella dei punti dell'indirizzo originale. Come vedrai, la ST_Containsfunzione PostGIS ha fatto il lavoro pesante, creando in ogni caso una nuova tabella di punti, ognuno acquisendo gli attributi dei tratti e bloccando i poligoni in cui cadevano.

Nota! Per brevità, sto prendendo solo una manciata di campi da ogni tabella. Probabilmente vorrai quasi tutto. Dico quasi perché perché dovrai omettere il ogr_fidcampo (forse anche altri?) Dalle tabelle che stai combinando, altrimenti PostGRE si lamenterà di entrambi i campi con lo stesso nome.

(PS Ho fatto un po 'di curiosità qui mentre lo capivo: http://postgis.net/docs/manual-1.4/ch04.html )

Crea una nuova tabella di punti di indirizzamento con attributi di tratti: Nota : prefisso ogni colonna di output con un suggerimento che rivela quale tabella è iniziata (spiegherò perché di seguito).

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);

Mantieni la tabella in modo che PostGREs continui a funzionare senza problemi:

vacuum mcdon_addresses_wtract;

Ora avevo due domande ..

ST_Contains ha funzionato davvero? ..e .. Ha senso il numero di indirizzi restituiti, dati gli input di dati che ho usato?

Sono stato in grado di rispondere ad entrambi utilizzando la stessa query:

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

Una rapida riflessione sulle perdite: in primo luogo, ho verificato in ArcGIS (è possibile farlo anche in QGIS) e ha restituito lo stesso conteggio. Quindi, perché la differenza? Innanzitutto, alcuni indirizzi caddero al di fuori del Missouri, e ho confrontato solo con un poligono di tratti del Missouri. In secondo luogo, a un'analisi più approfondita, sembra che esistessero alcuni esempi di cattiva digitalizzazione nei dati degli indirizzi. In particolare, molti dei punti non rilevati ST_Containsavevano campi di attributi vuoti, il che è un buon segno che qualcosa è andato storto durante la digitalizzazione; significa anche che non erano comunque dati utilizzabili. A questo punto, sono a mio agio con le differenze in quanto potrei ragionevolmente tornare indietro e migliorare i dati, consentendo un'analisi più pulita.

Passando, il passaggio successivo è stato l'aggiunta della tabella address / tracts con gli attributi dei dati dei blocchi. Allo stesso modo, l'ho fatto creando una nuova tabella, ancora una volta il prefisso di ciascun campo di output per indicare la tabella da cui proveniva (il prefisso è abbastanza importante che vedrai):

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);

Naturalmente, mantieni la tabella:

vacuum mcdon_addr_trct_and_blk;

Il motivo per cui ho anteposto a ciascun campo di output è perché, in caso contrario, alcuni campi avrebbero gli stessi nomi e sarebbe impossibile distinguerli l'uno dall'altro nel prodotto finale (anche ... PostGREs potrebbe essersi lamentato a metà strada in questo, ma da quando stavo rinominando, non ho dato la possibilità). Considera, ad esempio, i due campi seguenti di entrambi i passaggi, sopra. Puoi capire perché li ho rinominati ..

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

Ora che abbiamo un indirizzo con set di dati di tratte e blocchi, abbiamo ancora lo stesso numero di punti?

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

Sì, lo facciamo! Se vuoi, puoi andare avanti ed eliminare la prima tabella che abbiamo creato mcdon_addresses_wtract,. Non ne abbiamo più bisogno per l'analisi.

Come ultima azione, si potrebbe desiderare di esportare i dati da Postgres in uno shapefile ESRI in modo che è possibile visualizzare con altri programmi, come ArcGIS (di nota, QGIS può leggere i dati PostGIS senza numero). Se sei interessato, ecco come potresti eseguire la conversione 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"

Infine, quando esegui questo comando, probabilmente riceverai alcuni avvisi come questo:

Avviso 6: Nome campo normalizzato / riciclato: da "tr_statefp10" a "tr_statefp"

Questo significa semplicemente che OGR ha dovuto abbreviare quel nome di campo, perché il nome del campo in un file di forma può essere solo così lungo.

Naturalmente, questo è solo uno dei molti modi per realizzare questo lavoro.


9

La FCC ha un'API: http://www.fcc.gov/developer/census-block-conversions-api


2
+1 Questo sito relativamente oscuro (chi andrebbe ai dati FCC per il censimento?) Sembra offrire una soluzione potente e direttamente applicabile al problema. Benvenuto nella nostra community, Bob!
whuber

Quel sito fcc non ha dato la risposta giusta quando l'ho confrontato con le mappe a livello di blocco pubblicate dal censimento. Usato lat / long da google maps. census.gov/geo/maps-data/maps/block/2010/place/…
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.