У меня есть скрипт геокодирования на основе базы TIGER, есть скрипт рисования карт на основе той же базы. Полдела сделано, осталось проиндексировать весь инет, найти в нем все почтовые адреса и все :)
Если аргументация идет на таком уровне, то наверное в первую очередь просто не стоило его начинать?
А мне пришлось пару лет пожить в штатах. Зашел на local.google.com, ввел адрес своего бывшего дома и стал искать разные места, которые мне, к примеру, могли быть интересны - магазины, бары, библиотеки, отели. Точность вполне приемлимая. А вместе с их картографическим сервисом вообще получается очень полезная штука.
Дык ведь данная вещь как раз и предназначена в основном для поиска коммерческих предприятий (и прочих оффлайновых компаний). И адрес на их сайтах будет в стандартном формате, если компания желает, чтобы клиенты ее нашли или могли прислать письмо (а тем более чек, что очень популярно в штатах). На весь интернет географический поиск и не претендует. Сколько можно это обсуждать?
Ну пусть мне кто-нибудь расскажет, зачем какому-нибудь ресторанчику подделывать адрес. Ну выползет он на первое место в поиске, и я решу туда сходить. И чем это ему поможет? Наоборот, в условиях америки владельца этого ресторана быстро потащут в суд.
Что-то я уже совсем потерял нить разговора. И в обычных поисковиках есь нечестная оптимизация. Так может на этом основании и обычные поисковики отменим? Или в чем вы меня пытаетесь убедить?
Поясняю мысль: какая разница откуда берется адрес для оценки возможности/востребованности/удобства (нужно подчеркнуть) данного сервиса? Если нет хороших и полных географических баз данных, то откуда бы адреса не брались, толку в них нет, потому что работать с ними мы не сможем.
Ну и допустим, есть некая фирма с кучей филиалов по всему городу. Домен в лучшем случае будет зарегистирован на головной филиал (а может быть зарегистирован вообще на вебмастера, который обслуживает их вебсайт). Ну и зачем мне адрес головного филиала, если я ищу поставщиков некой услуги в 10 минутах ходьбы от моего дома? Тут нужно именно парсить текст страницы и искать в нем адреса, что при условии минимального соблюдения правил оформления адресов не слишком сложная задача.
lagif, меня не может:) Потому что не я заговорил про whois. Так почему же ответ обращен ко мне?
А какая разница откуда брать адрес - парсить текст страницы или из whois данных? Весь вопрос в том, что с этими данными делать дальше. Вот тут то возможность достаточно точной локализации адреса и играет ключевую роль.
Тот сам себе злобный Буратино. Ну не будет работать система в таком случае. Кому от этого будет хуже? Явно не системе, а владельцу сайта. Никто и не обещает 100% точности. Странно, что приходится объяснять эти вещи на этом форуме. Обычный поиск ведь никуда не денется, можно и им пользоваться.
А вот функции "Найти дилера не далее 5 км от моего дома" в штатах чрезвычайно популярны и используют их многие сайты. Не удивительно, что и поисковики в какой-то мере пытаются воспроизвести подобную функцию. И все благодаря тому, что государство на народные деньги создало такую базу данных (цель конечно у них была другая, не для этого ее создавали) и раздает ее как public domain.
lagif, пример с болельщиками как раз очень неудачный. Географический поиск в основном ориентирован на поиск услуг, привязанных к местности, как мне кажется. Если у человека есть маленький бизнес и есть маленький сайт, то наверняка на сайте есть точный адрес. Вот в этом случае географический поиск будет как нельзя кстати. Обычный поиск может мало помочь, задавят более крупные конкуренты. А тут можно позиционировать себя с точностью до сотни метров и искать что-нибудь в пределах пешей прогулки.
goover, подозреваю, что немаловажную роль в развитии этого направления играет то факт, что в штатах есть Census TIGER/Line database, которая содержит географические координаты почтовых адресов США, абсолютно бесплатная, с возможностью использовать ее в коммерческих приложениях. Если бы в России было что-то подобное, были бы и приложения, использующие эти данные. А раз данных нет, то и развивать нечего.
> Фишка в том, что данные достаются как в том так и вдругом случае SELECTом
Так ведь чтение данных с диска это не более одного процента работы, выполняемой поисковым механизмом. Затем эти данные нужно распаковать, найти объединение или пересечение, подсчитать релевантность, отсортировать полученный список. И если все эти операции делать на SQL, то база загнется (как показывает опыт mnogosearch). А если для этих целей пишется отдельный код, то зачем тогда данные хранить в дорогой полнофункциональной базе? Как сказал Илья, для простой таблицы "ключ -> инвертированный список" вполне достаточно самой примитивной схемы хранения, вроде Беркли_DB (если не говорить об особо крупных и загруженных системах, где и чтение данных приходится сильно оптимизировать). Использовать базу для хранения индекса оправданно только в том случае, если она и так используется для хранения, например, самих документов. Тогда конечно, почему бы и индекс не хранить там же.
