Можно для инструмента Q добавить проверку, что если координаты точки почти не сместились (или там сантиметры) то не метить их изменёнными.
А то получается, что уже оквадраченный дом нажимаешь ещё раз Q и он предлагает точки залить обратно в базу, хотя координаты до 7 знака не изменились.
Хорошо бы, но есть нюанс.
Из базы ОСМ координаты приходят с 7 разрядами, а после Q - координаты получают до 15 разрядов после запятой. Разница небольшая (<6.3мм), но если использовать координаты как базу для квадратизации больших объектов, то разница может набежать и в 7м разрядя.
ИМХО, лучше бы инструмент, который позволял снять отметку “измённый объект” если тэги/мемберы идентичны предыдущей версии, ну а для точек - координаты не отличаются в 7 знаках.
Кстати вопрос - а кто округляет до 7 знаков - JOSM или база?
Не совсем понял про “квадратизации больших объектов”. Ну и раз 7-й разряд это пол сантиметра, то специально для Q сделать хак - если первые 7 разрядов не изменились, значит мы и не изменяли объекты.
- Используем Q на большом объекте.
- Сохраняем в базу ОСМ.
- Загружаем из базы.
- Берём 2 близкие точки за базу и используем Q на объекте ещё раз - некоторые точки могут сдвинутся так, что в 7 разряде будет разница.
Ну и хорошо, тогда мы его сохраним, проблема-то. И кстати насколько это должен быть большой объект. В 99% случаев это дома, вряд ли кто-то лес ровняет.
Что-то после обновления java стал перезаписываться josm.jnlp и запись в него стала бесполезной… В принципе нашёлся даже правильный способ выделить webstart память. Вин способ трансформировался для федоры в это:
javaws -J-Xmx1024m -J-Djnlp.application.href=http://josm.openstreetmap.de/download/josm.jnlp "/home/пользователь/.cache/icedtea-web/cache/0/https/josm.openstreetmape/download/josm.jnlp"
Только минимальный объем нормально не устанавливается, в менеджере задач выделение выглядит так -Xms8m -Xms256m -Xmx1024m, хотя указывались только последние два…
Собственно вопрос: только у меня, после установки патченой java, при включении нового стиля джосма или подсветки адресации, начинаются эпические тормоза? Вроде, с выделением памяти всё в порядке, только загрузка процессора подскакивает под 100% при перемещении. Откатываюсь на “радужную” java – всё ок…
При скачивании данных вдоль трека, теперь не обновляется окно какой запрос из скольки сейчас скачивается.
Т.е. если джосм заявил что нужно 10 запросов, то в окне будет "Скачивание 1 из 10 (9 осталось). Раньше это работало корректно, и было видно сколько еще запросов осталось скачать.
Кто в силе - попровьте пожалуйста.
В JOSM есть инструментарий, чтобы объединить 2 мультиполигона с общей границей и с общими тегами?
Нет.
А такое сложно запилить?
Тоже иногда мучаюсь, но уже наловчился в полдюжину кликов делать
- Открываем на редактирование в диалоге первый релейшен
- Не закрывая диалог, выделяем членов второго
- То что подсветилось желтеньким - это общая граница, потом надо удалить из релейшена
- Добавляем всех членов второго, отказываясь от дублей
- Само сложное. То, что горело в п 3 - удаляем
Давно такое в хотелках весит. Проще всего восстановить из мультиполигонов полигоны, если это не границы, и объединить их. Сам стараюсь оные использовать только в крайних случаях из-за подобных проблем.
Ну и обратную операцию - распилить один полигон на два по заданной линии (линиям)
Для обычных полигонов есть - Alt-X
У меня есть два слоя (amenity=school и building=school), у каждого слоя может быть поле name (чаще всего name для школы присваивается только в одном слое, но бывает, когда одинаковый name присваивается и зданию школы, и ее территории). Если на один объект (то есть школу) у меня есть name сразу в двух слоях, тогда на карте они у меня дублируются, что выглядит не хорошо.
Предполагаю поступить так: выгрузить оба слоя в JOSM, затем оставить только те объекты, которые есть в других полигонах (building может показываться как точка или как полигон) и сами такие полигоны, потом удалить дублирующееся поле name в одном из слоев для каждого объекта, а потом все загрузить обратно в OSM. Подскажите, пожалуйста, как создать такую выборку из объектов, которые находят внутри полигонов, и самих полигонов, содержащих внутри себя точки или полигоны?
Вы в корне не правильно мыслите изначально.
Во первых amenity=school не подразумевает, что это здание вообще и никак. Здание это building=*. amenity=school без building — это территория школы. Вместе с building — это не посредственно школа.
building=school подразумевает что это здание школы (тип здания и его назначение), но без amenity - не является школой.
Я имею в виду случай, когда одинаковое поле name присваивается и паре building=school, в то время, как оно уже было прописано в amenity=school. Например, центр образования 1862 по адресу Черноморский бул., 6с1 в Москве. Там для каждого здания (а их там почти десяток) дублируется надпись “Центр образования № 1862”. Я не имею в виду, когда написано сразу же в одном объекте сразу amenity=school, building=school, name= *.
Лучше давать ссылки прямо на osm: http://www.openstreetmap.org/#map=18/55.64700/37.61440
Здесь, конечно же, почти всё неправильно. Составные здания мапятся вот так.
Название нужно ставить на полигон amenity=school.
А как следует мапить этот полигон, если территория школы сформирована частично забором, и частично стеной здания?
Использовать отношения http://wiki.openstreetmap.org/wiki/RU:Relation:multipolygon и для территории школы, и для ее здания.