Недосягаемый космос

Я настолько стар, что в детстве хотел стать космонавтом. Видимо желание это было так велико, что по инерции меня еще дважды заносило в подмосковный Центр управления полетами, старый советский космический скафандр и тренировочный аквариум Звездного городка. В Звездном городке я на контрольно-пропускном пункте впервые увидел лиственницу и совершенно изумился (ибо в то время я еще не научился как следует охуевать). Хвойное дерево, с мягкими как листья иголками это вам не акация с гледичкой. На тот момент, я уже принял решение, что космос может обойтись без меня, а вот таежные леса нет. Я так и записал в блокноте: «буду лесником», после чего перечитал в поселковой библиотеке все что имело отношение к лесу и лесному хозяйству.

В одну из зим, меня вместе с поземкой занесло за ворота конторы военного лесхоза. Это на специальность инженера лесного хозяйства я поступал обуреваемый мощным романтическим порывом. Сюда же пришел в полной убежденности, что настолько испорчен тлетворным влиянием института, что терять мне больше нечего и наконец-таки можно приступить к исполнению детских мечт. Так я получил два комплекта формы, петлицы с просветом без звездочек, юфтевые сапоги и красное удостоверение в котором между графой «выдано оружие…» и графой «наименование учреждения» стояла запись «Лесник (инспектор по охране леса»). Вскоре после этого я вывалился по пьянке из окна общежития и окончательно переселился в контору лесничества.

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

Хорошо, что зима не длится вечно. Я был самый трезвый из кочегаров и все-равно пил так, что написал монографию, философский трактат, программу на С++ для ввода и анализа геоботанических данных и обошел в Морровинде вокруг Красной горы. Фактически, вся теория живых систем, методы расчета важности информации, понимание красоты как строгой (в математическом смысле) функции системы и диатропический подход к классификации объектов возникли во время безделья между подброской в печь дров и угля.

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

Но даже небольшое усложнение картируемой территории приводит к неразрешимым проблемам. Мы вынуждены либо отбрасывать информацию, упрощая содержание карты, либо постоянно создавать новые типы и классы объектов. Рано или поздно схема неизбежно запутывается.

Мы наносим на карту родники. Это тип объекта, который, казалось-бы, прост и понятен. Но только до тех пор, пока не будет найден первый каптированный источник. Сразу родники становятся классом, содержащим два типа объектов: родники обустроенные и просто выходы вод. Что такое каптированный родник? Обычно это просто врезанная в землю труба, иногда достаточно большой длины, по которой родниковая вода течет цивилизовано. А теперь представьте, что нам, кроме родников, необходимо обозначить еще и трубопроводную сеть. Мы также представляем ее как класс, содержащий разные типы: система орошения, система канализации, и, черт возьми, сюда может попасть и наша труба, выводящая родниковые воды.

Что произошло? Два класса, абсолютно разные во всем, содержат в себе один и тот же тип объекта. В нормальной иерархической классификации такое абсолютно невозможно. У нас, вместо иерархии образуется сеть из типов объектов, в которых классы всего-лишь представляют собой группы типов с определенным набором признаков. Иерархия пропадает, возникает диатропизм. В ботанике и зоологии та же хрень описана еще палеоботаником С.В. Мейеном и его учеником Ю.В. Чайковским (смотри лучшее чтиво 1990-го года: «Элементы эволюционной диатропики»).

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

Мы рисуем контур конкретного объекта с редкостоящими дервьями, после чего решаем: отнести его к лесу, скверу или вообще к газону? Мы рисуем линию и решаем: отнести ее к ручью или ограждению (ров вокруг замка это ограждение или водоем?). Мы рисуем точку и думаем, обозначать ли этот канализационный люк как преграда на дороге, если с него раз в два месяца какие-то пидарасы снимают крышку? Возьмите OSM-мовские natural=wood и landuse=forest. Всегда ли легко установить разницу, особенно если речь идет о стране в которой лесное хозяйство официально отменено с 2007 года? А ведь это разные классы, объекты в них должны быть отличимы между собой как тротуар и ручей. Но что делать, если по тротуару уже второй год течет ручей водопроводного порыва, не мешая гулять пешеходам? Что это за объект-то такой?

