VPom

Lev G. писал(а) Wed, 28 November 2012 20:23 1) Метод слабого сигнала заключается в том, что программа находит строки в треке, где был потерян сигнал и помечает на удаление 1 точку до и 3 после этого события. Важным положительным эффектом от применения этого метода для пользователя является то, что он получает трек не разбитый на секции, а как одно целое. Просматривать его в MapSource будет гораздо приятнее 1. А что такое MapSource? 2. Как вы определяете "слабый сигнал"? У вас есть в треке информация и количестве видимых спутников/спутников, по которым принимается решение, или хотя бы, HDOP? 3. Почему именно "одна до и три после"? Lev G. писал(а) Wed, 28 November 2012 20:23 2) Метод отрезков заключается в том, что на отрезке из 4 точек сравниваются расстояние между крайними и между ближайшими точками. Если расстояние между крайними точками меньше чем между ближайшими точка помечается на удаление. К сожалению я не могу в полной мере оценить корректность его работы, т. к. треков с большими "дрифтами" нет. Конечно мой метод примитивен и тут я согласен с вами, есть огромный потенциал для творчества, можно учитывать азимуты точек, аппроксимацию... Если будет время можно попробовать вместе найти "идеальное" решение. Почему именно 4 точки? Могу вам накидать треков с логгера, там есть участки с частотой записи 5 точек в секунду Если расстояние между крайними точками меньше чем между ближайшими, то это может означать и то, что вы развернулись и пошли обратно, а совсем не ошибку в положении... Или просто крутой поворот. Или, например, движение по серпантину в горах... Вот вам навскидку трек. В архиве plt в том виде, как он получен с логгера, htm - как он должен выглядеть на самом деле. Я эту задачку решить не смог пока.

Что-то не запускается у меня. Стоит Java 1.6.0_37 - другие аплеты запускаются без проблем, а этот ругается на то, что не может найти какой-то класс. plt - это плохо Нет у меня таких треков готовых. все в стандартном gpx (озиком не пользуюсь, давно ушел на OkMap, навигатор - Магеллан - пишет напрямую в gpx, логгер пишет в nmea, потом в gpx конвертирую). Так что проверить быстро не получилось, увы...

