Monday, August 09, 1999

Magyar térinformatikai adatcsere-formátum

A téma keretében megismerkedünk

Az európai, de még inkább a magyar szabványok ismertetése elég sok nehézséggel párosul, mivel az elfogadott dokumentumok csak pénzért vásárolhatók meg, e mellett a magyar szabványok esetében, pénzért is csak a szabványok kis része szerezhető be digitális formátumban. Ha ehhez még hozzátesszük, hogy szabvány javaslatokkal, ismertető cikkekkel sem bővelkedik a hálózat úgy az olvasó is beláthatja, hogy nem a szerző hibája, ha a következő ismertetés a korábbiakhoz képest kissé halványabbra sikerül. Ez feltehetőleg összhangban van a szabvány alkotók és terjesztők törekvéseivel is, hiszen ha azt akarnák, hogy a szabványt széleskörűen ismerjék és használják, úgy gondoskodnának a könnyű hozzáférésről és nagyobb publicitásról.

Az ismertetésünk alapját képező dokumentum az MSZ 7771 számú szabvány 1996 03 20 dátumú tervezete [11] illetve Nikl István és dr. Kummert Ágnes Magyar Térinformatikai adatcsere szabvány alkalmazása című előadása [12], mely sajnos ábrák nélkül az Interneten is megtalálható. Magát a szabványt 1997 áprilisában fogadták el és információim szerint nem sokban különbözik a hivatkozott tervezettől. A [12] előadás tanúsága szerint az első alkalmazás az MSZ 7772-1 számú szabvány (népszerű nevén DAT szabvány) szerint készülő digitális alaptérképek alkalmazási sémájának elkészítése alapján ezeknek az állományoknak az átvitele volt.

Mielőtt a szabvány részletes ismertetésére áttérnénk alá szeretnénk húzni, hogy a szabvány csak magának az EXPRESS nyelvnek egy szűkített halmazát használja, és nem él azokkal az eszközökkel, melyeket az EXPRESS sémák adatokkal való feltöltésével nyerhető emberi vagy számítógépes megértésre alkalmas modellek létrehozására alkalmaznak: az EXPRESS I nyelvvel (1.2 fejezet), illetve a 2. 1 fejezetben található úgy nevezett Tiszta Szöveg Kódolással.
5.63 ábra - az átviteli folyamat logikai vázlata

Az ábra igen gondos tanulmányozása alapján a következőképpen képzelhetjük el az átviteli adatállomány létrehozási folyamatát:

·         a későbbiekben ismertetendő geometriai definíció együttes azaz séma illetve a metaadat séma felhasználásával a felhasználó elkészíti a kérdéses termék (pld. digitális alaptérkép) a szabványban megadott elemekből álló szűkített EXPRESS nyelvű sémáját. Ebben a sémában tehát már lehet hivatkozni a geometriai és metaadat sémákban deklarált entitásokra, típusokra, stb.;

·         a nyelvi séma segítségével, ami tulajdonképpen nem más mint a szűkített EXPRESS nyelv definiálása ugyancsak EXPRESS nyelven, az alkalmazási sémából létrehozható az alkalmazás adatszótára, mely nem más, mint az alkalmazási séma által használt típusok és entitások EXPRESS nyelvi megfogalmazása. Az adatszótár a többi metaadattal együtt bekerül a metaadat állományba;

·         a másik irányban az alkalmazási séma példányosításával (a benne található elemeknek történő értékadással) létrejön az alkalmazás adatállománya;

·         az adatállomány kódolása alatt tulajdonképpen azt értik a szabvány szerzői, hogy minden egyes adatelemet EXPRESS entitásként deklarálnak, megadva az entitás attribútumai között eredeti, alkalmazási sémabeli nevét is;

·         az adatcsere séma a metaadatokból és kódolt adatokból deklarálja az átviteli állományt;

·         a kódolási szabályok-ról a szabványtervezetben részletek nem találhatók.

