Формат файлов сплитов

Предлагаю для рассмотрения/обсуждения такой формат

<pre>
Пример:
spb|1|CP1251|
31.12.2007|Финал кубка города||
М10|1530|4|
Талант|Ище|Хороший клуб|FIN|1:01:00|10:00|10:00|10:00|10:00|21:00|
Ж12|1530|4|
Ещё|Талант|Тоже хороший клуб|FIN|1:01:01|10:00|10:00|10:00|10:00|21:01|
Ж21||10|
Элитная|||FIN|01:59|0:10|0:10|0:10|0:10|0:10|0:10|0:10|0:10|0:10|10|19|
Невезучая||лично|DSQ|01:59|0:10|0:10|0:10|0:10|0:10|0:10|0:10|0:10|0:10|10|19|
Невезучая|II|лично|DSQ||0:10|0:10|0:10|0:10|||0:10|0:10|0:10|20|9|
</pre>

Правило 1. Файл с разделителями, каждое поле кончается обязательным символом-разделителем "|". Необязательность поля означает возможное отсутствие значения в этом поле, но символ-разделитель обязан присутствовать. Начальные и конечные пустые символы поля игнорируются.
<pre>
Первая строка - сигнатура, все поля обязательные:
spb - название формата
1 - версия формата
CP1251 - кодировка, в которой представлен файл. Допустимые значения: любая кодировка, которую поддерживает iconv.
Если сигнатура не распознаётся, формат неверный.
Вторая строка - описание события, все поля необязательные:
31.12.2007 - дата
Финал кубка города - название
<третье поле> - место проведения
Далее следуют строки только двух видов:
строка ровно из 3-х полей - описание группы
строка не менее, чем из 7-ми полей - результат участника
Строка описания группы:
<первое поле> - название группы, обязательное
<второе поле> - длина дистанции в метрах, необязательное
<третье поле> - число пунктов на дистанции, не включая финишную отметку; необязательное
Строка результата участника
<первое поле> - фамилия, обязательное
<второе поле> - имя, необязательное
<третье поле> - клуб, необязательное
<четвёртое поле> - статус в финишном протоколе, обязательное. Допустимые значения:
FIN - успешно финишировал, DSQ - дисквалифицирован, DNF - не финишировал, DNS - не стартовал
<пятое поле> - финишное время, необязательное
<шестое поле> - сплит-отметка на первом пункте, необязательное
...
<последнее поле> - сплит-отметка на финише, необязательное
</pre>

Обоснования и внутренние проверки

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

Строка сигнатуры позволяет сразу понять, что это за файл, то есть, что следует дальше. В настоящее время практикуется по крайней мере 4 существенно различных вида соревнований: обычные личные, обычные эстафеты, эстафеты одного участника, эстафеты с более чем одним участником на одном этапе. Проще всего иметь свой формат файла для каждого из видов, соответственно, spb-1,2,3,4. Здесь предлагается простейший формат для самого простого из видов.

Число пунктов на дистанции, если оно есть, позволяет осуществить следующую проверку:

Правило 2. Число сплит-отметок (полей, но не обязательно значений) каждого участника должно быть ровно на единицу больше, чем число пунктов на дистанции для данной группы, если оно указано.

Правило 2а. Число сплит-отметок (полей) у всех участников одной группы должно быть одинаково.

Если указана длина дистанции, то это позволяет "склеивать" при анализе сплитов группы, у которых были одинаковые дистанции. Кроме того, это - основа для подсчёта скоростей на перегонах.

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

Фамилия|Имя|Клуб|FIN|1:00|10|5|10||25|10| - означает, что на 4-м пункте у участника не сработала отметка, поэтому следующий сплит (5-й) включает в себя два времени: своё и предыдущего перегона. Вполне пригодно для анализа сплитов.

Фамилия|Имя|Клуб|DSQ|1:00|10|5|10||25|10| - скорее всего, означает, что участник не отметился на 4-м пункте

