A tervező köteles szerkeszthető formában is leszállítani a terveket? És ez most mit jelent pontosan? Projektdokumentáció terén tapasztalható, hogy az elektronikus tervszállítás már a tervezői szerződések műszaki specifikációjában pontatlanul megfogalmazott követelmények miatt esetleges. Főként igaz ez, ha tervezői konzorcium szállít több szakágra kiterjedően.

Egyre inkább követelmény, hogy a döntéshozók (beruházók, hitelezők, ügyfelek, stb.) elektronikus dokumentumok alapján tájékozódjanak és alkossanak véleményt. De ezek a dokumentumok gyakran nehézkesen kezelhetők, minőségük változó. Pixeles, vektorgrafikus, zsizsikes, szövegesen kereshető, könyvjelzőzött, van itt minden, mi a számítógépes munkát segítheti vagy hátráltathatja.

Szerződés szerint általában annyi van meghatározva, hogy PDF-ben (engterv esetében ma már a PDF/A és jogszabályi követelmények is kikötésre kerülnek) és szerkeszthető módon is kell szállítani. De mi az, hogy szerkeszthető? Minden fájl szerkeszthető megfelelő alkalmazással, ha nem írásvédett. Ezt a műszaki tartalmat kívánta a megrendelő? Ugye, hogy nem?

Gondoltam, röviden közreadom azt a követelménylistát, melyet én ma fontosnak tartok meghatározni a tervdokumentációval kapcsolatosan. Ez nem teljeskörű, nem minden igényt kielégítő. Csupán azt a szintet üti meg, hogy a "CD-n átadott tervdokumentáció" esetenként többszáz dokumentuma között ne vesszen el az ember a végtermék tallózásával, olvasásával, kiértékelésével. A lista az igények tekintetében bővíthető. Alapvető célkitűzés az, hogy - függetlenül a tervezői eszközparktól - a végeredmény bármilyen operációs rendszeren több ingyenes és/vagy nyíltforráskódú alkalmazással megnyitható, továbbszerkeszthető legyen. Most is és a távolabbi jövőben is. Ezt biztosítja a nyíltforráskódú és szabványos formátumokra való törekvés.

(És talán ebben a körben meg sem kell külön említeni, hogy a terv és a dokumentáció nem azonos fogalmak!)

Formai követelmények a Vállalkozó által szállított dokumentumok tekintetében

A szállítandó elektronikus dokumentumokat két formátumban kell szállítani: natív módon szerkeszthető és PDF/A formátumban. Elektronikus szállítás történhet elektronikus adathordozón (pl. pendrive, előre meghatározott tárhely, felhőszolgáltatás) vagy optikai adathordozón (DVD).

Mindkét esetben követendő, hogy a nyomtatási méret iratoknál A4 (betétlapoknál A3), tervlapoknál járatos nyomtatási formátum, feleljenek meg a hatályos jogszabályi előírásoknak (különös tekintettel a hatósági engedélyezéshez fűződőekre).

A fájl neve és a szállított adathordozó könyvtárstruktúrája (azaz a teljes elérési út) nem tartalmazhat ékezetes betűket, és a „-", „_" karaktereken kívül speciális karaktereket, s a teljes elérési út hossza nem lehet több, mint 120 karakter. (Ez a későbbi másolhatóság miatt fontos, ugyanis windowsos rendszerben a fájlok elérési útja nem lehet végtelen hosszú karakterlánc.)

1. Natív módon szerkeszthető formátumok
   
   1. Szöveges dokumentumok esetében DOCX v. ODT formátumban.
   2. Táblázatos dokumentumok esetében XLSX v. ODS formátumban.
   3. Rajzok (tervrajzok) esetében DXF, DWG, PLN formátumok valamelyikében.
   4. Pixeles képek esetében JPG formátumban veszteségmenetes tömörítéssel, legalább 0,94Mp felbontásban, vektorgrafikus képek esetében SVG formátumban.
   5. Egyéb dokumentumok esetében az előállító szoftver alapértelmezett fájlformátumában. Ez esetben a fájl mellett egy OLVASSEL.TXT nevű és kiterjesztésű fájlban rögzíteni szükséges a fájlt előállító szoftver nevét, verziószámát és a szoftver fejlesztőjének nevét.
2. PDF/A formátum
   1. Szövegesen kereshető.
   2. Felhasználásban (megnyitásban, nyomtatásban, másolásban, exportálásban, stb.) nem korlátozott, jelszóval nem védett.
   3. Többoldalas dokumentum esetén könyvjelzőzött.
3. Látványtervek
   1. Engedélyezési terv és kiviteli terv szakaszban fotórealisztikus minőségben, korábbi tervfázisokban legalább építészeti modell minőségben.
   2. Nyomdai minőségben, legalább 30*20 cm-es méretben és legalább 300 dpi felbontásban. (PR igény esetén)
   3. A fájl formátuma TIFF.
   4. Külön szállítandó a nyers, renderelt kép és a staffázsolt végeredmény kép.
   5. A pontos helyszíneket tervfázisonként az Ajánlatkérővel előzetesen egyeztetni kell.
   6. Látványtervek készülnek a munkaközi tervváltozatokhoz is igény szerint (alátámasztásul), ezekre azonban nem vonatkoznak a látványtervi paraméterek.

Indoklás

