Néhány vektoros grafikus csereformátum

Ezen a lapon megismerjük

• az AutoCad grafikus csereformátumát a DXF-et;
• a MAPINFO csereformátumát a MIF és MID fájlokat valamint
• az ARC/Info ASCII csereformátumát .

DXF (Drawing Interchange Files) formátum.

Mielőtt bármit is mondanánk készítsünk el egy egyszerű AutoCAD rajzot (5.1 ábra) és listázzuk ki DXF megfelelőjét (a listázáshoz kattintson az 5.4 táblázatra).

Amint látjuk a rajz egyszerűségéhez képest elég hosszú listát kaptunk, pedig igyekeztünk helykimélés céljából a különben egy oszlopban elhelyezkedő adatokat párhuzamos oszlopokba rendezni és összezsugorítani.

A formátum megértéséhez azt kell mindenek előtt tisztáznunk, hogy a lista részekből (szekciókból) áll, melyek mint látni fogjuk különböző tipusúak lehetnek, de bármilyen tipusűak is SECTION karaktersorozattal kezdődnek és ENDSEC szóval végződnek.

A formátum másik egysége a csoport, mely mindössze két sorból áll: az első sor tartalmazz a csoport kódot, a második sor pedig a csoport értéket. A DXF lista nem más mint kölönböző kéttagú csoportok egymásutánja.

A csoport kód minden esetben megadja, hogy értéke milyen jellegű tehát karakteres, hexadecimális, decimális egész vagy lebegőpontos szám, e mellett esetenként fixen, esetenként összevontan utal a jelzett érték mibenlétére.

A DXF fájl részei (szekciói) elhelyezkédés és elnevezés szempontjából egy verzió vonatkozásában kötöttek, de verziószám növekedésével újabb csoportok jelenhetnek meg, például az OBJECTS (objektumok) szekció, mely a többszörös vonalak paraméter hivatkozásait is tartalmazza vagy a CLASSES (osztályok) szekció csak a 13-as verziótól kezdődően található meg a formátumban. Ez a bővítési lehetőség azonban kétélű fegyver, mivel a bővített DXF-eket a régebbi verziók illetve transzformációs programok nem értik. Ezt megkerülendő mind az exportnál mind az importnál lehetőség van arra, hogy a fájl csak az úgy nevezett entitás szekciót tartalmazza.

A mellékelt listán a következő szekciókat találjuk (helykimélés végett a szekciók felvázolását nem oszlop listában adjuk meg, de felhívjuk a figyelmet, hogy a tényleges fájlokban egy sorba csak egy space nélküli karaktersorozat kerül):

0 SECTION 2 HEADER (ide kerülnek azok az autocad változó értékek melyek a rajz készítése során érvényben voltak, sárga hátterü srafozzással emeltük ki a szekciót) 0 ENDSEC (a fejezet vége, amint látjuk valamennyi szekció végét ugyanaz a karakterkombináció jelöli) 0 SECTION 2 TABLES (ide helyeződnek az autocad táblázatok pld. a VPORT, mely megadja a megjelenítő ablakok paramétereit, köztük elsőnek az aktiv ablakot, a LTYPE a vonaltipusok jellemzőivel, a LAYER, mely tartalmazza a fedvényeket és jellemzőiket, a STYLE, mely a betűtipusokat írja le, a VIEW, mely a nézeteket adja meg a szemkoordináta rendszer kezdőpontjának és a vágási síkoknak a paramétereivel, az UCS a felhasználó által definiált koordináta rendszer, az újabb verziókban megjelent egy BLOCK_RECORD táblázat is, mely tartalmazza az előregyártott tömbök és a felhasználói tömbök hivatkozásait, a szekció a rendszertáblázatok bővülésével új elemekkel gazdagodik, bizonyos táblázatok elemeit csökkenthetjük, ha a dxf fájl létrehozása előtt purge utasítást alkalmazunk) 0 ENDSEC (a fejezet vége) 0 SECTION 2 BLOCKS (ebben a fejezetben találhatók a rajzban defineált tömbök, de az újabb verziókban a rajzi egységeket, tehát a modellteret és a papírteret is tömbökben defineálják) 0 ENDSEC (a fejezet vége) 0 SECTION 2 ENTITIES (ez a fejezet tartalmazza a tulajdonképpeni rajzi utasításokat a hozzátartozó koordináta mondatokkal, illetve a tömbök beillesztésére vonatkozó információkat. A tömbök tulajdonságait itt nem ismétli meg csak hivatkozik arra a táblázatra a TABLES fejezetben amelyet a BLOCKS fejezet feltölt a megfelelő rajzi értékekkel) 0 ENDSEC (a fejezet vége) 0 EOF (a fájl vége).

