Экспорт в JNX

[garl]

блииин... такая нужная вещь! генштаб в JNX на eTrex 20/30 очень блекло отображается и немного пересвеченно, приходится перед экспортом долго и мучительно делать групповую обработку файлов кэша (увеличивать контраст, гамму) и только потом экпорт в JNX. Вобщем с нетерпением ждем этой фичи... Может примерно известно когда эта функция будет реализована? спасибо

ну мне пока не хватит квалификации, выход: просить активыных девелоперов заинтересованных в этом.

[vdemidov]

ну мне пока не хватит квалификации, выход: просить активыных девелоперов заинтересованных в этом.

А там квалификации много не нужно. Ничуть не больше чем для добавления прямого копирования. Просто передаете из провайдера рабочему треду объект пост-обработчик битмапок если нужно обрабатывать. И в рабочем треде проверяете его наличие и если есть, то плюете на настройки прямого копирования и в обязательном порядке декодируете битмапку, делаете постобработку, а потом кодирование.
Строчек 20 на все про все понадобиться.

[Draude]

Надо бы добавить опцию, позволившую бы сохранять тайлы из хранилища SAS напрямую (если они в формате JPEG, естественно).

Ушло в последнюю ночную сборку.
Тестируем, не стесняемся

Вчерась добрался до новой опции. Продублировал экспорт. Все очень даже хорошо работает, как и задумано.
Дополнил таблицу:


При этом как и ожидалось картинка карты на экране дисплея GPS при copy в SasPlanet и при copy в Mobat ничем не отличается


смотреть при двукратном увеличении

Скрины jnx сделанные в SasPlanet напрямую и в 95%, 75% качестве имеют несущественные отличия


смотреть при двукратном увеличении

Все чудненько, траблов при экспорте и навигации не заметил

[AlexWhiter]

Дополнил таблицу:

А что такое copy/comb?

[Draude]

Да вот для copy/comb комбинировал прямое копирование и Стиснення 75% :

[Draude]

блииин... такая нужная вещь! генштаб в JNX на eTrex 20/30 очень блекло отображается и немного пересвеченно, приходится перед экспортом долго и мучительно делать групповую обработку файлов кэша (увеличивать контраст, гамму) и только потом экпорт в JNX. Вобщем с нетерпением ждем этой фичи... Может примерно известно когда эта функция будет реализована? спасибо

Вещь нужная, но считаю нецелесообразным именно при экспорте в JNX иметь опцию "Применить коррекцию изображения".
Мои размышления:
1)мне такая фишка нужна и для других операций с выделенкою, скажем даже для банальной склейки в jpg или в тот же KMZ (не совать же такую фичу в каждый отдельный случай)
2) -экспорт в JNX , такой какой он сегодня есть работает довольно шустро.
3) -дополнительная групповая обработка изображения занимает довольно продолжительное время (смотри здесь) и соответственно оценка результата применения коррекции изображения отодвигается на неопределенное время, а когда результат не устроит, снова по новой? Можна конечно перед экспортом в JNX выводить какой либо тайл для каждого слоя отдельно собственно для предварительной оценки картинки, но тогда какой? Одним словом все это утяжеляет экспорт в JNX.

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