Az általánosan elterjedt szerződéses gyakorlat szerint az elektronikus tervekkel szemben azt írják elő, hogy a tervezőnek a készített terveket elektronikusan is kell szállítani: szerkeszthető és nem szerkeszthető formátumban is. Ez mind informatikai, mind jogi megfogalmazásban iis rossz, nem tükrözi a kiíró szándékát és érdekét. A szándék általában az, hogy a későbbi másolhatóság, feldolgozhatóság érdekében DXF (vagy DWG) és PDF formátumban is meglegyen a terv. Mert a megrendelőnek érdeke, hogy költséghatékonyan további tevékenységei során rendelkezésre álljon a terv, ne kelljen mindig fénymásolni, vagy újból felszerkeszteni azt. És akkor csak a tervalpokra gondoltunk, az egyéb tokumentációrészekre nem!

Azonban a "szerkeszthető fájl" nem formátumot takar, hanem jogosultságot. Hiszen alapvetően igaz az, hogy minden fájl tartalma szerkeszthető (valamilyen szoftverrel és szaktudással), ha ezt a fájl publikálója nem tiltja le. Mondjuk jelszavas védelemmel. A helyes kifejezés itt az, hogy "natív módon szerkeszthető".

A natív azt jelenti, hogy a készítő szoftver (környezet) számára értelmezhető, átalakítás nélkül szerkeszthető. Ez még mindig elég tág fogalom, a ma használatos Word verziók is bő tucat natív fájlformátumot ismernek és szerkesztenek natív módon. Ezek közül olyat érdemes választani, mely általánosan elterjedt és nyíltforráskódú. Ez utóbbi kritérium azért fontos, hogy minél nagyobb eséllyel minden szabványtisztelő szoftver a készítőjének eredeti elképzeléséhez minél hívebben jelenítse meg a dokumentumot. Szövegszerkesztő esetében ez ma a DOCX (Office Open XML, az Microsoft fejlesztette) és az ODT (OpenDocument Text, ezt egy nemzetközi közösség fejlesztette). Mindkettő szabványosított formátum, s mindkettőt elég jól olvassa mind a Word, mind a Libre Office, de gyakorlatilag minden valamire való szövegszerkesztő és kiadványszerkesztő is. Azaz nem igaz az, hogy az ODT megengedésével vállalnunk kellene a Libre vagy Open Office-ok használatát cégünknél, hiszen ezt a Word a 2007 SP2 óta natívan támogatja. Az, hogy több natív fájlformátumot fogadunk el, az versenysemlegességi kérdés, ugyanis ezzel nem kényszerítjük a tervezőt saját megszokott környezetéből más típusú szabvány követésére (munkájának kétes eredményű exportálására), mi csak annyit írunk elő, hogy nyílt szabványt kövessen.

Az archív fájllal is hasonló a helyzet: nyílt szabványt kérünk. Ugyanakkor ezt már biztosan exportálással fogja előállítani a vállalkozó, s a cél sem a natív módon történő szerkeszthetőség, hanem a műszaki tervtárak számára a hosszútávú és egyértelmű megőrizhetőség. A PDF, mint főszabvány önmagában még kevés (pontosabban elégtelen számú) biztosítékot kínál az informatikai igények kielégítésére, a PDF/A már elegendőt. A PDF/A alatt is több szabvány létezik, de kár jobban részletezni, különleges egyedi igények hiiányában valamennyi PDF/A szabvány megfelelő. (Azt azért nem árt tudni, hogy a miinél magasabb verziószámú szabvány jobb eredményt, kisebb fájlt ad. Például, ha a tervező átlátszó kitöltéseket is használ a terven, akkor minimum PDF/A-2 a célszerű, mert a PDF/A-1 nem kezeli a transzparenciát, így egy hatalmas, pixeles fájlt fogunk eredményül kapni, melyet nagyon lassan és nehezen fogunk tudni kezelni.)

Fontos tudni, hogy a DVD és a CD nem elektronikus adathordozó, hanem optikai. Jogi jelentősége van, hogy szállításnál újraírható, azaz módosítható állományt írunk elő, illetve fizikai módon is fontos birtokba venni azt (pl. iktatásra egy DVD lemezt).

Megjegyzés: A tervlapok tekintetében a natív nyílt szabvány szerinti fájlformátum előírása túlzó lenne, ugyanis a nagy tervező szoftverek nem követik a nyílt szabványok útját, sőt, bezárkóznak és megnehezítik az átjárhatóságot. Egyszerűen nem gyakorlat nyílt fájlformátumban dolgozni, az exportálással pedig elveszítenénk a kiírás eredeti értelmét, magát a törekvés lényegét. Így ezen a területen belátó és kompromisszumkész módon csak annyit kérünk, hogy nevezze meg azt a szoftvert, amivel készítette a natív formátumot. Mert az esetleges későbbi munkához szükségünk lesz arra az információra, hogy mivel lehet a legjobb eredménnyel tovább dolgozni rajta. Ugyanis a natív formátum nem jelent automatikusan hozzárendelhető szoftvert, illetve a szoftverhez sem mindig rendelhető egyértelműen egyetlen natív fájlformátum. (Az, hogy "Word dokumentum", már kábé egy évtizede értelmetlen kifejezés a fentiek értelmében.)

Továbbiak: Az elektronikus építészeti-műszaki dokumentáció