Я бы в это даже может быть и поверил, если бы сам не занимался конвертацией. Не, я конечно верю, что можно написать обработку и настолько криво. Но сделать так, чтобы работало нормально особого труда не составляет. 
Я сильно подозреваю, что под “обработкой” Вы подразумеваете время без учета создания базы пространственных индексов.
А именно создание базы и займет основную долю времени.
Кстати, Вы в курсе, что количество элементов в OSM, вроде как, перевалило за 2 млрд?
PS. А время только на обработку без создания базы лично я оцениваю в минуты-десятки минут.
Я говорил про всё. Подготовка пространственных данных для быстрого поиска вхождения - это тоже быстро, там просто нечему сутками заниматься (разве что на совсем стареньком компьютере).
Конкретные величины времени бессмысленно обсуждать в отрыве от конкретной задачи и конкретного железа.
Ну у у осмосис сейчас вырезает Россию из мира ощутимо быстрее чем за 100 лет. Причем делает он это довольно тупым образом. Ну и та же pgsimple строится на приличном железе на весь мир несколько суток но не столетие. Индексы по геометрии там есть.
Ага, а потом ничего не работает из-за единственного поломанного отношения
Валидатор может не работать, а конвертер обязан работать и при частично поломанных данных.
В большинстве своём отношения ломают незначительно и их очень просто автоматически превратить в замкнутую область. Так что, если есть желание уметь всегда конвертировать даже на частично поломанных данных - это тоже можно организовать. Вот если область совсем удалят или капитально разломают - тогда да, проблема. Её тоже можно решить, но уже сложнее (например через хранение копий этих областей с предыдущих дампов и использованием их в случае невалидности в текущем). С другой стороны - чем быстрее проблему обнаружат, тем быстрее и починят.
В тоже время поддержание валидности обратных ссылок - проблема ничуть не меньшая, и так же подвержена разнообразным поломкам при редактировании. Принадлежность геообъекта конкретным координатам - это вещь весьма стабильная, и довольно глупо эту стабильность не использовать, заменяя её на какие-то левые ссылки.
Напоминаю, Москва живёт поломанная уже больше полугода
Да, это можно использовать для валидации и/или автоматической расстановки
А в Питере за месяц после бота все границы починили. Как используют - так и чинят.
Может, надо стоит перестать троллить по этому поводу (уже сильно побольше полугода, кстати) и рассказать, что кому там не нравится?
esaulenka, уже два раза рассказывал (см. профильную тему). Третий раз не буду, звиняй 
Угу, я и говорю - Москвой не пользуются
Два миллиарда точек - это быстро?
Не верю.
Геометрия из ~300 млн веев с 2 млрд узлами.
По ним и строится пространственная структура.
Есть 1 млн точек, положение которых нужно определить по отношению к этой структуре.
Вы читать умеете?
Повторюсь:
И, кстати, осмосис работает по уже готовой базе.
Т.е. нужно каждый раз обрабатывать весь дамп планеты и проверять на вхождение во все имеющиеся полигоны? Можно узнать конечную цель этого странного действа? И как вы собираетесь её решать через теги is_in? 
А что, у Вас есть другой вариант?
Если базы пространственных индексов нет, значит, ее нужно поднимать. Ничего другого здесь не придумаешь.
Мы оцениваем время выполнения полного цикла работы.
Если есть теги is-in или им подобные, нам не нужна база пространственных индексов, следовательно, обрабатываем только имеющийся миллион точек за 1 секунду.
Другой вариант чего? Вы пока не сказали какую задачу вы хотите решить. Вы лишь предлагаете способы решения, один странней другого.
Но ведь этими тегами вы не сможете проверить на вхождение в “любой имеющийся полигон в дампе планеты”. А если вам это не нужно, тогда зачем настаиваете на таком решении для пространственного варианта?
Задача - узнать, что один объект находится внутри другого.
Надежность тега is-in ничуть не хуже надежности проверки по дампу планеты, т.к. в дампе планеты ВСЕГДА присутствуют поломанные полигоны.
Но, честно говоря, с планетой я не работаю, а работаю с local.osm. Скачиваю новый вариант раз в 1-3 месяца и обновляю данные в своей базе.
Соответственно, весь геометрический анализ приходится делать с нуля (т.к. задействовать OSM через API еще дороже).
Так вот в версии от середины октября:
- Москва имеет admin_level=2, что, мягко говоря, затрудняет построение дерева вложенности объектов.
- Какие-то непонятки между Москвой, Московской Областью и Одинцовским районом.
- Какие-то непонятки между Минском, Минской областью и Минским районом.
- “Зеленов ауданы” в Казахстане имеет границу, в которую входят одни и те же пути по нескольку раз.
- Какие-то непонятки с Ташкентом. Сам он имеет admin_level=4, но ни в таком виде, ни при исправлении на admin_level=6 построить правильную иерархию не удается.
- Существенная доля субъектов РФ и аналогичных им образований в других странах постсоветского пространства имеет площадь отличающуюся от суммы площадей входящих в них районов. Причем, как в меньшую, так и в большую сторону. Это даже если не учитывать Эстонию, Молдову, Грузию… у которых не совпадающая с российской система деления по admin_level.
Я даже не говорю о том, что Северная Осетия и Нагорный Карабах имеют admin_level=2, но при этом входят в территории других государств.
Ну и уже упомянутая мною в п.5 разница в подходах к admin_level в разных странах дополнительно усложняет построение дерева вложенности.
В общем, при геометрическом подходе без эмпирики, волюнтаризма и изрядной доли ручного труде все равно не обойтись.
Поэтому такой метод я считаю слишком затратным и очень ненадежным.
Но ведь вас интересует не любой объект, а объекты вполне конкретных типов. С учётом этого, а так же того, что вся планета не нужна - сложность построения геометрических индексов сразу пропадает.
Но даже если бы понадобились все объекты по всей планете - это тоже можно было бы сделать, просто другими путями. Например настроить репликацию по дифам. Тогда была постоянно актуальная геобаза объектов (а не раз в 3 месяца) по которой можно было бы легко делать нужные проверки.
Можно, конечно, сидеть и созерцать поломанные данные, ожидая когда их кто-то починит. А можно просто взять и починить. Мне вот по Питеру нужны были данные границ - я сел и починил.
А держать в “каждом” объекте ссылки на все объекты, в которые он вложен - это типа не затратно? И на какой атрибут вы хотите ссылаться? На id? На name? И вы действительно считаете это более надёжным способом?
Более того - именно эти данные я уже починил. Вспоминать лень, но, кажется, это было сильно раньше, чем 2 недели назад.
Но товарищу поныть очень хочется…
Господа, что-то совсем уж отклонились с этой геометрией.
Сейчас для домов никто не ищет улицу из геометрии, так вопрос простой и конкретный: как назвать тег, заменяющий addr:street для группировки домов?
Давайте не будем предлагать всеобъемлющих решений и новых технологий.