0
- 08.08.2012 - 19:36
|
Здравствуйте, друзья! Прошу, так сказать совета или помощи, ну или хотя бы подскажите(ткните носом) в какую область смотреть. Задача заключается в следующем: все хорошо знают что почти за каждым почтовым адресом закреплен почтовый индекс. В Интернете много сайтов, на которых можно ввести свой адрес и узнать свой почтовый индекс. Существуют и базы этих индексов, в данном случае в DBF какой-то налоговой службы или органа (уж не знаю как назвать). То есть в этой базе четко расписаны все названия краев, областей и т.д., населенных пунктов, районов, улиц, номера домов (в основном в диапазонах). Так вот в общем каждой такой строке с названием (края или города или улицы..или..) соответствует уникальный код, ну и для нескольких улиц или даже улицы с населенным пунктом может соответствовать один почтовый индекс. ПРО БАЗУ ДАННЫХ ЭТО К СВЕДЕНИЮ. Непосредственная цель: на входе адрес, введенный в формате(край, субъект(район и т.п.), Населенный пункт(город, село, станица), Улица, Номер дома) - это все строки, введенные "человеком" (подразумевает, что в основном все написано "через одно место" - с ошибками (например Краснодар - КРАСНДР, Г.КРАСНОДАР, КАСНОДАР.Г, Октябрьская - АКТЯБРЬСКАЯ, ОКТЯБЫРЬСКАЯ) - в общем надеюсь понимаете). На выходе должен быть ПОЧТОВЫЙ индекс распознанный из этих каракуль. То есть получается нужно производить анализ каждого адреса на соответствие тому что в БД. Как вообще быть и с чего начать???? А то в поисковиках натыкаюсь лишь на синтаксические анализаторы, синтез речи, распознавание текста с картинки. Хотелось бы услышать идеи по этому поводу! ЗАРАНЕЕ ВСЕМ ОГРОМНОЕ СПАСИБО!!! | |
1
- 08.08.2012 - 20:42
| 1. в форме сделать выпадающий список (город/улица) | |
2
- 08.08.2012 - 20:50
| 2. список получить по полю из БД, с которой будет вестись выборка по условиям (адресу) | |
3
- 08.08.2012 - 21:06
| Да не. На входе то, что уже так сказать введено, но оно введено криво и вот считай нужно распознать из готовой БД. | |
4
- 08.08.2012 - 21:08
| brezhnev, ты наверное подумал что мне самому нужно адрес вводить, но нет. Но все равно спасибо! | |
5
- 08.08.2012 - 22:04
| а не проще копать в сторону проверки орфографии, если пользователь написал с ошибками, сообщить ему об этом, предложить список похожих слов, а потом достать из базы нужные данные, по проверке орфографии алгоритмы в сети попадаются. | |
6
- 09.08.2012 - 05:06
| Товарищ в п. 5 истину глаголет, либо поиск по N-граммам тебя спасет. Вопрос в том, стоит ли стрелять из пушки по воробьям. | |
7
- 09.08.2012 - 06:24
| С пользователем никакого взаимодействия не происходит. Этот некий плохой человек или несколько людей уже занесли в свою БД для людей "кривые адреса". Так вот мне нужно их брать и распознавать. Ну там конечно такие ошибки попадаются, что и анализатор сломается)))) | |
8
- 09.08.2012 - 09:24
|
(0) Слишком много текста в топике единственное что понял это видимо автор не знаком с такой вещью как КЛАДР http://www.gnivc.ru/inf_provision/cl...ference/kladr/ Посмотри как это сделано в любой 1С | |
9
- 09.08.2012 - 11:26
| ))) Как раз таки знаком и использую сейчас. Но задача не в том чтобы для пользователя который заносит адрес создать программулину, которая позволит из выпадающего списка все это добро выбирать, а том чтобы распознать уже введенный корявый адрес. | |
10
- 09.08.2012 - 22:02
| Может кто-нибудь слышал и применял Расстояние Левенштейна???? | |
11
- 11.08.2012 - 10:30
|
Одним алгоритмом Левенштейна вы не обойдетесь. Например, между строками "Краснодар" и "Крансодар" классический алгоритм Лев-на покажет разницу 2, а между "г. Краснодар" и "КРАСНОДАР г." разница будет 12 (больше, чем между "Краснодаром" и "Москвой"). Чтобы решить задачу, нужно видеть вашу БД. Скажем, данные, введенные вручную, отличается от данных, полученных при сканировании и распознавании документов (содержат другие виды ошибок). Можно попробовать максимально упростить названия в обеих базах, при этои постараться не потерять характерные черты названий, позволяющие отличить один населенный пункт от другого. Обрабатываем базу с ошибками: 1. Если данные были получаны при сканировании, то меняем латинские буквы на аналогичные кириллические. 2. Переводим строки в нижний регистр. 3. Меняем "ё" на "е", "ъ" на "ь", "щ" на "ш" и т.д. Удаляем сдвоенные согласные. 5. Удаляем кавычки, меняем дефисы и тире на пробелы (также можно попробовать вообще удалить, не оставляя пробелов). 6. С помощью регулярных выражений находим приписки "р-н", "район", "г.", "город", "ст.", "ст-ца", "пгт.", "пос.", "поселок" и присваиваем строке соответствующее свойство: район, город, пгт, станица, поселок, село, хутор. Затем удаляем приписки, чтобы они нам не мешали. 7. Удаляем все гласные буквы на слове, но оставляем гласные в окончании. Т.е. превращаем "краснодар" в "крсндр", "октябрьская" - в "ктбрьская", "темрюк" - в "тмрк". Окончания нужны, чтобы отличать станицу "Октябрьская" от поселка "Октябрьский" в том случае, если не было приписок "ст-ца" и "поселок". Для определения окончаний используем стеммер Портера. 8. Аналогичные действия проводим на эталонной базе, в которой содержатся правильные названия населенных пунктов и их индексы. Смотрим, сколько населенных пунктов стали дублироваться. Если дублей много (3 - 5%), то убираем лишнюю обработку, делаем упрощение названий менее жестким. Создаем хеш (словарь) вида: "крсндр"{полное название**= г. Краснодар "крсндр"{тип населенного пункта**=город "крсндр"{индекс**=1213213213 9. Перебираем обрезанные названия в каждой базе и рассчитываем похожесть строк. Здесь как раз можно применить алгоритм Левенштейна, он поможет узнать "крсндр" в строке "ксрндр". Только применяем с ограничениями: если строка состоит из 5 - 8 символов, то используем максимальный допуск = 2, если более 8 - 12 символов, то допуск = 3 - 4 (в длинных названиях люди допускают больше ошибок). Также можно вместо пункта 7 можно попробовать использовать фонетические алгоритмы (soundex и подобные). Важно понимать, что ни один алгоритм не решит вашу задачу на 100% точно. Задача программиста в том, чтобы подобрать последовательность действий, при которой количество ошибок будет минимизировано, а результат - наилучшим. | |
12
- 12.08.2012 - 21:51
| Благодарю! Попробую все сделать как вы описали. Интересный план!!! | |
13
- 02.11.2012 - 17:51
| Действительно, пушкой по воробьям. Если адрес вводился по какой-нибудь схеме (индекс, страна, край и т.д.), то можно его пропарсить и получить отдельные части адресов. Потом проверяем полученные данные на соответствие КЛАДРу и в итоге получаем кучку (кучу) не найденных элементов. Выводим на экран небольшой диалог с таблицей, в которой напротив каждого косячного элемента можно проставить правильный из КЛАДРа. После сопоставления элементов меняем их в тех адресах, в которых мы их ранее нашли. В итоге вместо исправления сотни тысяч миллионов ошибочно введенных "КраснАдар" нам нужно всего лишь однажды его изменить и заменить в той самой сотни тысяч миллионов адресов. | |
14
- 04.11.2012 - 11:52
| Читайте классиков: http://deepmemo.com/pg/blog/vanuwa/read/227201/ | |
15
- 05.11.2012 - 10:29
|
archimag, этот подход работает в теории, но для сабжевой задачи он, скорее всего, неприменим. В статье предлагается использовать частотный словарь и учет редакторского расстояния. Возьмем частотный словарь. Он делается по некой базе книг. Чем чаще слово встречается в книгах, тем больший оно имеет "вес". Но для проверки фамилий и топонимов такой подход неприменим. Алгоритм просто заменит слово "станица" на "страница", потому что второе слово имеет больший вес. Редакторское же расстояние оценивается достаточно тупо: просто берется удаление, перестановка, замена, вставка буквы. Причем, любой буквы и в любом месте. Но люди в большинстве случаев совершают вполне характерые ошибки. Например, мало кто напишет "Йраснодар" - эту ошибку сразу видно. Оператор гораздо чаще ошибается внутри слова: "Крансодар", "Красодар". То есть наиболее характерны перестановки и удаления букв внутри слова. Также люди часто промахиваются мимо одной буквы на клавиатуре и попадают по соседней. У FineReader'а тоже есть несколько характерных ошибок, связанных с визуальной "похожестью" некоторых букв. Эти моменты, как и многие другие, в статье не учитываются. | |
16
- 05.11.2012 - 10:36
|
Приведу пример из реального проекта. В базе данных есть классификатор, в котором 100 тысяч фраз (ключей второго уровня): спасатель о приемке выполненных работ для лица, желающего выполнять обязанности общественного исполнение бюджетов и контроль о результатах инвентаризации Управление ветеринарии участие в выборах иностранных граждан конкурс "Лучшие предприниматели" и т.д. Эти фразы составители БД придумывали и вводили вручную. Но так как БД разрабатывается одновременно во всех регионах России (с достаточно редкой синхронизацией данных), в классификаторе сразу стали появляться дубли фраз с различными отличиями: конкурс "Лучший инновационный проект" конкурс на лучший инновационный проект //добавлен предлог "на", убраны кавычки на приобретение земельных участков на приобретение земельного участка //изменены окончания о результатах служебной проверки по результатам служебной проверки //другой предлог, изменено окончание бюджетные инвестиции автономным и бюджетным учреждениям бюджетные инвестиции бюджетным и автономным учреждениям //изменен порядок слов плата за пользование информацион. ресурсами плата за пользование информационными ресурсами //слово сокращено больного острым инфарктом миокарда больного с острым инфарктом миокарда //добавлен предлог обжалование результатов порядка проведения конкурса обжалование результатов, порядка проведения конкурса //пропущена запятая регистрация потребительского кооператива (общества) регистрация потребительского кооператива, общества //отличия в знаках препинания Лицензионная палата лицензионная палата //изменен регистр конкурс "Лучшие предприниматели" конкурсы на лучшего предпринимателя //замечаете, что смысл фраз одинаковый, но отличий много? и так далее. Все ключи проходили проверку орфографии, т.е. ошибок в них нет. Но есть дубли, задача которые отловить. Алгоритм Левенштейна нашел 114 дублей, работал около часа, чистота лога была около 30%. После применения скрипта приходилось целый час разбирать лог вручную. Адгоритим Л-на просто не отловливает перестановку слов, изменение окончаний в нескольких словах - слишком большое редакторское расстояние получается. А при увеличении редакторского расстояния увеличивается процент шума и лишних данных в логах. Пришлось написать свой алгоримт, заточенный именно под эту задачу: http://smotr.im/8Jwa Новый алгоритм нашел еще 540 дублей (уже после Лев-на), при этом работал 5 минут (т.е. на порядок быстрее) и чистота лога была 95 - 97%, практически ничего лишнего. Я всё к тому, что "в лоб", одним алгоритмом такие задачи не решаются, нужен комплексный подход. | |
17
- 05.11.2012 - 11:37
|
13) ACKEP, ваш вариант (переложить исправление на оператора) хорош, если объемы редактируемой базы позволяют использовать ручную работу и если есть база данных с правильными названиями. А если такой базы данных нет? Представьте, что у вас есть документы - например, кадастровые паспорты всех земельных участков Республики Адыгеи. С перечислением всех аулов, улиц а также адыгейских фамилий лиц, в пользу которых установлены обременения. В распознанном виде - около 100 Мб текста. На 1 Кб текста - до 50 опечаток, самых разнообразных. Вам нужно найти ошибки в тексте и цифрах, без словаря. В вашем подчинении один оператор и неделя времени. Здесь есть над чем подумать. | |
18
- 05.11.2012 - 11:47
| 17-Suppir > Конечно соглашусь - мой вариант очень узкий и ограниченный. Но, глядя со своей колокольни, под мои объемы данных он вполне себе применим. Автор же не указал конкретно масштабы задачи. Вот и подумал, что смогу быть полезным :-) | |
19
- 07.11.2012 - 21:22
|
Делал такое. Перенос базы данных от собеса в медицину. Получилось очень хорошо. 1 берется официальный список улиц. 2 фио разбивается на Ф И О. 3 выполняется нечеткий поиск используется библа HyperString а в ней function Similar(const S1,S2:Ansistring):Integer; Ищем Ф, если Similar < 80 то считаем что ошибка иначе ищем И,... И скорость, и точность были отличны. Удалось найти странную женщину Варвара Кучеренко. Это оказался некий сын гор по имени Парвар, вступивший в брак с дамой Кучеренко. Взял ее фамилию. Получился Парвар Кучеренко. Долгое время он был загадкой. А всякие прочие алгоритмы оказались совершенно непригодны. Хорошо работал алгоритм Русский Метафон, но он для другой ситуации. function compare(a,b:string):real; Неполный список проверенных алгоритмов begin //проверенные, но плохие методы // result:=posVIA2grm(a,b); //33 // result:=VIAinv(a,b); //33 // result:=VIA2grm(a,b); //33 // result:=IndistinctMatching2(a,b); //11MS!!! // result:=IndistinctMatching(2,a,b); //2:853mks on 11 3:1200 4:1500 result:=0.01*similar(a,b); // result:=1-dist(a,b)/max(length(a),length(b)); Множество других, но совсем никудышних не приведено. Это всякие красивые тля теории, а не жизни. Или для очень специфичных задач. Например складывать из кусков ДНК исходную молекулу. | |
20
- 08.11.2012 - 20:14
| главное что бы не получилось как в яндыксовском поисковике , вставляешь слово а его нет в базе и он автоматом изменяет слово на то что есть , но оно то не верно . | |
21
- 18.01.2013 - 00:45
|
Если в базе нет близкого - выдать сообщение со списом самых похожих и предложить выбрать из них или ввести свой вариант. А кто может знать, то слово или не то? Разве что господь бог. | |
22
- 25.01.2013 - 22:38
| мош regex поможет как-то? | |
23
- 30.01.2013 - 14:47
| Задача специфична тупостью операторов, вводивших эти данные, и тупостью создателей КЛАДР, которые в полной мере не учитывают особенности российской почтовой адресации. К сожалению, на практике без помощи человечка, который бы разбирал все неправильные адреса и помечал, какие можно автоматом обрабатывать а какие нет, не обойтись, господа! | |
24
- 31.01.2013 - 14:25
|
Вот, что получилось при решении подобной задачи по вытягиванию данных из КЛАДР по адресной строке на T-SQL (работает не иделально конечно, но пользователей в целом устраивает) с допущением, что адреса в основном в Ростовской области: --Разбивает адрес ALTER PROCEDURE [dbo].[SplitAdress](@Adress varchar(100), @idRegion int out, @idRayon int out, @idTown int out, @idStreet int out, @House varchar(10) out, @Korpus varchar(10) out, @Apartament varchar(10) out) AS --Разбитие адреса declare @oAdress varchar(100) set @oAdress=@Adress if @Adress like 'РОСТОВСКАЯ%' set @Adress=replace(@Adress, 'РОСТОВСКАЯ','РО') --Ориентировочное извлечение региона Declare @minPosReg int Select @minPosReg=MIN(Position) FROM (SELECT idRegion, CHARINDEX(vcName, @Adress) AS Position FROM dbo.tbRegion WHERE (CHARINDEX(vcName, @Adress) <> 0) AND len(vcName)>1 GROUP BY idRegion, vcName) Tbl Declare @mLenReg int Select @mLenReg= MAX(lenstr) FROM (SELECT idRegion, LEN(vcName) AS lenstr FROM dbo.tbRegion WHERE (CHARINDEX(vcName, @Adress) <> 0) AND len(vcName)>1 GROUP BY idRegion, vcName) Tbl Select Top 1 @idRegion=idRegion FROM dbo.tbRegion WHERE (CHARINDEX(vcName, @Adress) <> 0) AND CHARINDEX(vcName, @Adress)=@minPosReg AND len(vcName)>1 AND len(vcName)=@mLenReg if (@idRegion is null) SELECT @idRegion=vcValue FROM tbDefaultSettings WHERE (vcTableName = 'tbPerson') AND (vcOption = 'idRegion') --Ориентировочное извлечение района Declare @minPosRay int Select @minPosRay=MIN(Position) FROM (SELECT id, CHARINDEX(rtrim(ltrim(replace(vcRayonFullName, 'РАЙОН', ''))), @Adress) AS Position FROM dbo.tbRayon WHERE (CHARINDEX(rtrim(ltrim(replace(vcRayonFullName, 'РАЙОН', ''))), @Adress) <> 0) AND len(rtrim(ltrim(replace(vcRayonFullName, 'РАЙОН', ''))))>1 GROUP BY id, vcRayonFullName) Tbl Declare @mLenRay int Select @mLenRay= MAX(lenstr) FROM (SELECT id, LEN(rtrim(ltrim(replace(vcRayonFullName, 'РАЙОН', '')))) AS lenstr FROM dbo.tbRayon WHERE (CHARINDEX(rtrim(ltrim(replace(vcRayonFullName, 'РАЙОН', ''))), @Adress) <> 0) AND len(rtrim(ltrim(replace(vcRayonFullName, 'РАЙОН', ''))))>1 GROUP BY id, vcRayonFullName) Tbl Select Top 1 @idRayon=id FROM dbo.tbRayon WHERE (CHARINDEX(rtrim(ltrim(replace(vcRayonFullName, 'РАЙОН', ''))), @Adress) <> 0) AND CHARINDEX(rtrim(ltrim(replace(vcRayonFullName, 'РАЙОН', ''))), @Adress)=@minPosRay AND len(rtrim(ltrim(replace(vcRayonFullName, 'РАЙОН', ''))))>1 AND len(rtrim(ltrim(replace(vcRayonFullName, 'РАЙОН', ''))))=@mLenRay if (@idRayon=78) set @idRayon = null if (@idRayon is not null) begin set @Adress=substring(@Adress, @minPosRay+@mLenRay, len(@Adress)-@minPosRay-@mLenRay+1) end else begin set @Adress=substring(@Adress, CHARINDEX('РАЙОН', @Adress)+1, len(@Adress)-CHARINDEX('РАЙОН', @Adress)) end set @Adress=ltrim(rtrim(@Adress)) --Извлечение нас. пункта Declare @minPos int Select @minPos=MIN(Position) FROM (SELECT id, CHARINDEX(vcTownName, @Adress) AS Position FROM dbo.tbTown WHERE (CHARINDEX(vcTownName, @Adress) <> 0) GROUP BY id, vcTownName) Tbl Declare @mLenT int Select @mLenT= MAX(lenstr) FROM (SELECT id, LEN(vcTownName) AS lenstr FROM dbo.tbTown WHERE (CHARINDEX(vcTownName, @Adress) <> 0) GROUP BY id, vcTownName) Tbl if (@idRayon is null) begin Select Top 1 @idTown=id FROM dbo.tbTown WHERE (CHARINDEX(vcTownName, @Adress) <> 0) AND (CHARINDEX(vcTownName, @Adress)=@minPos OR (len(vcTownName)>3 AND len(vcTownName)=@mLenT)) AND idRayon IN (Select id From tbRayon Where idRegion=@idRegion) and (idRayon in (select id from tbRayon where (CHARINDEX(vcRayonFullName, @oAdress)<>0)) or idRayon in (select id from tbRayon where cKod>60400 and cKod<60500)) and (idRayon in (SELECT vcValue FROM tbDefaultSettings WHERE (vcTableName = 'tbPerson') AND (vcOption = 'idRayon'))) end else begin Select Top 1 @idTown=id FROM dbo.tbTown WHERE (CHARINDEX(vcTownName, @Adress) <> 0) AND (CHARINDEX(vcTownName, @Adress)=@minPos OR (len(vcTownName)>3 AND len(vcTownName)=@mLenT)) AND idRayon IN (Select id From tbRayon Where idRegion=@idRegion) AND (idRayon=@idRayon or idRayon in (select id from tbRayon where cKod>60400 and cKod<60500)) end if (@idTown is null) begin Select Top 1 @idTown=id FROM dbo.tbTown WHERE (CHARINDEX(vcTownName, @Adress) <> 0) AND (CHARINDEX(vcTownName, @Adress)=@minPos OR (len(vcTownName)>3 AND len(vcTownName)=@mLenT)) AND idRayon IN (Select id From tbRayon Where idRegion=@idRegion) and (idRayon in (select id from tbRayon where (CHARINDEX(vcRayonFullName, @oAdress)<>0)) or idRayon in (select id from tbRayon where cKod>60400 and cKod<60500)) and (idRayon in (SELECT vcValue FROM tbDefaultSettings WHERE (vcTableName = 'tbPerson') AND (vcOption = 'idRayon'))) end if (@idTown is null) begin Select Top 1 @idTown=id FROM dbo.tbTown WHERE (CHARINDEX(vcTownName, @Adress) <> 0) AND (CHARINDEX(vcTownName, @Adress)=@minPos OR (len(vcTownName)>3 AND len(vcTownName)=@mLenT)) AND idRayon IN (Select id From tbRayon Where idRegion=@idRegion) and (idRayon in (select id from tbRayon where (CHARINDEX(vcRayonFullName, @oAdress)<>0)) or idRayon in (select id from tbRayon where cKod>60400 and cKod<60500)) end if (@idTown is null) begin set @idTown=1832 end declare @Town varchar(100) set @Town=@oAdress set @Town=replace(@Town, 'х.','') set @Town=replace(@Town, 'хут.','') set @Town=replace(@Town, 'п.','') set @Town=replace(@Town, 'пгт.','') set @Town=replace(@Town, 'пос.','') set @Town=replace(@Town, 'с.','') set @Town=replace(@Town, 'сел.','') set @Town=replace(@Town, 'сл.','') set @Town=replace(@Town, 'ст.','') set @Town=replace(@Town, 'ст-ца','') set @Town=replace(@Town, 'г.','') set @Town=replace(@Town, 'гор.','') set @Town=replace(@Town, 'к.','') set @Town=replace(@Town, 'д.','') set @Town=replace(@Town, 'дп.','') set @Town=replace(@Town, 'д. пос.','') set @Town=replace(@Town, 'д.пос.','') set @Town=replace(@Town, 'раз.','') set @Town=replace(@Town, 'рзд.','') set @Town=replace(@Town, 'рп.','') set @Town=replace(@Town, '.','') set @Town=replace(@Town, '-','') set @Town=replace(@Town, '/','') set @Town=replace(@Town, '\','') set @Town=replace(@Town, ':','') set @Town=replace(@Town, ',','') set @Town=replace(@Town, ' ','') if (substring(@Town,1,2)<>'РО') begin set @idTown=1832 end Declare @TownName varchar(20) Select @TownName=vcTownName From dbo.tbTown WHERE id=@idTown --Получение территории Select @idRayon=idRayon From tbTown Where id=@idTown if (@idRayon is null) begin rollback tran raiserror ('Не возможно идентифицировать территорию.', 16, 10) return end --Окончательное получение региона Select @idRegion=idRegion From tbRayon Where id=@idRayon if (@idRegion is null) begin rollback tran raiserror ('Не возможно идентифицировать регион.', 16, 10) return end --Извлечение улицы Declare @mLenS int Declare @SmallAdress varchar(100) Select @SmallAdress=replace(@Adress, @TownName, '') Select @mLenS= MAX(lenstr) FROM (SELECT id, LEN(vcStreetFullName) AS lenstr FROM dbo.tbStreet WHERE (CHARINDEX(vcStreetFullName, @SmallAdress) <> 0) GROUP BY id, vcStreetFullName) Tbl Select Top 1 @idStreet=id FROM dbo.tbStreet WHERE (CHARINDEX(vcStreetFullName, @SmallAdress) <> 0) AND len(vcStreetFullName)=@mLenS AND len(vcStreetFullName)>3 Declare @StreetName varchar(50) Select @StreetName=vcStreetFullName From dbo.tbStreet WHERE id=@idStreet --Получение дома, корпуса и квартиры if (@StreetName is not null) if (len(@SmallAdress)>len(@StreetName)) begin exec GetAttribAdress @StreetName, @SmallAdress, @House out, @Korpus out, @Apartament out end | |
25
- 31.01.2013 - 14:27
|
ALTER PROCEDURE [dbo].[GetAttribAdress] ( @StreetName varchar(50), @Adress varchar(100), @House varchar(10) out, @Korpus varchar(10) out, @Apartament varchar(10) out ) AS if (charindex(@StreetName, @Adress)>0) if @StreetName Is Not Null begin declare @mAdress varchar(100) set @mAdress=@Adress set @mAdress=replace(@mAdress, '#', '') set @mAdress=replace(@mAdress, @StreetName, '#') set @mAdress=ltrim(rtrim(replace(replace(right(@mAdres s, len(@mAdress)-charindex('#', @mAdress)),' ',''), ',',''))) declare @h varchar(100), @k varchar(100), @a varchar(100) if charindex('/', @mAdress)>0 begin if charindex('-', @mAdress)>0 begin set @h=substring(@mAdress, 1, charindex('/', @mAdress)-1) set @k=substring(@mAdress, charindex('/', @mAdress)+1, charindex('-', @mAdress)-charindex('/', @mAdress)-1) set @a=substring(@mAdress, charindex('-', @mAdress)+1, len(@mAdress)-charindex('-', @mAdress)) end else begin set @h=substring(@mAdress, 1, charindex('/', @mAdress)-1) set @k=substring(@mAdress, charindex('/', @mAdress)+1, len(@mAdress)-charindex('/', @mAdress)) end end else begin if charindex('-', @mAdress)>0 begin set @h=substring(@mAdress, 1, charindex('-', @mAdress)-1) set @a=substring(@mAdress, charindex('-', @mAdress)+1, len(@mAdress)-charindex('-', @mAdress)) end else begin set @h=@mAdress end end if isnumeric(substring(@h,1,1))>0 begin set @House=@h set @Korpus=@k set @Apartament=@a end end | |
26
- 31.01.2013 - 14:36
|
При этом таблицы tbRegion, tbRayon, tbTown, tbStreet имеют примерно слудующую структуру: CREATE TABLE [dbo].[tbStreet]( [id] [int] IDENTITY(1,1) NOT FOR REPLICATION NOT NULL, [vcStreetFullName] [varchar](50) COLLATE Cyrillic_General_CI_AS NOT NULL CONSTRAINT [DF_tbStreet_vcStreetFullName] DEFAULT (''), [vcStreetName] [varchar](20) COLLATE Cyrillic_General_CI_AS NOT NULL CONSTRAINT [DF_tbStreet_vcStreetName] DEFAULT (''), [rowguid] [uniqueidentifier] ROWGUIDCOL NOT NULL CONSTRAINT [DF_tbStreet_rowguid] DEFAULT (newid()), [klCode] [nvarchar](13) COLLATE Cyrillic_General_CI_AS NULL, CONSTRAINT [PK_tbStreet] PRIMARY KEY CLUSTERED ( [id] ASC )WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY], CONSTRAINT [IX_tbStreet] UNIQUE NONCLUSTERED ( [vcStreetFullName] ASC )WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY], CONSTRAINT [IX_tbStreet_1] UNIQUE NONCLUSTERED ( [vcStreetName] ASC )WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY] ) ON [PRIMARY] GO SET ANSI_PADDING OFF где klCode - код кладра (берется из справочника КЛАДР, в вашем случае - это индекс) В Вашем случае нужно еще и номер дома анализировать, ведь у одной и той же улицы может быть несколько индексов, а это еще одна таблица в иерархии георгафических таблиц tbDoma. Все они связаны по типу один ко многим каждый уровень с более нижним. | |
27
- 31.01.2013 - 15:43
| 24-Radon > http://codepaste.ru/ - иногда полезно: подсветка синтаксиса и постинг на форуме в виде ссылки. | |
| Интернет-форум Краснодарского края и Краснодара |