Чи існує вільний чи дешевий спосіб кодування великої кількості адрес та повернення чи додавання уроку перепису та блокування даних?
Існує декілька способів геокодування адреси та отримання довгострокової ширини, але мені дійсно потрібно отримати трактування перепису та заблокувати дані.
Відповіді:
Ок Бен, ось мої припущення:
1) Ви вже отримали свої дані (у мене було декілька адресних точок у файлі форм, і я завантажив переписний тракт і форму перепису блоку перепису для Міссурі).
2) Ви вже зашифрували свої адресні точки і вам зручно проектувати дані.
3) Вам комфортно рішення OGR / PostGIS (обидва безкоштовні).
Ось кілька приміток про встановлення, якщо у вас немає цього програмного забезпечення: Як встановити PostGRE з підтримкою PostGIS . (За матеріалами BostonGIS. Будь ласка, не ображайтесь на їх назву, я просто думаю, що це найкращий спосіб роботи там.) Також, ось один , два та три сайти, що описують, як встановити GDAL / OGR з прив’язками Python.
Попередження : Перш ніж виконати фактичний аналіз (тобтоST_Containsматеріал, наведений нижче), ви повинні переконатися, що всі ваші шари знаходяться в одній проекції ! Якщо у вас є форм-файли, легко перевести з однієї проекції на іншу, використовуючи або Quantum GIS (QGIS), або OGR (або ArcGIS, якщо у вас є). Крім того, ви можете виконати перетворення проекції в базі даних за допомогою функцій PostGIS. В основному виберіть свою отруту або повідомте нам, чи це камінь спотикання.
З цими даними, ось як я додав тракт і блокував атрибути до деяких даних адресних точок за допомогою PostGIS:
Спочатку я ogr2ogrімпортував три формати файлів у PostGIS:
Імпортуйте адреси за допомогою 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
Імпорт перепису тракти (Міссурі) з використанням ogr2ogr:spMoWest суфікс означає , я вже переклав свої дані в Міссурі State Plane Вест 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
Імпорт блоку даних (Міссурі): цей час зайняв деякий час. Насправді мій комп'ютер постійно виходив з ладу, і мені довелося поставити на нього вентилятор! Так само, ogr2ogrне даватимуть жодних відгуків, тому не будьте виразними; переконайтеся, що зачекайте, і воно врешті закінчиться.
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
Після імпорту даних запустіть PgAdmin III (графічний інтерфейс PostGREs), перейдіть до вашої бази даних та киньте кілька команд швидкого обслуговування, щоб PostGREsql запустив швидше за допомогою цих нових даних:
vacuum mcdon_addresses;
vacuum mo_tracts_2010;
vacuum mo_blocks_2010;
Далі мені було цікаво, скільки необроблених адресних точок я імпортував, тому я швидко зробив COUNT(*). Я зазвичай роблю підрахунок на початку подібного завдання, щоб згодом підкріпитися для "перевірок здорового стану".
SELECT COUNT(*) FROM mcdon_addresses;
-- 11979
На наступному етапі я створив дві нові таблиці, поступово додаючи атрибути трактів, а потім атрибути блоків, до моєї оригінальної таблиці адресних точок. Як ви побачите, ST_Containsфункція PostGIS робила важкий підйом, в кожному випадку створюючи нову таблицю точок, кожен отримуючи атрибути полігонів трактів і блоків, до яких вони потрапляли.
Примітка! Для стислості я беру лише жменьку полів з кожного столу. Напевно, ви хочете майже все. Я кажу майже тому, що вам потрібно буде опустити ogr_fidполе (можливо, навіть інші?) З таблиць, які ви поєднуєте, інакше PostGRE буде скаржитися на те, що обидва поля мають однакову назву ..
(PS Я десь пробув тут, розгадуючи це: http://postgis.net/docs/manual-1.4/ch04.html )
Створіть нову таблицю адресних точок з атрибутами трактів: Примітка. Я прив'язую до кожного вихідного стовпця підказку, розкриваючи, у якій таблиці він почався (я поясню, чому нижче).
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 продовжував безперебійно працювати:
vacuum mcdon_addresses_wtract;
Тепер у мене було два питання ..
Чи реально працювали ST_Contains? ..і .. Чи має значення кількість повернених адрес з огляду на введені нами дані?
Я зміг відповісти на обидва, використовуючи один і той же запит:
select count(*) from mcdon_addresses_wtract;
-- returns 11848
Швидке роздуми про втрати: По-перше, я перевірив в ArcGIS (ви також можете це зробити в QGIS), і він повернув той самий підрахунок. Отже, чому різниця? По-перше, деякі адреси потрапили за межі Міссурі, і я порівняв лише проти полігону Міссурі. По-друге, при більш детальному аналізі, мабуть, було кілька прикладів поганої оцифровки даних даних. Зокрема, у багатьох пунктах, на які не потрапили ST_Containsпусті поля атрибутів, що є хорошим знаком, що під час оцифрування щось зіпсувалося; це також означає, що вони все одно не були корисними даними. На даний момент мені подобаються відмінності, оскільки я міг обґрунтовано повернутися назад та покращити дані, дозволяючи зробити більш чистий аналіз.
Перейшовши далі, наступним кроком було додавання таблиці адрес / трактів з атрибутами з даних блоків. Так само я зробив це, створивши нову таблицю, ще раз префіксуючи кожне вихідне поле, щоб вказати таблицю, з якої вона вийшла (префіксація є досить важливою, яку ви побачите):
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);
Звичайно, підтримуйте таблицю:
vacuum mcdon_addr_trct_and_blk;
Причиною я був встановити кожне вихідне поле, тому що якщо я цього не зробив, деякі поля мали б однакові назви, і неможливо було б їх відрізнити одне від одного в кінцевому продукті (також .. PostGRE, можливо, поскаржився на середину цього, але оскільки я перейменував, я не дав шансу). Розглянемо, наприклад, наступні два поля з обох кроків, наведених вище. Ви можете бачити, чому я перейменував їх.
t.pop90 AS tr_pop90 -- would have been simply pop90
b.pop90 AS blk_pop90 -- also would have been pop90 !
Тепер, коли у нас є адреси з набором даних про тракти і блоки, у dwe все ще однакова кількість балів?
select count(*) from mcdon_addr_trct_and_blk;
-- 11848 (thumbs up!)
Так ми робимо! Якщо ви хочете, ви можете піти далі і видалити першу таблицю , яку ми створили, mcdon_addresses_wtract. Нам це більше не потрібно для аналізу.
Як остання дія, ви можете експортувати свої дані з PostGRE в файл форм ESRI, щоб ви могли їх переглядати за допомогою інших програм, наприклад ArcGIS (примітка, QGIS може читати дані PostGIS без проблем). Якщо ви зацікавлені, ось як можна здійснити перетворення за допомогою 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"
Нарешті, запустивши цю команду, ви, ймовірно, отримаєте такі попередження:
Попередження 6: Нормалізована / відмита назва поля: 'tr_statefp10' до 'tr_statefp'
Це просто означає, що OGR довелося скоротити цю назву поля, оскільки ім'я поля у файлі форм може бути таким довгим.
Звичайно, це лише один із багатьох способів виконання цієї роботи.