Zbiorcze wyszukiwanie adresu spisu ludności i bloku

16

Czy istnieje darmowy lub tani sposób na zakodowanie dużej liczby adresów oraz zwrócenie lub dołączenie spisu ludności i zablokowanie danych?

Istnieje wiele sposobów geokodowania adresu i uzyskania długiego czasu, ale naprawdę potrzebuję uzyskać spis ludności i zablokować dane.

Ben Farmer
źródło

Odpowiedzi:

16

Ok Ben, oto moje założenia:

1) Masz już swoje dane (miałem kilka punktów adresowych w pliku kształtu, a ja ściągnąłem plik spisu ludności i blok danych pliku kształtu dla Missouri).

2) Geokodowałeś już swoje punkty adresowe i możesz wygodnie wyświetlać dane.

3) Nie masz nic przeciwko rozwiązaniu OGR / PostGIS (oba za darmo).

Oto kilka uwag dotyczących instalacji, jeśli nie masz tego oprogramowania: Jak zainstalować PostGRE z obsługą PostGIS . (Autor: BostonGIS. Proszę nie obrażać się na ich tytuł, po prostu uważam, że jest to najlepszy poradnik). Oto też jedna , dwie i trzy strony opisujące sposób instalacji GDAL / OGR z powiązaniami Pythona.

Uwaga : przed wykonaniem rzeczywistej analizy (tj.ST_ContainsRzeczy poniżej), powinieneś upewnić się, że wszystkie twoje warstwy są w tej samej projekcji ! Jeśli masz pliki shapefile, łatwo je przetłumaczyć z jednej projekcji na drugą za pomocą Quantum GIS (QGIS) lub OGR (lub ArcGIS, jeśli go masz). Alternatywnie można wykonać transformację projekcji w bazie danych za pomocą funkcji PostGIS. Zasadniczo wybierz swoją truciznę lub daj nam znać, jeśli jest to przeszkodą.

W przypadku tych danych w ten sposób dołączyłem traktat i blokowałem atrybuty do niektórych danych punktów adresowych za pomocą PostGIS:

Najpierw ogr2ogrzaimportowałem trzy pliki kształtu do PostGIS:

Importuj adresy za pomocą 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

Połacie import spisu (Missouri) przy użyciu ogr2ogr:spMoWest przyrostek implikuje już przetłumaczone moje dane do Missouri State Samolot Zachodniej Stóp.

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

Importuj dane bloków (Missouri): Ten zajął trochę czasu. W rzeczywistości mój komputer ciągle się zawieszał i musiałem włożyć w to wentylator! Och, też ogr2ogrnie udzielam żadnych informacji zwrotnych, więc nie daj się nabić; koniecznie poczekaj na to, a ostatecznie skończy.

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

Po zakończeniu importowania danych uruchom PgAdmin III (GUI PostGRE), przejrzyj bazę danych i rzuć kilka szybkich poleceń konserwacyjnych, aby PostGREsql działał szybciej przy użyciu tych nowych danych:

vacuum mcdon_addresses;
vacuum mo_tracts_2010;
vacuum mo_blocks_2010;

Następnie byłem ciekawy, ile zaimportowałem nieprzetworzonych punktów adresowych, więc zrobiłem to szybko COUNT(*). Zwykle liczę na początku takiego zadania, aby dać mi później podstawę do „kontroli zdrowia”.

SELECT COUNT(*) FROM mcdon_addresses;
-- 11979

W następnej fazie utworzyłem dwie nowe tabele, stopniowo dodając atrybuty traktów, a następnie atrybuty bloków do mojej oryginalnej tabeli punktów adresowych. Jak zobaczysz, ST_Containsfunkcja PostGIS wykonała ciężkie podnoszenie, w każdym przypadku tworząc nową tabelę punktów, z których każda zyskała atrybuty traktów i blokuje wielokąty, w których wpadli.

Uwaga! Dla zwięzłości zabieram tylko garść pól z każdego stołu. Prawdopodobnie będziesz chciał prawie wszystkiego. Mówię prawie dlatego, że musisz pominąć ogr_fidpole (może nawet inne?) Z tabel, które łączysz, w przeciwnym razie PostGRE będą narzekać na oba pola o tej samej nazwie.

