Импорт OpenStreetMap. От бинарного исходника к таблице в БД в несколько шагов

[lokks]

А почему был выбран Osmosis, а не Imposm или osm2pgsql?
У последнего и обновление недавно вышло.
lists.openstreetmap.org/pipermail/dev/2019-August/030720.html

CREATE TABLE power_lines (
…
geom geometry
)

Со времен первого постгиса не встречал такой записи, сейчас явно идет явное указание типа и проекции типа geom geometry(LineString,4326)

[provotor]

А почему был выбран Osmosis, а не Imposm или osm2pgsql?

Всё просто — библиотека сейчас способна работать в составе нашего ПО, которое также на Java. Добавление новых «слоев» производится путем подкидывания нового XML файла. Встраивание osm2pgsql было бы несколько более трудоемким, но скорее всего, работало бы тогда быстрей.

явно идет явное указание типа и проекции типа geom geometry(LineString,4326)

Вы правы, надо подправить. Только нужно проверить, какой тип данных может попадаться при импорте в эту таблицу. В данном конкретном случае будет скорее либо MULTILINESTRING, либо геометрия и вправду нетипизирована.

[lokks]

Точно, в тексте же вы сами упоминали про библиотеки)

Мультики — да, более универсальный выбор. Сам обычно делаю поле таким и в обработке просто ST_Multi(geom) прописываю, спасает от ошибок в будущем.

[freeExec]

Как-то странно, встраивать в ПО надо поддержку SQL, а не процесс импорта. А из ваших уст звучит, что я написал программу на С++ и поэтому не могу использовать bash для подготовки данных.

[provotor]

Я не совсем вас понял. Речь была о выборе библиотеки для обработки OSM данных. Конвертация в БД лишь малая часть, того что пришлось делать. Osmosis предоставлял несколько бОльшее количество нужных операций. Помимо этого многие вещи дорабатывались под наши нужды. Плюс ко всему всё это проще и быстрей в разработке, чем если сопрягать с плюсовым кодом или командной строкой, что в данном случае было немаловажно.
Или вы о чем то другом?

[freeExec]

Да, я об этом. Мне кажется изобретать велосипед как из точек склеить полигон с дыркой не так уж быстр в разработке, как давно отлаженный инструмент по импорту данных в БД.
Но возможно вы можете рассказать, что за большая часть, что пришлось делать и где нужен был osmosis?

[provotor]

Мне кажется изобретать велосипед как из точек склеить полигон с дыркой не так уж быстр в разработке

Те два дня стоили того, чтобы как минимум более глубоко понять структуру данных в OSM.

как давно отлаженный инструмент по импорту данных в БД

Подобный инструмент и был выбран. Каких либо принципиальных проблем с ним не имел.

где нужен был osmosis?

Основные функции — вытягивание метаданных из pbf, вырезка pbf файла (по прямоугольнику, произвольному многоугольнику, конкретным административным границам, радиусу и центральной точки), конвертация в БД.
Как ни странно, он был отчасти использован как фреймворк. Использовались многие классы, например класс Bound помимо хранения прямоугольника координат, имеет кучу полезных готовых функций. Ну или, например, интерфейс командной строки тоже был готовым, оставалось только добавить немного кода и нужная задача была доступна в том числе через командную строку.
Ну и еще раз повторюсь — сопрягать куски ПО через вызов из Java командной строки или запуска через JNI было бы не совсем обосновано в нашем случае.

что за большая часть, что пришлось делать

Развертывание БД, импорт/экспорт Shape, конвертация в плоские таблицы на основе конфигурационных файлов, валидация данных для определеннного набора слоев и атрибутов (Shape, БД, стили Geoserver). Также реализация поиска по объектам. Это навскидку, новые функции еще добавляются.