воскресенье, 7 декабря 2014 г.

Эксперимент с Трекохранилищем, барахолка

Предлагаю попробовать включить формат gpx в число допустимых форматов Трекохранилища.

Точнее, Трекохранилище с сегодняшнего дня уже принимает данные не только в форматах plt, wpt, но и в формате gpx. Данные, подгруженные в процессе эксперимента, останутся в Трекохранилище на общих основаниях, даже если эксперимент будет признан неудачным.

Побудительный мотив для такого предложения следующий. Есть люди, которые не используют Ози. А конвертилки (при преобразовании к форматам Ози) убивают из треков и точек ценную информацию о метках времени. Разрешение этой проблемы каждым лыжником возможно, но требует от него значительного ценза в области компьютерной грамотности, чего у нас наблюдается не всегда.

Возможная проблема

Формат gpx допускает упаковку в один и тот же файл сразу нескольких треков (tracks), да ещё и набора путевых точек (waypoints) в придачу. Мне известны популярные навигаторы, в которых единицей информации является не трек, не набор точек, а файл. Редкий лыжник сможет воспользоваться треками и точками из такого сложного файла в таком навигаторе.

Сможем ли мы договориться с любителями подгружать данные в формате gpx -- так, чтобы в одном gpx файле был либо только один единственный трек, либо только набор точек? Иначе говоря, чтобы все gpx файлы были не сложными, а простыми?

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

Пользователям Ози

Ози (нескольких последних версий) позволяет загружать данные из gpx файла через основное меню:

File/LoadFromFile/ImportGPXfile

Просьба

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