Фамилия|Имя|Клуб|DSQ|1:00|10|5|10|20|5|10| - означает, что участник правильно отметился на всех пунктах (все отметки есть и их сумма равна финишному времени), но был дисквалифицирован по другой причине. Вполне пригодно для анализа сплитов.

Правило 3. Для каждого участника, имеющего статус FIN, сумма времен сплит-отметок должна быть равна финишному времени.

Правило 4. Формат представления времени <pre>((\d{1,2}?(\d{1,2})?\d{1,2}</pre>
(Если видите "смайлики" - это двоеточия)

Если не соблюдается любое из правил, файл признаётся неверным и подлежит корректировке.

А XML-Based формат, предложенный комиссией в IOF чем плох? Зачем увеличивать количество энтропии? :-)

Ответ получился достаточно объёмным:

http://vist.diverse.org.ru/Orienteering/is-IOFdata-good-or-bad.html

ValeriM Написал(а):
-------------------------------------------------------
> Ответ получился достаточно объёмным:
>
> http://vist.diverse.org.ru/Orienteering/is-IOFdata
> -good-or-bad.html

Немножко добавлю:

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

Это нормально - стандарт передачи данных не отвечает за бизнес-логику.

>Должен ли получатель файла проверить равенство времени-результата и суммы времён-сплитов? Или это обязанность источника - того, кто формирует файл?

Проверять целостность должны обе стороны. Если не совпадает - встает извечный вопрос "кто виноват" и "что делать". В общем случае за целостность данных несет ответственность их источник, поскольку несоответствие "контрольных сумм" - его ошибка и повод усомниться в достоверности данных. В жизни бывает иначе и может зависеть от позиции/договоренностей источника и получателя.... :\

>допускает указание в файле результатов не PersonId, а прямо информации об участнике, но в этом случае теряется "теоретическая стройность" всей конструкции

Стройность не теряется, все логично. Добавляется головная боль разработчику парсера...

>просматривая DTD, я даже не сразу понял, что сплиты там вообще есть ...

+100

>А кто-нибудь из организаторов перейдёт на использование этого формата?

Вопрос не ко мне, но ИМХО: Не будут они разбираться в этих концептуальных дебрях.

>XML ведь не панацея ... почему-то выдумали JSON

И еще почему-то пользуем старый-добрый стринговый мессаджинг
Универсальности ноль, но перфоманс!...

>совершенно невозможно без спецификации написать хороший парсер

+1000 Источникам сплитов инфы это вроде как и не надо. Что-то выложили и спасибо. Участникам интересно сравнивать сплиты, но удобной программы просмотра они пока не требуют. Возможно что просто не понимают насколько это приятнее чем просмотр текстовок. Чтоб понять надо попользовать соотв. софт, но написать его при отсутствии стандартов сплит-файлов весьма затруднительно. Замкнутый круг.

На тему JSON: Неплохая мысль, он ведь "заточен" под преобразование в java-script объекты - относительно легко можно было-бы парсить-процессить-отображать инфу сплитов непосредственно силами JS-песочницы броузера. Да и под прочие, "нормальные" языки, библиотек хватает. Опять-же в сравнении с XML он "lightweight" и "easy for humans to read and write", но все еще гибкий, в отличии от жестко кастомных текстов с разделителями.

P.S.
Впрочем мы можем тут дискутировать сколь угодно. Не сомневаюсь что "родить" удобный, т.е. одновременно достаточно простой и разумно универсальный формат более чем реально. И что дальше? "- А не соблаговолит-ли многоуважаемый джин выдавать сплиты в в таком-то формате?". Судя по отсутствиям комментов от Сан Саныча и Макса - не очень-то это им интересно.



Исправлений: 5. Последний раз редактировал GaMY в 21.05.2008, 11:32.

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

С картой есть RouteGadget, привязывается к WG84 координатам пунктов.

Да расширять данные можно до бесконечности, хоть GPS-координаты, хоть комменты от судьи. Вот к примеру быстренько накидал JSON вариант(не ругайте за синтаксис, только идеология):
<font face="Arial" style="font-size: 10px;">

{ codePage:'cp1251', name:'Финал кубка СПб', date:'2007.12.01', format:'классика',

data:[

{ name:'М-10', len:1530, cp:4, cpn:[31,33,37,100], cpGPS:[ '....',' ....' ,' ....' , '....' ], //если есть такие данные

lens:[ 350, 450, 400, 225],
results:[
{ rank:'1', lastName:'Талант', name:'Ище', club:'Хороший club', splits:['1:01:00','0:00','10:00','10:00','10:00','21:00'], memo:'отличник' },
{ rank:'DSN', lastName:'Пупкин', name:'Вася', club:'Хороший club', splits:[null,'','10:00','10:00','10:00','21:00'], memo:'хулиган' }
]
},
{ name:'Ж-21', len:5310, cp:10, cpn:[41,42,43,44,45,46,47,48,49,100], lens:[440,380,430,440,450,460,470,480,490,100,250], cpGPS:null,
results:[
{rank:1, lastName:'Ещё', name:'Талант', club:'Тоже хороший club', splits:['1:01:01','10:00','10:00','10:00','10:00','21:01','0:55','0:55','0:55','0.12']},
{rank:2, name:'Дифчонка', lastName:'Элитная', club:'лично', splits:['1:01:01','10:00','10:00','10:00','10:00','21:01','0:55','0:55','0:55','0.12'] },
{rank:'DSQ', lastName:'Невезучая', name:'II', club:'лично', splits:['1:01:01','10:00','10:00','10:00','10:00',null,null,'0:55','0:55','0.12'], memo:'утверждает что станция пищала'},
{rank:'DSQ', lastName:'Невезучая', club:'Челси', name:'Маруся', splits:null, memo:'блондинко, потеряла чип' },
{rank:'NST', lastName:'Опоздала', club:'Камеди Клаб', name:'На Стартовна', splits:null, memo:'красавица', married:true, flirt:false }
]
}
]
};
</font>



Исправлений: 4. Последний раз редактировал GaMY в 23.05.2008, 02:43.

А вот демо представление контента из предыдущего сообщения. Спасибо форуму за дырявую секьюрность (java-script должен быть включен):

<script>

function on()
{
a ={codePage:'cp1251', name:'Финал кубка СПб', date:'2007.12.01',format:'классика', data:[ { name:'М-10', len:1530, cp:4, cpn:[31,33,37,100], cpGPS:[ '....',' ....' ,' ....' , '....' ], lens:[ 350, 450,500, 225], results:[{ rank:'1', lastName:'Талант', name:'Ище', club:'Хороший club', splits:['1:01:00','0:00','10:00','10:00','10:00','21:00'], memo:'отличник' },{ rank:'DSN', lastName:'Пупкин', name:'Вася', club:'Хороший club', splits:[null,'','10:00','10:00','10:00','21:00'], memo:'хулиган' }]
},{ name:'Ж-21', len:5310, cp:10, cpn:[41,42,43,44,45,46,47,48,49,100], lens:[440,380,430,440,450,460,470,480,490,100,250], cpGPS:null, results:[
{rank:1, lastName:'Ещё', name:'Талант', club:'Тоже хороший club', splits:['1:01:01','10:00','10:00','10:00','10:00','21:01','0:55','0:55','0:55','0.12']},
{rank:2, name:'Дифчонка', lastName:'Элитная', club:'лично', splits:['1:01:01','10:00','10:00','10:00','10:00','21:01','0:55','0:55','0:55','0.12'] },{rank:'DSQ', lastName:'Невезучая', name:'II', club:'лично', splits:['1:01:01','10:00','10:00','10:00','10:00',null,null,'0:55','0:55','0.12'], memo:'утверждает что станция пищала'},{rank:'DSQ', lastName:'Невезучая', club:'Челси', name:'Маруся', splits:null, memo:'блондинко, потеряла чип' }, {rank:'NST', lastName:'Опоздала', club:'Камеди Клаб', name:'На Стартовна', splits:null, memo:'красавица' }]}
]
};

msg = 'Ой, алертик... \n\n '
+ a.name+' '+a.date+' '+a.format+'\n'
+'--------------------------------------------------------------------------------------';
for(i=0;i < a.data.length;i++){
msg+='\n====\n';
d=a.data;
msg+=d.name+' '+d.len+' км, '+d.cp+' кп, номера: ('+d.cpn+') \n\n';
for(j=0; j < d.results.length;j++){
p=d.results[j];
msg+=p.rank+' : '+p.lastName+' '+p.name+' ('+p.club+') ';
if (p.splits!=null){
msg+=' ';
for(k=0;k < p.splits.length;k++){
msg+=p.splits[k]+' ';
}
}
if(p.memo!=null) msg+=' ('+p.memo+')';
msg+='\n';
}
}

alert(msg+'\n\n Sincerely Yours, GaMY.');
}
</script>

<A type="Button" onClick="on()">ЖМИ СЮДА</a>



Исправлений: 1. Последний раз редактировал GaMY в 23.05.2008, 03:17.

GaMY Написал(а):
-------------------------------------------------------
> А вот демо представление контента из предыдущего
> сообщения.

Чудненько! Особенно про 'merried' и 'flirt' :-) Что и требовалось показать.

