Thursday, August 12, 1999

Az OPEN GIS koncepció

Ebben a részben megismerjük

Nehéz eldönteni, hogy az OPEN GIS-t a térinformatikai szabványok között tárgyaljuk-e vagy külön fejezetet szenteljünk a témának. Az utóbbi mellett döntöttem, mivel ez a koncepció túlmutat a létező GIS szabványok bármelyikén és teljesen új távlatokat nyit meg a térbeli információ felhasználására.

Mielőtt a részletekre rátérnénk vázoljuk fel durván, hogy miről is van szó.

Az OpenGIS™ Konzorcium célja

Az 1993-ban alakult Open GIS konzorcium olyan modell kidolgozását célozta meg, 'mely transzparens hozzáférést biztosít a heterogén földrajzi adatokhoz és feldolgozó erőforrásokhoz hálózati környezetben'. 'Olyan nyitott interfész specifikációk megalkotása a cél, melyek alapján írt szoftverek biztosítják a kitűzött célt' [13].

A fentieket jól szemlélteti az 5.64 ábra, melyet a [13]-ból kölcsönöztünk és részben magyarra is fordítottunk. A fordítás nem terjed ki azokra a rövidítésekre, melyek különféle USA szervezeteket, programokat, stb. jelölnek.

Az ábra tanulsága szerint a különböző intézmények különböző adatai és program moduljai úgy működnek együtt mintha a helyi számítógépre volnának együttesen installálva.
5.64 ábra - a megvalósított OGIS modell működése

Az OGIS rendszer olyan objektum orientált osztott szoftver rendszer, mely eléri és kezeli a különböző típusú osztott térbeli adatokat és lehetővé teszi az alkalmazások együttműködését a kliens számítógépen.

A rendszer három csomópontja: a Nyílt Geo-adat Modell (Open Geodata Model=OGM), az OGM adatokat manipuláló szolgáltatások architektúrája, és a "Földrajzi Információs Közösségek" fogalmi fordítója (megjegyezzük, hogy a legújabb 1999-es útmutatóban az első két elemet a lényegi - essential- modellben összevontan kezelik).

Az OGC feladata olyan interfész specifikációk kidolgozása, melyeknek megfelelő szoftverek lehetővé teszik a platform független, osztott adatelérést és osztott számítást (feldolgozást).

Már az eddigiekből is jól látszik, hogy az OGC specifikációt hálózati, alapvetően Internet-es környezetre koncepcionálták. Mivel azonban az Internet GIS kérdéseivel csak a következő részben foglalkozunk egyelőre, csak olyan szintig érintjük a hálózati kérdéseket, amely feltétlenül szükséges, és CORBA ismereteink alapján már most is érthető.

Az OpenGIS™ modellek

Ahhoz hogy a rendszer modelljét elkészítsük a valós világ tárgyait és műveleteit (a tárgyakkal végrehajtott akciókat) modelleznünk kell. A modellezésre a specifikáció megalkotói kezdetben a szintrópiának (syntropy) elnevezett grafikus objektum orientált modellező nyelvet használták[14]. Ez a nyelv a modellezésnek a következő szintjeit határozza meg:

Az OGC specifikációk egyik érdekessége vagy inkább kellemetlensége az, hogy a lényegi modell illusztrálására szintrópia stílusú diagramokat használ, míg a specifikációs modell valamint az implementációs modell dokumentálása UML nyelven történik. Másik lényeges sajátossága a modellnek, hogy mivel a különböző feladatokat különböző csoportok különböző időpontban kezdték kidolgozni, azok készültségi foka lényegesen különböző.

A lényegi modell főbb elemei
5.65 ábra - az OpenGIS™ adatmodell (OGM) főbb elemei

Az OGM végső céljaként az 5.65 ábrán látható adatmodell felépítésére törekszik. A cél tehát az, hogy olyan objektum orientált adatmodell jöjjön létre a különböző adatokhoz csatlakozó interfészek segítségével, mely az ábrán látható típusok keretén belül képes az eredeti adatok legkülönbözőbb tulajdonságait modellezni.

Ahhoz azonban hogy az adatinterfészek segítségével ez a sokoldalú és rugalmas modell specifikálható legyen alapvető vizsgálatokat kellett végrehajtani a földrajzi adatok jellegére, absztrakciós szintjeire, összetevőire, stb. vonatkozóan. Ezzel a modell építéssel kezdődött meg tulajdonképpen az Open GIS konzorcium lényegi munkája. Az alábbiakban viszonylag részletesen bemutatásra kerülő modell végső absztrakciós szintjén a valós világot objektumok illetve objektum gyűjtemények létrehozásával modellezi. A később ismertetendő fedvény szemléletű modellezés hivatott a folyamatos adatok előnyösebb leírására.

Modellezés objektumok és objektum gyűjtemények létrehozása céljából

Az 5.66 ábrán az 'Absztrakt specifikáció'[15] ötödik fejezete alapján összefoglaljuk az esszenciális modell főbb csomópontjait. Bár nem kis munkával az ábra lényegét alkotó szöveget lefordítottuk magyarra, a szöveges magyarázat során megadjuk az eredeti elnevezést is, mivel az absztrakt specifikáció angolul készül és ha valaki a szoftverjében alkalmazni kívánja előírásait, úgy természetesen az eredeti neveket kell figyelembe vennie. Még annyi megjegyzésre szükség van, hogy bár az ábránál és a következő magyarázatnál az absztrakt specifikációra hivatkoztunk, amiről most beszélünk az a lényegi modell különböző szinteken, az absztrakt specifikáció ugyanis a lényegi modellt is tartalmazza a specifikációs modell bevezetésére, sőt egyes fejezetek csak ezt tartalmazzák, mivel a kérdéses terület specifikációs modellje még nem készült el.
5.66 ábra - az OGM csomópontjai

