Проблема: у меня есть поле адреса из базы данных Access, преобразованной в Sql Server 2005. В этом поле все в одном поле. Мне нужно разобрать отдельные разделы адреса в соответствующие поля в нормализованной таблице. Мне нужно сделать это примерно для 4000 записей, и это должно быть повторяемым.
Предположения:
Предположим, адрес в США (пока)
Предположим, что входная строка иногда будет содержать адресата (адресата) и / или второй почтовый адрес (например, Suite B)
состояния могут быть сокращены
почтовый индекс может быть стандартным 5-значным или zip + 4
в некоторых случаях есть опечатки
ОБНОВЛЕНИЕ: в ответ на поставленные вопросы стандарты не соблюдались повсеместно, мне нужно сохранить отдельные значения, а не только геокодирование, а ошибки означают опечатку (исправлено выше)
Образец данных:
AP Croll & Son 2299 Lewes-Georgetown Hwy, Джорджтаун, DE 19947
11522 Shawnee Road, Greenwood DE 19950
144 Kings Highway, SW Dover, DE 19901
Встроенный Const. Услуги 2 Penns Way Suite 405 New Castle, DE 19720
Humes Realty 33 Bridle Ridge Court, Льюис, DE 19958
Николс Раскопки 2742 Pulaski Hwy Newark, DE 19711
2284 Bryn Zion Road, Смирна, DE 19904
VEI Dover Crossroads, LLC 1500 Serpentine Road, Suite 100 Baltimore MD 21
580 North Dupont Highway Dover, DE 19901
PO Box 778 Dover, DE 19903
источник
Ответы:
Я проделал много работы над таким анализом. Поскольку есть ошибки, вы не получите стопроцентной точности, но есть несколько вещей, которые вы можете сделать, чтобы добиться большего, а затем провести визуальный BS-тест. Вот общий способ сделать это. Это не код, потому что писать его довольно академично, в нем нет ничего странного, просто много обработки строк.
(Теперь, когда вы разместили несколько примеров данных, я внес небольшие изменения)
Надеюсь, это поможет несколько.
источник
Я думаю, что лучше всего передать эту проблему на аутсорсинг: отправить ее в геокодер Google (или Yahoo). Геокодер возвращает не только широту и долготу (которые здесь не представляют интереса), но и подробный анализ адреса с заполненными полями, которые вы не отправляли (включая ZIP + 4 и округ).
Например, анализ "1600 Amphitheatre Parkway, Mountain View, CA" дает
Теперь это можно разобрать!
источник
Первоначальный плакат, вероятно, давно перешел, но я попытался портировать модуль Perl Geo :: StreetAddress: US, используемый geocoder.us, на C #, сбросил его на CodePlex и подумал, что люди, которые в будущем могут столкнуться с этим вопросом, могут считаю полезным:
Парсер адресов США
На домашней странице проекта я пытаюсь рассказать о его (вполне реальных) ограничениях. Поскольку он не поддерживается базой данных действительных уличных адресов USPS, синтаксический анализ может быть неоднозначным, и он не может подтвердить или опровергнуть действительность данного адреса. Он может просто попытаться вытащить данные из строки.
Он предназначен для случая, когда вам нужно получить набор данных в основном в правильных полях или вы хотите предоставить ярлык для ввода данных (позволяя пользователям вставлять адрес в текстовое поле, а не переходить между несколькими полями). Он не предназначен для проверки возможности доставки адреса.
Он не пытается анализировать что-либо выше линии улицы, но, вероятно, можно было бы поиграть с регулярным выражением, чтобы получить что-то достаточно близкое - я бы, вероятно, просто сломал его по номеру дома.
источник
SmartyStreets имеет новую функцию, которая извлекает адреса из произвольных входных строк. (Примечание: я не работаю в SmartyStreets.)
Он успешно извлек все адреса из образца ввода, указанного в вопросе выше. (Кстати, действительны только 9 из этих 10 адресов.)
Вот некоторые из результатов:
А вот результат того же запроса в формате CSV:
Я был разработчиком, который изначально написал сервис. Реализованный нами алгоритм немного отличается от любых конкретных ответов здесь, но каждый извлеченный адрес проверяется на соответствие API поиска адресов, поэтому вы можете быть уверены, действителен он или нет. Каждый проверенный результат гарантирован, но мы знаем, что другие результаты не будут идеальными, потому что, как было ясно показано в этом потоке, адреса непредсказуемы, даже иногда для людей.
источник
Я делал это раньше.
Либо сделайте это вручную (создайте красивый графический интерфейс, который поможет пользователю сделать это быстро), либо автоматизируйте его и сверьте с недавней базой данных адресов (вы должны ее купить) и вручную обрабатывать ошибки.
Ручная обработка займет около 10 секунд каждая, то есть вы можете сделать 3600/10 = 360 в час, так что 4000 займет у вас примерно 11-12 часов. Это даст вам высокую точность.
Для автоматизации вам понадобится последняя база данных адресов в США и скорректируйте свои правила в соответствии с ней. Я предлагаю не увлекаться регулярным выражением (сложно поддерживать долгое время, так много исключений). Сделайте 90% совпадения с базой данных, остальное сделайте вручную.
Получите копию Стандартов почтовой адресации (USPS) по адресу http://pe.usps.gov/cpim/ftp/pubs/Pub28/pub28.pdf и обратите внимание, что в нем более 130 страниц. Реализация регулярных выражений была бы безумием.
Для международных адресов все ставки отключены. Работники из США не смогут подтвердить.
Как вариант, воспользуйтесь услугой передачи данных. Однако у меня нет рекомендаций.
Более того: когда вы все-таки отправляете материал по почте (это для чего, верно?), Убедитесь, что вы поместили «запрошено исправление адреса» на конверте (в нужном месте) и обновите базу данных. (Мы сделали простой графический интерфейс для этого сотрудника на стойке регистрации; человека, который на самом деле сортирует почту)
Наконец, когда вы очистили данные, ищите дубликаты.
источник
После приведенного здесь совета я разработал следующую функцию в VB, которая создает приемлемые, хотя и не всегда идеальные (если указаны название компании и строка набора, она объединяет набор и город) пригодные для использования данные. Не стесняйтесь комментировать / рефакторировать / кричать на меня за нарушение одного из моих собственных правил и т. Д .:
При передаче
parseAddress
функции «AP Croll & Son 2299 Lewes-Georgetown Hwy, Georgetown, DE 19947» возвращается:источник
Я работаю в области обработки адресов около 5 лет, и серебряной пули действительно нет. Правильное решение будет зависеть от ценности данных. Если это не очень ценно, пропустите его через синтаксический анализатор, как предлагают другие ответы. Если это хоть сколько-нибудь ценно, вам обязательно нужно, чтобы человек оценил / исправил все результаты парсера. Если вы ищете полностью автоматизированное, повторяемое решение, вы, вероятно, захотите поговорить с поставщиком коррекции адреса, таким как Group1 или Trillium.
источник
Хорошее предложение, в качестве альтернативы вы можете выполнить запрос CURL для каждого адреса в Google Maps, и он вернет правильно отформатированный адрес. Исходя из этого, вы можете использовать регулярное выражение, сколько душе угодно.
источник
+1 к предложенному Джеймсом А. Розену решению, так как оно хорошо сработало для меня, однако для комплементов этот сайт - увлекательное чтение и лучшая попытка, которую я видел в документировании адресов по всему миру: http://www.columbia.edu/kermit /postal.html
источник
Существуют ли вообще какие-либо стандарты в отношении записи адресов? Например:
Мой общий ответ - это серия регулярных выражений, хотя сложность этого зависит от ответа. И если нет никакой согласованности, то вы сможете достичь только частичного успеха с помощью Regex (то есть: отфильтровать почтовый индекс и состояние), а все остальное придется делать вручную (или, по крайней мере, пройти остальное очень внимательно, чтобы убедиться, что вы заметили ошибки).
источник
Еще один запрос на демонстрационные данные.
Как уже упоминалось, я бы работал в обратном направлении от застежки-молнии.
Как только у вас есть zip, я бы запросил базу данных zip, сохранил результаты и удалил их и zip из строки.
Это оставит вас с беспорядком с адресами. БОЛЬШИНСТВО (все?) Адресов будут начинаться с числа, поэтому найдите первое вхождение числа в оставшейся строке и возьмите все от него до (нового) конца строки. Это будет ваш адрес. Все, что находится слева от этого числа, скорее всего, является адресатом.
Теперь у вас должны быть сохранены City, State и Zip в таблице и, возможно, две строки, адресат и адрес. Чтобы узнать адрес, проверьте наличие "Suite" или "Apt." и т.д. и разделите это на два значения (адресные строки 1 и 2).
Что касается адресата, я бы взял последнее слово этой строки в качестве фамилии и поместил бы остальное в поле имени. Если вы не хотите этого делать, вам нужно сначала проверить приветствие (мистер, мисс, доктор и т. Д.) И сделать некоторые предположения на основе количества пробелов относительно того, как имя выдумал.
Я не думаю, что есть способ выполнить синтаксический анализ со 100% точностью.
источник
Попробуйте www.address-parser.com . Мы используем их веб-сервис, который вы можете протестировать онлайн.
источник
На основе выборочных данных:
Я бы начал с конца строки. Разберите почтовый индекс (в любом формате). Прочтите от конца до первого пробела. Если почтовый индекс не найден Ошибка.
Обрежьте конец для пробелов и специальных символов (запятых)
Затем перейдите к State, снова используйте пробел в качестве разделителя. Возможно, используйте список поиска для проверки двухбуквенных кодов штатов и полных имен штатов. Если действительное состояние не найдено, ошибка.
Снова обрезайте пробелы и запятые с конца.
Город становится сложным, я бы на самом деле использовал здесь запятую, чтобы не получить слишком много данных в городе. Найдите запятую или начало строки.
Если у вас все еще остались символы в строке, запихните все это в поле адреса.
Это не идеально, но должно быть неплохой отправной точкой.
источник
Если это данные, введенные человеком, вы потратите слишком много времени, пытаясь обойти исключения.
Пытаться:
Регулярное выражение для извлечения почтового индекса
Поиск по почтовому индексу (через соответствующую государственную базу данных) для получения правильного адреса
Найдите стажера, чтобы вручную проверить соответствие новых данных старым.
источник
Это не решит вашу проблему, но если вам нужны только данные широты и долготы для этих адресов, API Карт Google довольно хорошо проанализирует неформатированные адреса.
источник
RecogniContact - это COM-объект Windows, который анализирует адреса в США и Европе. Вы можете попробовать это прямо на http://www.loquisoft.com/index.php?page=8
источник
Возможно, вы захотите это проверить !! http://jgeocoder.sourceforge.net/parser.html Сработал для меня как шарм.
источник
Проблемы такого типа трудно решить из-за неоднозначности данных.
Вот решение на основе Perl, которое определяет дерево грамматики рекурсивного спуска на основе регулярных выражений для анализа многих допустимых комбинаций уличных адресов: http://search.cpan.org/~kimryan/Lingua-EN-AddressParse-1.20/lib/Lingua /EN/AddressParse.pm . Сюда входят вспомогательные свойства в пределах адреса, например: 12 1st Avenue N Suite # 2 Somewhere CA 12345 USA
Он похож на http://search.cpan.org/~timb/Geo-StreetAddress-US-1.03/US.pm, упомянутый выше, но также работает для адресов не из США, таких как Великобритания, Австралия и Канада.
Вот результат для одного из ваших примеров адресов. Обратите внимание, что раздел имени необходимо сначала удалить из "AP Croll & Son 2299 Lewes-Georgetown Hwy, Georgetown, DE 19947", чтобы уменьшить его до "2299 Lewes-Georgetown Hwy, Georgetown, DE 19947". Этого легко добиться, удалив все данные до первого числа, найденного в строке.
источник
Поскольку есть вероятность ошибки в слове, подумайте об использовании SOUNDEX в сочетании с алгоритмом LCS для сравнения строк, это очень поможет!
источник
используя Google API
источник
Для разработчиков ruby или rails доступен прекрасный гем под названием street_address . Я использовал его в одном из своих проектов, и он выполняет нужную мне работу.
Единственная проблема, с которой я столкнулся, заключалась в том, что всякий раз, когда адрес был в этом формате,
P. O. Box 1410 Durham, NC 27702
он возвращал ноль, и поэтому мне пришлось заменить «Почтовый ящик» на «», и после этого он смог его проанализировать.источник
Есть службы передачи данных, которые по почтовому индексу предоставят вам список названий улиц в этом почтовом индексе.
Используйте регулярное выражение для извлечения Zip или City State - найдите правильный или, если ошибка, получите оба. извлеките список улиц из источника данных. Исправьте город и штат, а затем адрес. Как только вы получите действительную строку адреса 1, город, штат и почтовый индекс, вы можете сделать предположения по адресной строке 2..3.
источник
Я не знаю, НАСКОЛЬКО это было бы РЕАЛЬНО, но я не видел, чтобы об этом упоминалось, поэтому я решил пойти дальше и предложить следующее:
Если вы находитесь строго в США ... получите огромную базу данных со всеми почтовыми индексами, штатами, городами и улицами. Теперь поищите их в своих адресах. Вы можете проверить то, что вы нашли, проверив, существует ли, скажем, найденный вами город в найденном вами штате, или проверив, существует ли найденная вами улица в найденном вами городе. В противном случае, скорее всего, Джон не на улице Джона, но это имя адресата ... В общем, получите как можно больше информации и сравните с ней свои адреса. В качестве крайнего примера можно получить СПИСОК ВСЕХ АДРЕСОВ В США A, а затем найти, какой из них наиболее соответствует каждому из ваших адресов ...
источник
Существует порт javascript для пакета perl Geo :: StreetAddress :: US: https://github.com/hassansin/parse-address . Он основан на регулярных выражениях и работает довольно хорошо.
источник