Çok sayıda adresi kodlamanın ve nüfus sayımı sistemini geri getirmenin veya eklemenin ve verileri engellemenin ücretsiz veya ucuz bir yolu var mı?
Bir adresi coğrafi kodlamak ve lat uzun almak için çeşitli yollar vardır, ama gerçekten sayım yolu almak ve veri engellemek gerekir.
Yanıtlar:
Tamam Ben, benim varsayımlarım:
1) Verilerinizi zaten aldınız (şekil dosyasında bazı adres noktalarım vardı ve Missouri için sayım yolu ve sayım bloğu şekil dosyaları indirdim).
2) Adres noktalarınızı zaten coğrafi olarak kodladınız ve verileri yansıtmakta rahatsınız.
3) OGR / PostGIS çözümüyle rahatsınız (her ikisi de ücretsiz).
Bu yazılıma sahip değilseniz bazı yükleme notları şunlardır: PostGIS destekli PostGRE'leri yükleme . (BostonGIS tarafından. Lütfen başlıklarına saldırmayın, sadece bunun en iyi nasıl yapılacağını düşünüyorum.) Ayrıca, burada GDAL / OGR'yi Python bağlamaları ile nasıl yükleyeceğini açıklayan bir , iki ve üç site.
Uyarı : Gerçek analizi yapmadan önce (örn.ST_ContainsAşağıdaki şeyler) tüm katmanlarınızın aynı projeksiyonda olduğundan emin olmalısınız! Şekil dosyalarınız varsa, Quantum GIS (QGIS) veya OGR (veya varsa ArcGIS ) kullanarak bir projeksiyondan diğerine çevirmek kolaydır. Alternatif olarak, PostGIS işlevlerini kullanarak veritabanındaki projeksiyon dönüşümünü gerçekleştirebilirsiniz. Temel olarak zehirinizi seçin veya bunun bir engel olup olmadığını bize bildirin.
Bu öğelerle, PostGIS kullanarak bazı adres noktaları verilerine yol ekledim ve özellikleri engelledim:
İlk ogr2ogrolarak üç şekil dosyasını PostGIS'e alırdım:
Ogr2ogr kullanarak adresleri içe aktarın:
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
İthalat sayım yolları ogr2ogr kullanarak (Missouri):spMoWest eki ima Zaten Missouri State Düzlem Batı Ayaklar verilerimi çevirdik.
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
Verileri içe aktarma blokları (Missouri): Bu biraz zaman aldı. Aslında, bilgisayarım çökmeye devam etti ve üzerine bir fan koymak zorunda kaldım! Oh, ayrıca, ogr2ogrherhangi bir geri bildirim vermeyecek, bu yüzden yumruklu olmayın; beklediğinizden emin olun ve sonunda bitecektir.
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
Veri içe aktarma işlemi tamamlandıktan sonra, PgAdmin III'ü (PostGREs GUI) başlatın, veritabanınıza göz atın ve PostGREsql'in bu yeni verileri kullanarak daha hızlı çalışması için bazı hızlı bakım komutları atın:
vacuum mcdon_addresses;
vacuum mo_tracts_2010;
vacuum mo_blocks_2010;
Sonra, kaç tane ham adres noktası aldığımı merak ettim, bu yüzden hızlıca yaptım COUNT(*). Genelde böyle bir görevin başlangıcında, daha sonra bana "akıl sağlığı kontrolleri" için bir dayanak vermek istiyorum.
SELECT COUNT(*) FROM mcdon_addresses;
-- 11979
Bir sonraki aşamada, yeni adres tablolarıma yavaş yavaş tracts özniteliklerini ve sonra blok özniteliklerini ekleyerek iki yeni tablo oluşturdum. Gördüğünüz gibi, PostGIS ST_Containsişlevi, her durumda yeni bir nokta tablosu oluşturarak, her biri içine düştükleri kanalların ve blok poligonların niteliklerini kazanan ağır kaldırma gerçekleştirdi.
Not! Kısacası, her tablodan sadece bir avuç alan alıyorum. Muhtemelen neredeyse her şeyi isteyeceksiniz . Neredeyse söylüyorum, çünkü ogr_fidalanı (belki de başkalarını?) Birleştirdiğiniz tablolardan atlamanız gerekeceği için, aksi takdirde PostGRE'ler aynı ada sahip her iki alandan şikayet edecek ..
(PS Bunu çözerken burada biraz gözetleme yaptım: http://postgis.net/docs/manual-1.4/ch04.html )
Tracts özniteliklerine sahip yeni bir adres noktaları tablosu oluşturun: Not Her çıktı sütununa, hangi tabloda başladığını açıklayan bir ipucu ekliyorum (nedenini aşağıda açıklayacağım).
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);
PostGRE'lerin sorunsuz çalışmaya devam etmesi için tabloyu koruyun:
vacuum mcdon_addresses_wtract;
Şimdi iki sorum vardı ..
ST_Contains aslında işe yaradı mı? ..ve .. Döndürdüğüm adres sayısı kullandığım veri girişlerine göre anlamlı mı?
Her ikisi de aynı sorguyu kullanarak cevap vermeyi başardı:
select count(*) from mcdon_addresses_wtract;
-- returns 11848
Kayıplara hızlı bir bakış: İlk olarak, ArcGIS'de kontrol ettim (bunu QGIS'de de yapabilirsiniz) ve aynı sayıyı döndürdü. Peki, neden fark var? Birincisi, bazı adresler Missouri dışına düştü ve ben sadece bir Missouri traktör poligonu ile karşılaştırdım. İkincisi, daha yakın analizde, adres verilerinde kötü sayısallaştırmanın bazı örnekleri vardı. Özellikle, yakalanmayan noktaların ST_Containsçoğunun boş nitelik alanları vardı, bu da sayısallaştırma sırasında bir şeyin kötü gittiğinin iyi bir işaretidir; aynı zamanda yine de kullanılabilir veriler olmadığı anlamına gelir. Bu noktada, makul bir şekilde geri dönüp verileri geliştirebileceğimden, daha temiz bir analize izin verebileceğimden, farklılıklardan rahatım.
Devam ederken, bir sonraki adım, blok verilerinden özniteliklerle adres / yollar tablosunu eklemekti. Benzer şekilde, yeni bir tablo oluşturarak bunu yaptım, bir kez daha her çıktı alanına önek geldiğinden tabloyu belirtmek için (önek görmeniz oldukça önemlidir):
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);
Tabii ki, masayı koruyun:
vacuum mcdon_addr_trct_and_blk;
Her çıktı alanına ön ek oluşturmamın nedeni, eğer olmasaydım, bazı alanların aynı isimlere sahip olması ve bunları nihai üründe birbirinden ayırmak imkansız olurdu. ama adını değiştirdiğim için ona şans vermedim). Örneğin, yukarıdaki her iki adımda da aşağıdaki iki alanı ele alalım. Onları neden yeniden adlandırdığımı görebilirsiniz ..
t.pop90 AS tr_pop90 -- would have been simply pop90
b.pop90 AS blk_pop90 -- also would have been pop90 !
Artık izleri ve blokları veri kümesi olan bir adresimiz var, dwe hala aynı sayıda noktaya sahip mi?
select count(*) from mcdon_addr_trct_and_blk;
-- 11848 (thumbs up!)
Evet yaparız! İsterseniz, oluşturup ilk oluşturduğumuz tabloyu silebilirsiniz mcdon_addresses_wtract. Analiz için artık buna ihtiyacımız yok.
Son bir eylem olarak, olabilecek ArcGIS gibi, çok bir ESRI shape içine Postgres'e gelen verileri dışa Diğer programlarla görebilmesi istiyorum (notun, QGIS sorun olmadan PostGIS verilerini okuyabilir). İlgileniyorsanız, ogr2ogr kullanarak dönüşümü nasıl yapabileceğiniz aşağıda açıklanmıştır:
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"
Son olarak, bu komutu çalıştırdığınızda, muhtemelen şu gibi bazı uyarılar alırsınız:
Uyarı 6: Normalleştirilmiş / aklanan alan adı: 'tr_statefp10' - 'tr_statefp'
Bu sadece OGR'nin bu alan adını kısaltması gerektiği anlamına gelir, çünkü şekil dosyasındaki alan adı sadece çok uzun olabilir.
Tabii ki, bu işi başarmanın birçok yolundan sadece biri.
FCC'nin bir API'si vardır: http://www.fcc.gov/developer/census-block-conversions-api