Amint már említettük az alkalmazási séma csak szűkített EXPRESS nyelvi elemeket használhat, melyek a következők: Egyszerű adattípusok, Gyűjtő adattípusok közül ARRAY, LIST, BAG, SET, a Felsorolási adattípus és a SELECT adattípus, az entitás deklarációban szerepelhetnek az attribútumok, inverz attribútumok, levezetett attribútumok, a különbözőségi feltétel, a tartomány szabály az altípus és szupertípus, a Séma deklaráció, Konstans deklaráció, Szabály deklaráció, Függvény és Eljárás deklaráció, a REFERENCE FROM utasítás csak a geometriai alsémára és a külső fájl sémára utalhat.

A geometriai alséma

Geometriai alapelemek

A geometriai alséma tulajdonképpen csak a vektoros modellre vonatkozik, mivel a tervezet megjegyzése szerint: “A raszteres állományok adatcseréjénél a adatcsere a raszter adatok szabványos formáját használja.” Hogy hány szabványos raszteres formátum van azt még e fejezet megírása után sem tudom, hogy mit ért ez alatt a tervezet szerzője arról pedig fogalmam sincs.

Lássunk ezután néhány geometriai meghatározást. A koordináta rendszer entitás a következőképpen van deklarálva:

ENTITY set_of_coordinates;

            SUBTYPE OF (position_information);

            x1:                  coordinate;
            x2:                  coordinate;
            x3:                  OPTIONAL coordinate;
            refers_to:      reference;

WHERE

            DR1: exists(x3) XOR (refers_to.dimension = 2);

END_ENTITY;

Amint látjuk a DR1 szabály segítségével biztosítjuk a megfelelő dimenzió számot a rendszer deklarációjában.

A koordináta rendszer deklarálása után deklaráljuk az úgy nevezett geometriai primitíveket azaz a pontot, vonalat és területet, illetve gyűjtő absztrakt szupertípusukat:

ENTITY geometric_primitive;
ABSTRACT SUPERTYPE OF (ONEOF(point, line, area));

            is_part_of:    SET[1:?] OF spatial_view; -- az elem térbeli nézetei

INVERSE

is_description_of: SET[0:?] OF structure_primitive FOR is_described_by; -- vonatkozó topológiai alapelemek

END_ENTITY;

Ezután rátérhetünk a pont, vonal és terület deklarálására:

ENTITY point;
SUBTYPE OF (geometric_primitive);

            has_position: set_of_coordinates; -- a pont térbeli helye

END_ENTITY;

TYPE interpolation_method = ENUMERATION OF (shortest_way, circular_arc, Bspline);
END_TYPE;

TYPE direction = REAL;
WHERE

            (SELF > -PI) AND (SELF <= PI);

END_TYPE;

ENTITY line;
SUBTYPE OF (geometric_primitive);

            has_position:          LIST [2 : ?] OF set_of_coordinates;
            interpolation:           interpolation_method;
            tangent_direction_at_first_end:             OPTIONAL direction;
            tangent_direction_at_last_end:             OPTIONAL direction;

WHERE

IR1: ; -- innét hiányzik a szabály, hogy két egymást követő pont nem lehet azonos
IR2: ; -- hiányzó szabály a pontokra kötelező azonos referencia rendszerről

END_ENTITY;

Érdekes vonása a specifikációnak, hogy a vonal összeköttetésére különféle interpolációs módszerek közül lehet választani (ez inkább rajzi mint térinformatikai opció).

A területet külső és belső határokkal specifikálja a tervezet. A három hiányzó szabály ebben az esetben:

·         IR1 azt köti ki hogy a külső és belső határok nem metszhetik vagy érinthetik egymást,

·         IR2 a belső határokra írja elő ugyanezt,

·         IR3 pedig azt követeli meg hogy a belső határok ne legyenek egymásba ágyazva.

Ezek a szabályok, különösen az utolsó, sok valós alkalmazás esetében problémát jelenthetnek, gondoljunk egy tóra, melyben egy olyan sziget van, amelyen egy kisebb tó található.

ENTITY area;
SUBTYPE OF (geometric_primitive);

            has_outer_boundary:       boundary; -- a külső határ
            has_inner_boundary:       SET [0:?] OF boundary; -- a lukak határai

WHERE

            IR1: ;
            IR2: ;
            IR3: ;

END_ENTITY;

ENTITY boundary;

            is_composed_of: LIST [1:?] OF UNIQUE boundary_line;

