Фигня там какая-то происходит (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) и
нелинейных искажений с этим связанных. Но для небольшой картинки
это вполне приемлимо.
Да знаю Но больше, похоже, некуда. Разработчики советуют переносит все действия чтения в “Открыть файл” одним из фильтров (как pbf и opendata), но вставка из буфера всё равно требует отдельной кнопки.
Что нибудь можно сделать, что бы вращение картинки было более предсказуемым? В идеале, конечно, лучше подгонять к горизонтали картинки рабочую область, что было бы логичней. Ну раз делам наоборот, то желательно, что бы это было менее эмоционально, чем у меня сейчас… Ну хотя бы отмечались метки за которые можно тянуть с предсказуемой скоростью, в предсказуемом направлении сию картинку для вращения…