С треками помоему главное препятствеие, для тех кто в принципе готов поделиться но не хочет напрягаться - это то что их конвертировать в gpx приходится. Замусоривание базы - это уже скорее проблемы тех кто хочет треки использовать, и возможностей по обработке треков тут больше т.к. доступен набор треков.
С рисованием, в принципе простые вещи, как то добавить домик, проставить адрес, нарисовать дорогу в том же id делаются просто, и почти что безопасно. Если в id догадаются автоматом лечить наложения дорог, то можно будет написать безопасно, без “почти”.
Я просто в милом моему сердцу регионе сталкиваюсь с проблемой не низкого качества правок а просто с очень низким количеством человек которые о проекте слышали и которым в принципе интересны картосервисы.
Ясно же, должно быть **“Как рисовать в OSM Для чайников” **
В ней простым человеческим языком было бы изложено, как установить JOSM, и нарисовать дома, дороги, пои и излагались бы базовые сведения из неокартографии (что тем же трекам свойственна большая погрешность вблизи домов).
А не программисты бы упражнялись в абстрактном мышлении (которое у них весьма специфическое)
Масса нужна для сбора геоинформации. А не для того, чтобы превращаться в гуру. Гуру всегда будет немного, а массовый проект должен быть простым.
“Черногорцы? что такое? - Бонапарте вопросил. - Правда ль: это племя злое, не боится наших сил? Так раскаятся ж нахалы: объявить их старшинам, чтобы треки и коммиты все несли к моим ногам”.
Ага, они. Но это в целом особенность местного сегмента сети. Тут проще найти магазин по продаже электроники, спросив на улице, чем поиском в интернете.
Мы тут опять возвращаемся к “нашим” и “вашим”.
Если человек хоть чем-то хочет участвовать и участвует в OSM, то это не “его” или “не его” проблема, а общая проблема.
В базу действительно ни к чему складывать “кляксы” и треки с 2D fix. И технологически, фильтрация куда более возможна на стороне пользователя (в софте, который имеет доступ к оригиналу трека), чем где-то еще, после того, как в треке уже остались одни только координаты.
Вот конкретно вы решились бы показать своему соседу Васе, у которого есть автонавигатор (предположим, уже пишущий GPX) возможность сабмитить его треки, держа в голове факт, что половина данных от него будет мусором и конкретно вам придется потом этот мусор, навсегда осевший в базе, тщательно фильтровать? Интересно, какое количество участников OSM об этом задумывается.
“Конвертировать в GPX” - это, безусловно, гигантский геморрой, состоящий из запуска какой-нибудь одной утилиты и нажатия в ней пары кнопок. Так что если это и правда основной останавливающий фактор, то проще может быть только если софт вообще всё сделает за человека. Такое возможно, но, пожалуй, только на смартфонах - установил, при желании - запустил и забыл. В остальных случаях это, видимо, непреодолимое препятствие.
Да, “наши” - те кто готов используя треки редактировать осм. “Ваши” - те кто готов поделиться треком и возможно пои, но не готов что то там редактировать. По крайней мере так это видится мне. Я не считаю что людей, готовых поделиться треком и путевыми точками “как есть” нужно игнорировать, потому что нам неудобно обрабатывать их треки.
Удобный сервис по хранению и распространению треков, мне видится принимающим оригинал трека. Если пользователь загружает обработанный трек - то всеравно нужны средства автоматической обработки.
Да, конечно, более того, я бы регулярно напоминал Васе о том что мне нужны его треки! Во-первых, кривой трек с кляксами - лучше чем ничего. Во-вторых, если сказать любому из моих соседей что мне не нужны треки с 2d Fix он просто ничего не будет заливать. Ну и в-третьих, сбор статистики (средняя скорость по участкам, гладкость трека, время его добавления в базу) должен осуществлятся на сервере. При загрузке оригинала трека это точно не сложнее чем на пользовательской машине. При загрузке обработанного трека - в любом случае пользовательский ввод надо обрабатывать и фильтровать.
Да, но перекладывать геморой по проверке наличия треков в данной области, их качества и качества загружаемого трека на человека загружающего трек - это очень дурной тон в создании массовых сервисов работающих с пользовательскими данными.
Просто неудобная форма логина, кривая капча, расположение формы логина в непривычном месте способны снизить использование сервиса в разы, а мы рассуждаем что хорошо бы пользователя приучить конвертировать фильтровать и обрабатывывать треки перед загрузкой.
Но результат участия за вычетом знаний участника зависит от свойств инструментов, которые он будет использовать. Если инструменты об этом не знают, то конечный результат будет хуже, чем если они будут об этом знать. Я, собственно, об этом и толкую: на мозги участников повлиять сложно, хоть завали их инструкциями для новичков, а на возможности инструментов для новичков повлиять, скорее всего, легче - для этого достаточно желания тех, кто эти инструменты разрабатывает. Хотя глядя на аргументацию некоторых разработчиков, начинаешь невольно в этом сомневаться. Не хочу никого задеть, но если я сейчас пойду к кому-нибудь из разработчиков пишущего треки софта для OSM с предложением фильтровать треки перед отправкой (и даже опишу, что именно и как фильтровать), то легко представить, что ответом будет нечто в спектре от “это не первоочередная задача” до “хочешь фичу - напиши собственную софтину”.
Мое саркастическое замечание имело своей целью показать, что “геморрой” в данном случае - величина крайне относительная, в чем ваш пример дополнительно помог, ведь согласитесь - не каждый готов заплатить 5к рублей за то, чтобы избавить себя от пары лишних кликов каждый раз, когда он захочет опубликовать трек?
Э… вы мое сообщение вообще читали?
Я обсуждаю то, что начинающему пользователю нужно дать возможность ничего не фильтровать перед загрузкой самостоятельно (т.е. этот вопрос должен быть возложен на софт или соответствующую часть сервиса), потому что требовать от него подобных знаний и желания их получить - утопия. И это было всего лишь частным примером.
Укажите, пожалуйста, с цитатами, кто здесь предлагал что-то перекладывать на пользователя.
Я как раз привел пример этой ситуации, как той, которая технически может быть решена без участия рядовых пользователей вообще, что потенциально привело бы к лучшему результату.
Просто я вас так понял что вы хотите чтобы приложение треки низкого качества не загружало в общую базу совсем. Я же хочу чтобы треки грузились в базу но размечались таким образом чтобы:
В редакторах осм была возможность не загружать кляксы стоянок
Не загружать старые треки для тех областей где есть более свежие
Не загружать треки низкого качества для тех областей где есть треки высокого качества
У загрузившего трек была возможность получить обратно исходный трек (не обязательно в том же формате).
У загрузившего трек была возможность получить обратно отфильтрованный трек.
Загрузка треков популярных форматов, желательно с автодетектом входного формата.
Ну и в данном случае я не вижу необходимости в десктопном клиенте.
Собственно с вами я не согласен разве что в том что трек всеравно стоит хранить просто при загрузке в редактор нужна фильтрация как треков в целом так и их частей.
Пример с формой логина - к вашим сообщениям относится в той мере, что конвертация трека в gpx это не такая уж и мелочь, это точно создает более высокий барьер чем неудобная форма логина или загрузки.
Вы конечно можете считать что я передергиваю и не достаточно аккуратно привожу цитаты. Сообщение на которое я отвечал мною же приведено.
Собственно почему я за хранение даже кривых треков в базе:
Потому что на момент загрузки других треков в данной области может не быть напрочь, нужно просто пометить участки трека или весь трек, как низкокачественные чтобы в дальнейшем отфильтровать их при появлении высококачественных треков. Если мы просто выкидываем все низкокачественные треки - теряем в принципе полезную информацию, или подспудно заставляем человека вырезать из трека плохие участки.
Потому что в осм есть традиция предоставлять доступ к загружаемым данным в том числе в изначальном виде. Тоесть для каких то целей мне может понадобиться скачать свой же трек в первозданном виде с высоким разбросом и кляксами.
Повторюсь - это был всего лишь пример ситуации, в которой сейчас вся ответственность как раз и возложена на пользователя, желающего поделиться треками, потому что для получения качественного результата нужно скачать треки с устройства, отфильтровать из них точки с плохими условиямии приема, сконвертировать треки в GPX, отправить их на сервер. Если что-то из этого представляет для пользователя проблему - результат будет плохой или нулевой.
Идеальным примером решения задачи “позволить пользователю поделиться треком” является наличие возможности положить треки в базу, даже не зная о ее существовании. Для чего, опять же, в идеальном случае, нужен и онлайн-сервис, и десктопное приложение (для тех, кто привык к ним) и приложение для мобильных устройств (в котором в минимальном варианте вообще нет никаких настроек, только кнопка “писать/не писать” и “отправить записанное”). И да, с автоопределением форматов.
А как уж оно там будет решено архитектурно - да не важно (это уже вопрос предпочтений и возможностей разработчика). Если есть подходящий сервер, который справится с обработкой - можно сделать сервис-прослойку между пользователями с одной стороны и osm track api - с другой. Через него же могут работать и программные клиенты. Если нет сервера - очевидно, вариант с обработкой треков самими программными клиентами предпочтительнее.
Но это всё не конкретно о треках, а о примере того, как можно снять с пользователей совершенно ненужную им ответственность.
P.S.: фильтрация треков по качеству определения координат не предполагает выкидывание всего трека, а предполагает выкидывание из него отдельных точек (сегментов). Это позволяет сохранить полезную информацию и избавиться от мусора. А уж все остальные фичи, которые вы перечислили - это “украшательства”, которые имеют косвенное отношение к решению непосредственной задачи более качественного и простого механизма пополнения базы треками. Ибо “кляксы стоянок” как раз и фильтруются по числу спутников в фиксе и по HDOP, а сортировка и выборка треков по времени и так есть в JOSM.
Что может быть полезного в сегменте трека, который улетел на 100 метров в сторону?
При этом мы никак не можем, глядя на сам трек, выяснить, на сколько именно он улетел.
Есть критерии (число спутников и HDOP) которые позволяют с некоторой вероятностью определить, что “эта точка трека - мусор”. И в таком случае ее надо выкинуть, а не пытаться лепить из дерьма конфеты.
BushmanK, как миниму что, дорожка которую можно разглядеть на IRS или ландсате проезжаема. Информация о том что из деревни А в деревню Б можно проехать “примерно вот тут” полезна даже со 100 метровой погрешностью.
Вот в случае дорожки между деревнями в поле трек с высокой вероятностью будет приемлемого качества, если писать его не на телефон, лежащий в кармане (это надо додуматься) а все же на какой-то навигатор.
Самый отборный мусор как раз чаще всего - либо в городской черте, где ±100м - это уже вопрос из соседней темы “машина едет по домам”, либо в лесу от велосипедистов и пеших туристов, у которых навигатор может быть в не самом выгодном положении для приема расположен (вроде GPSMAP 6x на руле горизонтально). А тут IRS - ни в красную армию.