10 комментариев :

  1. Сможем, нет ничего невозможного. Это вопрос элементарной (само)дисциплины и уважения к другим участникам.

    GPX может содержать следущие данные: 0 или более треков (trk), каждый из которых состоит из 1 или более сегментов (trkseg);
    0 или более маршрутов (rte), 0 или более точек (wpt). Для упрощения процедур предлагаю следующие ограничения:

    1) Маршруты (rte) не используются ни под каким видом;
    2) Один GPX-файл содержит либо один трек, состоящий из одного сегмента, либо набор точек;
    3) Трек должен иметь человекочитаемое, осмысленное название (т.е. содержание тега <name>...</name>).
    ACTIVE_LOG_138 - название человекочитаемое, но не осмысленное.
    4) Крайне желательно, чтобы в треке присутствовали временные отметки, а в навигаторе было правильно
    установлено местное время.
    5) Если трек подвергался активным преобразованиям, крайне желательно пропустить конечный результат через XML-валидатор.
    Самый простой вариант - online: загрузить GPX-файл сюда и сохранить в том
    же формате (т.е. как GPX). Если исходный файл содержит ошибки, сохранение не удастся.

    ЗАМЕЧАНИЕ: пункты 1)-4) валидаторами не проверяются! Ответственность за их соблюдение возлагается на подгружателя трека.

    ОтветитьУдалить
  2. А что плохого в том, что файл GPX содержит трек + точки? У нас часто выкладывают plt + wpt.

    И ещё - что делает прибор, который понимает GPX, если в файле окажется несколько разных треков? У меня просто таких приборов никогда не было.

    ОтветитьУдалить
    Ответы
    1. Плохого - ничего. Предложение вынесено как раз ради обратной совместимости (предполагаю, что многие привыкли к тому, что трек отдельно, а точки отдельно).

      Что будет делать тот или иной прибор - надо проверять. Если я правильно понимаю процесс, то при работе гарминовского прибора по гарминовскому сериальному протоколу понятия "файл" вообще не существует. Передаются сущности, описываемые спецификацией GPX, т.е. точки/треки/маршруты. Если нужно записать в прибор 10 треков и 50 точек, то из какого количества файлов это всё загружено, из 1 или из 60 - совершенно непринципиально. Другое дело, если прибор используется как USB storage (т.е. прикидывается "диском"). В этом случае .gpx пишется на "диск" и прибор САМ должен разобрать этот файл и вытащить оттуда всё, что там записано. Со всеми возможными последствиями (например при попытке прожевать _очень_ большой GPX прибору может не хватить памяти).

      Кроме того, смысл вводить ограничения я вижу в том, что не всем охота/удобно разбираться с кучей данных. Ну вот пришёл кто-то с работы в пятницу в десять часов вечера, скачал .gpx на субботу - а там 10 треков, из которых первая половина называется ACTIVE_LOG_xxx и находятся в 100км от предполагаемого места проведения мероприятия, а во второй половине все треки содержат больше 500 точек и в навигаторы старых поколений не влезают. И вместо того, чтобы лечь спать, начинается бессодержательная деятельность вида "склеить-проредить-выбросить".

      Удалить
    2. "И ещё - что делает прибор, который понимает GPX, если в файле окажется несколько разных треков?"
      Мой навигатор Garmin Edge 800 соединяет прямыми линиями конечные точки треков, телефон на Андроид, рисует треки правильно.

      Удалить
  3. Кратко говоря, прямая загрузка сложного GPX файла в современный прибор и последующая работа с этим файлом средствами прибора потребуют размышлений (даже страшно сказать), проб и ошибок, но главное -- изменения привычных процедур работы с навигатором. Что увеличит количество явок в лес с некорректно подготовленным прибором.

    Дмитрию А.: А чем плох маршрут (route) в отдельном файле? Я как раз собирался предлагать лыжникам эту технологию, в которой есть определённые удобства, вроде звукового оповещения при приближении к (заданного размера) окрестности места поворота.

    ОтветитьУдалить
  4. Ещё одно предложение для подгружателей:

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

    Смысл указания этой "нитки" простой и технический. Представьте себе, как Ваш трек будут искать люди через несколько лет через поисковые системы. Поленились написать название пройденной деревни, и Ваш трек поисковик не проиндексирует.

    ОтветитьУдалить
    Ответы
    1. Есть более правильный метод. Поскольку GPX есть XML, т.е. текстовый формат, вменяемый поисковый робот должен уметь смотреть внутрь. В соотвествии со спецификацией GPX 1.1 трек может содежать следующее:

      <metadata>
      <keywords>Станция1 - Деревня1 - Река1 - Бруль1 - Река2 - Бруль2 - Привал - Бруль3 - Станция2</keywords>
      </metadata>

      Удалить
  5. Это совсем не правильный метод. При этом поисковик выдаст ссылку на файл трека. Которой грош цена, потому что по ней нельзя найти ссылку на описание этого трека. А в описании может быть написано, что трек плохой, не ходите туда, а ходиде в другую сторону по другому треку.

    Мораль: поисковику нужно помогать выдать ссылку на описание трека, а не на сам трек.

    ОтветитьУдалить
  6. 1) Ничто не мешает использовать оба метода - в метаданных указывать маршрут кратко, а художественное описание размещать в блоге.
    2) С точки зрения бегун(а|ов), данные о скорости не менее, а может даже более, важны, чем художественное описание. Если на треке много участков, где скорость меньше 6-7 км/ч, то очевидно, что пробегаемость трека находится под вопросом.
    3) Не стоит полагать, что описание трека и трек всегда будут связаны правильной ссылкой. Люди делают ошибки; принадлежащие третьим лицам блог-платформы/хостинги претерпевают непредсказуемые изменения и/или закрываются совсем, перенос содержательного блога с одной платформы на другую в автоматическом режиме как правило невозможен, что влечёт за собой необходимость вручную исправлять большое количество ссылок, и, как следствие, новые ошибки, и т.п. Ссылки всё время стремятся указывать не туда, куда надо, по множеству причин; с этой точки зрения, чем больше информации содержится в самом треке, тем лучше.

    ОтветитьУдалить
  7. - Г-блог как раз имеет механизм для автоматического переноса содержимого на другую платформу, а также механизм для глобальной замены ссылок на файлы Трекохранилища при переносе последнего. Это обстоятельство было решающим при выборе Блоггера в качестве платформы.

    - Листинг и отдельные файлы Трекохранилища в настоящее время не индексируются какими-либо поисковиками. Причина этого состоит в том, что файлы Трекохранилища (в основном в формате Ози), будучи слишком многочисленными и большими по размеру, не являются человекочитаемыми. Их попадание в результаты поиска настолько замусоривает эти результаты, что поиск по сайту становится практически бессмысленным. Несколько лет назад я пробовал индексировать файлы треков и точек и результат был плачевным.

    - Если кто любит приводить трековые ссылки на чужие (внешние) ресурсы, то да, эти ссылки означают желание их создателей поиграть в высокие риски. Я не борюсь с такими ссылками из г-блога прежде всего потому, что по факту эти треки мало интересны, и потеря ссылок на эти треки не кажется мне проблемой, достойной внимания.

    ОтветитьУдалить

Прочтите правила и советы.

Образец гипер-ссылки на пройденный трек:
<a href="http://junior-wanderers.ru/gps/GT-Mozajs-dVenki-Borodi-130907.plt">Снято на местности: трек</a>.

Образец гипер-ссылки на фотоальбом:
<a href="http://fotki.yandex.ru/users/tolasov-georg/album/361983/">Фоторепортаж</a>.

Абстрактная гипер-ссылка (для тех, кто понимает):
<a href=""></a>.

Образец картинки:
[img]http://img-fotki.yandex.ru/get/9498/129715672.134/0_c74c6_9d33057b_M.jpg[/img]

Образец индексной картинки:
<a href="TargetUrl">[img]IndexUrl[/img]</a>

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

Примечание. Отправлять комментарии могут только участники этого блога.