GaMY, а Вы с SQL дружите?

ValeriM Написал(а):
-------------------------------------------------------
> Чудненько! Особенно про 'merried' и 'flirt' :-)
> Что и требовалось показать.

Показал возможность расширения формата + булевские значения.

> GaMY, а Вы с SQL дружите?

Я - да, он со мной - не всегда.
Отписал в личку - зачем форум засорять.

Михаил Гайдамак : gamy (at) mail (dot) ru

P.S. Все-же прикинул что XML правильнее использовать для сплитов. Только не IOF стандарт, а что-нибудь попроще. Да и представление через XSLT трансформацию нарисую быстрее скриптовых изысков...



Исправлений: 2. Последний раз редактировал GaMY в 23.05.2008, 14:11.

Я могу выдернуть сплиты из базы SFR в каком-нибудь текстовом формате. Вот простой дампер, который печатает вообще всё:
http://git.altlinux.org/people/bga/public/sfr-reader.git?a=tree

<pre>
competitor: 323, number: 709
surname: АННЕНКОВ, name: ЕГОР
group: 1, team: 27, qualif: 3, year: 1997
comment:
chip: -1, money: 60, type: 0
start: 12:09:0.0, finish: 12:31:54.0, bonus: 0, position: 0
started: 0, penalty: 0, ball: 0, score: 0, dsq: 0
...
split: 2
number: 709, group: 1, chip: 0, day: 1, recs: 64
kp: 242, check: 0, time: 12:07:23.0
kp: 43, check: 1, time: 12:18:33.0
kp: 31, check: 2, time: 12:21:36.0
kp: 51, check: 3, time: 12:24:9.0
kp: 48, check: 4, time: 12:27:32.0
kp: 47, check: 5, time: 12:30:14.0
kp: 100, check: 6, time: 12:31:38.0
kp: 240, check: 0, time: 12:31:54.0
</pre>