Кстати, в России landuse=forest и при действующем лесном хозяйстве нельзя было трактовать однозначно. Например северные гористые леса, принадлежащие лесхозу, который ввиду бессмысленности или отсутствия дорог не проводил там хозяйственные мероприятия.

Примитивная классификация данных OpenStreetMap позволяет отображать на карте огромное количество нюансов. Новый объект? — не вопрос, вот новое значение тега. Что-то совсем странное? — не вопрос, вот новый тег. Выбери в свое время Кост многоуровневую классификацию, мы получили бы сейчас головную боль в виде действия закона Ципфа: имели бы пять-шесть верхних классов, включающих 80-90 процентов всех объектов и овердохуя классов, содержащих по одному-два объекта. А в таком виде, классификация OSM сродни низкоуровневому языку или безработному без долгов: постоянно требуется вникать во множество деталей, зато никаких ограничений для творчества.

Лучше нынешней классификации OSM может быть только полный отказ от иерархии. Объединяем существующие теги и их значения в единые свойства и указываем наличие этих свойств у любого объекта. А поскольку свойства выражены в разной степени, добавляем значение истинности. Так для густого леса, вместо natural=wood мы получаем naturalwood=0.9, а для редкостойного, вместо natural=wood мы получаем naturalwood=0.3.

— Эй, бля! С твоей классификацией, мы получим таких монстров, что хер кто их распознает! Вот что это например за хуйня такая:  natural_wood=0.3, natural_scrub=0.2, natural_wetland=0.2, highway_construction=0.5,  highway_path=0.9,  barrier_ditch=1.0, landuse_construction=0.5, landuse_fill=0.7?

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

Я тут не буду намекать о том, что допуск отображения значения тегов через другие теги дает вообще космические возможности. Например, этот же объект можно в упрощенном виде записать как barrier: {natural_wood=0.3, natural_wetland=0.2, barrier_ditch=1.0}. Хотите увековечить на карте топиарное искусство? -говно вопрос: historic_memorial:{natural_scrub=1.0}. Обратите внимание, что в данном случае, natural_scrub относится именно к памятнику, то есть является его неотделимой частью. Если бы мы хотели обозначить могилу в кустах, то поступили бы по другому: historic_memorial=1.0, natural_scrub=0.4.

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

Формат FRNP: назначение и спецификация

Друзья мои, однажды, когда я работал редактором в одном научном журнале, мне довелось описывать историю создания программы для обработки геоботанических данных. Чуть позже, эта статья в популяризированном виде была выложена на Хабр и, вполне может быть, присутствует там до сих пор.

Хочу читать статью тут

Софт, формат, стандарт и немного занудства — опыт разработки программы для обработки геоботанических данных

В студенческие годы я пошел по наклонной и стал ботаником. Да-да, самым настоящим, который рвет «траву и лишаи», а после сидит с тяжеленными определителями. И хоть это не стало основным видом моей деятельности, но все-таки часть ботанической (точнее геоботанической) работы мне досталось. Под катом — взгляд на работу геоботаника с позиции айтишника, выраженный через опыт разработки костыльного софта. Обращаю ваше внимание, что слова «работа геоботаника» и «взгляд айтишника» расположенные в одном предложении означают, что дальнейший текст противопоказан беременным, несовершеннолетним, а также людям с неустойчивой психикой и сердечно-сосудистыми заболеваниями.

 

«Кто такой Тайлер Дёрден?»