Az ábrán 9 absztrakciós szintet találunk 8 interfésszel a valós világ dolgainak OpenGIS™ objektumokkal történő modellezésére. Az ábrán láthatók az absztrakciós szintek nevei, a használatos nyelveik, interfészeik és a navigálást támogató módszereik.

Az első négy színt absztrakciós eredménye az ötödik szintben - a projekt világ szintben kerül összefoglalásra. Ezek a szinteket nem kell modellezni a szoftverben. A projekt világ színt azt a szemléletet foglalja össze, amit egy információs közösség (pld. geodéták, topográfusok, környezettervezők, közművesek, stb.) a valós világ kiválasztott szegmenséről a maga számára kialakít. Az ábra tehát egy szakterület térbeli entitás felfogásának formalizálását illusztrálja. A formalizálás eredményeként a kérdéses nézetet az OGIS objektum gyűjtemény (OGIS feature collection) reprezentálja a digitális modellben.

A valódi világ (real world) kaotikus sokaságából az ismert elemeknek az emberek neveket adnak. Ez az elnevezési (name) módszer vezet át a következő absztrakciós csomópontba.

A koncepcionális világ (conceptual world) azokat a dolgokat tartalmazza, amiket el tudunk nevezni. Ezt a világot a természetes nyelv írja le. Ebből a világból a válogatási (select) módszerrel tudunk tovább lépni a térinformatikai világba (geospatial world).

A térinformatika világa (geospatial world) a GIS szakma nyelvén fogalmazza meg a koncepcionális világból érdeklődésére számot tartó objektumokat. Ez azt jelenti, hogy meghatározott egyszerűsítésekkel ábrázolja a figyelembe vett objektumokat (épületek alaprajza, folyók-, utak tengelyvonala, stb.).

A térinformatikai világ eredendő dimenzionalitását és kölcsönös topológiai viszonyait a műszer (instrument) módszer hatására euklidesi dimenzióval és metrikával veszi figyelembe a dimenzionális világ (dimensional world). Az absztrakciónak ezen a szintjén olyan egy és két elemű kapcsolatok tudatosodnak mint az ív hossza, a vonal irányszöge, illetve két pont távolsága.

A projekt világ (project world) mindig egy konkrét feladathoz kapcsolódó elemeket vesz figyelembe a dimenzionális világból és azok sarokpontjait az egységes referencia rendszernek megfelelő koordinátákkal reprezentálja, melyeket az interfész kodifikál (codify) módszere indukál. Fordított irányban az elhelyez (localize) módszer a koordinátákkal megadott sarokpontokat megfelelő méretekkel a megfelelő helyre teszi a dimenzionális világban.

A projekt világ szintjén a tervező két reprezentációs technológia közül választhat: ezek az 'objektum geometriával' (feature with Geometry) és a 'fedvény' (coverage) módszer. E választásnak megfelelően működnek a további, a szoftverben már figyelembe veendő absztrakciós csomópontok.

Először nézzük meg az 'objektum geometriával' esetét, a fedvény szemléletből fakadó eltéréseket egy későbbi pontban foglaljuk össze.

Mivel a különböző információs közösségek adatainak kölcsönös felhasználása csak úgy oldható meg, ha a projekt világ szintjén szigorú formális absztrakciót végzünk, ezért a projekt világ nyelvét a következő szigorú, formális struktúrákra korlátozzuk:

Ezek a struktúrák a valós világ tényei és ezen a szinten nem modellezendők szoftverrel.

Az objektum példányok képezik a projekt világ alapstruktúráját. Az objektumokat a térinformatikai világból explicit kiválasztással kell levezetni. Ugyancsak explicite kell meghatározni az objektum példányok közötti hierarchikus, hálózati, geometriai, topológiai kapcsolatokat.

Az objektum típusok jelentik az objektumok kategóriáit. Minden objektum példány a saját típusának megfelelő adatokkal hozható létre, azaz a típusok tulajdonképpen az objektum csoportok kliséinek tekinthetők.

A geometria feladata, hogy az objektumoknak a térinformatikai világ színtjén kialakított egyszerűsített rajzait objektum típusonként úgy nevezett 'Jól Ismert Típusoknak' (Well Known Types) megfeleltesse és 'Jól Ismert Struktúrákkal' (Well Known Structures) realizálja (példányosítsa). Ilyen JIS-ek a poligonok, vonal sztringek, poliéderek, stb. A specifikáció explicit szabályt követel minden objektum típus JIS-ekkel történő kifejezésére. Maguknak a JIS-eknek rendelkezniük kell azokkal az információkkal, melyekből az objektum helyreállítható (pld. vonal szakaszok esetén a hozzáfűzési információval).

A sarok az a hely, mely direkten vagy indirekten (pld. szplájnok esetében) meghatározza a projekt világ objektumainak térbeli kiterjedését. A projekt világ sarkait explicite meg kell feleltetni a JIS-ek sarok- vagy törés pontjainak. Ez viszont azt jelenti, hogy pld. poligon megfeleltetés esetén a projekt világban meg kell adni a poligont alkotó pontok egymásutánját.

A geometriai séma összefoglalja a geometriával és a sarkokkal kapcsolatban elmondott követelményeket, többek közt meghatározza

A térbeli referencia rendszer olyan koordináta rendszer, mely a dimenzionális világ relatív helymeghatározásából abszolút helymeghatározást tesz lehetővé, azaz koordinátákkal látja el a projekt világ kiválasztott pontjait a sarkokat.

