VPom

Класс защиты у них не указан. Купания в воде явно не переживут. Долгого лежания под проливным дождем, наверное, тоже. но в целом у меня пуксинги PX-2R уже два года живут без проблем. Правда, они ультракомпакты, в нагрудный карман рубашки помещаются. Ну или в рюкзаке. Наружу тангета или гарнитура выведена.

Суть в том, что с носимой СБшки вы вряд ли с кем-то вообще сможете общаться дальше чем на пару километров (в самом лучшем случае). Потому что мощность маленькая и антенна никакая.

Brainfire писал(а) Sat, 16 March 2013 00:30Да, вообще на экшн камере лучше не экономить Все правильно. Но. Без заранее продуманного сюжета и качественного монтажа ваши клипы, даже снятые с профессиональным качеством, даже вам второй раз смотреть не захочется. Не говоря уж о ком-то еще. Так что прежде чем задумываться о том, какую камеру взять, стоит подумать - а будете вообще потом возиться с обработкой отснятого?

Cascade писал(а) Fri, 15 March 2013 05:48 Ну, это как повезет. Я вот на прошлой неделе карточку получил из Болгарии. Болгарина этого я услышал на десятке минувшей осенью на покатушке где-то в Гатчинском районе. Позвал его внаглую. Антенна была резинка штатная на 50-144-430МГц и как всегда FT-815 c LiPol батарейкой. Это "дальний проход". На СБ обычное дело. При этом вы запросто можете не слышать соседа за пару километров. Вообще, по-моему, на весле, проводили тесты носимых радиостанций. Носимые СБшки по дальности связи в лесу на пересеченке проиграли рациям в диапазоне 2м (за счет невозможности использовать нормальный четвертьволновой штырь, а хорошая антенна, как известно, - лучший усилитель) и были на уровне раций диапазона 70см. Но проиграли всем по весу/габаритам и энергопотреблению. Вообще смысл СБшки в машине понятен - слушать информацию о гаишных засадах и пробках. Зачем все это на велике? Там более надежную связь обеспечит компактная двухдиапазонка (UHF/VHF) с хорошей антенной.

Duke писал(а) Thu, 14 March 2013 20:50 Если ценник принципиален, тогда 144Мгц к сож. не вариант, дешевых раций для этого диапазона нет. Хотя китайцы делают неплохие, но все равно это ~$150 Откуда вы такие цены берете? http://www.409shop.com/409shop_product.php?id=109155&option=21943 двухдиапазонка 136-174/400-480MHz, 4Вт. 91 долл. за пару. Тоже самое, но ультракомпакт (2вт) http://www.409shop.com/409shop_product.php?id=106855&option=5945 82 долл. за пару.

Вот такие: BBB MOUNTAINHIGH BPD-32 оказались на удивление живучими. Уже который сезон что с ними не делал, все живут. Хотя и не дорогие были. У дочки такие же - тоже живут давно уже.

hidden_ab писал(а) Wed, 13 February 2013 17:25VPom писал(а) Wed, 13 February 2013 21:19В последнее время в MP появились "нестандартные" типы объектов. Те, что не описаны в файле типизации от GPSMapEdit. Помню-помню, я на эти нестандартные типы напоролся как раз в июне, когда свою первую карту ваял (из трёх ). Сидел подбирал что чему соответствует и в LayersPOI.cfg пихал. Довольно наспех и только те типы объектов, которые на карте своего города нашёл, но повозился изрядно. Думаю, ваш-то файлик поправильней будет, так что снова спасибо большое. Я не уверен что мой файл правильнее - я не анализировал все используемые в MP типы. Просто потыкался по карте в GPSMapEdit в поисках объектов с "тип не определен" - что увидел, то добавил. Но запросто мог что-то и не увидеть. Вобщем, конечно, по уму надо рекомпозитор писать для ОСМ шейпов...

hidden_ab писал(а) Wed, 13 February 2013 15:58VPom, так я же по вашей статье и учился карты делать! Вау! Спасибо вам и за статью и за mpsplitter, это реально очень, очень круто! Да вобщем не за что... Я для себя делал в первую очередь (у меня 310-й эксплорист, брал в первую очередь из-за хорошей работа с растром, но потом и вектор стал интересен) По преобразованию гарминовских карт. В последнее время в MP появились "нестандартные" типы объектов. Те, что не описаны в файле типизации от GPSMapEdit. Я обнаружил в готовой карте отсутствие некоторых грунтовых дорог ну и начал разбираться с MP в GPSMapEdit... Вобщем, тут дополненный файл типов. Если дойдут руки - сделаю версию сплиттера, которая будет работать сразу с ОСМ данным в шейпах для перекомпоновки их по тегам.

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

