0001219: При экспорте в JNX задавать размер элементарного тайла

Notes
(0006181) neuda4nik (reporter) 18-03-2012 02:48	у Garmin Gpsmap62s размер экрана 160х240 так, что если делать склейку, то с возможностью отключения в настройках

(0006183) vdemidov (manager) 18-03-2012 09:10	Предпооложим что у нас тайл 256х256 занимает в среднем 3 КБайта (сейчас это не так, он занимает порядка 10 КБайт) Посчитаем общий объем: 50 000 * 3 000 * 250 = 37,5 ГБайт. Что больше размера современных поддерживаемых современными гарминовскими навигаторами флеш карточек. Итого даже без склейки тайлов предела по количетву скорее всего достигнуть не удасться.

(0006187) Smith2007 (reporter) 18-03-2012 13:15	Как минимум будет меньшее количество томов. Ну а флешки не заставят себя ждать и объем в 32гб не будет ограничением.

(0006195) vdemidov (manager) 18-03-2012 21:14 edited on: 18-03-2012 21:14	Ну я ж не говорю, что это не нужно реализовывать вообще, я просто считаю, что приоритет у этой хотелки ниже плинтуса.

(0006237) gpsMax (manager) 22-03-2012 06:22	> Ну а флешки не заставят себя ждать и объем в 32гб не будет ограничением А вот фиг там. Предел для microSDHC (как и для SDHC) - 32 гига, и это железное ограничение, его никак не перепрыгнуть. Производители вставлять картридеры SDXC даже в ноутбуки не торопятся, что уж говорить про навигаторы, так что ближайшие два-три года проблема будет оставаться актуальной.

(0006245) Smith2007 (reporter) 22-03-2012 09:04	> так что ближайшие два-три года проблема будет оставаться актуальной. 1. USB 3 уже во всю используется. Флешь память не задержит развитие на 3 года. 2. Да, сегодня еще не вышел мапсорс для PC с поддержкой JNX, но так же не заставит долго ждать. 3. Если первые 2 пункта говорят о перспективе, то сократить кол-во файлов можно уже сегодня. Да и производительность тех же монтан 650 еще ни кто не проверял с мелкими и крупными тайлами.

(0006248) vasketsov (manager) 22-03-2012 10:00	= 37,5 ГБайт Подобные оценки исходят из того, что мы пытаемся упихнуть всё в 250 томов "плотной упаковкой" (если конечно этот термин тут применим). А если исходить из реалий - взяли пару-тройку (или сколько влезет, может 10 или 100) целиком выкачанных снимков bing и сложили в один том. Аналогично сделали для google, dgsat и т.п. Ситуация как с хранением мелких файлов на диске. И нет никаких сомнений, что 250 _реальных_ томов, созданных по границам _реальных_ снимков, не забьют 32 гига. Превышение предела в 5 гигов, раскиданное на 250 томов, даст огромную необходимую точность "плотности" такой упаковки: "хвосты" не могут превышать в среднем 20 мегабайт. Что конечно чрезвычайно мало по сравнению с размером снимка. Так что доработка смысл имеет даже прямо сейчас. Именно потому что реальный мир неидеален, и теория несколько далека от практики.

(0006249) vdemidov (manager) 22-03-2012 10:29	Предел одного JNX тома 4 гига. Так что большого выиграша все равно не будет.

(0006250) vasketsov (manager) 22-03-2012 10:46	Ты не там ищешь выгоду. Выигрыш будет не в максимальном размере. Выигрыш будет в удобстве генерации.

(0006254) vdemidov (manager) 22-03-2012 10:57	>Выигрыш будет в удобстве генерации. И в чем удобство будет? Если при 10 КБайтах на тайл отсекаться будет все равно по размеру, а не по количеству тайлов. А размер от склейки тайлов вместе вряд ли будет сильно зависеть.

(0006255) vasketsov (manager) 22-03-2012 11:05	В том, что можно будет просто выбирать участки со снимками и экспортировать до полного заполнения карыт памяти. Не надо будет решать сложную задачу раскидывания снимков по томам так, чтобы всё вошло максимально плотно и чтобы "потери" составили не более 20 мегабайт на том.

(0006256) vdemidov (manager) 22-03-2012 11:10 edited on: 22-03-2012 11:12	Ну делайте. Я ж не возражаю :) Хотя совершенно не понимаю за счет чего будет выиграш, если тома все равно придется разбивать, только уже по размеру в 4 гига, который примерно соответствует 50000 стандартных тайлов. Ну будут эти 4 гига забиты 10000 увеличенных тайлов и что?