Меня часто спрашивают, знаю ли я Тайлера Дёрдена кто такие геоботаники? Отвечаю: геоботаники — специалисты по растительным сообществам. В отличии от, например, систематиков, которые путешествуют из одной пыльной гербарной в другую, геоботаники свой материал собирают исключительно в поле, составляя геоботанические описания — специальные таблицы, в которых указано какие растения и в каких объемах произрастают на площади. По этим таблицам в дальнейшем можно определить показатели плодородия и влажности почвы, антропогенную нарушенность, кормовую ценность участка и много других интересных вещей. И, как вы понимаете, это определение ведется так же как и в эпоху, «когда динозавры были маленькие» — с бумажным бланком и миллиметровкой. Самые продвинутые используют Excel.

 

 

«А теперь, Горбатый!»

Перефразирую Жеглова: «Геоботаник, который вносит данные из бумажного бланка в Excel, зря получает рабочую карточку». И дело тут вовсе не в экселе. К этой программе претензий нет — вещь замечательная, к тому же тотально перекраденная, с доступной portable-версией. И даже то, что формат xls не ГОСТовский, не только не беспокоит, но даже неизвестно основной массе специалистов. Основная проблема перевода с бумажных бланков в табличные редакторы состоит в бесполезности этой работы. Чем плохи экселевские таблицы? Вот вам аналогия с книгами: лет пять назад я начал активно собирать коллекцию из отсканированных pdf и djvu версий книг. За годы коллекция разрослась до сотен гигабайт, и пожалуй единственного чего в ней нет это пользы. После определенного момента, я полностью перестал пользоваться этими книгами, поскольку времени на поиск информации в моей библиотеке уходило больше чем на поиск такой информации в интернете. Форматы электронных книг хороши для художественных романов на ридерах, но для хранения технической литературы подходит только сеть и никак иначе. От того, что «Флора СССР» отсканирована, она не станет более востребованной чем ботанические разделы Википедии.

То же самое с геоботаническими описаниями. Работая по проекту восстановленной циркумбореальной растительности я собрал небольшой электронный фитоценарий (коллекция геоботанических описаний) — в несколько сотен описаний, в наивной попытке обработать его. Тут требуется отметить, что описания в фитоценарии были сделаны в разных природных зонах, разными авторами, в разное время, разными методами. Такие описания принципиально невозможно стандартизировать и сравнивать, если конечно речь не идет о грубом качественном сравнении («тамо были лишаи, а тамо мохи и евоные ягоды»). Даже работа, по формированию единой базы данных на основе этих описаний мучительна и уже потому неправильна.

 

«Надо понимать всю глубину наших глубин!»

Да, я опять нудю (или нужу?) об отсутствии стандартов и нелепости современной геоботаники. Это Леонтий Раменский мог позволить себе собрать десятки тысяч описаний и вручную их обработать. Сегодня это невозможно — никому не нужны такие работы, даже при том, что реально увеличить производительность за счет технических средств. Поэтому, если мы хотим работать с крупными фитоценариями, необходимо объединять наработки каждого в единую базу. Но для этого следует хотя-бы оформлять описания по единым стандартам, а не как придется. Да, я конечно понимаю, что «научная» полевая работа — это сегодня очень часто не более чем оплачиваемые турпоездки. Потому и не ставится вопрос об единых стандартах и методах. Потому и не поднимается вопрос о целесообразности публикаций описаний в журнале «Растительность России» (за публикацию таблиц описаний в БУМАЖНОМ журнале уже давно пора давать орден «почетный старпер»). Однако же, на дворе 21 век, а геоботаники продолжают заполнять бумажные бланки собственного изобретения.

 

«Это вам не это!»

Первую попытку оптимизировать работу с «сырыми» описаниями я предпринял три года назад в рамках работ над программой PhytoSoft (разработка велась в Borland C++ Builder 6). На тот момент, стояла задача облегчить и ускорить ввод данных с полевого бланка, для последующего анализа по экологическим шкалам Л.Г. Раменского (помните, я выше говорил о том, что с помощью геоботанических описаний можно определять плодородие и влажность почвы? Это, как раз и есть «метод экологических шкал»). Программу удалось довести до работоспособного состояния, но при крайне низком бюджете, она так и осталась на этапе альфа-тестирования и позже была выложена в открытый доступ со всеми своими тараканами.

