Еще один вопрос: каждая секция файла описывает свой квадрат, то есть, получается, что на самом деле режем не по полигону, а по набору квадратов, которые в любом случае не совпадут с границей… То есть для правильной нарезки территории РФ нужно закрыть такими квадратами ее всю?
Есть у меня подозрение, что лучше будет строить просто квадратный ббокс, включающий заведом всю территорию РФ ,а потом прогонять на нем скрипт проверки “точка в полигоне”, использую как полигон - границу. Только вот сколько будет работать скрипт с полигоном с 22000 вершин - я даже боюсь представить… Даже учитывая, что можно руками выбрать внутренний ббокс и вырезать сразу большой косуок территории…
Upd. Вопрос снят, формат поддерживает не только квадраты, но и любые полигоны. Ушел собирать полигон по границе.
там можно точно так же описать и просто полигон в таком же формате.
просто я подозреваю, что когдаа он описан как набор квадратов, то работает быстрее.
Только набор квадратов терят куски и захватывает лишнее. А быстрее или нет - имеет значение при первичном импорте planet.osm, то есть один раз, дальше импортируется не такой большой объем, чтобы это имело существенное значение (надеюсь
Но пока все не так просто, как хотелось - полигон не собрался, потому как половина путей повернута в одну сторону, а половина в другу. И первый узел первого пути в границе оказывается первым же узлом второго пути, идущего ему в лоб… Хотел править пути - понял что умру, буду переписывать скрипт…
Кстати, с сайта осмосиса идет ссылка на другие полигоны - там россия на три части побита, так вот там совсем не квадраты. а полигоны с десятками вершин.
из первого пути все точки копируется в новый массив, запоминаются ID первой и последней точек . вычеркиваем первую линию из из перечня
берем следующий путь из перечня, смотрим его первую и последнюю точку, если совпадает первая - заносим в новый массив по порядку, если последняя - в обратном порядке, запоминаем новую первую(последнюю) точку, вычеркиваем линию из перечня линий.
повторяем п.3 до совпадения первой и последней (полигон замнут) , опустошения перечня линий или возникновения лупа - полигон не замкнут.
Саш, пасиб, но VB в php плохо встраивается Я ровно это сейчас и пишу. Просто сначала тормознул и написал исходя из того, что все линии в одну сторону идут. То, что этот полигон замкнут, мне проверять не надо, я его ручками весь замкнул.
Как думаете, а что будет, если при импорте через осмосис почасовых обновлений я на один импорт отключу обрезку по полигону. И как раз перед этим обновлением передерну пути, составляющие границу, чтобы они пошли обновленными. Получится у меня закачать их полностью в локальную базу? Или импорт вообще провалится, потому что в базе будут отсутствовать объекты, которые раньше отрезались полигоном?
Суть в чем - полигон, по которому идет обрезка, во многих местах коцает границу и у меня в базе нехватает и путей, и точек. Писать парсер для xml не хочется, ибо есть готовый скрипт для базы, то есть хочется в базу как-то затянуть всю границу… Что думаете? Или дешевле закачать свежий planet.osm и порезать его не полигоном, а заведомо бОльшим ббоксом? Отработать на нем границу, потерпеть недельку и снова закать планету, обрезав ее уже по новому полигону?
Получаю:
SEVERE: Execution aborted.
org.openstreetmap.osmosis.core.OsmosisRuntimeException: Task 3-bounding-box does not support data provided by default pipe stored at level 1 in the default pipe stack.
Надеюсь, что обрезка будет проводиться не строго по границе, а с небольшой добавкой.
А то полигоны на границе , например река, по руслу которой и проходит граница, режутся очень забавно. В результате получаются самопересекащиеся полигоны, захватывающие вместо территории до границы кусок суши.
Для начала буду экспериментировать с опциями обрезки, в частности включать полностью задеваемые пути и реоейшены. Если не поможет - придется ручками править файл полигона, расширяя его. Потому что алгоритм автоматического расширения полигона мне в горлову не приходит. Только если делить его на четыре части по горизонтали и вертикали и увеличивать каждую в свою сторону. Но, боюсь, могут получиться глюки… А руками 22000 точек править будет непросто…
Перекроил дефолтную схему базы, убрал лишние индексы и foreign key constraints, из-за которых сбивался иморт, добавил свои индексы, отказался от innodb, ибо вроде как для моих задач myisam получается быстрее. Разнес базу с исходными данными и базу с производными по разным жестким дискам, надеюсь это положительно скажется на скорости. Запустил импорт по-новой, посмотрим что получится.
С трудом и танцами с бубном импорт я завершил. Но теперь умерло обновление… Опять ошибка про то, что процесс не может использовать pipe… Всю вики и девлист облазил, ничего не нашел…