Прежде всего от себя хочу написать, что есть альтернативный вариант: использовать уже готовое решение. Например, мне очень понравилась библиотека Osmapi для Python. Обратите внимание на неё, она может сильно упростить жизнь. Мне очень понравилось получать нужные мне объекты (единичные) через неё. Ещё она может загружать данные в OSM, но этот вариант я на практике не проверял.
Сам хотел заняться импортом, даже начал писать скрипт на Python. Хотел создавать osm-файл, который заливал вручную через JOSM. Тоже читал документацию, понял что ничего не понял и решил действовать методом тыка (но это костыльный способ, на практике не проверял, у меня не дощло до импорта на этапе проверки имеющихся объектов в OSM):
Открываю сайт OSM и иду какой-нибудь отдельностоящий дом. Приближаю до максимума и уменьшаю размеры экрана чтобы на экране (примерно вот так):
Нажимаю кнопку “Экспорт” (сверху). Далее, не меняя размера экрана, синюю кнопку “Экспортировать”. В резальтате мы должны получить файл “map.osm”.
2.1. Не обязательно: открываем в блокноте этот файл и смотрим что получили. В идеале чтобы там были только те объекты, которые нужно изменять, например для здания 4 node + 1 way
Делаем копию файла (изначальное состояние, которое не трогаем и новую версию, которую будем изменять в следующих пунктах).
Открываю JOSM, ничеге не скачиваю, открываю файл (либо кнопка с синей папкой в верхнем меню, либо Файл→Открыть, либо Ctrl+O). В резальтате мы должны увидеть на экране нашу скачанную область.
Изменяем что-нибудь в JOSM в зависимости от требований, например:
двигаем какую-нибудь точку
добавляем какой-нибудь тег к уже существующему объекту
изменяем существующий тег
удаляем существующий тег
добавляем новый объект (например, новую точку)
меняем существующую линию (например, добавляем в неё новые точки)
удаляем объекты
Не отправляем сделанные изменения. Сохраняем изменения (либо кнопка с дискетой в верхнем меню, либо Файл→Сохранить, либо Ctrl+S).
В результате мы должны получить 2 файла, которые отличаются друг от друга сделанными изменениями. Открываем оба файла и смотрим, что изменилось.
Дополнительное упражнение для проверки (чтобы убедиться, что способ рабочий), делаете на свой страх и риск:
Скачиваем любую небольшую область, которую знаем.
Делаем копию (бэкап) файла.
Открываем файл в JOSM, делаем какое-нибудь полезное изменение:
добавляем какой-нибудь тег к имеющемуся зданию (почтовый индекс, этажность)
изменяем существующий тег
добавляем какой-нибудь объект (например, магазин)
…и так далее.
Сохраняем изменения на диск.
Отправляем на сервер и (если всё прошло успешно), убеждаемся что всё прошло нормально.
От себя хочу заметить, что передавать в OSM нужно только те объекты, которые Вы меняете
Реальная практика (сначала нужно сделать на тестовом сервере OSM)
Скачиваем какую-нибудь область.
Пишем скрипт который будет что-нибудь добавлять или изменять.
Скармливаем скрипту файл и получаем изменённый файл на выходе.
В первые разы нужно вручную проверить, что изменения верные и ничего не сломалось. У меня на отладку ушло несколько часов.
Пытаемся загрузить изменения в базу. Разумеется, для начала нужно начать с тестового сервера.
Я до этого ещё не дошёл, забил.
Изучаю JOSM по подсказке ув. Grass-snake и Osmium с точки зрения генерации файлов измнений. .osm для импорта получил, но он какой-то неполноценный вышел.
Могу ошибаться (поправьте меня кто знает), но вроде формат OsmChange существует для диффов, то есть когда сервер присылает нам те изменения, которые произошли за определённый период времени.
Если мы загружаем из JOSM в базу OSM, то нужно использовать JOSM file format. Тут меняется параметр: для новых объектов просто отрицательный id (уникальный, это важно), а для существующих объектов указывается действие action=‘modify’ при изменении или action=‘delete’ при удалении.
В том и беда, что у меня генерируется JOSM file format а не полноценный OsmChange. Поэтому и не даю результат на суд публики в привычном для импортов формате.
Домик для римера. Я загружаю небольшую область рядом с местом предполагаемого нахождения частов (прямоугольник в проекции Меркатора). Если в него попала точка с определённым тегов, то значит есть вероятность что это дубль и нужно не доавлять новую точку, а изменять существующую (после ручной проверки, разумеется).
Если загрузка будет через JOSM, то вроде он позволяет открывать свой тип файлов. А дальше проверяем эти объекты и загружаем в OSM как обычный пакет правок. В теории должно работать, разве нет?
Эх, жаль я забросил свой проект, сейчас бы уже точно сказал.
Да. Только в том и проблема, что по традиции нужно давать результат как .osc / osmChange а не JOSM file format. А так JOSM file format я опубликовал, только толку-то. Для JOSM geoJSON проще, который тоже давно есть…
Коллеги, опубликован osmChange. Получен не выходя из PostGIS, команда выгрузки опубликована. Документация импорта измненена, показаны представления, генерирующие сразу osmChange, дана ссылка, уточнён перечень тегов.
Пока что нет. Я не знаю о потребителях этого файлового формата кроме API OSM. Буду проверять JOSM сейчас.
Вопрос в том, что JOSM должен показать в случае верного файла? По сути мы сохраняем протокол действий на правах намерения. Никакие старые данные согласно указанному в описании имопрта намерению не меняются. Может надпись “Нет данных…” уместна?
FireFox хорошо подсвечивает внутренности файла.
Он должен показать новые объекты. В общем то вы можете скачать любую правку как xml и засунуть в жосм, и он покажет.
У вас не совпадает формат по описанию тегов, например, и странные пустые блоки в xml
<modify/><delete/><delete/>
В общем надо ещё дорабатывать, в том числе и нормальный UTF8
У меня теги раньше паковались напрямую. Теперь JOSM открывает. Впрочем, отличий от открытого geoJSON для импорта я не обнаружил … Цель усилий не понятна. Разве только в OSM API напрямую пихать из питона.
Для открывания в JOSM у файла нужно убрать .xml в конце и оставить .osc.
Спасибо, округление введено в документацию и репозиторий.
Сейчас PostGIS делает данные импорта в двух видах. Смысл этого мне до сих пор не понятен. Предъявлемый сейчас в репозитории файл .osc для выбранного способа загрузки данных ровно ничем не отличается от файла .geoJSON.
Может ли кто-нибудь мне пояснить как .osc используется в контексте обсуждения импорта? Что там можно такое увидеть, что не ясно из .geoJSON?
Согласен. Но, по определению содержания импорта из преамбулы, такого рода правки заведомо не планировались. Вот по столбам без этого никуда, если дело до них дойдёт.
Кстати, расширил теги по замечанию. contact:phone диспетчерской часов + operaror как подрядчик + owner как балансодержатель. Скоро обновлю файлы в репозитории.
.