Формат файла полигона для osmosis

Народ. а подскажите, что за координаты в файле полигона для обрезки в osmosis?

russian_federation
1
1.4110078E+002 5.337188E+001
1.4110078E+002 5.344619E+001
1.4132091E+002 5.344619E+001
1.4132091E+002 5.337188E+001
1.4110078E+002 5.337188E+001
END
2
1.4119539E+002 4.621428E+001
1.4119539E+002 4.628667E+001
1.4124376E+002 4.628667E+001
1.4124376E+002 4.621428E+001
1.4119539E+002 4.621428E+001
END
3
1.4121286E+002 5.280641E+001
1.4121286E+002 5.282861E+001
1.4123517E+002 5.282861E+001
1.4123517E+002 5.280641E+001
1.4121286E+002 5.280641E+001
END

и так далее. Что за координаты и как в них перевести обычные широту с долготой???

область из трёх кусков
1.4121286E+002 5.280641E+001 - это (52.80641, 141.21286)

Кусков больше, это я первые три взял :slight_smile:
А +001 и +002 что-то значат?

http://ru.wikipedia.org/wiki/Экспоненциальная_запись

UPD.
Лучше http://en.wikipedia.org/wiki/Exponential_notation#E_notation

Понял, спасибо :slight_smile:

наверное надо и юристам учить математику

Еще один вопрос: каждая секция файла описывает свой квадрат, то есть, получается, что на самом деле режем не по полигону, а по набору квадратов, которые в любом случае не совпадут с границей… То есть для правильной нарезки территории РФ нужно закрыть такими квадратами ее всю?

Есть у меня подозрение, что лучше будет строить просто квадратный ббокс, включающий заведом всю территорию РФ ,а потом прогонять на нем скрипт проверки “точка в полигоне”, использую как полигон - границу. Только вот сколько будет работать скрипт с полигоном с 22000 вершин - я даже боюсь представить… Даже учитывая, что можно руками выбрать внутренний ббокс и вырезать сразу большой косуок территории…

Upd. Вопрос снят, формат поддерживает не только квадраты, но и любые полигоны. Ушел собирать полигон по границе.

там можно точно так же описать и просто полигон в таком же формате.
просто я подозреваю, что когдаа он описан как набор квадратов, то работает быстрее.

Только набор квадратов терят куски и захватывает лишнее. А быстрее или нет - имеет значение при первичном импорте planet.osm, то есть один раз, дальше импортируется не такой большой объем, чтобы это имело существенное значение (надеюсь :slight_smile:

Но пока все не так просто, как хотелось - полигон не собрался, потому как половина путей повернута в одну сторону, а половина в другу. И первый узел первого пути в границе оказывается первым же узлом второго пути, идущего ему в лоб… Хотел править пути - понял что умру, буду переписывать скрипт…

Кстати, с сайта осмосиса идет ссылка на другие полигоны - там россия на три части побита, так вот там совсем не квадраты. а полигоны с десятками вершин.

У меня есть такая процедура:

  1. создается перечень линий релейшена
  2. из первого пути все точки копируется в новый массив, запоминаются ID первой и последней точек . вычеркиваем первую линию из из перечня
  3. берем следующий путь из перечня, смотрим его первую и последнюю точку, если совпадает первая - заносим в новый массив по порядку, если последняя - в обратном порядке, запоминаем новую первую(последнюю) точку, вычеркиваем линию из перечня линий.
  4. повторяем п.3 до совпадения первой и последней (полигон замнут) , опустошения перечня линий или возникновения лупа - полигон не замкнут.

Если нужен код на VB готов дать.

Саш, пасиб, но VB в php плохо встраивается :slight_smile: Я ровно это сейчас и пишу. Просто сначала тормознул и написал исходя из того, что все линии в одну сторону идут. То, что этот полигон замкнут, мне проверять не надо, я его ручками весь замкнул.

Нифига… Прозевал что-то… Ушел править…

Как думаете, а что будет, если при импорте через осмосис почасовых обновлений я на один импорт отключу обрезку по полигону. И как раз перед этим обновлением передерну пути, составляющие границу, чтобы они пошли обновленными. Получится у меня закачать их полностью в локальную базу? Или импорт вообще провалится, потому что в базе будут отсутствовать объекты, которые раньше отрезались полигоном?

Суть в чем - полигон, по которому идет обрезка, во многих местах коцает границу и у меня в базе нехватает и путей, и точек. Писать парсер для xml не хочется, ибо есть готовый скрипт для базы, то есть хочется в базу как-то затянуть всю границу… Что думаете? Или дешевле закачать свежий planet.osm и порезать его не полигоном, а заведомо бОльшим ббоксом? Отработать на нем границу, потерпеть недельку и снова закать планету, обрезав ее уже по новому полигону?

Запускаю осмосис:
7z e -so “E:\osmosis\planet-090701.osm.bz2”|osmosis --fast-read-xml-0.6 file=- --log-progress-0.6 --bounding-box left=19.43 right=180 top=83 bottom=41 --write-mysql-0.6 user=“osm” database=“osm” forceUtf8=yes validateSchemaVersion=no

Получаю:
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.

Что делаю не так???

Бред какой-то, не работает с тойже ошибкой даже
osmosis --fast-read-xml-0.6 file=- --write-xml file=“1.osm”

nightly osmosis заработал только на write-xml про write-mysql пишет, что нет у него такого типа задач… Прям мистика какая-то…

Что-то в мейл-листе(?) пробегало про смену названий команд

ушел искать

UPD Нашел
http://wiki.openstreetmap.org/wiki/Osmosis/DetailedUsage#API_Database_Tasks

Заработало… Значит завтра постараюсь собрать правильный полигон для границы.

Надеюсь, что обрезка будет проводиться не строго по границе, а с небольшой добавкой.
А то полигоны на границе , например река, по руслу которой и проходит граница, режутся очень забавно. В результате получаются самопересекащиеся полигоны, захватывающие вместо территории до границы кусок суши.

Для начала буду экспериментировать с опциями обрезки, в частности включать полностью задеваемые пути и реоейшены. Если не поможет - придется ручками править файл полигона, расширяя его. Потому что алгоритм автоматического расширения полигона мне в горлову не приходит. Только если делить его на четыре части по горизонтали и вертикали и увеличивать каждую в свою сторону. Но, боюсь, могут получиться глюки… А руками 22000 точек править будет непросто…

Перекроил дефолтную схему базы, убрал лишние индексы и foreign key constraints, из-за которых сбивался иморт, добавил свои индексы, отказался от innodb, ибо вроде как для моих задач myisam получается быстрее. Разнес базу с исходными данными и базу с производными по разным жестким дискам, надеюсь это положительно скажется на скорости. Запустил импорт по-новой, посмотрим что получится.

С трудом и танцами с бубном импорт я завершил. Но теперь умерло обновление… Опять ошибка про то, что процесс не может использовать pipe… Всю вики и девлист облазил, ничего не нашел…