INVERSE

            is_outer_boundary: SET [0:1] OF area FOR has_outer_boundary;
            is_inner_boundary: SET [0:1] OF area FOR has_inner_boundary;

WHERE

            DR1: SIZEOF (is_outer_boundary) + SIZEOF (is_inner_boundary)

                        = 1; -- a határ vagy belső vagy külső, de nem lehet mindkettő

            IR1: ; -- az egyik határvonal végpontja = a következő határvonal kezdőponttal
            IR2: ; -- a határ nem metszheti önmagát
            IR3: ; -- az első határvonal kezdőpontja = az utolsó végpontjával

END_ENTITY;

Ezután már csak a határokat alkotó határvonalak szorulnak meghatározásra, melyek bár azonosak a már meghatározott vonalakkal, a szabvány szerzői szerint a területek létrehozásában játszott szerepük miatt indokolt a külön entitásként történő deklarációjuk.

ENTITY boundary_line;

has_position:          LIST [2 : ?] OF set_of_coordinates;
            interpolation:           interpolation_method;
            tangent_direction_at_first_end:             OPTIONAL direction;
            tangent_direction_at_last_end:             OPTIONAL direction;

INVERSE

            is_part_of:                SET [1:1] OF boundary FOR is_composed_of;

END_ENTITY;

Topológiai alapelemek

A geometria belső szerkezetét a topológiai alapelemek segítségével lehet megadni. A szabvány az alapelemek három típusát határozza meg. Ezek a csomópont, él és felület.

Itt is először az absztrakt topológiai típust deklaráljuk, majd ezt követik az alapelemek különböző válfajainak deklarálása.

ENTITY structure_primitive;

            ABSTRACT SUPERTYPE OF (ONEOF (node, edge, face));

             is_described_by:  OPTIONAL SET [1:?] OF geometric_primitive;
             is_part_of:   SET [1:?] OF spatial_view; -- a topológiai elemek térbeli nézete

END_ENTITY;

Ezután kerül sor a csomópont deklarálására. A szabvány megkülönbözteti az önálló pontot és az összeköttetésekre (élekre) illeszkedő csomópontokat és mind a kettőt csomópontnak (node) hívja. Az illeszkedő csomópontokat tovább osztja vég- és közbenső csomópontra.

Ez utóbbi felosztás nem konform a térinformatikában megszokott felosztással. Ott ugyanis a csomópontokat a szerint osztályozzák, hogy hány ív illeszkedik rájuk (ha egy – végpont, ha kettő közbenső pont (álcsomópont), ha pedig három vagy több – elágazás), addig a szabvány szerint: “végcsomópont olyan kapcsolódó csomópont, amely legalább egy él végpontjaként/kezdőpontjaként szerepel”, azaz a szabvány szerinti végcsomópont tulajdonképpen összefoglalja a térinformatika mindhárom csomópont típusát, míg a szabvány szerinti közbenső csomópont “az a kapcsolódó csomópont, amely rajta van az élen, de nem végpontja” a a térinformatikában nem létezik, mivel ez legfeljebb töréspont, ami nem része a topológiának.

A csomópont tehát altípusa a szerkezeti primitíveknek és főtípusa az említett két pontosztálynak, míg az illeszkedő csomópont a végcsomópont és közbenső csomópont főtípusa, azaz:

ENTITY node;

            SUBTYPE OF (structure_primitive);
            ABSTRACT SUPERTYPE OF (ONEOF (connected_node, isolated_node);

END_ENTITY;

Ezután deklaráljuk a két pontféleséget

ENTITY isolated_node;

SUBTYPE OF (node);

is_within:      SET [0:?] OF face; -- a pontot tartalmazó felületek halmaza

END_ENTITY;

ENTITY connected_node;

             SUBTYPE OF (node);
            ABSTRACT SUPERTYPE OF (terminating_node ANDOR             intermediate_node);

END_ENTITY;

majd az illeszkedő csomópont korábban már felvázolt altípusait

ENTITY terminating_node;

SUBTYPE OF (connected_node);

INVERSE

is_start_node_of: SET [0:?] OF edge FOR starts_at -- az induló élek halmaza
is_end_node_of: SET [0:?] OF edge FOR ends_at – a végződő élek halmaza

WHERE

DR1: SIZEOF (is_start_node_of) + SIZEOF (is_end_node_of) > 0;

END_ENTITY;

A DR1 feltétel azt köti ki, hogy a pontra legalább egy él illeszkedjen.

ENTITY intermediate_node;

SUBTYPE OF (connected_node);

Is_coincident_with: SET [1:?] OF edge; -- a pontra illeszkedő élek halmaza

END_ENTITY;

A következő topológiai primitív az él, amit a térinformatika az ARC/Info hatására inkább ívnek (arc) ismer. A szabvány szerinti élek irányítottak, azaz kezdőpontjuk és végpontjuk nem cserélhető fel. Az élek attribútumai között a kötelező kezdő és végcsomóponton kívül opcionálisan szerepelhetnek még a jobb és baloldali területek (topológiai értelemben lapok), külön - külön a kezdő és végcsomóponthoz csatlakozó legközelebbi jobb és baloldali él, az élhez tartozó köztes csomópontok és azok a gyűrűk, melyek tartalmazzák az élt. Mindez EXPRESS nyelven a következőképpen néz ki:

ENTITY edge;

starts_at: terminating_node; -- kiinduló csomópont
ends_at: terminating_node; -- végcsomópont
has_on_its_left: OPTIONAL SET [1:?] OF face; -- baloldali lapok (poligonok)
has_on_its_right: OPTIONAL SET [1:?] OF face; -- jobboldali lapok (poligonok)
next_right: OPTIONAL edge; -- a végpontból induló első jobboldali él
next_left: OPTIONAL edge; -- a végpontból induló első baloldali él
previous_right: OPTIONAL edge; -- a kezdőpontból induló első jobboldali él
previous_left: OPTIONAL edge; -- a kezdőpontból induló első baloldali él

INVERSE

supports: SET [0:?] OF intermediate_node FOR is_coincident_with; -- az élen lévő köztes pontok halmaza
is_part_of: SET [0:?] OF ring FOR is_composed_of; -- az élet tartalmazó gyűrűk halmaza

END_ENTITY;

Bár ez a deklaráció a szokásosnál több topológiai kapcsolat rögzítését teszi lehetővé nem teljesen világos, hogy mit ért a végpontból illetve a kezdőpontból kiinduló legközelebbi baloldali és jobboldali éleken, illetve, hogy ezek a jellemzők milyen adatszerkezet kedvéért kerültek be a szabványba.

A következő szerkezeti primitív a lap – face, mely tulajdonképpen a belső szigetekkel rendelkező poligon szabvány szerinti elnevezése.

ENTITY face;

            SUBTYPE OF (structure_primitive);

             has_outer_ring: OPTIONAL ring; -- külső határoló gyűrű
             has_inner_ring: OPTIONAL SET [0:?] OF ring; -- sziget gyűrűk halmaza

INVERSE

             contains:     SET [0:?] OF isolated_node FOR is_within; -- a felületen lévő önálló pontok halmaza
is_on_the_left_of: SET [0:?] OF edge FOR has_on_its_left; -- az élek melyektől a lap balra van
is_on_the_right_of: SET [0:?] OF edge FOR has_on_its_right; -- az élek melyektől a lap jobbra van

WHERE

            DR1: SIZEOF (is_on_the_left_of) + SIZEOF (is_on_the_right_of) > 0; – a lapot minimum egy él határolja

END_ENTITY;

Az utolsó topológiai elem az úgynevezett gyűrű – ring, mely leírja a poligont illetve a belső szigeteket alkotó éleket. Figyeljük meg, hogy a lap meghatározásához nem feltétlenül szükséges a gyűrű megléte, mivel az élek jobb és baloldali lap attribútumaiból a poligont határoló élek sorozata helyreállítható. Bizonyos adatszerkezetek azonban a feldolgozó szoftver tehermentesítése érdekében ezt az entitást is tárolhatják. A fentiek miatt a gyűrű már nem tartozik a szerkezeti primitívek főtipusába.

ENTITY ring;

            is_composed_of: LIST [0:?] OF UNIQUE edge; -- az alkotó élek listája

INVERSE

            is_the_outer_ring_of: SET [0:?] OF face FOR has_outer_ring; -- a lap melynek külső gyűrűje
            is_inner_ring_within: SET [0:?] OF face  FOR has_inner_ring; -- a lap melynek belső gyűrűje

WHERE

            DR1: SIZEOF (is_the_outer_ring_of) + SIZEOF (is_ inner_ring_within) = 1; -- a gyűrű vagy külső vagy belső
            IR1:; -- hiányzó szabály az egymás utáni élek kötelező kapcsolódásáról

END_ENTITY;

A következő geometriai – topológiai entitás a térbeli nézet tulajdonképpen a fedvény fogalom általánosítása. A topológiai alapelemekre vonatkozó szabályok egy térbeli nézetre vonatkoznak. A térbeli nézet EXPRESS deklarációja előtt még deklarálnunk kell a benne szereplő séma azonosító típusát is.

TYPE schema_id = STRING;
END_TYPE;

ENTITY spatial_view;

conforming_to: schema_id; -- a vonatkozó séma azonosítója

INVERSE

has_geometric_parts: SET [0:?] OF geometric_primitive FOR is_part OF; -- a hozzátartozó geometriai elemek
has_structure_parts: SET [0:?] OF structure_primitive FOR is_part OF; -- a hozzátartozó topológiai elemek

WHERE

            DR1: SIZEOF (has_geometric_parts) + SIZEOF (has_structure_parts) > 0; -- egy típus egy alapeleme mindenképpen ; -- szükséges

END_ENTITY;

Adatminőség és metaadatok

A szabvány röviden összefoglalja az adatminőséget érintő legfontosabb kérdéseket, utalva arra, hogy ezt a témát részletesen külön szabvány fogja tárgyalni. A felsorolt témák a következők:

·         helyzeti pontosság;

·         tematikus pontosság;

·         időbeli pontosság;

·         teljesség;

·         logikai konzisztencia;

·         szöveghűség.

Hasonlóképpen más szabvány lesz hivatott a metaadatok átfogó szabályozására, ezért az ismertetett szabvány csak a legfontosabb metaadatokat foglalja össze, de e mellett megadja a metaadat séma EXPRESS nyelvű leírását is.

A szabványban található legfontosabb metaadatok a következők:

·         az adathalmaz egyedi neve;

·         az adathalmaz tartalmának rövid összefoglalása;

·         felhasználási terület, szervezet, idő;

·         topológiai típus;

·         térbeli referencia rendszer (koordinátás vagy indirekt);

·         térképi vetület;

·         magassági referencia rendszer;

·         a maximális és minimális koordináták;

·         határoló poligon

·         közvetett térbeli referencia rendszer típus;

·         a terület földrajzi neve;

·         a minimális és maximális magasság értékek;

·         időintervallum, melyre az adatok vonatkoznak;

·         kapcsolattartó személy adatai;

·         a metaadatok létrehozási ideje, megtörtént és tervezett frissítésének időpontjai;

·         az adatok hálózati címe.

Lássuk ezután a kérdéses metaadat séma EXPRESS nyelvi megfogalmazását.

SCHEMA metadata;

USE FROM CoordinateSystem (set_of_coordinates); -- séma a 6. mellékletből
USE FROM data_encoding (dataset); -- kódolási séma 2. melléklet

TYPE conceptual_geometry_subschema = ENUMERATION OF (spaghetti, network, planar_graph); -- 3 lehetséges elvi modell
END_TYPE;

TYPE extent_status = ENUMERATION OF (actual, future);
END_TYPE;

TYPE geometric_primitive_type = ENUMERATION OF (point, line, area);
END_TYPE;

TYPE structure_primitive_type = ENUMERATION OF(node, edge, face);
END_TYPE;

TYPE external_graphic_file_type = SELECT (vector_file, raster_file);
END_TYPE; -- külső fájlok átvitelére is van lehetőség a szabványban

TYPE raster_file = STRING;
END_TYPE;

TYPE vector_file = STRING;

END_TYPE;

ENTITY dataset_description;

            SUBTYPE OF (dataset);

                        dataset_title:                                    STRING;
                        dataset_abstract:                           STRING;
                        purpose:                                           STRING;
                        usage:                                               STRING;
                        geometry_subschema_type:            conceptual_geometry_subschema;
                        spatial_reference_system_info: STRING;
                        has_extent:                                      SET [1:?] OF extent;
                        has_planar_extent:                        SET [1:?] OF planar_extent;
                        has_contact_person:                    SET [1:?] OF contact_person;
                        entry_date:                                       date;
                        last_update_date:                          date;
                        last_check_date:                            date;
                        on_line_access:                             STRING;

END_ENTITY;

ENTITY extent;

            ABSTRACT SUPERTYPE OF (ONEOF (planar_extent, vertical_extent, temporal_extent));

                        extent_date:                                     date;
                        extent_status:                                 extent_status;

END_ENTITY;

ENTITY bounding_xy;

            SUBTYPE OF (planar_extent);

                        min_xy:         LIST OF UNIQUE set_of_coordinates;
                        max_xy:        LIST OF UNIQUE set_of_coordinates;

END_ENTITY;

ENTITY bounding_area;

            SUBTYPE OF (planar_extent);

                        definition:     LIST [3:?] OF set_of_coordinates;

END_ENTITY;

ENTITY geographic_area;

            SUBTYPE OF (planar_extent);

                        type_of_indirect_spat_ref_system:      STRING;
                        areal_unit:    SET [1:?] OF geographic_areal_unit;

END_ENTITY;

ENTITY geographic_areal_unit;

            name:                                    STRING;
            code:                         STRING;
            coverage:                 STRING;

INVERSE

            geographic_areas:                        SET of geographic_area FOR areal_unit;

END_ENTITY;

ENTITY vertical_extent;

            SUBTYPE OF (extent);

                        min_value:               REAL;
                        max_value:              REAL;

END_ENTITY;

ENTITY temporal_extent;

            SUBTYPE OF (extent);

                        from_date:                date;
                        to_date:                     date;

END_ENTITY;

ENTITY contact_person;

            name:                                                STRING;
            role:                                        STRING;
            organisation:                       STRING;
            address:                               STRING;
            telephon:                              STRING;
            fax:                                         STRING;
            e_mail:                                   STRING;

END_ENTITY;

END_SCHEMA;

Összefoglalás

A szabvány amint a bevezetőben említettük több EXPRESS nyelven megfogalmazott sémát tartalmaz mellékleteiben (Nyelvi séma – 1. melléklet, kódolási séma – 2. melléklet, adatállomány átviteli séma – 3. melléklet, földrajzi helyzet sémák – 6. melléklet, geometriai séma (az általunk is közölt geometriai és topológiai elemek egy sémában összefoglalva) –7. melléklet és végül a közölt metaadat séma – 8. melléklet.

Úgy gondoljuk, hogy ahhoz, hogy a szabványról általános elképzelésünk legyen nem szükséges a többi sémát is leírnunk, az érdeklődők a szabvány végleges változatát beszerezhetik a Magyar Szabványügyi Testületben.

Amint a [12] irodalomból kitűnik a már említett DAT alkalmazási sémához kapcsolódva elkészült már egy programozói segédlet is az adatcsere állomány fogadását és előállítását szolgáló interfész kifejlesztéséhez.

Érdekes a cikk azon megállapítása miszerint “ A GEOVIEW SYSTEMS kft gyakorlatban is kipróbálta az adatcserét a szabvány logikáját követve (szemantikailag azonos, szintaktikailag más)” (a kiemelés tőlem). Hogy ez a mondat valójában mit jelent nagyon nehéz eldönteni, különösen egy olyan összefüggésben, ahol egy adott formális nyelv alkalmazása van előírva. Ha a szintaktika más akkor a nyelvi formalizmusok is mások és az átvitel nem a szabvány szerint valósul meg.

Összefoglalva megállapíthatjuk, hogy az ismertetett szabvány széleskörű gyakorlati alkalmazása még várat magára.

·          a következő részben megismerkedünk az OpenGIS koncepcióval

·         esetleg visszatérhet az előző részhez

·         illetve a tartalomjegyzékhez

Megjegyzéseit E-mail-en várja a szerző: Dr Sárközy Ferenc