Az attribútum érték párok kifejezik az objektumokhoz kapcsolt tulajdonság jellemzők nyelvtanát. Ahhoz, hogy az objektumok egyértelműen és ismételhetően legyenek meghatározva olyan 'nyelvre' van szükség, mely szó készletből és nyelvtanból áll. Minden objektum típushoz hozzá kell rendelni egy listát, mely első oszlopa tartalmazza az objektum típus attribútumainak neveit, második oszlopa pedig ezek típusait. Minden konkrét objektum példányhoz pedig egy olyan listát kell rendelni, mely értéket ad az előzőekben típusukban meghatározott, és objektum típushoz hozzárendelt attribútumoknak. Az elmondottakból világos, hogy a szókészlet a következő elemekből áll:

Azért, hogy a rövid elnevezések mögötti tartalmi elemek is világosak legyenek minden projekthez mellékelni kell egy olyan szótárat, melyben minden elnevezés természetes nyelvű magyarázatot kap.

Az attribútum séma az összes objektum típus gyűjteménye kiegészítve a típusokhoz tartozó attribútum-név / érték-típus listákkal. Az attribútum séma és a geometriai séma együttesen alkotják az objektum sémát.

A projekt séma az objektum gyűjteményhez hozzárendelt metaadatokat tartalmazza, négy részből áll:

  1. Az objektum gyűjtemény azonosítása (Feature Collection Identification) tartalmazza a lefedett területet, a közelítő méretarányt és a tematikus kulcs-szavakat, a felelős személyt és elérési feltételeket, az adatok előállítási dátumát, a forrás anyagok dátumát, az adatnyerési módszert, a lehetséges felhasználást;
  2. A lexikális értelmezés (Lexical Semantics) a már említett értelmező szótár, azaz a projektben szereplő fogalmak részletes szöveges leírása;
  3. A projekt értelmezés (Project Semantics) a projekt koncepciójának, kiterjedésének leírása;
  4. A használati értelmezés (Use Semantics) az eredetileg koncepcionált, illetve más lehetséges felhasználási lehetőségek kifejtése.

Az 5.67 ábrán bemutatjuk a projekt séma szerepét az objektum gyűjtemény létrehozásában. A szürke téglalapok jelölik azokat az elemeket amelyek közreműködnek az objektum együttes objektum példányainak a modellezésében, a többi kitöltetlen téglalap pedig a metaadatokat jelöli. Az egyes összeköttetések (asszociációk) végén található fekete teli körök a többszörösségre utalnak. Az üres háromszög a főtípus felé mutat az altípusok felől. Az asszociáción látható \ jel azt mutatja, hogy az asszociáció logikailag levezethető más kapcsolatokból.


Mivel itt még nem szoftverben implementálandó szinten vagyunk a téglalapok elnevezéseit megpróbáltuk magyarra fordítani.
5.67 ábra - a projekt séma szerepe az objektum gyűjtemény létrehozásában

A következő absztrakciós szinten az OGIS pont világban (OGIS Point World) a projekt világban meghatározott sarokpontok a survey módszer segítségével a referencia rendszer figyelembe vételével koordinátákat kapnak. Fordított irányban az interfész a locate módszerrel a koordinátás pontokat visszaállítja relatív helyzetükbe.

5.68 ábra - projekt világ - pont világ interfész szintrópia diagramja

Az 5.68 ábrán bemutatjuk az absztrakciós átmenet szintrópia diagramját. A diagramon a kapcsolat végén található 'gyémánt' jel itt is mint az UML-ben az aggregációt szimbolizálja, az asszociációra szerkesztett íven található téglalap pedig az asszociáció tulajdonsága. Mivel az ábrán szereplő angol szavakat már sokszor lefordítottuk ettől a továbbiakban eltekintünk.

Az OGIS geometriai világa (OGIS Geometry World) absztrakciós színt két interfésszel kapcsolódik a projekt világhoz illetve a pont világhoz. A projekt világtól megkapja a geometriai sémát, mely hozzárendelte az objektumokat a Jól Ismert Típusokhoz és meghatározta a leképezést végrehajtó Jól Ismert Struktúrát. A geometriai séma azt is megadta, hogy melyek az objektumok sarokpontjai. A geometria létrehozását a skeletonize (vázasít) művelet kezdeményezi, mely fordítottja az enclose (becsatol) visszaalakítja a projekt világ metrikus vázlatába az objektumot. Ahhoz azonban, hogy a valódi geometria létrejöjjön a geometriai sémából átvett sarokpontokat el kell látni koordinátákkal a pont világ felé kialakított interfészen keresztül. Ezt a feladatot az assemble (felépít) módszer kezdeményezi, melynek fordítottja a decompose (lebont) a sarokpontokat visszaviszi a struktúrákból a pont világba.

Az elmondottakat az 5.69 ábrán látható szintrópia diagrammal szemléltettük. Az összes jelöléseket már megismertük. Amire mégis külön fel szeretnénk hívni a figyelmet az az, hogy a pont világ és a geometriai világ közötti kapcsolat levezetett kapcsolat (\), mivel mibenlétét a geometriai séma határozza meg.
5.69 ábra - a geometriai világ interfészeinek szintrópia diagramja

Az objektum világ (feature world) a geometriai világban meghatározott struktúra példányból és a projekt világban meghatározott attribútum sémából állítja össze az objektumokat. Az objektum világ és a geometriai világ közti objektum struktúra interfész módszerei a kiterjedés (extent) és a geometriai érték (geo value). Minden objektumnak van térbeli kiterjedése, melyet egy OGIS geometriai struktúra modellez, az objektumnak pedig van egy geometria nevű attribútuma, melynek értéke pedig maga a struktúra (pld. poligon). A projekt világ és az objektum világ közti attribútum séma interfész két transzparens módszere az attribútum (attribute) és a példány (instance).
5.70 ábra - az objektum világ interfészeinek szintropia diagramja

