Обработки, агромодуль

LyDjons, спасибо за Ваши комментарии. Они для нас актуальны сейчас, так как мы работаем над новым агро-решением в рамках платформы Виалон. Текущее решение является несколько устаревшим и мы не собираемся вносить в него существенные доработки.

Итак, давайте убедимся, что мы правильно понимаем Ваши предложения. Вырисовывается такой список:
• при расчете множественной обработки задавать для каждого объекта свой агрегат (=прицеп?)
• при расчете общей (суммарной) обработанной площади вычитать перекрытия (взаимопересечения) и выезды за пределы поля
• также такие перекрытия вычитать из индивидуальных обработок объекта/водителя (а правильно ли это концептуально? ведь человек работал и на поле красной жирной линией не нарисовано, где проходил до него другой комбайн???)
• для расчета обработки внедрить и учитывать специальный датчик работы орудия (но он же не у всех будет, правда?)

Если что-то упустили или поняли не так, дайте знать.

Сложно пока прогнозировать. Точно не в этом году.
Вероятно, какая-то первая версия может появиться весной 2017.
Точнее не скажу.

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

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

1)обработанная площадь без перекрытия - Например для дисковки, культивации. Трактор может ходить по второму следу. Так же зависит от политики компани. Например поле 100 Га, тракторист задисковал полностью+ 2 раза прошел по узворотам поля. Или компания заплатит ему за 100 га, или за 100 + 5 га узворотов?

2) обработаная площадь с учетом перекрытия - для уборки культур комбайнами, опрыскивание полей, внесения удобрений. Желательно сделать что б обработанная площадь не выходила за пределы размера поля. (важный аспект для бухгалтерии!!!)
Да, при множественной обработке учитывать свой агрегат(прицеп)! это очень важно! А то все теряет свой смысл. Есть семь комбайнов, семь жаток(прицепов) прикрепленных каждому комбайну, при чем они могут быть разные по ширине! А у Вас все убирает одним прицепом. Нехорошо...

Так же Вам следует задуматься о следующих нюансах, и поверьте это тоже ОЧЕНЬ ВАЖНО!

Пример:

Есть поле размером 500 Га. На нем убирают 12 комбайнов.  Поле убирают 2 дня.
7 ед. - комбайны предприятия. Зарплата начисляется от тонажа
3 ед. - наемные комбайны предприятия "Злой фермер" - зарплата от гектар
2 ед. - наемные комбайны предприятия "Жадный фермер" - зарплата от гектар
Допустим за день 12 комбайнов убрали 360 Га. Это если мы посчитали линейкой по контуру. Вопрос, сколько покажут ваши обработки(агромодуль)? Боюсь что в даный момент погрешность составит не менее 30 Га. но не в этом суть.
По завершении уборки  обычно посчитали га ВРУЧНУЮ, или как смогли. Нашим впринципе по-барабану какие Га мы им поставим.
А от владелец предприятия "Злой фермер"  и владелец предприятия "Жадный фермер " обязательно придут, и будут настаивать на том, что мы им насчитали не 30 га, как они хотят, а 25.

А если на поле убирают только наемные комбайны, то это вообще прескорбная ситуация.

В общем к чему я:
1) Учитывать перекрывание следа стоит. И смотреть на это нужно с учетом кто первый проехал по данному участку, если есть наличие датчика вкл/выкл жатки(это можно реализовать, главное найти нужный провод питания жатки) . Чем больше вариантов по обработкам - тем лучше
2) Если в оброботках нам выдало 35 га обработанной площади, то при обмере инструментом вручную площадь погрешности была минимальной. Это если учитывать перекрытия
3) Каждый транспорт должен убирать своим агрегатом. (Даже если это саиоходный опрыскиватель, все равно создаем ему штангу 30м.)

Если у Вас все сложится хорошо, и Вы грамотно реализуете подсчет Га в обработках, то сразу убьете несколько зайцев. А именно: ставим Rfid - идентификации механизатора, метку прицепного устройства - имеем готовый отчет по полевым работам без минимального вмешательства пользователя.

1. Да.
2. Картинка 1. Дисковка по второму следу или по краю поля
http://forum.gurtam.com/misc.php?action … 9455t10411
3. С учетом перекрытия.  Или на выбор пользователя (без/из)
4.  Например выбрали отчет, период, технику - получили готовый результат:

Трактор ДТ-24
1.  01.10.2016 16:30   - 02.10.2016    18:20     ДТ-24  гос. 1234 Механизатор: Иванов И.И.   Борона John Deere 11м    Поле 01А   Площадь обработки 26Га   Потрачено по ДУТ....Xл. по ДМРТ ....Yл. ....