Сейчас я понимаю, что концепция «Фитософта» содержала в себе несколько ужасных стратегических ошибок. И дело даже не в том, что код — говно и руки растут из того же места, что и ноги. Сама идея того, что следует упростить ввод описаний с бланка в корне неверна. Во время показа первой успешно скомпилированной версии, я регулярно слышал вопрос, о возможности импорта в Фитософт описаний из Excel. Несомненно, я при разработке предусмотрел такую возможность, но технология импорта была уродской и я всегда старался замолчать этот вопрос, хотя он был и остается одним из главных. Даже если сейчас, появится чудо-программа для геоботаников, что делать с теми описаниями, которые уже введены в табличные редакторы? Выше я сказал, что привести описания разных авторов к единому шаблону практически невозможно, соответственно, у каждого описания будет либо собственная структура, либо общая структура будет сверх-сложной и всегда найдется описание, которое в эту структуру не встраивается. Требовался принципиально иной подход к организации данных в описаниях, чем те к которым мы привыкли (строчки-колонки).

Формат *.gbo который использован в Фитософте под эту задачу никак не подходил. Я не оформил должным образом спецификацию на него, но самое главное, что он тоже представлял собой те самые «строчки-колонки». Проще говоря, «*.gbo» — это большущая таблица, высотой в тысячу строк, шириной в несколько сот колонок. Каждое описание в таблице занимает одну строку. Описание разбито на логические элементы, которые размещаются в разных ячейчах. Например, в пятой ячейке первой строки указан автор первого описания, в шестой ячейке первой строки указана дата первого описания и т.д., в пятой ячейке второй строки указан автор второго описания, в шестой ячейке второй строки указана дата второго описания и т.д… Логика формата очень проста, но для импорта внешних файлов, последние приходилось мучительно переделывать (представьте: вашу сводную таблицу описаний необходимо перестроить таким образом, что-бы с 50 по 100 колонку шли названия видов, а с 101 по 151 их проективные покрытия). Эта проблема возникла от того, что вместо разработки программы под формат шла разработка формата под программу.

 

«Это не кадка, а настоящее японское фураке!»

Может быть я изобрел велосипед, но зато на собственной шкуре понял, что программное обеспечение и формат файла это никак не связанные (в плане разработки) вещи. Изначально следует разрабатывать формат файла, причем делать это независимо от того, когда и кем под этот формат будет написано программное обеспечение. После этого уже имеет смысл писать программу. При этом, придется решать многие задачи, которые не возникли бы при создании формата «под себя», но с другой стороны, риски того что формат будет обладать критическими недостатками снижаются.

Вот конкретный пример. Если вы изначально разрабатываете формат, как отдельный проект, то наверняка учтете, что он должен быть приспособлен для импорта в ГИС. После этого, начав разработку, вы будете вынуждены решать проблему с ГИС-совместимостью, даже если геоинформационными системами в вашей программе и не пахнет. Зато от этого формата не откажутся, что неизбежно произошло бы, когда выяснилось, что формат бесполезен для ArcGIS, QGIS или другой программы.

Формат файла должен быть максимально удобным для конвертации в другие и из других форматов.

