DEVELOPMENT OF RURAL ARCHITECTURE – DESIGN AND CREATION OF A WEB DATABASE

The article deals with the design of database structures of a web application for the presentation of information about the development of rural architecture in the 19th and 20th centuries in the territory of today's Czech Republic. The processes of data structure design, description of the chosen solution and method of implementation are presented. The solution used is based on freely available technologies and applied to the creation of a smaller web portal. The described methods can be inspiring for similar types of web presentations, which are a frequent output of many activities and projects. The created web application contains various types of data: maps of selected villages, spatial models of selected rural buildings, their floor plans, created orthophoto, photo gallery, and other textual and graphical information documenting the development of rural architecture. Objects of interest are located on the used interactive map. The application allows users to search and filter the required data. The technological solution is based on the PostgreSQL database and the PHP Nette framework. The created portal presents interesting information about important values of rural architecture, which can be considered as a part of the cultural heritage. The web portal can be used by experts and the general public.


INTRODUCTION
Modern web portals provide users with a large amount of information that is stored in various data files and formats. The tool for effective management and analysis of differentiated and content-structured information is a geographic information system (GIS). It is based on a database that has effective tools for all necessary data operations (editing, backup, history tracking, secure access, etc.). An important aspect of the creation of every GIS application is the design of a suitable data structure of this database. The design of a suitable structure for a database of documents relating to the development of rural architecture is the subject of this article. the development of urban planning of selected municipalities and art historical studies of selected houses in rural regions. The aim of the research is to map and promote the significant values of rural architecture and thus contribute to their preservation for future generations. The results of the research should also support the general debate on the need for more consistent monument protection of rural architecture, which would prevent the gradual devastation of its urban and stylish structure.
The changes in rural architecture that took place in the last two centuries are documented in many ways and forms. An important source of information about the development of rural localities are old maps, later black and white aerial survey photos, currently colour orthophotos. Historical drawings, later photographs, plans, results of geodetic surveying by various methods, possibly audio or video recordings, today also digital spatial models may be available for the study of important buildings. Across time and type of subject of interest, a number of verbal descriptions in the form of written or printed documents can be a valuable source of information.
In terms of building development, a total of 39 villages evenly distributed throughout the Czech Republic (three villages in each region) were processed within the mentioned research. In 13 of them (one in each region) detailed maps were prepared, clearly showing the built-up area development and the digital spatial models were made for 13 selected village buildings.

Fig. 1 -Location of selected villages and buildings
The selection of villages was made with regard to the historical significance of architecture. Locations that were so far outside the main interest of experts were selected for the research. Selected buildings represent characteristic historical buildings of the region, which have not yet been subjected to detailed architectural and historical research and show a high degree of originality. The location of selected villages and buildings is shown in Figure 1.

DATASETS
The collected and sorted material, as well as all processing results, must be systematically managed in a suitably selected system (database). An important element of the concept of such a system is an effectively designed structure, with respect to the type of data and the relationship between them. The following is an overview of the main data sets used and their brief characteristics.

Maps of built-up area development
The maps of built-up area development were created on the basis of detailed analyzes of archival and current maps [2] and they show the development of buildings in the period from the mid-19th century to the present. In the database, maps are stored in the PDF vector files (divided into thematic layers) and in the PNG raster files. All processed maps are presented interactively on the page http://venkov.fsv.cvut.cz/projekt/vesnice.html.

Spatial models
The modelling of all objects was based on data obtained by survey of objects [3]. A combination of geodetic and photogrammetric methods was used. The creation of the exteriors of the models was done in the form of vectorization of a point cloud; the interiors were modelled on the basis of the floor plans. The database stores models in the 3D PDF format and raster previews of models in the PNG format. All processed models are presented interactively on the page http://venkov.fsv.cvut.cz/projekt/modely.html.

