Не считая филосовского фопроса “кому же тогда подчинена Балашиха”…
Попробовать что ли задать вопрос налоговой на сайте ФИАС? Потому что
Ну, скажем так, он существует, но теперь называется городским округом.
А как пользоваться, я тоже не понял. Везде сопоставлено с осмом 0 объектов.
На самом деле, так и должно быть. Просто ФИАС предназначен не только для сравнения с ОСМ 
Если хоть у кого-то в паспорте осталась старая прописка в “Балашихинском районе”, ФИАС должен давать возможность разложить этот адрес по своим полям, даже если теперь этот адрес в реальности поменялся.
Выводится следующая информация:
Сколько всего подчиненных адресных элементов в ФИАС.
Сколько из них найденно в ОСМ в качестве территорий.
Сколько найдено в ОСМ в качестве улиц.
Сколько в ОСМ не найдено.
Сколько домов в ФИАС в этом адресном элементе
Сколько из них найдено в ОСМ.
Сколько из них не найдено в ОСМ.
Подчинение пока считается только непосредственное. Рекурсивная статистика - в ближайшем будущем.
Просьба предлагать более наглядное описание граф, если не понятно. У меня уже глаз “замылился” - мне эти колонки очевидны.
В ФИАС все еще район. Из-за этого сопоставитель не может найти Балашиху и все лежащее в ней, поскольку ищет “сверху вниз”
Понимаю. Но не в ущерб же современному названию…
Что бы можно было пользоваться, нужна агрегированная статистика по регионам/НП,
и раскраска цветом, где сколько адресов сопоставлено.
Ну и разделение на страницы выкинуть. Найти в Мск какую-либо улицу просто невозможно.
С раскраской я подумаю, суммарная статистика в планах https://github.com/Scondo/fiosm/issues/4
Технически там все понятно, но пока обсчет такой статистики вешает рендер. Ищу пути обхода в частности https://github.com/Scondo/fiosm/issues/6
Увы, но постраничное разделения явилось вынужденной мерой - данные обрезались при рендере. Учимся половинному делению…
Так, чуваки и чувихи, какие новости на Плюке?
Нельзя ли опубликовать наконец какой процент адресов из ФИАС есть в осм, по России в целом и в разрезе по областям?
К сожалению проблемы производительности посредством таймаутов переросли в проблемы с доступом.
Причем сейчас я не могу установить причину проблем с производительностью, т.к. они не воспроизводятся на отладочной машине, где ведется разработка.
Возможно это что-то с базой, в этом я сейчас пытаюсь разобраться, но, увы, очень медленно, поскольку “горячий” сезон на работе пока не кончился.
Расчет “рекурсивной” статистики - это та же проблема производительности, только в кубе.
К ней ищется параллельное решение в виде предварительного обсчета статистики.
В худшем случае сяду в режиме рабочего дня на майские. Обещать ничего не могу, но работа идет… или по крайней мере ползет.
Как там работа над проектом? Майские уже 
Починил пару глюков, нарисовал новую мордочку с тегом meter.
Надо: заменить прогрев кеша статистики на отстройку, увеличить число потоков сервера. После этого сайт должен стать рабочим.
Рекурсивная статистика постоянно имелась ввиду в рамках прибивания багов и, вероятно, как только будет прогрев кеша нарисую рекурсивные цифры. Т.е. не сколько районов подчиненных МО найдено в МО, а сколько всего районов, улиц (и отдельно - домов) найдено в МО.
В очереди: сделать страничку по списку сопоставленных домов.
А можешь напомнить, почему ты не хочешь просто сгенерить статические html-ки? Тогда все вообще должно залетать…
Сейчас: потому что на выбранной мной архитектуре единственный понятный мне способ это сделать - это пройтись по сайту “архиватором интернета”.
А в целом потому, что я все-таки надеюсь на то, что когда-нибудь перейду на работу в дифф-режиме, когда статистика будет пересчитываться только для обновленных данных.
Scondo, а что за странная архитектура, при которой сайт ложится от трёх пользователей? Подозреваю, этого сложно достичь даже если всё хранить в текстовых файлах и при каждом запросе их парсить целиком.
Мне тоже интересно. Если готовые данные для выдачи хранятся в БД, можно выводить их вполне быстро, этим занимаются миллионы сайтов.
Возможно, при первом обращении в базе ничего ещё нет и она лихорадочно начинает заполняться…
Ничего такого в коде не вижу, но оно, возможно, хорошо спрятано.
Наверное, когда появится время, надо добавить кучу отладочного вывода в логи - тогда станет хотя бы понятно, на чем висит.
Производительность Python-приложений, на мой неопытный взгляд, вообще очень зависит от настроек сервера и наличия на нём всяких наворотов/служб/хитроумных настроек… Я ставил себе только готовый Rhodecode - при самой простой конфигурации висело от 5 пользователей в локальной сети. После плясок с бубном по инструкциям и активации наворотов (mod_wsgi и (в случае Rhodecode) серверов+настроек Сelery, RabbitMQ) всё залетало…
Хранение в БД самого факта сопоставления.
Соответственно на каждый запрос идет куча селектов по джойнам на немаленькие таблички.
Собственно эту проблему и был призван решать кеш статистики (отдельная табличка хранящая только цифры для каждого объекта), но именно с ним и лезут проблемы.
Если БД на постгре и осмелитесь подпустить к ней постороннего человека, помогу, чем смогу.
Если я правильно понял суть, то как-то совсем не хорошо. На каждый запрос пользователя должен быть один сложный селект, тогда, при должном уходе за базой, джойны и размеры таблиц будут иметь уже не столь большое значение.