JOSM - PicLayer

То, о чём прошу я, мне нужно для выполнения этих пунктов

Всё равно непонятно.

Не говоря уже о том, что свежевставленный рисунок уже отмасштабирован в экран.

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

Мне кажется, что начальное наложение — до того, когда можно поставить первую точку — можно сильно ускорить, избавившись от необходимости перключения режимов трансформации.
Мне кажется, это удобно сделать клавиатурой.

То есть с момента загрузки картинки и до установки второй точки работают кнопки:
awsd — смещения
qe — поворот
rf — масштабирование

Довести до людей информацию об этой возможности — например, тултипом на кнопках тулбара. Или вывести в правую колонку, где формы для редактирования данных, картинку с этой информацией

Да, е ещё по нажатию кнопок с цифрами 1, 2, 3 можно позиционировать в центр экрана установленный маркер соответствующего номера. Кроме того, список точек тоже можно держать в формочке в правой колонке. Снизу кнопки добавления, редактирования и поиска. При дабл-клике в правой панели на кнопке она ставится в центр экрана, при нажатии на кнопку редактирования можно потаскать маркер.

Всё это никак не отменяет существующих сейчас возможностей.

Как раз кроме режима трансформации больше ничего и не нужно.

Для управления с клавиатуры вообще никакие экранные кнопки не нужны.

Можно, конечно, и оставить, чтобы через пару месяцев убедиться, что они точно не нужны, и уж тогда выкинуть их :slight_smile:

Вы, видимо, всегда попадаете в масштаб.
А я вот нет.
И по нескольку минут двигаю картинку и догужаю куски, пытаясь найти у картинки и жосма хоть что-то общее. Я не вижу общих точек, поймите это. Я обрисовываю генпланы маленьких городков, где треков зачастую нет вообще, или есть по одному шоссе, и нарисованы 1 или 2 дороги. По масштабу я почти всегда промашиваюсь изначально в несколько раз.

Вам это не надо — хорошо, просто не пользуйтесь.
Мне же это облегчит жизнь.

Ладно, отложим этот разговор, пока у меня не поставится новая версия.

У меня необходимость в плагине возникала всего лишь несколько раз, и это были рисунки дорог на несколько десятков километров. Я поочерёдно переключался между инструментами и масштабами, добивался крайне низкого качества привязки и рисовал с учётом вычисленных в уме поправок.

Последнюю дорогу я вообще не смог привязать сколько-нибудь хорошо и плюнул.

Потом появилась привязка по трём точкам. Я в несколько кликов в целом привязал дорогу несмотря на мешающуюся третью точку, и сразу понял перспективы такого подхода (правда не осилил выравнивание третей точки чтобы получить обратно прямоугольный рисунок (рисунок специфический, почти прямая дорога, и любое перемещение третьей точки его безнадёжно портит)). Этот подход интуитивный и точный. Надо всего лишь совместить характерные точки рисунка с точками на местности.

у меня josm-svn (+openjdk), piclayer 27662 : не хочет активировать кнопки.
Куда надо положить исходники плагина, чтобы ant их тоже пересобрал ?
Еще конечно просьба сохранять EPSG номер проекции в .cal

Чтоб активировались кнопки надо активировать слой (или мы о разных вещах говорим?)

Чтоб собрать исходники надо:


svn checkout http://svn.openstreetmap.org/applications/editors/josm
cd core
ant
cd ../plugins/piclayer
ant install

Про проекции пока ничего сказать не могу :slight_smile:

Ура! Обновился тестед и плагин. Подложил картинку, замечательно её привязал (с учётом того, что она получена кривой склейкой, пришлось привязывать два раза кусками по отдельности.)

Небольшие нарекания:

  • маркеры получились совершенно неухватистые, при этом никак не показывается что они становятся активными;
  • кнопки панели запутали мне мозг :slight_smile:

Предлагаю сделать так, что при наведении мыши на активную область маркера маркер меняется и выглядит активным. На кнопке, которая соответствует добавлению и изменению маркеров вместо стрелки нарисовать сам маркер. Кнопку удаления маркера вообще убрать, а удаление маркера делать с контролом или шифтом при активном инструменте управления маркерами. На кнопке трансформации картинки нарисовать три маркера и стрелки между ними. Стоит, наверное, сами маркеры сделать намного меньшим размером (расцветку оставить, она хороша), особым образом выделить область активности маркера и саму эту область сделать побольше.

Вроде всё :slight_smile:

В остальном это стал мегарульный инструмент, которого я всегда ждал!

А вот хочется пожаловаться на такую проблему - уж не знаю, PicLayer ли виноват, или архитектура плагинов в JOSM:

Имеем большущие привязанные в PicLayer растры, которые занимают в памяти сотни мегабайт. Если что - куски ген.планов.
Чтобы открыть такой кусок растра - нужно JOSM’у выдавать дополнительную память.
Я запускаю JOSM с параметром “выдать 1024 MB памяти”:
java -Xmx1024M -jar “C:\Program Files\JOSM\josm-tested.jar”
Для открытия куска растра этого хватает.
OK, поработали с этим растром, хотим загрузить другой кусок, которому нужно столько же памяти.
Одновременно с первым его открыть не получится - второму не хватает памяти.
Это ожидаемо.
Не ожидаемо тут то, что если удалить (закрыть) в JOSM первый открытый растр, то все равно открыть второй нет никакой возможности, поскольку, видимо, память никто не освобождает.
Возникает ошибка, что ему не хватает памяти, а размер процесса JOSM в операционной системе (windows, если что) не уменьшается.

Открыть следующий привязанный растр можно только одним способом - закрыть JOSM с потерей всех загруженных треков, скачанных областей, сабмитом измененных данных на сервер и т.д.
Иными словами, то, что я не могу открыть одновременно два привязанных растра в связи с их большими размерами - это нормально,
но то, что я не могу их открывать поочередно, не перезапуская при этом JOSM - абсолютно не нормально.
(и да - я знаю, что скачанные треки, скачанные данные, измененные данные - я могу сохранить локально перед перезапуском JOSM. Но речь идет о том, что память могла бы и освобождаться при закрытии растра в PicLayer.)

Если это не чинится в самом плагине и является ограничением JOSM - то может, разработчики плагина передадут это как проблему разработчикам JOSM?

дайте пример картинки, на которой воспроизводится проблема. возможно, реально починить…

По идее должно чиниться. Просто где-то ссылка на изображение остаётся висеть в памяти после удаления слоя.

Проблема была вот здесь в build.xml:


<property name="josm" location="../../core/dist/josm-custom.jar"/>

У меня вместо “core” “trunk”.

Я о добавлении тэга
SRS=EPSG:xxxxx к уже имеющимся M01=,M02=,… et al. в новом .cal формате.
Тогда при несовпадении с текущим SRS можно хотя бы
сделать предупреждение, ну а в перспективе и пересчитать
аффинное преобразование.

хорошая идея, на будущее может помочь

То есть при открытии картинки можно будет указать, что она в другой системе?

вообще надо посмотреть исходники, как и что с этими проекциями происходит. возможно, для начала придется просто ругаться, что проекции картинки и josm-а не совпадают

Только это… Ругайтесь, но не блокируйте, пожалуйста. Ну, кривовато немного…

Нельзя ли добавить формулу для distVincenty() из
http://www.movable-type.co.uk/scripts/latlong-vincenty.html
и использовать ее вместо greatCircleDistance ?
При этом, правда, надо бы параметры эллипсоида брать из Datum, а не
просто WGS84:


  var a = 6378137, b = 6356752.314245,  f = 1/298.257223563;  // WGS-84 ellipsoid params

Тогда эта формула будет работать во всех случаях.

Фигня там какая-то происходит (src/org/openstreetmap/josm/data/projection/Mercator.java):


    public Mercator() {
        ellps = Ellipsoid.WGS84;
        datum = WGS84Datum.INSTANCE;
        proj = new org.openstreetmap.josm.data.projection.proj.Mercator();
    }

    @Override
    public String toString() {
        return tr("Mercator");
    }

    @Override
    public Integer getEpsgCode() {
        /* initially they used 3785 but that has been superseded, 
         * see http://www.epsg-registry.org/ */
        return 3857;


EPSG:3857 это сферический меркатор, а с Ellipsoid.WGS84 будет уже EPSG:3395
Скорее всего этот кусок нигде не используется, иначе бы ошибки были бы грандиозные:


    public Mercator() {
        ellps = Ellipsoid.WGS84;
        datum = WGS84Datum.INSTANCE;
        proj = new org.openstreetmap.josm.data.projection.proj.Mercator();
    }

Так, расскажите плз кто-нибудь по быстрому, где можно почитать про проекции - какая между ними разница, для чего они нужны и тд?

Насколько я понимаю, практически все проекции непрямоугольные, и чтоб преобразовать координаты картинки на координаты карты нужно нелинейное преобразование, которое не поддерживается java2d (во всяком случае пока что, и не планируют) - иначе реальностью была бы привязка по более чем трем точкам и все-все-все… Думаю, именно это и есть причина, почему просто нельзя привязать карту полумира, да и почему появляются ошибки на углах карт более мелких областей…

так понимаю, что это параметры только одной из проекций и не подойдет для общего случая?