Szerény méretű rajzunk első tekintetre nem indokolja a tekintélyes méretű DXF fájlt. Ha azonban jobban megnézzük az állományt akkor kitűnik, hogy a tulajdonképpeni rajz nem tartalmaz több információt a fájl egy ötödénél, a többi érték akkor is megjelenik, ha csak egy pontot akarunk átvinni, mivel az állapot információk függetlenek a tényleges rajztól és csak a szoftver pillanatnyi beállításait és feltöltési állapotát tükrözik. A fentiekből következik, hogy:

• a fájlban találhatő összes információt csak az AutoCAD megfelelő verziója képes kihasználni;

• ez a 2 dimenziós GIS rendszerek szempontjából nem igazán problémás, mivel a változók illetve táblázatok jelentős része a kótázást, a megjelenítést és a rajzi minőséget szolgálja, az utóbbi célokra a GIS szoftver saját eszközökkel rendelkezik, kótázásra pedig a GIS-ben nem igen van szükség;

• ugyanakkor a DXF alkalmas a teljes adatmodell átvitelére, ami egyrészt a 3 dimenziós objektum leírásban, másrészt a tömbökkel jellemzett összetett objektumokban, a rétegszerkezetben és - az újabb (13-assal kezdődő) verziókban - az attribútum táblázatok alkalmazhatóságában jelentkezik.

A fentiekből két dolog következik: a DXF konveráló programokat mindíg az adott GIS szoftver adatmodell illetve grafikai színtjén kell megírni, másfelől tudatában kell lennünk annak, hogy a DXF konvertáló programok ezt a követelményt különböző színteken teljesítik.

A problémát még az is bonyolítja, hogy sok szoftver DXF kimenete (erre a lehetőség az AutoCAD-ban is megvan) csak az ENTITIES és EOF fejezeteket tartalmazó csonka DXF fájlokat hoz létre. Természetesen ezektől a DXF-ektől ne várjuk, hogy a rajzokat rétegekbe illetve tömbökbe rendezze. Hogy ez már a legegyszerűbb gyakorlati esetekben milyen nehézségekre vezet azt jól példázza tapasztalatunk arra az esetre, ha a SURFER-ben létrehozott színtvonal rajzot az AutoCAD-ben tovább akarjuk szerkeszteni. A SURFER a földtudományokban széleskörűen használt magasság modellező szoftver, mely közvetlenül rajzi állományokat illetve ezek DXF verziót állítja elő. Sajnos az állományok csonka DXF-ek, ami azt eredményezi, hogy mind a színtvonalak, mind a főszíntvonalak, mind pedig a megírások egy rétegen képződnek le, ezek szerkesztése (stílus változtatás, színváltoztatás, vonalvastagság változtatás, stb.) csak jelentős manuális munkával végezhető el.

Ezek után indokolt, hogy röviden megnézzük, hogy miként írja le a rajzot a DXF az ENTITIES fejezetben (megjegyezzük, hogy a BLOCKS fejezetben a tömbök leírása nagyon hasonló eszközökkel történik, ezért erre nem térünk ki).

