Размещено на http://www.allbest.ru/

• Содержание
• Введение
• 1 Разработка и анализ технического задания
• 1.1 Постановка задачи
• 1.2 Разработка технического задания
• 1.2.1 Функциональные требования
• 1.2.2 Требования к интерфейсу
• 1.2.3 Требования к совместимости
• 1.2.4 Требования к программному и техническому обеспечению
• 1.3 Анализ технического задания
• 1.4 Выбор методов и средств
• 2 Разработка анализатора
• 2.1 Архитектура
• 2.2 Разработка алгоритма чтения файла
• 2.3 Разработка алгоритма обработки данных
• 2.4 Разработка алгоритма подбора трека
• 2.5 Разработка схемы БД
• 2.6 Соглашение имен переменных
• 3. Расчеты и оценки быстродействия
• 3.1 Скорость расчетов
• 3.2 Скорость поиска
• 4 Разработка руководства пользователя
• 4.1 Запуск системы
• 4.2 Общий вид
• 4.3 Открытие файла
• 4.4 Расчет параметров
• 4.5 График набора высоты
• 4.6 Подбор трека
• 4.7 Открытие трека
• Заключение
• Список литературы
• Приложение А
• Приложение Б

Введение

Первоначально GPS -- глобальная система позиционирования, разрабатывалась как чисто военный проект. Но в современном мире она активно используется для гражданских целей. Потребителям предлагаются различные устройства и программные продукты, позволяющие видеть свое местонахождение на электронной карте; имеющие возможность прокладывать маршруты с учётом дорожных знаков, разрешенных поворотов и даже пробок; искать на карте конкретные дома и улицы, достопримечательности, кафе, больницы, автозаправки и прочие объекты инфраструктуры. Так же GPS широко применяется в туризме и активном отдыхе. Этому способствуют специальные устройства: GPS-трекеры. GPS-трекер - устройство приема-передачи данных для спутникового мониторинга автомобилей, людей или других объектов, к которым оно прикрепляется, использующее Global Positioning System для точного определения местонахождения объекта.

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

1 Разработка и анализ технического задания

1.1 Постановка задачи

Велотуризм как активный отдых заключается в прохождении на велосипеде маршрутов, содержащих общетуристические и специфические для велотуризма объекты экскурсионного характера. Сложность таких походов может колебаться от простой до крайне высокой, маршруты прокладываются так, чтобы использовать преимущества, которые дает велосипед для быстрого передвижения по маршруту. Аналогично водителям автомобилей, велосипедисты тоже пользуются GPS-навигаторами в своих поездках. При выборе маршрута для велотуристов основными критериями являются сложность маршрута, протяженность, время прохождения, географическое положение начальной и конечной точки. При активном использовании GPS появляется проблема, связанная с хранением и дальнейшим использовании треков. Каждый турист (или группа туристов) подбирает маршруты в соответствии со своими личными предпочтениями. Поэтому появляется необходимость в организованном хранении треков. А при использовании одного компьютера несколькими пользователями, еще возникает проблема подбора нужного трека из общей массы. Так как просматривать содержимое треков можно только при помощи специализированного ПО, появляются трудности при поиске необходимого трека. Открывать отдельно каждый файл и просматривать содержимое становится не удобно, а при большом количестве треков найти необходимый маршрут становится практически не возможно.

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

программный файл трек быстродействие

1.2 Разработка технического задания

Целью разработки является создание системы для хранения, обработки и подбора трека GPS. Система позволяет не только анализировать треки, но и организованно хранить их. А так же автоматически подбирать трек по пользовательским критериям.

Основанием разработки является приказ № 829/5 по личному составу студентов института радиоэлектроники и информационных технологий Нижегородского Государственного Технического Университета им. Р.Е. Алексеева от 06.04.2011.

1.2.1 Функциональные требования

Система должна выполнять следующие основные функции:

- определять среднюю скорость движения;

- определять время пути;

- определять пройденное расстояние;

- хранить треки;

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

1.2.2 Требования к интерфейсу

