JOSM - PicLayer

Ilis · 2012-01-31 12:44:02

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

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

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

Вроде всё

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

AlexTheTux · 2012-01-31 15:03:25

А вот хочется пожаловаться на такую проблему - уж не знаю, 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?

Last edited by AlexTheTux (2012-01-31 21:45:56)

Larry0ua · 2012-01-31 15:14:30

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

Sergey Astakhov · 2012-01-31 17:16:07

AlexTheTux wrote:

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

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

usm78-gis · 2012-02-01 01:22:00

Larry0ua wrote:

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

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

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

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

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

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

Larry0ua · 2012-02-01 10:29:20

usm78-gis wrote:

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

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

iav · 2012-02-01 10:42:09

Larry0ua wrote:

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

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

Larry0ua · 2012-02-01 10:45:30

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

iav · 2012-02-01 10:49:50

Larry0ua wrote:

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

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

usm78-gis · 2012-02-16 23:09:24

Larry0ua wrote:

[ с радостью приму патч в подарок

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

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

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

usm78-gis · 2012-02-16 23:23:52

Larry0ua wrote:

вообще надо посмотреть исходники, как и что с этими проекциями происходит.

Фигня там какая-то происходит (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();
    }

Larry0ua · 2012-02-17 08:51:13

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

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

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

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

Larry0ua · 2012-02-17 10:58:23

AlexTheTux wrote:

А вот хочется пожаловаться на такую проблему - уж не знаю, 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?

Знаете, у меня не получается повторить. сгенерировал файл 7Кх7К, пять раз открыл без удаления слоев - на шестом свалилось. удалил две штуки, получилось добавить еще.

dkiselev · 2012-02-17 11:36:37

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

esaulenka · 2012-02-17 11:38:41

Может, от явы зависит?

У меня что-то похожее с обычными слоями (данные + треки) происходит. Десяток раз скачиваешь - - заливаешь - удаляешь локальную копию (актуально, например, при работе с валидаторами, когда по карте "прыгать" приходится), и всё, кирдык - валится.

WinXP, версию явы не помню - она дома (что Sun предложил, то и скачал ).

Larry0ua · 2012-02-17 11:46:57

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

usm78-gis · 2012-02-17 21:25:11

Larry0ua wrote:

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

Если сильно не лезть в детали (и для простоты не трогать третью координату-высоту), то "проекция" это функция пересчета пары (longitude,latitude) в градусах,
в (easting,northing) в "метрах"

f(longitude,latitude,parameters)={(easting,northing)}

К параметрам (parameters) относятся собственно тип проекции, некий набор числовых параметров в зависимости от типа и
параметры Земли как эллипсоида (главные оси/эксцентриситет, положение центра в пространстве и т.п.: коротко Datum).
Самой распространенным типом проекции можно считать "Гаусса-Крюгера" (он же "трансверсальный меркатор"): его любят в
кадастрах, дядюшка Сэм, североатлантические союзники и другие генштабы.
Прелесть его в том, что (easting,northing) это метры системы SI внутри области определения (т.н. "зоны", к ГУЛАГу отношения не имеет),
и по картам можно прямо мерять расстояния и углы "линейкой и транспортиром".
В ОСМ "основным" типом проекции является "сферический меркатор", так как все slippy maps гуглов, яху и разных бингов сделаны
в ней (ну и mapnik по образцу и подобию гуглов). Область определения у нее почти глобальная (за исключением полярных регионов >~+-85°),
но раcстояния между 2 точками так просто не померяешь...
"сферический" он потому, что Земля считается сферой с радиусом R=6378137 метров.
Для определеня проекций и их проекций удобно применять т.н. номенклатуру proj4 http://trac.osgeo.org/proj
"Гаусс-Крюгер/трансверсальный меркатор" в ней называется "+proj=tmerc", а обычный меркатор просто "+proj=merc"
У "трансверсального меркатора" есть в общем случае числовые параметры:

+k= +x_0= +y_0= +lat_0= +lon_0=

и параметры эллипсоида (+ellps=) и смещения центра эллипсоида относительно центра масс (+towgs84=)
Некоторые (большинство применяемых на практике в непостсоветском пространстве) проекции стандартизованы
под т.н. EPSG кодами, т.е. просто числами, например

EPSG:4326 -> WGS 84 -> +proj=latlong +ellps=WGS84 +towgs84=0,0,0,0,0,0,0
EPSG:3857 -> Pseudo-WGS-84 Spherical Mercator -> +proj=merc +a=6378137 +b=6378137 +towgs84=0,0,0,0,0,0,0 ...
EPSG:3395 -> WGS 84 / World Mercator ->  +proj=merc +ellps=WGS84 +towgs84=0,0,0,0,0,0,0
EPSG:32635 -> WGS 84 / UTM zone 35N -> +proj=utm +zone=35 +ellps=WGS84 +datum=WGS84
она же
EPSG:32635 -> WGS 84 / UTM zone 35N -> +proj=tmerc +k=0.9996 +x_0=0 +y_0=0 +lat_0=0 +lon_0=27 +ellps=WGS84 +towgs84=0,0,0,0,0,0,0
или мои любимые
EPSG:3352 -> Pulkovo 1942 / CS63 zone C2 -> +proj=tmerc +lat_0=0.1 +lon_0=27.95 +k=1 +x_0=2250000 +y_0=0 +ellps=krass +towgs84=24,-123,-94,0.02,-0.25,-0.13,1.1
EPSG:2394 -> KKJ / Finland zone 4 -> +proj=tmerc +lat_0=0 +lon_0=30 +k=1 +x_0=4500000 +y_0=0 +ellps=intl +towgs84=-96.0617,-82.4278,-121.7435,4.80107,0.34543,-1.37646,1.4964

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

Это параметры датума WGS84.

usm78-gis · 2012-02-17 21:46:22

Какое все это имеет отношение к аффинным преобразованиям:
при пересчете одного "трансверсального меркатора" в другой
достаточно сделать параллельный перенос и поворот.
На этом основана уродливая система "секретных ключей перехода"
во всевозможных "местных системах координат".
При пересчете "трансверсального меркатора" в "сферический меркатор"
все несколько сложнее из-за скалирования на ~1/cos(latitude) и
нелинейных искажений с этим связанных. Но для небольшой картинки
это вполне приемлимо.

akks · 2013-07-12 08:13:40

Кнопки переедут в меню "Снимки"/ "Imagery", OK?

см. также http://josm.openstreetmap.de/ticket/6355 и http://forum.openstreetmap.org/viewtopi … 77#p346577

Last edited by akks (2013-07-12 08:15:49)

Zverik · 2013-07-12 09:28:44

В Imagery чревато без меры кнопки добавлять: у многих это меню и так излишне длинное из-за огромного списка подложек.

akks · 2013-07-12 09:47:43

Zverik wrote:

В Imagery чревато без меры кнопки добавлять: у многих это меню и так излишне длинное из-за огромного списка подложек.

Да знаю Но больше, похоже, некуда. Разработчики советуют переносит все действия чтения в "Открыть файл" одним из фильтров (как pbf и opendata), но вставка из буфера всё равно требует отдельной кнопки.

Last edited by akks (2013-07-12 09:49:47)

luiswoo · 2014-01-16 02:01:21

Что нибудь можно сделать, что бы вращение картинки было более предсказуемым? В идеале, конечно, лучше подгонять к горизонтали картинки рабочую область, что было бы логичней. Ну раз делам наоборот, то желательно, что бы это было менее эмоционально, чем у меня сейчас… Ну хотя бы отмечались метки за которые можно тянуть с предсказуемой скоростью, в предсказуемом направлении сию картинку для вращения…

kisaa · 2014-01-16 05:42:36

Shift держать не пробовал?

luiswoo · 2014-01-16 09:23:41

Спасибо, вон оно значит как…

Воспользуйтесь мышью. Зажимая SHIFT при вращении или масштабировании вы улучшите точность.

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

Announcement

#51 2012-01-31 12:44:02

Re: JOSM - PicLayer

#52 2012-01-31 15:03:25

Re: JOSM - PicLayer

#53 2012-01-31 15:14:30

Re: JOSM - PicLayer

#54 2012-01-31 17:16:07

Re: JOSM - PicLayer

#55 2012-02-01 01:22:00

Re: JOSM - PicLayer

#56 2012-02-01 10:29:20

Re: JOSM - PicLayer

#57 2012-02-01 10:42:09

Re: JOSM - PicLayer

#58 2012-02-01 10:45:30

Re: JOSM - PicLayer

#59 2012-02-01 10:49:50

Re: JOSM - PicLayer

#60 2012-02-16 23:09:24

Re: JOSM - PicLayer

#61 2012-02-16 23:23:52

Re: JOSM - PicLayer

#62 2012-02-17 08:51:13

Re: JOSM - PicLayer

#63 2012-02-17 10:58:23

Re: JOSM - PicLayer

#64 2012-02-17 11:36:37

Re: JOSM - PicLayer

#65 2012-02-17 11:38:41

Re: JOSM - PicLayer

#66 2012-02-17 11:46:57

Re: JOSM - PicLayer

#67 2012-02-17 21:25:11

Re: JOSM - PicLayer

#68 2012-02-17 21:46:22

Re: JOSM - PicLayer

#69 2013-07-12 08:13:40

Re: JOSM - PicLayer

#70 2013-07-12 09:28:44

Re: JOSM - PicLayer

#71 2013-07-12 09:47:43

Re: JOSM - PicLayer

#72 2014-01-16 02:01:21

Re: JOSM - PicLayer

#73 2014-01-16 05:42:36

Re: JOSM - PicLayer

#74 2014-01-16 09:23:41

Re: JOSM - PicLayer

Board footer