Megnyitottuk az entitások fejezetet, majd a 0 csoportkóddal arra mutatunk, hogy milyen tipusú rajzelemről van szó. A kód értéke tehát a rajzelem neve, esetünkben POLYLINE. A 8 csoportkód a réteg név kódja, esetünkben 0. A következő 5 csoportkód sorszámot ad a rajzi entitásnak esetünkben 31, majd a 66 kód arra utal, hogy ha értéke 1, akkor a sokszög (polyline) töréspontjai következnek.

Annak érdekében, hogy a sík sokszög Z síkja határozott legyen, a fájl megad egy fiktív pontot a sokszög síkjában melynek a 10 kód utáni X és a 20 kód utáni Y koordinátája mindíg zérus, a 30 kód után megadott Z koorinátája pedig megegyezik a sík magasságával, esetünkben ez is zérus. A 70 kód értéke az attribútum milyenségét adja meg, esetünkben 1 azt jelenti, hogy a sokszög zárt.

A továbbiakban már sok az ismétlődés. Megadjuk a rajzelem nevét esetünkben töréspont (VERTEX), rétegét - 0, és sorszámát - 32. Ezután következnek a töréspontok koordinátái, mégpedig 10-es kóddal az X, 20-as kóddal az Y és 30-as kóddal a Z.

Ezután hasonlóképpen felsorolja a fájl a további három töréspontot, figyeljük meg, hogy az 5 kóddal minden töréspontnak új sorszámot ad, majd a sokszögbe tartozó elemek végét a

Következő objektumunk az ábrán látható kör lesz.

A következő lépésben a fájl rendelkezik a tömb beszúrásáról.

A 0 műveleti kód INSERT értéke jelzi a műveletet, mely a következő 0 kódig tart. A mondat megadja a beszúrandó tömb rétegét (esetünkben a 2-es réteg) a tömb sorszámát, mely a 4F hexadecimális (16 alapú) szám, a tömb nevét, melyet a rajzoláskor feltett kérdésre megadtunk: VIRAG, a beszúrási pont koordinátáit x=239.415661, y=124.807692, z=0.0, az y irányú méretarány tényezőt: 0.9, az elfordulási szöget: 50.555022.

Amint látjuk ezekből az adatokból a tömb nem állítható helyre, azaz ha csak az ENTITIES fejezetet visszük ki DXF formában úgy a tömbök csak pont formában jelennek meg. Hasonló a helyzet, ha a DXF fájlt konvertáló program csak az ENTITIES fejezetet értelmezi. Ez utóbbi esetben csak akkor tudjuk helyreállítani a teljes rajzi állományt, ha a dxfout parancs előtt felrobbantjuk a tömböt.

A szekcióban eléforduló tobábbi csoportok a VIEWPORT-ot (megjelenítő ablakot) írják le. Ha állományokat és nem nézeteket cserélünk, úgy ezeknek a csoportoknak nincs jelentősége. A DXF fájlok részletei iránt érdeklődők az AutoCAD Alkalmazáshoz Igazítási Kézikönyvből [1] szerezhetnek további információkat.

Mapinfo csereformátum: a MIF fájl.

Mielőtt bármiféle magyarázatot fűztünk volna ehhez a csere formátumhoz az 5.5 táblázatban bemutattuk az 5.1 ábrán látható alakzat listáját ebben a formátumban.

A lista úgy készült, hogy az 5.4 táblázat DXF fájlját beolvastuk import DXF utasítással a MapInfo-ba, majd export utasítással MIF fájlt hoztunk létre. A tömböt (két kékszínű csúcsban illeszkedő háromszög) egy objektumként értelmeztük, bár a MapInfoban meg van a lehetőségünk arra is, hogy a két háromszöget külön objektumként kezeljük.