- простой и понятный интерфейс для построения приложений, использующих эту систему

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

1.2.3 Требования к совместимости

- расширяемость, возможность усовершенствования, на ряду с основным назначением

1.2.4 Требования к программному и техническому обеспечению

Операционная система Windows XP и выше.

Microsoft Office 2007 или выше

Borland C++ Builder 6 или выше

Pentium 4 1800 Мгц, 512 оперативной памяти, 1Гб на жёстком диске.

1.3 Анализ технического задания

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

Анализатор треков GPS представляет собой систему, позволяющую централизованно хранить, обрабатывать и подбирать треки. Существует огромное количество различных форматов треков. Рассмотрены были лишь те, которые наиболее распространены. .kml - формат, отображающий объекты в Google Earth. Каждая точка в этом формате описана на языке разметки на основе XML, что делает файл громоздким, а доступ к данным не удобным. .mps - имеет зашифрованную структуру, что делает не возможным открытие его в текстовом режиме. Открывается только с помощью специальной программы - Map Source. .gpx - так же как и .kml построен на основе XML. .gdb - Garmin Database format. Имеет самый большой размер файла из всех рассмотренных вариантов. Среди различных форматов треков был выбран формат .plt, т.к. его файлы имеют сравнительно не большой размер и структуру, позволяющую с легкостью выделить нужную информацию из общей массы. С треками данного формата работает специализированное ПО - OziExplorer. Но он не позволяет создать общую БД для хранения всех треков, а, следовательно, не может предоставить функцию подбора трека.

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

1.4 Выбор методов и средств

Исходя из требований проекта выбор делался из следующего перечня языков: Visual Basic, Borland Delphi, Borland C++ Builder, Visual C++. Язык Visual Basic очень прост в освоении но его возможности ограничены он скорее подходит для быстрого создания красивых приложений. Данный язык не подходит по функциональности и сложен для реализации предъявляемых требований. Borland Delphi очень хороший язык. Функционален, имеются достаточные инструменты для реализации нашего проекта, в последних версиях имеется поддержка технологии .Net разработанной компанией Microsoft что повышает переносимость программного обеспечения на другие платформы, конечно с реализованной технологией .Net на этой платформе. Но несмотря на простоту, эффективность и легкость в изучении, ему не хватает очень многих мощных средств C++. Например, не достает шаблонов, перегрузки операторов и объектной модели, похожей на объектную модель C++ . Visual Studio - самый распространенный инструментарий создания приложений под Windows, но она традиционно является не самым лучшим выбором при работе с базами данных. C++ Builder обеспечивает скорость визуальной разработки в сочетании с мощью языковых средств C++, усовершенствованными инструментами и разномасштабными средствами доступа к базам данных. Проводник баз данных предоставляет графический способ проводки пользователя по содержимому базы данных, обеспечивая создание и модификацию таблиц, иерархических указателей и псевдонимов. Таким образом основные особенности С++ Builder:

- Профессиональные средства языка C++ интегрированы в визуальную среду разработки. C++Builder предоставляет быстродействующий компилятор и гибкие средства отладки как на уровне исходных инструкций, так и на уровне ассемблерных команд.

- Механизм BDE (Borland Database Engine) поддерживает высокопроизводительный 32-разрядный доступ к базам данных.

- Свойства, методы и события обеспечивают быструю разработку приложений в рамках объектно-ориентированного программирования.

- Расширенная математическая библиотека.

- Прямое обращение к системным функциям Windows.

2. Разработка анализатора

2.1 Архитектура

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

Рисунок 2.1 - Схема разработки архитектуры

2.2 Разработка алгоритма чтения файла

При разработке системы первоочередной задачей был поиск формата треков GPS, который бы имел «открытую» структуру. Т.е. вся необходимая информация для обработки была бы видна при открытии файла в текстовом режиме. Среди рассмотренных файлов различных форматов только формат .plt отвечал всем предъявленным требованиям. Структура файла имеет следующий вид:



Рисунок 2.2 - Структура файла