2. 02.10.2016  18:25   -  03.10.2016  16: 00    ДТ-24  гос. 1234  Механизатор: Петров П.П. . Борона John Deere 11м      Поле 01А   Площадь обработки 15Га   Потрачено по ДУТ....Xл. по ДМРТ ....Yл.  ....

3. 02.10.2016  18:25   -  03.10.2016  16: 00    ДТ-24  гос. 1234  Механизатор: Петров П.П. .  Борона John Deere 11м     Поле 02А   Площадь обработки 30Га   Потрачено по ДУТ....Xл. по ДМРТ ....Yл.  ....

Автоматически происходит  фиксация смен водителей (Rfid - считыватели). Смена прицепных устройств (Rfid - метки).

PS.   "Злой фермер"  и "Жадный фермер " — это выдуманные предприятия, но судя по том как они требовательно настаивают на том, что они  убрали больше Га чем мы им насчитали (что особо и не удивительно), то названия сами напрашиваются).
P.S2 : Лень - двигатель прогресса!

ну это пример. марка трактора и его гос номер))

Предусмотреть возможность указывать смещение от центра?

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

LyDjons, треки на принтскринах с каким оборудованием? Обычная точность или с диф.поправкой?

Имею в виду субметровый режим точности. Когда на бортовые блоки приходит дифференциальная поправка от базовой станции. Требуется для "параллельного вождения", когда точность прохождения междурядья составляет несколько десятков сантиметров (до единиц сантиметров в космически дорогом оборудовании).

Обычных бортовых блоков с типовой точностью 3-5 метров достаточно, чтобы учитывать обрабатываемые площади?

Несколько наших клиентов кстати используют ГИС Агроаналитика, которая указана выше. Претензий нет, некоторые перешли с Автографа. Можете попробовать сами, ребята наверное вам тест дадут погонять посмотреть

kolinzu
Если вы на WL, WH, WP то ничего не требуется. Он работает через SDK, синхронизируется и все. Подробно можно тут посмотреть http://docs.agroglonass.ru/

Лето наступило. "первая версия" есть ?

В разделе "обработки" при просмотре, создании обработок в списке "Участок" отображаются участки из группы "неиспользуемая площадь". Зачем? Может, чего-то не знаю, подскажите...

Добрый день, очень актуальна тема, которую поднял LyDjons. На мой взгляд Wialon одна из лучших систем в СНГ, но текущий агромодуль неудобен для использования, из-за чего думаем - отказаться вообще от Wialonо или еще подождать, вдруг что-то поменяется. До уборки осталось около 1/2 месяца.
Если бы Агромодуль заменить или доработать, то в сторону Wialon посмотрели много аграрных компаний у которых огромное количество техники (Это вступление).

Что не так?
В один день на нескольких полях работает разная техника с абсолютно разными прицепными агрегатами, разной шириной захвата. Количество техники аграрных компаний может насчитывать несколько тысяч. На нашей технике есть идентификация агрегатов, мы онлайн видим с чем она работает, но обработка сама не определяет кто с чем ездил по факту.
Сейчас нужно выполнить n-ое количество действий: 1) построить отчет по идентификации прицепов , чтобы понять какой трактор с каким агрегатом работал 2) в множественной обработке выбрать вручную для каждой техники прицепной агрегат и еще несколько действий. Т.е. если у тебя 20 ед. техники будут работать с разными по ширине захвата агрегатами, то тебе нужно создать 20 отдельных обработок, если у некоторый техники агрегат одинаковый - тебе повезло.
Система выдает тебе несколько десятков или сотен строчек с кусочками работы в каждой зоне из-за того что техника при разворотах может покидать поле, таких кусочков несколько штук по каждой единице - они размещаются все вперемешку в одной таблице по разной технике. Приходится выгружать в Ексель и строить сводную таблицу, перед этим удаляя транзитный пробег по краю поля (когда техника не работала на поле, а просто трек зацепил край контура - погрешность карты и т.п.). Если увеличить параметры времени нахождения и глубины вьезда  в поле, то теряешь некоторые гектары - система их отсекает вообще.