Mielőtt rátérnénk a lista vizsgálatára meg kell jegyeznünk, hogy a MapInfo export egyszerre két fájlt készít az állományból egy MIF fájlt a grafikus elemeknek és egy MID fájlt az attribútumoknak. Mivel jelenleg elsősorban a grafikus adatcsere formátumokkal foglalkozunk, nem fogjuk részletezni a MID fájlt csak utalunk rá, hogy objektum azonosítónként tárolja ASCII formátumban az attribútumokat. A MID fájl opcionális, ha nincs megadva az azt jelenti, hogy minden sora üres. Hogy mégis szólnunk kell róla az egyszerűen azért van, mivel a MID fájlban tárolt táblázat alakját és fejezetét a MIF fájl fejezete határozza meg.

Lássuk ezek után a MIF listát. Már az első ránézésre látszik, hogy a fájl két részből áll: a fejezetből (header), és az adatokból (data).

A header első sora a verziószámot tartalmazza, masodik sora az irásjelkészletet, harmadik sora az elválasztó karaktert. Ez az elválasztó karakter a MID fájlban játszik szerepet. A MID fájl rekordjai sorokból állnak, melyek végén soremelés vagy soremelés kocsivissza karakter áll. Egy soron belül az oszlopokat pedig az itt megadott jellel választják el. A negyedik sor jellemzi a koordináta rendszert, az ötödik sor az oszlopok számát a MID fájlban, a következő sorok pedig (annyi sor ahány oszlopot megadtunk az előző sorban) az oszlopok nevét és tipusát valamint zárójelben a tipus jellemzőit (pld. hány karakter széles) tartalmazza.

Példánk esetében a koordináta rendszer nem valamely a program által ismert lokális földi referencia rendszer ezért a header megadja az általa értelmezett koordináta határokat. Egy oszlopot adtunk meg, melynek neve ID, tipusa pedig Integer.

A DATA szóval kezdődnek a tulajdonképpeni geometriai adatok. A leírásra soron következő grafikus objektum jellegét a következő kilenc kulcsszó valamelyikével közli a fájl: POINT, LINE, POLYLINE, REGION, ARC, TEXT, RECTANGLE, ROUNDED RECTANGLE, ELLIPSE.

Az egyes objektum tipusok részletes ismertetésétől - amennyiben az 5.5 táblázatban nem szerepel - eltekintünk, az érdeklődök az erre vonatkozó információt megtalálják a MapInfo felhasználói kézikönyvében [2].

A zárt sokszögeket REGION kulcsszóval jelöli a rendszer. Egy region egy vagy több területet is tartalmazhat. A területek számát a kulcsszó utáni szám mutatja. A következő sorban lévő szám a töréspontok számát adja meg. Figyeljük meg, hogy zárt poligonokról lévén szó a kezdő és zárópont kétszer szerepel, azaz a töréspontok száma eggyel nagyobb a ténylegesnél. Ezután következnek az x y koordináta párok (elválasztó karakter a space), majd a rajzi milyenséget kifejező opcionális Pen (szélesség, minta, szín). Esetünkben Pen (1,2,0) azt jelenti, hogy a vonalvastagság 1-es egy 1-7 skálán, a vonal minta folytonos, a szín pedig fekete. A szín 24 biten elhelyezkedő RGB érték, azaz mivel a fekete R=0, G=0, B=0 ez binárisan is azt jelenti hogy mind a 24 bit nullákkal van tele, aminek megfelelő tizes alapú szám szintén 0. A következő opcionális kulcsszó a kitöltést vezérlő Brush (minta, kitöltőszín, háttérszín), esetünkben Brush (1,0,16777215). Az 1 kitöltési minta tulajdonképpen azt jelenti, hogy nincs kitöltés, azaz a másodiknak megadott fekete kitöltő szín nem számít, a harmadiknak megadott háttér szín értelmezéséhez képzeljük el hogy az fehér azaz R=255, G=255, B=255. Irjuk fel ezeket a számokat binárisan a megfelelő bájtokba