Гриша, что-то сходу не собирается у меня:
<pre>
$ make
cc -g -Wall -O2 dump.c -o dump
dump.c: In function ‘bufferize’:
dump.c:50: warning: implicit declaration of function ‘strnlen’
Undefined symbols:
"_strnlen", referenced from:
_bufferize in ccYqrgWw.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [dump] Error 1
</pre>
Происходит это под MacOS X, компилятор стандартный gcc:
<pre>
$ make --version
GNU Make 3.81

$ gcc --version
powerpc-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5490)
</pre>
В Си я совсем не силён :-) Может библиотеки надо какие-то явно подключить?

А почему на Си, кстати? Вроде, Вы говорили, что в основном используете Perl? Там с RegExp'ами это всё на ура делается?

<pre>
> $ make
> cc -g -Wall -O2 dump.c -o dump
> dump.c: In function ‘bufferize’:
> dump.c:50: warning: implicit declaration of
> function ‘strnlen’
> Undefined symbols:
> "_strnlen", referenced from:
> _bufferize in ccYqrgWw.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
> make: *** Error 1
</pre>
ValeriM Написал(а):
-------------------------------------------------------
> Происходит это под MacOS X, компилятор стандартный gcc

MacOS X основывается на FreeBSD, а я собирал в Linux. Вероятно, в BSD просто нет этой функции. Я заменил её на обычную strlen, скачайте заново.

