Именно, хочется быстро отсечения. Ибо именно в городах много путей, тоесть большее количество точек для проверки. Отсекая кусок мы сразу выигрываем в скорости. Да, я могу задать внутренний ббокс для большого города руками. но для всех - замучаюсь. А ведь надо еще проверять, не сместилась ли граница с прошлого прогона…
Проще тогда рубить на сетку, определить внутренние квадраты, наружные квадраты и квадраты, через которые проходит граница полигона.
все, что в наружных - сразу выбрасываем
все, что во внутренних - сразу принимаем
все, что в квадратах с границей - проверяем по полной
ага, а координаты перевести в 32-битные целые, и сетку брать кратную степени двойки
А квадраты ты как проверять будешь? Это с дорогами мы можем считать, что если начало и конец в полигоне, то она вся в полигоне. А квадрат по четырем точкам не проверишь… Проверять несколько точек по каждой стороне с определенным шагом?
Вдогонку.
А почему все объекты (в __russia.rar) пребывают в "OSM"ской области, государства “Earth”?
потому что пока нет возможности их правильно распределить 
для России есть вариант сделать это по кладр-у, про других вообще пока непонятно
я бы советовал у полигонов городов прописывать addr:country и addr:region
Как и с way, случай, когда здание одной стороной заезжает в н/п, и тем более содержит этот населенный пункт в себе можно отнести на 99.99% к погрешностям рисования полигонов, а оставшиеся 0,01% разрулить ручками.
Почему же нет, можно ведь и проверить на вхождение в страну/область 
А как это сделать, не загружая planet.osm знает Ilis.
А также для POI городов.
Это я к тому веду, что говорить об избыточности подобной информации несколько … радикально.
Стоп. При чем тут здание? Мы про квадраты, а не про здания… А вот вероятность что квадрат заденет край полигона стороной, а не вершиной, очень велика. Она уменьшаетс с уменьшением стороны квадрата, но чем меньше квадрат, тем меньше выигрыш по скорости…
Дык эта… уже 
Т.е. речь идет о квадрате сетки о которой говорит KekcuHa?
Его (полигон), естественно, проверять (по крайней мере предварительно - а то и этим удовлетвориться) по boundrect. А уж проверка столкновения двух прямоугольников - задача предельно тривиальная, из арифметики только сравнения.
эт хорошо… значит, скоро будет не только Earth/OSM 
этот весь сыр бор из за того что лучше как нить вые**тся написав алгоритм вычисления по координатам объекта принадлежность объекта к городу стране чем просто ввести идентификаторы привязок домов к улицам а улиц к городу а город к стране Короче говоря простых путей не ищем.
Ну если вы считаете ,что подписать 130000 объектов руками проще, нежели подумать и сделать для них бота - то да, простых путей мы не ищем…
Стоп, какое столкновение прямоугольников? Нам нужно проверить нахождение квадрата вне полигона или в полигоне. Полигон - ниразу не прямоугольный. И что имеется в виду под boundrect?
Имелся в виду, описанный вокруг полигона прямоугольник, который все равно пригодится для этапа отсева неподходящих точек.
Оффтоп. Самое, понятно, приятное, это дву-направленный список. То есть каждый ссылается на младшего члена иерархии и на старшего.
Выдернул нужный, к примеру, улицу - получи вверх город (область, страну) и получи вниз дома по этой улице. Только занимать места это будет… много.
Для отношений это и так доступно.
Можно как выдернуть member’а (тут все очевидно), так и все отношения - куда данное отношение (точка/линия) входят как member
Рисуночек тут на коленке изобразил для предметности.
Черный - полигон
Красный - ббокс
Зелёный - сетка
Синий - квадраты
Ну кагбы понятно. Только квадраты должны быть трех типов ин-аут-граница. И главный вопрос - как проверять положение квадрата. Ну слабо у меня с математикой 