hidden_ab писал(а) Wed, 13 February 2013 11:42Тогда, наверное надо переформулировать вопрос. Хочу сделать себе векторную карту с POI, где взять наиболее актуальный и точныйматериал для преобразования (старый формат Гармин или ещё лучше сразу польский формат). OSM, ЕМНИП, не содержит нумерации домов например. Да не проблема. Для Гармин Для Навител И там и там есть исходники в MP. Так что останется только раскидать исходный MP по шейпам в соответствии с тем, как вы хотите получить раскладку по слоям, выделить POI. Ну и собрать все в ММО. Но тут надо иметь ввиду, что придется проверять типизацию. Столкнулся с тем, что в последних версиях для гармина начали использовать нестандартные типы. При желании скачать данные ASTER-GDEM или SRTM, сделать BLX файл и добавить в карту данные для отрисовки рельефа.

hidden_ab писал(а) Tue, 12 February 2013 18:49Может готовые есть у кого, а то понадобятся скоро, а прилететь и обнаружить что при самостоятельном изготовлении я ошибся с привязками жуть как не хочется. В самостоятельном изготовлении нет никаких проблем. Нужно всего 2 программы - GlobalMapper и RMPCreator Ну и карты, естественно. GM нужен чтобы исходную карту преобразовать в формат GeoTIFF в нужном датуме и проекции (WGS84, Lat/Lon). Процедура описана тут. Вобщем, там на все минут 10-15 на карту уходит. При желании можно и вектор сделать из ОСМ данных. Но это уже посложнее.

satanton писал(а) Wed, 06 February 2013 00:57работа ночью абсолютно не важна. я не идиот, чтобы по ночам кататься и не сопрут ничего. самое важное - компактность. потом время работы и качество записи, не кино же мне снимать. Может такое тогда?

satanton писал(а) Tue, 05 February 2013 14:45может кто-нибудь подскажет хороший видеорегистратор на велик, мелкий, с возможностью фото, долгим временем работы? у меня есть, но время работы - мах. 45 мин. и фото не сделать. Вообще-то это называется экшн-камера. От обычного регистратора отличается большим временем автономной работы и защитой от окружающей среды (как минимум - пыле- и брызгозащита по классу IPX6, ронять в воду не стоит, но дорожная пыль и проливной дождь камере не страшны). Выбор тут достаточно велик. От брендов типа GpPro, Contour, Drift и т.п. до разнообразных китайских поделок. Отличия, как обычно в цене и качестве. Я пользуюсь вот таким китайцем. Качество съемки так себе (хотя тут надо иметь ввиду, что труба сама по себе понижает качество ужимая битрейт), особенно в условиях недостаточной освещенности. Качество изготовления вполне приличное - под сильным дождем работает исправно. Комплектация тоже вполне нормальная. Аккумулятора (совместим с Nokia BLC-2) хватает на два часа минимум, в комплекте два аккума. Если хочется нормального качества, то надо смотерть в строну брендов. Лучше всего (на мой взгляд) GoPro Hero 3.

indi писал(а) Tue, 05 February 2013 13:46 вполне возможно, что тормоза связаны с "индивидуальностью" тайлов. даже, в случае когда тайлы имеют одинаковое значение градусы/пиксели, даже в линейном тупом разбиении кратном 256x256, всё равно для каждого тайла индивидуальный скалинг. Вот интересно - а зачем это нужно было делать? Ну раз так сделали, о чем-то думали ведь? У магеллана сетка тейлов стандартная. Вот тут человек (который писал конвертер GeoTIIF -> RMP) описывал это дело. Вот тут расчет сетки Вот тут он же писал примерно то же самое. Несколько заморочено, зато по сути сетка является готовым индексом. Возможно, за счет этого и скорость работы выше на стыках тейлов и атласов.

indi писал(а) Tue, 05 February 2013 12:39В jnx размер тайла ограничен максимумом 1024x1024. При этом ничто не мешает создавать тайлы хоть размером 363x122. Привязка каждого тайла к координатам индивидуальная, каждый тайл имеет 4 координаты. При этом, тайлы могут накладываться друг на друга, могут быть разных масштабов в одном слое. Возможно тут тормоза и кроются. Вот на этом видео видно что тормоза основные явно происходят при переходе с тейла на тейл. indi писал(а) Tue, 05 February 2013 12:39Но я не скажу что растр так уж тормозит по сравнению с вектором, по крайней мере на 62s. Какие-нить Дороги России, порой, тормозят гораздо больше Если будет возможность сравнить тормоза с магелланами - напишу Извиняюсь за качество - снимал на карандаш Как работает с растром Magellan eXplorist 310 (функционально аналог 20-го етрекса). Скроллинг в данном случае осуществляется в пределах двух атласов - листы О41-109 и 110 в масштабах 025 и 050к. разницы в скролинге особо незаметно ни переходе между тейлами, ни переходе с атласа на атлас. Вектор - да, тормозит. Но там много времени на рендеринт уходит, особенно когда много объектов.