> А почему на Си, кстати? Вроде, Вы говорили, что в
> основном используете Perl? Там с RegExp'ами это
> всё на ура делается?

База SFR - по сути, дамп памяти, хотя и записывается в файл кусочками. Мне показалось, что работать с двоичными данными проще на C.
Да, на Перле удобнее обращаться с текстом, но тут-то ещё не текст.

grisxa Написал(а):
> заменил её на обычную strlen, скачайте заново.

OK. Собирается.

> База SFR - по сути, дамп памяти, хотя и
> записывается в файл кусочками. Мне показалось, что
> работать с двоичными данными проще на C.

А-а. Вот о чём речь. Тогда конечно.

Где можно взять примеры реальных дампов для проверки?
И, если не трудно, напишите "dump2sfr" - в текстовый SFR.

PS Надеюсь, Вы понимаете, что ни одного принципиального вопроса это не снимает:
<pre>
- где спецификация формата этого дампа?
- приняла ли ФСО решение об обязательном применении формата?
- исполняют ли проводящие организации это решение?
</pre>

ValeriM Написал(а):
-------------------------------------------------------
> Где можно взять примеры реальных дампов для
> проверки?

http://sportsystem.ru/results

> И, если не трудно, напишите "dump2sfr" - в
> текстовый SFR.

Описание "текстового SFR" есть? =)

> PS Надеюсь, Вы понимаете, что ни одного
> принципиального вопроса это не снимает:
>
> - где спецификация формата этого дампа?

Мне спецификацию прислал А. Курдюмов в виде BaseMemStruct.h
Можно также использовать мой sfr.h, он получился короче =)

Другого описания, насколько мне известно, нет. Но было бы
неплохо его иметь. Например, неясно назначение многих полей
и диапазоны их значений.

> - приняла ли ФСО решение об обязательном
> применении формата?
> - исполняют ли проводящие организации это
> решение?

Да, все эти вопросы остаются.
Я на что хотел намекнуть: пока формат сплитов не утверждён, можно самостоятельно конвертировать базы SFR в том или ином виде, не отвлекая сотрудников Спортсервиса от проведения соревнований.

Важно понимать - никакой "формат сплитов" никогда не будет утвержден - хотя бы в силу антимонопольного законодательства. Организаторы соревнований могут использовать абсолютно любое ПО. Поэтому логичнее все-таки иметь в собственной программе импорт из наиболее распространенных форматов.
Я, со своей стороны, готов открыть любые подробности работы нашей системы. Думаю, что написав Дмитрию Налетову (moscompass@rambler.ru), можно получить достаточно исчерпывающие данные по winorient.
Главное - не надо стесняться задавать вопросы!

grisxa Написал(а):
-------------------------------------------------------

> Да, все эти вопросы остаются.
> Я на что хотел намекнуть: пока формат сплитов не
> утверждён, можно самостоятельно конвертировать
> базы SFR в том или ином виде, не отвлекая
> сотрудников Спортсервиса от проведения
> соревнований.

Согласен с Вами, Гриша.

Собственно, для чего я хочу "dump2sfr": ConcreteSplitViewer умеет читать SFR-текст, поэтому по крайней мере для тех соревнований, что выкладывают результаты в SFR-dump, уже можно было бы иметь ср-во анализа.

С форматом SFR-текст та же история, что и SFR-dump ;-)