Первые шесть строк содержат информацию о трекере и ПО с которым работает данный файл. Все последующие строки содержат информацию о точках. Причем, каждая строка является набором информации об одной точке. Визуально можно разделить имеющуюся информацию на колонки, т.к. в файле каждая информационная единица отделена от другой при помощи запятой. См. рис. 2.2: Первая колонка - широта. Вторая колонка - долгота. Третья - Код. "0" - если нормальный, "1" - если перерыв в линии следа. Четвертая - высота над уровнем моря. Пятая - Дата и время в формате Дельфи. Шестая - Дата в формате "ДДММГГ". Седьмая - Время в формате "ЧЧММСС.НН".

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



да

нет

Рисунок 2.3 - Заполнение таблиц

2.3 Разработка алгоритма обработки данных

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

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

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

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

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

Известно, что более точно описывает форму Земли не сфера, а эллипсоид, однако в данной работе рассматривается вычисление расстояний именно на сфере, для вычислений используется сфера радиусом 6372795 метров, что может привести к ошибке вычисления расстояний порядка 0.5% (приблизительно 0,47 метров).

Для определения расстояния между точками, при помощи координат широты и долготы, было три варианта: Сферическая теорема косинусов, Формула гаверсинусов, Модификация для антиподов. Итак, рассмотрим каждую формулу отдельно.

Сферическая теорема косинусов. Имеет формулу:

где

- широта и долгота первой точки;

- широта и долгота второй точки ;

- разница координат по долготе;Размещено на http://www.allbest.ru/

- угловая разница.Размещено на http://www.allbest.ru/

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

Формула гаверсинусов. Используется, чтобы избежать проблем с

небольшими расстояниями.

где

- широта и долгота первой точки;

- широта и долгота второй точки;

- разница координат по долготе;Размещено на http://www.allbest.ru/

- угловая разницаРазмещено на http://www.allbest.ru/

.

Модификация для антиподов. Позволяет более точно определять расстояние между близко расположенными точками.

где

- широта и долгота первой точки;

- широта и долгота второй точки;

- разница координат по долготе;Размещено на http://www.allbest.ru/

- угловая разница.Размещено на http://www.allbest.ru/

Громоздкость данной формулы и большое количество тригонометрических вычислений негативно скажется на быстродействии системы. Поэтому она тоже не подходит.

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

Для определения времени затраченного на весь путь необходимо найти разность между значением времени в последней точке и значением в первой точке. Для этого будем последовательно вычитать секунды, затем минуты, часы и т.д. используя заем из старших разрядов по принципу вычитания «столбиком». Результат в формате «ДД;ЧЧ;ММ;СС».

2.4 Разработка алгоритма подбора трека

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



Рисунок 2.2 - Алгоритм поиска

2.5 Разработка схемы БД

Необходимо определить таблицы, поля в каждой таблице, а также отношения между полями и таблицами.

Таблица «Треки» содержит поля:

“Название” - имя, под которым был сохранен трек.

“Участник” - человек, производивший запись трека.

“Дата” - дата сохранения трека.

“Начальный пункт” - место отправления.

“Конечный пункт “- место прибытия.

“Результаты расчетов” - параметры, которые были получены в результате обработки трека.

Таблица «Координаты» содержит поля:

“№ трека” - порядковый номер трека.

“№ записи” - порядковый номер точки.

“Широта” - координаты широты точки.

“Долгота” - координаты долготы точки.

Таблица «Пункты» содержит поля:

“Название” - имя пункта.

“Область” - область, в которой находится пункт.

Таблица «Участники» содержит поля:

“Фамилия” - фамилия участника.

“Имя” - имя участника.

“Отчество” - отчество участника.

“Статус” - статус участника в группе.

Таблица «Расчеты» содержит поля:

“Время пути” - время, затраченное на прохождение маршрута.

“Расстояние” - длина маршрута.

“СреднСкорость” - средняя скорость движения за все время пути.

Таблица «Статусы» содержит поля:

“Гуру” - лидер группы.