(PS. Szukałem tutaj, szukając tego: http://postgis.net/docs/manual-1.4/ch04.html )

Utwórz nową tabelę punktów adresowych z atrybutami traktatów: Uwaga Poprzedzam każdą kolumnę wyjściową wskazówką, w której tabeli ona się rozpoczęła (wyjaśnię dlaczego poniżej).

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

Utrzymaj tabelę, aby PostGRE działał płynnie:

vacuum mcdon_addresses_wtract;

Teraz miałem dwa pytania ...

Czy ST_Contains rzeczywiście działało? ..i .. Czy liczba zwracanych adresów ma sens, biorąc pod uwagę użyte dane?

Byłem w stanie odpowiedzieć na oba, używając tego samego zapytania:

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

Szybkie zastanowienie się nad stratami: po pierwsze, sprawdziłem w ArcGIS (możesz to zrobić również w QGIS) i zwróciło to samo. Skąd ta różnica? Po pierwsze, niektóre adresy wypadły poza Missouri, a ja porównałem tylko z wielokątem traktów Missouri. Po drugie, po bliższej analizie wydaje się, że były pewne przykłady złej digitalizacji danych adresowych. W szczególności wiele punktów, które nie zostały złapane, ST_Containsmiały puste pola atrybutów, co jest dobrym znakiem, że coś poszło nie tak podczas digitalizacji; oznacza to również, że i tak nie były to dane przydatne. W tym momencie czuję się dobrze z różnicami, ponieważ mogłem rozsądnie wrócić i poprawić dane, co pozwoli na czystszą analizę.

Idąc dalej, następnym krokiem było dodanie tabeli adresów / traktatów z atrybutami z danych bloków. Podobnie zrobiłem to, tworząc nową tabelę, po raz kolejny poprzedzając każde pole wyjściowe, aby wskazać tabelę, z której pochodzi (prefiks jest dość ważny, zobaczysz):

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

Oczywiście zachowaj tabelę:

vacuum mcdon_addr_trct_and_blk;

Powodem, dla którego poprzedziłem każde pole wyjściowe, było to, że gdybym tego nie zrobił, niektóre pola miałyby te same nazwy i niemożliwe byłoby ich rozróżnienie w produkcie końcowym (także ... PostGREs może narzekać na to w połowie, ale ponieważ zmieniłem nazwę, nie dałem temu szansy). Rozważmy na przykład następujące dwa pola z obu kroków powyżej. Możesz zobaczyć, dlaczego zmieniłem ich nazwę ...

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

Teraz, gdy mamy adresy z traktami i blokami danych, czy nadal mamy taką samą liczbę punktów?

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

Tak! Jeśli chcesz, możesz śmiało usunąć pierwszą tabelę stworzyliśmy, mcdon_addresses_wtract. Nie potrzebujemy go już do analizy.

W ostatniej akcji, to może chcesz wyeksportować dane z PostgreSQL w produkt shapefile ESRI, dzięki czemu można go zobaczyć z innych programów, takich jak ArcGIS (nuty, QGIS może odczytać danych PostGIS bez problemu). Jeśli jesteś zainteresowany, oto jak możesz wykonać konwersję za pomocą 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"

Wreszcie po uruchomieniu tego polecenia prawdopodobnie otrzymasz kilka ostrzeżeń:

Ostrzeżenie 6: Znormalizowana / wyprana nazwa pola: „tr_statefp10” na „tr_statefp”

Oznacza to po prostu, że OGR musiał skrócić tę nazwę pola, ponieważ nazwa pola w pliku kształtu może być tylko tak długa.

Oczywiście jest to tylko jeden z wielu sposobów wykonania tej pracy.

elrobis
źródło
9

FCC ma API: http://www.fcc.gov/developer/census-block-conversions-api

Bob wie
źródło
2
+1 Ta stosunkowo mało znana strona (kto poszedłby do FCC po dane ze spisu powszechnego?) Wydaje się oferować skuteczne, bezpośrednio stosowane rozwiązanie problemu. Witamy w naszej społeczności, Bob!
whuber
Ta strona fcc nie dała właściwej odpowiedzi, gdy porównałem ją z mapami poziomu bloków opublikowanymi przez spis powszechny. Używana długość / długość z Google Maps. census.gov/geo/maps-data/maps/block/2010/place/…