Могу ошибаться (поправьте меня кто знает), но вроде формат 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 как балансодержатель. Скоро обновлю файлы в репозитории.
“Невозможно прочитать файл ‘Экспорт часов.osc’. Ошибка: Строка 15 столбец 76: Attribute name “crossorigin” associated with an element type “link” must be followed by the ’ = ’ character”