Floor plans
For the geodetic survey of the ground floor plans of the modelled buildings, the method of constructional measures supplemented by cross measures was used. The floor plan drawings correspond to their real model geometrically and dimensionally with sufficient accuracy. It is therefore possible to determine control measures retrospectively, e.g. lengths and angles, between building structures that are not easily detectable in reality. The connection of the drawings to the state reference coordinate system was performed using current cadastral maps. In the database, floor plans are stored in the PDF format.

Orthophotos
Orthophotos were processed on the basis of archival aerial survey photos (LMS) and the current digital relief model (DMR 5G). A sufficient number of naturally signalled ground control points were used to make orthophotos, the coordinates of which were obtained from the current maps. The accuracy of the resulting orthophotos was verified at checkpoints and is in the interval 1 -1.5 m according to the age and quality of the LMS used [4]. In the database, the created orthophotos are saved as TIF files with georeferencing in TFW files.

Other text and graphic documents
The database includes other various text and graphic files (articles, photographs, plans, sketches). In general, these materials can be divided into two groups according to the date of origin: archival and contemporary. They are stored in the database in various formats depending on the type of data.

METHODS AND TECHNOLOGIES
Interactive websites presenting various documents can be based on many technologies. Simpler content can be effectively presented without the use of sophisticated database tools [5]. In current practice, still popular and much used systems based on the traditional relational database model (RDBMS) are used to manage a common documentation pool. These systems are mostly based on the client-server architecture, where the client communicates with the server component using the Structured Query Language (SQL).
The relational database model, as practice shows, is not ideal in all cases [6], [7]. For large amounts of data (so-called "big data") or data that do not fit into the relational model due to their structure, database systems are used, which are in many respects more advantageous for the management of such data. These systems include so-called NoSQL (not-only SQL) databases [8], [9].
In addition to the efficiency of storing and modifying the content of documents, a key element in the design of the database is the ability to index their content for full-text search. Another important feature may be the ability to track changes in document content over time (similar to versioning systems). The choice of the used database system is essential for the longterm sustainability and extensibility of the proposed information system. The following text describes the design and implementation of a specific database, including the relevant web application.

Application design
The initial task was to create a database system with an appropriate web interface to facilitate the storage, sorting and representation of the data used. In this section, these tasks are looked at individually, with a strong accent on data presentation in the database design process.
The first order of business was to formulate an appropriate technical solution for the task at hand. The first task was to create a system that would suitably present a complex sets of data regarding to selected municipalities and buildings in the Czech Republic. First of all, detailed discussions about proper data presentations were conducted. Then a database model was devised. The initial data presentation was to create tables for each specific entity (such as buildings, municipalities, documents, maps, etc.), that would be linked together in a parent-child type of relationship. This way, all documents would correspond to a building, all buildings to municipality, those then to a district, and so forth.
After the principal guidelines were defined, the tasks moved to create a user interface. Several technologies to base the application on were considered. One of the primary options was the Java Spring framework coupled with a front end powered by such technologies as react.js. A more high-level language approach would make the applications design more robust and modular. In the end the PHP and Nette framework was selected, as PHP was a technology more familiar to the production team. The Nette framework was an added value that could give the solution a more high-level design such as Java Spring framework.
During this time, a number of similar projects were reviewed to gain inspiration for website design. The subject of interest was the website, which contains an interactive map connected with other information about selected thematic objects displayed on the map. There is a large number of such web portals -they differ in the technologies used and the implemented functionality. The biggest conceptual inspiration was the website presenting the Archaeological Atlas of the Czech Republic (archeologickyatlas.cz). Using the knowledge gained through an extensive research, the original web database application was developed.

