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