Az 5.66 ábrán található utolsó világ az objektum gyűjtemények világa (OpenGIS™ Feature Collection) olyan absztrakt objektumot képvisel, mely objektum példányokból s azok objektum sémáiból és a projekt sémából áll. Az objektum világot az objektum gyűjtemény világgal a projekt struktúra interfész (Project Structure Interface) kapcsolja össze. Transzparens módszerei a tag (member) és befoglal (include) egy levezetett asszociáción működnek, mivel az, hogy mely objektumok lesznek a gyűjtemény tagjai nem az objektum világtól, hanem a projekt világ részét képező projekt sémától függnek. Ezt az elsődleges kapcsolatot realizálja a projekt séma interfész (Project Schema Interface) a realizál (realize) és képvisel (represent) módszereivel. Az 5.71 ábra ezeknek az interfészeknek a szintrópia diagramját ábrázolja
5.71 ábra - az objektum gyűjtemény világhoz vezető interfészek szintrópia diagramja

Az 5.70 ábrán láthatjuk a kérdéses interfészek szintrópia diagramját. Az ábrával kapcsolatban két megjegyzés érdemel figyelmet. Az egyik, hogy a geometriai világ és objektum világ közti kapcsolat nem levezetett, mivel az objektum minden geometriai tulajdonságát a geometriai világ tartalmazza, hiszen már korábban átvette a projekt világból a szükséges információkat.
A másik az ábra két új objektum típusára vonatkozik: az attribútum (Attribute) nem más mint a projekt világban már bemutatott attribútum név, érték típus (AttributeName, ValueType) pár, az attribútum referencia rendszerre (Attribute Reference System) pedig azért van néha szükség, hogy megadjuk az attribútum érték értelmét.
Példaként a specifikáció egy szórt pontokat tartalmazó hőmérsékleti TIN objektumra utal, melyben a minta pontokon kívüli hőmérséklet becslésre szolgálhat információval az attribútum referencia rendszer.

Modellezés a fedvény (coverage) koncepció alapján

Az OGIS adatmodell absztrakciós szintjeinek áttekintése után nézzük meg röviden azokat az adatmodellező feladatokat, melyekkel a specifikáció hatodik része foglalkozik, azaz a fedvény (coverage) modellt, majd kizárólag példaképpen mutassunk be néhány UML specifikációt is az absztrakt specifikációs szintről.

Ezután összefoglaljuk az OGIS koncepció másik két alapelemét: a szolgáltatási architektúrát és az információs közösségek szemantikus fordítóját.

5.72 ábra - az absztrakt specifikáció fejezetei és a köztük fennálló kapcsolat

Az 5.72 ábrából jól látható, hogy a részben ismertetett 5. téma összefoglaló jelentőségű a vektoros objektumok modellezésében. Ezt egészíti 6. és 7. téma mely a fedvények és kép féleségek objektum szemléletét specifikálja. Teljesen különállnak a 12., 13., 15. és 16 téma, melyek a bevezetőben már említett szolgáltatási architektúrát specifikálják. Végül említsük meg, hogy az OGIS koncepció harmadik főelemének a "Földrajzi Információs Közösségek" fogalmi fordítójának csírái a 14. feladatban jelennek meg.

Fedvények és képek

5.73 ábra - az objektum főtípus altípusai

A fedvény (coverage) a valós világ nézete, az objektum főtípus altípusa. Míg a geometriai objektum egy vagy több tulajdonságát az OGIS geometriai világból nyeri, addig a fedvények tulajdonságait a C_Function (a fedvény függvény rövidítve) határozza meg. A C_Function homogén numerikus rekordok halmaza. Egy fedvényhez több C_Function is rendelhető. Nem tudom megállni, hogy ne utaljak az általam korábban megfogalmazott függvénytér koncepcionális modell implementálására, mely nagyon sok hasonlóságot mutat az OGIS fedvény szemlélettel.

Talán a legjobb elképzelést a fedvény fogalomról úgy nyerhetjük, ha a következő ábrán megnézzük a fedvények altípusait.

5.74 ábra - a függvények altípusai

A fedvények térbeli tartománya (spatial domain) valamely referencia rendszerhez kapcsolt geometria vagy geometriák együttese. Ebből talán a legismertebb a raszter geometria, melyet a fedvény oldalaival párhuzamos négyzetek alkotnak. A fedvény szemlélet azonban tágabb az egyszerű raszteres modellnél mivel nem korlátozza a geometriát a négyzetekre. A jelen specifikációs verzió az általános geometriák közül a pontokat, vonalakat és felületeket definiálja.

A C_függvények (C_Functions) a térbeli tartomány elemeihez rendelnek egy vagy több numerikus értéket. Ezeket az értékeket vektoroknak nevezi a specifikácó, mely annyi dimenziós ahány tulajdonság jellemzőre vonatkozik egy-egy elem vonatkozásában. Ha például az adott pontokban a hőmérséklet és légnyomás ismert, úgy a vektor kétdimenziós.

A fedvény geometriájának függvényében változnak a C_függvények is. A legegyszerűbb a PontC_függvény (PointC_Function) mely a kizárólag pontokból álló p geometria minden eleméhez illeszt egy v jelű, n dimenziós vektort. A C_függvény grafikonját ebben az esetben p, v érték párok alkotják.

Nagyon hasonló módon rendel értékeket a vonal sztringekhez a VonalSztringC_függvény (LineStringC_Function), illetve a felületnek elkeresztelt területekhez a FelületC_függvény (SurfaceC_Function).

A pont geometriával kapcsolatban bevezetett érték pár fogalom kiterjeszthető az egyéb értelmezett geometriákra is, hisz ezekben az esetekben a vonal darab vagy a terület képezik a fedvény alapelemét mely konstans vektor értékkel írható le.