ConcreteSplitViewer пока анализирует только личные старты, а там SFR-текст простой: вначале
заголовок, затем заголовок группы, затем результаты участников в полях fixed-length.
Если согласны сделать - я напишу спецификацию формата, который понимает ConcreteSplitViewer.

Попробовал напустить dump на финал Снежной тропы - получил 400Мб "пустого" текста типа:
<pre>
version: -1207238656
header end: 234946560
title: Кубок Санкт-Петербурга "Снежная тропа"
referee: В.Белозеров
gensec: О.Гультяева
days: 16777216 groups: 0 distances: 0
cps: 0 teams: 0 competitors: 0
splits: 0
group: 0 distance: 0 cp: 0
team: 0 competitor: 0 split: 0
type: 0 day: 16777216 precision: 0
midnight: 0 check: 0
day: 1
name: Финал
date: 15.03.2009
day: 2
name: ^NA^C
date: ’D^C
day: 3
name: ^C
date: ^D
day: 4
name: *-^D
date: ®0^D
day: 5
name: ^D
date:
day: 6
name:
date:
day: 7
name:
...
</pre>

ValeriM Написал(а):
-------------------------------------------------------
> Собственно, для чего я хочу "dump2sfr":
> ConcreteSplitViewer умеет читать SFR-текст,
> поэтому по крайней мере для тех соревнований, что
> выкладывают результаты в SFR-dump, уже можно было
> бы иметь ср-во анализа.
>
> С форматом SFR-текст та же история, что и SFR-dump
> ;-)
>
> ConcreteSplitViewer пока анализирует только личные
> старты, а там SFR-текст простой: вначале
> заголовок, затем заголовок группы, затем
> результаты участников в полях fixed-length.
> Если согласны сделать - я напишу спецификацию
> формата, который понимает ConcreteSplitViewer.

Да, напишите. Можно лично, чтобы форум не засорять. grisxa@gmail.com

> Попробовал напустить dump на финал Снежной тропы -
> получил 400Мб "пустого" текста типа:
>
> version: -1207238656
> header end: 234946560
> title: Кубок Санкт-Петербурга "Снежная тропа"
> referee: В.Белозеров
> gensec: О.Гультяева
> days: 16777216 groups: 0 distances: 0

Похоже, дело в архитектуре процессора (big-endian/low-endian ). Должно быть days: 1, отсюда и 400 Мб. =)
Мне надо почитать на эту тему, так сразу не соображу, как исправить.

Григорий, посмотрел Вашу программу. Там все правильно, но для независимости от операционной системы тип переменных должен быть указан полностью - signed, последовательность (hi|low) и количество байт (поскольку я писал заведомо под win32, у меня и указан просто int, а для других ОС это может быть полная ботва). И еще: логика работы программы по присвоению сплитов участникам устроена "снизу вверх", то есть при наличии двух и более сплитов с одним и тем же днем и номером "истинным" считается последний.

ValeriM Написал(а):

<pre>
version: -1207238656
header end: 234946560
title: Кубок Санкт-Петербурга "Снежная тропа"
referee: В.Белозеров
gensec: О.Гультяева
days: 16777216 groups: 0 distances: 0
</pre>

Исправил, и на PowerPC/Linux проверил =)

(BSD и MacOS у меня нет.)

grisxa Написал(а):
-------------------------------------------------------

> Исправил, и на PowerPC/Linux проверил =)
>
> (BSD и MacOS у меня нет.)
<pre>
$ make
cc -g -Wall -O2 dump.c -o dump
dump.c:32:20: error: endian.h: No such file or directory
dump.c:44:27: error: asm/byteorder.h: No such file or directory
dump.c: In function ‘main’:
dump.c:142: warning: implicit declaration of function ‘__le32_to_cpu’
dump.c: In function ‘revert_tsp’:
dump.c:403: warning: implicit declaration of function ‘__le16_to_cpu’
make: *** [dump] Error 1
</pre>

То же выдаёт и Watcom C под WinXP.

Может, не стоит в данном случае бороться за переносимость? Просто собирать бинарники, типа dump-win32.exe, dump-linux-x86 и т.п.