“Мастер” - участник группы со стажем более двух лет.

“Бывалый” - участник группы со стажем более одного года.

“Новичок” - участник группы со стажем менее одного года.

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



Рисунок 2.3 - Схема данных

2.6 Соглашение имен переменных

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

str -- String, символьное значение;

c -- константа;

ch -- символ;

p -- указатель;

b -- Boolean, логическое значение (True или False);

d -- дата;

n -- числовое значение;

i и j -- обобщенные счетчики циклов;

Для функций и структур тоже были определены префиксы:

fn -- функция;

stc -- структура;

Все имена классов начинаются с заглавной "С" с последующей заглавной буквой (например, CPath, CPrint, CStrm и т.д.).

3. Расчеты и оценки быстродействия

Если задача, решаемая на ЭВМ, фиксирована, то объем информации, которую необходимо переработать для получения результата, также задан. Однако время решения задачи существенно зависит как от скоростных характеристик ЭВМ, так и от характеристик алгоритма.

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

Для ускорения работы данной системы был применен принцип нормализации БД, а именно - предварительные расчеты. В БД имеется таблица, хранящая результаты расчетов всех треков. Таким образом, при повторном обращении к треку нет необходимости заново выполнять все вычисления, а можно просто обратиться к таблице, хранящей результаты всех проведенных вычислений. На рис.3.1 приведена схема обращения к трекам. Из схемы видно, что данный подход существенно ускоряет работу системы.

3.1 Скорость расчетов

Для определения скорости расчета трех параметров (расстояние, время, скорость) было проведено несколько тестов при различных количествах точек в треке. Результаты выполнения тестов представлены в графике на рис. 3.2.



Рисунок 3.2 - Тест быстродействия

Как видно на графике зависимость времени от количества точек напоминает функцию y=2^x . Следовательно, быстродействие системы существенно снижается при большом количестве точек в треке. Таким образом, учитывая то, что в каждом треке содержится в среднем 700 точек, можно сделать вывод, что быстродействие системы при расчетах параметров является вполне приемлемым, но как указывалось в п.2.3, максимальная точность при этом не достигается.

3.2 Скорость поиска

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

Так как ежегодный прирост БД до 20МБ (это около 50 треков) необходимо определить при каком количестве треков в БД поиск будет занимать большое количество времени и работа с системой будет невозможна. Для начала было проведено несколько тестов, в результате которых была определена динамика изменения скорости поиска.

50 треков - 1 с.

70 треков - 1,6 с.

100 треков - 2 с.

В результате проведения линейной апроксимации в Excel, было выявлено, что при хранении в БД 373 треков приблизительное время поиска составляет 7,5 с. Это значение было принято как предельное время поиска.

Итак, размер БД при 373 треках - 149МБ. Вычитание уже имеющихся 40МБ (100 треков) и деление на ежегодный прирост (20МБ), дает 5,46. Через пять с половиной лет при активном использовании система не сможет полностью удовлетворять все потребности пользователя, а именно, подбор трека будет занимать большое количество времени. Но заявленный в техническом задании срок службы составляет 5 лет, а значит, данная система удовлетворяет условию задания.

4. Разработка руководства пользователя

4.1 Запуск системы

Для корректной работы программы необходимо файлы atg.exe и dbt.mdb скопировать в корневой каталог диска С:. Далее можно производить запуск системы. Запуск производится открытием файла atg.exe.

4.2 Общий вид

После запуска программа выглядит как показано на рис. 4.1

Рисунок 4.1 - Общий вид

Это главная форма программы. Для произведения каких-либо манипуляций над данными необходимо сначала открыть файл GPS трека и добавить его в БД или открыть уже существующий в БД трек. Это осуществляется нажатием кнопок «Открыть файл» и «Открыть трек», соответственно.

Выход из программы осуществляется нажатием кнопки «Выход» или нажатием на красный крестик в правом верхнем углу.

4.3 Открытие файла

Для добавления нового трека в БД необходимо нажать кнопку «Открыть файл». В появившемся диалоговом окне указать путь к файлу и нажать кнопку «Открыть». Затем на главной форме программы нужно нажать кнопку «Экспорт».

