Dr. Sárközy Ferenc: Térinformatika
Thursday, August 12, 1999
Az OPEN GIS koncepció (1)
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(TM) Konzorcium célja
Az
1993-ban alakult [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ő.
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:
- Lényegi modell (Essential Model) a valós vagy képzetes
világ modellje, nincs semmi köze a szoftverhez, a helyzet elemeit,
struktúráját és tulajdonságait írja le;
- Specifikációs modell
(Specification Model) a szoftver rendszer absztrakt modellje, mely
legalább annyira részletes, hogy rá támaszkodva el lehessen készíteni az
- Implementációs modelleket
(Implementation Models) a különböző hálózati szoftver környezet (OLE/COM,
CORBA, JAVA) számára.
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(TM) 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.
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.
Az ábrán 9
absztrakciós szintet találunk 8 interfésszel a valós világ dolgainak OpenGIS(TM) 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:
- objektum példányok (feature
instances),
- geometria (Geometry),
- sarkak (Corners),
- geometriai séma (Geometry
Schema),
- térbeli referencia rendszer
(Spatial Reference System),
- objektum típusok (Feature Types),
- attribútum érték párok
(Attribute- Value Pairs),
- attribútum séma (Attribute
Schema),
- projekt séma (Project Schema).
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
- minden objektum típusra a
reprezentáló JIT-t;
- minden JIS-re, hogy mely objektum
példányok leképezésében játszik szerepet;
- minden objektum példányra a
leképező JIS-kat;
- minden JIS-re az alkotó sarkokat;
- minden sarokra azokat a JIS-eket
melyek specifikálásában részt vesz.
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:
- 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;
- 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;
- A projekt értelmezés (Project Semantics) a
projekt koncepciójának, kiterjedésének leírása;
- 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.
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).
Az 5.66 ábrán
található utolsó világ az objektum gyűjtemények világa (OpenGIS(TM) 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
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.
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.
|
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.
|
|
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(TM) 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ő:
- Alkalmazások (Applications);
- Osztott tartomány szolgáltatások
(Shared Domain Services);
- Közös segédeszközök (Common
Facilities);
- Osztott számítási és objektum
szolgáltatások (Distributed Computing and Object Services);
- Platform szolgáltatások (Platform
Services);
- Külső entitások (External
Entities).
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(TM) 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.
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
elérési szolgáltatások (Geospatial Domain Access Services - GDAS)
egy sor interfészt határoznak meg, melyek lehetővé teszik a választott
térinformatikai adatok kiolvasását és szétosztását valamely GIS-ből vagy
térinformatikai könyvtárból, illetve a könyvtárak frissítését.
- Az objektum generalizáló
szolgáltatások (Feature Generalization Services - FGS)
segítségével valósítható meg a kartográfiai objektumok generalizálása -
egyszerűsítése.
- A térbeli információ kivonó
szolgáltatások (Geospatial Information Extraction Services - GIES)
támogatják az objektum és domborzati információ kivonását a távérzékelt és
szkennelt képekből.
- A térinformatikai
koordináta transzformációs szolgáltatások (Geospatial Coordinate
Transformation Services - GCTS) felhasználásával lehet a
koordinátákat az egyik referencia rendszerből a másikba átszámítani.
- A térinformatikai
feliratozási szolgáltatások (Geospatial Annotation Services - GAS) segítségével
lehet kiegészítő információval ellátni a képeket vagy az objektumokat az
objektum gyűjteményben.
- A képmanipulációs
szolgáltatások (Image Manipulation Services - IMS) kép nagyítást,
kicsinyítést, különböző szűréseket és matematikai képfeldolgozást tesznek
lehetővé.
- Az objektum manipulációs
szolgáltatások (Feature Manipulation Services - FMS) támogatják az
objektum gyűjtemények létrehozását, ellenőrzését, elemzését és
megjelenítését a végfelhasználó szintjén.
- A képállomány feltárási
szolgáltatások (Imagery Exploitation Services - IES) a távérzékelt
és szkennelt képek fotogrammetriai elemzését támogatják.
- A térinformatikai
információ kivonó szolgáltatások (Geospatial Information Extraction
Services - GIES) olyan információk kinyerését támogatják, melyek a
nyers adatokból nem láthatók (tulajdonképpen a GIS elemző funkcióiról van
szó).
- A kép geometriai modell
szolgáltatások (Image Geometry Model Services - IGMS) a képek
regisztrálására szolgáló matematikai módszereket biztosítják.
- A térinformatikai szimbólum
kezelő szolgáltatások (Geospatial Symbol Management Services - GSMS)
támogatják a szimbólum könyvtárak használatát.
- A fototérkép generáló
szolgáltatások (Image Map Generation Services - IMGS) segítségével
manipulálhatjuk és kombinálhatjuk a képeket alkalmassá téve azokat a
fotótérképszerű használatra.
- A kép szintézis
szolgáltatások (Image Synthesis Services - ISS) - térbeli
számítási modellek segítségével végrehajtott kép generálás, transzformálás
és képjavítás a felhő és köd hatásának csökkentésére.
- A kép értelmező szolgáltatások
(Image Understanding Services - IUS) lehetővé teszik az
automatikus változás detektálást.
- A térinformatikai
megjelenítő szolgáltatások (Geospatial Display Services - GDS) egy
vagy több objektum gyűjtemény illetve fedvény előkészítését és szolgáltatását
végzik képernyő vagy hardcopy megjelenítésre.
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(TM) 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(TM) 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.
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(TM)
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:
- 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.
- 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.
- Minden különálló és egyedi térinformatikai
katalógust is egy információs közösség birtokol.
- 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.
- 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(TM) katalógus
szolgáltatások tartalmazni fognak:
- műveleteket katalógusok,
címszavak létrehozására és karbantartására;
- műveleteket új adat együttesek és
kapcsolt metaadatok létrehozására;
- műveleteket az elérhetőség
rögzítésére és közlésére;
- műveleteket a metadatokban leírt
adat tartalom és struktúra feltárására.
- A specifikációnak ki kell
terjednie mind az adatokra, mind a program modulokra, mind a hibrid
állományokra.
- A műveleteknek ki kell terjednie
a metaadatok szabványos kezelésére.
- A metaadat lekérdező műveletek
lehetővé kell hogy tegyék
- a metaadat elemek nevének és
értékének specifikálását,
- a logikai műveletek használatát,
- a metsz (intersect),
tartalmaz (contains), tartalmazva van …által (contained by), belül
(within) és túl (beyond) térbeli műveletek alkalmazását.
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(TM) 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(TM) 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(TM) 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.
(1) A tanulmány része az OTKA T 030643 témaszámon folyó kutatásnak.
Megjegyzéseit
E-mail-en várja a szerző: Dr Sárközy Ferenc