A specifikáció szempontjából lényeges a diszkrét és folytonos fedvények, illetve az azokat leíró C_függvények szembeállítása. Diszkrét pont fedvény esetén az érték párok véges számú pontra vonatkoznak. Más esetekben, ha például interpolációs módszerekkel akarjuk a függvényteret leírni az értelmezett ponthalmaz végtelen.

Alkalmazható a diszkrét fogalom a vonaldarabok illetve területek gyűjteménye szempontjából is, ahol bár egy-egy vonal darab vagy terület önmagában folytonos, a vonal darabok illetve területek száma véges.

A specifikáció a továbbiakban foglalkozik az 5.74 ábrán bemutatott altípusokkal. Általánosságban elmondható, hogy a fedvények egy jelentős részénél a diszkrétből a folyamatosba történő átmenettel érhetjük el a végső célt. Először létrehozunk pld. egy diszkrét rácsot, majd megfelelő interpolációs eljárással végtelenre tágítjuk a C_függvény értelmezési tartományát.

Részletesen foglalkozik az anyag a rács (grid) fedvény típussal. Ez a típus is diszkrét pont fedvényként indul. Ezután négyes csoportokba foglalva a pontokat valamilyen intepolációs módszerrel kiterjesztjük a C_függvények tartományát a négyzeten belüli területre. A legközelebbi szomszéd (NN) mint alapértelmezésű interpoláció mellett a bilineáris, optimális és bikubikus interpoláció kerül megemlítésre. Az interpolációk realizálását vagy kiértékelő szolgáltató modul vagy interfész biztosítja.

A rács fedvények különböző speciális területek igényeinek kielégítésére szolgálhatnak. Lehet digitális ortofotó, digitális magasság modell (DEM) vagy computer kijelző ablak. Mivel ezek az altípusok különböző képen értelmezik a rácspontok és négyzetek értékeit, a csúcsok szemantikáját explicite meg kell adni.

Másik igen gyakori fedvény altípus a szórt pontokra szerkesztett háromszöghálózat (TIN).Ezzel a témával részletesen foglalkoztunk a 2.6 pontban.

Szintén interpoláción alapuló fedvény altípus a legközelebbi szomszéd (Nearest Neighbor). Ebben a fedvényben valamely interpolált p pont azt az értéket kapja, ami a hozzá legközelebb eső pontnak az értéke.

Szintén foglalkoztunk már a lopott területek módszerével, mely 'elvesztett terület interpoláció' (lost area interpolation) néven szerepel a specifikáció fedvény altípusai között.

A szegmentált vonal fedvények (segmented line coverages) a vonalas műtárgyak tervezési gyakorlatában jól ismert szelvényezési paraméterezést használják a C_függvény folyamatos vagy diszkrét értékeinek előállítására, azaz az érték a vonal kezdetétől számított ívhossz függvénye. Gyakorlati okokból a vonalon felvehetünk speciális diszkrét pontokat (pld. forgalom irányító tábla helye) és szakaszokat kezdő és végpontjukkal. Míg a speciális pontok esetén egyértelmű hogy a C_függvénynek a kérdéses tábla, pózna, stb. értékét kell szolgáltatni, szakaszok esetén a szakaszon belüli értékeket a szakasz kezdő és végpontján érvényes értékekből kell interpolálni.

A következő speciális fedvény típust a képek (images) alkotják. A képek nagyon különbözőek lehetnek és nagyon különböző térbeli referencia rendszer segítségével alakíthatók egyszerűen használható térbeli adattá. A földfelszín fényképezése vagy szkennelése során nyert képek leképezése a referencia rendszerbe a fotogrammetria módszereivel történik, melyeket részletesen tárgyaltunk. A specifikáció szabványosítani kívánja a térbeli referencia rendszer tárolt függvény megfogalmazásának nevezett összetartozó földi és képkoordináta értékek véges halmazát. Hasonlóképpen szabványosítani kívánja a tárgy és képe közötti transzformációs együtthatók számítását megfelelő interfész kialakítása érdekében.

Amint arra az objektum szemlélet kapcsán már utaltunk a projekt világ szintjén a tervezőnek kell eldöntenie, hogy geometriai objektum vagy fedvény szemlélet segítségével specifikálja ugyan azt a projekt világ színtű valóságot. Ebből viszont következik, hogy a geometriai objektumok átalakíthatók fedvényekké.

Ahhoz hogy az objektum sémát fedvény sémára képezzük le úgy kell meghatározni a C_függvényt, hogy azokban a pontokban, melyek az objektum geometria részei visszaadja az objektum tulajdonság/érték párját, a geometrián kívüli pontokban 'határozatlan' értéket vegyen fel. Előfordulhat még egy harmadik eset is amikor a kérdéses pont egyszerre két geometriának is része. Ezt az esetet elkerülendő alkalmazhatjuk a particionálási szabályt, mely megtiltja metsző objektumok jelenlétét. Ha mégis kezelni akarjuk a metszési esetet is, úgy külön szabályban kell megfogalmazni, hogy miként kell kialakítani a visszaadott értéket az érintett objektumok tulajdonság/érték párjainak felhasználásával.

Ha különböző fedvényeknek ugyanaz a koordináta tartománya és azonos a térbeli referencia rendszere is, úgy ezek a fedvények fedvény családot alkotnak. A fenti meghatározás egyenértékű azzal, hogy az azonos koordináta tartományú fedvények egyben regisztráltak is. A fedvény családok támogatják a fedvényeken elvégezhető két vagy többszereplős műveleteket.

