Геокодування та обробка великих масштабів в ESRI


9

Гаразд, тому я гадаю, що це неформальний запит / опитування щодо того, наскільки великі набори даних ви використовуєте у своїх ESRI світах ...

Я будую та підтримую загальнодержавний набір даних, де я повинен обробляти до рівня індивідуального будинку, не рівень посилки, але кілька поштових адрес на посилку для наших систем. У багатьох місцях я використовую теоретичні адреси, обчислені з даних вуличної мережі або даних USPS AMS / AIS. Тож мій список адрес становить приблизно 13,5 мільйонів адрес і зростає щомісяця або щоквартально.

Хтось там зараз підтримує живу систему адрес / правильно шукає інформацію, яка така велика в безперервному наборі даних?

Я хотів би співпрацювати або поговорити більше про те, як інші обробляють такий великий набір даних. Я бачу проблеми, коли програмне забезпечення ESRI, здається, розгорається, коли я намагаюся виконувати такі завдання, як перехрестя або просторове з'єднання. ESRI каже, що вони не бачать подібних проблем, але у мене виникли ці проблеми з 9.3.1, тому я не можу бути першою / єдиною особою, яка робить це, оскільки можу відтворити це на багатьох машинах.

Моєю платформою зараз є ESRI ArcGIS 10 на робочому столі, розмовляючи з ArcSDE 9.3.1-sp1 на бекенді SQL2008 за допомогою просторового об’єкта GEOMETRY. Тому я не роблю нічого по-справжньому екзотичного; але все ж мені здається, що в деяких районах я, можливо, штовхаю конверт.

[Далі]

Мені цікаво знати, що інші люди роблять для оптимізації процесів роботи з цими наборами даних. Я буду додавати слова мільйона записів щомісяця вперед, і хоча геокодування тощо не є проблемою, коли ви починаєте виконувати інші процеси та зв'язувати дані для подальшого аналізу, ви починаєте займатися складними приєднаннями. Ну, ви виводите дані з перетину / перекриттів / ідентифікацій за допомогою Only_FID, і ви отримуєте тонку середню таблицю, щоб також приєднатися; але коли ви починаєте намагатися розділити та підкорити створення цієї таблиці, ви починаєте стикатися з проблемами, де потрібно розділити вихідні дані на робочі області, але потім у вас повторюється IDS, що ви не можете злитися назад; тож вам залишаються менші блоки даних, які ви не зможете легко скласти знову цілими.

Роздумуючи над параметрами, які розбивають дані до масштабу округу за округом, а потім використовуйте просторові подання, щоб об’єднати їх назад і т. Д. Просто цікаво, якщо інші користувачі дивляться на такі ж проблеми в такому масштабі, але в малому сліди.


3
60 мільйонів адрес геокодовано в просторовій (11 г) ArcSDE та візуалізовано в ArcGIS та веб-додатках (внутрішній). Мова не про геокодовану адресу, але нечітку (неправильно відповідні адреси). Це хороший посібник scdhec.gov/gis/presentations/ESRI_Conference_08/tws/workshops/…
Mapperz

Я згоден, геокодування ніколи не було проблемою. Моя проблема виникає, коли у вас є настільки великий набір даних, що вам потрібно мати процес безперервної роботи, що інші процеси стають дуже складними. Функції / завдання, такі як "Перехрестя", "Простір-з'єднання" тощо, де вам потрібно приєднатись до інших даних у високо нормалізованому середовищі для моделювання.
DEWright

Чи індексуються ваші просторові дані? Згідно з документами, SQL Server використовує індекси B-Tree. Спробуйте завантажити дані в базу даних PostGIS з індексами GIST та порівняйте продуктивність. Це скаже вам, чи це проблема SQL Server.
Шон

Немає проблем з подібними речами, але в цілому я бачу те, що коли ти маєш справу з такою кількістю точок і виконуєш глибокі функції, які так довго працюють, ти дивишся на шляхи їх оптимізації. Мені цікаво, чим займаються інші великі користувачі.
DEWright

Якщо питання в тому, що це відкрите, воно повинно перефразовуватись та робити вікі спільноти.
Шон

Відповіді:


1

Оскільки це (старе) відкрите запитання, я дам вам відкриту відповідь: Правильне використання бази даних може економити величезну кількість часу. Очевидний спосіб зробити щось не обов’язково найшвидший, наприклад, коли я нещодавно хотів видалити багато рядків з Oracle, виявляється, що просто надсилання: delete from TABLE1 where ID = 123для кожної функції було надзвичайно повільно, і що я можу зробити деякі модні речі Oracle. щоб швидше зробити це на порядок .

Отже, якщо ви виявите конкретну проблему, яка є вузьким місцем, поставте експертам конкретне питання, що стосується цього вузького місця. Тож для сторони ArcGIS, яка, можливо, буде тут (або форуми ESRI, або ваша підтримка ESRI), але для питання, пов’язаного з базою даних (і все зазвичай буде швидше, якщо ви їх зробите там), ви хочете запитати на http : //www.stackoverflow.com


Не так багато відкритого закінчилося; але шукати більше кращих теоретичних способів вирішення цієї теми. На моєму останньому шляху я побудував свою власну логіку нечіткого пошуку, щоб поговорити з власною БД SQL2008. Усунення залежності від двигуна ESRI покладається на добре налаштований індекс, щоб спробувати зробити це швидше. Оскільки ми не можемо знати достатньо про внутрішні системи двигунів BING або Google, ми можемо лише припускати, що вони будуть використовувати там власну дрібну логіку.
DEWright

Ви можете з’ясувати досить багато закулісних частей Google із наукових робіт - research.google.com/pubs/papers.html
GIS-Джонатан
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.