Рисунок 4.2 - Открытие файла

4.4 Расчет параметров

Расчет параметров производится для определения средней скорости движения, пройденного расстояния и времени, затраченного на прохождение данного маршрута. Эта функция становится доступна только после добавления трека в БД. Добавление трека осуществляется нажатием кнопки «Экспорт». Расчет производится кнопкой «Рассчитать». Результаты расчетов выводятся в левом нижнем углу главной формы.



Рисунок 4.3 - Результаты расчетов

На рис. 4.3 представлены результаты расчетов, где Speed - средняя скорость в км/ч; Points - количество точек в треке; Track - длина в км; Time - время пути.

4.5 График набора высоты

После проведения расчетов становится возможным построения графика набора высоты. Он показывает высоту над уровнем моря в каждой точке трека.

Рисунок 4.4 - График набора высоты

4.6 Подбор трека

При нажатии кнопки «Подобрать трек» открывается окно, позволяющее пользователю выбрать критерий и границы поиска.

Рисунок 4.5 - Критерии поиска

После ввода границ поиска нажатием кнопки «Найти» осуществляется непосредственно сам поиск, результаты которого показываются в новом окне.

Рисунок 4.6 - Результаты поиска

4.7 Открытие трека

Для открытия нужного трека из БД необходимо ввести его имя в специальную строку в верхней части главной формы и нажать кнопку «Открыть трек».



Открытый трек будет представлен в виде таблицы в левой верхней части главной формы.

Рисунок 4.7 - Трек в виде таблицы

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

Заключение

В рамках данного проекта была разработана система позволяющая хранить, обрабатывать и подбирать треки GPS. Реализовано автоматическое определение средней скорости движения, времени пути, расстояния. Для проведения расчетов были подобраны оптимальные формулы, позволяющие с приличной точностью определять параметры. Были произведены расчет и анализ быстродействия системы с учетом динамики увеличения БД. Так же был реализован подбор трека по пользовательским критериям, позволяющий быстро найти в БД треки с подходящими параметрами. При создании системы были использованы: Borland C++ Builder, так как он имеет наиболее простые и в тоже время гибкие средства для доступа к базам данных. Язык С++ является одним из самых мощных из распространенных языков ООП. Microsoft Access - представляет собой простой и многофункциональный инструмент для создания баз данных, а так же отлично взаимодействует с Windows.

Плюсы данной системы:

- база данных, позволяющая организованно хранить треки;

- автоматический подбор треков по пользовательским критериям;

- простой интерфейс.

Минусы:

- работа с треками только одного формата;

- снижение быстродействия при большом количестве точек в треке;

- нет привязки к карте.

Возможно развитие системы по следующим направлениям:

- расширение системы для работы с большим количеством форматов;

- увеличение быстродействия путем усовершенствования имеющихся алгоритмов;

- отображение маршрута на карте.

- подбор треков по нескольким критериям одновременно

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

Список литературы

1. Павловская, Т.А. С/С++. Программирование на языке высокого уровня/ Т.А. Павловская -- СПб.: Питер, 2003. --461 с.: ил.

2. Дубинин, М.Н. Вычисление расстояния и начального азимута между двумя точками на сфере/ М.Н. Дубинин - http://gis-lab.info/qa/great-circles.html, 2011.

3. Хроменко, А.Д. Работа с базами данных в С++ Builder/ А.Д. Хроменко -- СПб.: БХВ-Петербург, 2006. -- 496 с.: ил.

4. Дейт, К. Дж. SQL и реляционная теория. Как грамотно писать код на SQL/Пер. с англ./К. Дж. Дейт -- М.: «Символ-плюс», 2011. -- 480 стр.: ил.

Приложение А

Реализация выполнения расчетов

Form1->ADOTable1->First();

date1=DBGrid1->Fields[1]->AsString;

j=Form1->ADOTable1->RecordCount;

for(i=1;i<=j;i++)

