should contain all topographic objects that are represented in 
HOK, TK25 and in other small-scale maps. 
Functionally oriented modelling significantly improves the 
status and the quality of data. The reality, in our specific case 
the landscape with all its complexity, can be represented in a 
satisfactory way only by respecting the complexity. 
Cartographic objects that are not included in the cartographic 
key are neither represented nor can be a part of the official 
geoinformation systems. 
  
  
  
  
  
  
Figure 1. Creation of STOKIS 
A model is representation of real world objects and the relations 
among them; i.e. model is the real world abstraction. Specific, 
clearly identified things and phenomena in the real world are 
called objects, and class is class type or type of an object. An 
object can be regarded as an instance of the class it belongs to. 
A data model encompasses all classes and objects that make 
part of the cartographic information system. Models bring 
together the data structure and the data processing. An object, 
as the basic element of object-oriented data, contains in 
addition to the description of data structure also the description 
of the operations that can be performed on it (attendance 
methods), (Biljecki, 2000). 
3. CARTOGRAPHIC MODEL 
Cartographic data model is a data model that describes the 
structure and contents of cartographic database (KBP) for the 
purpose of establishing the cartographic information system. 
Cartographic information system is developed for cartographic 
object system. The basic elements analysed in cartographic 
object system are topographic objects. Topographic objects that 
we present, are defined by means of a cartographic key for a 
given scale. All topographic objects presented on TK 25 and 
HOK are compiled on the basis of CROTIS data model. 
The establishment of the cartographic model has created a 
precondition for the cartographic database that will be used for 
carrying out a direct implementation of vector data model. it 
will contain the elements of graphics and alphanumeric, and the 
visual appearance will remain identical to the graphic 
64 
appearance of TK25 and HOKS, and to the other small scale 
maps. 
During the design of cartographic data model the following has 
been taken into consideration: CROTIS input data model, 
topographic database (TBP), and cartographic key (HOKS 
version 1.3, TK 25 version 1.5). Topographic objects, economic 
parameters, conformity with European cartographic information 
systems, etc. have been identified visually. Topographic objects 
that are to be structured using the data model are called 
topographic features. The features are categorised into classes; 
i.e. the features of the same properties form a class. 
The first phase in the structuring of the model is logical and 
effective classification of features (topographic objects) 
according to the type of geometry (point, line, area) and 
toponyms (that are actually points as well). Thus, all 
topographic objects defined by cartographic key and depending 
on the cartographic presentation are classified into area objects 
(POVRS), linear objects (LIN), point objects (TOC) or 
toponyms (TOP). 
After carrying out the classification of topographic objects, it is 
necessary to pay attention to the graphic database hierarchy 
since all topographic objects have been associated to a graphic 
database already defined in the process of map production. 
<<Leaf>> 
Coordinate Geometry 
<<Leaf>> + DirectPosition 
Geometric aggregates 
+ GM_Aggregate 
* GM MultiCurve 
* GM MultiPoint 
* GM MultiPrimitive 
* GM MultiSolid 
* GM MultiSurface 
Geometric primitive 
* Bearing 
* GM Boundary 
* GM ComplexBoundary 
* GM Curve 
* GM CurveBoundary 
* GM OrientableCurve 
* GM OrientablePrimitive 
* GM OrientableSurface 
* GM, Point 
* GM Primitive 
+ GM_PrimitiveBoundary 
* GM Ring 
* GM Shell 
* GM Solid 
* GM. SolidBoundary 
* GM Surface 
<<Leaf>> 
Geometry root 
* GM Object 
<<Leaf>> 
Geometric complex 
* GM Complex 
* GM Composite 
4 + GM_CompositeCurve 
* GM CompositePoint 
* GM, CompositeSolid 
* GM CompositeSurface 
* GM AffinePlacement 
* GM Arc 
* GM ArcByBulge 
* GM ArcString 
+ GM_ArcStringByBulge 
+ GM_Bezier 
* GM, BicubicGrid 
* GM BilinearGrid 
* GM BSplineCurve 
* GM BSplineSurface 
* GM. BSplineSurfaceForm 
* GM Cirde 
* GM Clothoid 
* GM Cone 
* GM Conic 
* GM CubicSpline 
* GM Curvelnterpolation 
* GM CurveSegment 
* GM. Cylinder 
* GM Envelope 
* GM GenericCurve 
* GM GenericSurface 
* GM Geodesic 
* GM GeodesicString 
* GM GriddedSurface 
* GM Knot 
* GM KnotType 
* GM LineSegment 
* GM LineString 
* GM OffsetCurve 
* GM ParametricCurveSurface 
* GM Placement 
* GM PointArray 
* GM. PointGrid 
* GM, PointRef 
* GM. Position 
* GM Polygon 
* GM, PolynomialSpline 
* GM  PolyhedralSurface 
* GM SurfacePatch 
*GM Tin 
* GM Triangle 
* GM TriangulatedSurface 
* GM Sphere 
* GM SurfaceBoundary 
* GM SplineCurve 
* GM SplineCurveForm 
* GM Surfaceinterpolation 
+ TransfiniteSet<DirectPosition> 
Figure 2. UML diagram of geometric properties( ISO/TC211, 
2000-2002) 
4. THE ROLE OF ISO STANDARDS 
Spatial data transfer among various users, applications, systems 
and locations requires standardisation of digital geodata. 
Formal model descriptions for specific applications - 
application schemas - have been made in order to enable 
geodata exchange. 
A formal language for data description - Unified Modeling 
Language (UML) - has been applied for the description of the 
conceptu: 
according 
for geoint 
19109 
m IC 
I 
; 
Figure 3 ! 
Unified N 
oriented 
constructi 
(Booch, F 
planning 
business 
matter su 
schemas « 
Except fo 
an import 
language 
Good nx 
projects te 
the incre 
modelling 
additional 
key factoi 
There are 
technique 
= modi 
deve 
= mod 
beha 
a mod 
* mod 
UML is 
suggested 
example « 
Usage di: 
Taking i 
interactio 
objects. 1 
objects. 1 
and colla 
the intera 
collabora 
Of course 
both type 
He or she 
hand. By 
recognise