ractThe paper describes new software for manipulating GREIS-formatted raw data. The implementation features a way of keeping it's codebase up-to-date with format by means of automatic code generation. Core component is C++ library that provides methods to load, save and manipulate GNSS measurements data as classes and methods. Input and output is flexible. Current implementation, beside binary files, includes MySQL database as both destination and source of the data. For end users we provide simple yet sufficient tools for both binary and MySQL database survey data. IntroductionSince launch of first NAVSTAR satellites GNSS became a new instrument for studying the Earth. To enable coordinated effort of collecting and analysing GNSS measurements data, networks of continuously operated stations have emerged. There are several global\cite{igs} networks that maintain stations across the world and some regional\cite{gsiterras,noaacors,nasacddis} networks that collect data of specific regions. All these networks maintain an archive of data for variety of applications ranging from geodetic augmentation to studies of modern crustal motion. Often network operators make this archives available to public. Some networks in addition to historical data also provide realtime data. Realtime data is primarily used for geodetic RTK applications, however it's scientific value is also high for early tsunami monitoring systems, ionospheric tomography and other applications.GNSS measurement networks generally utilize Receiver Independent Exchange Format (RINEX)\cite{gurtner1989common} to distribute data. Some networks even use this format to collect data from stations e. g. the IGS\cite{igsrinex}. RINEX is a whitespace-separated ASCII set of fields with distinguishable header and data blocks. Early RINEX philosophy like most other universal formats concluded that most data applications don't need all the data that the instrument could produce. This led to format that defined only time marks, pseudoranges and carrier phases. Later revisions added Doppler measurements, new navigational systems and some other features. Generally, drawbacks and imperfections of early RINEX revisions spawned several other formats. For instance, RINEX is an ASCII format. It means that it uses human-readable symbols like letters, numbers and whitespaces to represent data. While this allows one to manipulate the file with simple and generally available tools and eliminates platform incompatibilities it also brings excess storage requirements in. This particular issue was addressed with Hatanaka compression\cite{hatanaka1996rinex}. This compression greatly reduces the size of original RINEX files sacrificing its readability. However, there is no API that enables direct access to compressed RINEX and most software lacks support of Compressed RINEX so generally this format is not used directly and native RINEX conversion always takes place. Later, \cite{galas2001binary} pointed on insufficient precision and incompleteness of early RINEX revisions and proposed the GFZ-BINEX format. The format is similar to RINEX, except that it is binary, allows better precision and accepts new types of observables. Another binary format is UNAVCO's BINEX. It is a more complex format, capable of handling different records within single volume, supports checksumming, capable of embedding ephemeris, orbital and geodetic solution data and has many more other features. UNAVCO sees BINEX as a replacement for RINEX since 2000 but it is still rarely used. All cited formats are usually utilized for storing, publishing and processing of historical data. Realtime applications utilize different formats, such as RTCM, that originated from Radio Technical Commission for Maritime Services, an US not-for-profit company. The RTCM SC-104 format's primary goal was enabling differential GNSS techniques and now it is used for both storage and realtime applications.Data networks will benefit much if format they utilize is capable of storing all the observables that receivers provide. The number of observables grows with satellite systems being upgraded. Recent changes in navigation systems include launch of new navigation systems, introducing of new broadcast frequencies and new signals (какие )именно и когда?). All this changes are rapidly reflected in receiver's firmware and new observables are made available from the receiver, but lack of support in storage format leads to new types of data being discarded. To address this vendors and committees revise their formats. For example, there are three major RINEX versions which introduced the anti-spoofing flag, GLONASS support, better time resolution, non-integer sampling rate, doppler observables and so on (ссылки на соответствующие версии). Each new revision changed the way the data is stored i.e. changed field lengths, changed field types, added new possible values thereby breaking compatibility. While not crucial, version incompatibilities require additional coding to handle. We consider that incompleteness, incompatibilities, slow development of universal formats make them hard to use for storage purposes in GNSS data networks. Vendor-specific formats tend to closely match the extending receiver's capabilities thus becoming the optimal way to collect measurement data. Vendor-specific formats are often not available to public, with rare exceptions For instance, "JPS" also known as GREIS is a proprietary format used in Javad GNSS and Javad Positioning Systems hardware, as well as in receivers of Javad Navigation Systems (Topcon and Javad joint). Systems.The basic concept in GREIS is using messages of strict format to store measurements, stati, navigation data and other related information. Message in terms of GREIS consists of a header and a data blob. Header encodes message type and its byte length while data blob is represented by serialized data structure consisting of several fields. The field is either one of the basic types (e. g. integer, float, char) or an array of one of basic types. Many message types contain a checksum field. The format is designed for maximum backwards compatibility hence, if implemented correctly, the parsing software would just ignore unknown messages. The specification defines the way that both current and any possible new messages should be handled. The format is supported in multiple geodetic and scientific software products, including popular freely available TEQC and open source RTKLIB. However, considering format evolution, to utilize it in GNSS data network we shall address the issue with specification updates. To reflect changes in GNSS receiver vendor modify the firmware that receiver runs on. Often, the firmware update is delivered online and that process is quite straightforward. In order to process new types of measurements (or deal with other changes) the corresponding software should be updated as well. To minimize the delay between the new measurements are introduced and the software update that makes it capable of processing them we implemented automatic code generation that relies on vendor's format specification. This is particularly useful because as the vendor delivers the firmware update to production-grade sites it also publishes a revised format specification. With updated specification the generated code is updated as well. Because update is performed relatively easy and mostly automatically we call our software "evergreen". The term "evergreen" is believed to be coined in business management and meant always available or always suitable option or idea. In computer science "Evergreen Software" is an update strategy that implies little to no effort to bring the product to the most recent release. LibraryНаша цель - создание ПО для сетей сбора данных. Мы должны обеспечить поддержку регистрации данных, передачи данных в ЦОД, первичная обработка, переформатирование, хранение (резервное копирование, архивация - вертикальная масштабируемость (?)), организация доступа (распространение данных, публикация как данных, так и результатов их обработки). Имея в виду тенденцию к увеличения плотности сетей наблюдения необходимо обеспечить горизонтальную масштабируемость системы.Не претендуя на решение полного круга задач приведем подход к единому решению. В качестве иллюстрации приводим практически полезные инструменты в рамках системы. Мы будем считать, что пункты наблюдений оснащены приемным оборудованием JAVAD или что приемники совместимы с GREIS. С одной стороны, это, действительно, распространенное оборудование. С другой стороны, формат сообщений открыт и удобен для использования. Многие из перечисленных задач, эффективно решаются и СУБД... Чтобы использовать БД нужно отобразить сообщения приемника ГНСС (в нашем случае - GREIS) в реляционную структуру... Кроме того, для манипулирования данными необходимо ПО. Все это делается на автоматической обработки GREIS...и как бонус - документация. This software is a programming component that is used to create tools for GNSS data management service. The purpose of such service is to collect, store and make publicly available GNSS measurement data. Key features of such data management service include providing online access to captured data for user-chosen period of time and being capable of capturing every piece of measurements that the receiver can provide.To enable stable and fast access to stored data the service should implements some features that are generally attributed to database management systems. These features are: horizontal scaling, data redundancy, and predictable search time. One of the ways to acquire these traits is to utilize a popular relational database management system such as PostgreSQL or MySQL with its forks. RDBMS like those already include the desired features. Through database clustering we can achieve horizontal scaling, replication provides data redundancy and with indexes we can achieve predictable search time. In our software we have chosen MySQL as database management system, however, this could be easily changed. The API's to access the RDBMS are public and are available for almost any platform and programming language. To use RDBMS as storage for GNSS data our manipulation API provides all the necessary connectors.To implement the capture capability feature we have decided to use vendor-specific format with an evergreen API. This reduces the effort to manually keep the format up-to-date with receiver capabilities. The subject software implements GREIS. Unlike most other vendor-specific formats GREIS has a very well-formed specification. So we designed an automated code generator that processes the official specification into C++ code of program library we called "Greis", database schema for MySQL and brief documentation in Doxygen. At the core of automatic code generation lies the meta-information gathered from official vendor documentation, a document called "GNSS Receiver External Interface Specification". This document describes the format used by the receiver's firmware. To obtain formal format definition from this human-readable document we utilize some basic methods of natural language processing. The result of such processing is format specification metainformation. This metainformation is a sufficient instrument to describe any message. To generate metainformation we locate the specific fragments of text, analyse them and then build a syntax tree. Those specific fragments of interest are C-like message definitions, as seen on fig. 1. After analysis we have a syntax tree except for dynamic length messages. Dynamic length messages have fixed structure but dynamic field length. To deal with such messages we attempt to guess the array size depending on message size and array type. This is valid for messages with only one dynamic field: [.[SI],Sat[SI],Satellite Indice [SI], Carrier Phases [CP], [. Some messages, such as "Spectrum" [sp]has two variables in definition. In this case automatic code generator produces code to handles the whole message without providing methods to access individual fields.essage.fields.t.fields.sagefields.ncountered The analysis is performed in two steps: inter-message and intra-message and is sort of finite-state The result is an abstract syntax tree that describes the whole message composition. This abstract syntax tree is ultimately formalized into XML-formatted specification. This XML is then used to create library headers, code files, doxygen documentation and SQL deployment schema.