Ура! Обновился тестед и плагин. Подложил картинку, замечательно её привязал (с учётом того, что она получена кривой склейкой, пришлось привязывать два раза кусками по отдельности.)
Небольшие нарекания:
маркеры получились совершенно неухватистые, при этом никак не показывается что они становятся активными;
кнопки панели запутали мне мозг
Предлагаю сделать так, что при наведении мыши на активную область маркера маркер меняется и выглядит активным. На кнопке, которая соответствует добавлению и изменению маркеров вместо стрелки нарисовать сам маркер. Кнопку удаления маркера вообще убрать, а удаление маркера делать с контролом или шифтом при активном инструменте управления маркерами. На кнопке трансформации картинки нарисовать три маркера и стрелки между ними. Стоит, наверное, сами маркеры сделать намного меньшим размером (расцветку оставить, она хороша), особым образом выделить область активности маркера и саму эту область сделать побольше.
Вроде всё
В остальном это стал мегарульный инструмент, которого я всегда ждал!
А вот хочется пожаловаться на такую проблему - уж не знаю, 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?
Я о добавлении тэга
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 (во всяком случае пока что, и не планируют) - иначе реальностью была бы привязка по более чем трем точкам и все-все-все… Думаю, именно это и есть причина, почему просто нельзя привязать карту полумира, да и почему появляются ошибки на углах карт более мелких областей…
так понимаю, что это параметры только одной из проекций и не подойдет для общего случая?
Знаете, у меня не получается повторить. сгенерировал файл 7Кх7К, пять раз открыл без удаления слоев - на шестом свалилось. удалил две штуки, получилось добавить еще.
У меня что-то похожее с обычными слоями (данные + треки) происходит. Десяток раз скачиваешь - - заливаешь - удаляешь локальную копию (актуально, например, при работе с валидаторами, когда по карте “прыгать” приходится), и всё, кирдык - валится.
WinXP, версию явы не помню - она дома (что Sun предложил, то и скачал ).
так, ну я описал же юзкейс, на котором у меня работает, а у человека - нет. возможно, действительно глюк в джаве на его машине. у меня память освобождается, хоть и не сразу, по запуску GC или по запросу, так и должно же быть
Если сильно не лезть в детали (и для простоты не трогать третью координату-высоту), то “проекция” это функция пересчета пары (longitude,latitude) в градусах,
в (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 кодами, т.е. просто числами, например
Какое все это имеет отношение к аффинным преобразованиям:
при пересчете одного “трансверсального меркатора” в другой
достаточно сделать параллельный перенос и поворот.
На этом основана уродливая система “секретных ключей перехода”
во всевозможных “местных системах координат”.
При пересчете “трансверсального меркатора” в “сферический меркатор”
все несколько сложнее из-за скалирования на ~1/cos(latitude) и
нелинейных искажений с этим связанных. Но для небольшой картинки
это вполне приемлимо.