 |
|
CITY MODEL
In 1996, our office was commissioned to make an Analysis of the Land Use of Rijeka, which was to be a preparatory document for the city's new master plan. This material had to identify the basic facts of current land use and also produce a map which defined areas of different activities. How one can make such conclusions turned out to be the most important question. Due to various historical circumstances and its topographical situation, Rijeka has not developed a readable urban fabric. The city is covered by a homogenous mixed-use structure, in which one can hardly identify borders between areas of different use. Despite it specific urban form, Rijeka is generic in the sense that it raises questions concerning the extent to which present urban cartography is capable of representing contemporary cities. It was obvious that before starting with such a project, it would be neccesary to bulid an appropirate interface that could give an actual representation of the existing activities. To build the necessary data-base, we began inserting all available data into a GIS (geographic information system). This decision turned the original task into merely a fraction of the total work, which lasted over a year. Most of the time was consumed in the creation of the GIS project, which we have called the Dynamic Model.
Dynamic Model
The Dynamic Model represents a tool for the display and analysis of available geospatial data. GIS technology, in which this model was made, creates a relational model of geographically referenced data, which is a hybrid of a spatial and an attribute related model. Basically, it coordinates spatial information with records from related databases. Single coverage stores both geometric (graphic) and attribute (non-graphic) information. An item, like a parcel for example, can be then represented by an area geometry and defined by attribute information such as the owner's name. Available data can be divided into two categories: 1. spatial data (urban plans, census tracts, administrative areas, port territory, maritime domain, etc.) 2. data from the city's relational databases (population register, list of housing units, business register, etc.) The key issue, which in fact is the basis of the GIS project, is how this data is structured and represented. GIS technology can generate a limitless amount of information, which is then useless if the data is not appropriately filtered. Whereas this project was structured for planning purposes, the lowest level was set on the individual address. The other very important issue is the reliability of the data. The collection and processing of the data is a long process, and it is quite common that data used in similar studies becomes obsolete even before the study is completed. For that reason, the project was conceived in a way that it can be constantly up-dated. The project uses the city's exisitng databases and can therefore establish, at any time, an external link to them. In that way, change in the external database is registered in the model and thereby represents the actual situation on the ground.
Address Model
A central part of the project is the address model. The address model locates individual addresses in a coordinate system, in a way that it can relate them to the other features in the model. This enables relations of different features through addresses. The address model is created with points. Every individual address is located with a single point, which is associated with a unique code for its street and street number, using the existing address system. The programs in which the model was created, Arcad and ArcView, can establish links only with a single unique key. For that reason we have created a unique key UIN, which connects the three existing attributes. The original relational databases have been also updated with the UIN attribute. This process has enabled links with relational databases, and elementary statistical operations on this data (i.e. where a certain shop or a person is). In this process, 12,910 addresses have been created, linked with 167,138 records of the population register and 18,400 records of the business register. Analytical Unit
This data is not yet helpful for a physical analysis. For that reason a surface attribute had to be added which meant that the addressed data had to be summed on a certain spatial unit. The size of this unit defines the precision of the data, which should be set according to the scale of the project. At first we have considered the available spatial categories. Subdivision according to census tracts was too big and inoperative for this project. On the other hand, parcel division was equally inadequate, since it varied in size and shape and is therefore not neutral. For that reason, we have inserted a new level with a neutral grid that has no reference to the citys fabric. The size of the grid defines the resolution of the model. This individual pixel was called the analytical unit. A unit is defined as a part of a geodetic cross, 50 x 50 m in size (1/4 hectacre), which is the equivalent of an immediate neighbourhoud, or part of the city block. Using a topological overlay, individual units were linked with addresses. With the UIN key, all available statical informations have been summed for each analytical unit. This process has enabled a reading of the city structure. Once connected with relational databases, this grid has enabled the visual representation of all statistical categories, such as distribution of activities or population density. Data is represented either by a color range, or in 3D where the height of the column is defined by the value of a selected index. Indexes
The basic index used in this model was the total area ratio. Since the model contained information on all buildings, it was possible to get this index for the entire town as well as for floor areas of both housing and bussines. Calculations were made from the analytical unit level to that of census tracts. This data was differentiated in relation to the size of surfaces. The model has different levels of density, from simulated net density of an analytical unit to total city density, at the level of census tracts. Net density includes only lot areas without streets, while total city density includes the whole teritory. Using this process, new data has been aggregated which shows the total number and density of inhabitants per hectacre, the number and total areas of bussines and housing space, as well as statistical data such as the average, minimum, maximum and standard deviation on each of the categories, the ratio between them, etc. The ratio between activities has been used to determine the predominant use of the area. The basis for land use was National Classification of Businesses, since all records in external databases are grouped in this way. The national classifcation divides bussineses in areas, sub areas, departments, groups, classes and sub classes. This divison had to be slightly modified, since for example the metal industry is in the same area as that of printing. Division by areas was taken for most of acitivities, while some were isolated on the department level. In this process, a total of 20 categories were isolated. To enable comparison with other cities, these were further filtered in 5 basic categories; production, services, tertial activities, public institutions and leisure activities. Product
In total, the project has generated 70 GIS categories, 41 different tables, with over 7 million records. The land-use map, which was the original task, was done on the basis of interpretation of these results. Other analyses have been carried out as well, using GIS techniques such as overlaying, relational join operations, buffering and feature extraction. Application of this model seems to be its biggest achievement. As previously said, the model was made with the idea that it can constantly be up-dated from external databases and represent changes in real time. During 1998 and 1999, the project was converted into a GeoMedia and MGE project using the Oracle database system, following the decision of the city administration to switch to Oracle and Intergraph products. The model has been constantly updated, and is activly in use. |
|
|
|