ValeriM Написал(а):
<pre>
$ make
cc -g -Wall -O2 dump.c -o dump
dump.c:32:20: error: endian.h: No such file or directory
dump.c:44:27: error: asm/byteorder.h: No such file or directory
</pre>
Ну значит поищу BSD.

> Может, не стоит в данном случае бороться за
> переносимость? Просто собирать бинарники, типа
> dump-win32.exe, dump-linux-x86 и т.п.

Переносимость лишней не бывает =). Фактически, у меня уже есть dump-linux-x86, dump-linux-x86_64, dump-linux-ppc. Другие платформы ожидают своей очереди.

grisxa Написал:
-------------------------------------------------------
> ... а те файлы, что выкладываются на o-site в виде html не подходят? Мне
> кажется, они все примерно одинаковые, может быть, 3-5 разных типов.

GaMY Написал:
> Можно, конечно, но путь порочный ... HTML - язык представления

grisxa Написал:
>Я думаю, они разные, потому что организаторы стартов используют разные программы. >А программ немного =). Под каждую можно заточить парсер. Ждать, пока авторы этих >программ сделают экспорт в каком-то едином формате можно очень долго, тем более, >что и формат не определён.

Под программу - согласен. Их действительно не много и выгружать данные они могут в пусть свой, но более-менее строгий формат. Возражал именно против разбора HTML представлений.

"Единый" формат появится "сам собой" - а именно в процессе разбора данных от разных программ. Ну распарсишь SFR дампы и что-то там от SI, а в чем хранить? Желательно в чем-то универсальном. Здесь и родится единый XML.

при наличии воли со стороны ФСО можно и единый формат продавить. но тут мы возвращаемся к вопросу о рейтинге и наличии той самой воли для его внедрения.
а хранил бы я прямо в sql каком.

druid Написал(а):
-------------------------------------------------------
> при наличии воли со стороны ФСО можно и единый
> формат продавить. но тут мы возвращаемся к вопросу
> о рейтинге и наличии той самой воли для его
> внедрения.

Не надо ни на кого "давить" и волевыми решениями "внедрять" - насильно мил не будешь и счастливым никого не сделаешь. :-) Вы ведь не хотите, чтобы на Вас кто-то "давил"?

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

Как Вы себе представляете такую картину: г-н Курдюмов, проявляя волю ФСО, "давит" на г-на Курдюмова-предпринимателя, дескать, давай, Саша, пиши спецификацию своего SFR-формата и обещай (сам себе) выкладывать протоколы в этом формате и т.д.? Смешно? :-)

> а хранил бы я прямо в sql каком.

Это вот поподробнее можно? Мы говорим о формате обмена информацией между программами. На сегодняшний день наиболее эффективными признаются "CSV и XML - наше всё!", как заметил GaMY. Ну, пожалуй, ещё JASON можно упомянуть.

А вот что Вы под sql имеете в виду? Как программы между собой должы друг другу передавать данные в sql?

вот такая тяжёлая у Курдюмова жизнь

теперь серьёзно.

пункт первый. предположим что ФСО таки решило внедрить некую базу учёта спотрсменов (предполагаемую пользу Копелевич описал) и рейтинг. соответственно надо импортировать результаты соревнований. понятно что парсинг html выложенного на o-site не вариант, надо чтобы файлы выдавали непосредственно организаторы. тут возможно два варианта: написать парсеры под выходной формат обеих используемых программ (но при этом, заметим, нет гарантии что это выходной формат внезапно не измениться), либо стандартизировать формат подачи этой информации (РАЗУМНЫЙ формат, GaMY прав). большой проблемы дописать экспорт в нужном формате (при его разумности, опять же) я не вижу. разве что делать это надо не вдруг, а сначала проконсультироваться с обоими двумя авторами. XML, при всей моей к нему нелюбви, здесь лучше CSV потому что гибче, и в нём можно указать кодировку, с которой в нашей стране традиционные проблемы.