Nem térünk ki a fedvényekkel végrehajtható számtalan műveletre csak a fedvények két alapműveletét vázoljuk fel. A kiértékelés (evaluation) megkeresi és visszaadja az adott p ponthoz tartozó C_függvény értéket. A második művelet az inverz kiértékelés (inverse evaluation) vagy más néven alak (shape) művelet az általunk megadott C_függvény értékhez keresi meg azokat a helyeket, ahol a függvény ezzel az értékkel rendelkezik. Ha tehát megadjuk egy digitális magasságmodell fedvény esetén a 110 méteres értéket, akkor az alak műveletnek meg kell rajzolnia a 110 méteres szintvonalat.

A fenti alapműveletek azért érdekesek az adatmodell szempontjából, mivel a fedvény adatokhoz olyan interfészt kell specifikálni, melyen keresztül az említett műveletek az adatokkal végrehajthatók.

Ígéretünknek megfelelően lássunk most néhány UML diagramot a fedvény típus specifikálására.

5.75 ábra - a fedvény típus egyszerű osztály diagramja

A fedvény mint látjuk alosztálya az objektum osztálynak és egyirányú asszociáció kapcsolja a diszkrét C_függvény, illetve a C_függvény osztályokhoz.

 

5.76 ábra - a C_függvény osztály diagramja

Tovább folytatva a specifikálást látjuk a C_függvény módszereit: mégpedig az értelmezési tartományát (domain) és a kiértékelést (evaluate): az értelmezési tartományhoz rendelt vektorokat.

A C_függvény többféle függvény típus főtípusa. Ezek közül az 5.76 ábra a rács, szegmentált vonal, TIN és Voronoi cella hálózat típusokat mutatja be. A specifikáció szöveges megjegyzésben utal arra is, hogy ezek közül a típusok közül egyelőre csak a rács típus részletes specifikálása van napirenden.
5.77 ábra - a diszkrét C_függvény osztály diagramja

Az 5.77 ábra a diszkrét C_függvény osztály diagramja. A num módszer a halmaz számosságát adja vissza, az értékek (values) az összes érték vektort szolgáltatja, a tartomány (domain) a geometriák gyűjteményét melyen értelmezve van, a kiértékel (evaluate) pedig egy geometriára vonatkozó értékvektort szolgáltat. A diszkrét C_függvény a diszkrét felületi C_függvény és a diszkrét pont C_függvény főtípusa.

Az 5.78 ábrán láthatjuk a diszkrét pont C_függvény osztály diagramját. Ez az osztály alosztálya mind a C_függvénynek mind a diszkrét C_függvénynek. A függvény véges pont tartományra értelmezett, ezért képviselhető a pont érték pár listával (ezt jelképezi az asszociáció végén található kompozíció jel). érdekesek a TIN-t és a Voronoi cellákat generáló illetve definiáló aggregativ asszociációk, illetve a TIN és a Voronoi cella hálózat dualitását képviselő asszociáció is.
5.78 ábra - a diszkrét pont C_függvény osztály diagramja

5.79 ábra - diszkrét felület C_függvény osztály diagramja

Rövid UML példa specifikációnkat a diszkrét felület C_függvény osztály diagramjának bemutatásával zárjuk (5.79 ábra). A függvény véges területekhez rendel felület érték párokat. Az elhelyez (locate) művelet a beadott p ponthoz megadja azoknak a felületeknek a listáját melyeken az elhelyezkedik. Befejezésül még annyit, hogy az öröklődés következtében a főosztályokban deklarált módszerek érvényesek az alosztályokban is. Azt is el kell mondanunk, hogy valamennyi felsorolt módszer helyet kap a fedvény osztály nyilvános interfészében.

OGIS szolgáltatások architektúrája

Ahhoz hogy az OGIS adatmodell használható legyen a hálózaton elosztott térbeli adatok és műveletek együttes működéséhez meg kell határozni azokat a szolgáltatásokat, melyeket a rendszer biztosít. Az OpenGIS™ szolgáltatások nem terjednek ki minden feladatra, hanem csak keretet biztosítanak azokhoz a szolgáltatásokhoz, melyek szükségesek a térbeli alkalmazások fejlesztésére. A keretet azon interfészek specifikációi alkotják, melyeket bármelyik jól ismert struktúrát megvalósító objektum támogat.

A szolgáltatások felépítésének alapját a rendszer műszaki referencia modellje szolgáltatja (5.80 ábra).

5.80 ábra - OGIS szolgáltatások referencia modellje

Az ábrán is látható hat főbb entitás típus a következő:

Az alkalmazások szokásos computer programok vagy szkriptek, melyekhez a felhasználó speciális feladatok megoldása érdekében kíván csatlakozni. Az alkalmazási entitás mind a terület specifikus, mind a közös támogatottságú alkalmazásokat magában foglalja. A terület specifikus alkalmazásokat csak valamely szűk szakterület használja, míg a közös támogatottságú alkalmazásokra több szakterület is igény tart, mint például táblázatkezelésre vagy szövegszerkesztésre.

Az osztott tartomány szolgáltatásokat egy információs tartomány egy vagy több alkalmazása veheti igénybe és egy információs tartomány igényeinek megfelelően kerültek kialakításra. Ugyanakkor osztottak mivel más tartományok alkalmazásai is használhatják őket.

A közös segédeszközök CORBA specifikus modulok, melyeket alkalmazások, és osztott tartományi szolgáltatások hívhatnak meg. Jellemzőjük, hogy külső cégek készítik és nem valamely kiválasztott információs tartomány igényei szerint.

Az osztott számítási szolgáltatások az osztott számítási környezet platform független működését biztosítják.

Az objektum szolgáltatások jelentik az interfészt a CORBA és a konkrét számítógép operációs rendszere között.

A platform szolgáltatások jelentik az interfészt az osztott számítási és objektum szolgáltatások és a számítógép között, melyen a feladat fut, illetve biztosítják az interfészt a külső entitások felé.