Как должно быть?
1) Выбираешь единицу или несколько единиц или группу техники, задаешь период
2) указываешь параметры по которым система поймет это пробег транзитом через край поля или работа на поле
Если время пребывания внутри зоны или глубина заезда более чем ... засчитать эту работу внутри поля в полном обьеме, если меньше значений ..., которые мы установили - не добавлять этот кусок в обработку вообще. А также добавить возможность удаления записей в таблице - кусочков работы до сохранения обработки.
3) система сама должна показать какая техника на каких полях работала с каким агрегатом и при расчетах используя ширину захвата, указанную в справочнике, посчитать кол-во полезной площади обработки (за вычетом разворотов и накладок). Т.е. несколько кликов и отчет напр. по 100 единицам техники готов. Сейчас вместо нескольких минут, составление отчета занимает несколько часов. А для компаний, у которых по 3 тыс. единиц техники такая система вообще не подходит.
Важные моменты логики расчетов:
1) должен быть справочник, в котором можно создать виды работ - посев, культивация и т.п. У каждого агрегата в настройках должна быть возможность указания этого вида работ.  Предположим, что логика формирования обработки такая:
- выбрал технику/группу и период, нажимаешь "Определить вид операции" или "...прицепы" и выводится предварительная форма, где видно в какой промежуток времени какая техника с чем работала и вид работ (уборка, боронование и т.п. - по умолчанию отражается вид работ, который пользователь выбрал в настройках самого агрегата при его создании. НО должна быть возможность перед выполнением расчетов изменить этот вид работ вручную - это для тех случаев, когда агрегат выполняет не стандартную или специфическую для него операцию, напр. в исключительных случаях сеялкой могут вносить удобрения, опрыскивателем жидкие удобрения и т.п.
Все это для того, чтобы через идентификацию агрегата система отличала виды работ
2) если вид работ, описанный в п.1 одинаковый для всей техники, которая работает одновременно на этом поле - то повторный пробег трактора №2 по треку трактора №1 не засчитывать и суммарный обьем работ не должен превышать площади поля
3) если на одном поле два трактора выполняют разный вид работ, то кол-во га у каждого индивидуально, напр. на поле 100 га №1 выполнял сев, №2 культивацию, обработали все поле значит каждый сделал по 100 га, итого 200 га - больше площади поля. Если 5 комбайнов убирают одновременно на одном поле - в любом случае площадь обработки не может превышать площади поля, т.к. одинаковый вид работ, пшеницу нельзя скосить два раза.
4) при одинаковом виде работ все накладки ширины захвата агрегата и выступы за край поля должны вычитаться. Если комбайн №2 проедет по треку комбайна №1 еще раз или часть его жатки будет выступать на уже скошенный участок, то эту накладку последнего - вообще не засчитывать, т.к. опять таки урожай нельзя скосить два раза.
5) система должна анализировать уже имеющиеся обработки - если на этом поле уже выполнялся такой вид работ раньше той же техникой, напр. поле засевали в течении 3 дней частями, значит общий обьем работ за 3 дня не должен превышать общей площади поля.

Не думаю, что стоит ориентироваться на Гуртам в данном вопросе. В первую очередь их задача - развитие _платформы_.

Агромодуль - один из вспомогательных аппсов, который никогда не сравнится по функционалу с решениями компаний, изначально заточенных на данный сектор.
Простой пример - Logistic. Он дает основной, базовый, простой функционал. Для многофакторных задач используются иные решения, для которых аппс Гуртам не подойдет даже в первом приближении.

Используйте remote api.

svc=agro/delete_cultivation_msg&
params={"plotItemId":"xxx","plotId":"xxx","timeFrom":1437253200,"timeTo":1505854799,"msgIndex":"0"}

Множество запросов можно объединить в batch:
https://sdk.wialon.com/wiki/ru/sidebar/ … core/batch

Можно использовать большой промежуток времени и удалять в цикле обработку с "msgIndex":"0", до тех пор пока сервер не начнет возвращать error:4.

qazar, к сожалению, пока разработка по Агро не ведётся.

LyDjons, спасибо за Ваши инсайты))
Действительно, решение для аграрной промышленности - дело непростое и к нему просто так не подойдёшь.
Так что мы всё ещё в размышлениях.

terran89, работы по данной тематике находятся в планах. По срокам сориентировать не смогу. Тема довольно объёмная.

Oleg Moskalenko, это не доклад, это тема круглого стола. То есть формат будет обсуждение с участниками будущей разработки, выявление их нужд, потребностей и интересов в области агро.

Не забудьте записаться на этот круглый стол и внести свою лепту!

qazar, нет, разработка еще не началась. Мы находимся в стадии активного сбора требований. Если желаете поучаствовать в этом процессе и внести свою лепту, а также повлиять на дальнейший ход событий, напишите мне, пожалуйста, в личку или на почту - alek@gurtam.com

Отправил предложения на электронку, как просили)

Есть ли новости? На какой стадии процесс?

Здравствуйте, написал Вам по этому поводу на почту.