Обсуждение Beta версий (тестирование, баги, замечания)

[User_tester]

Поправьте, пожалуйста!



1. В отличие от остальных дорог из той же категории, в исходнике не отображаются иконками префиксы ~[0x01] - ~[0x06] перед:

0х001A Паром FERRY
0х001B Брод INTERNATIONAL_FERRY

Паромы - это тоже дороги и поэтому располагаются в соответствующей категории "дороги". В Гармине паромы, наряду с остальными дорогами, могут обозначаться иконками. Трансляция префикса для паромов в шейпы ведётся правильно. Проблема только в отображении в исходнике в МГЕ.

2. И по объекту 0x001B напомню давние замечания от меня и Dark_Diver: необходимо поправить выделенное жирным курсивом некорректное описательное название "Брод" на правильное "Международный паром".

[Alex]

Сделаем. Помним об этом.

[DarkDiver]

А по поводу вот этого вопроса будут официальные комментарии?
http://www.micro-gis.com/forum/viewtopi ... 2910#p4512

[Fencer_Silver]

Работаем.... Не покладая рук.....

[Fencer_Silver]

А по поводу вот этого вопроса будут официальные комментарии?
http://www.micro-gis.com/forum/viewtopi ... 2910#p4512

Ну, разгреб, немного, могу прокомментировать:
В силу неоднородности СК 42, при простом преобразовании МОГУТ получаться ошибки около: Дельта X = 21,4 м, Дельта Y = –2,6 м.
Это правда. Для более точного преобразования необходимо учитывать неоднородность СК42. Сейчас используются приближенные формулы преобразования СК42, которые задают ориентировку эллипсоида Красовского относительно общеземного эллипсоида WGS–84. Для более точного преобразования необходимо учитывать неоднородность СК42.
К, сожалению, это проявляется , например, и в МапИнфо.

Пример ошибки: осевые линии дорог в "СК42" , а маршрутные точки в WGS–84 (МапИнфо)

1.png (23.8 КБ) 10222 просмотра

В принципе, на такую точность при преобразованиях, мы не рассчитывали с самого начала. Это сейчас вопрос поднялся для СК42, но у нас поддержано более 100 систем координат. Для этого и введено и смещение растров (в том числе и ECW, JPEG2000), а так же On-Line подложки.

Добавлено спустя 15 минут 58 секунд:
А вот и ошибка при преобразованиях в АркГис

Источник
http://mitrichtools.narod.ru/Files/GeoTransform.ppt

[Alex]

MicroGISEditor обновление v1.0.11.569b

 История изменений:

Версия 1.0.11.569b 18.03.2013

- Добавлены: встроенные загрузчики изображений (для карт формата OziExplorer): BMP, GIF, TIF, JPG, PNG. Загрузка будет осуществляться встроенными загрузчиками, при неудачной попытке загрузки средствами Windows;
- Изменено: увеличено количество загружаемых изображений, (для карт формата OziExplorer);
- Изменено: при нахождении ошибок в дереве адресов, все узлы ветки содержащие ошибки будут подсвечены красным;

[Fencer_Silver]

Для тех, кто будет пользоваться Ozi растрами - загрузка рисунка в формате TIF - поддержана только для сжатия LZW, ну и естественно, без сжатия то же. Все остальные (PackBits, JPEG, ZIP, JPEG, Huffman и т.д.) - не поддержаны.

[DarkDiver]

- Добавлены: встроенные загрузчики изображений (для карт формата OziExplorer): BMP, GIF, TIF, JPG, PNG. Загрузка будет осуществляться встроенными загрузчиками, при неудачной попытке загрузки средствами Windows;
- Изменено: увеличено количество загружаемых изображений, (для карт формата OziExplorer);

Спасибо! будем тестить.

Добавлено спустя 8 минут 36 секунд:

В силу неоднородности СК 42, при простом преобразовании МОГУТ получаться ошибки около: Дельта X = 21,4 м, Дельта Y = –2,6 м.
Это правда. Для более точного преобразования необходимо учитывать неоднородность СК42. Сейчас используются приближенные формулы преобразования СК42, которые задают ориентировку эллипсоида Красовского относительно общеземного эллипсоида WGS–84. Для более точного преобразования необходимо учитывать неоднородность СК42.
К, сожалению, это проявляется , например, и в МапИнфо.
В принципе, на такую точность при преобразованиях, мы не рассчитывали с самого начала. Это сейчас вопрос поднялся для СК42, но у нас поддержано более 100 систем координат. Для этого и введено и смещение растров (в том числе и ECW, JPEG2000), а так же On-Line подложки.
А вот и ошибка при преобразованиях в АркГис

Да, проблема действительно наблюдается не только в MGE, ее причины тоже понятны.
Возможно ли в будущем повысить точность преобразований в MGE?

[DarkDiver]

Не корректно сохраняются пути к аттачам, в случаях когда каталоги имеют названия на русском языке:

;@FILE,"D:\?????????\??????? ?????????\public\tracks\3.gpx",1
;@FILE,"D:\?????????\??????? ?????????\public\tracks\4.gpx",1
;@FILE,"D:\?????????\??????? ?????????\public\tracks\5.gpx",1
;@FILE,"D:\?????????\??????? ?????????\public\tracks\Current2.gpx",1
;@FILE,"D:\?????????\??????? ?????????\public\tracks\Current.gpx",1

[User_tester]

Не корректно сохраняются пути к аттачам, в случаях когда каталоги имеют названия на русском языке:

Проверил у себя. У меня всё исправно, пример:

Код: Выделить всё

;@FILE,"D:\Карты\Обновленная\Треки\Из поездки\Разведка 2012.11.06.gdb",1
;@FILE,"D:\Карты\Обновленная\Свежак\!Важное.gpx",1
;@FILE,"D:\Карты\Обновленная\Треки\Старые\2011.12.02.gdb",0
;@FILE,"D:\Карты\Обновленная\Дополнения\Минская область\POI.gdb",1

CodePage=1251
LblCoding=9

Посмотри, может в кодировках засада?

[Alex]

Возможно ли в будущем повысить точность преобразований в MGE?

Сделать можно всё, но полученным инструментом смогут пользоваться только настоящие геодезисты, картографы и прочие специалисты. Да и к тому же инструмент не попадает в ценовую политику редактора в целом.
Инструмент получится не из разряда: "в 2 клика".

[DarkDiver]

Alex, то что принципиально задача решаема - это я и так знаю Global Mapper - наглядный тому пример.
Меня как раз таки интересует именно реализация в MGE, возьметесь ли вы повышать точность преобразований, пусть не прямо сейчас, а чуть позже - в будущем, или нет.

[Alex]

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

[DarkDiver]

Не корректно сохраняются пути к аттачам, в случаях когда каталоги имеют названия на русском языке:

Проверил у себя. У меня всё исправно, пример:
CodePage=1251
LblCoding=9
Посмотри, может в кодировках засада?

Даже не мог предположить, что сохранение путей к трекам зависит от настроек в заголовке карты. То была тестовая карта, поэтому в заголовок не заглядывал.
Спасибо! Вопрос снят.

Добавлено спустя 9 минут 36 секунд:

Только в случае выпуска какой нибуть версии PRO или по крайней мере если без этого станет невозможно двигаться дальше. Но это точно не сейчас и не в этой версии. Подобного рода сложные инструменты ведут к потере некоего сегмента пользователей. Так что подобного рода реализации должны быть оправданными.

Ок, не сейчас, так не сейчас. Совсем не понятно только, как это может привести к потере сегмента пользователей. Для пользователя то все останется по прежнему - загрузил данные, программа пересчитала из Пулково в ВГС84, только сделала это точнее чем сейчас. Весь математический механизм пересчета хоть и станет сложнее, но как был, так и будет по прежнему скрыт от пользователя.

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

Да ну ты брось какие тут могут быть обиды, именно такой прямой ответ меня и интересовал.
Просто я теперь буду иметь ввиду, что в случаях, когда такая погрешность критична, я буду заранее перепроецировать исходные данные при помощи Global Mapper.
Ну и буду надеяться, что может быть в будущем вы еще пересмотрите этот вопрос

[Alex]

Это правильно. Именно GlobalMapper я бы и по рекомендовал. А вообще - время покажет ...