пункт второй. если мы хотим сделать что-то для себя, то придётся парсить html. потому что лежала же здесь ссылка на программму для анализа сплитов, а что я ей скормлю если мне захочется этап 110% проанализировать?

druid Написал(а):
-------------------------------------------------------
> пункт первый. предположим что ФСО таки решило
> внедрить некую базу учёта спотрсменов
> (предполагаемую пользу Копелевич описал) и
> рейтинг. соответственно надо импортировать
> результаты соревнований. понятно что парсинг html
> выложенного на o-site не вариант, надо чтобы файлы
> выдавали непосредственно организаторы. тут
> возможно два варианта: написать парсеры под
> выходной формат обеих используемых программ (но
> при этом, заметим, нет гарантии что это выходной
> формат внезапно не измениться),

Поэтому, обычно, так разумные люди и не делают. Только в крайнем случае.

> либо
> стандартизировать формат подачи этой информации
> (РАЗУМНЫЙ формат, GaMY прав).

Об этом тут речь и идёт.

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

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

Проблема в том, что они этого не делают.

> разве что делать
> это надо не вдруг, а сначала проконсультироваться
> с обоими двумя авторами.

А чего не вдруг-то? Вот, Григорий взялся написать экспорт из SFR. У Вас есть желание написать из второго формата? Ищите автора, требуйте с него спецификацию
формата - и вперёд.

> XML, при всей моей к нему
> нелюбви, здесь лучше CSV потому что гибче, и в нём
> можно указать кодировку, с которой в нашей стране
> традиционные проблемы.

Это Вы зря. Смотрите первое сообщение в этом топике - там есть "заклинание" CP1251.

Смотрите далее сообщение Михаила о JSON - чем не гибкость?

А в общем, разницы в нашем случае ни вижу. Цвет верёвки - дело вкуса.

> пункт второй. если мы хотим сделать что-то для
> себя

А Вы лично чем готовы заняться? Рейтингами, пополнением базы?

>, то придётся парсить html.

Не надо этого делать. Это нарушит гармонию мира :-) Михаил же всё про это объяснил. Не надо поддаваться маразму.

> потому что лежала
> же здесь ссылка на программму для анализа сплитов,
> а что я ей скормлю если мне захочется этап 110%
> проанализировать?

Ничего. Это одна из причин, по которой затевался весь этот разговор. После того, как я написал
4 парсера для более-менее "внятных" форматов, организаторы вдруг перестали их
использовать, а стали класть html. И продолжают менять эти html. А на просьбы выкладывать что-то приемлемое для автоматического разбора - отмалчиваются.

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

Я закончил экспорт в текстовый формат SFR, используемый Валерием для ConcreteSplitViewer.

Описание программы: http://wiki.github.com/grisxa/sfr-reader

Откуда скачать: http://github.com/grisxa/sfr-reader/downloads



Исправлений: 1. Последний раз редактировал grisxa в 23.05.2009, 19:10.

Григорию большое спасибо!

Последняя версия ConcreteSplitViewer лежит, как обычно, тут:

http://code.google.com/p/concretesplitviewer/downloads/list

Там же и 5 конвертированных сплитов этого сезона.

Предлагаю договориться с автором любой растпространённой программы, чтобы он в экспорт результатов в HTML вставил чекбокс "Прикрепить CSV" (заглянул в WinOrient: там уже есть для результатов три формата экспорта данных, кроме генерации html). Т.е. чтобы прямо в HTML-код вставлялся блок сырых данных (например, в любой несуществующий тэг: браузер обязан его игнорировать вместе с содержимым).

Автору программы это практически ничего не стоит: экспорт как таковой уже реализован. Судьям тоже несложно ещё один чекбокс включить, от которого для них ничего не изменится (по-крайней мере договориться будет реальнее, чем на лишние телодвижения: "Запустите в программе дополнительный экспорт, сохраните результат и передайте нам"). Читатели-листатели результатов вообще ничего не заметят: визуально всё то же, а размер файла и так больше от визуальной разметки зависит, чем от данных, да и объёмы смешные.