(0006258) vasketsov (manager) 22-03-2012 11:19	>уже по размеру в 4 гига зачем? том по гигу - аж 32 тома получается. и копировать их можно будет на маленькие карточки как угодно.

(0006260) vdemidov (manager) 22-03-2012 11:28	А зачем для этого увеличенный размер тайлов в томе?

(0006262) vasketsov (manager) 22-03-2012 11:48	Чтобы больше было свободы для манёвра при забивании всей карты. Я ж приводил оценку, средняя недостаточность плотности упаковки от максимума не более 20 мегов на один том (чтобы из 37 получить 32 на 250-ти томах). Это 6-7 тыщ тайлов. Один подробный снимок на 18-м зуме в разы больше, а то и на порядок. И запросто может так оказаться, что в остаток любого тома его уже не загнать, а разделив на все тома - загнать можно. Так что придётся либо делить снимки между томами, либо налетать на ограничение в 250 томов. Оба варианта очевидно ущербны.

(0006265) Smith2007 (reporter) 22-03-2012 13:23	Я выделил область и экспортировал в JNX с 15 по 18 зум. Получил 7,8Гб в 5-ти файлах. Один файл 3,2 гига, остальные по 1,3 - 1,5 и один 0,4г. Соглашусь, что проблема не особо острая. По крайней мере на данное время с учетом ограничений в 32Гб. А что будет с производительностью прибора в зависимости от размера тайла? Например на Монтане разрешение гораздо больше чем разрешение тайла.

(0008350) gpsMax (manager) 12-08-2012 12:32 edited on: 12-08-2012 12:33	> Предел для microSDHC (как и для SDHC) - 32 гига, и это железное ограничение, его никак не перепрыгнуть. Кстати, возможно был неправ - недавно где-то читал, что, как минимум, на многих андроидных девайсах без заявленной поддержки SDXC удаётся распознать карточку на 64 Гб, после её форматирования в FAT. Сам пока не пробовал.

Users who viewed this issue
User List	Anonymous (3184x), vdemidov (1x), AlexWhiter (1x)
Total Views	3186
Last View	21-11-2024 12:53

Issue History
Date Modified	Username	Field	Change
15-03-2012 14:27	Smith2007	New Issue
18-03-2012 02:45	neuda4nik	File Added: 148.bmp
18-03-2012 02:48	neuda4nik	Note Added: 0006181
18-03-2012 09:10	vdemidov	Note Added: 0006183
18-03-2012 09:10	vdemidov	Status	new => confirmed
18-03-2012 09:10	vdemidov	Target Version	=> 50xxxx
18-03-2012 13:15	Smith2007	Note Added: 0006187
18-03-2012 21:14	vdemidov	Note Added: 0006195
18-03-2012 21:14	vdemidov	Note Edited: 0006195	View Revisions
22-03-2012 06:14	gpsMax	Tag Attached: garmin
22-03-2012 06:14	gpsMax	Tag Attached: jnx
22-03-2012 06:22	gpsMax	Note Added: 0006237
22-03-2012 09:04	Smith2007	Note Added: 0006245
22-03-2012 10:00	vasketsov	Note Added: 0006248
22-03-2012 10:29	vdemidov	Note Added: 0006249
22-03-2012 10:46	vasketsov	Note Added: 0006250
22-03-2012 10:57	vdemidov	Note Added: 0006254
22-03-2012 11:05	vasketsov	Note Added: 0006255
22-03-2012 11:10	vdemidov	Note Added: 0006256
22-03-2012 11:12	vdemidov	Note Edited: 0006256	View Revisions
22-03-2012 11:19	vasketsov	Note Added: 0006258
22-03-2012 11:28	vdemidov	Note Added: 0006260
22-03-2012 11:48	vasketsov	Note Added: 0006262
22-03-2012 13:23	Smith2007	Note Added: 0006265
09-08-2012 06:52	vdemidov	Product Version	.Nightly => 120808
12-08-2012 12:32	gpsMax	Note Added: 0008350
12-08-2012 12:33	gpsMax	Note Edited: 0008350	View Revisions
12-08-2012 12:33	gpsMax	Note Edited: 0008350	View Revisions
13-10-2015 08:20	vdemidov	Target Version	50xxxx => 30xxxx.Vip

Relationships

SASGIS