Principal usage
The website has the following basic uses: data presentation, storage and categorization. The first, the presentation, refers to the ability of all visitors to view the content of the web portal. Essentially, anyone can come to the web application and view all the published materials. The filtering feature makes it possible for researchers and the general public to find materials related to their interest or work.
The filter allows users to sort entities according to two basic attributes: entity type and keywords. A potential user can select what type of entity searches for, e.g. maps, documents or entire municipalities. The second filtering attribute lets the user select what keywords he wants to look for. A typical use case would be to find an archival document and specify the keyword type to be a map.
For other users -the maintainers, the website in addition to representation of their work, also serves in the storage and categorization portions. All registered users of the website can add and manage their own work. The web application provides a clear overview of the presented work results. A preview of the available user rights is shown in Figure 2. The basic use of the application remains the same for all users. All entities are created and stored under their respective parent entities. To find an entity, the search function can be used or the map, or simply navigate to the appropriate parent entity. If one is looking for data from a given district, he simply finds the region and selects the district to see all municipalities that contain some data. Alternatively, the filter form can also be used to enter such a query. This can be done by all users. But only the registered users can create new entities, keywords and edit the data.
To create something new, it is needed to navigate to the appropriate parent entity. For example, to add a new building, one does so from the page of the municipality the building belongs to. If the municipality is not listed, one must navigate to the district of municipality (all of which are listed for registered users) and first create the municipality. Editing an entity is performed at the site that actually represents it (in contrast to creation, which is done from the entities parents' page).

Technological approach
Web application technical design can be divided into two sections, database design and user interface design. The database uses the PostgreSQL v. 11 application. The web app runs on Apache webserver with PHP 5. The web application itself runs on the PHP Nette framework. The whole system is deployed on a virtual machine, running Debian Buster. Deployment diagram is seen in Figure 3.

Fig. 3 -Deployment diagram
As mentioned previously, the Nette framework was chosen to provide a more high-level support to the project. Unlike plain PHP, Nette is designed to facilitate web application design, handle several security problems, improve the code reusability and add various functionalities for handling database objects. The result is that using the framework, the application could be designed using a more industry standard template format. This proved a great help in the process of development as changes in ever larger application scaled very well.
The choice of PostgreSQL as the database client was motivated in part by the existence of the PostGIS spatial database extender. The motivation was, that as an application partially used for storing geo-informatics data, the addition of such functionality would be useful. While the PostGIS add-on is currently not used (as the only localisation of data stored in the database are GPS coordinates of municipalities and buildings -of which are in database terms few), it remains a good option for future expansion.
An important part of the website is the background map which indicates by the mark the location of processed municipalities and buildings. Location data (GPS coordinates) of elements can be entered into the database graphically by clicking on the location on the map, or by numerical values of coordinates from the keyboard. The map and database information are linked in both directions. Clicking on a marker on the map will display information about that feature. Similarly, selecting an element in the database displays the position of the element on the map. For example, when selecting a region, the location of all database elements located in the given region is displayed in the map with a marker.
The map server mapy.cz is used as a base map. It provides a detailed map with a resolution of the individual buildings displayed, including descriptive numbers. It is thus easy to locate individual buildings registered in the database on the map accurately. The map server contains a detailed documented application programming interface (API) that can be freely used for the development of publicly accessible user applications.

Database model
The data are represented as a set of texts, files, and attributes pertaining to various objects, such as municipalities, buildings, etc. A database system that was put forward resembled a knowledge tree, as most objects belonged to some parents and themselves had several children. Such as a municipality containing a number of buildings, the buildings having a large gallery are associated with them.
By the end of the process, the reflection was, that a graph database such as MongoDB might have been a better choice for representing this data structure, but due to familiarity with and general lack of system taxing database tree traversing operations, the selected SQL database system proved sufficient.
The original design did not change significantly. All objects or entities as they began to be called remained mostly unchanged. The major difference was that all the entities became represented primarily by one table (class), as seen in Figure 4. After some evolution, all entities proved to benefit from some common attributes (such as a name, description, etc.), that it was decided, the tree structure and common data for all entities, be represented in a single tableentity.

Fig. 4 -Domain model
A significant aspect of the entity design in the database model is the inclusion of keywords. Several types of keywords can be related to given entity types. Such as a building having the "type of building" or a photo of a building might have the "exterior type" keyword. These are used for description but primarily filtering. If someone is looking for a photo containing doors, beams, or renovated floors, one can simply filter for such images. The keywords also help to maintain a unified approach to categorization. Any registered user can create new keywords, but this practice will be later restricted. The flexible database design also enables to modify easily what keywords can be assigned to which entities, as this design configuration had to be changed several times during development.
The last notable part of the general domain model is the part documenting user actions. Every action in the system (creation, editing, deleting) is documented.
The following Figure 5 shows an overview of all used entities. These being the keywords, attributes, and general tree structure of all entities in the database application. The individual table attributes are accompanied by their data type.

Fig. 5 -Application entities
Acronym FK in this context means a foreign key usually to a set of keywords. It is the unique use of keywords being kept in this way at the database level. One may add keywords but only in a global context -for all entities with the given keyword type. then the keywords can be only assigned to individual entities. This is done so that individual users are discouraged from coming up with new keywords whenever they want and to rely more on a standardized set. Arrows represent the three like relations of the various entities in the application. The same coloured entities represent the duplicatione.g. the entities that can belong to both, a municipality or a building.
Finally, take note that while some entities contain a file as an argument (such as a document entity), entities such as archival or map can contain several files. These files are stored in the server file system. Upon upload to server all files are renamed using a unique identifier. This is done to prevent overriding existing files with new ones (user uploading file called map.pdf twice). Their original name is stored as entity name in the database. The name of the entity can be changed for the purposes of the website itself, but the file once downloaded keeps its original name.
The application, its database and uploaded files are subject to regular backups. These backups are facilitated using a bash backup script while the application is in development. Backups will be replaced by a fully automated system once the application is moved to the final production server after development is concluded.
Copyright must be strictly observed during the public presentation of documents on the website. The data used (archive maps, aerial survey photos, etc.) must contain information about the data provider. According to the license conditions, their presentation on the website is often conditioned by the use of a watermark with the abbreviation of the relevant organization. The documents used and created (photographs, maps, orthophotos, studies, etc.) must include the author's name and the type of license. This information is an integral part of the documents in the created web application.

RESULTS
Two teams of experts participated in the development of the described application. Experts in rural architecture (ÚDU) and specialists in geoinformatics (CTU). The usual problems in communication between members of differently oriented teams (caused by different professional vocabulary) occurred mainly in the initial phases of the cooperation. The ideas of ÚDU experts were transformed by the CTU team into the environment of the used technological tools. The concept of the proposed solution had to be modified several times with regard to new requirements.
The used data storage based on a classic relational database is sufficiently powerful and provides all the necessary functionality. For a larger amount of data with a looser structure, it would be possible to consider using a NoSQL database.
The NoSQL document database MongoDB was tested in the phase of finding suitable tools. Due to the relatively small amount of processed data and their quite unambiguous interconnection, the concept of a traditional relational database was finally chosen. The PostgreSQL database was selected, which is one of the most used freely available relational databases. The described solution based on the use of keywords is sufficiently powerful and flexible.
The application is currently in the testing phase of the final version, which will be then released as a production version. Through a web application, the database is filled with real data. Therefore, all subsequent fixes and enhancements to the application must be already made with a respect to the entered data. The application contains considerable potential for further development. Planned modifications include the implementation of a module for user management (so far implemented manually), expansion of search options, as well as optimization of the connection with the navigation map and improvement of a web design. A trial version of the application is available at https://country.fsv.cvut.cz/.

CONCLUSION
The created web portal organized presents information about the development of rural architecture in the 19th and 20th centuries in selected localities in the territory of today's Czech Republic in one place. Maps of built-up area development, floor plans and spatial models of buildings, orthophotos, photo galleries and a number of archival materials are available at the portal, all of them were supplemented by expert studies of the results of art historical research.
Some of the materials posted to the web server are not publicly accessible (e.g. due to copyright or data volume) and are used only for the needs of registered users of the portal.
The target group of users of the portal is the general public, but experts in the field of rural architecture will also find inspiring and new knowledge here. The information presented on the web portal serves to discover and better understand the values of the cultural heritage that rural architecture contains.