1 1 1 1 1 1 1 1

1 1 1 1 1 1 1 1

1 1 1 1 1 1 1 1

és alakítsuk át a kapott bináris számot tizes rendszerbe egy zsebszámológép segítségével, az eredmény 16777215 lesz, azaz a háttér valóban fehér. Mivel azonban kitöltés nincs a háttérszínnek sincs jelentősége, ezért ezt az értéket sem veszi figyelembe a megfelelően megírt fordítóprogram. Az utolsó opcionális kulcsszó a Center a terület súlypontjának x y koordinátáit tartalmazza, elválasztó jelekként itt is spacek szerepelnek.

Következő új kulcsszavunk ELLIPSE attribútumában két koordináta párral az 5.1 ábra következő objektumát a kört jelöli. A két koordinátapár az ellipszis befoglaló téglalapjának két sarokpontját határozza meg. Az ellipszis tengelyei a MapInfo értelmezésében párhuzamosak a koordináta tengelyekkel. Mivel az ellipszis általánosabb a körnél, a kör is megadható egy olyan speciális ellipszissel, melynek befoglaló téglalapja négyzetté fajul. Az objektumhoz csatolt Pen (1,2,16711680) rajzi kód azt mutatja, hogy a kört a legvékonyabb folytonos vonallal vörös színnel kell rajzolni. Ha ugyanis beírjuk az R=255, G=0, B=0 értékeit bináris formában a megfelelő bytekbe majd az eredményt egy 3 byte hosszú bináris számnak tekintjük és átalakítjuk tizes

1 1 1 1 1 1 1 1

0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0

számrendszerbe úgy 16711680-at kapunk, ami megegyezik a Pen argumentumában szereplő értékkel. Az ELLIPSE-hez csatolt Brush (1,0,16777215) megegyezzik az előző objektumnál ismertettel, az ott elmondottak itt is érvényesek.

Az utolsó objektumunk is region tipusú az érdekessége, hogy az AutoCAD tömb átalakításával készült s mivel a tömb két háromszögből állt ez is két poligont fog tartalmazni. Másik említendő körülmény, hogy a kék szín, mivel úgy nyerjük, hogy a legalacsonyabb helyértékű azaz a jobboldali byte-ot feltöltjük egyesekkel a többit pedig nullákkal tizes számrendszerbe történő átalakítás után 255 értékkel fejezhető ki ebben a rendszerben.

Összefoglalva elmondhatjuk, hogy a formátum alkalmas egyszerű grafikus objektumok cseréjére, területi objektumokból álló összetett objektumokat is tud kezelni beágyazási hierarchia nélkül (csak az összetett objektumhoz tud attribútumokat rendelni a részekhez nem), e mellett gondoskodik bizonyos rajzi kódok hozzárendeléséről is.

Végül megemlítjük, hogy a formátum csak egy rétegre vonatkozik. Mivel az 5.1 ábra az AuroCad-ban három rétegre készült, a MapInfo választást ajálott fel, hogy három különálló MIF fájlba vigyük ki az adatokat vagy vonjuk össze az objektumokat egy rétegre. Mi az utóbbi eljárást választottuk.

Az Arc/Info ASCII csereformátuma.

Bár az Arc/Info is rendelkezik csereformátummal ez nem ASCII fájl, s ezért kevéssé alkalmas a téma megvilágítására. A grafikus elemek vonatkozásában azonban az Arc/Info képes ASCII állományt is létrehozni az UNGENERETE paranccsal, ezért az alábbiakban ezt a lehetőséget fogjuk röviden áttekinteni.

Az 5.1 ábra rajzát visszavittük az AutoCAD-ba, a tömböt felrobbantottuk, majd DXF-ben bevittük az Arc/Infoba és az alábbi vonal jellegű ASCII fájlt kaptuk, melyet az 5.6 táblázatra történő kattintással tudunk elővarázsolni.