VORON писал(а) Mon, 19 November 2012 15:43VPom писал(а) Mon, 19 November 2012 09:25Был прокол камеры. Пока клеился, прибор был неподвижен, а записанный им трек "гулял" вокруг прибора. А как отличить такой случай от владельца навигатора, который решил погулять туда-сюда, пока кто-то клеит камеру? Вопрос хороший. По существу. Я такой задачи перед собой не ставил т.к. не сталкивался с такой ситуаций. Подозреваю, что движение владельца навигатора будет все-таки более упорядоченным (ну разве что он в "классики" решит поиграть нежели дрифт. И его можно каким-то образом отфильтровать уже после того, как выделена область, подозреваемая на дрифт.

indi писал(а) Mon, 19 November 2012 12:00 а почему именно прямоугольник? может, проще векторы 10-20 точек складывать, и , чем ближе их сумма к нулю, тем больше шансов, что это дрифт. Я сейчас не вспомню уже - пару лет назад было, с тех пор не возвращался к этой теме. С векторами идея тоже здравая, но пробовал ее или нет - убей не припомню. Возможно, чисто алгоритмически с прямоугольником проще реализуется. А вообще там вся сложность в том, с какого соотношения сторон включать "подозрение на дрифт" и в точном уточнении границ дрифт-участка. Не могу сказать, что у меня получилось на 100% надежно - иногда не получалось выловить. Хотя в большинстве случаев работало. Но это задача не на 500 рублей. Хотя бы потому что для решения ее приходится обкатывать алгоритм на большом количестве треков чтобы убедиться в его универсальности.

indi писал(а) Mon, 19 November 2012 11:45VPom писал(а) Mon, 19 November 2012 09:25Напомню - все началось с того, что некоторые (не будем показывать пальцем) утверждали что любой фрилансер за 500р напишет программу, которая легко и просто отсеет все "плохие точки". кто-то где-то говорил, что все точки? А смысл отсеивать одну две "самых плохих" и оставлять "просто плохие"? Я не спорю что можно сразу выкинуть пару-тройку точек на треке, в которых скорость запредельная. Но я лично сталкивался с ситуациями когда точка вылетела, а скорость вроде бы и не сказать чтобы нереальная. И я бы даже сказал, что это более типично, чем "дальние вылеты" с нереальными скоростями. Тут много чего можно придумать. Скажем, резкие изменения скорости за короткий промежуток времени. Резкие изменения курса туда-сюда (опять же за короткий промежуток времени)... Большие отклонения отдельных точек от "генеральной линии"... Но все это надо анализировать в комплексе.

indi писал(а) Mon, 19 November 2012 11:35VPom писал(а) Mon, 19 November 2012 09:25Красный трек - то, что получено с прибора. Синий - обработанный по некоторому специальному алгоритму. Здесь мы видим классический пример "дрифта". Был прокол камеры. Пока клеился, прибор был неподвижен, а записанный им трек "гулял" вокруг прибора. С такими артефактами научился бороться более-менее эффективно (не на 100%, но в большинстве случаев выявлять их умею). Не так это и просто на самом деле. Визуально-то они сразу в газа бросаются, а вот математически выделить их оказалось достаточно нетривиально. круто! очень хотелось бы взглянуть на алгоритм. В подробностях описывать сложно, на пальцах не получится. Вообще, там все как-то на грани шаманства получилось Если в двух словах, то так. Берем некоторое "окно" из 10-15-20 точек и двигаем его по треку (ну скажем, точки с 1-й по 10-ю, потом со 2-й по 11-ю и т.д). Каждый раз строим прямоугольник, в который попадают все точки окна и анализируем соотношение его сторон - чем оно ближе к 1 (квадрат), тем больше вероятность того, что мы нашли участок "дрифта". Когда такой участок выделен в первом приближении, играемся с размерами окна и точным его положением так, чтобы получить максимально близкое к 1 соотношение сторон. Так удается максимально точно локализовать начало и конец дрифт-участка. Когда участок локализован уже можно делать с ним что угодно. я обычно заменяю все дрифит-точки на две с одинаковыми координатами (скажем, усредненными по всем дрифт-точкам) и временами начала и конца участка. Т.е. имитирую точное стояние на месте в течении некоторого времени. Вобщем, алгоритм получился "геометрическим" - пробовал чистой математикой, но даже с коэффициентами корреляции получалось не слишком убедительно. Так что пришлось отталкиваться от того, как эти участки воспринимаются глазом - как "облако" точек на фоне "генеральной линии трека". Т.е. пока идем по линии, прямоугольник окна имеет сильно вытянутую форму и соотношение сторон у него сильно меньше единицы. Как начался дрифт, прямоугольник становится ближе к квадрату и соотношение сторон резко увеличивается.

Lev G. писал(а) Sun, 18 November 2012 22:39 Все равно я не понимаю зачем вам понадобился четкий критерий, ради которого вы готовы потратить так много своего свободного времени? И так же очевидно, что его нет и быть не может. Напомню - все началось с того, что некоторые (не будем показывать пальцем) утверждали что любой фрилансер за 500р напишет программу, которая легко и просто отсеет все "плохие точки". Так вот. Для программы нужен четкий и однозначный критерий того, какая это точка. Хорошая или плохая. Программа не умеет мыслить интуитивно, она умеет складывать, вычитать, сравнивать больше-меньше... Т.е. с каждой точкой она может произвести некий набор арифметических действий и потом сравнить результат с каким-то заданным числом. А на основании сравнения сделать вывод удалять току или нет. Я утверждаю, что скорость, вычисленную по координатам-времени, в качестве такого критерия использовать невозможно. Просто потому что невозможно однозначно определить пороговое ее значение ниже которого все точки будут признаны хорошими, а выше - плохими. Я не говорю что это невозможно в принципе. Я говорю лишь о том, что задача намного сложнее чем может показаться человеку, ни одной программы за свою жизнь не написавшему. И что скорее всего критериев там будет не один, а некоторая совокупность признаков, каждый из которых увеличивает или уменьшает вероятность того, что точка является выбросом. И что скорее всего базироваться тут нужно не на скорости, а на взаимном расположении данной точки и всех остальных. Точнее, на отклонении реально измеренной точки от ее предполагаемого положения. Но тут сразу встает вопрос в том, как вычислить это положение... Вот еще один пример. Красный трек - то, что получено с прибора. Синий - обработанный по некоторому специальному алгоритму. Здесь мы видим классический пример "дрифта". Был прокол камеры. Пока клеился, прибор был неподвижен, а записанный им трек "гулял" вокруг прибора. С такими артефактами научился бороться более-менее эффективно (не на 100%, но в большинстве случаев выявлять их умею). Не так это и просто на самом деле. Визуально-то они сразу в газа бросаются, а вот математически выделить их оказалось достаточно нетривиально.

Lev G. писал(а) Sat, 17 November 2012 01:57 Так можно ведь написать такую программу, чтоб пользователь сам задавал в программе это число. Скажем если он знает, что он более 40км/ч не ехал, выставит допустим 45 в фильтре, а если это скоростной даунхилл, то большее число. После этого программа начнет работу. Хорошо. Значит 44.99 - не выброс, а 45.01 - выброс? вы сами хоть одну такую программу написали? Думаю что нет. А я несколько лет этим вопросом в свободное время занимаюсь. Не так там все просто как кажется с первого взгляда. Чтобы стало понятнее могу предложить "домашнее задание". возьмите трек, загрузите его, скажем, в эксель, и попробуйте рассчитать какой-то критерий для каждой точки трека, по которому можно было бы однозначно сказать выброс это или нет. Не видя трек на карте, просто по координатам-времени для каждой точки. Если удастся, возьмите еще десяток-другой треков и проверьте найденный критерий на них. Lev G. писал(а) Sat, 17 November 2012 01:57По поводу ускорения все гораздо проще. Ведь у 99% пользователей нет треклогеров, которые бы писали трек с интервалом <1 сек. Для треклога обычного навигатора ускорение просто невозможно вычислить поскольку точки ставятся в лучшем случае через интервал 6-10 сек(метод записи авто - совсем часто). А за такое время разогнать велосипед до 40км/ч думаю будет уже по силам, хотя не проверял Тем не менее мгновенную скорость навигатор определяет с погрешностью во всяком случае не более 1км/ч, сравнивал с велокомпьютером расхождений когда либо замечено не было! Вопрос не в том, что вы думаете. Вопрос в том - где четкий однозначный критерий достоверности точки. Когда вы видите трек на карте вопросов нет. весь вопрос в том, что нужен какой-то алгоритм математической обработки трека, который однозначны выделял бы плохие точки на фоне хороших. Что касается скорости. Ни на навигаторе, ни на велокомпе мгновенной скорости вы не видите. Тм отображается некая усредненная скорость. Скорее всего, по методу взвешенного скользящего среднего. Что-то типа: V[i] = a * V + (1 - a) * V[i-1]; где: V[i] и V[i-1] - отображаемая скорость в текущий и предыдущий моменты времени V - реально измеренная мгновенная скорость в текущий момент времени a - коэффициент усреднения (с достаточно большой степенью вероятности могу предположить что он выбирается где-то в интервале 0.6..0. Кроме того, навигатор берет мгновенное значение скорости не вычисленное по координатам, а измеренное независимо, с использованием доплер-эффекта (по смещению частоты сигнала от каждого из спутников возможно определить скорость относительно спутника, затем, зная расстояние до него и направление на спутник можно вычислить результирующую скорость и направление движения в пространстве как векторную сумму скоростей относительно спутников). Эта скорость (и направление) всегда выдается навигацинным чипом в программу навигатора. Хотя и не записывается в трек (но в NMEA потоке оно присутсвует). Lev G. писал(а) Sat, 17 November 2012 01:57По поводу массовых выбросов первое что приходит в голову это кривость вашей карты, т. е. трек рисуется правильно, а дорога на карте изображена с ошибкой. Или у вас совсем древний прибор. Garmin eTrex Hа чипе Bravo2. Не менее современный, чем МТК или Сирф-3. Трек наложен на гуглеснимок в сети (программа работает через GMap API с онлайновыми картами). В одну сторону ухода нет, в другую - есть. Ни на древность чипа, ни на кривость карты тут не списать.

indi писал(а) Fri, 16 November 2012 13:38VPom писал(а) Fri, 16 November 2012 10:124. Есть пара идей как еще можно попробовать ловить одиночные выбросы, но пока нет времени реализовать и нет уверенности, что это вообще будет работать... интересно! а в чём суть этих идей? На пальцах сложно объяснять - идеи были в зачаточном состоянии Одно из направлений - попробовать что-то типа алгоритма Дуглас-Пекера, но "наоборот". Т.е. выявлять не те точки, отклонение которых от "генеральной линии" пренебрежимо мало (на этом основано прореживание трека - удаление "незначащих" точек), а те, которые имеют максимальное отклонение. И их уже рассматривать более пристально. Второе - что-то типа фильтра калмана с применением скоростей и курсов. Но скорость считать не по исходному треку, а усредненную по сглаженому. К примеру, скажем, сглаживаем трек В-сплайном, просчитываем по нему "опорные" точки с интервалом, к примеру, 5-10 секунд, по ним считаем скорость, строим еще один В-сплайн и по нему уже просчитываем скорости в реальных точках трека. Затем уже для каждой последующей точки трека сначала строим аппрокисмацию по предыдущей точке и скорости, а потом смотрим насколько реальная точка отклоняется от аппроксимуемой и делаем на основе этого какие-то выводы. Вобщем, это крайне черновые варинаты направлений движения на текущий момент, не более того. Может, как в работой разгребусь, попробую что-то пописать на эту тему.

VORON писал(а) Fri, 16 November 2012 13:13VPom писал(а) Fri, 16 November 2012 10:45Есть еще один способ улучшения качество трека А практический смысл? На 500-метровке вылетевшую точку даже не увидеть будет. Единственное, что при экспорте в OSM надо наверно все же довести трек до ума. Эх, помню я времена 10-летней давности, когда навигатор гарантированно терял спутники в кармане куртки или если лес начинал сгущаться... Трек в покатушке получался пунктирным, а о такой мелочи, как выбросы, никто даже не думал. Особенно весело было тайники искать - на опушке леса определяется примерное направление на тайник, в лесу сигнал скорей всего теряется, дальше искать по фоткам и особым приметам. Собственно, стало неинтересно искать тайники с точными навигаторами. Практический смысл - отдельная тема. кому просто положить трек на карту и примерно посмотреть - тому не надо. Речь была о том, что фильтрация выбросов только кажется простой, на самом деле это задача очень нетривиальная - глазом выборос виден сразу, а вот математически выявить его ой как непросто.

indi писал(а) Fri, 16 November 2012 13:00VPom писал(а) Fri, 16 November 2012 10:45 В моем случае это наблюдалось на старом Garmin eTrex H (чип Bravo-2). а в Garmin Legend/Vista HCx такой же чип? Помнится на эту тему было развернутое обсуждение. Пришли к тому, что eTrex H делались только на B2, а вот Легенды и Висты по разному. Ранние серии выпускались на В2, потом его стали вытеснять приборы на МТК. Вроде бы там это как-то можно было определить (включить питание при каких-то нажатых кнопках и прибор входит в информационно-тестовый режим где написано все, включая тип чипа). Но подробностей не помню уже - давно было. Существенно разницы в поведении я не заметил, кстати. Был eTrex H на Bravo2, потом параллельно с ему появился логгер на МТК, сейчас вместо етрекса магеллан на sirf-III - в целом там расхождения в реальной обстановке непринципиальные, в мелочах. У всех трех чипов (даже специально как-то писал трек одновремено тремя приборами на разных чипах, просто для сравнения. Где-то больше нравится как МТК работает, где-то как сирф...

indi писал(а) Fri, 16 November 2012 12:37VORON писал(а) Fri, 16 November 2012 10:27VPom писал(а) Fri, 16 November 2012 10:12А такой уход бывает и плавным - выглядит весьма натурально, как с дороги съехал в лес, проехал по лесу, потом выехал обратно на дорогу. Если не знать что с дороги не съезжал - никаких аномалий не заметишь (был где-то пример и такого трека). Это не функция привязки к дороге шалит? я встречал такие жалобы часто на старых навигаторах с виндоус мобайл. ещё у меня был когда-то такой: https://buy.garmin.com/shop/shop.do?pID=220 тоже подобные штуки вытворял. но у него с приёмом сигнала совсем плохо было, стоило въехать в лес, а то и просто небо натянется облаками - ищи свищи эти спутники В моем случае это наблюдалось на старом Garmin eTrex H (чип Bravo-2). Подобное было и на логгере Qstarz BT-Q1000P на чипе МТК3318. Ни тот н другой плохой чувствительностью не страдают. Это чисто системная погрешность - какая-то помеха или сбой. Есть еще один способ улучшения качество трека - пистаь его двумя независимыми приборами, расположенными на фиксированом расстоянии друг от друга. Затем совместно обрабатывать. На первом же проходе обычно сразу выявляются "подозрительные" точки, которые на разных треках слишком далеко друг от друга разлетелись. Потому уже только останется определить кто соврал, но это уже чуть проще - по крайней мере область исследования локализуется.

VORON писал(а) Fri, 16 November 2012 12:27VPom писал(а) Fri, 16 November 2012 10:12А такой уход бывает и плавным - выглядит весьма натурально, как с дороги съехал в лес, проехал по лесу, потом выехал обратно на дорогу. Если не знать что с дороги не съезжал - никаких аномалий не заметишь (был где-то пример и такого трека). Это не функция привязки к дороге шалит? Какая, к чертям, "привязка к дороге" в логгере? В нем ни экрана, ни карты. Он просто протоколирует то, что получает со спутника.

Lev G. писал(а) Mon, 12 November 2012 23:10 Про программу я уверен, что такую написать возможно, но для конкретных задач. Например, если транспорт велосипед то очевидно, что скорости >100км/ч из области фантастики. В программе можно сделать фильтр по скоростям зачищающий строки в файле от момента включения прибора до точек с такими скоростями если таковые будут. Увы, но это рассуждения дилетанта. Без обид, просто констатация факта. Давайте уточним. Для программы нужен четкий критерий для отбора. Иными словами - конкретное число. Больше - плохая точка ("выброс"), меньше - хорошая. Как мы определим это число? Вот вы говорите, что больше 100км/ч на велосипеде нереально. А 99 реально? Нет. Тогда сколько? 70 нереально? А 69.9? Где точная граница между реальностью и нереальностью? Но на самом деле все еще сложнее. Вот скорость 40км/ч на велосипеде реальна? Да. А когда в какой-то момент времени скорость равна нулю, через секунду она равна 40км/ч а еще через секунду опять ноль - это реально? Нет. Т.е. одной скорости, получается, недостаточно. Нужно еще и ускорение учитывать. А это еще один точный критерий - какое ускорение считать реальным, а какое нет? Я не говорю уже о том, что расчет скорости, а тем более, ускорения по координатам-времени дает гигантскую погрешность на малых временных интервалах. Настолько большую, что это теряет всякий смысл. Можно рассчитать с некоторой точностью усредненные значения, скажем, за 10-20-30 секунд, но это мало что даст с точки зрения локализации выбросов. Куда проще работать с треками, где содержатся дополнительные данные в виде доплеровской скорости и курса. Там можно сравнивать рассчетную скорость и доплеровскую, можно применять фильтр калмана с аппрокимацией следующей точки по координатам-скорости-курсу предыдущей (да еще и HDOP учитывать в качестве "весов" для точек). Но туристические навигаторы такой трек не пишут (в отличие от логгеров, именно поэтому я для записи трека использую логгер, а не навигатор). У магелланов, правда, можно включить NMEA лог, но это делается ручной правкой конфигов (благо, к ним несложно добраться) и в к тому же там не будет разделения по трекам - придется потом все это разгребать руками где "вчера", где "сегодня" и к тому же руками их чистить. Резюме. 1. Я искал, но не нашел ни одной программы, которая могла бы эффективно фильтровать треки, содержащие только координаты и время. 2. Я пытался сам написать такую программу. Проанализировал куеву хучу треков (ручками, в экселе) в поисках закономерностей и методов их выявления. Результат близкий к нулю. Максимум, что мне удалось, более-менее эффективно выявлять участки "дрифта" (когда стоишь на месте, а трек "гуляет вокруг тебя"). Алгоритм получился отнюдь не простой и ближе к "геометрическому", нежели к математическому. Но что-то ловит. 3. Есть и более сложные ситуации - массовые выбросы. Когда из трека вылетает не одна точка, а несколько. Скажем, движемся по дороге, вдруг трек скачком улетает на 100м в сторону, затем идет ровно, но со смесщением, через несколько секунд (5-10 точек) возвращается обратно. Восстанавливать такое еще сложнее чем выкинуть одну точку, заменив ее интерполяцией. А такой уход бывает и плавным - выглядит весьма натурально, как с дороги съехал в лес, проехал по лесу, потом выехал обратно на дорогу. Если не знать что с дороги не съезжал - никаких аномалий не заметишь (был где-то пример и такого трека). 4. Есть пара идей как еще можно попробовать ловить одиночные выбросы, но пока нет времени реализовать и нет уверенности, что это вообще будет работать... Вобщем, поверьте, это задачка не на 500р первому попавшемуся студенту, а весьма серьезная задача для человека, хорошо знакомого с математическим аппаратом обработки экспериментальных данных.

indi писал(а) Tue, 23 October 2012 13:15VPom писал(а) Tue, 23 October 2012 11:11indi писал(а) Tue, 23 October 2012 13:08VPom писал(а) Tue, 23 October 2012 11:06А jnx открытый, да? да, разговор закончен? Можно ссылку на официальное описание формата от BirdsEye? Желательно с описанием как обходить ограничения на "демонстрационные карты" в прошивке гармина напишете для rmp подобное, или расскажете как написать - продолжим общение, а так - "вы мне неинтересны" Объясните - зачем? "Подобное" я делаю при помощи MOBAC. Хотя если честно, меня больше интересует конвертация карт ГШ и ГГЦ. А то, что вы показываете - извините, в хрен не уперлось. Там нет территорий Урала (от севера до юга) - на кой черт оно вообще кому-то сдалось, кроме самого автор и еще нескольких человек?

indi писал(а) Tue, 23 October 2012 13:08VPom писал(а) Tue, 23 October 2012 11:06А jnx открытый, да? да, разговор закончен? Можно ссылку на официальное описание формата от BirdsEye? Желательно с описанием как обходить ограничения на "демонстрационные карты" в прошивке гармина

indi писал(а) Tue, 23 October 2012 13:00VPom писал(а) Tue, 23 October 2012 10:56indi писал(а) Tue, 23 October 2012 12:51VPom писал(а) Tue, 23 October 2012 10:50VORON писал(а) Tue, 23 October 2012 12:48Магеллан - это для тех, кто хочет быть не таким, как все. И выбирает собственные грабли, непохожие на чужие. Я бы сказал - для тех, кто использует преимущественно растр. И подготовка проще и отображение лучше и работает с растром быстро. подготовка проще, хо-хо-хо В чем проблемы? Любую карту из озика перекину в RMP минут за 10 (если не меньше). Прошивку хакать не надо чтобы он нормально с растром работал. P.S. С гарминами сталкивался, сравнивать могу адекватно. Для растра магелланы лучше. rmp - закрытый формат сможете написать онлайн конвертер типа этого или хотя бы алгоритм описать, тогда и поговорим А jnx открытый, да? Конвертер есть - http://antalos.com/gps/rmp-creator.php Можно пользоваться шароновским, но менее удобен. Можно вообще взять MOBAC - http://mobac.sourceforge.net/ За алгоритмами - к авторам софта. Они как-то пишут рабочие конверторы

VORON писал(а) Tue, 23 October 2012 12:55Чисто для растра как раз проще всего взять какой-нибудь Андроид по вкусу. Там хоть не будет УГ-шного резистивного тачскрина и не менее УГ-шной Винды СЕ (MS PocketPC 2002 сейчас вспоминаю, как страшный сон). В 310 нет тачскрина и винда там другая - WinCE 5. Работает стабильно (года полтора активно использую). Плюс есть еще энергосберегающий режим при котором отключается экран, но трек пишется

indi писал(а) Tue, 23 October 2012 12:51VPom писал(а) Tue, 23 October 2012 10:50VORON писал(а) Tue, 23 October 2012 12:48Магеллан - это для тех, кто хочет быть не таким, как все. И выбирает собственные грабли, непохожие на чужие. Я бы сказал - для тех, кто использует преимущественно растр. И подготовка проще и отображение лучше и работает с растром быстро. подготовка проще, хо-хо-хо В чем проблемы? Любую карту из озика перекину в RMP минут за 10 (если не меньше). Прошивку хакать не надо чтобы он нормально с растром работал. P.S. С гарминами сталкивался, сравнивать могу адекватно. Для растра магелланы лучше.

VORON писал(а) Tue, 23 October 2012 12:48Магеллан - это для тех, кто хочет быть не таким, как все. И выбирает собственные грабли, непохожие на чужие. Я бы сказал - для тех, кто использует преимущественно растр. И подготовка проще и отображение лучше и работает с растром быстро.

HardDen писал(а) Mon, 22 October 2012 23:44 А У Гармина - Магелан, который почти никто вживую не видел ... Я бы не стал говорить за всех. Читайте отчеты про тритоны на весле. Ну и пара ссылок для общего развития: http://forum.gpsinfo.ru/viewforum.php?f=40&start=0 http://tourist.kharkov.ua/phpbb/viewforum.php?f=118 Сам пользуюсь Magellan eXplorist 310. Вобщем и целом - аналог Garmin eTrex 20. Построен на WinCE (теоретически туда можно любой софт дал WinCE засунуть, но вопрос - зачем). Экран лучше чем у гармина - выше разрешение, лучше отображаются растровые карты. Сложно найти готовый вектор, хотя нет проблем сделать самому. Скажем, на основе ОСМ данных. Растр делается легко - GlobalMapper (для подготовки GeoTIFF в нужной проекции) + RMPCreator. К компу подключается легко - никаких дров не требует. Видится как флешка. Карты, треки, точки - просто скопировать в нужную папку и все. Хотя можно и родным софтом пользоваться - в комплекте идет программа VantagePoint. Еще одна фишка - в векторную карту можно вшить сетку высот (SRTM или GDEM). Тогда прибор сам будет рисовать изолинии и рельеф, проставлять высоты, указывать высоту произвольно выбранной точки (куда курсор наведешь):

Birdshell писал(а) Wed, 26 September 2012 18:28секунда на ебае как вариант http://www.ebay.com/itm/New-Sanyo-Li-lion-3-7V-18650-18650-Rechargeable-Battery-2600mAh-Red-/350585947314?pt=US_Rechargeable_Batteries&hash=item51a08d04b2 http://www.ebay.com/sch/i.html?_from=R40&_trksid=m570.l2736&_nkw=panasonic+18650 Вопрос в том, насколько оригинален этот панасоник... Как-то покупал на ебее аккум для нокии - внешне 1:1 оригинал. По сути - редкостное УГ. Вообще емкости никакой. Потом купил на ДХ честный китайский Жапод - оказался очень качественный аккум (потому уже по этому производителю слышал много положительных отзывов в сети).

indi писал(а) Wed, 11 July 2012 12:38 мир тесен, у меня теперь такой же девайс есть а есть на него какой-нить мануал? там 3 светодиода под кнопкой, есть какие-то режимы? разъём миниюэсби для зарядки? 3 светодиода показывают примерный уровень заряда аккумов - 0-30%, 30-60% и 60-100% Разъем miniUSB для зарядки аккумов внутри девайса. Тут есть некоторая хитрость - когда вставили новые аккумы, нужно иголкой нажать Reset (сбоку отверстие) - это калибровка контроллера заряда-разряда аккумов. Если аккумы не доставать, заряжать внутри девайса, то каждый раз резетить не нужно. Только когда новые вставил. Зарядка внешнего устройства начинается после нажатия кнопки "фонарик". Вскоре после отключения внешнего устройства девайс сам отключается (уходит в спячку) с погашением всех лампочек.

[quote title=VORON писал(а) Wed, 11 July 2012 12:24] У меня только растровые карты Северо-Запада, где я регулярно езжу, занимают более 2 ГБ. Дороги России - еще 2 ГБ. Плюс Исландия, Финляндия, Крым, Беларусь и так далее. Когда мне приходится слепить или скачать новый пакет карт, я просто кидаю его на карточку и забываю о нем. Это лучше, чем перед каждой поездкой лихорадочно проверять, загружены ли требуемые карты в прибор. Тем более, что скорость передачи данных на USB весьма невелика, каждый раз ворочать 500-МБ файлами времени банально жалко. У меня картами забито десяток ДВД, плюс еще на компе хрен знает сколько. Так что на одну карточку все не влезет. Даже на две вряд ли (которые по 32Гб, больше вроде пока не видел). Если речь идет о походе, то я привык его заранее планировать на компе. Тогда и загружаются нужные карты. А для ежедневных покатушек есть отдельный набор - он не занимает много места. Вобщем, этот вопрос не напрягает ничуть. Тем более, что это не гармин и карту всей страны в приборе держать совсем не обязательно. Можно хранить отдельно нужные регионы (векторные Свердловская, Челябинская области и Башкирия с высотами в сумме около гига занимают). VORON писал(а) Wed, 11 July 2012 12:24Я кстати купил себе вот такой девайс: http://www.ebay.com/itm/160793024562 Вчера вечером поставил на подоконник навигатор, запитав от него, посмотрим, протянет ли до выходных. Есть такой. Вроде работает нормально. Правда, навигатор не запитывал (мне вполне хватает питатьего от литиевых АА - 25-30 часов работы один комплект обеспечивает). Больше использую как зарядник для мобильника, логгера и раций.

VORON писал(а) Wed, 11 July 2012 11:06А сейчас, возможно, сидит и сосет лапу: даже ДР уже не влезают в 2 ГБ. А смысл держать постоянно в приборе карты всей страны? Вы собираетесь в Бурятию? В Приморье? Подозреваю, что вы в обозримом будущем даже до Урала не доберетесь, ограничившись Карелией и Ленобластью. И какой смысл держать в приборе объем карт, которые на 99% вам никогда не понадобятся... С такими подходами и 32Гб карты памяти не хватит. По своему опыту - у меня магеллан эксплорист 310. Карт памяти нет, только 1.7гб встроенной. Этого вполне хватает чтобы держать там 3 соседних региона в векторе (причем, с матрицей высот - в гармине этого нет, магеллан позволяет) плюс растр (1км и 500м ГШ или 500м и 250м ГГЦ) тех мест, где я катаюсь постоянно.