Вопрос:
"приходится перед экспортом долго и мучительно делать групповую обработку файлов кэша", какими средствами?
Я остановился на бесплатном FastStone Image Viewer, те же 34000 тайлов на лучшей конфигурации ПК а также без антивируса он делает за 17минут.
Фотошоп , Batch process с двумя-тремя корректирующими операциями в быстродействии уступает значительно.
ACDSee (скажем Pro 2) вылетает при обнаружении тайлов с одинаковыми именами (а они всегда у нас присутствуют (см.соседние горизонтальные тайлы ) .
Другие проги или не поддерживают структуру каталогов - подкаталогов, или не допускают перезапись картинок.

[Draude]

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

[Draude]

Проверил default значениея для масштаба прибора (уровня приближения) при экспорте в JNX в зависимости от выбранного уровня Zoom SasPlanet.
Данные параметры очень далеки от сложившихся на практике и не есть оптимальные как для зрительного восприятия так и для работы самих приборов (смотрел на garmin 62s, eTrex 30, Oregon 450, есть еще возможность поюзать Colorado 300, но это не столь важно).
Каждый раз при экспорте JNX в SAA Planet постоянно изменяю параметры "масштаб"
Нет, если производится экспорт в JNX выделенной области одного Zoom-уровня и от одного картосервиса, без нижнего ограничения то мирится можно.
Вчерась было немножко свободного времени, чего то надумал, чего то посчитал и поделюсь размышлениями.

скрытый текст: показать

В режиме карта (на GPS) имеется отрезок масштабной линейки (в метрах и км). Зная длину в пикселях этого отрезка пересчитал масштаб отображения растра в метрах на пиксель (m/пикс) для каждого уровня приближения прибора и назвал это разрешением (уровня приближения).
Для разных GPS Garmin по одинаковым масштабам прибора получил одинаковые значения.
Так вот идея затеи состоит в том, чтобы (при создании растра вообще, и в SAS Planet в частности) не вдаваясь в слишком сложные расчеты "прикинуть хрен к носу" и получить более-менее приемлемый результат.
Для SAS это оказалось не сложно. Поскольку при экспорте в ней не применяется ресайз, (более того, с внедрением последней хотелки тайлы могут попадать в JNX сборку вообще никак не тронутые: as there).
Соответственно изначально с тем разрешением (м/пикс), которое мы видим в нижней инфостроке рабочего окна SAS при соответствующем уровне zoom.
Так вот, если разрешение уровня zoom в SAS (уровень, который я планирую экспортировать в слой JNX и лицезреть этот слой в выбранном масштабе прибора) будет более-менее совпадать с разрешением девайса для выбранного масштаба,то я могу быть уверенным:
А) что такие параметры не будут уж слишком "утяжелять" быстродействие прибора;
Б) на дисплее GPS я буду видеть картинку примерно в том же масштабе что и в окне программы SAS .
Что имеем на сегодня.
Допустим я хочу слепить JNX из километровки генштаба z14, ландшафта Google z15, аэрофотосъемка кадастр Украинs z17 и Яндекс z19 .
Со значениями по умолчанию ничего приличного не получится.

скрытый текст: показать

Б) Километровку будем видеть при масштабе прибора 5km и практично ничего там не разберем. На 3km откроется Ландшафт Google z15, который еще будет присутствовать на 1,2km и тоже исчезнет до того, как что либо можно будет там различить. На 800m вступает кадастр z17 и еще за долго до открытия себя "во всей красе" выключится z19-тым от Яндекса.

А) Картинка в навигаторе на масштабе прибора 3km в нашем примере формируется из тайлов Ландшафта Google z15 , но из расчетов следует что для масштаба прибора 3km более подходят тайлы из Z12. Принимая во внимание что для одного тайла z12 необходимо аж 64! тайла z15, можно только догадываться как мы "усложним жизнь нашему девайсу" используя существующие default значения

скрытый текст: показать

[Draude]

Еще раз глянул на табличку и увидел, что если в параметрах по умолчанию забрать нолик все будет очень даже прилично.
А может косячок подкрался в лишнем нолике?
Хотя нет пересмотрел тему и хотелку так было изначально задумано.

[AlexWhiter]

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

Вообще говоря, с самого начала шкала масштабов JNX строилась таким образом, чтобы повторять шкалу карт, приходящих по подписке BirdsEye. Предполагалось, что Garmin лучше знает, какие масштабы нужно устанавливать, чтобы устройствам было проще
Вполне допускаю, что простота отображения в устройствах не являлась для Гармина основной целью, и масштабы были подкорректированы в сторону более "красивого" показа карт.

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

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