Удалил C:\Documents and Settings\ilis\Application Data\JOSM\
Всё равно такая ошибка. Сломался йосм, помогите!
ЗЫ. И сообщения бы перенести в более подходящую тему, просьба модераторам.
Удалил C:\Documents and Settings\ilis\Application Data\JOSM\
Всё равно такая ошибка. Сломался йосм, помогите!
ЗЫ. И сообщения бы перенести в более подходящую тему, просьба модераторам.
Ilis, проблема вряд ли в плагине
usm78-gis
Матрица афинного преобразования в данном случае записана в сокращенной форме, М20=М21=0, М22=1 - принимаются по умолчанию. Это же принимается при расчете обратной матрицы. В ней, естественно, получаются те же значения на месте этих 0,0,1 и они отбрасываются для удобства записи в java2d AffineTransform
На счет ортогональности - понял, о чем речь, но не понял, каким оно сюда боком.
Кстати, если число точек больше 3, это уже не афинное преобразование…
На счет размерности ничего не могу сказать - это просто коэффициенты - из пиксельных координат картинки в josm-овские внутренние (в которых сдвиг записывается) - или наоборот
Это к вопросу о world файле, который тоже задает аффинное преобразование
m00
m01
m10
m11
m02
m12
но векторы (m00,m01) и (m10,m11) должны быть ортогональны
m00m10+m01m11=0
Т.е. любой world файл (а значит и для любого геотиффа с проекцией поддерживаемой josm)
коеффициенты можно прямо пересчитать в .cal
ok. остается разобраться, как josm-овские внутренние связаны с экранными пиксельными.
Итак, йосм у меня запустился, и плагин поставился и заработал.
Пробовал таскать точки, но поскольку они оказались почти на одной прямой, получилась полная лажа.
Вручную перемещать, масштабировать и вращать получается намного лучше. Что бы мне помогло? Всего лишь фиксация точки, вокруг которой производится поворот и масштабирование. Я бы совместил один перекрёсток на картинке и карте, зафиксировал бы эту точку, перешёл к другому перекрёстку и небольшими поворотами и масштабированием выровнял бы картинку по второй точке.
Поскольку уже реализовали постановку и фиксирование точек, то может добавить и описанную мной функциональность? Это вроде не сложно, а польза была бы огромной!
понимаю задачу, не представляю пока что, как ее организовать в плане интерфейса. может, если фиксирована только одна точка, то операции производить относительно нее?
Кстати, сейчас масштабирование, поворот и прочее делается относительно центра josm-экрана
Да, можно вокруг единственной установленной точки. Или вокруг только первой точки, если их несколько.
То, что вокруг центра, я вроде догадался. Но хотелось бы на крупном зуме очень точно поставить привязку, потом переместиться в другое место и там на крупном зуме очень точно прицелиться.
Пока писал, придумал ещё один способ. Делать преобразование по двум точкам, при этом сохраняя прямоугольность и соотношение сторон. (Забыл как такой тип преобразований называется).
Это вообще заменит сразу и поворот и масштабирование вокруг одной точки.
Вот реальный практический пример: геотифф 20020819_brovey8_2_4_5.tif с 16-битной палитрой,
сдвоенная сцена ландсат, 20281 на 25821 пикселов,
проекция UTM 35N
Origin = (438600,6932700)
Pixel Size = (15,-15)
Upper Left ( 438600.000, 6932700.000) ( 25d48'26.29"E, 62d31'12.72"N)
Lower Left ( 438600.000, 6545385.000) ( 25d55'47.67"E, 59d 2'36.52"N)
Upper Right ( 742815.000, 6932700.000) ( 31d42'28.12"E, 62d26'45.02"N)
Lower Right ( 742815.000, 6545385.000) ( 31d13'32.13"E, 58d58'44.17"N)
Center ( 590707.500, 6739042.500) ( 28d39'55.93"E, 60d46'35.35"N)
Из него создается 8-битный трехканальный .png (+world) файл с помощью gdal_translate.
piclayer хоть и справляется с 16-битным png, но josm при этом занимает 14ГБ в ОЗУ и работает “небыстро”.
$ gdal_translate -co worldfile=yes -of png -ot Byte -expand rgb 20020819_brovey8_2_4_5.tif 20020819_brovey8_2_4_5.png
20020819_brovey8_2_4_5.wld переименовывается для piclayer в 20020819_brovey8_2_4_5.pgw
$ cat 20020819_brovey8_2_4_5.pgw
15
0
0
-15
438607.5
6932692.5
Квадратные пикселы по 15 метров, никакого вращения, верхний левый угол в центре верхнего левого пиксела
(сдвинут на пол-пиксела=7.5 метра относительно Upper Left/Origin ( 438600, 6932700), как и положено )
piclayer сохраняет для него следующий .cal файл (в новом формате)
$ cat 20020819_brovey8_2_4_5.png.cal
#JOSM PicLayer plugin calibration data
#Sat Jan 21 17:08:49 CET 2012
POSITION_Y=6739042.5
POSITION_X=590707.5
M12=0.0
M11=1499.0209994075628
M10=0.0
M02=0.0
INITIAL_SCALE=1.0
M01=-0.0
M00=1496.619909949947
POSITION_X, POSITION_Y совпадает с Center ( 590707.5, 6739042.5), единицы “метры”.
M00,M11 (единицы “сантиметры/пиксел”, но установив INITIAL_SCALE=100 можно использовать “метры/пиксел”).
Вопрос: почему M11 не равно М00 и не равно 15 метрам ?
4 сантиметра / пиксел вроде бы как не много, но на 26000 пикселах
набегает немалая ошибка.
Не стоит ли пересмотреть функцию getMetersPerEasting()
как слишком грубую ?
/**
* Returns the distance in meter, that corresponds to one unit in east north
* space. For normal projections, it is about 1 (but usually changing with
* latitude).
* For EPSG:4326, it is the distance from one meridian of full degree to the
* next (a couple of kilometers).
*/
Такое есть в qlandkarte: привязка по 2 точкам с квадратными пикселами.
Что такое qlandkarte?
И почему не сделать такое в PicLayer?
Есть одна точка — вращение и масштабирование делаются относительно неё. Есть две точки — вращение и масштабирование делаются одновременно одной точкой относительно другой. Три точки — поведение нынешнее. Даже в случае трёх точек удобнее сначала в целом выровнять картинку по двум точкам, а потом добавить третью и скособочить картинку окончательно.
Можно ещё добавить функцию удаления точек привязки (например, щёлкнуть по ней с контролом).
usm78-gis, похоже, есть такая проблема. Если знаешь, как решить, с радостью приму патч в подарок
на счет qlandkarte - а что если пользователь хочет прямоугольную привязку без соотношения сторон и поворота - тоже по двум точкам реализуется ведь?
Сделайте, плиз, выравнивание по двум точкам! У меня проект огромного куска дороги лежит, подложить его нынешними средствами никакой возможности нет, промахи на полкилометра получаются
Что такое qlandkarte?
Программа такая http://qlandkarte.org
в основном для работы с гарминовскими девайсами,
но в ней есть и модуль привязки+создание геотиффов.
usm78-gis, похоже, есть такая проблема. Если знаешь, как решить, с радостью приму патч в подарок
Это тяжелое наследие EPSG:4326, ну и конечно меркатора. Для проекций типа UTM (Гаусс-Крюгер) и LCC она
в общем-то совсем не нужна, точный результат (внутри зоны) и так известен, но сейчас для любых проекций используется приближенная формула greatCircleDistance()
на cфере с радиусом 6378135 метра ( src/org/openstreetmap/josm/data/coor/LatLon.java)
* Computes the distance between this lat/lon and another point on the earth.
* Uses Haversine formular.
Конечно тут ни о какой сантиметровой точности и говорить не приходится.
на счет qlandkarte - а что если пользователь хочет прямоугольную привязку без соотношения сторон и поворота - тоже по двум точкам реализуется ведь?
Да, но это совсем просто сделать.
ИМХО, в большинстве “реальных” случаев применения piclayer есть отсканированная карта-схема, сделанная в
местной системе координат. У нее квадратные пикселы и разыскиваются только 4 неизвестных: сдвиг (x,y) , размер пиксела в метрах
и угол поворота к сетке ( aka “секретный” http://forum.openstreetmap.org/viewtopic.php?id=5928 )
Для этого 2х точек вполне достаточно.
Остается только реализовать такую привязку по двум точкам в piclayer
вот теперь все ясно на счет двух точек, спасибо! попробую реализовать на досуге
Чорт, я думал что я понятно объясняю
Ilis, usm78-gis, обновите плагин и скажите, это ли имелось ввиду?
Теперь картинка таскается за одну точку, крутится и растягивается за две, на трех - как обычно.
Еще добавил “удалить точку привязки” - может пригодиться. конечно, то, как это все реализовано в интерфейсе, мне сильно не нравится, но более очевидных путей я не вижу…
У меня чота не обновился… 27241 текущий.
27662 должен быть, на josm-latest проверять
У меня тестед… В него можно прикрутить? Если нет, то буду ждать нового тестеда…