Разрабатывая Фитософт в рамках идеи упрощения оцифровки бумажных бланков я ошибался. Бумажных бланков не должно быть вообще, полевые данные сразу должны быть готовы к обработке. Но, поскольку любой тупиковый путь рано или поздно заканчивается, примененная концепция довольно быстро изжила себя, породив новую проблему. С одной стороны, стало ясно, что геоботаник должен вводить данные в программу сразу после их получения в поле. С другой стороны, это означает, что он не будет пользоваться ни компьютером, ни ноутбуком. Планшеты? Но их цена столь же аморальна, как и срок заряда батареи. А самое главное, я вспомнил, в каком состоянии возвращаются полевые бланки — намокшие, с пятнами крови от раздавленных комаров. И со стороны пользователя я бы не хотел, что-бы моя (и не только моя) привычка не задумываясь бросать планшетку (которая скрепляет бумажные бланки) рядом с собой погубила однажды электронику. Планшет не подходил. Оставался смартфон. С точки зрения пользования это идеальный вариант — стоят они гораздо меньше, берут их с собой в любую погоду и вероятность повредить их гораздо меньше. Но в то же время это значит, что весь код, связанный с интерфейсом Фитософта можно удалять. Для полевых условий требуется что-то принципиально иное чем множество окон выбора.

 

«Айл би бэк»

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

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

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

Что же делают геоботаники? Они берут бланк и переносят его в табличный редактор, в надежде, что чудо-компьютер предоставит им бесконечное количество инструментов для анализа. А когда выясняется, что таким образом никаких новых данных не получить, разводят руками, мол, фуфло все, эти ваши компьютеры: разве что миллиметровку экономят.

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

«Из пяти множеств описаний отобрать те, для которых коэффициент Жаккара более 0,7 если в них присутствует группа таволги и коэффициент от 0,4 до 0,7, если в них доминируют луговые виды»

Представили себе объем работы? Ну, тогда хера ли мы с вами рассуждаем о всякой банальщине, ловите истинную суть этого поста:

=======================================================

Формат FRNP, версия 1 (Voikar)

Формат FRNP (format research nature page) предназначен для хранения и автоматизированной обработки данных о растительности, почвах и отобранных образцах, полученных в ходе полевых работ.