indi писал(а) Tue, 05 February 2013 11:42 растр требует декодирование jpg и линейный независимый скаллинг по обеим осям. возможно, дело в медленном декодировании jpg, возможно, в скаллинге. я немного поэксперементировал с jnx. можно слегка немного увеличить скорость отрисовки уменьшив размер тайлов сильным сжатием и размерами. Да, требует. Но это не те операции, которые занимают много времени. Когда речь идет о тейлах небольшого размера. Я не знаю размер тейла в JNX, в RMP он фиксирован 256х256 пикселов. Плюс там хитрая сетка тейлов, которая доставляет ряд заморочек на этапе создания атласа, но, видимо, весьма удобна на этапе поиска и выборки нужных тейлов при выводе карты. Так или иначе, но разработчикам магеллана как-то удалось получить скорость вывода растра достаточную, чтобы этот процесс не казался медленным. Ни при переходе от тейла к тейлу (даже в тех случаях, когда тейлы принадлежат разным слоям одного атласе или вообще разным атласам), ни при масштабировнии (опять же, нет разницы происходит при этом масштабирование текущего слоя или переход на другой слой).

indi писал(а) Thu, 17 January 2013 09:55 Ведь, по-идее скорость отрисовки карт, старта навигатора зависит, наверное, от скорости чтения с карточки, class 6, 10... Увы, но скорость отрисовки растра определяются внутренними алгоритмами. С чем это связано - большая загадка - по идее растр должен рисоваться быстрее вектора т.к. не требует рендеринга. Возможно, какие-то проблемы в самом формате JNX, не позволяющем быстро находить и извлекать нужные участки изображения. Сравнивал с магелланами (тритоны, новые эксплористы) - там растр рисуется очень быстро, никаких тормозов не заметно.

Lev G. писал(а) Tue, 04 December 2012 14:37 Постараюсь выразиться точнее. Потеря сигнала всегда вызывает завершение секции в треке! В вашем конкретном случае - да. В общем случае - нет. Так что ваша программа годится для обработки ваших треков. Но не других.

indi писал(а) Tue, 04 December 2012 14:31кстати, для мегелланов в версии 1.60 Qlandkarte GT добавили поддержку rmp http://mac.softpedia.com/progChangelog/QLandkarte-GT-Changelog-54425.html Спасибо, интересно. Надо глянуть на досуге. Хотя мне для работы вполне хватает их родного софта VantagePoint. Хотя по большому счету магелланам внешний софт особо не нужен - его к компу подключил, он вилится как флешка обычная, просто копируйешь что надо куда надо. Работа с картой - OkMap. Все карты у меня сейчас уже в GeoTiff переведены. Для создания атласов RMP есть утилитка RMPCreator.

Lev G. писал(а) Tue, 04 December 2012 14:06 Вот когда вы превратитесь из счастливого необладателя в обладателя прибора Garmin (на сирф-3 или мтк), видимо тогда вы перестанете считать подобные треки нормальными для города. Это не реклама Гармин, возможно что и другие производители делают нечто подобное. По крайне мере 60 серия и eTrex (не совсем древние) с такой огромной погрешностью треки в городах да и вообще где бы то ни было(за исключением разве что глубоких каньонов) не рисуют. Я был обладателем "не совсем древнего" Garmin eTrex H (то же поколение, что и Legend HCx). И в городе он рисовал не менее затейливо. Магеллан, кстати, в этом отношении более аккуратен - у них еще со времен старого чипсета (TrueFix) весьма неплохие внутренние алгоритмы обработки. Ну и вылетов трека в космос при замене батарейки они точно не страдают. А мне приходится работать с теми данными, которые предоставил заказчик. И как-то выкручиваться.

