5. Definitions of the OBAK-LiegKat NRW
Elements to be captured / OSKA-code as identifier
There are about 1100 different objects defined within the
OBAK-LiegKat NRW, differentiated basically by their unique
OSKA-codes. The cartographic layout is only used for display
and plot respectively. This information is not to be transferred
while data transfer via EDBS (e.g. hatching for buildings,
embankments, default positions for annotations, etc.), except
for special solutions (e.g. annotation on non-default position,
etc.).
Working with graphic software such as MicroStation is based
on visualization of different features. Distinction between
elements is usually done by level, color, weight, line style, text
and symbol size and layout. Assigning numbers such as OSKA-
codes is not the preferred way, as most people can easier work
with visual impressions than with number codes.
Following this, a data structure has been designed, where to
each OSKA-code given in the OBAK-LiegKat NRW a unique
MicroStation level-symbology was assigned.
Layer orientation
This problem was easy to be solved as ALK as well as
MicroStation are layer oriented. So, for every ALK layer, one
or more MicroStation level are exclusively assigned. As
MicroStation is restricted to 63 levels, it is not always
possible, to keep the layer number equal to the level; but this is
done as far as possible. For various layer, more than one
MicroStation level was assigned for the sake of easier
differentiation of elements.
Geometric elements to be captured
For some of the objects, a restrictions in terms of the allowed
geometric elements is given in the OBAK-LiegKat NRW, e.g.
only lines for parcel boundaries. This restrictions have been
considered within the data structure.
Color coding
Color coding is no requirement of the ALK data structure, but
was used for different purposes. One is the definition of
elements, which occur on more than one layer and will not be
plotted (e.g. OSKA 0242 (line for object definition) and 0249
(virtual object line)). These are stored on MicroStation levels
61 and 62 respectively. The color number represents the ALK
layer. Both levels can be excluded from plotting in the final
output.
Another use of the color code is performed with the OSKA-
code 0292 (arrow), which also occurs on different layers, but
has to be plotted. Here, the color number zero was always
assigned.
As mnemonics, certain colors were assigned to lines with
symbols. For fences, hedges, walls, cadastral division borders,
etc., the OBAK-LiegKat NRW differentiates between symbol
to the right-hand side, to the left-hand side, on both side or no
symbol (note: the direction indicates the ownership, where
applicable). The direction left/right is defined by the
orientation of the linear feature seen from the first point being
the most western one and the azimuth for the second, i.e. for
ALK data structure the last point, being within 200 grades. As
this rule is rather involved for data capturing, as the exact
azimuth would have to be measured before digitizing a line,
the final check should be left to the data transfer software. For
the data capturing, color coding disregarding the digitizing
direction is more obvious specially for lines, where the
symbolization has to be shown separately (e.g. cadastral
divisions and sub-divisions).
For right-hand side rot red (color code 3,
13,23, etc.)
left-hand side lila purple (color code 9,
19,29, eic.)
on both sides,
‘wechselnd’ weiss white (color code 0,
10, 20, etc.)
for symbol as separate line cyan (color code 5,
15,25, etc.)
note: this lines are for plotting only and the color codes are
chosen from German color names.
The color table is arranged accordingly.
Creating objects
Forming ‘Objekte’ - „objects“ is another necessity in order to
fulfill the definitions of the ALK. For objects consisting of
more than one geometric element, the function ‘grouping’ (also
called orphan cell) as well as graphic groups are used, e.g. the
geometric elements of buildings are combined to a group for
data transfer. In this way, all required elements are easily
found. The creation of groups should be supported by an ucm
or md] rather than only using the MicroStation standard
functions in order to avoid forgetting the inclusion of geometric
elements. Using the object coordinate as start point for the
search algorithm, the program can perform an automatic or
semi-automatic forming of a closed area around the centroid.
The operator will attach the alpha-numerical information -
object names - to these objects in several sub-information,
using the MicroStation command ‘tag’.
The graphic group function offers the advantage of being a
toggle function (on/of), so that, single elements of a graphic
group still can be manipulated. A disadvantage is the restricted
number of graphic groups and difficulties with the numbering
under certain conditions.
Object coordinate
In general the justifications of symbols and text can be used as
described in the OBAK-LiegKat NRW. For symbols, this point
of placement is by definition the object coordinate. In most
cases, it is identical with the geometric center of the symbol
(e.g. center point of circular symbols, etc.); for MicroStation,
this results in the justification ‘center center’.
When text feature are placed parallel to the ordinate (y-axis) of
the coordinate system, only one point of origin is needed, as
the direction is already defined implicitly. This point is usually
the center point of the base line, which can be described in
MicroStation as justification ‘center bottom’. For text written
in more the one line (e.g. parcel number as fraction), the
MicroStation feature ‘text node’ with justification ‘center
center’ is applied.
Some text features require two points of placement for
alignment with the topography (e.g. street names along the
road). The justification is set to ‘bottom left’ and the second
point has to be calculated from the rotation angle and the
length of the text during data transfer.
For the justification of text and symbols, the following
positions are going to be used: :
text, if parallel to the grid center bottom (cb)
838
International Archives of Photogrammetry and Remote Sensing. Vol. XXXI, Part B4. Vienna 1996
te
sy
S)
eil
or