Синтаксис
В нотации Бэкуса-Наура:
Char ::= ‘A’|’B’| … |’Z’|’a’|’b’| … |’z’|’%’|’№’|’0’ | ‘1’ | ‘2’ | … | ‘9’|’_’|’+’
Note ::= ‘A’|’B’| … |’Z’|’a’|’b’| … |’z’|’%’|’0’ | ‘1’ | ‘2’ | … | ‘9’|’_’|»’|’,’|’.’|’%’|’№’|’@’|'(‘|’)’|’+’
Text ::= ‘»‘
Polychardelimited ::= ‘,’
Delimited ::= ‘:’
End ::= ‘;’
String_end ::= ‘$’
Name ::= {Char},Char
Data ::= {{Text,Note,Text}|{{Char},Polychardelimited,{Char},Polychardelimited},{Char}
Descriptor ::= {Name,Delimited,Data,End}String_end
Base ::= {Descriptor}

Семантика
Пробелы и символы переноса строки игнорируются.

Приставки и окончания:
total — общее (например общее проективное покрытие);
% — показатель измеряется в процентах;
1,2…10,… — показатель измеряется в долях от 1,2…10,…;
quality — качество;
№ — номер;
sp. — вид;
c — окружность;
sm — показатель измеряется в сантиметрах;
h — высота;
m — показатель измеряется в метрах;

Корни:
dendro — древесный ярус;
underdendro — подрост;
upgrass — подлесок;
grass — травы и кустарнички;
undergrass — мхи и лишайники;

Дескрипторы описания:
tags — ключевые слова (теги) описания;
time — дата в формате ГГГГММДД, например седьмое июля 2015 года: 20150807;
author — автор или авторы описания;
feedback — контакты для связи с автором;
license — лицензия распространения данных;
source — источник данных;

Дескрипторы местоположения
lat — широта;
long — долгота;
ele — высота над уровнем моря;
datum- система координат:
wgs84 — WGS-84;
pulkovo42 — СК-42;
unknown — Неизвестная система координат;
area — площадь описания в квадратных метрах;
note- примечание;

Дескрипторы описания древостоя:
totaldendrocover% — общая сомкнутость древостоя в процентах;
dendrocover% — повидовая сомкнутость древостоя в процентах;
dendroshare10 — состав древостоя в долях от десяти;
dendrocompleteness — абсолютная полнота древостоя в квадратных метрах;

Дескрипторы описания подроста:
totalunderdendrocover% — общая сомкнутость подроста в процентах;
underdendrocover% — повидовая сомкнутость подроста в процентах;
underdendroquality3 — состояние подроста в трех баллах (1-нормальный, 2-удовлетворительный, 3-угнетенный)

Дескрипторы описания подлеска:
totalupgrasscover% — общая сомкнутость подроста в процентах;
upgrasscover% — повидовая сомкнутость подлеска в процентах;

Дескрипторы описания травяно-кустарничкового яруса:
totalgrasscover% — общее проективное покрытие травяно-кустарничкового яруса в процентах;
grasscover% — повидовое покрытие травяно-кустарничкового яруса в процентах;

Дескрипторы описания мохово-лишайникового яруса:
totalundergrasscover% — общее проективное покрытие мохово-лишайникового яруса в процентах;
undergrasscover% — повидовое покрытие мохово-лишайникового яруса в процентах;

Дескрипторы описания почв:
soil(N) — номер почвенного горизонта верху вниз (soil0,soil1,soil2 и т.д.);
Шаблон значения дескриптора описания почв
m_colorsoil_density_composition_root_stone_coal
m — мощность горизонта;
colorsoil — цвет почвы по А.С. Захарову (например светло серый — «white-grey»)
composition — механический состав горизонта:
cl — глина;
hl — тяжелый суглинок;
ml — средний суглинок;
ll — легкий суглинок;
sl — супесь;
sd — песок;
density — плотность горизонта:
f — слитой;
t — плотный;
p — уплотненный;
c — рассыпчатый;
l — рыхлый;
root — наличие корней;
stone — наличие камней;
coal — присутствие углей;
peat — торф;

Дескрипторы описания отобранных образцов:
dendroextruder№_sp._csm_hm — отобранный образец дерева с указанием номера, вида, окружности и высоты дерева;

Пример описания:
tags:»betula»;
time:20150807;
lat:66.00287;
long:63.66359;
ele:58;
datum:wgs84;
note:
«Описание №102. Склон 3 градуса ЮВ экспозиции с кочками высотой 0,4 м»;
totaldendrocover%:40;
dendroshare10:
picea_obovata_4,
betula_aurata_6;
dendroextruder№_sp._csm_hm:
248_picea_obovata_71_13,
249_picea_obovata_71_14,
280_betula_aurata_53_13;
totalunderdendrocover%:5;
underdendro:
picea_obovata,
betula_aurata;
totalupgrasscover%:5;
upgrasscover%:
sorbus_sibirica_1,
duschekia_fruticosa_3,
rosa_accicularis_1;
totalgrasscover%:80;
grasscover%:
vaccinium_myrtillus_70,
ledum_palustre_7,
carex_globularis_1,
vaccinium_vitis-idaea_1,
licopodium_sp._3,
linnea_borealis_+;
totalundergrasscover%:40;
undergrasscover%:
pleurozium_schreberi_30,
ptilium_crista-castrensis_10,
politrichum_commune_5,
sphagnum_sp._+,
hylocomium_splendens_+;
soil0:
13_peat;
soil1:
6_white-grey_cube_l_sd_stone_;
soil2:
brown_cube_плотн_sd;
$

=======================================================

Да, я знаю, что описанная спецификация содержит косяк на косяке, но надо же хоть с чего то начинать. Кстати, если по Бэкусу-Науру есть специалисты, ткните меня пожалуйста носом в косяки оформления синтаксиса. Пока я вижу только то, что запись Data типа ___,____,_____ будет считаться допустимой. Это не очень хорошо, но приемлимо.