FError, если есть какой-то дополнительный источник данных, например список номеров вагонов, тогда можно выбирать наиболее похожий.
В целом свести ошибку распознавания можно лишь введением дополнительных данных, которые можно потом использовать (вроде кода Рида-Соломона).
Если бы номера вагонов всегда писались одинаковым шрифтом, то можно было бы опереться на особенности шрифта и дообучить алгоритм используя данные от человека.
Stalker_RED, я говорю о том, что на десктопе все работает несколько иначе. Например на десктопе вам не нужен постоянно висящий стек поддерживающий связь с базовой станцией. А на телефоне он нужен. И он должен иметь гарантированное время отклика.
fedor, Linux не имеет гарантированного времени отклика системы, в нем недостаточно хорошо реализованы механизмы взаимодействия с пользовательским вводом и т.д.
Могу вам привести пример - графический редактор, где есть простой тач интерфейс. Просто быстро проведите пальцем и линия будет отставать. Гарантированное время отклика будет означать, что тач будет считан с устройства и отображен на экране за время, меньшее 1/60 секунды.
В таком случае у вас не будет задержки. Если не понимаете о чем я, проведите пальцем по песку, а потом по экрану андроида и все поймете.
Идея интересная, но как обслуживать парк из 3000 планшетов?
Просто закачать туда видосики сколько займет времени?
А зарядка? Надо под каждое место будет подвести кабель или водителю прийдется бегать от места к месту и все подзаряжать.
Ну штуки вроде какое-то быдло ножом экран поцарапало или скважину жвачкой залепило? Давно вы на междугородних автобусах вообще ездили? Я такие приколы даже в самолетах видел, а про автобусы и подавно.
А теперь немного о расценках. 3000 планшетов + самый дешевый вариант антивандального корпуса + подводка питания, ну пусть $100 на устройство. Итого $300000 + $5000 R&D + минимум $100 на новые устройства ежемесячно (при таком парке устройств просто будет срабатывать % брака не говоря о предумышленном повреждении) + обучить водителей + что-то платить сверху водилам за обслуживание. А еще водитель может прихватить планшетик-то и сказать, что тот сломался.
Либо мой вариант самопала, пусть $1000 на автобус + изначальные затраты на R&D где-то $10000 + $100 за накатывание обновлений ежемесячно (в 99% они будут автоматическими). Плюс у моего варианта есть потенциал, поскольку всегда можно расширять и обновлять каталог автоматически.
Из моего интернационального опыта могу сказать, что встроенный планшет с рекламой полное г. (сразу вспомнился Аэрофлот). Во всех американских междугородних автобусах есть Wi-Fi и розетки для телефонов. В американских поездах тоже есть Wi-Fi и розетки. Даже в Мексике в местных маршрутках для туристов есть Wi-Fi. Все, кому надо могут прочитать SSID и ввести пароль. Системы со встроенными недопланшетами только в самолетах. Но уже в некоторых компаниях есть что-то вроде локального Wi-Fi с медиахабом или даже медленным бесплатным интернетом на некоторых рейсах/самолетах.
Вообще, рекомендую автора заморочиться и сделать нормальный комплекс для автобусов. Вполне себе продаваемое решение, особенно если довести его до ума.
Александр Пашкевич, смотрите в сторону 15". 13 это очень маленький экран. Я вообще не понимаю, как можно работать на таком малюсеньком экране. На нем же ничего не помещается.
Алексей Сундуков, DOM есть, только вот он разный. XPath не поможет. Прийдется искать блоки в определенных позициях на экране.
Плюс часть DOM'а может быть реализована через псевдоэлементы CSS.
PhantomJS/CasperJS могут сделать рендер страницы, в них можно запустить JS, но если дерево будет постоянно меняться, вы не сможете написать правила для выдергивания данных.
В итоге прийдется распознавать с картинки или искать какой-именно блок находится в указанном месте, но тут тоже можно устроить подлость, оставить в обычном HTML один блок, а потом его перекрыть другим.
Алексей Сундуков, парсер то видит, но с помощью того же flex-box можно сделать таблицы ввиде div и каждая строка может быть сделана иначе. Т.е. порядок данных в каждой строке может быть разным.
Отображен он будет корректно, но внутри HTML будет такой хаос, что черт ногу сломит.
Здесь фишка в непредсказуемости. Например одна ячейка сделана тегом span, а другая тегом b. И правило это только для 3-й строки. В первой строке данные идут в прямом порядке, а в следующей уже в обратной.
И такая каша генерируется динамически.
Т.е. даже наличие DOM-а не сильно помогает, т.к. правила разные все время.
В итоге для парсера прийдется написать систему, которая будет сначала рендерить все, а потом распознавать, что и где находится. Это дороже, чем создание генератора каши. Плюс генерация легка, а вот парсинг становится затратным с точки зрения вычислительных ресурсов.
А вы не рассматривали Канаду как вариант?
Можете попробовать как стартап.
Вполне себе развитое государство. В целом очень похоже на США.
Если вы северный житель, то для вас климат прийдется по душе.
Я кажется понял, почему говорят про то, что $match надо делать до $lookup.
Если данных много, то Монга начнет их объединять до передачи в проверку и это будет достаточно низкоэффективной операцией.
В идеале лучше делать что-то вроде:
// workshop
{
"title": "Nam of the workshop",
...
"members": [ {"_id": "user_id", roles: ["founder", "actor"] } ]
...
}
При такой схеме участники и их роли будут дублироваться внутри мероприятия. При такой схеме можно отследить, кто был просто участником, а кто был спикером, организатором мастер-классов и т.п.
При таком дизайне можно легко вывести таблицу мероприятий и их спикеров.
В NoSQL принято строить дизайн базы от решаемых задач (или предстоящих задач). Плюс вы должны быть ментально готовы изменить структуру, если того требует предстоящая задача.
Если для вас критически важна скорость, то можете напрочь забыть про реляционные БД в принципе.
Смотрите в сторону NoSQL, MongoDB например. Ну и штуки вроде Redis тоже подойдут.
В целом свести ошибку распознавания можно лишь введением дополнительных данных, которые можно потом использовать (вроде кода Рида-Соломона).
Если бы номера вагонов всегда писались одинаковым шрифтом, то можно было бы опереться на особенности шрифта и дообучить алгоритм используя данные от человека.