{

perem=DBGrid1->Fields[1]->AsString;

length=DBGrid1->Fields[2]->AsString;

cel = atof( perem.c_str() );

lcel = atof( length.c_str() );

ADOTable1->Next();

perem=DBGrid1->Fields[1]->AsString;

length=DBGrid1->Fields[2]->AsString;

cel2 = atof( perem.c_str() );

lcel2 = atof( length.c_str() );

delt=lcel2-lcel;

rez1=sin((cel2-cel)/2);

rez1=rez1*2;

rez2=cos(cel);

rez3=cos(cel2);

rez4=sin(delt/2);

rez4=rez4*2;

rez=2*asin(sqrt(rez1+rez2*rez3*rez4));

rasst=rasst+rez;

}

rasst=rasst*r_zem;

date2=DBGrid1->Fields[4]->AsString;

sscanf(date1.c_str(),

"%d.%d.%d %d:%d:%d",

&day1,&month1,&year1,&hour1,&minute1,&second1);

sscanf(date2.c_str(),

"%d.%d.%d %d:%d:%d",

&day2,&month2,&year2,&hour2,&minute2,&second2);

second3=second2-second1;

if(second3<0)

{

minute2--;

}

minute3=minute2-minute1;

if(minute3<0)

{

hour2--;

}

hour3=hour2-hour1;

if(hour3<0)

day2--;

day3=day2-day1;

if(day3<0)

month2--;

month3=month2-month1;

if(month3<0)

year2--;

year3-year2-year1;

Form1->Edit1->Text=rasst;

Form1->Edit2->Text=j;

Form1->Edit3->Text=lsumm;

Form1->Edit4->Text=day3;

Form1->Edit5->Text=hour3;

Form1->Edit6->Text=minute3;

Form1->Edit7->Text=second3;

Открытие файла и добавление данных в БД

stream = fopen("FileName","r");

if(!stream)

return;

TADOQuery *Qu = new TADOQuery (this);

Qu->Connection = ADOConnection1;

Qu->SQL->Clear();

Qu->SQL->Add("CREATE TABLE Table_Name");

Qu->SQL->Add("(Код int identity,");

Qu->SQL->Add("Coord1 varchar (255) NULL, ");

Qu->SQL->Add("Coord2 varchar (255) NULL,");

Qu->SQL->Add("Поле3 varchar (255) NULL, ");

Qu->SQL->Add("Date varchar (255) NULL)");

Qu->SQL->Add("Поле4 varchar (255) NULL, ");

Qu->SQL->Add("Поле5 varchar (255) NULL, ");

Qu->SQL->Add("Time date NULL)");

Qu->ExecSQL();

delete Qu;

while( fgets(ch,LEN,stream)!=NULL)

{

i++;

if(i>6)

{

while(ch[j]!='\n')

{

cod[a][k]==ch[j];

if(ch[j]==',')

{

k=0;

a++;

}

j++;

k++;

}

}

}

TADOQuery *Qu2 = new TADOQuery (this);

Qu2->Connection = ADOConnection1;

Qu2->SQL->Clear();

Qu2->SQL->Add("INSERT INTO FileName");

Qu2->SQL->Add("( Код, Coord1, Coord2, Поле3, Date, Поле4, Поле5, Time) VALUES");

Qu2->Parameters->ParamByName("Код")->Value=cod[0];

Qu2->Parameters->ParamByName("Coord1")->Value=cod[1];

Qu2->Parameters->ParamByName("Coord2")->Value=cod[2];

Qu2->Parameters->ParamByName("Поле3")->Value=cod[3];

Qu2->Parameters->ParamByName("Date")->Value=cod[4];

Qu2->Parameters->ParamByName("Поле4")->Value=cod[5];

Qu2->Parameters->ParamByName("Поле5")->Value=cod[6];

Qu2->Parameters->ParamByName("Time")->Value=cod[7];

Qu2->ExecSQL();

delete Qu2;

Edit1->Text=tmas;

fclose(stream);

Размещено на Allbest.ru