Ismét el kell mondanunk, hogy ez alkalommal is helykimélés okán tördeltük a koordináta párokat három oszlopba, az eredeti fájl egy oszlopba rendezi a koordináta párokat. Amint látjuk a fájl struktúrája végtelenül egyszerű: minden objektum első sorában azonosítója foglal helyet, majd következnek a vonal töréspontjait reprezentáló koordináta párok, az objektumot END kód zárja, egy másik END pedig magát fájlt.

Felmerül a kérdés, hogy miért olyan végtelenül hosszú a második objektum leírása. Erre a válasz egyszerű: mivel a formátum semmiféle objektum tipust sem defineál explicit módon, a második objektum esetében található kör minden egyes "töréspontját" megadja az ArcInfoban szabályozott felbontási finomsággal. Implicit módon természetesen tudjuk, hisz a fájlt igy készítettük hogy az objektumok vonalak. Hasonló módon létrehozhatnánk önálló pontokból álló fedvényt is, ha az eredeti rajzunk önálló pontokat tartalmazott volna, illetve ha nem robbantjuk fel a tömböt hanem azt önálló fedvényen beillesztési pontjával helyettesítjük.

Miután a DXF fájlt bevittük az Arc/Infóba a grafikus réteghez attribútum tábla is csatlakozik, mely többek közt tartalmazza a fájlban megadott rajzi jellemzőket is. Ebből a fájlból is készíthetünk egy ASCII fájlt a TABLES DUMP utasítással, mely esetünkben a következőképpen néz ki (5.7 ábra):

Sok magyarázatra a fájl értelmezéséhez nincs szükségünk mindössze azt kell hozzátennünk, hogy F12_1 a grafikus f'ájl neve, $RECNO a record sorszáma az attribútum táblázatban, DXF__CURVE az AutoCad görbe kódja, az 1 érték a körívet jelenti.
Ezek után beláthatjuk, hogy a két fájl felhasználásával gyakorlatilag ki tudjuk használni az eredeti rajz legtöbb jellemzőjét a tömb struktúra kivétlével.

Összefoglalásul megállapíthatjuk a következőket

• A szoftvergyártók által készített átviteli formátumok csak olyan adatmodellt képesek átvinni, amilyent a kérdéses szoftver illetve szoftver verzió tartalmaz;
• A jó átviteli formátum nem kapcsolja szoftver paraméterekhez az objektumok geometriai és rajzi tulajdonságait, hanem a szükséges kódolást objektumonként hajtja végre;
• Az állomány átvitele történhet egy fájlban is, de gyakori a két vagy több összekapcsolt fájl alkalmazása is;
• A fájlok fejezeteibe össze lehet foglalni az állomány közös jellemzőit, csökkentve ezzel a fájlok méretét;
• A jó átviteli formátum ugyanannak az adatmállománynak többszíntű megértését is lehetővé teszi.

A legutolsó megállapítással kapcsolatban megjegyzem, hogy ez a feladat természetesen nem csak az átviteli formátumra, de a fogadó szoftverre is vonatkozik. Az eddigi példánkban a rövidített DXF (mely csak az entitásokat tartalmazta) nem tudta átvinni a tömböt, hanem csak a beillesztési pontját. Ha azonban a DXF úgy volna megszerkesztve, hogy az entitások között kiegészítő cimkével ellátva szerepeltetné a tömb geometriai elemeit is, a fogadó szoftver pedig, ha nem képes kezelni a tömböt, figyelmen kívül hagyná a kiegészítő címkét, de értelmezné a címkével jelölt entitásokat, úgy a magasabb logikai színtű rendszerből az alacsonyabb színtű rendszerbe is viszonylag kevés információ vesztéssel lehetne átvinni az adatokat.
 
 

a következő részben néhány raszteres export formátumot tekintünk át

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