Lev G. писал(а) Fri, 30 November 2012 17:34 Да уж, это мягко говоря тяжелый случай Я бы такой трек сразу отправил в корзину. К сожалению, это вполне нормальный трек для города. И, к сожалению, с таким треком приходится работать, отправлять в корзину его нельзя. К счастью, заказчик не предъявлял требований по восстановлению трека, задача была немного иная, я ее решил. Но трек оставил в качестве "тестового" для разработки своих алгоритмов. Lev G. писал(а) Fri, 30 November 2012 17:34Тем не менее проанализировал его своей программой. Кое что она все таки смогла для вас сделать. Обнаружила и удалила откровенные вылеты. Вот результат ее анализа: Часть вылетов таки да. А вот большую часть она таки пропустила. Хотя первый (внизу) пик - откровенный вылет. Пила в правом верхнем углу - похоже на дрифт. Перед ней - вылет на несколько точек. И еще. Очень неплохо было бы чтобы программа не просто удаляла вылеты, а корректировала их - "возвращала" вылетевшие точки туда, где они должны быть.

Lev G. писал(а) Fri, 30 November 2012 16:48 MapSource - оффлайновая программа компании Garmin для работы с векторными картами. Распространяется бесплатно при покупке приборов Garmin. Соответственно есть у всех счастливых обладателей таких приборов. Я себя отношу к счастливым необладателям сего прибора (вот уже почти полтора года как). Lev G. писал(а) Fri, 30 November 2012 16:48Слабый сигнал(точнее его потерю) определяю по данным plt файла. В структуре plt файла это можно узнать по символу после 2 запятой. Если это "1" потеря сигнала, если "0" нет Вот пример: 60.363370, 29.209070,1, 175.5,41049.2970833, 20-май-12, 7:07:48 В структуре gpx файла за это отвечает такая строка </trkseg> И соответственно начало новой секции <trkseg> Могу вас заверить, что деление трека на секции никак не коррелирует с потерей сигнала. Тут возможны разные ситуации: 1. Прибор действительно начинает новую секцию при потере сигнала. 2. Прибор никак не отмечает потерю сигнала и вообще никоим образом не поддерживает секции в треке 3. Прибор закрывает текущий трек и начинает новый при потере сигнала. 4. Прибор делит трек на секции по своим внутренним соображениям. Например, по количеству точек. Или по истечении некоторого времени. Или... да бог его знает почему. Так что привязываться к сегменту трека как к точке потери сигнала некорректно. Я не говорю о таких ситуациях как: Выключили запись трека (не выключая прибора), отошли на километр, включили снова. Скачали (или обработали) трек какой-то программой, которая все сегменты объединила в один. Вобщем, вы закладываетесь на обработку очень частных случаев, характерных для вашего прибора и ваших настроек. В то время как на самом деле программа должна сама искать "особые точки", исходя из того, что они чем-то отличаются от остальных (соседних).

Lev G. писал(а) Fri, 30 November 2012 16:22 Во первых время, которое очень важно для расчета расстояния, а затем и скорости в plt формате находиться в абсолютных единицах с погрешностью примерно 0.01с Это довольно неплохо. В случае с gpx форматом погрешность 1с, что в 100 раз больше. Правильнее сначала проверить программу на более точных данных. Если вы работает с треком, записанным с навигатора, то там в любом случае точность будет не выше 1с. Навигаторы точнее не умеют. А елси логгер, то и в gpx время может писаться с высокой точностью: <time>2012-04-06T01:50:28.799Z</time> Lev G. писал(а) Fri, 30 November 2012 16:22 Во вторых для gpx формата мне пришлось бы писать отдельный метод для перевода времени в абсолютные единицы. Уйти от формата ДД:Мес:ГГ ЧЧ:ММ:СС чтобы сравнивать время. Это отняло бы лишнее время для написания программы. А время и так и этак нужно переводить в нормальный вид. Например в Unixtime в расширенном варианте (т.е. не 32 бит целое, а с плавающей точкой где целая часть - стандартный Unixtime, а дробная - миллисекунды). А gpx по сути есть обычный xml, парсеров готовых можно найти.

anviczhukov писал(а) Fri, 30 November 2012 14:32VPom писал(а) Fri, 30 November 2012 12:17anviczhukov писал(а) Thu, 29 November 2012 16:05VPom писал(а) Thu, 29 November 2012 12:29 Вот вам навскидку трек. Такой трек обрабатывать - просто безумие! А более простые треки обрабатывать большого смысла нет. Выкинуть 1-2 точки проще всего руками в GPXEditor'е Да такой трек с погрешностью более км тоже обрабатывать смысла нет. Проще от руки нарисовать, точнее будет! Да нет, там просто ряд точек надо скорректировать.

anviczhukov писал(а) Thu, 29 November 2012 16:05VPom писал(а) Thu, 29 November 2012 12:29 Вот вам навскидку трек. Такой трек обрабатывать - просто безумие! А более простые треки обрабатывать большого смысла нет. Выкинуть 1-2 точки проще всего руками в GPXEditor'е