A külső entitások kommunikációs entitásokra és információ csere entitásokra oszthatók. Az elsők közé tartoznak a drótok, optikai kábelek, stb. amin az információ áramlik. A második csoport jellemző elemei a billentyűzet, képernyő, egér, lemez, szalag, stb.

Mivel az osztott tartomány szolgáltatások, közös segédeszközök, osztott számítási szolgáltatások, objektum szolgáltatások, platform szolgáltatások szabványosítottak és hasonló funkciókat látnak el az osztott számítási és objektum környezetben (tulajdonképpen egy virtuális computeren) mint az operációs rendszer egy magányos PC-n vagy munkaállomáson, ezért a felsorolt modulokat együttesen Közös operációs környezetnek (Common Operating Environment) is nevezik, az ábrán KOK rövidítéssel jelöltük.

Az 5.80-as ábrán már feltüntettünk az alkalmazások szintjén néhány szakma specifikus tartományt, alapvetően a térbeli információt hasznosító információs közösségek területéről. Az 5.81 ábrán tovább részleteztük és pontosítottuk az alkalmazások fogalmát.

Az OGIS specifikáció aláhúzza, hogy nem specifikál alkalmazásokat, hanem csak speciális szakmai tartományokat. Ennek megfelelően a részletezésben is ezek a szakmai tartományok szerepelnek az alkalmazások első, tartomány specifikus részében. A második részben a közösen támogatott alkalmazások között olyan közismert feladatok szerepelnek, melyek általában az iroda automatizáláshoz tartoznak, de bármely specifikus szakterületnek szüksége lehet rá.
5.81 ábra - az alkalmazások csoportosítása
 

5.82 ábra - osztott tartomány szolgáltatások

Az osztott tartomány szolgáltatások az alkalmazások építőkövei (5.82 ábra). A komponens alapú architektúrában rendszerint mint 'biznisz objektumokra' hivatkoznak rájuk olyan szabványos interfészeken alapulnak, melyek szolgáltatásai előrelátható természetűek és melyeket sok alkalmazás és más biznisz objektum is meghívhat.

Ugyanezek a biznisz objektumok továbbá meghívhatnak más biznisz objektumokat vagy közös segítőket. Lényegében az osztott tartomány szolgáltatások úgy működnek mint egy szerszámos láda mely elemeit tetszőleges kombinációban lehet használni a közös segítők és objektum szolgáltatások tetszőleges kombinációval együtt, mind a tartomány specifikus mind a közösen támogatott alkalmazások végrehajtására.

A felhasználó szempontjából figyelemre méltó, hogy a térinformatikai tartomány specifikus felhasználások használhatnak nem térinformatikai biznisz objektumokat is, melyeket feltehetőleg nem az alkalmazás szoftver forgalmazója szállít.
Másfelől, a térinformatikai tartomány specifikus biznisz objektumokat az OpenGIS™ Konzorcium fogja meghatározni azért, hogy az OGIS Szolgáltatások architektúráját különböző szoftvergyártók szabványosan illeszkedő programjaival lehessen megvalósítani.

5.83 ábra - térinformatikai osztott tartományi szolgáltatások

A térinformatikai osztott tartomány szolgáltatásokat jelképező blokk foglalja össze az OGIS szolgáltatások architektúráját (5.83 ábra).

A térinformatikai tartomány szolgáltatások egy részét, melyek térinformatikai termékeket állítanak elő, csak a tartományon belüli specifikus alkalmazások használhatják. Más szolgáltatásokat, mint például a megjelenítési szolgáltatást más szakterületek is használhatják térbeli problémákat is tartalmazó feladataikban. Természetesen a térinformatikai feladatokhoz is használhatók azok a szolgáltatások, melyeket más szakterületek dolgoztak ki, de nem korlátozták azok használatát a saját tartományukban.

 

5.84 ábra - közös segítők

Ha visszatekintünk az 5.80-as ábrára, úgy látjuk, hogy az osztott tartomány szolgáltatásokkal párhuzamosan elhelyezkedő elem az OpenGIS™ szolgáltatások architektúrájában a közös segítők blokkja.

A közös segítők specifikációit más szervezet, többségében a CORBA-val kapcsolatban már megismert Object Management Group (OMG) készítette. Az 5.84 ábrán bemutatjuk főbb komponenseit, de részletezésükre nem térünk ki.

Az 5.80 ábrára nézve látjuk, hogy az architektúra következő eleme az osztott számítási szolgáltatások és feltételesen az objektum szolgáltatások a CORBA platform választása esetén.
A OpenGIS™ szolgáltatások architektúrája nem szabja meg hogy procedurális vagy objektum orientált Osztott Számító Platformot (DCP) válasszon a rendszer használója az interoperábilitás megvalósítására. A procedurális DCP-re az OMG Osztott Számító Környezet (DCE) specifikációját hozza fel például. Ha azonban az objektum orientált paradigmát választja a felhasználó, úgy sugallja, hogy az a CORBA-n alapuljon, bár a Microsoft DNA-ról is tesz említést.

Az architektúra következő alkotóeleméről a platform szolgáltatásokról csak két dolgot kívánunk megjegyezni. Először, a szolgáltatás az operációs rendszert és olyan primitív színtű szolgáltatásokat tartalmaz, melyek a platform alapfunkcionalitását biztosítják. Másodszor, míg a procedurális paradigmán alapuló programozás nagymértékben függött a platform szolgáltatásoktól, a CORBA szerinti komponens alapú architektúrák lényegében nem függnek a platform szolgáltatások milyenségétől, ezen a területen a jövőben csak a teljesítmény jellemzők és a minimális hálózati szolgáltatások megléte lesznek a meghatározók.

A külső entitások, amint már említettük, olyan hardver elemek, melyek az információ cseréjére és átvitelére szolgálnak. Az információ cserét szolgálják a billentyűzet, képernyő, egér, lemezek, stb., az átvitelt pedig kábelek, kapcsolók, erősítők, stb.

