У финов номера домов с буквами тоже не исключение.
Более того они очень часто вместо номера дома в адресе используют номер подъезда, который представляет собой номер дома с добавленной (без пробела) буквой: 4а, 4b, 4c.
OSM - база данных, и хотя стоит задумываться о том, чтобы не превратить ее в монстра, сделав данные непригодными для использования в сторонних продуктах, но наличие в адресе буквы (которая происходит от вполне официального статусного названия этой части адреса) - проблема для авторов конвертеров, решаемая за десять минут.
Другое дело, что дабы не создавать таким авторам лишних проблем, такие прецеденты, отличающиеся от привычной схемы адресации, должны быть где-то перечислены (в вики, например).
К слову - адресация по микрорайонам даже в пределах Московской области - не единичный случай: в г. Видное (Ленинский р-н) есть, как минимум, один микрорайон, где адреса официально “микрорайон Солнечный, дом 1…10”, в другом микрорайоне долгое время не было названий улиц и в ФНС дома числились как “микрорайон Березовая роща, дом …”, а в строящемся 6-м микрорайоне тоже, возможно, будут корпуса и не будет улиц.
Да, по России много мест, где адресация по микрорайонам, деревням в целом и прочим не улицам. В этом нет ничего “непривычного”.
Но, еще раз повторю, что в Зеленограде нет адресации по микрорайонам. Микрорайон в адрес не входит. Совсем. Но как-то группировать дома при поиске очень хочется.
Эта проблема может решаться двумя основными способами.
- Адреса Зеленограда особым образом обрабатываются в конвертере.
- По Зеленограду расставляется “костыль”, представляющий собой неиспользуемый в Зеленограде тег адресации.
Т.к. вероятнее всего реализовать 1 способ для всех имеющихся и перспективных конвертеров вряд ли удастся, более перспективным выглядит 2-й вариант.
Например, в addr:suburb записывается номер квартала (полностью - с двумя последними нулями, чтобы пользователь сразу понял, в чем дело).
addr:suburb в Зеленограде используется и по делу для различения одноименных улиц. Как костыль для группировки домов сейчас используется addr:street=X-й микрорайон и этот костыль есть желание таки убрать.
OSM выглядит уже как вполне зрелая база, чтобы не прибегать чуть что к костылям.
Мне решение видится так:
адреса в Зеленограде и других схожих местах обрабатываются неким общим способом, быть может и новым.
Использование костылей вылазит в других местах — корректную работу с адресами в Зеленограде приходится делать с помощью антикостылей: убиранием липовых улиц.
Давайте определимся, какую именно задачу мы решаем, и на каком этапе.
Кстати, этап может быть продиктован и самой задачей.
Попытайтесь как можно точнее сформулировать задачу.
Начали с буквы “к” в номере корпуса — выяснили, что базе данных с ней лучше, а на картинке по вкусу. Тут решение вырисовывается: “к” вставить, а в навитель всё одно буквы обрезать.
Попутно вопрос, который хочется решить в качестве второго этапа — избавление от костылей псевдоулиц:
Общая задача — приведение данных к установленному виду адресации без потери имеющейся функциональности в конверторах и т.п…
Насколько я представляю, адресация может быть либо по улице, либо по территории. Кстати КЛАДР (до ФИАС еще руки не дошли) все, по чему осуществляется адресация - это улицы.
Так что при попытке унификации чем-то приходится жертвовать. Например, считать за улицы то, что в бытовом представлении улицами не является.
Насколько я понимаю, основная проблема Зеленограда не в структуре адреса, которая как раз ничуть не уникальна, а в обилии номеров домов, из-за чего трудно управляться на маленьком экране. Или я чего-то недопонял?
ФИАС использует понятие “адресный элемент” которые являются узлами дерева от региона до улицы. Технически дом может быть привязан к любому узлу.
Дома привязанные к деревне есть (первое что под руку попало) в “143391, Москва г, Марушкинское п, Анкудиново д”. При этом в той же деревне есть Сосновая улица со своими домами.
Ну тогда первое, что следует сделать, это посмотреть, как Зеленоград прописан в ФИАС. Потому как это “последнее научное достижение” в области"установленных видов адресации".
В конце концов, хотя и понятно, что ФИАС не является истиной в последней инстанции для OSM, но люди ломали голову над этой проблемой и не воспользоваться плодами их работы было бы неразумно.
А потом подумать, подходит ли нам то, что есть в ФИАС для Зеленограда. Если не подходит, пытаться найти решение уже в более узкой области - без конфликтов с текущей структурой OSM и ФИАС.
Истины в последней инстанции, похоже, не существует. :3
Для Москвы истиной в предпоследней инстанции является “Адресный реестр Москвы”. В нём - “Зеленоград, корпус nnn”.
ЗЫ
Истина в последней инстанции существует, и это документ о регистрации или смене адреса строения из местного БТИ.
Номер пустой, цифры в графе “корпус”, в соответствии с:
А к какому узлу все это прицеплено?
Пара дней прошла.
Решение по добавлению “к” в addr:housenumber считаю принятым.
Ждём определённости по группировке корпусов и тогда делаем корректировку заодно с addr:street
Ещё наблюдаются addr:city=Зеленоград, addr:country=RU и addr:region=Москва. Есть мнение, что это всё избыточно, т.к считается из геометрии. Сносим или проставляем+корректируем?
Считать по геометрии, конечно, очень дорого, но раз у большинства объектов эти поля отсутствуют, то и на остальных они лишены смысла.
Хотя, по хорошему, адресация хотя бы на на 1 уровень вверх должна быть.
Это избыточно, но допустимо. Можно вообще не трогать, можно проставить.
По факту может использоваться для “не лазанья в геометрию” или для отнесения к региону вопреки геометрии (такое где-то по-моему встречалось, хотя не вспомню где). Так что сносить уж точно не стоит.
С утра мне в голову пришла СМСка:
А для группировки домов подошел бы тег из разряда is_in:xxxx
Вот муниципалитет предлагают, но это немножко сильно
is_in:municipality=* (proposed)
может так?
is_in:housegroup=территория ЗИЛ (для более тысячи строений по Автозаводской 23 )
is_in:housegroup=3-й микрорайон
З.Ы. Или уж is_in:buildinggroup
Как только народ не извращается лишь бы не использовать простые и универсальные свойства геометрической вложенности…
Простые?
Для обработки миллиона точек при наличии локальных атрибутов нужно порядка 1 секунды.
Если попытаться в лоб обработать такой массив данных с расчетом геометрической вложенности, задача будет считаться вечно (в прямом смысле слова - 100 лет - далеко не предел).
Чтобы хоть как-то обработать массив за вменяемое время нужно формирование вспомогательной структуры геометрических индексов. И даже при этом время обработки составит порядка суток.
Как говорится, почувствуйте разницу.