Крупномасштабное геокодирование и обработка в ESRI


9

Итак, я думаю, что это неформальный запрос / опрос о том, какие большие наборы данных вы используете в своих мирах ESRI ...

Я создаю и поддерживаю набор данных в масштабе штата, где мне нужно обрабатывать данные до уровня отдельных домов, а не уровень посылки, но несколько почтовых адресов для одной посылки для наших систем. Во многих местах я использую теоретические адреса, рассчитанные по данным уличной сети или USMS AMS / AIS. Таким образом, мой список адресов составляет примерно 13,5 миллионов адресов и растет ежемесячно или ежеквартально.

Есть ли кто-нибудь прямо сейчас, поддерживающий живую систему адресации / правильного поиска информации, которая настолько велика в непрерывном наборе данных?

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

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

[Дальше]

Мне интересно знать, что делают другие люди, чтобы оптимизировать свои процессы для работы с этими наборами данных. Я собираюсь добавлять несколько миллионов записей в месяц в будущем, и хотя геокодирование и т. Д. Не является проблемой, когда вы запускаете другие процессы и связываете данные для дальнейшего анализа, вы начинаете работать со сложными объединениями. Ну, вы выводите данные из Intersects / Overlays / Identities, используя Only_FID, и вы получаете тонкую среднюю таблицу для присоединения; но когда вы начинаете пытаться разделить и победить создание этой таблицы, вы начинаете сталкиваться с проблемами, когда вам нужно разделить ваши исходные данные на рабочие области, но тогда у вас есть повторяющиеся IDS, которые вы не можете объединить обратно; таким образом, у вас остаются меньшие блоки данных, которые вы не можете легко восстановить целиком.

Думая об опциях, которые разбивают данные до масштаба по округам, затем используют пространственные представления, чтобы объединить их вместе и т. Д. Просто любопытно, смотрят ли другие пользователи на такие же проблемы в таком большом масштабе, но в небольшом следы.


3
60 миллионов адресов, геокодированных в Oracle Spatial (11g) ArcSDE и визуализированных в ArcGIS и Web App (Internal). Речь идет не о геокодированном адресе, а о нечетких ( несовпадающих
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-Jonathan
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.