Az OGIS Szolgáltatások architektúrájában csak a legfontosabb csomópontokra tértünk ki. A téma iránt érdeklődőknek ajánlani tudjuk az absztrakt specifikáció 12., 13., 15. és 16. fejezeteinek gondos áttanulmányozását.

Az információs közösségek szemantikus fordítója

A különböző szakterületeken dolgozó emberek ugyanazokat a tárgyakat, jelenségeket különbözőképpen szemlélik. Különösen igaz ez a térbeli objektumokra, mivel ezeket az objektumokat szinte minden szakterület használja.

Az OpenGIS™ konzorcium azt a célt tűzte ki mag elé, hogy optimalizálja a különböző szakterületek (információs közösségek) által gyűjtött és kezelt térbeli adatok kölcsönös felhasználhatóságát.

Ahhoz, hogy ezt a célt gyakorlatilag is el lehessen érni az OGIS a következő feltételezésekkel élt:

  1. Minden információs közösségnek egyedülálló, közös szemantikai (értelmezési) halmaza van, mely megadja a kérdéses közösség identitását.
  2. Minden különálló, egyedi objektum gyűjteménynek egy információs közösség a tulajdonosa. Más információs közösség csak információ vesztéssel járó szemantikus fordítás után használhatja a kérdéses állományt, mely a fordítás után átmegy ennek a másik információs közösségnek a tulajdonába.
  3. Minden különálló és egyedi térinformatikai katalógust is egy információs közösség birtokol.
  4. A térbeli adatok közösségek közötti megosztása úgy nevezett szemantikus fordítók segítségével érhető el. A küldő közösséget forrás közösségnek, az adatokat átvevő közösséget tárgy közösségnek nevezik.
  5. Minden információs közösségnek egy-egy szemantikus fordítója lesz minden külső forrás közösség vonatkozásában.

Az 5.83 ábra kapcsán megemlítettük a térinformatikai tartomány elérési szolgáltatások nevű blokkot, de ennek a blokknak a további részletezésétől, hasonlóan az ábra többi blokkjához, eltekintettünk. Mivel azonban az Információs Közösségek szempontjából különös jelentősége van az OGIS Katalógus szolgáltatásainak néhány szóval ki kell térnünk ezek implementációs specifikációira.

Mindenek előtt, a tervek szerint, ezekre a szolgáltatásokra nem szándékoznak külön specifikációt írni a különböző osztott számítási környezetekre (CORBA, DCOM) hanem csak egy specifikáció fog készülni, mely minden környezetben használható lesz és mind helyi, mind hálózatos vonatkozásban biztosítja az on-line és off-line térinformatikai erőforrások feltárását.

Az OpenGIS™ katalógus szolgáltatások tartalmazni fognak:

Az információs közösségek többféle eszközzel limitálhatják erőforrásaik elérhetőségét. Legegyszerűbb, ha igénybe veszik az infrastruktúra 'trader' szolgáltatását (az objektum szolgáltatások (lsd. 5.80 ábrát) része CORBA használata esetén), de más biztonsági megoldások is léteznek.

A célból, hogy az információs közösségek egymás erőforrásait eredményesebben használhassák szemantikus fordítókra van szükség. E téren jelenleg még csak alapozó kutatások folynak. Ezt fogja követni a témára vonatkozó javaslat kérés (RFP) majd a beérkezett javaslatok felhasználásával a specifikáció.

A projekt státusa

Végül néhány szó arról, hol is tart a projekt megvalósítása.
Amint láttuk a projekt úgy valósul meg, hogy az OpenGIS™ konzorcium elkészíti az esszenciális specifikációt, ez alapján bekérik a javaslatokat, majd kidolgozzák az absztrakt specifikációt, és az erre épülő implementációs specifikációkat. Ez utóbbiak birtokában a szoftver gyártó cégek elkészíthetik specifikáció kompatíbilis szoftvereiket, melyeket az OpenGIS™ kérésre tesztel.

Az absztrakt specifikáció, ahogy arra már utaltunk, a 16 rész feladatra különböző részletességgel készült el. Az implementációs specifikáció pedig az egyszerű objektumok (Simple Features Specification ) vonatkozásában készült el három verzióban a Microsoft OLE/COM-ra, a CORBA-ra és az SQL-re. Míg az első kettő objektum orientált implementációt feltételez, addig a harmadik relációs adatbázis modellben tárolja az egyszerű objektumokat.

Ami az OGIS specifikációval konform szoftvert illeti az első programok 1999 márciusában jelentek meg.

Az ESRI Spatial Database Engine (térbeli adatbázis gép) nevű kliens / szerver programja, amely valamely relációs adatbázis kezelőre épülve alkalmassá teszi azt térbeli adatok tárolására és manipulálására. Három SDE program (az Informix, a DB2 és az ORACLE számára készült) felel meg az egyszerű objektum SQL-re történő specifikációjának a típusok és függvények szempontjából.

Az ORACLE cég Oracle8 Spatial Cartridge és Oracle8i Spatial programjai pedig a normalizált geometria szempontjából konformak ugyancsak az egyszerű objektum SQL-re történő specifikációjával.

Talán nem véletlen, hogy az első specifikáció szerinti programok relációs adatbázis kezelő kiterjesztések. Ma még ugyanis nagyon kevés objektum orientált GIS szoftver van és a legtöbb GIS szoftver relációs adatbázis kezelőt használ. Várható azonban, hogy éppen az OpenGIS™ specifikációk hatására az új szoftvereket illetve szoftver modulokat már az objektum orientált paradigma alapján fogják megalkotni a cégek.

·         a következő részben megismerkedünk az INTERNET GIS-szel

·         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